voidstar wrote: ↑Thu Oct 26, 2023 7:22 amCorrect, BASLOAD won't do long variable names. Stefan has been working on handling that, on and off for a few weeks. But he also helps with SMC and core system features (like gamepad, PS/2 keyboard interfacing) and those get a bit higher priority. That's all mostly stable, but for instance an unexpected gamepad issue propped up again just this past week.
I totally agree & understand.
voidstar wrote: ↑Thu Oct 26, 2023 7:22 amLabels were "easy" since there are only a few use cases: GOTO GOSUB RESTORE. But variables are used all over the place. It's very admirable he's even trying to tackle this - but I think will be very worthwhile since it makes a very new kind of experience on using these systems (one that I wish we had in the 80s!!). To me, it has "made BASIC fun again."
I agree - and working on more complex programs like a pascal compiler or assembler has made it more fun for me too. Next on my list is some kind of database to track all the many Gb of image data I generate in my other main hobby, astrophotography. Keeping track of which image data needs to be calibrated with which calibration data and from which dates/times, and variations thereof due to the use of different filters - a modern PC will eat this up for breakfast - there's probably an app already for that - but where's the fun in that??!!
voidstar wrote: ↑Thu Oct 26, 2023 7:22 amI see the p-code parser example the article is actually in Pascal itself. It has line numbers, except they are just file index numbers. So that may take some doing to adapt into BASIC, as a way to "emulate" the resulting compiled Pascal p-code - we could skip that (I mean a BASIC version of that), if your off-system version is suitable enough for testing (and for on-system focus on the p-code to 6502 conversions).
I converted the Pascal coded pCode interpreter to BASIC on my iPad using TechBasic, so I have that running and will bring it over to the X16 and C64/C128 very soon, as in the next week or so. The intention is to be able to develop code in Pascal on the X16 and then run it on the X16 - no need for any other computer or hardware. Until now I've been bringing over my generated pCode to the iPad via email and copy/paste to run it - it runs fine so I know the Pascal compiler is good at the moment. But I'll really want it all on the X16 when I start adding support for floats, strings and probably also 32 bit integer math. Pointers are defo on my list - very handy things!
voidstar wrote: ↑Thu Oct 26, 2023 7:22 amOh, before I forget: the X16 "natively" doesn't have { } braces, the typical comment symbols in Pascal.
Yep - I've made use instead of // and /*...*/ instead, just as in C.
voidstar wrote: ↑Thu Oct 26, 2023 7:22 amTo me, the "dream" is any high level language supported on system that:
- can define multi-line functions with arguments, like check_engine(a, 7)
- supports some form of record data structure
- can handle "large" allocations (beyond the ~32K that BASIC offers)
- function recursion isn't too critical to me, though most high-levels will support that
- pointers to types
#1 is there out of the box, though I need to extend it for handling floats and strings, pointers etc.
#2 on my list, also to be married with the file system and record handling, though I understand there are some quirks (bugs?!) in the way CBM machines handle these. Could be fun/tricky/arse-achingly annoying!
voidstar wrote: ↑Thu Oct 26, 2023 7:22 amIt's a lot of small steps first. But ultimately, another (long term) goal is:
- not just that data declarations >32K, but the code-portion can also be >32K. (i.e. the logic/size of the program results in >>32K of processing code, or even 64K. That'll get tricky: data declarations will have to get assigned a bank, with some "master table" keeping track of what those bank assignments are, and supporting generated code to automatically switch to those banks when the corresponding data is being accessed, etc.
This is actually easier than it might appear. At least, for pCode. Because pCode is a virtual machine using a virtual memory system, all (!) that is needed is a way under the hood to map the virtual machine to a suitably sized chunk of memory anywhere in the main 64K or memory space including the RAM and ROM banks. There's an added performance hit, but it does mean you get to run very big apps! Port the pCode interpreter to assembly language and much of that performance problem is resolved quite nicely.
As far as the functions/procedures and parameters etc are concerned, at first glance this does look challenging. But it isn't so much. The way most modern compilers handle this is with stack frames. The venerable 68000 processor from way back in the mid-late 70s had specific registers for handling stack frames and claiming/releasing them, along with specific instructions for doing so - LINK and UNLINK. The original Tiny Pascal compiler uses this approach also. All local variables and parameters, plus pointers to the parent function/code block are hosted on the stack frame, as many levels of hierarchy as you want. It's ideal for this environment, especially one as unsophisticated as the 6502.
Thanks for your comments and suggestions. I'm loving the vibe here!
Cheers
Martin
