World: r3wp

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.

agreed, thtat is sufficient.

Sorry, to-dec a a ...

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.

be brief. use the first one like now

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.

3 is not rebol. add/i add/d if you really want that. the little extra 
letter works best for me.

as in 2)

The third makes the typing distinct from the opcode, and that could 
be an advantage when future opcodes are added later.

2

For instance, if you had set.i mean set integer, seti.i could mean 
set integer indirectly.

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.

3) come from asm68k that looks like that.

And rebcode, as a byte-code, is near ASM (even if more powerfull, 
ie: block!)

Paths are much bigger to store, meaning memory and lookup overhead. 
They are blocks you know, with different syntax.

dot looks like a space and spaces are veryimportant in rebol-layout. 
i would not use that.

A period looks like a space?

I know also that performance depends on needed volume. both processing 
steps and codeamount are small.

looks close to it. its very small.

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.

in rebol most signs fill the space  if .. [ ..], not  if .. { .. 
}. a-word, not a_word. i like that

Maybe 2 or 3 times slower.

sure, but i can change the other way. why start with a bad opcode 
and replace it with a bad, when i can have it the other way around?

Hey, Volker's got it! Use version 3, but call them add-i, sub-i, 
...

That's the REBOL style.

one of the "bad" should be good", but you understand what i mean.. 
;)

3b is better than 3, but still not necessary.

Part of what makes rebcode so fast is that it doesn't do path lookup 
for its operations. You would make it drastically slower if you changed 
it so it does.

DideC: Add a choice.
4) INTEGER add-i mul-i div-i ... / DECIMAL add-d mul-d div-d ...

there would not be much path-lookup, only on compilation. i dont 
know how rebcode works internally, i guess the words are not stored 
as rebol-words finally?

Using paths is not in the question (answer is no).

Internally, the opcodes are words that are bound to the system/internal/rebcodes 
context by the assembler. Then those bound words are used as an index 
internally to the implementation. No evaluation is involved at runtime.

That is according to Carl's writings so far.

DideC, I'd prefer the second or fourth (with -) choices.

REPLY TO URGENT NOTICE:  i propose i.add, i.mult, i.div etc... this 
way we include to rebcode a some object like stuctrure but only applayable 
on fonctions /operation names 

this allow us to not mistake betwin rebol/core  funtions and rebcode 
ones. As type take a  !  in rebol syntax we can use i!add i!mult 
i!div i!sub etc... I think this syntaxe would be really attractive 
for coders abit to object language. I.add or i!add is directly understable 
i -> interger add -> the operation applyed to integer! args ...

rebcode uses a full value for an opcode, 16 bytes? not something 
comprimized? if so, that works badly with cache-prefetch. But i agree 
the opcodes should have word-based names. so 2 if we think we stay 
with int/decimal, 1-2 others, 4 if we think we get special code for 
more types than the alphabet has letters.

shadwolf, please no ! in opcodes. That would be against the minimal 
use of the shift key that directs the syntax of hte rest of REBOL.

lol and i->add lol

in rebol function comes first, then arguments. no oops-syntax here.

too C like .... it's rebol  dude not python !!!

I prefer the opcodes first, before their typing.

<---- dude @_@

I prefer 1, as it is now. Keep it short. I think of the decimal variations 
like the normal ones, but with some extra (decimal has better precision 
and gives you decimals, so it's something extra than integer). It 
also take up more bits -> more bits, longer name. That's the way, 
I think. Also reminds me of C, where 10 is a short integer, and 10L 
is a long integer. (Not the same, but kind of the same thoughts.)

REBOL is not an object-oriented language shadwolf.

and addi minimizalkeystrokes too. :) and since Carl has choosen that 
way, but before he had addd etc, i opt for the smallest adjustion.

i clash with seti and such. then we should make everything integer, 
and have a setv for any-value.

hum and for decimal! value 1) gives addd
.... not clear enought i think

I never liked that integers were treated like a default value in 
C. This leads to its typing problems, excessive casting, character 
as integer, ...