Jun-6 4:20 PM - Jun-11 12:44 PM

[MS] had reached out asking about a project of mine, the [TRS-80 on a PIC32], and if it was considered stable.  I believed it was -- it's an older project of mine, and now it's in enhancement/maintenance mode (though interesting bugs are still found from time-to-time by users!)  At length, the reason for the inquiry is that they were thinking about replacing an existing BASIC interpreter that seemed slow with an emulation of a TRS-80.  They did a little research and so came across my project.

However, as flattered as I was at the notion of porting my emulator to another hardware platform (which I would enjoy), I had to ask:  wouldn't a native implementation be faster than an implementation on an emulated CPU?  And has there been any analysis done on where the slowdown might be.

[The guys involved in the project] had been running at break-neck speed to get it completed for an event, and really hadn't had time to dig into the speed problem.  (I know, I saw the commit history -- it was very impressive what was done in such a small time.  Integrating this BASIC was just a small part of the overall project.)  Since that event was over, there was a little time to come up for breath and look at possible improvements.

I had taken a peek at the BASIC implementation.  It was straightforward:  just 2 C-language modules (4 files, header and implementation), and didn't have any funky library dependencies.  The code was originally written by an Adam Dunkels [http://dunkels.com/adam/ubasic/] as a personal challenge to himself to speed-code a functioning BASIC, and he released it unto the world for anyone to use if they liked.  [The project team] had extended it with a bunch of new keywords, and of course adapting to their board's I/O subsystems.

OK, those that know me, know that I have a fetish for disassembly.  I'd check myself into Betty Ford if they had one for reversers.  I don't know why it is -- it just is.  It's yielded some good things professionally, but not often enough to slake my thirst.  A distant third or fourth place is for code optimization, so for someone to say they have a speed problem in some straightforward C source code... That's going to be a... 'distraction', for me.  I guess it's best just to take a look and get it over with....