roy@phri.UUCP (Roy Smith) (03/08/86)
In article <204@dg_rtp.UUCP> throopw@dg_rtp.UUCP writes: [In an ongoing discussion about self-modifying code] > [on certain machines, like a pdp-11 with I&D spaces] code is code and > data is data and never the twain shall meet. [...] Consider a C > function which creates an instruction stream, and returns a pointer to a > function which when invoked will execute this instruction stream. [...] > It must *always* be possible to implement this function, otherwise > compilers would not be possible, since compilers are simply programs that > treat code as data (though sometimes an implementation of the above > function will have to start one or more new processes...) 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. One of the other oddities about the 5700 was a lack of conventional assembler -- you did systems programming in an Algol derivitive. -- Roy Smith, {allegra,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
andrew@aimmi.UUCP (Andrew Stewart) (03/15/86)
In article <2277@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In article <204@dg_rtp.UUCP> throopw@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"
dave@inset.UUCP (Dave Lukes) (03/18/86)
In article <2277@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In article <204@dg_rtp.UUCP> throopw@dg_rtp.UUCP writes: >[In an ongoing discussion about self-modifying code] >> Consider a C >> function which creates an instruction stream, and returns a pointer to a >> function which when invoked will execute this instruction stream. [...] >> It must *always* be possible to implement this function, otherwise >> compilers would not be possible, since compilers are simply programs that >> treat code as data ... WHAAAATTT??? Uh-uh: you mean LOAD-AND-GO compilers aren't possible: most compilers generate a file of code which is read into the I space by the OS. ^^^^ > 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 ^^^^^^^^^^ Wrong: there is/was (at least on the B6700) a ``set tag'' instruction (I don't rememeber what it was called) which overwrote the tags in the operand. Anyways: there are plenty other reasons why implementing a compiler on those beasts is strange: the major one being the total lack of protection. >(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. Again (see above), the code was generated in a file usually, then run by the OS. > One of the other oddities about the 5700 was a lack of conventional >assembler -- you did systems programming in an Algol derivitive. Sure, it was an Algol derivative (ESPOL: Executive Systems PrOgraming Language it was called), but totally machine oriented. BTW: tou HAD to program in a high level language: assembler was forbidden due to the lack of protection (which was all provided by the compilers ...) >-- >Roy Smith, {allegra,philabs}!phri!roy >System Administrator, Public Health Research Institute >455 First Avenue, New York, NY 10016 P.S. BTW: Burroughs called their OS MCP (Master Contol Program) long before Disney did TRON. Does anyone know if Burroughs sued? -- Dave Lukes. (...!inset!dave) All opinions, philosophies, dogmas and idiosyncrasies expressed in this article INCLUDING THIS DISCLAIMER, are solely those of the author.