RE: Transcoding patch
At 07:03 PM 10/8/2001 -0500, Gibbs Tanton - tgibbs wrote: This looks good. Also, WRT the utf8_t, utf16_t, and utf32_t can we not just use utf32_t and then mask off the lower 8 or 16 bits? We can still have utf8_t be defined as char to allow sizeof to work right and we can do sizeof(utf8_t)*2 to get the utf16_t's size. utf8 and utf16 are both variable length encodings for space reasons. There's not much reason to space-compact something then expand the heck out of it. #I think he was just referring to the internal type used to hold a #character during processing, not to expanding the whole string. Yep, they would still be in UTF8 or UTF16 format internally, but I was trying to find a way were a 16 bit type was not needed as it might be hard to find on some systems. For that matter a 32 bit type can be hard to find on some systems. It seems we need one type and then some macros to fish out the other types. On the other hand, I'd really, *really* rather not have Unicode constants in anything other than UTF-32, so I'd as soon we chopped out the utf-8 and utf-16 constant support from this. A should be the prefix for US-ASCII characters. U should be the prefix for Unicode characters N should be the prefix for the native character set (and the default) Beyond that I'm not sure what, if anything, we should accommodate in the assembler. #What does US-ASCII correspond to internally - we don't have an #encoding for that. unless you're planning to mark it as UTF-8 and #rely on US-ASCII being a subset of UTF-8 of course ;-) Besides that, I'm not sure who would want to write a string in parrot assembly in iso latin 1 if it wasn't their native character set...seems like to me they would go straight to unicode. I can understand the need for native and U32, but I question the latin1 US-ASCII need. #The only oter thing is that writing tests for UTF-8 and UTF-16 strings #and the transcoder is going to be quite tricky if we can't generate #them using the assembler. Yeah, perhaps we could keep this in, but note that it will be removed in the future once our tests pass...however, it seems like this is something that we will want to put in the test harness, so it seems we would need UTF8 and UTF16 constants for that.
RE: String comparison ops
Question about the following code.
+INTVAL
+string_compare(STRING* s1, STRING* s2) {
+if (s1-encoding != s2-encoding) {
+if (s1-encoding-which != enc_utf32) {
+s1 = Parrot_transcode_table[s1-encoding-which][enc_utf32](s1,
NULL);
+}
+if (s2-encoding-which != enc_utf32) {
+s2 = Parrot_transcode_table[s2-encoding-which][enc_utf32](s2,
NULL);
+}
+}
+
+return (ENC_VTABLE(s1)-compare)(s1, s2);
+}
Does the call to the transcode function create a new string or change the
string in place. I don't think we want to pass in a native string only to
find out it is unicode after we get done comparing it.
-Original Message-
From: Tom Hughes
To: [EMAIL PROTECTED]
Sent: 10/9/2001 6:49 PM
Subject: String comparison ops
Attached is a patch to add string comparison ops, along with the
necessary infrastructure in the string code.
The current behaviour is that if the two strings do not have the
same encoding then both are promoted to UTF-32 before comparison
as that should generally preserve information.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
strcmp.patch
RE: Transcoding patch
Absolutely. A few other issues that I remembered last night are: - The current code assumes that the string data will be two byte aligned for UTF-16 and four byte aligned for UTF-32 which is probably reasonable but maybe not. Yeah, I think we can handle that in the constant section for constants. As for run-time generated strings, we can generate them to be aligned to whatever we want (assuming the underlying architecture allows it.) - The utf8_t, utf16_t and utf32_t types will need to be determined by configure as they will currently break on some machines. Plus machines without native 8, 16 and 32 bit types will be a problem. Almost all hardware should have char as an 8 bit type so that shouldn't be a problem. However, finding a 16 bit or 32 bit type might be a problem on some hardware. We might want to think about using arrays of 8 bit types or using bit fields. - There are byte ordering issues for UTF-16 and UTF-32 strings. The current code assumes host byte ordering but should we be spotting byte order markers in the strings and adjusting to cope? There are byte ordering issues for all of parrot. I assume we'll fix these when we fix the rest of parrot. A fundamental question (which I think Simon was hinting at with his cryptic comment) is whether the native encoding is fixed when parrot is built or can change on the fly as they user changes their locale settings. If it's the latter than conversion to and from native will have to work by loading an appropriate conversion table at run time. This could get interesting. I don't think it should be fixed when parrot is built, but should be gathered at initialization time. If the user wants to change his locale right in the middle of a parrot run, that is even more interesting and we would probably have to have an opcode that would go through each native string and change it to fit the new locale. Tanton
RE: Itanium still a little ill
Yeah, long double is going to break things because we are packing it into a double and then memcpying it out like it is a long double. The inconsistency is the problem. -Original Message- From: Brent Dax To: Perl 6 Internals Sent: 10/8/2001 1:36 PM Subject: Itanium still a little ill Moral of the story: long double breaks things for some reason. FYI, Itanium has 16-byte long doubles. Automated smoke report for patch Oct 8 07:00:01 2001 UTC v0.01 on linux using cc version 2.96-ia64-000717 snap 001117 O = OK F = Failure(s), extended report at the bottom ? = still running or test results not (yet) available Build failures during: - = unknown c = Configure, m = make, t = make test-prep Configuration --- --- - O O --defaults O O --defaults --define nv=double F F --defaults --define nv=\long double\ O O --defaults --define iv=long O O --defaults --define iv=long --define nv=double F F --defaults --define iv=long --define nv=\long double\ O O --defaults --define iv=\long long\ O O --defaults --define iv=\long long\ --define nv=double F F --defaults --define iv=\long long\ --define nv=\long double\ | | | +- --debugging +--- normal Failures: linux--defaults --define nv=\long double\ linux--debugging --defaults --define nv=\long double\ linux--defaults --define iv=long --define nv=\long double\ linux--debugging --defaults --define iv=long --define nv=\long double\ linux--defaults --define iv=\long long\ --define nv=\long double\ linux--debugging --defaults --define iv=\long long\ --define nv=\long double\ t/op/integerdubious DIED. FAILED test 25 --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: Itanium still a little ill
I think we can support it; whether we will or not is up to Dan and Simon. Either way, it is not ready yet. -Original Message- From: Brent Dax To: Gibbs Tanton - tgibbs; 'Perl 6 Internals ' Sent: 10/8/2001 2:11 PM Subject: RE: Itanium still a little ill Gibbs Tanton - tgibbs: # Yeah, long double is going to break things because we are # packing it into a # double and then memcpying it out like it is a long double. The # inconsistency is the problem. Does that mean we're not gonna support long double, or just that it isn't ready yet? --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: Itanium still a little ill
I should have waited :) -Original Message- From: Dan Sugalski To: Brent Dax; Gibbs Tanton - tgibbs; 'Perl 6 Internals ' Sent: 10/8/2001 2:11 PM Subject: RE: Itanium still a little ill At 12:11 PM 10/8/2001 -0700, Brent Dax wrote: Gibbs Tanton - tgibbs: # Yeah, long double is going to break things because we are # packing it into a # double and then memcpying it out like it is a long double. The # inconsistency is the problem. Does that mean we're not gonna support long double, or just that it isn't ready yet? It isn't ready yet. We will be supporting long doubles. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Transcoding patch
Thanks! Applied. -Original Message- From: Tom Hughes To: [EMAIL PROTECTED] Sent: 10/8/2001 6:51 PM Subject: RE: Transcoding patch In message [EMAIL PROTECTED] Gibbs Tanton - tgibbs [EMAIL PROTECTED] wrote: This is good, unless someone has objections I'll commit this. However, we also need the ability to do unicode in the assembler (I'll do this later today if no one beats me to it), and we need some way to communicate the encoding number between the C and the Perl code. The attached patch solves the assembler issue by allowing quoted strings to be prefixed with U8, U16 or U32 to indicate a unicode string of the appropriate type, so: set_s_sc S1, U8Hello World creates a UTF-8 string in S1 containg the specified data. I don't particularly like that syntax so if anybody has any better ideas then please say... Most of the patch is useful whatever the syntax though - it will just need tweaking to recognise the appropriate syntax. The patch also adds support for \x escapes in strings as it is difficult to write unicode string constants without that. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ utfstr.patch
RE: Transcoding patch
This is good, unless someone has objections I'll commit this. However, we also need the ability to do unicode in the assembler (I'll do this later today if no one beats me to it), and we need some way to communicate the encoding number between the C and the Perl code. I guess the question with native strings is will it always be ASCII or will it be Shift-JIS etc...? And the follow up to that is can, for the short term, we assume it will be ASCII and then improve our native string transcoding over time? Tanton -Original Message- From: Tom Hughes To: [EMAIL PROTECTED] Sent: 10/7/2001 10:23 AM Subject: Transcoding patch The attached patch is a first stab at implementing string transcoding and the unicode string types. The transcoder will currently only map one UTF type to another - there is no attempt to implement mapping to or from native strings as I wasn't sure what the plan was for that. Presumably we will have to determine what the native character set is at configure time and then generate some code to map between that and unicode somehow? There are currently no proper tests because there is no way to generate anything other than a native string using the current assembler. There is a small C test harness (trans-test.c) which I have used to validate the transcoder to a certain extent. This patch also fixes a bug in the existing native strings where string_native_compute_strlen was returning the number of bytes that had been allocated rather than the number that were in use. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ transcode.patch
RE: vtable.h
for add we will end up with void add( PMC* self, PMC* left, PMC* right ); does this represent: self = left + right or some other ordering? -Original Message- From: Simon Cozens To: [EMAIL PROTECTED] Sent: 10/6/2001 7:50 AM Subject: vtable.h I've just committed some files which generate vtable.h; these were actually left over from my experiments of a *long* time ago. [1] It might need quite a few changes, but it's a good start, and I think it's general enough to survive. The next thing I want to do with it is have something akin to process_op_func.pl which takes a macro-ized description of the vtable functions and turns them into real C code. Volunteers welcome, or I'll write it myself. :) This could be a good place, however, for newcomers to Parrot to get involved with something relatively straightforward but pretty crucial. Hint, hint... Simon [1] In short, back in the beginning, Dan and I independently started implementing Parrot; Dan's version was more complete and sensible by the time we got together to discuss it, so his became the codebase that was checked into CVS. Dan had started with the interpreter main loop and ops, and I had started with PMCs. -- Actually Perl *can* be a Bondage Discipline language but it's unique among such languages in that it lets you use safe words. -- Piers Cawley
RE: vtable.h
2 other things 1.) Will each different type of PMC have its own vtable, function definitions, etc or will they all share everything with switches on type in the function definitions. 2.) Can you give an idea of what you think the macro-ized function should look like (an example would be great.) Thanks! Tanton -Original Message- From: Simon Cozens To: [EMAIL PROTECTED] Sent: 10/6/2001 7:50 AM Subject: vtable.h I've just committed some files which generate vtable.h; these were actually left over from my experiments of a *long* time ago. [1] It might need quite a few changes, but it's a good start, and I think it's general enough to survive. The next thing I want to do with it is have something akin to process_op_func.pl which takes a macro-ized description of the vtable functions and turns them into real C code. Volunteers welcome, or I'll write it myself. :) This could be a good place, however, for newcomers to Parrot to get involved with something relatively straightforward but pretty crucial. Hint, hint... Simon [1] In short, back in the beginning, Dan and I independently started implementing Parrot; Dan's version was more complete and sensible by the time we got together to discuss it, so his became the codebase that was checked into CVS. Dan had started with the interpreter main loop and ops, and I had started with PMCs. -- Actually Perl *can* be a Bondage Discipline language but it's unique among such languages in that it lets you use safe words. -- Piers Cawley
RE: vtable.h
2.) Can you give an idea of what you think the macro-ized function should look like (an example would be great.) No, because then you'll go away and implement it, and I want to encourage some fresh blood to do that. :) Okey Dokey...I promise not to do it :) Seriously, before I do that, I need to seriously think about what vtable accessors ought to look like; (pmc1-vtable[want_vtbl_add])(pmc1, pmc2, pmc3) is going to scare people away quickly, and, while PMC_ADD(pmc1, pmc2, pmc3) s cute, (and allows us to autogenerate Parrot byte ops ;) Macro Hell is something we want to avoid. Well, you currently have vtable as a struct so you would say pmc1-vtable-add( pmc1, pmc2, pmc3 ) which doesn't look that bad. Really, I would imagine all of this would be autogenerated by process_opfunc.pl so it doesn't matter what the longhand looks like. We can use PMC_ADD in basic_opcodes.ops just like we use INT_CONST or whatever and the macro is stripped out of the perl. Also, how will adds of different types be handled. In the above if pmc2 is an int and pmc3 is a float we're going to have to know that and do a switch or something to convert to/create the right type. Tanton
RE: [PATCH] non-init var possibility
No, the behavior of malloc(0) is implementation defined.
-Original Message-
From: Bryan C. Warnock
To: [EMAIL PROTECTED]
Sent: 10/6/2001 12:43 PM
Subject: [PATCH] non-init var possibility
mask and max_to_alloc are unitialized if the size requested is less that
1.
(Which it could be, since INTVAL is signed.) Of course, if it happens,
you
should get what you deserve, but this at least horks them cleanly.
Creation of an UINTVAL (UNTVAL? :-) and subsequent patches will follow
pending feedback.
Is the behavior of malloc(0) consistent?
Index: memory.c
===
RCS file: /home/perlcvs/parrot/memory.c,v
retrieving revision 1.12
diff -u -r1.12 memory.c
--- memory.c2001/10/06 00:57:43 1.12
+++ memory.c2001/10/06 17:39:55
@@ -40,8 +40,8 @@
*/
void *
mem_allocate_aligned(INTVAL size) {
-ptrcast_t max_to_alloc;
-ptrcast_t mask;
+ptrcast_t max_to_alloc = 0;
+ptrcast_t mask = 0;
ptrcast_t i;
void *mem = NULL;
--
Bryan C. Warnock
[EMAIL PROTECTED]
RE: [PATCH] vtable.tbl: REGEX pointer
Thanks! Applied. -Original Message- From: Bryan C. Warnock To: [EMAIL PROTECTED] Sent: 10/6/2001 11:56 AM Subject: [PATCH] vtable.tbl: REGEX pointer Index: vtable.tbl === RCS file: /home/perlcvs/parrot/vtable.tbl,v retrieving revision 1.1 diff -u -r1.1 vtable.tbl --- vtable.tbl 2001/10/06 12:41:57 1.1 +++ vtable.tbl 2001/10/06 16:56:14 @@ -35,5 +35,5 @@ void logical_orPMC* leftPMC* right void logical_and PMC* leftPMC* right void logical_not PMC* left -void match PMC* leftREGEX re +void match PMC* leftREGEX* re void repeatPMC* leftPMC* right -- Bryan C. Warnock [EMAIL PROTECTED]
RE: More speed trials
I tried removing the bounds checking and adding multiple DO_OPs inside the while loop. with -O0 the loop unrolling helped, but removing the bounds checking actually slowed it down. With -O3, neither one helped at all.
RE: moving integer constants to the constant table
Bryan wrote -- The header portion may need some work I'm a little confused by what this means...is this something the patch can address? Tanton
[COMMIT] opcode_t cleanup and process_opfunc.pl cleanup
I have committed the two patches I posted recently. Unfortunately, I was stupid and forgot to do make before make test; therefore I thought it didn't work, freaked out, and undid the commit. Then, I figured out my mistake and recommitted the patch. Here are the comments from the cvs log This patch ensures that all bytecode is of type opcode_t except for the constant table constants. That means that almost all of the INTVALs in the code were replaced with opcode_t and the i pack type was replaced with the op pack type in calls to pack_arg and such. Also, since it has been declared that ALL integer constants are to be 32 bits, some test cases were changed to ensure that an integer constant was no bigger than 2 ** 31. process_opfunc.pl was also cleaned up to no longer look at either opcode_table or interp_guts.h but gather all of its information from Opcode.pm. The Assembler.pm module was changed to do late binding of arguments so that 0 could be treated like 0.0 without having to be so declared. Also, only strings now use the [sc:N] intermediate form as it was unneccesary for integer and float types. -- One thing I fogot to put in the log was that (INTVAL) casts of memory are now (ptrcast_t) which is typedefed in config.h to be size_t. If you have any problems with this patch let me know and I will revert (again). Tanton
PMC Questions
As 0.0.3 will be about PMC's, we might as well start hashing out the details. I'd like to take a small example and look at how it should work. add P1, P2, P3 This should take the PMC in register P2 and add it to the PMC in register P3 and store the result in register P1. To do this, it needs to call the add function in P2's vtable, correct? How will the interpreter know what entry has the add function. Will it directly mimic the main interpreter vtable? If so, it seems like an awful waste of space as the PMC might not overload but a couple of those functions (or does a PMC always have to overload all of the functions)? Also, what about GC. Will that come into play during 0.0.3? Thanks! Tanton
Cleanup
I've done some VERY minor cleanup of a couple of files, removing unused variables and such from Opcode.pm, removing an unused typedef print from make_op_header.pl and changing intval to op in disassemble.pl. I also fixed a typo I did in Assembler.pm. Tanton
RE: More speed trials
I think that changing from a function based implementation to a switch based implementation will help on many platforms. Someone did a patch on that, maybe we could update it and commit it. Having to go through two indirections and two array accesses to access a register probably doesn't help much either, although it won't be easy to get around that. Apart from that, there is not much else to be done. We can reprofile, but the only thing being executed are integer additions and comparisons...you can't get much more basic than that...and you are right, we are running much too slowly. Tanton -Original Message- From: Bryan C. Warnock To: [EMAIL PROTECTED] Sent: 10/5/2001 11:44 PM Subject: More speed trials Holding steady. As a lark, I wrote the functionality of test.pasm (the time test) in Perl, and ran it under 5.6.1. (Keep it mind, you've got variables that you're fetching and storing to.) Parrot Assembler (with the time_n patch, since the elapsed time is so small. The comma delimeters are mine): Iterations: 100,000,000 Start time: 1002342433.400218 End time: 1002342442.858994 Count: 100,000,000 Elapsed time:9.458776 Estimated ops:300,000,000 Ops/sec:31,716,577.291820 9.370u 0.010s 0:09.46 99.1% 0+0k 0+0io 173pf+0w Perl 5.6.1 Perl: Iterations: 100,000,000 Start time: 1002342340 End time: 1002342416 Count: 100,000,000 Elapsed time: 76 Estimated ops:300,000,000 Ops/sec: 3,947,368.42105263158 75.890u 0.020s 1:15.94 99.9%0+0k 0+0io 324pf+0w Now, if we actually count how many ops it really is: (-MO=Terse and test_prog -t) Parrot: 300,000,009 ops = 31,712,475 ops/sec Perl 5.6.1: 1,400,000,026 ops = 18,435,607 ops/sec You may draw your own conclusions. Mine is... we're not fast enough. -- Bryan C. Warnock [EMAIL PROTECTED]
replacing INTVAL in memory and register
INTVAL is used in memory and register to cast a pointer to an integer for mathematical operators. Instead of using INTVAL I propose we use ptrdiff_t or size_t (with my preference being the former). It would not be used anywhere else, just when we need to do mathematics on pointers. Both are given by the standard and both should be big enough to hold a pointer (although I think only ptrdiff_t is guarenteed to be so...it is a little fuzzy with size_t). Suggestions, comments, criticisms? Tanton
RE: replacing INTVAL in memory and register
My ANSI and ISO Standard C reference manual (Plauger and Brodie) has it listed in stddef.h with the comment: ptrdiff_t( which is the type of the subtract operator when its operands are both pointers to data objects ). Althought the book was written in 1989 I still think it applies. Tanton -Original Message- From: Bryan C. Warnock To: Gibbs Tanton - tgibbs; '[EMAIL PROTECTED]' Sent: 10/4/2001 9:41 AM Subject: Re: replacing INTVAL in memory and register On Thursday 04 October 2001 10:38 am, Gibbs Tanton - tgibbs wrote: INTVAL is used in memory and register to cast a pointer to an integer for mathematical operators. Instead of using INTVAL I propose we use ptrdiff_t or size_t (with my preference being the former). It would not be used anywhere else, just when we need to do mathematics on pointers. Both are given by the standard and both should be big enough to hold a pointer (although I think only ptrdiff_t is guarenteed to be so...it is a little fuzzy with size_t). Suggestions, comments, criticisms? Which standard? -- Bryan C. Warnock [EMAIL PROTECTED]
RE: moving integer constants to the constant table
Okey dokey...this patch is scratched; thanks for the feedback. However, I will probably issue another one soon that makes sure that intval is never used in the bytecode, only opcode_t. -Original Message- From: Dan Sugalski To: [EMAIL PROTECTED]; Gibbs Tanton - tgibbs; '[EMAIL PROTECTED] ' Sent: 10/4/2001 11:05 AM Subject: Re: moving integer constants to the constant table At 11:29 AM 10/4/2001 -0400, Bryan C. Warnock wrote: Just the fact that we needed this patch in the first place indicates that we're not doing *nearly* enough talking beforehand of some of the particulars of Dan's overall design. That's the thing, though--we *don't* need this patch, not for integer constants. It's actually detrimental to performance in many ways. Parrot guarantees you can embed 32-bit signed integer constants in the instruction stream, and that's it. These constants are used to load up integer registers, sure, but they're also used for jump offsets. Integer *variable* constants should go in the constant table. We don't have any of those yet, though. They come in with the PMC stuff. Which isn't to say the design shouldn't be worked over and talked about. It should, and it should get re-evaluated as we go along. (And all the code I write should probably ultimately be replaced with code that actually works... :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: moving integer constants to the constant table
This is what my initial patch addressed. If opcode_t is always 32 bits, but we allow the native integer type to be 64 bits, then we cannot have inlined integers. Instead, we have to move the integers out into the constant section. Therefore, it would seem that we must force sizeof( opcode_t) == sizeof( intval ) or do some chicanery with splitting the 64 bit integer up into two 32 bit integers, but that gets really ugly. -Original Message- From: Andy Dougherty To: Dan Sugalski Cc: [EMAIL PROTECTED] Sent: 10/4/2001 12:25 PM Subject: Re: moving integer constants to the constant table On Thu, 4 Oct 2001, Dan Sugalski wrote: Sort of. They're guaranteed to be as big as the native integer you've chosen to build Parrot with, and at least 32 bits. Ok, but does long long count as a native integer? Yup, if that's what you configured perl with. Ok, last question for today: Do we want to require sizeof(opcode_t) == sizeof(INTVAL)? A user may know he wants 'long long' integer constants, but also know that opcodes will always fit in 32-bits and want to use 'int' for opcode_t (for compactness and possibly speed). On the one hand, I could see allowing different sizes as a reasonable position. On the other hand, I could also see forbidding different sizes as a reasonable position. I don't have a gripping hand, so I don't see any other possibilities at the moment :-). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
RE: moving integer constants to the constant table
Ok, that makes sense. Thanks! -Original Message- From: Dan Sugalski To: Gibbs Tanton - tgibbs; 'Andy Dougherty ' Cc: '[EMAIL PROTECTED] ' Sent: 10/4/2001 12:52 PM Subject: RE: moving integer constants to the constant table At 12:48 PM 10/4/2001 -0500, Gibbs Tanton - tgibbs wrote: This is what my initial patch addressed. If opcode_t is always 32 bits, but we allow the native integer type to be 64 bits, then we cannot have inlined integers. Sure we can. We just can't have inlined integer constants outside the range +-2^31. I don't think it'll be a problem, really. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] process_opfunc.pl cleanup
This patch makes process_opfunc.pl use Opfunc.pm for all of its opcode related information. Therefore, it no longer needed to parse interp_guts.h or opcode_table. Also, I removed the $nvivsize from Opcode.pm (it wasn't being used anyway as process_opfunc.pl was recalculating it.) I think this patch makes everything more consistant, but I wanted to make sure there wasn't a reason (upcoming?) that process_opfunc.pl needed to parse either interp_guts.h or opcode_table.h If there are no objections, I will commit this patch AFTER 0.0.2 is released. Thanks! Tanton patch2.dat
RE: [PATCH] process_opfunc.pl cleanup
Oops...I meant OpCode.pm ... not OpFunc.pm Sorry for the confusion. -Original Message- From: Gregor N. Purdy To: Gibbs Tanton - tgibbs Cc: '[EMAIL PROTECTED] ' Sent: 10/4/2001 7:40 PM Subject: Re: [PATCH] process_opfunc.pl cleanup Tanton -- This patch makes process_opfunc.pl use Opfunc.pm for all of its opcode related information. Therefore, it no longer needed to parse interp_guts.h or opcode_table. Also, I removed the $nvivsize from Opcode.pm (it wasn't being used anyway as process_opfunc.pl was recalculating it.) I think this patch makes everything more consistant, but I wanted to make sure there wasn't a reason (upcoming?) that process_opfunc.pl needed to parse either interp_guts.h or opcode_table.h Is your Opfunc.pm similar to the OpFunc.pm I produced for the bytecode to C compiler (patch posted recently). If so, I'm happy to see movement in the direction of putting all parsing code in modules, and I'll make the compiler use the same code. I'd like to commit the compiler after you commit this. Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
RE: [PATCH] forcing packfile to opcode_t.
Bryan wrote -- Ok, I was put in a burlap sack and beaten for my first attempt at this; hopefully this attempt will go better. Based on everyone's (read: Dan's) comments I have changed the patch to NOT move integer constants to the constant table. Instead, the assembler dies if you try to make it handle an integer constant value larger than 2 ** 31 or smaller than -2 ** 31. Well, that obviously should be MAX_whatever and MIN_whatever. But sufficient for now, since that's probably a configure thing. Yes and No. If our inline constants are always going to be 32 bits then 2 ** 31 should always work (of course I shouldn't do it in such an ugly fastion, but a constant should work ). This required a change in two of the integer tests as 0xdeadbeef and 0xa0b0c0d0 were both bigger than 2 ** 31. Basically, this patch ensures that all code in the pack file is of size opcode_t (except the constant table which is in string(char) or double format). It also has the (size_t) casts where pointers are converted to integers. FWIW, size_t != size of pointers everywhere. (But you're probably safe.) No, but it should always be AT LEAST as big as a pointer. That is all that matters, we only have problems when it is smaller. (See below) a FLOATVAL constant without having to type 0.0 9.) Changed (INTVAL) casts in memory.c, register.h, and strnative.c to (size_t) casts just in case sizeof(INTVAL) sizeof(void*); !=, not . (If you cast back, for instance.) Unless we do something horribly wrong, then the cast back shouldn't be a problem becuase the value cast back will fit in a void*. 10.) integer.t had 0xdeadbeef changed to 0xdeadbee and 0xa0b0c0d0 to 0xa0b0c0d for signed 32 bit compatability. Any and all feedback is appreciated. NOTE: I apologize if this patch is still not what is wanted; I don't want to enforce anything I decide to code on parrot, but I thought it might be easier to comment on the patch if it were already coded. If this isn't wanted, I will continue to change it until it is :) I'm still not sure about size_t, but nothing standard had been added until recently. It's probably universal enough to be safe, but we may want to just find a type the same size as a pointer and roll our own just to be safe. I think size_t will be safe; however, I understand your hesitation. I can replace size_t with a typedefed type ( perhaps ptrcast_t ) and then have it typedefed with size_t to begin with. That way, we can easily change it when we decide what we want to do. Does that sound OK? Thanks for the feedback! Tanton
RE: [PATCH] forcing packfile to opcode_t.
Oops...after looking at the code closer I take this back...we do need to find our own ptrcast_t type. I'm replacing the size_t with ptrcast_t and adding a typedef size_t ptrcast_t to the config_h.in file. I'll then let Brent work out what to really put there :) -Original Message- From: Gibbs Tanton - tgibbs To: 'Bryan C. Warnock '; Gibbs Tanton - tgibbs; ''[EMAIL PROTECTED] ' ' Sent: 10/4/2001 10:40 PM Subject: RE: [PATCH] forcing packfile to opcode_t. Bryan wrote -- Ok, I was put in a burlap sack and beaten for my first attempt at this; hopefully this attempt will go better. Based on everyone's (read: Dan's) comments I have changed the patch to NOT move integer constants to the constant table. Instead, the assembler dies if you try to make it handle an integer constant value larger than 2 ** 31 or smaller than -2 ** 31. Well, that obviously should be MAX_whatever and MIN_whatever. But sufficient for now, since that's probably a configure thing. Yes and No. If our inline constants are always going to be 32 bits then 2 ** 31 should always work (of course I shouldn't do it in such an ugly fastion, but a constant should work ). This required a change in two of the integer tests as 0xdeadbeef and 0xa0b0c0d0 were both bigger than 2 ** 31. Basically, this patch ensures that all code in the pack file is of size opcode_t (except the constant table which is in string(char) or double format). It also has the (size_t) casts where pointers are converted to integers. FWIW, size_t != size of pointers everywhere. (But you're probably safe.) No, but it should always be AT LEAST as big as a pointer. That is all that matters, we only have problems when it is smaller. (See below) a FLOATVAL constant without having to type 0.0 9.) Changed (INTVAL) casts in memory.c, register.h, and strnative.c to (size_t) casts just in case sizeof(INTVAL) sizeof(void*); !=, not . (If you cast back, for instance.) Unless we do something horribly wrong, then the cast back shouldn't be a problem becuase the value cast back will fit in a void*. 10.) integer.t had 0xdeadbeef changed to 0xdeadbee and 0xa0b0c0d0 to 0xa0b0c0d for signed 32 bit compatability. Any and all feedback is appreciated. NOTE: I apologize if this patch is still not what is wanted; I don't want to enforce anything I decide to code on parrot, but I thought it might be easier to comment on the patch if it were already coded. If this isn't wanted, I will continue to change it until it is :) I'm still not sure about size_t, but nothing standard had been added until recently. It's probably universal enough to be safe, but we may want to just find a type the same size as a pointer and roll our own just to be safe. I think size_t will be safe; however, I understand your hesitation. I can replace size_t with a typedefed type ( perhaps ptrcast_t ) and then have it typedefed with size_t to begin with. That way, we can easily change it when we decide what we want to do. Does that sound OK? Thanks for the feedback! Tanton
RE: [PATCH] opcode_t *
Thanks! Applied. -Original Message- From: Bryan C. Warnock To: [EMAIL PROTECTED] Sent: 10/3/2001 9:22 AM Subject: [PATCH] opcode_t * Missed one of these. Index: interpreter.c === RCS file: /home/perlcvs/parrot/interpreter.c,v retrieving revision 1.21 diff -u -r1.21 interpreter.c --- interpreter.c 2001/10/02 14:01:30 1.21 +++ interpreter.c 2001/10/03 14:21:52 @@ -136,7 +136,7 @@ opcode_t * code_start; INTVAL code_size; opcode_t * code_end; -INTVAL * pc; +opcode_t * pc; check_fingerprint(interpreter); -- Bryan C. Warnock [EMAIL PROTECTED]
RE: Parrot 0.0.2
Cygwin is fine. Although I still have to change the makefile to get make test to work right. -Original Message- From: Simon Cozens To: [EMAIL PROTECTED] Sent: 10/3/2001 9:55 AM Subject: Parrot 0.0.2 Any objections to a release today? How's Cygwin and Win32 looking? -- I'm a person, not a piece of property. Happily, I'm both! - Lionel and Stephen Harris.
RE: Parrot 0.0.2
Here is the patch to get make test to work on cygwin. There may be a better way to do it. It is actually courtesy of someone else, but I'll have to go look to see who (unless you speak up :) It basically takes test: ...do tests and replaces it with test: dummy dummy: ...do tests so that cygwin really thinks there is something to do. -Original Message- From: Gibbs Tanton - tgibbs To: 'Simon Cozens '; '[EMAIL PROTECTED] ' Sent: 10/3/2001 10:12 AM Subject: RE: Parrot 0.0.2 Cygwin is fine. Although I still have to change the makefile to get make test to work right. -Original Message- From: Simon Cozens To: [EMAIL PROTECTED] Sent: 10/3/2001 9:55 AM Subject: Parrot 0.0.2 Any objections to a release today? How's Cygwin and Win32 looking? -- I'm a person, not a piece of property. Happily, I'm both! - Lionel and Stephen Harris. patch.dat
NV Constants
I tested the patch on CygWin, Solaris SunOS 5.8, and Tru64. It passed on all three systems. Tanton
RE: NV Constants
Simon,
I'm completely confused by this,
1.) Why are you allocating sizeof(IV) instead of sizeof(NV)?
2.) What is the difference between
mem_sys_memcopy( value, cursor, sizeof(NV) )
and allocating a new pointer and copying into it? They are both just
copying data into a pointer...does the sizeof(IV) have something to do with
it?
This code does not look right at all...can you help me understand?
-Original Message-
From: Simon Cozens
To: Gregor N. Purdy
Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Sent: 9/30/2001 3:21 PM
Subject: Re: NV Constants
On Sun, Sep 30, 2001 at 11:25:04AM -0400, Gregor N. Purdy wrote:
* Solaris (Sparc)
This was failing here until I made the following change:
PackFile_Constant_unpack_number(struct PackFile_Constant * self, char *
packed, IV packed_size) {
char * cursor;
NV value;
NV * aligned = mem_sys_allocate(sizeof(IV));
if (!self) {
return 0;
}
PackFile_Constant_clear(self);
cursor= packed;
mem_sys_memcopy(aligned, cursor, sizeof(NV));
value = *aligned;
cursor += sizeof(IV);
self-type = PFC_NUMBER;
self-number = value;
mem_sys_free(aligned);
return 1;
}
* FreeBSD (x86)
This passes, as does Tru64. I'm committing my tree, which is your patch
plus
my memcpy fix above; this is starting to smell very like 0.0.2 indeed,
apart
from the IV/NV renaming fix, which I'll do when nobody's looking. :)
I want VMS, Win32 and Cygwin to check in, then we'll do the renaming,
then
we'll release 0.0.2. Have fun!
--
It's 106 miles from Birmingham, we've got an eighth of a tank of gas,
half a pack of Dorritos, it's dusk, and we're wearing contacts.
- Malcolm Ray
--
If computer science was a science, computer scientists would study
what
computer systems do and draw well-reasoned conclusions from it, instead
of
being rabid clueless wankers who've never even seen a real world system
before,
let alone used one. These are the kind of people that brought us pascal,
folks.
- Charles J Radder, asr.
RE: Cygwin Problems (was: [PATCH assemble.pl] Fix binary values in bytecode)
Ooohh, that's bad. Cygwin works fine for me. What test is it failing on? What version of perl? -Original Message- From: Andreas Buggs Hauser To: Gibbs Tanton - tgibbs Cc: [EMAIL PROTECTED] Sent: 9/28/2001 11:59 AM Subject: Cygwin Problems (was: [PATCH assemble.pl] Fix binary values in bytecode) On Friday 28 September 2001 17:42, Gibbs Tanton - tgibbs wrote: The CygWin issue might be because 'make test' doesn't work when there is a directory named test. Perl doesn't have a test directory and instead has just t/ Would anyone complain if we renamed the test directory t? I think this would add CygWin to the list of test oks. Running harness by hand fails too. Have fun, Buggs
RE: Solaris problems with trans.t
In perl sin(1) != sin(1.0) or in C or in both? Also, what version of the OS is this, SunOS 5.8 works fine. -Original Message- From: Andreas Buggs Hauser To: [EMAIL PROTECTED] Sent: 9/28/2001 8:07 PM Subject: Solaris problems with trans.t Hoi, the solaris math functions(sin() ...) do not return the same value as perl when called with an integer. This causes the trans.t to fail. On solaris sin(1) != sin(1.0). Buggs
RE: new assemble.pl
It works for me and looks to be ok, can you tell me why you think binary numbers are broken? -Original Message- From: Mattia Barbon To: Gibbs Tanton - tgibbs Cc: '[EMAIL PROTECTED] ' Sent: 9/26/2001 2:44 AM Subject: Re: new assemble.pl On Wed, 26 Sep 2001, Gibbs Tanton - tgibbs wrote: Attached is a new assemble.pl. No, it doesn't change anything, it only breaks the code up into easier to follow functions (which are commented). I After looking at the old assembler code: Thanks! am going to test it on a few more platforms and then apply it tomorrow if no one has any objections. Having it broken up into functions should make it easier to change (e.g. adding NV to the constants table). Current assembler ( Wed Sep 26 01:00:02 2001 UTC ) does not handle binary ( 0b0101010 ) constants ( that's why bitwise tests were failing for me ). If you could have a quick look at it it would be great ( of course I can do it too, but since you are working on the assembler, probably is easier for you ) Regards Mattia
RE: new assemble.pl
Even with the old assembler, I get the correct answer. It might be something with your version of perl. I'm using 5.6.1. I'll try to find a 5.005 version and retry. -Original Message- From: Mattia Barbon To: Gibbs Tanton - tgibbs Cc: ''[EMAIL PROTECTED] ' ' Sent: 9/26/2001 9:00 AM Subject: RE: new assemble.pl On Wed, 26 Sep 2001, Gibbs Tanton - tgibbs wrote: It works for me and looks to be ok, can you tell me why you think binary numbers are broken? Sorry: I was unclear. I meant: the current assembly is broken here ( I have perl 5.005 BTW ) ( debugging shows that the register is set to zero instead of say 12, and if I change the assembly from 0b1100 to 12, the test passes ) I din't try the new assembler. Mattia -Original Message- From: Mattia Barbon To: Gibbs Tanton - tgibbs Cc: '[EMAIL PROTECTED] ' Sent: 9/26/2001 2:44 AM Subject: Re: new assemble.pl On Wed, 26 Sep 2001, Gibbs Tanton - tgibbs wrote: Attached is a new assemble.pl. No, it doesn't change anything, it only breaks the code up into easier to follow functions (which are commented). I After looking at the old assembler code: Thanks! am going to test it on a few more platforms and then apply it tomorrow if no one has any objections. Having it broken up into functions should make it easier to change (e.g. adding NV to the constants table). Current assembler ( Wed Sep 26 01:00:02 2001 UTC ) does not handle binary ( 0b0101010 ) constants ( that's why bitwise tests were failing for me ). If you could have a quick look at it it would be great ( of course I can do it too, but since you are working on the assembler, probably is easier for you ) Regards Mattia
RE: Tru64 core dumps
Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS is designed for a 32 bit system. It needs to be changed in the Configure.pl script to be 0xf000 for 64 bit systems. With that changed it works fine. -Original Message- From: Mattia Barbon To: Simon Cozens Cc: Gibbs Tanton - tgibbs; '[EMAIL PROTECTED]' Sent: 9/26/2001 9:05 AM Subject: Re: Tru64 core dumps On Wed, 26 Sep 2001, Simon Cozens wrote: On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote: I'm getting a core dump on Tru64 for stacks.t. Does anyone else get this? Just the one? I'm getting six of the damned things. The 01:00 UTC snapshot segfaulted on all tests because in perl 5.005 it uses 32 bit for opcodes and 64 bits for constants ( see my previous mail about Configure.pl ); after correctring that it segfaults on stacks.t and has p[roblems with binary constants in assembler, that break biotwise.t; other tests pass. ( this is perl 5.005_03 ) Regards Mattia
new assemble.pl
I tested this on Tru64, SunOS 5.8, and CygWin. It worked on each of those so I went ahead and committed it. If you have any problems, let me know and I will fix or revert. Thanks! Tanton
[COMMIT] assemble.pl
I changed assemble.pl so that the 0b constants will work on versions of perl prior to 5.6. The problem was that oct before 5.6 did not recognize 0b as a valid prefix. Therefore, I created a separate function from_binary that converts binary numbers to decimal numbers and I now call it instead of oct for binary constants. It is a rather crude implementation (I just loop through each bit and multiply by the appropriate power of 2); however, I could not find a pretty implementation that held up in a 64 bit environment. If anyone knows of one, please submit a patch :) Thanks! Tanton
FW: new assemble.pl
Oops...meant to send this to the group. -Original Message- From: Gibbs Tanton - tgibbs Sent: Wednesday, September 26, 2001 1:31 PM To: 'Andrew Kuchling '; Gibbs Tanton - tgibbs Subject: RE: new assemble.pl Thanks! Applied. -Original Message- From: Andrew Kuchling To: Gibbs Tanton - tgibbs Sent: 9/26/2001 12:52 PM Subject: Re: new assemble.pl On Wed, Sep 26, 2001 at 12:43:01PM -0500, Gibbs Tanton - tgibbs wrote: I tested this on Tru64, SunOS 5.8, and CygWin. It worked on each of those so I went ahead and committed it. If you have any problems, let me know and I will fix or revert. One quick fix: could you have error() return a non-zero exit status? I have a script that runs assemble.pl and needs to figure out if it compiled successfully or not. --amk Index: assemble.pl === RCS file: /home/perlcvs/parrot/assemble.pl,v retrieving revision 1.45 diff -C2 -r1.45 assemble.pl *** assemble.pl 2001/09/24 16:01:58 1.45 --- assemble.pl 2001/09/24 21:40:01 *** *** 440,444 my($message,$file,$line)=@_; print STDERR Error ($file:$line): $message\n; ! exit; } --- 440,444 my($message,$file,$line)=@_; print STDERR Error ($file:$line): $message\n; ! exit 1; }
Floating Points and 0.0.2 release
For the 0.0.2 release, do we want floating point constants in the constant table, or do we want to change the code to work with inline constants...I think we can do a simple memcpy to make the inline constants work (instead of casting and assigning.) Tanton
Where is Parrot/Types.pm
assemble.pl dies saying that it can't find Parrot/Types.pm in @INC. I've done a cvs update -dP and it doesn't get added...what happend to this file? Tanton
RE: Complete failure on Linux/PowerPC with 64bit ints.
Don't forget that this patch requires the configure patch by Brent that was just a couple of messages back. -Original Message- From: Michael G Schwern To: Andy Dougherty Cc: [EMAIL PROTECTED] Sent: 9/20/2001 8:22 AM Subject: Re: Complete failure on Linux/PowerPC with 64bit ints. On Thu, Sep 20, 2001 at 09:03:45AM -0400, Andy Dougherty wrote: On Thu, 20 Sep 2001, Michael G Schwern wrote: But if we run Configure.pl with bleadperl that *does* use 64bit ints and has debugging flags on, there's trouble. And all of the tests fail with This isn't Parrot bytecode! That's because assemble.pl hasn't been patched yet to use the right pack_type. You can either apply my patch from yesterday or you can hand-patch the pack_type for 'i' to be 'q'. This one? http:[EMAIL PROTECTED]/msg04540.html -- Michael G. Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Death follows me like a wee followey thing. -- Quakeman
RE: Tru64
Ok, I applied Damien's integer.t fix and we now get: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/number.t7 1792237 30.43% 1 7 9 11 13 15 17 4 subtests skipped. Failed 1/5 test scripts, 80.00% okay. 7/74 subtests failed, 90.54% okay. make: *** [test] Error 2 Damien, is there any way we could get a similar fix for number.t? That would make us at 100% on Tru64. Thanks! Tanton
Me
I will be on vacation in Disney World from now until Sunday night. Therefore, if you need me I won't be here :) Tanton
RE: The core platforms list
Both of these things were fixed when I converted from IV to opcode_t. (not that I didn't break other things...) Since that change was made, how many of the core platforms pass? If we lose one, I need to revert. Thanks! Tanton -Original Message- From: H.Merijn Brand To: Simon Cozens Cc: [EMAIL PROTECTED] Sent: 9/19/2001 6:22 AM Subject: Re: The core platforms list On Wed 19 Sep 2001 13:10, H.Merijn Brand [EMAIL PROTECTED] wrote: And, maybe even more important, not all the world has gcc! and bytecode.c l1:/pro/3gl/CPAN/parrot 136 make test_prog cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FI LE_OFFSET_BITS=64 -I.. -I./include -g -o bytecode.o -c bytecode.c cc: bytecode.c, line 53: warning 603: Cast is not lvalue; ++ requires lvalue. cc: bytecode.c, line 53: error 1560: Modifiable lvalue required with operator ++. which comes from #define GRAB_IV(x) *((IV*)*x)++ OK, switching to gcc, just because I'm curious ;) l1:/pro/3gl/CPAN/parrot 149 make test_prog perl make_op_header.pl opcode_table op.h gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o test_main.o -c test_main.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o global_setup.o -c global_setup.c perl build_interp_starter.pl gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o interpreter.o -c interpreter.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o parrot.o -c parrot.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o register.o -c register.c perl process_opfunc.pl basic_opcodes.ops gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o basic_opcodes.o -c basic_opcodes.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o memory.o -c memory.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o bytecode.o -c bytecode.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o string.o -c string.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o strnative.o -c strnative.c gcc -lnsl -lnm -lndbm -lgdbm -ldb -ldld -lm -lc -lndir -lcrypt -lsec -o test_prog global_setup.o interpreter.o parrot.o register.o basic_opcodes.o memory.o bytecode.o string.o strnative.o test_main.o l1:/pro/3gl/CPAN/parrot 150 make test perl t/harness Can't open perl script t/harness: No such file or directory make: *** [test] Error 2 l1:/pro/3gl/CPAN/parrot 151 test_prog Warning: Bytecode does not include opcode table fingerprint! l1:/pro/3gl/CPAN/parrot 152 MANIFEST? (using most recent parrot-nightly) -- H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.6.1, 5.7.1 629 on HP-UX 10.20 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro WinCE 2.11. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
RE: [PATCH] changing IV to opcode_t!!
Ok, after class I will fix and repatch. Making opcode_t a simple type that is configurable. Thanks! Tanton -Original Message- From: Dan Sugalski To: Simon Cozens; ''[EMAIL PROTECTED]' ' Sent: 9/19/2001 10:14 AM Subject: Re: [PATCH] changing IV to opcode_t!! At 03:58 PM 9/19/2001 +0100, Simon Cozens wrote: On Wed, Sep 19, 2001 at 10:59:45AM -0400, Dan Sugalski wrote: Nope. opcode_t should be the native opcode type for the platform we're compiling on. No need for fancy unions--configure should find out the integer type that works out right for the platform and the bytecode and use that. I thought the whole point was that on some platforms there *isn't* an integer type that works right. Nope. There's *always* an integer type that works right. We won't be running on a platform that doesn't have 32-bit integers. (Well, not without someone hacking the heck out of the core) The bytecode stream on disk is a series of M-bit integers holding 32-bit opcodes and parameters. It's treated as a stream of N-bit integers internally. That doesn't mean that M==32, or N==32, or even M==N. If M != N it means the bytecode load function needs to read in the bytecode stream from disk, treat it as a series of M-bit integers that need to be converted to N-bit ones for native interpretation. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: [PATCH] Remove C++ style comment
Thanks. Applied. -Original Message- From: Andy Dougherty To: [EMAIL PROTECTED] Sent: 9/19/2001 12:22 PM Subject: [PATCH] Remove C++ style comment I'm not sure why this is commented out in the first place, but if we want to keep it, we need to use C-style comments. diff -r -u parrot/config_h.in parrot-andy/config_h.in --- parrot/config_h.in Wed Sep 19 11:57:11 2001 +++ parrot-andy/config_h.in Wed Sep 19 12:08:27 2001 @@ -18,7 +18,7 @@ typedef void DPOINTER; typedef void SYNC; -//typedef IV *(*opcode_funcs)(void *, void *) OPFUNC; +/* typedef IV *(*opcode_funcs)(void *, void *) OPFUNC; */ #define FRAMES_PER_CHUNK 16 -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
[REPATCH] changing IV to opcode_t
Ok, this patch changes from the union to a simple type. The type is queried for at configure time. Brent, if you'll ok the configure stuff I'll go ahead and apply it. Thanks! Tanton patch.dat
64 bit Assembler
I have updated the Assembler to work better with 64 bit platforms. Now, to run under a 64 bit platform, just change the 'l' to a 'q' in the pack_type hash. I think Andy's patch will come closer to automatically choosing the right type, but that's not my area :)
RE: another silly question about Parrot::Opcode
Nope, I think you've messed up your math there :)
The current version multiplies the number of numeric types seen by two
(because (unportably) most numbers are twice the size of integers). Yours
does not take that into account.
-Original Message-
From: Pat Eyler
To: [EMAIL PROTECTED]
Sent: 9/19/2001 2:11 PM
Subject: another silly question about Parrot::Opcode
I found one more bit that looks odd to me (again in _load), near the end
of the while loop is this code:
my $num_i = () = grep {/i/} @params;
my $num_n = () = grep {/n/} @params;
$opcode{$name}{RETURN_OFFSET} = 1 + $num_i + $num_n * 2;
which could be reduced to:
my $numParams = () = grep {/[ni]/} @params;
$opcode{$name}{RETURN_OFFSET} = 1 + $numParams * 2;
which is (I think) more legible, and (in limited testing) about 30%
faster -- probably not a big deal in something so little used
Is there a reason not to do this?
-pate
RE: [REPATCH] changing IV to opcode_t
This has been applied. Please rerun Configure.pl after updating. Thanks! Tanton -Original Message- From: Gibbs Tanton - tgibbs To: '[EMAIL PROTECTED] ' Sent: 9/19/2001 1:15 PM Subject: [REPATCH] changing IV to opcode_t Ok, this patch changes from the union to a simple type. The type is queried for at configure time. Brent, if you'll ok the configure stuff I'll go ahead and apply it. Thanks! Tanton patch.dat
RE: [PATCH] mem_allocate_aligned explanation
Thanks. Applied.
-Original Message-
From: Josh Wilmes
To: [EMAIL PROTECTED]
Sent: 9/19/2001 3:04 PM
Subject: [PATCH] mem_allocate_aligned explanation
This patch adds Dan Sugalski's explanation to the code.
Index: memory.c
===
RCS file: /home/perlcvs/parrot/memory.c,v
retrieving revision 1.9
diff -u -r1.9 memory.c
--- memory.c2001/09/16 01:45:51 1.9
+++ memory.c2001/09/18 05:24:28
@@ -14,6 +14,29 @@
/*=for api mem mem_allocate_aligned
Allocate a chunk of memory aligned on a power-of-2 boundary
+
+ This is a boundary for which all the low bits of the address
+ are zeroes. Basically take the size of an object, round it up to a
+ power-of-two size (256, 512, 1024, whatever) and make sure that you
can
+ mask out the low bits with no problem. So for an up to 256-byte
thing the
+ low 8 bits are zero, for a thing that's between 257 and 512 the low
9 bits
+ are zero, and so on.
+
+ The reason for this is nasty, and basically speed. If I'm aligned
properly,
+ and I have an address in the middle of one of my aligned structures,
I can
+ mask the low bits off and find the base of the whole structure
without
+ needing embedded pointers or anything.
+
+ Register frames work like this, for example. The first chunk of the
+ register frame is some meta-information (forward and back pointers,
frames
+ used, and so forth) while the rest is sets of register arrays. If I
have an
+ address of one of the register arrays in the frame (which I do) I
can find
+ the base structure by lopping the low bits off. Cheaper in memory
terms
+ than having lots of back pointers. (Time, too, since I don't have to
fill
+ those back-pointers in)
+
+ It is a hack that might go if it turns out that having the back
pointers is
+ cheaper, though.
*/
void *
mem_allocate_aligned(IV size) {
changes for new operators
I've updated number.t and integer.t to use the new comparison operators. I also made a minor patch to opcode_table because the if ops had the wrong number of args. Finally, I made a change to assemble.pl to grok operators better. It should now handle an operator no matter how you name it as long as it consists of a base name followed by some sequence of _type where type is in ( i s n p ic sc nc ). Thanks! Tanton
RE: question about branching/returning
RETURN causes the program counter to be incremented by that many opcodes. So RETURN 4 would move forward 4 opcodes and RETURN -2 would move backward 2 opcodes. Basically, it returns a relative offset from the current position. -Original Message- From: Dave Storrs To: The Perl 6 Internals list Sent: 9/20/2001 12:22 AM Subject: question about branching/returning I'm working on documenting the opcodes, and I want to make sure that I understand the 'RETURN' code properly. I've poked around a little bit to see if I coudl figure it out, but I don't want to divert too much. Would someone please explain to me what each of the following does? RETURN 4 RETURN 0 RETURN -2 # Is this even legal? Thanks in advance, Dave
RE: question about branching/returning
First, code-i doesn't exist anymore...it is back to being *code (much more
readable that way :)
Second, we are going to remove those safety checks on that version of runops
if I'm not mistaken, I just don't think anyone's gotten around to it yet.
-Original Message-
From: Simon Cozens
To: Dave Storrs
Cc: 'The Perl 6 Internals list '
Sent: 9/20/2001 12:53 AM
Subject: Re: question about branching/returning
On Wed, Sep 19, 2001 at 10:47:44PM -0700, Dave Storrs wrote:
Well, I'm in the process of fiddling with this stuff anyway...what do
you
want me to make it do?
Oh, sorry, I see what happens. The last test (code-i) is what I would
think
of as *code: it tests whether we're sitting on an end op, zero. The
end
function itself is probably never called.
But this still sucks:
while (code = code_start code (code_start + code_size)
code-i) {
DO_OP(code, temp, func, interpreter);
}
Three tests and an addition each op. At the *very least*, we should
store
code_end = code_start + code_size. And at best...
DS The default dispatch loop shouldn't check. The Safe dispatch loop
(note the
DS caps there... :) should check.
--
User: In 1793 the french king was executed.
MegaHAL: HA HA HA! CORRECT. ALTHOUGH, EXECUTED HAS MULTIPLE MEANINGS.
sizeof(IV)
Are we assuming that sizeof(IV) = sizeof(char*). If so, we should probably assert this somewhere in the configure system. Tanton
[PATCH]pedantic
This patch allows parrot to compile cleanly under the -pedantic flag of gcc.
It removes the lvalue casts in GRAB_IV and DO_OP. GRAB_IV I had to add a
variable that was an IV** to hold the program code in each function that
used GRAB_IV. With DO_OP I just changed the lvalue cast to an rvalue cast.
Let me know of any improvements I could make.
Index: build_interp_starter.pl
===
RCS file: /home/perlcvs/parrot/build_interp_starter.pl,v
retrieving revision 1.9
diff -u -u -r1.9 build_interp_starter.pl
--- build_interp_starter.pl 2001/09/18 01:20:43 1.9
+++ build_interp_starter.pl 2001/09/18 14:38:59
@@ -62,7 +62,7 @@
#define DO_OP(w,x,y,z) do { \\
x = (void *)z-opcode_funcs; \\
-(void *)y = x[*w]; \\
+y = (IV* (*)())x[*w]; \\
w = (y)(w,z); \\
} while (0);
EOI
Index: bytecode.c
===
RCS file: /home/perlcvs/parrot/bytecode.c,v
retrieving revision 1.10
diff -u -u -r1.10 bytecode.c
--- bytecode.c 2001/09/17 17:38:14 1.10
+++ bytecode.c 2001/09/18 14:39:00
@@ -31,7 +31,7 @@
#include parrot/parrot.h
-#define GRAB_IV(x) *((IV*)*x)++
+#define GRAB_IV(x) *(*x)++
/*
@@ -51,8 +51,9 @@
static int
check_magic(void** program_code, long* program_size) {
+IV** pcode = (IV**)program_code;
program_size -= sizeof(IV);
-return (GRAB_IV(program_code) == PARROT_MAGIC);
+return (GRAB_IV(pcode) == PARROT_MAGIC);
}
/*
@@ -74,7 +75,8 @@
static void
read_constants_table(void** program_code, long* program_size)
{
-IV len = GRAB_IV(program_code);
+IV ** pcode = (IV**)program_code;
+IV len = GRAB_IV(pcode);
IV num;
IV i = 0;
@@ -85,24 +87,24 @@
return;
}
-num = GRAB_IV(program_code);
+num = GRAB_IV(pcode);
len -= sizeof(IV);
*program_size -= sizeof(IV);
Parrot_string_constants = mem_allocate_aligned(num * sizeof(STRING*));
while (len 0) {
-IV flags= GRAB_IV(program_code);
-IV encoding = GRAB_IV(program_code);
-IV type = GRAB_IV(program_code);
-IV buflen = GRAB_IV(program_code);
+IV flags= GRAB_IV(pcode);
+IV encoding = GRAB_IV(pcode);
+IV type = GRAB_IV(pcode);
+IV buflen = GRAB_IV(pcode);
int pad;
len -= 4 * sizeof(IV);
*program_size -= 4 * sizeof(IV);
-Parrot_string_constants[i++] = string_make(*program_code /* ouch
*/, buflen, encoding, flags, type);
-(char*)*program_code += buflen;
+Parrot_string_constants[i++] = string_make((char*)*pcode /* ouch
*/, buflen, encoding, flags, type);
+*pcode = (IV*)((char*)*pcode + buflen);
len -= buflen;
*program_size -= buflen;
@@ -111,7 +113,7 @@
if (pad) {
pad=sizeof(IV)-pad;
len -= pad;
- (char*)*program_code += pad;
+ *pcode = (IV*)((char*)*pcode + pad);
*program_size -= pad;
}
num--;
@@ -140,10 +142,11 @@
static void
read_fixup_table(void** program_code, long* program_size)
{
-IV len = GRAB_IV(program_code);
+IV** pcode = (IV**)program_code;
+IV len = GRAB_IV(pcode);
*program_size -= sizeof(IV);
/* For now, just skip over it */
-((IV*)*program_code) += len;
+*pcode += len;
*program_size -= len;
}
RE: bytecode and sizeof(IV)
You probably don't want to use ld as your linker. You should try cc instead. -Original Message- From: Simon Cozens To: [EMAIL PROTECTED] Sent: 9/18/2001 9:46 AM Subject: Re: bytecode and sizeof(IV) On Tue, Sep 18, 2001 at 05:52:24PM +0300, Jarkko Hietaniemi wrote: Segfault in alpha even when IVs and pointers are both 8 bytes since the code tries to dereference the pointers (to read IVs) at four byte offsets. Yep, and the latest pedantic patch doesn't help. Also, I'm seeing this, which is weird: ld -ldbm -ldb -lm -liconv -o test_prog global_setup.o interpreter.o parrot.o register.o basic_opcodes.o memory.o bytecode.o string.o strnative.o test_main.o ld: Error: Undefined: exit _iob fprintf fputs strncmp _OtsDivide64 printf time acos asin atan atan2 cosh exp log log10 pow sinh tan tanh cos sin _OtsRemainder64 malloc __CFE_print_puts free realloc _OtsMoveMinimum _OtsZero _OtsMove mmap stat open errno strcmp *** Exit 1 -- The UNIX system is harder to use than a toaster. -Kaare Christian
RE: [PATCH]pedantic
Ignore this patch as I think I have a better way to fix it.
-Original Message-
From: Gibbs Tanton - tgibbs
To: '[EMAIL PROTECTED] '
Sent: 9/18/2001 9:44 AM
Subject: [PATCH]pedantic
This patch allows parrot to compile cleanly under the -pedantic flag of
gcc.
It removes the lvalue casts in GRAB_IV and DO_OP. GRAB_IV I had to add
a
variable that was an IV** to hold the program code in each function that
used GRAB_IV. With DO_OP I just changed the lvalue cast to an rvalue
cast.
Let me know of any improvements I could make.
Index: build_interp_starter.pl
===
RCS file: /home/perlcvs/parrot/build_interp_starter.pl,v
retrieving revision 1.9
diff -u -u -r1.9 build_interp_starter.pl
--- build_interp_starter.pl 2001/09/18 01:20:43 1.9
+++ build_interp_starter.pl 2001/09/18 14:38:59
@@ -62,7 +62,7 @@
#define DO_OP(w,x,y,z) do { \\
x = (void *)z-opcode_funcs; \\
-(void *)y = x[*w]; \\
+y = (IV* (*)())x[*w]; \\
w = (y)(w,z); \\
} while (0);
EOI
Index: bytecode.c
===
RCS file: /home/perlcvs/parrot/bytecode.c,v
retrieving revision 1.10
diff -u -u -r1.10 bytecode.c
--- bytecode.c 2001/09/17 17:38:14 1.10
+++ bytecode.c 2001/09/18 14:39:00
@@ -31,7 +31,7 @@
#include parrot/parrot.h
-#define GRAB_IV(x) *((IV*)*x)++
+#define GRAB_IV(x) *(*x)++
/*
@@ -51,8 +51,9 @@
static int
check_magic(void** program_code, long* program_size) {
+IV** pcode = (IV**)program_code;
program_size -= sizeof(IV);
-return (GRAB_IV(program_code) == PARROT_MAGIC);
+return (GRAB_IV(pcode) == PARROT_MAGIC);
}
/*
@@ -74,7 +75,8 @@
static void
read_constants_table(void** program_code, long* program_size)
{
-IV len = GRAB_IV(program_code);
+IV ** pcode = (IV**)program_code;
+IV len = GRAB_IV(pcode);
IV num;
IV i = 0;
@@ -85,24 +87,24 @@
return;
}
-num = GRAB_IV(program_code);
+num = GRAB_IV(pcode);
len -= sizeof(IV);
*program_size -= sizeof(IV);
Parrot_string_constants = mem_allocate_aligned(num *
sizeof(STRING*));
while (len 0) {
-IV flags= GRAB_IV(program_code);
-IV encoding = GRAB_IV(program_code);
-IV type = GRAB_IV(program_code);
-IV buflen = GRAB_IV(program_code);
+IV flags= GRAB_IV(pcode);
+IV encoding = GRAB_IV(pcode);
+IV type = GRAB_IV(pcode);
+IV buflen = GRAB_IV(pcode);
int pad;
len -= 4 * sizeof(IV);
*program_size -= 4 * sizeof(IV);
-Parrot_string_constants[i++] = string_make(*program_code /*
ouch
*/, buflen, encoding, flags, type);
-(char*)*program_code += buflen;
+Parrot_string_constants[i++] = string_make((char*)*pcode /*
ouch
*/, buflen, encoding, flags, type);
+*pcode = (IV*)((char*)*pcode + buflen);
len -= buflen;
*program_size -= buflen;
@@ -111,7 +113,7 @@
if (pad) {
pad=sizeof(IV)-pad;
len -= pad;
- (char*)*program_code += pad;
+ *pcode = (IV*)((char*)*pcode + pad);
*program_size -= pad;
}
num--;
@@ -140,10 +142,11 @@
static void
read_fixup_table(void** program_code, long* program_size)
{
-IV len = GRAB_IV(program_code);
+IV** pcode = (IV**)program_code;
+IV len = GRAB_IV(pcode);
*program_size -= sizeof(IV);
/* For now, just skip over it */
-((IV*)*program_code) += len;
+*pcode += len;
*program_size -= len;
}
[PATCH] changing IV to opcode_t!!
Earlier there was some discussion about changing
typedef long IV
to
typedef union {
IV i;
void* p;
} opcode_t;
This patch does that. I have tested it on cygwin, solaris 5.8, and solaris
8. I would love someone to test it on Tru64 and Win32.
If this is NO LONGER WANTED, just let me know.
Thanks!
Tanton
patch.dat
RE: [PATCH] changing IV to opcode_t!!
Applied. -Original Message- From: Simon Cozens To: Gibbs Tanton - tgibbs Cc: '[EMAIL PROTECTED]' Sent: 9/18/2001 3:53 PM Subject: Re: [PATCH] changing IV to opcode_t!! On Tue, Sep 18, 2001 at 03:31:11PM -0500, Gibbs Tanton - tgibbs wrote: 8. I would love someone to test it on Tru64 and Win32. Testing anything on Tru64 is currently impossible, as Jarkko has pointed out. I'm still trying to wrap my branes around how to fix that. However, it compiles. I say apply it. Incidentally, Parrot's now compiling on Tru64 a lot more cleanly that it's ever done. -- Feed me on TOASTIES! There's no HALL for PHILOSOPHERS ON FRIDAYS. - Henry Braun is Oxford Zippy
RE: Bytecode safety
I would vote no. HOWEVER, I would think that the user should have the option to turn on checking for malformed bytecode (i.e. Safe mode). In the default case, I think the bytecode should be assumed well formed and no extra checking be performed. -Original Message- From: Damien Neil To: [EMAIL PROTECTED] Sent: 9/18/2001 4:37 PM Subject: Bytecode safety Proposed: Parrot should never crash due to malformed bytecode. When choosing between execution speed and bytecode safety, safety should always win. Careful op design and possibly a validation pass before execution will hopefully keep the speed penalty to a minimum. Yes, no? - Damien
Transcendental Math Function Tests
I have added trans.t to t/op/. It contains tests for all 18 transcendental math functions. BTW, did we ever decide on a naming scheme for operators...I named all of the math functions against the grain (although I didn't realize it at the time)...for example sin_n_n instead of sin_n. Does this need to be changed? I'll be glad to do it. Tanton
Tests
All the tests are great! But, could everyone please remember to put an end at the end of each assembly test...cygwin doesn't like it if you don't. I think I've patched all the ones up to this point. Thanks! Tanton
RE: [PATCH] changing IV to opcode_t!!
Ok...let me try to get this straight and I'll repatch...
opcode_t should be something that will represent the native opcode type. In
most cases it should just be long; however, there might be special systems
where it is somehting different (int, long long, etc...). IV should be a
union with a long and void* member so that we can cast from a long to a
pointer.
Is that correct?
-Original Message-
From: Hong Zhang
To: '[EMAIL PROTECTED]'
Sent: 9/18/2001 8:47 PM
Subject: RE: [PATCH] changing IV to opcode_t!!
Do we want the opcode to be so complicated? I thought we are
going to use this kind of thing for generic pointers. The p
member of opcode does not make any sense to me.
Hong
Earlier there was some discussion about changing typedef long IV
to
typedef union {
IV i;
void* p;
} opcode_t;
Purify machine
What type of machine is the hourly purify running on. It keeps dieing with a SIGBUS on most set_n_nc calls (meaning invalid alignment). This is really bad. I would like to know the type of an NV as well as the sizeof NV, sizeof IV, and sizeof void*. Thanks! Tanton
RE: Parrot coredumps on Alpha (Was: Parrot coredumps on Solaris 8)
Yep, you were right...I made a patch for you and applied it :)
Thanks!
Tanton
Philip Kendall wrote:
* The trickier one: with the above two changes, test and test2 work,
but test3 tries to pop a non-existent stack frame. In Parrot_pop_i,
should the fragment:
if (chunk_base-prev) {
/* Do so. We don't need to adjust used/free, since they're
already OK for the We're full case */
chunk_base = chunk_base-prev;
interpreter-int_reg = chunk_base-IReg[chunk_base-used];
}
actually be:
if (chunk_base-prev) {
/* Do so. We don't need to adjust used/free, since they're
already OK for the We're full case */
chunk_base = chunk_base-prev;
interpreter-int_reg = chunk_base-IReg[chunk_base-used - 1];
}
If chunk_base-used == 1, I think we want chunk_base-IReg[0], not
chunk_base-IReg[1]?? (but I'll happily admit I haven't got my head
around the memory management yet). Similar considerations apply to the
other Parrot_pop_? functions.
Apologies for any stupidity...
Phil
--
Philip Kendall [EMAIL PROTECTED]
http://www.srcf.ucam.org/~pak21/
RE: Time for a moratorium on changes for a bit
Things work fine for me on cygwin...just be sure that you use cc instead of ld. Also, you probably don't want to include any libraries. As for the Manifest I haven't had any problems. -Original Message- From: Dan Sugalski To: [EMAIL PROTECTED] Sent: 9/17/2001 9:10 AM Subject: Time for a moratorium on changes for a bit Okay, I checked out parrot fresh from CVS this morning (after wading through a *lot* of e-mail) and I find: *) Configure.pl doesn't like the current state of the manifest and won't run (at least not for me, though it's misbehaving oddly) *) Things don't build at all well on CygWin. (They used to, it's what I use) I think it's time for us to take a moment, *stop* twiddling with things, and get the repository back in a state where the code builds properly for a bit. A 0.02 release wouldn't be out of order either when we get things calmed down. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: [PATCH AGAIN] Revised op tracing patch
Wearing my coding standard police hat -
You should remove your cuddled else statements:
i.e. if {
} else {
}
becomes
if {
}
else {
}
other than that, it looks good.
-Original Message-
From: Gregor N. Purdy
To: [EMAIL PROTECTED]
Sent: 9/17/2001 11:37 AM
Subject: [PATCH AGAIN] Revised op tracing patch
[UPDATED: patch actually attached this time]
All --
I am attaching a revised op tracing patch based on the feedback I got.
Its features are:
* Provides macros in interp_guts.h for setting up arrays with
op names and op arg counts (done via build_interp_starter.pl).
These are used in the op tracing
* The functions in bytecode.[hc] pass around a pointer to the length
of the bytecode so that later when we get to runops, we know
how much bytecode we've got and we can detect out-of-bounds
jumping. The documentation is updated, too.
* runops in interpreter.c now looks at interpreter-flags to
decide if the core of runops should be runops_trace_core or
runops_notrace_core. These new functions contain just the
while-loop portion of runops. A new function runops_generic
does any other setup (such as checking the bytecode
fingerprint) or wrapup (such as complaining if we ended up
out-of-bounds). NOTE: I didn't know what we should do for
functions in here that are not part of the api, so I gave
them docs with 'TODO' marks mentioning they really aren't
part of the api. Guidance appreciated.
* test_main.c now checks for '-t' arg and sets the tracing flag
on its interpreter instance as appropriate.
I'd like to commit this soon to clear out my sandbox so I can go
back and re-commit the constant comparison ops. So, if there
aren't any objections...
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc.http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_/
traceop.diff
RE: Automated Purify Run
It looks like to me that this is only running every day. Can we get it to run every hour? Perhaps even on demand? I think I have fixed all of the memory access errors but one. -Original Message- From: Josh Wilmes To: [EMAIL PROTECTED] Sent: 9/15/2001 5:16 PM Subject: Automated Purify Run This time i've filtered out all the memory leak related data so all that shows up are legitimate errors. (hopefully) I have set up a cheesy script to update the following URL with the current output of purify on the current CVS test_prog (test,test2,test3,euclid) every hour. http://www.hitchhiker.org/josh/parrot/purify.txt --Josh
RE: Automated Purify Run
The hourly should be fine...can you do me one other favor and run the
following c snippet through Purify:
int main() {
char* c = (char*)malloc(0);
printf( %.*s\n, 0, c );
return 0;
}
-Original Message-
From: Josh Wilmes
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED] '
Sent: 9/17/2001 1:18 PM
Subject: Re: Automated Purify Run
It should now be running once an hour. (it broke due to some makefile
changes yesterday).
I can't really do it easily on-demand, due to the way this is set up.
--Josh
At 13:05 on 09/17/2001 CDT, Gibbs Tanton - tgibbs
[EMAIL PROTECTED] wrote:
It looks like to me that this is only running every day. Can we get
it to
run every hour? Perhaps even on demand? I think I have fixed all of
the
memory access errors but one.
-Original Message-
From: Josh Wilmes
To: [EMAIL PROTECTED]
Sent: 9/15/2001 5:16 PM
Subject: Automated Purify Run
This time i've filtered out all the memory leak related data so all
that
shows up are legitimate errors. (hopefully)
I have set up a cheesy script to update the following URL with the
current output
of purify on the current CVS test_prog (test,test2,test3,euclid) every
hour.
http://www.hitchhiker.org/josh/parrot/purify.txt
--Josh
RE: Automated Purify Run
Well, that explains the last Purify issue. Whenever we substr out 0 bytes
to a NULL register, we create a string by malloc(0). If we later print that
string, then we pass in 0 to printf. I thought that printf would not look
at its argument if the length specifier was 0, but apparently on your system
it does. So, it appears we have two options:
1.) Ignore the error
2.) Put an if statement around the print and have it not print if the
string is of length 0.
Any sugestions or other ideas?
-Original Message-
From: Josh Wilmes
To: Gibbs Tanton - tgibbs
Cc: ''[EMAIL PROTECTED] ' '
Sent: 9/17/2001 2:23 PM
Subject: Re: Automated Purify Run
Purify instrumented foo (pid 11272)
ABR: Array bounds read:
* This is occurring while in:
_doprnt[libc.so.1]
printf [libc.so.1]
main [ccjq2xev.o]
_start [crt1.o]
* Reading 1 byte from 0x969b0 in the heap.
* Address 0x969b0 is 1 byte past end of a malloc'd block at 0x969b0 of
0 bytes
.
* This block was allocated from:
malloc [rtlib.o]
main [ccjq2xev.o]
_start [crt1.o]
At 14:18 on 09/17/2001 CDT, Gibbs Tanton - tgibbs
[EMAIL PROTECTED] wrote:
The hourly should be fine...can you do me one other favor and run the
following c snippet through Purify:
int main() {
char* c = (char*)malloc(0);
printf( %.*s\n, 0, c );
return 0;
}
-Original Message-
From: Josh Wilmes
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED] '
Sent: 9/17/2001 1:18 PM
Subject: Re: Automated Purify Run
It should now be running once an hour. (it broke due to some makefile
changes yesterday).
I can't really do it easily on-demand, due to the way this is set up.
--Josh
At 13:05 on 09/17/2001 CDT, Gibbs Tanton - tgibbs
[EMAIL PROTECTED] wrote:
It looks like to me that this is only running every day. Can we get
it to
run every hour? Perhaps even on demand? I think I have fixed all
of
the
memory access errors but one.
-Original Message-
From: Josh Wilmes
To: [EMAIL PROTECTED]
Sent: 9/15/2001 5:16 PM
Subject: Automated Purify Run
This time i've filtered out all the memory leak related data so all
that
shows up are legitimate errors. (hopefully)
I have set up a cheesy script to update the following URL with the
current output
of purify on the current CVS test_prog (test,test2,test3,euclid)
every
hour.
http://www.hitchhiker.org/josh/parrot/purify.txt
--Josh
RE: Automated Purify Run
Okey Dokey. With that being the case, it appears we should rethink
string_grow/string_make. If we get a length of 0, we should allocate 1 byte
and store '\0' in it (really storing '\0' is not necessary, but it is always
nice to initialize). We can still keep the length as being 0, but this way
it will be portable.
Does this sound ok?
Tanton
-Original Message-
From: Jarkko Hietaniemi
To: Gibbs Tanton - tgibbs
Cc: 'Josh Wilmes '; ''[EMAIL PROTECTED] ' '
Sent: 9/17/2001 2:26 PM
Subject: Re: Automated Purify Run
On Mon, Sep 17, 2001 at 02:18:16PM -0500, Gibbs Tanton - tgibbs wrote:
The hourly should be fine...can you do me one other favor and run the
following c snippet through Purify:
int main() {
char* c = (char*)malloc(0);
I can tell without Purify that malloc(0) is unportable.
(As is calling it without stdlib.h inclusion, but I'm being mean :-)
printf( %.*s\n, 0, c );
return 0;
}
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
RE: Automated Purify Run
I'm working on taking the perl function and stripping out the parts we don't need. I should have it tonight. My thought is that we can add some stuff in later and Parrot_printf should only have the bare necessities (therefore I am throwing out things like maybe_tainted and vector strings). Does that sound ok? Tanton -Original Message- From: Jarkko Hietaniemi To: Timur Safin Cc: Gibbs Tanton - tgibbs; 'Josh Wilmes '; [EMAIL PROTECTED] Sent: 9/17/2001 3:24 PM Subject: Re: Automated Purify Run On Tue, Sep 18, 2001 at 12:06:32AM +0400, Timur Safin wrote: Hi Jarkko, Here is that the SUSV2 prescribe to do in this situation. The Single UNIX ® Specification, Version 2, Copyright © 1997 The Open Group NAME malloc - a memory allocator ... I'm reading the same page :-) You glossed over the ... part too fast. In DESCRIPTION: If the size of the space requested is 0, the behaviour is implementation-dependent; the value returned will be either a null pointer or a unique pointer. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
RE: Op cost models
Yeah, I ran a test where I substituted a huge switch statement with all of the operations inlined for the function calls and I went from 27 seconds to 21 seconds on the benchmark. -Original Message- From: Simon Cozens To: [EMAIL PROTECTED] Sent: 9/16/2001 10:01 AM Subject: Op cost models Here are the costs in seconds for running 100 million iterations of each op. This only really makes sense on *my* machine, but it gives you an idea of what sort of tradeoffs there are. Given that the difference between most ops is negligible, I'd suggest that a lot of work is still happening in the despatch. The script which generated this is attached. add_i 4.5 add_n 5 branch_ic 2 dec_i 4.5 dec_i_ic4.5 dec_n 4.5 dec_n_nc6 div_i 10.5 div_n 24.5 eq_i_ic 4.5 eq_ic_ic4.5 eq_n_ic 5.5 eq_nc_ic6 ge_i_ic 5.5 ge_ic_ic5 ge_n_ic 6 ge_nc_ic6 gt_i_ic 5 gt_ic_ic5 gt_n_ic 5.5 gt_nc_ic6.5 if_i_ic 5 if_n_ic 6 inc_i 2 inc_i_ic4.5 inc_n 5 inc_n_nc5.5 iton_n_i6.5 le_i_ic 5 le_ic_ic5 le_n_ic 5.5 le_nc_ic5.5 length_i_s 6 lt_i_ic 4.5 lt_ic_ic4.5 lt_n_ic 5 lt_nc_ic6 mod_i 11 mul_i 5.5 mul_n 6 ne_i_ic 4.5 ne_ic_ic4.5 ne_n_nc 5.5 ne_nc_ic5 noop3.5 ntoi_i_n11.5 pushpop_i 14 pushpop_n 14 pushpop_p 14 pushpop_s 14 set_i 4.5 set_i_ic4.5 set_n_nc5 sub_i 5 sub_n 5 substr_s_s_i23.5 time_i 49.5 time_n 49.5 -- Simon: `hello kitty' douche. If you are getting some and you know what hello kitty is... Well, you're an exceptionally lucky man. -- Megahal, trained on IRC. cost_model
RE: Op cost models
Another point: I added the -O3 on each test: function dispatch switch statement%speedup -O0 27s21s 30 -O3 16s12s 25 AS you can see -O3 helped out quite a bit giving a 40% gain in both cases. -Original Message- From: Gibbs Tanton - tgibbs To: 'Simon Cozens '; '[EMAIL PROTECTED] ' Sent: 9/16/2001 10:39 AM Subject: RE: Op cost models Yeah, I ran a test where I substituted a huge switch statement with all of the operations inlined for the function calls and I went from 27 seconds to 21 seconds on the benchmark. -Original Message- From: Simon Cozens To: [EMAIL PROTECTED] Sent: 9/16/2001 10:01 AM Subject: Op cost models Here are the costs in seconds for running 100 million iterations of each op. This only really makes sense on *my* machine, but it gives you an idea of what sort of tradeoffs there are. Given that the difference between most ops is negligible, I'd suggest that a lot of work is still happening in the despatch. The script which generated this is attached. add_i 4.5 add_n 5 branch_ic 2 dec_i 4.5 dec_i_ic4.5 dec_n 4.5 dec_n_nc6 div_i 10.5 div_n 24.5 eq_i_ic 4.5 eq_ic_ic4.5 eq_n_ic 5.5 eq_nc_ic6 ge_i_ic 5.5 ge_ic_ic5 ge_n_ic 6 ge_nc_ic6 gt_i_ic 5 gt_ic_ic5 gt_n_ic 5.5 gt_nc_ic6.5 if_i_ic 5 if_n_ic 6 inc_i 2 inc_i_ic4.5 inc_n 5 inc_n_nc5.5 iton_n_i6.5 le_i_ic 5 le_ic_ic5 le_n_ic 5.5 le_nc_ic5.5 length_i_s 6 lt_i_ic 4.5 lt_ic_ic4.5 lt_n_ic 5 lt_nc_ic6 mod_i 11 mul_i 5.5 mul_n 6 ne_i_ic 4.5 ne_ic_ic4.5 ne_n_nc 5.5 ne_nc_ic5 noop3.5 ntoi_i_n11.5 pushpop_i 14 pushpop_n 14 pushpop_p 14 pushpop_s 14 set_i 4.5 set_i_ic4.5 set_n_nc5 sub_i 5 sub_n 5 substr_s_s_i23.5 time_i 49.5 time_n 49.5 -- Simon: `hello kitty' douche. If you are getting some and you know what hello kitty is... Well, you're an exceptionally lucky man. -- Megahal, trained on IRC. cost_model
RE: [proposed] Moving *.h to include/parrot/ right away
I don't think anyone objects to this...I vote go ahead and move the .h files and modify Makefile.in according to Brent's email. Tanton -Original Message- From: Gregor N. Purdy To: Gibbs Tanton - tgibbs Cc: 'Robert Spier '; '[EMAIL PROTECTED]' Sent: 9/14/2001 7:05 PM Subject: [proposed] Moving *.h to include/parrot/ right away All -- Since we are so early in the game, I'm not sure if it really matters whether we keep the version information or not. Does anyone have a problem with me deleting the header files and readding them under include/parrot/. or is the general concensus moving the RCS files? Rather than do it via patch submission, I'd be happy to go in and make the changes now that I have write access. Have there been any objections to this process: $ cvs -q upd -AdP $ mkdir -p include/parrot $ cvs add include $ cvs add include/parrot $ for hdr in *.h; do cp -a $hdr include/parrot cvs add /include/parrot/$hdr cvs remove -f $hdr done $ cvs commit -m 'gnp: Moved all header files to include/parrot' With the appropriate modification to Makefile.in as well (diff attached)? I don't remember seeing anyone particularly upset by it. [[ UPDATE: REALLY ATTACHED THIS TIME ]] If not, I'd be happy to do it. It'll take just a few minutes... Also, would anyone like to see a standard C comment header that includes the RCS information added to each file? I would definitely like to see something like # $Revision: $ at a minimum. Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/ Makefile.in.diff
[PATCH]Makefile.in
Brent,
This patch allows the Makefile to work for me...if the
$(CC) -o $*$(O) -c $*.c
line is not below each .c file cygwin's make does not do the right thing and
does not make properly. This patch adds those lines. If you have a better
way to do it, I would be glad to implement that instead.
Index: Makefile.in
===
RCS file: /home/perlcvs/parrot/Makefile.in,v
retrieving revision 1.4
diff -u -u -r1.4 Makefile.in
--- Makefile.in 2001/09/16 01:55:26 1.4
+++ Makefile.in 2001/09/16 16:15:38
@@ -11,7 +11,7 @@
CC = ${cc} $(C_FLAGS)
-all : $(O_FILES)
+all : test_prog
shared: libparrot.so
libparrot.so: $(O_FILES)
@@ -21,12 +21,16 @@
$(CC) $(C_LIBS) -o test_prog $(O_FILES) test_main$(O)
test_main$(O): $(H_FILES)
+ $(CC) -o $*$(O) -c $*.c
global_setup$(O): $(H_FILES)
+ $(CC) -o $*$(O) -c $*.c
string$(O): $(H_FILES)
+ $(CC) -o $*$(O) -c $*.c
strnative$(O): $(H_FILES)
+ $(CC) -o $*$(O) -c $*.c
interp_guts.h: opcode_table build_interp_starter.pl
${perl} build_interp_starter.pl
@@ -34,14 +38,19 @@
interpreter$(O): interpreter.c $(H_FILES) interp_guts.h
memory$(O): $(H_FILES)
+ $(CC) -o $*$(O) -c $*.c
bytecode$(O): $(H_FILES)
+ $(CC) -o $*$(O) -c $*.c
parrot$(O): $(H_FILES)
+ $(CC) -o $*$(O) -c $*.c
register$(O): $(H_FILES)
+ $(CC) -o $*$(O) -c $*.c
basic_opcodes$(O): $(H_FILES) basic_opcodes.c
+ $(CC) -o $*$(O) -c $*.c
basic_opcodes.c: basic_opcodes.ops process_opfunc.pl interp_guts.h
${perl} process_opfunc.pl basic_opcodes.ops
RE: [PATCH]Makefile.in
Ok, here is the rule based makefile... -Original Message- From: [EMAIL PROTECTED] To: Gibbs Tanton - tgibbs Cc: '[EMAIL PROTECTED] ' Sent: 9/16/2001 2:49 PM Subject: Re: [PATCH]Makefile.in This should be done with an implicit rule or a pattern rule. By putting all the explicit lines in, it'll be harder to change later, and errors can crop up. The makefile needs a cleanup - we're not making good use of any of the 'features' of make. Are we allowed to use gnu makeisms? -R (holding off on a patch until the current batch of Make patches settle.) On Sun, Sep 16, 2001 at 11:20:10AM -0500, Gibbs Tanton - tgibbs wrote: | Brent, | | This patch allows the Makefile to work for me...if the | $(CC) -o $*$(O) -c $*.c | line is not below each .c file cygwin's make does not do the right thing and | does not make properly. This patch adds those lines. If you have a better | way to do it, I would be glad to implement that instead. patch.dat
RE: [PATCH] testsuite and Win32 compilation
## +#if defined(WIN32) ## +program_code = malloc( file_stat.st_size ); ## +#else Also, since more than win32 is not going to have mmap, perhaps you could add a Configure #define for HAS_MMAP or something like that. Then you could test the cc compiler to check for mmap availability.
RE: Difficulties
The README really doesn't have to mention Configure.pl because when you do make test_prog it will run Configure.pl for you (at least it is supposed to :) -Original Message- From: Will Coleda To: [EMAIL PROTECTED] Sent: 9/15/2001 12:13 AM Subject: Difficulties The README doesn't mention Configure.pl (minor doc patch follows), and Parrot::Opcode is requiring perl5.6, which makes my 5.5.3 quite unhappy. Are folks intentially using 5.6 constructs? I'll consider generating a patch to make things work with 5.5.3 if this was an act of convenience rather than benevolent despotism. =-) Index: README === RCS file: /home/perlcvs/parrot/README,v retrieving revision 1.5 diff -u -r1.5 README --- README 2001/09/10 16:56:28 1.5 +++ README 2001/09/15 05:09:56 @@ -34,6 +34,10 @@ For now, unpack your Parrot tarball, (if you're reading this, you've probably already done that) type +perl Configure.pl + +answer the questions, and a Makefile will be generated. Then type + make test_prog and the test interpreter should build.
RE: Difficulties
I haven't had any problem with my instead of use vars...can you send me the test program that blows up? -Original Message- From: Uri Guttman To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: 9/15/2001 8:57 AM Subject: Re: Difficulties BD == Brent Dax [EMAIL PROTECTED] writes: BD use vars qw(%opcode $fingerprint);#or strict will throw a tantrum so why didn't 'my' work. those are file globals from what i can tell. my causes interpreter.c to blow up. use vars fixes it. 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
coding standards
Ok, I just updated every .c and .h file to include the new coding standard. I also updated most of the .pl files to use Parrot_Interp instead of Perl_Interp. Please refresh your copy of the files. I will try to watch things as they go in and make coding standard changes immediately from now on so we don't have such a massive change. Thanks! Tanton
RE: Constant comparisons
It seems to me that this might eventually get out of hand...could there
possibly be some way to automate the generation of a family of opcodes? For
example:
MANUAL_OP_FAMILY eq_T1_T2 {
if( T1 == T2 ) {
RETURN(P3);
}
else {
RETURN(P4);
}
} OVER(i, ic, n, nc)
Note that I'm not proposing that syntax, just wondering if there is a more
automated way of doing things.
-Original Message-
From: Nathan Torkington
To: [EMAIL PROTECTED]
Sent: 9/15/2001 4:56 PM
Subject: Constant comparisons
I wanted to be able to say
eq I1, 15, label1, label2
That is, to compare against a constant. I've implemented versions of
the comparison opcodes that let you compare against constants. This
is my first patch to Parrot. Be merciful :-)
Nat
(also working on test system ... stay tuned)
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.15
diff -u -d -r1.15 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/14 14:08:00 1.15
+++ basic_opcodes.ops 2001/09/15 21:52:38
@@ -56,6 +56,15 @@
}
}
+/* EQ Ix, CONSTANT, EQ_BRANCH, NE_BRANCH */
+MANUAL_OP eq_ic_ic {
+ if (INT_REG(P1) == P2) {
+RETURN(P3);
+ } else {
+RETURN(P4);
+ }
+}
+
/* NE Ix, Iy, NE_BRANCH, EQ_BRANCH */
MANUAL_OP ne_i_ic {
if (INT_REG(P1) != INT_REG(P2)) {
@@ -65,6 +74,15 @@
}
}
+/* NE Ix, CONSTANT, NE_BRANCH, EQ_BRANCH */
+MANUAL_OP ne_ic_ic {
+ if (INT_REG(P1) != P2) {
+RETURN(P3);
+ } else {
+RETURN(P4);
+ }
+}
+
/* LT Ix, Iy, LT_BRANCH, GE_BRANCH */
MANUAL_OP lt_i_ic {
if (INT_REG(P1) INT_REG(P2)) {
@@ -74,6 +92,15 @@
}
}
+/* LT Ix, CONSTANT, LT_BRANCH, GE_BRANCH */
+MANUAL_OP lt_ic_ic {
+ if (INT_REG(P1) P2) {
+RETURN(P3);
+ } else {
+RETURN(P4);
+ }
+}
+
/* LE Ix, Iy, LE_BRANCH, GT_BRANCH */
MANUAL_OP le_i_ic {
if (INT_REG(P1) = INT_REG(P2)) {
@@ -83,6 +110,15 @@
}
}
+/* LE Ix, CONSTANT, LE_BRANCH, GT_BRANCH */
+MANUAL_OP le_ic_ic {
+ if (INT_REG(P1) = P2) {
+RETURN(P3);
+ } else {
+RETURN(P4);
+ }
+}
+
/* GT Ix, Iy, GT_BRANCH, LE_BRANCH */
MANUAL_OP gt_i_ic {
if (INT_REG(P1) INT_REG(P2)) {
@@ -92,6 +128,15 @@
}
}
+/* GT Ix, CONSTANT, GT_BRANCH, LE_BRANCH */
+MANUAL_OP gt_ic_ic {
+ if (INT_REG(P1) P2) {
+RETURN(P3);
+ } else {
+RETURN(P4);
+ }
+}
+
/* GE Ix, Iy, GE_BRANCH, LT_BRANCH */
MANUAL_OP ge_i_ic {
if (INT_REG(P1) = INT_REG(P2)) {
@@ -101,6 +146,15 @@
}
}
+/* GE Ix, CONSTANT, GE_BRANCH, LT_BRANCH */
+MANUAL_OP ge_ic_ic {
+ if (INT_REG(P1) = P2) {
+RETURN(P3);
+ } else {
+RETURN(P4);
+ }
+}
+
/* IF IXx, TRUE_BRANCH, FALSE_BRANCH */
MANUAL_OP if_i_ic {
if (INT_REG(P1)) {
@@ -193,6 +247,15 @@
/* EQ Nx, Ny, EQ_BRANCH, NE_BRANCH */
MANUAL_OP eq_n_ic {
if (NUM_REG(P1) == NUM_REG(P2)) {
+RETURN(P3);
+ } else {
+RETURN(P4);
+ }
+}
+
+/* EQ Nx, CONSTANT, EQ_BRANCH, NE_BRANCH */
+MANUAL_OP eq_nc_ic {
+ if (NUM_REG(P1) == P2) {
RETURN(P3);
} else {
RETURN(P4);
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.13
diff -u -d -r1.13 opcode_table
--- opcode_table2001/09/13 16:16:38 1.13
+++ opcode_table2001/09/15 21:52:38
@@ -62,12 +62,19 @@
# Comparators
eq_i_ic4 I I D D
+eq_ic_ic 4 I i D D
eq_n_ic4 N N D D
+eq_nc_ic 4 N n D D
ne_i_ic4 I I D D
+ne_ic_ic 4 I i D D
lt_i_ic4 I I D D
+lt_ic_ic 4 I i D D
le_i_ic4 I I D D
+le_ic_ic 4 I i D D
gt_i_ic4 I I D D
+gt_ic_ic 4 I i D D
ge_i_ic4 I I D D
+ge_ic_ic 4 I i D D
# Flow control
RE: parrot/config.h patch and others
Here is the parrot/config.h patch
It fixes Makefile.in, but not in the correct way. Brent, if you could look
at this and fix it the right way I would really appreciate it (note that I
have no clue what the right way is :)
Index: Makefile.in
===
RCS file: /home/perlcvs/parrot/Makefile.in,v
retrieving revision 1.1
diff -u -r1.1 Makefile.in
--- Makefile.in 2001/09/14 09:57:01 1.1
+++ Makefile.in 2001/09/14 13:22:35
@@ -4,7 +4,7 @@
O_FILES = global_setup$(O) interpreter$(O) parrot$(O) register$(O)
basic_opcodes$(O) memory$(O) bytecode$(O) string$(O) strnative$(O)
-C_FLAGS = ${ccflags}
+C_FLAGS = ${ccflags} -I..
C_LIBS = ${libs}
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.14
diff -u -r1.14 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/13 16:16:38 1.14
+++ basic_opcodes.ops 2001/09/14 13:22:36
@@ -4,8 +4,8 @@
*
*/
-#include parrot.h
-#include math.h
+#include parrot/parrot.h
+#include math.h
/* SET Ix, CONSTANT */
AUTO_OP set_i_ic {
Index: bytecode.c
===
RCS file: /home/perlcvs/parrot/bytecode.c,v
retrieving revision 1.7
diff -u -r1.7 bytecode.c
--- bytecode.c 2001/09/14 09:57:01 1.7
+++ bytecode.c 2001/09/14 13:22:36
@@ -19,7 +19,7 @@
*/
-#include parrot.h
+#include parrot/parrot.h
#define GRAB_IV(x) *((IV*)*x)++
Index: global_setup.c
===
RCS file: /home/perlcvs/parrot/global_setup.c,v
retrieving revision 1.3
diff -u -r1.3 global_setup.c
--- global_setup.c 2001/09/14 09:03:43 1.3
+++ global_setup.c 2001/09/14 13:22:36
@@ -7,7 +7,7 @@
*/
#define INSIDE_GLOBAL_SETUP
-#include parrot.h
+#include parrot/parrot.h
void
init_world() {
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.9
diff -u -r1.9 interpreter.c
--- interpreter.c 2001/09/14 10:54:23 1.9
+++ interpreter.c 2001/09/14 13:22:36
@@ -5,8 +5,8 @@
*/
-#include parrot.h
-#include interp_guts.h
+#include parrot/parrot.h
+#include parrot/interp_guts.h
void
runops (struct Perl_Interp *interpreter, IV *code) {
Index: interpreter.h
===
RCS file: /home/perlcvs/parrot/interpreter.h,v
retrieving revision 1.4
diff -u -r1.4 interpreter.h
--- interpreter.h 2001/09/13 08:44:08 1.4
+++ interpreter.h 2001/09/14 13:22:36
@@ -9,7 +9,7 @@
#if !defined(PARROT_INTERPRETER_H_GUARD)
#define PARROT_INTERPRETER_H_GUARD
-#include parrot.h
+#include parrot/parrot.h
struct Perl_Interp {
struct IReg *int_reg;/* Current top of int reg stack */
Index: memory.c
===
RCS file: /home/perlcvs/parrot/memory.c,v
retrieving revision 1.5
diff -u -r1.5 memory.c
--- memory.c2001/09/14 11:01:40 1.5
+++ memory.c2001/09/14 13:22:36
@@ -4,7 +4,7 @@
*
*/
-#include parrot.h
+#include parrot/parrot.h
/* Allocate a chunk of memory aligned on a power-of-2 boundary */
void *
Index: parrot.c
===
RCS file: /home/perlcvs/parrot/parrot.c,v
retrieving revision 1.1
diff -u -r1.1 parrot.c
--- parrot.c2001/08/29 12:07:03 1.1
+++ parrot.c2001/09/14 13:22:36
@@ -4,4 +4,4 @@
*
*/
-#include parrot.h
+#include parrot/parrot.h
Index: parrot.h
===
RCS file: /home/perlcvs/parrot/parrot.h,v
retrieving revision 1.5
diff -u -r1.5 parrot.h
--- parrot.h2001/09/13 08:44:08 1.5
+++ parrot.h2001/09/14 13:22:36
@@ -13,7 +13,7 @@
#define VAR_SCOPE extern
#endif
-#include config.h
+#include parrot/config.h
#include stdlib.h
#include stdio.h
@@ -46,15 +46,15 @@
typedef void STRING_FUNCS;
-#include global_setup.h
-#include string.h
-#include interpreter.h
-#include register.h
-#include exceptions.h
-#include memory.h
-#include bytecode.h
-#include io.h
-#include op.h
-#include events.h
+#include parrot/global_setup.h
+#include parrot/string.h
+#include parrot/interpreter.h
+#include parrot/register.h
+#include parrot/exceptions.h
+#include parrot/memory.h
+#include parrot/bytecode.h
+#include parrot/io.h
+#include parrot/op.h
+#include parrot/events.h
#endif
Index: register.c
===
RCS file: /home/perlcvs/parrot/register.c,v
retrieving revision 1.4
diff -u -r1.4 register.c
--- register.c 2001/09/14 09:03:44 1.4
+++ register.c 2001/09/14 13:22:37
@@ -4,7 +4,7 @@
*
*/
-#include parrot.h
+#include parrot/parrot.h
void
Parrot_push_i(struct Perl_Interp *interpreter) {
Index: register.h
RE: Half-completed parrot/parrot.h conversion?
The patch assumes that your source code directory is named parrot. This may have been an invalid assumption, but it is going to be hard to do this patch unless we agree on the name of the source directory. -Original Message- From: Gregor N. Purdy To: [EMAIL PROTECTED] Sent: 9/14/2001 11:20 AM Subject: Half-completed parrot/parrot.h conversion? All -- When I updated my sandbox this morning, I discovered that some files wanted includes from ./parrot/*.h. So, I had to create the directory manually, and did a bunch of ln foo.h parrot/foo.h's until I got no more complaints. Is someone in the middle of the change, or was it missed? Also, I had to edit my makefile to change '-I..' to '-I.' for things to work... Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
[PATCH]Assemble.pl and config_h.in
Ok, my previous patch to assemble.pl caused somethings to core dump...I
promise this one won't :) It fixes the problem with numeric values having
the wrong pack type. Also, config_h.in was changed to typedef ${iv} double
NV to typedef ${nv} NV
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.17
diff -u -r1.17 assemble.pl
--- assemble.pl 2001/09/14 09:57:01 1.17
+++ assemble.pl 2001/09/14 16:28:08
@@ -202,7 +202,7 @@
$args[$_]=oct($args[$_]) if($args[$_]=~/^0/);
$pc+=$sizeof{$rtype};
}
-$bytecode .= pack $type, $args[$_];
+$bytecode .= pack $pack_type{$type}, $args[$_];
}
if($options{'listing'}) {
# add line to listing.
Index: config_h.in
===
RCS file: /home/perlcvs/parrot/config_h.in,v
retrieving revision 1.1
diff -u -r1.1 config_h.in
--- config_h.in 2001/09/14 09:57:02 1.1
+++ config_h.in 2001/09/14 16:28:08
@@ -7,7 +7,7 @@
#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
typedef ${iv} IV;
-typedef ${iv} double NV;
+typedef ${nv} NV;
typedef struct _vtable VTABLE;
typedef void DPOINTER;
RE: Half-completed parrot/parrot.h conversion?
Ok, I'll fix it to where all header files are in a separate parrot subdirectory. -Original Message- From: Dan Sugalski To: Gibbs Tanton - tgibbs Cc: [EMAIL PROTECTED] Sent: 9/14/2001 12:36 PM Subject: RE: Half-completed parrot/parrot.h conversion? At 01:03 PM 9/14/2001 -0400, Gregor N. Purdy wrote: Gibbs -- The patch assumes that your source code directory is named parrot. This may have been an invalid assumption, but it is going to be hard to do this patch unless we agree on the name of the source directory. Ah. I try not to assume the source directory name, since folks might rename it for various reasons (for instance, I always check out CVS code as foo-cvs rather than just foo to call my attention to it in its parent directory). I think that, if we're going to put the includes in the parrot subdir, there should be a parrot/ under the CVS root dir. Whether we put all the source there or not's a separate problem. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Half-completed parrot/parrot.h conversion?
Okeydokey. As all header files are already included as parrot/x.h then the following should be done: 1.) create an include/parrot directory under the main source directory 2.) move all .h files into include/parrot 3.) add -I./include to Configure.pl any objections? -Original Message- From: Andy Dougherty To: Gibbs Tanton - Tgibbs Cc: 'Dan Sugalski '; '[EMAIL PROTECTED] ' Sent: 9/14/2001 1:24 PM Subject: RE: Half-completed parrot/parrot.h conversion? On Fri, 14 Sep 2001, Gibbs Tanton - Tgibbs wrote: Ok, I'll fix it to where all header files are in a separate parrot subdirectory. Sigh. Here's my original proposal again. cd parrot # Or wherever you've got the parrot source. mkdir include mkdir include/parrot mv *.h include/parrot changing parrot.h to do #include parrot/config.h and then changing Makefile to add -I./include to CCFLAGS. The reason you don't just want a parrot/ subdirectory is that you might want to build an executable named 'parrot' that would conflict with the directory name. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
RE: Half-completed parrot/parrot.h conversion?
Since we are so early in the game, I'm not sure if it really matters whether we keep the version information or not. Does anyone have a problem with me deleting the header files and readding them under include/parrot/. or is the general concensus moving the RCS files? Also, would anyone like to see a standard C comment header that includes the RCS information added to each file? Thanks! Tanton -Original Message- From: Robert Spier To: [EMAIL PROTECTED] Sent: 9/14/2001 3:11 PM Subject: RE: Half-completed parrot/parrot.h conversion? Quoting Dan Sugalski [EMAIL PROTECTED]: Hmmm. I think we need a reorg of the source directories, then. I'll get with Simon and coordinate doing this. (It's going to make CVS *so* happy... :) It's often easier to do this by moving the RCS files inside the CVS respository directly - it's cleaner because you keep the per-file versioning information, which is more important than the location information which gets lost. Otherwise you end up with a delete this file and recreate it elsewhere as r1.1. -R
coding standards
Below is memory.c changed to support all (I think) of the coding standards.
Please look it over and let me know. Once the powers that be give the ok, I
will try to change all the source files to the standard.
Thanks!
Tanton
/* Memory.c
* Copyright: (When this is determined...it will go here)
* CVS Info
* $RCSfile: $
* $Revision: $
* $Date: $
* Overview:
* The memory (mem) API handles memory allocation
* Data Structure and Algorithms:
* History:
* Notes:
* References:
*/
#include parrot/parrot.h
/*=for api mem mem_allocate_aligned
Allocate a chunk of memory aligned on a power-of-2 boundary
*/
void *
mem_allocate_aligned(IV size) {
IV max_to_alloc;
IV mask;
IV i;
void *mem = NULL;
/* Okay, we just brute-force things here. Yeah it's stupid, but it
works */
for (i = 1; i 0xff; i = 1) {
if (size i) {
mask = ~(i*2 - 1);
max_to_alloc = i*4;
}
else {
break;
}
}
mem = malloc(max_to_alloc);
if (((IV)mem mask) (IV)mem) {
mem = (void *)(((IV)mem mask) + ~mask + 1);
}
return mem;
}
/*=for api mem mem_sys_allocate
uses malloc to allocate system memory
*/
void *
mem_sys_allocate(IV size) {
return malloc(size);
}
/*=for api mem mem_setup_allocator
initializes the allocator
*/
void
mem_setup_allocator(struct Perl_Interp *interpreter) {
}
/*
*Local Variables:
*c-indentation-style: bsd
*c-basic-offset: 4
*indent-tabs-mode: nil
*End
*
*vim: expandtab shiftwidth=4:
*/
RE: coding standards
Sorry...forgot the tabs...this one should be right. memory.c
RE: [PATCH] testsuite and Win32 compilation
## +#if defined(WIN32)
## +program_code = malloc( file_stat.st_size );
## +#else
#Should we be using malloc, or are we supposed to use our own allocator?
#(I haven't been munging in the C, so I don't really know--it just looks
#a little suspicious.)
In memory.{h,c} there is a mem_sys_allocate(IV) that I would suggest.
[PATCH]Transcendental Math Functions
I've never submitted a patch before, but here goes...
Here are the transcendental math functions.
A couple of notes:
1.) I had to change the real type of n to a 'd' for it to output
the correct type in the pack in the assembler. It was already
a 'd' in the disassembler. I also changed all of the i's to l's to
match the disassembler.
2.) I'm using the standard C math functions. I don't know if we want
to always do this, but it is a start. However, I don't include
-lm in the Makefile. Mainly because it didn't work in cygwin.
Does this need to be added to the configure system?
3.) I changed the regex for interp_guts.h in assemble.pl and
disassemble.pl to find 0-9 in the opcode names as well
(for atan2 and log10).
4.) Certain math functions aren't in the std C library (i.e. log2 and
asec). Someone might want to check my math.
5.) Attached is a .pasm file that will execute each one of these
op codes, I plan to have a perl test soon.
Thanks!
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.8
diff -u -r1.8 assemble.pl
--- assemble.pl 2001/09/12 09:54:46 1.8
+++ assemble.pl 2001/09/13 06:45:11
@@ -16,20 +16,20 @@
n = 'd',
);
-my %real_type=('i'='i',
- 'n'='n',
- 'N'='i',
- 'I'='i',
- 'S'='i',
- 's'='i',
- 'D'='i');
+my %real_type=('i'='l',
+ 'n'='d',
+ 'N'='l',
+ 'I'='l',
+ 'S'='l',
+ 's'='l',
+ 'D'='l');
my $sizeof_packi = length(pack($pack_type{i},1024));
open GUTS, interp_guts.h;
my $opcode;
while (GUTS) {
-next unless /\tx\[(\d+)\] = ([a-z_]+);/;
+next unless /\tx\[(\d+)\] = ([a-z0-9_]+);/;
$opcodes{$2}{CODE} = $1;
}
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.8
diff -u -r1.8 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/12 18:39:12 1.8
+++ basic_opcodes.ops 2001/09/13 06:45:12
@@ -5,6 +5,7 @@
*/
#include parrot.h
+#include math.h
// SET Ix, CONSTANT
AUTO_OP set_i_ic {
@@ -329,3 +330,205 @@
// NOOP
AUTO_OP noop {
}
+
+// TRANSCENDENTAL MATH FUNCTIONS
+
+// sin_n_n
+AUTO_OP sin_n_n {
+ NUM_REG(P1) = sin(NUM_REG(P2));
+}
+
+// cos_n_n
+AUTO_OP cos_n_n {
+ NUM_REG(P1) = cos(NUM_REG(P2));
+}
+
+// tan_n_n
+AUTO_OP tan_n_n {
+ NUM_REG(P1) = tan(NUM_REG(P2));
+}
+
+// sec_n_n
+AUTO_OP sec_n_n {
+ NUM_REG(P1) = ((NV)1) / cos(NUM_REG(P2));
+}
+
+// atan_n_n
+AUTO_OP atan_n_n {
+ NUM_REG(P1) = atan(NUM_REG(P2));
+}
+
+// atan2_n_n_n
+AUTO_OP atan2_n_n_n {
+ NUM_REG(P1) = atan2(NUM_REG(P2), NUM_REG(P3));
+}
+
+// asin_n_n
+AUTO_OP asin_n_n {
+ NUM_REG(P1) = asin(NUM_REG(P2));
+}
+
+// acos_n_n
+AUTO_OP acos_n_n {
+ NUM_REG(P1) = acos(NUM_REG(P2));
+}
+
+// asec_n_n
+AUTO_OP asec_n_n {
+ NUM_REG(P1) = acos(((NV)1) / NUM_REG(P2));
+}
+
+// cosh_n_n
+AUTO_OP cosh_n_n {
+ NUM_REG(P1) = cosh(NUM_REG(P2));
+}
+
+// sinh_n_n
+AUTO_OP sinh_n_n {
+ NUM_REG(P1) = sinh(NUM_REG(P2));
+}
+
+// tanh_n_n
+AUTO_OP tanh_n_n {
+ NUM_REG(P1) = tanh(NUM_REG(P2));
+}
+
+// sech_n_n
+AUTO_OP sech_n_n {
+ NUM_REG(P1) = ((NV)1) / cosh(NUM_REG(P2));
+}
+
+// log2_n_n
+AUTO_OP log2_n_n {
+ NUM_REG(P1) = log(NUM_REG(P2)) / log((NV)2);
+}
+
+// log10_n_n
+AUTO_OP log10_n_n {
+ NUM_REG(P1) = log10(NUM_REG(P2));
+}
+
+// ln_n_n
+AUTO_OP ln_n_n {
+ NUM_REG(P1) = log(NUM_REG(P2));
+}
+
+// exp_n_n
+AUTO_OP exp_n_n {
+ NUM_REG(P1) = exp(NUM_REG(P2));
+}
+
+// pow_n_n_n
+AUTO_OP pow_n_n_n {
+ NUM_REG(P1) = pow(NUM_REG(P2), NUM_REG(P3));
+}
+
+// sin_n_i
+AUTO_OP sin_n_i {
+ NUM_REG(P1) = sin(INT_REG(P2));
+}
+
+// cos_n_i
+AUTO_OP cos_n_i {
+ NUM_REG(P1) = cos(INT_REG(P2));
+}
+
+// tan_n_i
+AUTO_OP tan_n_i {
+ NUM_REG(P1) = tan(INT_REG(P2));
+}
+
+// sec_n_i
+AUTO_OP sec_n_i {
+ NUM_REG(P1) = ((NV)1) / cos(INT_REG(P2));
+}
+
+// atan_n_i
+AUTO_OP atan_n_i {
+ NUM_REG(P1) = atan(INT_REG(P2));
+}
+
+// atan2_n_n_i
+AUTO_OP atan2_n_n_i {
+ NUM_REG(P1) = atan2(NUM_REG(P2), INT_REG(P3));
+}
+
+// atan2_n_i_n
+AUTO_OP atan2_n_i_n {
+ NUM_REG(P1) = atan2(INT_REG(P2), NUM_REG(P3));
+}
+
+// atan2_n_i_i
+AUTO_OP atan2_n_i_i {
+ NUM_REG(P1) = atan2(INT_REG(P2), INT_REG(P3));
+}
+
+// asin_n_i
+AUTO_OP asin_n_i {
+ NUM_REG(P1) = asin(INT_REG(P2));
+}
+
+// acos_n_i
+AUTO_OP acos_n_i {
+ NUM_REG(P1) = acos(INT_REG(P2));
+}
+
+// asec_n_i
+AUTO_OP asec_n_i {
+ NUM_REG(P1) = acos(((NV)1) / ((NV)INT_REG(P2)));
+}
+
+// cosh_n_i
+AUTO_OP cosh_n_i {
+ NUM_REG(P1) = cosh(INT_REG(P2));
+}
+
+// sinh_n_i
+AUTO_OP sinh_n_i {
+ NUM_REG(P1) = sinh(INT_REG(P2));
+}
+
+// tanh_n_i
+AUTO_OP tanh_n_i {
+ NUM_REG(P1) = tanh(INT_REG(P2));
+}
+
+// sech_n_i
+AUTO_OP sech_n_i {
+ NUM_REG(P1) = ((NV)1) /
[PATCH]Assembler.pl
This patch allows 0-9 in the opcode name (for atan2 and log10 etc...). It
also uses the pack_type hash for the pack instead of the real_type.
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.11
diff -u -r1.11 assemble.pl
--- assemble.pl 2001/09/13 13:42:41 1.11
+++ assemble.pl 2001/09/13 14:37:43
@@ -31,7 +31,7 @@
open GUTS, interp_guts.h;
my %opcodes;
while (GUTS) {
-next unless /\tx\[(\d+)\] = ([a-z_]+);/;
+next unless /\tx\[(\d+)\] = ([a-z0-9_]+);/;
$opcodes{$2}{CODE} = $1;
}
close GUTS;
@@ -127,7 +127,7 @@
foreach (0..$#args) {
my($rtype)=$opcodes{$opcode}{RTYPES}[$_];
-my($type)=$opcodes{$opcode}{TYPES}[$_];
+my($type)=$pack_type{$opcodes{$opcode}{TYPES}[$_]};
if($rtype eq I || $rtype eq N || $rtype eq P || $rtype eq
S) {
# its a register argument
RE: [PATCH]Assembler.pl
Because of some of the changes to the assembler...my patch no longer applies
cleanly. Therefore, I'm resubmitting it. When we changed assemblers, the
new assembler did not correctly support the transcendental math
functions...this patch fixes that.
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.14
diff -u -r1.14 assemble.pl
--- assemble.pl 2001/09/13 16:29:24 1.14
+++ assemble.pl 2001/09/13 17:38:42
@@ -31,7 +31,7 @@
open GUTS, interp_guts.h;
my %opcodes;
while (GUTS) {
-next unless /\tx\[(\d+)\] = ([a-z_]+);/;
+next unless /\tx\[(\d+)\] = ([a-z0-9_]+);/;
$opcodes{$2}{CODE} = $1;
}
close GUTS;
@@ -135,7 +135,7 @@
foreach (0..$#args) {
my($rtype)=$opcodes{$opcode}{RTYPES}[$_];
-my($type)=$opcodes{$opcode}{TYPES}[$_];
+my($type)=$pack_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;
patch test3.pasm
test3.pasm needed an end at the end of the file. Here is the patch This should fix one of the bugs reported by purify. Index: test3.pasm === RCS file: /home/perlcvs/parrot/t/test3.pasm,v retrieving revision 1.1 diff -u -r1.1 test3.pasm --- test3.pasm 2001/09/10 22:18:43 1.1 +++ test3.pasm 2001/09/13 20:36:28 @@ -194,4 +194,4 @@ print_i I1 pop_i print_i I1 - \ No newline at end of file +end \ No newline at end of file
parrot/config.h patch
I have a patch that puts parrot/ in front of all the header files and adds -I.. to the makefile. However, I will wait until some of the other patches get applied because my version is extremely hacked up and I don't want to keep sending all these patches munged together.
