On Sun, Sep 01, 2002 at 09:51:32PM -0700, Terry Lambert wrote:
The original claims for the tape-out on the x86-64 from AMD so
that this could happen were September 2001, with sample units
1Q2002. The AMD schedule slipped.
LOL! This slippage is *NOTHING* compared to Merced/IA-64. When I was
David O'Brien wrote:
On Sun, Sep 01, 2002 at 09:51:32PM -0700, Terry Lambert wrote:
The original claims for the tape-out on the x86-64 from AMD so
that this could happen were September 2001, with sample units
1Q2002. The AMD schedule slipped.
LOL! This slippage is *NOTHING* compared
Brandon D. Valentine wrote:
[ ... AMD ... ]
In all seriousness I'm not sure where he got the idea that these things
were supposed to be out a while ago but I don't recall any claims from
AMD to confirm that. If anything AMD's development cycle for these
things makes Intel's development cycle
Terry Lambert writes:
Wilko Bulte wrote:
I knew not to recommend the Alpha because it is limited to 2G
of physical memory.
?
FreeBSD is limited to using 2G of whatever you have in the Alpha.
Which is a deficiency that has been debated a number of times,
IIRC it
Another interesting processor family is the AMD x86-64 ClawHammer.
I do not know the progress the FreeBSD/x86-64 project. I would imagine
the major difficulty will be getting a running compiler.
I just wish AMD added an 8K page size so the Page Table Maps did not
eat so much memory.
--mark
Ut-oh. Time for a rant...
mark tinguely wrote:
Another interesting processor family is the AMD x86-64 ClawHammer.
I do not know the progress the FreeBSD/x86-64 project. I would imagine
the major difficulty will be getting a running compiler.
Actually, the major difficulty is getting a box,
mark tinguely wrote:
Another interesting processor family is the AMD x86-64 ClawHammer.
I do not know the progress the FreeBSD/x86-64 project. I would imagine
the major difficulty will be getting a running compiler.
Nope, the compiler is already pretty robust.
I just wish AMD added an 8K
Hello all,
I've been thinking what kind of modifications would it need to decide
the KVA space size at the kernel boot time (maybe an argument to
btext), instead of compile time. In theory I can't see any obstacles.
Basically the approach would be simply the following:
- The current KERNBASE
Aaro J Koskinen wrote:
I've been thinking what kind of modifications would it need to decide
the KVA space size at the kernel boot time (maybe an argument to
btext), instead of compile time. In theory I can't see any obstacles.
Basically the approach would be simply the following:
[ ...
Apparently, On Thu, Aug 29, 2002 at 12:41:14PM -0700,
Terry Lambert said words to the effect of;
Aaro J Koskinen wrote:
I've been thinking what kind of modifications would it need to decide
the KVA space size at the kernel boot time (maybe an argument to
btext), instead of compile
On Thu, Aug 29, 2002 at 01:48:11PM -0700, Terry Lambert wrote:
Jake Burkholder wrote:
If you need a larger amount of UVA space, you might want to consider
buying an IA64 machine, instead, since the bigger your iron, the
bigger your KVA space requirements will be.
What, no
Hello Terry,
On Thu, 29 Aug 2002, Terry Lambert wrote:
Aaro J Koskinen wrote:
I've been thinking what kind of modifications would it need to decide
the KVA space size at the kernel boot time (maybe an argument to
btext), instead of compile time. In theory I can't see any obstacles.
Wilko Bulte wrote:
I knew not to recommend the Alpha because it is limited to 2G
of physical memory.
?
FreeBSD is limited to using 2G of whatever you have in the Alpha.
Which is a deficiency that has been debated a number of times,
IIRC it needs bus space work etc. See the archives..
Aaro J Koskinen wrote:
Am I completely off the track? What are the main reasons behind the
current KVM layout?
Kernel code is not position independent.
Yes, I understand this. It seems I failed to explain what I meant. :-(
The reason for moving the kernel text, data and bss to the
14 matches
Mail list logo
