Structured SuperBASIC

[NormanDunbar]

Afternoon all.

As you know, I have hijacked Tim Swenson's excellent Structured SuperBASIC application (aka compiler) and have been making changes,

I have just uploaded release 2.7.2f to the Sinclair QL GitHub at https://github.com/SinclairQL/Structure ... ses/latest where you can read about all the bugs I have fixed in this release. Granted, some were a bit esoteric, buty hey, that's me.

There's still the problem of the trailing line continuation flag, which is a valid PRINT separator, to fix.

ssb272f.zip

(31.41 KiB) Downloaded 190 times

Cheers,
Norm.

[NormanDunbar]

Afternoon all.

Version 2.7.2g has hit the release area on Github: https://github.com/SinclairQL/Structure ... ses/latest. This version has fixed the bug whereby the line continuation character, '\', at the end of a (valid) PRINT statement led to the following line being joined to the PRINT line, causing either silent corruption and/or MISTake lines to be caused. The continuation character(s) are now "\+".

This release is no longer compatible with previous releases.

As the line continuation is now "\+", using this version to compile lines with the '\' as the continuation will simply cause errors when loading the generated SuperBASIC code. Equally, running versions up to and including 2.7.2f against ssb files using the new continuation, will fail or will have unexpected results!

The latest version is on GitHub as per the URL above, or attached somewhere on this post.

ssb272g.zip

(32.06 KiB) Downloaded 192 times

At this point, I have no plans to make any more changes, that I am aware of anyway! Bugs that I might have created will, of course, be fixed.


Cheers,
Norm.

[NormanDunbar]

Attached is a small utility which can be used to convert the loaded SuperBASIC program to an SSB file for use with Structured SuperBasic. This utility strips out line numbers, converts "REMark"s to "**", handles GOTO, GOSUB and RESTORE correctly, and everything else required to convert a loaded program into an SSB source file for further manipulation.

I have no idea if this is useful, I was using the file as an example of examining the loaded contents of a SuperBASIC program actually in memory, and it sort of grew from that!

I have compiled it with QLiberator 3.36 I think, so it should be ok. However, it does use the enhanced PEEK commands in SMSQ, such as X = PEEK_L(\\$10) to get the long contents of the Basic Variable which is $10 bytes on from the start of SuperBASIC. I use this to get the program start address, end address and to extract names from the name list/name table. I am 100% certain that this will not work on plain old, but much loved, QDOS systems.

User testing has been done, by me, and it seems to work. I'm happy to receive bug reports etc.

My thinking is to convert this to a useful (?) Assembly Language utility for a future eMagazine. At present, it is not part of the SSB repository on GitHub.

* Load your program.
* Execute the Basic2ssb_obj file, will need the Qliberator run times.
* Type in the full name of the desired output file, including and "_ssb" extensions and device names.
* Press ENTER and the program will do its stuff.


EDIT: I've removed the original attachment. It was actually compiled with Qlib 3.35 but that seems to not like running with "$" for hexadecimal numbers. I have just tried to compile it with 3.46, but that has thrown up 20+ errors about duplicate names which doesn't make sense to me. If anyone can get the attached source file to compile with Qliberator and run afterwards, I'd be grateful. I'm obviously doing something wrong and it's been years since I late liberated any software!

Basic2ssb.zip

(10.79 KiB) Downloaded 191 times

Cheers,
Norm.

[badaman]

It's an excellent piece of work, and I'm glad it's now available in Spanish.

Just to suggest crazy ideas (you never know where they'll end up), I think this transpiler could be something like TypeScript in the future, a superset of SuperBASIC that checks data types to avoid errors at transpilation time.

[dilwyn]

Looking at the Basic2ssb_bas code:

2930 END FOR
change to 2930 END FOR x
(in the procedure decode_program)

3880 END DEFine monadic
change to END DEFine monadics

5640 END DEFine readText$:
change to 5640 END DEFine readName

The compilers seem to (unlike interpreted BASIC) need End Define and Define names to match, and don't seem to allow omission of loop names at the end of FOR names (I think SBASIC tries to match to most recent loop name).

The same issues seem to be in the _bas and _ssb versions.

Then compiles OK with QLib 3.46, no errors compiling, but running it on itself produces an output file of zero length.

That's as far as I've got so far with it. Hope that helps a little. I'll take a deeper look later on if I get time.

[NormanDunbar]

Thanks Dilwyn. I did manage to find those and fix them, which allowed me to compile the code. This has introduced new problems as it seems that in interpreted S*BASIC the various "indirect peek" functions return a value, such as the peek_l(peek_l(\\$10) ) to get the start of the program file, but when compiled, some of them return zero.

Probably to do with not being job zero, I need to check further. It seems that finding the job control block in the system variables and extracting the start address of the job should work, but that gives zero compiled or interpreted. It works fine for other running jobs though. Basic is obviously special.

Trying the same trick, but pulling A6 from the saved register list gives different results when interpreted and compiled! Aaargh!

The supplied code will run, interpreted, if you feel like giving it a try, it will recreate its own SSB file!

Cheers,
Norm.

[dilwyn]

What was interesting was how the missing END FOR name and two mis-matched END DEFine names seemed to throw the compiler into generating that long list of errors causing it to struggle with so many otherwise legitimate names!

[pjw]

The compiled version of the program is very different from the interpreted one; they are not the same. So if the program is peeking its own structures while running two different versions of the program are probably needed. Most of the program data structures are emulated in the compiled version but, for starters, the compiled version has no parser. The token list may also not be the same.

[dilwyn]

Any merits in making Basic2ssb work on _sav files instead?

[NormanDunbar]

Hi Dilwyn, Per,

I too was confused when I sorted the "warnings" about the proc/fn names in the end define not matching, which cured the 20+ duplicate name errors. Weird!

I suspect that I might have to go down the route of reading a SAV file as opposed yo just looking in the program file, but I'm going to write something in Assembly first, because I'm daft like that, to see if:

1. I can!
2. I can make it work!

Per, thanks. I was aware that a compiled program might have troubles accessing the real Basic area, but I am trying out a couple of workarounds. One of which is as how you did it in the boot file for Qliberator 346u, getting A6 from the JCB list. But, I'm not convinced that will work compiled. Time will tell!

Cheers,
Norm.