What is the purpose of the 8 bytes at the end of the program?

Bobb Fwed

In the Propeller Tool, under the F8 dialogue, after your program there is "FF FF F9 FF FF FF F9 FF". They're long-aligned.

What is their purpose?
I am creating a bit of software for a firmware update, and I'm wondering if these are important. They don't show up when you "Save Binary File", but they do when you "Save EEPROM File"

rogloh

Bobb Fwed wrote: »

In the Propeller Tool, under the F8 dialogue, after your program there is "FF FF F9 FF FF FF F9 FF". They're long-aligned.

What is their purpose?
I am creating a bit of software for a firmware update, and I'm wondering if these are important. They don't show up when you "Save Binary File", but they do when you "Save EEPROM File"

Am guessing they are the return address on the stack used for the top level spin program. They point to the Spin Interpreter's stop COG byte code at hub address $FFF9 (sign extended to 32 bits). This will stop the interpreter when you exit from the top level SPIN function block. I'm not entirely sure why there are two copies however.

David Betz

rogloh wrote: »

Am guessing they are the return address on the stack used for the top level spin program. They point to the Spin Interpreter's stop COG byte code at hub address $FFF9 (sign extended to 32 bits). This will stop the interpreter when you exit from the top level SPIN function block. I'm not entirely sure why there are two copies however.

Is one the error target? Doesn't spin have a way of signaling an error something like catch/throw in Lisp? (you can tell I'm not an expert Spin programmer!)

Edit: I think I'm talking about the ABORT statement and the corresponding way you catch aborts.

kuroneko

rogloh wrote: »

I'm not entirely sure why there are two copies however.

If Im reading the booter correctly the important bits here are pcurr and pbase+flags. As it happens they live on opposite ends of the stackframe (see interpreter source for return & Co), i.e. pcurr is pop'd first, pbase+flags last. So since you're writing 2 longs anyway it might as well be the same.

Dave Hein

The four words make up the initial stack frame which is used when executing a return from the first method or an abort. The four words of the stack frame contain the caller's PCURR, PBASE, VBASE and DBASE. It also contains two flag bits which indicate whether the return value should be stored on the stack and whether an abort stops at that point or should continue aborting to the next stack frame. The value of PBASE is $fff9, which is the address in the ROM that contains Spin bytecodes that execute cogstop(cogid). Since this code does not access DAT, VAR or stack variables, and it does not call a method the values of PBASE, VBASE and DBASE don't matter. The only things that matter are the value of PCURR ($fff9) and the abort trap bit.

BTW, the checksum byte is calculated including the 2 extra stack frame longs even though the binary file doesn't include them. If you add up the bytes in a binary file you will get $14. If you add the extra 8 bytes from the initial stack frame you will get $00.

Bobb Fwed

What I am gathering is that they are there to terminate Cog 0 if the code just kind of trails off (no infinite loops or something). So are they necessary, or should it just be best practice to include it?

What I am writing is not for public consumption, so anything that gets programmed with the firmware updater will be extensively tested, and will definitely include infinite loops.

Dave Hein

If you're programs never return from the first method in the top object, and can never abort through it, then you will never use the initial stack frame. So in that case it is not needed. However, in my opinion it is best practice to maintain compatibility with standard tools and file formats.

Bobb Fwed

Dave Hein wrote: »

If you're programs never return from the first method in the top object, and can never abort through it, then you will never use the initial stack frame. So in that case it is not needed. However, in my opinion it is best practice to maintain compatibility with standard tools and file formats.

Alright, thanks.

Bobb Fwed

Dave Hein wrote: »

If you're programs never return from the first method in the top object, and can never abort through it, then you will never use the initial stack frame. So in that case it is not needed. However, in my opinion it is best practice to maintain compatibility with standard tools and file formats.

But the two longs come after the VAR block. If I only receive the .binary file, there is no way to know how much space to reserve for the VAR block (or is there?).

Dave Hein

The first 16 bytes provide all the information you need. They are as follows:

Bytes Meaning
----- -------
 0-3  CLKFREQ
  4   CLKMODE
  5   CHECKSUM
 6-7  PBASE - Starting address of first object.  Normally $10
 8-9  VBASE - Starting address of the VAR area.
 A-B  DBASE - Starting address of the stack variables.  Address of RESULT variable in first method.
 C-D  PCURR - Starting address to execute code.  Normally address of the first PUB method in the top object.
 E-F  DCURR - Starting stack address.  Normally the address just after the last stack variable in the first PUB method.

The VAR block size is DBASE - VBASE - 8. The value of 8 accounts for the initial stack frame.

Bobb Fwed

Awesome. Thanks.