Re: [opendemo-devel] zlib problems

[Dr. U. G. <Uwe...@ph...>]

Hello!

> What would
> be more interesting is where return pointers and return values are stored,
> as they apparently aren't stored in the same place as local variables and
> function parameters.
Totally correct.
Function parameters are stored relative to some thing called "Frame Pointer".
ADDRFP4 0 is the first argument of a function.
Local variables are stored relative to some other thing called "Local Pointer".
ADDRLP4 0 is the first local variable.
Return values are stored on the normal calculation stack. But both the calling
and called function must work together: we have CALLV to call a void function
and CALLI4 to call a function, which returns an integer (and CALLU4 for
unsigned etc.). Then we have RETI4 to return an integer. A strange thing is,
that after all CALLV statements comes a pop, which would mean, that even a
void function returns something but I looked at the asm of void functions and
they simply end with "endproc localspace framespace". May it be, that void
functions do not work at all? Then I found at least one place (I did not
especially look for it) in zlib, where framespace was 4 (bytes) but we had 2
arguments (8 bytes). Strange indeed!

So we have first the problem, that we need ALWAYS and in EVERY case the
CORRECT prototype for ANY function call. I'll do some automatic post-processing
of the asm files to look from more inconsistencies. What happens, if the
compiler issues the warning: unused function parameter? Will the space for it
removed but all calling functions don't know about this decision!

> >From what I remember, wbxml only stores XML structure data binary, so for
> example:
> <origin index="123">456</origin> 
This particular tag would result in 1 byte for "origin with attributes and
content", one byte for "index", then one byte encoding and 3 bytes "123",
then 1 byte attribute end, one byte for "text", one byte encoding, 3 bytes
for "456" and one byte "tag-end".
So we get 1 1 1 3 1 1 1 3 1 = 13 bytes (text XML is 22 bytes).

Bye, Uwe