Open avsa242 opened 4 months ago
Oh no...
I guess the problem is that there's two level of structure. I think this might be repro-able in C, too?
Anyways, the problem is that only the final level of structure is taken into account, so it actually ends up reading from FullDuplexSerial's VARs, very curious.
Basically, the ROM interpreter is very specifically able to do all the kinds of memory access that plain Spin1 can do. All extended features are basically trying to make the square peg go through the round hole, which is why the function to do it is called BCCompileMemOpExEx
and needs to contain 19 goto statements.
Ahhh k, I wondered how much of these features required a lot of bending, creasing, crinkling of things to get it all to work...
Hey guys,
When I create an array of VARs of a structure I've defined, if I read the values back after setting them, they aren't quite correct (seems like an offset calculation in memory is wrong or something).
For instance, running the attached parent1.spin shows:
when I'd have expected it to show:
The former output is spin1/P1/bytecode. The latter is spin1/P1/PASM. spin2/P2 in both cases seems fine.
The 'Arrayed' outputs above shows two ways of reading the data. The first tries to read the structure members directly (basically
ser.dec( child.structname.member )
). The second way uses a "getter" function call to return the value. The function call seems to work fine, but not the direct read by the parent object.Cheers
struct-arrays-issue.zip