Uri Guttman wrote:
> that is good. i wasn't disagreeing with your alternative architecture.
> i was just making sure that the priority was execution over compilation
> speed.
I use a snazzy quintuple-pass object-oriented assembler written
in equal parts spit and string (with a little RecDescent t
Uri Guttman wrote:
> so my point is the the speed of the VM is a separate issue from the ease
> of code generation. an S2S VM would be easier to code generate for but
> may be slower to run. the speed difference is still an open point as dan
> has said. but since his goal is execution speed, that
Uri Guttman wrote:
> and please don't bring in hardware comparisons again. a VM design
> cannot be compared in any way to a hardware design.
I have absolutely no idea what you are talking about. I didn't
say a single thing about hardware. My entire post was simply about
an alternative VM architec
Dan Sugalski wrote:
> What sort of dispatch was your version using, and what sort was
> parrot using in your test?
Parrot used the standard function call dispatcher without bounds
checking.
Kakapo used a threaded dispatcher. There's a pre-processing phase
that does byte code verification because
On Mon, Oct 29, 2001 at 05:27:30PM +, David Trusty wrote:
> I would like to request a new feature for perl: The ability to
> attach a perl debugger to a running process.
The DB module gives you the tools to do this sort of thing, though
there is some assembly required for certain very large
Hi,
I would like to request a new feature for perl: The ability to
attach a perl debugger to a running process.
Also, it would be nice to have the capability to generate a
"dump" (core file) for post-mortem analysis. The perl debugger
could then read the "core" file.
These capabilities would
>
> > A split between local, marginal, and global registers would be an
> > interesting thing to do, and I can see it making the code more elegant. I
> > worry about it making things more complex, though, especially with us
> > already having multiple register types. (We'd double or triple the num
On Mon, Oct 29, 2001 at 11:20:47PM +, Tom Hughes wrote:
> > 2) But either can support converting directly if it wants.
> The danger is that everybody tries to be clever and support direct
> conversion to and from as many other character sets as possible, which
> leads to lots of duplication.
Y
In message <[EMAIL PROTECTED]>
James Mastros <[EMAIL PROTECTED]> wrote:
> > That leaves the third, which is what I have implemented. When looking to
> > transcode from A to B it will first ask A if can it transcode to B and
> > if that fails then it will ask B if it can transcode from A
On Mon, Oct 29, 2001 at 08:32:16PM +, Tom Hughes wrote:
> We have established that the first two will not work because of the
> unicode problem.
Hm. I think instead of requiring Unicode to support everything, we should
require Unicode to support /nothing/. If A and B have no mutual transcodi
At 04:44 PM 10/29/2001 -0500, Ken Fox wrote:
>Well, I've tuned things up a bit. It's now
>hitting 56 mops with the mops.pasm example. Parrot
>turns in 24 mops on the same machine with the same
>compiler options.
Damn. I hate it when things outside my comfort zone end up being faster. :)
>This i
A little while back I posted some code that
implemented a storage-to-storage architecture.
It was slow, but I tossed that off as an
implementation detail. Really. It was. :)
Well, I've tuned things up a bit. It's now
hitting 56 mops with the mops.pasm example. Parrot
turns in 24 mops on the same
On Mon, Oct 29, 2001 at 03:15:07PM -0300, Daniel Grunblatt wrote:
> Just to make it clear both of them still need a LOT of work, but I don't
> know to which should I stick.
Just in case anyone wonders what's up with this patch, I'm waiting for
some feedback from others before applying.
--
"So i
In message <[EMAIL PROTECTED]>
"Stephen Howard" <[EMAIL PROTECTED]> wrote:
> right. I had just keyed in on this from Tom's message:
>
> "My code currently allows either set to provide the transform on the
> grounds that otherwise the unicode module would have to either know
> how to c
John Siracusa writes:
> > I think we're due out in reasonably good alpha/beta shape for the summer.
> Heh, the phrase "suitable vague" springs to mind... :)
There's a good reason for that, for why I've tried hard to avoid
giving promises of when things would be ready. Have you seen Apache 2
and
Just to make it clear both of them still need a LOT of work, but I don't
know to which should I stick.
On Mon, 29 Oct 2001, Daniel Grunblatt wrote:
> OK, there is another workaround to make pbc2c.pl work which still uses the
> "goto model" so speed is not affected but it's harder to maintain sin
OK, there is another workaround to make pbc2c.pl work which still uses the
"goto model" so speed is not affected but it's harder to maintain since
it's not as generic as the other one.
Daniel.
Index: pbc2c.pl
=
At 03:33 PM 10/29/2001 -0500, Ken Fox wrote:
>Anybody do a gcc-specific "goto *pc" dispatcher
>for Parrot yet? On some architectures it really
>cooks.
That's a good question. There was talk and benchmark numbers from a variety
of different dispatchers.
C'mon folks, kick in the code. I'll weld d
Anybody do a gcc-specific "goto *pc" dispatcher
for Parrot yet? On some architectures it really
cooks.
- Ken
right. I had just keyed in on this from Tom's message:
"My code currently allows either set to provide the transform on the
grounds that otherwise the unicode module would have to either know
how to convert to everything else or from everything else."
...which seemed to posit that Unicode modul
At 02:52 PM 10/29/2001 -0500, Stephen Howard wrote:
>You might consider requiring all character sets be able to convert to Unicode,
That's already a requirement. All character sets must be able to go to or
come from Unicode. They can do others if they want, but it's not required.
(And we'll hav
You might consider requiring all character sets be able to convert to Unicode, and
otherwise only have to know how to convert other
character sets to it's own set.
-Original Message-
From: Tom Hughes [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 29, 2001 02:31 PM
To: [EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:23 PM 10/27/2001 +0100, Tom Hughes wrote:
>
> >Attached is my first pass at this - it's not fully ready yet but
> >is something for people to cast an eye over before I spend lots of
> >time going down the wro
Dan --
You can also look at section 1.4.1' of
http://www-cs-faculty.stanford.edu/~knuth/fasc1.ps.gz
for another view of subroutine linkage from the upcoming TAOCP.
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526)
Dan --
[snip]
> I'll have to snag that manual next time I'm around a good bookstore. I've
> not read it as of yet, and Knuth generally has good things to say.
You can grab PDFs here:
http://link.springer.de/link/service/series/0558/tocs/t1750.htm
Of course, you can also browse around on
At 11:17 AM 10/29/2001 -0500, Gregor N. Purdy wrote:
> > > > *) The first five registers (I0-I4, S0-S4, P0-P4, N0-N4) are scratch
> > > and do
> > > > not have to be preserved by the callee
> > >
> > >Still thinking about this... We are reducing the overall number of reg
> > >copies going on by ad
Dan --
> >Looks like I'm going to have to write some real logic in jakoc
> >pretty soon...
>
> Ahhh! The horror! :-)
:)
> Seriously, the conventions are geared towards full-blown compilers with a
> reasonable register ordering module at the very least, which isn't
> unreasonable to expec
At 08:52 AM 10/29/2001 -0500, Gregor N. Purdy wrote:
>The first step I'm going to take is to start putting the arg and
>result counts on the stack, and remove the stack rotation stuff.
Leave the rotate opcode, though. That might come in handy for the
Forth/Scheme/Postscript folks, once we have t
At 08:43 AM 10/29/2001 -0500, Gregor N. Purdy wrote:
>Dan --
>
>On Fri, 2001-10-26 at 16:38, Dan Sugalski wrote:
> > Okay, here are the conventions.
>
>Looks like I'm going to have to write some real logic in jakoc
>pretty soon...
Ahhh! The horror! :-)
Seriously, the conventions are geared t
Sam --
> > Okay, here are the conventions.
>
> Great. Anyone want to offer up some examples or should I just wait for
> Jako support to see this in action?
I'll be working on making jakoc support the convention, but it may
take a while with my day job duties as they are. If I can get it in
qui
Dan --
On Fri, 2001-10-26 at 16:38, Dan Sugalski wrote:
> Okay, here are the conventions.
Looks like I'm going to have to write some real logic in jakoc
pretty soon...
> *) The callee is responsible for saving and restoring non-scratch registers
Nice for callee since if its work fits into five
Automated smoke report for patch Oct 28 20:00:01 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 =
32 matches
Mail list logo
