From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 16 Feb 2008 23:32:30 +0000 To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Non-stack-based calling conventions From: "Eris Discordia" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Message-ID: User-Agent: Opera Mail/9.23 (Win32) MIME-Version: 1.0 References: <11c3f7123799c7bb2fb4637fc62a10f8@coraid.com> In-Reply-To: <11c3f7123799c7bb2fb4637fc62a10f8@coraid.com> Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 576a0152-ead3-11e9-9d60-3106f5b1d025 On Fri, 15 Feb 2008 23:39:40 -0000, Pietro Gagliardi wrote: > - DOS interrupt function calls use the registers, not the stack. > - SPARC and MIPS registers are provided to pass parameters. > > On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote: > >>> >>> The calling conventions I have seen are the ccall, stdcall (Windows' >>> slightly modified version of the ccall), and pascal. All of them push >>> parameters on the stack. >> >> Take a look at the R-call and S-call conventions used on the IBM System >> 360 architecture. These machines didn't even have a stack. >> >> --lyndon > Good pieces of info. By the way, MS-DOS software interrupts were interrupts after all, i. e. different from procedure calls. Using the stack there would create re-entry problems (?) and a serious performance bottleneck (heh, MS-DOS to performance is Pumpkins to what?). On Sat, 16 Feb 2008 00:23:22 -0000, Brantley Coile wrote: > Early Control Data machines, like many machines > of the era, used the return address to fine the parameters. > This meant that you put he parameters in the instruction > stream right after the call to the subroutine. > > Here's the calling convention for your entertainment. > > 1) The calling program would put the parameters into memory > locations just past the call to the subroutine. > 2) Do a return-jump to the subroutine. This puts the return > address in the first word of the subroutine and > begins to execute the second word. > 3) Parameters are accessed by using and incrementing the > return address. > 4) With the return address now safely stored in the first > word of the subroutine, we can now return to the > calling routine just by doing a indirect jump thru > the first word of the routine. > All this might not make sense to you so here is some code. In fact, your explanation made much more sense than the code. To me, of course. The question of why would anyone devise such a weird scheme of calling procedures remains. > All the memory you would need was known as compile time. At the cost of transforming relocation into black magic. Were there binaries on that platform? Did those binaries need relocation? With code and data intermingled, there must have also been serious problems with minimizing binary sizes. All the "empty" words at the beginning of each subroutine had to be written to permanent storage, I guess. The x86 stack consumes zero space on permanent storage. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/