16 Nov 2006 01:40:39 -0500

Related articles |
---|

[3 earlier articles] |

Re: Fastening the run-time interpretation of mathematical expressions akk@privat.de (Andreas Kochenburger) (2006-11-13) |

Re: Fastening the run-time interpretation of mathematical expressions martin@gkc.org.uk (Martin Ward) (2006-11-13) |

Re: Fastening the run-time interpretation of mathematical expressions tommy.thorn@gmail.com (Tommy Thorn) (2006-11-13) |

Re: Fastening the run-time interpretation of mathematical expressions 148f3wg02@sneakemail.com (Karsten Nyblad) (2006-11-15) |

Re: Fastening the run-time interpretation of mathematical expressions martin@gkc.org.uk (Martin Ward) (2006-11-15) |

Re: Fastening the run-time interpretation of mathematical expressions idknow@gmail.com (idknow@gmail.com) (2006-11-15) |

Re: Fastening the run-time interpretation of mathematical expressions gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-11-16) |

Re: Fastening the run-time interpretation of mathematical expressions darius@raincode.com (Darius Blasband) (2006-11-20) |

From: | glen herrmannsfeldt <gah@ugcs.caltech.edu> |

Newsgroups: | comp.compilers |

Date: | 16 Nov 2006 01:40:39 -0500 |

Organization: | Compilers Central |

References: | 06-11-052 06-11-060 06-11-074 |

Keywords: | history |

Posted-Date: | 16 Nov 2006 01:40:39 EST |

Martin Ward wrote:

(snip)

*> I forgot to add that when I wanted to solve the exact same problem in*

*> interpreted BASIC on a Compukit UK101 machine (with a 6502 processor*

*> running at 2 MHz and 4 KB of RAM) I needed a rather different*

*> approach. Take the string containing the mathematical formula, convert*

*> BASIC keywords to tokens, and overwrite a line of the running program*

*> with the new BASIC line (the space required having been pre-allocated*

*> by padding the line in question with spaces!).*

(snip)

*> [Wow, that's gross. -John]*

About as gross as much of the 6502 code. There is a story about

someone with a cloned Apple II ROM claiming that they had packed the

code so tightly that there was no other solution to the problem, and

so it should be legal to copy.

I remember once looking at 6502 code for a jump table that pushed a

value onto the stack, and the did a RET. I wondered why all the

constants were off by one. It seems that JSR pushes one less than the

address of the next instruction, and RET adds one before the jump.

Most likely self modifying code was very common for 6502's, though I

never wrote much of it.

-- glen

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.