🚀 go-pugleaf

From article <1992Nov13.155126.3660@linus.mitre.org>, by bs@gauss.mitre.org (Robert D. Silverman):
> 
> Herman is bemoaning the fact that quite often a computer HAS hardware
> to execute some particular instruction that he likes, but that HLL's
> do not allow him access to it.
> 
> I can cite one example that bothers me a lot.
> 
> Quite a few modern microprocessors have hardware to do 32 x 32 bit 
> multiplies and 64 bit / 32 bit divides.  I know of no HLL that will
> allow me to write code to access these instructions. For example,
> suppose I want to compute A*B/C exactly, where A,B, C are 32 bit
> ints and C > A and C > B.  How do I do this in a HLL ?
>  
> If one has:
> 
> long a,b,c,d;
> 
> c = 7777777;
> a = 111111;
> b = 222222;
> d = a*b/c;
> 
> 
> I will NOT get the right answer, even when the computer has a 64 bit
> multiply because the compiler will not generate the instruction!
> It will generate an ordinary 32 bit multiply, and a*b will overflow.
> 
> I would like to see a language that has a feature that will allow
> me to (say) define new operators that use specific machine instructions.
> 
> for example: (pseudocode)
> 
> #ifdef VAX define binary operator arg1 ** arg2  as  'emul arg1 arg2'
> #elseif SUN define binary operator arg1 ** arg2 as 'umul arg1 arg2'
> #ifdef VAX define binary operator arg1 /& arg2 as 'ediv arg1 arg2'
> #elseif SUN define binary operator arg1 /& arg2 as 'ldiv arg1 arg2'
> 
> 
> OR
> 
> define unary operator *& arg1  as  'sigbit arg1'
> 
> should my computer have an instruction, sigbit, that returns the
> most significant bit in a word.
> 
> and be able to write:
> 
> d = a**b/& c;
> or
> 
> d = *& a;
> 
> 
> where 'emul' is the double length multiply instruction on a VAX and
> 'umul' is the same for a SUN-3. Similarly for ediv and ldiv.
> 
> This requires that the code emitter for the compiler be able to
> recognize such things.
> 
> I would also like to see an HLL developed that handles arithmetic
> correctly. i.e. a language for numerical and semi-numerical algorithms.
> Fortran claims to be that, but it is woefully inadequate. 
> 
> I could design such a language, but I don't have the spare time to
> do it and I can't see my employer paying me to do it.

I must completely support this.

There are often VERY USEFULL things in the hardware, but now programming
language supports them. This is mostly the case in the field of numerics,
like
- long integer product, as shown by Bob,
- the carry, the major incredient to build a 'long' arithmetic
- rounding control, needed to generate verified results ( not a mode bit! )

The writing of own operators, as Bob would like it, is available in the
-XSC languages, where we have Pascal-, Fortran- ( Acrith-XSC by IBM )
and C- ( will come out soon )

Since these languages need long integer arithmetic for the precise dot product
access to the carry is mandatory. Since C does not support it the portable
versions are SLOOOOOW.....

Even those versions supporting IEEE hardware do change the rounding mode
veryveryveryvery often, which always drains the pipeline etc.

What bothers me even more is the fact that modern processors are designed
to support only things that can be used by HLL, mainly C, because statistics
show no use of other features ( what else ), and so we find ourselves
severley limited by a chicken and egg problem.

Reinhard Kirchner
Univ. of Kaiserslautern, Germany
kirchner@informatik.uni-kl.de