Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!limes
From: limes@sun.uucp (Greg Limes)
Newsgroups: comp.unix.wizards
Subject: Re: sun-3 dbx, arguments, hacking, help...
Message-ID: <51441@sun.uucp>
Date: 30 Apr 88 05:35:53 GMT
References: <1641@homxb.UUCP> <7765@brl-smoke.ARPA> <613@auvax.UUCP>
Reply-To: limes@sun.UUCP (Greg Limes)
Organization: Sun Microsystems, Mountain View
Lines: 46
Keywords: Kludge, Hack, Hack

In article <613@auvax.UUCP> rwa@auvax.UUCP (Ross Alexander) writes:
>Doug Gwyn mentions that nargs() was pulled out of un*x at about v6 or
>so because people decided it would be hard to port. ...
>
>On machines with flat addressing spaces (i.e., able to to do "mov
>@#codespace, r0" and get it to work right :-) the nargs() function is
>trivial assuming the compilers adopt some kind of a convention re
>linkage code.  Yes, it varies from machine to machine; but so does
>bcopy().
>
>I think the other thing that might foul things up is the idea of
>variable sized objects (is eight bytes on the stack 4 shorts, 2 ints,
>one double, or char x[ 8 ] ??).  This could be solved easily enough
>via descriptor lists ( even Algol60 had `dope vectors' ).

mmm. sometimes the idea of the number of bytes on the parameter stack
might be of use; on current sun compilers, you can look at the
instruction following the call to get this. takes a bit of work, you
have to check for both the "addql #x,sp" and "lea a6(x),sp" forms, but
not too hard. The following function returns the number of bytes passed,
or -1 if it is unable to find out ... oh, this only works on mc68020
based machines that use Sun stack conventions.

		.globl  _bargs
	_bargs:
		movl    a6@(4),a0
		movw    a0@,d0

		cmpw    #0x4FEF,d0
		bne     0f
		bfextu  a0@{#16:#16},d0
		bra     9f
	0:
		andw    #0xF1FF,d0
		cmpw    #0x504F,d0
		bne     0f
		bfextu  a0@{#4:#3},d0
		bne     9f
		movl    #8,d0
		bra     9f
	0:
		movl    #-1,d0
	9:
		rts
-- 
   Greg Limes [limes@sun.com]				frames to /dev/fb