Xref: utzoo comp.sys.atari.st:36785 comp.sys.atari.st.tech:1863 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jato!hanauma.jpl.nasa.gov!hyc From: hyc@hanauma.jpl.nasa.gov (Howard Chu) Newsgroups: comp.sys.atari.st,comp.sys.atari.st.tech Subject: Re: Turbo C's Wierd Behavior Message-ID: <1991Apr3.002151.178@jato.jpl.nasa.gov> Date: 3 Apr 91 00:21:51 GMT References: <1991Mar31.181651.9813@daffy.cs.wisc.edu> <1991Apr1.065127.11604@daffy.cs.wisc.edu> Sender: news@jato.jpl.nasa.gov Organization: SAR Systems Development and Processing, JPL Lines: 36 Nntp-Posting-Host: hanauma.jpl.nasa.gov 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!