World: r3wp
[rebcode] Rebcode discussion
older newer | first last |
BrianH 23-Feb-2007 [1947] | Try it. My memory of the behavior of SETT on 0 is a little sparse. |
Steeve 23-Feb-2007 [1948] | i don't see any gain |
BrianH 23-Feb-2007 [1949] | It would be faster than a compare. |
Steeve 23-Feb-2007 [1950x4] | i use 3 instructions to test a bit in all cases |
should have: bit 7 [do the job] | |
:-) | |
missing the operand | |
BrianH 23-Feb-2007 [1954] | I'm curious, did you check SETT to see if the value 0 sets the T flag to false? |
Steeve 23-Feb-2007 [1955x3] | no sorry , i test now |
it works | |
anyway it's not really a problem, i never perform such tests | |
BrianH 23-Feb-2007 [1958x2] | Cool. So SETT can replace ZERO? and NONE?, which otherwise don't have rebcode equivalents. |
Or rather NOT ZERO? and NOT NONE?, but the effect is the same. | |
Steeve 23-Feb-2007 [1960x2] | i don't understand usage of ext8 and ext16 |
perhaps, they should be usefull for me | |
BrianH 23-Feb-2007 [1962x2] | Sign extension, so that you can use signed arithmetic on integers that contain values retrieved from 8 or 16 bit data. |
It's so you don't have to do arithmetic on bytes. | |
Steeve 23-Feb-2007 [1964x5] | hum i see |
i think i should replace this: | |
gt.i decal 127 ift [sub.i decal 256] | |
by this: ext8 decal | |
eureka !!!! | |
BrianH 23-Feb-2007 [1969] | Looks like. |
Steeve 23-Feb-2007 [1970x2] | thi code is the macro i use the most |
*is in the macro | |
BrianH 23-Feb-2007 [1972] | I wonder how much other code generated by your macros could be optimized... |
Steeve 23-Feb-2007 [1973x3] | not as much as that |
i hope | |
but surely some of them | |
BrianH 23-Feb-2007 [1976x3] | Perhaps some of those and x 255 operations could be put off until the value is written to memory. |
While the values are in the registers, who cares what precision they are internally. | |
It would make the C flag easy to keep track of. Perhaps some of the multibyte operation sequences could be combined. | |
Steeve 23-Feb-2007 [1979] | hum |
BrianH 23-Feb-2007 [1980] | Where it matters you could replicate the overflow behavior on purpose. |
Steeve 23-Feb-2007 [1981] | but you see, the 8bit registers are often combined into 16bits registers, so i should perform AND 255 before to translate them into 16 bit, i'm not sure there is a real gain |
BrianH 23-Feb-2007 [1982x4] | That combination of 8-bit values into 16-bit registers has got to be a common code pattern. Are the 16-bit operations distinct from the 8-bit ones? This is the kind of code pattern that you could combine and optimize. Internally, do you need to have the 16-bit registers be a combination of the 8, or could they be seperate and have their values transfered over if it would be faster? |
Are the 16-bit values loaded in one statement or two? | |
Need there be a difference? | |
It's what the modern processor designers call register renaming :) | |
Steeve 23-Feb-2007 [1986x2] | sorry, disconnected |
not sure to understand what u mean | |
BrianH 23-Feb-2007 [1988x2] | I would have to read your Z80 manual to be sure, but it seems to me that these 16-bit operations seem to be great candidates for opcode combining. It may even be a good idea to have the 16-bit registers be seperate variables internally. |
At the very least you should have seperate macros for 16-bit reads from and writes to memory, rather than a combination of 8-bit ops. | |
Steeve 23-Feb-2007 [1990x3] | but i'm afraid that synchronization of 16bits registers with the 8bits (transfer of values) cause an overhead |
what u gain in one side, u lost it in the other side | |
synchronisation needs more operations | |
BrianH 23-Feb-2007 [1993] | How does that overhead compare to that of doing it the straight-forward way? Remember that every loop of the interpreter is overhead. |
Steeve 23-Feb-2007 [1994x3] | moreover , i'm not that writing/reading a word in memory is more faster than to write/read 1 byte 2 times |
*i'm not sure | |
i explain | |
older newer | first last |