old microcode listings
|
Prev: Software vs Hardware
Next: Searching for the PDP-3
From: ChrisQuayle on 9 Jan 2007 11:58 kenney(a)cix.compulink.co.uk wrote: > In article > <Pine.LNX.4.61.0701080542300.30635(a)ask.diku.dk>, > firefly(a)diku.dk ( Lund) wrote: > > >>Sure, something rudimentary like that, fine, yes, >>that's useful. > > > The Z80 had a NMI and three modes of interrupts with Mode > 2 and Mode 1 being vectored. If multiple interrupts were > possible at the same time they had to have priority > settled by external hardware. > > Ken Young Didn't the z80 also have fully vectored interrupts for zilog peripheral devices, implemented as a vector register in the peripheral controller chip itself ?... Chris
From: "Peter "Firefly" Lund" on 9 Jan 2007 12:26 On Tue, 9 Jan 2007, ChrisQuayle wrote: > Erik Trulsson wrote: > >> If the system wants to actually *handle* the exception properly then it >> will >> need to know the format of the stack frame in order to find out things >> like >> *which* instruction caused the exception, or which memory access caused a >> page >> fault. >> > > ...and if Apple had designed a machine using 68060, no doubt the install > program would have probed for cpu type and loaded the appropriate modules, or > patched the os on the fly. To criticise an architectural change because some > third party add-on company found it difficult to integrate their product is > hardly relevant. It's precisely the sort of problem one would expect to have > to solve if you build such products. I think you misunderstood us. I am saying that /Motorola/ made 68K versions that were incompatible with each other. This gave problems /both/ for Apple /and/ for others. That the third-party product needed to work around those problems had nothing to do with Apple taking short cuts. Apple also needed to work around the incompatibilities and it took them longer to do so (because it was somewhat difficult) than the third-parties. Even Apple had the problem that older system software didn't work well with newer CPUs. The responsibility for this lies almost entirely with Motorola. The third-party in question was Radius (there were probably also others), which consisted of some of the most knowledgeable people about the Macintosh that existed on the planet at that time. One of them was Burrell Smith, who designed the electronics for the first Macs. >> The problem was that the stack frame format *changed*. That meant that >> you had to get an updated (or at least patched) OS in order to run on >> the new CPUs. This was not just a problem for the Mac, but for all other >> systems that used th 68k series as well. > > Well, nothing stays the same if we are to have progress and it's true of many > architectures. Peter's incremental approach in action :-)... Wrong. Completely wrong. One of the blunders from Motorola was that they didn't have a flag in the CPU for ignoring the top 8 virtual address bits in the 68020+. Others were changing exception stack frame layouts between the versions -- they were identified by a four-bit code but what does that help if a newer CPU uses a new format? And it is still very bad form to expect exception handlers to inspect the stack to find out what the stack is. They also removed some of the instructions in the later versions (and I am not talking about the coldfire/dragonball embedded versions). And changed the allowed alignments for some of them. -Peter
From: Terje Mathisen on 9 Jan 2007 13:02 Peter "Firefly" Lund wrote: > On Tue, 9 Jan 2007, Terje Mathisen wrote: > >> Using POP from the stack to initialize the star field crashes if there >> happens be a timer (or other hw) interrupt while the stack pointer has >> wrapped around into the PSP+code. > > I didn't like that one, either :( > >> I.e. the original 24-byte was elegant, while the 20-byte version was >> ugly, > > But an interesting kind of ugly, wouldn't you say? Sure, I'll give you that one. > > I still like the IN AL, 60h .. DAS .. JC/JNC idea. It doesn't work with > all keypresses but Esc is one of the keys it does work with. The smallest code doesn't check the keyboard at all, so that's a less important optimization IMHO. Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: ChrisQuayle on 9 Jan 2007 16:57 Peter "Firefly" Lund wrote: > > I am saying that /Motorola/ made 68K versions that were incompatible > with each other. This gave problems /both/ for Apple /and/ for others. > > Apple also needed to work around the incompatibilities and it took them > longer to do so (because it was somewhat difficult) than the third-parties. > > Even Apple had the problem that older system software didn't work well > with newer CPUs. That's Apple's problem - they should write system software that works. Be honest, the older macs never were about robust, pro engineering design - overpriced, crashing, underperforming marketing exercise systems targeted at media arts wheenies and those who didn't like computers. Too much art and not enough engineering, perhaps. A complete contrast to the Apple II, which was an honest, unpretentious machine and very good for its time. > One of the blunders from Motorola was that they didn't have a flag in > the CPU for ignoring the top 8 virtual address bits in the 68020+. > > Others were changing exception stack frame layouts between the versions > -- they were identified by a four-bit code but what does that help if a > newer CPU uses a new format? And it is still very bad form to expect > exception handlers to inspect the stack to find out what the stack is. > Well, systems programming is about getting down into the internals, so you should expect to have to do stuff like that from time to time. Just part of the rich tapestry of design life. > They also removed some of the instructions in the later versions (and I > am not talking about the coldfire/dragonball embedded versions). And > changed the allowed alignments for some of them. I remain unconvinced on this point, so let's leave it at that and agree to differ ?. The general debate is fun, however :-)... Chris
From: "Peter "Firefly" Lund" on 9 Jan 2007 17:19
On Tue, 9 Jan 2007, ChrisQuayle wrote: > That's Apple's problem - they should write system software that works. Be > honest, the older macs never were about robust, pro engineering design - Yes, they were :) > overpriced, crashing, underperforming marketing exercise systems targeted at But they were also overpriced -- and crashing, mostly due to the unfortunate choice of running in supervisor mode by default and due to the fact that the system calls didn't validate their parameters. > media arts wheenies and those who didn't like computers. Too much art and not > enough engineering, perhaps. A complete contrast to the Apple II, which was > an honest, unpretentious machine and very good for its time. The first Mac and the Apple II were much alike in their creative hardware design. Both are wonders of component optimization. >> They also removed some of the instructions in the later versions (and I >> am not talking about the coldfire/dragonball embedded versions). And >> changed the allowed alignments for some of them. > > I remain unconvinced on this point, so let's leave it at that and agree to > differ ?. What are you unconvinced about? That they really changed exception stack frame formats? Several times? That some of the instructions got stricter alignment requirements imposed on them later in the 68K series? That they removed some of the (user-level) instructions? > The general debate is fun, however :-)... Yeah :) -Peter |