[comp.sys.atari.st.tech] Turbo C's Wierd Behavior

carter@cat34.cs.wisc.edu (Gregory Carter) (04/01/91)

Cold anybody explain why Turbo C 2.0 takes a long constant like this:

ffff8e20 and turns it into -> 8e20  then takes
00ff8e20                   -> ffff8e20???

I had this occur when I was working on my app program..MOST ANNOYING.

It seems to only generate the correct address when you insert the two 00's
????

--Gregory

hyc@hanauma.jpl.nasa.gov (Howard Chu) (04/03/91)

In article <1991Apr1.065127.11604@daffy.cs.wisc.edu>
carter@cat34.cs.wisc.edu (Gregory Carter) writes:
>
>Cold anybody explain why Turbo C 2.0 takes a long constant like this:
>
>ffff8e20 and turns it into -> 8e20  then takes

It's an optimization. Remember, word-length values loaded into address
registers are automatically sign-extended, so you can store addresses
0000-7fff and ffff8000-ffffffff in only 16 bits. This saves 2 bytes and
a couple cycles every time you reference those addresses. It is also
completely legal/correct.

>00ff8e20                   -> ffff8e20???

Dunno, maybe to try to take advantage of the above optimization. It's
also perfectly legal. In fact most of my docs list the hardware register
addresses as ffffxxxx, not 00ffxxxx. Can't think why you'd want to use
4 bytes to store a value when you only need 2, and using 4 slows you
down...
>
>I had this occur when I was working on my app program..MOST ANNOYING.

Nothing to fret about whatsoever...
>
>It seems to only generate the correct address when you insert the two 00's
>????

The address will be correct when the code actually executes. Leave it
alone...

Hey, what's any of this got to do with the Mega STE? (Why was Mega STe in
the keywords of your posting?)
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA
	Disclaimer: How would I know, I just got here!