mwm@eris (Mike (My watch has windows) Meyer) (01/19/88)
[Followups pointed to comp.lang.misc.]
In article <36200003@pyr1.cs.ucl.ac.uk> awylie@pyr1.cs.ucl.ac.uk writes:
<Your explanation of pointers being shifted is wrong - this implies not
<that the pointers are on 4-byte boundaries, but that anything they can
<point to must have this alignment. How then do you handle arrays of
<chars (bytes)?
No, the explanation is right - the description was wrong. BCPL views
memory as a flat array of sequentially addressed words, each word is
at least 16 bits long, and large enough to hold the address of any
word.
On a 68K (or 370, where I did it), this means that words are four
bytes long, and the BCPL pointer to an object is it's machine address
divided by four. All BCPL object had to land on 4-byte boundaries, so
there's no remainder problem.
An array of chars was just a vector in which you had crammed
characters. If you wanted to deal with a string, you used PACKSTRING
to convert a vector into a string, UNPACKSTRING to go the other way,
GETBYTE to get a single char from the string, and PUTBYTE to change
them.
Oh, yeah - the compiler is nice enough to turn the construct "string"
into a PACKSTRINGed version of the vector.
The real problem in AmigaDOS is with things that want BCPL pointers,
not with things that return them. This can lead to obscure bugs as the
C structure moves around relative to longword boundaries.
Of course, the problem of going from machine pointer in the users code
to BPTR in the DOS to machine pointer in the Exec probably doesn't
help performance.
<mike
--
The weather is here, I wish you were beautiful. Mike Meyer
My thoughts aren't too clear, but don't run away. mwm@berkeley.edu
My girlfriend's a bore, my job is too dutiful. ucbvax!mwm
Hell nobody's perfect, would you like to play? mwm@ucbjade.BITNET