World: r3wp

Series in rebcode are offset-1 based like normal (except image positions 
in DRAW). Would it be a good idea to make them offset-zero based 
in rebcode? Example: if I wanna read a pixel value at a certain position 
in REBOL, I could write:
image/1
or
first skip image position
(If position was 0x0, I'll get the first pixel.)

If I pick an image in rebcode at offset 0, I get an out of range 
error. It's a tough decision, but what seems most 'correct'?

Why chose?
1-based: pick x s 1
0-based: pickz x s 0

Rebcode supports both.

LOL thanks! :-)

Oldes, after some testing, it seems that to-integer always acts big-endian. 
As long as that is predictable, cool!

I am writing int-to-binary conversions in rebcode that support lengths 
of binary from 1 to 4 bytes, little and big endian. I already wrote 
binary-to-int conversions in rebcode, 16 and 32 bit, little and bigendian, 
before it occured to me to check the behavior of to-integer. I'll 
speed-test the rebcode-versus-REBOL methods for comparison.

I'm writing these functions to figure out how to do Duff's Device 
efficiently in rebcode :)

Here's an example of using something like Duff's Device to do loop 
unrolling in rebcode.


binary-to-int16-be: rebcode [b [any-string!] /local x y l dest offs] 
[
    ; Get the length, bounded
    length? l b
    min l 2
    ; Set the initial value
    set x 0
    ; Switch on the length
    set offs [16 6 2]
    pickz dest offs l
    braw dest
    ; Set the low byte
    pickz x b 1
    ; Add the high byte
    pickz y b 0
    lsl y 8
    or x y
    ; Done!
    return x
]

>> binary-to-int16-be #{0001}
== none

okay, I submited to Rambo wish for better support for binary conversions, 
because I reaaly don't know why I should use image to store integer 
arrays if I want to deal with them in Rebcode

And I sould also write one, which points out, that there is probably 
no image alpha channel support in the rebcode

hmm, there is, but just with signed integers:)

you can access the alpha channel using the 32bit integer vaule in 
IMAGE! array.

AFAIK Carl plans to add vector! datatype so this should help you 
create arrays of integers for fast access from RebCode

Oldes, ouch :(

It turns out that the offsets of branches and the positions of labels 
are calculated from the end of the branch or label statement rather 
than the beginning. This was not clear from the treatment of them 
in the assembler. Fortunately, the principle of the above code stands, 
once you change  set offs [16 6 2]  to  set offs [14 4 0]

There, I've changed all of the code that I wrote that branches to 
numeric offsets. Turns out to not be much, just some hand-calculated 
switch code. Most of my branch code uses labels.

Jaime: "rebcode first priority is speed, according to Carl."

And it is fast, really. Later, when JIT is implemented, it will be 
even faster.

I am just a bit scared, that you guys don't get your answers, or 
chat here with Carl ....

hopefully your requests will not get ignored. Let's suppose Carl 
answers to your requests before final release is freezed ...

Pekr. Believe me Carl is informed by a bunch of us in a private channel. 
The most active proxy and who should receive a lot of praise is Gabriele.

Well, I don't want to be a jerk, so I'm not complaining. Gabriele 
does a great job and even lurks around here when he isn't being vocal. 
We came up with some suggestions and tried reasonable means of getting 
them to the attention of the people concerned. I'm not taking the 
lack of feedback as a bad sign - these are busy people, as are we 
all. If it takes too long to find out whether they have heard us, 
I'll just summarize our suggestions in a post to feedback.

Brian we appreciate your comments, and your summary was posted to 
Carl. You will know soon enough what gets adopted.

yes, Jaime, I can understand it, but from the Brian's answer, you 
can consciously feel, that folks here would deserve some feedback. 
RT Q&A channel stopped working as promissed, folks put their requests 
in rebcode, RT Q&A, Rebol Enhancements group, RAMBO, just to be sure 
they are noticed. So - if RT monitors the situation here directly, 
or via Gabriele the "proxy", then folks here should receive some 
answers imo ... I still hope they will? :-)

ah, posted without reading previous post, sorry, was not neccessary 
then ...

Jamie, Yay!

Petr: I guess that there were not enough questions for this wednesday 
so Carl skipped it. (Just one, from you, and you always ask questions 
anyway. ;)

so we have Doc Friday and Questions Wednesday now? :-)

What would be the best way to implement switch like function in rebcode 
(with many cases - encoding/decoding table)

Oldes, that's a tough one. If you aren't using rewrite rules it's 
easy, if tedious, to count offsets like I did above. The last code 
I posted here used a switch statement:
    set offs [14 4 0]
    pickz dest offs n
    braw dest

is sort of like switch(n). The  selection of the right offset to 
branch to can be as simple as that or as complicated as you want.

If you are using rewrite rules you can't count offsets because the 
length of your code can change with every rewrite.

Is it possible to declare the distance between two labels as data?

I still do not understand what does the braw :(

rc: rebcode[][
 seti v 2
 braw v
 probe 1
 probe 2
 probe 3
]

(sorry, on the phone, brb)

so it skips over number of the rebcode words

yes. but i dont know how to do arithmetices with labels

.

isn't this bug:

rc: rebcode[][
	setd pi 3.14159265358979
	print pi
	setd freq pi
	print freq
]

will print out ?unset? instead of freq == pi

No, speedup.

rc: rebcode[][
print pi
	setd pi 3.14159265358979
	print pi
set freq 0.0
	setd freq pi
	print freq
]
rc

setd test only for decimal, it does not change type otherwise.

pi is already a decimal..

exactly as Volker said: if FREQ is not a decimal!, you cannot use 
setd freq ...

ok, thanks

Oldes, when you use the branches other than braw, any label word 
targets are converted to literal number offsets, with the offset 
calculations being performed by the assembler. On the other hand, 
the target word of the braw branch is looked up at runtime, so you 
need to assign the offset to that word yourself, usually through 
a lookup table like I specified above or through calculations.

Would be nice if those tables could be build by hand. is it possible 
to access them for calculations?

Volker, the problem with declareing the distance between two offsets 
as data is that the assembler doesn't currently have any way to even 
get those offset values as data. That is what my HERE directive proposal 
does. You have to do this kind of thing in the assembler, because 
until the rewrite rules are done operating the offsets can't even 
be known.

But the assembler knows this values internally and could be extended?