You actually don't want to add the Makefile.in patch. Brent Dax submitted a
patch that puts the correct -I./include in the Configure.pl file. If you
don't still have the patch I can forward it to you.
Tanton
-Original Message-
From: Gregor N. Purdy
To: Gibbs Tanton - tgibbs
Cc: 'Rober
The README really doesn't have to mention Configure.pl because when you do
make test_prog it will run Configure.pl for you (at least it is supposed to
:)
-Original Message-
From: Will Coleda
To: [EMAIL PROTECTED]
Sent: 9/15/2001 12:13 AM
Subject: Difficulties
The README doesn't mention
## +#if defined(WIN32)
## +program_code = malloc( file_stat.st_size );
## +#else
Also, since more than win32 is not going to have mmap, perhaps you could add
a Configure #define for HAS_MMAP or something like that. Then you could
test the cc compiler to check for mmap availability.
## +#if defined(WIN32)
## +program_code = malloc( file_stat.st_size );
## +#else
#Should we be using malloc, or are we supposed to use our own allocator?
#(I haven't been munging in the C, so I don't really know--it just looks
#a little suspicious.)
In memory.{h,c} there is a mem_sys_allocat
I have a question on your test suite.
Would backticks not be more portable then trying to figure out how to
redirect STDOUT on each OS? To me, it would just be simpler to use the
--ouput flag of the assembler to create the .pbc file, and then use
backticks to capture the output of the interpret
Paul Johnson:
# Call me an old fuddy duddy if you will, or Unix-centric if
# you must, but
# the .pl extension historically refers to Perl Libraries, and even now
# that is my first thought when I see it.
#
# Now I realise that many people working on this project have rarely, if
# ever, used Perl
I have modified assemble.pl to do a slightly different form of
lookup...basically, it takes the op and gets all operations that have op as
a base (followed by (_([ins]c?)|p)+). Then, it goes through each candidate
and compares the arguments declared in opcode_table to the arguments
actually give
Benjamin Stuhl:
# --- Brian Wheeler <[EMAIL PROTECTED]> wrote:
# > I've been thinking alot about the bytecode file format
# > lately. Its
# > going to get really gross really fast when we start
# > adding other
# > (optional) sections to the code.
# >
# > So, with that in mind, here's what I prop
Mattia Barbon:
# > PLEASE can someone rewrite the tests to actually *test* things
# > and print "ok 1\n" and so on?
# Here it is ( for the second time )
#
# > Quick, or I'll call Schwern in.
# Ah, I thought you missed my patches, then I was correct
# both attached
...
(in things.diff)
# -C_FLAGS =
Will Coleda wrote:
>
> The README doesn't mention Configure.pl (minor doc patch follows), and
> Parrot::Opcode is requiring perl5.6, which makes my 5.5.3 quite unhappy.
>
> Are folks intentially using 5.6 constructs? I'll consider generating a
> patch to make things work with 5.5.3 if this was
The README doesn't mention Configure.pl (minor doc patch follows), and
Parrot::Opcode is requiring perl5.6, which makes my 5.5.3 quite unhappy.
Are folks intentially using 5.6 constructs? I'll consider generating a
patch to make things work with 5.5.3 if this was an act of convenience
rather th
Attached a simple bytecode header reader/writes that writes out the
natively correct output, and can read in recognize the output of "any"
(for small enough values of any) other platform. Tried on x86 (32LE),
sparc (32BE), alpha (64LE), mips (32BE/64BE, compiler-switchable), and
unicosmk (64BE, r
Sorry...forgot the tabs...this one should be right.
memory.c
Below is memory.c changed to support all (I think) of the coding standards.
Please look it over and let me know. Once the powers that be give the ok, I
will try to change all the source files to the standard.
Thanks!
Tanton
/* Memory.c
* Copyright: (When this is determined...it will go here)
On Fri, Sep 14, 2001 at 02:35:33PM -0700, Benjamin Stuhl wrote:
> > Chunks we'd need are:
> >
> > Name: 'PINF' - Parrot Information
> > Name: 'PBYT' - Parrot Bytecode
> > Name: 'PSTR' - Parrot String Table
> > Name: 'PFIX' - Parrot Fixup Ta
All --
> Since we are so early in the game, I'm not sure if it really matters whether
> we keep the version information or not. Does anyone have a problem with me
> deleting the header files and readding them under include/parrot/. or is the
> general concensus moving the RCS files?
Rather th
All --
> Since we are so early in the game, I'm not sure if it really matters whether
> we keep the version information or not. Does anyone have a problem with me
> deleting the header files and readding them under include/parrot/. or is the
> general concensus moving the RCS files?
Rather th
All --
I'd like to suggest that the Parrot image we've seen associated with
Perl6 be given the name "Jake", especially if it turns out to be a
picture of an African gray parrot (a jako).
Regards,
-- Gregor
_
/ perl -e 's
On Fri, Sep 14, 2001 at 06:37:33PM -0400, Dan Sugalski wrote:
> At 03:29 PM 9/14/2001 -0700, Damien Neil wrote:
> >On Sat, Sep 15, 2001 at 12:39:39AM +0300, Jarkko Hietaniemi wrote:
> > > > It will be hard to use one format for both native and portable.
> > >
> > > Not one format, but a set of clo
Since we are so early in the game, I'm not sure if it really matters whether
we keep the version information or not. Does anyone have a problem with me
deleting the header files and readding them under include/parrot/. or is the
general concensus moving the RCS files?
Also, would anyone like to
At 03:29 PM 9/14/2001 -0700, Damien Neil wrote:
>On Sat, Sep 15, 2001 at 12:39:39AM +0300, Jarkko Hietaniemi wrote:
> > > It will be hard to use one format for both native and portable.
> >
> > Not one format, but a set of closely related formats with well-defined
> > transformations between them.
At 03:18 PM 9/14/2001 -0700, Damien Neil wrote:
>On Sat, Sep 15, 2001 at 01:03:51AM +0300, Jarkko Hietaniemi wrote:
> > > Re: IFF. Being an old Amiga user, I find it appealing. Is the lack
> > > of a dictionary likely to be a significant problem?
> >
> > Please elaborate.
>
>IFF stores a linear
On Sat, Sep 15, 2001 at 12:39:39AM +0300, Jarkko Hietaniemi wrote:
> > It will be hard to use one format for both native and portable.
>
> Not one format, but a set of closely related formats with well-defined
> transformations between them.
After thinking about implementing this for a bit, I'm
At 03:01 PM 9/14/2001 -0700, Damien Neil wrote:
>On Fri, Sep 14, 2001 at 04:42:21PM -0400, Dan Sugalski wrote:
> > Where all word values are as big as the word size says they are.
>
>What should the byteloader do when it encounters data in a word that
>cannot fit in a native word?
That, generally
On Sat, Sep 15, 2001 at 01:03:51AM +0300, Jarkko Hietaniemi wrote:
> > Re: IFF. Being an old Amiga user, I find it appealing. Is the lack
> > of a dictionary likely to be a significant problem?
>
> Please elaborate.
IFF stores a linear series of chunks. Each chunk has a header containing
the
On Fri, Sep 14, 2001 at 03:01:11PM -0700, Damien Neil wrote:
> On Fri, Sep 14, 2001 at 04:42:21PM -0400, Dan Sugalski wrote:
> > Where all word values are as big as the word size says they are.
>
> What should the byteloader do when it encounters data in a word that
> cannot fit in a native word?
On Fri, Sep 14, 2001 at 04:42:21PM -0400, Dan Sugalski wrote:
> Where all word values are as big as the word size says they are.
What should the byteloader do when it encounters data in a word that
cannot fit in a native word?
Re: IFF. Being an old Amiga user, I find it appealing. Is the lack
I might try tonight doing *very* simple code to portably write and
read the bytecode header since I have access to 32/64 little/big
endian boxes and to the resident gremlin of a platform, UNICOS.
(Well, it's really UNICOS/mk, so it's LE, not BE, as real UNICOS,
but it still has the funky integer s
> It will be hard to use one format for both native and portable.
Not one format, but a set of closely related formats with well-defined
transformations between them.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'.
> There's a one-off conversion penalty at bytecode load time, and I don't
> consider that excessive. I want the bytecode to potentially be in platform
> native format (4/8 byte ints, big or little endian) with a simple and
> well-defined set of conversion semantics. That way the bytecode loader
On Fri, Sep 14, 2001 at 02:26:37PM -0700, Hong Zhang wrote:
> > We can't do that. There are platforms on both ends that
> > have _no_ native 32-bit data formats (Crays, some 16-bit
> > CPUs?). They still need to be able to load and generate
> > bytecode without ridiculuous CPU penalties (your Palm
--- Brian Wheeler <[EMAIL PROTECTED]> wrote:
> Ok, what if we did IFF with these caveats:
> * all chunks must be padded to 4 bytes (instead of IFF's
> 2)
> * no nesting of FORMs
>
> Chunks we'd need are:
>
> Name: 'PINF' - Parrot Information
> Size: 28 bytes + size o
Call me an old fuddy duddy if you will, or Unix-centric if you must, but
the .pl extension historically refers to Perl Libraries, and even now
that is my first thought when I see it.
Now I realise that many people working on this project have rarely, if
ever, used Perl 4 or earlier versions, and
> We can't do that. There are platforms on both ends that
> have _no_ native 32-bit data formats (Crays, some 16-bit
> CPUs?). They still need to be able to load and generate
> bytecode without ridiculuous CPU penalties (your Palm III
> is not running on a 700MHz Pentium III, after all!)
If the p
At 01:56 PM 9/14/2001 -0700, Hong Zhang wrote:
> > 8-byte word:endianness (magic value 0x123456789abcdef0)
> > byte: word size
> > byte[7]:empty
> > word: major version
> > word: minor version
> >
> > Where all word values are as big as the word size says
On Fri, 2001-09-14 at 15:42, Dan Sugalski wrote:
> At 03:10 PM 9/14/2001 -0500, Brian Wheeler wrote:
> >I've been thinking alot about the bytecode file format lately. Its
> >going to get really gross really fast when we start adding other
> >(optional) sections to the code.
> >
> >So, with that i
--- Brian Wheeler <[EMAIL PROTECTED]> wrote:
> I've been thinking alot about the bytecode file format
> lately. Its
> going to get really gross really fast when we start
> adding other
> (optional) sections to the code.
>
> So, with that in mind, here's what I propose:
>
> * All data sizes are
> PLEASE can someone rewrite the tests to actually *test* things
> and print "ok 1\n" and so on?
Here it is ( for the second time )
> Quick, or I'll call Schwern in.
Ah, I thought you missed my patches, then I was correct
both attached
testsuite.diff:
-
Run with
perl
> 8-byte word:endianness (magic value 0x123456789abcdef0)
> byte: word size
> byte[7]:empty
> word: major version
> word: minor version
>
> Where all word values are as big as the word size says they are.
>
> The magic value can be something else, but it
Brian --
> I've been thinking alot about the bytecode file format lately. Its
> going to get really gross really fast when we start adding other
> (optional) sections to the code.
>
> So, with that in mind, here's what I propose:
This may be too crazy, but if we take seriously the notion that
> > I believe that Microsoft is using a derivative of that format for some of
> > its files, and I think that TIFF files are another instantiation.
>
> To avoid using Redmondian references :-) I think IFF was one
> of the strongest inspirations for the PNG .
...and here's a link that explains t
Uri --
> well, pdp-11 assembler would be very cool to work in again if it weren't
> so painful to reinvent every wheel. c was a big step up and then perl
> even more so. no more (or almost no more) worries about memory
> management and boundary conditions. if a pasm macro assembler allows me
> so
On Fri, 2001-09-14 at 15:44, Buddha Buck wrote:
> At 03:10 PM 09-14-2001 -0500, Brian Wheeler wrote:
> >I've been thinking alot about the bytecode file format lately. Its
> >going to get really gross really fast when we start adding other
> >(optional) sections to the code.
> >
> >So, with that i
> Have you taken a look at the old Amiga IFF format? It consisted mainly of
> "chunks" identified by a 32-bit type code and a chunk-length code. While
> most implementations were for specific multi-media applications (chunks
> defining sound formats, chunks defining image formats, etc), the
At 04:44 PM 9/14/2001 -0400, Buddha Buck wrote:
>>What do you guys think?
>
>Have you taken a look at the old Amiga IFF format? It consisted mainly of
>"chunks" identified by a 32-bit type code and a chunk-length code. While
>most implementations were for specific multi-media applications (ch
At 03:10 PM 9/14/2001 -0500, Brian Wheeler wrote:
>I've been thinking alot about the bytecode file format lately. Its
>going to get really gross really fast when we start adding other
>(optional) sections to the code.
>
>So, with that in mind, here's what I propose:
>
>* All data sizes are in lon
At 03:10 PM 09-14-2001 -0500, Brian Wheeler wrote:
>I've been thinking alot about the bytecode file format lately. Its
>going to get really gross really fast when we start adding other
>(optional) sections to the code.
>
>So, with that in mind, here's what I propose:
>What do you guys think?
> "BW" == Brian Wheeler <[EMAIL PROTECTED]> writes:
BW> On Fri, 2001-09-14 at 10:20, Dan Sugalski wrote:
>> Okay, we've had a number of people in favor of a good macro assembler for
>> Parrot. Given that, do we have anyone who'll volunteer to define, maintain,
>> and extend the thin
Not to harp on this subject, but there is still no official place where a
casual developer like myself can find a current listing of PDDs aside from
the perl6-internals mail list archive. http://dev.perl.org/perl6 has not
been updated in a long time... and that's the place that I would expect
peo
> OffsetLength Description
> 0 1 Magic Cookie (0x013155a1)
> 1 n Data
> n+1 m Directory Table
> m+n+1 1 Offset of beginning of directory table (i.e. n+1)
I think we need a version right after cookie for long term compatibility.
> The directory is after
This patch adds:
an hints directory ( files are named hints/lc($^O).pl )
therir contents are eval'd in Config.pl
it adds to Config.pl some flags
--debugging Enable debugging
adds -g or equivalento to compiler flags
--defaults Accept all default values
like -d option to
> On Thu, Sep 13, 2001 at 11:07:00AM -0600, Nathan Torkington wrote:
> > Isn't the correct solution to this problem to say
> >#include
> >
> > That is, include the subdirectory prefix in all #includes. You -I the
> > directory containing parrot/, and that avoids randomly located
> > config.
Quoting Dan Sugalski <[EMAIL PROTECTED]>:
> Hmmm. I think we need a reorg of the source directories, then. I'll get
>
> with Simon and coordinate doing this. (It's going to make CVS *so*
> happy... :)
It's often easier to do this by moving the RCS files inside the CVS respository
directly - it's
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 10:33 PM 9/13/2001 -0400, Uri Guttman wrote:
>> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>>
DS> Actually, I'm expecting almost nothing to be written in pasm after
DS> we get a working parser and compiler. We mi
Just a quick note (since I have no time for more commentary...):
for inspiration on the data storage you might want to look at how
Storable has chosen to do things.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. --
I've been thinking alot about the bytecode file format lately. Its
going to get really gross really fast when we start adding other
(optional) sections to the code.
So, with that in mind, here's what I propose:
* All data sizes are in longwords (4 bytes) because that's just the way
things are :
All --
I've made some more additions to the Jako compiler and changed the
examples, including the addtion of a factorial example based on
Leon Brocard's fact.pasm submission earlier today.
At this point, Jako is reasonably friendly for coding little
programs such as these. I'd like to encourage
Gibbs Tanton - tgibbs:
# 1.) create an include/parrot directory under the main source directory
# 2.) move all .h files into include/parrot
# 3.) add -I./include to Configure.pl
The patch below my sig will handle the Configure side of things.
Include it in your own set of patches. Do not apply t
On Fri, Sep 14, 2001 at 12:16:52PM -0700, Brent Dax wrote:
> make test_prog
Is there any reason not to make test_prog build by default? The
.o files aren't very useful on their own. :>
- Damien
Gibbs Tanton - tgibbs:
# 1.) create an include/parrot directory under the main source directory
# 2.) move all .h files into include/parrot
# 3.) add -I./include to Configure.pl
I'll take care of the Configure munging--I have an idea for how to work
this.
--Brent Dax
[EMAIL PROTECTED]
They *wil
--- c:\old_parrot\READMEFri Sep 14 12:13:42 2001
+++ README Mon Sep 10 09:56:28 2001
@@ -34,11 +34,6 @@
For now, unpack your Parrot tarball, (if you're reading this, you've
probably already done that) type
+ perl Configure.pl
+
+to run the Configure script. This will generat
At 01:27 PM 9/14/2001 -0500, Gibbs Tanton - tgibbs wrote:
>Okeydokey.
>
>As all header files are already included as "parrot/x.h" then the following
>should be done:
>
>1.) create an include/parrot directory under the main source directory
>2.) move all .h files into include/parrot
>3.) add -I./in
Okeydokey.
As all header files are already included as "parrot/x.h" then the following
should be done:
1.) create an include/parrot directory under the main source directory
2.) move all .h files into include/parrot
3.) add -I./include to Configure.pl
any objections?
-Original Message-
On Fri, 14 Sep 2001, Gibbs Tanton - Tgibbs wrote:
> Ok,
> I'll fix it to where all header files are in a separate parrot subdirectory.
Sigh. Here's my original proposal again.
>
> cd parrot # Or wherever you've got the parrot source.
> mkdir include
> mkdir include/parrot
Ok,
I'll fix it to where all header files are in a separate parrot subdirectory.
-Original Message-
From: Dan Sugalski
To: Gibbs Tanton - tgibbs
Cc: [EMAIL PROTECTED]
Sent: 9/14/2001 12:36 PM
Subject: RE: Half-completed parrot/parrot.h conversion?
At 01:03 PM 9/14/2001 -0400, Gregor N.
On Fri, Sep 14, 2001 at 10:20:00AM +0100, Simon Cozens wrote:
> On Thu, Sep 13, 2001 at 08:54:40PM -0700, Damien Neil wrote:
> > Here's an updated version of my original patch, to account for recent
> > changes in CVS. As before, this includes opcode-munging to let Parrot
> > run on FreeBSD.
...
Attached is a patch to assemble.pl that adds very simple macros. I
fear it's a bit of a hack, but I'm fighting my usual impulse to
rewrite stuff.
Attached is also macros.pasm, a simple usage case. It goes in t/ for
want of a better place, but it's not a true test yet.
-- Rocco Caputo / [EMAIL
At 01:03 PM 9/14/2001 -0400, Gregor N. Purdy wrote:
>Gibbs --
>
> > The patch assumes that your source code directory is named parrot.
> > This may
> > have been an invalid assumption, but it is going to be hard to do this
> patch
> > unless we agree on the name of the source directory.
>
>Ah. I
The attached patch munges the tests (well, examples really)
in the following ways:
a) use set instead of set_i_ic
b) more comments
c) newlines at strategic places
This brings up two problems I don't understand. test.pasm produces the
following crud for me (meaning the I t
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> So, I'm currently working on the stack system for Parrot.
> I've got the
> following issue here.
>
> Assuming there's one general stack to save "stuff" on,
> where stuff is:
Out of curiousity, why only one stack? Perl 5 has at least
four or five tha
On Fri, Sep 14, 2001 at 11:31:20AM -0500, Gibbs Tanton - tgibbs wrote:
> The patch assumes that your source code directory is named parrot. This may
> have been an invalid assumption, but it is going to be hard to do this patch
> unless we agree on the name of the source directory.
That may be d
Gibbs --
> The patch assumes that your source code directory is named parrot.
> This may
> have been an invalid assumption, but it is going to be hard to do this patch
> unless we agree on the name of the source directory.
Ah. I try not to assume the source directory name, since folks might
rena
All --
It seems to me that the full complement of set_* ops should be something
like this (minus PMC stuff):
set_i_ic # We have this
set_i_i # We have this, and call it set_i
set_i_nc # NOT NEEDED: Assembler does it
set_i_n # We have this, a
On Fri, Sep 14, 2001 at 11:36:04AM -0500, Gibbs Tanton - tgibbs wrote:
> Ok, my previous patch to assemble.pl caused somethings to core dump...I
> promise this one won't :) It fixes the problem with numeric values having
> the wrong pack type. Also, config_h.in was changed to typedef ${iv} doubl
On Fri, Sep 14, 2001 at 12:33:37PM -0400, Rocco Caputo wrote:
> The attached assemble.diff has assemble.pl look in its parent
> directory if the data files it needs aren't in the current one. This
> lets me camp out in t/ and assemble stuff over and over.
>
> The attached Makefile goes in the t/
At 11:31 AM 9/14/2001 -0500, Gibbs Tanton - tgibbs wrote:
>The patch assumes that your source code directory is named parrot. This may
>have been an invalid assumption, but it is going to be hard to do this patch
>unless we agree on the name of the source directory.
Hmmm. I think we need a reorg
Ok, my previous patch to assemble.pl caused somethings to core dump...I
promise this one won't :) It fixes the problem with numeric values having
the wrong pack type. Also, config_h.in was changed to typedef ${iv} double
NV to typedef ${nv} NV
Index: assemble.pl
The attached assemble.diff has assemble.pl look in its parent
directory if the data files it needs aren't in the current one. This
lets me camp out in t/ and assemble stuff over and over.
The attached Makefile goes in the t/ directory. It lets me reassemble
files by invoking "make test.pbc".
-
The patch assumes that your source code directory is named parrot. This may
have been an invalid assumption, but it is going to be hard to do this patch
unless we agree on the name of the source directory.
-Original Message-
From: Gregor N. Purdy
To: [EMAIL PROTECTED]
Sent: 9/14/2001 11:
All --
When I updated my sandbox this morning, I discovered that some files
wanted includes from ./parrot/*.h. So, I had to create the directory
manually, and did a bunch of ln foo.h parrot/foo.h's until I got no
more complaints. Is someone in the middle of the change, or was it
missed?
Also, I
Dan/All --
> Keen! And I added a little_languages subdir to hold compilers of this sort.
> (And checked in jako while I was at it...)
Thanks! I've enhanced the compiler a bit and fixed a bug in the
handling of while(){}. I've also added some features and rewritten
the fibo.pasm example program
On Fri, Sep 14, 2001 at 10:33:19AM -0500, Brian Wheeler wrote:
> On Fri, 2001-09-14 at 10:20, Dan Sugalski wrote:
> > Okay, we've had a number of people in favor of a good macro assembler for
> > Parrot. Given that, do we have anyone who'll volunteer to define, maintain,
> > and extend the thing
[EMAIL PROTECTED] sent the following bits through the ether:
> Here is the fibonaci function
Here are slightly cleaner (could even be used for testing purposes)
fibonacci and factorial example files. I'd say bundle them in as
examples and prod me until I do the test suite
Leon
--
Leon Broc
On Fri, Sep 14, 2001 at 11:20:36AM -0400, Dan Sugalski wrote:
> Okay, we've had a number of people in favor of a good macro assembler for
> Parrot. Given that, do we have anyone who'll volunteer to define, maintain,
> and extend the thing? (Presuming we jump off of the current assembler,
> whic
First, good news! Parrot now builds - and works - on FreeBSD.
However, the output from the tests now looks really silly
given that we've got no newlines on printing integer and
float registers.
PLEASE can someone rewrite the tests to actually *test* things
and print "ok 1\n" and so on?
Quick, o
Lvalue casts are evil, I know. Patches welcome.
cc: Warning: bytecode.c, line 89: In this statement, the result of the cast "(char
...)*program_code" is used as an lvalue.
(char*)*program_code += buflen;
^
cc: Warning: bytecode.c, line 97: In this statement, the result of the cas
At 10:33 AM 9/14/2001 -0500, Brian Wheeler wrote:
>On Fri, 2001-09-14 at 10:20, Dan Sugalski wrote:
> > Okay, we've had a number of people in favor of a good macro assembler for
> > Parrot. Given that, do we have anyone who'll volunteer to define,
> maintain,
> > and extend the thing? (Presuming
On Fri, 2001-09-14 at 10:20, Dan Sugalski wrote:
> Okay, we've had a number of people in favor of a good macro assembler for
> Parrot. Given that, do we have anyone who'll volunteer to define, maintain,
> and extend the thing? (Presuming we jump off of the current assembler,
> which seems reaso
Yes-
People just need to agree to send all patches to RT first so that
they can be tagged in their subject line, so discussion gets
tracked. For now, RT needs to be CC'ed on followups - soon it
will just "listen".
When Simon/Dan/$PATCHER applies/rejects a patch, they can t
Okay, we've had a number of people in favor of a good macro assembler for
Parrot. Given that, do we have anyone who'll volunteer to define, maintain,
and extend the thing? (Presuming we jump off of the current assembler,
which seems reasonable)
There probably isn't a huge amount to do with the
At 10:33 PM 9/13/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> Actually, I'm expecting almost nothing to be written in pasm after
> DS> we get a working parser and compiler. We might write template code
> DS> for the compiler in it, but that'
At 09:36 AM 9/14/2001 +0100, Leon Brocard wrote:
>Dan Sugalski sent the following bits through the ether:
>
> > Actually, I'm expecting almost nothing to be written in pasm after we
> get a
> > working parser and compiler
>
>I am, as you may have noticed already, clearly a frustrated assembler
>p
At 09:02 AM 9/14/2001 -0500, Brian Wheeler wrote:
>I've tracked it down to string problems.
Might not be just string problems. There was a change to memory.c that
caused the memory allocations to round addresses down, not up. Sync up and
try it again.
Da
So, I'm currently working on the stack system for Parrot. I've got the
following issue here.
Assuming there's one general stack to save "stuff" on, where stuff is:
* Scope entries
* Return addresses for JSRs
* Saved individual registers
* Local() calls
Should plain "return"s at
On Fri, Sep 14, 2001 at 08:34:22AM -0600, Nathan Torkington wrote:
> I wonder if, when RT comes online, we could use that to manage the
> patches. In other words, patches become open "to do" items, which are
> cleared when the patches are definitively applied or rejected.
That would be nice; som
Gibbs Tanton - tgibbs:
# Here is the parrot/config.h patch
#
# It fixes Makefile.in, but not in the correct way. Brent, if
# you could look
# at this and fix it the right way I would really appreciate it
# (note that I
# have no clue what the right way is :)
It's understandable that you couldn't
At 10:16 AM 9/14/2001 -0400, Gregor N. Purdy wrote:
>All --
>
>For your amusement, I've produced a very simple compiler that targets
>Parrot assembly language. It implements a tiny language name 'Jako',
>the name of an African parrot (also called the gray parrot).
Keen! And I added a little_langu
Simon Cozens writes:
> So maybe the best thing would be for people to send patches to the
> list and Cc [EMAIL PROTECTED]
I wonder if, when RT comes online, we could use that to manage the
patches. In other words, patches become open "to do" items, which are
cleared when the patches are definiti
All --
For your amusement, I've produced a very simple compiler that targets
Parrot assembly language. It implements a tiny language name 'Jako',
the name of an African parrot (also called the gray parrot).
Don't get too excited about the language, since it has only global
data, highly naiive re
On Fri, Sep 14, 2001 at 08:26:05AM -0500, Gibbs Tanton - tgibbs wrote:
> Here is the parrot/config.h patch
Thanks applied (so that Brent can have a look at it)
Be careful with line wrapping, by the way.
Simon
1 - 100 of 122 matches
Mail list logo
