🚀 go-pugleaf

In article <504@daitc.daitc.mil> jkrueger@daitc.daitc.mil (Jonathan Krueger) writes:
>In article <426@bnr-fos.UUCP>, schow@bnr-public (Stanley Chow) writes:
>>it is not necessary for all programmers to know enough to use
>>the specail instructions. Some guru can set it up and everyone can
>>then use the pre-built modules. Depending on how you set everything
>>up, the compiler does not have to be smart at all.
>
>Of course, but you lose the performance advantage if the modules get
>called frequently and require significant setup (e.g. can't maintain
>state for multiple callers or sequences) with respect to work
>performed.  Or to put it another way, That Way Lies Threaded Code.
>However, this isn't an argument for Better Living Through Inlining,
>rather an appeal for analysis and measurement of the tradeoffs.
>

This depends a lot on the system and language you use. We spend 
considerable time to make sure the utilities are suited to the
application. (This is easy, since this whole system is a single
application, and we have measured it to death).

In our operating system, maintaining states for multiple callers
is easy and essentially free. Most of the funny opcodes can be
easily generated by a peepholer and the really strange opcodes are
what we call Intrinsics - half way between macros and inlining.


>>For example, we have a system with really wild instructions that gets
>>generated even though the user don't know what they are and the
>>compiler does only peephole optimization. As is turns out, having
>>atomic operations for free is really nice.
>
>Sounds like you've managed to let your users express what they want in
>terms familiar to them but also understandable to the language
>translator, following which optimization to particular hardware can be
>done in a reasonable way.  By any chance, would this be done by way of
>a function library?

We use just about every trick in the book and some that aren't. Since
we have a project that is big enough to support our own language and
operating system, we have a lot of freedom. Usually, we figure out the
hardware/firmware limits, decide how we want it in the language, then
change the language/compiler and operating system to suit. Sorry I 
can't give details.


Stanley Chow        BitNet:  schow@BNR.CA
BNR		    UUCP:    ..!psuvax1!BNR.CA.bitnet!schow
(613) 763-2831		     ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public
I am just a small cog in a big machine. I don't represent nobody.