World: r3wp

First question: what 'instructions' are implemented in rebcode ? 
Seems like series are not implemented.

Second question: Rebcode supports integer math only. Any chance of 
FP math?

Series traverse seems to work, but I'm not able to pick, poke or 
change something

FP is likely to be implemented in the future

bear in mind, it is still very experimental right now.

No problem, I understand

And series? What is implemented

only string and binary so far... and images

I see, thank you very much.

Kru:should this group be under Rebol ?

Alan probably yes

has this only been tested yet on x86?

I find it interesting that the assembler part of rebcode is implemented 
in REBOL code that is provided, and can be improved by us. It has 
been quite fun so far :)

Henrik: AFAIK Rebcode has been tested on x86 only, but it is designed 
to be crossplatform so this shouldn't be an issue.

New version of rebcode posted here: http://www.rebol.net/builds/031/rebcode2.zip

old demos don't seem to work though ... something has changed probably 
...

The VM opcodes have been modified, so new demos will be needed.

Ah, there's decimal math...that's really great

braw:  Computed goto?

Does the | integer! in the rebcode spec refer to an argument type 
or a return type?

If it is a return type, does the operation still modify its first 
argument when the return value is used?

Given the addition of the set, seti and setd opcodes, does the set-word! 
notation for setting variables still work?

The new syntax of do in the tests and opcodes is not reflected in 
the treatment of do in the assembler.

The new do seems to take a word before the block, presumably to catch 
the return value, but the assembler stage of removing the do blocks 
for binding doesn't take that word into account.

If the braw opcode is a computed goto, does this mean the label words 
can be referenced to get their offset value? Or is this just for 
compilers?

I would LOVE to add a syntax check to the assembler, if only I knew 
the current syntax. I also have an idea on handling of nested labels 
better.

The syntax check would allow such errors to be caught at rebcode 
creation time, rather than have it just crash REBOL with no error 
message at runtime.

Can you branch out of a block to an enclosing block?

The assembler comment says no, but it hasn't been updated to reflect 
the other changes in syntax for test 2.

Sorry for the mass of questions, rather than just testing for myself 
:)

I have to go elsewhere for a while, and can pick up the discussion 
later...

Do has been fixed.  Also Gabriele has been working on better assembler.

BRAW - yes computed goto.

BTW, code for everything is in system/internal object.

We will be doing another update very soon with new asm and various 
fixes.

is there any particular design you are going for yet? as in when 
we can expect to see a fixed feature set?

Instruction set redesigned for best performance. That is #1 goal, 
not the look of the opcodes.

Floating point has now been added, as well as quick access to normal 
math lib funcs (sine, log, etc.)

Carl - that is fantastic ... I am just curious what was the reason 
we got rebcode? We talked about VM for years and suddenly it is here. 
Working with pixels is fast now :-) Is it just that you really enjoyed 
your vacation or is there any customer wish behind it? :-)

The problem now is that the VM is getting close to optimal, which 
is making it very difficult to deal with the CPU oddities like pipeline 
and nonpredicted branch flushes, etc.

Hi Pekr: true reason is the move to better support OSX, which is 
on PPC. I wanted a VM so people could make faster funcs but without 
problems on other CPUs.

Any speedup/slowdown because of redesign? Still the same levels of 
performance as you posted in your blog?

Yes, about the same.  Depends on if your CPU is hyperthreaded.  The 
problem there is that removing instructions (making the opcodes more 
efficient) actually has slowed it down a bit (like here on my system).

There is one big change yet to make: security.

to better support OS-X? So Internally you will switch to VM? Well, 
sorry for such questions, it is not just my level of knowledge - 
too low level :-)

So now someone can start thinking of writing JIT for rebcode, right? 
:-)

btw - would it (technically) make sense to provide interface to internal 
representation of datatypes? Dunno, just very primitive question, 
maybe it can't even technically work that way, but I thought that 
using technique as a rebcode, theoretically we could produce our 
own natives. Think of 'remove-each as an example. You had to provide 
us with one. I thought that if it would be possible to access e.g. 
block from within the rebcode, do some operations, that such functions 
could be done. Is that nonsense? :-)

Maybe we could rewrite some mezzanines then and have them more fast, 
but as I said - I am not even sure I know what I talk about :-)

I've though a lot about internal access to datatypes, but the problem 
is that they change. For example, the 2.7.0 core kernel changes the 
internal id's for 80% of the datatypes.

So, the only way to do it would be to isolate them (datatype identifiers) 
via a lookup table.

wasn't it planned for so called language plug-ins some time ago?