World: r3wp

Never mind, I will wait, maybe one day it will come.

In the meanwhile, ou can do it yourself:

pickz hi b 0
pickz lo b 1
lsl hi 8
add hi lo
skip b 2

for bigendian

Better yet, change the add to or, it should be faster.

Less likely to cause problems with large unsigned numbers too, it 
you are implementing unsigned int32s.

What are you trying to do with that function? I'm having a little 
trouble understanding its purpose, though I seem to get most of the 
parts.

Oldes - put it in RAMBO - or just guys let's decide what channel 
will we use for last-minute suggestions! Remember - if you don't 
get your desired functionality now, your wait might be quite long 
...

And posting your code here I can guarantee you, that Carl will not 
scroll thru them ;-)

The code I've posted here recently is for you all. I've posted the 
request code to RAMBO.

My suggestion goes mainly to Oldes now, who wishes to have rebcode 
supporting binary datatype and ability to switch endianness .....

In rebcode, the pick opcode can be used with both binaries and images. 
If you have an image, it's rgb values can be reached as image/rgb, 
and that is a binary serie. Each value is 0-255, and you then have 
to multiply the index by 3 and use an offset to reach the red, green 
or blue component of a pixel. It's also possible to work on the image 
as an image! datatype, and then it's not necessary to multiply the 
index by 3, as the full pixel is addressed, but the value isn't a 
tuple, as we're used to, but the binary version of a tuple as an 
integer. E.g. green (0.255.0 or #{00ff00}) is 65'280.


Now to my questions. Are there shortcuts or tricks to make it easier 
to work with pixel-valus in rebcode? Should it be possible to use 
tuples, or will that slow things down too much? What do others do?

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
]