Problem with parameter to a SuperBASIC machine code extension

[swensont]

> BTW: Has anyone tried to run my reflection toolkit with compiled code (IMHO NO chance with Turbo and most probably also not even with QLiberator).

I've not tried your toolkit, mostly because I don't care about line number with SuperBasic. I write all SuperBasic without line numbers and let my pre-processor do all of the dirty work. The code looks so much better with no line numbers. I can't imagine programming with C, Pascal, Perl, or awk with line numbers, so why do it with SuperBasic. (just my 2 cents).

Tim

[NormanDunbar]

What Tim said! I haven't used line numbers in Super basic for ages!

Cheers,
Norm.

[ql_freak]

Good news:

Today I finished the "main" program of the missing function, and it seems to work.

Bad News:

I'm programming top (mostly very easy) down (mostly very complicated) and the 2 (assembler) subroutines, which do the real work, must still be written (they are currently only dummies, but at least they are called from the main program[!]).

[ql_freak]

I've not tried your toolkit, mostly because I don't care about line number with SuperBasic. ... line numbers, so why do it with SuperBasic. (just my 2 cents).

You MUST bother with line numbers, if you want to merge another S(uper)BASIC program to your main program, e.g. a library SuperBASIC program (which only contains PROCedures and FuNctions)!

That's why I have started to write the Reflection Toolkit. With the REF_GETLNFREE%() S(uper)BASIC function and my "rn" (C) program it is now possible to merge ANY S(uper)BASIC program file which does not use GO TOs (SUBs, ...).

Now I'm trying (today I realized, that I most probably will succeed) to write a FuNction which allows to port programs which are using GO (TO/SUB/...).

Please note: Programs with GO... cannot be MERGEd directly, you first must port them. But this should be easy (if I will succeed).
Note 2: Ported programs using "my trick" will be slower than using GO... directly(!). Most often you won't notice it, but there may be programs (where a GO... is used in [deeply nested, often called] loops), which will be notably slower.

[swensont]

> You MUST bother with line numbers, if you want to merge another S(uper)BASIC program to your main program

Not if all of your programs don't have any line numbers. If I want to use a procedure written by someone else, I will covert it to not have line numbers.

Also, I don't use MERGE, I use "#include file_ssb". This adds the file name "file_ssb" to the existing program as it is processed.

Tim

[NormanDunbar]

You MUST bother with line numbers, if you want to merge another S(uper)BASIC program to your main program, e.g. a library SuperBASIC program (which only contains PROCedures and FuNctions)!

Nope! If you use Tim's excellent (and I cannot praise it highly enough!) Structured SuperBASIC utility, you never need a line number again. Even for GO TO, GO SUB and RESTORE, no line numbers are required and the code still works.

Merging other library functions? Simple, there's an "include" command which allows multiple depths of nested "includes" for as deep as you need to go, provided you don't run out of file channel in the channel table of course.

Tim gave his blessing to me to make some changes. These are based on Tim's version 2.7.2 --- available from https://github.com/SinclairQL/Structure ... /tag/2.7.2 and from Tim. Tim still uses that version as it does all he needs to do. I'm using 2.7.2g which is available from https://github.com/SinclairQL/Structure ... tag/2.7.2g.

I thoroughly recommend you give it a try.


Cheers,
Norm.

[Derek_Stewart]

Hi,

I try to never use GOTO, GOSUB and the RESTORE command is a nightmare.

I usually use SSB which when it first appeared was all I was looking for. so I use that by default now, which gave the use of labels instead of line number references.

If the Line Numbers could be not displayed in TK2 ED, would this encourage the use of Procedures and Functions rather that GOSUB and GOTO

[ql_freak]

> You MUST bother with line numbers, if you want to merge another S(uper)BASIC program to your main program

Not if all of your programs don't have any line numbers.

It seems, you and nearly all others does not understand, how my Reflection toolkit and the rn program can be used. What I want is: That I can merge ANY S(uper)BASIC program, without first renumbering it.

THIS IS ALREADY WORKING (if the merged program does NOT use GO...)

Example:

Main program (pseudo code):

100 IMPORT'sblib1_sbl':REMark Simulate IMPORT with: REF_GETLNFREE% and the rn program
110 IMPORT 'sblib2_sbl'
120 ...
130 makeWhatImThinking
990 STOP

SB-Lib 1 (filename: sblib1_sbl; _sbl: SuperBasic Library):

1000 DEF PROCedure makeWhatImThinking
1010 ...
1020 isPrime=testIfPrime(number)
1030 ...

SB-Lib 2 (filename: sblib2_sbl):
1000 DEF FuNction testIfPrime(integer)
1010 ...

And this all will work with ED where you have the advantage of syntax checking when writing your program. With SSB you must use an editor. Does SSB have a real parser, which you can call with e.g.:

ex'ssb';"source destination >ram1_error_txt"

which will parse source, writes destination if no errors and outputs errors (or success messages) to ram1_error_txt?

It's unfortunately horrible to write such a parser for S(uper)BASIC. Not even the compiler writers did it. To compile a program with Turbo or QLiberator you first must load it as a SuperBASIC program before you can compile it. You unfortunately cannot directly compile from the source code (plain text). I'm afraid similar is true for SSB. If it will have a S(uper)BASIC parser, this would be great, than it shouldn't be too complicated to write a new S(uper)BASIC compiler or even editor.

[swensont]

IIRC, Wolfang's "Basic Linker" has a SuperBasic parser in it. It can be found on Dilwyn's page at:

https://dilwyn.theqlforum.com/program/Basic_Linker.zip

Tim

[BSJR]

IIRC, Wolfang's "Basic Linker" has a SuperBasic parser in it. It can be found on Dilwyn's page at:

https://dilwyn.theqlforum.com/program/Basic_Linker.zip

Tim

I write all my numberless Basic in QD and use F10-"sbas/qd" to parse and test run it from there.
BasicLinker will produce from that a numbered SBasic file and error reports.
The numbers are only needed & helpful to get BasicLinker to point my QD to the error line.
When no more errors are reported BasicLinker can then call QLib to produce the _obj file as well.
A _ctrl text can link several bin & SBasic modules together making the process mostly automatic.

BSJR