Command line parameters

[NormanDunbar]

Maybe post some of the stack tidying code you are running to clear off at the end of a procedure? With a bit of context as to what is or should be on the stack from parameters fetching etc?

Cheers,
Norm.

[tofro]

Each SBasic has its own name table (parts of which are inherited (and supplemented) from job 0).

Yep. But there's only one single instance of the Arithmetic Stack, I believe (because there's only one instance of system variables and thus only one Arithmetic Stack Pointer). Martin's post made me start to wonder how this is shared/synchronized between several daughter Basics.

Tobias

[pjw]

Tobias,

There are significant differences between the SBasic and SuperBasic designs (and, it would appear SBasic daughter Basics) but there doesnt appear to be any documentation. Perhaps we could have a thread exploring the differences between the various Basics? I started looking into SBasic 15 or 20 years ago (and I havent done much real hobby-programming since then). The SMSQ/E source code was not available to me at the time, so it was very much RTFB. My notes on whatever I found is in the form of commentary spread around the code of whatever I was doing at the time, so Ill have to do some digging and refreshing.

One conclusion I came to at the time, IIRC, was that SBasics dont move, so all that faffing around with double indexing via a6 is redundant - except for for compatibility reasons, of course: Ie you can treat the stack pretty much as you can from within a compiled program. Once an instance of SBasic, including job 0, starts, a6 is fixed for the whole session. That conclusion seems at variance with your findings?

Per

[Martin_Head]

tofro wrote:

Martin_Head wrote:.... I was adjusting the maths stack pointer to clear them before returning to BASIC, while trying to take care of odd length strings etc.

It would be interesting to know how you did this, as any manual changes to the AS need to be in properly allocated memory and reflected in the system variables.

To remove something from the maths stack, Adjust upwards the value of A1 then store in, BVRIP ($58(A6)).

NormanDunbar wrote:
Maybe post some of the stack tidying code you are running to clear off at the end of a procedure? With a bit of context as to what is or should be on the stack from parameters fetching etc?

I'm attaching two versions of the procedure to this message in a Zip file.

Note the second version (new) has some rewriting to remove the maths stack tiding up, and some other improvements to the original code, but has not been tried yet. Or even assembled yet, so there may be some assembly errors present.

As I said earlier, I'm not even sure that this procedure is causing daughter SBASIC jobs to fail.

[dilwyn]

Volume P of DIY Toolkit has some general parameter handling extensions - not specifically what you were looking for, but some assembler code to study in general.

[Martin_Head]

A bit of an update. I've been doing some tests to try to narrow down the problem.

I've assembled my modified version of the command (see my previous post), and I'm still getting crashes when SBASIC daughter jobs are started.

I usually use QPC2 v3.30, but I am also getting similar problems with QPC2 v4.02

Could somebody please try my code to see if they get the same problems in case it's something weird about my system. I've attached a Zip file, with the code I am using

So in QPC2 v4.02 this is kind of problems I am seeing

Start QPC2 (it loads it's normal BOOT file from WIN1)
Then type -

LRESPR flp1_command_cde
MAKE_FDI "dos6_SDmake","SDtest","s"
SBASIC
switch to the daughter SBASIC job

Up to here everything seems to be OK

If I now type into the daughter SBASIC job, LOAD flp2_qdos_imageexplorer_bas - The whole system tends to lock up. However if I load the image explorer program from FLP1_, it will appear to load OK. (It's not just the image explorer program, other Basic programs cause problems also)

But the whole of Basic is now in trouble, If I type ED in either SBASIC job. The listings are corrupted and keywords are missing. If I type EXTRAS into either SBASIC, I get different lists of keywords, with a lot of them missing. Which suggests to me that the Name Tables are getting corrupted.

But I only seem to see problems after starting a daughter SBASIC job, and it doesn't do it always. (but the above steps seem to bring it on)

This only seems to happen after the MAKE_FDI command. Because if I leave that one out, things seem to be OK again, So I need to look into that further.

[pjw]

Martin,

Just took a quick peek at your code, command_asm. The first thing that strikes me is that the procedure initialisation table is faulty. Id say that is the first thing to put right. It would explain all your symptoms. The problem is that the numbers of procedures and and functions are merely estimates to allow the initalisation routine to reserve enough space. I quote from the Bible:

The "approximate number" of procedures or functions is used to reserve internal table space. It
can be calculated with the following formulae:
INT ((total number of characters used in procedures or functions + 6)/7)

Thus in your case the number of procs should be (9+11+7+8+6)/7 = 6 - not 4.

Ive burnt myself on this a number of times. There is a nice macro, part of the smsq/e sources, called dev8_mac_proc. It takes out all the hassle of working it out every time you make a change.

Per

[Martin_Head]

Thus in your case the number of procs should be (9+11+7+8+6)/7 = 6 - not 4.

Ive burnt myself on this a number of times. There is a nice macro, part of the smsq/e sources, called dev8_mac_proc. It takes out all the hassle of working it out every time you make a change.

Per

Thanks I'll give that a try.

I have discovered, (I don't know if it's tied in with the above) that the problem seems to start in the procedure when I allocate space on the common heap and fill it with $FF's.

If I don't fill the space, then the daughter SBASIC jobs seem to be OK. It seems like when the space is released to the common heap, then a new SBASIC is started, it uses the old space in the common heap that is full of FF's and corrupts it. But I would expect the operating system to clear the area before starting a new SBASIC.

So for a quick test, I cleared the allocated space before releasing it, And that seemed to fix the crashing problem with the daughter SBASIC job.

I'm sure I should not have to clear the allocated space before releasing it. So hopefully the initialisation problem will fix it.

[pjw]

In a case like this, after initialising the procedures, the machine is basically in a crashed state and anything could happen. I cant promise the fix will solve everything, but it is necessary and a good place to start

[NormanDunbar]

I've had a really quick look and noticed, as mentioned elsewhere, that your number of procs is wrong. If the average length of the new procs is greater than 7, then you must use the formula as detailed. If the average is 7 or less, then the individual lengths is fine.

I also see a comment about A1 being the top of the maths stack. The following extract from chapter 7 of my free book should, hopefully, dispell that particular myth....

One of the first things I learned when writing extensions to SuperBasic was that on entry to a function or procedure, the A1 register is set to a value corresponding to the top of the maths stack. This is a myth and is not correct.

The value in register A1 can be anything on entry to a machine code function or procedure. I have done a lot of investigating (thanks to QMON2) and come up with the following rule:

If you want a suitable value in A1 for the top of the maths stack, then either fetch some parameters, or, load it from BV_RIP.

This means that if a function wants to return a value - which functions usually do - and the function has no parameters then you must load A1 from BV_RIP(A6) before calling the BV_CHRIX vector to reserve space. As I found out to my cost, not setting A1 is a good way to trash the system!

If your function does have parameters, then AFTER they have been fetched, A1 is set ok, up until that time, it is not and has the following possible values:

7.8.1 A1 Is Negative

If A1 is a negative number, then your function has been called as part of an expression such as:

PRINT 10 * MY_FUNCTION(p1, p2, p3 ....)

The number in A1.L is the number of bytes that have already been used on the maths stack for the ‘10’ in this case. This will be -6 as the 10 will be stored as a floating point number.

7.8.2 A1 Is Zero

If the number in A1 is zero, then your function has been called thus:

PRINT MY_FUNCTION(p1, p2, p3 ....)
or
PRINT MY_FUNCTION(p1, p2, p3 ....) + 10

and no bytes have been used on the maths stack yet.

7.8.3 A1 Is Positive

If A1.L is greater than zero then this implies that there are A1.L many bytes available on the maths stack and calling bv_chrix to allocate stack space will not move the maths stack around in memory. (Assuming the requested space is less than the value in A1.)

So if your code doesn't fetch any parameters, then A1 is not suitable for storing in BV_RIP and will trash the system. So that might be something to look at.


Cheers,
Norm.