Xref: utzoo comp.lang.c:11366 comp.arch:5533 Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!bu-cs!bzs From: bzs@bu-cs.BU.EDU (Barry Shein) Newsgroups: comp.lang.c,comp.arch Subject: Re: Programmed code generation (was: Self-modifying code) Message-ID: <23944@bu-cs.BU.EDU> Date: 16 Jul 88 19:07:34 GMT References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <12381@ut-sally.UUCP> <1108@ficc.UUCP> Organization: Boston U. Comp. Sci. Lines: 42 In-reply-to: peter@ficc.UUCP's message of 15 Jul 88 20:25:20 GMT Did I miss something critical here? Most lisp systems generate and execute there own machine code. They usually do so by loading the code into the data segment but not for any particular reason other than that few OS's support the extension and modification of a text segment, and that it probably doesn't much matter other than a) not being able to mark it read-only which would usually be desireable (tho this could be done in data or text) and b) possibly taking advantage of a different paging strategy for text vs data pages, if relevant. None of that is critical tho both could be very useful. Exploiting shared library designs might make this more feasible in the future, it occurs to me that it might be possible to dynamically build a file object that the OS will consider a shared library text and then page it back into the text section. I would imagine some changes might be needed to current designs (eg. do the shareable objects and symbols have to be fully specified at initial load-time?) Speaking of lisp and self-modifying code I worked on an IBM370 lisp which accomplished trace and stepping modes (debugging) by self-modifying the top of the eval loop. Of course it didn't save much more than a test and branch, but eval loops are entered for every operator/function (eg add, subtract etc etc etc), on a 370/158 with less than a MIP and 100 logged in users one becomes a fanatic about such things, I don't know how much it helped in fact. And there was always the IBM370 MVC (move characters) instruction which only took a fixed number of chars specified at assemble time, a common sequence was (particular register numbers irrelevant): stc r1,*+5 mvc 0(r2,0),0(r3) which overwrote the second zero (,0), the length. The 370 of course provided an EX (execute) instruction which allowed indirect execution of an instruction after OR'ing in a particular register's low byte, naturally that was designed to accomplish the above (SS instructions which took a fixed length field all had the same basic format using either the byte or two nibbles as a length indicator.) Why people tended to use the store char hack above rather than EX was always a mystery to me, other than tribal practice. -Barry Shein, Boston University