[Exult-general] Usecode, CALLE and CALL

[Marzo J. <ma...@ya...>]

    Hello all,

    One thing I have noticed while going through BG
and SI usecode while researching to make a usecode
decompiler was this:

-- Every function below 0x800
    (a) Says that it has a parameter. This parameter
never really seems to get used -- even for the
functions that do "use" it, the first time it appears
it is being assigned to.
    (b) Is only ever called in ways that set an
itemref (i.e., CALLE opcode, scripts/intrinsics,
NPC/egg/shape functions, spells, weapons).

Conversely, 
-- Every function above 0x7FF
    (a) Pays attention to the value of the first
argument, if it specifies one.
    (b) Is never called in ways that set an itemref
(i.e., it is only ever used through the CALL opcode).

    This leads me to the conjecture that the
"argument" specified by functions below 0x800 was
actually itemref, and it was specified only so that
the originals games knew how much memory the function
would use up (this "argument" was only accessible
through PUSHITEMREF opcode, though -- this is
verified). These functions are the only ones that were
ever called from outside usecode. Such functions also
only ever have this "phantom" argument, and no others.

    I've been toying with the idea of implementing
this in Exult/UCC/Exult Studio. The symbol tables
would have a new type of function ('object_fun', say)
which, together with 'shape_fun', would tell Exult not
to pop values from the stack for such functions (as it
currently does, apparently without consequences). ES
would only accept 'object_fun' and 'shape_fun'
functions for NPCs, eggs and weapons. And UCC would
require/force such functions to be called in CALLE
form (supplying the current itemref if needed and
maybe issuing a warning) and prevent all other
functions from being called in such a way.

    What I have come up for the declaration of such
functions is the reason I wrote this message: I am not
sure it is very good.

Specifically, I've had two different ideas:
(1) C++ class-like: prefix functions with something
like "Object::". For example, Iolo's function
declaration in BG could be
    extern Object::Iolo 0x401 ();
while the function for keys would be declared as
    extern Object::Key shape#(0x2D3) ();
and likewise for their definitions.

(2) Something along the lines of "shape#" construct;
maybe "object#", as in:
    extern Iolo object#(0x401) ();
This has the advantage of not requiring changes to
declaration/definition of shape functions.

    Which one do you prefer? (1), (2) or neither? I
myself am tending more towards (2), but welcome
suggestions.

    Later,

-- 

Marzo Sette Torres Junior
ma...@fi...
ma...@ya...
ma...@ta...


       
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow