[rebcode] Rebcode discussion
No group for recode found so I started this one.
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.