G
Greg Lindahl
daytripper said:
Hush! He was sounding very convincing, let's not burst his bubble.
-- greg
Hush! He was sounding very convincing, let's not burst his bubble.
-- greg
D
daytripper
ooops! sorry ;-)
R
Rupert Pigott
Bengt said:
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.
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.
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
A
Alexander Grigoriev
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.
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.
A
Alexander Grigoriev
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.
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.
S
Stephen Sprunk
Alexander Grigoriev said:
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
Y
Yousuf Khan
Bengt Larsson said:
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
S
Scott Moore
Nick said:
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.
S
Scott Moore
Sander said:
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.
R
Rob Warnock
+---------------
| 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.)
| 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.)
A
Anton Ertl
Yousuf Khan said:
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
P
Paul Repacholi
daytripper said:
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.
P
Paul Repacholi
Scott Moore said:
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.
N
Nick Maclaren
I like it! Please collect your wooden spoon as you go out.
Regards,
Nick Maclaren.
P
Peter Dickerson
Scott Moore said:
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.
B
Bengt Larsson
Yousuf Khan said:
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.
B
Bengt Larsson
Yousuf Khan said:
I'm aware of Sparc International, BTW.
R
Rupert Pigott
Bengt Larsson wrote:
[SNIP]
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 bugger
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
[SNIP]
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 bugger
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
S
Sander Vesik
In comp.arch Bengt Larsson said:
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 prcatice, there is also a difference between reality and getting
your facts wrong.
T
Tony Hill
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.