Pascal not considered harmful - was Re: Rich kids are into COBOL

Chuck Guzis cclist at sydex.com
Sat Feb 21 16:49:17 CST 2015


On 02/21/2015 12:26 PM, Mouse wrote:

> Well, this makes it impossible to implement long long, which (loosely
> put) must have at least 64 bits of range.  But let's pretend that long
> long doesn't exist, or perhaps that all the bit counts you give are
> doubled, or some such.

I think a double-precision type could be shoehorned if we decided to 
describe as our subset of floating point terms--96 bits of precision in 
two 64 bit words, with the exponent field of the more significant being 
48 larger than the least significant--and both being unnormalized. 
Basically 96 bits of integer spread across 128 bits.

Consider this one--in the arrangement described, there's no particular 
reason that the exponent (protected padding bits if you will) need to be 
in the most significant bit position in a word.  You could exchange the 
positions of the exponent and significand or even scatter the 
exponent/padding bits among the significand bits.

How do bit logical operations (especially shift) operate then?

> FSVO "byte", I agree.  However, since we've been discussing C, there's
> a _lot_ of (C) code that assumes that char * has the same size and
> representation as other pointer types, even though there's no
> justification in the C spec for such an assumption.  (POSIX, on the
> other hand, may impose such a restriction; I don't have even a draft of
> POSIX handy to check.)

One thing that I've never understood was the lack of a bit type in C 
(not the struct bit length specification), but something encountered on 
bit-addressed architectures.  That is, a bit array starting and ending 
at arbitrary addresses, complete with a pointer that can be dereferenced 
to select a specific bit.  Vector machines certainly use this capability 
and C seems to be totally oblivious to it (c.f. sparse and control vectors).

The biggest problem of C to me is the existing code base that makes all 
sorts of assumptions about data type and structures.  Because this is 
The Way Things Are, it becomes more difficult to propose alternative 
architectures that might be more efficient.  Witness the "nUxi" problem 
that plagued early ports of That Operating System.

I recall the moan from one of my project members when confronted with 
automatic optimization of C.  "A *&^%$ pointer can refer to ANYTHING!"

Ah well, time for me to get back to coding for my ternary-based machine 
that uses Murray code as its character set.

--Chuck




More information about the cctalk mailing list