World: r3wp

Also note: To see the current valid opcodes and their arguments, 
type this:
      print system/internal/rebcodes

This object is actually used by the assembler.  And, many opcodes 
include comments to explain what they do.  A good reference.

Hint: try to set:  rebcode*/debug?: yes   if you are creating rewrite 
rules. (note, produces a lot of output)

I have only been discussing higher-level issues to the extent that 
they would affect the semantics of the lower level. At this point 
the only such concern I've had is the problem of adding variables 
in rewrite rules. This would be required by compilers, something 
perhaps a little too high level to consider for doing with rewrite 
rules. On the other hand, this variable addition might also be required 
by peephole optimizers, something that seems very appropriate to 
add on the level of the rewrite rules. This is, of course, up to 
you.

Carl, love the new Apply, thanks!

So, Brian - if you have any suggestion of how to improve low-level 
to make it compilable later in higher-level, just suggest! :-)

Great, I mention that ADDD and the like can take integer arguments 
in the second parameter but the syntax doesn't allow it in version 
10 (and request a change in declaration), and now in version 11 the 
opcodes don't take integer parameters any more. I hope that change 
resulted in a good speedup - it would certainly be easier to JIT.

so you think rebcode will be "compillable"?

AFAIK, ADDD (etc.) can only take decimal! arguments. it does not 
crash with integer!, but it does not work either.

What is assigned to the word argument to BRAW: A relative offset, 
an absolute offset into the block, or the word value of the label 
to be branched to?

i think, relative offset (like bra)

Gabriele, last version adding an integer to a decimal with ADDD worked 
if the integer was assigned to a variable. I mentioned it here, requested 
the syntax check reflect this for literal integers as well. This 
version integers don't work. I'm not complaining, just updating since 
I mentioned it before.

Relative offset seems to be the least useful for use with computed 
goto. With absolute offset in the block you could have each label 
word be assigned their offset as a value, and then assign those values 
to other words to be branched to later. If the offset is relative 
then you have to recompute the offset for every branch statement. 
This is quite awkward for more than one branch statement.

strange, when i fed integers by mistake i always got very strange 
results :)

i'll ask Carl if the offset is relative or absolute.

I've seen computed gotos used by threaded interpreters and that ProtoThreads 
package among other circumstances, so I'm quite interested in their 
use here.

They can be a great way to speed up state machines, implement switch 
statements and such.

(I mean C-style switch statements)

Carl (or Gabriele), is that formula you gave for LOG-2 the way it 
is implemented in the LOG-2 native? I thought a binary logarithm 
would have a more efficient implementation on a binary machine.

I've been using it to calculate IP subnets and the like.

binary logarithm: you can spare one multiplication, that doesn't 
look like a big difference

Remembering the constant could be :(

I do not understand

do you mean that it is a problem for you to remember the constant?

Still, it would surprise me if that is how C has to calculate a binary 
logarithm. I thought there'd be an instruction or something. Spoiled 
by CISC processors I suppose.

Actually, there is a lot of things I have to remember and adding 
long numeric constants to the list would be a problem. That isn't 
sufficient justification (to me) to add another opcode. Greater efficiency 
would be, as would making the log-* set as complete as REBOL's natives 
are to save on silly questions like mine in the future :)

(Another thing to remember: Grammar-check my posts - I can't fix 
them later)

you don't have to remember it...

log-e 2

>> log-e 2
== 0.693147180559945

See, that solves one problem.

log base b (x) = log (x) / log (b)

I still think the native version would be more efficient than that. 
Base-2 logs help a lot with binary to decimal conversion (or was 
it vice-versa?). I may be wrong here though...

one opcode more or less should not be the difference,no? So why not 
to add it if found usefull? :-)

Wasn't there a log2 instruction in x86 before the floating-point 
processor was incorporated onto the main chip?

Floating point division on x86 is quite slow in comparison to integer 
operations, sometimes more than 10 times as slow.

(depending on the cpu)

and log2 does help with it? Just asking - most of the time I dunno 
what you are talking about here :-)

you don't have to use division: (log-2 x) = (log-e x) * (log-2 e)

They used division in their above solution.

Adding a mul instead of a div isn't such a big deal, in comparison.

I think, that everyone knows, that division by a constant can be 
replaced multiplication by its reciprocal, which is a constant too 
:-)

So your example would be (log-2 x) = (log-e x) * (1 / (log-e 2))

especially since e isn't defined as a constant in REBOL, and log-2 
isn't a rebcode opcode so we can't use it here.

of course you can, just define: log-2e: log-2 e

log-2e: log-2 exp 1

Ah, exp 1. It has been a while, I had forgotten.

actually, it may be of a value to have: e: exp 1

I suppose those "constants" could be calculated ahead of time and 
just inserted in the code as local variables. Well, that solves the 
functionality and memory (mine) problems. Still, it seems like C 
libraries and such must have a better way of doing this - it seems 
a bit inefficient.

On a binary machine, wouldn't log-e and log-10 be implemented on 
a lower level on top of log-2, instead of the other way around?

I'm probably just misunderstanding logarithms.

i don't think there's any way to implement log-2 any faster then 
log-e