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*
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 w
"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 developmen
On Fri, Aug 30, 2002 at 08:03:29AM -0700, Terry Lambert wrote:
> For all we know, AMD has gotten out of the new Silicon business all
> together, and will simply be shipping upgraded simulators of things
> which would be cool if they were ever taped out, plactic'ed, and
> slotted in a ZIF in non-ex
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
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
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 ting
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,
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 a
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 ar
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.
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,
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 UltraSPARC? :) :) :)
Unfortunately, my SPARC machine is not an UltraS
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 c
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:
[ ..
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 w
16 matches
Mail list logo
