<div dir="ltr">On Fri, Jul 4, 2014 at 6:21 AM, John Criswell <span dir="ltr"><<a href="mailto:jtcriswel@gmail.com" target="_blank">jtcriswel@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 7/2/14, 9:44 PM, Bruce Hoult wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've considered doing this as well :-) As an exercise to learn the LLVM back end as much as anything.<br>
<br>
It probably makes sense to allocate 8 or 16 pairs of zero page locations as virtual 16 bit registers and make 32 bit operations available only as library routines/intrinsics.<br>
</blockquote>
<br></div>
One interesting problem with doing that is determining which zero page locations are free for use on the target machine.  The Apple II ROM, for example, reserves many of these locations for its own use. Other machines may reserve different locations within the zero page.</blockquote>
<div><br></div><div>The monitor reserves very few. Mostly just screen cursor position and the hooks for character in and out, if you want to use those. Or you can run on bare metal and do your own screen drawing and exit by calling the monitor init vector (e.g. the CPU reset vector).</div>
<div><br></div><div>DOS uses a few more, but not a lot.</div><div><br></div><div>The vast majority of locations marked as "reserved" are used by AppleSoft. Which you can totally ignore if you're not a subroutine called by & from BASIC. If you preserved monitor and DOS locations, then you can exit to the AppleSoft init vector. You'll recall "3D0G" :)</div>
<div><br></div></div></div></div>