Following my recent blog on Banana Registers, I've been recollecting and reflecting on designs that didn't perform their function in life in quite the way I had anticipated.
In turn, this led me to recall a story one of my design engineer friends once related to me about a goof made in the design of a mainframe computer with which he had been associated (the computer, not the goof).
In order to fully appreciate the magnitude of this design blunder, let's first remind ourselves how things used to be in the not-so-distant past. (See also my recent column, A 1960 Incarnation of Google.) If you worked for a very large company circa the 1960s and 1970s, the chances are that the company would own -- or have access to -- a humongous mainframe computer.
An example of a humongous mainframe computer.
In those days of yore, users didn't have access to their own personal computers or workstations -- instead, they worked on "dumb terminals" that were connected to the mainframe. The idea was that it was inefficient to have only a single user working on the computer, which would spend a disproportionate amount of time waiting for the user to press the next key on the keyboard. The solution was to have tens or hundreds of users time-sharing the computer's resources; that is, the computer would spend small slices of time dealing with each user in turn. To each user, it appeared as though he or she had full access to the machine.
Users working on time-sharing "dumb" terminals.
OK, now consider a program statement like "a = b + 2," where "a" and "b" are variables in some high-level programming language. If this statement were converted into machine code that was stored in the computer's memory, it would typically look something like the following (note that I'm visualizing this example in terms of a simple microprocessor with an 8-bit data bus and a 16-bit address bus, because that's just the way I think and it makes things easier to explain; things would be a bit different in the case of a mainframe computer, but the overall concept remains sound):
Typical machine-code implementation of our example program statement.
In this example, the first instruction is a LOAD, which loads the accumulator (ACC) using the "absolute" addressing mode (the absolute address of the data in memory is provided in the memory locations following the opcode). The second instruction is an ADD using the "immediate" addressing mode, which means the value to be added to the contents of the accumulator (the binary equivalent of "2" in this case) is provided in the memory location immediately following the opcode. Finally, the third instruction is a STORE, which copies the contents of the accumulator (ACC) back into memory using the absolute addressing mode (once again, the absolute address of the data in memory is provided in the memory locations following the opcode).
Max, "Look ahead means" not to the sky (Grin), I mean about future and one of the problem they may face with updation of technology. Since we have new technology, we are satisfied with that, but for next generation it may get outdated.
"To be honest I think every generation has it's own problems -- the new generation may have a lot of stuff we didn't have, but they will still face their own trials and tribulations"
Max, may be true, but when we are looking ahead, its only greenery and not sure about any hurdles for them. May be they have to face all such hurdles with the new technologies.
@Hamster, Interrupting an interrupt is something I have stayed well away from, mainly because the stack sizes I can use on Atmel AVR 8 bit is limited.
But I salute those that manage this task.
As another point have you used a 6502 softcore or any softcore on the Papilio One?
If so, I would like to bounce some ideas off you?
Bryan Pape of the Cyber Cortex seems to be incomunicado, I was going to use the Cyber Cortex board I have, to emulate the old 6520 single board computer (UK101).
I have gone for the Papilio One 500 as more info available.
I too remember looking thorugh ROM dumps to see what code preceeded a RTN opcode, to see what could be used and abused. In the PC world, the original Flight Simulator used this quite a bit of ROM code, making it very hard to run on the first clones as they did not have the IBM BIOS.
In a modern software context, re-enterant code is a stuff safe to be used even if the CPU was half way through running it. It identifies what code is safe to be be used by interrupt handlers and signal handlers.
The most obvious requirements are that that all work space is on the stack, and any if any changes are made to global memory they are atomic - so even if an interrupt occurs at just the wrong time memory in not left in an inconsistent state.
Sorry I missed your call today Max I was doing some debugging on this safety critical system where your can control some functions by sending dtmf tones and audio over the power lines ,a very good reason to break out the simulator before trying to debug it
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
