Glulx accelerated functions and NUM_ATTR_BYTES

This post is going to be boring. You don’t have to read it unless you want to use obscure I6 compiler options.

Back in 1998-ish, when I was defining the object record layout for Glulx Inform (I6), I threw in seven bytes for the attribute flags. (That is, 56 attributes available.) This was more than Z-code had (48 attributes in V5/8) so I figured it was good.

But I didn’t want to absolutely lock that number in. So I added a compiler option. You can say ‘$NUM_ATTR_BYTES=11’ on your I6 compile, and it will leave room for 88 attributes. The value has to be 4n+3, because of the way I laid out the object fields, but you can increase it as high as you want.

So fine. Only I screwed up. I forgot to make the veneer code adapt to different NUM_ATTR_BYTES values. (The veneer code is a set of routines generated by the I6 compiler which handle object access and property lookup and so on.) So if you tried to use ‘$NUM_ATTR_BYTES=11’ in a game, all the object access would look in the wrong place and your game would crash. Oops. You’d think I would have noticed this in testing, but apparently not.

Anyhow, I submitted a compiler patch last week, and fixed the veneer code. (The I6 library code doesn’t need to be fixed, fortunately.) That hasn’t been released yet but you can get it on github if you really want.

So fine. Only I screwed up worse.

Back in 2006-ish, I came up with a scheme to speed up Glulx games by moving a few core functions into the interpreter. And one of these, you guessed it, was a veneer routine that contained the NUM_ATTR_BYTES bug. It’s fine as long as you stick to the default value of 56 attributes, but as soon as you increase it, the game crashes. And this is a bug in the interpreter. I can make a game using spiffy new compiler features but I can’t make players upgrade buggy interpreters.

Current plan: leave the old accelerated routines in the interpreter – I did promise that they would never change – and instead add a new set of accelerated routines, which are NUM_ATTR_BYTES-aware. The new routines will behave exactly the same as the old ones in the default case, but if you increase NUM_ATTR_BYTES, they won’t crash.

(The annoying part is that the bug is only in a single routine… but all the others call it, so I have to replace the lot.)

If you build a game to use the new routines, and run it on an old interpreter, it’ll run slow. (Because the new acceleration routines are missing.) This is better than crashing but obviously not ideal.

Note: I7 games use the (old) acceleration routines. I7 games never need to increase NUM_ATTR_BYTES, so they can ignore this whole problem.

Someday we may see the I7 compiler increasing NUM_ATTR_BYTES so that it can make more efficient use of Glulx RAM (I won’t get into the details) but I’m not going to put that forward as a suggestion until we get updated interpreters into common use.

I’ve tentatively added these definitions to the Glulx spec document:

I’m waffling about whether to increase the spec number to 3.1.3 for this change. My current theory is that I won’t; I’ll just update the 3.1.2 spec. The @accelfunc opcode is designed to be backwards compatible (or you can use @gestalt 10 to test whether the new functions are in place).

(Later tonight I’ll update the Glulxe and Quixe source code to match.)


I’m running into this error a lot now, and it’s caused by too many variables attached to a certain class. I just did a quick count, and came up to 86, (but I could be one or two off). If I add 1 more variable, I get this error:

Is this the bug you’re talking about? I’m cutting out every non-essential variable as I go, and am only trimming them now that I’m running into this error. I can attach 86-88 variables to another class, and it works, so it’s a problem with each “kind of [major class]”. For example, an NPC class I created, and the player class, if I combine the variables, it’s way more than 88 – but that does seem to be the magic number.

Nope! I’m talking about a runtime crash if you add the line “Use NUM_ATTR_BYTES of 11” to your game, which, I assure you, you’re not doing.

You’re seeing the generic “I6 compile failed” error. When you see that error, you can get more details by selecting the “Progress” pane of the “Errors” tab. That’ll show you the exact I6 error message. Post that and I can try to explain it – but start a new thread in the Inform forum. :slight_smile:

Thanks, zarf – I posted the report in the Inform board. I never knew about the progress button, thanks :smiley:

On the original subject: I have checked in updates to glulxe and quixe (the interpreters). I’ve also added the new material to the accelfunctest.ulx unit test (usual location). I think it all works right.

I will wait a few days for further comment, and then do formal interpreter releases.

(Also passed a patch for the Git interpreter over to DavidK. The accel.c code is nearly identical, so this was easy.)

I just wanted to say I read this whole thread, and liked it.

Glulxe 0.5.2 and Quixe 1.3.1 are up, with these additions.