Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!haven!umbc3!umbc5.umbc.edu!cs472226
From: cs472226@umbc5.umbc.edu (David Wood (CS472226))
Newsgroups: comp.sys.apple
Subject: Re: Computer languages on the various Apple Corp computers
Message-ID: <2075@umbc3.UMBC.EDU>
Date: 24 May 89 11:41:17 GMT
References: <2821@puff.cs.wisc.edu> <10204@claris.com>
Sender: newspost@umbc3.UMBC.EDU
Reply-To: cs472226@umbc5.umbc.edu.UUCP (David Wood (CS472226))
Organization: University of Maryland Baltimore Co.
Lines: 48

In article <10204@claris.com> kevin@claris.com (Kevin Watts) writes:
>
>Sorry, but the 65816 is quite inadequate for high-level languages.  The main
>problem is it's severe shortage of registers, which is why it's NOT a RISC
>chip - they have LOTS of registers.  Yes, it does have stackframe support,
>but large data sets are extremely cumbersome - anything over 64K requires
>struggling like crazy to obtain any sort of reasonable performance, and
>because of the bank restrictions even 64K can be difficult to obtain.
>Crossing a bank boundary on a 65816 produces very messy code.  In some
>ways the restrictions of the 65816 remind me of the problems with the
>Intel chips (before the 80386), but at least there segments can begin
>on any paragraph (16 byte) boundary.
>Oh, and I expect that some people will claim that direct (zero) page space
>provides sufficiently rapid access that it's equivalent to having 256 bytes
>of registers - there's some validity to such a claim, but it won't work
>at all if the direct page register is used to set up a stack frame, which
>is essential for a high level language and pretty much so in any sizable
>hand-coded assembler project.  Also, there isn't a true general register
>anywhere, which really constrains high-level languages.

   There is a possible solution for that...
   Let's say you absolutely positively MUST set up a stack space (sounds
reasonable for most languages I've seen). You have the stack register
pointed at a large block of memory... Why does it ALL have to be
reserved for the stack?
   Why not shave off 2, 4, 8, 16, or however many bytes of storage above
the bottom of the stack at the end of the page (stacks build down) and
reserve it for those values that you would otherwise contain in
registers? I'm not completely familiar with the 816 instruction set (and
I don't carry my reference library around), but I think there are single
instructions which read and write to the DP fast enough to support
register emulation.

> Kevin Watts        ! Any opinions expressed here are my own, and are not
> Claris Corporation ! neccessarily shared by anyone else.  Unless they are
> kevin@claris.com   ! patently absurd, in which case they're not mine either.

   The solution is simple ...maybe too simple.

                                                    -David Wood
************************************************************************
*  A Mind is a Terrible Thing  ***  Attention: I WAS WRONG ABOUT THE   *
* to have Oozing out          ***  PUMPKINIZATION DATE OF THIS ACCOUNT *
* your ears...               *******************************************
*      -- The League of     ***  This account vaporizes on Friday,     * 
*         Sadistic         ***  MAY 26! Conventional mail address is:  * 
*         Telepaths       ***  7 SYCAMORE CT. GRASONVILLE, MD 21638    *
************************************************************************