lindsay@k.gp.cs.cmu.edu (Donald Lindsay) (07/20/88)
The idea of storing a return address into the front word of a subroutine was widespread. It would be nice to think that this rank stupidity died out long ago, but in fact the HP 2100 series worked that way. (I believe it went off the market in the 1980's.) Issues like ROM and reentrance weren't the only headaches. How to write a compiler? I have in my possesion the assembler source for an HP2100 Algol 60 compiler. Now, that's some real macho hacking. Especially with no subtract instruction, and about 2 registers .. -- Don lindsay@k.gp.cs.cmu.edu CMU Computer Science "Imitation is not the sincerest form of flattery. Payments are." - a British artist who died penniless before copyright law.
dre%ember@Sun.COM (David Emberson) (07/21/88)
> > The idea of storing a return address into the front word of a subroutine > was widespread. It would be nice to think that this rank stupidity died out > long ago, but in fact the HP 2100 series worked that way. (I believe it > went off the market in the 1980's.) > Stupidity?!?? They didn't have stacks in those days. It probably seemed like a pretty cute idea at the time. I had the pleasure of spending many, many hours hacking on one of these machines during my undergrad days. At the Digital Systems Lab at MIT a group led by grad student extraordinaire Brad Hampson and fellow hacker Don Slutz wrote a Multics clone in HP2100 assembler called DSL/TSS. It had dynamic linking, a Runoff-type text formatting capability, and networking to a bunch of microcomputers--mostly 8080s. The only thing we did not have was any languages--just assembler. As a consequence the system ran like a bat out of hell, and we never really noticed the fact that we only had 32K of memory. This was around 1975-76. Now for my absolutely true story: In order to receive my bachelor's degree, I was assigned the job of completing Dave Presotto's bachelor's thesis. (I can say this now because Dave is currently wildly successful at Bell Labs.) The mission: to build a micro out of the new 6800 processor from Motorola and create software development tools for the 6800 which would run under DSL/TSS. I wrote tens of thousands of lines of HP2100 assember, including a cross assembler for the 6800. But the thesis deadline was approaching. In one all-nighter, I typed into the DecWriter II some 1500 lines of assembler which constituted the expression evaluator for the cross assembler. I assembled it and ran my test. The entire expression evaluator worked perfectly on the very first attempt, except that it bombed out when attempting to return to the calling routine. It turned out that I had JMP'ed to the evaluator instead of JSR'ing. Since the JMP did not deposit the return address in the entry point, the JMP indirect through the entry point (which is how you do a return on a 2100) got a return address of zero. Ah, for the good old days of ASR 33s and punched tape. Sigh... Someone once told me that the 2100 architecture was the result of someone's masters thesis at Stanford. I have no idea who. Dave Emberson (dre@sun.com)
jms@antares.UUCP (joe smith) (07/21/88)
The PDP-10 still uses JSR to write the return address at the front of the routine, but only when absolutely necessary. Normal calls us the recursive/reentrant mechanism of pushing the return PC on the stack, but the debugger (DDT) can't do that. Since programs can use anywhere from 0 to 16 different stack pointers, there is no such thing as "the" stack. The usual use for JSR is to save all accumulators in memory before setting up a private stack for processing the breakpoint. This even works in exec mode on an SMP (symmetric multi processor) system as long as each CPU maps the same virtual address of the return PC word to different physical addresses. The main point I'm trying to make is that the PDP-10 gives us the option of storing the return PC in memory, in an accumulator, or on the stack, allowing the programmer to choose whichever option is best suited to the task at hand. Having a small impure section of the program is reasonable under certain circumstances. -- +-----------------------------------------------------------------------------+ | TYMNET: JMS@F29 UUCP: {ames|pyramid}oliveb!tymix!antares!jms | | INTERNET: JMS%F29.Tymnet@Office-1.ARPA PHONE: Joe Smith @ (408)922-6220 | +-----------------------------------------------------------------------------+
cik@l.cc.purdue.edu (Herman Rubin) (07/21/88)
Occasionally I have needed to trace a program for debugging purposes. I do not mean the trace facilities usually included with HLLs; I mean that exactly what happens on any given hardware instruction is printed out. (Beware; know exactly what you are doing and how much output you will get, as thousands of pages can result.) The only way to do this is to copy each instruction, possibly modified to handle certain types of address modification and jump instructions, to some place in memory and then execute it and print out what happens. This should be done very carefully; in most cases there are much cheaper ways to achieve the same results. I have located errors in programs which would have been difficult to find otherwise. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
henry@utzoo.uucp (Henry Spencer) (07/22/88)
In article <2317@pt.cs.cmu.edu> lindsay@k.gp.cs.cmu.edu (Donald Lindsay) writes: >The idea of storing a return address into the front word of a subroutine >was widespread. It would be nice to think that this rank stupidity died out >long ago, but in fact the HP 2100 series worked that way. (I believe it >went off the market in the 1980's.) I wouldn't be surprised if DEC is still making PDP-8s, which did things that way. -- Anyone who buys Wisconsin cheese is| Henry Spencer at U of Toronto Zoology a traitor to mankind. --Pournelle |uunet!mnetor!utzoo! henry @zoo.toronto.edu
EGNILGES@pucc.Princeton.EDU (Ed Nilges) (07/24/88)
In article <60742@sun.uucp>, dre%ember@Sun.COM (David Emberson) writes: >...Now for my absolutely true story: > >In order to receive my bachelor's degree, I was assigned the job of completing >Dave Presotto's bachelor's thesis. (I can say this now because Dave is >currently wildly successful at Bell Labs.) ...so much for ethics...
dre%ember@Sun.COM (David Emberson) (07/25/88)
In article <5718@pucc.Princeton.EDU>, EGNILGES@pucc.Princeton.EDU (Ed Nilges) writes: > > ...so much for ethics... What the hell do you mean by that? 1) There was quite a bit of original work done by both of us, and 2) the requirements for a bachelor's thesis are quite a bit different from a doctoral dissertation--it's more like a project of sorts If you want to question my ethics, may we meet outside! Dave
rrh@june.cs.washington.edu (Robert R. Henry) (06/15/89)
I am interested in readers' experiences with self-modifying code. Specifically, I'm interested in knowing of 'standard' programming tricks that have been used in conjunction with self modifying code, and in what kinds of programs and on what kinds of architectures self modifying or self generating code has proven to be useful. I'm interested in any of these three kinds of self-modifications, although for the moment I'm focusing on fine-grain modifications: *fine-grain shape-preserving self modifications (such as changing an instruction every time through a loop) *medium/coarse-grain shape-preserving self modifications (similar to relinking code prior to executing it) *shape-altering modifications via on-the-fly code generation (this is used in some bit-blit kernels, and in some interpreters for lisp and smalltalk) Please don't flame me about system's level issues. I'm perfectly aware that self-modifying code is not reentrant; is not sharable; it can't reside in a ROM; it must be paged; it leads to serious cache coherency problems; it isn't easy to understand; it is architecture and perhaps implementation dependent. Please send mail directly to me, and I'll (eventually) post a summary. Thanks, Robert R. Henry Computer Science Department University of Washington