tinyPascal in BASIC

[Martin Schmalenbach]

Congrats on the HANGMAN conversion!

Did you start the CONVERSION with REMLINE as I had suggested. ? I used QB64 to compile the REMLINES.BAS source. I bet PureBasic could handle it too, maybe.

I'm sorry - I'm not familiar with REMLINE - I can't see reference to it here or elsewhere so I'm not aware of what this is or does. At a guess I'd say it removes REM statements that aren't the target of a GOTO, GOSUB or THEN statement?

Where might I find REMLINES.BAS? I think I should take a look at it!

Cheers

Martin

[Martin Schmalenbach]

Correct, 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.

Labels 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??!!

I 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!

Oh, 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.

To 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!

It'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

[ahenry3068]

Congrats on the HANGMAN conversion!

Did you start the CONVERSION with REMLINE as I had suggested. ? I used QB64 to compile the REMLINES.BAS source. I bet PureBasic could handle it too, maybe.

I'm sorry - I'm not familiar with REMLINE - I can't see reference to it here or elsewhere so I'm not aware of what this is or does. At a guess I'd say it removes REM statements that aren't the target of a GOTO, GOSUB or THEN statement?

Where might I find REMLINES.BAS? I think I should take a look at it!

Cheers

Martin

It actually removes all line #'s that aren't a target of GOTO,GOSUB,THEN, ON GOTO/GOSUB ,RESTORE, ELSE (Even though ELSE isn't in Commodore Basic it doesn't effect REMLINES efficacy on CBM code)


I posted it in my HANGMAN thread as it's what I used to start the conversion. It was distributed with MS-DOS 5.0 and QBASIC

viewtopic.php?p=29736&hilit=REMLINE.BAS#p29736

[Martin Schmalenbach]

It actually removes all line #'s that aren't a target of GOTO,GOSUB,THEN, ON GOTO/GOSUB ,RESTORE, ELSE (Even though ELSE isn't in Commodore Basic it doesn't effect REMLINES efficacy on CBM code)


I posted it in my HANGMAN thread as it's what I used to start the conversion. It was distributed with MS-DOS 5.0 and QBASIC

viewtopic.php?p=29736&hilit=REMLINE.BAS#p29736

Ooh - nice!

I've got it now - it should run with a few tweaks here and there in PureBasic on my Mac!

I'll get to it right away!!

Cheers

Martin

[voidstar]

I do astrophotography as well (steven_usa on astrobin, though I got a little bummed about what happened at astrobin a couple years ago -- big accident, but they did manage to recover quite a bit). And yeah, I've been thinking how the X16 (and "classic 8-bits" in general) might be shown to be viable astrophotography control stations (as far as aligning and slewing the mount at least, even dome control-- just not so much for image processing, obviously the 128-core "super computers" are still needed for that).

I'm excited to see a "first light" (first run at compiling a Pascal sample) on system And glad you're optimistic about the longer term challenges -- seems each data and "code blob" would need to be annotated with a possible bank assignment. Then I got to thinking, there might be cases where it might faster to duplicate/copy a "code blob" across banks rather than copying the data that runtime blob needs (a "blob" just being some object code sequence that generally ends with a RTS). In general I would imagine the blobs we'd generate would be easily relocatable in memory.

Lots to think about, but let's get to the WriteLn('Hello World!'); first
Or I guess at this stage, maybe we have to accept upper-case only.

[Martin Schmalenbach]

I do astrophotography as well (steven_usa on astrobin, though I got a little bummed about what happened at astrobin a couple years ago -- big accident, but they did manage to recover quite a bit). And yeah, I've been thinking how the X16 (and "classic 8-bits" in general) might be shown to be viable astrophotography control stations (as far as aligning and slewing the mount at least, even dome control-- just not so much for image processing, obviously the 128-core "super computers" are still needed for that).

Very cool!

An 8 bit machine is quite capable of this level of control, including calculations needed for guiding, especially if running along at a tidy lick, like 8MHz!

My first degree is electrical and electronic engineering, and for my final year project/thesis I developed an early microprocessor controlled switched mode power supply. It mostly worked - the challenge was processing speed in the control loop so I had to keep things simple.

Many moons later I found myself working for one of the premier microcontroller design/manufacturing companies who have a whole portfolio of fast 8 and 16 bit microcontrollers specifically for power control, with small but speedy 16bit DSP machines for the more interesting switched mode power supply designs.

Thing is, these days, a super-duper 32 bit microcontroller is way more capable and the same price or cheaper! Designers stick with those 8 and 16 bit designs especially where they desire a physically/electrically more robust design or a speedier response to interrupts. But it'll all be 32 bit one day - then 64 bit! Imagine, having a 64bit microcontroller controlling the motor to make your car window go up and down! It's coming!!!

[ahenry3068]

Thing is, these days, a super-duper 32 bit microcontroller is way more capable and the same price or cheaper! Designers stick with those 8 and 16 bit designs especially where they desire a physically/electrically more robust design or a speedier response to interrupts. But it'll all be 32 bit one day - then 64 bit! Imagine, having a 64bit microcontroller controlling the motor to make your car window go up and down! It's coming!!!

It sounds horrifying....lol... I wish we still had that little crank handle, they were more reliable .

[DragWx]

If the book I'm reading about Commodore is to be trusted, one of the things the 6502 aimed to do was give you a low-cost way to replace a discrete circuit with just a couple of components that could do even more if you needed.

Therefore, having a completely overkill microprocessor do something simple (like automatic window controls) because it's cheaper than the alternatives? That's a natural extension of something engineers were doing way back in the 70s. Remind me how the X16 interfaces with the keyboard, again?

[Martin Schmalenbach]

If the book I'm reading about Commodore is to be trusted, one of the things the 6502 aimed to do was give you a low-cost way to replace a discrete circuit with just a couple of components that could do even more if you needed.

Therefore, having a completely overkill microprocessor do something simple (like automatic window controls) because it's cheaper than the alternatives? That's a natural extension of something engineers were doing way back in the 70s. Remind me how the X16 interfaces with the keyboard, again?

But we like overkill!!!

[Martin Schmalenbach]

A quick update - I now have the code running on the X16 emulator that has come from the BASLOAD process, v0.2.3 for now, so it does have the REM statements in it - for now.

The code runs - at least, it has stopped crashing to the ML Monitor now I've stopped it from compiling the pCode in to important parts of memory - like starting at $0000!!!!

So it runs. BUT... I knew there were going to be a few subtle bugs here and there to do with the parser, so I suspect it will take me most of the weekend to track them all down - I know roughly where to look based on the kinds of error messages the compiler is giving me about the Pascal source code I'm compiling - it's known good code.

I'm hoping that my next update towards the end of this weekend will be a posting or a link to a video recording of the screen of my X16 hardware loading the Tiny Pascal compiler, compiling it and then running the pCode. One has to have goals - and dreams, right?!!