(Free42) GTOs - question

[Werner]

Thomas, a question out of sheer curiosity ;-)
The 41 and 42 encode the jump lengths in their respective GTOs.
Short labels (0-14) can record jumps forward of 112 bytes, and long ones can handle 3584 bytes.
Since Free42 is a simulator, how does it handle GTO's? I think it encodes jump lengths as well, but is it also held to the original limits?
(for the long jumps it doesn't, just tried that out. On EMU42 I get 'Global Span' - I bet no-one else has seen that particular error before)
This is one area where I don't mind Free42 being different from the original, mind you. It allows much larger programs, and someone somewhere is bound to write a program longer than 3584 bytes with a single alpha label in it ;-)

Cheers, Werner

[Paul Dale]

My recollection of the Free42 code is that the offsets for branches are ignored. I don't think they are stored after import. On export, they are set to zero.

This means some synthetic programs will not work but I guess most wouldn't work despite it.

Pauli

[Werner]

I meant during execution, of course, not import/export.
I'm guessing Free42 encodes all jump distances as they are encountered, regardless of whether a short or long label is used, and without limits.
Cheers, Werner

[Paul Dale]

I don't remember seeing jump distances encoded at all.

Pauli

[Thomas Okken]

Free42 ignores GTO and XEQ offsets when importing programs, and it sets them to zero when exporting programs.

It does use offsets itself, but since the way Free42 stores programs internally is different, the 42S offsets and the Free42 offsets are usually different. Hence the way offsets are treated during import and export.

The internally-used GTO and XEQ offsets are signed 32-bit integers. There is no distinction between "short form" and "long form."

[Werner]

I think I remember Thomas saying something about that, not too long ago, but I can't seem to find it.
Anyway, there is a marked difference in execution speed between

1E6
1
>LBL 99
GTO 01
<lots of lines>
>LBL 01
DSE ST Y
GTO 99

and GTO IND ST X instead of GTO 01.
The GTO 01 execution time remains constant, whatever I put between the GTO and the LBL, while the GTO IND ST X execution time becomes longer if I put more lines in between..

Cheers, Werner

[Werner]

Thanks Thomas.
Werner

[Werner]

and now, a request for incompatibility ;-)

The 42S has 8 return stack levels, faithfully reproduced in Free42 - but why? This is a case where the 42S is not 'compatible' with the 41 either - I know of no programming construct where you'd purposefully exploit having only 8 return levels.
In view of the vastly larger programming space, wouldn't it make sense to remove that limit altogether?

Cheers, Werner

[Thomas Okken]

(03-27-2018 05:36 AM)Werner Wrote:  and now, a request for incompatibilty ;-)

The 42S has 8 return stack levels, faithfully reproduced in Free42 - but why? This is a case where the 42S is not 'compatible' with the 41 either - I know of no programming construct where you'd purposefully exploit having only 8 return levels.
In view of the vastly larger programming space, wouldn't it make sense to remove that limit altogether?

The fact that the HP-42S isn't perfectly compatible with the HP-41C is no excuse for Free42 not to be as close as possible to perfectly compatible with the HP-42S.

Still, I have been chewing on this for a while, and I agree that removing the eight-level limit from the return stack seems highly unlikely to cause any existing programs to fail -- and if or when such programs do turn up, adding an option to restore the limit would always be a possibility.

It made me think, though: the more deeply you can nest subroutines, the more annoying the lack of local variables becomes. Looking for a way to address this, without RPLifying Free42, I came up with this idea: a new function called LVAR, which takes an alpha argument, no indirect allowed (i.e. syntactically like MVAR), which stores the contents of X in a new local variable, which exists until execution returns from the current level. The local variables will have dynamic scope, and will hide any global variables with the same name.

I haven't decided to do this yet, but I think it's an interesting idea, assuming I can figure out how to deal with the potential problems, e.g. should local variables show up in variable catalogs, how would they interact with REGS, SOLVE, and INTEG, and who knows what else may turn up.

Thoughts?

[Werner]

I've been thinking about that, too - but that is a change I would never have dared to ask for ;-)

I make do with globals for now, and use names starting with the return level, meaning, programs that call no other use variables "0something", the ones that call another must use "Nsomething", with N 1 higher than the highest level used in any called subroutine. The current-level variables are deleted upon return, and this way they'll never get in each other's way.

But of course real local variables are way better.

How would you recall the contents of LVAR? With RCL?
(Alternatively: STO L "VAR" and RCL L "VAR", akin to STO/RCL ST ..)
But why no indirection?.. many times I use variables as pointers inside a matrix - and since you can have only one matrix indexed, I use REGS as a second one, and access it with RCL IND something. Okay, you could do

Code:

 RCL L "I"
 RCL IND ST X

but that's a bit of a kludge.

Werner

[Thomas Okken]

No, no -- after having been created with LVAR (or LSTO or whatever it may end up being called), local variables will be indistinguishable from regular ones. You'll be able to create a local REGS, index a local matrix, use the regular STO, RCL, etc. on them.

Hmm, regarding indexing, making that possible inside a subroutine would require the name of the indexed matrix, and the I and J pointers, to be scoped as well. This is getting messy already.

[Thomas Okken]

(04-11-2018 02:55 PM)moonbeam Wrote:  Isn't this what github and the like are for? Thanks to you releasing Free42 under the GPL, anybody can fork Free42 and set up feature branches to experiment.

True, but finding ways to collaborate is trivial compared to the challenge of actually writing solid code. Are you volunteering to develop the LSTO (and LINDEX, LEDIT, LEDITN, LPGMSLV, LPGMINT) extension?

[Paul Dale]

Local registers on the 34S caused a few issues but were worthwhile. Solve and integrate were fun -- the routine being solved can access locals from where the solve was invoked. We included some local flags as well but only allowed numeric registers (starting with a dot) rather than variables.

One I wish we had exposed to users is the xIN / xOUT pair -- these preserve the stack, set last X etc. They allow subroutines to behave like builtin commands without having to track all the stack motions or using registers to preserve unused things. xIN also allocates local flags but not registers. A combination xIN which allocated some locals would be more useful I suspect.

Pauli

[Werner]

(04-11-2018 02:18 PM)Thomas Okken Wrote:  No, no -- after having been created with LVAR (or LSTO or whatever it may end up being called), local variables will be indistinguishable from regular ones. You'll be able to create a local REGS, index a local matrix, use the regular STO, RCL, etc. on them.

O, I misunderstood. Sounds good!

Thomas Okken Wrote:Are you volunteering to develop the LSTO (and LINDEX, LEDIT, LEDITN, LPGMSLV, LPGMINT) extension

Why would you need LINDEX etc? Once a matrix has been created with LVAR or LSTO, you could use INDEX" straight away, no?

Cheers, Werner

[Thomas Okken]

(04-12-2018 05:33 AM)Werner Wrote:  Why would you need LINDEX etc? Once a matrix has been created with LVAR or LSTO, you could use INDEX straight away, no?

Yes, I had just come to realize that as well. You do need special behavior in INDEX, EDIT, and EDITN for local matrices (because the previous indexed matrix and IJ need to be restored when the indexed local matrix goes out of scope), but of course they can simply detect whether or not a variable is local. There's no need to have separate functions to make that explicit.

I still think LPGMSLV and LPGMINT are needed, at least if you want SOLVE and INTEG to be able to nest. Calling those functions would create new instances of the solver's and integrator's internal data structures.

I foresee a fair amount of internal messiness, but from a user's perspective, this is starting to look like it would be pretty clean and elegant, and it wouldn't have to break backward compatibility.