moving little_languages/ to languages/jako/
would anyone object to moving parrot/little_languages/* to
parrot/languages/jako/? Then we can add the beginnings of the other
compilers to parrot/languages/{perl|ruby|python|Foo|C}
Of course they should have their own repositories at some point, but
right now it seems like they are more for parrot than for anything
else. =)
- ask
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: moving little_languages/ to languages/jako/
[EMAIL PROTECTED] (Ask Bjoern Hansen) writes:
would anyone object to moving parrot/little_languages/* to
parrot/languages/jako/? Then we can add the beginnings of the other
compilers to parrot/languages/{perl|ruby|python|Foo|C}
Of course they should have their own repositories at some point, but
right now it seems like they are more for parrot than for anything
else. =)
(uh, and of course: I would move them directly in the cvs repository
as to preserve the revision history properly).
- ask
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: moving little_languages/ to languages/jako/
On Fri, Oct 05, 2001 at 01:46:44AM -0700, Ask Bjoern Hansen wrote: (uh, and of course: I would move them directly in the cvs repository as to preserve the revision history properly). Go for it. -- It can be hard to tell an English bigot from a monoglot with an inferiority complex, but one cannot tell a Welshman any thing a tall. - Geraint Jones.
Re: moving little_languages/ to languages/jako/
Ask --
would anyone object to moving parrot/little_languages/* to
parrot/languages/jako/? Then we can add the beginnings of the other
compilers to parrot/languages/{perl|ruby|python|Foo|C}
I'd appreciate it if this didn't happen until I commit my latest
Jako changes, which Simon has asked me to hold off on until 0.0.2
is released :(
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc.http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_/
[PATCH] sub-second time_n (+ request for eyeballs)
All --
I was toying with the test.pasm benchmarking file while working with
the Jako compiler. I tried to change time_n to use gettimeofday() to
achieve sub-second resolution. The patch is trivial, but applying it
here causes t/op/time.t to fail on the time_n test.
I copied the test in question to time.pasm (attached separately
hereto), assembled it and ran it through test_prog. Sure enough, I
get a segfault. I wanted to see where it was segfaulting, so I
ran test_prog -t time.pbc, and got this:
$ test_prog -t time.pbc
PC=0; OP=62 (time_n); ARGS=(0)
PC=2; OP=62 (time_n); ARGS=(1)
PC=4; OP=52 (ge_nc_ic); ARGS=(0, 0, 6)
PC=10; OP=24 (print_sc); ARGS=(1)
ok, (!= 1970) Grateful Dead not
PC=12; OP=51 (ge_n_ic); ARGS=(1, 0, 6)
PC=18; OP=24 (print_sc); ARGS=(2)
ok, (nowbefore) timelords need not apply
PC=20; OP=54 (branch_ic); ARGS=(4)
PC=24; OP=0 (end)
$
(no segfault!)
The code paths for test_prog and test_prog -t don't seem *that*
different to me after staring at them for a while. So its official:
I'm puzzled.
I compiled things with cc -g and ran them through gdb, and got
flaming death, but in Parrot_op_print_sc()!
$ gdb test_prog
...
(gdb) run time.pbc
Starting program: /home/gregor/src/parrot-time/test_prog time.pbc
Program received signal SIGSEGV, Segmentation fault.
0x4000d79a in fixup () at eval.c:41
41eval.c: No such file or directory.
in eval.c
(gdb) where
#0 0x4000d79a in fixup () at eval.c:41
#1 0x4000d9b0 in _dl_runtime_resolve () at eval.c:41
#2 0x0804be02 in Parrot_op_print_sc (cur_opcode=0x80612c8,
interpreter=0x8055068) at basic_opcodes.c:622
#3 0x08048da0 in runops_notrace_core (interpreter=0x8055068) at
interpreter.c:66
#4 0x08049006 in runops_generic (core=0x8048d28
runops_notrace_core, interpreter=0x8055068) at interpreter.c:147
#5 0x0804908e in runops (interpreter=0x8055068, code=0x80610d8) at
interpreter.c:172
#6 0x0804ecda in main (argc=2, argv=0xb474) at test_main.c:103
#7 0x40087177 in __libc_start_main (main=0x804e8e0 main, argc=2,
ubp_av=0xb474, init=0x8048904 _init,
fini=0x804ed50 _fini, rtld_fini=0x4000e184 _dl_fini,
stack_end=0xb46c)
at ../sysdeps/generic/libc-start.c:129
(gdb)
Anyone else out there that finds this odd? Better still, anyone out
there that can shed some light on this one?
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc.http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_/
timeN0
timeN1
ge N0, 0, OK1
branch FAIL
OK1:print ok, (!= 1970) Grateful Dead not\n
ge N1, N0, OK2
branch FAIL
OK2:print ok, (nowbefore) timelords need not apply\n
branch OK_ALL
FAIL: print failure\n
OK_ALL:
end
? time.pasm
? time.pbc
? t/op/time2.pasm
? t/op/time2.pbc
? t/op/time2.out
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.31
diff -a -u -r1.31 basic_opcodes.ops
--- basic_opcodes.ops 2001/10/05 11:46:47 1.31
+++ basic_opcodes.ops 2001/10/05 12:06:24
@@ -316,7 +316,9 @@
/* TIME Nx */
AUTO_OP time_n {
- NUM_REG(P1) = time(NULL);
+ struct timeval t;
+ gettimeofday(t);
+ NUM_REG(P1) = (FLOATVAL)t.tv_sec + ((FLOATVAL)t.tv_usec / 100.0);
}
/* PRINT Nx */
Parrot::Smoke 0.02
I just uploaded a new version of Parrot::Smoke to CPAN. Changes: 0.02 Fri Oct 05 06:57:20 2001 - support for sending mail through Net::SMTP - autonfiguration through Makefile.PL should work on Win32 - eliminated --define/--defaults from output Regards Mattia P.S.: sending mail through Net::SMTP is enabled only if none of mail/mailx/sendmail is found, so is used on Win32 only
Re: [PATCH] sub-second time_n (+ request for eyeballs)
At 08:25 AM 10/5/2001 -0400, Gregor N. Purdy wrote: Anyone else out there that finds this odd? Better still, anyone out there that can shed some light on this one? Well, your patch has this: + gettimeofday(t); but the man page I have handy (Solaris 5.something) says: int gettimeofday(struct timeval *tp, void * ); and: The second argument to gettimeofday() and settimeofday() should be a pointer to NULL. Perhaps adding a NULL as a second parameter? Otherwise you'll potentially geek up your stack. (Why there weren't any compiler complaints is a separate questions...) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: moving integer constants to the constant table
Is it safe to say that all the data (the values themsevles - the opcodes and opcode arguments (registers, constants, constant table lookups, jump offsets, etc)) within the bytecode are exactly and invariably 32 bit, but the size of the type that they're stored in may be whatever is comfortable to the platform? That makes 64-32-64 conversions trivial (even accounting for byte order), since 64 bit is simply a sign extension word and the 32 bit value. Hmm, but we do have a mix of signed and unsigned words, which could have an effect if the MSB is set. The header portion may need some work -- Bryan C. Warnock [EMAIL PROTECTED]
Re: [PATCH] sub-second time_n (+ request for eyeballs)
but the man page I have handy (Solaris 5.something) says: int gettimeofday(struct timeval *tp, void * ); and: The second argument to gettimeofday() and settimeofday() should be a pointer to NULL. (wearing my portability hat here . . . ) And, of course, note that gettimeofday() isn't necessarily available on non-Unix systems. However, you can fetch Win32 and VMS emulations from Time::HiRes in bleadperl. Before doing that, however, please explicitly check with the author about the copyright (given the current copyright status of the perl6 effort). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: moving integer constants to the constant table
At 11:12 AM 10/5/2001 -0400, Bryan C. Warnock wrote: Is it safe to say that all the data (the values themsevles - the opcodes and opcode arguments (registers, constants, constant table lookups, jump offsets, etc)) within the bytecode are exactly and invariably 32 bit, but the size of the type that they're stored in may be whatever is comfortable to the platform? Yes, exactly. That makes 64-32-64 conversions trivial (even accounting for byte order), since 64 bit is simply a sign extension word and the 32 bit value. Exactly. Hmm, but we do have a mix of signed and unsigned words, which could have an effect if the MSB is set. I can't think of anything that should be reasonably unsigned that won't fit in a 31 bit value. (No need for sign bits for constant table offsets, but 2 billion constant table entries should be sufficient...) The header portion may need some work Could be, yep. :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] sub-second time_n (+ request for eyeballs)
Dan --
Well, your patch has this:
+ gettimeofday(t);
but the man page I have handy (Solaris 5.something) says:
int gettimeofday(struct timeval *tp, void * );
D'Oh!
OK. Updated patch attached.
Re: Portability, I suppose for now we could make a test for the
presence of gettimeofday() and #define Parrot_gettimeofday() to
it if it is there, else #define it to (FLOATVAL)time() to get
the prior behavior. Smarter solutions could come later...
I haven't learned enough about the configure system to be comfortable
putting those changes in...
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc.http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_/
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.31
diff -a -u -r1.31 basic_opcodes.ops
--- basic_opcodes.ops 2001/10/05 11:46:47 1.31
+++ basic_opcodes.ops 2001/10/05 15:37:03
@@ -316,7 +316,9 @@
/* TIME Nx */
AUTO_OP time_n {
- NUM_REG(P1) = time(NULL);
+ struct timeval t;
+ gettimeofday(t, NULL);
+ NUM_REG(P1) = (FLOATVAL)t.tv_sec + ((FLOATVAL)t.tv_usec / 100.0);
}
/* PRINT Nx */
RE: moving integer constants to the constant table
Bryan wrote -- The header portion may need some work I'm a little confused by what this means...is this something the patch can address? Tanton
Twist and shout
All --
In the interest of completely twisting your brain...
Imagine what this piece of code could do:
clear C1
const C1, I1, Hello,
const C1, I2, world!\n
const C1, I3, :CORE
const C1, I4, print_sc
const C1, I5, ret
push C1, I6, I3, I4, I1
push C1, I6, I3, I4, I2
push C1, I6, I3, I5
call C1, 0
pack S1, C1
unpack C2, S1
call C2, 0
setC3, C1
call C3, 0
end
Some explanation:
* Registers C0-C31 contain code (CV's)
* clear_c Cx initializes register Cx to undef (but as soon as
write to it, it autovivifies)
* const Cx, Iy, sc Allocates a new constant in Cx, sets
its value to sc and puts the index in Iy. Perhaps that
should read const Iy, Cx, sc to follow the dest-rest
arg ordering standard...
* push Cw, Ix, Iy, Iz, ... pushes an op (code Iy:Iz + args ...) at the
end of the bytecode stream for code Cw and returns the
offset where the next op will go in Ix.
Some elaboration:
* push_c_i_i_i_v has to be a varop (see my recent posting with
print_s_v.
It takes the 'library' ('CORE' for builtins) and 'entry' strings
as indexes into the constant table, finds the op and links the
op to the CV's opcode_table (see below), then it writes the
opcode and args to the bytecode stream.
* call_c_ic makes the indicated code object active, and starts the
pc off at the designated index.
* pack and unpack on CVs do what you would expect from having
seen packfile.[hc]. These can be used by a loader written in
Parrot assembly (!) if desired.
Load-time op binding:
* Consider having the opcode_table not belong to the interpreter,
but rather to the CV.
* On disk, the CV has a segment containing the library-entry
pairs it uses (IV-IV pairs indexing into the const_table).
Of course, CORE::end is always at position zero.
* At load time, this opcode_table is read and ops are found.
The loader builds a opcode_func_table as the ops are found.
* Library dependancies can be captured in a depend_table of
name-version (IV-IV const_table indexes) pairs and the loader
can attempt to load them before doing the op lookups.
* We need an entry_table of IV-IV pairs where the first is
the name of the entry and the second is the local-PC where
that entry starts (so we can implement ops and general
linking in Parrot).
* So, we *do* pay to lookup ops at load time, but for smaller
programs (where we care more), there will be fewer ops to
look up.
* Each program contains a full list of all the ops it (statically)
uses.
* We are free to play all sorts of games with ops over time,
since they are referred to by name (just don't reuse a name
with different semantics!)
Attributes:
* We may want to allow a general attributes section. Again, this
is just a set of attr-value (IV-IV indexes into const_table)
pairs. I like keeping this separate from the const_table. Any
fingerprinting could go on here (although the above kind of
makes that unnecessary).
Generally, I think making Parrot completely introspective like this
has big benefits for dynamic stuff. It is very natural to write
all kinds of on-the-fly code generators if we can have full access
to the guts of the CV with Parrot ops (these ops, presumably, could
be part of the :CODE oplib, not the :CORE oplib -- I'm using
leading colons here as reserved for official Parrot libs).
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc.http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_/
Re: moving integer constants to the constant table
On Friday 05 October 2001 12:02 pm, Gibbs Tanton - tgibbs wrote: Bryan wrote -- The header portion may need some work I'm a little confused by what this means...is this something the patch can address? Oh, sorry, no. Just thinking aloud about how the header information - from the magic word through metadata and the constant table - would need to be handled across platforms of different sizes. Constant table lookups, for example, would have to adjusted by the size differences. There may be alignment issues as well. (Reading 12 byte FLOATVALs on a 16 byte FLOATVALs machine whose alignment is 8, for instance. [1]) [1] Except floats are horrendously non-portable anyway, so that's probably a very bad example. -- Bryan C. Warnock [EMAIL PROTECTED]
[COMMIT] Enhanced Jako compiler goes in!
All -- Here's the details from the commit log: * Compiler: * User-defined subroutines. * Generates assembly code with the Jako code in comments. * end; no longer required at the end of programs. * Better handling of const-reg and reg-const. * Optimizes const-const operations to compile-time evaluations. * Constants in addition to variables. * Arithmetic fixes. * Allow leading minus signs in integer and number constants (ahem). * goto's. * New sample programs: * leibniz.jako (based on Greg McCarroll's leibniz.pasm example) * mandelbrot.jako (based on Leon Brocard's translation of Glenn Rhodes' C code) * mops.jako (based on t/test.pasm) * primes.jako (based on Leon Brocard's primes.pasm example) * sub.jako (demonstrates a simple user-defined subroutine) Have the appropriate amount of fun... Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
Re: moving integer constants to the constant table
At 12:47 PM 10/5/2001 -0400, Bryan C. Warnock wrote: [1] Except floats are horrendously non-portable anyway, so that's probably a very bad example. Horrendously non-portable. I think I've docs for at least a half-dozen different formats... :( Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] forcing packfile to opcode_t.
At 12:05 AM 10/5/2001 -0400, Bryan C. Warnock wrote: On Thursday 04 October 2001 11:40 pm, Gibbs Tanton - tgibbs wrote: Well, that obviously should be MAX_whatever and MIN_whatever. But sufficient for now, since that's probably a configure thing. Yes and No. If our inline constants are always going to be 32 bits then 2 ** 31 should always work (of course I shouldn't do it in such an ugly fastion, but a constant should work ). Oh, crap. Crap, crap, crap, crap, crap. *I* annoyed Dan with this question pointedly, Nope, you didn't. You had a very specific question, but it certainly wasn't an annoyance. Crap, crap, crap, crap, crap. Sorry, Dan. Not a problem. If I'd been specific with this in the first place there wouldn't be the confusion we see now. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Twist and shout
At 12:40 PM 10/5/2001 -0400, Gregor N. Purdy wrote: * Registers C0-C31 contain code (CV's) At the moment I'm not leaning towards special registers for code. Subs will just be another type of PMC, and use the PMC registers. * push_c_i_i_i_v has to be a varop (see my recent posting with print_s_v. Nope. No vararg ops! :) * Consider having the opcode_table not belong to the interpreter, but rather to the CV. It'll belong to the compilation unit. Generally, I think making Parrot completely introspective like this has big benefits for dynamic stuff. We'll be introspective, but probably differently. We at least need to do things in ways both perl and python can easily stomach, and I think that's going to end up looking different than this will. Neat ideas, though. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Twist and shout
Dan Sugalski writes: * push_c_i_i_i_v has to be a varop (see my recent posting with print_s_v. Nope. No vararg ops! :) It might help forestall future flamewars if you explained why. We'll be introspective, but probably differently. We at least need to do things in ways both perl and python can easily stomach, and I think that's going to end up looking different than this will. Do you have any current thinking on how this will work, or is that a bridge you'll burn when you get to it? :-) Nat
Re: Twist and shout
NT == Nathan Torkington [EMAIL PROTECTED] writes: NT Dan Sugalski writes: * push_c_i_i_i_v has to be a varop (see my recent posting with print_s_v. Nope. No vararg ops! :) NT It might help forestall future flamewars if you explained why. this has been covered several times before. for speed reasons alone dan wants the op to return the address of the next op and not have to calculate it. also that means that the conversion to TIL is simpler and arg handling is easier since the number of args is known quickly and is fixed. language level var arg type calls will be passed a single arg ref to a list. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
Re: Twist and shout
At 01:33 PM 10/5/2001 -0600, Nathan Torkington wrote: Dan Sugalski writes: * push_c_i_i_i_v has to be a varop (see my recent posting with print_s_v. Nope. No vararg ops! :) It might help forestall future flamewars if you explained why. *) Sheer personal preference, which I realize is a lousy reason. (But better to be up front about it, I suppose) *) Varargs make it more work to figure out where the next op is if you're scanning the op stream *) It chews up registers awfully quickly, with little benefit over throwing things in a list *) You have no easy way, at runtime, for an op to figure out for sure how many things it was passed. I fear we'll end up with something like C's fscked-beyond-rationality vararg system if we don't impose more order on things now. We'll be introspective, but probably differently. We at least need to do things in ways both perl and python can easily stomach, and I think that's going to end up looking different than this will. Do you have any current thinking on how this will work, or is that a bridge you'll burn when you get to it? :-) There'll be some way to get access to a sub's opcode stream, scopes, and suchlike stuff from the parrot level, but beyond that... well, I have my matches, and I'm on the lookout for a bridge. ;-P Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Twist and shout
Dan -- * Registers C0-C31 contain code (CV's) At the moment I'm not leaning towards special registers for code. Subs will just be another type of PMC, and use the PMC registers. Special C* regs or P* regs with CV values both work fine for what I'm talking about (I refuse to actually call it a proposal :). * push_c_i_i_i_v has to be a varop (see my recent posting with print_s_v. Nope. No vararg ops! :) Stay tuned for my reply to the followups... * Consider having the opcode_table not belong to the interpreter, but rather to the CV. It'll belong to the compilation unit. Yay! This is exactly what I was hoping. Generally, I think making Parrot completely introspective like this has big benefits for dynamic stuff. We'll be introspective, but probably differently. We at least need to do things in ways both perl and python can easily stomach, and I think that's going to end up looking different than this will. What I'm looking for is a reasonable way for Parrot native stuff to construct CVs on the fly, and to link to various op libraries in a simple and very dynamic way (that hopefully doesn't cost any more at run time than what we currently have). Neat ideas, though. Thanks. I was going for the overall vision of what can be done more than the specific implementation, though I will have some comments on specifics in replies to come. Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
Re: Twist and shout
Uri -- NT Dan Sugalski writes: * push_c_i_i_i_v has to be a varop (see my recent posting with print_s_v. Nope. No vararg ops! :) NT It might help forestall future flamewars if you explained why. this has been covered several times before. for speed reasons alone dan wants the op to return the address of the next op and not have to calculate it. also that means that the conversion to TIL is simpler and arg handling is easier since the number of args is known quickly and is fixed. If you look at my previous varop example patch, or look at the one I'm nearing completion of, you'll see that speed is not a factor in go/no go for varops. From the perspective of the DO_OP loop, ops are of different sizes. True, most of them return a constant, but there is no global speed penalty for having those that are varops return something that is calculated (typically the extra cost is a fetch and an add, which for any but the most trivial ops would be radiation). Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
Re: Twist and shout
We'll be introspective, but probably differently. We at least need to do things in ways both perl and python can easily stomach, and I think that's going to end up looking different than this will. And ruby ;-) Benoit
[PATCH Configure, etc.] Better VMS support and test.c goodness
Patch below my sig does three things:
*makes sure that *all* the VMS-specific stuff is in the VMS hints file
*makes test.c return a chunk of eval-able code
*makes test.c return several more sizeof() results (for types like
int, double...)
I especially need the VMS bits tested, as I don't have a VMS system
available to check them on. (Dan, did you see my e-mail about this
patch and haven't replied yet, or did you miss it?)
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
--- ..\..\parrot-cvs\parrot\Configure.plThu Oct 4 23:04:36 2001
+++ Configure.plThu Oct 4 23:01:40 2001
@@ -88,7 +88,7 @@
);
#copy the things from --define foo=bar
-@c{keys %opt_defines}=@opt_defines{keys %opt_defines};
+@c{keys %opt_defines}=values %opt_defines;
# set up default values
my $hints = hints/ . lc($^O) . .pl;
@@ -133,22 +133,17 @@
a small C program. This could take a bit...
END
-buildfile(test_c);
-if ($^O eq 'VMS') {
- system($c{cc} $c{ccflags} test.c) and die C compiler died!;
- system(link/exe=test_siz test) and die Link failed!;
-} else {
- system($c{cc} $c{ccflags} -o test_siz$c{exe} test.c) and die C
compiler died!;
-}
-if ($^O eq 'VMS') {
- (@c{qw(intvalsize longsize numvalsize opcode_t_size)})=split('/',
`mcr []test_siz`);
-} else {
- (@c{qw(intvalsize longsize numvalsize opcode_t_size)})=split('/',
`./test_siz$c{exe}`);
+{
+ my %newc;
+
+ buildfile(test_c);
+ compiletestc();
+ %newc=eval(runtestc()) or die Can't run the test program: $!;
+
+ @c{keys %newc}=values %newc;
+
+ unlink('test.c', test_siz$c{exe}, test$c{o});
}
-die Something wicked happened!
-unless defined $c{intvalsize} and defined $c{longsize} and
- defined $c{numvalsize} and defined $c{opcode_t_size};
-unlink('test.c', test_siz$c{exe}, test$c{o});
print END;
@@ -297,3 +292,11 @@
END
}
}
+
+sub compiletestc {
+ system($c{cc} $c{ccflags} -o test_siz$c{exe} test.c) and die C
compiler died!;
+}
+
+sub runtestc {
+ `./test_siz$c{exe}`
+}
--- ..\..\parrot-cvs\parrot\test_c.in Thu Oct 4 23:04:38 2001
+++ test_c.in Thu Oct 4 23:01:08 2001
@@ -8,8 +8,23 @@
#include stdio.h
int main(int argc, char **argv) {
- printf(%d/%d/%d/%d,
- sizeof(${iv}), sizeof(long), sizeof(${nv}),
sizeof(${opcode_t}));
+ printf(();
+
+ printf(\tintvalsize = %d,\n, sizeof(${iv}));
+ printf(\tnumvalsize = %d,\n, sizeof(${nv}));
+ printf(\topcode_t_size = %d,\n, sizeof(${opcode_t}));
+
+ printf(\tshortsize = %d,\n, sizeof(short));
+ printf(\tintsize = %d,\n,sizeof(int));
+ printf(\tlongsize = %d,\n, sizeof(long));
+
+ printf(\tptrsize = %d,\n,sizeof(void*));
+
+ printf(\tfloatsize = %d,\n, sizeof(float));
+ printf(\tdoublesize = %d,\n, sizeof(double));
+
+ printf(););
+
return 0;
}
--- ..\..\parrot-cvs\parrot\hints\vms.plThu Oct 4 13:17:58 2001
+++ hints\vms.plThu Oct 4 22:56:08 2001
@@ -1 +1,14 @@
$c{ccflags} =
/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList/NOANSI_ALIAS/include=
[.include];
+
+{
+ local $^W; #no warnings on redefinition
+
+ *compiletestc=sub {
+ system($c{cc} $c{ccflags} test.c) and die C compiler
died!;
+ system(link/exe=test_siz test) and die Link failed!;
+ };
+
+ *runtestc=sub {
+ `mcr []test_siz`
+ };
+}
Re: [PATCH Configure, etc.] Better VMS support and test.c goodness
At 03:07 PM 10/5/2001 -0700, Brent Dax wrote: (Dan, did you see my e-mail about this patch and haven't replied yet, or did you miss it?) I saw it, but it fell into the bottomless pit that is my in-box. I'll try and look at it tonight or tomorrow. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Test::...
Explain to me again why we can't move the Test directory so that make test works on Cygwin? Can't we just 'use lib'? What's the dependency? Grant M.
Re: Test::...
Grant -- Explain to me again why we can't move the Test directory so that make test works on Cygwin? Can't we just 'use lib'? What's the dependency? Grant M. I would love to see both Test and Parrot move under a new directory lib, so that if we find cause to add more modules that don't start with Parrot:: or Test::, we don't pollute the project's root directory. Ask? What do you think of this little bit of reorg? Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
Perl6 Tinderbox
Because the need for a tinderbox testing platform is fairly urgent right now for perl6, I am releasing my (place your favorite adjective in the blank here) tinderbox client for perl6 ahead of the near-rewrite that I am working on to use Devel::Tinderbox::Reporter (which was just written) and Test::Smoke (which wouldn't help perl6 all that much anyway. First of all, what is really needed urgently is clients, both windows and unix os's. Also, those on rare os's: please please please be a client. You can run the tinderbox client software using a low priority if you wish, though it will not clbr the build dir so no rebuilding will occur if nothing has changed. To get the client scripts, grab Z/ZL/ZLIPTON/Devel-Tinderclient-1.1.tar.gz from CPAN. At the moment (pending the rewrite) it does not follow the standard module installation format, so simply untargzip the archive. Take a quick peek at the README and then run: cp sample_config/Tinderconfig.cvs.pm Tinderconfig.pm Then edit Tinderconfig.pm to reflect your configuration. Just run nohup tinderbox.pl to start the client from there. Windows users will have to edit Tindermail.pm to reflect your mail setup. In terms of dev stuff, you can go to http://tinderbox.perl.org/cgi-bin/tinderbox/showbuilds.cgi?tree=perl6 (soon to be just tinderbox.perl.org) and see the build status (notice how empty it is now?) I'll have some more details there soon, but green means all ok, orange means tests failed, red means compile failed, and yellow means building. Let me know if you have any questions. Zach
Re: Test::...
From the .02 version, downloaded 8pm EST ||vanveen@parrot|| assemble.pl t/test.pasm test.pbc Invalid type in pack: '!' at Parrot/Types.pm line 50. BEGIN failed--compilation aborted at Parrot/Assembler.pm line 36. BEGIN failed--compilation aborted at ./assemble.pl line 9. Removing the '!'s from my %pack_type = ( i = q/l!/, n = q/d/, op = q/l!/, ); Made it happy. Why were they there? Michael -- Michael Fischer 7.5 million years to run [EMAIL PROTECTED]printf %d, 0x2a; -- deep thought
Re: Perl6 Tinderbox
On Fri, Oct 05, 2001 at 05:18:07PM -0700, Zach Lipton wrote: Because the need for a tinderbox testing platform is fairly urgent right now for perl6, I am releasing my (place your favorite adjective in the blank here) tinderbox client for perl6 ahead of the near-rewrite that I am working on to use Devel::Tinderbox::Reporter (which was just written) and Test::Smoke (which wouldn't help perl6 all that much anyway. There's an existing Parrot::Smoke module, I forget where it is off hand. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One That which stirs me, stirs everything. -- Squonk Opera, Spoon
Re: Perl6 Tinderbox
On 10/5/01 5:58 PM, Michael G Schwern [EMAIL PROTECTED] wrote: On Fri, Oct 05, 2001 at 05:18:07PM -0700, Zach Lipton wrote: Because the need for a tinderbox testing platform is fairly urgent right now for perl6, I am releasing my (place your favorite adjective in the blank here) tinderbox client for perl6 ahead of the near-rewrite that I am working on to use Devel::Tinderbox::Reporter (which was just written) and Test::Smoke (which wouldn't help perl6 all that much anyway. There's an existing Parrot::Smoke module, I forget where it is off hand. I figured it had to exist. Why don't we use what we have for the moment and then roll out the new client with Devel::Tinderbox::Reporter soon? Zach
Re: Perl6 Tinderbox
On 10/5/01 5:58 PM, Michael G Schwern [EMAIL PROTECTED] wrote: On Fri, Oct 05, 2001 at 05:18:07PM -0700, Zach Lipton wrote: Because the need for a tinderbox testing platform is fairly urgent right now for perl6, I am releasing my (place your favorite adjective in the blank here) tinderbox client for perl6 ahead of the near-rewrite that I am working on to use Devel::Tinderbox::Reporter (which was just written) and Test::Smoke (which wouldn't help perl6 all that much anyway. There's an existing Parrot::Smoke module, I forget where it is off hand. I figured it had to exist. Why don't we use what we have for the moment and then roll out the new client with Devel::Tinderbox::Reporter soon? Also, I don't see any clients running yet, if you are having a problem, please let me know so I can fix it! Zach
@ undocumented?
Am I correct that '@' in the assembly syntax is undocumented? The only place I could find it was in source comments in Parrot::Assembler. I had to search for @ to find it. Believe me, the last thing you want to search for in a Perl module is @. I think a patch to docs/parrot_assembly.pod would be appropriate. Sound good? -sam
[COMMIT] opcode_t cleanup and process_opfunc.pl cleanup
I have committed the two patches I posted recently. Unfortunately, I was stupid and forgot to do make before make test; therefore I thought it didn't work, freaked out, and undid the commit. Then, I figured out my mistake and recommitted the patch. Here are the comments from the cvs log This patch ensures that all bytecode is of type opcode_t except for the constant table constants. That means that almost all of the INTVALs in the code were replaced with opcode_t and the i pack type was replaced with the op pack type in calls to pack_arg and such. Also, since it has been declared that ALL integer constants are to be 32 bits, some test cases were changed to ensure that an integer constant was no bigger than 2 ** 31. process_opfunc.pl was also cleaned up to no longer look at either opcode_table or interp_guts.h but gather all of its information from Opcode.pm. The Assembler.pm module was changed to do late binding of arguments so that 0 could be treated like 0.0 without having to be so declared. Also, only strings now use the [sc:N] intermediate form as it was unneccesary for integer and float types. -- One thing I fogot to put in the log was that (INTVAL) casts of memory are now (ptrcast_t) which is typedefed in config.h to be size_t. If you have any problems with this patch let me know and I will revert (again). Tanton
Re: Perl6 Tinderbox
On Fri, 5 Oct 2001, Zach Lipton wrote: Also, I don't see any clients running yet, if you are having a problem, please let me know so I can fix it! uh, it didn't work for me when I nohup'ed it (it made blank reports). other than that, then I have clients on Linux and FreeBSD going. Mac OS X will run if I can make it work properly when it only runs when I happen to have the powerbook on. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: [perl6]Re: Perl6 Tinderbox
Wow, great! I'm not sure about the nohup issue, but I'm looking into it. We really could use some windows clients and some rare platforms (vms? Etc) Any help you can give would be great. I'll put out a call for clients on perl-qa as well. Zach On 10/5/01 6:53 PM, Ask Bjoern Hansen [EMAIL PROTECTED] wrote: On Fri, 5 Oct 2001, Zach Lipton wrote: Also, I don't see any clients running yet, if you are having a problem, please let me know so I can fix it! uh, it didn't work for me when I nohup'ed it (it made blank reports). other than that, then I have clients on Linux and FreeBSD going. Mac OS X will run if I can make it work properly when it only runs when I happen to have the powerbook on. - ask
Re: @ undocumented?
On Fri, 5 Oct 2001, Sam Tregar wrote: Am I correct that '@' in the assembly syntax is undocumented? Sounds like it. What's the thing do? I think a patch to docs/parrot_assembly.pod would be appropriate. Sound good? Probably the place at the moment. (It really needs to be split into a user and implementor version at some point) Dan
PMC Questions
As 0.0.3 will be about PMC's, we might as well start hashing out the details. I'd like to take a small example and look at how it should work. add P1, P2, P3 This should take the PMC in register P2 and add it to the PMC in register P3 and store the result in register P1. To do this, it needs to call the add function in P2's vtable, correct? How will the interpreter know what entry has the add function. Will it directly mimic the main interpreter vtable? If so, it seems like an awful waste of space as the PMC might not overload but a couple of those functions (or does a PMC always have to overload all of the functions)? Also, what about GC. Will that come into play during 0.0.3? Thanks! Tanton
More speed trials
Holding steady. As a lark, I wrote the functionality of test.pasm (the time test) in Perl, and ran it under 5.6.1. (Keep it mind, you've got variables that you're fetching and storing to.) Parrot Assembler (with the time_n patch, since the elapsed time is so small. The comma delimeters are mine): Iterations: 100,000,000 Start time: 1002342433.400218 End time: 1002342442.858994 Count: 100,000,000 Elapsed time:9.458776 Estimated ops:300,000,000 Ops/sec:31,716,577.291820 9.370u 0.010s 0:09.46 99.1% 0+0k 0+0io 173pf+0w Perl 5.6.1 Perl: Iterations: 100,000,000 Start time: 1002342340 End time: 1002342416 Count: 100,000,000 Elapsed time: 76 Estimated ops:300,000,000 Ops/sec: 3,947,368.42105263158 75.890u 0.020s 1:15.94 99.9%0+0k 0+0io 324pf+0w Now, if we actually count how many ops it really is: (-MO=Terse and test_prog -t) Parrot: 300,000,009 ops = 31,712,475 ops/sec Perl 5.6.1: 1,400,000,026 ops = 18,435,607 ops/sec You may draw your own conclusions. Mine is... we're not fast enough. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: [perl6]Re: Perl6 Tinderbox
On Fri, 5 Oct 2001, Zach Lipton wrote: Wow, great! I'm not sure about the nohup issue, but I'm looking into it. We really could use some windows clients and some rare platforms (vms? Etc) I'll see about setting up cygwin in a bit. I also changed the urls a bit and made http://tinderbox.perl.org/ itself work; hope you don't mind. http://tinderbox.perl.org/ http://tinderbox.perl.org/parrot http://tinderbox.perl.org/perl5 Zach, we should rename perl6 to parrot and perl to perl5. Can you do that and make it still work for my perl6 clients for now? :-) How about setting up bonsai? - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: PMC Questions
On Oct 05, Gibbs Tanton - tgibbs [EMAIL PROTECTED] took up a keyboard and banged out As 0.0.3 will be about PMC's, we might as well start hashing out the details. I'd like to take a small example and look at how it should work. add P1, P2, P3 This should take the PMC in register P2 and add it to the PMC in register P3 and store the result in register P1. To do this, it needs to call the add function in P2's vtable, correct? How will the interpreter know what entry has the add function. Will it directly mimic the main interpreter vtable? If so, it seems like an awful waste of space as the PMC might not overload but a couple of those functions (or does a PMC always have to overload all of the functions)? For that matter, I can't find where a struct _vtable is defined... Michael -- Michael Fischer 7.5 million years to run [EMAIL PROTECTED]printf %d, 0x2a; -- deep thought
Re: [perl6]Re: Perl6 Tinderbox
I'll look into bonsai, that will take some work on the cvs server end and some more effort all the way around, it needs to be done though. Thanks for the url fixes. In terms of the renaming, I'll need to hack some stuff in the scripts so you can still use it the way it was, I'll be at the Apple Store opening tomorrow in Palo Alto, but I'll get to it as soon as possible. Thanks, Zach On 10/5/01 9:57 PM, Ask Bjoern Hansen [EMAIL PROTECTED] wrote: On Fri, 5 Oct 2001, Zach Lipton wrote: Wow, great! I'm not sure about the nohup issue, but I'm looking into it. We really could use some windows clients and some rare platforms (vms? Etc) I'll see about setting up cygwin in a bit. I also changed the urls a bit and made http://tinderbox.perl.org/ itself work; hope you don't mind. http://tinderbox.perl.org/ http://tinderbox.perl.org/parrot http://tinderbox.perl.org/perl5 Zach, we should rename perl6 to parrot and perl to perl5. Can you do that and make it still work for my perl6 clients for now? :-) How about setting up bonsai? - ask
Cleanup
I've done some VERY minor cleanup of a couple of files, removing unused variables and such from Opcode.pm, removing an unused typedef print from make_op_header.pl and changing intval to op in disassemble.pl. I also fixed a typo I did in Assembler.pm. Tanton
RE: More speed trials
I think that changing from a function based implementation to a switch based implementation will help on many platforms. Someone did a patch on that, maybe we could update it and commit it. Having to go through two indirections and two array accesses to access a register probably doesn't help much either, although it won't be easy to get around that. Apart from that, there is not much else to be done. We can reprofile, but the only thing being executed are integer additions and comparisons...you can't get much more basic than that...and you are right, we are running much too slowly. Tanton -Original Message- From: Bryan C. Warnock To: [EMAIL PROTECTED] Sent: 10/5/2001 11:44 PM Subject: More speed trials Holding steady. As a lark, I wrote the functionality of test.pasm (the time test) in Perl, and ran it under 5.6.1. (Keep it mind, you've got variables that you're fetching and storing to.) Parrot Assembler (with the time_n patch, since the elapsed time is so small. The comma delimeters are mine): Iterations: 100,000,000 Start time: 1002342433.400218 End time: 1002342442.858994 Count: 100,000,000 Elapsed time:9.458776 Estimated ops:300,000,000 Ops/sec:31,716,577.291820 9.370u 0.010s 0:09.46 99.1% 0+0k 0+0io 173pf+0w Perl 5.6.1 Perl: Iterations: 100,000,000 Start time: 1002342340 End time: 1002342416 Count: 100,000,000 Elapsed time: 76 Estimated ops:300,000,000 Ops/sec: 3,947,368.42105263158 75.890u 0.020s 1:15.94 99.9%0+0k 0+0io 324pf+0w Now, if we actually count how many ops it really is: (-MO=Terse and test_prog -t) Parrot: 300,000,009 ops = 31,712,475 ops/sec Perl 5.6.1: 1,400,000,026 ops = 18,435,607 ops/sec You may draw your own conclusions. Mine is... we're not fast enough. -- Bryan C. Warnock [EMAIL PROTECTED]
acceptable development environments/tools...?
Hello there, Sorry to disrupt your discussion with some loosely related question... Could anyone help me determine which development tools/IDEs are to be used when hacking at Parrot? As you'd have guessed it, I'm relatively new to this project... ;-). However, I do want to help out with the effort to code a great 'system' that any other developer could benefit from (including myself :). Say, at home, I'm working on a Windows (ME) system. The IDEs I have at my disposal are the MS Visual Studio (C++), CodeWarrior, and some old DOS based C compilers. I've got CVS all set up on my side so retrieving recent copy of the working files from the Parrot cvs root shouldn't be of a problem. I'm also thinking of moving to a Unix based system in a short while (since I've used to coding on a Solaris box at work). Thanks tons for your help (in advance! :), I'd greatly appreciate it! Cheers, Vladimir Bogdanov.
