AltME groups: search

that's because mouse events have higher priority than time events 
and the scene is refreshed only when time event occur. If you move 
your mouse, no time-events are generated.

and with bug in my english as well: goot = good :(

But I think the accuracy is fine if you are doing animations and 
effects based on atan2 function - where speed is more important than 
precision

As I work with sound synthesis and 3d graphics I use lot of maths 
so I need rebcode imost of the time :) I had data structures using 
objects, so I rearanged them for now. I wrote it as wish to RAMBO.

You can use 'third, 'get and 'set to turn objects into blocks. only 
from the rebol-side, but maybe it helps a bit.

Kru, you can use apply in or apply bind to get a word bound to the 
object field, and then use setw and getw to get at the values.

Continuing from SDK group: I noticed that cyphre thinks pixel writing 
and reading can be a bottleneck in the current rebcode implementation, 
which is why the native convolve functions in rebol/view 1.3.2 are 
much faster than the rebcode version demonstrated earlier.

By providing ways to read and write RGBA information directly without 
needing to extract and combine them first, rebcode could be faster 
at per-pixel operations.

Any thoughts on how to do this?

I got an email from Carl at one point regarding this issue. I asked 
to have poking of tuples in rebcode. Carl wrote:

Regarding below, tuple poke not supported on images.
But, perhaps 
it makes sense to add that, eh?


As I also see it, adding support for tuple datatype from within rebcode 
is a good solution. Carl is aware of it, it seems, so just *poke* 
him once more and ask for that. It should also work with PICK of 
course (reading pixels).

I'm a bit in two minds about this. Reading is done with PICK, but 
it'll return an integer. So how to make it return a tuple? Something 
like:
pick.tuple result img 1

Not so good, eh? Maybe we need a TO-TUPLE command in rebcode. And 
how will it influence performance? Maybe it isn't such a great idea 
to add support for tuples to rebcode!?

hmm, 'to-tuple is not bad. it's just a graphical interpretation of 
bytes in memory. there's no difference between 16777215 and 255.255.255 
. It's just parser's job.

tick and toke? ;)

Hmm, now I think about it once more, maybe a special PICK isn't needed. 
The internal representation of values, whether they are seen as integers 
or tuples, can be the same. If we name each of the components of 
a 4 part tuple red, green, blue and alpha, the following holds:

integer = (alpha * (2 ** 24)) + (red * (2 ** 16)) + (green * (2 ** 
8)) + blue

What we need, is the ability to tell values as tuples as well as 
integers. Internal they are the same. I would like to be able to 
do this:
poke img 1 16843009
poke img 1 1.1.1.1
pick result img 1
eq.i result 16843009
eq.i result 1.1.1.1

I've made a test of a voxel landscape engine in rebcode. As I did 
it on my Mac, it's written in the version of rebcode found in the 
version 1.3.50 of REBOL/View from around Oct-2005. I haven't tested 
it with the Windows version of View, but I guess, it should work 
with that same version 1.3.50. I first did a plain REBOL version 
and got a framerate of around 3-4 fps (frames pr. second). With the 
rebcode version, I get around 20 fps. The script is found here: http://home.tiscali.dk/john.niclasen/voxel/NicomVoxel.r


I've also made a snapshot here: http://home.tiscali.dk/john.niclasen/voxel/snapshot.png

In case someone is interested in trying the script out, you can move 
around with w, s, a and d.

Computers are strange and difficult to compare. :)

Use w, s, a and d to move around.

Q to quit and F1 to save snapshot.png

Nice job, John!


I have played with it a bit : the keys were not friendly for Azerty 
keyboards ;-)
And I wanted it to fly without "Control".


So the same things, but use Arrows to increase/decrease speed in 
both directions.
do http://membres.lycos.fr/didec/rebol/NicomVoxel.r


You can also try page up/down to change the view altitude, but rebcode 
part is not fully ready for that (can give error if you go too far).

DideC, I just tried your version on my PC. It's cool! :-) Ok flying 
experience, and the elevation is fun too. But code is not completely 
ready for that, as you point out.

I think there's confusion there between face/rate and the fps reported 
by your program. I think I have switched to talking about face/rate 
while everybody else is still talking about your program. I thought 
that Gabriele was probably talking about face/rate. Now I'm not so 
sure :)

can anyone tell me if we can access objects! using rebcode... I read 
the whole document and did not notice any object using examples or 
explanations.  It seems we can, but its not stated explicitely. AFAICT

You can also APPLY the IN native and SETW/GETW the resulting word.

They would be really usefull for editing faces,and other object-based 
REBOL resources... if they are in opcodes, we could expect a big 
speed improvement, even if that meant to "freeze" some aspects of 
the object within the rebocode loop. (JIT compile on demand  ;-)

The variables swapping over are yp and sev - yp is an integer and 
sev is a series..

have tried the same code under rebview1352031.exe and rebview1361031.exe 
but same results.

Ah well. The rebcode VM was the basis for much of my own research 
projects. I would really like to see it return, as I am blocked on 
those projects until I can count on rebcode being there and safe 
to use. As it is, I rarely get to use REBOL professionally, it's 
more of an enabling tool.

REBCODE is AMAZING ...


I am trying to convert a 300+ MB file from little-endian 16-bit Unicode 
to UTF-8. I am pretty sure that all the characters in this file are 
ASCII characters, so I can just discard the second byte (0x00) of 
every 16-bit Unicode character. Beside that, the beginning 2 bytes 
(0xFFFE) need to be discard too. 


In these two days, I wrote REBOL scripts for this purpose in different 
ways, and I suffered in different ways, too. Sometime I got out-of-memory 
error, sometimes I didn't. Even if I didn't get any error, the performance 
would definitely dramatically dropped down after few minutes because 
of the memory issue, I guess. I would take me 30 minutes to convert 
the file in my PC. I was trying to make it less than 10 minutes, 
so I kept asking stupid questions in the AtlME REBOL3 World.

 

Few ours ago, REBCODE came to my mind out of the blue. I remembered 
Carl said something like 10-30 faster. Because I am no REBOL expert, 
I'd never used REBCODE before. I took 1-2 hours to read the REBCODE 
document, then I do my very first REBCODE code in my life. Guess 
what? It turned out very well. The REBCODE version took only 45 seconds. 
It's AMAZING.

Interesting! And it's made for the Motorola 68030 CPU.

and a (shrinking) number of ops are buggy.... but a bug in rebcode 
is much more dramatic than in normal REBOL

it can crash the interpreter and even make your OS buggy... so I 
think Carl is a bit wary of the bad publicity this might give REBOL.

I coded a gauss blur test program and recreated it in rebcode and 
it was approximately 18 times faster. it could probably be 30-40 
times faster if there are going to be color conversion and pixel 
read/write routines built in. Right now that needs to be done manually. 
It will be fast enough for anyone to build a software rendering texture 
mapping 3D engine.

and many image processing funcs could at least be coded in a fast 
pre-process mode (not interactive, but fast enough that rendering 
them isn't too slow as to be annoying

I'd also like a way to copy to/from an external image source... to 
allow easier access to DLL rendered gfx.  (opengl and others)

and things like capture cards or output framebuffers...

I think a big issue was security. Because of the same issues that 
let you crash the system, bad things could be done by talented people. 
I'd love to see it included though, even if they had to take out 
the buggy and unsafe bits for the time being.

brian is your best bet for rebcode help, he helped a lot in designing 
and testing it with Carl.

is the T flag positionned after AND opcode execution ?

so, i have to do something like that, to set the T flag, i mean :
 
AND tmp 255
eq.i  tmp 255

...and slower

I'm not an expert only that I know by having many 3d cgi scripts 
that many apis have a mix and match of rad and degres... but it seems 
you looked at that too...

sorry in english, and sin 1 should give something near to 0

just tested  and well... the values supplied really are in radians 
 :-)

and a radian is pi / 2, right ?

It's to emulate the PSG AY-3-8910
Just for the fun and to understand a little about music

oh I see. But I thought AY-3-8910 has 4bit osc. with square and saw 
waves(plus some combinations), no sine? or does it have same lfo 
with better resolution and sine wave? don't remember the architecture 
corectly.

Yes that's right, 3 channel plus one for the noise, and square wave.

But it's enough complex to start and understand music generation 
for me.

With a simple parameter, I can switch between square wave or sine 
wave, it's quiet interresting to listen the difference.

that's great Coccinelle! nice to see more and more people using REBOL 
for audio stuff. Maybe R3 will have the annoying audio-click bug 
fixed ;)

btw, I'm just reading your code, there's [rate: 44200], you probably 
meant [rate: 44100], taht's default CD sampling frequency

Coccinelle: that's good idea with auto-detection. I was thinking 
about something simmilar for Sintezar once, auto-switching between 
rebol version, rebcode version and for /PRO C-library version. But 
I never wrote it, as nobody's using it anyway :) 

(I've got all three codes, rebol, rebcode and C-library, but not 
the autoswitch).

Gregg that binaural beat thing looks very interesting. I was interested 
in in ELF (extreme low frequencies) some time ago, but I though you 
need some pretty expensive equipment for it (as normal speakers cannot 
play 7Hz wave very well, but after reading a book by V. Marek, I 
found, that 7Hz frequency can be easily simulated by using one wave 
of frequency X and second wave of frequency X+7Hz. The 7Hz freq. 
is then created thanks to modulation, regardless on equipment. It's 
very interesting, unfortunately I had no time to get deeper into 
this field.

Yes, interesting, and with good headphones you can get subsoncis; 
SBAGen even offers boost options, by frequency, so you can tailor 
the compensation to your equipment.

I've heard that Enya's albums are 'enhanced' by some ELFs, but this 
may be just some urban legend (the reasoning was something like the 
music sounds so positive because it's using some brainwaves stuff, 
but maybe it's all bogus. Actually I bought two MCs from Enya some 
10-15 years ago and I cannot expect so wide freq. spectrum from cassette, 
but the music is still positive enough ;)

and these modify your mood, for example?

There are a lot of claims and potential uses.

There is another script of the PSG AY-3-8910 from Guest2, it's here 
http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=demo-ay.r

His script was my inspiration and is much more nice than mine. But 
I wanted to understand by myself.

It's been a while - for some I had to go back and look at my own 
posts :)

That was part of the planned upcoming features, and then they stopped 
updating it. I recall creating a comprehensive proposal...

You can still APPLY IN and then GETW or SETW.

rebcode really has to be part of 2.7... if we could just have object 
lookup, that would allow me try to make a few tests with liquid and 
mayb optimise so its about 10-30 times faster at managing the dataflow 
 :-)

Have you tried it with APPLY IN and such? How is the speed compared 
to REBOL?

I have not yet done any rebcode tests with liquid, as so far, its 
always interactive enough, so as to not require it... but I am going 
nuts with the engine  ;-)  liquidator is a testament to its stability 
and another user here is helping me push the enveloppe to  :-)


but obviously, It will come to a point where pure processing will 
be needed and in such a case, speed will always be a factor.

going nuts as in "I'm having a lot of fun with it"  :-D  the apis 
is pretty complete for most gui and procedural

For structs, yes. For objects, IN and GETW/SETW would be faster since 
you can cache the looked-up word.

hum, and if i have severall apply to do (in sequence) ?

APPLY in a LOOP block or something. Even then, it is much more efficient 
to translate to rebcode and inline when you can - APPLY overhead 
is significant, and DO overhead much more so.

This only matters when writing your own offsets. I only noticed when 
I started using the BRAB opcode, and its predecessor BRAW.

Remember that the current assembler* doesn't do much, and even that 
is done at rebcode function creation time. It has no effect on execution 
time.

You can do code snippets for your emulation/debugger, and concatenation 
for direct execution.

i have a main loop wich do the branchements and call the rebcode 
routines

first i parse Z80 opcodes and execute them step by step, then they 
are concatened to build sub-routines and cached, if sub-routines 
are mantory another time, then i call cached sub-routines instead 
of reparse the opcodes.

when i seek a Z80 branch opcode (direct or indirect), i stop the 
current rebcode function construction and i build new one for the 
folowing opcodes

if a routine return an unknwon adress, then the parser jump a these 
adress and rebuild a new function.

It also occurs to me that you could assemble your own code and modify 
the code blocks at runtime to make lookups unnecessary.

As long as you don't change the length of the code blocks any offsets 
would still be valid and the location in memory of the data underlying 
the code blocks wouldn't change, lowering the chance of a crash.

How much address arithmetic is common when doing indirect branches 
and calls, and can you reverse it using flow analysis?

and yes it is common to branch in the middle of opcodes, we can't 
predict that by a static analysis

yes and what is the question ?!?

If you are really evil, you could fill a BRAB block with the offsets 
of every Z80 operation into the offsets of their equivalent rebcode 
operations and turn every branch into an address calculation, a BRA 
to a label before the BRAB, then the BRAB.

yes but it's not ROM but RAM, and evil programms can rewrite opcodes

So, you can keep track of which areas of RAM have code in them and 
fix up the rebcode offsets when they are modified.

You can even do this incrementally by filling in the code block as 
you go along and fixing up the offsets in the BRAB block as you generate 
the code that they point to..

If you keep the Z80 memory in a binary! and make changes to it, whenever 
code at an offset already covered by the BRAB block is modified you 
would change that offset in the BRAB block to the default and mark 
the associated section of the rebcode as free. That way the next 
time you branch to that offset it would retranslate the Z80 to rebcode 
and put that rebcode in the first free spot big enough. You could 
even break up your code into blocks of around the same size and branch 
between them, to reduce fragmentation.

and if i include my snipset in conditionnal block s, i will not have 
to recalculate offset of segments ?

If you fill in the whole rebcode block with code snippets of fixed 
length and then just swap in the code blocks you want, you wouldn't 
even need to alter the BRAB block - you could just change the code 
block references. For that matter, multiple references to the same 
code block could be just that, rather than copies, saving memory.

The main code block could be generated too, and all of your Z80 rebcode 
could be generated, and you could do the assembly yourself during 
the generation using code based on the standard assembler.

If you have each snippet be just this:
    IFT []
    BRA top

then the size of the main code block could be minimized, and the 
state of the T flag at the beginning of each snippet could control 
conditional execution.

All of the infrastructure code would be at the top of the main code 
block, and the code that gets called every time before the BRAB would 
be after a LABEL top statement. Any calculations that affect the 
pc would go in the generated rebcode blocks.

This approach would end up with the size of your generated interpreter 
adding up to one 64k element block for the BRAB target block, one 
main block of 64k*4 + (some fixed number for overhead code) elements, 
and the size of any rebcode blocks generated from Z80 code between 
branches. Your source would be much smaller, or course.

Question Steeve, if you parse the Z80 opcode to produce rebcode, 
how do you handle Self Modifying Code  opcode, for example this one 
which is used to save a and restore it later :
   ld (Restore + 1), a
   .. (Do some stuff)
   Restore:	ld  a, 12h

This sample is a common optimization technic used in the 80's

peut-être que cela te serait utile :
; Patch to rebcode assembler

; - Add setl opcode -> setl: ["Set variable to label offset (0 based 
offset)" word! word!]
; - very usefull to call sub routine

system/internal/rebcode*: make system/internal/rebcode* [
    fix-bl: func [block /local labels here label][
	    labels: make block! 16 
	    block-action: :fix-bl 
	    if debug? [print "=== Fixing binding and labels... ==="] 
	    parse block [
	        some [
	            here: 
	            subblock-rule (here/1: bind here/1 words) 
	            | 

             'label word! (here/1: bind here/1 words insert insert tail labels 
             here/2 index? here) 
                |
                'setl word! word!
	            | 
	            opcode-rule (here/1: bind here/1 words) 
	            | 
                skip (print "LA" error here)
	        ]
	    ] 
	    parse block [
	        some [
	            here: 
	            ['bra word! | 'brat word! | 'braf word!] (
	                fix-label labels at here 2 here 0
	            ) 
	            | 
	            'brab into [some word!] word! (
	                label: here/2 
	                forall label [
	                    fix-label labels label here -1
	                ]
	            ) 
	            | 
	            'brab word! word! (
	                fix-label labels at here 2 here -1
	            ) 
	            |
	            'setl word! word! (
	            	here/1: 'set
	            	here/1: bind here/1 words
	            	here/3: -1 + any [
	            		select labels to word! here/3

               error/with here join "Missing label '" [here/3 ":"]
            		]
	            )
	            | 
	            opcode-rule 
	            | 
                skip (print "ICI" error here)
	        ]
	    ]
    ]
	system/internal/assemble: func [
	    "REBCODE Assembler" 
	    body 
	    /local frame here do-blks labels tmp rule
	][
	    body: second :body 
	    fix-bl body
	]
]

hum, i'm not sure of  the utility of your code. Currently,  the development 
of the Z80 virtual machine is achieved and is very simple.

the new rebcode version, is several times faster than the old, i'm 
happy !,  and I did not convert the video emulation into rebcode 
yet  , so ,   I think that we will be able to play in a screen much 
larger while keeping fluidity.

A direct interpreter, or I guess a tokenized interpreter using the 
original opcodes as tokens, which amounts to the same thing. Interesting. 
I suppose that would be simplest way to do it, and a threaded interpreter 
would be a little hard in rebcode because of the relative branches. 
Good job!

Your new version also deals with the too-many-words backwards-compatibility 
problem that the old approach had, by just having words for opcodes 
rather than addresses. It should also have much less memory overhead 
than my compiled suggestion, and not require generating the rebcode 
of the interpreter - it is probably hand-codeable.

Several branches for every instruction, but probably optimizable 
on a special-case basis. Definitely slower than compiled rebcode, 
but much less complex and without the compiler overhead, so perhaps 
not that much slower. Much more compatible with self-modifying code. 
Also likely more compatible with JIT-compiled rebcode when that happens. 
Some code-generation on your interpreter, but mostly hand-coded. 
Overall, nice.

That platform has BCD-based output opcodes? Surprising - most use 
integers and string conversion.

yes but addition and substractions are performed on char! (byte)

for example if you add 06h and 04h, you get 0Ah which is the correct 
result in byte form, using DAA after such addition, convert the result 
into 10h which is the correct result in BCD form

I forget (and don't have rebcode installed on this PC), what happens 
if you pick out-of-range in rebcode?

and using past?

How does the DAA react differently after an add or a sub? Could you 
simplify things by combining the add/sub and the daa into a larger 
logical opcode? It occured to me, looking at your code earlier, that 
you could combine strings of opcodes that didn't include writes to 
memory into larger virtual opcodes, to cut down on interpreter overhead 
when not necessary.