Jump to content
geek504

Teaching BASIC

Recommended Posts

On 1/23/2021 at 2:44 AM, paulscottrobson said:

Fine as long as you limit your words to 256 bytes (slightly less in practice). There's still a bottleneck because you've got one 8 bit stack, so there's a big hit on enter/exit.

The pointer in JMP (COLD,X) pointer is updated with every branch or call to a high level routine ... and if there is any serious issue of having 128 consecutive primitives, a check on number of primitives compiled and an "update pointer" primitive can eliminate that constraint, though a word that has 128 consecutive primitives is a symptom of a deeper failure to factor code properly.

As far as stacks, the 65C02 has an implicit S register stack, as many explicit addr,X or addr,Y stacks as there are pages of RAM, (zp),Y stacks for stacks of data frames. Anyone who faces a constraint because they have boxed themselves into only using a single stack only has themself to blame.

Edited by BruceMcF

Share this post


Link to post
Share on other sites

Absolutely. The problem is those three lines - inx ; inx ; jmp (code,x) are executed so much that obvious fixing (putting BMI in there) have a performance hit.

It's the same thing with the stacks. If you use that jmp (code,x) as your core, then you still have two stacks, one is fairly efficient and the other isn't.  You can have as many stacks as you want, yes, it just takes a fair amount of CPU cycles to do them.

Share this post


Link to post
Share on other sites
On 2/21/2021 at 1:01 AM, paulscottrobson said:

Absolutely. The problem is those three lines - inx ; inx ; jmp (code,x) are executed so much that obvious fixing (putting BMI in there) have a performance hit.

It's the same thing with the stacks. If you use that jmp (code,x) as your core, then you still have two stacks, one is fairly efficient and the other isn't.  You can have as many stacks as you want, yes, it just takes a fair amount of CPU cycles to do them.

However, it remains highly infrequent ~ the most common frequency would be 0 ~ that there are 126 calls in a row between branches or literals, so just clearing a count when compiling a branch or a literal and incrementing it when compiling anything else, and inserting PGFIX if the increment passes 127 would suffice. It would almost never be triggered, and if triggered would rarely actually be needed, but the first means that the runtime penalty of the second is negligible.

As far as the overhead of a Y indexed stack, the system efficiencies of not having return addresses and operands intermingled on the same single stack more than compensates for that.

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use