World: r3wp

skip str 2

that's the same error

that was just a quick example

And other thing is, that I'm still missing better binary support

for example:

>> to-integer #{FF00}
== 65280
>> x: rebcode[][set b #{FF00} to-int i b print i] x
== 0

that's no good:( I cannot use rebcode to speed up any from my RSWF 
dialect functions as all of them are base on dealing with datatypes 
like UI16 UI32 SI16 SI32, FP and other which simply Rebol do not 
support:(

Are deciding that REBOL is bigendian? What about when it runs on 
x86 machines?

what about to add some options switch?

if I want to make binary structure, I now what binary type it is

and I want to make binaries all the time:(

event in the UTF8 you can specify if it is bigendian in the first 
bytest of the text

I tend to use struct! for that, when available. That is what I suggested 
struct! in REBOL/Core, and they agreed but haven't implemented it 
yet. I'm hoping for 2.7.0 :)

Me as well, but that is only for signed integers

Most of the time I have to use these ugly functions:

ints-to-sbs: func[

 ints [block!]	 "Block of integers, that I want to convert to SBs"

 /complete l-bits "Completes the bit-stream => l-bits stores the nBits 
 info of the values"
	;/maxb mb
	/local b b2 l bits sb
][
	ints: reduce ints
	max-bits: 0
	bits: make block! length? ints
	foreach i ints [
		;b: enbase/base load rejoin ["#{" to-hex i "}"] 2
		b: enbase/base head reverse int-to-ui32 i 2
		b: find b either i < 0 [#"0"][#"1"]
		b: copy either none? b [either i >= 0 ["00"]["11"]][back b]
		;insert b either i >= 0 [#"0"][#"1"]
		if max-bits < l: length? b [max-bits: l]
		append bits b
	]
	foreach b bits [
		if max-bits > l: length? b [
			insert/dup b b/1 max-bits - l
		]
	]
	either complete [
		sb: int-to-bits max-bits l-bits
		foreach b bits [insert tail sb b]
		sb
	][	
		bits
	]
]

int-to-FB: func[i /local x y fb][
	x: to integer! i
	y: to integer! (either x = 0 [i][i // x]) * 65535

 fb: rejoin [either x = 0 ["0"][first ints-to-sbs to block! x] int-to-bits 
 y 16]
	if all [x = 0 i < 0][fb/1: #"1"]
	fb
]

Unfortunately I'm not able to do it in Rebcode:(

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.