Path: utzoo!news-server.csri.toronto.edu!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.arch
Subject: Re: Unusual instructions and constructions
Message-ID: <5236:Mar1121:25:0091@kramden.acf.nyu.edu>
Date: 11 Mar 91 21:25:00 GMT
References: <7499@mentor.cc.purdue.edu> <4748@eastapps.East.Sun.COM> <7571@mentor.cc.purdue.edu>
Organization: IR
Lines: 18

In article <7571@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> The other is that struct is too clumsy, as there is no automatic reason
> (although in some cases hardware may do it for simplicity) to assign adjacent
> locations for the results.  Despite some formal similarities, a list is not a
> struct.

Data point: Q has both ``struct'' and ``bstruct''. The former makes no
guarantees about memory arrangement; the latter makes similar guarantees
to ANSI C's struct. As the language's sole user for now, I can assure
you that it's normal practice to have a function return a struct, and to
write (q,r) = div(a,b). (Yes, you can make a struct of lvalues.)

In the C code output by q2c, the place to store a struct returned from
a function is currently passed as an initial argument, in this case
pointers to q and r. Somewhere in my optimization list is having a
function use registers for this when possible.

---Dan