|
|
|
04-16-2012, 05:47 AM
|
#81
|
Human being with feelings
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
|
Justin, another JS suggestion for when you're done revamping the entire language: it would be really useful if Jesusonic plugins could send and receive OSC messages in the same way OSC control surfaces can now. Some of the much requested stuff that we now 'have to' do outside of REAPER could then also be done inside REAPER, such as parameter feedback to MIDI controllers, or a virtual CV system like for VCA mixer groups).
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
|
|
|
04-16-2012, 06:56 AM
|
#82
|
Mortal
Join Date: Dec 2008
Location: France
Posts: 1,969
|
Quote:
Originally Posted by dub3000
tried again with the brand-new latest DLL, results appear to be pretty much the same as the previous one (32-bit).
|
Confirmed here too (32-bit, not tested x64 yet): as far as I can tell arrays are not faster than in 4.22, it depends on what you do.. It could even be a bit slower. It looks promising in the perf window but not with a real monitoring tool. Globally I can see a tiny overall imrprovement but much erratic use of the CPU:
^^cheap dual core, win xp. Same zoomed image attached. Very only diff between the 2 graphs: the new jsfx.dll. The erratic thing seems to happen when there are array accesses from everywhere (@sample, @gfx, @block).
Anyway, in both cases, I'm not sure such a vu-meter pumping 14-16% of the cpu on its own could be released For the record, the optimized version w/o array but 64 vars instead (!) uses 5% CPU with full load, i.e. 64 channels. I'll test a stack solution when I have a minute.
Quote:
Originally Posted by cyco130
Here's a small but useful js function, just to show that this new addition opens up some very cool possibilities that may not be immediately recognizable:
Code:
@init
function malloc(size)
local(result)
(
result = heapTop;
heapTop += ceil(size);
result;
);
// Allocate 200 ms delay buffers for each channel
delayBufferL = malloc(srate * 0.200);
delayBufferR = malloc(srate * 0.200);
// Report memory usage
freembuf(heapTop);
Automatic memory management for JS
|
I'd call this func AddSomething() but not malloc haha! I'm not sure you posted that folowing the sucky suggestion I did about allocations (?) but if so my suggestion was not really to have alloc/realloc features but -if it makes sense- to "delegate" such things to us. So, for ex, no bounds checking on REAPER side but at the cost of bad JS's to crash REAPER, of course.
Last edited by Jeffos; 04-16-2012 at 07:04 AM.
|
|
|
04-16-2012, 07:16 AM
|
#83
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,653
|
Quote:
Originally Posted by Justin
I've just updated the builds, with that optimization fix (- being + for constants).
|
Fixed, thanks.
Quote:
Originally Posted by Justin
The builds are now compiled with ICC (as they would be in a REAPER release), so that might affect performance (positively!) too.
|
I just ran two tests on my work machine (an ancient Core2 Duo E6300 1.86GHz running WinXP Pro x86), a very dumb delay that actually moves 441 samples each @sample call using an array, and a tone generator adding up 220 sines each @sample call (no arrays here):
Code:
v4.23pre1a jsfx_functions
Delay 47.7% 27.1%
Tone generator 34.8% 33.2%
So the performance improvement is there, although without arrays I guess it is less profound.
EDIT: I just ran the same two tests on a Core2 Duo E6550 2.33GHz running REAPER x64 on Win7 Pro x64:
Code:
v4.23pre1a jsfx_functions
Delay 38.7% 22.1%
Tone generator 27.8% 26.5%
Last edited by Tale; 04-16-2012 at 07:57 AM.
Reason: Added x64 results
|
|
|
04-16-2012, 07:43 AM
|
#84
|
Mortal
Join Date: Dec 2008
Location: France
Posts: 1,969
|
humm.. wow 20% better !? where do those % come from Tale? from REAPER's perf meter window? could you post the JS?
just in case: here's attached the test project + JS I used for the graphs above (sucky effect, just for test: lots of array accesses)
|
|
|
04-16-2012, 08:06 AM
|
#85
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,653
|
Quote:
Originally Posted by Jeffos
humm.. wow 20% better !? where do those % come from Tale? from REAPER's perf meter window?
|
I am talking about the CPU usage as REAPER reports it in the status bar of the FX window.
Quote:
Originally Posted by Jeffos
could you post the JS?
|
Sure.
|
|
|
04-16-2012, 08:12 AM
|
#86
|
Human being with feelings
Join Date: Jan 2007
Location: mcr:uk
Posts: 3,891
|
Quote:
Originally Posted by Justin
maybe we can come up with some hybrid of the two that can have it all. I'll think about this some more...
|
Justin Frankel can't resist a challenge .
Quote:
Originally Posted by Justin
Having said that, I am curious about thoughts where the namespace system reaches its limits -- not in general, but for this application. It already allows for a huge amount of reusability, perhaps that will be enough...
|
I've got no idea where the limit is but I'm looking forward to finding it. It would be nice to be able to pass objects around instead of treating blocks of memory as objects but I ain't complaining. I suspect that all this new stuff is going to make manipulating those blocks of memory much easier anyway.
|
|
|
04-16-2012, 08:40 AM
|
#87
|
Mortal
Join Date: Dec 2008
Location: France
Posts: 1,969
|
@Tale: thanks! yes, confirmed much better results with your test JS "delay" indeed (I see 15% better here, I use perfmon.exe)
#é!?#&ù!? Ok, so this might depend on what/where you code + "the age of the captain" as we say in French
|
|
|
04-16-2012, 08:50 AM
|
#88
|
Human being with feelings
Join Date: Jan 2007
Location: mcr:uk
Posts: 3,891
|
There's a bug lurking in the debug list code. I thought that adding/subtracting constants was still broken but it turned out that the list just wasn't showing the right values when I saved/recompiled. Seems to be working properly now. Should've got a screen shot .
|
|
|
04-16-2012, 10:03 AM
|
#89
|
Human being with feelings
Join Date: Apr 2012
Posts: 4
|
I've spotted a bug where calling an undeclared function with dots (like when you misspell the function name: myObject.myFun xtion) crashes Reaper. Unfortunately it happens very sporadically, I couldn't isolate a simple case. I'll report more about it if I can reproduce it reliably.
Also, I didn't check if it was already the case in the release version but % operator seems to have higher precedence than array access operator []. So a = b % c[3] is parsed as a = (b%c)[3]. This caused me a good amount of time trying to understand what was going wrong
Quote:
Originally Posted by Jeffos
I'd call this func AddSomething() but not malloc haha!
|
Haha, it's nothing like malloc of course. But it does work beatifully for (semi)static arrays
Quote:
Originally Posted by IXix
There's a bug lurking in the debug list code. I thought that adding/subtracting constants was still broken but it turned out that the list just wasn't showing the right values when I saved/recompiled. Seems to be working properly now. Should've got a screen shot .
|
I can confirm that. But it doesn't happen all the time.
Quote:
Originally Posted by Justin
Having said that, I am curious about thoughts where the namespace system reaches its limits -- not in general, but for this application. It already allows for a huge amount of reusability, perhaps that will be enough...
|
I'm playing around with a proof-of-concept GUI library, based on passing around memory pointers but manipulating them with namespaces. Goes well for now, except the occasional need for event callbacks for more generality, which I don't expect any time soon But loosening the 3 arguments limit could have lead to an easier-to-use design.
|
|
|
04-16-2012, 10:29 AM
|
#90
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by cyco130
I've spotted a bug where calling an undeclared function with dots (like when you misspell the function name: myObject.myFunxtion) crashes Reaper. Unfortunately it happens very sporadically, I couldn't isolate a simple case. I'll report more about it if I can reproduce it reliably.
|
I will look into this and try to duplicate too.
Quote:
Also, I didn't check if it was already the case in the release version but % operator seems to have higher precedence than array access operator []. So a = b % c[3] is parsed as a = (b%c)[3]. This caused me a good amount of time trying to understand what was going wrong
|
It is, and it's also the case with ^, and a few other operators. Ack! I'm going to fix, but hoping that fixing it doesn't break a lot of existing JS that depend on that (incorrect) behavior.
|
|
|
04-16-2012, 01:21 PM
|
#91
|
Human being with feelings
Join Date: Jun 2007
Location: Palm Beach FL
Posts: 265
|
Firstly, thank you Justin and the other brilliant people behind Reaper!
Here are some of my ideas...
Code:
function F(#Code#)
(
#Code#;
);
This will open the possibility for macros, lambda functions, passing object references, and much more syntactic candy!
I vote for hidden *.inc extension for includes, as that will encourage clean bundling by the directory of the author, while /../ in path names can reference external shared libraries.
If we can get some basic string and output functions, JS can become a rather serious musical programming language, programmable in the context of loaded songs and production! Also, file change detection of loaded JS programs, so when you save it in an external editor and it re-compiles automatically, would be a very significant time saver...
Long live Reaper!
|
|
|
04-16-2012, 01:32 PM
|
#92
|
Human being with feelings
Join Date: Jul 2006
Posts: 626
|
Quote:
Originally Posted by Banned
[...]it would be really useful if Jesusonic plugins could send and receive OSC messages[...]
|
++1! would love to add OSC support to arp!0.
|
|
|
04-16-2012, 01:49 PM
|
#93
|
Human being with feelings
Join Date: Jul 2006
Posts: 626
|
Quote:
Originally Posted by Justin
It is, and it's also the case with ^, and a few other operators.
|
including !foo[] == (!foo)[] i hope.
Quote:
Originally Posted by Justin
Ack! I'm going to fix, but hoping that fixing it doesn't break a lot of existing JS that depend on that (incorrect) behavior.
|
i've spent more than a little time finding bugs from this odd precedence and will be grateful for a fix.
and since we seem to be in Jesusonic dreamtime, the one feature that would have saved me gobs of time debugging is some sort of basic variable declaration:
dim theVariable;
tehVariable= 1; //error please!
fwiw, /dan
|
|
|
04-16-2012, 02:05 PM
|
#94
|
Human being with feelings
Join Date: Sep 2009
Location: Middle of nowhere (where the cheese comes from)
Posts: 483
|
Quote:
Originally Posted by bang
...basic variable declaration:
dim theVariable;
tehVariable= 1; //error please!
fwiw, /dan
|
please please pretty please?
|
|
|
04-16-2012, 02:55 PM
|
#95
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Just noticed, looking at code, but havent tested -- accessing regXX may crash heh.
I'm actually looking at modernizing the front end of eel to match the new back end. Fun with yacc!
|
|
|
04-16-2012, 03:15 PM
|
#96
|
Human being with feelings
Join Date: Jun 2007
Location: Palm Beach FL
Posts: 265
|
Quote:
Originally Posted by Justin
I'm actually looking at modernizing the front end of eel to match the new back end. Fun with yacc!
|
EEL for Reaper? Too cool for words!
http://eel.olofson.net/features.html
"EEL code can generate and compile EEL code at run time", ah the power of metaprogramming...
|
|
|
04-16-2012, 03:17 PM
|
#97
|
Human being with feelings
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
|
Quote:
Originally Posted by Justin
[...] I'm actually looking at modernizing the front end of eel to match the new back end. [...]
|
That sounds pretty gross.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
|
|
|
04-16-2012, 04:17 PM
|
#98
|
Human being with feelings
Join Date: Feb 2005
Location: Greece
Posts: 100
|
Quote:
Originally Posted by beyond
|
that EEL has nothing to do with REAPER's EEL.
although both live in the water
|
|
|
04-16-2012, 09:33 PM
|
#99
|
Human being with feelings
Join Date: Nov 2008
Location: Toronto, Canada
Posts: 4,630
|
I feel like I'm watching a foreign film festival, caught up in the excitement but not understanding a single thing. I missed that day at school when they were teaching JS coding.
Hope there will be some green functions, too, like compost and recycle.
R.
|
|
|
04-17-2012, 08:01 PM
|
#100
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
OK, updated again on April 17. Changes in this version: - Some small fixes, optimizations
- Changed the way expressions such as a ^ mem[x], a ~ mem[x], and a % mem[x] are parsed. It used to be (erroneously) (a^mem)[x], but it is now a^(mem[x]), which makes a lot more sense. Hopefully this doesn't break existing plug-ins! It really could!
- In fixing this, I noticed there are a lot of other areas where the logic does not match what one would expect. For example: x % 2^y is parsed as (x%2)^y. We can't go changing all of these rules, so I'd suggest that everybody use () religiously, and especially whenever you use %, ~, or ^.
- I spent a bunch of time writing new flex/bison rules trying to emulate JS/EEL. I have it 90% of the way there, but there are a lot of constructs that JS/EEL code often uses that are a real pain to properly support. At some point we should probably make an EELv3 that ditches compatibility, but that's a ways off. Some of the perks of the new code (which isn't finished but is at least limping) are nice, though, such as more descriptive errors with accurate line numbers, support for EEL functions with more than 3 parameters, etc. Someday, I guess, we'll make JS2.
Some things I'm going to do soon: - optional support for explicit variable declarations
- include/import support for functions (probably with .inc files in the same path as the js, and make REAPER ignore *.inc when scanning).
- look at having more of win32's jsfx.dll compiled with ICC, it looks like it never really was (though the win64 version is). Anybody have any performance summaries with the most recent builds?
- Edit (added thoughts): I'm going to make a script that will check the existing library of JS effects to see if they are affected by the most recent precedence change. I will also experiment with fixing other precedence issues, provided of course the affected plug-ins are minimal enough, heh.
Last edited by Justin; 04-17-2012 at 08:30 PM.
|
|
|
04-17-2012, 08:42 PM
|
#101
|
Human being with feelings
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
|
Quote:
Originally Posted by Justin
[...] We can't go changing all of these rules, so I'd suggest that everybody use () religiously [...]
|
Amen.
Quote:
Originally Posted by Justin
Someday, I guess, we'll make JS2. [...]
|
ReaSurrection, Hallelujah!
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
|
|
|
04-17-2012, 09:48 PM
|
#102
|
Human being with feelings
Join Date: Jul 2006
Posts: 626
|
Quote:
Originally Posted by Justin
Changed the way expressions such as a ^ mem[x], a ~ mem[x], and a % mem[x] are parsed. It used to be (erroneously) (a^mem)[x], but it is now a^(mem[x]), which makes a lot more sense. Hopefully this doesn't break existing plug-ins! It really could!
|
also ! mem[x] is now !(mem[x]). thanks.
Quote:
Originally Posted by Justin
In fixing this, I noticed there are a lot of other areas where the logic does not match what one would expect. For example: x % 2^y is parsed as (x%2)^y. We can't go changing all of these rules, so I'd suggest that everybody use () religiously, and especially whenever you use %, ~, or ^.
|
when the dust settles, could we please a definitive operator precedence list? i for one really like to know *why* i'm using ().
Quote:
Originally Posted by Justin
[...]soon: optional support for explicit variable declarationss are minimal enough, heh.[/list]
|
fantastic! tia!
and fyi, something seems wrong with JS: midi_logger with the latest update on osx 10.6.8 w/ Reaper 4.22pre2.
enjoy! /dan
|
|
|
04-17-2012, 10:31 PM
|
#103
|
Human being with feelings
Join Date: Mar 2008
Location: Sydney, Australia
Posts: 3,955
|
We could trivially build some sort of basic JS smoke test by defining a project with one of each js plugin with random settings, rendering as float32, and doing a before/after diff on the output file across different js versions. Just have to leave out plugs that use random numbers.
|
|
|
04-18-2012, 01:52 AM
|
#104
|
Human being with feelings
Join Date: Jan 2007
Location: mcr:uk
Posts: 3,891
|
So much love!
Regarding changes to precedence, why not implement a method for new plugins to use the new precedence?
Code:
@init
js_version = 2;
Then any plugin that doesn't specify a version could just use the old precedence.
|
|
|
04-18-2012, 02:29 AM
|
#105
|
Mortal
Join Date: Dec 2008
Location: France
Posts: 1,969
|
bug: stack_exch(x) replaces the top of the stack but it does not "exchanges" it
|
|
|
04-18-2012, 02:30 AM
|
#106
|
Human being with feelings
Join Date: Sep 2009
Location: Middle of nowhere (where the cheese comes from)
Posts: 483
|
Quote:
Originally Posted by IXix
So much love!
Regarding changes to precedence, why not implement a method for new plugins to use the new precedence?
Code:
@init
js_version = 2;
Then any plugin that doesn't specify a version could just use the old precedence.
|
BLOATWARE!!!!
I agree with you IXix
|
|
|
04-18-2012, 03:24 AM
|
#107
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,653
|
Quote:
Originally Posted by IXix
Regarding changes to precedence, why not implement a method for new plugins to use the new precedence?
Code:
@init
js_version = 2;
Then any plugin that doesn't specify a version could just use the old precedence.
|
But then you'd have to start every new script you write with those same boring lines, which seems kinda lame to me. I would rather fix the few scripts (if any) that actually exploit the old precedence, and be done with it.
|
|
|
04-18-2012, 03:44 AM
|
#108
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
But there are hundreds of JSFX coming with Reaper... who's gonna check them all for that precedence inconsistency?
BTW, how about allowing the users to rename the JS effects from Reaper's FX browser, without messing with the actual filename? I'd really love to do this.
Also, how about displaying JS subfolders in the FX browser as actually subfolders in the tree...
And, how about adding an extension for JS scripts? Something like .jsfx (so it doesn't clash with JavaScripts)?
[img]http://img295.**************/img295/9007/fxbrowse.png[/img]
Wouldn't this be a lot nicer? Yes, ED, it would!
Last edited by EvilDragon; 04-18-2012 at 07:30 AM.
|
|
|
04-18-2012, 04:29 AM
|
#109
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,653
|
Quote:
Originally Posted by EvilDragon
But there are hundreds of JSFX coming with Reaper... who's gonna check them all for that precedence inconsistency?
|
Sure. But the same goes for any of the JS changes. Anyway...
Quote:
Originally Posted by Justin
I'm going to make a script that will check the existing library of JS effects to see if they are affected by the most recent precedence change. I will also experiment with fixing other precedence issues, provided of course the affected plug-ins are minimal enough, heh.
|
So, apparently Justin is gonna check them all.
|
|
|
04-18-2012, 06:58 AM
|
#110
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
My script lives! The only thing it found in the stock JS was this, in midi_arp:
Code:
pbvarpos > nvar || !notelist[pbnotepos] ?
Which I guess means that it fixes a bug in midi_arp, as I can't imagine that working right in the old JS!
I will try out some other changes and run them on all of the stock JS -- if anybody has scripts that they want me to test parser changes against, you can PM me them..
|
|
|
04-18-2012, 07:00 AM
|
#111
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by Jeffos
bug: stack_exch(x) replaces the top of the stack but it does not "exchanges" it
|
Hmm, what OS/arch? It is working here on win32 and win64...
Last edited by Justin; 04-18-2012 at 07:15 AM.
|
|
|
04-18-2012, 07:09 AM
|
#112
|
Mortal
Join Date: Dec 2008
Location: France
Posts: 1,969
|
win32 too..
may be you can try this:
Code:
@init
stack_push(3);
stack_push(2);
stack_push(1);
stack_push(7);
stack_exch(2);
DEBUG0=stack_peek(0); // should be 2
DEBUG1=stack_peek(1);
DEBUG2=stack_peek(2); // should be 7 but remains 2 (in the JS debugger at least)
DEBUG3=stack_peek(3);
EDIT:
Quote:
Originally Posted by Justin
Anybody have any performance summaries with the most recent builds?
|
oh and I still see CPU "spikes" with *some* JS effects (eg the one I attached http://forum.cockos.com/showpost.php...5&postcount=84) whilst the same JSs are "smooth on the CPU" in v4.22
Last edited by Jeffos; 04-18-2012 at 07:18 AM.
|
|
|
04-18-2012, 07:18 AM
|
#113
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by Jeffos
win32 too..
may be you can try this:
Code:
@init
stack_push(3);
stack_push(2);
stack_push(1);
stack_push(7);
stack_exch(2);
DEBUG0=stack_peek(0); // should be 2
DEBUG1=stack_peek(1);
DEBUG2=stack_peek(2); // should be 7 but remains 2 (in the JS debugger at least)
DEBUG3=stack_peek(3);
|
Ooops, this wasn't clear -- stack_exch(x) exchanges the value of x onto the top of the stack... it's essentially tmp=stack_pop(); stack_push(x); x=tmp; (but faster).
|
|
|
04-18-2012, 07:20 AM
|
#114
|
Mortal
Join Date: Dec 2008
Location: France
Posts: 1,969
|
ha ha! Ok, thanks (that's an English bug on my end then )
|
|
|
04-18-2012, 07:24 AM
|
#115
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,653
|
Quote:
Originally Posted by Justin
My script lives!
|
Yay!
Quote:
Originally Posted by Justin
The only thing it found in the stock JS was this, in midi_arp:
Code:
pbvarpos > nvar || !notelist[pbnotepos] ?
Which I guess means that it fixes a bug in midi_arp, as I can't imagine that working right in the old JS!
|
Well, probably not in this case, but if notelist == 0, then I guess !notelist[pbnotepos] could be shorthand for notelist[pbnotepos+1]... But that is not very likely, now is it?
|
|
|
04-18-2012, 07:25 AM
|
#116
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by Jeffos
|
Hmm, that project is working fine -- CPU on that meter is 6% instead of 9% (in 4.22), and it doesn't really seem to spike much here. If you view the process CPU use in task manager, they are pretty similar looking, though maybe a touch lower with the new build.
|
|
|
04-18-2012, 07:27 AM
|
#117
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,653
|
Quote:
Originally Posted by Justin
Ooops, this wasn't clear -- stack_exch(x) exchanges the value of x onto the top of the stack... it's essentially tmp=stack_pop(); stack_push(x); x=tmp; (but faster).
|
I usually don't care about names, but... I don't suppose stack_exch could be renamed to stack_xchg (like the x86 instruction)?
|
|
|
04-18-2012, 07:38 AM
|
#118
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Woot! Changing it so that x (%|~|<<|>>) y ^ z is parsed as x OP (y^z) instead of (x OP y) ^ z. x^y^z will still be (x^y)^z, and I've tested it against all of the JS I have and it didn't break anything. I'll post a build later today...
|
|
|
04-18-2012, 08:38 AM
|
#119
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by Tale
I usually don't care about names, but... I don't suppose stack_exch could be renamed to stack_xchg (like the x86 instruction)?
|
Haha, err, I guess we should probably just stick to what it is already?
Also I should note, you can use stack_peek(x) to both read or write the stack at arbitrary offsets, i.e:
Code:
x = stack_peek(2);
stack_peek(2) = y;
If you pass a constant to stack_peek(), it optimizes more, and it is faster.
|
|
|
04-18-2012, 09:12 AM
|
#120
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Builds updated, now with the !/%/~/<</>> precedence vs ^ fixes.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 04:30 AM.
|