pointers to freshly minted functions.

[Andrew Stewart]

In article <2277 at phri.UUCP> roy at phri.UUCP (Roy Smith) writes:
>In article <204 at dg_rtp.UUCP> throopw at dg_rtp.UUCP writes:
>[In an ongoing discussion about self-modifying code]
>
>	The Buroughs B5700 had (in addition to the strangest subroutine
>linkage I've ever seen) a tagged architecture.  Each memory word had a
>(3-bit?) tag which defined the value stored there as integer, real,
>pointer, instruction, etc.  This tag was not directly accessible by a
>programmer which made it kind of hard to implement a compiler.  Presumably
>(I never actually used a B5700) there was some magic way the OS used to
>convert data into code, but I never ran accross any reference to it.

There was a simple trick - the tag bits were not held on disk, only
in memory. (I'm not sure if they even existed when a segment was paged
out); the compiler generated a file whose format was defined and
understood by the loading procedures.
When a program was run, the MCP (Burrough's name for the OS) created a new
stack segment for the run-time info which was linked back to the system
stack; it then  built the segment dictionary for the code segments and the data
segments, loaded the segments and lit the blue touch paper.
Only the system could change tag bits, and not even the system could change
certain tag bits once they were created. You had to destroy the segment and
reallocate it.
It also did memory management ('buddy' method, I think) in microcode.
Nice machine. Bit sluggish in a hundreds-of-little-jobs environment, though.
Have a look at Elliot Organick's book on the B6700 - it's quite a machine.
-- 
-------------------------------------------
Andrew Stewart		 USENET:   ...!mcvax!ukc!aimmi!andrew

"My axioms just fell into a Klein bottle"