The display, in this context, and I hope I use and explain the term correctly, is one of two common ways to handle the context in nested procedures, where the inner procedure would access the variables from the enclosing one, but from the right activation record on the stack (think recursive cases!). You could follow the chain of invocations whenever an outer variable is accessed or you can maintain a global so-called display of outermost activation records for each nesting level. The latter has a bit of overhead on each procedure entry/exit, but makes the actual variable accesses quite fast. Not fully sure it pays off, though, because in the end you probably never go beyond a single level of nesting.
I've got a vague recollection that typical display implementations were problematic since they had a fixed number of elements... but everything I've ever worked on directly had sufficient index registers to use chained stackframes. I've also got an extremely vague recollection of a top-end mainframe which used a display for internal addressing and had a /very/ large "display" mounted in the middle of the computer room to show people it was busy... I don't know whether there was any direct connection, or if that was just a CPU usage scoreboard.
In any event, as CPUs got faster than memory anything that demanded extra cycles on function entry/exit was frowned upon: you only have to look at the way that Intel introduced pusha/popa in the '186 but that they were mostly ignored since even low-end compilers gained the ability to decide which registers needed to be saved and restored at about the same time.
I agree that Chris Fenton's system is a bit of a brute. I'm intermittently using a V20 as a target system to decode the output from a logic analyser, and considering the state of FPGAs etc. today it would be comparatively easy to replace that with something that implemented both x86 and Z80 opcodes (as distinct from the 8080 opcodes that the V20 is limited to).
MarkMLl
Recent
