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 (GUTS) {
-next unless /\tx\[(\d+)\] = ([a-z_]+);/;
-$opcodes{$2}{CODE} = $1;
-}
-
-open OPCODES, opcode_table or die Can't get opcode table, $!/$^E;
-while (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 CONST;
/*
*
@@ -18,16 +17,8 @@
#define BUILD_TABLE(x) do { \\
CONST
-my $count = 1;
-while (OPCODES) {
-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 (GUTS) {
-next unless /\tx\[(\d+)\] = ([a-z_]+);/;
-$opcodes{$2}{CODE} = $1;
-}
-
-open OPCODES, opcode_table or die Can't get opcode table, $!/$^E;
-while (OPCODES) {
-next if /^\s*#/;
-s/^\s+//;
-
Re: Muddled Boundaries - Perl 6 vs Parrot
On Mon, Sep 10, 2001 at 11:26:03AM -0700, Benjamin Stuhl wrote: 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. You are, of course, correct; I back down. However, if you care that much, I'm going to make you prove it by implementing it. :) As Nat identifies, the problem is with deciding what should and shouldn't be exported, especially on platforms which require an explicit exports list. For instance, the interpreter ops should never see the light of day; other functions might need to. So sorting out namespaces ought to be unnecessary in many cases. For instance, since interpreter ops should never escape from an object, there should be no need to explicitly rename them - we simply don't export them. (But are there platforms where you *can't* tell the linker or ar to not export certain symbols?) I am in two minds here. I want to have Parrot_... prefices on functions even if they're *not* completely necessary /pour encourager les autres/. However, I don't want to go the way of opening up everything in a public API righht now, because once you've exported a symbol for developers to use, you can never take it away from them again - whereas if nearly everything's private and not exported, you can always open it up later. So on balance, I think I'm not going to do anything about the Great Renaming Issue until someone (myself included) has either come up with a patch and/or a good proposal for what the Parrot API should look like for embedders. And by embedders, don't forget we also mean Perl 6 itself, since Parrot is just an interpreter - it's got to be fed bytecode from *somewhere*... Simon
Configure system
One of the items on the Parrot TODO is to build a Configure system. I don't want to spark up the old metaconfig-versus-autoconf debate again, so I'll clarify what I mean. We have long-term and short-term goals for Parrot's configure system. The long-term goal is not something I want people to worry about right now, but it would be good if people could start thinking about it. Eventually, we want Parrot's configure to work a little like the proposed microperl configure system. That's to say, we build a tiny tiny version of Parrot with default values for various config assumptions; we can ship config.h files that work on standard Unix platforms, Win32, and so on. Then that microparrot runs various precompiled bytecode programs which probe the system finding out more information about the enivronment, and produce a config file which is used to build Parrot proper. But we can't do that right now because we don't have a very easy way of generating those precompiled bytecode programs. So relax. The short-term goal is really really simple and really really neat. You'll notice that the Parrot build process currently depends on the existence of Perl 5 to build certain header files and preprocess the opcode table. So if we know we've got Perl 5 hanging around, we know we've already got a config file which tells us things like how big IVs are, what header files we have around, and so on. Furthermore, we can write a Perl program which uses Config.pm to give us this information in a hash, and hence we can use that to produce a config.h specific to a given machine. So I'd like to see a patch which consists of a program to automatically generate Parrot's config.h from Perl's Config.pm. You could be really clever, and also have it conditionally include some of the header files mentioned in parrot.h depending on whether the i_... values in Config.pm say we have them. (You may need to move the #includes of the system header files from parrot.h to config.h) No prizes will be awarded for using Perl's config.h, or C preprocessor abuse. :) Furthermore, I'd like to see a Portability Pumpkin step forward to warn us when we're doing things that don't go down too well on Cray Unicos or QNX 6. Simon
Re: String API
On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote: Have you guys seen Topaz? I may have heard of it, yes. The other major suggestion I have is to avoid void * interfaces. I'm using void * to avoid char *. :) Do we really need a string_make() that takes the encoding enum? Yes. Aren't encodings different enough that we'd want string_make_ascii(), string_make_utf32(), ... No. Look at the code for string_make. If you're already passing *in* a UTF32 buffer, why do we need any special processing for UTF32? Maybe I've been doing C++ too long, Any C++ is too much C++. 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. And that'll remove the abstraction I've fought so hard to put in. 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 don't know why I did this. Patches welcome. 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. No, that's a really bad way to do it. We can special-case things like UTF16 to UTF32. The destination can be pre-extended to the length of the source to avoid fragmenting memory. Yes, I've thought about that, and that's what max_bytes is for. How many encoding specific optimizations are there? Is it worth having a table of custom transcoders instead of using a generic algorithm? Yes. Simon
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote: Nothing should read out of interp_guts.h. That's autogenerated from opcode_table. Or it was yesterday, but things might've changed. :) Sorry, but things have changed. This is now where the op number assignments are stored. Simon
Re: length_s_i patch
On Mon, Sep 10, 2001 at 09:10:17PM -0400, Bryan C. Warnock wrote: Okay, we'll start small. length_s_i is backwards - should be length_i_s. Patch fixes code and test. Thanks, applied.
Re: Patch: missing comparison _ics
On Mon, Sep 10, 2001 at 09:24:33PM -0400, Bryan C. Warnock wrote: This patch (temporarily) fixes the missing _ic on comparison opcodes. Didn't apply cleanly. Can you try again from CVS? Simon
Re: Parrot configure stuff, first stab
On Mon, Sep 10, 2001 at 11:42:01PM -0700, Matthew Cline wrote: This is a first stab at the configure stuff for Parrot. Damn, I knew I should have got that mail out last night. Sorry, Matthew. Simon
Re: Patch: missing comparison _ics
On Mon, Sep 10, 2001 at 09:24:33PM -0400, Bryan C. Warnock wrote: This patch (temporarily) fixes the missing _ic on comparison opcodes. I'd also like to publically question the wisdom of changing *too much* of the assembly before we have an assembler that's smart enough to grok both styles of code. Simon
RE: Configure system
Simon Cozens:
# One of the items on the Parrot TODO is to build a Configure
# system. I don't want to spark up the old metaconfig-versus-autoconf
# debate again, so I'll clarify what I mean.
...
# You'll notice that the Parrot build process currently depends on the
# existence of Perl 5 to build certain header files and preprocess the
# opcode table. So if we know we've got Perl 5 hanging around, we know
# we've already got a config file which tells us things like how big IVs
# are, what header files we have around, and so on. Furthermore, we
# can write a Perl program which uses Config.pm to give us this
# information in a hash, and hence we can use that to produce a
# config.h
# specific to a given machine.
#
# So I'd like to see a patch which consists of a program to
# automatically generate Parrot's config.h from Perl's Config.pm. You
# could be really clever, and also have it conditionally include some
# of the header files mentioned in parrot.h depending on whether the
# i_... values in Config.pm say we have them. (You may need to move the
# #includes of the system header files from parrot.h to config.h)
# No prizes will be awarded for using Perl's config.h, or C preprocessor
# abuse. :)
I'm starting to do some hacking on this. (Hey, I can't sleep... :^) )
Since Perl 5 already has this stuff, it seems like it should be pretty
easy. (Famous last words?) The $64,000 question is, what do I have to
copy over? A simple autogenerate what's already in Parrot's config.h
is easy--I've already written a prototype (pasted after my sig)--but
seems like it's too easy considering what you're talking about. What
else does it need to do?
The prototype below properly defines IV and NV (most of the time) based
on Perl 5's IV and NV. It also sets up HAS_HEADER_FOO for each of the
i_ symbols in Config.pm. Let me know if I should change the symbol I
define. (If the comment line with my name in it seems improper, feel
free to remove it.)
I'm on Win32, so I don't have the tools to make a diff (I'm trying to
get PPT working) so you'll have to turn it into a patch yourself.
Sorry.
--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.
~~~
#!/usr/bin/perl -w
#we want -w on
#Configure.pl, written by Brent Dax
use strict;
use Config;
print END;
Parrot Configure
Copyright (C) 2001 Yet Another Society
Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.
Rules are the same as Perl 5's Configure--defaults are in
square brackets, and you can hit enter to accept them.
END
#Some versions don't seem to have ivtype or nvtype--provide
#defaults for them.
#XXX Figure out better defaults
my($iv, $nv)=(($Config{ivtype}||'long'), ($Config{nvtype}||'long
double'));
my $input;
print How big would you like integers to be? [$iv] ;
chomp($input=STDIN);
$iv=$input||$iv;
print How about your floats? [$nv] ;
chomp($input=STDIN);
$nv=$input||$nv;
my($config_h)=END_OF_CONFIG_H;
/* config.h
*
* Platform-specific config file
*
* DO NOT EDIT THIS FILE!
* This file was autogenerated by Configure.pl--please
* rerun that! Changes to this file may be lost!
*
*/
#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
typedef $iv IV
typedef $nv NV;
typedef struct _vtable VTABLE;
typedef void DPOINTER;
typedef void SYNC;
//typedef IV *(*opcode_funcs)(void *, void *) OPFUNC;
#define FRAMES_PER_CHUNK 16
#define FRAMES_PER_PMC_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_NUM_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_INT_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_STR_REG_CHUNK FRAMES_PER_CHUNK
#define MASK_CHUNK_LOW_BITS 0xf000
END_OF_CONFIG_H
print END;
Okay. Now I'm gonna probe Perl 5's configuration to see
what headers you have around. This could take a bit on slow
machines...
END
#set up HAS_HEADER_
foreach(grep {/^i_/} keys %Config) {
$config_h.=defineifdef((/^i_(.*)$/));
}
$config_h.=\n#endif;
open(CONFIG_H, config.h);
print CONFIG_H $config_h;
print END;
Okay, we're done!
You can now use `make test_prog' (or your platform's equivalent to
`make')
to build your Parrot. Happy Hacking,
The Parrot Team
END
sub defineifdef {
my $thing=shift;
if($Config{i_$thing}) {
return #define HAS_HEADER_\U$thing\E\n;
}
else {
return #undef HAS_HEADER_\U$thing\E\n; #XXX do we want this?
}
}
RE: Configure system
Simon Cozens: # On Tue, Sep 11, 2001 at 02:22:13AM -0700, Brent Dax wrote: # A simple autogenerate what's already in Parrot's config.h is easy # # This is a good start. # # --I've already written a prototype (pasted after my sig)--but # seems like it's too easy considering what you're talking # about. What # else does it need to do? # # I'd rather it took a config.h.in or similar and slapped the IV/NV/etc. # typedefs in the middle. This means we can hack the template each time # we need it to change, instead of hacking the Perl script that # generates # config.h. Good idea. Why didn't I think of it? :^) # Thanks for working on this. No problem--I'm just helping the best way I can at this point. Attached are new Configure.pl and config.ht files. Feel free to rename config.ht if you want. (They may have Windows newlines, unless e-mail clients do some translating of those behind the scenes that I don't know about.) --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. Configure.pl config.ht
Re: Parrot configure stuff, first stab
On Tuesday 11 September 2001 01:14 am, Simon Cozens wrote: On Mon, Sep 10, 2001 at 11:42:01PM -0700, Matthew Cline wrote: This is a first stab at the configure stuff for Parrot. Damn, I knew I should have got that mail out last night. Sorry, Matthew. Well, the autoconf/automake configure system does more than just generate a config.h file. It also determines what compiler and linker flags to use, if the needed libraries are present (with needed versions), takes care of stuff like dependencies, and lets you maintain a simple make file which it translates into a big-and-hairy makefile (22 lines for my Makefile.am versus 465 lines for the output Makefile). I have no clue as to how gcc does automatic dependency checking, but I just have to add one line to configure.in and it magically happens. Is parrot going to have it's own makefile generator, or should it use autoconf? -- Matthew Cline| Suppose you were an idiot. And suppose that [EMAIL PROTECTED] | you were a member of Congress. But I repeat | myself. -- Mark Twain
JavaVM - ParrotVM
Seeing as Simon's gone to all the trouble of releasing the source to
Parrot now, I wondered what I could have a play with. I've did simple
Parrot assembler and thought about different types of bytecode. Like
bytecode for the Java virtual machine, which it turns out is stack
based. Could I convert JVM-PVM? I think so ;-)
[Yes, this is a proof of concept, and the parrot assembler will change
in many ways rsn, so this is just a head up to show it's possible]
Given the following Java code:
class HelloWorld {
public static void main (String args[]) {
int i = 1;
int j = 1;
while(i 10) {
System.out.print(i);
System.out.print(j);
i++;
j += i;
}
}
}
(which prints out: 112336410515621728836945)
That actually gets translated into the the following JVM bytecode:
0 iconst_1
1 istore_1
2 iconst_1
3 istore_2
4 goto 28
7 getstatic #2 Field java.io.PrintStream out
10 iload_1
11 invokevirtual #3 Method void print(int)
14 getstatic #2 Field java.io.PrintStream out
17 iload_2
18 invokevirtual #3 Method void print(int)
21 iinc 1 1
24 iload_2
25 iload_1
26 iadd
27 istore_2
28 iload_1
29 bipush 10
31 if_icmplt 7
34 return
And my magic script (http://astray.com/java2parrot.pl.txt)
converts it to the following Parrot assembler code:
set_i_ic I1, 1
set_i I63, I1
set_i_ic I1, 1
set_i I62, I1
branch_ic LAAA
LAAB: set_i I1, I63
print_i I1
set_i I1, I62
print_i I1
inc_i I63
set_i I1, I62
set_i I2, I63
add_i I1, I1, I2
set_i I62, I1
LAAA: set_i I3, I63
set_i_ic I4, 10
lt_i_ic I3, I4, LAAB, LAAC
LAAC: end
which outputs:
I reg 1 is 1
I reg 1 is 1
I reg 1 is 2
I reg 1 is 3
I reg 1 is 3
I reg 1 is 6
I reg 1 is 4
I reg 1 is 10
I reg 1 is 5
I reg 1 is 15
I reg 1 is 6
I reg 1 is 21
I reg 1 is 7
I reg 1 is 28
I reg 1 is 8
I reg 1 is 36
I reg 1 is 9
I reg 1 is 45
Cool, huh. Much more on this soon! Leon
--
Leon Brocard.http://www.astray.com/
Iterative Software...http://www.iterative-software.com/
... If you eat yogurt you'll have lots of culture
Parrot coredumps on Solaris 8
/lurk Hi. I've just tried getting Parrot running on a Solaris 8 box here, but it's coredumping on me with test2.pasm and test3.pasm: cass87:pak:~/data2/parrot$ ./test_prog test.pbc I reg 1 is 1000206849 I reg 5 is 1000206859 I reg 2 is 1000 I reg 2 is 10 I reg 4 is 3000 N reg 1 is 3000.00 I reg 2 is 10 N reg 2 is 10.00 N reg 1 is 300.00 cass87:pak:~/data2/parrot$ perl assemble.pl t/test2.pasm test2.pbc cass87:pak:~/data2/parrot$ ./test_prog test2.pbc Bus Error cass87:pak:~/data2/parrot$ perl assemble.pl t/test3.pasm test3.pbc cass87:pak:~/data2/parrot$ ./test_prog test3.pbc I reg 1 is 0 Segmentation Fault This is apparently consistent across various Solaris boxes here; the machine above is: cass87:pak:~/data2/parrot$ uname -a SunOS cass87 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10 Has anyone else seen this behaviour, or am I going to have to do some digging? Cheers, Phil -- Philip Kendall [EMAIL PROTECTED] http://www.srcf.ucam.org/~pak21/
Re: Muddled Boundaries - Perl 6 vs Parrot
--- Simon Cozens [EMAIL PROTECTED] wrote: On Mon, Sep 10, 2001 at 11:26:03AM -0700, Benjamin Stuhl wrote: 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. You are, of course, correct; I back down. However, if you care that much, I'm going to make you prove it by implementing it. :) On my personal todo list for this afternoon is to go through each of the source files and enforce the coding PDD. However, before I do this, I would like to bring up the question of prefixes once again. Do we really need a 7 letter, mixed-case prefix (Parrot_)? If Apache can do ap_, why can't we do par_ (and maybe parp_ for private stuff)? Also, I am planning to go through the structs and prefix them (STRING - PAR_STRIN, for instance) and clean up the subsystem naming. What do you think of par_gc_* for memory management (yes, that means that uncollected memory is gotten by par_gc_memalloc_nogc(), but if you really want it, you deserve to type in all those letters) and par_io_* for I/O? -- BKS __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
Feature testing API?
It seems to me that Parrot should expose a feature testing API. Something on the order of int [read: boolean] par_has_feature(PAR_STRING *feature); (yes, I _do_ think that claiming STRING is unnecessary namespace pollution - sepecially as ANSI compilers, AFAIK, aren't required to be case-sensitive) This would be very useful for any language running on Parrot, so that they can just test (via some language binding) its presence at the beginning of a program, rather than bombind out in the middle when they hit an unimplemented call. Example features might be async I/O, run-time compilation (eval) of different languages, dynamic loading, etc. Basically, I would like to be able to say: use features qw[asyncio eval(perl6)]; and know that if my program loads, it's not going to panic when it gets to an eval 'Async::queueio_out($out_fh, $text);'; What d'y'all think? -- BKS __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
Re: Muddled Boundaries - Perl 6 vs Parrot
At 05:25 AM 9/11/2001 -0700, Benjamin Stuhl wrote: However, before I do this, I would like to bring up the question of prefixes once again. Do we really need a 7 letter, mixed-case prefix (Parrot_)? Externally exposed, yes. That's not to say that the programmer working inside the core needs to ever use 'em. Preprocessors are a nifty thing. :) 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
Simon Cozens writes: I am in two minds here. I want to have Parrot_... prefices on functions even if they're *not* completely necessary /pour encourager les autres/. However, I don't want to go the way of opening up everything in a public API righht now, because once you've exported a symbol for developers to use, you can never take it away from them again - whereas if nearly everything's private and not exported, you can always open it up later. Part of configuration could be building a #define pile so you can use foo and bar in the .c files, but they're invisibly translated into Parrot_ and so on equivalents. Preprocessing hurts my ass, though, when it comes time to debug. Nat
Re: PDD 6: Parrot Assembly Language
Bryan C. Warnock wrote:
On Monday 10 September 2001 09:30 pm, Dan Sugalski wrote:
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.
I'm not sure I understand what you mean. Perl 5 allows us to enter
and leave scopes with goto:
sub foo {
my($x, @y) = @_;
if ($x) {
goto START;
}
while (@y) {
$x = shift @y;
START:
print $x\n;
}
}
And of course the keywords last, next and redo are just restricted
gotos. Those are able to leave one or more scopes.
It isn't clear to me that explicit ops are the way to go
for scope management -- that seems to shift the burden of scope
management onto the compiler. A declarative interface between
the compiler and interpreter might be best. The compiler will
probably need that for communicating debugging info anyways.
- Ken
Re: PDD 6: Parrot Assembly Language
At 12:41 PM 9/11/2001 -0400, Ken Fox wrote: And of course the keywords last, next and redo are just restricted gotos. Those are able to leave one or more scopes. Leaving scopes is easy. You just walk up the stack and deconstruct things. (Or, in this case, potentially run the end-of-scope code attached to each scope) It isn't clear to me that explicit ops are the way to go for scope management -- that seems to shift the burden of scope management onto the compiler. I'm not seeing the problems with explicit scope management. Something's got to set up and tear down the various scopes, after all. Explicit management is a bit of a pain for the compiler, granted, but it gives us a lot of flexibility we wouldn't otherwise have. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot coredumps on Solaris 8
It also coredumps on Solaris 7, when running the test2.pbc - test.pbc is fine. The coredump doesn't show much, only that it keeled over at interpreter.c line 16, which is the while() loop. Once upon a time Philip Kendall shaped the electrons to say... /lurk Hi. I've just tried getting Parrot running on a Solaris 8 box here, but it's coredumping on me with test2.pasm and test3.pasm: cass87:pak:~/data2/parrot$ ./test_prog test.pbc I reg 1 is 1000206849 I reg 5 is 1000206859 I reg 2 is 1000 I reg 2 is 10 I reg 4 is 3000 N reg 1 is 3000.00 I reg 2 is 10 N reg 2 is 10.00 N reg 1 is 300.00 cass87:pak:~/data2/parrot$ perl assemble.pl t/test2.pasm test2.pbc cass87:pak:~/data2/parrot$ ./test_prog test2.pbc Bus Error cass87:pak:~/data2/parrot$ perl assemble.pl t/test3.pasm test3.pbc cass87:pak:~/data2/parrot$ ./test_prog test3.pbc I reg 1 is 0 Segmentation Fault This is apparently consistent across various Solaris boxes here; the machine above is: cass87:pak:~/data2/parrot$ uname -a SunOS cass87 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10 Has anyone else seen this behaviour, or am I going to have to do some digging? -D -- ZangTT berkeley db - it's mostly about the hash()
Re: String API
Dan Sugalski wrote: If you're speaking of multiple buffers for a string or something like that, you're looking at too low a level. That's something that should go in the variables, not in the string bits. (We do *not* want all string ops slow to support flexibility of this sort. Only the bits that need it) I think of buffers as more primitive than strings. They are segments of bits. They can be copied, extended, garbage collected, etc. They don't have character encodings. A string is just a buffer with a few more semantics. PMCs might implement split strings or some higher abstraction using several parrot_strings. Perhaps you intend to make parrot_string.bufstart hold a buffer structure. That'd be good, except that now parrot_string.buflen is not really owned by the string anymore -- the buffer structure is probably going to need to mess around with the string's internals. That increases the coupling between buffers and strings. Coupling is bad. ;) Others are the use of stacks in the interpreter and the dispatch of opcodes in runops(). So what's wrong with this? Lots of duplicated code in register.h. We really need a stack template. The interpreter knows the internals of the stack structure and is responsible for managing it. To change the stack implementation, we'll have to carefully examine all the interpreter code. The semantics of the stack aren't real clear either. For example, when changing the stack code what invariants must be preserved? If the stack had an API the interpreter used I think this would be much clearer. runops() is hard-wired with assumptions on the ops. What if we want to generate a switch-based runops()? How much code is going to make the same assumption that runops() does now? runops() should be generated similarly to the opcode table. There should be an API for calling ops so we don't have to jump through the same hoops required for perl 5. Compiler type checking isn't going to work for us at this level--we'd need runtime checking for it to work properly. I'm talking about the interface between Parrot and user code -- the XS layer in Perl 5. Sometimes compile-time checking is possible. We should try to take as much advantage of those situations as possible. For example, in Win32 we *know* that certain things are 16 bit Unicode. If we try to build a utf8 parrot_string with them, the compiler should barf. String encodings will be dynamically loadable. I'm going to add documentation for those ops in soon. (I was hoping today or tomorrow, but things are kinda screwy here at the moment) Simon just said the opposite. Does this mean that the C and Unicode encodings will be built-in and everything else dynamically loadable? - Ken
Re: PDD 6: Parrot Assembly Language
On Tuesday 11 September 2001 12:41 pm, Ken Fox wrote: I'm not sure I understand what you mean. Perl 5 allows us to enter and leave scopes with goto: Perl 5 allows you to leave most scopes (sort being the only exception), but just over half the constructs that introduce scope allow you to enter via goto. (And three of those should be footnoted as well...) And of course the keywords last, next and redo are just restricted gotos. Those are able to leave one or more scopes. Yes, leaving is okay. I was referring just to entering. -- Bryan C. Warnock [EMAIL PROTECTED]
A discussion of writing to the GCC front end
http://cobolforgcc.sourceforge.net/cobol_14.html
Re: String API
At 01:35 PM 9/11/2001 -0400, Ken Fox wrote: Dan Sugalski wrote: If you're speaking of multiple buffers for a string or something like that, you're looking at too low a level. That's something that should go in the variables, not in the string bits. (We do *not* want all string ops slow to support flexibility of this sort. Only the bits that need it) I think of buffers as more primitive than strings. That's OK, I don't. :) They are segments of bits. They can be copied, extended, garbage collected, etc. They don't have character encodings. A string is just a buffer with a few more semantics. Strings and buffers are mildly different or the same, depending on how you look at them. They ought not be conflated, really. And, honestly, there's nothing to stop you from adding a buffer type if you don't like what we've got. :) Perhaps you intend to make parrot_string.bufstart hold a buffer structure. No, I don't. It points to a chunk of memory. The encoding library associated with the string type knows what sort of data's there and its format. Others are the use of stacks in the interpreter and the dispatch of opcodes in runops(). So what's wrong with this? Lots of duplicated code in register.h. We really need a stack template. Oh, good grief. This is version *0.01*! Sheesh, not everything is going to look like Hemmingway writing C. The interpreter knows the internals of the stack structure and is responsible for managing it. No, it doesn't. The opcode functions do. The interpreter knows nothing to speak of about the format of the stack, and even if it does so what? It *should*. The stack is part of the interpreter. To change the stack implementation, we'll have to carefully examine all the interpreter code. No, we won't. We change some opcode functions. So? And deep carnal knowledge of the interpreter guts is just fine for other parts of the interpreter. Putting walls in at this level gets in the way in performance far more than the abstraction would help people writing code. The semantics of the stack aren't real clear either. For example, when changing the stack code what invariants must be preserved? If the stack had an API the interpreter used I think this would be much clearer. It might, the code's still young. It might not, too. That's fine as well. runops() is hard-wired with assumptions on the ops. What if we want to generate a switch-based runops()? How much code is going to make the same assumption that runops() does now? runops() should be generated similarly to the opcode table. You must have missed that part of the discussion. This has always been part of the plan, with the actual core being platform dependent for performance reasons. (Switch isn't faster everywhere) There should be an API for calling ops so we don't have to jump through the same hoops required for perl 5. There will *always* be hoops non-interpreter-core code needs to jump through to call ops. In fact, no non-interpreter-core code should *ever* call an op. Ever. Compiler type checking isn't going to work for us at this level--we'd need runtime checking for it to work properly. I'm talking about the interface between Parrot and user code -- the XS layer in Perl 5. You're looking in the wrong place. We haven't written *any* code or documentation on how extensions should interface to the core. This is all interpreter-guts-level stuff, and no extension should *ever* call it. I may well randomly generate structure offsets and such at build time to make sure nothing does. String encodings will be dynamically loadable. I'm going to add documentation for those ops in soon. (I was hoping today or tomorrow, but things are kinda screwy here at the moment) Simon just said the opposite. Does this mean that the C and Unicode encodings will be built-in and everything else dynamically loadable? No, it means Simon and I haven't talked this out yet. All string libraries will be potentially dynamically loaded. You'll probably get one or two built in. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Parrot demo at tonight's Boston perlmonger meeting is *off*
Folks, If anyone was planning to go to the Boston perlmongers meeting to see the parrot demo, be aware that the meeting has been cancelled. We'll try again at the next meeting. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
