Is Itanium the first 64-bit casualty?

[Guest]

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

I'd be very surprized. Actually, Windows NT and its children are designed
from the beginning to support 64-bit physical address for DMA.

You don't have to switch CPU to another mode, to do 64-bit DMA. It's
physical address, not virtual.

"Zak" <jute@zak.invalid> wrote in message
news:xR7Fc.809$vH5.567@amstwist00...
>
> > As it turns out Intel's 64-bit doesn't even support DMA beyond 32-bit
memory
> > address boundary.
>
> That would be very strange as it is supported (using 64 bit PCI
> addressing) on older Xeons. But stranger things have happened... hmm...
> switch CPU to 32 bit mode, do your 64 bit DMA, then switch back? Hehe...
>
>
> Thomas

 

[Guest]

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

Sander Vesik <sander@haldjas.folklore.ee> wrote:
> 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.

Usually file size and addressability are related when you're using memory
mapped i/o. The advantage of memmaps is that after you've finished the
initial setup of the call, you no longer have to make any more OS calls to
get further pieces of the file, they are just demand-paged in just like
virtual memory. Actually, not _just like_ virtual memory, it _is_ actual
virtual memory. Saves many stages of context switching in between this way.

Many operating systems, such as Solaris, are actually using memmaps natively
even within the OS kernel. The OS standard file i/o calls are all wrappers
around memmaps. When an application uses standard file i/o, it's still
ending up using memmaps, except the OS does the job of memmapping for you;
so an application employing memmaps directly saves a few intermediate steps.

Of course for a memmap to work you have to native support for a large
address space. You can do this either by combining two 32-bit registers
together to form a single 64-bit pointer, or you can have a true 64-bit
register.

Yousuf Khan

 

[Guest]

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

Dan Pop <Dan.Pop@cern.ch> wrote:
> At my previous job, all workstations with a single user, sitting on or
> near his desk, were called desktops, just as the PCs and Macs. The
> ones
> in the machine room were called servers, even if they were identical
> with
> those in the first category. The definition was based on how the
> machine
> was used and not on some political/religious issues.

I've always looked at a "workstation" as simply a very expensive "desktop".
🙂

Yousuf Khan

 

[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:
> Sander Vesik <sander@haldjas.folklore.ee> wrote:
> > 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.
>
> Usually file size and addressability are related when you're using memory
> mapped i/o. The advantage of memmaps is that after you've finished the

no. They are still not related and you can use any size of files you want.
the *only* relation adressing has to this is the size of teh windows you can
use.

> initial setup of the call, you no longer have to make any more OS calls to
> get further pieces of the file, they are just demand-paged in just like
> virtual memory. Actually, not _just like_ virtual memory, it _is_ actual
> virtual memory. Saves many stages of context switching in between this way.

With all the drawbacks of that aswell, however.

>
> Many operating systems, such as Solaris, are actually using memmaps natively
> even within the OS kernel. The OS standard file i/o calls are all wrappers
> around memmaps. When an application uses standard file i/o, it's still
> ending up using memmaps, except the OS does the job of memmapping for you;
> so an application employing memmaps directly saves a few intermediate steps.
>
> Of course for a memmap to work you have to native support for a large
> address space. You can do this either by combining two 32-bit registers
> together to form a single 64-bit pointer, or you can have a true 64-bit
> register.

*not* pointer. File offsets are not pointers. BigInts are very easy to handle
and it has basicly almost no extra overhead.

>
> Yousuf Khan
>
>

--
Sander

+++ Out of cheese error +++

 

[Guest]

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

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
news:7veFc.670078$Ar.473944@twister01.bloor.is.net.cable.rogers.com...
> Zak <jute@zak.invalid> wrote:
> >> As it turns out Intel's 64-bit doesn't even support DMA beyond
> >> 32-bit memory address boundary.
> >
> > That would be very strange as it is supported (using 64 bit PCI
> > addressing) on older Xeons. But stranger things have happened...
> > hmm... switch CPU to 32 bit mode, do your 64 bit DMA, then switch
> > back? Hehe...
>
> I don't think it would need to be switched to 32-bit just to do DMA, more
> likely, they will prevent the devices from writing beyond the 4GB barrier.
> And if they need to write beyond that barrier, then the OS would have to
> take care of repaging the lower 4GB into the upper addresses.

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.

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.

IIRC, DMA writes to physical memory addresses and not logical or linear
addresses, so you can't play tricks with the paging system to get around
this. Either use some trickery to allocate DMA buffers in low memory, or
employ bounce buffers when the specified buffer isn't in low memory itself.

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 Fri, 02 Jul 2004 20:40:01 GMT, "Stephen Sprunk" <stephen@sprunk.org>
wrote:

>"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
>news:7veFc.670078$Ar.473944@twister01.bloor.is.net.cable.rogers.com...
>> Zak <jute@zak.invalid> wrote:
>> >> As it turns out Intel's 64-bit doesn't even support DMA beyond
>> >> 32-bit memory address boundary.
>> >
>> > That would be very strange as it is supported (using 64 bit PCI
>> > addressing) on older Xeons. But stranger things have happened...
>> > hmm... switch CPU to 32 bit mode, do your 64 bit DMA, then switch
>> > back? Hehe...
>>
>> I don't think it would need to be switched to 32-bit just to do DMA, more
>> likely, they will prevent the devices from writing beyond the 4GB barrier.
>> And if they need to write beyond that barrier, then the OS would have to
>> take care of repaging the lower 4GB into the upper addresses.
>
>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".

>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.

>IIRC, DMA writes to physical memory addresses and not logical or linear
>addresses, so you can't play tricks with the paging system to get around
>this. Either use some trickery to allocate DMA buffers in low memory, or
>employ bounce buffers when the specified buffer isn't in low memory itself.

Depends on the device - the AGP aperture allows precisely that.

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?)

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:%3gFc.2572$R36.1650@newsread2.news.pas.earthlink.net...
> I'd be very surprized. Actually, Windows NT and its children are designed
> from the beginning to support 64-bit physical address for DMA.
>
> You don't have to switch CPU to another mode, to do 64-bit DMA. It's
> physical address, not virtual.

Ah, but only 64-bit PCI cards can understand 64-bit physical addresses.
It's quite possible (and in time, likely) to allocate a buffer above the
32-bit limit and drivers for 32-bit PCI cards will need some trickery to get
the data to/from the right place.

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?)

Stephen Sprunk wrote:
[snip]

> IIRC, DMA writes to physical memory addresses

[snip]

DMA does but DVMA doesn't. Sun, and presumably all the other RISC
vendors', systems have IOMMUs which translate bus addresses to physical
addresses for DMA transfers. The AMD K8 has an on-chip IOMMU.

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

 

[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: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"?

> >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.

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

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 Fri, 02 Jul 2004 21:01:20 GMT, "Stephen Sprunk" <stephen@sprunk.org> wrote:

>"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
>news:%3gFc.2572$R36.1650@newsread2.news.pas.earthlink.net...
>> I'd be very surprized. Actually, Windows NT and its children are designed
>> from the beginning to support 64-bit physical address for DMA.
>>
>> You don't have to switch CPU to another mode, to do 64-bit DMA. It's
>> physical address, not virtual.
>
>Ah, but only 64-bit PCI cards can understand 64-bit physical addresses.
>It's quite possible (and in time, likely) to allocate a buffer above the
>32-bit limit and drivers for 32-bit PCI cards will need some trickery to get
>the data to/from the right place.

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

 

[Guest]

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

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.

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."

 

[Guest]

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

Robin KAY <komadori@myrealbox.com> wrote:
+---------------
| Stephen Sprunk wrote:
| > IIRC, DMA writes to physical memory addresses
|
| DMA does but DVMA doesn't. Sun, and presumably all the other RISC
| vendors', systems have IOMMUs which translate bus addresses to physical
| addresses for DMA transfers. The AMD K8 has an on-chip IOMMU.
+---------------

Not "all the other RISC vendors' systems": In SGI's Origin 2000/3000 XIO
32-bit DMA addressing -- that is, PCI "A32" cycles (whether D32 or D64) --
is mapped through an IOMMU[1], but 64-bit DMA addressing (PCI "A64" cycles)
is mapped one-to-one with physical memory[2], which is a *tremendous*
performance advantage for devices that can do a few "smart" things such
as select which of multiple sets of pre-staged buffers to use based on
the size of the transfer, etc.


-Rob

[1] Well, not always. For each PCI bus, there is a 2 GB window that
can be mapped to any 2GB (2GB-aligned) portion of main memory.
But normally, A32 devices use the 1 GB window that's page-mapped
through the IOMMU for that bus.

[2] Well, almost. The low 48/52/56 bits are one-to-one with physical
memory, but for A64 transfers a few upper bits are used to convey
side-channel information, such as BARRIER write or not, PREFETCH
read or not, etc. Again, using A64 transfers provide a tremendous
performance advantage for devices that can dynamically decide when
to set BARRIER, say. (With A32 & the IOMMU, those attributes are
a fixed part of each page's mapping. Ugh.)

-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

 

[Guest]

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

In article <1c0ce05ruik6p4ir24ocsk0qtbppig9t8u@4ax.com>,
daytripper <day_trippr@REMOVEyahoo.com> wrote:

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

Hush! He was sounding very convincing, let's not burst his bubble.

-- greg

 

[Guest]

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

On Sat, 03 Jul 2004 01:24:39 GMT, lindahl@pbm.com (Greg Lindahl) wrote:

>In article <1c0ce05ruik6p4ir24ocsk0qtbppig9t8u@4ax.com>,
>daytripper <day_trippr@REMOVEyahoo.com> wrote:
>
>>Someone obviously never heard about 32b PCI's 64b "Dual Address Cycle"...
>
>Hush! He was sounding very convincing, let's not burst his bubble.

ooops! sorry ;-)

 

[Guest]

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

Bengt Larsson 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.

It is still totally stupid IMO.

Dual sourcing is there for a reason. It's not a fetish. It can ensure
that there is competition which keeps prices reasonable. It can help
reduce the risk of common mode failures. It can ensure that if your
supplier become unwilling to supply you with critical components,
you have an alternative.

How much would it cost to fab say 100 units of an IA-64 chip that run
within 90% of the speed of a full blown IA-64 (ignore the cost of losing
your shirt to Intel in a courtroom) ? Answer : Lots. Designing and
fabbing 100 IA-64 boards on the other hand is a *lot* cheaper.

Like I said : It's not just a fetish, it's a sane way of doing business.

> 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).

The point remains : Would Fujitsu be able to do that vs HP/Intel ?
Unlikely, because they couldn't produce a chip of their own that gave
them the characteristics and product differentiation required. HP/
Intel would just sue the pants off them - or make it prohibitively
expensive. 😉

> "In Theory, there is no difference between Theory and Practice, in
> Practice, there is."

Indeed. Practice is : Intel has you over a barrel if you buy IA-64,
whereas Sun does *not* have you over a barrel if you buy SPARC.


Cheers,
Rupert

 

[Guest]

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

In Windows, you can do different ways:

1. A driver can allocate a contiguous non-pageable buffer and do DMA
transfers to/from it. The buffer can be requested to be in lower 4 GB, or
even in lower 16 MB, if you need to deal with legacy DMA.
2. A buffer may be originated from an application. In this case, MapTransfer
function may move the data from/to a buffer in low memory (bounce buffer
you've mentioned), if a device is unable to do DMA above 4 GB. It's done by
HAL, and drivers don't need to bother. If a device supports scatter-gather,
only some parts of the transfer may need bounce buffers.

"Stephen Sprunk" <stephen@sprunk.org> wrote in message
news:d8ca95587a26dd1fa8a9352d9840c566@news.teranews.com...
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:%3gFc.2572$R36.1650@newsread2.news.pas.earthlink.net...
> > I'd be very surprized. Actually, Windows NT and its children are
designed
> > from the beginning to support 64-bit physical address for DMA.
> >
> > You don't have to switch CPU to another mode, to do 64-bit DMA. It's
> > physical address, not virtual.
>
> Ah, but only 64-bit PCI cards can understand 64-bit physical addresses.
> It's quite possible (and in time, likely) to allocate a buffer above the
> 32-bit limit and drivers for 32-bit PCI cards will need some trickery to
get
> the data to/from the right place.
>
> 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?)

With use of IOMMU, bounce buffers are not necessary in Windows.

For a DMA transfer, NT HAL maps a virtual address to a device-visible memory
address. Device-visible memory address is not necessarily the same as
physical address, even though for most cases it is.

If IOMMU can map 32-bit PCI bus-master address to any 64-bit memory address,
HAL can set up the mapping and returns the corresponding address, which the
driver should tell the PCI device.

I don't know if HAL supplied with XP 64 does that, but it fits very well to
NT architecture, and doesn't require to change drivers.

"Stephen Sprunk" <stephen@sprunk.org> wrote in message
news:7e5151c106093be538ff8c18346d2a6d@news.teranews.com...
>
> 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.
>
> If you have a better solution then, as they say, "send patches."
>
> 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?)

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:WlpFc.3150$R36.2326@newsread2.news.pas.earthlink.net...
> In Windows, you can do different ways:
>
> 1. A driver can allocate a contiguous non-pageable buffer and do DMA
> transfers to/from it. The buffer can be requested to be in lower 4 GB, or
> even in lower 16 MB, if you need to deal with legacy DMA.
> 2. A buffer may be originated from an application. In this case,
MapTransfer
> function may move the data from/to a buffer in low memory (bounce buffer
> you've mentioned), if a device is unable to do DMA above 4 GB. It's done
by
> HAL, and drivers don't need to bother. If a device supports
scatter-gather,
> only some parts of the transfer may need bounce buffers.

Linux has the same two cases. I think the bounce buffers are handled in
generic code but the drivers have to explicitly support them; it's been a
while since I read the docs on that, so the kernel may handle it
automagically now.

I'd never heard of "Dual Address Cycle" (thanks daytripper), so I did some
reading. NT does use it if every PCI device in the system supports it. If
a single PCI device is non-DAC-capable (which includes most consumer hw),
then bounce buffers are used for all DMAs above 4GB. I don't know if Linux
takes the same approach or just assumes bounce buffers are always needed
above 4GB.

I still note that the same mess is present with 24-bit ISA DMA, and there's
even cases where some DMA buffers have to live in the first 1MB for obscure
backwards-compatibility reasons. These hacks will remain in amd64, so it's
not much more of a mess to do the same for 32-bit PCI. I'm not claiming
it's ideal, but it's already standard practice.

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?)

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.

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.

Yousuf Khan

 

[Guest]

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

Nick Maclaren wrote:
> In article <2x0Fc.9424$XM6.996@attbi_s53>,
> Scott Moore <samiam@moorecad.com> writes:
> |>
> |> > What is actually wanted is the ability to have multiple segments,
> |> > with application-specified properties, where each application
> |> > segment is inherently separate and integral. That is how some
> |> > systems (especially capability machines) have worked.
> |>
> |> Thats what paging is for, and, IMHO, a vastly superior system that
> |> gives you memory attributing while still resulting in a linear
> |> address space.
> |>
> |> 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 !
>
> I suggest that you read my postings before responding. It is very
> clear that you do not understand the issues. I suggest that you
> read up about capability machines before continuing.
>
> You even missed my point about the read-only and no-execute bits,
> which are in common use today. Modern address spaces ARE segmented,
> but only slightly.
>
>
> Regards,
> Nick Maclaren.

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.

--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Being right is more powerfull than large corporations or governments.
The right argument may not be pervasive, but the facts eventually are.

 

[Guest]

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

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.

--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Being right is more powerfull than large corporations or governments.
The right argument may not be pervasive, but the facts eventually are.

 

[Guest]

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

"Yousuf Khan" <bbbl67@ezrs.com> writes:
>The advantage of memmaps is that after you've finished the
>initial setup of the call, you no longer have to make any more OS calls to
>get further pieces of the file, they are just demand-paged in just like
>virtual memory. Actually, not _just like_ virtual memory, it _is_ actual
>virtual memory. Saves many stages of context switching in between this way.

What do you believe happens on a page fault? Yes, typically a context
switch.

So mmap does not necessarily save context switches; it may save system
calls, though (typically one uses fewer, larger mmaps than reads,
often just one).

The main benefit of mmap (compared to read), however, is that it
usually eliminates a kernel-to-user-space copy without eliminating
disk caching by the kernel. It also allows to write programs in a
slurping style more efficiently.

Mmap also has some disadvantages, though, which is why it is not the
most popular I/O method; in particular, it does not work on all things
that can be opened, and it has no atomicity guarantees (except those
given by the hardware).

Followups to comp.arch

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

 

[Guest]

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

In article <H6sFc.17283$7t3.14605@attbi_s51>,
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.

I like it! Please collect your wooden spoon as you go out.


Regards,
Nick Maclaren.

 

[Guest]

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

"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. Most 64-bit addressing CPUs don't yet have full 64-bit virtual
address translation.

> --
> Samiam is Scott A. Moore
>
> Personal web site: http:/www.moorecad.com/scott
> My electronics engineering consulting site: http://www.moorecad.com
> ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
> Classic Basic Games web site: http://www.moorecad.com/classicbasic
> The IP Pascal web site, a high performance, highly portable ISO 7185
Pascal
> compiler system: http://www.moorecad.com/ippas
>
> Being right is more powerfull than large corporations or governments.
> The right argument may not be pervasive, but the facts eventually are.

 

[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:

>Bengt Larsson <bengtl5.net@telia.NOSPAMcom> wrote:
>> 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.
>
>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 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-IA64
AIX-on-PowerPC

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.