Ultrix CC bug?
Chris Torek
chris at mimsy.UUCP
Sun Sep 17 06:19:22 AEST 1989
In article <DUPUY.89Sep16000855 at cs.cs.columbia.edu> dupuy at cs.columbia.edu
(Alexander Dupuy) writes:
>... [a] big-endian machine ... allows easy and graceful punning from
>pointer type to pointer type, even if you bend the rules of C.
>... a little-endian machine [does not]
This is false, and indeed exactly backwards. Both machines allow
easy puns from one pointer type to another, because all pointer types
have the same size and format. But only little-endian machines can
get away with puns on data types. (A type pun is a `conversion'
that consists of simply pretending a variable has a new type. C
compilers can use puns if it generates correct machine code using
fewer instructions than would a true conversion.)
>[on a VAX] pointers to ints, shorts and chars all point to the high
>order byte
No, pointers point to the numerically lowest byte, which, on a VAX, is
least significant byte. On a 680x0, it is the most significant byte.
We have to use the `Chinese writing method' to avoid confusion:
location: byte:
000c 12
000d 34
000e 56
000f 78
Value at location 000c:
type: on vax: on 680x0:
char 12 12
short 3412 1234
long 78563412 12345678
In expressions like `*(long *)p', both machines simply `fetch a longword
from the address', without really caring what was originally stored at
that address. The trick comes in dealing with extended and narrowed
objects. In C, parameters to (non-prototyped) functions are widened,
so that `char' and `short' both become `int'. On a VAX, when one writes
f(x) char x; { char *p = &x; ... }
one gets a pun from the actual parameter (which has been `sent in' on
the stack as an int) to the desired parameter (a char), while on the
680x0, one gets a conversion. In code:
_f: .word 0 # (vax)
# ap+4 points to one longword holding the widened value of x
# in memory we have (if x=='!'):
#
# 4(ap) 21
# 5(ap) 00
# 6(ap) 00
# 7(ap) 00
#
movab 4(ap),r0 # p = &x
but
_f: link a6,#0
| a6+8 points to one longword holding the widened value of x
| in memory we have (if x=='!'):
|
| a6@(8) 00
| a6@(9) 00
| a6@(0a) 00
| a6@(0b) 00
|
lea a6@(0b),a0 | p = &x
which (inside the compiler) required a conversion to go from `a6@(8)'
to `a6@(b)'.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris at mimsy.umd.edu Path: uunet!mimsy!chris
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list