woody@tybalt.caltech.edu.UUCP (04/06/87)
The Megamax C compiler library stuff insists upon using the magic location 694 decimal (2B6 hex) in low memory to store a long word of data. For some reason programs compiled using version 3.0 of the C compiler crashes a Mac II, and I think it may be because of this. However, as I don't have access to a copy of IM v5 at the moment, I thought I'd ask this forum if it is possible that the crash is occuring because of a write to this global location. What is at this location anyways? BTW, the decimal address is correct; I think the hex value is right, but I wouldn't bet a house on it... - William Woody Mac! > ][n && /|\ woody@tybalt.caltech.edu woody@juliet.caltech.edu
jww@sdcsvax.UUCP (04/06/87)
In article <2236@cit-vax.Caltech.Edu>, woody@tybalt.caltech.edu (William Edward Woody) writes: > The Megamax C compiler library stuff insists upon using the magic location > 694 decimal (2B6 hex) in low memory to store a long word of data. For some > reason programs compiled using version 3.0 of the C compiler crashes a > Mac II, and I think it may be because of this. ... > ... What is at this location anyways? $2B6 (aka 694 decimal) is ExpandMem "pointer to expanded memory" according to the APDA beta IM Vol. V file :AIncludes:SysEqu.a It isn't in the MPW 1.0 includes, so it must be new. Why doesn't it use scratch20 equ $1E4 scratch8 equ $9FA which are unallocated and rarely used by programs? -- Joel West {ucbvax,ihnp4}!sdcsvax!jww (ihnp4!gould9!joel once I fix news) jww@sdcsvax.ucsd.edu if you must
woody@tybalt.caltech.edu.UUCP (04/06/87)
In article <2957@sdcsvax.UCSD.EDU> jww@sdcsvax.UCSD.EDU (Joel West) writes: >In article <2236@cit-vax.Caltech.Edu>, woody@tybalt.caltech.edu (William Edward Woody) writes: >Why doesn't it use > scratch20 equ $1E4 > scratch8 equ $9FA >which are unallocated and rarely used by programs? >-- > Joel West According to IM V.1, scratch20 and scratch8 are not guarenteed across various ROM calls. (Apparently, they're also used as scratch space by the ROMS.) However, ApplScratch (I don't have IM with me, so I think that this is the right symbol--I don't know the memory address) is 12 bytes of scratch space useable by the application, and guarenteed unfussed with across ROM calls. Most likely, I'll try patching my copy of the Megamax C compiler, and re-compile the syslib file and see if it works on our institute's Mac II. - William Woody Mac! > ][n && /|\ woody@tybalt.caltech.edu woody@juliet.caltech.edu
dgold@apple.UUCP (04/08/87)
In article <2236@cit-vax.Caltech.Edu> woody@tybalt.caltech.edu (William Edward Woody) writes: > >The Megamax C compiler library stuff insists upon using the magic location >694 decimal (2B6 hex) in low memory to store a long word of data. For some >reason programs compiled using version 3.0 of the C compiler crashes a >Mac II, and I think it may be because of this. You are absolutely correct. This memory location was reserved for use by Apple (it was named BasicGlob and used to be reserved for the never- released MacBasic, but I don't recall seeing anything which told people they could use it). As of system 4.1, we're using this location on all machines (Mac Plus, Mac SE, and Mac II). Any program which trashes this location will cause a machine running System 4.1 (Mac II being the best example) to crash. -- David Goldsmith Apple Computer, Inc. MacApp Group AppleLink: GOLDSMITH1 UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold CSNET: dgold@apple.CSNET, dgold%apple@CSNET-RELAY BIX: dgoldsmith