home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.mac.programmer:20895 comp.sys.atari.st.tech:6532
- Path: sparky!uunet!stanford.edu!rock!concert!duke!dsb
- From: dsb@duke.cs.duke.edu (D. Scott Bigham)
- Newsgroups: comp.sys.mac.programmer,comp.sys.atari.st.tech
- Subject: Re: Sozobon (or other free C's): would this strategy work?
- Message-ID: <726422043@bronto.cs.duke.edu>
- Date: 7 Jan 93 15:54:04 GMT
- References: <29879@castle.ed.ac.uk>
- Followup-To: comp.sys.mac.programmer,comp.sys.atari.st.tech
- Distribution: comp
- Organization: n. Arrangement in an orderly or logical fashion. See "miracle".
- Lines: 29
-
- From the Holy Book of <29879@castle.ed.ac.uk>
- as spake by ngse18@castle.ed.ac.uk (J R Evans) :
- > [...] I propose to build a relocating loader to be inserted
- >into the CODE 1 resource. This would load and lock the TOS format
- >module into memory, allocate and lock a further area for the bss
- >segment, relocate the code and pass control to it. [...]
-
- Seems like it would almost be easier to convince Sozobon to produce
- PC-relative, base-relative code.
-
- Another possibility is a pseudo-relocator post-processor that takes the
- object file output and transmogrifies absolute addressing modes to
- PC/base-relative. The result could presumably be dropped into a CODE
- resource and treated just like normal Mac code.
-
- > [...] According to several correspondents who are
- >acting as beta-testers, Ian is almost ready to release a further
- >version of HSC - version 1.40i - for which the source will be more
- >readily available. [...]
-
- "Almost" may be too strong a word, considering that we haven't heard a
- peep from him in about four months.
-
- -sbigham
- --
- Scott Bigham | The opinions expressed above are
- dsb@romeo.cs.duke.edu | (c) 1993 Hacker Ltd. and cannot be
- bigham@hercules.acpub.duke.edu | copied or distributed without a
- (but not for long) | Darn Good Reason(tm).
-