dbrus.Unify.Com.hearth@unify.uucp (Donald S. Hearth) (08/08/90)
I have a HP 9000/375 computer. Somebody informs me that any software
developed on my 375 will run on a 9000/400 series computer. Does anybody
have any info on the 400 series at all? What kind of architecture is it?
Thanks in advance,
Don Hearthsmith@groucho (08/09/90)
In article <j902s89@Unify.Com> dbrus.Unify.Com.hearth@unify.uucp (Donald S. Hearth) writes: > > I have a HP 9000/375 computer. Somebody informs me that any software >developed on my 375 will run on a 9000/400 series computer. Does anybody >have any info on the 400 series at all? What kind of architecture is it? It's 68030 and 60040 based. Runs HPUX and Domain (not at the same time). It's supposedly object code compatable (under HPUX) with the 300 series. It's part of HP's merged platform plan. Probably the 300 series will die soon. __ | | My employer will disavow any ----------------------------- | | knowledge of my actions. William Smith |. | Microelectronics Research Center \ | University of Idaho / \ Moscow, ID 83843 | \ (208)885-6500 | \ | ---| E-mail: wsmith@groucho.mrc.uidaho.edu | | ---------------------------- | | |----------
rjn@hpfcso.HP.COM (Bob Niland) (08/09/90)
re: > I have a HP 9000/375 computer. Somebody informs me that any software > developed on my 375 will run on a 9000/400 series computer. Correct. For the same revs of HP-UX, the 300 and 400 are binary compatible. The HP-UX software is the very same product on both 300 and 400. Even hardware-level I/O drivers should work (although recompilation may be wise due to kernel table structure changes from release to release). > What kind of architecture is it? Compared to your 375, these things are the same: * Same SPU architecture, including 68030 processor daughter board, cache and memory management. Your self-modifying code for your 300 will work fine on your 400, (but will break on both 300 & 400 when you upgrade to 68040 with copyback cache enabled :-) * Both 300 and 400 upgradable to 68040. * Same RAM boards (SIMMs). * Same backplane (DIO-II), although future 400's will move away from DIO. * Same built-in AUI/ThinLAN, low-speed HP-IB, SCSI, HP-HIL, beep, centronics and first RS-232C port * 4 new video interfaces were introduced with the s400. They are also supported on the 300 (various releases). These things are different: * Boot ROM is a superset of the 300, and can boot DOMAIN as well as HP-UX. - Apollo keyboard port present (ignored by HP-UX). - Apollo serial ports 2&3 present (supported by HP-UX in a future rel). - Apollo token ring port optional. * The deskside 400 supports built-in SCSI peripherals (3 full-high 5.25-inch spaces, one divisible into 2 half-high). Although the 340 and 345 support a single 3.5-inch hard disk, no previous 300 has supported built-in 5.25 devices. * Maximum of 6 available DIO-II slots (vs 10 on 375). * Only two DIO-I (I/O) slot possible (vs 10 pairs on 375). * No built-in "Option 010" high-speed HP-IB available on 400. Must order separate 98625B card and A1401A DIO-II to DIO-I/O downconverter. * Any customer-supplied DIO cards that are bus-masters need to be re-tested on the 400 looking for 300-specific shortcuts assumed in their designs. * 3 EISA/ISA slots possible on 400"S" (vs 4 VME on 375). VME may yet become available on the 400. Regards, Hewlett-Packard Bob Niland Internet: rjn@hpfcrjn.FC.HP.COM 3404 East Harmony Road UUCP: [hplabs|hpfcse]!hpfcrjn!rjn Ft Collins CO 80525-9599
rjn@hpfcso.HP.COM (Bob Niland) (08/09/90)
re: naturally my response got networked instantly, and THEN I noticed... > * Both 300 and 400 upgradable to 68040. More precisely: * Both 375 and 400 upgradable to 68040. > - Apollo token ring port optional. Make that... - Apollo token ring port optional, ignored by HP-UX. > * Maximum of 6 available DIO-II slots (vs 10 on 375). Make that... * Maximum of 5 available DIO-II slots (vs 10 on 375). Both figures assume no graphics card. Bob Niland Internet:rjn@hpfcrjn.FC.HP.COM UUCP:[hpfcse|hplabs]!hpfcrjn!rjn
rjn@hpfcso.HP.COM (Bob Niland) (08/09/90)
re: > Probably the 300 series will die soon.
Only if you customers kill it by so voting with your purchase orders. The
top-end 300 will offer the same '040 performance as the 400, and the 300 can
do some things the 400 can't yet do, and may never do, like...
* Lots of DIO-II slots; up to 10 available (vs 5)
* Lots of DIO-I slots; more than you can actually use (vs only 2 on 400).
* Run stand-alone BASIC and Pascal operating systems.
* Easy rack-mount.
Regards, Hewlett-Packard
Bob Niland Internet: rjn@hpfcrjn.FC.HP.COM 3404 East Harmony Road
UUCP: [hplabs|hpfcse]!hpfcrjn!rjn Ft Collins CO 80525-9599rer@hpfcdc.HP.COM (Rob Robason) (08/10/90)
William Smith concludes:
> Probably the 300 series will die soon.
This is incorrect. There are still lots of uses for the 300 with it's
inherent strengths for which the 400 is not well suited. At least one
of these is instrument control, which depends on the DIO/I backplane.
Others are applications requiring rack-mounted systems like work-cell
and imbedded controllers. I'm sure the 300 will be around for a long
time.
It does seem as though the 400 is the way to go for a general purpose
UN*X based workstation though.
Rob "strictly my opinion" Robasonjinx@zurich.ai.mit.edu (Guillermo J. Rozas) (08/10/90)
> What kind of architecture is it?
Compared to your 375, these things are the same:
* Same SPU architecture, including 68030 processor daughter board, cache
and memory management. Your self-modifying code for your 300 will work
fine on your 400, (but will break on both 300 & 400 when you upgrade to
68040 with copyback cache enabled :-)
This is actually no laughing matter. Some Lisp systems (and other
systems with garbage collectors) put (some) user code in data space by
default, and it is rellocated and moved at garbage collection time, so
in effect, it has to be re-linked at every GC. If the data updates
are not seen by the I-cache, the system will not work.
Hopefully there will be some system call in future versions of HP-UX
to flush the complete cache system back to memory (and invalidate
I-cache entries).
On the Series 800 this can be done by using FIC, FDC, FICE, and FDCE,
which are all user-mode instructions, but on the 68040 the cache
management instructions are, unfortunately, priviledged instructions.
Note that this problem is not confined to esoteric languages such as
Lisp. The GNU C compiler depends on cache consistency to make local
procedures work, since local procedures are implemented as
instructions on the stack that jump to the shared code.
I hope HP doesn't shoot itself on the foot on this one.rjn@hpfcso.HP.COM (Bob Niland) (08/11/90)
re: >> Your self-modifying code for your 300 will work fine on your 400, (but >> will break on both 300 & 400 when you upgrade to 68040 with copyback >> cache enabled :-) > This is actually no laughing matter. > If the data updates are not seen by the I-cache, the system will not work. We know it. My remarks were partially intended to get end users and software developers thinking about the issue. > Hopefully there will be some system call in future versions of HP-UX to > flush the complete cache system back to memory (and invalidate I-cache > entries). There will, and in the '040 release (be that 7.05 or 8.0). > I hope HP doesn't shoot itself on the foot on this one. The default will be that copyback is enabled, with 'chatr(1)' options and other methods to disable/flush it in stages. I don't have the complete details, but I do know that providing cache controls for the user is a hot topic in the software lab. Regards, Hewlett-Packard Bob Niland Internet: rjn@hpfcrjn.FC.HP.COM 3404 East Harmony Road UUCP: [hplabs|hpfcse]!hpfcrjn!rjn Ft Collins CO 80525-9599
mikef@hp-ptp.HP.COM (Mike_Forman) (08/11/90)
The Series 400 will, indeed, run Series 300 software. It is based upon the MC68030 and MC68040 processors, depending upon model. Series 400 systems can be ordered to run either HP-UX or Domain/OS, so they serve to unify the hardware for Series 300 and DN-series users wishing to move up the performance ladder. HP-UX continues to support DIO cards, but new graphics systems are used. The graphics libraries are compatible, though. Systems range from the 12 MIPS 400DL at $4990 U.S. list price, to the 25 MIPS 433S, starting at less than $20K. Hope this helps. Mike Forman Hewlett-Packard Workstation Group
wayne@dsndata.uucp (Wayne Schlitt) (08/13/90)
In article <7370192@hpfcso.HP.COM> rjn@hpfcso.HP.COM (Bob Niland) writes: > re: >> Your self-modifying code for your 300 will work fine on your 400, (but > >> will break on both 300 & 400 when you upgrade to 68040 with copyback > >> cache enabled :-) > > [ ... ] > > > Hopefully there will be some system call in future versions of HP-UX to > > flush the complete cache system back to memory (and invalidate I-cache > > entries). > > There will, and in the '040 release (be that 7.05 or 8.0). > (there was a similar thread in comp.arch about the problems of self modifying code and caches...) pardon my ignorance, but why does the 040 break things worse than the 030? dont they both have separate instruction and data caches? the only difference that i know of is the fact the the 030's caches are tiny (256 bytes for I & D) and therefor you are not as likely to encounter problems. -wayne
jinx@zurich.ai.mit.edu (Guillermo J. Rozas) (08/14/90)
In article <WAYNE.90Aug12150209@dsndata.uucp> wayne@dsndata.uucp (Wayne Schlitt) writes:
pardon my ignorance, but why does the 040 break things worse than the
030? dont they both have separate instruction and data caches? the
only difference that i know of is the fact the the 030's caches are
tiny (256 bytes for I & D) and therefor you are not as likely to
encounter problems.
Certainly the probabilities are different, but there are real
differences as well:
- The 68030 caches are direct-mapped, while the 68040 caches are
set-associative with random line replacement.
- The 68030 D-cache is write-through, while the 68040 is either
write-through or store-in, depending on the configuration (per
access).
With a 68030, main memory (or a secondary shared off-chip cache)
always contains valid data, and if there is an i-cache miss, the right
data will be brought in. Thus we only need to figure out a way (from
user code) to flush the appropriate cache entry. Since the cache is
direct mapped, executing a nop (or set of nops) with the correct
bottom bits in its address will do the trick. If code modifications
are rare, and a hundred instructions are not a large price to pay (as
at the end of a relocating garbage collection), running through enough
nops to "invalidate" all i-cache entries will flush the complete
i-cache.
The 68040 is worse. If the access is such that writes are stored in
rather than written back, main memory does not have valid data. Thus
even if we could invalidate the i-cache entries, we might get invalid
data on the next access. Because the cache is set associative and the
line replacement algorithm is random, we can't be sure that we've
flushed the dirty data back to main memory or that we've invalidated
the i-cache entry!rer@hpfcdc.HP.COM (Rob Robason) (08/15/90)
wayne> pardon my ignorance, but why does the 040 break things worse wayne> than the 030? dont they both have separate instruction and data wayne> caches? the only difference that i know of is the fact the the wayne> 030's caches are tiny (256 bytes for I & D) and therefor you are wayne> not as likely to encounter problems. My understanding is that the fetch of instructions doesn't look in the data cache and hence instructions written there by self modifying code are missed. Rob