World: r3wp
[rebcode] Rebcode discussion
older newer | first last |
BrianH 1-Nov-2005 [1126] | Mix |
Ladislav 1-Nov-2005 [1127] | It might be desirable to find out if any feature of his assembler is missing. Volunteers? |
BrianH 1-Nov-2005 [1128x2] | I don't have the Knuth books, but there is a port of Mix to the .NET CLR that I've been meaning to look at. |
Does anyone know if Mix supports branches to addresses? Rebcode just branches to relative offsets. | |
Ladislav 1-Nov-2005 [1130] | see http://sunburn.stanford.edu/~knuth/mmix.html |
Sunanda 1-Nov-2005 [1131] | Technically Mix was the virtual machine, Mixal was its assembler. It has loads of things for i/o to devices like paper tape....I think rebcode could assume that happens as the mezznine level. |
BrianH 1-Nov-2005 [1132] | i and o could be series parameters |
Gabriele 1-Nov-2005 [1133] | Oldes: the rewriting engine is mezzanine, so it can be easily added back by users. i will take care of releasing a script containing it as soon as we have an official version out. |
Pekr 1-Nov-2005 [1134] | so official version will not contain rewriting engine? |
Gabriele 1-Nov-2005 [1135] | that's not decided yet, but probably not. |
Pekr 1-Nov-2005 [1136] | was it regarded being way too much high-level or so? Or inflexible, so that other ppl might find different way of how to aproach this? |
Gabriele 1-Nov-2005 [1137] | the main thing is, that the details need to be discussed more (i.e. the grammar for the rules dialect, and things like this). |
Pekr 1-Nov-2005 [1138] | ok, thanks ... |
Rebolek 1-Nov-2005 [1139] | is there some decimal FLOOR opcode in rebcode, or should I use [to-int val to-dec val] instead? Would be FLOOR a good addition? |
Ladislav 1-Nov-2005 [1140] | FLOOR: ROUND can be adapted to Rebcode, but only partially - some datatypes aren't available yet, and I have got a newer ROUND version - better suited for Rebcodization |
Rebolek 1-Nov-2005 [1141] | I don't need whole ROUND functionality, right now just FLOOR is OK for me (but OTOH, ROUND is very useful). |
BrianH 1-Nov-2005 [1142] | The to-int opcode is equivalent to floor, at least the round-down-to-0 version of floor. Ceiling can be done by adding 1 (or subtracting if the argument is negative). |
Oldes 1-Nov-2005 [1143x2] | I did some test with integer conversions and found, that using rebcode is 3x faster than using struct! :) |
But will rather wait a little bit before making more complex rebcodes, it would be good to have some place for rebcode scripts | |
BrianH 1-Nov-2005 [1145] | So they will all be where we can find them when we have to change their opcodes after the great rename? |
Pekr 1-Nov-2005 [1146] | grand rename? :-) it will happen soon, no? |
Ladislav 1-Nov-2005 [1147] | one more link to MMIX: http://sunburn.stanford.edu/~knuth/fasc1.ps.gz |
BrianH 1-Nov-2005 [1148] | Petr, they say the next version. |
Rebolek 1-Nov-2005 [1149] | Brian: I know I can use to-int but I need decimal value so I'm using to-int to-dec. Don't know if native floor would be faster.. |
BrianH 1-Nov-2005 [1150x5] | Probably not. |
Posted to RAMBO: | |
A SIGN opcode would set a word to the integer -1, 0 or 1 depending on whether an argument is less than, equal to, or greater than 0. sign: ["Set variable to the sign of a value (-1,0,1)" word! word!] It would be preferable to have SIGN work with all numeric arguments, but you might choose to implement this as sign.i and sign.d for speed - either way is fine by me. The SIGN opcode, when combined with BRAB, would enable functionality equivalent to the BRAS proposal (#3948), and so would supercede it. There are many other uses as well. | |
; Equivalent of BRAS (RAMBO 3948): sign a x brab [l0 l1] ; x < 0 label l0 ; x = 0 label l1 ; x > 0 ; Equivalent of CEILING to-int x sign a x add x a | |
; Equivalent of COMPARE for numbers set a x sub a y sign a a | |
Rebolek 3-Nov-2005 [1155x2] | Is/will be possible to use apply on function in object! ? Following code does not work: |
>> ctx: context [rcmul: rebcode [a][mul a 2 return a]] >> rca: rebcode [a][apply x ctx/rcmul [a] return x] ** User Error: Syntax error: apply x ctx/rcmul [a] return x ** Near: make error! reform [msg copy/part mold/only where 50] | |
Volker 3-Nov-2005 [1157] | Not sure, we can now take the value of a word? with bind or something? and then apply that? |
Geomol 3-Nov-2005 [1158] | Yes, you can do this: >> ctx: context [rcmul: rebcode [a][mul a 2 return a]] >> myrcmul: get in ctx 'rcmul >> rca: rebcode [a][apply x myrcmul [a] return x] >> rca 3 == 6 But I think, Kru got a point. It would be better to be able to do it his way. |
Rebolek 3-Nov-2005 [1159x2] | Geomol I thought it's possible this way, but I've got object that holds some values plus function for manipulating this values. So it's not possible to export my function to global context. |
Because I've got lot of this objects (i.e. this object is oscillator with settings like pitch and with one rebcode function to produce actual value). | |
Geomol 3-Nov-2005 [1161] | Right, and it's not 'nice' to export things to the global context like that. We should have it your way! Write it in "RT Q&A". |
Volker 3-Nov-2005 [1162] | i thought we have some sort if binding in rebcode now. then it would be like rebcode[][ set word 'rcmul bind word ctx setw x word apply x [..] ] but not soure if its really there, and about syntax. |
Geomol 3-Nov-2005 [1163] | oh |
Rebolek 3-Nov-2005 [1164] | Volker, there's no 'bind in system/internal/rebcodes |
Volker 3-Nov-2005 [1165] | Is 1.3.50 current, or is there somthing more new? |
Geomol 3-Nov-2005 [1166] | 1.3.51 28-Oct |
Rebolek 3-Nov-2005 [1167] | I've got 1.3.51 |
DideC 3-Nov-2005 [1168] | Why not doing it this way? : >> ctx: context [b: 4 rcmul: rebcode [a][mul a b return a]] >> rca: rebcode [a] bind [apply x rcmul [a] return x] ctx >> rca 2 == 8 >> ctx/b: 3 == 3 >> rca 2 == 6 |
Rebolek 3-Nov-2005 [1169] | DiceC thanks, that should solve my problem. I'm not strong at binding. |
Geomol 3-Nov-2005 [1170] | DideC, neat! :-) |
Romano 3-Nov-2005 [1171] | There is some reasons that makes relative jmp better than absolute ones in rebcode? In other words I am asking why bra uses relative jmp. I think that absolute jmp are more easy to handle, at least for me. |
BrianH 3-Nov-2005 [1172x4] | Romano, not that I would normally be defending relative jump (look at the group history :) ), but when you have to specify the offsets as literal numbers, relative offsets are more useful. Most of the time branches are used for control flow on a local level - branches only work within the same code block and most code blocks aren't very large. If you have relative branches, you can add instructions before the affected area without having to recount all of your branch statements, and you can add code snippets into code without having to add labels. When you use absolute branches that doesn't work so well. Of course there is no difference when you are branching to labels because either way the assembler would be doing the counting. |
Absolute offsets are more useful when doing calculated branches, but right now rebcode doesn't do those. | |
There is something in the rebcode docs about a special case behavior for BRAB that would enable calculated branches, but that special case hasn't been implemented yet. I have just made a RAMBO request that this behavior be implemented, so we'll see how that goes. | |
Gabriele, Gregg, my initial comments on the rebcode documentation has been sent to Feedback. If anyone would like them posted here as well, please say so. | |
older newer | first last |