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!