From: Mike H. <mik...@aa...> - 2007-11-30 08:03:45
|
Hi Nao, > Bingo! :-) Ah, I like it!! As you say, memory is cheap these days, so we can increase these amounts with no problem. Also your code change below will stop the exbuff crash, at least -- but we could also make it give an error. Anyway there's plenty of time before the next release. Cheers, Mike. > > In the case of MachO 32bit PowerMops, > at the 21st file the __exbufPtr is 707680, while the upper limit of > exbuff > is 707684 by calculation. One "NEED" seems to take 48 bytes in exbuff, > so > the 22nd NEED should overrun the buffer. > (As for CFM PowerMops, the buffer resides at higher place, but the > condition > is similar.) > > As a trial, I set a turning point to __exbufPtr: > At the last part of the definition of (EX-GEN) in file "cg7" > [code] > : (EX-GEN) ... > > ... > svMC -> modCode svMD -> modData \ restore module base addr regs > svExBufPtr dup \ 11/30/07 ns > exBuff 512 + > IF drop 0 THEN \ 11/30/07 ns > -> __exBufPtr \ and old exBufPtr > ?stack > ; > > > [code-end] > > Then with extended return stack 30 iterated NEEDS don't cause crash. > From the value of __exbufPtr in loading, I think 50 iterated NEEDs will > be ok. > > > However, return stack size will be another problem. > 50 iterated NEEDs will require about 3500 cells for return stack at > least > (the size is 1600 cells, at present). > But compared with normal stack frame size (typically in C), > it will look very small. > Since return stack reside on heap, its expansion will not influence > the size of PowerMops executable file. > 100kb (25600 cells) for return stack may be cheap nowadays. > > > > Sincerely, > Nao Sacrada --------------------------------------------------------------- Mike Hore mik...@aa... --------------------------------------------------------------- |