On Tru64, freshly compiled perl 5.005_03,
Configure.pl decides the correct type for opcode is 'l'
but that is 32 bit! After manually changinq it to 'q'
it mostly[1] works.
Problem is that al line 159 it does:
elsif ($c{ivsize} == 8) {
$c{packtype_i} = 'q';
$c{pac
Attached is a new assemble.pl. No, it doesn't change anything, it only
breaks the code up into easier to follow functions (which are commented). I
am going to test it on a few more platforms and then apply it tomorrow if no
one has any objections. Having it broken up into functions should make
Collect all the P(ok)emons on the Core Platforms
and try to find the secret ways to the None Core Platforms.
Then proceed to level 0.0.2.
--
CORE PLATFORMS
--
===
Linux (x86):
make ok / test ok
===
CygWin (1.3
On Wednesday 26 September 2001 01:36, Dan Sugalski wrote:
> At 05:00 PM 9/25/2001 -0400, Will Coleda wrote:
> >In parrot_assembly.pod, line 135 seems to trail off...
>
> Hmmm. Could you paste in the offending bit? I'm not seeing it, so I'm not
> sure if I'm looking in the wrong place or have fixed
At 06:26 PM 9/25/2001 -0700, Benjamin Stuhl wrote:
>--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 06:07 PM 9/25/2001 -0700, Benjamin Stuhl wrote:
> > >But why store it in this
> > >format? What we really need to store is the list of what
> > we
> > >expect in the table and where.
> >
> > We h
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 06:07 PM 9/25/2001 -0700, Benjamin Stuhl wrote:
> >Just to make sure that it's making the _right_ sense,
> the
> >fixup section is basically our single level of
> indirection
> >so that we can make the bytecode itself be
> >position-independant, rig
At 06:07 PM 9/25/2001 -0700, Benjamin Stuhl wrote:
>Just to make sure that it's making the _right_ sense, the
>fixup section is basically our single level of indirection
>so that we can make the bytecode itself be
>position-independant, right?
Yup.
>But why store it in this
>format? What we real
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 07:36 PM 9/25/2001 -0400, Gregor N. Purdy wrote:
> >I'm just waiting for the thumbs-up from Simon and Dan
> before committing
> >that increment and then moving on to do the changes to
> the format to
> >support more than just strings in const_table.
At 05:28 PM 9/25/2001 -0700, Damien Neil wrote:
>On Tue, Sep 25, 2001 at 08:18:04PM -0400, Dan Sugalski wrote:
> > That'd be interesting. Try cobbling up a version of the assembler that
> does
> > big-endian assembly and a loader that reads and byteswaps, and see what
> you
> > get for start-to-
On Tue, Sep 25, 2001 at 08:18:04PM -0400, Dan Sugalski wrote:
> That'd be interesting. Try cobbling up a version of the assembler that does
> big-endian assembly and a loader that reads and byteswaps, and see what you
> get for start-to-finish performance.
I'm going to take a crack at that Real
At 02:57 PM 9/25/2001 +0200, Bart Lateur wrote:
>On Mon, 24 Sep 2001 11:29:10 -0400, Dan Sugalski wrote:
>
> >However...
> >
> >I was talking about a different instance of "bitmap". More like:
> >
> > newbm P3, (640, 480, 24, 8) # Make a 640X480, 24 bit image
> >
At 04:24 PM 9/25/2001 -0700, Damien Neil wrote:
>In particular, I'd like to see if we can
>get empirical data to justify some of the design decisions that
>are being assumed. Exactly how expensive, for example, would it
>be to use a single bytecode format with platform-independent
>encodings?
Th
At 05:03 PM 9/25/2001 -0700, Damien Neil wrote:
>On Wed, Sep 26, 2001 at 12:38:28AM +0100, Simon Cozens wrote:
> > But then I'm one of those weird critters who doesn't understand what
> all the
> > complaining over XS is about. :) I'd be happy to do the XS coding if it
> came
> > down to it.
>
>
On Wed, Sep 26, 2001 at 12:38:28AM +0100, Simon Cozens wrote:
> But then I'm one of those weird critters who doesn't understand what all the
> complaining over XS is about. :) I'd be happy to do the XS coding if it came
> down to it.
I'll take a look at making the assembler and disassembler use t
On Tue, Sep 25, 2001 at 07:36:31PM -0400, Gregor N. Purdy wrote:
> I'm currently working on some assigned taskes for the bytecode stuff
> for 0.0.2. I need to get it to the point where we can stash NVs in
> the const_table. I've already got the interpreter using packfile.[hc]
> for its work (I pos
On Tue, Sep 25, 2001 at 07:51:22PM -0400, Gregor N. Purdy wrote:
> Is there hope that 0.0.2 could be out by the end of the week if I get
> the tasks assiged to me done RSN?
Once we've got NVs into the constant table, we can ensure they're aligned
nicely, and all the problems we're seeing on Sparc
Simon --
> I think that's exactly what needs work, and one of the things Gregor
> is looking at. Here's how it goes.
>
> Before 0.0.2 is released, we need to pass tests on Sparc,
Someone else has to tinker with this this... (no Sparc here)
> which means we need to stop dereferencing NVs o
At 07:36 PM 9/25/2001 -0400, Gregor N. Purdy wrote:
>I'm just waiting for the thumbs-up from Simon and Dan before committing
>that increment and then moving on to do the changes to the format to
>support more than just strings in const_table. A cooler packfile/
>bytecode file format is due post-0.
On Tue, Sep 25, 2001 at 07:36:31PM -0400, Gregor N. Purdy wrote:
> I'm currently working on some assigned taskes for the bytecode stuff
> for 0.0.2.
Hrm, we should probably be using the request tracker to manage these
takss.
> the const_table. I've already got the interpreter using packfile.[hc]
Damien --
> Are there any issues holding up 0.0.2 that I (or others) could work
> on? Failing that, what areas of Parrot are most in need of immediate
> work?
>
> I'm interested in looking at the bytecode loader, if nobody else
> has intentions there. In particular, I'd like to see if we can
>
On Tue, Sep 25, 2001 at 07:29:01PM -0700, Wizard wrote:
> Actually, the thing that I didn't like was using an actual string as the
> message_id. I would have expected something more in the way of:
>
> char *err = get_text_string( THREAD_EXCEPTION_117, \
> "THREAD EXC
At 05:00 PM 9/25/2001 -0400, Will Coleda wrote:
>In parrot_assembly.pod, line 135 seems to trail off...
Hmmm. Could you paste in the offending bit? I'm not seeing it, so I'm not
sure if I'm looking in the wrong place or have fixed it.
Dan
---
On Tue, Sep 25, 2001 at 04:24:53PM -0700, Damien Neil wrote:
> I'm interested in looking at the bytecode loader, if nobody else
> has intentions there.
I think that's exactly what needs work, and one of the things Gregor
is looking at. Here's how it goes.
Before 0.0.2 is released, we need to pa
Michael --
> I had more time to think about it, and I determined how a compute op-code
> could be efficient.
>
> [snip]
You wicked, wicked person! :)
I'd like to see some benchmarks on that one vs. the most efficient
possible hand-coded separate ops for moderate to complex arithmetic...
These s
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] wrote:
> You quoted something similar to my text above and said you didn't
> like it. I
> believe mostly because it involved reading external files, but
> also because of
> the concept of the message-id.
Actually, the thing that I didn't like was usin
Are there any issues holding up 0.0.2 that I (or others) could work
on? Failing that, what areas of Parrot are most in need of immediate
work?
I'm interested in looking at the bytecode loader, if nobody else
has intentions there. In particular, I'd like to see if we can
get empirical data to ju
At 06:59 PM 9/25/2001 -0400, Michael L Maraist wrote:
> > > > I've created a varargs-ish example by making a new op, print_s_v.
> > > > This is pretty rough, and I haven't updated the assembler, but it
> > > > seems to work.
Okay, I've been off the air all day (Sorry 'bout that--cable got nuked)
On Wed, Sep 26, 2001 at 12:05:49AM +0200, Mattia Barbon wrote:
> O O
> O O nv=double
> O O nv=\"long double\"
> O O iv=int
> O O iv=int nv=double
> O O iv=int nv=\"long double\"
> O O iv=long
> O O iv=long nv=double
> O O iv=long nv=\"long double\"
Weird. That probably shouldn't happen.
Michael Maraist wrote:
> > All --
> >
> > > I've created a varargs-ish example by making a new op, print_s_v.
> > > This is pretty rough, and I haven't updated the assembler, but it
> > > seems to work.
>
>
> With var-args, we could produce highly efficient SIMD instructions.
> printf obviously,
At 12:39 AM 9/25/2001 -0400, Steven W McDougall wrote:
>So the declaration of opcode_funcs was at a different level of
>indirection than its allocation and use. The compilers weren't
>complaining about this because of all the (void *) casts. The IRIX64
>compiler did complain, not about indirection
--- Forwarded message follows ---
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Subject:Parrot Smoke Sep 25 19:00:04 2001 UTC MSWin32 4.0
Date sent: Tue, 25 Sep 2001 22:00:03 +0200
Automated smoke report for patch Sep 25
I changed t/op/trans.t to not use loops so you can more easily see which
test failed.
Thanks!
Tanton
Wizard wrote:
> Michael Maraist [mailto:[EMAIL PROTECTED]] wrote:
> > Does you idea allow for:
> > int msgid = txtToMsgid( "This feels strange\n" );
> > char *label = msgidToRes( msgid );
>
> I'm not sure that I understand your question. This is not my idea, but GNU's
> gettext tools. I, myself,
In parrot_assembly.pod, line 135 seems to trail off...
Michael Maraist [mailto:[EMAIL PROTECTED]] wrote:
> ... but I'm assuming it involves (among other things) displaying
> locale-based error messages.
I'm not sure how the catalog would be determined, but I would suggest
another mechanism other than locale. Rather, I'd suggest a user-specific
envir
Michael Maraist [mailto:[EMAIL PROTECTED]] wrote:
> Does you idea allow for:
> int msgid = txtToMsgid( "This feels strange\n" );
> char *label = msgidToRes( msgid );
I'm not sure that I understand your question. This is not my idea, but GNU's
gettext tools. I, myself, am not thrilled with this im
> All --
>
> > I've created a varargs-ish example by making a new op, print_s_v.
> > This is pretty rough, and I haven't updated the assembler, but it
> > seems to work.
>
> Um.. I *have* updated the assembler. Its the *dis*assembler I haven't
> updated. This is what happens:
>
> * *_v ops list
> and a call to the API would be:
> char *label = gettext( "This feels strange\n" );
Does you idea allow for:
int msgid = txtToMsgid( "This feels strange\n" );
char *label = msgidToRes( msgid );
In addition to the above, since this affords compile-time optimizations?
I'm not following this thre
All --
As a first step to moving NV constants out of the byte code stream
and other goodness, I have produced this patch that gets rid of
bytecode.[hc] (for now) and has the interpreter rely on packfile.[hc]
for its bytecode interface.
The packfile.[hc] stuff has been modified a bit in anticipat
> On Monday 24 September 2001 11:54 am, Dan Sugalski wrote:
> > Odds are you'll get per-op event checking if you enable debugging, since
> > the debugging oploop will really be a generic "check event every op"
> > loop that happens to have the "pending debugging event" bit permanently
> > set. Dun
On Tuesday 25 September 2001 09:56 am, Leon Brocard wrote:
> I see a great need for OpenGL opcodes (let's forget about
> arrays and hashes, right?) ;-)
You scoff! A cow-orker and I were just discussing hijacking some of the
more powerful graphic boards routines to off-load processing.
--
Brya
All --
> I've created a varargs-ish example by making a new op, print_s_v.
> This is pretty rough, and I haven't updated the assembler, but it
> seems to work.
Um.. I *have* updated the assembler. Its the *dis*assembler I haven't
updated. This is what happens:
* *_v ops list their number of a
Bart Lateur sent the following bits through the ether:
> What underlying graphics engine would you use?
I see a great need for OpenGL opcodes (let's forget about
arrays and hashes, right?) ;-)
Leon
--
Leon Brocard.http://www.astray.com/
Nanoware.
On Mon, 24 Sep 2001 11:29:10 -0400, Dan Sugalski wrote:
>However...
>
>I was talking about a different instance of "bitmap". More like:
>
> newbm P3, (640, 480, 24, 8) # Make a 640X480, 24 bit image
> # with 8 bits of alpha
> drawline P3, (100, 100, 200, 200,
I've been looking over the gettext implementation, and I'm not sure that I
entirely like it, but let me know if this sounds like I've been programming
to long. (Maybe I'm misreading the document)
The gettext API uses strings as "msgid". What this means is that in order to
get a translated string,
hi,
sorry for off-topic, could u point me to the address of CVS Web reposity
viewer (u use for cvs.perl.com).
Privetely of cource :")
Thanx alot..
=
iVAN
[EMAIL PROTECTED]
=
On Tue, Sep 25, 2001 at 12:45:02AM +0100, Alex Gough wrote:
> noop didn't have a test, ironic yes, but imagine the shame if it didn't work.
If noop does anything that could remotely be called work, it's broken. :)
Thanks, applied.
--
"The Amiga is the only personal computer where you can run a
On Thu, 20 Sep 2001 14:04:43 -0700, Damien Neil wrote:
>On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
>> >For clarification: do you mean async I/O, or non-blocking I/O?
>>
>> Async. When the interpreter issues a read, for example, it won't assume the
>> read completes immediatel
48 matches
Mail list logo
