Re: String API
Thus wrote the illustrious Simon Cozens: [severely trimmed] > STRING* string_make(void *buffer, IV buflen, IV > encoding, IV flags, IV type) > STRING* string_copy(STRING* s) > void string_destroy(STRING *s) *cough* Namespace pollution *cough* These should proably all be prefixed... -- BKS __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
Re: String API
On Mon, Sep 10, 2001 at 04:48:35AM -0700, Benjamin Stuhl wrote: > *cough* Namespace pollution *cough* > These should proably all be prefixed... You're going to have a canary when you see the rest of the code... :) Seriously, I see the string subsystem as being self-sufficient; it can be detached from Parrot as a stand-alone string library, and hence shouldn't have Parrot_... prefices. Simon
String API
You'll be glad to hear that the interpreter now supports strings.
Here's a document about how that happens and what STRING* means and
its API. As before, I'd like
i) people to come up with more fundamental operations on strings
ii) someone to take over this document and patch it up based on
the results of this thread so I can go on writing the next bit of
documentation...
=head1 The Parrot String API
This document describes how Parrot abstracts the programmer's interface
to string types. All strings used in the Parrot core should use the
Parrot C structure; Parrot programmers should not deal with
C or other string-like types outside of this abstraction without
very good reason.
=head1 Interface functions on Cs
In fact, programmers should hardly ever even access members of the
C structure directly. The reason for this is that the
interpretation of the data inside the structure will be a function of
the data's encoding. The idea is that Parrot's strings are
encoding-aware so your functions don't need to be; if you break the
abstraction, you suddenly have to start worrying about what the data
actually means.
=head2 String Constructors
The most basic way of creating a string is through the function
C:
STRING* string_make(void *buffer, IV buflen, IV encoding, IV flags, IV type)
In here you pass a pointer to a buffer of a given encoding, and the
number of bytes in that buffer to examine, the encoding, (see below for
the C which defines the different encodings) and the initial
values of the C and C field. These should usually be zero.
In return, you'll get a brand new Parrot string. This string will
have its own private copy of the buffer, so you don't need to keep it.
=over 3
=item *
I: Nothing stops you doing
string_make(NULL, 0, ...
=back
If you already have a string, you can make a copy of it by calling
STRING* string_copy(STRING* s)
This is itself implemented in terms of C.
When a string is done with, it can be destroyed using the destructor
void string_destroy(STRING *s)
=head2 String Manipulation Functions
Unless otherwise stated, all lengths, offsets, and so on, are given in
characters; you are not allowed to care about the byte representation of
a string, so it doesn't make sense to give the values in bytes.
To find out the length of a string, use
IV string_length(STRING *s)
You I explicitly use C<< s->strlen >> for this since it is such a
useful operation.
To concatenate two strings - that is, to add the contents of string
C to the end of string C, use:
STRING* string_concat(STRING* a, STRING *b, IV flag)
C is updated, and is also returned as a convenience. If the flag is
set to a non-zero value, then C will be transcoded to C's encoding
before concatenation if the strings are of different encodings. You
almost certainly don't want to stick, say, a UTF-32 string on the end of
a Big-5 string.
Chopping C characters off the end of a string is achieved with the
unlikely-sounding
STRING* string_chopn(STRING* s, IV n)
B:
To retrieve a substring of the string, call
STRING* string_substr(STRING* src, IV offset, IV length, STRING** dest)
The result will be placed in C.
(Passing in C avoids allocating a new string at runtime. If
C<*dest> is a null pointer, a new string structure is created with the
same encoding as C.)
B:
To format output into a string, use
STRING* string_nprintf(STRING* dest, IV len, char* format, ...)
C may be a null pointer, in which case a new B string will
be created. If C is zero, the behaviour becomes more Cish
than C-like.
=head1 Elements of the C structure
Those implementing the C API will obviously need to know about
how the C structure works. You can find the definition of this
structure in F:
struct parrot_string {
void *bufstart;
IV buflen;
IV bufused;
IV flags;
IV strlen;
IV encoding;
IV type;
IV unused;
};
Let's look at each element of this structure in turn.
=head2 C
This pointer points to the buffer which holds the string, encoded in
whatever is the string's specified encoding. Because of this, you should
not make any assumptions about what's in the buffer, and hence you
shouldn't try and access it directly.
=head2 C
This is used for memory allocation; it tells you the currently allocated
size of the buffer in bytes.
=head2 C
C on the other hand, contains the number of bytes out of the
allocated buffer which are actually in use. This, together with
C, is used by the buffer growing algorithm to determine when and
by how much to grow the allocation buffer.
=head2 C
This is a general holding area for string flags. The exact flags
required have not yet been determined.
=head2 C
This is the length of the string in characters, as you would expect to
find from C in Perl. Again, because string buffers may
be in one of a number of encodings, this must be computed by the
appropriate encoding function. C updates
this value, calling the
Re: String API
On Mon, Sep 10, 2001 at 12:53:51PM +0100, Nicholas Clark wrote: > > void *bufstart; > > A split buffer would allow an offset at the front, by effectively treating > the STRING as '' . 'Pathologically Eclectic Rubbish Lister' Who says we don't support split buffers? void* bufstart can be anything you like. This is the point of the abstraction. Simon
Re: String API
--- Simon Cozens <[EMAIL PROTECTED]> wrote: > On Mon, Sep 10, 2001 at 04:48:35AM -0700, Benjamin Stuhl > wrote: > > *cough* Namespace pollution *cough* > > These should proably all be prefixed... > > You're going to have a canary when you see the rest of > the code... :) I know. I've looked at the anon CVS, such as it is. > Seriously, I see the string subsystem as being > self-sufficient; it can be > detached from Parrot as a stand-alone string library, and > hence shouldn't have > Parrot_... prefices. Except that Parrot is written assuming its there, which means that Parrot itself needs to be linked against it. If we're being embedded, we might clash with the main program's own string library, which shoots down the entire project. I would look at this more like glib - it's a utility library, but it's still prefixed because who knows what else the final executable will be linked against. -- BKS (who seems to have accidentally become the namespace police) __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
Re: An overview of the Parrot interpreter
On 09/07/01 Dan Sugalski wrote: > >The only optimizations that interpreter had, were computed goto and > >allocating the eval stack with alloca() instead of malloc(). > > Doesn't this really get in the way of threading? You'll chew up great gobs > of system stack, and that's a scarce resource when running with threads. The number of entries in the eval stack is bounded, I've never seen it grow past 13. > >I think they worked also on outputting IL bytecode... > > Yep, but that version was slower. Dick Hardt snagged me at TPC this year (I > think I spent most of my non-speaking time being pinned to a table or bench > by folks with Things To Say... :) and made a .NET pitch. They were going > with the translation to .net but switched to embedding perl. It was a lot > faster. (Brad Kuhn had a paper on translating perl to java bytecode and he > had lots of trouble, but for different reasons) My point is that using their experience, a few changes should be designed to better support dynamic languages in the CLR in the same way that currently the research is focused on extending it for functional languages, generics etc. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
Re: PDD 6: Parrot Assembly Language
At 10:09 PM 9/9/2001 +0100, Simon Cozens wrote: >On Fri, Sep 07, 2001 at 04:30:56PM -0400, Dan Sugalski wrote: > > =item find_method Px, Py, tz > >Using what kind of dispatch mechanism? Or is that what the t is for? That bit needs to change because of some of the stuff I've been digging into. Basically dispatch is handled by the object itself. When you do: $foo->bar(1,2,3); under the hood we look up the method call function in $foo's vtable and tell it to go handle things. That way people can install per-class (or per-object, if they must) dispatch code. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Math functions? (Particularly transcendental ones)
At 08:07 PM 9/9/2001 -0400, Uri Guttman wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > DS> Yeah, I can't think of a good reason for a noop. We might have one > DS> anyway, though, just in case one comes along anyway. > >in a hardware cpu they were commonly used to fill an instruction slot to >keep a pipeline filled, or to follow a branch decision, or to pad a long >running op. Yup, I realize that. I wasn't sure that we might not have some sort of in-memory opcode whiteout thing we need to do, in which case it'd be useful and potentially faster than recalculating a bunch of jump addresses. > >> Here's a dumb question: will parrot allow bytecode which is stored in a > >> perl scalar to be executed? > > DS> Yup, in a restricted sandbox too, if you want. That way we'll be > DS> able to serialize code to bytestreams, spit them across the 'net, > DS> and execute them on the other end. > >will the op code table need to be sent over if it is code from a module >which defines new op codes? Basically we'll build a small "freeze to disk" section and send it over the wire instead of freezing to disk. It'll have all the standard stuff--fixup section, constants section, and code. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String API
At 12:53 PM 9/10/2001 +0100, Nicholas Clark wrote:
>On Sun, Sep 09, 2001 at 10:16:27PM +0100, Simon Cozens wrote:
> > =head1 Elements of the C structure
> >
> > Those implementing the C API will obviously need to know about
> > how the C structure works. You can find the definition of this
> > structure in F:
> >
> > struct parrot_string {
> > void *bufstart;
> > IV buflen;
> > IV bufused;
> > IV flags;
> > IV strlen;
> > IV encoding;
> > IV type;
> > IV unused;
> > };
>
>At some point on p5p Ilya Zakharevich expressed regret that perl5 doesn't
>support split buffers. A split buffer would allow things like regular
>expressions to run faster when repeatedly substituting in the middle of a
>string, as it reduces the amount of data to copy. With a single contiguous
>buffer
As Simon's said, the buffer can certainly be pointing to a fancier data
structure than "heap 'o bytes". :) I hadn't considered that, though. I was
thinking that split strings would be dealt with at a higher-level of
abstraction--in the PMC (basically at the variable level) rather than in
the string itself.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: Math functions? (Particularly transcendental ones)
Uri Guttman wrote:
> but having parrot op codes map to special instructions
> makes sense only if we are doing some form of machine instruction
> generation as with JIT or TIL.
Actually, I wasn't necessarily asking for any special ops (I'm not actually
asking for anything, it's just a suggestion), just that the boolean math
operations use a specific register or registers. I think this would make
implementing code generation on those platforms more straight-forward.
Things like:
if( $port_read && 0xF7 ) {...
would tell perl to place the word into the bool-specific register, and the
implementation for the platform could then see that the operation on that
register would be a more likely candidate for optimizations such as:
LOW B0, AX ; get low-order byte of bool register (from DATA?)
BITT B0, 4 ; test bit4 of B0
or whatever the actual ASM ops are.
If the word were to be randomly assigned to any register, then all similar
operations would need to be tested for those potential optimizations. That's
not impossible, however in RT/embedded systems those ticks are at a premium.
Again, I'm not implying this is necessary, but only a suggestion. It may
however also offer gains in some internal (event?/flag?) operations.
Grant M.
P.S.> Dan, looking forward to meeting you on Tuesday night.
[EMAIL PROTECTED]
Re: PDD 6: Parrot Assembly Language
On Fri, Sep 07, 2001 at 04:30:56PM -0400, Dan Sugalski wrote: > =item find_method Px, Py, tz Using what kind of dispatch mechanism? Or is that what the t is for? Simon
Re: Configurators!
Yes, I'm still interested. Don't know how much I'll have time, though, (even after 5.8.0, that is). But I guess (together with Andy) we can at least tell horror stories about all the possible ways of how *not* to do it to scare all the young whippersnappers :-) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Simon Cozens is the Source Pumpking
I'm happy to say that, in preparation for the release of the first piece of Parrot code, Simon Cozens has stepped forward to hold the source pumpkin. Simon's responsible for the contents of the internal and external source distribution. He'll update the CVS repository with patches submitted by the public to perl6-internals. He'll make periodic releases available on CPAN. He'll also build an initial team of committers from those who submit good patches. Simon will have to work closely with many people, including: * Larry, who is designing the language * Dan, who is designing the internals * Schwern and everyone else from QA, who will be responsible for smoking the builds, unit testing, and more * The as-yet-unknown configuration and build group, responsible for determining system configuration and the build process. Nat
Re: Math functions? (Particularly transcendental ones)
> "DW" == David Whipp <[EMAIL PROTECTED]> writes: DW> Dan Sugalski wrote: >> Okay, I'm whipping together the "fancy math" section of the >> interpreter assembly language. I've got: DW> [...] >> Can anyone think of things I've forgotten? It's been a while >> since I've done numeric work. DW> I'm not sure where this belongs, but I'd really like to have DW> a usage model for some of the edges of arithmetic. For example, DW> it should be possible to enable/disable overflow and underflow DW> exceptions. Basically, Perl5 should be IEE754 compliant; and it DW> should support the (optional) traps. It would also nice to have DW> a saturation-on-overflow mode/type. we are planning automatic over/underflow to bigfloat. so there is no need for traps. they could be provided at the time of the conversion to big*. DW> If you have this type of stuff for floats; it'd be consistant to DW> have it for integers, too. overflow to bigint is also planned. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
RE: Math functions? (Particularly transcendental ones)
At 10:58 AM 9/10/2001 -0700, David Whipp wrote: >Dan Sugalski wrote: > > Okay, I'm whipping together the "fancy math" section of the > > interpreter assembly language. I've got: >[...] > > Can anyone think of things I've forgotten? It's been a while > > since I've done numeric work. > >I'm not sure where this belongs, but I'd really like to have >a usage model for some of the edges of arithmetic. For example, >it should be possible to enable/disable overflow and underflow >exceptions. Basically, Perl5 should be IEE754 compliant; and it >should support the (optional) traps. It would also nice to have >a saturation-on-overflow mode/type. I'd intended the basic math ops on floats and ints (the ones in I and N registers) to ignore over and underflow stuff, or potentially throw exceptions, though there's no exception code at the moment. For math ops on variables, I'd intended they catch the exceptions and handle upgrading as appropriate. (The assumption being that the compiler would generate the low-level int/float code and make sure things don't over/underflow. I'm thinking that was probably a naive thought... :) >If you have this type of stuff for floats; it'd be consistant to >have it for integers, too. Yep. For variable operations we'd need it certainly, to catch cases where we need to go to the bigint format. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Math functions? (Particularly transcendental ones)
Uri Guttman > we are planning automatic over/underflow to bigfloat. so there is no > need for traps. they could be provided at the time of the > conversion to big*. OK. But will Perl support signaling and non-signaling NANs?
RE: Math functions? (Particularly transcendental ones)
> Uri Guttman > > we are planning automatic over/underflow to bigfloat. so there is no > > need for traps. they could be provided at the time of the > > conversion to big*. > > OK. But will Perl support signaling and non-signaling NANs? I don't think we should go for automatic overflow/underflow between float and bigfloat. The float exception (overflow, underflow, inexact, divide zero, ...) is very difficult to handle. Using Unix signal is expensive and very platform-specific (lots of ucontext issues). Since C language does not support floating-point signal, we may use some assembly code to handle it, it will be porting nightmare. Since most of floating-point assumes IEEE-semantics, taking automatic float/bigfloat will change this assumption significantly. It may a lot of code and algorithm. I think it is safer just to provide a BigDecimal class for developers to use, and keep the basic float semantics (close to 64-bit IEEE-754 if possible). Hong
Re: Math functions? (Particularly transcendental ones)
Dan Sugalski wrote: >Okay, I'm whipping together the "fancy math" section of the interpreter >assembly language. I've got: [...] > >Can anyone think of things I've forgotten? It's been a while since I've >done numeric work. I'm not a math weenie, but I would thing gamma(x) would be of use. Also perhaps a div2(n,m): given two ints, returns two ints, n/m and n%m. -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
RE: Math functions? (Particularly transcendental ones)
At 02:12 PM 9/10/2001 -0700, Hong Zhang wrote: > > Uri Guttman > > > we are planning automatic over/underflow to bigfloat. so there is no > > > need for traps. they could be provided at the time of the > > > conversion to big*. > > > > OK. But will Perl support signaling and non-signaling NANs? > >I don't think we should go for automatic overflow/underflow between >float and bigfloat. Not for N registers, no. Perl's standard scalar variable will do this, though. >The float exception (overflow, underflow, inexact, >divide zero, ...) is very difficult to handle. That's why we wrap it in a generic macro and leave it for the individual ports to handle. >Using Unix signal is >expensive and very platform-specific (lots of ucontext issues). Since >C language does not support floating-point signal, we may use some >assembly code to handle it, it will be porting nightmare. Not if we do it right to start. Yes, there may be snippets of assembly in solaris.c/vms.c/linux.c/whatever.c, but that's fine. We can use a boring test comparison as a generic replacement on platforms people don't want to use a specific one on. >Since most of floating-point assumes IEEE-semantics, taking automatic >float/bigfloat will change this assumption significantly. Most people I know that use floating point numbers don't have any idea that there are well-defined IEEE semantics, let alone what they are. Some folks are, and for them we'll make sure you can avoid leaving IEEE floats. Of course, that's as much an argument for automatically going straight to bigfloats rather than going to native floats, since if people generally have no idea what the errors inherent in IEEE floats are they probably ought not use them. That's something to take up with Larry, though. >It may a >lot of code and algorithm. I think it is safer just to provide a >BigDecimal class for developers to use, and keep the basic float >semantics (close to 64-bit IEEE-754 if possible). IEEE floats suck. (I've got an amazingly bad opinion of a lot of widely-accepted computer practice, don't I? :) They're an OK option for what they are, and the hardware speed support is nice, but let's face it, they're a compromise with adequate characteristics, and the design compromises are usually the wrong ones (with the single exception of speed) for what most people do with floats in perl. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Math functions? (Particularly transcendental ones)
Dan Sugalski wrote: > Okay, I'm whipping together the "fancy math" section of the > interpreter assembly language. I've got: [...] > Can anyone think of things I've forgotten? It's been a while > since I've done numeric work. I'm not sure where this belongs, but I'd really like to have a usage model for some of the edges of arithmetic. For example, it should be possible to enable/disable overflow and underflow exceptions. Basically, Perl5 should be IEE754 compliant; and it should support the (optional) traps. It would also nice to have a saturation-on-overflow mode/type. If you have this type of stuff for floats; it'd be consistant to have it for integers, too. Dave.
Re: Muddled Boundaries - Perl 6 vs Parrot
On Monday 10 September 2001 12:58 pm, Nathan Torkington wrote: > Here's my Official Word. Right now it's too early to know whether > building perl6's runtime to also support other languages will impact > perl6's speed or size. We also have faced skepticism about the whole > effort from other languages. > > So we're proceeding with designing perl6. We're leaving the door open > for other languages, but we're not going to significantly delay or > impede perl6 to support them. Most excellent. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Math functions? (Particularly transcendental ones)
> "W" == Wizard <[EMAIL PROTECTED]> writes:
W> Uri Guttman wrote:
>> but having parrot op codes map to special instructions
>> makes sense only if we are doing some form of machine instruction
>> generation as with JIT or TIL.
W> Actually, I wasn't necessarily asking for any special ops (I'm not
W> actually asking for anything, it's just a suggestion), just that
W> the boolean math operations use a specific register or registers. I
W> think this would make implementing code generation on those
W> platforms more straight-forward.
which level of code generation are you refering to? parrot op codes or
machine instructions?
W> Things like:
W>if( $port_read && 0xF7 ) {...
W> would tell perl to place the word into the bool-specific register, and the
W> implementation for the platform could then see that the operation on that
W> register would be a more likely candidate for optimizations such as:
W>LOW B0, AX ; get low-order byte of bool register (from DATA?)
W>BITT B0, 4 ; test bit4 of B0
W> or whatever the actual ASM ops are.
same question.
W> If the word were to be randomly assigned to any register, then
W> all similar operations would need to be tested for those potential
W> optimizations. That's not impossible, however in RT/embedded
W> systems those ticks are at a premium.
again, i think you are conflating parrot registers with machine
registers. they are not the same and there is no mapping from one to the
other on any particular platform. when we get to TIL or JIT which both
will generate real machine code, then architecture specific
optimizations will be addressed. right now the actual machine
architecture is (mostly) irrelevant in discussing parrot op
codes. parrot op codes will be implemented in portable c and not in
platform dependent assembler for the obvious portability reasons.
uri
PS. my cc's to you are bouncing with a delivery warning. this is replied
only to the list.
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Search or Offer Perl Jobs -- http://jobs.perl.org
RE: Math functions? (Particularly transcendental ones)
Well, I used to do some embedded systems programming using C, and many of
the compilers would make attempts to optimize logical ops like
if( byte_variable & 0xF7 ){...
into something using a processor op equivalent to the 8051C
testbit( byte_variable, bit_offset).
The 8051 processor has several direct, optimized, bit-test and manipulation
ops built-in, equivalent to the 8051C testbit, bitset, high, and low (and
probably more that I don't recall - it's been more than 10 years). These ops
were heavily used in embedded systems (they likely still are ;-).
The idea behind the separate boolean register(s) would be to make it
simpler for the implementer of perl on one of these targets to decide what
to test for optimization. It could also make it "more better" for
determining what ops require extended functionality (like carrys/overflows
for integers... or maybe not).
I have plans on being at your demo on Tuesday and, if you'd like, I think
I still have an old Intel 8051 code manual around somewhere that you can
have. Or if I'm not making myself clear enough (which happens fairly
regularly ;-), tell me... I promise not to be offended.
Let me know,
Grant M.
Re: String API
[EMAIL PROTECTED] (Simon Cozens) writes: > =head2 C > > This field is, as its name suggests, unused; however, it can be used to > hold a pointer to the correct vtable for foreign strings. Wouldn't it be better to put a vtable * directly inside struct parrot_string instead of the 'encoding' enum? That would save the 'unused' slot for foreign encodings and you wouldn't need an additional layer of wrapper functions (or another way of indirection) for enc_foreign. The small integer ids you need for transcoding table lookups, etc. could be stored in a dedicated slot in the string vtables, or returned by a vtable function. -Edwin
Re: String API
Will the buffers associated with a string be managed by Parrot's memory management, and be visible to the garbage collector ? Or will these buffers be allocated from their own pool of memory not subject to garbage collection. -- Jason
Re: Math functions? (Particularly transcendental ones)
On Monday 10 September 2001 10:28 am, Brian Wheeler wrote: > > I was thinking about NOP this morning, and I realized that it might very > well be necessary. If someone was writing a "simple" assembler for > parrot, it might be useful for padding. Pad what? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Muddled Boundaries - Perl 6 vs Parrot
On Mon, Sep 10, 2001 at 10:58:33AM -0600, Nathan Torkington wrote: > let's assume that Parrot will only officially be part of the Perl project, > and focus on writing more Parrot code instead of arguing about > namespaces. What He Said. And in addition - why are we worrying about namespace collision RIGHT NOW? Sure, when Parrot can be embedded, then we should ensure that our names aren't going to clash. But who in their right minds is going to embed Parrot in anything in its current state? (Leon, I said "in their right minds") It's not a priority, compared to getting working code out there. We can sort it out later. Simon
Re: Patch to assembler/disassembler + parrot asm inconsistancies
At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote: >First off, here's an inconsistancy I found: In test.pasm > >REDO: eq_i_ic I2, I4, DONE, NEXT > >appears. Shouldn't this be comparing to a constant, not a register? Nope, though if I let you in on the actual secret it's help. That should really be eq_i_ic_ic. (Well, actually there should be only one label, and we fall through otherwise. It's a bug in implementation and assembly, not opcode name... :) The intention is the last _x covers the last arg, the next to last covers the next to last arg, and so on. When we run out, we repeat the innermost type. The ultimate intention is that you'd write that as a plain: eq I2, I4, DONE, NEXT or probably eq I2, I4, DONE and either way the assembler would know DONE was a constant and we needed i registers since that was specified, and emit the eq_i_ic opcode. >It >became a little obvious when I made a few changes to the >assembler/disassembler to give more details about the data (and to allow >shortcuts like "add I1,I2,I3" to go to "add_i I1,I2,I3", etc) >The opcode_table patch changes the argument encoding to use these terms: ># i Integer constant ># I Integer register ># n Numeric constant ># N Numeric register ># s String constant? ># S String register ># D Destination I was using a trailing c to note a constant since we're using the opcode name as a C function name, and we're not counting on case-sensitivity in symbols. Other than that (well, and Simon has a patch in to the repository to yank out the opcode numbers entirely from opcode_table) it looks keen. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Muddled Boundaries - Perl 6 vs Parrot
On Monday 10 September 2001 01:08 pm, Simon Cozens wrote: > And in addition - why are we worrying about namespace collision RIGHT NOW? > Sure, when Parrot can be embedded, then we should ensure that our names > aren't going to clash. But who in their right minds is going to embed > Parrot in anything in its current state? (Leon, I said "in their right > minds") > > It's not a priority, compared to getting working code out there. We can > sort it out later. Oh, how many times have I heard that before? It's not a prioirty, but it's so much easier to walk the correct path from the start. Since it's all Parrot, it's even easier. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: String API
At 12:46 PM 9/10/2001 -0400, Jason Gloudon wrote: >Will the buffers associated with a string be managed by Parrot's memory >management, and be visible to the garbage collector ? Or will these buffers be >allocated from their own pool of memory not subject to garbage collection. They'll be GC'd. (Except in a very few circumstances, for example when pointing to a shared buffer, memory Parrot doesn't own, or memory that can't move because it's passed to an external library or hardware) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
FYI, that last email was sent last night...
I'm having trouble with my hosting company (wehost.net is poop!). That last email was a reply that I sent last night at 6pm. Please ignore it :-P Grant M.
Re: Muddled Boundaries - Perl 6 vs Parrot
At 01:20 PM 9/10/2001 -0400, Bryan C. Warnock wrote: >On Monday 10 September 2001 01:08 pm, Simon Cozens wrote: > > And in addition - why are we worrying about namespace collision RIGHT NOW? > > Sure, when Parrot can be embedded, then we should ensure that our names > > aren't going to clash. But who in their right minds is going to embed > > Parrot in anything in its current state? (Leon, I said "in their right > > minds") > > > > It's not a priority, compared to getting working code out there. We can > > sort it out later. > >Oh, how many times have I heard that before? Yeah, me too. :) Seriously, I think we should get it right from the start, if for no other reason than I can stop writing opcode and utility functions with the same name and coring the interpreter. (Which would be a nice change) It is my fault to begin with, since I started the show with no prefixes. It may also make things easier when we start dynaloading libraries, as we'll be doing pretty darned soon. (String and opcode function libraries, at least, and the rest will follow) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Math functions? (Particularly transcendental ones)
At 06:26 PM 9/9/2001 -0700, Wizard wrote: >into something using a processor op equivalent to the 8051C >testbit( byte_variable, bit_offset). This is pretty much testbit I0, 6 to test whether bit 6 is set i I0, right? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Muddled Boundaries - Perl 6 vs Parrot
Bryan C. Warnock writes: > It's not a prioirty, but it's so much easier to walk the correct path from > the start. Since it's all Parrot, it's even easier. I agree. How about this: when the code is available (i.e., this afternoon), why don't you sit down with whoever else feels passionately about this, and add the namespace protection? There's no reason why it can't be added early, and I agree with Simon that he has higher priority things to worry about, but there's no reason why you or anyone else can't add it in. And it should be easy to add it in while the codebase is small. Namespace protection seems tricky. You need a list of symbols, categorized public or private. You need to automatically check the symbol list (e.g., output of nm) to see you're not exporting un-prefixed symbols. And so on. The more of this stuff that can be automated, the better. Go to it! Nat
RE: Math functions? (Particularly transcendental ones)
> At 06:26 PM 9/9/2001 -0700, Wizard wrote: > >into something using a processor op equivalent to the 8051C > >testbit( byte_variable, bit_offset). > > This is pretty much > >testbit I0, 6 > > to test whether bit 6 is set i I0, right? What is the difference from and I0, I0, (1 << 6) Unless if we want Parrot to handle multi-media data, there is not reasons to introduce many bitops (such as rotate, leading zeros, trailing zeros). Hong
Muddled Boundaries - Perl 6 vs Parrot
Erk, we seem to be muddling around in that great grey area between what is Parrot and what is Perl. Parrot is striving to be a common backend for multiple scripting languages, of which one is Perl 6, no? And, of course, to adequately test Parrot, you need to concurrently develop Perl 6, yes? And that is what is currently happening, yes? No. (At least, it doesn't seem so.) Certainly, register creation, memory allocation, garbage collection, and opcode dispatch are definitely within the purview of Parrot. However, the opcodes' code themselves aren't - they're provided by the language. Of course, some concepts are global across multiple languages, so where *do* those commonalities lie? Are those things part of a Parrot sublanguage that all superlanguages are expected to build on top of? Parrot may provide facilities for vtable dispatch and string handling, but a language isn't roped into using them. Things to keep in mind. (And another reason why it's good to have Namespace Police :) -- Bryan C. Warnock [EMAIL PROTECTED]
RE: Math functions? (Particularly transcendental ones)
At 10:55 AM 9/10/2001 -0700, Hong Zhang wrote: > > At 06:26 PM 9/9/2001 -0700, Wizard wrote: > > >into something using a processor op equivalent to the 8051C > > >testbit( byte_variable, bit_offset). > > > > This is pretty much > > > >testbit I0, 6 > > > > to test whether bit 6 is set i I0, right? > >What is the difference from > > and I0, I0, (1 << 6) Well, I took a shortcut, it'd probably be: testbit I0, 6, SOME_LABEL_TO_JUMP_TO_IF_THE_BIT_IS_SET But I was posting mainly to get some clarification as to what Grant was talking about. >Unless if we want Parrot to handle multi-media data, there is >not reasons to introduce many bitops (such as rotate, leading >zeros, trailing zeros). At the moment I tend to agree, but since perl has some bitwise operations we need to support at least those. I expect the bit ops will probably get consigned to a loadable library the same way that the transcendental ops will be, in which case it doesn't hurt to define a bunch for now since they won't get in the way. Besides, they are, if properly defined, useful. And they have the advantage that one or two people can split off to do them as they think necessary, so we can have another semi-independent development project. I don't want one or two people (Namely me... :) to be holding up development that other folks could be doing. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Muddled Boundaries - Perl 6 vs Parrot
--- "Bryan C. Warnock" <[EMAIL PROTECTED]> wisely wrote: > On Monday 10 September 2001 01:08 pm, Simon Cozens wrote: > > And in addition - why are we worrying about namespace > collision RIGHT NOW? > > Sure, when Parrot can be embedded, then we should > ensure that our names > > aren't going to clash. But who in their right minds is > going to embed > > Parrot in anything in its current state? (Leon, I said > "in their right > > minds") > > > > It's not a priority, compared to getting working code > out there. We can > > sort it out later. > > Oh, how many times have I heard that before? > > It's not a prioirty, but it's so much easier to walk the > correct path from > the start. Since it's all Parrot, it's even easier. Hear, hear! I remember the pain in 5.005_5* of turning off PERL_POLLUTE. I expect that there may still be CPAN modules that won't build without manually defining it. It's much better if we get it right from the start so that there's less that we need to go back and fix. -- BKS __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: Patch to assembler/disassembler + parrot asm inconsistancies
On Mon, Sep 10, 2001 at 06:23:02PM -0400, Dan Sugalski wrote: > That should really be eq_i_ic_ic. (Well, actually there should be only one > label, and we fall through otherwise. It's a bug in implementation and > assembly, not opcode name... :) Patches are... :) > I was using a trailing c to note a constant since we're using the opcode > name as a C function name, and we're not counting on case-sensitivity in > symbols. *nodnod*. I knew there was a reason something smelt funny about that. > Other than that (well, and Simon has a patch in to the repository to yank > out the opcode numbers entirely from opcode_table) it looks keen. Brian, if you could cvs update (or grab the snapshot from http://www.netthink.co.uk/downloads/parrot-0.0.1.tar.gz) and rework your patch given Dan's comments, I'd appreciate it. Thanks, Simon
Re: Math functions? (Particularly transcendental ones)
On Mon, 2001-09-10 at 09:16, Bryan C. Warnock wrote: > On Monday 10 September 2001 10:28 am, Brian Wheeler wrote: > > > > I was thinking about NOP this morning, and I realized that it might very > > well be necessary. If someone was writing a "simple" assembler for > > parrot, it might be useful for padding. > > Pad what? > How about preserving offsets during an optimization phase: add i3,i1,1 add i3,i3,8 could become add i3,i1,9 nop without having to recompute offsets for later bytecode. In the same way, you could also use it for reserving space for things like debugging code, like adding 10 nops if debugging is turned off, and using those 10 instructions for debugging if it is turned onmaintaining the relative addresses of things. Of course, one could just recompile using the parrot assembler, so this would only be for those tinkering with their own assembler, I suppose. Honestly, I don't care either way, since add i0,i0,0 is the same (basically) as a nop, but takes a little more cpu. One could always #define nop add i0,i0,0 :) Brian
Re: Math functions? (Particularly transcendental ones)
On Sat, Sep 08, 2001 at 12:00:24PM -0400, Dan Sugalski wrote: > Okay, I'm whipping together the "fancy math" section of the interpreter > assembly language. I've got: > > sin, cos, tan : Plain ones > asin, acos, atan : arc-whatevers > shinh, cosh, tanh : Hyperbolic whatevers > log2, log10, log : Base 2, base 10, and explicit base logarithms > pow : Raise x to the y power > > Can anyone think of things I've forgotten? It's been a while since I've > done numeric work. FWIW, it's just dawned on me that if we want all of these things to be overloadable by PMCs, they need to have vtable entries. The PMC vtable is going to be considerably bigger than we anticipated. Simon
Re: Math functions? (Particularly transcendental ones)
At 09:15 PM 9/10/2001 +0100, Simon Cozens wrote: >FWIW, it's just dawned on me that if we want all of these things to be >overloadable by PMCs, they need to have vtable entries. The PMC vtable >is going to be considerably bigger than we anticipated. Who the heck is going to override arctangent? (No, don't tell me, I don't want to know) For stuff like this I don't see a point in having a vtable entry for the transcendentals. atan is atan is atan. (Now, having said that, someone's going to define it for matrices or something wacky like that) At absolute worst I can see having a single vtable entry that gets passed in a "transcendental function number" or have the vtable be double-level for these, where there's just a "pointer to transcendental functions table" entry in the main vtable, so everyone shares the same table unless they want to get really extreme. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Math functions? (Particularly transcendental ones)
On Mon, 10 Sep 2001, Simon Cozens wrote: > On Sat, Sep 08, 2001 at 12:00:24PM -0400, Dan Sugalski wrote: > > Okay, I'm whipping together the "fancy math" section of the interpreter > > assembly language. I've got: > > > > sin, cos, tan : Plain ones > > asin, acos, atan: arc-whatevers > > shinh, cosh, tanh : Hyperbolic whatevers > > log2, log10, log: Base 2, base 10, and explicit base logarithms > > pow : Raise x to the y power > > > > Can anyone think of things I've forgotten? It's been a while since I've > > done numeric work. > > FWIW, it's just dawned on me that if we want all of these things to be > overloadable by PMCs, they need to have vtable entries. The PMC vtable > is going to be considerably bigger than we anticipated. Does that mean that opcodes like these are just going to call functions pointed to by vtable entries (that is, not have a 'default implementation')? It makes more sense to me to just have these functions act on numbers (like float and bigfloat), and auto-numify like Perl 5 does. Forgive me if I am missing something (I usually am :). - D <[EMAIL PROTECTED]>
Re: Parrot 0.0.1 is released.
> Patches should be sent to the perl6-internals mailing list, where I'll take a
> look at them and apply them to the CVS tree.
Ooo, ooo - me first. Since you turned on -Wall in the Makefile I thought
it would be nice if it compiled without warnings. Below is a patch that
does that on my system.
This is the output from "cvs -q diff -u". Is this is the best way to send
a multi-file patch from the CVS checkout?
-sam
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.4
diff -u -r1.4 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/10 15:48:36 1.4
+++ basic_opcodes.ops 2001/09/10 21:28:39
@@ -60,7 +60,7 @@
// PRINT Ix
AUTO_OP print_i {
- printf("I reg %i is %i\n", P1, INT_REG(P1));
+ printf("I reg %li is %li\n", P1, INT_REG(P1));
}
// BRANCH CONSTANT
@@ -152,7 +152,7 @@
// PRINT Nx
AUTO_OP print_n {
- printf("N reg %i is %Lf\n", P1, NUM_REG(P1));
+ printf("N reg %li is %Lf\n", P1, NUM_REG(P1));
}
// INC Nx
@@ -257,7 +257,7 @@
// PRINT Sx
AUTO_OP print_s {
STRING *s = STR_REG(P1);
- printf("S reg %i is %.*s\n", P1, string_length(s), s->bufstart);
+ printf("S reg %li is %.*s\n", P1, (int) string_length(s), (char *) s->bufstart);
}
// LEN Ix, Sx
@@ -272,4 +272,4 @@
// NOOP
AUTO_OP noop {
-}
\ No newline at end of file
+}
Index: bytecode.c
===
RCS file: /home/perlcvs/parrot/bytecode.c,v
retrieving revision 1.3
diff -u -r1.3 bytecode.c
--- bytecode.c 2001/09/10 09:50:39 1.3
+++ bytecode.c 2001/09/10 21:28:39
@@ -93,7 +93,7 @@
}
num--;
if (len < 0 || (len > 0 && num == 0)) {
-printf("Bytecode error: string constant segment corrupted: %i, %i\n",
len, num);
+printf("Bytecode error: string constant segment corrupted: %i, %i\n",
+(int) len, (int) num);
exit(1);
}
}
Index: parrot.h
===
RCS file: /home/perlcvs/parrot/parrot.h,v
retrieving revision 1.2
diff -u -r1.2 parrot.h
--- parrot.h2001/09/07 15:23:40 1.2
+++ parrot.h2001/09/10 21:28:39
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#define NUM_REGISTERS 32
#define PARROT_MAGIC 0x13155a1
Index: register.c
===
RCS file: /home/perlcvs/parrot/register.c,v
retrieving revision 1.2
diff -u -r1.2 register.c
--- register.c 2001/09/10 15:49:27 1.2
+++ register.c 2001/09/10 21:28:39
@@ -10,10 +10,10 @@
struct IRegChunk *chunk_base;
chunk_base = CHUNK_BASE(interpreter->int_reg);
- printf("Chunk base is %x for %x\n", chunk_base, interpreter->int_reg);
+ printf("Chunk base is %x for %x\n", (unsigned int) chunk_base, (unsigned int)
+interpreter->int_reg);
/* Do we have any slots left in the current chunk? */
if (chunk_base->free) {
-printf("Free was %i\n", chunk_base->free);
+printf("Free was %i\n", (int) chunk_base->free);
interpreter->int_reg = &chunk_base->IReg[chunk_base->used++];
chunk_base->free--;
}
Index: test_main.c
===
RCS file: /home/perlcvs/parrot/test_main.c,v
retrieving revision 1.2
diff -u -r1.2 test_main.c
--- test_main.c 2001/09/10 10:05:23 1.2
+++ test_main.c 2001/09/10 21:28:40
@@ -35,19 +35,19 @@
int i;
time_t foo;
- printf("String %p has length %i: %.*s\n", s, string_length(s),
string_length(s), s->bufstart);
+ printf("String %p has length %i: %.*s\n", s, (int) string_length(s), (int)
+string_length(s), (char *) s->bufstart);
string_concat(s, t, 0);
- printf("String %p has length %i: %.*s\n", s, string_length(s),
string_length(s), s->bufstart);
+ printf("String %p has length %i: %.*s\n", s, (int) string_length(s), (int)
+string_length(s), (char *) s->bufstart);
string_chopn(s, 4);
- printf("String %p has length %i: %.*s\n", s, string_length(s),
string_length(s), s->bufstart);
+ printf("String %p has length %i: %.*s\n", s, (int) string_length(s), (int)
+string_length(s), (char *) s->bufstart);
string_chopn(s, 4);
- printf("String %p has length %i: %.*s\n", s, string_length(s),
string_length(s), s->bufstart);
+ printf("String %p has length %i: %.*s\n", s, (int) string_length(s), (int)
+string_length(s), (char *) s->bufstart);
foo = time(0);
for (i = 0; i < 1; i++) {
string_concat(s, t, 0);
string_chopn(s, 4);
}
- printf("1000 concats and chops took %i seconds.\n", time(0)-foo);
+ printf("1000 concats and chops took %li seconds.\n", time(0)-foo);
string_destroy(s);
}
/* Otherwise load in the program they gave and try that */
Re: PDD 6: Parrot Assembly Language
Dan Sugalski wrote: > =item if tx, X, Y What's the purpose of providing Y? Does it make anything easier allowing Y != 0? > =item jump tx I expected a "call" op too. Not a named sub call, but just "call tx" where tx has the same semantics as in "jump". A "return" op is needed too. > =item iton Nx, Iy > =item ntoi Ix, Ny > =item tostring Sx, ty, Iz Are these good names? They aren't very regular IMHO. Why is integer abbreviated "i" and string left spelled out? Why does tostring have three operands and the other two? > =item inc tx, nn * > =item dec tx, nn * > Decrement register x by nn. nn is an integer constant. If nn is > omitted, decrement by 1. Variable length ops don't sound so cool to me. Why not use add/sub to inc/dec by something other than 1? Also, it would be nice if inc/dec *always* kept Parrot semantics instead of automagically transmogrifying to Perl inc/dec. Is this the plan? > =head2 Register and stack ops I'm a little confused why we can only push/pop entire register frames. Won't this make function value returns via registers impossible? IMHO, instead of push/pop a rotate command would be nice. That would allow SPARC-like register usage which has always seemed elegant to me. > =item warp [string] > > Reset the current register stacks to the state they were in when the > warp was set. Resets only the frame pointers, doesn't guarantee the > contents of the registers. Be I careful modifying the frame > pointers by, for example, pushing register frames. I don't understand this explanation. It sounds like you are setting up co-routines or maybe resuming a continuation. Shouldn't the ops be a little safer? IMHO we don't want a co-routine construction set, we just want co-routines. > =item find_lex Px, sy > > Find the lexical of name sy and store the PMC pointer in register Px. You're expecting the current lexical scope to be carried implicitly via the PC? Seems like find_lex should really be implemented as a vtable method on a compiler's scope object. > =item find_method Px, Py, tz > =item call_method Px, ty Multi-methods are notably absent. I'm assuming that Parrot does not understand multi-methods and requires the object (or the compiler generating the object) to register a multi-method dispatcher as the single-dispatch method known to Parrot. This only lets us use multi-methods where arg0 is an object. Is this sufficient for implementing Perl 6? - Ken
RE: Math functions? (Particularly transcendental ones)
> At 09:15 PM 9/10/2001 +0100, Simon Cozens wrote: > >FWIW, it's just dawned on me that if we want all of these things to be > >overloadable by PMCs, they need to have vtable entries. The PMC vtable > >is going to be considerably bigger than we anticipated. > > Who the heck is going to override arctangent? (No, don't tell > me, I don't want to know) If we we allow overriden sin(), then the int version will do the coersion and call the float version. The float version will do the dirty job. If we use shared version, then the opcode_sin() have to coersion first, then call the the ::sin(). The ::sin() is surely not good enough for bigfloat. The "Complex" also want to override all math functions. If the interpreter only handles int/float, but not complex/bigfloat, there is not much reason to allow overriden sin(). Hong
Re: Parrot 0.0.1 is released.
On Mon, Sep 10, 2001 at 09:42:38PM +0100, Simon Cozens wrote: > From CPAN: http://www.cpan.org/authors/id/S/SI/SIMON/parrot-0.0.1.tar.gz >http://www.cpan.org/src/parrot-0.0.1.tar.gz >(once the mirrors have updated) > > From CVS: See the Parrot CVS home page at http://cvs.perl.org/ OK, I screwed that one up good and proper. :( Be nice, I'm new to this game. Please use the anon CVS where you can, because that'll always be up to date, and won't suffer from any packaging issues. Emergency fixed package available at http://www.netthink.co.uk/downloads/parrot-0.0.1.tar.gz I've even tested this one. Sorry, and this time, have more fun. Simon
Parrot configure stuff, first stab
This is a first stab at the configure stuff for Parrot. It works fine, except that I had to put in a hack in the dependencies for it to generate ops.h before it was needed, since I couldn't figure out how to get the automatic dependencies system to do it right. Also, it doesn't check for the proper version of Perl (whichever version that might be). I've attached a gziped tar file of configure.in, Makefile.am, plus config/bootsrap. Running config/bootstrap from the top Parrot directory will do all the steps necessary to generate the configure script. -- Matthew Cline| Suppose you were an idiot. And suppose that [EMAIL PROTECTED] | you were a member of Congress. But I repeat | myself. -- Mark Twain conf.tar.gz
Re: Math functions? (Particularly transcendental ones)
On Mon, 10 Sep 2001 17:13:44 -0400, Dan Sugalski wrote: >Who the heck is going to override arctangent? (No, don't tell me, I don't >want to know) Perhaps you do. Think BigFloat. Or Complex. -- Bart.
Patch: Common opcode_table parsing
The following patch moves all parsing of opcode_table into a
Parrot::Opcode module. It also removes all parsing of interp_guts.h.
This patch incorporates my earlier patches to prefix all C opcode
functions with "Perl_op_".
As best I can tell, everything works the same with the patch as it
did before--the assembler and disassembler both generate identical
output, and test_prog runs as well as before. (Or better on FreeBSD,
where it stops core dumping. :>)
- Damien
diff -r --new-file -u parrot.orig/Parrot/Opcode.pm parrot/Parrot/Opcode.pm
--- parrot.orig/Parrot/Opcode.pmWed Dec 31 16:00:00 1969
+++ parrot/Parrot/Opcode.pm Mon Sep 10 23:52:35 2001
@@ -0,0 +1,86 @@
+package Parrot::Opcode;
+
+use strict;
+use Symbol;
+
+sub read_ops {
+my $file = @_ ? shift : "opcode_table";
+
+my $fh = gensym;
+open $fh, $file or die "$file: $!\n";
+
+my %opcode;
+my $count = 1;
+while (<$fh>) {
+ s/#.*//;
+ s/^\s+//;
+ chomp;
+ next unless $_;
+
+ my($name, @params) = split /\s+/;
+ if (@params && $params[0] =~ /^\d+$/) {
+ my $count = shift @params;
+ die "$file, line $.: opcode $name parameters don't match count\n"
+ if ($count != @params);
+ }
+
+ warn "$file, line $.: opcode $name redefined\n" if $opcode{$name};
+
+ $opcode{$name}{ARGS} = @params;
+ $opcode{$name}{TYPES} = \@params;
+ $opcode{$name}{CODE} = ($name eq "end") ? 0 : $count++;
+ $opcode{$name}{FUNC} = "Parrot_op_$name";
+
+ my $num_i = () = grep {/i/} @params;
+ my $num_n = () = grep {/n/} @params;
+ $opcode{$name}{RETURN_OFFSET} = 1 + $num_i + $num_n * 2;
+}
+
+return %opcode;
+}
+
+1;
+
+
+__END__
+
+=head1 NAME
+
+Parrot::Opcode - Read opcode definitions
+
+=head1 SYNOPSIS
+
+ use Parrot::Opcode;
+
+ %opcodes = Parrot::Opcode::read_ops();
+
+=head1 DESCRIPTION
+
+The read_ops() function parses the Parrot opcode_table file, and
+returns the contents as a hash. The hash key is the opcode name;
+values are hashrefs containing the following fields:
+
+=over
+
+=item CODE
+
+The opcode number.
+
+=item ARGS
+
+The opcode argument count.
+
+=item TYPES
+
+The opcode argument types, as an arrayref.
+
+=item FUNC
+
+The name of the C function implementing this op.
+
+=back
+
+read_ops() takes an optional argument: the file to read the opcode table
+from.
+
+=cut
diff -r --new-file -u parrot.orig/assemble.pl parrot/assemble.pl
--- parrot.orig/assemble.pl Mon Sep 10 14:26:08 2001
+++ parrot/assemble.pl Mon Sep 10 23:51:34 2001
@@ -3,6 +3,7 @@
# assemble.pl - take a parrot assembly file and spit out a bytecode file
use strict;
+use Parrot::Opcode;
my(%opcodes, %labels);
@@ -12,23 +13,7 @@
);
my $sizeof_packi = length(pack($pack_type{i},1024));
-open GUTS, "interp_guts.h";
-my $opcode;
-while () {
-next unless /\tx\[(\d+)\] = ([a-z_]+);/;
-$opcodes{$2}{CODE} = $1;
-}
-
-open OPCODES, ") {
-next if /^\s*#/;
-chomp;
-s/^\s+//;
-next unless $_;
-my ($name, $args, @types) = split /\s+/, $_;
-$opcodes{$name}{ARGS} = $args;
-$opcodes{$name}{TYPES} = [@types];
-}
+%opcodes = Parrot::Opcode::read_ops();
my $pc = 0;
my @code;
diff -r --new-file -u parrot.orig/build_interp_starter.pl
parrot/build_interp_starter.pl
--- parrot.orig/build_interp_starter.pl Mon Sep 10 14:26:09 2001
+++ parrot/build_interp_starter.pl Mon Sep 10 23:53:26 2001
@@ -1,10 +1,9 @@
# !/usr/bin/perl -w
use strict;
+use Parrot::Opcode;
open INTERP, "> interp_guts.h" or die "Can't open interp_guts.h, $!/$^E";
-open OPCODES, "opcode_table" or die "Can't open opcode_table, $!/$^E";
-
print INTERP <) {
-chomp;
-s/#.*$//;
-s/^\s+//;
-next unless $_;
-my($name) = split /\s+/;
-my $num = $count;
-$num = 0 if $name eq 'end';
-print INTERP "\tx[$num] = $name; \\\n";
-$count++ unless $name eq 'end';
+my %opcodes = Parrot::Opcode::read_ops();
+for my $name (sort {$opcodes{$a}{CODE} <=> $opcodes{$b}{CODE}} keys %opcodes) {
+print INTERP "\tx[$opcodes{$name}{CODE}] = $opcodes{$name}{FUNC}; \\\n";
}
print INTERP "} while (0);\n";
diff -r --new-file -u parrot.orig/disassemble.pl parrot/disassemble.pl
--- parrot.orig/disassemble.pl Mon Sep 10 14:45:33 2001
+++ parrot/disassemble.pl Mon Sep 10 23:57:36 2001
@@ -7,6 +7,7 @@
use strict;
my(%opcodes, @opcodes);
+use Parrot::Opcode;
my %unpack_type;
%unpack_type = (i => 'l',
@@ -16,28 +17,10 @@
n => 8,
);
-open GUTS, "interp_guts.h";
-my $opcode;
-while () {
-next unless /\tx\[(\d+)\] = ([a-z_]+);/;
-$opcodes{$2}{CODE} = $1;
-}
-
-open OPCODES, ") {
-next if /^\s*#/;
-s/^\s+//;
-chomp;
-next unless $_;
-my ($name, $args, @types) = split /\s+/, $_;
-next unless defined $name;
-$opcodes{$name}{ARGS} = $args;
-$opcodes{$name}{TYPES} = [@types];
-my $code = $opco
Re: Math functions? (Particularly transcendental ones)
At 10:07 AM 9/10/2001 -0500, Brian Wheeler wrote: >Honestly, I don't care either way, since add i0,i0,0 is the same >(basically) as a nop, but takes a little more cpu. One could always >#define nop add i0,i0,0 >:) Ah, almost, except that add i0,i0,0 is a four-word instruction, and you might be nuking pieces of a different size. :) I just added a noop operation to the repository. Whee... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 06:58:23PM -0400, Dan Sugalski wrote:
> At 03:52 PM 9/10/2001 -0700, Damien Neil wrote:
> >Parrot fails to work in very obscure ways on FreeBSD. After some
> >poking around, I tracked the problem to the "end" op--this appears
> >to conflict with something inside libc. Renaming the op fixes the
> >problem.
>
> Ah, that's what was killing the build on Nat's machine. Patch, by chance?
The following quick-and-dirty patch appears to work. This prefixes
all opcode functions with "Parrot_op_". I'd have made the prefix
configurable, but the opcode generation is spread across three
different files.
(Aside: What's the best way to generate a useful patch with cvs?
The following comes from "cvs -q diff -u".)
- Damien
Index: build_interp_starter.pl
===
RCS file: /home/perlcvs/parrot/build_interp_starter.pl,v
retrieving revision 1.2
diff -u -u -r1.2 build_interp_starter.pl
--- build_interp_starter.pl 2001/09/10 21:26:09 1.2
+++ build_interp_starter.pl 2001/09/10 23:07:08
@@ -27,7 +27,7 @@
my($name) = split /\s+/;
my $num = $count;
$num = 0 if $name eq 'end';
-print INTERP "\tx[$num] = $name; \\\n";
+print INTERP "\tx[$num] = Parrot_op_$name; \\\n";
$count++ unless $name eq 'end';
}
print INTERP "} while (0);\n";
Index: make_op_header.pl
===
RCS file: /home/perlcvs/parrot/make_op_header.pl,v
retrieving revision 1.3
diff -u -u -r1.3 make_op_header.pl
--- make_op_header.pl 2001/09/10 21:26:09 1.3
+++ make_op_header.pl 2001/09/10 23:07:08
@@ -6,7 +6,7 @@
next if /^\s*#/ or /^\s*$/;
chomp;
($name, undef) = split /\t/, $_;
-print "IV *$name(IV *, struct Perl_Interp *);\n";
+print "IV *Parrot_op_$name(IV *, struct Perl_Interp *);\n";
}
BEGIN {
Index: process_opfunc.pl
===
RCS file: /home/perlcvs/parrot/process_opfunc.pl,v
retrieving revision 1.3
diff -u -u -r1.3 process_opfunc.pl
--- process_opfunc.pl 2001/09/10 21:26:09 1.3
+++ process_opfunc.pl 2001/09/10 23:07:08
@@ -105,7 +105,7 @@
my $line = shift;
my ($name) = $line =~ /AUTO_OP\s+(\w+)/;
-print OUTPUT "IV *$name(IV cur_opcode[], struct Perl_Interp *interpreter) {\n";
+print OUTPUT "IV *Parrot_op_$name(IV cur_opcode[], struct Perl_Interp
+*interpreter) {\n";
return($name, " return cur_opcode + "
. $opcode{$name}{RETURN_OFFSET}. ";\n}\n");
}
@@ -114,7 +114,7 @@
my $line = shift;
my ($name) = $line =~ /MANUAL_OP\s+(\w+)/;
-print OUTPUT "IV *$name(IV cur_opcode[], struct Perl_Interp *interpreter) {\n";
+print OUTPUT "IV *Parrot_op_$name(IV cur_opcode[], struct Perl_Interp
+*interpreter) {\n";
print OUTPUT " IV return_offset = 1;\n";
return($name, " return cur_opcode + return_offset;\n}\n");
}
Index: test.pbc
===
RCS file: /home/perlcvs/parrot/test.pbc,v
retrieving revision 1.2
diff -u -u -r1.2 test.pbc
Binary files /tmp/cvsqe7MSGr3cy and test.pbc differ
Re: Patch to assembler/disassembler + parrot asm inconsistancies
I think Dan mentioned this, but it looks like the suffixes can be derived from the args being passed in. That would greatly simply the assembler to just the function names: set, eq, add, branch. Were there problems with the scheme, is someone working on it, or did it fall through the cracks? (I'm very much in favor of such a change, and will pick it up if no one else is working on it.) -- Bryan C. Warnock [EMAIL PROTECTED]
Parrot 0.0.1 is released.
Because the game of hide-and-seek was still going on, it took Edmund and Lucy some time to find the others. But when at last they were all together (which happened in the long room, where the suit of armour was) Lucy burst out: "Peter! Susan! It's all true. Edmund has seen it too. There is a country you can get to through the wardrobe. Edmund and I both got in. We met one another in there, in the wood. Go on, Edmund; tell them all about it." - "The Lion, The Witch and the Wardrobe", CS Lewis I suppose (unlike Edmund did) I should tell you all about it. What we're releasing today is a very, very early alpha of the Parrot interpreter. At the moment, we have support for some simple operations on integer, floating point and string registers, and the ability to read in and execute bytecode. We also have an assembler which can generate bytecode output from Parrot assembly. You can get the source tarball in (currently) two different ways: From CPAN: http://www.cpan.org/authors/id/S/SI/SIMON/parrot-0.0.1.tar.gz http://www.cpan.org/src/parrot-0.0.1.tar.gz (once the mirrors have updated) From CVS: See the Parrot CVS home page at http://cvs.perl.org/ Once you've unpacked parrot, you should be able to "make test_prog", and use the Parrot assembler to turn assembly into bytecode: make test_prog perl assemble.pl test.pasm > test.pbc ./test_prog test.pbc perl assemble.pl test2.pasm > test2.pbc ./test_prog test2.pbc The first test program will add some numbers together, count to 10,000,000, and tell you how long it took; the second test program will print a familiar greeting. In the next email, coming in a couple of minutes, I'll outline two areas where I really, really need some patches before we go much further; you should also note that Parrot has a bug/request tracking system at http://parrotbugs.develooper.com/ which will be filled with some more things that I'd like people to take a look at. Patches should be sent to the perl6-internals mailing list, where I'll take a look at them and apply them to the CVS tree. As time goes by, people who regularly submit good patches will be given committer access to the tree, and can help me out applying other patches from the list. IMPORTANT! Please note that we haven't decided the final license for Parrot yet. You currently receive Parrot under the same terms as Perl 5: your choice of either the Artistic or General Public Licenses. Have fun, Simon -- set_s_sc S1, "Just Another Parrot Hacker, " print_s S1
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 04:04:20PM -0700, Damien Neil wrote:
> The following quick-and-dirty patch appears to work. This prefixes
> all opcode functions with "Parrot_op_". I'd have made the prefix
> configurable, but the opcode generation is spread across three
> different files.
Oops--that breaks the assembler. This patch fixes the assembler to
work with the prior patch.
- Damien
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.6
diff -u -u -r1.6 assemble.pl
--- assemble.pl 2001/09/10 21:26:08 1.6
+++ assemble.pl 2001/09/10 23:43:30
@@ -15,7 +15,7 @@
open GUTS, "interp_guts.h";
my $opcode;
while () {
-next unless /\tx\[(\d+)\] = ([a-z_]+);/;
+next unless /\tx\[(\d+)\] = Parrot_op_([a-z_]+);/;
$opcodes{$2}{CODE} = $1;
}
RE: Speaking of namespaces...
Damien Neil: # On Mon, Sep 10, 2001 at 06:58:23PM -0400, Dan Sugalski wrote: # > At 03:52 PM 9/10/2001 -0700, Damien Neil wrote: # > >Parrot fails to work in very obscure ways on FreeBSD. After some # > >poking around, I tracked the problem to the "end" op--this appears # > >to conflict with something inside libc. Renaming the op fixes the # > >problem. # > # > Ah, that's what was killing the build on Nat's machine. # Patch, by chance? # # The following quick-and-dirty patch appears to work. This prefixes # all opcode functions with "Parrot_op_". I'd have made the prefix # configurable, but the opcode generation is spread across three # different files. # # (Aside: What's the best way to generate a useful patch with cvs? # The following comes from "cvs -q diff -u".) This patch seems to work on the FreeBSD box I have access to. Now to figure out what's causing all those 'use of uninitialized value at assembler.pl line 81' messages... --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Speaking of namespaces...
Damien Neil: # On Mon, Sep 10, 2001 at 04:04:20PM -0700, Damien Neil wrote: # > The following quick-and-dirty patch appears to work. This prefixes # > all opcode functions with "Parrot_op_". I'd have made the prefix # > configurable, but the opcode generation is spread across three # > different files. # # Oops--that breaks the assembler. This patch fixes the assembler to # work with the prior patch. That explains it! :^) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
PMC vtable vs other overloading techniques
Simon Cozens wrote: > FWIW, it's just dawned on me that if we want all of these things to be > overloadable by PMCs, they need to have vtable entries. The PMC vtable > is going to be considerably bigger than we anticipated. Surely you don't expect the PMC vtable to be the only mechanism for overloading?! Perl 6 has the option of: * emiting Perl 6 specific opcodes * over-riding built-in opcodes in a lexical scope * generating method calls instead of ops * replacing the dispatcher in a lexical scope We've talked about all of those options. Have you eliminated some of them? One of the things that confuses me is how compiler writers will decide to use one code generation technique over another. For example, if the Perl back-end generates a method call for sin() and Python generates a custom op, the two won't interoperate. IMHO this needs to be nailed down soon or we'll end up with a messy architecture. Just because Perl is TMTOWTDI doesn't mean Parrot should be. - Ken
RE: Parrot 0.0.1 is released.
Am I missing something (well, clearly I am), but are test.pasm and test2.pasm missing from the CVS repository? // Jeffrey Coleman Carlyle: Computer Science Graduate Student at the // University of Illinois at Urbana-Champaign; Creator of StratoSetup, // Windows Restart, comp.os.msdos.programmer FAQ; Kentucky "roadgeek"; // RULER OF EARTH! -Original Message- From: Simon Cozens [mailto:[EMAIL PROTECTED]] Sent: Monday, September 10, 2001 3:43 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Parrot 0.0.1 is released. Because the game of hide-and-seek was still going on, it took Edmund and Lucy some time to find the others. But when at last they were all together (which happened in the long room, where the suit of armour was) Lucy burst out: "Peter! Susan! It's all true. Edmund has seen it too. There is a country you can get to through the wardrobe. Edmund and I both got in. We met one another in there, in the wood. Go on, Edmund; tell them all about it." - "The Lion, The Witch and the Wardrobe", CS Lewis I suppose (unlike Edmund did) I should tell you all about it. What we're releasing today is a very, very early alpha of the Parrot interpreter. At the moment, we have support for some simple operations on integer, floating point and string registers, and the ability to read in and execute bytecode. We also have an assembler which can generate bytecode output from Parrot assembly. You can get the source tarball in (currently) two different ways: From CPAN: http://www.cpan.org/authors/id/S/SI/SIMON/parrot-0.0.1.tar.gz http://www.cpan.org/src/parrot-0.0.1.tar.gz (once the mirrors have updated) From CVS: See the Parrot CVS home page at http://cvs.perl.org/ Once you've unpacked parrot, you should be able to "make test_prog", and use the Parrot assembler to turn assembly into bytecode: make test_prog perl assemble.pl test.pasm > test.pbc ./test_prog test.pbc perl assemble.pl test2.pasm > test2.pbc ./test_prog test2.pbc The first test program will add some numbers together, count to 10,000,000, and tell you how long it took; the second test program will print a familiar greeting. In the next email, coming in a couple of minutes, I'll outline two areas where I really, really need some patches before we go much further; you should also note that Parrot has a bug/request tracking system at http://parrotbugs.develooper.com/ which will be filled with some more things that I'd like people to take a look at. Patches should be sent to the perl6-internals mailing list, where I'll take a look at them and apply them to the CVS tree. As time goes by, people who regularly submit good patches will be given committer access to the tree, and can help me out applying other patches from the list. IMPORTANT! Please note that we haven't decided the final license for Parrot yet. You currently receive Parrot under the same terms as Perl 5: your choice of either the Artistic or General Public Licenses. Have fun, Simon -- set_s_sc S1, "Just Another Parrot Hacker, " print_s S1
Re: Patch to assembler/disassembler + parrot asm inconsistancies
On Monday 10 September 2001 06:23 pm, Dan Sugalski wrote: > At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote: > >First off, here's an inconsistancy I found: In test.pasm > > > >REDO: eq_i_ic I2, I4, DONE, NEXT > > > >appears. Shouldn't this be comparing to a constant, not a register? > > Nope, though if I let you in on the actual secret it's help. > > That should really be eq_i_ic_ic. (Well, actually there should be only one > label, and we fall through otherwise. It's a bug in implementation and > assembly, not opcode name... :) The intention is the last _x covers the > last arg, the next to last covers the next to last arg, and so on. When we > run out, we repeat the innermost type. Why are you doing right-to-left instead of left-to-right? -- Bryan C. Warnock [EMAIL PROTECTED]
Another Patch...
This patch (which is pretty big) does:
* Changes the opcode_table file to provide additional information about
the operands. Case shouldn't be a problem since that data never becomes
a C symbol [this is pretty much as before]
* Padding errors solved: assemble.pl and bytecode.c were padding the
constants incorrectly. It should have been 4-(size % 4), not just (size
% 4). It is now fixed in both places.
* assembler has less special cases, and should be easier to hang error
checking on
* disassembler dumps constant table and the format is a bit prettier,
including register names, etc. Test2.pbc dumps as this:
# Constants: 1 entries (32 bytes)
# ID FlagsEncoding Type Size Data
: 000b Hello World
# Code Section
: set_i_ic I2, 1
000c: set_i_ic I1, 0
0018: set_s_sc S1, [string ]
0024: eq_i_ic I1, I2, 0060, 0038
0038: length_s_i S1, I1
0044: print_s S1
004c: chopn_s_ic S1, 1
0058: branch_ic0024
0060: end
Let me know what you guys think!
Brian
[Crap, there's some wordwrapping below. Too bad you can plug emacs into
evolution :) ]
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.6
diff -u -r1.6 assemble.pl
--- assemble.pl 2001/09/10 21:26:08 1.6
+++ assemble.pl 2001/09/11 03:14:32
@@ -9,7 +9,16 @@
my %pack_type;
%pack_type = (i => 'l',
n => 'd',
- );
+ );
+
+my %real_type=('i'=>'i',
+ 'n'=>'n',
+ 'N'=>'i',
+ 'I'=>'i',
+ 'S'=>'i',
+ 's'=>'i',
+ 'D'=>'i');
+
my $sizeof_packi = length(pack($pack_type{i},1024));
open GUTS, "interp_guts.h";
@@ -26,8 +35,11 @@
s/^\s+//;
next unless $_;
my ($name, $args, @types) = split /\s+/, $_;
+my @rtypes=@types;
+@types=map { $_ = $real_type{$_}} @types;
$opcodes{$name}{ARGS} = $args;
$opcodes{$name}{TYPES} = [@types];
+$opcodes{$name}{RTYPES}=[@rtypes];
}
my $pc = 0;
@@ -65,23 +77,17 @@
die "wrong arg count--got ". scalar @args. " needed " .
$opcodes{$opcode}{ARGS};
}
-$args[0] = fixup($args[0])
-if $opcode eq "branch_ic" and $args[0] =~ /[a-zA-Z]/;
-
-#if ($opcode eq "eq_i_ic" or $opcode eq "lt_i_ic") {
-if ($opcode =~ /^(eq|ne|lt|le|gt|ge)_i_ic$/) {
-$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
-$args[3] = fixup($args[3]) if $args[3] =~ /[a-zA-Z]/;
-}
-if ($opcode eq "if_i_ic") {
-$args[1] = fixup($args[1]) if $args[1] =~ /[a-zA-Z]/;
-$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
-}
-
print pack "l", $opcodes{$opcode}{CODE};
foreach (0..$#args) {
- $args[$_] =~ s/^[INPS]?(\d+)$/$1/i;
- my $type = $pack_type{$opcodes{$opcode}{TYPES}[$_]};
+ my($rtype)=$opcodes{$opcode}{RTYPES}[$_];
+ my($type)=$opcodes{$opcode}{TYPES}[$_];
+ if($rtype eq "I" || $rtype eq "N" || $rtype eq "P" || $rtype eq "S") {
+ # its a register argument
+ $args[$_]=~s/^[INPS](\d+)$/$1/i;
+ } elsif($rtype eq "D") {
+ # a destination
+ $args[$_]=fixup($args[$_]);
+ }
print pack $type, $args[$_];
}
$pc += 1+@args;
@@ -112,7 +118,10 @@
for (@constants) {
$size += 4*$sizeof_packi;
$size += length($_);
-$size += length($_) % $sizeof_packi; # Padding
+ my($pad)=length($_) % $sizeof_packi;
+ if($pad) {
+ $size+=$sizeof_packi-$pad;
+ }
}
$size += $sizeof_packi if @constants; # That's for the number of
constants
@@ -127,6 +136,9 @@
print pack($pack_type{i},0) x 3; # Flags, encoding, type
print pack($pack_type{i},length($_)); # Strlen followed by that
many bytes.
print $_;
-print "\0" x (length($_) % $sizeof_packi); # Padding;
+ my $pad=(length($_) % $sizeof_packi);
+ if($pad) {
+ print "\0" x ($sizeof_packi-(length($_) % $sizeof_packi)); #
Padding;
+ }
}
}
Index: bytecode.c
===
RCS file: /home/perlcvs/parrot/bytecode.c,v
retrieving revision 1.4
diff -u -r1.4 bytecode.c
--- bytecode.c 2001/09/10 21:47:26 1.4
+++ bytecode.c 2001/09/11 03:14:33
@@ -79,6 +79,7 @@
IV encoding = GRAB_IV(program_code);
IV type = GRAB_IV(program_code);
IV buflen = GRAB_IV(program_code);
+ int pad;
len -= 4 * sizeof(IV);
@@ -87,9 +88,11 @@
len -= buflen;
/* Padding */
-if (buflen % sizeof(IV)) {
-len -= buflen % sizeof(IV);
-(char*)*program_code += buflen % sizeof(IV);
+ pad=buflen % sizeof(IV);
+ if(pad) {
+ pad=sizeof(IV)-pad;
+ len -= pad;
+ (char*)*program_code += pad;
}
Re: String API
Simon Cozens wrote: > =head1 The Parrot String API Have you guys seen Topaz? One of many things I think Chip did right was to build strings from a low-level buffer concept. This moves memory management (and possibly raw-io) out of the string class and into the buffer class. The other major suggestion I have is to avoid "void *" interfaces. Do we really need a string_make() that takes the encoding enum? Aren't encodings different enough that we'd want string_make_ascii(), string_make_utf32(), ... Maybe I've been doing C++ too long, but taking advantage of compiler type checks as much as possible seems like an excellent goal -- especially since the various string_* functions are going to be visible in user code. The use of an encoding enum seems a little weird, but once you explain why it will probably make sense. Right now the only thing it seems good for is the transcoding system -- everything else is slower and vtables are more cumbersome because you have to manage a vtable[num_encodings] array. I'd make a string's encoding a direct pointer to its' vtable struct. The transcoding algorithm seems like it could be implemented using a string iterator on the source with a character-by-character append to the destination. We would need an abstract character object, but that seems necessary anyway. (Perl doesn't have characters, but does Perl 6 or Python?) The destination can be pre-extended to the length of the source to avoid fragmenting memory. How many encoding specific optimizations are there? Is it worth having a table of custom transcoders instead of using a generic algorithm? - Ken
Re: Patch to assembler/disassembler + parrot asm
> > At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote: > >First off, here's an inconsistancy I found: In test.pasm > > > >REDO: eq_i_ic I2, I4, DONE, NEXT > > > >appears. Shouldn't this be comparing to a constant, not a register? > > Nope, though if I let you in on the actual secret it's help. > > That should really be eq_i_ic_ic. (Well, actually there should be only one > label, and we fall through otherwise. It's a bug in implementation and > assembly, not opcode name... :) The intention is the last _x covers the > last arg, the next to last covers the next to last arg, and so on. When we > run out, we repeat the innermost type. > > The ultimate intention is that you'd write that as a plain: > > eq I2, I4, DONE, NEXT > > or probably > > eq I2, I4, DONE > > and either way the assembler would know DONE was a constant and we needed i > registers since that was specified, and emit the eq_i_ic opcode. BUT, I'm more confused now :) If eq_i_ic is really treated as /eq(_i)+_ic/ then this code still doesn't work: eq_i_ic I1,I2,NEXT,DONE because that'd be like eq_i_i_ic_ic, right? I assume that opcodes aren't going to have variable arguments at this level, so there should be a one-to-one mapping between function and opcode, right? A thought (though gross): if we restrict mneumonics to not use the underscore, then anything after _ can be the op signature. The opcode_table could use these characters for different data types: integer i integer constantj numeric n numeric constanto address a string s string constant t The file could be reorganized as: set 2 i j set 2 i i set 2 n o set 2 s t The perl scripts which create the interfaces (process_opfunc.pl, etc) could use this information to create 4 opcodes: set_ij set_ii set_no set_st When the assembler comes across 'set I1,I2', It knows the set_ii form is the one to use. The disassembler can dump it as 'set_ii I1,I2' or (I suppose) as 'set I1,I2' Also, doing it this way takes out the special cases for the comparison and jump ops: the fixups are known to be done with things that have type 'a' > > >It > >became a little obvious when I made a few changes to the > >assembler/disassembler to give more details about the data (and to allow > >shortcuts like "add I1,I2,I3" to go to "add_i I1,I2,I3", etc) > > > >The opcode_table patch changes the argument encoding to use these terms: > ># i Integer constant > ># I Integer register > ># n Numeric constant > ># N Numeric register > ># s String constant? > ># S String register > ># D Destination > > I was using a trailing c to note a constant since we're using the opcode > name as a C function name, and we're not counting on case-sensitivity in > symbols. > fair enough... > Other than that (well, and Simon has a patch in to the repository to yank > out the opcode numbers entirely from opcode_table) it looks keen. > I'll take a peek and see what all depends on the opcode_table file... Brian > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk >
RE: Math functions? (Particularly transcendental ones)
At 10:08 AM 9/10/2001 -0700, Wizard wrote: >Uri Guttman wrote: > > but having parrot op codes map to special instructions > > makes sense only if we are doing some form of machine instruction > > generation as with JIT or TIL. > >Actually, I wasn't necessarily asking for any special ops (I'm not actually >asking for anything, it's just a suggestion), just that the boolean math >operations use a specific register or registers. I think this would make >implementing code generation on those platforms more straight-forward. Okay, I see what you're aiming at. I don't think we will, mainly because it's not going to do us a whole lot of good. Parrot's got more registers than any system on the planet that I know of, so the bit that handles converting to native machine code will need to do some analysis and register renaming anyway. It can handle putting things in the right places. Besides, no matter what we do, Perl and/or Parrot assembly is probably *not* the right place to do embedded device speed critical things. (I wouldn't do it in BASIC or Fortran either. C or Forth maybe, but that'd be about it) Other embedded device things, sure, but not the real low-level stuff. Too many layers of abstraction in the way. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Patch to assembler/disassembler + parrot asm
another thought... > > A thought (though gross): if we restrict mneumonics to not use the underscore, > then anything after _ can be the op signature. > > The opcode_table could use these characters for different data types: > integer i > integer constant j > numeric n > numeric constant o > address a > strings > string constant t > > The file could be reorganized as: > > set 2 i j > set 2 i i > set 2 n o > set 2 s t > what if the table had another column (optional) at the end: set 2 i j set_i which gave the name of the C function which implemented it. that way the assembly ops are independant of the C function names and multiple ops could map to a single C routine (if needed) I've got to know...what's the significance of the magic number? :) Brian
Re: Patch to assembler/disassembler + parrot asm inconsistancies
"Bryan C. Warnock" wrote: > On Monday 10 September 2001 06:23 pm, Dan Sugalski wrote: > > When we run out, we repeat the innermost type. > > Why are you doing right-to-left instead of left-to-right? Because it would be harder to repeat the innermost type then? ;) Most binary ops will take identical inner args. This is just a readability optimization to avoid things like "_i_i". Avoiding type extensions completely seems best if the compiler and disassembler are smart enough. I'm not sure we'll be able to do that though -- more complex addressing modes may lose type info. (But that assumes someday we get more complex addressing modes... ;) - Ken
Re: Patch to assembler/disassembler + parrot asm inconsistancies
At 08:00 PM 9/10/2001 -0400, Bryan C. Warnock wrote: >On Monday 10 September 2001 06:23 pm, Dan Sugalski wrote: > > At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote: > > >First off, here's an inconsistancy I found: In test.pasm > > > > > >REDO: eq_i_ic I2, I4, DONE, NEXT > > > > > >appears. Shouldn't this be comparing to a constant, not a register? > > > > Nope, though if I let you in on the actual secret it's help. > > > > That should really be eq_i_ic_ic. (Well, actually there should be only one > > label, and we fall through otherwise. It's a bug in implementation and > > assembly, not opcode name... :) The intention is the last _x covers the > > last arg, the next to last covers the next to last arg, and so on. When we > > run out, we repeat the innermost type. > >Why are you doing right-to-left instead of left-to-right? Because I think backwards from most people, apparently. :) That and generally speaking if there are three args the second is the same type as the first, while the third is the variant. Generally. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Speaking of namespaces...
At 04:56 PM 9/10/2001 -0700, Brent Dax wrote: >This patch seems to work on the FreeBSD box I have access to. Now to >figure out what's causing all those 'use of uninitialized value at >assembler.pl line 81' messages... It's the blank lines in opcode_table. The assembler (and disassembler) at some point didn't grok 'em. Patches have been applied, but you might've checked out before that happened. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Patch to assembler/disassembler + parrot asm inconsistancies
On Monday 10 September 2001 08:47 pm, Dan Sugalski wrote: > Because I think backwards from most people, apparently. :) > > That and generally speaking if there are three args the second is the same > type as the first, while the third is the variant. Generally. Tayyib. Handling constants now. Everything else seems to work on the assembler side. -- Bryan C. Warnock [EMAIL PROTECTED]
RE: Parrot 0.0.1 is released.
# -Original Message- # From: Jeffrey Coleman Carlyle [mailto:[EMAIL PROTECTED]] # Sent: Monday, September 10, 2001 5:04 PM # To: 'Simon Cozens' # Cc: [EMAIL PROTECTED] # Subject: RE: Parrot 0.0.1 is released. # # # Am I missing something (well, clearly I am), but are test.pasm and # test2.pasm missing from the CVS repository? Check the t/ directory. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 08:48:48PM -0400, Dan Sugalski wrote: > At 04:56 PM 9/10/2001 -0700, Brent Dax wrote: > >This patch seems to work on the FreeBSD box I have access to. Now to > >figure out what's causing all those 'use of uninitialized value at > >assembler.pl line 81' messages... > > It's the blank lines in opcode_table. The assembler (and disassembler) at > some point didn't grok 'em. Patches have been applied, but you might've > checked out before that happened. No, in this case, it's my fault. I didn't realize the assembler reads op name/number mappings out of interp_guts.h, so my patch broke the assembler. I'm thinking of writing something to generate a Parrot::Opcode.pm module, so code doesn't need to parse opcode_table and interp_guts.h. Sound reasonable? - Damien
Re: Muddled Boundaries - Perl 6 vs Parrot
Bryan C. Warnock" <[EMAIL PROTECTED]> wrote: > Erk, we seem to be muddling around in that great grey area between what is > Parrot and what is Perl. Yes, which leads me on to think... (With my "maintainer of the Coding PDD" hat on) Presumably we have to decide what bits of code have a Parrot_ prefix, and what bits are Perl_. And do we split off everything into two completely independent src trees, perhaps which compile to libparrot.a and libperl.a? Or this articifcal separation too hard to achieve in practice?
Re: Patch to assembler/disassembler + parrot asm
At 07:56 PM 9/10/2001 -0500, Brian Wheeler wrote: >I've got to know...what's the significance of the magic number? :) It's the number of arguments. Why it's there, I don't know, since it's redundant. Seemed like a good idea at the time. We can probably chop it out without a problem. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Patch to assembler/disassembler + parrot asm
At 07:45 PM 9/10/2001 -0500, Brian Wheeler wrote: >If eq_i_ic is really treated as /eq(_i)+_ic/ then this code still >doesn't work: > >eq_i_ic I1,I2,NEXT,DONE > >because that'd be like eq_i_i_ic_ic, right? Right. But don't forget, I screwed up the eq op--it ought to have a single destination. :) >I assume that opcodes aren't going to have variable arguments at this level, >so there should be a one-to-one mapping between function and opcode, right? Each opcode number has a single function, yes. The same "high-level" opcode, for example eq or add, might map to two or more different 'real' opcodes based on the types of the args. There won't be any runtime morphing--it's more "The assembler sees the first arg of foo as a numberic register and the second as a constant, so it must be foo_n_nc". >A thought (though gross): if we restrict mneumonics to not use the >underscore, >then anything after _ can be the op signature. Too gross. We don't need to go there. :) >Also, doing it this way takes out the special cases for the comparison and >jump ops: the fixups are known to be done with things that have type 'a' The jump ops will be easy to figure--either they'll take a register, a constant number, or a label. We don't allow labels that could be confused with registers. (No I0: anywhere...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD 6: Parrot Assembly Language
Dan Sugalski wrote:
> At 05:41 PM 9/10/2001 -0400, Ken Fox wrote:
> > You're expecting the current lexical scope to be carried implicitly
> > via the PC?
>
> No, it'll be in the interpreter struct.
But how does the interpreter know where a lexical scope begins
and ends in the bytecode? For example, a "jump FOO" might change
scopes. How is the scope discovered?
> >This only lets us use multi-methods where arg0 is an object. Is
> >this sufficient for implementing Perl 6?
>
> Ummm... how on earth do you plan on calling a method of something that's
> not an object? Methods sorta require them... :)
sub add(int x, int y) : multi { ... }
sub add(int x, num y) : multi { ... }
sub add(num x, num y) : multi { ... }
That makes sense to me. My syntax is probably wrong, but the intention
is clear. I'd be surprised if Damian doesn't want this.
- Ken
Re: Muddled Boundaries - Perl 6 vs Parrot
At 03:55 PM 9/10/2001 +0100, Dave Mitchell wrote: >Bryan C. Warnock" <[EMAIL PROTECTED]> wrote: > > Erk, we seem to be muddling around in that great grey area between what is > > Parrot and what is Perl. > >Yes, which leads me on to think... > >(With my "maintainer of the Coding PDD" hat on) > >Presumably we have to decide what bits of code have a Parrot_ prefix, >and what bits are Perl_. And do we split off everything into two completely >independent src trees, perhaps which compile to libparrot.a and libperl.a? >Or this articifcal separation too hard to achieve in practice? We aren't going to split things out that hard. Generally speaking, the language-specific pieces will be: 1) Parser rules 2) Possibly compiler rules (maybe) 3) Variable vtable things So pretty much everything should have a Parrot_ prefix on it, with the (possible) exception of the perl variable vtable code. (Though I think those should probably be Parrot_ as well. We can change them to Perl_ at some point if it becomes appropriate) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot 0.0.1 is released.
Jeffrey Coleman Carlyle wrote: > Am I missing something (well, clearly I am), but are test.pasm and > test2.pasm missing from the CVS repository? Look in ./t - Ken
Re: Patch to assembler/disassembler + parrot asm inconsistancies
At 08:44 PM 9/10/2001 -0400, Bryan C. Warnock wrote: >On Monday 10 September 2001 08:47 pm, Dan Sugalski wrote: > > Because I think backwards from most people, apparently. :) > > > > That and generally speaking if there are three args the second is the same > > type as the first, while the third is the variant. Generally. > >Tayyib. Is that a good thing or a bad thing? :) >Handling constants now. Everything else seems to work on the >assembler side. Keen. Constants are odd, since they can happen in a number of ways. Int and float constants get embedded in the opcode stream, the rest go into the constants section and fixup sections of the bytecode, and that's still in flux. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
And speaking of snapshots...
On Mon, Sep 10, 2001 at 11:13:15PM +0100, Simon Cozens wrote: > Brian, if you could cvs update (or grab the snapshot from > http://www.netthink.co.uk/downloads/parrot-0.0.1.tar.gz) If all goes well, http://www.netthink.co.uk/downloads/parrot-nightly.tar.gz will contain nightly CVS snapshots, generated at midnight UK time. We're also planning on adding rsync access to the repository. Simon
Re: Speaking of namespaces...
At 05:49 PM 9/10/2001 -0700, Damien Neil wrote: >On Mon, Sep 10, 2001 at 08:48:48PM -0400, Dan Sugalski wrote: > > At 04:56 PM 9/10/2001 -0700, Brent Dax wrote: > > >This patch seems to work on the FreeBSD box I have access to. Now to > > >figure out what's causing all those 'use of uninitialized value at > > >assembler.pl line 81' messages... > > > > It's the blank lines in opcode_table. The assembler (and disassembler) at > > some point didn't grok 'em. Patches have been applied, but you might've > > checked out before that happened. > >No, in this case, it's my fault. I didn't realize the assembler >reads op name/number mappings out of interp_guts.h, so my patch >broke the assembler. Nothing should read out of interp_guts.h. That's autogenerated from opcode_table. Or it was yesterday, but things might've changed. :) >I'm thinking of writing something to generate a Parrot::Opcode.pm >module, so code doesn't need to parse opcode_table and interp_guts.h. >Sound reasonable? Yes, please do. I knew we needed one the second time I needed to parse opcode_table, I just haven't stopped long enough to be lazy and still program. (In those cases I came to a full stop...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD 6: Parrot Assembly Language
At 09:05 PM 9/10/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 05:41 PM 9/10/2001 -0400, Ken Fox wrote:
> > > You're expecting the current lexical scope to be carried implicitly
> > > via the PC?
> >
> > No, it'll be in the interpreter struct.
>
>But how does the interpreter know where a lexical scope begins
>and ends in the bytecode? For example, a "jump FOO" might change
>scopes. How is the scope discovered?
jump FOO
doesn't change scope.
newscope scope_template_in_fixup_section
does. And
exitscope
leaves one. :)
> > >This only lets us use multi-methods where arg0 is an object. Is
> > >this sufficient for implementing Perl 6?
> >
> > Ummm... how on earth do you plan on calling a method of something that's
> > not an object? Methods sorta require them... :)
>
>sub add(int x, int y) : multi { ... }
>sub add(int x, num y) : multi { ... }
>sub add(num x, num y) : multi { ... }
>
>That makes sense to me. My syntax is probably wrong, but the intention
>is clear. I'd be surprised if Damian doesn't want this.
Ah, multimethod subroutines. Those are a different beast entirely. For
those the destination sub code is responsible for dispatch, that way you
only pay the penalty to decode the arg types for those subs that actually
do multimethodish things.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Parrot 0.0.1 is released.
At 09:06 PM 9/10/2001 -0400, Ken Fox wrote: >Jeffrey Coleman Carlyle wrote: > > Am I missing something (well, clearly I am), but are test.pasm and > > test2.pasm missing from the CVS repository? > >Look in ./t Right. We moved them around a bit ago. Joys of a new project--everything's in flux, and the documentation doesn't quite keep pace. (Sometimes its ahead, sometimes its behind, but it beats having two source modules out of sync :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Patch to assembler/disassembler + parrot asm inconsistancies
On Monday 10 September 2001 08:58 pm, Dan Sugalski wrote: > > > >Tayyib. > > Is that a good thing or a bad thing? :) It's an "okay" thing. Literally. > > >Handling constants now. Everything else seems to work on the > >assembler side. > > Keen. Constants are odd, since they can happen in a number of ways. Int > and float constants get embedded in the opcode stream, the rest go into > the constants section and fixup sections of the bytecode, and that's still > in flux. Yes, constants are the current problem child, because string and integer constants come down to the guts of the assembler the same way, and I can't base it off of the destination type. I think I'll need to do mangling beforehand, or come up with another mechanism. (One of which I already have in mind.) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Parrot 0.0.1 is released.
On Mon, Sep 10, 2001 at 05:25:46PM -0400, Sam Tregar wrote: > Ooo, ooo - me first. Since you turned on -Wall in the Makefile I thought > it would be nice if it compiled without warnings. Below is a patch that > does that on my system. Thanks, applied. (Although I consider it a temporary fix, because when we have a configure system and IV isn't necessarily a long, we'll need to do something more permanent.) > This is the output from "cvs -q diff -u". Is this is the best way to send > a multi-file patch from the CVS checkout? Yes, thanks. Simon
RE: Patch to assembler/disassembler + parrot asm
Dan Sugalski: ... # The jump ops will be easy to figure--either they'll take a # register, a # constant number, or a label. We don't allow labels that could # be confused # with registers. (No I0: anywhere...) Noo! How will I write really confusing JAPHs now? :^) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
Re: PDD 6: Parrot Assembly Language
On Monday 10 September 2001 09:00 pm, Dan Sugalski wrote: > >But how does the interpreter know where a lexical scope begins > >and ends in the bytecode? For example, a "jump FOO" might change > >scopes. How is the scope discovered? > >jump FOO > > doesn't change scope. Is that a "doesn't" or "won't"? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote: > >I'm thinking of writing something to generate a Parrot::Opcode.pm > >module, so code doesn't need to parse opcode_table and interp_guts.h. > >Sound reasonable? > > Yes, please do. I knew we needed one the second time I needed to parse > opcode_table, I just haven't stopped long enough to be lazy and still > program. (In those cases I came to a full stop...) OK, I'll do that sometime tonight. Should it parse opcode_table, or should it be generated with the contents of opcode_table? - Damien
length_s_i patch
Okay, we'll start small. "length_s_i" is backwards - should be "length_i_s".
Patch fixes code and test.
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.6
diff -u -r1.6 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/10 21:47:25 1.6
+++ basic_opcodes.ops 2001/09/11 01:13:43
@@ -311,7 +311,7 @@
}
// LEN Ix, Sx
-AUTO_OP length_s_i {
+AUTO_OP length_i_s {
INT_REG(P1) = string_length(STR_REG(P2));
}
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.6
diff -u -r1.6 opcode_table
--- opcode_table2001/09/10 21:26:09 1.6
+++ opcode_table2001/09/11 01:13:44
@@ -44,7 +44,7 @@
set_s_sc 2 i i
print_s1 i
-length_s_i 2 i i
+length_i_s 2 i i
chopn_s_ic 2 i i
# Comparators
Index: t/test2.pasm
===
RCS file: /home/perlcvs/parrot/t/test2.pasm,v
retrieving revision 1.1
diff -u -r1.1 test2.pasm
--- t/test2.pasm2001/09/10 22:18:43 1.1
+++ t/test2.pasm2001/09/11 01:13:44
@@ -2,7 +2,7 @@
set_i_ic I1, 0
set_s_sc S1, "Hello World"
REDO: eq_i_ic I1, I2, DONE, NEXT
-NEXT: length_s_i I1, S1
+NEXT: length_i_s I1, S1
print_s S1
chopn_s_ic S1, 1
branch_ic REDO
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Muddled Boundaries - Perl 6 vs Parrot
At 10:29 AM 9/10/2001 -0400, Bryan C. Warnock wrote: >Erk, we seem to be muddling around in that great grey area between what is >Parrot and what is Perl. > >Parrot is striving to be a common backend for multiple scripting languages, >of which one is Perl 6, no? And, of course, to adequately test Parrot, you >need to concurrently develop Perl 6, yes? And that is what is currently >happening, yes? No. (At least, it doesn't seem so.) No. We don't need perl to test the interpreter. Parser and compiler, yes, interpreter no. >Certainly, register creation, memory allocation, garbage collection, and >opcode dispatch are definitely within the purview of Parrot. However, the >opcodes' code themselves aren't - they're provided by the language. Nope. The core opcodes are provided by the interpreter. A branch is a branch is a branch, no matter what language generated it. >Parrot may provide facilities for vtable dispatch and string handling, but a >language isn't roped into using them. True, but performance is going to really suck if they don't use them. Which is OK, I don't mind if people work to get themselves bad performance. :) >Things to keep in mind. (And another reason why it's good to have Namespace >Police :) For which reason we have brainwashed^Wrecruited Ben, it seems. Keen! (Smile and wave to the OMCL, Ben... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD 6: Parrot Assembly Language
Dan Sugalski wrote:
>jump FOO
>
> doesn't change scope.
>
>newscope scope_template_in_fixup_section
>
> does. And
>
>exitscope
>
> leaves one. :)
Ok. That clears it up a little. The current scope is part of
the VM internal state and compilers need to generate state
change instructions if they use lexicals. (Actually, I hope
they only need state change instructions if they need the
scope's symbol table...)
Just to check my understanding, Perl 6 will compile
{ bar { foo } blah }
into
newscope
bar
newscope
foo
exitscope
blah
exitscope
What happens with:
goto FOO; { bar { FOO: foo } blah }
Is goto responsible for figuring out it has entered bar's
scope and setting the VM state so that the exitscopes are
properly balanced?
- Ken
RE: Patch to assembler/disassembler + parrot asm
At 06:16 PM 9/10/2001 -0700, Brent Dax wrote: >Dan Sugalski: >... ># The jump ops will be easy to figure--either they'll take a ># register, a ># constant number, or a label. We don't allow labels that could ># be confused ># with registers. (No I0: anywhere...) > >Noo! How will I write really confusing JAPHs now? :^) "use APL;" ? ;-P Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD 6: Parrot Assembly Language
At 09:01 PM 9/10/2001 -0400, Bryan C. Warnock wrote: >On Monday 10 September 2001 09:00 pm, Dan Sugalski wrote: > > >But how does the interpreter know where a lexical scope begins > > >and ends in the bytecode? For example, a "jump FOO" might change > > >scopes. How is the scope discovered? > > > >jump FOO > > > > doesn't change scope. > >Is that a "doesn't" or "won't"? Won't. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Speaking of namespaces...
At 06:02 PM 9/10/2001 -0700, Damien Neil wrote: >On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote: > > >I'm thinking of writing something to generate a Parrot::Opcode.pm > > >module, so code doesn't need to parse opcode_table and interp_guts.h. > > >Sound reasonable? > > > > Yes, please do. I knew we needed one the second time I needed to parse > > opcode_table, I just haven't stopped long enough to be lazy and still > > program. (In those cases I came to a full stop...) > >OK, I'll do that sometime tonight. Should it parse opcode_table, >or should it be generated with the contents of opcode_table? Parse opcode_table. Sync up your source first, there have been some changes to the format in the last few hours. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Patch: missing comparison _ics
This patch (temporarily) fixes the missing _ic on comparison opcodes.
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.6
diff -u -r1.6 assemble.pl
--- assemble.pl 2001/09/10 21:26:08 1.6
+++ assemble.pl 2001/09/11 01:27:58
@@ -68,12 +68,12 @@
$args[0] = fixup($args[0])
if $opcode eq "branch_ic" and $args[0] =~ /[a-zA-Z]/;
-#if ($opcode eq "eq_i_ic" or $opcode eq "lt_i_ic") {
-if ($opcode =~ /^(eq|ne|lt|le|gt|ge)_i_ic$/) {
+#if ($opcode eq "eq_i_ic_ic" or $opcode eq "lt_i_ic_ic") {
+if ($opcode =~ /^(eq|ne|lt|le|gt|ge)_i_ic_ic$/) {
$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
$args[3] = fixup($args[3]) if $args[3] =~ /[a-zA-Z]/;
}
-if ($opcode eq "if_i_ic") {
+if ($opcode eq "if_i_ic_ic") {
$args[1] = fixup($args[1]) if $args[1] =~ /[a-zA-Z]/;
$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
}
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.6
diff -u -r1.6 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/10 21:47:25 1.6
+++ basic_opcodes.ops 2001/09/11 01:27:58
@@ -41,7 +41,7 @@
}
// EQ Ix, Iy, EQ_BRANCH, NE_BRANCH
-MANUAL_OP eq_i_ic {
+MANUAL_OP eq_i_ic_ic {
if (INT_REG(P1) == INT_REG(P2)) {
RETURN(P3);
} else {
@@ -50,7 +50,7 @@
}
// NE Ix, Iy, NE_BRANCH, EQ_BRANCH
-MANUAL_OP ne_i_ic {
+MANUAL_OP ne_i_ic_ic {
if (INT_REG(P1) != INT_REG(P2)) {
RETURN(P3);
} else {
@@ -59,7 +59,7 @@
}
// LT Ix, Iy, LT_BRANCH, GE_BRANCH
-MANUAL_OP lt_i_ic {
+MANUAL_OP lt_i_ic_ic {
if (INT_REG(P1) < INT_REG(P2)) {
RETURN(P3);
} else {
@@ -68,7 +68,7 @@
}
// LE Ix, Iy, LE_BRANCH, GT_BRANCH
-MANUAL_OP le_i_ic {
+MANUAL_OP le_i_ic_ic {
if (INT_REG(P1) <= INT_REG(P2)) {
RETURN(P3);
} else {
@@ -77,7 +77,7 @@
}
// GT Ix, Iy, GT_BRANCH, LE_BRANCH
-MANUAL_OP gt_i_ic {
+MANUAL_OP gt_i_ic_ic {
if (INT_REG(P1) > INT_REG(P2)) {
RETURN(P3);
} else {
@@ -86,7 +86,7 @@
}
// GE Ix, Iy, GE_BRANCH, LT_BRANCH
-MANUAL_OP ge_i_ic {
+MANUAL_OP ge_i_ic_ic {
if (INT_REG(P1) >= INT_REG(P2)) {
RETURN(P3);
} else {
@@ -95,7 +95,7 @@
}
// IF IXx, TRUE_BRANCH, FALSE_BRANCH
-MANUAL_OP if_i_ic {
+MANUAL_OP if_i_ic_ic {
if (INT_REG(P1)) {
RETURN(P2);
} else {
@@ -178,7 +178,7 @@
}
// EQ Nx, Ny, EQ_BRANCH, NE_BRANCH
-MANUAL_OP eq_n_ic {
+MANUAL_OP eq_n_ic_ic {
if (NUM_REG(P1) == NUM_REG(P2)) {
RETURN(P3);
} else {
@@ -187,7 +187,7 @@
}
// IF Nx, TRUE_BRANCH, FALSE_BRANCH
-MANUAL_OP if_n_ic {
+MANUAL_OP if_n_ic_ic {
if (NUM_REG(P1)) {
RETURN(P2);
} else {
@@ -311,7 +311,7 @@
}
// LEN Ix, Sx
-AUTO_OP length_s_i {
+AUTO_OP length_i_s {
INT_REG(P1) = string_length(STR_REG(P2));
}
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.6
diff -u -r1.6 opcode_table
--- opcode_table2001/09/10 21:26:09 1.6
+++ opcode_table2001/09/11 01:27:58
@@ -44,25 +44,25 @@
set_s_sc 2 i i
print_s1 i
-length_s_i 2 i i
+length_i_s 2 i i
chopn_s_ic 2 i i
# Comparators
-eq_i_ic4 i i i i
-eq_n_ic4 i i i i
-ne_i_ic4 i i i i
-lt_i_ic4 i i i i
-le_i_ic4 i i i i
-gt_i_ic4 i i i i
-ge_i_ic4 i i i i
+eq_i_ic_ic 4 i i i i
+eq_n_ic_ic 4 i i i i
+ne_i_ic_ic 4 i i i i
+lt_i_ic_ic 4 i i i i
+le_i_ic_ic 4 i i i i
+gt_i_ic_ic 4 i i i i
+ge_i_ic_ic 4 i i i i
# Flow control
jump_i 1 i
branch_ic 1 i
-if_i_ic3 i i i
-if_n_ic3 i i i
+if_i_ic_ic 3 i i i
+if_n_ic_ic 3 i i i
# Convertors
Index: t/test.pasm
===
RCS file: /home/perlcvs/parrot/t/test.pasm,v
retrieving revision 1.1
diff -u -r1.1 test.pasm
--- t/test.pasm 2001/09/10 22:18:43 1.1
+++ t/test.pasm 2001/09/11 01:27:58
@@ -2,7 +2,7 @@
set_i_ic I2, 0
set_i_ic I3, 1
set_i_ic I4, 1000
-REDO: eq_i_ic I2, I4, DONE, NEXT
+REDO: eq_i_ic_ic I2, I4, DONE, NEXT
NEXT: add_i I2, I2, I3
branch_ic REDO
DONE: time_i I5
Index: t/test2.pasm
===
RCS file: /home/perlcvs/parrot/t/test2.pasm,v
retrieving revision 1.1
diff -u -r1.1 test2.pasm
--- t/test2.pasm2001/09/10 22:18:43 1.1
+++ t/test2.pasm2001/09/11 01:27:58
@@ -1,8 +1,8 @@
set_i_ic I2, 1
set_i_ic I1, 0
set_s_sc S1, "Hello World"
-REDO: eq_i_ic I1, I2, DONE, NEXT
-NEXT: length_s_i I1, S
Re: PDD 6: Parrot Assembly Language
At 05:41 PM 9/10/2001 -0400, Ken Fox wrote: >Dan Sugalski wrote: > > =item if tx, X, Y > >What's the purpose of providing Y? Does it make anything easier >allowing Y != 0? Hmmm. No, it doesn't, it just bloats out the opcode stream by an IV. I'll fix that. > > =item jump tx > >I expected a "call" op too. Not a named sub call, but just "call >tx" where tx has the same semantics as in "jump". > >A "return" op is needed too. In the next rev, I just haven't mailed it out yet. > > =item iton Nx, Iy > > =item ntoi Ix, Ny > > =item tostring Sx, ty, Iz > >Are these good names? They aren't very regular IMHO. Why is >integer abbreviated "i" and string left spelled out? Why does >tostring have three operands and the other two? No, because, and the third is a string type, on the off chance you wanted a non-native string. (Unicode, EBCDIC, whatever) Respectively. :) > > =item inc tx, nn * > > =item dec tx, nn * > > > Decrement register x by nn. nn is an integer constant. If nn is > > omitted, decrement by 1. > >Variable length ops don't sound so cool to me. Why not use >add/sub to inc/dec by something other than 1? They aren't variable length. They're actually inc_i & inc_i_ic (and inc_n, inc_n_nc, and so on...) under the hood. The assembler is supposed to be smart enough to see you did: inc N2, 5 and know it's supposed to emit the inc_n_nc form. The assembler's not that smart yet. >Also, it would be nice if inc/dec *always* kept Parrot semantics >instead of automagically transmogrifying to Perl inc/dec. Is >this the plan? Dunno what you mean. I & N registers increment numerically, PMC registers get the variable's vtable inc function called, and I don't know what happens if we do it on a string register. We might not allow it. > > =head2 Register and stack ops > >I'm a little confused why we can only push/pop entire register >frames. Won't this make function value returns via registers >impossible? IMHO, instead of push/pop a rotate command >would be nice. That would allow SPARC-like register usage which >has always seemed elegant to me. There are things missing. There's a fetch from the past op, a push-with-clone op, and a push on the generic stack op. They're just not in the doc I mailed yet. > > =item warp [string] > > > > Reset the current register stacks to the state they were in when the > > warp was set. Resets only the frame pointers, doesn't guarantee the > > contents of the registers. Be I careful modifying the frame > > pointers by, for example, pushing register frames. > >I don't understand this explanation. It sounds like you are setting >up co-routines or maybe resuming a continuation. Shouldn't the ops >be a little safer? IMHO we don't want a co-routine construction set, >we just want co-routines. It's more for the case when we've pushed a few frames of registers and need to get back to the marker for a moment. Sort of like setjmp/longjmp/comefromjmp in C. (If it had a comefromjmp to undo the longjmp...) Might turn out to be a stupid thing. If so, it's out of there. > > =item find_lex Px, sy > > > > Find the lexical of name sy and store the PMC pointer in register Px. > >You're expecting the current lexical scope to be carried implicitly >via the PC? No, it'll be in the interpreter struct. >Seems like find_lex should really be implemented as a >vtable method on a compiler's scope object. Well, if we had one we could, I suppose. > > =item find_method Px, Py, tz > > =item call_method Px, ty > >Multi-methods are notably absent. Haven't gotten there yet. >I'm assuming that Parrot does not >understand multi-methods and requires the object (or the compiler >generating the object) to register a multi-method dispatcher as the >single-dispatch method known to Parrot. Nope, multimethod dispatch will be built in, at least for some number of args. (At least 2, maybe more) It's a lot more efficient if parrot handles that. >This only lets us use multi-methods where arg0 is an object. Is >this sufficient for implementing Perl 6? Ummm... how on earth do you plan on calling a method of something that's not an object? Methods sorta require them... :) Anyway, I realized that bit of the PDD was unfinished after I sent it. I'd hoped to correct it before it got poked at, but didn't get a chance. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD 6: Parrot Assembly Language
At 09:26 PM 9/10/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> >jump FOO
> >
> > doesn't change scope.
> >
> >newscope scope_template_in_fixup_section
> >
> > does. And
> >
> >exitscope
> >
> > leaves one. :)
>
>Ok. That clears it up a little. The current scope is part of
>the VM internal state and compilers need to generate state
>change instructions if they use lexicals.
Yes. More to the point only if they need to have a new set of lexicals.
We'll probably have scopeless subs.
>(Actually, I hope
>they only need state change instructions if they need the
>scope's symbol table...)
>
>Just to check my understanding, Perl 6 will compile
>
> { bar { foo } blah }
>
>into
>
>newscope
>bar
>newscope
>foo
>exitscope
>blah
>exitscope
Something like that, yes.
>What happens with:
>
>goto FOO; { bar { FOO: foo } blah }
>
>Is goto responsible for figuring out it has entered bar's
>scope and setting the VM state so that the exitscopes are
>properly balanced?
I'm not sure what we'll do in that situation. gotos into scopes might not
be allowed.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Speaking of namespaces...
On Monday 10 September 2001 09:27 pm, Dan Sugalski wrote: > > Parse opcode_table. Sync up your source first, there have been some > changes to the format in the last few hours. I'll wait on those changes before delving back into the assembler for the simplified instruction handling. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: PDD 6: Parrot Assembly Language
On Monday 10 September 2001 09:30 pm, Dan Sugalski wrote:
> >What happens with:
> >
> >goto FOO; { bar { FOO: foo } blah }
> >
> >Is goto responsible for figuring out it has entered bar's
> >scope and setting the VM state so that the exitscopes are
> >properly balanced?
>
> I'm not sure what we'll do in that situation. gotos into scopes might not
> be allowed.
That's how it currently is for most scopes, and it certainly saves a whole
lot of trouble and inconsistencies.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Patch: assembler deferred output
Following patch defers output of opcode until the end of an error-free run.
Also introduces a primitive '-c' option to allow checking of assembly only
(a la Perl).
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.6
diff -u -r1.6 assemble.pl
--- assemble.pl 2001/09/10 21:26:08 1.6
+++ assemble.pl 2001/09/11 01:45:34
@@ -5,6 +5,11 @@
use strict;
my(%opcodes, %labels);
+my ($output, $opt_c);
+if (@ARGV and $ARGV[0] eq "-c") {
+shift @ARGV;
+$opt_c = 1;
+}
my %pack_type;
%pack_type = (i => 'l',
@@ -52,14 +57,16 @@
# Now assemble
$pc = 0;
+my $line = 0;
while ($_ = shift @code) {
+$line++;
chomp;
s/,/ /g;
my ($opcode, @args) = split /\s+/, $_;
if (!exists $opcodes{lc $opcode}) {
- die "No opcode $opcode";
+ die "No opcode $opcode at line $line:\n <$_>\n";
}
if (@args != $opcodes{$opcode}{ARGS}) {
die "wrong arg count--got ". scalar @args. " needed " .
$opcodes{$opcode}{ARGS};
@@ -68,25 +75,27 @@
$args[0] = fixup($args[0])
if $opcode eq "branch_ic" and $args[0] =~ /[a-zA-Z]/;
-#if ($opcode eq "eq_i_ic" or $opcode eq "lt_i_ic") {
- if ($opcode =~ /^(eq|ne|lt|le|gt|ge)_i_ic$/) {
+#if ($opcode eq "eq_i_ic_ic" or $opcode eq "lt_i_ic_ic") {
+if ($opcode =~ /^(eq|ne|lt|le|gt|ge)_i_ic_ic$/) {
$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
$args[3] = fixup($args[3]) if $args[3] =~ /[a-zA-Z]/;
}
-if ($opcode eq "if_i_ic") {
+if ($opcode eq "if_i_ic_ic") {
$args[1] = fixup($args[1]) if $args[1] =~ /[a-zA-Z]/;
$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
}
-print pack "l", $opcodes{$opcode}{CODE};
+$output .= pack "l", $opcodes{$opcode}{CODE};
foreach (0..$#args) {
$args[$_] =~ s/^[INPS]?(\d+)$/$1/i;
my $type = $pack_type{$opcodes{$opcode}{TYPES}[$_]};
- print pack $type, $args[$_];
+ $output .= pack $type, $args[$_];
}
$pc += 1+@args;
}
+print $output unless (defined $opt_c and $opt_c);
+
sub fixup {
my $l = shift;
die "Unknown label $l" unless exists $labels{$l};
@@ -100,10 +109,10 @@
return $constants{$s} = $#constants;
}
-sub emit_magic { print pack($pack_type{i}, 0x13155a1) }
+sub emit_magic { $output .= pack($pack_type{i}, 0x13155a1) }
# Dummy for now.
-sub emit_fixup_section { print pack($pack_type{i}, 0) }
+sub emit_fixup_section { $output .= pack($pack_type{i}, 0) }
sub emit_constants_section {
# First, compute how big it's going to be.
@@ -116,17 +125,17 @@
}
$size += $sizeof_packi if @constants; # That's for the number of
constants
-print pack($pack_type{i}, $size);
+$output .= pack($pack_type{i}, $size);
return unless @constants; # Zero means end of segment.
# Then spit out how many constants there are, so we can allocate
-print pack($pack_type{i}, scalar @constants);
+$output .= pack($pack_type{i}, scalar @constants);
# Now emit each constant
for (@constants) {
-print pack($pack_type{i},0) x 3; # Flags, encoding, type
-print pack($pack_type{i},length($_)); # Strlen followed by that
many bytes.
-print $_;
-print "\0" x (length($_) % $sizeof_packi); # Padding;
+$output .= pack($pack_type{i},0) x 3; # Flags, encoding, type
+$output .= pack($pack_type{i},length($_)); # Strlen followed by
that many bytes.
+$output .= $_;
+$output .= "\0" x (length($_) % $sizeof_packi); # Padding;
}
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Patch to assembler/disassembler + parrot asm inconsistancies
At 07:25 PM 9/10/2001 -0400, Bryan C. Warnock wrote: >I think Dan mentioned this, but it looks like the suffixes can be derived >from the args being passed in. That would greatly simply the assembler to >just the function names: set, eq, add, branch. > >Were there problems with the scheme, is someone working on it, or did it >fall through the cracks? (I'm very much in favor of such a change, and will >pick it up if no one else is working on it.) No, I dont' think so, and yes, respectively. (Or, rather, we did the easy literal stuff first and planned on smartening up the assembler later. It's in the TODO even... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
