> "erik quanstrom" <[EMAIL PROTECTED]> wrote...
> > this is different from how c has traditionally done types.
> > c types mapped to what the hardware provides.  unless
> > you're working on a hc6508 or similar, you probablly don't
> > have bit-wide memory access.
> > [bool]'s more in the spirit of oberon, or pascal which have
> > had more formally defined and machine independent
> > types.
> 
> C has a long tradition of not mapping precisely into the
> native types, not even on the PDP-11, where "long"
> was word-swapped from the native format.  bool can
> easily be implemented in one of the native integer types.
> Its properties are appropriate for its use.

i assume you mean that the word order was different than
what the dec compilers generated,  not that the unix c compiler
generated code to word swap longs after the operation.  if that's 
true, this case isn't analogous.

in the case of _Bool assignment the compiler needs to generate
magic fixup code on each assignment to overcome the machine.

i would assume (since i don't have the code), the pdp-11 compiler
needed to do the same dance we do these days for vlong.  (or
one does for short on an 8-bit machine).  while this isn't pretty,
a bigger integer than the hardware provides can be needed and
difficult to manufacture efficiently in c without access to the 
carry bit or extended MUL result.  

- erik

Reply via email to