anton (03/17/83)
Following Henry Spencer's (utzoo!henry) revelations aboutthe internal structure of the 68k, how about this.... Little of it is new, though some may be to the net and still more to the newer members. Lemma: All the 16 and 32 bit machines with 16 bit busses are *crippled* when you try using them with 32 bit words. main reason is having to go read, read, operate, wrwite, write. Corrolary: This it seems is non obvious. If you treat ints as 16 bits (or bus width) you will get a higher throughput than if you treat them as 32 bits. Most noticable on the RUNing, but also on the LOADing ! The problem is so much of UNIX code (at v6, v7 BSD level) is rather non portable, doing things like assuming pointers and words are the same length. Corrolary: The much neglected Z-8000 is actually a very fast machine for a number of reasons. Firstly is sees itself as a 16 bit machine with a 16 bit bus, which invokes Corrolary #1. Secondly it has all 16 of its registers as TREULY general purpose. This means that by having a library of csav/cret for the number of registers you want to save you can have oodles of register variables OR (and more importantly) tell the compiler it has all these regiters to use. This means FAST code. In practice a lot faster than the 68000 because those registers really ARE general purpose. See Brad Templeton (weatmath!bstempleton) for bencharks. The MINUS. The Z-8000 is not a contigious memory machine. This is fine for the ZEUS approach of multiple 64+64k processes, since a single MMU can have RESIDENT the mapping tables for 32 such processes ! This makes for ultra-fast context switches. Bigger address spaces need other (but also well proven) techniques. See the papers from the UNICOM just gone for details. The BIG PLUS which you guys wont see.... The Z-8000 is mainly used in military equipment. This means it is more reliable (is FORCED TO BE) than other micros. For example, wider internal paths than 68K, built with a well proven FAB technology, same as that used for the 8080 (!), just better layout to fit it all in. Come the war, Z-8000 systems will be running.... Also uses slower (i.e. cheaper) memory than 68K or 16K families for the same clock speed and "throughput". If you think the cost of the CPU is a small part of the system cost this is a GOOD THING. Lemma: The 8088, being an 8 bit 8086, grinds. Its registers are not general purpose enough and the means for addressing beyond 64K is problematic if you need to address large data structures. (e.g. big buffer caches) Corrolary: There is *supposed* to be a Z-800, which is a Z-80 plus in a Z-8000 pinout. All manner of rumours have surfaced; the nice ones say... "Z-80 with 16 bit data path, instruction queue, 16 bit ALU and internal MMU to 4Megabytes of addressing, plus multiple/divide and proper 16 bit arithmetic extending to the index registers as well." It seems to say that this is an easy road to the Z-8000; buy one and run z-80 software until it gets too slow then put in the plug compatable (??) Z-8000. Anyone with solid details please mail me and post to the net. Lemma: The National Semiconductor 16000 family starts off with something which emulates an 8080 then switches to a more powerful instruction set. Sounds like a lot of silicon real estate. I will believe it when I see it. The 16032 is here now. Some guys are announcing a board with it and 512k bytes that plugs into the IBM PC. As other articles have said, there are a number of firms that have UNIX running on it. Corrolary: See Lemma #1 above. This is another machine with 16 bit bus and 32 bit ALU. However, it beats the 68K, it has 32 bit internal data paths. Never mind though, the 32032 is on the way. Same silicon and design for the most part, so it is easy and will be here soon, but it has a 32 bit external data bus. That is what will make it a winner. The 16000 family has a lot going for it as a UNIX machine, truely general purpose registers, shareable software modules for resident or 'load on demand' library functions, a MMU that has been 'done properly', a VERY good instruction set IEEE floating point in hardware and more. Lemma: Some of you are probably using an 8 bit micro that has a 4 bit alu. Corrolary: These 16 bit things that emulate 8080s and Z-80 will have a lot of established software to work with. It is unfortunate that some of it is quite grungy. "FORTAN we will always have with us..." And COBOL and ..... =========================================================================== Perhaps we ought to look to set up a net.micro.unix or a net.unix.micro. There are getting to be so many UN*X in a box on a micro now that it warrants a seperate group. I would also like to see discussion of how micros can best "do" UN*X like things effectively (e.g. MARC fron Vector). /anton aylward HCRC