🚀 go-pugleaf

In article <Bxr9vx.KBD@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
]In article <1992Nov15.032459.3069@udel.edu> carroll@thorin.cis.udel.edu (Mark C. Carroll) writes:
]]In article <BxMCxA.3nM@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
]
]			.........................
]
]]#2: The semantic model of a language does *not* inhibit the optimizer.
]]  Read that sentence again. Read it several times, if necessary, until
]]  you get it into your head. The fact that the language is conceptually
]]  stack based does *not* mean that it has *any* stack at runtime!
]]  (For example, the code generator may write continuation passing code,
]]  which completely replaces the stack with a special form of tail-calling.)
]
]This is the case if the considerations for the optimizer were put in by
]the compiler writer.  Computers are extremely fast sub-imbeciles.  If we
]had a group of compiler people who would do their best to incorporate
]considerations which users see in their optimizers, and produce their
]optimizers so that these improvements can be quickly inserted, we may
]get reasonable results.

Please try reading some compilers literature. One textbook on compiler
optimizations would do wonders for you!

Optimization is a _very_ difficult business. Any optimization has
interactions with other optimizations, in terribly complex (and not
necessarily well-understood) ways. Making any change to the
optimization process can have broad affects on the entire process.
Changing one instruction in an inner loop that saves two cycles per
iteration may completely disable a different optimization that would
have saved 200 cycles per iteration.

Any optimization, particularly on modern architectures, has got to
consider its affect on pipeline fills, branch predictions, register
allocations, memory and cache uses, and dozens of other factors.  Do
you think that you're qualified to judge what affect your two-cycle
savings will have on the rest of your program? If so, you're in the
wrong field - you should be designing compilers.

]The semantic model of the language can, however, greatly inhibit the
]programmer.  Try communicating floating binary from one machine to
]another; the only semi-portable way I have seen are to convert to
]higher precision floating decimal, transmit that, and convert back.
]

What does that have to do with the semantic model of the language?
That's a very hardware related issue. If I design a language that uses
floating point numbers, I'm restricted to using whatever internal
float format the hardware designer chose for the architecture I'm
learning. That's got nothing to do with the semantic model of the
language.

Just what do you think a semantic model is?

	<MC>
-- 
[ Mark Craig Carroll <MC> ] You say you know no tricks, have no talents -
[ U of Delaware, CIS Dept ] Isn't everyone supposed to have their own?
[ Grad Student/Lab Hacker ] Yes, but few are obvious. Few draw notice to those
[ carroll@udel.edu        ] who posess them, like flags waving themselves.