🚀 go-pugleaf

In article <id.HJ1V.BTG@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <BxtA6v.CE8@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>> But it is.  The operations often use register arguments and the results
>> are wanted in registers.

>What's a register? Most modern compilers ignore "register", or use it as a
>hint "this is a frequently used value".

Maybe that is one reason for such poor object code.  Most modern architectures
REQUIRE that arguments are in registers.  This should be well known; no matter
how well loads or stores can be integrated into the code, they certainly add
an instruction issue.

So, assuming that addition takes one cycle, a = b + c takes one cycle if
only registers are used, but four cycles otherwise.

Take one of the examples, unpack.  Since the registers typically do not 
behave in enough respects like memory, it is certainly difficult to put
a struct in the register file.  And even if it is, they might be in the
wrong registers.  So that unpack, as a macro, can often be done in 3 steps,
while any use of a struct for the result is likely to add at least 2 more,
and if memory is invoked, 4 more.

>And how is an inline library part of the language more than a subroutine
>or an include file?

An include file should be considered as part of the program.  The programmer
decides explicitly which ones to include.  By a subroutine, I normally mean
one compiled separately, and with object code linked at run time, or when
an object file is being produced, by the loader.  Inlining requires that
the compiler introduce instructions directly into the compilation as it
does when it is handling the user's code.  The current inlining is a special
case of what I would like to accomplish with the macro processor I have
called for; I would allow macros applied to macros, etc.  Inlining corresponds
to a subset of what a more powerful #define would handle.  But since it is not
under the control of the programmer, it becomes part of the language.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)