World: r3wp

This is just one single test using only a few of the available instructions. 
To have a better view, more tests are needed. I made a similar loop 
in C, compiled it with gcc, and it runs around 6 times faster than 
the pure rebcode version. Initially I won't call rebcode slow, but 
not blasting fast either.

and R3 rebcode si going to be even slower ....

There's something wrong with my compare with a 1MHz 6502. I counted 
the number of cycles in the inner loop and found 17 cycles. A 1MHz 
6502 can then do 1'000'000 / 17 * 40 = 2'352'941 loops in 40 seconds. 
But the BeebEm emulator made 16.7 mio. loops in that time. It should 
have taken 285 sec. So programming in rebcode is more like a 107 
MHz cpu in this test.
(It's probably not correct to measure it this way.)

Rebcode is a higher-level language than 6502 assembler. Perhaps a 
peephole optimizer can rewrite your generated rebcode into better 
equivalent rebcode.

Geomol, i had a look on your emulator code, i think perfs could be 
improved if you delay the update of all flags only when they are 
used.

Good idea! Do you have previous experience with emulators like this, 
because I have none.

in fact the engine is very similar with the z80 one, i think we could 
make a meta-emulator using external data-sheets (one for 6502, one 
for Z80)

i' made a Z80 emulator using rebcode (not complete), you can see 
it in galaga.r on rebol.org

Ah, that was you. Someone mentioned that one lately.

ah BrianH, i remember that you made the same proposal for my z80 
emu (peephole optimzation)

hard to do

interesting to do on ROMs (static analysis before to launch the code) 
but not valuable in RAM because the code can be modified

Steeva, about flags: e.g. the zero flag Z (bit 1 of P). In stead 
of that I set it each time A, X or Y become zero, I could save any 
of those (A, X or Y) in a variable, and then test on that var and 
set the flag correctly, if and when the flag is actual used. Is that 
what you mean?

and limited because on 6502 for example, many branchements are calculated 
(not statics)

yes Geomol, it's that

Flags are calculated on the last accumulator value if i don't do 
mistakes

ok. One optimization, I consider, is to cross-compile 6502 opcodes 
to rebcode, instead of emulating the 6502. That won't work with self-modifying 
code and branches will be a problem. So it's hard, but I think, it 
might work.

in theory

i give you an example with the TAX opcode

; updating flags in real time

label TAX
seti X A
eq X 0
either [or P 2] [and P 253]
seti i X
and i 128
eq i 128
either [or P 128] [and P 127]
bra continue

;  delay the calcul of flags

label TAX
seti X A

or maskA (2 + 128)     ; remember that we have to recalculate zero 
and negative flags using A, but don't do it now
bra continue

Thanks!

you got the idea ? ;-)

Yup! :)

did you think that using PC as an offset (integer) instead of as 
a serie could be faster ?

I should do a test before saying that

I didn't consider much in deep actually. It can be improved, I'm 
sure. :)

anyone happes to still have a rebol/core binary with rebcode functionality 
archived somewhere?

it's not in the download section of rebol.com anymore ?

ah, got it: http://www.rebol.net/builds/042/rebview1350042.tar.gz

resp. http://www.rebol.net/builds/031/rebview1350031.exefor windows