Automated smoke report for patch Oct 31 20:00:02 2001 UTC
v0.02 on hpux using cc version B.11.11.02
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: - = unknown
c = Configure, m = make, t =
On Thu, Nov 01, 2001 at 10:31:07AM -0500, Dan Sugalski wrote:
> So it looks like about a 2.5 speedup with computed goto. Cool.
Looks really good to me, too. Where's the patch? This should probably
go in as an alternate runops core.
--
The problem with big-fish-little-pond situations is that you
At 03:34 PM 11/1/2001 +, Leon Brocard wrote:
>Dan Sugalski sent the following bits through the ether:
>
> > For the Java-impaired (i.e. me :) what's the -Xint option do?
>
>It turns off the JIT (which is enabled by default).
Ah, thanks. Much as I hate it (because the numbers are so lousy) I t
On Sat, Oct 27, 2001 at 04:23:48PM +0100, Tom Hughes wrote:
> The encoding_lookup() and chartype_lookup() routines will obviously
> need to load the relevant libraries on the fly when we have support
> for that.
Could you try rewriting them using an enum, like the vtable stuff and
the original st
At 01:12 AM 11/1/2001 -0500, Jeff wrote:
>Added features:
>
>1) 'alloci(i,i|ic)' - Allocates $2 integers, sets $1 to a "reference" to
>the new arena
>2) 'freei(i)' - Frees the arena referenced by $1
>3) 'savei(i,i,i|ic)' - Saves the integer register at $1 into arena $2,
>at index $3
>4) 'loadi(i,i
OK then, here is the patch, of course I don't expect this to be commited
since it's crap but if you test it (please do it) and it's ok for everyone
I will rewrite it more efficiently.
*PLEASE* test it and give me some feedback.
Thanks in advance.
On Thu, 1 Nov 2001, Simon Cozens wrote:
> On Th
Look, now I'm rewriting a patch for pbc2c.pl which will use computed goto
*ONLY* in a few ops like jump or ret (or any other that modifies the
program flow) in all other cases it will stay with the actual goto model
which is ,in my opinion, the fastest.
# ./mops
Iterations:1
Estimated
> My intial impression is that a page should be 1024 bytes (though I'm also
> looking at 512 bytes to reduce the shotgun effect of 8-byte allocs).
> I've actually found that "q-caches" were detramental to things like
> conslidation, and the calling depth (overhead) of a worst-case allocation.
> S
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 27, 2001 at 04:23:48PM +0100, Tom Hughes wrote:
> > The encoding_lookup() and chartype_lookup() routines will obviously
> > need to load the relevant libraries on the fly when we have support
> > for that
On Thu, Nov 01, 2001 at 02:18:17PM +, Tom Hughes wrote:
> > Could you try rewriting them using an enum, like the vtable stuff and
> > the original string encoding stuff does?
>
> Allocating them globally is not possible if we're going allow people
> to add arbitrary encodings and character se
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> As things stand, that won't work, because you're doing a string lookup in one
> of the core functions, and you still need some way of registering incoming
> stuff. With an enum, you can keep hold of a fake encoding_m
At 09:45 PM 10/31/2001 -0300, Daniel Grunblatt wrote:
>I have tested times using computed goto in the interpreter and here are
>the results:
>
># ./test_prog mops.pbc
>M op/s:34.864582
>
># java -Xint mops
>M op/s:30.950170356876555
>
>Just for the records, this is with the current
Daniel Grunblatt wrote:
> I have tested times using computed goto in the interpreter and here are
> the results:
>
> # ./test_prog mops.pbc
> Iterations:1
> Estimated ops: 3
> Elapsed time: 8.604721
> M op/s:34.864582
Yes, I wrote a poor-man's computed goto versio
Dan Sugalski sent the following bits through the ether:
> For the Java-impaired (i.e. me :) what's the -Xint option do?
It turns off the JIT (which is enabled by default).
Leon
--
Leon Brocard.http://www.astray.com/
Nanoware...http://www.
Jeff --
Thanks. Applied.
NOTE: flags issue not solved.
Regards,
-- Gregor
On Tue, 2001-10-30 at 22:58, Jeff wrote:
> Implements the following instructions:
>
> 1) open(i|ic,i|ic,s|sc) - Filehandle in $1, r/w mode in $2 (permissions
> 644), filename in $3
> 2) read(s,i|ic,i|ic) - String regi
Richard --
Thanks. Applied.
NOTE: I put the code in time.c in a function Parrot_floatval_time().
Some Win32 person please see if that can be made to work. Patches
to make it actually work are hereby solicited.
Regards,
-- Gregor
On Thu, 2001-11-01 at 16:48, Richard J Cox wrote:
> Current ge
> void gettimeofday(struct timeval* pTv, void *pDummy);
> {
> SYSTEMTIME sysTime;
> FILETIME fileTime;/* 100ns == 1 */
> LARGE_INTEGER i;
>
> GetSystemTime(&sysTime);
> SystemTimeToFileTime(&sysTime, &fileTime);
> /* Documented as the way to get a 64 bit from a FIL
I just noticed that we're not using any tags in the CVS tree. Do you think
that we're at a state where we could start applying labels to our code. I am
considering two types of labels. One for the periodic snapshots (so as to
back-trace features in those files), and one for successful smoke-
Hi all,
I have developed some adittions that give Parrot a limited
amount of support to regular expressions.
It all started as a little experiment to find out what the
"compile down to low-level ops" thing could mean
someday.
The patch consists of:
* 5 new opcodes:
- matchexactly
- ma
At 07:58 PM 11/1/2001 +0100, Angel Faus wrote:
>I am a rather mediocre programmer, and this are the first
>lines of code i ever sent to a mailing list, so please be
>benevolent with me. :)
Looks like your mailer wordwrapped the program pretty badly. Could you try
again as either a context or uni
Current get fails to build on Win32[1]
There are a host of problems (not the least being the object files not
going where the linker is expecting them), then aside the first is the
lack of a gettimeofday function. This is used in time_n.
Here's my Win32 version:
void gettimeofday(struct timev
On Thu, 1 Nov 2001, Gregor N. Purdy wrote:
> We may end up needing to consolidate these platform-isms into a small
> number of files (one?) rather than have them split by type (like I did for
> Parrot_*_time). I don't know if we can get away with something as simple
> as platform.[hc] with all th
Jason Diamond:
# I'm having trouble building the latest parrot sources from
# CVS on Windows
# 2000. The Configure.pl script ran fine but after running
# nmake test_prog.exe
# I'm getting an error while compiling core_ops.c:
#
# core_ops.c(370) : error C2065: 'S_IRUSR' : undeclared identifier
# co
Jason Diamond:
# > Can you give me the output of that time.c compilation? Someone just
# > asked for feedback on how that was working.
#
# It was complaining about SYSTEMTIME not being defined. You
# have to #include
# for that. But that caused a redefinition error
# for BOOL. So I
# renamed the
Dan --
> platform.c and platform.h is exactly what we're going to do. We need a
> platforms directory as well. In there we'll have a win32.[ch], a
> linux.[ch], a vms.[ch], a generic.[ch] and so on. Configure.pl will copy
> the appropriate ones up and rename them platform.c & platform.h, and we'
Brent (and Jason) --
Based on Dan's agreement to the approach, I just checked in the starting
point files for doing this "right". Please have a look and send patches
against those files. As soon as we get config wired up to autoselect the
appropriate platform files, we'll be able to make this All
After downloading a dozen PDF files I've given up.
All I need is the approximate cycle counts for
instructions and address modes.
The particular problem I've got now is deciding
which of these three is the fastest:
movl (%edi,%eax,4),%eax
movl (%edi,%eax),%eax
movl (%edi),%eax
Same wit
I've been playing around with my own RE ops, and I was wondering if
someone can check my logic:
#this should be equivalent to: "afbarz" =~ /f.o*?bar/i
match "afbarz", "i"
RE_1:
goforward RE_END#this gives us the behavior of marching
# forwar
Jason Diamond:
# > # Once I got past that, it couldn't link to
# classes/intclass.obj. After
# > # looking at the output a bit, I found out that intclass.obj is
# > # being written
# > # to the main parrot directory and not into the classes
# > # directory. The option
# > # for CL to specify the o
On Thursday 01 November 2001 09:08 pm, Ken Fox wrote:
> Michael L Maraist wrote:
> [an incredible amount of detailed information that will
> take me weeks to digest...]
>
> This looks like a malloc/free style allocator. Since the whole
> GC system for Parrot is on the table, you don't have to con
Jason --
> I'm trying to build parrot on my Windows 2000 box and am failing when
> compiling core_ops.c with these errors:
>
> core_ops.c(370) : error C2065: 'S_IRUSR' : undeclared identifier
> core_ops.c(370) : error C2065: 'S_IWUSR' : undeclared identifier
> core_ops.c(370) : error C2065: 'S_
> According to an old 486 book I have, it claims
> that complex addressing modes don't have cycle
> penalties for leaving out the scale or the offset.
> That seems hard to believe for the RISC-like
> P3s and Athalons.
x4 is just a bit offset, so it shouldn't be hard to believe that the pentium+
> "MLM" == Michael L Maraist <[EMAIL PROTECTED]> writes:
MLM> As with the relationship to the GC, my vision was that the GC
MLM> would free memory objects as it found them unused (mark/sweep or
MLM> what-ever), which only hands the memory regions over to the
MLM> deallocator, which in
Here's a patch to get the latest CVS sources to get everything to build on
my Windows box.
Here's what I did:
* Modified Configure.pl, mswin32.pl, and Makefile.in so that the platform
specific files in the platforms directory gets copied to the correct
directories. The Makefile will re-copy the
On Friday 02 November 2001 01:33 am, Uri Guttman wrote:
>
> dan at his recent talk at boston.pm's tech meeting said he was leaning
> towards a copying GC scheme. this would be the split ram in half design
> and copy all objects to the other half at CG time. the old half is
> reclaimed (not even re
Brent --
[ snip Jason Diamond's question ]
> No, this seems to be a case of Unix-centrism. (I feel your pain--I'm on
> Win32 too.) I'm CCing perl6-internals on this, since I don't really
> have the C experience to know what to do here.
I just posted a reply to someone else on the matter. If
Hi.
> in /usr/include/sys/stat.h. As for what to includ in Windows to get
> these (if anything), or what should be done to get them, I'm unsure.
> I suppose for now, you could paste the above into a header file
> somewhere with a #ifdef WIN32 around it to get things compiling.
I'd suspect that
Michael L Maraist wrote:
[an incredible amount of detailed information that will
take me weeks to digest...]
This looks like a malloc/free style allocator. Since the whole
GC system for Parrot is on the table, you don't have to constrain
yourself to malloc/free. IMHO free is not needed at all --
38 matches
Mail list logo
