This references the previously posted (by someone else) article on SUN's libu
memory architecture. If needed I can run through the archives and find the
URL.
I've already written a threaded implementation which has a decent
responsiveness. It did as much as the SUN libu claimed that it would
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,i|ic)' - Loads the integer from arena $2, index
Daniel Grunblatt:
# 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
Holy $#!+...
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
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
# java -Xint mops
Iterations:1
Estimated ops: 3
Elapsed time: 9.6929
On Tue, Oct 30, 2001 at 09:37:39AM -0500, Aaron Sherman wrote:
: Yep, but in Perl5, this was never very clean or obvious to the
: casual programmer. Constants have been coming of age in Perl,
: and they're kind of scary if they're not constant.
On one hand, one might say that a developer changing
In message <[EMAIL PROTECTED]>
Tom Hughes <[EMAIL PROTECTED]> wrote:
> 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
> >
Aaron mused:
> > Then maybe we shouldn't call it 'is const'? Or maybe another tag is
> > needed in addition, like 'is unbindable' for the latter case.
>
> Yes, I see the wisdom of not using "const" here, since it does carry
> SO MUCH baggage. "final" has Java baggage. "only", "s
At 06:54 PM 10/30/2001 -0600, Kevin Huber wrote:
>The code density is one thing that surprised me. Even with 4 byte
>opcodes and arguments, pbc is very reasonable.
Code density's the place where perl's always had a big win. Either an
interpreter's got a very limited set of ops (to fit in a byte
At 01:39 PM 10/31/2001 +, Simon Cozens wrote:
>On Wed, Oct 31, 2001 at 08:33:05AM -0500, Gregor N. Purdy wrote:
> > If there's no objection, I'll apply the patch here and play with it and
> > probably commit it.
>
>Feel free.
Yup. I'm working on the docs for the I/O ops at the moment, and thi
On Tue, Oct 30, 2001 at 04:15:46PM -0600, David M. Lloyd wrote:
> On Wed, 31 Oct 2001, Damian Conway wrote:
>
> > To me C means: "the *value* stored in the memory
> > implementing this variable cannot be changed". Which doesn't preclude
> > rebinding the variable to some *other* memory.
> >
> > B
> "John" == John Siracusa <[EMAIL PROTECTED]> writes:
John> (Can I pre-order the Perl 6 Camel or what? ;)
Of course. You'll almost certainly visit the nodes before the subnodes
in the documentation.
:-)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAI
On Wed, Oct 31, 2001 at 08:33:05AM -0500, Gregor N. Purdy wrote:
> Eventually, we'll want to move these and the printint ops to a separate
> devel.ops (or some such thing).
I would do that immediately. In fact, call 'em temp.ops, to remind people
that they're not the final solutions and are dest
All --
[Thanks, Jeff]
Does anyone object to using this as a starting point? I'd like to have
such ops, even if they are only there until we have a full I/O
subsystem.
Eventually, we'll want to move these and the printint ops to a separate
devel.ops (or some such thing). That has to wait until w
Automated smoke report for patch Oct 30 20:02:18 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 =
14 matches
Mail list logo
