Path: utzoo!utdoe!generic!pnet91!ericmcg
From: ericmcg@pnet91.cts.com (Eric Mcgillicuddy)
Newsgroups: comp.sys.apple2
Subject: Re: relocatable code
Message-ID: <312@generic.UUCP>
Date: 22 Dec 90 21:50:09 GMT
Sender: root@generic.UUCP
Organization: People-Net [pnet91], Etobicoke, ON
Lines: 34

>>I suggest that bank aligning code segments and only using short (6502)
>>addressing modes would be a valid solution.
>
>Sure it would work, but it defeats the purpose. The goal was position
>independent code that didn't need relocation or bank-alignment. Using
absolute
>code segments IS a valid solution if you aren't worried about the effects on
>memory of all those bank aligned blocks. If you are writing a big program and
>intentionally write it so that it sits comfortably in a few bank aligned
>spaces
>then that's great -- but I prefer solutions that are still environment
>friendly
>for both small and large projects.

I am curious how you would insure that a position independent code segment
would not cross a bank boundary, particularly in the context of a Memory
Manager compaction. I assume that the code segment is unlocked immediately
after it completes execution and locked just prior to commencing execution. My
suggestion is that all code and data segments are precisely 64k long and page
aligned (the only option the memory manager supports). This will create a
certain amount of wastage for small programs, but does provide a known amount
of workspace that is easily accessed by the code. What I am attempting to do
is turn a problem with the 65816 (segmented memory model) into an advantage.
This also has the added advantage of providing hardware memory protection for
multiple processes, since the architecture prevents the crossing of bank
boundaries, as well as providing position independence for code segments.

This is the entire premise of ViM, if it can not work then perhaps I am
wasting my time and should go ont{{o{ {_{{_ano{ther project?i]
{_{.s
w.s

UUCP: bkj386!pnet91!ericmcg
INET: ericmcg@pnet91.cts.com