I'm sorry, it's late for me
At the time you wrote I was already in bed
I only had to change "alloc" instead of "malloc" and it works perfectly (I am not quite useful at coding)
with the same code (and the same openmsx) it gives 108 ticks (at 50 Mhz, MSX2 NMS 8245) ... slow?
at 50 Mhz sounds a bit slow
...perhaps tomorrow I will be awoke
don't worry, MSX can wait
Hi again
I said I would try on a real MSX, and ... of course I do it
I've used the same code on ML-G3, at 50 Hz, and the result was 111/112 ticks (a bit more than two seconds for 4095 moves) so, it is not good for BDS-C
anyway, if you want to try another code, I will be glad to do it
see you
sounds to me like IX points to stack base of current function and is a pointer to a pointers list containing stack bases of underlying functions.Correct. But that has nothing to do with debug support. It's a normal way of setting up re-entrant code.
What you could try is to make all variables static, with the exception of the ones in storre(). Static variables are not created on the stack (and thus accessed via IX/IY), but in the bss segment.
[edit]Ah, wait there are no local variables in the code, except for a few in the main() routine. Then my last suggestion was not very helpful Then the best thing to do is to get rid of the recursion![/edit]
IIRC 65 ticks at 60Hz and 53 ticks at 50Hz are already obtained with full optimization (I have to verify about debug info, but usually I let them disabled by default)
The use of IX and IY is linked to the use of variables on the stack and on the heap respectively.
As the code is recursive, even if parameters are passed using z80 registers, their local istance is allocated on the stack and accessed by IX.
anyway, if you want to try another code, I will be glad to do it
see you
Hi Josb,
what about continuing our experiments with this comparison... BDS-C vs ASCII-C part two ;)
sounds to me like IX points to stack base of current function and is a pointer to a pointers list containing stack bases of underlying functions.
Correct. But that has nothing to do with debug support. It's a normal way of setting up re-entrant code.
Ah... I supposed that top speed optimization and no debug support could lead to a very different strategy in cpu registers usage... in our example no more usage of IX but:
- a sequence of POPs if stack frame is small
- LD HL,stack_frame_size
ADD HL,SP
LD SP,HL if stack frame is large enough to make POPs not efficient
... but it's just a my supposal :P
Generally speaking, every time there is no need of using the stack for parameter (chars, pointers and integers are passed using cpu registers wherever possible) and no need to allocate auto variables, the Hitech C does not neither initialize the IX and IY registers
Anyway, in our example, due to recursion, it cannot adopt the above optimizations
HI guys.
Anyone can send this material to me? Thanks.
julio_lemos at yahoo.com or
julio.lemos at gmail.com
- bootDisk
- msxC-1.10
- msxC-1.20
- msxC-Lib
- msxC-Manual
- msxC-Utils
Thanks in advanced,
Julio Cesar
who is the winner in speed?
who is the winner in speed?
Which test are you referring to?
who is the winner in speed?
Which test are you referring to?
the Hanoi tower sample