Re: [PATCH] RCS Ids + capitalization + genclass.pl lib
At 01:10 PM 1/2/2002 -0800, Steve Fink wrote: >Small cleanup patch: Applied, thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] "chartypes/unicode.c": warning: improper pointer/integer combination
At 01:58 PM 1/2/2002 -0600, David M. Lloyd wrote: >Silences this warning. Applied, thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Automatic porting with register-based VMs?
At 11:10 PM 1/3/2002 -0500, Bryan C. Warnock wrote: >The other obvious answer is that we don't, because it's just to difficult, >if not impossible, to do, and do well. So is it worth the effort to pursue? FWIW, I've heard of at least one product out there that does this, though at the machine code level. (It'll turn your x86 binaries to Alpha ones, for example) It's supposed to do some optimizations as it goes, and there were reports of x86->other->x86 translations ending up with code that was faster than the original. Still, Brian's original point was well taken--there's a lot more to a machine than just its CPU. The hardware and OS are darned important too, and much tougher to emulate. (Not that I'd mind someone whipping up an Atari 800 emulator--I'd have to dig out the old M.U.L.E. and Archon disks) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: TODOs for STRINGs
At 07:42 PM 1/2/2002 +, Tom Hughes wrote: >In message <20020102054642$[EMAIL PROTECTED]> > "David & Lisa Jacobs" <[EMAIL PROTECTED]> wrote: > > > Here is a short list of TODOs that I came up with for STRINGs. First, do > > these look good to people? And second, what is the preferred method for > > keeping track of these (patch to the TODO file, entries in bug tracking > > system, mailing list, etc. > > > > * Add set ops that are encoding aware (e.g., set S0, "something", > "unicode", > > "utf-8")? > >You can already have Unicode constants by prefixing the string >with a U character. I seem to recall Dan saying that he didn't want >to allow constants in arbitrary encodings but instead would prefer >just to have native and unicode. I'm of two minds on arbitrary encoding constants. Practically speaking, though, we ought to have some way of doing them, though that'll make the bytecode segments a bit more complex. > > * Add transcoding ops (this might be a specific case of the previous e.g., > > set S0, S1, "unicode", "utf-16") > >I'm not sure whether this is needed. I think the idea is that in >general transcoding will happen at I/O time, presumably by pushing >a transcoding module on the I/O stack. I can see the need to explicitly transcode strings. We should have a transcode op for this, I think. > > * Move like encoded string comparison into encodings (i.e., the STRING > > comparison function gets the strings into the same encoding and then calls > > out to the encodings comparison function - This will allow each encoding to > > optimize its comparison. > >The problem with this is that string comparison depends on both the >encoding and the character set so in general you can't do this. If >the character set was the same for both strings then you could do so >though. > >What I did think about was having a flag on each encoding that >specified whether or not comparisons for that encoding could be >done using memcmp() when the character sets were the same. That >is true for things like the single byte encoding, but probably >not for the unicode encodings due to canonicalisation issues. It's also not true for Unicode because there are several different ways to sort Unicode strings, and most of them don't have anything to do with the order of the characters in the character set. (Granted you don't need this for eq/ne, though there are normalization issues there, but you do for cmp style comparisons) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH Miniperl::Tokenizer] Shut up warning in test
At 07:38 AM 1/2/2002 +, Jonathan Stowe wrote: >This quietens a warning in the Tokenizer test: Applied, thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [patch/RT#193] - Fix non-shared linking
At 12:00 AM 1/2/2002 -0500, Josh Wilmes wrote: >This patch changes the makefiles to call LD rather than CC where >appropriate. Applied, thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Automatic porting with register-based VMs?
Wow, thanks for that excellent anaylsis of the problem. On the point about the data and OS calls: You could potentially get around that by also converting the system-call machine code into byte-code as well, in which case your program may end up emulating some of the OS (which may fiddle with interupts and other things you are usually not supposed to touch). In the extreme case you could convert the entire OS to byte code. However, its not a very practical thing to do. As you noted, it would probably be better to try to figure out what to do with the system calls...in which case you could probably use one of the higher-level languages that do this sort of thing (convert a disk access system call into a perl or python call for the same thing). The many-to-one problem would probably involve a lot of special cases...possibly too many to actually be implementable. Very fun to think about though. :) -Paul B > -Original Message- > From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 03, 2002 11:11 PM > To: Paul Baranowski > Cc: [EMAIL PROTECTED] > Subject: Re: Automatic porting with register-based VMs? > > > On Thursday 03 January 2002 08:40 pm, Paul Baranowski wrote: > > Hi - > > I love what you guys are doing with Parrot. I was just recently > > wondering if it would be possible to transform a program > compiled down > > to machine language into byte-code, thereby automatically > porting any > > app to any other machine (at least any statically-compiled > app). Does > > anyone see any technical problems in doing this? > > Let's tackle the difficulties in order. (I apologize if this > will seem > flippant. Not the intention.) > > First, we need to be able to read the program format: ELF, > dwarf, .exe, > what-have-you. This is relatively clear-cut - a lot of > metadata, your > different segments, etc. Some of the info may not be > pertinent, some may > not map well. We'll assume we find a valid use for what we > have, and that > we can produce anything we need. (After all, it had to have > been producable > at some point.) > > Next, we need to understand the program inside the program - > the opcode > instructions. This is mostly straightforward. This code is this > instruction, these two are its arguments (which are these), > so on and so > forth. We should be able to figure out what operations are > occuring on what > data with relative ease. > > Now, we have to figure out the semantics of those operations. > Some of them > are quite obvious - when we divide an integer by an integer, > we are going to > get an integer back. Some aren't. When we make the system > call "fstat", > for instance, what exactly does that mean? > > Plus, we have to figure out what the data means. Is this a > path? Do we > need to change the path delimiter? Does the path refer to an > absolute > location - /home - or some effective location - the home > directories? This > is largely up to the programmer for providing portable, > consistent data, so > we shall not address it. Data is *always* the scourge of portability. > > Let's assume that we've got some reasonable results from the > above steps, > and we're ready to port to our byte-code model. Working in > reverse order, we need to make sure that we can reproduce the > semantics of the program. > Does this mean that we need to call the system call "fstat", and use > whatever it decides to return? What if it doesn't exist? What about > interpreting the results so that the remaining semantics stay > true to the > original program's intent? Does it mean that we need to > convert to bytecode > that retrieves the stat info, no matter how that may be, so > that we may > preserve the semantics directly? What of information that may not be > applicable from one platform to the next? > > It's safe to assume that opcodes are not going to map > one-to-one. So we now > need to take the opcode stream, with all its arguments and > semantics, and > map them somehow onto bytecode. This part should be relatively > straight-forward, assuming that everything is mappable. > However, there are > bound to be some sticky parts. What about op-and-a-half ops? > (Bytecode > that does slightly more than one native op, and slightly less > than two.) Do > argument sizes need to come into play? > > Now, you need to reassemble your mapped bytecode to a format > the interpreter > can read. Maybe some fixup stuff. Maybe just some packing > things in there. Presto. If you're successful, you've a > portable program. > > But let's think about this a little further. If you're able > to deconstruct > problems 1, 2, and 3 for a particular platform, should you be able to > construct the reverse for the same? It should be an issue of > one-to-many > mappings not being inversible, because you don't need to find > *the* original > program, simply one of the m
Re: [patch] more warnings
At 08:20 PM 1/1/2002 -0500, Kevin Falcone wrote: >In an attempt to just keep knocking off warnings.. Applied, thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] Let the world know about the JIT...
The enclosed patch brings the list of documentation in parrot.pod up to date. Simon --- parrot.pod.old Sat Dec 8 21:24:15 2001 +++ parrot.pod Fri Jan 4 16:44:02 2002 @@ -36,6 +36,10 @@ Describes what PMCs are and how they work. +=item F + +A brief description of Parrot's Just-In-Time compiler. + =item F The Parrot bytecode format.
Re: [PATCH] Let the world know about the JIT...
At 04:47 PM 1/4/2002 +, Simon Glover wrote: > The enclosed patch brings the list of documentation in parrot.pod > up to date. Applied, thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Current Makefile.pl fails on Win32
C:\home\parrot>perl configure.pl --defaults Parrot Version 0.0.3 Configure Copyright (C) 2001-2002 Yet Another Society Since you're running this script, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking the MANIFEST to make sure you have a complete Parrot kit... Okay, we found everything. Next you'll need to answer a few questions about your system. Rules are the same as Perl 5's Configure--defaults are in square brackets, and you can hit enter to accept them. Determining if your C compiler is actually gcc (this could take a while): test_gnuc.c LINK : fatal error LNK1149: Output filename identical to input filename "C:\home\parrot\test_siz.exe" identical C compiler died! at configure.pl line 696. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Re: Current Makefile.pl fails on Win32
At 06:06 PM 1/4/2002 +0100, Sebastian Bergmann wrote: >test_gnuc.c >LINK : fatal error LNK1149: Output filename identical to input filename >"C:\home\parrot\test_siz.exe" identical >C compiler died! at configure.pl line 696. Gah. Visual studio, right? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Current Makefile.pl fails on Win32
Dan Sugalski wrote: > Gah. Visual studio, right? Right. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Re: Current Makefile.pl fails on Win32
At 06:29 PM 1/4/2002 +0100, Sebastian Bergmann wrote: >Dan Sugalski wrote: > > Gah. Visual studio, right? > > Right. Okay, the problem is in the compiletestc in Configure.pl. Unfortunately I'm not sure what's proper for this. If you could, take a look at hints/vms.pl for how to override the default compiletestc sub and add an override to hints/mswin32.pl? Or pass on the compile and link command lines that're appropriate here and I'll wedge it in myself as best I can. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Current Makefile.pl fails on Win32
Dan Sugalski wrote: > not sure what's proper for this. If you could, take a look at > hints/vms.pl for how to override the default compiletestc sub and add > an override to hints/mswin32.pl? Or pass on the compile and link > command lines that're appropriate here and I'll wedge it in myself as > best I can. Sorry, I currently don't have time to look at this. Gotta run... -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Re: Automatic porting with register-based VMs?
On Thu, Jan 03, 2002 at 11:10:56PM -0500, Bryan C. Warnock wrote: > On Thursday 03 January 2002 08:40 pm, Paul Baranowski wrote: > > Hi - > > I love what you guys are doing with Parrot. I was just recently > > wondering if it would be possible to transform a program compiled down > > to machine language into byte-code, thereby automatically porting any > > app to any other machine (at least any statically-compiled app). Does > > anyone see any technical problems in doing this? > > Let's tackle the difficulties in order. (I apologize if this will seem > flippant. Not the intention.) I vote for a link to this response be placed in the FAQ.
Re: Current Makefile.pl fails on Win32
> Okay, the problem is in the compiletestc in Configure.pl. Unfortunately I'm > not sure what's proper for this. If you could, take a look at hints/vms.pl > for how to override the default compiletestc sub and add an override to > hints/mswin32.pl? Or pass on the compile and link command lines that're > appropriate here and I'll wedge it in myself as best I can. Overriding compiletestc would have fixed Configure.pl but there was still a bunch of Makefile issues. The problem is that gcc uses the same option (-o) to specify the name for both an object and executable file and ld also uses the same option. On Win32, all three are different. So instead of just using the ld_out option, I added cc_o_out and cc_exe_out options. In Configure.pl, they're all set to '-o ' but in mswin32.pl they're set to the appropriate strings for that platform. I had to modify a few of the Makefile.in files to use the correctly named options. None of the other hint files set the ld_out option so I'm assuming that they can all use the defaults of '-o '. The attached patch builds for me on Win32. After applying it, re-Configure.pl and make to see if I screwed up the Unix builds. Jason. out.patch Description: Binary data
Re: Current Makefile.pl fails on Win32
On Fri, 4 Jan 2002, Jason Diamond wrote: > > Okay, the problem is in the compiletestc in Configure.pl. Unfortunately > I'm > > not sure what's proper for this. If you could, take a look at hints/vms.pl > > for how to override the default compiletestc sub and add an override to > > hints/mswin32.pl? Or pass on the compile and link command lines that're > > appropriate here and I'll wedge it in myself as best I can. > > Overriding compiletestc would have fixed Configure.pl but there was still a > bunch of Makefile issues. The problem is that gcc uses the same option (-o) > to specify the name for both an object and executable file and ld also uses > the same option. On Win32, all three are different. So instead of just using > the ld_out option, I added cc_o_out and cc_exe_out options. In Configure.pl, > they're all set to '-o ' but in mswin32.pl they're set to the appropriate > strings for that platform. I had to modify a few of the Makefile.in files to > use the correctly named options. None of the other hint files set the ld_out > option so I'm assuming that they can all use the defaults of '-o '. > > The attached patch builds for me on Win32. After applying it, > re-Configure.pl and make to see if I screwed up the Unix builds. I don't know if this is related, but about an hour or two ago someone committed something that caused 'make' to not include 'CFLAGS' in the link phase, which causes 64-bit Solaris to not build properly. Should I be setting an additional thingy in my Configure line now, or is this a bug? - D <[EMAIL PROTECTED]>
Re: Current Makefile.pl fails on Win32
At 12:25 PM 1/4/2002 -0600, David M. Lloyd wrote: >I don't know if this is related, but about an hour or two ago someone >committed something that caused 'make' to not include 'CFLAGS' in the >link phase, which causes 64-bit Solaris to not build properly. Should I >be setting an additional thingy in my Configure line now, or is this a >bug? That'd be me, and probably a bug. Let me dig out why and see what needs fixing. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Current Makefile.pl fails on Win32
At 10:19 AM 1/4/2002 -0800, Jason Diamond wrote: >The attached patch builds for me on Win32. After applying it, >re-Configure.pl and make to see if I screwed up the Unix builds. Works on Cygwin. Applied, thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Current Makefile.pl fails on Win32
At 12:25 PM 1/4/2002 -0600, David M. Lloyd wrote: >I don't know if this is related, but about an hour or two ago someone >committed something that caused 'make' to not include 'CFLAGS' in the >link phase, which causes 64-bit Solaris to not build properly. Should I >be setting an additional thingy in my Configure line now, or is this a >bug? Okay, this is semi-intentional. Link flag are separate from compile flags. For the moment stick them in the libraries section, and I'll patch up configure to prompt for real linker flags. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Link options added
Okay, I just added a separate link options question and associated makefile
twiddlings to configure.pl. Any link-specific options you need can now go
there, or get jammed into $c{ldflags} if you need platform-specific bits.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
[PATCH] PerlUndef PMC methods
This makes PerlUndef somewhat functional by adding logical,
arithmetic, and repeat methods.
Index: global_setup.c
===
RCS file: /home/perlcvs/parrot/global_setup.c,v
retrieving revision 1.12
diff -u -r1.12 global_setup.c
--- global_setup.c 1 Jan 2002 03:46:40 - 1.12
+++ global_setup.c 4 Jan 2002 18:59:12 -
@@ -25,6 +25,7 @@
string_init(); /* Set up the string subsystem */
/* Call base vtable class constructor methods! */
+Parrot_PerlUndef_class_init();
Parrot_PerlInt_class_init();
Parrot_PerlNum_class_init();
Parrot_PerlString_class_init();
Index: classes/perlundef.pmc
===
RCS file: /home/perlcvs/parrot/classes/perlundef.pmc,v
retrieving revision 1.2
diff -u -r1.2 perlundef.pmc
--- classes/perlundef.pmc 18 Dec 2001 07:05:00 - 1.2
+++ classes/perlundef.pmc 4 Jan 2002 18:59:12 -
@@ -59,7 +59,7 @@
}
STRING* get_string () {
- return NULL;
+ return string_make(INTERP,NULL,0,NULL,0,NULL);
}
STRING* get_string_index (INTVAL index) {
@@ -154,75 +154,139 @@
}
void add (PMC * value, PMC* dest) {
+if(value->vtable == &Parrot_base_vtables[enum_class_PerlUndef]) {
+ dest->vtable->set_integer_native(INTERP, dest, 0);
+ }
+else if(value->vtable == &Parrot_base_vtables[enum_class_PerlInt]) {
+ dest->vtable->set_integer(INTERP, dest, value);
+ }
+ else {
+ dest->vtable->set_number(INTERP, dest, value);
+ }
}
void add_int (INTVAL value, PMC* dest) {
+ dest->vtable->set_integer_native(INTERP, dest, value);
}
void add_bigint (BIGINT value, PMC* dest) {
}
void add_float (FLOATVAL value, PMC* dest) {
+ dest->vtable->set_number_native(INTERP, dest, value);
}
void add_bigfloat (BIGFLOAT value, PMC* dest) {
}
void add_same (PMC * value, PMC* dest) {
+ dest->vtable->set_integer_native(INTERP, dest, 0);
}
void subtract (PMC * value, PMC* dest) {
+if(value->vtable == &Parrot_base_vtables[enum_class_PerlUndef]) {
+ dest->vtable->set_integer_native(INTERP, dest, 0);
+ }
+else if(value->vtable == &Parrot_base_vtables[enum_class_PerlInt]) {
+ dest->vtable->set_integer_native(INTERP, dest,
+ -value->vtable->get_integer(INTERP, value));
+ }
+ else {
+ dest->vtable->set_number_native(INTERP, dest,
+ -value->vtable->get_number(INTERP, value));
+ }
}
void subtract_int (INTVAL value, PMC* dest) {
+ dest->vtable->set_integer_native(INTERP, dest, -value);
}
void subtract_bigint (BIGINT value, PMC* dest) {
}
void subtract_float (FLOATVAL value, PMC* dest) {
+ dest->vtable->set_number_native(INTERP, dest, -value);
}
void subtract_bigfloat (BIGFLOAT value, PMC* dest) {
}
void subtract_same (PMC * value, PMC* dest) {
+ dest->vtable->set_integer_native(INTERP, dest, 0);
}
void multiply (PMC * value, PMC* dest) {
+ dest->vtable->set_integer_native(INTERP, dest, 0);
}
void multiply_int (INTVAL value, PMC* dest) {
+ dest->vtable->set_integer_native(INTERP, dest, 0);
}
void multiply_bigint (BIGINT value, PMC* dest) {
+ dest->vtable->set_integer_native(INTERP, dest, 0);
}
void multiply_float (FLOATVAL value, PMC* dest) {
+ dest->vtable->set_integer_native(INTERP, dest, 0);
}
void multiply_bigfloat (BIGFLOAT value, PMC* dest) {
+ dest->vtable->set_integer_native(INTERP, dest, 0);
}
void multiply_same (PMC * value, PMC* dest) {
+ dest->vtable->set_integer_native(INTERP, dest, 0);
}
void divide (PMC * value, PMC* dest) {
+ if(value->vtable == &Parrot_base_vtables[enum_class_PerlUndef]) {
+ fprintf(stderr, "division by zero!\n");
+ exit(1);
+ }
+ else if(value->vtable == &Parrot_base_vtables[enum_class_PerlInt]) {
+ if(value->vtable->get_integer(INTERP, value) == 0) {
+ fprintf(stderr, "division by zero!\n");
+ exit(1);
+ }
+ }
+ else if(value->vtable->get_number(INTERP, value) == 0) {
+ fprintf(stderr, "division by zero!\n");
+ exit(1);
+ }
+
+ dest->vtable->set_integer_native(INTERP, dest, 0);
}
void divide_int (INTVAL value, PMC* dest) {
+ if(value == 0) {
+ fprintf(stderr, "division by zero!\n");
+ exit(1);
+ }
+ dest->vtable->set_integer_native(INTERP, dest, 0);
}
void divide_bigint (BIGINT value, PMC* dest) {
+ /* need test for value == 0 */
+ dest->vtable->set_integer_native(INTERP, dest, 0);
}
void divide_float (FLOATVAL value, PMC* dest)
Re: [PATCH] PerlUndef PMC methods
On Fri, Jan 04, 2002 at 02:57:29PM -0500, Jason Gloudon wrote:
> This makes PerlUndef somewhat functional by adding logical,
> arithmetic, and repeat methods.
Cool, thanks.
> STRING* get_string () {
> - return NULL;
> + return string_make(INTERP,NULL,0,NULL,0,NULL);
> }
I did this as essentially an assertion, to make sure that people
check string pointers before merrily derefering them. Everything
ought to be able to cope with NULL strings.
> void add_same (PMC * value, PMC* dest) {
> + dest->vtable->set_integer_native(INTERP, dest, 0);
> }
Adding undef to undef? Why bother? :)
--
I decided to spread the bad mood: Dress To Depress.
- Red Drag Diva
Re: [PATCH] PerlUndef PMC methods
At 08:06 PM 1/4/2002 +, Simon Cozens wrote:
>On Fri, Jan 04, 2002 at 02:57:29PM -0500, Jason Gloudon wrote:
> > This makes PerlUndef somewhat functional by adding logical,
> > arithmetic, and repeat methods.
>
>Cool, thanks.
Want to apply the bits you want, then? Or shall I commit the whole thing?
> > STRING* get_string () {
> > - return NULL;
> > + return string_make(INTERP,NULL,0,NULL,0,NULL);
> > }
>
>I did this as essentially an assertion, to make sure that people
>check string pointers before merrily derefering them. Everything
>ought to be able to cope with NULL strings.
Which is a good point.
> > void add_same (PMC * value, PMC* dest) {
> > + dest->vtable->set_integer_native(INTERP, dest, 0);
> > }
>
>Adding undef to undef? Why bother? :)
Who needs to initialize variables anyway? :)
We need to add in some warning code, I think. I'll stub out an interface.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: [PATCH] PerlUndef PMC methods
On Fri, Jan 04, 2002 at 03:14:05PM -0500, Dan Sugalski wrote: > >Adding undef to undef? Why bother? :) > > Who needs to initialize variables anyway? :) > > We need to add in some warning code, I think. I'll stub out an interface. Exceptions of some kind would be nice too :) -- Jason
Re: Link options added
> Okay, I just added a separate link options question and associated
makefile
> twiddlings to configure.pl. Any link-specific options you need can now go
> there, or get jammed into $c{ldflags} if you need platform-specific bits.
Having the $c{ldflags} appear in compiletestc is showing warnings on Win32
since the linker flags mean nothing to the compiler. I'm assuming that's not
the case with gcc. It doesn't seem to have any adverse affect for now (aside
from the ugly warning messages) but there is a chance that some linker
option can mean something entirely different to the compiler in the future.
Would this be a good reason to override compiletestc in hints/mswin32.pl?
Looking at hints/vms.pl, I see that it overrode compiletestc so that it can
compile and link in two seperate steps. Could we do that for all platforms
in order to avoid overriding and duplicating code?
Jason.
Re: Link options added
At 01:33 PM 1/4/2002 -0800, Jason Diamond wrote:
> > Okay, I just added a separate link options question and associated
>makefile
> > twiddlings to configure.pl. Any link-specific options you need can now go
> > there, or get jammed into $c{ldflags} if you need platform-specific bits.
>
>Having the $c{ldflags} appear in compiletestc is showing warnings on Win32
>since the linker flags mean nothing to the compiler. I'm assuming that's not
>the case with gcc.
GCC plays the role of both compiler and linker. (Well, it compiles and
invokes ld under the hood, but it's all in one step) It can definitely
handle linker flags.
>It doesn't seem to have any adverse affect for now (aside
>from the ugly warning messages) but there is a chance that some linker
>option can mean something entirely different to the compiler in the future.
>Would this be a good reason to override compiletestc in hints/mswin32.pl?
Absolutely. I was surprised that all the Win32 C compilers would do the
single-step compile and link thing, honestly.
>Looking at hints/vms.pl, I see that it overrode compiletestc so that it can
>compile and link in two seperate steps. Could we do that for all platforms
>in order to avoid overriding and duplicating code?
We certainly could, though I'm not sure how much work it's worth, given
that at the moment it's just VMS and Win32 that do this.
On the other hand, patches are definitely welcome. :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Link options added
> GCC plays the role of both compiler and linker. (Well, it compiles and > invokes ld under the hood, but it's all in one step) It can definitely > handle linker flags. CL.exe does this, too. I just found out that you can specify link options if you include them after a /link option at the end of the command. cl /link If it works for GCC to have link options appear after the filename (I'd try it but I don't have cygwin installed here at work) then the attached patch might work without having to override anything. (It works for me.) Jason. ldflags.patch Description: Binary data
Re: Link options added
At 02:04 PM 1/4/2002 -0800, Jason Diamond wrote: >If it works for GCC to have link options appear after the filename (I'd try >it but I don't have cygwin installed here at work) then the attached patch >might work without having to override anything. (It works for me.) Works here. In, and thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
configuration and build tools: what's the plan?
Dan, back in Novemeber you mentioned talking with Eric Raymond about CML2 in the context of the configuration and build issues surrounding Parrot. What ever became of that? I've also been hearing the occassional peep about a soon to materialize make replacement. And mutterings related to autoconf, automake, and CONS... I am curious to hear who has been doing what, and in what general direction things are heading. Or is it too early to be asking such questions?
Re: Automatic porting with register-based VMs?
On Friday 04 January 2002 11:20 am, Dan Sugalski wrote: > At 11:10 PM 1/3/2002 -0500, Bryan C. Warnock wrote: > >The other obvious answer is that we don't, because it's just to > > difficult, if not impossible, to do, and do well. So is it worth the > > effort to pursue? > > FWIW, I've heard of at least one product out there that does this, though > at the machine code level. (It'll turn your x86 binaries to Alpha ones, > for example) It's supposed to do some optimizations as it goes, and there > were reports of x86->other->x86 translations ending up with code that was > faster than the original. I don't know if it was a Microsoft product, but it was for software for Windows NT on Alpha. Windows allowed the execution of x86 NT software on the Alphas, albeit at an even slower crawl than what they normally ran. This program was basically a JIT that would convert the x86 code to the corresponding Alpha code, and redirect future calls to that point. IIRC, I believe it may have even been able to freeze the Alpha code to disk, but it's been about five years since I looked at it. In either case, since it's usually the same threads that are constantly exercised, you'd get close to native speed for the application after a while. This largely worked because you were still targetting the same OS, so the issues with system calls and data were essentially a noop. > Still, Brian's original point was well taken--there's a lot more to a > machine than just its CPU. The hardware and OS are darned important too, > and much tougher to emulate. (Not that I'd mind someone whipping up an > Atari 800 emulator--I'd have to dig out the old M.U.L.E. and Archon > disks) Hmm, you don't google much, do you, Dan? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Automatic porting with register-based VMs?
At 06:45 PM 1/4/2002 -0500, Bryan C. Warnock wrote: >On Friday 04 January 2002 11:20 am, Dan Sugalski wrote: > > At 11:10 PM 1/3/2002 -0500, Bryan C. Warnock wrote: > > >The other obvious answer is that we don't, because it's just to > > > difficult, if not impossible, to do, and do well. So is it worth the > > > effort to pursue? > > > > FWIW, I've heard of at least one product out there that does this, though > > at the machine code level. (It'll turn your x86 binaries to Alpha ones, > > for example) It's supposed to do some optimizations as it goes, and there > > were reports of x86->other->x86 translations ending up with code that was > > faster than the original. > >I don't know if it was a Microsoft product, but it was for software for >Windows NT on Alpha. Windows allowed the execution of x86 NT software on >the Alphas, albeit at an even slower crawl than what they normally ran. FX!32, from Digital. It was really nice near the end, and was ultimately kinda speedy. There were also the VEST tools for moving from VMS on a VAX to VMS on Alphas that translated the machine code. >This largely worked because you were still targetting the same OS, so the >issues with system calls and data were essentially a noop. The tool I heard about doesn't do anything with system calls, so it'd still be a problem. For some programs that's still OK. (Assuming plain text mode stdio type things) A neat enough thing but of limited utility in many cases. > > Still, Brian's original point was well taken--there's a lot more to a > > machine than just its CPU. The hardware and OS are darned important too, > > and much tougher to emulate. (Not that I'd mind someone whipping up an > > Atari 800 emulator--I'd have to dig out the old M.U.L.E. and Archon > > disks) > >Hmm, you don't google much, do you, Dan? Of course not. (Nor do I spell your name right much, apparently) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
prederef problem
Gregor,
You've got a disaster waiting to happen when sizeof(pointer) !=
sizeof(opcode). (64 bit/32 bit mix would be valid.)
interpreter.c, line 204:
static void **
prederef(void ** pc_prederef, struct Parrot_Interp * interpreter)
{
size_t offset = pc_prederef - interpreter->prederef_code;
opcode_t * pc = ((opcode_t *)interpreter->code->byte_code) + offset;
I'm not sure to what extent this problem reaches, or how you want to
approach this, so I've no quick patch, sorry.
--
Bryan C. Warnock
[EMAIL PROTECTED]
[PATCH] Nothing Compares 2 UINT
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.51
diff -u -r1.51 interpreter.c
--- interpreter.c 4 Jan 2002 03:37:43 - 1.51
+++ interpreter.c 5 Jan 2002 02:47:40 -
@@ -62,7 +62,7 @@
runops_generic (opcode_t * (*core)(struct Parrot_Interp *, opcode_t *),
struct Parrot_Interp *interpreter, opcode_t * pc) {
opcode_t * code_start;
-INTVAL code_size;
+UINTVALcode_size;
opcode_t * code_end;
check_fingerprint(interpreter);
@@ -273,7 +273,7 @@
runops_jit (struct Parrot_Interp *interpreter, opcode_t * pc) {
#ifdef HAS_JIT
opcode_t * code_start;
-INTVAL code_size;
+UINTVALcode_size;
opcode_t * code_end;
jit_f jit_code;
@@ -285,9 +285,9 @@
jit_code = build_asm(interpreter, pc, code_start, code_end);
(jit_code)();
-#else
-return;
#endif
+return;
+
}
@@ -297,7 +297,7 @@
runops_prederef (struct Parrot_Interp *interpreter, opcode_t * pc,
void ** pc_prederef) {
opcode_t * code_start;
-INTVAL code_size;
+UINTVALcode_size;
opcode_t * code_end;
void **code_start_prederef;
@@ -416,7 +416,7 @@
make_interpreter(INTVAL flags) {
struct Parrot_Interp *interpreter;
/* Get an empty interpreter from system memory */
-interpreter = mem_sys_allocate((INTVAL)sizeof(struct Parrot_Interp));
+interpreter = mem_sys_allocate((UINTVAL)sizeof(struct Parrot_Interp));
/* Set up the memory allocation system */
mem_setup_allocator(interpreter);
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: [PATCH] Nothing Compares 2 UINT
At 09:50 PM 1/4/2002 -0500, Bryan C. Warnock wrote: >Index: interpreter.c Applied, thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] It's a trick, sir...
On Mon, Dec 31, 2001 at 10:57:54PM -0500, Bryan C. Warnock wrote:
> ...there's *two* of them!
My very first ever attempt at obfuscated code circa 1997.
#!/usr/lib/perl -w
use strict;
eval unpack('u*', <<'JOKE');
M;7D@0'-I>F5S(#T@<72UO;F4@2US:7@*"2`@9FEV92UH=6YD2`Dhttp://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
and I pull out the Magnum from under the desk where I keep it in case
someone laughs at a joke that's so dry it's got a built in
water-fountain, and blow the lot of them away as a community Service.
-- BOFH
Question about INTVAL vs. opcode_t sizes
I'm getting warnings on this bit of core.ops when compiling with 64-bit
ints:
op write(i|ic, i|ic) {
INTVAL * i = &($2); /* */
write($1, i, sizeof(INTVAL));
goto NEXT();
}
I'm getting a warning that stems from the fact that sizeof(INTVAL) = 8 and
sizeof(opcode_t) = 4, so the pointer assignment (marked by the arrow) is
not valid/safe (unless I'm missing something). Specifically, this applies
to the (i|ic, ic) forms of this op.
It'd probably be safer to do something like this:
op write(i|ic, i|ic) {
INTVAL i = (INTVAL)$2;
write($1, &i, sizeof(INTVAL));
goto NEXT();
}
So that you can use constants that are up to sizeof(opcode_t) bytes, but
after that you're on your own. That raises a question, though: Do we
want to move integer constants into the constant table?
- D
<[EMAIL PROTECTED]>
Re: Question about INTVAL vs. opcode_t sizes
On Friday 04 January 2002 10:43 pm, David M. Lloyd wrote: > > So that you can use constants that are up to sizeof(opcode_t) bytes, but > after that you're on your own. That raises a question, though: Do we > want to move integer constants into the constant table? We're guaranteeing 32 bits of inline integer arguments. If integers (or/and) opcodes are 64 bits, we're only guaranteeing the LS 32 bits. Anything larger needs to be a PMC. There's a discussion about this at http:[EMAIL PROTECTED]/msg05299.html -- Bryan C. Warnock [EMAIL PROTECTED]
[PATCH] Re: Question about INTVAL vs. opcode_t sizes
On Fri, 4 Jan 2002, Bryan C. Warnock wrote:
> On Friday 04 January 2002 10:43 pm, David M. Lloyd wrote:
> >
> > So that you can use constants that are up to sizeof(opcode_t) bytes, but
> > after that you're on your own. That raises a question, though: Do we
> > want to move integer constants into the constant table?
>
> We're guaranteeing 32 bits of inline integer arguments. If integers
> (or/and) opcodes are 64 bits, we're only guaranteeing the LS 32 bits.
> Anything larger needs to be a PMC.
That's what I thought I remembered; in that case, here's a patch:
Index: core.ops
===
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.68
diff -u -r1.68 core.ops
--- core.ops4 Jan 2002 02:36:25 - 1.68
+++ core.ops5 Jan 2002 03:58:14 -
@@ -463,8 +463,8 @@
=cut
op write(i|ic, i|ic) {
- INTVAL * i = &($2);
- write($1, i, sizeof(INTVAL));
+ INTVAL i = (INTVAL)$2;
+ write($1, &i, sizeof(INTVAL));
goto NEXT();
}
- D
<[EMAIL PROTECTED]>
[COMMIT] PerlHash class added.
Sample: new P0,PerlHash set P0,-6,"foo" # Store the value -6 in key 'foo' of the hash P0 set I0,P0,"foo" # Recover the value at "foo" No work has yet been done on hash collision, and behavior for undefined hash keys is not yet decided upon. -- Jeff <[EMAIL PROTECTED]>
RE: [PATCH] It's a trick, sir...
Michael G Schwern: # On Mon, Dec 31, 2001 at 10:57:54PM -0500, Bryan C. Warnock wrote: # > ...there's *two* of them! # # My very first ever attempt at obfuscated code circa 1997. ROFL. Schwern, only you are weird enough to have written that... ;^) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 "Nothing important happened today." --George III of England's diary entry for 4-Jul-1776
Uh-oh! (New perlhash stuff)
Parrot Version 0.0.3 Configure Copyright (C) 2001-2002 Yet Another Society Since you're running this script, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking the MANIFEST to make sure you have a complete Parrot kit... No such file: classes/perlhash.pmc Ack, some files were missing! I can't continue running without everything here. Please try to find the above files and then try running Configure again. - D <[EMAIL PROTECTED]>
RE: [COMMIT] PerlHash class added.
Jeff G:
# new P0,PerlHash
# set P0,-6,"foo" # Store the value -6 in key 'foo' of the hash P0
# set I0,P0,"foo" # Recover the value at "foo"
How do you do these?
P1=P0{foo}
P0{foo}=P1
I think you're going to need retrieve and store ops:
retrieve P1, P0, "foo"
store P0, "foo", P1
And no, you can't just figure it out by the position of the string
parameter:
set P1, P0, "foo" #ok
set P0, "foo", P1 #ok
set P0, P1, P2 #huh?
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
"Nothing important happened today."
--George III of England's diary entry for 4-Jul-1776
Re: prederef problem
Bryan --
Thanks for the message.
> You've got a disaster waiting to happen when sizeof(pointer) !=
> sizeof(opcode). (64 bit/32 bit mix would be valid.)
My intent in allocating a second memory block as an array of (void *) was
to make sure that I handled this case, even though it does not occur on my
setup.
You point out a place where I'm trying to resynch pc (which points into
real bytecode) with pc_prederef (which points into the array of void *s):
> interpreter.c, line 204:
>
> static void **
> prederef(void ** pc_prederef, struct Parrot_Interp * interpreter)
> {
> size_t offset = pc_prederef - interpreter->prederef_code;
> opcode_t * pc = ((opcode_t *)interpreter->code->byte_code) + offset;
This is supposed to be calculating offset = # opcodes not # bytes.
I didn't look it up, and I don't do lots of address arithmetic code,
but I assumed that pointer differences give offsets that can be passed
into array indexing / pointer arithmetic to get back where I want. If
its giving the *byte* difference, then most definitely this code doesn't
DWIM and offset needs to be divided by a sizeof(void *) factor.
> I'm not sure to what extent this problem reaches, or how you want to
> approach this, so I've no quick patch, sorry.
I don't recall doing such pointer mucking anywhere else but at this
point in the code.
Regards,
-- Gregor
RE: [COMMIT] PerlHash class added.
At 08:26 PM 1/4/2002 -0800, Brent Dax wrote:
>Jeff G:
># new P0,PerlHash
># set P0,-6,"foo" # Store the value -6 in key 'foo' of the hash P0
># set I0,P0,"foo" # Recover the value at "foo"
>
>How do you do these?
>
> P1=P0{foo}
> P0{foo}=P1
set P1, P0, ["foo"]
set P0, ["foo"], P1
is what I'm thinking at the moment. P1 has (or should have) a null key
which can be omitted if the syntax is clear to the assembler. (It's always
there for the bytecode)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: [PATCH] Re: Question about INTVAL vs. opcode_t sizes
At 09:59 PM 1/4/2002 -0600, David M. Lloyd wrote: >That's what I thought I remembered; in that case, here's a patch: Applied, thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: prederef problem
On Friday 04 January 2002 11:38 pm, Gregor N. Purdy wrote:
> You point out a place where I'm trying to resynch pc (which points into
>
> real bytecode) with pc_prederef (which points into the array of void *s):
> > interpreter.c, line 204:
> >
> > static void **
> > prederef(void ** pc_prederef, struct Parrot_Interp * interpreter)
> > {
> > size_t offset = pc_prederef - interpreter->prederef_code;
> > opcode_t * pc = ((opcode_t *)interpreter->code->byte_code) +
> > offset;
>
> This is supposed to be calculating offset = # opcodes not # bytes.
> I didn't look it up, and I don't do lots of address arithmetic code,
> but I assumed that pointer differences give offsets that can be passed
> into array indexing / pointer arithmetic to get back where I want.
Offsets are given in terms of the objects pointed to. In the above code,
you've two pointers to pointers, so the byte difference would be offset *
sizeof(void *). But then you add that offset to a pointer to an opcode_t,
so the byte difference would be offset * sizeof(opcode).
I didn't mean to be alarmist - if you've a one-to-one mapping between the
opcode_t stream and the corresponding void * stream, then you're safe, as
you're simply scaling the sizes.
But you may want to document that. It's quite scary looking on first
glance. :-)
--
Bryan C. Warnock
[EMAIL PROTECTED]
[patch] fake out vtable.h during Configure.pl
I'm fiddling with a compiler called tcc (i'll add it to tinderbox
shortly). It was complaining that struct _vtable was not completely
defined while building one of the test programs in Configure.pl. It was
right- at that point we generate an empty version of vtable.h, so this
struct isn't defined.
I've stuck in a dummy definition which allows it to get past that point:
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.71
diff -u -r1.71 Configure.pl
--- Configure.pl4 Jan 2002 22:13:58 - 1.71
+++ Configure.pl5 Jan 2002 05:58:01 -
@@ -499,6 +499,7 @@
my %newc;
open NEEDED, ">include/parrot/vtable.h";
+print NEEDED "/* dummy */ struct _vtable { int a; };\n";
close NEEDED;
buildfile("testparrotsizes_c");
compiletestc("testparrotsizes");
lcc and tcc added
I've added two more entries to the tinderbox. Both are on linux. Both are not successfully building at the moment. lcc: http://www.cs.princeton.edu/software/lcc/ lcc has been discussed before on this list- it's a fairly picky ANSI C compiler. tcc: http://www.cse.unsw.edu.au/~patrykz/TenDRA/tcc/tcc1.html tcc is fairly interesting in that you can tell it to only provide a specific API to the compilation environment, as listed at http://www.cse.unsw.edu.au/~patrykz/TenDRA/tcc/tcc8.html#S54 This means that we could, in theory, test whether parrot will build in a variety of different environments on one machine. Right now that's not going to work since so many hints are coming from the existing perl install. So i've told it to provide the full set up system headers so that it will match those assumptions for now. But once parrot does its own checking for such things, it may be interesting to try this out. I'm not too clear on how well it would actually work. Seems interesting in concept though. --Josh -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
[patch] ignore classes/*.h
Index: classes/.cvsignore === RCS file: /home/perlcvs/parrot/classes/.cvsignore,v retrieving revision 1.2 diff -u -r1.2 .cvsignore --- classes/.cvsignore 11 Dec 2001 12:03:23 - 1.2 +++ classes/.cvsignore 5 Jan 2002 06:29:23 - @@ -1,3 +1,3 @@ Makefile *.c -default.h +*.h
Failed tests (win32)
the pmc.t test 48 through 52 all fail. I've reported this two days ago as well, seems like it hasn't been fixed yet. nmake test also recompiles test_parrot.exe, so it's compiled once at nmake and again at nmake test. Ilya Sterin
