SyntaxBomb - Indie Coders

In my never ending quest i found this little site. https://able.bio/kerrishotts/building-a-basic-interpreter-80s-style--79a9d703

There is a lot to understand and learn.

Baggey

This is an excellent find. I like that he is looking at how to implement it in machine code. find out what need to be done and what can be dropped.

read a bit, take a break and let it seep in. try a few things as a test - just for fun.

What I liked was the first step was to upper/lowercase the input to minimise parsing errors. then work out how this can be built in machine code.

Suddenly you can understand the odd Spectrum way of inputting code - you are side stepping the parsing, and directly using token to start with <- it's genius if you think about it...

Quote from: iWasAdam on June 28, 2024, 07:07:40Suddenly you can understand the odd Spectrum way of inputting code

The real reason would have been down to costs. Adding a parser would have meant that Sinclair Research would have had to increase the ROM size, or use more than one ROM with additional logic chips to handle memory mapping. This was a company that did cost cutting by buying faulty RAM chips because they were cheap, and with a bit of wiring wizardry, made ZX Spectrum into a 48K model.


As for direct tokens. You could write an IDE to work in a similar fashion to how the ZX Spectrum did it by defined input modes and checking syntax on pressing enter.

Been there, done that, bought the t-shirt*

When I made JSE, I do believe I read that very blog for tips right at the start.  To be honest, I read a ton of different sites.  Probably would've been a good idea to keep a list... sorry

My parser converts everything to a token-style, and I also found it better to RPN the maths and such, eventually placing the command at the end of a "line" of code.
As an example..
Print 1+2*3+4  would become (after a TON of parsing, juggling, stacks, BODMAS and more...)

_v030000=n1
_v040000=n2
_v040001=n3
_v040002=m*
_v030001=r04
_v030002=m+
_v020000=r03
_v020001=n4
_v020002=m+
_v010000=r02
_v000000=r01
_v000001=iprint
Starts with 1, Multiplies 2 and 3, Adds that (via reference) to the 1, then Adds (via reference) the four, then Prints the referenced result.
There's an extra reference at the end, because I add a bracket-set to any commands that don't have them during the parsing.

The left value is the stack count, and on the right is what each "line" is doing.
n's are numbers, m's are maths, i's are commands. there's also v variables and s strings.  r's are references, and there appears to be too many of those, but I haven't found a neat way to remove the last few of those to keep things working properly!!  It'd be nice to just have it realise the numbers have reduced and automagically do the referrals, but ..  I dunno, lots of spaghetti code by that point

After that, I convert everything further into just a few arrays, with command names being turned into numerical command references, and things like that.

I did all this in Javascript, and one oddity I found right at the start was that Javascript can't handle HUGE Select/Case things.  I originally had all my commands in one big list, but it slowed it down terribly.  Instead, I split commands up into groups.  System/Logic/Drawing/Sound/etc, and now have one main select/case for the groups, which then splits into a second select/case for the commands within that group.  Sped things up a TON, so if you're looking to use Selects or similar methodology, be sure to watch for that.
Then it's just a simple case of flicking through and doing things in the order that you've set things out in.

Easy!!! :\

The best way is to stress test things, and play it by ear.
People will tell you one way is better, but as I learned doing this sort of thing in Javascript, where the browsers will try to further optimise the code, it's not always the case that one method is "faster" than another.
"Why reinvent the wheel?" ..  Because I'm driving on a different road, so I need a different wheel.
Test things, work out what's best, then go with that.



*I haven't bought the t-shirt.  Maybe I should make a t-shirt..?