Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-ses!hpcuhb!hpcllla!daryl From: daryl@hpcllla.HP.COM (Daryl Odnert) Newsgroups: comp.sys.hp Subject: Re: Array indexing problem (bug?) Message-ID: <3770038@hpcllla.HP.COM> Date: 22 Dec 89 17:31:11 GMT References: Organization: Hewlett-Packard Calif. Language Lab Lines: 33 You have indeed discovered a bug in the s800 C compiler. I will forward the defect along the the C compiler team to investigate a fix. If you are interested in a technical description of what the problem is, read on. Warning, entering compiler guru mode... Because the array named junk is only global variable allocated in this program, it is allocated at the base of the global data area. On the s800, the global data area begins at address 0x40000000. The HP Precision Architecture is a 64-bit virtually addressed machine. The 32-bit address 0x40000000 is implicitly selecting a 32-bit space register with the upper two bits of this address. This space register is concatenated with the base register to form the 64-bit virtual address. When you subtract 20 bytes from the base address of junk, you get 0x3FFFFFEC. In this intermediate result, the upper two bits of the address have changed from 01 to 00, so they now specify a different space register. Unfortunately for us compiler writers, the LDBX (load byte indexed) instruction selects the space register for the memory reference *before* the base register and the index value are combined to form the effective address. Thus, when the LDBX instruction is executed in your test program, we are accessing a virtual space that we don't have access to. Ergo, core dump. Exit compiler guru mode. Happy Holidays, Daryl Odnert daryl@hpda.hp.com HP California Languages Lab