[GEM Development] GEM/XM VDI source

[Ben A L Jemmett]

Quoting Lyrical Nanoha <LyricalNanoha at dosius.ath.cx>:
> I'm only a mediocre programmer but do you think it's possible, now that 
> the XM source is complete, to merge XM into the current dev GEM?

There's one slight problem with the XM source as it stands: we can't
successfully build the AES.  It compiles and links OK, but then crashes as the
Desktop starts up.

However, John's communications yesterday inspired me to dig up my old VMware
session where I'd been working on GEM/XM back in 2003 (shortly before I found
myself a girlfriend, so I got distracted halfway through *grin*).  I've spent
this evening poking around a bit, and tracked the crash down to a stack
overflow.  Initial experiments with upping the supervisor stack size (STACK_SIZE
in STRUCT.H) to 768 words got the Desktop to start and work for a while, and
further debugging shows every trip into supervisor mode and back leaks one word
of stack space:

[Shutting down the Desktop ends with...]
AES CALL, PID = 0, OPCODE = 104, SPSUPER = 35f6
AES done for PID 0 opcode 104 with 0x1 [spsuper=35f6]
AES CALL, PID = 0, OPCODE = 123, SPSUPER = 35f4
AES done for PID 0 opcode 123 with 0x7b [spsuper=35f4]
AES CALL, PID = 0, OPCODE = 30, SPSUPER = 35f2
AES done for PID 0 opcode 30 with 0x1 [spsuper=35f2]
AES CALL, PID = 0, OPCODE = 19, SPSUPER = 35f0
ev_multi called for process 1 [state 0].
Entering body of ev_multi.
exec return, pid=0, ret=0
QUICK OUT

Just going to do a bit more poking around and see if it's getting bumped by a
word before it enters the routines in GEMSUPER.C or before it completes the
return.  Hopefully the notes left in the source will be enough to work out what
should be going on.
-- 
Regards,
Ben A L Jemmett.
(http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/)

----------------------------------------------
This mail sent through http://www.ukonline.net