🚀 go-pugleaf

On 6 Oct 1995, Stephen E. Halpin wrote:

> It's not convenient on a 24-bit machine (5600x).  There are plenty of DSP
> and embedded processors for which 32-bit 'int's would be impractical.

Well, that's true. On the other hand, it's probable that programming 
general applications on general processors (which are at least 32-bit 
these days) is very different from programming a DSP. When you're 
programming a DSP, you're probably pretty concerned about speed... and 
you probably don't want lots of error/bounds/etc. checking (which would 
slow things down). For a general programming language, you probably do.

> Something is better than nothing, as long as you dont get a false sense
> of security from it.  Im more concerned about boundary behavior, ie what
> happens with (2^31)*4/32..  When executed in order, it should really
> produce an exception - veriants of C which dont optimize to (2^31)/8
> return 0 and go on their merry way...  The simple truth of the matter
> is you have to know something about the underlying machine in almost any
> language.

I agree. However, you have to note that checking errors like in the 
example can be pretty difficult (w/o slowing the program down greatly), 
since many processors don't implement integer overflow exceptions. 
(Another note: If you're worried about speed and you know that your 
program will never cause an overflow in that way, wouldn't you want that 
optimization?)

> A language for developing such interface libraries to files/network ports
> which can cleanly and efficiently express the data types and conversions
> would be a good thing.  Making it part of the general language is more
> likely to lead to people bringing the endian issue up too far in the
> abstraction.  If someone builds such a language, it should also take
> care of alignment issues as well :->

Absolutely true (especially the endian issue). However, from what I know 
Ada allows the width (of integers) to be specified -- do you think that 
that's bringing hardware issues too far up in the abstraction? What does 
width really mean, anyway? First, it makes the assumption that the 
computer is binary. Then, there are endian issues and sign issues (2's 
complement versus 1's complement)...

> ACK!  There are machines where char/short/int/long are 8/16/16/16, 8/32/64/64,
> 32/32/32/32, 16/16/16/16, etc...  There are also 36-bit machines with 9-bit
> characters.  C and C++ have become popular due to the fact that one can write
> (with a little care) code which will run on a variety of architectures in
> an efficient manner, exploiting whats available, and living with what isnt.
> Its too late to make all the world a VAX (though X was a darned good try :-)

But you have to admit that the difference between a 16-bit and a 32-bit 
integer is pretty big. Maybe specifying a range (when needed) is the best 
way (i.e., you could declare an integer with values -100000 to +100000 
and it would use a 32-bit integer even on a 16-bit machine).

> Dont forget, UNIX and C grew together on a PDP-11 - a 16-bit machine.

Yes, and I programmed on a 16-bit machine (x86 in M$-DOG) in C for quite a 
while. However, for *future* languages, a move to a higher lower-bound should
be made.

- Trung