Is Itanium the first 64-bit casualty?

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.arch, "Yousuf Khan" <bbbl67@ezrs.com> wrote:

>Peruse the members list for Sparc International Inc., the consortium
>entrusted with maintaining the Sparc standards:
>
>http://www.sparc.com/
>
>It's considerably more than just Sun and Fujitsu. Some people are actually
>building Sparcs for embedded applications.

I'm aware of Sparc International, BTW.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

daytripper <day_trippr@REMOVEyahoo.com> writes:

> Someone obviously never heard about 32b PCI's 64b "Dual Address
> Cycle"...

Someone ranted on the PCI sig list years ago to say it should be
REQUIRED, and that the idea of a 32bit counter plus a 32bit static
high address register should be shot at birth.

Welcome to the pit. Again...

--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Scott Moore <samiam@moorecad.com> writes:

> Obviously you didn't live through the bad old days of segmentation,
> or you would not be avocating it.

Perhaps you should raise your eyes and notice that there is more to
the world than misbegotten barnacles from a chip vendor. The problem is not
segmentation, it is 80x86s.

--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Bengt Larsson wrote:

[SNIP]

> I meant general-purpose systems, like those built by Dell, IBM, HP.
> What defines a platform there is operating-system-on-hardware and
> application compatibility with it. For example, Windows-on-x86 is what
> we can thank (or blame) for still having x86 in the way we do.
>
> Compare for example the following:
>
> Solaris-on-SPARC
Linux-on-SPARC
OpenBSD-on-SPARC
NetBSD-on-SPARC
FreeBSD-on-SPARC

> Linux-on-IA64
>
> and which is the more open platform? I think it's clear that
> HPUX-on-IA64 is more closed than any of these and Linux-on-x86_64 is
> more open.

IA-64 is just limited. You're stuck with a single source who can yank
your chain anytime they feel like it, high migration cost and ah heck
all native applications. Take a look at how swiftly HPQ dropped Alpha.

They can use that same volume/market place justification to axe IA-64.
Arguably it would make even more sense when you compare IA-64 volumes
to Alpha volumes at the point Alpha was axed, but that's another rant
that's already happened and it's dull.

My personal thought on the matter is that two of the things that have
kept IA-64 safe from the bean counters so far are :

1) Minimal competition (MIPS, Alpha, SPARC sidelined on performance
or support)
2) Executive face saving.
3) Maintaining a small edge in the performance stakes.

AMD have addressed 1) very aggressively, forcing Intel to respond in
kind with a catch-up product. That same catch-up product will be
filling the market segments that IA-64 was meant to descend into in
order to drive down it's price and broaden it's application base.

As for 2), people retiring/changing employers/getting fired could
change that in the blink of an eye.

Now for point 3). The margin of superiority over the competition has
not been stunning and the range of *commerical* software available
for it remains limited. So the customers are not necessarily being
attracted to the product, instead they are being kicked towards it
by vendors killing off lines they were quite happy with. Vendors can
get away with that to a degree, but if a viable alternative shows up
(AMD64) with lower migration cost (AMD64), wider software base (AMD64),
and lower system cost (AMD64), then they will probably lose those
same customers.

I still haven't decided whether St. Pfister leaping overboard is a
reliable indicator for the future of the good ship "Itanic".

Cheers,
Rupert

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.arch Bengt Larsson <bengtl5.net@telia.nospamcom> wrote:
> In comp.arch, Rupert Pigott
> <roo@try-removing-this.darkboong.demon.co.uk> wrote:
>
> >Not my call. Reminds me a little of the thread about some Intel dude
> >calling SPARC "proprietry".
>
> Actually, there are only two systems-vendors for SPARC systems (Sun
> and Fujitsu) but more for Itanium systems (IBM, HP, Dell, SGI,
> NEC...). Raw processors is not what is bought by most people. So the
> argument isn't totally stupid.

You are basicly wrong on all counts:
* there are far more than 2 system vendors for sparc[1]
* there are even more board vendors that just Sun & Fujitsu
* IBM, HP, Dell, SGI, NEC, ... are not good examples as
none of these have or even *could* have a second source
for Itanium CPUs, so its not clear what advantage you really
get from multiple repackagers

[1] Sun, Fujitsu, Tadpole, Naturetech all make their own original boards
from which a whole bunch of companies make systems.

>
> In theory and legally you can clone SPARC, build Solaris systems to
> compete directly with Sun. In practice, forget it. Sun has too much
> momentum (Fujitsu has managed by building bigger systems than Sun).
>
> "In Theory, there is no difference between Theory and Practice, in
> Practice, there is."
>

In prcatice, there is also a difference between reality and getting
your facts wrong.

--
Sander

+++ Out of cheese error +++

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Fri, 02 Jul 2004 04:49:09 GMT, "Yousuf Khan" <bbbl67@ezrs.com>
wrote:
>Stephen Sprunk <stephen@sprunk.org> wrote:
>> There was a year or so when an Alpha running x86 binaries on FX!32 did
>> indeed outpace the fastest x86 machines available, though by less
>> than a 50% margin. I believe it was right before the P6 core came
>> out.
>
>As far as I recall, FX32 came out a long time after the P6 core introduced.
>P6's first generation, PPro, was already obsolete, and they were already
>into the second generation, PII. PPro was introduced in late 1995. I don't
>think FX32 came out till sometime in 1997.

FX!32 actually made it out sometime in '96, and for a brief moment it
may well have been faster at running x86 code on Alpha systems than
the fastest x86 systems out there. At that time, all Intel had was
the PPro 200MHz. In fact, Intel was in a bit of a lull, with the PPro
having been released in late '95 at 200MHz and never really been
surpassed until the release of the 233-300MHz PII chips in May of '97.
Meanwhile DEC had managed to push their Alpha chips up to 500MHz or
maybe even 600MHz.

At this time I'm pretty certain that there were at least a few
applications that would have run faster on the Alpha and FX!32 than
the 200MHz PPro. Mind you, with translation/emulation you have a lot
of variation in performance and it was probably only some sort of
best-case type of programs that were faster. All in all though it
probably would have made for a pretty respectible x86 workstation,
albeit a waste of money if that was all you were going to do with it.
Seems a shame to cripple a chip with such incredible (at the time)
native performance by translating and emulating code all the time.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Thu, 01 Jul 2004 19:42:37 GMT, "Stephen Sprunk"
<stephen@sprunk.org> wrote:
>"Rupert Pigott" <roo@try-removing-this.darkboong.demon.co.uk> wrote in
>message news:1088700445.812547@teapot.planet.gong...
>> I think the distinguishing features for the PHBs were :
>> 1) It didn't run x86 binaries native (unlike PCs aka "Desktops")
>> 2) It cost more for a given level of performance.
>
>By both measures, a Mac is a workstation and not a desktop.

Yes, but there's a third important point: A workstation must look
tough and manly...

Macs, on the other hand, are most popular in Bonderberry Blue... As
someone in this newsgroup once mentioned: "fruity chips need not
apply" :>

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Thu, 1 Jul 2004 22:08:14 -0600, "Judd" <IhateSpam@stopspam.com>
wrote:
>"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
>news😛j97e09ahuh9sdq8ha8go0rv3rvejlbmsi@4ax.com...
>> Smart business move for who?!? For Intel maybe, but how exactly does
>> it help MS' cause? It's not like they're selling more by not having a
>> product now and I can't see any way that it would help them long-term.
>> Not releasing the product until the end of this year or early next
>> year (it looks like 64-bit Windows is being delayed *again*) is only
>> going to hurt Microsoft relative to Linux.
>>
>
>It isn't hurting them at all. Development costs $$$... In today's world,
>you don't develop unless the $$$ is there. The $$$ isn't there until Intel
>is OEM'ing large quantities of 64-bit hardware. Linux isn't gaining
>anything at all from this.

Linux probably isn't gaining much marketshare (and hence, not gaining
much money), but it is gaining some mind-share from this. 64-bit
Linux has been here, stable and working for a full year now, while
Windows is still off in the distance. This sort of thing goes a LONG
way to demonstrating what people have said all along about Linux and
open-source, it gets developed and stable much faster than
closed-source Windows.

Development may cost money, but developing a product for 3 years
without selling it costs more money than developing it for 2 years
without selling it. The simple fact of the matter is that the longer
64-bit x86 Windows spends in development the less time it will spend
actually being sold to customers.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Fri, 02 Jul 2004 22:41:52 GMT, "Stephen Sprunk" <stephen@sprunk.org>
wrote:

>"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
>news:ufnbe0p3vaf2t91udbr3vlhukor0gufoju@4ax.com...
>> On Fri, 02 Jul 2004 20:40:01 GMT, "Stephen Sprunk" <stephen@sprunk.org>
>> wrote:
>> >This technique has been used for a decade to handle other types of DMA
>which
>> >must be in the first 1MB or 16MB of memory; extending the model to handle
>> >32-bit PCI DMA only in the first 4GB of memory would be minor.
>>
>> Yeah it was used in DOS Extenders and we were all glad (ecstatic ?) when
>it
>> was retired for "doing it right".
>
>And what, pray tell, is "doing it right"?

Uhh that would be not doing device transfers in a sub-optimal way.

>> >Linux has had "bounce buffers" to do these sorts of things for a long
>time,
>> >if not since the beginning. I recall seeing PCI bounce buffers in the
>> >source to support earlier 64-bit machines such as a the Alpha. Little
>work
>> >should be required to extend this to amd64, and presumably it's already
>been
>> >done.
>>
>> Extend to AMD64?? It's a hack... which AMD64 doesn't need.
>
>The hack already exists for 16-bit ISA DMA, and there's no obvious way to
>remove it or it would have been done by now. Likewise, there's no obvious
>way to remove bounce bufferring for 32-bit PCI DMA. The Linux folks may be
>religious wackos, but they're not dumb.

ISA DMA is a different mechanism from PCI Bus Mastering - if you need
bounce bufferng with both, commonality of code is not obvious. As for
32-bit PCI Bus Mastering, it depends on devices, PC memory mappings and
legacy support - the code may have to be there to cover that but it's
certainly possible to do without bounce buffering for current modern
hardware to <4GB main memory. Doing it all the time is err, sub-optimal;
designing new hardware which needs it is an abberation, maybe even a case
of incompetence or contempt!

>If you have a better solution then, as they say, "send patches."

This has nothing to do specifically with Linux but I can't believe the
capability is not already there.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
news:4ciee0dgggvv0qco4aqh791b9l6ri2oqs2@4ax.com...
> On Fri, 02 Jul 2004 22:41:52 GMT, "Stephen Sprunk" <stephen@sprunk.org>
> wrote:
> >The hack already exists for 16-bit ISA DMA, and there's no obvious way to
> >remove it or it would have been done by now. Likewise, there's no
obvious
> >way to remove bounce bufferring for 32-bit PCI DMA. The Linux folks may
be
> >religious wackos, but they're not dumb.
>
> ISA DMA is a different mechanism from PCI Bus Mastering - if you need
> bounce bufferng with both, commonality of code is not obvious.

The commonality is obvious. If a driver requests a DMA to/from a buffer
that's outside the address space addressable by DMA, then you use a bounce
buffer. Only the size of the address space is different between the two.

The mechanisms of performing a DMA are very different, but the bounce buffer
code is identical.

> As for
> 32-bit PCI Bus Mastering, it depends on devices, PC memory mappings and
> legacy support - the code may have to be there to cover that but it's
> certainly possible to do without bounce buffering for current modern
> hardware to <4GB main memory. Doing it all the time is err, sub-optimal;
> designing new hardware which needs it is an abberation, maybe even a case
> of incompetence or contempt!

Neither Windows nor Linux uses bounce buffers if the src/dst buffer is in
the low 4GB. I know Linux allows device drivers to specifically request a
buffer in the low 4GB (or 16MB), but by default they're located higher to
conserve low memory, and buffers may come from sources that are unaware of
their physical address (like applications); I presume Windows has the same
mechanisms.

S

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Sun, 04 Jul 2004 22:46:42 GMT, "Stephen Sprunk" <stephen@sprunk.org>
wrote:

>"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
>news:4ciee0dgggvv0qco4aqh791b9l6ri2oqs2@4ax.com...
>> On Fri, 02 Jul 2004 22:41:52 GMT, "Stephen Sprunk" <stephen@sprunk.org>
>> wrote:
>> >The hack already exists for 16-bit ISA DMA, and there's no obvious way to
>> >remove it or it would have been done by now. Likewise, there's no
>obvious
>> >way to remove bounce bufferring for 32-bit PCI DMA. The Linux folks may
>be
>> >religious wackos, but they're not dumb.
>>
>> ISA DMA is a different mechanism from PCI Bus Mastering - if you need
>> bounce bufferng with both, commonality of code is not obvious.
>
>The commonality is obvious. If a driver requests a DMA to/from a buffer
>that's outside the address space addressable by DMA, then you use a bounce
>buffer. Only the size of the address space is different between the two.
>
>The mechanisms of performing a DMA are very different, but the bounce buffer
>code is identical.

Floppy vs. HDD?? When the device accesses are so different, there's no
reason to attempt common code - one will evolve the other stays the same.

>> As for
>> 32-bit PCI Bus Mastering, it depends on devices, PC memory mappings and
>> legacy support - the code may have to be there to cover that but it's
>> certainly possible to do without bounce buffering for current modern
>> hardware to <4GB main memory. Doing it all the time is err, sub-optimal;
>> designing new hardware which needs it is an abberation, maybe even a case
>> of incompetence or contempt!
>
>Neither Windows nor Linux uses bounce buffers if the src/dst buffer is in
>the low 4GB. I know Linux allows device drivers to specifically request a
>buffer in the low 4GB (or 16MB), but by default they're located higher to
>conserve low memory, and buffers may come from sources that are unaware of
>their physical address (like applications); I presume Windows has the same
>mechanisms.

Well, well, we seem to be in danger of agreeing... apart from the fact that
the reason to not bounce is more to do with efficiencies, i.e. not having
to do mem-mem copies. An app., of course doesn't have to know about buffer
physical addresses anyway.

Now if we have one mfr who does it right and the other who does it with
err, legacy chipset functionality, which seems preferable?

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Scott Moore wrote:

--snip snip
>
>
> Having segmentation return would be to me like seeing the Third
> Reich make a comeback. Segmentation was a horrible, destructive
> design atrocity that was inflicted on x86 users because it locked
> x86 users into the architecture.
>
> All I can do is hope the next generation does not ignore the
> past to the point where the nightmare of segmentation does not
> happen again.
>
> Never again !
>

8086/88 did NOT have SEGMENTS ! ! ! They could
address up to 64K bytes from base addresses
that could be on any 16 byte boundary. That's
all, no length, no attributes, nothing. Some
marketdroid (or Bruce Ravenal?) decided to name
them segments and the well has been poisoned ever since.

B5000/5500/Multics/B6700 et seq had segments
and used them rationally and well.

80286 et seq had segments that could be optionally
used but which no one used.

Are you railing against 8086 so-called "segments" or
real (Burroughs/Multics) segments?

JKA

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Rupert Pigott wrote:

> Scott Moore wrote:
>
>> Rupert Pigott wrote:
>>
>>> I think we should play the Marketoids at their own game : Let's start
>>> referring to IA-64 as "Legacy" now that we have a dual-sourced 64bit
>>> architecture in the x86 world.
>>
>>
>>
>> It didn't get widespread enough to be a legacy.
>
>
> I think it's old enough and dead enough and has had enough money thrown
> at it to be called legacy though. 😉
>
> Cheers,
> Rupert
>

A legacy is what let's you buy a boat or send your
kids to college. In our whole field "legacy" should
be replaced by "millstone". Let's start with IA64 a
millstone architecture.

JKA

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Rupert Pigott wrote:

> Scott Moore wrote:
>
>> Rupert Pigott wrote:
>>
>>> I think we should play the Marketoids at their own game : Let's start
>>> referring to IA-64 as "Legacy" now that we have a dual-sourced 64bit
>>> architecture in the x86 world.
>>
>>
>>
>> It didn't get widespread enough to be a legacy.
>
>
> I think it's old enough and dead enough and has had enough money thrown
> at it to be called legacy though. 😉
>
> Cheers,
> Rupert
>

A legacy is what let's you buy a boat or send your
kids to college. In our whole field "legacy" should
be replaced by "millstone". Let's start with IA64 a
millstone architecture.

JKA

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Tony Hill wrote:
> At this time I'm pretty certain that there were at least a few
> applications that would have run faster on the Alpha and FX!32 than
> the 200MHz PPro.

One advantage that FX!32 had over other "fragile" IA32 translators
in use today is that its translations were persistent, and not
limited in size. Both P4's trace cache and Transmeta's Crusoe are
said to have a weakness whenever code size makes the (single)
decoder the bottleneck. FX!32 should only have had that
limitation the first time it saw a new program.

On the other hand, FX!32 was first introduced on EV4 Alphas, I
think, and they had their own reasons for being somewhat brittle,
compared to their OOO successors.

Cheers,

--
Andrew

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In <fgyFc.121$_X2.15@newsfe3-win.ntli.net> "Peter Dickerson" <first{dot}surname@ukonline.co.uk> writes:

>"Scott Moore" <samiam@moorecad.com> wrote in message
>news:ScsFc.396$JR4.230@attbi_s54...
>> Sander Vesik wrote:
>>
>> > In comp.arch Yousuf Khan <bbbl67@ezrs.com> wrote:
>> >
>> >>Stephen Sprunk <stephen@sprunk.org> wrote:
>> >>
>> >>>I've never run across a desktop app that needs more than 2GB of
>> >>>address space; for that matter my 512MB machine (with no VM) handles
>> >>>anything I throw at it, though I'm sure it'd be a bit faster if the
>> >>>motherboard accepted more than that.
>> >>
>> >>Many news readers are running into the file size limitation when
>downloading
>> >>from binary newsgroups.
>> >
>> >
>> > What does file size have to do with 32 vs 64bit? The OS I run on my
>desktop
>> > has been supporting file sizes in excess of 4GB since at least 1994 when
>I
>> > switched to it, *including* on plain vanilla x86 hardware.
>> >
>>
>> It enables you to memory map files.
>
>You mean memory map whole files? There isn't any reason why a big file can't
>be mmapped into a 32-bit address space as a window. Its a sane way too.
>Otherwise you can't mmap a file that is bigger that the virtual memory of
>the system.

That's why people want 64-bit pointers even if they don't plan to install
more than 4 GB of memory on their systems.

>Most 64-bit addressing CPUs don't yet have full 64-bit virtual
>address translation.

They have as much as needed to cover the current demands. No current
system with a 64-bit CPU can realistically store a file of 2 ** 63 bytes.
So, no need to mmap such a file. For the time being...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Dan Pop wrote:
>
> In <fgyFc.121$_X2.15@newsfe3-win.ntli.net> "Peter Dickerson" <first{dot}surname@ukonline.co.uk> writes:
>
> >"Scott Moore" <samiam@moorecad.com> wrote in message

> >Most 64-bit addressing CPUs don't yet have full 64-bit virtual
> >address translation.
>
> They have as much as needed to cover the current demands. No current
> system with a 64-bit CPU can realistically store a file of 2 ** 63 bytes.
> So, no need to mmap such a file. For the time being...
>

They can if they use sparse files (a simple form of compression). There
are some crude ad hoc database implementations that hash index into
sparse files. It's fun backing up those kind of databases as raw files.
Takes a long time. You could mmap it and scan for non zero data. That
would give your virtual memory subsystem a good run.

Joe SEigh

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Scott Moore <samiam@moorecad.com> wrote:
>
> I have heard the arguments over and over and over (and over) again.
>
> Obviously you didn't live through the bad old days of segmentation,
> or you would not be avocating it.

Nick Maclaren wrote:
>
> I like it! Please collect your wooden spoon as you go out.

Nick: He's not going to understand. He doesn't even know about google.

Scott: At least on my newsreader, Nick's posts contain the header

Organisation: University of Cambridge.

Google for "Nick Maclaren University of Cambridge" to decide whether
Nick is too young to know about segmentation.

Google for "University of Cambridge wooden spoon" to learn about spoons.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <40E955B5.4B184D93@xemaps.com>,
Joe Seigh <jseigh_01@xemaps.com> writes:
|> Dan Pop wrote:
|> >
|> > They have as much as needed to cover the current demands. No current
|> > system with a 64-bit CPU can realistically store a file of 2 ** 63 bytes.
|> > So, no need to mmap such a file. For the time being...
|>
|> They can if they use sparse files (a simple form of compression). There
|> are some crude ad hoc database implementations that hash index into
|> sparse files. It's fun backing up those kind of databases as raw files.
|> Takes a long time. You could mmap it and scan for non zero data. That
|> would give your virtual memory subsystem a good run.

Heaven help me, yes. At least two compilers I am inflicted with
use memory mapping and sparse access; in one case, it means that
I can't set the store limits low enough to protect the system
against a user making a mistake and running us out of swap in a
single process!

It is ridiculous that one of the first things that some vendors'
development teams have used 64-bit addressing for is to make their
products unmanageable by their employer's own operating system.
But, as Schiller said:

Against stupidity, the Gods themselves contend in vain

A related insanity is a perverse program that spawns its processes
using MPI, and then uses a massive shared memory segment for data
transfer. If I make the limits large enough to let that one
through, and a user makes a mistake in his space calculations,
by, bye system.


Regards,
Nick Maclaren.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

I artiklen <2skhe0pd1pc65v5glg0s9rd9o0p1018pc6@4ax.com> , George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> skrev:

> Now if we have one mfr who does it right and the other who does it with
> err, legacy chipset functionality, which seems preferable?

It is strange that Intel put 64 bit in Prescott, but forgot about the
chipset. FWIW, Apples G5 chipset has a GART lookalike for HyperTransport.
They call it DART for DMA Address Relocation Table.

--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <ccbhvo$f5b$1$830fa795@news.demon.co.uk>,
"Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:
|>
|> Google for "Nick Maclaren University of Cambridge" to decide whether
|> Nick is too young to know about segmentation.

Gosh! Thanks. I had completely forgotten that debate. I am
getting old ....


Regards,
Nick Maclaren.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Dan.Pop@cern.ch (Dan Pop) writes:

> That's why people want 64-bit pointers even if they don't plan to install
> more than 4 GB of memory on their systems.

In practice it's more than 2GB.

On a 32bit OS the kernel normally needs some virtual space (1-2GB
depending on the OS) that cannot be used by applications and there is
space lost to shared libraries etc. Due to fragmentation and other
waste virtual memory is less efficiently used than physical memory. If
you need continuous virtual space and you're slightly unlucky the cut
off point can be even at slightly over ~1.5GB. This can be increased
by special tuning, but this generally needs some effort and has some
disadvantages.

-Andi

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Andi Kleen wrote:
> Dan.Pop@cern.ch (Dan Pop) writes:
>
>> hat's why people want 64-bit pointers even if they don't plan to install
>> more than 4 GB of memory on their systems.
>
> In practice it's more than 2GB.

[snip]

For sun4u systems at least, the Solaris kernel uses only 4mb at the top
of the process address space. All non-immediate SPARC load/store
instructions have an 8-bit field for an address space identifier.
Solaris/IA32, on the other hand, allows processes to use up to 3gb of
the virtual address space. I think more in some configurations.

--
Wishing you good fortune,
--Robin Kay-- (komadori)

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Robin KAY" <komadori@myrealbox.com> wrote in message
news:1089041690.40745.0@iris.uk.clara.net...
> Andi Kleen wrote:
> > Dan.Pop@cern.ch (Dan Pop) writes:
> >
> >> hat's why people want 64-bit pointers even if they don't plan to
install
> >> more than 4 GB of memory on their systems.
> >
> > In practice it's more than 2GB.
>
> [snip]
>
> For sun4u systems at least, the Solaris kernel uses only 4mb at the top
> of the process address space. All non-immediate SPARC load/store
> instructions have an 8-bit field for an address space identifier.
> Solaris/IA32, on the other hand, allows processes to use up to 3gb of
> the virtual address space. I think more in some configurations.

RedHat offers a special kernel that allows each process just shy of 4GB, and
the kernel gets its own 4GB. Syscalls require a page table swap, which
makes them slower, but apparently some folks consider having double the
address space per process to be worth it.

Hopefully all those people will be switching to amd64 soon and such tricks
can be forgotten.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Mon, 05 Jul 2004 07:39:10 GMT, J Ahlstrom <AhlstromJK@comcast.net> wrote:

>Scott Moore wrote:
>
> --snip snip
>>
>>
>> Having segmentation return would be to me like seeing the Third
>> Reich make a comeback. Segmentation was a horrible, destructive
>> design atrocity that was inflicted on x86 users because it locked
>> x86 users into the architecture.
>>
>> All I can do is hope the next generation does not ignore the
>> past to the point where the nightmare of segmentation does not
>> happen again.
>>
>> Never again !
>>
>
>8086/88 did NOT have SEGMENTS ! ! !

Yes, it did.

And I'm not yet quite old enough to forget setting CS, DS, SS and ES segment
registers in my yute...

/daytripper (who is sad that the 8086 is already Misremembered History ;-)