🚀 go-pugleaf

hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

>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.

[...]

>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, please.  Audit some undergrad courses in computer architecture & compilers.
Then you can come back and resume your endless spiel, but at least you'll
have some idea what you're talking about.

Geesh.  Most of us don't spend time and bandwith flaming on sci.math.stat
about Gaussian normal distributions...

Dan Breslau
dan@codex.com
Speaking for myself, at most...