[perl #21276] [PATCH] formatting fix for docs/dev/rx.dev
# New Ticket Created by Cal Henderson # Please include the string: [perl #21276] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21276 hi, this patch fixes some formatting issues that cause docs/dev/rx.dev to incorrectly display code snippets and to have no title. it also adds a missing B tag. second code snippet broken here: http://www.parrotcode.org/docs/dev/rx.dev.html no title displayed here: http://www.parrotcode.org/docs/ -cal -- ** For great Emap magazine subscription gift offers visit http://www.emapmagazines.co.uk ** The information in this email is intended only for the addressee(s) named above. Access to this email by anyone else is unauthorised. If you are not the intended recipient of this message any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. Emap plc and or its subsidiaries do not warrant that any attachments are free from viruses or other defects and accept no liability for any losses resulting from infected email transmissions. Please note that any views expressed in this email may be those of the originator and do not necessarily reflect those of this organisation. -- attachment 1 -- url: http://rt.perl.org/rt2/attach/52349/39656/85f0fd/rx.dev.diff rx.dev.diff Description: rx.dev.diff
Re: pxs help
Tupshin Harper wrote:
Taking a look at the pxs example (is this the right place to be
looking?), and I'm having problems compiling PQt.C per it's own
instructions.
I don't know, what's up with pxs, but AFAIK this is obsolete and
replaced by the NCI (native call interface).
Attached is the Qt example rewritten to NCI. This will probably only run
on i386, which builds thunking functions on the fly, other $archs will
need adjustment in call_list.txt.
s. also t/pmc/nci.t, nci.c, build_nativecall.pl, call_list.txt and last
but not least the docs.
BTW, should I check this in?
Into examples/nci or just replace the pxs files?
leo
/*
* Qt Native interface for Parrot - Sample for playing with the
* extension design.
*
* compile with: g++ -fPIC -I$QTDIR/include -L$QTDIR -c PQt.C
*gcc -shared -o libPQt.so PQt.o $QTDIR/lib/libqt.so
*
* Or something like that...
*/
#include qapplication.h
#include qlabel.h
extern C {
#include stdio.h
#include dlfcn.h
QApplication * pApp;
/*
* QApplication bindings
*/
QApplication *QApplication_new(void) {
int PQtargc = 0;
char *PQtargv[2];
PQtargv[0] = ;
PQtargv[1] = NULL;
pApp = new QApplication(PQtargc, PQtargv);
return pApp;
}
void QApplication_exec(QApplication *app)
{
app-exec();
}
void QApplication_setMainWidget(QApplication *app, QWidget *w)
{
app-setMainWidget(w);
}
/*
* QLabel bindings
*/
QLabel * QLabel_new(const char *txt)
{
QLabel * pLabel = new QLabel(txt, 0);
return pLabel;
}
void QLabel_show(QLabel *label)
{
label-show();
}
void QLabel_resize(QLabel *label, int x, int y)
{
label-resize(x, y);
}
}
# Sample Hello World with Qt, via Parrot Native Call API (nci)
# You'll need to build libPQt.so for this to work, see
# pqt.C for more info.
#
# ln -s languages/imcc imcc
# cd examples/pxs
# export LD_LIBRARY_PATH=.
# ../../imcc QtHelloWorld.pasm
#
loadlib P1, libPQt.so
print Loaded\n
dlfunc P0, P1, QApplication_new, pv
invoke
set P2, P5 # pApp
set S5, Hello, world!
dlfunc P0, P1, QLabel_new, pt
# if you need more labels, save P0 = QLabel_new() function
invoke
set P6, P5 # save pLabel
set I5, 30 # y
set I6, 120 # x
dlfunc P0, P1, QLabel_resize, vpii
invoke
dlfunc P0, P1, QApplication_setMainWidget, vpp
set P5, P6 # pLabel
set P6, P2 # pApp
invoke
# P5 = label
dlfunc P0, P1, QLabel_show, vp
invoke
dlfunc P0, P1,QApplication_exec, vp
set P5, P2 # app
invoke
end
RE: pxs help
Tupshin Harper:
# If pxs is truly obsolete, please trash it ;-).
I'm not confident enough about PXS to trash it, but I've commented a few
files appropriately.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism
bit rot (and other tribulations) in parrot/languages/*
A number of the language examples in parrot seem to not work as well as they once might have(or should). The learning curve to get familiar something like parrot is much easier if things like this just work. So, if anybody cares, here's the list of issues I ran into in the languages directory: ook: executing: parrot ook.pbc generates: invoke() not implemented in class 'PerlUndef' basic: no instructions on how to actually run the .bas examples. Tried a few thing like parrot basic.pbc eliza.bas and got nothing but BAD KEYWORD. Probably my usage error, but at a loss how to use it. Befunge-93: Trivial, but a fresh cvs checkout has a lingering empty Befunge-93 directory. cola: doesn't compile bison -v -y -d -o parser.c cola.y cola.y:75.7-11: type redeclaration for class_decl cola.y:84.7-11: type redeclaration for element_access cola.y:91.7-11: type redeclaration for relational_expr cola.y:91.7-11: type redeclaration for equality_expr forth: not an error, but no examples of usage tried a helloworld, but didn't get anywhere miniperl: make fails t/harness make: t/harness: Command not found make: *** [test] Error 127 parrot_compiler: unclear what its relationship(if any) to the top level assemble.pl is. Looks like it might be a proof of concept assembler written in native parrot, but a little unclear. A tiny readme would be good. Also, tried ../../parrot pc.pbc and got no such file or directory. When I did ../../parrot pc.pbc sample.pasm, I didn't get an error, but it didn't do anything. perl6: The perl6 interpreter/compiler is fine, but some it's examples are broken: qsort.p6: get_pmc_keyed() not implemented in class 'PerlUndef' bnf.p6: Undefined subroutine P6C::Tree::concat_string called at P6C/Tree.pm line 1053. qsort.p6: [IMCC::add_function (diagnostic) main] Redefining function reverse [IMCC::add_function (diagnostic) main] Redefining function main error:imcc:mk_address file examples/qsort.imc line 73: Label '_reverse' already defined Error: '../imcc/imcc -oexamples/qsort.pasm examples/qsort.imc' failed with exit code 1 Stopped at ./perl6 line 312, DATA chunk 155. ruby: absolutely no idea what the status of this one is. The README is a placeholder. -Tupshin
[perl #21277] [PATCH] Macros in imcc (part 2.)
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #21277]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21277
Hello,
Here is an extension to my first macro support patch (#21033 already
applied).
This replaces the calls to yyerror wiht calls to fataly as suggested
by leo, and removes some dead code which creaped through in the first
patch.
Further more it implements .constant; now only the two buggy string
tests fail when run with imcc.
And last there is a start of documentation docs/macros.pod, which is a
slightly edited version of perldoc -u assemble.pl.
bye boe
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/52351/39659/cb0334/imcc2.diff
Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.314
diff -u -r1.314 MANIFEST
--- MANIFEST 14 Feb 2003 22:33:42 - 1.314
+++ MANIFEST 18 Feb 2003 01:22:09 -
@@ -1364,6 +1364,7 @@
languages/imcc/debug.c
languages/imcc/debug.h
languages/imcc/docs/imcc.pod
+languages/imcc/docs/macros.pod
languages/imcc/docs/operation.pod
languages/imcc/docs/parsing.pod
languages/imcc/docs/running.pod
Index: languages/imcc/imcc.l
===
RCS file: /cvs/public/parrot/languages/imcc/imcc.l,v
retrieving revision 1.27
diff -u -r1.27 imcc.l
--- languages/imcc/imcc.l 17 Feb 2003 13:56:36 - 1.27
+++ languages/imcc/imcc.l 18 Feb 2003 01:22:09 -
@@ -47,7 +47,6 @@
/* static function declariations */
static struct macro_frame_t *new_frame (void);
-/*static void add_param_to_frame (const char *param, const char *expansion); */
static void scan_string (struct macro_frame_t *frame, const char *expansion);
static void scan_file (struct macro_frame_t *frame, FILE *);
static void destroy_frame (struct macro_frame_t *frame);
@@ -129,7 +128,7 @@
return EOM;
}
-emit,INITIAL[ISNP]{DIGIT}{DIGIT}? {
+*[ISNP]{DIGIT}{DIGIT}? {
valp-s = str_dup(yytext);
return REG;
}
@@ -182,6 +181,37 @@
return read_macro(valp, interp);
}
+INITIAL.macro {
+fataly (EX_SOFTWARE, , line, Macros only allowed in assembly mode);
+}
+
+emit.constant {
+int c;
+ char *name;
+ struct macro_t *m;
+
+ BEGIN(macro);
+ c = yylex_skip(valp, interp, );
+ if (c != IDENTIFIER)
+ fataly(EX_SOFTWARE, .constant, line,
+ Constant names must be identifiers);
+
+ name = str_dup(valp-s);
+
+ c = yylex_skip(valp, interp, );
+if (c != INTC c != FLOATC c != STRINGC c != REG)
+fataly(EX_SOFTWARE, name, line, Constant value must be a number,
+stringliteral or register);
+
+ m = macros + num_macros++;
+ m-name = name;
+ m-expansion = str_dup (valp-s);
+ m-params.num_param = 0;
+
+ BEGIN (emit);
+ return MACRO;
+}
+
emit.include {
int c;
@@ -303,7 +333,8 @@
char *label;
char *name = macros[num_macros].name;
- if (yylex(valp, interp) != LABEL) yyerror(LABEL expected);
+ if (yylex(valp, interp) != LABEL)
+ fataly(EX_SOFTWARE, , line, LABEL expected);
if (valp) {
YYCHOP();
@@ -408,7 +439,7 @@
const char *p;
do {
-c = yylex(NULL, interp);
+c = yylex(valp, interp);
p = skip;
while (*p c != *p) p++;
} while (*p != '\0');
@@ -418,7 +449,7 @@
static int
read_params (YYSTYPE *valp, void *interp, struct params_t *params,
- int need_id)
+ const char *macro_name, int need_id)
{
int c;
YYSTYPE val;
@@ -429,7 +460,9 @@
c = yylex_skip(val, interp, \n);
while(c != ')') {
- if (c == 0) yyerror (Unexpected end of file);
+ if (c == 0)
+ fataly(EX_SOFTWARE, macro_name, line,
+ End of file reached while reading arguments);
else if (c == ',') {
params-name[params-num_param++] = current;
current = strdup();
@@ -437,7 +470,8 @@
c = yylex_skip(val, interp, \n);
}
else if (need_id (*current || c != IDENTIFIER) c != ' ') {
- yyerror(macro parameter error);
+ fataly(EX_SOFTWARE, macro_name, line,
+ Parameter definition must be IDENTIFIER);
}
else {
if (!need_id || c != ' ') {
@@ -469,11 +503,9 @@
start_cond = YY_START;
BEGIN(macro);
-c = yylex(NULL, interp);
-if (c != ' ') yyerror(macro error);
-
-c = yylex(valp, interp);
-if (c != IDENTIFIER) yyerror(macro error);
+c = yylex_skip(valp, interp, );
+if (c != IDENTIFIER)
+ fataly(EX_SOFTWARE, .macro, line, Macro names must be identifiers);
m-name = valp-s;
@@ -483,14 +515,15 @@
if (c == '(') {
free(valp-s);
- c = read_params(NULL, interp, m-params, 1);
- if (c != ')') yyerror(macro parameter: \)\ expected);
+ c = read_params(NULL, interp, m-params, m-name, 1);
c = yylex(valp, interp);
}
while (c != ENDM) {
- if (c == 0) yyerror(file ended before
[RFC] imcc calling conventions
Attached is a pod - describing the current existing stack calling convention - proposing a syntax for parrot's NCI calling convention. Comments ... welcome, leo =head1 NAME IMCC - calling conventions =head1 VERSION =over 4 =item 0.1 intital proposal =back =head1 OVERVIEW This document describes subroutine calling conventions. =head1 DESCRIPTION A imcc does register allocation, it has to track the life span of variables. This includes the (possible) data flow in and out of subroutines. =head1 Stack calling conventions Arguments are Bsaved in reverse order onto the user stack: .arg y # save args in reversed order .arg x call _foo#(r, s) = _foo(x,y) .local int r .local int s .result s# restore results in reversed order .result r# [1] and return values are Brestored in reversed order from there. The subroutine is responsible for preserving registers. .sub _foo # sub foo(int a, int b) saveall .param int a .param int b ... .return pl # return (pl, mi) .return mi # [1] restoreall ret .end [1] or vice versa? =head1 Parrot calling conventions (NCI) Proposed syntax: $P0 = load_lib libname $P1 = dlfunc $P0, funcname, signature .nciarg z # I5 .nciarg y # I6 .nciarg x # I7 ncicall $P1 # r = funcname(x, y, z) .nciresult r This prepares parameters like described in pdd03_calling_conventions.pod, saves the registers and invokes the function. =head1 Parrot calling conventions (Method calls) TBD. =head1 Namespaces and lexicals - Should imcc keep track of pad opcodes? - Should imcc even emit such opcodes from e.g. .local directives? =head1 FILES Fimcc.y, Ft/syn/bsr.t =head1 AUTHOR Leopold Toetsch [EMAIL PROTECTED]
parrot performance vs.(trivial test) the good, the bad, and the ugly
In case anyone is interested. On a whim I took the primes.pasm example from the parrot examples page and converted it to both c and perl5, with _interesting_ results. Timing all three with a max of 100,000 produced the following results: c -primes.c(lickety split): real0m7.710s user0m6.790s sys 0m0.030s parrot primes.pasm(default options not too impressive): real0m33.289s user0m29.130s sys 0m0.080s parrot primes.pasm(with -P...a bit better) real0m21.063s user0m20.000s sys 0m0.050s parrot primes.pasm (with jit -j option--omfg...i'm impressed) real0m12.625s user0m11.610s sys 0m0.040s perl5 primes.pl(ouch!, yes...this is the same algorithm) real6m53.454s user6m33.490s sys 0m0.990s FYI...all three used the identical algorithm taken from the primes.pasm example complete with labels and gotos(makes for very disconcerting perl code). Startup times and printf times were not significant in any of the cases(5%). Further curious because of the python challenge, I took a different (slower) primes algorithm(trying to be fair to python since it doesn't have gotos), That someone had already written C and python versions of, and ported it to parrotdrum roll please(only 10,000 primes due to slower algorithm): c - primes2.c real0m1.147s user0m1.050s sys 0m0.000s parrot primes2.pasm(default) real0m4.868s user0m4.700s sys 0m0.020s parrot primes2.pasm(-P) real0m3.058s user0m2.920s sys 0m0.000s parrot primes2.pasm(-J) real0m1.825s user0m1.700s sys 0m0.000s python primes2.py real0m25.922s user0m24.900s sys 0m0.050s So at least on simple looping benchmarks like this, parrot is much closer to the performance of C than it is to perl or python...I lke it (doing my best Tony the Tiger impersonation here). Congrats guys...it's pretty impressive. Testing platform is linux debian (sid) on an Athlon 2100, gcc 3.2.3, perl 5.8.0, python 2.2.2, and parrot CVS head as of today. -Tupshin Code available if anybody cares.
Re: bit rot (and other tribulations) in parrot/languages/*
On Tue, Feb 18, 2003 at 02:14:39AM -0800, Tupshin Harper wrote: Befunge-93: Trivial, but a fresh cvs checkout has a lingering empty Befunge-93 directory. This is a CVS annoyance. It's a good idea to add: checkout -P update -d -P to your ~/.cvsrc. You won't get empty directories if you use -P. As for the rest of your problems, I'm clueless. :-) -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project -+ http://twistedmatrix.com/users/radix.twistd/
Re: [perl #21277] [PATCH] Macros in imcc (part 2.)
Jürgen Bömmels (via RT) wrote: # New Ticket Created by Jürgen Bömmels # Please include the string: [perl #21277] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21277 Hello, Here is an extension to my first macro support patch (#21033 already applied). Thank you, applied leo ... now only the two buggy string tests fail when run with imcc. I did adjust the tests, so imcc now passes all. As long as HL people don't say, we really need unescaped NULs in strings, they (the NULs :) are considered to be illegal. $ IMCC=languages/imcc/imcc make test (or whatever syntax your shell has, to set the IMCC environment var) leo
Re: parrot performance vs.(trivial test) the good, the bad, and the ugly
Tupshin Harper wrote: In case anyone is interested. Always :) Did you have an optimized parrot compile? ( make progclean ; perl Configure.pl ... --optimize ; make -s) -Tupshin Code available if anybody cares. Yes please. TIA, leo
Re: bit rot (and other tribulations) in parrot/languages/*
Tupshin Harper wrote: A number of the language examples in parrot seem to not work as well as they once might have(or should). The learning curve to get familiar something like parrot is much easier if things like this just work. So, if anybody cares, here's the list of issues I ran into in the languages directory: ook: executing: parrot ook.pbc generates: invoke() not implemented in class 'PerlUndef' Missing program argument $ make test $ ../imcc/imcc ook.pasm test.ook basic: $ perl basic.pl no instructions on how to actually run the .bas examples. yep. LOAD bla.bas ? cola: doesn't compile Seems to be written for old bison. forth: not an error, but no examples of usage tried a helloworld, but didn't get anywhere ../imcc/imcc forth.pasm 2 dup + . 4 miniperl: make fails Yep parrot_compiler: parrot.pasm has some comments. perl6: The perl6 interpreter/compiler is fine, but some it's examples are broken: qsort.p6: delete the function reverse (its internal now) in qsort.p6, the it runs fine $ perl6 -r qsort.p6 ruby: dunno I fear you are right, bit rot -Tupshin leo
Re: bit rot (and other tribulations) in parrot/languages/*
At 02:14 AM 2/18/2003 -0800, Tupshin Harper wrote: A number of the language examples in parrot seem to not work as well as they once might have(or should). cola: doesn't compile bison -v -y -d -o parser.c cola.y cola.y:75.7-11: type redeclaration for class_decl cola.y:84.7-11: type redeclaration for element_access cola.y:91.7-11: type redeclaration for relational_expr cola.y:91.7-11: type redeclaration for equality_expr I just checked in a fix for these, it was simple redeclarations of grammar rules. The rest of the grammar is still in sad shape, granted, but my rewrite is too incomplete to checkin (being in C++ it wont overlay easily). Hope this did the trick. -Melvin
Re: pxs help
At 05:04 PM 2/17/2003 -0800, Tupshin Harper wrote: So I'm gonna take a look at the native calling functionality of parrot to see about access to an XML parser. Taking a look at the pxs example (is this the right place to be looking?), and I'm having problems compiling PQt.C per it's own instructions. After getting the qt headers installed, the following has problems all across the map. My command: I think pxs might be a bit out of date/sync with the rest of Parrot. I haven't been active lately so someone else will have to confirm, but as it was only a toy to hint on how to start a native call interface, I do not think of it as sacred. If someone will checkin an alternative (or point it out to me), I'll remove pxs altogether. -Melvin
Re: parrot performance vs.(trivial test) the good, the bad, and the ugly
[EMAIL PROTECTED] wrote: On Tue, Feb 18, 2003 at 01:53:11PM +0100, Leopold Toetsch wrote: Did you have an optimized parrot compile? ( make progclean ; perl Configure.pl ... --optimize ; make -s) --optimize may be broken. I tried it with a clean parrot source and The ellipses should have been placeholders for other options. I configure mine with: perl Configure.pl --floatval=double --debugging --optimize from Makefile: CFLAGS = -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O3 ... This should get perl5's default optimization for parrot. leo
Re: [perl #21288] [PATCH] Function pointer initialization in packfile.c
Simon Glover (via RT) wrote: # New Ticket Created by Simon Glover # Please include the string: [perl #21288] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21288 The attached patch changes the initialization of various function pointers in packfile.c from NULL to NULLfunc (defined in parrot.h), in line with the discussion in parrot.h Thanks, applied. leo
Re: parrot performance vs.(trivial test) the good, the bad, and the ugly
Leopold Toetsch wrote:
Did you have an optimized parrot compile?
( make progclean ; perl Configure.pl ... --optimize ; make -s)
No I hadn't, but I just did, using those exact commands(no additional
options to Configure.pl), and had no perceivable performance change
using any of the parrot variances(default, -P, -j). Is there a way to
verify that an optimized build was truly made? Did you expect to see
much of any difference? GCC issues(running 3.2.3)?
-Tupshin
Code available if anybody cares.
Yes please.
Alright...all versions are attached (sorry for spamming the list, but
others might be interested). Some of the code is ugly (done around 3:00
in the morning), and some are in languages I am less then fluent in
(last touched any flavor of assembly in 1985, and barely touched it
then), so be kind. I don't believe I'm being too unfair to any of the
languages, though feel free to tell me otherwise.
The python and c versions of prime2 come from a tutorial on optimizing
python by writing extensions in C
http://kortis.to/radix/python_ext/
Modified slighly to behave more analogously to the first test, and some
compilation bugs fixed.
TIA,
leo
WATF
(welcome after the fact)
-Tupshin
#include stdio.h
int main()
{
int I1 = 1;
int I2 = 10;
int I3;
int I4;
int I5;
printf(\nThe primes up to );
printf(%d, I2);
printf( are:\n);
REDO:
I3 = 2;
I4 = I1 / 2;
LOOP:
I5 = I1 % I3;
if (I5) {goto OK;}
goto NEXT;
OK:
I3++;
if (I3 = I4) {goto LOOP;}
printf (%d, I1);
printf (\n);
NEXT:
I1++;
if (I1 = I2) {goto REDO;}
}
primes.pl
Description: Perl program
# Some simple code to print out the primes up to 100
# Leon Brocard [EMAIL PROTECTED]
# I1 holds the number we're currently checking for primality
set I1, 1
# I2 holds the highest number we want to check for primality
set I2, 10
print The primes up to
print I2
printare:\n
# I1 counts up to I2
REDO: # I3 counts from 2 up to I4 (I1/2)
set I3, 2
div I4, I1, 2
LOOP: # Check if I3 is a factor of I1
mod I5, I1, I3
if I5, OK
# We've found a factor, so it can't be a prime and
# we can skip right out of this loop and to the next
# number
branch NEXT
OK: inc I3
le I3, I4, LOOP
# We haven't found a factor so it must be a prime
print I1
print \n
NEXT: # Move on to the next number
inc I1
le I1, I2, REDO
end
int main(){
int i=0, l=0, max=1;
while (1) {
if (isprime1(i)==1) {
printf(%i\n,i);
l++;
}
i++;
if (i==max){
break;
}
}
printf(primes calculated to %i\n,max);
}
int isprime1(int input)
{
int n;
if (input 1) {
return 0;
}
n = input - 1;
while (n 1){
if (input%n == 0) return 0;
n--;
}
return 1;
}
import os,sys
def isprime1(input):
if input 1:
return 0
n = input-1
while n 1:
if input%n == 0:
return 0
n = n - 1
return 1
def main():
i = 0
l = 0
max = 1
while 1:
if isprime1(i):
l = l +1
print i
i = i + 1
if i == max:
break
print primes calculated to ,max
if __name__ == __main__:
main()
set I1, 0
set I2, 0
set I3, 0
set I4, 1
BEGINLOOP:
branch PRIMECHECK
ISPRIME:
print I1
print \n
inc I2
NOTPRIME:
inc I1
eq I1,I4, DONE
PRIMECHECK:
set I5, I1
lt I5,1,NOTPRIME
set I6,I5
dec I6
NLOOP:
mod I7, I5, I6
eq I7, 0, NOTPRIME
dec I6
gt I6, 1, NLOOP
branch ISPRIME
DONE:
printprimes calculated to
print I1
print \n
end
Re: parrot performance vs.(trivial test) the good, the bad, and the ugly
[EMAIL PROTECTED] wrote: On Tue, Feb 18, 2003 at 04:03:40AM -0800, Tupshin Harper wrote: FYI...all three used the identical algorithm taken from the primes.pasm example complete with labels and gotos(makes for very disconcerting perl code). Startup times and printf times were not significant in any of the cases(5%). This is, unfortunately, a rigged demo. Its code optimized for Parrot and then mechanically translated into Perl and C. The algorithm would have been the same if it, for example, used a loop in Perl instead of gotos. I don't know that its all that interesting to show that goto is slow in Perl. OTOH, goto should be fast in C, no? I'm going to tinker with those benchmarks again. Agreed...the second example is probably less rigged, since the mechanical translation was to pasm(and don't know enough to optimize the pasm ;-) -Tupshin
[perl #21288] [PATCH] Function pointer initialization in packfile.c
# New Ticket Created by Simon Glover
# Please include the string: [perl #21288]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21288
The attached patch changes the initialization of various function
pointers in packfile.c from NULL to NULLfunc (defined in parrot.h),
in line with the discussion in parrot.h
Hopefully this will fix the current breakage with lcc, but I don't have
a working copy to test this with; on the machines I do have access to
(x86 and Alpha, both with Linux) parrot builds fine, and all tests past.
Simon
--- packfile.c.old Tue Feb 18 14:18:26 2003
+++ packfile.c Tue Feb 18 14:27:22 2003
@@ -763,9 +763,9 @@ PackFile_new(INTVAL is_mapped)
PackFile_Segment_new_seg(pf, PF_BYTEC_SEG, BYTE_CODE_SEGMENT_NAME, 1);
pf-need_wordsize = 0;
pf-need_endianize = 0;
-pf-fetch_op = (opcode_t (*)(opcode_t)) NULL;
-pf-fetch_iv = (INTVAL (*)(INTVAL)) NULL;
-pf-fetch_nv = (void (*)(unsigned char *, unsigned char *)) NULL;
+pf-fetch_op = (opcode_t (*)(opcode_t)) NULLfunc;
+pf-fetch_iv = (INTVAL (*)(INTVAL)) NULLfunc;
+pf-fetch_nv = (void (*)(unsigned char *, unsigned char *)) NULLfunc;
return pf;
}
@@ -868,10 +868,10 @@ pf_register_standard_funcs(struct PackFi
};
struct PackFile_funcs defaultf = {
PackFile_Segment_new,
-(PackFile_Segment_destroy_func_t) NULL,
-(PackFile_Segment_packed_size_func_t) NULL,
-(PackFile_Segment_pack_func_t) NULL,
-(PackFile_Segment_unpack_func_t) NULL,
+(PackFile_Segment_destroy_func_t) NULLfunc,
+(PackFile_Segment_packed_size_func_t) NULLfunc,
+(PackFile_Segment_pack_func_t) NULLfunc,
+(PackFile_Segment_unpack_func_t) NULLfunc,
default_dump
};
struct PackFile_funcs fixupf = {
@@ -893,9 +893,9 @@ pf_register_standard_funcs(struct PackFi
struct PackFile_funcs bytef = {
byte_code_new,
byte_code_destroy,
-(PackFile_Segment_packed_size_func_t) NULL,
-(PackFile_Segment_pack_func_t) NULL,
-(PackFile_Segment_unpack_func_t) NULL,
+(PackFile_Segment_packed_size_func_t) NULLfunc,
+(PackFile_Segment_pack_func_t) NULLfunc,
+(PackFile_Segment_unpack_func_t) NULLfunc,
default_dump
};
struct PackFile_funcs debugf = {
Re: parrot performance vs.(trivial test) the good, the bad, and the ugly
Tupshin Harper wrote: Leopold Toetsch wrote: Did you have an optimized parrot compile? ( make progclean ; perl Configure.pl ... --optimize ; make -s) No I hadn't, but I just did, using those exact commands(no additional options to Configure.pl), and had no perceivable performance change using any of the parrot variances(default, -P, -j). There sould be some advantage for non JIT runloops. ... Is there a way to verify that an optimized build was truly made? Did you expect to see much of any difference? GCC issues(running 3.2.3)? You sould see some -Ox in Makefile's CFLAGS. The 'x' is taken from your perl5 build options. I have now checked in slightly modified versions: - s/mod/cmod/ this is what C has - made a real subroutine in primes2.pasm - omitted printing, only summary - reduced first count to 5. parrot -j is only slightly slower then -O3 primes*.c on my system. $ time imcc -j examples/benchmarks/primes2.pasm N primes calculated to 1 is 1230 last is: 9973 real0m2.219s $ cc -O3 examples/benchmarks/primes2.c time ./a.out real0m1.936s $ time imcc -j examples/benchmarks/primes.pasm real0m3.902s $ cc -O3 examples/benchmarks/primes.c time ./a.out real0m3.497s I don't have the time to give .pl and .py timings here:) (Athlon 800; i386/linux; all -O3; gcc 2.95.2) -Tupshin Thanks for your contributions. leo
Re: parrot performance vs.(trivial test) the good, the bad, and the ugly
[EMAIL PROTECTED] wrote: I think --optimize alone is busted. Probably my fault, when introducing this option. I did test only with --debugging. leo
Re: parrot performance vs.(trivial test) the good, the bad, and the ugly
On Tue, Feb 18, 2003 at 10:58:59PM +0100, Leopold Toetsch wrote: [EMAIL PROTECTED] wrote: I think --optimize alone is busted. Probably my fault, when introducing this option. I did test only with --debugging. No no no. You're supposed to test with -march=... -fomit-frame-pointer -ffancy-math -fuse-lots-of-resources-go-very-fast -fsacrifice-more-goats -fsummon-cthulu-if-that-helps as root at nice -20, preferably in single user mode and jumps should be aligned on pentagrams, not 8 byte boundaries. Definitely not use debugging :-) Nicholas Clark
Re: Arrays, lists, referencing
2) (4, 1, 2) + 7 returns (9). This is C comma behavior, and I always
found it incredibly non-intuitive. I'd really like to get away
from this, even if it means that this expression is a fatal error
Can't add scalar to list.
[...]
Agreed, however, that (2) is icky. My worry has been that removing
C-comma behavior would break common constructs, but I haven't been able
to find any that would really break (except obfuscated ones that would
be better written in some other fashion anyway.) Statements like:
foo() or (warn(blah), next);
work either way, because they don't rely on getting the scalar value
of the list.
One thing that the C comma operator promises is that its left operand
(and all side effects) is completely evaluated before work starts on the
right operand. (This may not be strictly true in the Perl interpretation
of the operator; can a Perl5 developer comment?)
I'm pretty sure that for a Perl list, the order of evaluation of
elements isn't guaranteed, meaning that Cnext may evaluate before
Cwarn in the above example if it were treated exactly like a list.
(Again, can someone refute or support this?)
That said, I don't know of anything that the C comma operator can do
that you couldn't equivalently do with a Perl5 Cdo statement:
foo() or (do { warn(blah); next; }); # Yes, it's ugly.
So I too support the notion that comma should always and only be a list
constructor.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
Chaos, panic, disorder - my work here is done. - button slogan
Re: Arrays, lists, referencing
On Saturday, February 15, 2003, at 08:47 AM, David Storrs wrote: I can see five possible courses here: 1) We decide that my suggestion is a bad one and do nothing with it. That's fine; I am not wedded to it, I just thought it was an interesting idea that I wanted to raise. 2) (4, 1, 2) + 7 returns (9). This is C comma behavior, and I always found it incredibly non-intuitive. I'd really like to get away from this, even if it means that this expression is a fatal error Can't add scalar to list. 3) (4, 1, 2) + 7 returns (10), by adding 7 to the length of the list. This makes lists look even more like arrays, and doesn't really add any new power to the language. 4) (4, 1, 2) + 7 returns (11, 8, 9). This is a convenient shorthand for the vector syntax, IMO. 5) (4, 1, 2) + 7 returns (14). That is, the list is collapsed into a datatype matching the RHS by iteratively applying the operator in question to the list elements, and then the item on the RHS of the operator is applied. I'm not sure this is useful; I'm just exploring options. IMHO the only reasonable possibilities are (2) or (3)... the others are much rarer in practice, and too prone to accidental-invocation-with-baffling-results. Agreed, however, that (2) is icky. My worry has been that removing C-comma behavior would break common constructs, but I haven't been able to find any that would really break (except obfuscated ones that would be better written in some other fashion anyway.) Statements like: foo() or (warn(blah), next); work either way, because they don't rely on getting the scalar value of the list. So, IMO, the only reasonable answer is (3)... that a list in numeric context returns the length. Thus we have consistency between lists and arrays: (1,2,3) + 4 # -- (1,2,3).length + 4 -- 7 (list) [1,2,3] + 4 # -- [1,2,3].length + 4 -- 7 (array ref) my @a = (1,2,3); # @a + 4# -- @a.length + 4 -- 7 (array var) *@a + 4 # -- (*@a).length + 4 -- 7 (list) (@a,@a) + 4 # -- 3 + 3 + 4 -- 10 (list) Alternatively, we could say that using a list in numeric context is a syntax error. This is fine w/ me as well, but pointedly *doesn't* match the array behavior... and would mean the second to last line would also be a syntax error. I think the consistency of behavior probably means (3) wins. MikeL
Re: Arrays, lists, referencing
Michael Lazzaro wrote: So, IMO, the only reasonable answer is (3)... that a list in numeric context returns the length. Thus we have consistency between lists and arrays: (1,2,3) + 4 # -- (1,2,3).length + 4 -- 7 (list) [1,2,3] + 4 # -- [1,2,3].length + 4 -- 7 (array ref) my @a = (1,2,3); # @a + 4# -- @a.length + 4 -- 7 (array var) *@a + 4 # -- (*@a).length + 4 -- 7 (list) (@a,@a) + 4 # -- 3 + 3 + 4 -- 10 (list) Alternatively, we could say that using a list in numeric context is a syntax error. This is fine w/ me as well, but pointedly *doesn't* match the array behavior... I think having them doing different things is reasonable -- they _are_ different. An array is something tangible and as such can have operations on it. A list is something ephemeral, some scalars that happen to be together right now but don't have a collective identity. There can be operations on each of the individual items in a list but having an operation on them as a group seems odd to me. More practically, the length of a list is never interesting: a list by definition must be hardcoded into the program so its length is known at compile time. Indeed it should be known by whoever typed it in! and would mean the second to last line would also be a syntax error. That seems fine by me. I can't see any reason why somebody would type that rather than the version on the line above. I think the consistency of behavior probably means (3) wins. Why should different things behave in the same way? More pragmatically, somebody who has code with an explicitly hardcoded list which is used in scalar context has probably made a mistake -- there are so many better ways (to take the above example) of hardcoding the constant 7 into a program! Why would somebody write out each element of a list just to throw away most of the data and reduce it to an integer? In the case where somebody has made an error -- either a typo, or a conceptual error by somebody still learning the language -- it's much more useful to have a compilation error than for the code run but not yield the desired behaviour. Can somebody come up with a realistic example of where having a list be interpreted as its length is genuinely useful and isn't more easily written using some other syntax? Smylers
Re: Arrays, lists, referencing
On Tue, Feb 18, 2003 at 10:06:29PM -, Smylers wrote: More practically, the length of a list is never interesting: a list by definition must be hardcoded into the program so its length is known at compile time. Indeed it should be known by whoever typed it in! Err, no. Eg in perl 5: $value = (1,2, @ARGV,3,4)[$i] That's a list, and its length is not known at compile time. Dave. -- Nothing ventured, nothing lost.
Re: parrot performance vs.(trivial test) the good, the bad, and the ugly
Hello!
Benchmarks are idiosyncratic and devious and I thank you for starting a
comparison whose results interest me greatly. =]
On Tue, 2003-02-18 at 10:03, Tupshin Harper wrote:
[...]and some are in languages I am less then fluent in
(last touched any flavor of assembly in 1985, and barely touched it
then), so be kind. I don't believe I'm being too unfair to any of the
languages, though feel free to tell me otherwise.
I looked at the .pl and .py versions and was struck by the very
dissimilar approaches taken in the two. I translated the GOTO-style
primes.pl to a loop syntax in both Perl and Python which I believe
accurately represents the logic of primes.pasm without resorting to
actual GOTO statements[1].
I'd be very curious as to the runtime of these on the system you used
for the earlier benchmarks. On my box, the retooled Python script takes
only approximately 50% of the time used by the earlier Perl version; the
retooled Perl version runs in roughly 30% the time of its Perl
predecessor.
Thanks again for taking this initiative!
--j
[1] Go To Statement Considered Harmful, Edsger W. Dijkstra,
Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148; see
http://www.acm.org/classics/oct95/
--
Jim Meyer, Geek at Large [EMAIL PROTECTED]
#!/usr/bin/env perl
my $i1 = 1;
my $i2 = 1;
printf(\nThe primes up to %d are:\n, $i2);
while ($i1 = $i2) {
my $i3 = 2;
my $i4 = $i1 / 2;
while (1) {
if ($i1 % $i3) {
$i3++;
next if ($i3 = $i4);
print $i1\n;
}
last;
}
$i1++;
}
#!/usr/bin/env python2
i2 = 1
print \nThe primes up to %d are: % i2
for i1 in range(1,i2+1) :
i3 = 2
i4 = i1 / 2
while 1:
if i1 % i3:
i3 += 1
if i3 = i4 : continue
print i1
break
Re: parrot performance vs.(trivial test) the good, the bad, and the ugly
On my system, the perl takes 2.24 second and the python takes 3.76 seconds. You are correct that the 2 versions I send out earlier are *very* different. I started from two places, the primes.pasm which I converted to C and perl versions and a pre-existing primes.py and primes.c that I converted to primes.pasm. My interest was in comparing parrot to other things, so I didn't pay any attention in trying to get comparable perl and parrot ones. Thanks for taking an interest. -Tupshin Jim Meyer wrote: Hello! Benchmarks are idiosyncratic and devious and I thank you for starting a comparison whose results interest me greatly. =] On Tue, 2003-02-18 at 10:03, Tupshin Harper wrote: [...]and some are in languages I am less then fluent in (last touched any flavor of assembly in 1985, and barely touched it then), so be kind. I don't believe I'm being too unfair to any of the languages, though feel free to tell me otherwise. I looked at the .pl and .py versions and was struck by the very dissimilar approaches taken in the two. I translated the GOTO-style primes.pl to a loop syntax in both Perl and Python which I believe accurately represents the logic of primes.pasm without resorting to actual GOTO statements[1]. I'd be very curious as to the runtime of these on the system you used for the earlier benchmarks. On my box, the retooled Python script takes only approximately 50% of the time used by the earlier Perl version; the retooled Perl version runs in roughly 30% the time of its Perl predecessor. Thanks again for taking this initiative! --j [1] Go To Statement Considered Harmful, Edsger W. Dijkstra, Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148; see http://www.acm.org/classics/oct95/
