Bryan C. Warnock [EMAIL PROTECTED] wrote:
As mentioned previously. Makes IMCC and PASM constant keywords
consistent, with '.const'.
As mentioned previously ;-) this doesn't work that simple. Imcc already
has:
.const type ID = value
and:
#v+
$ IMCC=imcc perl t/harness t/o*/ma*.t
Well, I'm beginning to feel it's habitual for me to periodically pop my
head in and waffle on Parrot's core sizes. But waffle I shall.
- opcode_t
This has already been discussed, so I'll sum up. To remain compatible
(and efficient) across the spectrum of 32-bit and 64-bit platforms, the
value
On Sat, 2003-05-31 at 09:53, Leopold Toetsch wrote:
Bryan C. Warnock [EMAIL PROTECTED] wrote:
As mentioned previously. Makes IMCC and PASM constant keywords
consistent, with '.const'.
As mentioned previously ;-) this doesn't work that simple. Imcc already
has:
.const type ID =
Matt Fowles [EMAIL PROTECTED] wrote:
This patch adds simple constant propagation to imcc.
First thanks, seconds I modified and applied it - but third, its
disabled and doesn't work and forth - it needs a lot of tests to really
get activated.
I did add some comments, and an example, why it will
If memory serves me right, Bryan C. Warnock wrote:
Not to mention all the *other* problems we'll have if we've got more
than 2^31 different opcodes. (Although that's why there's UUIDs now,
isn't there?)
I think parrot has already crossed the limit of 1024 ...
(I can't even keep 256 opcodes in
Mitchell N Charity [EMAIL PROTECTED] wrote:
At a minimum, it would be nice for some register access macro set to
be globally available.
REG_PMC(0) = method;
Yep. Seems reasonable. The macros would improve readability IMHO
Mitchell
leo
Bryan C. Warnock [EMAIL PROTECTED] wrote:
The flow *really* is, in value sizes:
Opcodes: 32 (constants are limited by the spec)
In which spec? How would we handle 64 bit INTVAL constants on 32 bit
systems?
PMCs : 64
Regs : 32
Guts : 32
System : 32
Yep, guts
At 1:03 AM +0200 5/29/03, Leopold Toetsch wrote:
Luke Palmer [EMAIL PROTECTED] wrote:
I've been trying to run pbc2c.pl, and it's been dying. I traced the
problem down to Parrot::Packfile thinking that the size of the
bytecode segment is zero. However, it works fine when I use
assemble.pl to
At 1:03 AM +0200 5/29/03, Leopold Toetsch wrote:
Luke Palmer [EMAIL PROTECTED] wrote:
I've been trying to run pbc2c.pl, and it's been dying. I traced the
problem down to Parrot::Packfile thinking that the size of the
bytecode segment is zero. However, it works fine when I use
Leopold Toetsch wrote:
First thanks, seconds I modified and applied it - but third, its
disabled and doesn't work and forth - it needs a lot of tests to really
get activated.
I did add some comments, and an example, why it will not work.
I think its better, to have the midifed patch applied and
This gives imcc a better help message, without being patronizing about
the meanings of the options (because they're clear from the long
option names). It also cleans up the option data structure in imcc
and test_main by removing the unsightly NULLs that needn't be there.
Luke
Index: test_main.c
At 9:38 AM -0700 5/30/03, Jonathan Sillito wrote:
Thanks Dan. One little picky thing what is the naming convention for ops?
Good question--there really isn't one. I've been trying to avoid
underscores in names, since it was inconvenient when the assembler
was trying to figure out if you were
At 8:30 PM +0100 5/30/03, Nicholas Clark wrote:
I'm not sure if I'm asking a stupid question here, but:
On Fri, May 30, 2003 at 08:12:34AM -0400, Dan Sugalski wrote:
You say P2 is a continuation
[snip]
But you seem to be using P2 like it's the object
I'm confused.
No, I was. There are three
At 5:54 PM +0200 5/31/03, Leopold Toetsch wrote:
Mitchell N Charity [EMAIL PROTECTED] wrote:
At a minimum, it would be nice for some register access macro set to
be globally available.
REG_PMC(0) = method;
Yep. Seems reasonable. The macros would improve readability IMHO
Absolutely. Works
Luke Palmer wrote:
[Dan] ... Honestly I'd prefer just a single executable, named
[Dan] parrot
I would totally dig that. I use imcc for everything; why not just
call it parrot :-)
Why don't we just build a single executable, where the main c-source
isn't called test_main.c but parrot.c and
Matt Fowles [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
Shortly after trying to go to bed last night [this morning], I realized
a case (or class of cases) in which this would be broken. I will try to
hack at dealing with that later; however, I am still relatively new to
this. Is there
At 14:26 on 05/31/2003 EDT, Dan Sugalski [EMAIL PROTECTED] wrote:
Honestly I'd prefer just a single executable, named
parrot, that can handle assembly files, rather than the two
executables we're building now. If we can do that, we can ditch
assemble.pl.
I'm all for that as well. It
This patch is a collection of a few small fixes vaguely related to the
lexical pads. It implements pop_pad(out PMC), banishes Intval in
favor of INTVAL, and adds some newlines to internal_exception calls.
Luke
Index: core.ops
===
Luke Palmer [EMAIL PROTECTED] wrote:
+op pop_pad(out PMC) {
+$1 = new_pmc_header(interpreter);
+stack_pop(interpreter, interpreter-ctx.pad_stack,
+ $1, STACK_ENTRY_PMC);
goto NEXT();
Do we really need a new PMC header here? The PMC already must have one.
Josh Wilmes wrote:
At 14:26 on 05/31/2003 EDT, Dan Sugalski [EMAIL PROTECTED] wrote:
Honestly I'd prefer just a single executable, named
parrot,
I'm all for that as well. It would imply some code reorganization
(placing them in the same directory might make sense, or at least taking
imcc
Luke Palmer [EMAIL PROTECTED] wrote:
+op pop_pad(out PMC) {
+$1 = new_pmc_header(interpreter);
+stack_pop(interpreter, interpreter-ctx.pad_stack,
+ $1, STACK_ENTRY_PMC);
goto NEXT();
Do we really need a new PMC header here? The PMC already must have one.
On Sat, 2003-05-31 at 11:15, Gopal V wrote:
If memory serves me right, Bryan C. Warnock wrote:
Not to mention all the *other* problems we'll have if we've got more
than 2^31 different opcodes. (Although that's why there's UUIDs now,
isn't there?)
I think parrot has already crossed the
On Sat, 2003-05-31 at 11:43, Leopold Toetsch wrote:
Bryan C. Warnock [EMAIL PROTECTED] wrote:
The flow *really* is, in value sizes:
Opcodes: 32 (constants are limited by the spec)
In which spec? How would we handle 64 bit INTVAL constants on 32 bit
systems?
Parrotbyte.pod.
Merlyn's use perl journal of April 29, 2003:
http://use.perl.org/~merlyn/journal/
suggests using environment variables to spare the installer of
CPAN modules a long wait while running 'make test'. One reply
noted that DBD, HTML::Mason and other modules already do this.
Is there a standard name/s
On Sunday, June 1, 2003, at 08:43 am, Andrew Savige wrote:
Merlyn's use perl journal of April 29, 2003:
http://use.perl.org/~merlyn/journal/
suggests using environment variables to spare the installer of
CPAN modules a long wait while running 'make test'. One reply
noted that DBD, HTML::Mason
25 matches
Mail list logo
