AltME groups: search

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).

To clarify: my original script only update the window, when moving 
around, so fps can only be measured when holding a move key. DideC's 
version use RATE, so it continuously update the window. Using RATE 
doesn't work with View 1.3.50 under MacOS (I don't know about the 
Linux version).

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  ;-)

getting a weird variable cross over in a rebcode code block where 
the function will run fine sometimes then inexplicably swaps its 
variable contents while under recursion..

ill post the code so anyone interested can have a play

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

Brian: I found my post above:

Kru: this really seems to be APPLY related, because the following 
code crashes too:

mulr: rebcode [][return 4]
mull: rebcode [][loop 10000000 [apply a mulr []] return a]
mull

Did they ever make a new rebcode alpha based on the latest REBOL 
version? I know I requested it many times...

The version above is the latest I have got, so I think there is not 
a newer one

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.

Gregg, Thank you.

I've just found out that "to-char" is not necessary in Rebcode, the 
value picked from a binary! can be poked into a binary! without using 
"to-char" first. This is different from the regular REBOL code.

I would like to have an interactive console for REBCODE. That would 
be greate for learning the REBCODE dialect.

>> iRebcode       ; switch to REBCODE console
:> set.i a 10     
:> add.i a 20      
:> print a        
== 30             
:> exit           ; back to REBOL console
>> print a
== 30

>> iRebcode: has [b] [while [(b: ask ":> ") <> "exit"] [if error? 
try [do  do append/only copy [rebcode []] load b] [print "Syntax 
error!"]]]
>> iRebcode
:> set.i a 10
:> print a
?unset?
:>

No need for the do append copy - the rebcode function is a function, 
not syntax.

Jerry, about the above, remember that A must already refer to a integer 
value before you can use set.i.

Have a look

The Synthesis kernel written by Dr. Henry Massalin as his PhD. thesis 
is commonly viewed to be the 
mother of all self-modifying code."
via SteDekorte et al :
http://www.dekorte.com/blog/blog.cgi?do=item&id=2336

I thought rebcode was a function built into all new builds of REBOL 
- is it?  if not why not?

only a few beta versions had rebcode in them

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.

Although I do agree... in the least, it would allow a select few 
the opportunity to develop fast code other can just use...

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)

this could also be useful in situations where you don't need anything 
but rebcode. what if it were possible to build a rebol core that 
only consist of rebcode? that would be pretty small, wouldn't it?

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.

its a specific beta version or rebol/view downloads are on rebol.net.

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

i think i will ahve no problems to covert Z80 opcodes in rebcode, 
it's a similar approach

just that if you have some bugs or wandering about specifics, he 
has deep knowledge of it, he might even be able to give you hints 
on how to go around a few missing things.

is there a way to test if a var is set to none ?

i need a speed reverse byte function with rebcode , for example 1100 
0000 => 000 0011
any idea ?

I get strange result from the sin opcode, is there something special 
to know or is it a bug ?

I try with rad too but I should make a mistake

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...

and a radian is pi / 2, right ?

Thanks to rebcode I can generate 6 minutes of music in 20 seconds 
instead of 5 minutes with a standard script. Great.

I'm a newbe in music generation so ... I don't know what is self 
oscilating filter.

some example code (in C, but easy to rewrite):

float a = 2.f*(float)sin(Pi*frequency/samplerate);

float s[2];

s[0] = 0.5f;
s[1] = 0.f;

loop:
s[0] = s[0] - a*s[1];
s[1] = s[1] + a*s[0];
output_sine = s[0];
output_cosine = s[1]

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

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.

If I ever have free time again (not complaining, it's good to have 
work :-), I was thinking it would be fun to do a dialect for binaural 
beats, ala SBAGen.

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.

There are a lot of claims and potential uses.

I haven't done deep research, but mainly I view them as something 
like a "helper" for meditation, self-hypnosis, etc.

Another question : Is possible to do something like a call within 
rebcode ?

As for reversing the bits in a byte, have you considered a binary 
lookup table?

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...

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 
 :-)

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

I didn't know about APPLY IN ... I might just do a quick try in a 
little while...  does 'APPLY support refinements?

IN doesn't work with structs though, so I requested a set of struct 
opcodes to work with them (SET.S, GET.S, ...).

since its a simple shift

It's not that bad a technique in REBOL code either.

Path evaluation has a lot of overhead.

BrianH, what is the most rapid, to use a do [my-func var] or an apply 
?

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.

i use a parser to convert Z80 opcodes into rebol opcodes

i attempt to do a Z80 emulator

It really doesn't gain you much speed. The label fixups are done 
once, at rebcode function creation time. After that it just calls 
the offsets - the label statement is a noop. I only do straight offsets 
when generating code (like you are). Be careful though, as the offsets 
are calculated from the end of the branch statement, not the beginning.

anyway, can i replace assembly* by a dummy function ?

You can replace assembly* with a Z80 assembler even.

yes but i try to do emulation + a debugger , so Z80 opcodes are converts 
step by step

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

Are you doing a compiler or an interpreter? A compiler would be faster, 
but would require you to translate branches.

A JIT compiler, perhaps?

sort of like a JIT ?

but it's not a problem, the management of branches is done in real 
time, it's in a stack, so i can manage fixed as indirect branches.

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.

i could try this as a final compilation step, perhaps

Your trick of generating words for branch targets may need changing 
when you switch to rebcode. Pre-2.7 versions of REBOL had hard limits 
on the number of words possible at once (about 8000). You might consider 
issue! values instead with a lookup table (probably a hash!).

It will be a little slower. You might then return references to the 
code rather than the names.

i think i will implement  a cached routines cleaner (GC) ,  to keep 
in memory only routines which are frequently requested

currently a rebuild the parser to generate rebcode instead of rebol 
instructions

It occurs to me that you might be able to do the fixups using a compile-time 
lookup table, or perhaps translating addresses to label statements.

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.

but there is a sort of memory mapper

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

I mean, to the middle of opcodes, not from. The real-programmer trick 
is to treat the latter portion of an opcode as if it were a different 
opcode, just because it has the same bit pattern, or worse yet, branching 
into the middle of static data.

I was seeing how difficult it would be to do a full-program compilation 
to a single rebcode block, with label statements at every branch 
destination.

my parser was just a proof of concept, i agree there is a lot of 
optimizations to do

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.

It would mean a 64K element BRAB block for every 64K set of memory, 
in addition to the size of the generated code.

You can't run REBOL on a cell phone, you know. Everything else has 
plenty of RAM :)

There is no reason that the generated rebcode need be in the same 
order in its block that the original code is in its context. The 
BRAB block adds a layer of indirection, making the memory virtual.

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.

You will likely have some rebcode that corresponds to the same areas 
of Z80 memory more than once, but memory is cheap on every platform 
REBOL runs on, particularly compared to a Z80.

You can have all of your generated code segments be added as snippets 
of the same length if you wrap them in a block surrounded by the 
same code. For that matter, only that code block would need to be 
changed when changing the generated rebcode. You could even handle 
the freelist with ease by swapping marker code into free areas.

or into a loop 1 block! ?

after a break point for example

If you go with the fixed main code block prefilled with snippets, 
the unchanging length of that block would lend stability to the rebcode 
interpreter. REBOL tends to crash if modifications to code that it 
is running at the time increase the length of the code block enough 
to force a reallocation of that block.

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.

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

yeah yeah, that is not a problem anymore, i changed my way, now with 
rebcode i do pure emulation.

soon i will post a proto

label start
pickz op-code memory adress
brab [          ;list of opcode
	...
             ...
             LD_A_B
            ... 
] op-code
label LD_A_B set.i _a _b bra start

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.