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:
[ ..
15 matches
Mail list logo
