r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[rebcode] Rebcode discussion

DideC
25-Oct-2005
[789x3]
Actually...
opcodes for integer math are :
	-add, mul, div, min, max, abs, ...
opcodes for decimal math are :
	-addd, muld, divd, mind, maxd, absd, ...
Would you prefer integer opcodes to be :
	-addi, muli, divi, mini, maxi, absi, ...
or not ?
(quick answer required!)
Volker
25-Oct-2005
[792x2]
yes.
i typed it that way the first few times.
BrianH
25-Oct-2005
[794x2]
Speaking as someone who generates as well as wwrites rebcode, I would 
say yes. This frees up the non-typed opcodes to be rewritten with 
their typed equivalents by a type inferencer.
It also makes their typed nature explicit, and establishes the convention 
of <opcode>i for integer-specific opcodes, which will come in handy 
later when we add more (like picki/pokei).
Volker
25-Oct-2005
[796x2]
Maybe it makes it sense to have generic math too, then we could add, 
sub etc too. Not sure, but if interaction with rebol is closer and 
we deal with rebol-created blocks?
would keep that option open.
BrianH
25-Oct-2005
[798]
Generic math is slower....
Volker
25-Oct-2005
[799]
Yes, but a typecheck and a branch and a conversin even more.
Tomc
25-Oct-2005
[800]
I would prefer the explicit interger opcodes
DideC
25-Oct-2005
[801]
(no chance some of you change a bit his color : you look the same 
all three)
BrianH
25-Oct-2005
[802]
Volker, the typecheck can be done by the programmer, or a type inferencer, 
either way statically. When rebcode gets a JIT those typechecks get 
put right back to implement generic math, because the real machine 
won't have it.
Volker
25-Oct-2005
[803]
if i want a generic sum, people feed [ 1 2.5 3 ], it would be faster 
in rebcode, so makes sense. with hand-typecheck it would be slower. 
I guess its to rare to worry about, but i would keep the option.

but main reason is, its easier to remember, set seti setd add addi 
addd would be first thoughts.
BrianH
25-Oct-2005
[804x2]
When you hand-typecheck, you usually do it at programming time, not 
runtime, so it's not so bad.
(I just read the names :)
Volker
25-Oct-2005
[806]
i write support for rebol, and so it should be easy to pass data.
Tomc
25-Oct-2005
[807]
Didec: on linux we cannot change colors
DideC
25-Oct-2005
[808]
Ah, didn't know that. Pooor guy ;-)
Volker
25-Oct-2005
[809]
it worked, see dotgroup.
Tomc
25-Oct-2005
[810x2]
I get an error report requester to send feedback to safeworlds
ahhh but it did change
BrianH
25-Oct-2005
[812]
(I'm just lazy)
Volker
25-Oct-2005
[813]
We managed to give you a different color than us. :)
Tomc
25-Oct-2005
[814]
but then ...  "Multiple Errors, Altme must quit now"    <blink>
DideC
25-Oct-2005
[815]
If change is done to add the "i" on add and others, it will also 
be the case on comparison operators.
eqi, gti, ...
BrianH
25-Oct-2005
[816x3]
I was hoping so.
Did you see that idea in Rebol Enhancements about picki and pokei 
for bytewise access to integers?
I get generic add by doing this:
    to-dec a
    to-dec b
    addd a b

You can skip one or both conversions if you can trace the type flow 
and be sure of the data types of the arguments.
Volker
25-Oct-2005
[819]
agreed, thtat is sufficient.
BrianH
25-Oct-2005
[820]
Sorry, to-dec a a ...
DideC
25-Oct-2005
[821]
Your opinion is require.


Some opcodes exist in double due to specific integer or decimal value 
handling.

What would be your preference on opcode naming ?

Choice are :

1) INTEGER add mul div min eq gt gte ... / DECIMAL addd muld divd 
mind eqd gtd gted ...

2) INTEGER addi muli divi mini eqi gti gtei ... / DECIMAL addd muld 
divd mind eqd gtd gted ...

3) INTEGER add.i mul.i div.i min.i eq.i gt.i gte.i ... / DECIMAL 
add.d mul.d div.d min.d eq.d gt.d gte.d ...

(Today rebcode is 1)

It concern math, logic and comparison opcode.
Henrik
25-Oct-2005
[822]
be brief. use the first one like now
BrianH
25-Oct-2005
[823x2]
I prefer the second, although the third has merits.
The second is brief and consistent. The first is just brief, half 
the time, and confusing.
Volker
25-Oct-2005
[825x2]
3 is not rebol. add/i add/d if you really want that. the little extra 
letter works best for me.
as in 2)
BrianH
25-Oct-2005
[827]
The third makes the typing distinct from the opcode, and that could 
be an advantage when future opcodes are added later.
Tomc
25-Oct-2005
[828]
2
BrianH
25-Oct-2005
[829]
For instance, if you had set.i mean set integer, seti.i could mean 
set integer indirectly.
Volker
25-Oct-2005
[830]
if we go that complex, i go for extra field or pathes. for now rebcode 
is confusing enough, then at least the keywordsshould be easy.
DideC
25-Oct-2005
[831]
3) come from asm68k that looks like that.

And rebcode, as a byte-code, is near ASM (even if more powerfull, 
ie: block!)
BrianH
25-Oct-2005
[832]
Paths are much bigger to store, meaning memory and lookup overhead. 
They are blocks you know, with different syntax.
Volker
25-Oct-2005
[833]
dot looks like a space and spaces are veryimportant in rebol-layout. 
i would not use that.
BrianH
25-Oct-2005
[834]
A period looks like a space?
Volker
25-Oct-2005
[835x2]
I know also that performance depends on needed volume. both processing 
steps and codeamount are small.
looks close to it. its very small.
BrianH
25-Oct-2005
[837]
You can change path opcodes to dots with rewrite rules if you prefer. 
Opcodes are supposed to be static. The whole interpreter would have 
to be changed to make opcodes paths, and it would be much slower 
after the change.
Volker
25-Oct-2005
[838]
in rebol most signs fill the space  if .. [ ..], not  if .. { .. 
}. a-word, not a_word. i like that