* [TUHS] PDP-11 MARK (was: Early Unix function calls: expensive?) [not found] <mailman.7.1452015811.15972.tuhs@minnie.tuhs.org> @ 2016-01-05 20:35 ` Johnny Billquist 2016-01-05 23:04 ` Greg 'groggy' Lehey 0 siblings, 1 reply; 4+ messages in thread From: Johnny Billquist @ 2016-01-05 20:35 UTC (permalink / raw) On 2016-01-05 18:43, Ronald Natalie<ron at ronnatalie.com> wrote: > > Just never figured out how to make good use of the MARK instruction on the PDP-11. Not surprising. As others noted, few ever did. And apparently none responding actually do either. It *is* a stupid instruction in many ways. And it's not for multiple returns either. It's an odd way of handling stack cleanup without a frame pointer. It's extremely bad, since it actually requires the stack to be in instruction space. And yes, you are expected to execute on the stack. The idea is that the caller pushes arguments on the stack, but the cleanup of the stack is implicitly done in the subroutine itself, and at the same time you get an argument pointer. Example: Calling: MOV R5,-(SP) ; Save old R5 MOV <argn>,-(SP) MOV <argn-1>,-(SP) . MOV <arg1>,-(SP) MOV #MARKN,-(SP) ; Where the N in MARK N is the number of arguments you just pushed. MOV SP,R5 JSR PC,SUB . . In the subroutine you then have the arguments available relative to R5. So that arg1 is available at 2(R5) for example. SUB: . . . RTS R5 There is a lot going on at this point. The trick is to note that the code does an RTS R5 to return. If people remember what happens at that point, PC gets loaded with R5, while R5 gets loaded with the PC that we actually would like to return to (since that's what is at the top of the stack). And R5 is pointing into the stack, at the MARK instruction, so execution continues with actually performing the MARK. MARK, in turn, will case SP <- PC + 2*N, thus restoring the stack pointer to point to the place where the original R5 was stored. Next, it does a PC <- R5, so that we now have the PC point to where we actually want to return. Next it does a R5 <- (SP)+, meaning we actually restored the original R5. And so we have cleaned up the stack, preserved R5, and returned to the caller again. Also notice that the subroutine could have pushed any amount of data on the stack before the return, and I suspect the idea was that the process would not have needed to clean that up either. However, that fails, since the RTS needs the return address at the top. But you can essentially solve that by pushing -2(R5) before returning. Ugly, isn't it? :-) Johnny ^ permalink raw reply [flat|nested] 4+ messages in thread
* [TUHS] PDP-11 MARK (was: Early Unix function calls: expensive?) 2016-01-05 20:35 ` [TUHS] PDP-11 MARK (was: Early Unix function calls: expensive?) Johnny Billquist @ 2016-01-05 23:04 ` Greg 'groggy' Lehey 2016-01-05 23:20 ` [TUHS] PDP-11 MARK Johnny Billquist 0 siblings, 1 reply; 4+ messages in thread From: Greg 'groggy' Lehey @ 2016-01-05 23:04 UTC (permalink / raw) On Tuesday, 5 January 2016 at 21:35:47 +0100, Johnny Billquist wrote: > On 2016-01-05 18:43, Ronald Natalie<ron at ronnatalie.com> wrote: >> >> Just never figured out how to make good use of the MARK instruction on the PDP-11. > > Not surprising. As others noted, few ever did. And apparently none > responding actually do either. > > It *is* a stupid instruction in many ways. And it's not for multiple > returns either. > > It's an odd way of handling stack cleanup without a frame pointer. Thanks for the (omitted) explanation. At first sight, the instruction almost seems to make sense for functions with a variable number of parameters, but of course there are simpler ways to do it. I wonder if this is a case of "it sounded like a good idea at the time" (when the instruction set was being designed), and it took a while for people to realize that it wasn't of any use. I recall a similar issue with the Siemens 306, their first stack-based machine, round about 1975. They had function call and return instructions which manipulated the stack pointer, but it seemed that nobody used them: they didn't work. From memory, the call instruction incremented the stack pointer and stored PC. The return call instruction decemented the stack pointer and loaded PC--from the wrong location. I never used the 306 myself, but I often wondered if they modified one of the instructions to DTRT. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160106/691b97e6/attachment.sig> ^ permalink raw reply [flat|nested] 4+ messages in thread
* [TUHS] PDP-11 MARK 2016-01-05 23:04 ` Greg 'groggy' Lehey @ 2016-01-05 23:20 ` Johnny Billquist 2016-01-06 0:54 ` Ronald Natalie 0 siblings, 1 reply; 4+ messages in thread From: Johnny Billquist @ 2016-01-05 23:20 UTC (permalink / raw) On 2016-01-06 00:04, Greg 'groggy' Lehey wrote: > On Tuesday, 5 January 2016 at 21:35:47 +0100, Johnny Billquist wrote: >> On 2016-01-05 18:43, Ronald Natalie<ron at ronnatalie.com> wrote: >>> >>> Just never figured out how to make good use of the MARK instruction on the PDP-11. >> >> Not surprising. As others noted, few ever did. And apparently none >> responding actually do either. >> >> It *is* a stupid instruction in many ways. And it's not for multiple >> returns either. >> >> It's an odd way of handling stack cleanup without a frame pointer. > > Thanks for the (omitted) explanation. At first sight, the instruction > almost seems to make sense for functions with a variable number of > parameters, but of course there are simpler ways to do it. Definitely. Like how most compilers do - the caller cleans the stack afterwards, if we have a system where a variable number of arguments are allowed and not indicated in other ways. Not to mention explicit cleaning up of the stack in the function before the return as well. > I wonder if this is a case of "it sounded like a good idea at the > time" (when the instruction set was being designed), and it took a > while for people to realize that it wasn't of any use. Probably not. This ties in with an old (urban) myth about the PDP-11. The MARK instruction was not in the basic, original instruction set. It came about in one of the extensions that were done. And one story behind it was that it was "invented" in order to copyright, or somehow protect the instruction set for a few years more. (I think it came at the same time as SOB, and the EIS stuff, but I don't remember for sure...) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ^ permalink raw reply [flat|nested] 4+ messages in thread
* [TUHS] PDP-11 MARK 2016-01-05 23:20 ` [TUHS] PDP-11 MARK Johnny Billquist @ 2016-01-06 0:54 ` Ronald Natalie 0 siblings, 0 replies; 4+ messages in thread From: Ronald Natalie @ 2016-01-06 0:54 UTC (permalink / raw) > > The MARK instruction was not in the basic, original instruction set. It came about in one of the extensions that were done. And one story behind it was that it was "invented" in order to copyright, or somehow protect the instruction set for a few years more. > (I think it came at the same time as SOB, and the EIS stuff, but I don't remember for sure...) Maybe it was because someone named Mark at DEC was an SOB? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2284 bytes Desc: not available URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160105/d1a1c03e/attachment-0001.bin> ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-01-06 0:54 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <mailman.7.1452015811.15972.tuhs@minnie.tuhs.org> 2016-01-05 20:35 ` [TUHS] PDP-11 MARK (was: Early Unix function calls: expensive?) Johnny Billquist 2016-01-05 23:04 ` Greg 'groggy' Lehey 2016-01-05 23:20 ` [TUHS] PDP-11 MARK Johnny Billquist 2016-01-06 0:54 ` Ronald Natalie
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).