Backward branch, warnocked.
Leo clarified this as a problem with backward branch circa 3/12/03: Sorry to be a pain in the butt, but I need to be told that there has been no improvement in the last two months on this ;-( .sub _main goto L1 test: $I1 = 1 ret L1: $I2 = 2 call test print $I2 # prints 1, not 2 end .end Surely it can't just be me that thinks this is rather fundamental? How fundamental *is* the problem, can it *ever* be fixed? Again, sorry to be a pain, but I'd like the truth/an update, please! Or some hints... file level variables... better ways to code this... Pete PS use parrot -o and examine the output .pasm:, $I1 and $I2 (or .local int i, .local int j) get assigned the same register.
Re: Backward branch, warnocked.
On Mon, 2 Feb 2004 20:51:21 -0500 (EST), Michal Wallace [EMAIL PROTECTED] wrote: On Tue, 3 Feb 2004, Pete Lomax wrote: .sub _main goto L1 test: $I1 = 1 ret L1: $I2 = 2 call test print $I2 # prints 1, not 2 end .end Huh. That is pretty funky. The problem is that imcc doesn't realize the two variables ought to be distinct, right? Yup. A workaround is to call pushtopi and poptopi around the call statement... Um. Why topi? why not bottomi? why not saveall? What if I want some side effects? What if I don't know exactly which variables will/will not be affected? Or what happens if it is a spilled register I _don't_ want updated?. More to the point how do I work out which registers to restore to the ones I _did_ want updated? Er.. sorry, you appear to have touched a raw nerve there... What's the benefit of doing it this way, rather than using separate subs? Does this answer?: .sub _main $I2 = 2 call _m2 print $I2 # prints 1, not 2 end .end .sub _m2 $I1 = 1 ret .end I'm using a single sub because of a complete lack of file-level variables. This I see as a serious, fundamental flaw. Pete
Re: More on threads
On Sat, 24 Jan 2004 13:59:26 -0500, Gordon Henriksen [EMAIL PROTECTED] wrote: snip It doesn't matter if an int field could read half of a double or v.v.; it won't crash the program. Only pointers matter. snip These rules ensure that dereferencing a pointer will not segfault. In this model, wouldn't catching the segfault and retrying (once or twice) work? - If I'm reading you correctly, which is unlikely, this has little to do with program correctness, but about the interpreter not crashing because of an unfortunate context switch.. which the programmer should have guarded against in the first place... no, I think I just lost the plot again ;-) Pete
Re: Generating optimized PIR?
On Mon, 5 Jan 2004 10:59:18 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: I know IMCC's being redone, and we're nowhere near close to optimized, That was my guess but I think it'd be worth it to get a handle on what sorts of things are likely to trigger off exponential time compiles when fed to IMCC. I'm assuming that it's due to a combination of sub size (about 61K of source in one sub) and locals needing coloring (132) but it'd be nice to know for sure. My experience was as follows (don't take these times too literally since this is a very old, very slow box; the relative times are what count). This was creating a single .sub: compile source and write a 2,500 line imc file: 0.2 seconds The first line of the imc file included a hand-crafted 1000 line file. parrot -o t.pasm t.imc: 7 seconds load the final pasm file (now 3,500 lines) and run it: 0.3 seconds Editing the hand-crafted 1000-line include file to replace symbolic registers (ie $I1 etc) with real registers (I1) cut imc time down to 3.5 seconds. Changing the code emitter to re-use symbolic registers no longer in use (ie not local variables, and not still on the parse stack) cut the time down to 1.39 seconds. Just letting you know what I found, I shall let you draw your own conclusions. Lastly, while I know that -O2 is not complete, I don't know by how much it is incomplete. You may want to check the times on that too. Regards, Pete
Re: ParrotIO array
On Tue, 23 Dec 2003 09:16:45 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Pete Lomax [EMAIL PROTECTED] wrote: I've opened a few files, using P0, and saved a copy of P0 in P4[n]. I was planning on chucking say 0 or -1 in P4[n] when I closed the file, but it won't let me do this. (set_integer_native not implemented in class parrotIO) I hope there is something planned not yet implemented? Can you come up with a minimal working example? Attached, one small program and two small text files for it to play with. Strictly speaking, I could make it smaller, but I felt it better to show something performing read functions on different files. My question is: What can I do to P4 entries to mark them as available for re-use? Regards, Pete t.imc Description: Binary data hlolo el e!
Re: For info only, open/read broken on 3/12 pow build
On Tue, 23 Dec 2003 19:28:30 -, Jonathan Worthington [EMAIL PROTECTED] wrote: - Original Message - From: Pete Lomax [EMAIL PROTECTED] To: Jonathan Worthington [EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 6:59 PM Subject: Re: For info only, open/read broken on 3/12 pow build And building it on Win98 from the source does work, I'm guessing? I've never managed it. It took me about three weeks to get Configure.pl to run, now make dies with the message: Can't use an undefined value as an ARRAY reference at lib/Parrot/OpsFile.pm line 432. which I can't get past OK, so we could be looking at a problem with Parrot on Win98 in general, I guess. Your 15/11 build works fine Does my POW build work under other Windows versions for the test you gave me (it worked here)? Sorry, no access to other windows versions. I'll ask on another list. May I ask in what way the example doesn't work on Win98? Crash? Exception? Does nothing? Does nothing. I do have access to WinME, which is essentially Win98 with more bugs and less stability, so I can take a look into why there are so many problems (and hey, now I've learnt some C, I might be able to fix something). My best guess on at least some of the building problems is that the 98 shell is probably even worse than the XP one, and doesn't do stuff like we'd expect. I could be way off. I've installed minGW/MSYS, so I have a cut down bash. So far, it hasn't really been shell problems, just uncharted territory: it's just that no-one else on this list is sad enough to be running 98 ;-) If you have time, please could you do me a favour? Go to a command prompt in 98, change to the pow directory and do:- perl t/harness And send me the output. Erm, well, in pow 23/12 this dies rather horribly 'cos there is no lib directory hence no Parrot/Test.pm, and no include directory hence no header files. On the snapshot I've been playing with, and got Configure.pl to run on, (29/11, I'll download a fresh one if you think it will help), the output is rather large: $ perl t/harness t/src/basic.# 'gcc -g t/src/basic_1.o -o t/src/basic_1.exe blib/lib/libparrot.a -lmsvcrt' failed with exit code 1 # Failed to build 't/src/basic_1.exe': gcc: blib/lib/libparrot.a: No such file or directory # Failed test (t/src/basic.t at line 5) .. snip 212K of similar .. so it looks like there is a wee problem with the following line in my Makefile: LIBPARROT = blib/lib/libparrot$(A) I have no idea what it should read instead, or where it came from. Regards, Pete
For info only, open/read broken on 3/12 pow build
Someone might want to check this works on the latest build: .sub _main set S0, t.imc open P0, S0, AA100: read S1, P0, 1 length I0, S1 le I0, 0, EOF print S1 goto AA100 EOF: end .end I just noticed it doesn't work on Jonathon Worthington's 3/12 build is all. I have three other builds it works fine on, so I'm happy ;-) Regards, Pete PS can no-one shed any light on my build error?: Can't use an undefined value as an ARRAY reference at lib/Parrot/OpsFile.pm line 432.
ParrotIO array
I've opened a few files, using P0, and saved a copy of P0 in P4[n]. I was planning on chucking say 0 or -1 in P4[n] when I closed the file, but it won't let me do this. (set_integer_native not implemented in class parrotIO) I hope there is something planned not yet implemented? Pete
restore N via win32 CreateProcessA
Hi, I've hit a very strange problem: set N18, 86 save N18 restore N18 if I run this from a DOS prompt, it works fine, however if I run it via the kernel32.dll function CreateProcessA, the restore N18 line fails with Wrong type on top of stack!. If I change the first line to set N18, 86.0 then it works fine. Is that something I should be doing, appending a '.0' when setting an N reg with a literal integer value? Pete
Re: restore N via win32 CreateProcessA
On Tue, 16 Dec 2003 19:54:25 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: At 11:38 PM + 12/16/03, Pete Lomax wrote: Hi, I've hit a very strange problem: set N18, 86 save N18 restore N18 Solved. I forgot I was using -O2 when executing via CreateProcessA, which I wasn't when running at the DOS prompt. Under -O2 the above code outputs: set N18, 86 save 86 restore N18 which explains things. I'll stop using -O2 (for now). Maybe pushing an int and popping a num should be allowed? Pete
Catching Parrot Exceptions
Hi,
Just fishing for comments..
I have been experimenting with error handling, using
P9 = 1
to force the error:
Null PMC access in set_integer_native()
(others too, such as Key not an integer! or Array index out of
bounds!).
I have found that:
newsub P0, .Exception_Handler, _eh
set_eh P0
...
_eh:
does not catch it, whereas
P0 = _eh()
set_eh P0
...
_eh:
does, however when _eh is called, P5 is just {0,}.
I'd like to print/know whatever error it was I trapped.
Pete
PS getline always returns 0, and getfile (unknown file), though I
suspect people are aware of that.
Re: Some PIR How do I? questions
On Mon, 01 Dec 2003 22:28:00 -0500, Melvin Smith [EMAIL PROTECTED] wrote: 2) printf/sprintf - we do need it (and implemented in C) since it is a staple and is the reasonable hook for HLL implementors to do interpolation without having to write a special native method or PMC for each language. Rummaging around /ops/ops.num, I spotted: sprintf_s_s_p 1140 sprintf_s_sc_p 1141 sprintf_p_p_p 1142 (don't recall seeing sprintf mentioned elsewhere) So I tried them (well the first two anyway), and they work. Pete
Re: Symbolic vs Named variable register allocation
At 03:01 PM 12/3/2003 +0100, Leopold Toetsch wrote: Pete Lomax [EMAIL PROTECTED] wrote: The following demonstrates that $I1 and .local int i map to the same register in the output pasm code: Yep. The problem seems to be the backward branch. When you put the test sub after the end op, its working fine. Just a quick comment inspired by reading the perl 6 summary: As Leo said, it is backward branch. $I1 and $I2 can both get stored in the same register, as can .local int i and .local int j. I'm just pointing out that my subject line was a little misleading. Pete
Re: Incorrect scoping of constants in IMCC
On Tue, 9 Dec 2003 16:20:25 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: Just ran across a bug in IMCC. The .const directive is incorrectly available only within a .sub/.end block. Silly. (And wrong) That makes it very difficult to usefully use constants--generally they're defined at the top of a file (or in a file which is .included) and visible through the rest of the compilation unit. When someone gets a chance to patch this one up, I'd much appreciate it. There's no file level locals yet either ;-) Can I ask a stupid question? Guess I'm going to anyway... Is there much benefit to .const, over sticking a value in a register and not modifying it? (which is what I've done to get round this) How much benefit for a heavily used 0/1 flag? What about a lightly used string? Pete
Re: Missing branch instructions?
On Mon, 8 Dec 2003 11:35:59 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: At 12:15 PM +0100 12/7/03, Leopold Toetsch wrote: Pete Lomax [EMAIL PROTECTED] wrote: ... only to find there are no such equivalents for ne, gt, and ge. I've added these missing ops now. *But* there are a lot more missing: Yeah, we need all the comparison operators for PMCs in both numeric and string versions. This needs quite careful thought. I'd like to throw a _str and _num suffix on them, so we have: eq_str lt_num cmp_str I disagree/don't see the point, pls read on. and so on. I think, at this point, that I'm OK with restricting the eq/lt/whatever unqualified versions to same-type comparisons--i.e.: eq I5, 13 lt S5, Foo and have them do the obvious thing (numeric or string comparison). AFIAK, this happens quite reasonably now. Cross-type comparisons without PMCs won't be allowed, Agreed, that's been my (short-term) experience. so if you want this: lt S5, 12 you'll need to either get the integer contents of S5 or turn 12 into a string, so it's a two-op sequence. Not too onerous. (int/float mixes are still OK, they're obvious) Yes, 1) get length of string, 2) compare integers. (or whatever) Unqualified eq/cmp/lt are OK for two PMC operations, I'm not convinced at all here. PMC comparison ops, afaict, are based solely on the pmc instance/address Here's a snippet to play with: $P1 = new Array $P1 = 2 $P1[0] = 1 $P1[1] = 1 $P2 = new Array $P2 = 2 $P2[0] = 1 $P2[1] = 1 # eq $P1, $P2, _L3 eq fred, fred, _L3 print error \fred\!=\fred\ _L3: Is $P1=$P2? and call the underlying unqualified comparison check, but I'd bet that's rarely used. Well, that's what I'm doing: eq_i_i_*, eq_n_n_*, and eq_s_s_*, I'm using directly; the rest are going though a check/cast types routine. Odds are most compilers will go for the explicit string or numeric comparisons, or MMD on type to figure out which to use, but we can leave that to the compiler writers. (Enough people have been burned with the whole my numbers sorted weird issue to explicitly specify numeric or string comparisons pretty much everywhere)
Missing branch instructions?
I've started referring to ops/ops.num, in an attempt to figure out why some of my pasm is getting rejected, and I've noticed a couple of points: There is an eq_p_i_ic and an eq_p_ic_ic, but not an eq_i_p_ic or an eq_ic_p_ic. So, I swapped the operands and it worked, but of course not on an lt statement, so I switched the operands and inverted the sense, only to find there are no such equivalents for ne, gt, and ge. There are also eq_ic_ic_ic, eq_nc_nc_ic, eq_sc_sc_ic instructions and similar for ne, lt, le, gt, and ge. Surely those should automatically be replaced with branch or no_op/omitted, so what are they for? Pete
Symbolic vs Named variable register allocation
The following demonstrates that $I1 and .local int i map to the same register in the output pasm code: .sub _main goto L1 test: $I1 = 1 ret L1: .local int i i = 2 call test print i # prints 1, not 2 end .end parrot -o - t.imc shows: _main: branch L1 test: set I16, 1 ret L1: set I16, 2 bsr test print I16 end Is this a bug, or am I missing something? Pete PS this happens on pow builds 0.0.11 (20/09/03), and 15/11/03 Pete http://palacebuilders.pwp.blueyonder.co.uk/euphoria.html
Re: configure on windows
On 02 Dec 2003 18:37:15 +0100, Juergen Boemmels
[EMAIL PROTECTED] wrote:
Pete Lomax [EMAIL PROTECTED] writes:
Command line used was:
$ perl -e open STDERR,'STDOUT'; exec qq{$^X Configure.pl --cc=gcc
--cgoto=0 --jitcapable=0 --verbose} conf.out
Output file is attached
[...]
Ok, I looked through this things.
Many thanks, Configure.pl is now running without any warnings or
errors.
However (gulp), make fails with:
Can't use an undefined value as an ARRAY reference at
lib/Parrot/OpsFile.pm line 432.
make: *** [include/parrot/oplib/core_ops.h] Error 255
Any idea what that means?
Regards,
Pete
Re: Why are .sub and compilation unit one and the same thing?
On Sat, 29 Nov 2003 15:17:11 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: If you have some small specialized subs, you can always put these inside .emit/.eom as PASM. I'll ditch imc then and just use pasm for everything, Thanks, Pete
Why are .sub and compilation unit one and the same thing?
Am I missing a trick here, thinking it would be better to allow eg: .imcc .local int a .sub _get_a return a .end .sub _set_a restore a .end .endimcc
Error pause
Can someone add a pause to parrot, presumably similar to the existing -. option, only at the end, if an error occurs. Pete
Re: configure on windows
On 19 Nov 2003 16:03:59 +0100, Juergen Boemmels
[EMAIL PROTECTED] wrote:
Could you try out the attached patch.
diff -u -r1.16 mswin32.pl
--- config/init/hints/mswin32.pl15 Oct 2003 12:06:24 - 1.16
+++ config/init/hints/mswin32.pl19 Nov 2003 14:30:26 -
@@ -95,6 +95,19 @@
Configure::Data-set(
link = 'gcc',
libs = $libs,
+ccflags= '-DWIN32 -DNO_STRICT -DNDEBUG
-D_CONSOLE',
+cc_o_out = '-o ',
+cc_exe_out = '-o ',
+cc_debug = '-g',
+
+ld = ${cc},
+ldflags= '',
+ld_out = '-o ',
+cc_ldflags = '',
+ld_debug = '-g',
+ld_shared = '-mdll',
+libs = '-lmsvcrt'
+
slash = '\\',
ar= 'ar',
);
Hello again,
I tried that (needed a comma after libs = '-lmsvcrt') and it didn't
seem to make any difference. I also tried changing -DWIN32 to
-DGARBAGEWIN32 but I didn't get any additional errors so my guess
would be it is not figuring out $is_mingw properly (I am using
--cc=gcc). BTW, I ditched djgpp and installed mingw, and got a fresh
snapshot (2003-11-26 16:01) of parrot, and got pretty much the same
results (duplicates removed):
GCC.EXE: unrecognized option `-nologo'
GCC.EXE: unrecognized option `-nodefaultlib'
GCC.EXE: unrecognized option `-release'
test.c:2:21: pthread.h: No such file or directory
GCC.EXE: test.o: No such file or directory
Bad command or file name
test.c:2:23: arpa/inet.h: No such file or directory
test.c:2:21: sysexit.h: No such file or directory
test.c:2:24: sys/socket.h: No such file or directory
test.c: In function `main':
test.c:15: warning: left shift count = width of type
test.c: In function `main':
test.c:11: warning: initialization makes pointer from integer without
a cast
test.o(.text+0x30):test.c: undefined reference to `memalign'
test.o(.text+0x3c):test.c: undefined reference to `posix_memalign'
test.c:12: parse error before set_handler
test.c:12: parse error before __sighandler_t
test.c: In function `set_handler':
test.c:13: `__sighandler_t' undeclared (first use in this function)
test.c:13: (Each undeclared identifier is reported only once
test.c:13: for each function it appears in.)
test.c:13: parse error before numeric constant
test.c: In function `main':
test.c:13: storage size of `old' isn't known
test.c:13: storage size of `new' isn't known
test.c: In function `main':
test.c:17: storage size of `its' isn't known
test.c:17: storage size of `ots' isn't known
test.c:20: `SIGALRM' undeclared (first use in this function)
test.c:20: (Each undeclared identifier is reported only once
test.c:20: for each function it appears in.)
test.c:24: `ITIMER_REAL' undeclared (first use in this function)
test.o(.text+0x49):test.c: undefined reference to `setenv'
Trying to run make after that lot gave me:
$ make
echo Compiling with:
Compiling with:
make: D:Parrotperlbinperl.exe: Command not found
make: *** [flags_dummy] Error 127
Regards,
Pete
Re: Some PIR How do I? questions
Perl6 already does interpolation without special support from IMCC. That's nice for it. Where do I go crib from? Pete
Re: Some PIR How do I? questions
On Thu, 27 Nov 2003 09:52:10 -0500, Melvin Smith [EMAIL PROTECTED] wrote: At 12:02 PM 11/27/2003 +, Pete Lomax wrote: Perl6 already does interpolation without special support from IMCC. That's nice for it. Where do I go crib from? ? -Melvin I'll rephrase. Is there anything knocking about which would help with eg: printf (pFile, Amount %12.3f [%-10.10s]\n,balance,name); Or do I have to rip the string apart character-by-character, then throw all my variables about in registers, cutting, chopping and padding them into shape, and then dumping them in iddy little bits? Pete
pod/html error on the wiki?
Browsing http://www.vendian.org/parrot/source/?op=pod2htmlfile=docs/overview.pod I noticed tmp.pod: cannot resolve L in paragraph 16. at Pod/Html.pm line 1575. tmp.pod: cannot resolve L in paragraph 32. at Pod/Html.pm line 1575. tmp.pod: cannot resolve L in paragraph 38. at Pod/Html.pm line 1575. at the end of the page Pete
Re: configure on windows
On 19 Nov 2003 16:00:00 +0100, Juergen Boemmels
[EMAIL PROTECTED] wrote:
Are there any people out there building parrot on MinGW?
config/init/hints/mswin32.pl is far from complete.
I'm quite happy to be the first/only testing this
Could you try out the attached patch.
Sorry, no can do this week. Winders just restored my registry (never
seen that before: a screen quite similar to the all-to-familiar
dos-style scandisk) and it won't boot no more with my latest reg
backup so I have to go with the, I dunno, 3 month old, copy.
So I'm going to delete all the compilers, parrot etc I've installed in
the meantime, and start again from scratch.
Plus I'm away the next four days.
Think I'll try mingw+indigostar this time (I was trying djgpp last go)
unless anyone wants to convince me otherwise.
Tuesday,
Pete
Bearing in mind I can no longer reproduce this:
What does the file CFLAGS say?
# DO NOT EDIT THIS FILE
# Generated by lib/Parrot/Configure/Step.pm from
config/gen/cflags/root.in
# [ filename | {regex} ] -{removed options} +{added options} s/// ...
#
# Avoid using non-configure controlled +{} directly in this file, as
# it'll most likely break on other platforms.
#
# Note, empty regex/options are just ignored.
#
spf_render.c -{-Wformat-nonliteral} # noisy
tsq.c -{} # never optimize tsq.c!
# imcc file settings
{imcc} -{-Wwrite-strings -Wcast-qual} s/-Wno-unused/-Wunused/
-{-Wformat-nonliteral}
What make are you using?
Could it be that it has problems with long commandlines?
as above, I'll reinstall next week we'll go from there.
Re: configure on windows
On 18 Nov 2003 15:09:34 +0100, Juergen Boemmels [EMAIL PROTECTED] wrote: Pete Lomax [EMAIL PROTECTED] writes: Hi, I've only just installed perl. Running Configure.pl on a windows box, I got 'bad command or file name' because line 12 of config\init\hints.pl is: my $hints = config/init/hints/ . lc($^O) . .pl; I had to change it to: my $hints = perl config/init/hints/ . lc($^O) . .pl; I'll carry on editing lines by hand, just though I should mention it. This is very strange. Last time I tested it Configure.pl runs under windows without any changes. My bad, it was an error with my file associations, it is a little better now, that change is unnecessary, pls disregard. The main question is: what do you want to get from this? A compiled version 0.0.13 of course ;-) Now that Jonathan Worthington has put a new binary up, it is just a matter of wanting to be able to do it, if I ever need to. $hints is passed to do, which reads the file and evals it in the current interpreter. Normaly this bad command or file name come form failing system calls. But there is no system in hints.pl nor in hints/mswin32.pl. When playing around with windows it has bitten me sometimes that stdout and stderr are not really in sync. So the error could be well one test later or earlier. What is your Configure line? Is cl.exe (Visual compiler is the default on windows) in your PATH or did you pass the right --cc= flag. I used --ask and specified gcc but it doesn't seem to help. See Jonathan Worthingtons reply to me. Sometimes I find Configure.pl a bit brief when you debugg things like that. It might be a good idea to add a --verbose flag, which gives some status information on the things that get done. Yes, It might help to have a few more of those 'and die(msg)' things (I don't know perl). Pete
Re: configure on windows
On 18 Nov 2003 18:37:57 +0100, Juergen Boemmels [EMAIL PROTECTED] wrote: I assume he runs it with perl Configure.pl --ask Yes snip The problem is that --ask option of has not the knowledge to change the options according to the compiler. I don't know a simple fix for this. A workaround solution to this is: Don't use --ask. Put the Compiler directly to the commandline perl Configure --cc=gcc# for MinGW perl Configure --cc=bcc32 # for Borland C++-Builder Maybe you need to add --jitcapable=0 or --cgoto=0 as well. That certainly moves things in the right direction. Determining if your C compiler is actually gcc... I had to laugh when that appeared! ;-) Some more errors, I still get lots of these three: gcc.exe: unrecognized option `-nologo' gcc.exe: unrecognized option `-nodefaultlib' gcc.exe: unrecognized option `-release' test.c:2:21: pthread.h: No such file or directory (ENOENT) gcc.exe: test.o: No such file or directory (ENOENT) gcc.exe: no input files Bad command or file name test.c:2:23: arpa/inet.h: No such file or directory (ENOENT) test.c:2:21: sysexit.h: No such file or directory (ENOENT) test.c:2:24: sys/socket.h: No such file or directory (ENOENT) test.o(.text+0x1b):test.c: undefined reference to `_memalign' collect2: ld returned 1 exit status test.o(.text+0x23):test.c: undefined reference to `_posix_memalign' collect2: ld returned 1 exit status test.c:12: error: parse error before set_handler test.c:12: error: parse error before __sighandler_t test.c: In function `set_handler': test.c:13: error: `__sighandler_t' undeclared (first use in this function) test.c:13: error: (Each undeclared identifier is reported only once test.c:13: error: for each function it appears in.) test.c:13: error: parse error before numeric constant It does finish, but this is what make does: D:\Parrot\Parrotmake echo Compiling with: Compiling with: Use of uninitialized value in pattern match (m//) at tools\dev\cc_flags.pl line 54, F line 15. Use of uninitialized value in pattern match (m//) at tools\dev\cc_flags.pl line 54, F line 15. Use of uninitialized value in pattern match (m//) at tools\dev\cc_flags.pl line 54, F line 15. Use of uninitialized value in pattern match (m//) at tools\dev\cc_flags.pl line 54, F line 15. Use of uninitialized value in pattern match (m//) at tools\dev\cc_flags.pl line 54, F line 15. -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -g -Dan_Sugalski -Larry -Wall -Ws D:\Parrot\perl\bin\perl.exe build_tools\ops2pm.pl ops/core.ops ops/bit.ops ops/c mp.ops ops/debug.ops ops/dotgnu.ops ops/io.ops ops/math.ops ops/object.ops ops/p mc.ops ops/rx.ops ops/set.ops ops/stack.ops ops/string.ops ops/sys.ops ops/var.o ps build_tools\ops2pm.pl: Could not find ops file 'ops/object.op'! make.exe: *** [lib\Parrot\OpLib\core.pm] Error 2 Regards, Pete
configure on windows
Hi, I've only just installed perl. Running Configure.pl on a windows box, I got 'bad command or file name' because line 12 of config\init\hints.pl is: my $hints = config/init/hints/ . lc($^O) . .pl; I had to change it to: my $hints = perl config/init/hints/ . lc($^O) . .pl; I'll carry on editing lines by hand, just though I should mention it. Pete
Re: Proposal: parrot-compilers list
On Mon, 17 Nov 2003 11:35:51 -0800, Sterling Hughes [EMAIL PROTECTED] wrote: I think this would be a *very* cool thing. What he said. Pete Pete http://palacebuilders.pwp.blueyonder.co.uk/euphoria.html
Re: configure on windows
On Mon, 17 Nov 2003 20:46:32 +, Pete Lomax [EMAIL PROTECTED] wrote: I got 'bad command or file name' because line 12 of config\init\hints.pl is: my $hints = config/init/hints/ . lc($^O) . .pl; PS: that was the dos error, shouldn't there be an and/or die thing somewhere near it? Pete http://palacebuilders.pwp.blueyonder.co.uk/euphoria.html
Re: Calling conventions. Again
On Fri, 14 Nov 2003 08:12:26 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: _u_fred: I5=P3[1] S5=P3[2] _fred: There is no P3[] involved. _fred just starts with whatever is in registers I5/S5. Yes, _fred wades straight in, expecting everything to be set up. It is _u_fred which is sucking them out of P3, and falling through. If the function is always called prototyped, _u_fred won't be referenced and imcc will strip that code (according to the Pirate document, iirc). If it is called non prototyped from several places, it makes a smaller footprint. Please read my proposal WRT default params posted elsewhere in this thread. The default value could be the result of an arbitrary expression, so its not that simple. On re-reading your post it seems I was trying to say the same thing. Pete
Re: Calling conventions. Again
Hi, New to this list, so please excuse any glaring stupidity. such as posting this direct to Dan instead of the list, sorry I've been thinking about porting a small language to run on parrot, and the call/return conventions. This is what I plan to do, at least for my local routines. I'll follow the rules a bit more closely for globals and external calls (but not this week). I'd be interested to see what sort of signature changes between compile and runtime you think are likely to happen, as I have to admit I have never encountered such a beast. Doesn't that force non-prototyped calls? As I understand it, the requirements are: Call a routine explicitly and be as efficient as possible/practical. You know what the parameters are and where they should go. Call a routine indirectly given two items: The address of the routine, and A list (or similar structure) of the parameters. You don't know, and you probably don't care what they are. Generally speaking, efficiency in this case is less important. Optional parameters in both calling methods. Without optional parameters I will simply translate as follows: procedure fred(integer x, string y) to: _u_fred: I5=P3[1] S5=P3[2] _fred: Basically, replace the 0/1 prototype flag with a mangled label. Yes/no? For optional parameter handling, I will do something like: procedure fred(integer x=0, string y=Default) _u_fred: length I1, P3 # total number of params lt I1, 1, _fred I5=P3[1] lt I1, 2, _fred S5=P3[2] _fred: eq I1, 2 fred_main # where 2 is max_params set S5 Default eq I1, 1 fred_main set I5 0 fred_main: In this first stab, all optional parameters must be grouped on the rhs. Not sure yet how much more complicated it gets if not. I don't know what games might need to be played with overflow parameters in P3, I can imagine needing to extend a short P3 with some defaults and chop off the first 11 somewhere in _u_fred. Any comments? Pete
