The Sinclair QL Forum

This is interesting stuff, Norman. I havent seen it documented before. But is this behaviour of a1 intentional? If it is replicated across MBasic and SBasic then good. If it only applies to Qdos JS, a suitable warning to that effect should be considered. IMHO software compatibility is very important - not least of all in such a tiny environment as ours.

Per

Hi Per,

If I remember correctly, the testing was done on QPC and SMSQ. I wrote a function, can't remember what for, that took no parameters but obviously returned a result. It crashed the system. I used QMON2 and was surprised to find that A1 was nothing like a decent value for the offset to the maths stack.

It might be wise to do some more debugging to see if anything has changed I suppose.

Cheers,
Norm.

All,

nowhere in the docs I have it's promised that on entry to a FN or PROC a1 would be holding the Arithmetic Stack (I've checked - only a6 is part of the deal). This applies to both QDOS and SMSQ/E.

The top of the arithmetic stack is usually pointed to by a1

is not enough of a contract, IMHO - Especially because this sentence occurs only in the context of "Parameters have been fetched".

It is exactly as Norman says - a1 needs to be set either through parameter fetch routines or by obtaining it from BV_RIP(a6). PROCedures without parameters probably wouldn't care and FuNctions without parameters are pretty rare - So the likeliness of not having a parameter fetch before trying to access the AS is pretty small, so this (wrong) assumption on a1 leading to problems is probably occurring only rarely. But assuming a1 points to somewhere reasonable is just wrong.

Tobias

(Who has just realized BV_RIP(a6) is part of the Basic variables that are allocated per SBASIC job, so sync is not an issue.)

Tobias,

I believe Norman was referring to something that, for some reason, was a common misunderstanding in the early days, when we were all grappling to get to grips with Qdos. But as Norman has pointed out, there may be a method in a1's value on entry to a proc/fn after all. It may turn out to be random, ie particular only to Qdos. This is yet to be determined.

I found something else that might interest. However that is a subject for another thread..

Per

nowhere in the docs I have it's promised that on entry to a FN or PROC a1 would be holding the Arithmetic Stack (I've checked - only a6 is part of the deal).

Wolfgang's pdf of the QDOS SMSQ docs, section 9 makes no mention of it in relation to obtaining parameters. Section 10 mentions it in respect of returning values. So point taken. However, I know pretty much 100% that just about any article of writing functions in any of the magazines past, did say that A1 would be the stack pointer on entry. Nothing about after fetching parameters.

I'm sure, almost, that Pennell does, somewhere. I need to check though.



Cheers,
Norm.

pjw wrote: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

Changing the numbers of Procedures, and the number of Functions. Seems to have fixed the problem, Thank you very much for your help.

I've found a couple of other bugs in the MAKE_FDI procedure, but that's another story...

If anyone is interested, I've finished a little test program that deals with procesing names, as opposed to string parameters, and it will be written up in the next issue of the randomly produced Assembly Language eMagazine. When it comes out. Which it will. Honest!

Cheers,
Norm.

NormanDunbar wrote:I When it comes out. Which it will. Honest!

Chomping at the bit already.....

tofro wrote:Chomping at the bit already.....

My wife is out watching "The Jersey Boys" so I have some time to play with my self (ooh err!) as it were, and get some writing done.

Watch this space .... [ ]

Cheers,
Norm.

NormanDunbar wrote:

nowhere in the docs I have it's promised that on entry to a FN or PROC a1 would be holding the Arithmetic Stack (I've checked - only a6 is part of the deal).

I'm sure, almost, that Pennell does, somewhere. I need to check though.

Ok, I found it in Pennel, as suspected. Page 123 in the section called "The Maths Stack" it states:

It is conventional to use A1 as the Maths Stack pointer, and as with all SuperBASIC system variables, it must be used relative to A6. Thus the top item ...... On entry to the procedure or function, A1 is a suitable value for the top of the stack.

And I have written on my copy, in pen, on this page, the following:

Bollox! A1 could be zero on entry to a procedure or function!


Cheers,
Norm.