old microcode listings
|
Prev: Software vs Hardware
Next: Searching for the PDP-3
From: ChrisQuayle on 7 Jan 2007 16:22 ChrisQuayle wrote: > Peter "Firefly" Lund wrote: > > I think we must be at cross purposes here. On exception, at least the > stack pointer ^^^^^^^^^^^^^ Sorry, brain fade. Should be program counter... Chris
From: "Peter "Firefly" Lund" on 7 Jan 2007 23:51 On Sun, 7 Jan 2007, ChrisQuayle wrote: >> It certainly does. It means you have to upgrade your operating system or >> install a funny "extension" to do the job instead of the operating system >> if you want to use the newer CPU. > > I think we must be at cross purposes here. On exception, at least the stack > pointer and current cpu status must be pushed onto the stack and these values > are popped in reverse order on exit from the handler. Note that this is all > done transparently from the software point of view, as it's a hardware > function. The order in which this is done is important to the degree that the > program counter gets pushed first and popped last, but neither the > application nor the os exception handler need to know anything about it. So > why should 'extensions' be needed, or am I missing something ?. What if the system software needs to examine the exception stack frame and it is different from what is expected? This is not hypothetical. It was one of the reasons why it was difficult to put a 68060 in a Mac. The relevant exception handling and occasional faking of an old-style exception stack frame + forwarding to the os handler was taken care of by some system software that came with the (third-party) CPU board. In this case, this kind of software was called an "extension". >> I don't think having many prioritized interrupt levels really matters all >> that much. Vectors probably do but not priorities. > > Well, in real time systems at least, interrupts from devices like scheduling > clocks need to have priority over more mundane tasks like serial comms. One can get surprisingly far by just being able to block interrupts individually. After taking an interrupt, one blocks that particular kind of interrupt and sets a flag. The priority handling can be handled in software, including starvation prevention, reshuffling of priorities, and permanent disabling of naughty interrupt sources. > Therefore, you prioritise interrupts to guarantee service for critical > devices, irrespective of what other device is currently interrupting the What is critical enough to need that on a non-embedded machine? > original pc used a prioritised interrupt structure, tagging on the 8259 > device, which can't have been low cost at the time. Even older cpu's like the But look at how screwed up the priorities were (or at any rate, got, by the time of the AT when the second interrupt controller was introduced). You could rotate the priorities (and even run the interrupt controller in a mode where it automatically rotated them) but that was all. If you really needed real-time -- and had more than one interesting interrupt source -- you something like what I sketched above and handled the prioritization in software. > original 6502 had an implied priority structure: reset, highest, non maskable > interrupt, then irq at the lowest priority... Sure, something rudimentary like that, fine, yes, that's useful. -Peter
From: "Peter "Firefly" Lund" on 7 Jan 2007 23:54 On Sun, 7 Jan 2007, ChrisQuayle wrote: > If you do a bit more digging, you'l find that the original research that led > to the 68k was started in 1975, so it's very much in the same time frame... That, I know. As far as I know, the project was late, used many transistors, were not compatible with anything, and was expensive in the beginning. The 8086/8088 got there first, was smaller, was compatible, and was cheaper ;) Also, it seems to have been a backup project in case anything happened to the 432, the flagship clean-sheet design. -Peter
From: "Peter "Firefly" Lund" on 8 Jan 2007 00:14 On Sun, 7 Jan 2007, ChrisQuayle wrote: > would miss pre and post dec/inc operators, as they can save a lot of > instructions whan accessing arrays, depending on how you have structured the > code. These days, instructions are free but loads and stores are not ;) > As an example, see if you can work out what's happening here and why: > > tst (pc)+ > 10$ sec > rts pc its an epilogue that returns to the address on the top of the stack with these flags: N = 0 Z = 0 V = 0 C = 0 "tst (pc)+" ; after loading the instruction, pc points to the word after tst, namely the "sec" instruction. The operand that gets loaded is 000261 octal/00B1 hex. The tst instruction subtracts 0 from the operand value in order to compare it to zero and sets the flags accordingly. V and C always get set to 0 by that instruction, Z gets set to 0 because 000261 is not equal to 0 and N gets set to 0 because 000261 is not less than 0. As part of the loading of the operand, pc gets incremented. tst loads a word (whereas tstb would load a byte) but that is not important in the case where pc is used; pc is always incremented/decremented by two when used in an addressing mode, no matter the operand size. I think "10$" is a temporary label of sorts -- I know very little about the PDP-11 assembler(s?). The sec instruction will be skipped because it was used as an operand. "rts pc" will do what a normal return does in architectures that always save return addresses on the stack. PDP-11 wasn't one of those, but using "pc" as the register holding the return address simulates it. This instruction doesn't change the flags. My guess is that sometimes the epilogue would be entered at the label "10$", in which case it will return with C = 1 (and the other flags untouched by this code). -Peter
From: "Peter "Firefly" Lund" on 8 Jan 2007 00:23
On Sun, 7 Jan 2007, ChrisQuayle wrote: > This is typical of the idiom and saves memory. By the time you have a couple > of hundred modules, the overall saving is quite significant. > > Now of course, all is surfaces, and uSoft Studio rulz ok :-)... Try this: ftp://ftp.scene.org/pub/mirrors/hornet/code/effects/stars/mwstar.zip -Peter |