Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!seismo!harpo!floyd!clyde!ihnp4!inuxc!pur-ee!uiucdcs!uiuccsb!grunwald From: grunwald@uiuccsb.UUCP Newsgroups: net.flame Subject: Re: Godless 68000 instruction set - (nf) Message-ID: <4300@uiucdcs.UUCP> Date: Fri, 2-Dec-83 22:34:40 EST Article-I.D.: uiucdcs.4300 Posted: Fri Dec 2 22:34:40 1983 Date-Received: Sun, 4-Dec-83 06:34:15 EST Lines: 30 #R:hp-dcde:32700001:uiuccsb:7600059:000:1379 uiuccsb!grunwald Dec 2 13:53:00 1983 God, I've been waiting for this. Let us consider consistency. We have heard all of the techno-pundents rave about parsiminous and orthogonal architecture. We've heard them laud the principle of not putting weird side effects into instructions. But did the 68000 designers listen? Nope. Lets us look at the auto increment/decrement modes. Using any other address register than a7, an instruction of the form "movb ,a5@-" will push a byte. Use the a7 register, and all of a sudden it pushes a word. Jez. Understandable, but still, a pain. Also, let us look at interrupts. In a generalised "I got an interrupt and now I need to schedule a process to field that interrupt" intgerrupt management routine, one needs to be able to tell what interrupt interrupted you. On the 68000 (but not the 68010, admittedly), this is impossible to do without wasting a ton of space. (i.e. having each interrupt vector go to a different routine which loads a number saying "I am interrupt #N" and then jumping to the generalised interrupt process scheduler routine). Having not had the opportunity to read through the NS16000 manuals, I can only hope that they too did not market such a feculent design. The 68000 is nice, but I would hardly call it a good chip for high level languages. Dirk " Now them's good flamin' " Grunwald University of Illinois ihnp4 ! uiucdcs ! grunwald