Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site l5.uucp Path: utzoo!linus!decvax!decwrl!Glacier!well!l5!gnu From: gnu@l5.uucp (John Gilmore) Newsgroups: net.micro.68k,net.micro.16k Subject: Bus Error Effluvia Message-ID: <44@l5.uucp> Date: Sun, 1-Sep-85 02:48:12 EDT Article-I.D.: l5.44 Posted: Sun Sep 1 02:48:12 1985 Date-Received: Mon, 2-Sep-85 09:04:32 EDT References: <2422@sun.uucp> <5883@utzoo.UUCP> <5890@utzoo.UUCP>, <124@desint.UUCP> <5913@utzoo.UUCP> Organization: Ell-Five [Consultants], San Francisco Lines: 59 Xref: linus net.micro.68k:1030 net.micro.16k:348 Personally, :-) I think Henry was just using my vacation from the net to see if he could slip a few 68000 flames past me. No way, Jose! On dumping microstate during a page fault: My first reaction was the same as Henry's -- it's not as clean as the old IBM 360 I grew up on, so it must be bad. Further discussions with various chip and architecture designers led me to realize that a BIG problem with making fast processors is stopping them dead once you realize you need to stop. Motorola was going for speed as usual, so they opted to run normal instructions quickly and page faults slowly. I've heard that the National 16032 designers had to go to a lot of trouble both in instruction set design and in implementation, to make sure that they could always back out an instruction if it faulted. IBM, Amdahl, etc. have always had to dedicate a lot of (otherwise useless) hardware to stopping all the other instructions, or backing them out if already completed, when you get e.g. integer overflow. The 68010 and 68020 microcode can concentrate on do as much work as possible and very seldom have to worry about whether things would be straight if a page fault occurred at that microstep. For example, in the IBM 370 the block move instruction had to use four general registers for the two addresses and two counts (well... this was IBM, remember) because if it took an interrupt or page fault, it didn't want to restart from the beginning. National did similarly. In the 68020 the CALLM instruction can copy a large block of arguments from one stack to another; it doesn't need that kind of kludge because it can afford to keep some internal state around. Though I think CALLM is a botch for other reasons. Somebody mentioned that they feel creepy about the idea of the system going on and executing more instructions after a bus error. It's not really that bad. If the fault happens on a data access, it stops dead and handles it. If it happens on an instruction prefetch, then it remembers that it got a fault, but goes on until it tries to execute that instruction. If you branch first, no fault. This fixes a bug wherein the 68000 would fault if your return-from-subroutine was the last thing in a page and the next page was not executable. In older micros "bus error" conjures up images of dead hardware and bits of wire shorting the pins and such. In a 680xx system, bus error is just another way to end a bus cycle; it happens all the time. It doesn't mean the hardware or software is broken, so there's no reason for the CPU to stop at that instant to deal with it. The next cycle will probably work OK even if this one got a bus error. Tom Gunter (project mgr. or similar for 68000 family) remarked several years ago that the reason the 68000 didn't do page faults is because he decided it was too hard for the first release. Remember, the VERY first 68000 design had 16-bit data regs and 24-bit address regs. He needed to get the product out against Intel's "ship it first, then design it" schedules, and he realized it needed to be a 32-bit design and they had a lot of work to do, so he compromised on page faults. I think his judgement was pretty good -- if they'd shipped that first design, it wouldn't be compatible with the 32-bit version now; if they'd delayed another 6 months to introduction, they'd have lost the whole show to Intel. (Another rumor says IBM chose the 8088 for the PC because Motorola couldn't ship 250Kchips that year -- but Intel could. Wonder if the PC-2 will use 68020 since the 386 is not real yet...)