🚀 go-pugleaf

>In article <13660@mcdphx.phx.mcd.mot.com> fnf@riscokid.UUCP (Fred Fish) writes:
>In article <6620@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
>>(As an aside: most 68000 compilers I've used in the past have returned
>> pointers in A0 and ints in D0. Seems like an obvious move. I guess Manx
>> and Lattice had other priorities.)
>
>It does seem obvious, but most of the compilers I've worked with that
>did so ended up being modified to copy the value from A0 to D0 just before
>returning, so that buggy programs (such as the one that started this
>thread) would continue to run without change.
>
>-Fred

    This type of 'buggy' program is such an obscure bug that I fault the
    compilers for trying to do the A0/D0 business without adding
    appropriate cautions. For example, simply renaming any defined function
    that returns a pointer to something like  p_<function_name> instead of
    _<function_name> would catch all such bugs at link time.  Any compiler
    that returns pointers in A0 and NOT in D0 and does NOT do such renaming
    (or some other method to detect the problem) is screwed up.

    When I implement structural returns in my DICE compiler I will use the
    'pass pointer to return storage and have callee dump structure through
    that pointer instead of the static storage return' method.  To catch
    such prototype errors all routines that return structures will be
    silently renamed by the compiler, so any improperly prototyped call
    will generate a link error.  I intend to do the same for prototyped
    functions that cause the size of arguments to be different from
    non-prototyped functions... again to catch any screwups on the
    programmer's part that would otherwise be difficult to debug.

    I like the idea of returning pointers in A0 instead of D0 and would
    use the same renaming convention to support it.

    By the way, malloc() is prototyped in <stdlib.h> as per ANSI standard
    in the Lattice, Manx, and DICE compilers.

						    -Matt

--


    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
    891 Regal Rd.	    uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708
    USA