Allison Randal wrote:
> It's a balance, like everything else in design.
use Yin::Yang;
s/design/life/g;
A
I'll just weigh in with my vote against this.
On Tue, 4 Feb 2003, Stéphane Payrard wrote:
> In the tradition of Perl concision, I would like newline to be a
> statement terminator everywhere it can: that is when
>a) the parser expects an operator
> _and_ b) we are not in the middle of a
At 01:57 +0100 2003/02/04, Stéphane Payrard wrote:
>In the tradition of Perl concision, I would like newline to be a
>statement terminator everywhere it can: that is when
> a) the parser expects an operator
> _and_ b) we are not in the middle of a parenthesised expression.
>
IMO this would
At 10:12 PM 2/6/2003 +0100, Leopold Toetsch wrote:
Improvements welcome - and I'm a really bad C programmer, I won't do it.
*cough*
If you are a "bad" C programmer, what is your "good" language? :)
-Melvin
At Thu, 06 Feb 2003 13:47:45 +0100,
Leopold Toetsch wrote:
> I don't know, why I can't update the MANIFEST, I got a fresh copy added
> CGP.pm and...
>
> $ cvs ci -mCGP MANIFEST
> cvs server: Up-to-date check failed for `MANIFEST'
> cvs [server aborted]: correct above errors first!
What does `cvs
On Thu, Feb 06, 2003 at 01:37:42PM +0100, Leopold Toetsch wrote:
> This is one thing I allways wanted to try ;-)
>
> fast_core MOps: 11
> Prederef: 17.5
> CGoto MOps: 19.4
> CGP MOps: 27.5
> CGP -O3 MOps: 65 !!!1
>
> This runloop combines the faster dispatch of opcodes via compu
This patch removes a lot of code duplication:
- core_ops_cg.c is built by ops2c.pl now, making ops2cgc.pl obsolete
- core_ops_prederef.c doesn't have an op_info_table anymore, it was just
a duplication of core_ops.c
- this saves ~300K in sources and makes the interpreter smaller by ~10%
- all core
I don't know, why I can't update the MANIFEST, I got a fresh copy added
CGP.pm and...
$ cvs ci -mCGP MANIFEST
cvs server: Up-to-date check failed for `MANIFEST'
cvs [server aborted]: correct above errors first!
This is one thing I allways wanted to try ;-)
fast_core MOps: 11
Prederef: 17.5
CGoto MOps: 19.4
CGP MOps: 27.5
CGP -O3 MOps: 65 !!!1
This runloop combines the faster dispatch of opcodes via computed goto
and the clever register addressing due to predereferencing registers and
leo++
Leopold Toetsch <[EMAIL PROTECTED]>
02/06/2003 07:37 AM
To: P6I <[EMAIL PROTECTED]>
cc:
Subject:[CVS ci] CGP - CGoto Prederefed runloop
This is one thing I allways wanted to try ;-)
fast_core MOps: 11
Prederef: 17.5
CGoto MOps: 19.4
CG
guile -s examples/mops/mops.schemeM op/s: 0.9
python -OO examples/mops/mops.py M op/s: 1.2
perl examples/mops/mops.plM op/s: 1.4
imcc -P examples/assembly/mops_p.pasm M op/s: 22.7
imcc -j examples/assembly/mops_p.pasm M op/s: 26.0
imcc -P examples/assembly/mops.pasm M
Jerome Vouillon wrote:
CGP -O3 MOps: 65 !!!1
This generates some pretty good code (for instance, for sub_i_i_i) :
Yep. I'd have a look at it, really compact.
Why not also predereference the operation address? This would save a
memory read. The goto would become:
goto **(cur_op
I have lost my network connection from home (hopefully only for
another week or so), and I keep my work/hobby lives separate.
Actually, that's closer to paid/unpaid work, isn't it? :-) So you
won't hear much from me for a while. And my bug reports will be poor.
Like this one:
IMCC doesn't handle b
13 matches
Mail list logo
