A peephole optimizer won't help with trigonometric functions; in fact, your best bet is to actually use more DATA statements and lookup tables for the results.

Caching the results is basically like using "look-up" tables. :)

The peep-hole optimizer was an idea to look for things that were obvious and blatant duplication of effort, like maybe calling to "PRINT" 30 times without any variables when you could just concatenate all those strings into one PRINT statement, find a way to eliminate obvious IF/THEN/ELSE constructs, etc.
I've actually seen it before distributed on a CD I once purchased for an Interactive Fiction collection...

I know. I watched a video on CORDIC which talks about how it's a technique to create the values for Sine/Cosine and other functions simply by using addition, subtraction and shift (and a few predefined lookups) and is very accurate. This means BASIC incorporates this to some degree, as does most hand-held calculators. It's simple, fast, cheap, and doesn't require anything too complex.

During my experiments i did save the values for the first 1/4th, then later 1/8th and had a circle drawn by swapping around which numbers the results were inverting. As creative as it is, it's probably years behind what other people do :P

I remember reading the GCC's notes on the different level of optimizations. It was all very very interesting, however safe to say i'm not really making a compiler or optimizer, and making something less readable is sorta the opposite that the detokenizer is intended to do (and more complex than i'd want to do).

Not necessarily years behind. I think you're doing pretty good.

I only recommended the optimization part because it would be interesting to optimize the tokens and see what the BASIC spew became.

BTW, not sure if you ever looked into Coursera, but they offer free online courses from some good schools. They have a really good one from Stanford on Compilers. No, you don't have to pay anything to learn. :)

Hmmm... i suppose i could try... Almost most of it would probably be just dropping idle/filler/useless tokens, which won't add much speed or save much space.

By far the slowest part of the Atari is the math, considering glancing at the instruction set i think it can only add/subtract, and only 8bits, so the BCD math is pretty much all emulated, although it works it's slow... while a 16.16 would probably work better, but not be appropriate for many applications.

Well, 8 bits of approximation is a long way off from 32-bits of approximation, can't blame them for trying... and yes, there was probably that one bubble-sort someone managed to creep in.

That's not quite it... I think variables for numbers have 10 bytes to hold their contents, which allows for 18-20 digits of precision (each byte holding 2 base-10 digits). All in all, it works... I'd have to look at the specifications for how it was stored again, but the floating point in Basic often is superior vs the float type, you could do your checkbook with 8-bit basic floating point math. However BASIC didn't allow the huge approximations that were done in floating point you'd see floats or doubles doing. So...

When I used the 99/4a, their floating point numbers were stored in Radix 100 notation. Floating numbers took 8 bytes each.

You're going to make me have to look up the specs now aren't you? :P

At least I gave you a link. ;)

Well glancing at my decoding notes for BCD, that might be the same format used by Atari/Apple Basic. My decoding function doesn't have many notes... but my source material comes from here.


LATE edit: Well i'll say with certainty the Atari800 doesn't use 8 bytes for it's internal floats.. it uses 6, but otherwise it's identical... (I think), the other 2 bytes are an identifier for type (number, array, string, etc) and it's variable ID.

Thanks!
I won’t pretend I understood all the details, but it clearly looks like an interesting tool.

Yeah... I just spent like 4 hours chasing after why it wouldn't decode an array number/name entry, only to find out the added block of data was put there by the cassette save code for sector information... That was annoying to figure out.

This reminds me of when I read about copy protection (DRM) on a game that was distributed on a casette tape. (Yes, DRM is older than consumer-grade floppy disks!)