The Sinclair QL Forum

Ignoring all the other aspects of machine code extensions and call to compatible hardware issues that would and could arise.

Does anyone know or have any comments on how difficult it would be to write an interpreter or compiler based around the Sinclair QL SuperBASIC and have it running on a Linux based system?

A Nano-emulator I suppose!

If you ignore the problems as you say, then it wouldn't be too difficult, but it wouldn't be SuperBASIC as we know it. For example, extensions are a huge part of SuperBASIC's success and almost all programs use them. Other problems would be computed goto/gosub/restore statements, compatibility with existing software (e.g. different numeric results, weird commands like FILL, etc.) and access to modern devices (graphics, storage, etc.)

And how difficult would it be to,port qdos or smsq to ARM, e.g. RaspberryPI?

SMSQ/E has probably over 200,000 lines of 68000 assembly code. Porting to a different language would be a big task, it's unlikely that anybody would want to do it, especially when emulation-based soultions are so much easier.

M68008 wrote:SMSQ/E has probably over 200,000 lines of 68000 assembly code. Porting to a different language would be a big task, it's unlikely that anybody would want to do it, especially when emulation-based soultions are so much easier.

I love it when a typo still means something relevant

Mr_Navigator wrote: Does anyone know or have any comments on how difficult it would be to write an interpreter or compiler based around the Sinclair QL SuperBASIC and have it running on a Linux based system?

As a Debian user, I can say it would be a dream, but probably impossible. A language with similar syntax to S*BASIC is one thing. But reproducing the specific features of S*BASIC and its environment in another system is a different thing. In the first case, you could use simple QL programs to some extent, but they would need rewriting anyway.

Some time ago I searched for modern BASICs for Linux. Finally I tried FreeBASIC. It's multiplatform, very powerful and... it's free software (so anybody can contribute to its development, and so its future seems guaranteed). But I didn't like it: many data types, too many syntax details... and the endless cycle compiling-testing-editing-compiling...

Some time ago I used OPL+ a lot. It's a OPL (the Psion 5mx language) preprocessor that improves the original language. I think something similar could be done with FreeBASIC macros. A layer of macros could be created to transform S*BASIC-style code into actual FreeBASIC. It sounds a really attractive project for me. But it would be a compiler anyway, and in my opinion one of the best features of S*BASIC is it's an interpreter.

Finally, since QPC2 and Wine work fine together, the suggested runtime QPC2 would be an alternative too.

Porting S*Basic to, say, Raspberry Pi has been going around in my head for a while, plus, (I'll regret this) it's not all that hard at all.

ANTLR http://www.altlr.org would be my tool of choice and I'd generate a C interpreter from it, not Java. Then I'd slap a wxWidgets http://www.wxwidgets.org front end onto it for the GUI.

Problems? What problems?

1. Bugs in the QL will not be replicated across. And why should they be?

2. Machine code extensions, toolkits etc are completely out - Raspberry Pi is not a 68000 processor and, most of Linux will be running x86 in 32 or 64 bits too.

3. You'd have a bare bones, vanilla flavoured S*Basic interpreter - with the only manner of extending it being to change the Lexer/Parser/AST/Interpreter. And possibly the run time "library" as well.

4. Who's going to do the work?


Bonus points?

1. The GUI would be cross platform, as would the backend, so Windows users could use it as well.

2. Any program executed would open a new window with all the joys of non-destructive text etc based on the underlying host OS.

3. File open dialogues etc, again, based on the underlying host OS.

4. Etc.


The main drawback is time. If I was to make any serious effort on this front, I'd have to stop everything else! Anyone fancy writing 68000 Assembler for QL Today?

Norman, please go on writing!
I have much more use for your Assembler articles than for YAIL(*).

Cheers
tofro

(*)Yet Another Interpreted Language

tofro wrote:Norman, please go on writing!
I have much more use for your Assembler articles than for YAIL(*).
(*)Yet Another Interpreted Language

Morning tofro,

Thanks! I never knew anyone other than George read my articles. I have two readers now!

Using an AST (Abstract Syntax Tree) between the parser and the interpreter (which is really just a tree walker with actions) means that it would be "simple" to compile - well, at least to bytecode Visual Basic style.

Or, compile Basic to C or C++ and then compile the C/C++ with gcc/g++.


Cheers,
Norm.