[EMAIL PROTECTED] (Allison Randal) writes:
> In the design meetings early this month we added C for true
> pass-by-value.
Can someone please compile a list of all the "is foo" properties that
have been suggested/accepted as being pre-defined by the language?
I can't keep track of them all.
--
So
On Feb-22, Dan Sugalski wrote:
> At 10:20 AM -0800 2/20/03, Steve Fink wrote:
> >The invoke op is bothering me -- namely, it disturbs me that it
> >implicitly operates on P0. I know that P0 is the correct register to
> >use according to pdd03, but I dislike having it be implicit. The user
> >is req
Dan Sugalski wrote:
At 6:54 PM -0800 2/22/03, Tupshin Harper wrote:
Sorry for all the questions...these are the trials and tribulations
of dealing with a newbie trying to get up to speed with the current
state of parrot. So here's another question:
Is it possible and/or meaningful to read and
Luke wrote:
> If you want to modify a parameter in place, you declare with C.
> If you want to pass by-value, there might be a property for that, but
> I think this was recommended:
>
> sub foo($bar_) {
> my $bar = $bar_; # Copy, not bind
> # ... with $bar
> }
In th
On Feb-23, Leopold Toetsch wrote:
>
> Good.
> One minor note - and it is my fault to haven't documented that in the
> first place - I did revert all the other changes, they are necessary for
> pbc2c compiled code.
> Of course, it would be better, to have another set of macros, that
> state: "Thi
On 2/23/03 10:25 AM, "Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
[SNIP]
>
> While you say it "tinderbox", currently the reports are really
> suboptimal. Some are red (stating not even parrot was built), but only
> have failing tests, sometimes the error reason is not show in the brief
> log, maki
On Sun, Feb 23, 2003 at 11:13:30AM -0500, Dan Sugalski wrote:
> Cool. When we do that I'd like to look at revamping the tinderbox
> system to run tests on all the core types.
I know I'm asking a needless question (because I should be able to work it
out from the source and the list archive) but w
Dan Sugalski wrote:
At 2:33 PM +0100 2/23/03, Leopold Toetsch wrote:
Ok, ok, you have convinced me. Let's just select a default core set
build according to the mentioned hierarchies and the possibility to
build every combination, if the user wants to.
Cool. When we do that I'd like to look at
At 6:54 PM -0800 2/22/03, Tupshin Harper wrote:
Sorry for all the questions...these are the trials and tribulations
of dealing with a newbie trying to get up to speed with the current
state of parrot. So here's another question:
Is it possible and/or meaningful to read and write from a part of a
At 2:33 PM +0100 2/23/03, Leopold Toetsch wrote:
I forget who I'm misquoting, but good tools can be used in ways their makers
never even thought of.
Ok, ok, you have convinced me. Let's just select a default core set
build according to the mentioned hierarchies and the possibility to
build ever
If memory serves me right, Leopold Toetsch wrote:
> > Is it possible and/or meaningful to read and write from a part of a
> > register(e.g. a single word) in pasm?
I always thought bitwise "and" and "or" were the things to use to modify
partial content ?. Though I can't say if that makes sense be
[EMAIL PROTECTED] wrote:
Leo / Dan --
Have we allocated PASM or IMC directives to replace the setline, setfile,
and setpackage ops?
* .file
* .line []
* .package
Should we have an indicator of the name of a sub, too?
We don't need .file/.line, imcc knows these, and passes the inf
Dan Sugalski wrote:
At 12:09 PM +0100 2/20/03, Leopold Toetsch wrote:
Starting from the unbearable fact, that optimized compiled C is still
faster then parrot -j (in primes.pasm), I did this experiment:
- do register allocation for JIT in imcc
- use the first N registers as MAPped processor regi
Nicholas Clark wrote:
On Sat, Feb 22, 2003 at 12:31:09PM +0100, Leopold Toetsch wrote:
It might just be that on someone's machine the faster and smaller core
triggers a compiler bug. And
When PBC code size matters we could have:
CGoto
you've already found a reason why someone might want the "ob
> On Sun, Feb 23, 2003 at 11:12:18AM +1300, Martin D Kealey wrote:
> > I would like to argue in favour of "pass by value" to be the
> > default in the absence of some explicit prototype, because it
> > allows greater type-safety, and because the opposite default
> > interacts badly with out-of-orde
On Sun, Feb 23, 2003 at 11:12:18AM +1300, Martin D Kealey wrote:
> I would like to argue in favour of "pass by value" to be the default in the
> absence of some explicit prototype, because it allows greater type-safety,
> and because the opposite default interacts badly with out-of-order execution
On Sat, Feb 22, 2003 at 12:31:09PM +0100, Leopold Toetsch wrote:
> Nicholas Clark wrote:
>
> >On Fri, Feb 21, 2003 at 08:34:05AM +0100, Leopold Toetsch wrote:
>
> >>Case 2) should disable only core_ops_cg.c but not core_ops_cgp.c
> >>
> >
> >But surely we'd also like a flag to disable core_ops_cg
Leo / Dan --
Have we allocated PASM or IMC directives to replace the setline, setfile,
and setpackage ops?
* .file
* .line []
* .package
Should we have an indicator of the name of a sub, too?
Regards,
-- Gregor
Leopold Toetsch <[EMAIL PROTECTED]>
02/23/2003 04:35 AM
Benjamin Goldberg wrote:
Dan Sugalski wrote:
Yeah, 32 is a bunch. I've considered going with 16 on and off, and
still might.
16 is not enough for non trivial subroutines. E.g. the _Generate sub in
life.p6 consumes 25 P regs.
Given that registers are allocated with the lower numbers being the
Tupshin Harper wrote:
Is it possible and/or meaningful to read and write from a part of a
register(e.g. a single word) in pasm?
We have a very limited subset in dotgnu.ops.
-Tupshin
leo
Steve Fink wrote:
On Feb-22, Leopold Toetsch wrote:
Yep. At least add B.
Ok, done.
Good.
One minor note - and it is my fault to haven't documented that in the
first place - I did revert all the other changes, they are necessary for
pbc2c compiled code.
Of course, it would be better, to have
As stated in the thread "pxs help", the QT example can be expressed in
terms of NCI. So IMHO the following opsen are obsolete:
- loadext (unused)
- callnative (only in QtHelloWorld.pasm, unimplemented)
And further:
- setline
- setfile
- setpackage
which are already/ought to be in the PBC metadata
22 matches
Mail list logo
