Re: [perl #23135] Build fails under Win32
> Jonathan Worthington:
> > LIB : fatal error LNK1181: cannot open input file "jit_cpu.obj"
> > NMAKE : fatal error U1077: 'lib' : return code '0x49d'
> > Stop.
>
> There *is* code in config/auto/jit.pl to disable JIT on Win32, so I'm not
> sure why Parrot's trying to compile it. I *do* know that it was working
> fine before the exec stuff went in--perhaps looking at the diffs on jit.pl
> will be enlightening. Unfortunately, I'm away from my home computer and I
> don't have a C compiler or toolkit, so I can't work it out myself.
DONE. Have a nice vacation, Brent!
Index: jit.pl
===
RCS file: /cvs/public/parrot/config/auto/jit.pl,v
retrieving revision 1.18
diff -r1.18 jit.pl
71c71
< if (-e "jit/$cpuarch/core.jit") {
---
> if (-e "jit/$cpuarch/core.jit" and not $osname == 'MSWin32') {
Re: approaching python
Benjamin Goldberg wrote:
>
>Joseph Ryan wrote:
>
>>Benjamin Goldberg wrote:
>>
>>>K Stol wrote:
>>>
The register stuff, I presume, is register allocation and the like?
When targeting IMCC, you can use an infinite amount of registers. Just
keep a counter in the code generator, each time a new register is
needed, just increment the counter and add a "${S|N|I|P}" in front of
it (example: $P1). IMCC does register allocation and spilling.
So this is not really difficult.
>>>
>>>Nono, the problem isn't that python uses *more* registers than
>>>, but rather, that it doesn't use registers at all. Instead,
>>>it uses a stack. So, for example, python's add instruction might get
>>>translated into the following pir or pasm code:
>>>
>>> restore P0
>>> restore P1
>>> clone P0, P0
>>> add P0, P1
>>> save P0
>>>
>>>Needless to say, this is not efficient, due to how slow parrot's push
>>>and pop operations are.
>>
>>Well, thats because you're trying to make a register machine act like a
>>stack machine. It would be more efficient to translate add as:
>>
>>$P2 = $P0 + $P1
>>
>>That is to say, map stack positions to registers by simulating the
>>stack while walking each op during translation time, rather than
>>during runtime. So, in this case, the code that translates the add
>>instruction might look something like:
>>
>>translate_add_op {
>>pop variable1 off of simulated stack
>>pop variable2 off of simulated stack
>>create new temp pmc
>>push new temp_pmc onto simulated stack
>>print temp_pmc's name
>>print " = "
>>print variable1's name
>>print " + "
>>print variable2's name
>>}
>>
>>So, after this code, our simulated stack is depleted by two items
>>(the operands), and then replenished by one (the result); this
>>makes it act exactly like the real stack, except that we are
>>manipulating the registers rather than the values.
>
>
>The problem with this approach is that for every single stack-based
>language which we want to run on parrot, we have to do this same thing.
>
Is this really a problem? Its takes a very minimal amount of work to
do. I think that its fine, especially considering that the alternative
is to implement a pretty heavy-weight feature into IMCC.
>>>Hmm... If imcc is smart enough, (or perhaps I should say, when the
>>>flow control is simple/clear enough) it should be able to see when a
>>>value is pushed onto the stack, and later popped off, when there are
>>>enough registers free that we could have stored it in a spare register
>>>instead of on the stack. That is, a sort of register *un*spilling.
>>
>>Doesn't IMCC already do this?
>
I think I misunderstood you. However, I still don't see this would be
helpful. How would IMCC know which save/restore are associated with
"the" stack, and which are "normal" save/restore? (i.e., associated
with parameters/results from a subroutine) Unless I'm missing
something, you'd have to between those two sets of use...
- Joe
--
This message was sent using 3wmail.
Your fast free POP3 mail client at www.3wmail.com
Re: [CVS ci] make: print filenames only
> Echoing all compiler flags clutters the screen too much, so that > warnings easily can get missed. > Earlier I used to run "make -s" which silents "make". > Still better would be: > - echo compiler flags once > - echo filenames only > - let the work depending on "-s" was given to "make" or not or such Yepper. Leo is right. Most of output produced by make is such a bore. I'm standing for doing these actions as default, namely: 1) we output "Supplying the following c compiler flags: -Zi -DDEBUGGING-nologo ..." once at the begining 2) ouput "Building the classes ..." once and a name of each class as it being maked. 3) then "Linking the libraries: comdlg32.lib advapi32.lib shell32.lib " 4) and finally "Building documentation" And echoing the whole thingy as the case of the --detailed switch being passed. It wouldn't be worth anything to type the only switch for who really wants the full output.
Patch status
I have a question about the status of my patches: [perl #23034][PATCH] Implementation of methods for PIOs [perl #23124][PATCH] [PATCH] Standard filehandles in the interpreter are now PMCs. There was very little feedback to this. Can someone give me some feedback to the patches or if thats not possible just apply them? Its not so simple if my trees diverge from current CVS. Thanks boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfC] Clean up of the ParrotIOLayerAPI
This should go to the list also: "Gregor N. Purdy" <[EMAIL PROTECTED]> writes: > Juergen -- > > Juergen Boemmels wrote: > > > Write > > PutS > > Why are there two diffrent calls to write data to an io, with only a > > slightly different prototype. This is code-duplication in every > > layer. I can't think of any use case where PutS won't be implemented > > as Write(..., data, strlen(data)). These two calls could be unified. > > As a side note: The primary memory structure is the buffer, maybe > > the unified call should take a buffer argument. > > -> unify these two > > We need to be careful here about the difference between C strings and > Parrot strings. For your basic C string strlen(data) is the way to > decide how many bytes to write. For Parrot strings, we can have > internal zero bytes (or the lack of a trailing zero byte) that will > throw off strlen and therefore screw things up. I'm not arguing for removing PIO_puts et al., I want to remove ParrotIOLayerAPI.PutS. Both calls Write and PutS take a pointer to raw data; the first one with a len, the second one with terminating '\0'-byte. There is no version which takes a Parrot-String with encodings. A unified version of ParrotIOLayerAPI.Write might have the signature Write(struct ParrotInterp *, ParrotIOLayer *, ParrotIO *, Buffer *); > I have a patch on my workstation (currently in transit from Cincinnati > to Seattle, so not accessible -- but, I've discussed a bit with Dan on > IRC) that tries to deal with this issue by having a "*c" (for C-style) > and a "*l" (for length-style) variant of a couple functions (including > changes to vtables stuff, IIRC). > > But, that leaves out another important piece: If we have a Parrot string > in some encoding, and we are going to Write/Put it to STDOUT, which is > headed for someone's terminal, we might need to do more than just blast > the buffer if we expect the user to do anything other than curse us and > our mothers. This is another problem. Should this recoding be done in the IO-subsystem? This data-recoding might be another layer on top of the others. But then the Parrot-String must be passed down to the layers. This demands even more a unified version, because the current version does not pass this information down. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Patch status
At 15:10 +0200 7/29/03, Juergen Boemmels wrote: I have a question about the status of my patches: [perl #23034][PATCH] Implementation of methods for PIOs [perl #23124][PATCH] [PATCH] Standard filehandles in the interpreter are now PMCs. There was very little feedback to this. Can someone give me some feedback to the patches or if thats not possible just apply them? Its not so simple if my trees diverge from current CVS. I know I'm still digging out from under the backlog YAPC created (I've not gotten through work backlog, let alone p6i, unfortunately) but I'll try and take a look at them as soon as I can. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #23159] Parrot SIGSEGV in scratchpad_find
# New Ticket Created by Jos Visser
# Please include the string: [perl #23159]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23159 >
Description:
The following PIR code causes parrot to dump core:
.sub_main
find_lex $P1,"n"
print $P1
print "\n"
end
.end
Failing routine:
Under GDB it says:
Program received signal SIGSEGV, Segmentation fault.
0x080a4323 in scratchpad_find (interp=0x817f2f8, pad=0x0, name=0x40408b5c,
position=0xbfffd850) at sub.c:180
180 for (i = pad->cache.int_val - 1; i >= 0; i--) {
Reason:
Variable "pad" is NULL!
Additional comments:
Trying to find a lexical when no pad is established is stupid. However,
I don't guess dumping core is the appropriate thing to do, returning
NULL from scratchpad_find probably is.
Patch:
I don't know if this is the appropriate patch, but still
Index: sub.c
===
RCS file: /cvs/public/parrot/sub.c,v
retrieving revision 1.28
diff -u -b -B -r1.28 sub.c
--- sub.c 21 Jul 2003 18:00:24 - 1.28
+++ sub.c 29 Jul 2003 13:35:55 -
@@ -177,6 +177,9 @@
INTVAL i, pos = 0;
struct Parrot_Lexicals * lex = NULL;
+if (!pad)
+return NULL;
+
for (i = pad->cache.int_val - 1; i >= 0; i--) {
lex = &(((struct Parrot_Lexicals *)PMC_data(pad))[i]);
pos = lexicals_get_position(interp, lex, name);
With this patch I get the error message "Lexical 'n' not found"..
Yours truly,
Jos Visser
--
ek is so lug jy vlieg deur my
sonder jou is ek sonder patroon
"Breyten Breytenbach"
Why we went with CPS for parrot
Klaas-Jan asked about this a while back--sorry it's taken so long to get an answer. If you read back through the list and other stuff I've written, it's pretty clear that while I like CPS, I wasn't convinced that CPS was the way to go, but if you look at the parrot code now, we use CPS. Why? First, it's important to know why I wasn't going to go with CPS. That's pretty straightforward--fear and uncertainty. I was uncertain they were sufficiently useful, and afraid that if we did go with them we'd end up with an engine that nobody would create code for and nobody'd be able to work on because we were using a scheme (pardon the pun) that noone understood. I don't mind pieces of something that only a dozen or two folks at any one time feel comfortable working on--you don't need that many people poking at the internals of the garbage collector--but we need to make sure that things are at intelligible to at least some folks. The uncertainty about their utility has been dealt with. Partly because of some of the needs that parrot has, and I'll talk about that a bit later, and partly because I've just gotten more comfortable with them. I had a fair amount of lingering discomfort with them that needed dealing with. The fear about scaring people off with them is gone as well--I understand them, I know how to explain them to people quickly and reasonably simply, and in a way that can deal with the knee-jerk fear often associated with them. (I'm convinced at this point that all of the fear people have about continuations is a direct result of how they're taught and what's associated with them, though that's a rant for another day. The reasons to use them fall out of two needs--the need for optimizations, and the amount of context that needs to be preserved across function calls. Optimizations are easy--having a CPS makes doing tail calls dead-simple. We can't always do tail calls, of course--they can have some issues with destruction timing guarantees and while we don't explicitly make those, it's not nice to surprise people when they haven't asked for it. Still, it's there for the using, and it means the difference between a deeply recursive algorithm dying a horrible death and running to completion. Besides, in a managed environment (and we are managed--while everything will ultimately be open to inspection there'll be some limits to what you can actually change) it can be quite difficult to implement tail calls without engine help. It's trivial to provide it, difficult to make it happen if we don't, and useful for the optimizer. Not a tough choice. Calling context is another big one. We have gobs of stacks, registers, context, and whatnot that need preserving, putting us far past the "stick the return value on the stack and branch off to wherever" style of calling code. Not only is there this stuff that's required at the user level, the interpreter has a lot of stuff it potentially needs to save--what runloop you had, what your security context was, what flags were in effect, and so on. What we were going to do, pre-CPS, was, in the caller: saveall call restoreall and the callee would do a: return The call would push all the interpreter info onto the call stack, along with the return point. Return uses that information to put things back on return. With a CPS style, that turns into: saveall callcc restoreall with the callee doing invoke Px with Px being the register holding the return continuation in it. Generally P1, but that's not required. (In both cases, the sub/method to be invoked has to be in P0 so no parameters are needed for the call) You'll note two differences: We spell return "invoke" in the CPS version and give it a parameter, and give call the "cc" suffix. Ooohhh, scary! We could, of course, make the state saving explicit, rather than rolling it up with the call in the first example, but since we must save the state in all cases, there's little point in doing that. Mandatory state saving is fine, making it mandatory but not automatically doing it is silly. Someone'll forget and things will go bang, or we'll get odd security holes. Interestingly, it also means that if you squint a bit and don't think too hard about it (and generally you won't) the only difference between a CPS scheme and the old scheme is we pass in the "return object" as a parameter, rather than put it on the stack. We could even rename the ops if we so chose, though the old jsr/ret style of calling is being preserved for a variety of reasons, so we're not going to. Security is something of a concern--since a sub/method boundary is also a privilege boundary (which is to say that code on one side of a sub may have more or fewer privs than the other side) all the state saving, restoring, and respecting has to be handled by the interpreter. That's a good reason to not even give the option of managing interpreter state manually, since that's d
Re: Patch status
Juergen Boemmels wrote: I have a question about the status of my patches: [perl #23034][PATCH] Implementation of methods for PIOs [perl #23124][PATCH] [PATCH] Standard filehandles in the interpreter are now PMCs. There was very little feedback to this. I didn't have a closer look yet, but they seem to be ok. If there are no negative opinions (and if still unapplied) I'll check them in tomorrow. ...Its not so simple if my trees diverge from current CVS. Yep, that's true. Thanks boe leo
This week's Perl 6 Summary
Perl 6 Summary for the week ending 20030727 Welcome to another in the ongoing series of Perl 6 summaries in which your faintly frazzled summarizer attempts to find a native speaker of Esperanto to translate this opening paragraph in honour of the huge amount of money (1371 Euros) raised for TPF during the YAPC::Europe auction, when the official language of both London.pm and Paris.pm's websites were auctioned off as one lot. Somewhat to the surprise of everyone, the winning bid was for Esperanto. As Jouke Visser just commented on IRC, the price was well worth paying just to see the looks of panic on the faces of Mark Fowler, Leon Brocard and other London.pm worthies as the price of keeping the website English (and changing Paris.pm's website to English in the process) shot up beyond the reach of their collective pocket. Meanwhile, we'll return to English and start with the internals list as usual. Events Junior reporter: "Mr Macmillan, what caused your greatest difficulties in your time as UK Prime Minister?" Macmillan: "Events dear boy, events." Whilst I'm not sure Dan would fully agree with Macmillan, there was a certain amount of concern about Events (well, event handling). Damien Neil is still convinced that asynchronous IO is the Wrong Thing, but he hasn't convinced Dan, and (in this at least) it's Dan's opinion that counts. http://xrl.us/nj3 http://xrl.us/nj4 -- Dan ditches the cranky reply Memory system issues Jürgen Bömmels' work on the aforementioned Asynchronous IO system means that he's been getting rather more involved with the internals of Parrot's memory allocation and Garbage Collection system than he intended. He had a few questions, which Dan answered. http://xrl.us/nj5 Splitting core.ops Brent Dax announced that the patch splitting core.ops into a slightly more logical set of smaller files has been committed. This occasioned a small flurry of discussion and a smaller flurry of patches to ensure that all the new .ops files had their associated documentation files built. http://xrl.us/nj6 Parrot docs translated to Japanese Koichi Sasada, a Japanese university student has translated the Parrot Primer into Japanese and put it on his website. He wanted to know if he could publicise the translation. This summary is (at least in part) his answer. http://xrl.us/nj7 http://xrl.us/nj8 -- In English http://xrl.us/nj9 -- In Japanese PMC methods Luke Palmer can't stop thinking of other ideas as he works on implementing lazy PMCs. His latest idea relates to accessing methods on PMCs without having to generate scads of new opcodes (Personally, I don't see what's wrong with using the object stuff for getting both PMC vtable (C) methods and methods that are implemented in Parrot itself.) Luke proposed a few ops which he reckons will solve the problem. http://xrl.us/nka objects.t Failures Simon Glover tracked down a problem with the objects.t test file that had been failing on some, but not all platforms. It turns out that the class_hash wasn't included as part of the root set, which meant that the garbage collector could try to reclaim it before it got used. Which is bad. He supplied a two line patch to fix the problem. Which is good. Dan made with the "D'oh!", commenting that he'd known he'd forgotten something. http://xrl.us/nkb RFC: Cleaning up the ParrotIOLayer API Jürgen Böemmels has reached a point in his redoing of the Parrot IO subsystem that he wanted to remove and/or rename several of the old methods so he posted an RFC explaining what he intended to do and asked for comments. Gregor N. Purdy had some comments, mostly to do with the data structures involved (with particular reference to strings) but other than that there has been no further comment. http://xrl.us/nkc Parrot Emits an Executable Daniel Grunblatt checked in a patch to make parrot generate native executables. There are caveats about what must be done in order to get a working executable and the original patch needed to have a few wrinkles ironed out, but this looks like a fantastic start to me. http://xrl.us/nkd Approaching Python Michael Wallace wondered about the issue of compiling python to parrot. He wondered if it would be possible to make use of the existing Python compiler module which generates python bytecode from a parse tree. He wondered if it'd be worthwhile modifying it to generate parrot bytecode. The discussion which followed covered various options for handling Python code, ranging from bytecode transformation to translating the source code into Perl 6 (which is probably the least likely to save Dan from pie). I'm not sure if a particular approach was chosen, but Micha
Re: [perl #23159] Parrot SIGSEGV in scratchpad_find
--- Jos Visser <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Jos Visser
> # Please include the string: [perl #23159]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=23159 >
>
>
>
> Description:
>
> The following PIR code causes parrot to dump core:
>
> .sub _main
> find_lex $P1,"n"
> print $P1
> print "\n"
> end
> .end
>
>
> Failing routine:
>
> Under GDB it says:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x080a4323 in scratchpad_find (interp=0x817f2f8, pad=0x0, name=0x40408b5c,
> position=0xbfffd850) at sub.c:180
> 180 for (i = pad->cache.int_val - 1; i >= 0; i--) {
>
>
> Reason:
>
> Variable "pad" is NULL!
>
>
> Additional comments:
>
> Trying to find a lexical when no pad is established is stupid. However,
> I don't guess dumping core is the appropriate thing to do, returning
> NULL from scratchpad_find probably is.
>
>
> Patch:
>
> I don't know if this is the appropriate patch, but still
>
> Index: sub.c
> ===
> RCS file: /cvs/public/parrot/sub.c,v
> retrieving revision 1.28
> diff -u -b -B -r1.28 sub.c
> --- sub.c 21 Jul 2003 18:00:24 - 1.28
> +++ sub.c 29 Jul 2003 13:35:55 -
> @@ -177,6 +177,9 @@
> INTVAL i, pos = 0;
> struct Parrot_Lexicals * lex = NULL;
>
> +if (!pad)
> +return NULL;
> +
> for (i = pad->cache.int_val - 1; i >= 0; i--) {
> lex = &(((struct Parrot_Lexicals *)PMC_data(pad))[i]);
> pos = lexicals_get_position(interp, lex, name);
>
>
> With this patch I get the error message "Lexical 'n' not found"..
I don't think it's worth adding extra overhead to lexical variables just to
support broken pasm. There are many ways to crash parrot with bad code - but
it's OK, since compilers of higher level languages simply won't generate
them. :)
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: [perl #23135] Build fails under Win32
--- Vladimir Lipskiy <[EMAIL PROTECTED]> wrote:
> > Jonathan Worthington:
> > > LIB : fatal error LNK1181: cannot open input file "jit_cpu.obj"
> > > NMAKE : fatal error U1077: 'lib' : return code '0x49d'
> > > Stop.
>
> >
> > There *is* code in config/auto/jit.pl to disable JIT on Win32, so I'm not
> > sure why Parrot's trying to compile it. I *do* know that it was working
> > fine before the exec stuff went in--perhaps looking at the diffs on
> jit.pl
> > will be enlightening. Unfortunately, I'm away from my home computer and
> I
> > don't have a C compiler or toolkit, so I can't work it out myself.
>
> DONE. Have a nice vacation, Brent!
>
> Index: jit.pl
> ===
> RCS file: /cvs/public/parrot/config/auto/jit.pl,v
> retrieving revision 1.18
> diff -r1.18 jit.pl
> 71c71
> < if (-e "jit/$cpuarch/core.jit") {
> ---
> > if (-e "jit/$cpuarch/core.jit" and not $osname == 'MSWin32') {
Hey, I use win32 (mingw) and the JIT has always worked fine for me. If this
is an issue with MSVC, it should be specific about that
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: parrot on HP-UX etc
On Tue 29 Jul 2003 16:40, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Hi Merijn, > > > Available: > > > > HP-UX 11.00 32bit 1 or 2 CPU's HP C-ANSI-C and gcc-3.3 > > HP-UX 11.00 64bit 1 or 2 CPU's HP C-ANSI-C and gcc-3.3 > > HP-UX 10.20 32bit HP C-ANSI-C and gcc-3.3 > > AIX 4.3 32bit IBM vac-5 and gcc-3.3.1 > > SuSE 8.232bit gcc-3.3 > > Win2k/Cygwin-1.3.23s 32bit gcc-3.2 prerelease > > > > All with perl-5.8 and perl-5.9 > > > > What's the info you want/need? > > Do these boxen correctly run parrot and the tests ;-) > $ make realclean > $ perl Configure.pl # [1] I'll use perl-5.8.0 with defined-or > $ make HP-UX 11.00/32 2 CPU: : io/io_buf.c cpp: "io/io_buf.c", line 65: warning 2001: Redefinition of macro MAX. cpp: "io/io_buf.c", line 66: warning 2001: Redefinition of macro MIN. : Scanning /pro/3gl/CPAN/parrot/classes/timer.pmc... cc -Ae -DDEBUGGING -D_HPUX_SOURCE -Wl,+vnocompatwarnings -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64-I../include -o timer.o -c timer.c cc: "timer.c", line 75: error 1000: Unexpected symbol: "32". make[1]: *** [timer.o] Error 1 make[1]: Leaving directory `/pro/3gl/CPAN/parrot/classes' make: *** [classes/array.o] Error 2 : HP-UX 10.20/32: : Determining what pmc files should be compiled in...done. Tweaking ccflags...done. Determining your minimum pointer alignment... ... here it hangs. ... It is probably related to the same test that's always hanging in Digest::MD5-2.25 where it hangs in Testing alignment requirements for U32... I've mailed Gisle about that, but never got a reply. In MD5 all goes well if you hit ^C :/ AIX 4.3/32: : Generating config.h...value for 'execos' in config/gen/config_h/config_h.in is undef at lib/Parrot/Configure/Step.pm line 122, line 101. done. : perl pmc2c.pl timer.pmc Scanning /pro/3gl/CPAN/parrot/classes/timer.pmc... xlc -DDEBUGGING -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=16384 -qnoansialias -DUSE_NATIVE_DLOPEN -I/pro/local/include -q32 -D_LARGE_FILES -qlonglong -I../include -o timer.o -c timer.c "timer.c", line 75.5: 1506-275 (S) Unexpected text integer constant encountered. "timer.c", line 74.18: 1506-275 (S) Unexpected text ',' encountered. make[1]: *** [timer.o] Error 1 make[1]: Leaving directory `/pro/3gl/CPAN/parrot/classes' make: *** [classes/array.o] Error 2 SuSE 8.2 too busy smoking perl to do parrot ... Win2k + Cygwin-1.3.23s/32: : [ you don't want the full list :}} ] : : from parser_util.c:19: ../../include/parrot/packfile.h:145: warning: padding struct to align `u' In file included from ../../include/parrot/parrot.h:210, from imc.h:18, from parser_util.c:19: ../../include/parrot/io.h:149: warning: padding struct to align `fsize' In file included from ../../include/parrot/parrot.h:215, from imc.h:18, from parser_util.c:19: ../../include/parrot/intlist.h:37: warning: padding struct size to alignment bou ndary jit.c In file included from ../../include/parrot/string.h:19, from ../../include/parrot/register.h:16, from ../../include/parrot/interpreter.h:50, from ../../include/parrot/global_setup.h:18, from ../../include/parrot/parrot.h:195, from jit.c:20: ../../include/parrot/pobj.h:52: warning: padding struct size to alignment bounda ry In file included from ../../include/parrot/parrot.h:201, from jit.c:20: ../../include/parrot/hash.h:33: warning: padding struct to align `val' ../../include/parrot/hash.h:42: warning: padding struct to align `value' ../../include/parrot/hash.h:44: warning: padding struct size to alignment bounda ry In file included from ../../include/parrot/parrot.h:209, from jit.c:20: ../../include/parrot/packfile.h:145: warning: padding struct to align `u' In file included from ../../include/parrot/parrot.h:210, from jit.c:20: ../../include/parrot/io.h:149: warning: padding struct to align `fsize' In file included from ../../include/parrot/parrot.h:215, from jit.c:20: ../../include/parrot/intlist.h:37: warning: padding struct size to alignment bou ndary gcc -o imcc.exe -L/usr/local/lib imcparser.o imclexer.o imc.o stacks.o symreg.o instructions.o cfg.o sets.o debug.o optimizer.o pbc.o main.o parser_util.o jit. o ../../blib/lib/libparrot.a -lcrypt -lutil make[1]: Leaving directory `/P/parrot/languages/imcc' perl -MExtUtils::Command -e mv languages/imcc/imcc.exe parrot.exe cd languages/imcc && make && cd ../.. make[1]: Entering directory `/P/parrot/languages/imcc' gcc -o imcc.exe -L/usr/local/lib imcparser.o imclexer.o imc.o stacks.o symreg.o instructions.o cfg.o sets.o debug.o optimizer.o pbc.o main.o parser_util.o jit. o ../../blib/lib/libparrot.a -lcrypt -lutil make[1]: Leaving directory `/P/parrot/languages/imcc' cd docs && make && cd .. make[1]: Entering directo
Re: [perl #23135] Build fails under Win32
"Vladimir Lipskiy" <[EMAIL PROTECTED]> writes:
>> if (-e "jit/$cpuarch/core.jit" and not $osname == 'MSWin32'){
ITYM:
>> if (-e "jit/$cpuarch/core.jit" and $osname ne 'MSWin32') {
--
Lars Balker Rasmussen Consult::Perl
Re: parrot on HP-UX etc
On Tue, 29 Jul 2003, H.Merijn Brand wrote: > On Tue 29 Jul 2003 16:40, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > Hi Merijn, > > > HP-UX 11.00/32 2 CPU: > > : > io/io_buf.c > cpp: "io/io_buf.c", line 65: warning 2001: Redefinition of macro MAX. > cpp: "io/io_buf.c", line 66: warning 2001: Redefinition of macro MIN. The offending lines of io_buf.c are: #define MAX(a, b) ((a) > (b) ? (a) : (b)) #define MIN(a, b) ((a) < (b) ? (a) : (b)) There are a couple of obvious solutions here: i) Rename them to PARROT_MAX, PARROT_MIN ii) Get rid of them. I vote for option (ii), as otherwise someone is likely to write something like: MAX(a,b++) at some point in the future. Now, MAX doesn't appear to be in use at the moment, while MIN is only used in a couple of places, so it shuold be easy to patch this, but I'm going to hold off on doing this until Juergens latest IO patches have been applied. > Scanning /pro/3gl/CPAN/parrot/classes/timer.pmc... > cc -Ae -DDEBUGGING -D_HPUX_SOURCE -Wl,+vnocompatwarnings -I/pro/local/include > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64-I../include -o timer.o -c timer.c > cc: "timer.c", line 75: error 1000: Unexpected symbol: "32". > make[1]: *** [timer.o] Error 1 > make[1]: Leaving directory `/pro/3gl/CPAN/parrot/classes' > make: *** [classes/array.o] Error 2 This is odd -- on my machine, line 75 is in the middle of an enum, and looks perfectly fine to me. Could you post the offending section of timer.c? Simon PS Thanks for the report
[CVS ci] PCC 1-3
Parrot now has basic PCC (Parrot Calling Convention) support inside the PIR assembler. 1) no fancy stuff like register renumbering 2) only the upper half of all registers are preserved currently TODO: - tests - more tests - docs - still more tests - optimize register usage - tail call optimizations - check which registers have to be preserved over sub calls - preserve only necessary register sets - allocate regs that have not to be preserved in the lower half of regs - if too many regs have to be preserved then emit saveall/restoreall including save/restore return values around restoreall. Register allocation now starts at #16 for each set, giving 16 preserved registers for sub calls. That should be enough for first tests. SYNOPSIS: s. languages/imcc/docs/calling_conventions.pod Have fun, leo
Re: [perl #23135] Build fails under Win32
> > > There *is* code in config/auto/jit.pl to disable JIT on Win32, so I'm not > > > sure why Parrot's trying to compile it. I *do* know that it was working > > > fine before the exec stuff went in--perhaps looking at the diffs on jit.pl > > > will be enlightening. Unfortunately, I'm away from my home computer and > > > I don't have a C compiler or toolkit, so I can't work it out myself. > Hey, I use win32 (mingw) and the JIT has always worked fine for me. If this > is an issue with MSVC, it should be specific about that To learn from Brent Dax, it's a os specific problem. To be honest, I don't know much about JIT, as well as Parrot yet. I just did what Brent asked for. And it seems to me as if I overlooked the thread where Brent explained why he made up his mind to disabling JIT on Win32. Is there anybody who could drop a couple of lines on account of this question while Brent is unget-at-able?
Re: [perl #23135] Build fails under Win32
> >> if (-e "jit/$cpuarch/core.jit" and $osname ne 'MSWin32') {
Yeah, you're right. Thanks.
Index: jit.pl
===
RCS file: /cvs/public/parrot/config/auto/jit.pl,v
retrieving revision 1.18
diff -r1.18 jit.pl
71c71
< if (-e "jit/$cpuarch/core.jit") {
---
> if (-e "jit/$cpuarch/core.jit" and $osname ne 'MSWin32') {
Re: parrot on HP-UX etc
Index: io/io_buf.c
===
RCS file: /cvs/public/parrot/io/io_buf.c,v
retrieving revision 1.6
diff -u -r1.6 io_buf.c
--- io/io_buf.c 21 Jul 2003 18:00:45 - 1.6
+++ io/io_buf.c 29 Jul 2003 18:31:39 -
@@ -62,9 +62,6 @@
size_t PIO_buf_readthru(theINTERP, ParrotIOLayer *layer,
ParrotIO *io, void *buffer, size_t len);
-#define MAX(a, b) ((a) > (b) ? (a) : (b))
-#define MIN(a, b) ((a) < (b) ? (a) : (b))
-
/* XXX: This is not portable */
#define IS_EOL(c) ((*c) == '\n')
@@ -292,7 +289,7 @@
if (b->flags & PIO_BF_READBUF) {
size_t avail = b->endb - b->next;
-current = MIN(avail, len);
+current = avail < len ? avail : len;
memcpy(out_buf, b->next, current);
b->next += current;
@@ -323,7 +320,7 @@
got = PIO_buf_fill_readbuf(interpreter, l, io, b);
-len = MIN(len, got);
+len = len < got ? len : got;
}
/* read from the read_buffer */
--
Juergen Boemmels [EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: parrot on HP-UX etc
On 29 Jul 2003, Juergen Boemmels wrote: > Simon Glover <[EMAIL PROTECTED]> writes: > > > On Tue, 29 Jul 2003, H.Merijn Brand wrote: > > > iii) protect them with #ifdef MAX/#endif > > I bet the definition of MAX and MIN on HP-UX is identical to my > definition. I would not be surprised. > Ok, here is the patch for this. It should not give any problems with > my not yet applied patches. There will only be a line offset of 1. But > if there are problems i can easily rediff. Right, I've gone ahead and applied this. Thanks. Simon
[perl #23162] [PATCH] get miniparrot compile
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #23162]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23162 >
Hi,
I just tried to get
perl Configure.pl --miniparrot
running
following problems I need to solve:
In embed.c the type off_t is used which is defined in unistd.h but not
in plain ansi. In case there is no unistd.h I changed this type to
off_t.
Parrot_memalign is not defined in config/gen/platform/ansi.c. I
removed the tests for memalign in case of miniparrot.
There was also a little problem with io_stdio.c:
fopen (name, "r+") fails if the file does not exists. I added a check
for this and use "w+" in the case of nonexisting files.
Many tests are failing because of double close of the standard
file-descriptors. I will solve these after [perl #23124] is applied.
bye
boe
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/61930/45654/4e2e29/miniparrot.diff
Index: embed.c
===
RCS file: /cvs/public/parrot/embed.c,v
retrieving revision 1.75
diff -u -r1.75 embed.c
--- embed.c 21 Jul 2003 18:00:24 - 1.75
+++ embed.c 29 Jul 2003 18:49:55 -
@@ -16,7 +16,6 @@
#include "parrot/parrot.h"
#include "parrot/embed.h"
-
struct Parrot_Interp *
Parrot_new(void)
{
@@ -68,7 +67,11 @@
struct PackFile *
Parrot_readbc(struct Parrot_Interp *interpreter, char *filename)
{
+#if HAS_HEADER_UNISTD
off_t program_size, wanted;
+#else
+size_t program_size, wanted;
+#endif
char *program_code;
struct PackFile *pf;
PMC * io = NULL;
Index: config/auto/memalign.pl
===
RCS file: /cvs/public/parrot/config/auto/memalign.pl,v
retrieving revision 1.4
diff -u -r1.4 memalign.pl
--- config/auto/memalign.pl 13 Jul 2003 18:52:36 - 1.4
+++ config/auto/memalign.pl 29 Jul 2003 18:49:55 -
@@ -6,7 +6,17 @@
$description="Determining if your C library supports memalign...";
[EMAIL PROTECTED](miniparrot);
+
sub runstep {
+my ($miniparrot) = @_;
+
+if ($miniparrot) {
+Configure::Data->set(memalign => '');
+ print "(skipped)";
+ return;
+}
+
my $test = 0;
if (Configure::Data->get('i_malloc')) {
Index: io/io_stdio.c
===
RCS file: /cvs/public/parrot/io/io_stdio.c,v
retrieving revision 1.23
diff -u -r1.23 io_stdio.c
--- io/io_stdio.c 21 Jul 2003 18:00:45 - 1.23
+++ io/io_stdio.c 29 Jul 2003 18:49:55 -
@@ -130,6 +130,10 @@
/* Try opening the file- note that this can't really handle O_EXCL, etc. */
fptr = fopen(spath, oflags);
+if (fptr == NULL && errno == ENOENT && (flags & PIO_F_WRITE)) {
+fptr = fopen(spath, "w+b");
+}
+
/* File open */
if (fptr != NULL) {
if (PIO_isatty(fptr))
Re: PHP/Parrot
On 29 Jul 2003, Luke Palmer wrote: > > G'day, > > > > For a complete list of instructions, grab the cvs and look at the > various .ops files. They are scattered with POD documentation about > each op they implement. The same documentation can also be found in the docs/ops/ subdirectory -- it's generated from the .ops files at build time. There's also a master list of the different ops: /docs/pdds/pdd06_pasm.pod Unfortunately, this is somewhat out of date (although I'm working on getting it into shape). > > I see this page parrot website : > > http://www.parrotcode.org/docs/parrot.pod.html > > > > Is reading those documents my best bet? > > Definitely not. But it never hurts... > > > Some of them haven't been altered since '01 (and in fact one of them > > seems a verbatim copy of an article on perl.com). Does anyone have > > any other recommendatations? Should I just read the source? > > Basically yes, at this point. Again, the .ops files will probably be > the most useful for your purposes. I also strongly suggest reading the IMCC documentation in languages/imcc/docs -- IMCC is an intermediate code compiler that compiles something called Parrot Intermediate Language down to assembly and/or bytecode. IMCC will handle a lot of the low-level code generation details for you (eg. register spilling), so targeting this makes more sense than targeting Parrot assembler or Parrot bytecode directly. > > I'm not sure how I'm going to go about bootstrapping this (the > > bootstrapping must be done for 100% php compatibility because its > > 'include' operator is equivilient to reading a file and running > > eval($file_contents);). > > That's not a bootstrapping problem. You only need to bootstrap if php > actually parses itself with its own code. I don't think php is > powerful enough to do that ;-) > > What you want to do is write your parser in Python, and use the Parrot > embedding interface (only in C at the moment) to run your code. You > can register a compiler with Parrot, and it will call out to your > Python routine that parses and generates code. > > I see a problem, however. It's that you probably want to target IMCC > (Intermediate Code Compiler) when you're generating code, as opposed > to pure byte code (lest you reinvent several wheels). But, AFAIK, > IMCC has no such spiffy embedding interface. I'll let the IMCC > masters get back to you on that one. > > > If Parrot is eventually able to compile Python and that Python is > > capable of using C extensions, then it should be possible to simply > > use the compiler I've already written - Is that going to be even > > possible? > > Again, that's possible even if we don't support Python. Which we > don't. But we will :-) Well, it won't be us that get pelted with pie if we fail :-) But I digress... > > Using C extensions from Parrot-compiled bytecode? It seems thats in > > a bit of doubt (based on the comments about the Python compiler > > using C code and having to use a drop-in replacement code generator > > to solve the bootstrap issue). > Calling out from Parrot bytecode to external C library code should and will be possible - this is the purpose of the native call interface (NCI) routines that we already have. Unfortunately, this is one of those areas that isn't terribly well documented... Good luck, Simon
Re: [perl #23162] [PATCH] get miniparrot compile
On Tue, 29 Jul 2003, Jürgen Bömmels wrote: > # New Ticket Created by Jürgen Bömmels > # Please include the string: [perl #23162] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=23162 > Thanks, applied. miniparrot still doesn't build for me, incidentally -- it's dieing with: blib/lib/libparrot.a(timer.o): In function `recalc_ticks': /home/scog/bin/parrot/classes/timer.c:175: undefined reference to `get_sys_timer_ms' /home/scog/bin/parrot/classes/timer.c:210: undefined reference to `start_sys_timer_ms' /home/scog/bin/parrot/classes/timer.c:212: undefined reference to `stop_sys_timer_ms' blib/lib/libparrot.a(timer.o): In function `do_alarm_handler': /home/scog/bin/parrot/classes/timer.c:222: undefined reference to `get_sys_timer_ms' blib/lib/libparrot.a(timer.o): In function `Parrot_Timer_class_init': /home/scog/bin/parrot/classes/timer.c:611: undefined reference to `new_sys_timer_ms' but this seems unrelated to your patches, and I don't really have time to investigate further right now. Simon
Re: [perl #23159] Parrot SIGSEGV in scratchpad_find
On Tue, Jul 29, 2003 at 09:11:15AM -0700 it came to pass that Mr. Nobody wrote: > I don't think it's worth adding extra overhead to lexical variables just to > support broken pasm. There are many ways to crash parrot with bad code - but > it's OK, since compilers of higher level languages simply won't generate > them. :) I would call an "if (!pad) return 0;" hardly extra overhead (4 instructions on an Intel x86). There is a lot of stuff you can not do if this is the sort of overhead you are worried about. I was unaware that the entire parrot VM can crash due to bad code. I would argue that this is undesirable behaviour, because compiler writers are not perfect (as your smiley seems to indicate... :) I'd rather have a parrot thread crash with a more or less intelligeble error code than have the entire VM crash. However, this is a discussion that deserves a place (as far as it has not already taken place) of its own instead of being tagged to an unimportant issue such as this one... Anyway, the problem is obvious and so is the "solution". I leave it to the parrot gurus whether to include it in the source tree or not... ++Jos.es -- ek is so lug jy vlieg deur my sonder jou is ek sonder patroon "Breyten Breytenbach"
Re: [perl #23159] Parrot SIGSEGV in scratchpad_find
On Tue, 29 Jul 2003, Jos Visser wrote: > On Tue, Jul 29, 2003 at 09:11:15AM -0700 it came to pass that Mr. Nobody wrote: > > I don't think it's worth adding extra overhead to lexical variables just to > > support broken pasm. There are many ways to crash parrot with bad code - but > > it's OK, since compilers of higher level languages simply won't generate > > them. :) > > I would call an "if (!pad) return 0;" hardly extra overhead (4 > instructions on an Intel x86). There is a lot of stuff you can not do > if this is the sort of overhead you are worried about. > > I was unaware that the entire parrot VM can crash due to bad code. It's actually extremely easy to do; for instance, this: set I0, P10 end will segfault since Parrot tries to call get_integer on a NULL PMC (since there's nothing in P10 at startup). Now, this segfault can be avoided, just as the one you point out above can be avoided, but only at the cost of adding extra checks. The problem is that you wind up needing a LOT of these, if you're to guarantee that Parrot will never segfault when given bad code. So: in the individual case, the cost is not much (although branches are icky on modern processors due to deep pipelines), but in the aggregate it will be considerably more. Therefore the decision was taken that we should not guarantee that Parrot should never segfault when fed bad assembler; the creation of invalid assembler is a compiler bug, and should be fixed at the compiler level. (Note, however, that we should never segfault on _valid_ assembler). Hope that clarifies things, and thanks for the report and for the patch (even if we don't end up applying it). Simon
Re: cvs commit: parrot/docs/pdds pdd02_vtables.pod
Simon Glover <[EMAIL PROTECTED]> wrote: > Try and explain what invoke is supposed to do. NB this still needs work [ snip ] > +=item void* invoke(INTERP, PMC* self, void* next) [ snap ] > +It should set up the environment for the sub, and should return the > +location at which operation flow should continue after the subroutine > +returns. The C vtable method gets a bytecode address, that is the NEXT() in the opcode stream. But it returns the address, where it wants to jump to. Returning to the passed address is not up to the called subroutine object, setting up specific environment depends on the called subroutine object. A look at docs/pmc/subs.pod might provide some hints. So the invoke opcode branches to the address it got from the invoke vtable, normally: eval.pmc is slightly different or it takes just longer to branch really there ;-) Sorry if that was missleading in my first answer regarding that topic. Anyway, there are no really general rules what the vtables do. They are some kind of overloading (e.g. get_integer()): set I0, P0 # get an integer from a scalar set I1, P1 # get size of aggregate P1 leo
Re: cvs commit: parrot/docs/pdds pdd02_vtables.pod
On Tue, 29 Jul 2003, Leopold Toetsch wrote: > Simon Glover <[EMAIL PROTECTED]> wrote: > > Try and explain what invoke is supposed to do. NB this still needs work > > [ snip ] > > > +=item void* invoke(INTERP, PMC* self, void* next) > > [ snap ] > > > +It should set up the environment for the sub, and should return the > > +location at which operation flow should continue after the subroutine > > +returns. > > The C vtable method gets a bytecode address, that is the > NEXT() in the opcode stream. But it returns the address, where it wants > to jump to. Returning to the passed address is not up to the called > subroutine object, setting up specific environment depends on the > called subroutine object. A look at docs/pmc/subs.pod might provide some > hints. > > So the invoke opcode branches to the address it got from the invoke > vtable, normally: eval.pmc is slightly different or it takes just longer > to branch really there ;-) > > Sorry if that was missleading in my first answer regarding that topic. I said the current draft needed work :-) > Anyway, there are no really general rules what the vtables do. They are > some kind of overloading (e.g. get_integer()): > >set I0, P0 # get an integer from a scalar >set I1, P1 # get size of aggregate P1 Yes, but in both cases we can still document the general intent of the method: it returns an integer value from the specified PMC. Now, what that value _actually represents_ is another matter, and you're right that PDD02 isn't the place to discuss that. I shall try and add something along these lines to the docs soon, but I don't have time tonight. Simon
Re: [perl #23159] Parrot SIGSEGV in scratchpad_find
Simon Glover wrote: Therefore the decision was taken that we should not guarantee that Parrot should never segfault when fed bad assembler; ... in the "fast run case", but we will provide a save environment, that does do all kinds of bounds checking, check byte code, have a reduced and configurable opcode set (a la Safe.pm"), and that doesn't joke on "parrot -- - Simon leo
Task for the interested: Coverage
One thing we don't have is a complete set of coverage tests for the parrot opcodes. (Nor stats as to which ops do actually get covered by our current test suite) This would be a good thing to have, especially if we could add it into the make test target to generate a coverage report as part of its run. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: This week's Perl 6 Summary
Piers Cawley <[EMAIL PROTECTED]> wrote: > Okay, okay, PONIE really stands for 'Perl On New Internal Engine'. That's that what they say. Actually it was: "PONIEPONIE": "Perl5 Obsoletes Nasty Internals Entirely: Parrot Occupies Numerous Interpreters Everywhere" But that was to bulky. Or too many ponies, w/o any camels... [ quote of the week ] > Dan: I'm really bad at reading my mails Leo: You should at least read > *my* mails Everyone: Hear! Hear! (or words to that effect) s/read/please read/ - albeit the pronounciation of "my" above is ok ;-) Piers, thanks again for doing these summaries & it was a great pleasure to meet you »in personam«, leo
[CVS ci] Exec argument.
I have checked in a patch to make the following work: ./parrot -o life.o examples/assembly/life.pbc So, don't use test_main anymore. I made this storing the pointer to the -o argument in the interpreter string register 0 to make it visible from inside the core, instead of adding another pointer the the interpreter structure. s. embed.c:302 Daniel.
Re: Task for the interested: Coverage
Dan Sugalski wrote:
One thing we don't have is a complete set of coverage tests for the
parrot opcodes. (Nor stats as to which ops do actually get covered by
our current test suite) This would be a good thing to have, especially
if we could add it into the make test target to generate a coverage
report as part of its run.
I have a (unportable, ugly, slightly tested, ...) script here doing some:
total ops 1099
ops types 257
op usage stat
560 op-list-all
165 op-list-types
Meaning, we have slighlty more then a half of opcodes used/tested.
$ cat op-stat
#!/bin/sh
[ -e .op-list1 ] && rm .op-list1
[ -e op-list-all ] && rm op-list-all
[ -e op-list-types ] && rm op-list-types
find . -name '*.pasm' -exec ./parrot -d1000 {} \; 2>&1 |
perl -ne 'm/\d+ (\w+)/; print "$1\n" if ($1)' >> .op-list1
sort < .op-list1 | uniq -c | sort -rg > op-list-all
sort < .op-list1 | sed -e's/_.*//' | uniq -c | sort -rg > op-list-types
echo
T=`grep NAME lib/Parrot/OpLib/core.pm | wc -l`
S=`grep NAME lib/Parrot/OpLib/core.pm | sort | uniq | wc -l`
echo total ops $T
echo ops types $S
echo op usage stat
wc -l op-list* | head -2
Re: Task for the interested: Coverage
There is http://www.hitchhiker.org/parrot_coverage/, which is built by tools/dev/parrot_coverage.pl. Any enhancements made there should show up in the next run. I disabled it about a month ago when it started going into an endless loop on a test. I'll try turning it back on though. --Josh At 18:12 on 07/29/2003 EDT, Dan Sugalski <[EMAIL PROTECTED]> wrote: > One thing we don't have is a complete set of coverage tests for the > parrot opcodes. (Nor stats as to which ops do actually get covered by > our current test suite) This would be a good thing to have, > especially if we could add it into the make test target to generate a > coverage report as part of its run. > -- > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even >teddy bears get drunk
Re: [perl #23159] Parrot SIGSEGV in scratchpad_find
On Tuesday, July 29, 2003, at 02:41 PM, Simon Glover wrote: Therefore the decision was taken that we should not guarantee that Parrot should never segfault when fed bad assembler; the creation of invalid assembler is a compiler bug, and should be fixed at the compiler level. If people write PBC directly, perhaps the assembler could do a few checks. It may not be a good idea. It's just an idea. -- c
Re: [perl #23159] Parrot SIGSEGV in scratchpad_find
On Tuesday 29 July 2003 21:10, chromatic wrote: > On Tuesday, July 29, 2003, at 02:41 PM, Simon Glover wrote: > > Therefore the decision was taken that we should not guarantee that > > Parrot > > should never segfault when fed bad assembler; the creation of invalid > > assembler is a compiler bug, and should be fixed at the compiler > > level. > > If people write PBC directly, perhaps the assembler could do a few > checks. It may not be a good idea. It's just an idea. Another idea (not mine and I can't recall from whom) is to write a safe interpreter where every single check of those Jos propose is done, may be this could be done by adding #if SAFE_INTERPRETER checks and a configure option, I know this will make the interpreter really slow, but safe. > > -- c Daniel.
Re: [perl #23159] Parrot SIGSEGV in scratchpad_find
At 20:54 -0300 7/29/03, Daniel Grunblatt wrote: On Tuesday 29 July 2003 21:10, chromatic wrote: On Tuesday, July 29, 2003, at 02:41 PM, Simon Glover wrote: > Therefore the decision was taken that we should not guarantee that > Parrot > should never segfault when fed bad assembler; the creation of invalid > assembler is a compiler bug, and should be fixed at the compiler > level. If people write PBC directly, perhaps the assembler could do a few checks. It may not be a good idea. It's just an idea. Another idea (not mine and I can't recall from whom) is to write a safe interpreter where every single check of those Jos propose is done, may be this could be done by adding #if SAFE_INTERPRETER checks and a configure option, I know this will make the interpreter really slow, but safe. That's ultimately the plan. There'll be a safe version of all the ops, automatically generated, that perform some basic checks--for example making sure all the pointer-based registers are valid. This'll be the version of the ops that get executed (probably in the slowest form of the interpreter, or if we're lucky in the switch core) when the bytecode is considered untrustable. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
