From amiga-gcc-port-owner@nic.funet.fi Sun Jan 1 16:03:12 1995 Received: by nic.funet.fi id <91699-2>; Sun, 1 Jan 1995 16:00:15 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <95Jan1.160015+0200_eet.91699-2+35@nic.funet.fi> Date: Sun, 1 Jan 1995 16:00:08 +0200 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Mon Jan 2 17:26:06 1995 Received: from figbox.funet.fi ([128.214.6.7]) by nic.funet.fi with ESMTP id <92566-2>; Mon, 2 Jan 1995 17:19:17 +0200 Received: from noc.BelWue.DE by FIGBOX.FUNET.FI (PMDF V4.3-11 #2494) id <01HLC3MFJM5S00025M@FIGBOX.FUNET.FI>; Sun, 01 Jan 1995 14:44:02 +0000 (GMT) Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA21256 (5.65c8/IDA-1.4.4 for ); Mon, 2 Jan 1995 12:24:26 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA04192; Mon, 2 Jan 95 12:24:25 +0100 Date: Mon, 02 Jan 1995 12:24:25 +0100 (MET) From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Subject: Re: func. placement etc. In-reply-to: from "Ville-Pertti Keinonen" at Dec 30, 94 05:47:51 am To: will@clinet.fi (Ville-Pertti Keinonen) Cc: amiga-gcc-port@nic.funet.fi Message-id: <9501021124.AA04192@sunserv.IZFM.Uni-Stuttgart.DE> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL23] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 8bit Content-length: 726 > > qsort(): I'm not sure what the algorithm is supposed to do, but it > certainly seems stupid to compare an element to itself. > Well, that's quicksort ;-). According to the book 'Sedgewick: Algorithms in C' quicksort's speed is a straight result of the small inner loop and not handling all those special cases like comparing an element to itself. If you really would like to avoid this you would have to check for it in the most inner loop (since your comparison element may move). This may well cost more than all those comparisons. Maybe there's a nice trick to work around this problem but I didn't have the time to work one out the time I wrote on qsort(), sorry. Just believe me: It's not that simple. Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Jan 2 18:06:44 1995 Received: from clinet.fi ([193.64.6.1]) by nic.funet.fi with SMTP id <92244-2>; Mon, 2 Jan 1995 18:05:28 +0200 Received: from zetor.clinet.fi (root@zetor.clinet.fi [193.64.6.8]) by clinet.fi (8.6.9/8.6.4) with ESMTP id SAA10301; Mon, 2 Jan 1995 18:06:09 +0200 Received: (will@localhost) by zetor.clinet.fi (8.6.8/8.6.4) id SAA16707; Mon, 2 Jan 1995 18:12:15 +0200 Date: Mon, 2 Jan 1995 18:12:10 +0200 (EET) From: Ville-Pertti Keinonen To: Matthias Fleischer cc: amiga-gcc-port@nic.funet.fi Subject: Re: func. placement etc. In-Reply-To: <9501021124.AA04192@sunserv.IZFM.Uni-Stuttgart.DE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Maybe there's a nice trick to work around this problem but I didn't > have the time to work one out the time I wrote on qsort(), sorry. > Just believe me: It's not that simple. I know it isn't simple, especially since the relative cost of comparing an element to itself versus actually handling this kind of a case in the actuall algorithm depends on the elements being sorted.. In any case, the algorithm seems to be fast enough for my use as is. What might make a big difference would be registerized arguments, they would decrease the overhead of calling the compare-function (and function calls in general). However, since even the Amiga port of GCC isn't Amiga-specific, this is most likely hopeless to try to implement. (Registers d0-d1/a0-a1 get trashed by functions anyhow - the ability to place arguments in them is one of the advantages of other compilers on the Amiga, though they don't seem to optimize as efficiently as GCC in other ways). From amiga-gcc-port-owner@nic.funet.fi Tue Jan 3 18:09:48 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <92601-3>; Tue, 3 Jan 1995 17:47:18 +0200 Received: by theseas.ntua.gr with UUCP; Tue, 3 Jan 1995 17:48:27 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05gw@kriton.UUCP>; Tue, 3 Jan 95 17:39:11 EET Date: Tue, 3 Jan 95 17:39:11 EET Message-Id: <9501031539.05gw@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 410 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: cp requires too much stack The cp program that comes with gcc requires more than 20000 bytes of stack. This has been true for some time, but now that gcc allocates its own stack, the problem is more prominent. Perhaps (Philippe?) should compile it with stack allocation as well. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) ----- "`Eureka' is greek for `this bath is too hot'!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jan 3 18:09:49 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <92598-4>; Tue, 3 Jan 1995 17:47:16 +0200 Received: by theseas.ntua.gr with UUCP; Tue, 3 Jan 1995 17:48:29 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05gr@kriton.UUCP>; Tue, 3 Jan 95 17:36:12 EET Date: Tue, 3 Jan 95 17:36:12 EET Message-Id: <9501031536.05gr@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 483 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: GNU:lib/libm020/lib881/libnix Gcc 2.6.3 comes with a set of libnix libraries in GNU:lib/libm020/lib881/libnix, which are apparently compiled for a 68020+68881. How does one use these libraries, instead of the plain 68020 version? Specifying "-m68020 -m68881" during linking does not appear to work (gcc -v prints the same command line as for "-m68020"). -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) ----- "`Eureka' is greek for `this bath is too hot'!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jan 3 19:12:20 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <92601-4>; Tue, 3 Jan 1995 19:09:49 +0200 Received: by colombo.telesys-innov.fr; Tue, 3 Jan 1995 17:59:12 +0100 From: Philippe BRAND Message-Id: <199501031659.RAA12631@colombo.telesys-innov.fr> Subject: Re: GNU:lib/libm020/lib881/libnix To: kyrimis@theseas.ntua.gr Date: Tue, 3 Jan 1995 17:59:10 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9501031536.05gr@kriton.UUCP> from "Kriton Kyrimis" at Jan 3, 95 05:36:12 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 344 Kriton Kyrimis writes: > How does one use these libraries, instead of the plain 68020 version? > Specifying "-m68020 -m68881" during linking does not appear to work > (gcc -v prints the same command line as for "-m68020"). specs file has to be modified. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Tue Jan 3 19:14:55 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <92598-1>; Tue, 3 Jan 1995 19:08:49 +0200 Received: by colombo.telesys-innov.fr; Tue, 3 Jan 1995 18:00:02 +0100 From: Philippe BRAND Message-Id: <199501031700.SAA12644@colombo.telesys-innov.fr> Subject: Re: cp requires too much stack To: kyrimis@theseas.ntua.gr Date: Tue, 3 Jan 1995 18:00:00 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9501031539.05gw@kriton.UUCP> from "Kriton Kyrimis" at Jan 3, 95 05:39:11 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 431 Kriton Kyrimis writes: > The cp program that comes with gcc requires more than 20000 bytes of stack. > This has been true for some time, but now that gcc allocates its own stack, > the problem is more prominent. Perhaps (Philippe?) should compile it with > stack allocation as well. Well I'm always running shells with 50.000 stack size :-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Tue Jan 3 20:45:24 1995 Received: from oulu.fi ([130.231.240.1]) by nic.funet.fi with SMTP id <92542-1>; Tue, 3 Jan 1995 20:43:36 +0200 Received: from paju.oulu.fi by oulu.fi (4.1/SMI-4.1) id AA01880; Tue, 3 Jan 95 20:43:32 +0200 Received: by paju.oulu.fi (931110.SGI/930416.SGI.AUTO) for @ousrvr.oulu.fi:amiga-gcc-port@nic.funet.fi id AA27923; Tue, 3 Jan 95 20:43:31 +0200 Date: Tue, 3 Jan 1995 20:43:29 +0200 (EET) From: Petteri Heikkinen To: amiga-gcc-port@nic.funet.fi Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe ----------------------------------------------------------- Try When I read those lines to hold They felt so true and some faith familiar that I just couldn't in leave them where they were. the goodness - Petteri Heikkinen of humanity pheikkin@paju.oulu.fi ----------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Tue Jan 3 23:07:54 1995 Received: from proffa.cc.tut.fi ([130.230.102.14]) by nic.funet.fi with ESMTP id <92585-4>; Tue, 3 Jan 1995 23:01:02 +0200 Received: (from k150471@localhost) by proffa.cc.tut.fi (8.6.8.1/8.6.6) id XAA15648; Tue, 3 Jan 1995 23:00:57 +0200 From: Kniivil{ Jarkko Message-Id: <199501032100.XAA15648@proffa.cc.tut.fi> Subject: Re: cp requires too much stack To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Tue, 3 Jan 1995 23:00:57 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199501031700.SAA12644@colombo.telesys-innov.fr> from "Philippe BRAND" at Jan 3, 95 06:00:00 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1316 Thus Philippe BRAND spoke: > > Kriton Kyrimis writes: > > > The cp program that comes with gcc requires more than 20000 bytes of stack. > > This has been true for some time, but now that gcc allocates its own stack, > > the problem is more prominent. Perhaps (Philippe?) should compile it with > > stack allocation as well. > > Well I'm always running shells with 50.000 stack size :-) In that case you'll be out of luck with `cksum' which I had to try when installing NetBSD. For some files (read: NetBSD 1.0 bin-dist) it needed a stack of over 70.000 (verified with `ixconfig -r 10000 -w' + `stack 80000'). That's pretty heavy for a simple CRC checksum program ;) But of course this particular binary isn't high on the priority list for Philippe, but I just wanted to warn you folks for such a seemingly innocuous program. By the way, Philippe, do you use `-fno-defer-pop' when compiling the binaries? > > -- > Philippe BRAND > phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ > / Jarkko PS. Hope this gets through. My last response disappeared in NIL: due to bogus headers. -- E-Mail: k150471@cc.tut.fi | S-Mail: Jarkko Kniivil\"a % (TEX-format) [ This space unintentionally | Opiskelijankatu 4 F 315 left blank! ] | FIN-33720 TAMPERE From amiga-gcc-port-owner@nic.funet.fi Wed Jan 4 10:37:06 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <92728-3>; Wed, 4 Jan 1995 02:20:52 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA14469; Tue, 3 Jan 95 17:22:09 MST Date: Tue, 3 Jan 1995 17:22:08 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: amiga-gcc-port@lists.funet.fi Subject: ixconfig causes enforcer hits Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I just had something strange happen. I was trying to set ixemul.library configuration using ixconfig and started getting some enforcer hits. When I tried to run 'ls' after using ixconfig, I got more hits. Doing a 'ixconfig -d' doesn't help. I finally flushed ixemul.library out of memory with 'avail flush' and then tried 'ls' and all was fine. Every time I tried to set ixemul.library configuration with ixconfig, I start getting the hits again. I am using gcc 2.6.3. Anyone have any idea what is going on? P.S. I tried rebooting and the same thing occurred again, but only after I use ixconfig. Paul Ney From amiga-gcc-port-owner@nic.funet.fi Wed Jan 4 11:28:46 1995 Received: from figbox.funet.fi ([128.214.6.7]) by nic.funet.fi with ESMTP id <92649-2>; Wed, 4 Jan 1995 11:22:57 +0200 Received: from leon.nrcps.ariadne-t.gr by FIGBOX.FUNET.FI (PMDF V4.3-11 #2494) id <01HLEMHRWQJK0003BF@FIGBOX.FUNET.FI>; Tue, 03 Jan 1995 10:05:31 +0000 (GMT) Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA29440; Wed, 4 Jan 95 10:22:38 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA11385; Wed, 4 Jan 95 10:27:56 +0200 Date: Wed, 04 Jan 1995 10:27:54 +0200 (EET) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: cp requires too much stack In-reply-to: <199501031700.SAA12644@colombo.telesys-innov.fr> from "Philippe BRAND" at Jan 3, 95 06:00:00 pm To: phb@colombo.telesys-innov.fr (Philippe BRAND) Cc: amiga-gcc-port@lists.funet.fi Reply-to: kyrimis@theseas.ntua.gr Message-id: <9501040827.AA11385@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-length: 256 > Well I'm always running shells with 50.000 stack size :-) This is too much for almost everything, and too little for almost everything else (e.g., older gcc versions, povray, rayshade, and cksum) You just can't win :-( -- Kriton (kyrimis@hpcl.cti.gr) From amiga-gcc-port-owner@nic.funet.fi Wed Jan 4 12:24:25 1995 Received: from figbox.funet.fi ([128.214.6.7]) by nic.funet.fi with ESMTP id <92629-3>; Wed, 4 Jan 1995 12:20:55 +0200 Received: from leon.nrcps.ariadne-t.gr by FIGBOX.FUNET.FI (PMDF V4.3-11 #2494) id <01HLEMKQ1IRK0002QS@FIGBOX.FUNET.FI>; Tue, 03 Jan 1995 10:07:54 +0000 (GMT) Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA29481; Wed, 4 Jan 95 10:25:00 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA11388; Wed, 4 Jan 95 10:30:18 +0200 Date: Wed, 04 Jan 1995 10:30:15 +0200 (EET) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: GNU:lib/libm020/lib881/libnix In-reply-to: <199501031659.RAA12631@colombo.telesys-innov.fr> from "Philippe BRAND" at Jan 3, 95 05:59:10 pm To: phb@colombo.telesys-innov.fr (Philippe BRAND) Cc: amiga-gcc-port@lists.funet.fi Reply-to: kyrimis@theseas.ntua.gr Message-id: <9501040830.AA11388@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-length: 207 > specs file has to be modified. Does this mean we should be expecting an updated specs file RSN? If not, what are the appropriate ld options to link with these libraries? -- Kriton (kyrimis@hpcl.cti.gr) From amiga-gcc-port-owner@nic.funet.fi Wed Jan 4 13:24:30 1995 Received: from figbox.funet.fi ([128.214.6.7]) by nic.funet.fi with ESMTP id <92663-2>; Wed, 4 Jan 1995 13:22:01 +0200 Received: from allegro.cs.tufts.edu by FIGBOX.FUNET.FI (PMDF V4.3-11 #2494) id <01HLE7FSV1SG0002W7@FIGBOX.FUNET.FI>; Tue, 03 Jan 1995 02:54:48 +0000 (GMT) Received: by allegro.cs.tufts.edu (5.0/SMI-SVR4) id AA22886; Tue, 3 Jan 1995 20:10:50 +0500 Date: Tue, 03 Jan 1995 20:10:50 -0500 (EST) From: Eric Dana Subject: gcc -resident causes an internal error To: amiga-gcc-port@lists.funet.fi Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Content-length: 634 I tried using compiling hello.c with gcc 2.6.3: gcc -resident -o hello hello.c and I get an internal error. The is the printout of the error and the hello.c listing follow: hello.c: In function `main': hello.c:6: internal error--unrecognizable insn: (call_insn 6 4 8 (call (mem:QI (symbol_ref:SI ("__main"))) (const_int 0)) -1 (nil) (nil) (nil)) Abort trap gcc: Internal compiler error: program cc1 got fatal signal 6 #include main() { printf("Hello World!\n"); } Also, if optimization is turned on, other errors (not this one) occur. Any ideas? Eric Dana email: edana@cs.tufts.edu Tufts Univ. From amiga-gcc-port-owner@nic.funet.fi Wed Jan 4 17:42:39 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <92629-3>; Wed, 4 Jan 1995 17:34:57 +0200 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA20267 (5.65c-6/7.3w-FAU); Wed, 4 Jan 1995 15:18:06 +0100 Received: from pctc.chemie.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA27924 (5.65c-6/7.3m-FAU); Wed, 4 Jan 1995 15:18:04 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA21746; Wed, 4 Jan 1995 15:17:49 +0100 Date: Wed, 4 Jan 1995 15:17:49 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9501041417.AA21746@pctc.chemie.uni-erlangen.de> To: amiga-gcc-port@lists.funet.fi Subject: g++ (amiga gcc version 2.6.3) problem Hello! Yesterday I had to compile a program written in c++. I used the new amiga gcc version 2.6.3. The problem is that it will not link, because of some missing stuff in libg++. The previous version 2.6.1 worked fine. Following I will give the messages gcc gives while compiling: ---------- start of protocol -------------- gcc -v -s -O -o bkurse bkurse.cc -lg++ -lm Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -D__OPTIMIZE__ -Dmc68010 bkurse.cc t:cc285712.ii GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/lib/g++-include /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. In file included from /gnu/include/stdlib.h:67, from bkurse.cc:4: /gnu/include/sys/cdefs.h:55: warning: `__P' redefined /gnu/lib/g++-include/libio.h:62: warning: this is the location of the previous definition /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1plus t:cc285712.ii -quiet -dumpbase bkurse.cc -O -version -o t:cc285712.s GNU C++ version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3 snapshot 941209. as -mc68010 -o t:cc2857121.o t:cc285712.s ld -o bkurse -s /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/local/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/gnu/lib -L/local/lib -L/local/lib t:cc2857121.o -lg++ -lm -lgcc -lc -lgcc t:cc2857121.o: Undefined symbol ___pl__FRC6StringPCc referenced from text segment t:cc2857121.o: Undefined symbol ___pl__FPCcRC6String referenced from text segment t:cc2857121.o: Undefined symbol ___pl__FPCcRC6String referenced from text segment t:cc2857121.o: Undefined symbol ___pl__FPCcRC6String referenced from text segment t:cc2857121.o: Undefined symbol ___pl__FPCcRC6String referenced from text segment t:cc2857121.o: Undefined symbol ___pl__FRC6StringPCc referenced from text segment t:cc2857121.o: Undefined symbol ___pl__FRC6StringT0 referenced from text segment t:cc2857121.o: Undefined symbol ___pl__FRC6StringPCc referenced from text segment t:cc2857121.o: Undefined symbol ___pl__FRC6StringT0 referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): More undefined symbol String::_substr(int, int) refs follow --------- end of protocol ---------------- Please can anybody check what happened to libg++ ?!?!?! Thank you. PS: A little to late but a happy new year to all! -- Thomas Walter walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Wed Jan 4 18:24:12 1995 Received: from figbox.funet.fi ([128.214.6.7]) by nic.funet.fi with ESMTP id <92712-2>; Wed, 4 Jan 1995 18:21:42 +0200 Received: from colombo.telesys-innov.fr by FIGBOX.FUNET.FI (PMDF V4.3-11 #2494) id <01HLF0SHJTDS0003NF@FIGBOX.FUNET.FI>; Tue, 03 Jan 1995 16:55:00 +0000 (GMT) Received: by colombo.telesys-innov.fr; Wed, 4 Jan 1995 16:16:34 +0100 Date: Wed, 04 Jan 1995 16:16:33 +0100 (MEZ) From: Philippe BRAND Subject: Re: gcc -resident causes an internal error In-reply-to: from "Eric Dana" at Jan 3, 95 08:10:50 pm To: edana@cs.tufts.edu (Eric Dana) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Message-id: <199501041516.QAA14210@colombo.telesys-innov.fr> Organization: Telesystemes MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL23] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-length: 326 Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 Eric Dana writes: > Also, if optimization is turned on, other errors (not this one) occur. > Any ideas? Yes I have a good idea of what's going on and another good idea on how to avoid this: do not compiler with -resident as for now :-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Fri Jan 6 16:03:38 1995 Received: from swan.doc.ic.ac.uk ([155.198.191.2]) by nic.funet.fi with SMTP id <92726-3>; Fri, 6 Jan 1995 15:58:09 +0200 Received: from doc.ic.ac.uk by swan.doc.ic.ac.uk with SMTP (PP) id <15016-0@swan.doc.ic.ac.uk>; Fri, 6 Jan 1995 13:57:59 +0000 To: amiga-gcc-port@nic.funet.fi Subject: Using MUI and gcc X-Mailer: Oingo Boingo Mailer Date: Fri, 06 Jan 1995 13:57:56 +0000 From: Paul Hickman Message-ID: <"swan.doc.i.019:06.00.95.13.58.04"@doc.ic.ac.uk> I am new to gcc (V2.6.2), and I am trying to write program using MUI. I have been successful in writing / converting small programs, but I have some questions / problems: 1) How to I write a hook function - I.E. Specify which registers parameters should be received in and that the result should be returned in register D0. 2) Is there anyway to specify that a function should NOT be made inline (As I wouldn't want the hook function inlined. 3) The gcc readme file states that 4Mb of memory is required for small to medium size projects. I have approx 5.3Mb of free memory and yet I run out of memory trying to compile a 6K C++ file which doesn't include much other than a few include/clib file for amiga shared library calls, and exec/exec.h. The command line I am using is: gcc -c -o Apart from changing the stack size, is there any other way of reducing memory usage of gcc, particulary with C++ which seems to require much more than the same program compiled as C code. 4) Do you know of a text reader (Or a port of more) which accepts input from stdin, so I can page the error messages output by gcc? +-------------------------+------------------------------------+ | | _____ | | PAUL HICKMAN | / \ ON A HOT SUMMER NIGHT | | (ph@doc.ic.ac.uk) | / O O \ WOULD YOU OFFER YOUR | | DEPARTMENT OF COMPUTING | | _ | THROAT TO THE WOLF | | IMPERIAL COLLEGE LONDON | \ / \ / WITH THE RED ROSES ? | | | \_____/ | +-------------------------+------------------------------------+ Machines: Amiga 500 WB1.3 - 1mb Memory - External Disk Drive. Amiga 1200 WB3.0 - 6mb Memory - 200Mb Hard Disk. From amiga-gcc-port-owner@nic.funet.fi Fri Jan 6 17:30:14 1995 Received: from cardhu.cs.hut.fi ([130.233.192.95]) by nic.funet.fi with SMTP id <92722-2>; Fri, 6 Jan 1995 17:24:52 +0200 Received: by cardhu.cs.hut.fi id AA16513 (5.65c8/HUTCS-C 1.3 for amiga-gcc-port@nic.funet.fi); Fri, 6 Jan 1995 17:22:50 +0200 Date: Fri, 6 Jan 1995 17:22:50 +0200 Message-Id: <199501061522.AA16513@cardhu.cs.hut.fi> From: Tomi Ollila Reply-To: To: Paul Hickman Cc: amiga-gcc-port@nic.funet.fi Subject: Using MUI and gcc In-Reply-To: <"swan.doc.i.019:06.00.95.13.58.04"@doc.ic.ac.uk> References: <"swan.doc.i.019:06.00.95.13.58.04"@doc.ic.ac.uk> Paul Hickman writes: > > I am new to gcc (V2.6.2), and I am trying to write program using MUI. I have > been > successful in writing / converting small programs, but I have some questions / > problems: > > 1) How to I write a hook function - I.E. Specify which registers parameters > should be received in and that the result should be returned in register D0. One way to do this is to write the function entry the following way: ULONG hook(void) { register char * a0 __asm("a0"); char * buffer = a0; register ULONG d0 __asm("d0"); ULONG size = d0; ... return length; } We wrote some macros for AmiTCP/IP project to make it easier to write this kind of function entries... #define RAF2(funname, type1, arg1, reg1, type2, arg2, reg2) \ funname(VOID) \ { \ register type1 reg1 __asm(#reg1); \ type1 arg1 = reg1; \ register type2 reg2 __asm(#reg2); \ type2 arg2 = reg2; would make the above function look like: ULONG RAF2(hook, char *, buffer, a0, ULONG, size, d0) #if 0 { #endif The whole macro file `amiga_raf.h' is available at kampi.hut.fi, directory /AmiTCP. It defines RAF1 - RAF7 for both GNU C and SAS C compilers (someone could write these to DICE as well). > 2) Is there anyway to specify that a function should NOT be made inline (As > I wouldn't want the hook function inlined. Compile it in a separate module. This way gcc doesn't see the function code when compiling. If you give a pointer to the function, then it must also exist as a callable function. > 4) Do you know of a text reader (Or a port of more) which accepts input from > stdin, > so I can page the error messages output by gcc? > 11.HD:> version hd:utilities/less Amiga Less 1.6Z 11.HD:> > | PAUL HICKMAN | / \ ON A HOT SUMMER NIGHT | From amiga-gcc-port-owner@nic.funet.fi Sat Jan 7 18:08:25 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <92558-3>; Sat, 7 Jan 1995 18:04:23 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA14322; Sat, 7 Jan 95 09:05:36 MST Date: Sat, 7 Jan 1995 09:05:36 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: amiga-gcc-port@lists.funet.fi Subject: ixconfig causes enforcer hits Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I just had something strange happen. I was trying to set ixemul.library configuration using ixconfig and started getting some enforcer hits. When I tried to run 'ls' after using ixconfig, I got more hits. Doing a 'ixconfig -d' doesn't help. I finally flushed ixemul.library out of memory with 'avail flush' and then tried 'ls' and all was fine. Every time I tried to set ixemul.library configuration with ixconfig, I start getting the hits again. I am using gcc 2.6.3. Anyone have any idea what is going on? P.S. I tried rebooting and the same thing occurred again, but only after I use ixconfig. Paul Ney From amiga-gcc-port-owner@nic.funet.fi Mon Jan 9 07:09:20 1995 Received: from sleepy.cc.utexas.edu ([128.83.108.13]) by nic.funet.fi with SMTP id <92566-2>; Mon, 9 Jan 1995 07:03:46 +0200 Received: (from thedward@localhost) by sleepy.cc.utexas.edu (8.6.8.1/8.6.6/cc-wf-sunos.mc-1.1) id XAA17785 for amiga-gcc-port@nic.funet.fi; Sun, 8 Jan 1995 23:03:34 -0600 From: the Edward Blevins Message-Id: <199501090503.XAA17785@sleepy.cc.utexas.edu> Subject: Amiga Programming To: amiga-gcc-port@nic.funet.fi (Amiga GCC Port Mailing List) Date: Sun, 8 Jan 1995 23:03:33 -0600 (CST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 615 I've been using gcc awhile now to practice my generic C skills, and lately I was wondering if there was any documentation out there that gives tips on learning to do amiga style programming with gcc, I mean accessing the libraries and stuff like that. Preferably w/ libnix. Or failing that a good book ( or online txt ) about programming the Amiga in general. I have the RKRM: Libraries, but it doesn't seem like a very good tutorial. Any help would be greatly appreciated, thank you for your time and bandwidth. --- thedward@mail.utexas.edu (Aspiring Amiga Programmer, and Chem Eng. Major) From amiga-gcc-port-owner@nic.funet.fi Mon Jan 9 07:42:27 1995 Received: from red.ariel.cs.yorku.ca ([130.63.104.32]) by nic.funet.fi with SMTP id <92513-4>; Mon, 9 Jan 1995 07:38:13 +0200 Received: by ariel.cs.yorku.ca (8.6.9/YU_CS_869.1.2.Ariel) id AAA08588; Mon, 9 Jan 1995 00:37:58 -0500 Received: from green by red with SMTPD id <8587>; Mon, 09 January 1995 00:37:58 -0500 Received: by green (4.1/YUCS_Sun_sub) id AA18968; Mon, 9 Jan 95 00:37:57 EST Date: Mon, 9 Jan 1995 00:37:57 -0500 (EST) From: ENNIO A CELLUCCI To: the Edward Blevins Cc: Amiga GCC Port Mailing List Subject: Re: Amiga Programming In-Reply-To: <199501090503.XAA17785@sleepy.cc.utexas.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 8 Jan 1995, the Edward Blevins wrote: > I've been using gcc awhile now to practice my generic C skills, and > lately I was wondering if there was any documentation out there that gives > tips on learning to do amiga style programming with gcc, I mean accessing > the libraries and stuff like that. Preferably w/ libnix. Or failing that > a good book ( or online txt ) about programming the Amiga in general. I > have the RKRM: Libraries, but it doesn't seem like a very good tutorial. > Any help would be greatly appreciated, thank you for your time and > bandwidth. Hi, In a set of about 5 (or maybe 7) Fred Fish disks, there was a tutorial on Programming the Amiga in C. Unfortuntaly, I don't have the disk numbers handy (they are consecutive). But I'm sure you can find out via King Fisher. Another book I have lying about is 'The Waite Group's Inside The Amiga with C (2nd edition)' by John Thomas Berry. Copyright 1988 by Howard W. Sams and Company. I found it pretty good to read but it does have a fatal flaw: Only covers to AmigaDOS 1.2 (you read that right). Hope this helps..EAC Ennio Cellucci cs911180@ariel.cs.yorku.ca From amiga-gcc-port-owner@nic.funet.fi Mon Jan 9 12:40:36 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <92628-4>; Mon, 9 Jan 1995 12:29:54 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 9 Jan 95 11:29 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 9 Jan 95 11:21 MET Message-Id: Subject: Re: amigaguide "\" problem (fwd) To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 9 Jan 1995 11:21:30 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 862 Forwarded message: > Someone posted a small program to patch amigaguide files so that "\" is > converted to "\\". Before running it, make sure that you really need to > do so, as my version of amigaguide has no problem whatsoever in printing > single slashes. Maybe it is a bug/feature of the 3.0+ version of > amigaguide (I'm running 2.1). > -- > Kriton (UUCP: pythia!theseas!kriton!kyrimis) > (INTERNET: kyrimis@theseas.ntua.gr) > i cant use / in node-names. and i have trouble using in a @{" sentence. maybe there are more bugfixes outthere ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Mon Jan 9 12:42:05 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <92558-2>; Mon, 9 Jan 1995 12:34:49 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 9 Jan 95 11:34 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 9 Jan 95 11:31 MET Message-Id: Subject: Re: Amiga Programming To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 9 Jan 1995 11:31:31 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2527 Forwarded message: > From arbi.informatik.uni-oldenburg.de!nic.funet.fi!amiga-gcc-port-owner Mon Jan 9 06:44:03 1995 > Date: Mon, 9 Jan 1995 00:37:57 -0500 (EST) > From: ENNIO A CELLUCCI > To: the Edward Blevins > Cc: Amiga GCC Port Mailing List > Subject: Re: Amiga Programming > In-Reply-To: <199501090503.XAA17785@sleepy.cc.utexas.edu> > Message-Id: > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > > On Sun, 8 Jan 1995, the Edward Blevins wrote: > > > I've been using gcc awhile now to practice my generic C skills, and > > lately I was wondering if there was any documentation out there that gives > > tips on learning to do amiga style programming with gcc, I mean accessing > > the libraries and stuff like that. Preferably w/ libnix. Or failing that > > a good book ( or online txt ) about programming the Amiga in general. I > > have the RKRM: Libraries, but it doesn't seem like a very good tutorial. > > Any help would be greatly appreciated, thank you for your time and > > bandwidth. > > Hi, > > In a set of about 5 (or maybe 7) Fred Fish disks, there was a > tutorial on Programming the Amiga in C. Unfortuntaly, I don't have the > disk numbers handy (they are consecutive). But I'm sure you can find out > via King Fisher. > > Another book I have lying about is 'The Waite Group's Inside The > Amiga with C (2nd edition)' by John Thomas Berry. Copyright 1988 by > Howard W. Sams and Company. I found it pretty good to read but it does > have a fatal flaw: Only covers to AmigaDOS 1.2 (you read that right). > > Hope this helps..EAC i am preparing a amiga-programming file for gcc. its not ready yet, but if someone is willing to check it out he can mail me. i have changed a lot of programms to compile without warning under gcc (concerns RKRM examples). the ACM (amiga c manual is now available in guide-format). I still need same good examples for - device - library - datatypes - locale its now around 2MB. because i dont have time i need someone who is willing to move this project on. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Mon Jan 9 19:36:04 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <92750-2>; Mon, 9 Jan 1995 19:25:47 +0200 Received: from bastion.nmrc.ucc.ie (actually host nmrc.ucc.ie) by funet.fi with SMTP (PP); Mon, 9 Jan 1995 19:23:26 +0200 Received: by nmrc.ucc.ie (8.6.8.1/8.6.6) with ESMTP id RAA17959; Mon, 9 Jan 1995 17:21:18 GMT From: Lars Hecking Message-Id: <199501091723.RAA21422@mostar.nmrc.ucc.ie> Subject: Re: your mail To: ph@doc.ic.ac.uk (Paul Hickman) Date: Mon, 9 Jan 1995 17:23:09 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <01HLNAJMMNXE00RATQ@mailgate.ucd.ie> from "AMIGA-GCC-PORT-OWNER%FINFILES.BITNET@bureau.ucc.ie" at Jan 9, 95 03:00:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2310 > I am new to gcc (V2.6.2), and I am trying to write program using MUI. 2.6.3 is out. > I have been successful in writing / converting small programs, but I have > some questions / > problems: > > 1) How to I write a hook function - I.E. Specify which registers parameters > should be received in and that the result should be returned in register D0. Sorry, can't help about the hook part. For registerised parameters, see the the manual, sec 5.29 (C Extensions -> Extended Asm). You could also have a look into the gnu:os-include/inline headers. > 2) Is there anyway to specify that a function should NOT be made inli= > ne (As I wouldn't want the hook function inlined) a) functions are only inlined with optimisation enabled (-O, -O2, -O3) b) make the declaration external and have the function source code in a different file. > 3) The gcc readme file states that 4Mb of memory is required for small to > medium size projects. I have approx 5.3Mb of free memory and yet I run out > of memory trying to compile a 6K C++ file which doesn't include much other > than a few include/clib file for amiga shared library calls, and exec/exec.h. > The command line I am using is: > > gcc -c -o Apart from changing the stack size, is there any other way of reducing memory > usage of gcc, particulary with C++ which seems to require much more than the > same program compiled as C code. See above. > 4) Do you know of a text reader (Or a port of more) which accepts input from > stdin, so I can page the error messages output by gcc? Aminet:util/gnu/less-252.lha should do. If you use elm, please set textencoding to 8bit. For other mailers accordingly. Hope this helps. -- Lars Hecking | Yes I know my enemies lhecking@nmrc.ucc.ie | They're the teachers who taught me to fight me NMRC | Compromise, conformity, assimilation, submission Cork, Ireland | Ignorance, hypocrisy, brutality, the elite | ALL OF WHICH ARE AMERICAN DREAMS From amiga-gcc-port-owner@nic.funet.fi Mon Jan 9 20:54:36 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <92738-4>; Mon, 9 Jan 1995 20:52:12 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 9 Jan 95 19:49 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 9 Jan 95 19:47 MET Message-Id: Subject: amiga documentation for gcc To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 9 Jan 1995 19:47:33 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1018 ITS POSSIBLE that you got this message before but i got a undelivery problem, and to my surprise some some replies, so next try. i am preparing a amiga-programming file for gcc. its not ready yet, but if someone is willing to check it out he can mail me. i have changed a lot of programms to compile without warning under gcc (concerns RKRM examples). the ACM (amiga c manual is now available in guide-format). I still need same good examples for - device - library - datatypes - locale (i already included FLEXCAT ) its now around 2MB. because i dont have time i need someone who is willing to move this project on. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Tue Jan 10 07:57:24 1995 Received: from fishpond.amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <92685-1>; Tue, 10 Jan 1995 07:56:03 +0200 Message-ID: <9501092300.AA01428@fishpond.amigalib.com> Subject: ixemul.library testing To: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) Date: Mon, 9 Jan 1995 23:00:30 +0700 (MST) From: "Fred Fish" Cc: fnf@fishpond.amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2414 I have greatly reorganized the available ixemul-40.4 library sources to incorporate them into the GNU tree on my next FreshFish CD. This means that it is now possible to configure them to build in a directory different than the sources, and to build many different flavors at one time. I've put current test copies of the various versions in an archive that is available via anonymous ftp from ftp.amigalib.com: -r-------- 1 ftp ftp 787870 Jan 9 22:49 pub/amiga/files/ixemul-40.4.X.lha -r-------- 1 ftp ftp 1233 Jan 9 22:49 pub/amiga/files/ixemul-40.4.X.readme Please do not redistribute copies of the libraries to help avoid confusion. Note that "version full ..." will show a date of 1-Jan-95, which will help to verify whether you are currently running with this test version or the older official release. Here are the current contents of the readme file: LhA Evaluation V1.38 - Copyright (c) 1991,92 Stefan Boberg. All rights reserved. Not for commercial use. Listing of archive 'ixemul-40.4.X.lha': Original Packed Ratio Date Time Name -------- ------- ----- --------- -------- ------------- 120160 63675 47.0% 05-Jan-95 10:37:12 68000/soft-float/ixemul.library 144180 71769 50.2% 05-Jan-95 10:37:22 68000/soft-float/ixemul.trace 110248 60472 45.1% 05-Jan-95 10:43:56 68020/68881/ixemul.library 134232 68718 48.8% 05-Jan-95 10:44:08 68020/68881/ixemul.trace 112172 61314 45.3% 05-Jan-95 10:39:18 68020/soft-float/ixemul.library 136156 69483 48.9% 05-Jan-95 10:39:30 68020/soft-float/ixemul.trace 111244 60911 45.2% 05-Jan-95 10:46:22 68030/68881/ixemul.library 135228 69116 48.8% 05-Jan-95 10:46:34 68030/68881/ixemul.trace 113168 61783 45.4% 05-Jan-95 10:41:32 68030/soft-float/ixemul.library 137152 69905 49.0% 05-Jan-95 10:41:44 68030/soft-float/ixemul.trace 111588 60966 45.3% 05-Jan-95 10:48:48 68040/68881/ixemul.library 135572 69139 49.0% 05-Jan-95 10:49:00 68040/68881/ixemul.trace -------- ------- ----- --------- -------- 1501100 787251 47.5% 09-Jan-95 11:48:14 12 files The structure should be pretty self explanatory in helping you select different flavors to test. Please advise me as soon as possible if you can isolate any reproducible problems or you notice any significant performance differences, either for the better or for the worse. Thanks! -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Jan 10 15:47:56 1995 Received: from figbox.funet.fi ([128.214.6.7]) by nic.funet.fi with ESMTP id <92700-4>; Tue, 10 Jan 1995 15:33:57 +0200 Received: from pan.rz.uni-konstanz.de by FIGBOX.FUNET.FI (PMDF V4.3-11 #2494) id <01HLN8MV5APS000093@FIGBOX.FUNET.FI>; Mon, 09 Jan 1995 14:05:53 +0000 (GMT) Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Tue, 10 Jan 1995 13:26:49 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA08584; Tue, 10 Jan 95 13:26:33 +0100 Date: Tue, 10 Jan 1995 13:26:33 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Subject: Re: ixconfig causes enforcer hits To: amiga-gcc-port@lists.funet.fi, pney@RT66.com Message-id: <9501101226.AA08584@inf-wiss.uni-konstanz.de> Content-transfer-encoding: 7BIT > I just had something strange happen. I was trying to set ixemul.library > configuration using ixconfig and started getting some enforcer hits. Maybe you are using the wrong ixconfig program for this ixemul.library? Unluckily, R. Luebbert removed the 4 bytes of ARPBase dummy in the library base in 40.4, causing older ixconfig to touch the wrong bits. I really hope that he will put a long dummy in for 40.5, as that would again make most ixconfigs around compatible with almost any ixemul.library. Regards, Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Tue Jan 10 17:12:28 1995 Received: from mail.Germany.EU.net ([192.76.144.65]) by nic.funet.fi with ESMTP id <92700-3>; Tue, 10 Jan 1995 16:54:17 +0200 Received: by mail.Germany.EU.net with SMTP (8.6.5:29/EUnetD-2.5.1.c) via EUnet id PAA16088; Tue, 10 Jan 1995 15:55:12 +0100 Message-Id: <9501101412.AA01830@GWEU.softlab.de> Received: from H8 by GWEU.softlab.de with SMTP (5.65/GEN-1.1.8) via EUnet for [192.76.144.65] id AA01830; Tue, 10 Jan 95 15:12:15 +0100 Received: by H8 (1.37.109.4/16.2) id AA17024; Tue, 10 Jan 95 15:38:07 +0100 Date: Tue, 10 Jan 95 15:38:07 +0100 From: REH@softlab.de To: amiga-gcc-port@lists.funet.fi review amiga-gcc-port From amiga-gcc-port-owner@nic.funet.fi Tue Jan 10 17:42:38 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <92732-4>; Tue, 10 Jan 1995 17:31:44 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA07248; Tue, 10 Jan 95 08:32:51 MST Date: Tue, 10 Jan 1995 08:32:50 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: Joerg-Cyril Hoehle Cc: amiga-gcc-port@lists.funet.fi Subject: Re: ixconfig causes enforcer hits In-Reply-To: <9501101226.AA08584@inf-wiss.uni-konstanz.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Jan 1995, Joerg-Cyril Hoehle wrote: > > I just had something strange happen. I was trying to set ixemul.library > > configuration using ixconfig and started getting some enforcer hits. > > Maybe you are using the wrong ixconfig program for this ixemul.library? > > Unluckily, R. Luebbert removed the 4 bytes of ARPBase dummy in the > library base in 40.4, causing older ixconfig to touch the wrong bits. I > really hope that he will put a long dummy in for 40.5, as that would > again make most ixconfigs around compatible with almost any > ixemul.library. I am currently using the ixconfig distributed with gcc 2.6.3. Is this the wrong one to use? If so, which one should I be using? Paul Ney From amiga-gcc-port-owner@nic.funet.fi Tue Jan 10 18:04:12 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <92728-2>; Tue, 10 Jan 1995 17:56:16 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Tue, 10 Jan 1995 16:54:52 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA09533; Tue, 10 Jan 95 16:54:48 +0100 Date: Tue, 10 Jan 95 16:54:48 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9501101554.AA09533@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA08873; Tue, 10 Jan 95 16:54:48 +0100 To: amiga-gcc-port@nic.funet.fi Subject: using ixemul.trace and the trace program Hi, more than one year ago, I corrected a huge bug in the program trace (a buffer overflow). Together with ixemul.trace, this program allows you to see every ixemul call (aka SnoopDOS for ixemul.library programs) and may be useful for debugging. Before, because of that overflow, trace hung the whole system very often (and very soon) when tracing every ixemul call. Now, I've been able to trace long sessions of gcc compilation to a (K)CON: window without trouble. Nevertheless, my system still crashes from time to time when using trace. Anybody out there with the same experience? Are there more hidden bugs there? Is anybody actually using trace? Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Jan 11 16:31:41 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91246-2>; Wed, 11 Jan 1995 16:18:53 +0200 Received: by theseas.ntua.gr with UUCP; Wed, 11 Jan 1995 15:24:32 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05j5@kriton.UUCP>; Wed, 11 Jan 95 15:20:10 EET Date: Wed, 11 Jan 95 15:20:10 EET Message-Id: <9501111320.05j5@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 3959 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Cc: walter@pctc.chemie.uni-erlangen.de Subject: Possible version mixup of libg++/c++ header files I get the feeling that the C++ header files released with 2.6.3 are older versions, incompatible with the released version of libg++: There is a file m68k-cbm-amigados/include/_G_config.h in my GNU: directory, which is probably left over from a previous release. The file is version 0.66, while the one in the C++ header directory is version 0.65. Given the frequent changes in C++ header files, could this be the cause of the linking problems Thomas Walter reported a few days ago? I'm including Thomas's test program exhibiting the error, as I don't believe I've seen it in the list. The program has compiled fine under AIX and SunOS.) -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Keep calm, Sarah! Whatever you do... Oh! You *are* calm!" ----- ---------------- start of program ----------------------------------- /* * How to compile: * g++ -O -o compltst compltst.cc -lm * * If you search for the text TROUBLE you will see the code lines which * prevents compiling. */ #include #include <_complex.h> #include <_String.h> // TROUBLE following: // a helper needed by at, before, etc. // normally this is declared and defined in String.h (_String.h on the AM*GA) // if the code is added here as a real function (the compiler has a label to jump to) // then the link error Undefined symbol String::_substr(int,int) will not occur. /*inline*/ SubString String::_substr(int first, int l) { if (first < 0 || (unsigned)(first + l) > length() ) return SubString(_nilString, 0, 0) ; else return SubString(*this, first, l); } void string_as_arg (String string_arg); void string_ref_as_arg (String &string_arg); void const_string_ref_as_arg (const String &string_arg); String string_as_arg_string_return (String string_arg); int main (int argc, char **argv) { complex a, b, c; String sa, sb; cout << "\nPlease enter a complex number:" << endl; cin >> a; b = a + a; cout << "\nTha value of a: " << a << endl; cout << "\nThe result of b = a + a: " << b << endl; cout << "\nNow I set a to the value of (2,1)" << endl; a = complex (2,1); b = a + a; cout << "\nTha value of a: " << a << endl; cout << "\nThe result of b = a + a: " << b << endl; cout << "\nNow I test class String!\n" << endl; cout << "Please enter a string:" << endl; cin >> sa; cout << "\nYou enterred: " << sa << endl; string_as_arg (sa); string_ref_as_arg (sa); const_string_ref_as_arg (sa); sb = string_as_arg_string_return (sa); } void string_as_arg (String string_arg) { String fump = string_arg; cout << "\nFunction string_as_arg(String) got the argument:" << endl; cout << string_arg << endl; cout << "\nThe local copy is: " << fump << endl; // TROUBLE: The next line is the line of trouble. Uncomment it and the next line of // code and amiga gcc263 will not compile. // fump = string_arg + ".dat"; // cout << "This should be equivalent:" << string_arg << ".dat = " << fump << endl; } void string_ref_as_arg (String &string_arg) { cout << "\nFunction string_ref_as_arg(String &) got the argument:" << endl; cout << string_arg << endl; } void const_string_ref_as_arg (const String &string_arg) { String fump = string_arg; cout << "\nFunction const_string_ref_as_arg(String &) got the argument:" << endl; cout << string_arg << endl; cout << "\nThe local copy is: " << fump << endl; // TROUBLE: The next line is the line of trouble. Uncomment it and the next line of // code and amiga gcc263 will not compile. // fump = string_arg + ".dat"; // cout << "This should be equivalent:" << string_arg << ".dat = " << fump << endl; } String string_as_arg_string_return (String string_arg) { cout << "\nFunction string_as_arg_string_return(String) got the argument:" << endl; cout << string_arg << endl; return (string_arg); } ---------------------------- end of program --------------------------- From amiga-gcc-port-owner@nic.funet.fi Wed Jan 11 17:03:05 1995 Received: from fishpond.amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <92744-3>; Wed, 11 Jan 1995 16:59:49 +0200 Message-ID: <9501110804.AA05451@fishpond.amigalib.com> Subject: Re: Possible version mixup of libg++/c++ header files To: kyrimis@theseas.ntua.gr Date: Wed, 11 Jan 1995 08:04:37 +0700 (MST) From: "Fred Fish" Cc: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9501111320.05j5@kriton.UUCP> from "kriton!kyrimis" at Jan 11, 95 03:20:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 931 > I get the feeling that the C++ header files released with 2.6.3 are > older versions, incompatible with the released version of libg++: There > is a file m68k-cbm-amigados/include/_G_config.h in my GNU: directory, Possibly, it works fine here with my current test version for the next FreshFish CD. I didn't test it with older CD versions. You do have to make the changes noted below... > // TROUBLE following: > // a helper needed by at, before, etc. > // normally this is declared and defined in String.h (_String.h on the AM*GA) There seems to be perpetual confusion about this. I changed it back to and it works fine for me. > // if the code is added here as a real function (the compiler has a label to jump to) > // then the link error Undefined symbol String::_substr(int,int) will not occur. This code caused a multiple defined symbol error. I commented it out and it compiles and links fine. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Jan 11 22:22:28 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <92749-1>; Wed, 11 Jan 1995 22:15:07 +0200 Received: by theseas.ntua.gr with UUCP; Wed, 11 Jan 1995 22:16:02 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05jd@kriton.UUCP>; Wed, 11 Jan 95 22:11:13 EET Date: Wed, 11 Jan 95 22:11:13 EET Message-Id: <9501112011.05jd@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1493 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Re: Possible version mixup of libg++/c++ header files (fwd) On Jan 11, Fred Fish wrote: > Possibly, it works fine here with my current test version for the next > FreshFish CD. I didn't test it with older CD versions. You do have to > make the changes noted below... Good! This means that this is not a bug with gcc 2.6.3 per se, so we only have to fix the network version. > > // TROUBLE following: > > // a helper needed by at, before, etc. > > // normally this is declared and defined in String.h (_String.h on the AM*GA) > There seems to be perpetual confusion about this. I changed it back to > and it works fine for me. In the network version of 2.3.3 this will fail miserably, as String.h refers to string.h (C version) and _String.h refers to String.h (C++ version). > This code caused a multiple defined symbol error. I commented it out and > it compiles and links fine. This was an attempt by Thomas to make the program work, as he apparently had several versions of String.h (how?), one of which did not define this function. If things had been working properly, this function wouldn't have been in the program at all. (When I compiled the program on a sparcstation, I commented out the function as well. I assume Thomas did the same thing when he compiled it under AIX.) -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I think I would have noticed a nuclear explosion!" "Yes, well, they are conspicuous!" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Jan 12 08:03:55 1995 Received: from acmez.gatech.edu ([130.207.165.24]) by nic.funet.fi with SMTP id <92758-4>; Thu, 12 Jan 1995 08:01:07 +0200 Received: (from gt1567b@localhost) by acmez.gatech.edu (8.6.9/8.6.9) id BAA01937 for amiga-gcc-port@nic.funet.fi; Thu, 12 Jan 1995 01:01:02 -0500 From: gt1567b@prism.gatech.edu Message-Id: <199501120601.BAA01937@acmez.gatech.edu> Subject: AmigaGuide To: amiga-gcc-port@nic.funet.fi Date: Thu, 12 Jan 1995 01:01:01 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1208 Actually, I think this problem may be due to my not having GCC set up properly. I am trying to add AmigaGuide support to a program I'm writing, so when the user presses the [HELP] key, an asychronous window pops up with help on what the user is currently trying to do. I've got a SMALL test program I'm using that just does the AmigaGuide stuff, but I can't make it work- GCC says it can't find where the AmigaGuide functions are supposed to go- "t:cc9994881.o: Undefined symbol _OpenAmigaGuide referenced from text segment" I've put the only .h files that came with AmigaGuide in the proper place, either clib/ or libraries. Any clue? If it makes a difference, I've never been able to make GCC work properly by putting the Amiga-specific header files in the os-include directory. They only can be found if they're in the include directory along with the ANSI stuff. Messy, but it seems to work! AA AA i Jeffery C. May ONLY A A A A President, Amiga Atlanta, Inc. Users' Group AMIGA AAAA AAAA i Senior EE, Georgia Institute of Technology MAKES IT A A A A i gt1567b@prism.gatech.edu POSSIBLE From amiga-gcc-port-owner@nic.funet.fi Thu Jan 12 10:34:32 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <92765-4>; Thu, 12 Jan 1995 10:31:51 +0200 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA06111 (5.65c-6/7.3w-FAU); Thu, 12 Jan 1995 09:30:01 +0100 Received: from pctc.chemie.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA22304 (5.65c-6/7.3m-FAU); Thu, 12 Jan 1995 09:29:58 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA15857; Thu, 12 Jan 1995 09:29:49 +0100 Date: Thu, 12 Jan 1995 09:29:49 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9501120829.AA15857@pctc.chemie.uni-erlangen.de> To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@lists.funet.fi In-Reply-To: <9501112011.05jd@kriton.UUCP> (kriton!kyrimis@theseas.ntua.gr) Subject: Re: Possible version mixup of libg++/c++ header files (fwd) Hello, here I want to give a better example to show the problem with g++ from amiga gcc263. This program compiles fine with amiga gcc260/gcc261 and on AIX using gcc version 2.6.0 without the need to define the String member _substr(int,int), but it does not matter if it is done on AIX because it is declared as a real function, not as inline. With amiga gcc263 there some undefined symbols referenced from the code given later in this message. I hope this will make things clear. -------------------- start of program ------------------------------ /* How to compile: * g++ -O -o bk bk.cc * * Exsample input file: * give it the name index_list.asc * write into it the name, i.e. investa * * How to run the program: * bk index_list.asc */ #include #if defined(AMIGA) #include <_String.h> #else #include #endif #include // a helper needed by at, before, etc. // normally this is declared and defined in String.h (_String.h on the AM*GA) // if the code is added here as a real function (the compiler has a label to jump to) // then the link error Undefined symbol String::_substr(int,int) will not occur. // This function is given here only, because the amiga gcc263 will allways // say libg++(String.o): Undefined symbol String::_substr(int, int) // inline must be commented out then the compiler does not complain // about a second definition. /*inline*/ SubString String::_substr(int first, int l) { if (first < 0 || (unsigned)(first + l) > length() ) return SubString(_nilString, 0, 0) ; else return SubString(*this, first, l); } size_t date_to_days (const String &date); String make_sortable_date (const String &date); char * prog_name; void usage (void) { cerr << "\nUsage: " << prog_name << " " << endl; cerr << "\t" << "data format of bestands_liste:" << endl; cerr << "\t" << "each line may have only one stock/fund name" << endl; cerr << "\t" << "the extension '.dat' is added by the program." << endl; } int main (int argc, char **argv) { ifstream bestands_liste; String index_name; String index_filename; String current_date, sortable_date; size_t day_nr; float wert; ofstream current_index; prog_name = argv[0]; if (argc != 2) { usage (); exit (1); } cout << "\nPlease enter date of index" << endl; cin >> current_date; //cout << "\n current_date = " << current_date << endl; day_nr = date_to_days (current_date); sortable_date = make_sortable_date (current_date); bestands_liste.open (argv[1]); bestands_liste >> index_name; // cout << "\n index_name = " << index_name << endl; while (!bestands_liste.eof()) { index_filename = index_name + ".dat"; // cout << "\n index_filename = " << index_filename << endl; cout << "\n Enter value of " << index_name << endl; cin >> wert; // cout << "\n wert = " << wert << endl; current_index.open (index_filename, ios::app); // current_index << current_date << "\t" << wert << endl; // current_index << current_date << "\t" << day_nr << "\t" << wert << endl; current_index << sortable_date << "\t" << day_nr << "\t" << wert << endl; current_index.close(); bestands_liste >> index_name; // cout << "\n index_name = " << index_name << endl; } bestands_liste.close(); return (0); } inline int is_leap (long year) { return (year % 4 == 0 && year % 100 != 0 || year % 400 == 0); } static const long day_table[2][14] = {{0,0,31,59,90,120,151,181,212,243,273,304,334,365}, {0,0,31,60,91,121,152,182,213,244,274,305,335,366}}; size_t date_to_days (const String &cdate) { String day, month, year; long current_day, current_month, current_year; int leap; const long *current_day_table; long days_in_year; int dm_point, my_point; String date = cdate; date = cdate; dm_point = date.index (".",0); // point between day and month my_point = date.index (".",-1); // point between month and year day = date.before(dm_point); dm_point++; month = date.at(dm_point, my_point - dm_point); year = date.after(my_point); current_day = atol (day); current_month = atol (month); current_year = atol (year); //cout << "\n Day = " << current_day << " Month = " << current_month << " Year = " << current_year << endl; leap = is_leap (current_year); current_day_table = day_table[leap]; days_in_year = current_day + current_day_table[current_month]; return (days_in_year); } String make_sortable_date (const String &cdate) { String day, month, year; long day_nr, month_nr, year_nr; int dm_point, my_point; String date = cdate; dm_point = date.index (".",0); // point between day and month my_point = date.index (".",-1); // point between month and year day = date.before(dm_point); dm_point++; month = date.at(dm_point, my_point - dm_point); year = date.after(my_point); // day and month must be 2 digit (leading zero) // year must have 4 digits //cerr << "make_sortable_date(): unchanged day, month, year:" << endl; //cerr << "\t" << " day = " << day << " month = " << month << " year = " << year << endl; if (day.length() < 2) { day = "0" + day; } if (month.length() < 2) { month = "0" + month; } if (year.length() < 4) { if (atol (year) > 90) { year = "19" + year; } else { year = "20" + year; } } //cerr << "make_sortable_date(): changed day, month, year:" << endl; //cerr << "\t" << " day = " << day << " month = " << month << " year = " << year << endl; return (day + "." + month + "." + year); } ----------------------- end of program -------------------------------- Servus -- Thomas Walter walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Thu Jan 12 15:11:55 1995 Received: from grex.cyberspace.org ([152.160.30.1]) by nic.funet.fi with SMTP id <92611-4>; Thu, 12 Jan 1995 15:10:30 +0200 Received: (from fog@localhost) by grex.cyberspace.org (8.6.9/8.6.9) id IAA01881; Thu, 12 Jan 1995 08:09:52 -0500 Date: Thu, 12 Jan 1995 08:09:42 -0500 (EST) From: Federico Di Gregorio To: Amiga GCC List cc: mccallum@cs.rochester.edu Subject: Problems with sh Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Running the configure script from libobjects-0.1.2 with sh configure (sh from gcc 2.6.3 dist.) gives me an error: floating exception. Running the configure from libobjects-0.1.0 with sh from 2.6.1 dist. gives no error. I don't think there is an error in the script (but I can't be sure, i am really bad at sh scripts). Because the new sh replacedc the old I can't try the version that worked fine... Anyone has reported the same problem? Anyone can tell me from where download a working version of a ksh compatible shell without having to get the entireutils pack (1.4 Megs)? Thenk you for your help Federico Di Gregorio From amiga-gcc-port-owner@nic.funet.fi Thu Jan 12 17:38:24 1995 Received: from fishpond.amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <92743-1>; Thu, 12 Jan 1995 17:24:50 +0200 Message-ID: <9501120830.AA03553@fishpond.amigalib.com> Subject: Re: Possible version mixup of libg++/c++ header files (fwd) To: pctc.chemie.uni-erlangen.de!walter Date: Thu, 12 Jan 1995 08:29:52 +0700 (MST) From: "Fred Fish" Cc: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9501120829.AA15857@pctc.chemie.uni-erlangen.de> from "pctc.chemie.uni-erlangen.de!walter" at Jan 12, 95 09:29:49 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 780 > here I want to give a better example to show the problem with g++ > from amiga gcc263. > ... > With amiga gcc263 there some undefined symbols referenced from the code > given later in this message. I installed the gcc263 distribution from aminet and have independently verified this problem exists. I also tried it with the GNU tools on my GoldFish Vol 2 CD (gcc 2.6.2 and libg++ 2.6.1) and my current working set for the FreshFish Vol 8 (gcc 2.6.3 and libg++ 2.6.2). In both cases, it worked fine after I corrected <_String.h> to and commented out the "helper function". I did notice that when I diffed gnu:lib/g++-include in the aminet version against both of my versions that there were a lot of differences. I didn't have time to investigate further. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Jan 12 17:39:36 1995 Received: from fishpond.amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <92755-3>; Thu, 12 Jan 1995 17:29:15 +0200 Message-ID: <9501120834.AA03575@fishpond.amigalib.com> Subject: Re: Problems with sh To: cyberspace.org!fog (Federico Di Gregorio) Date: Thu, 12 Jan 1995 08:34:17 +0700 (MST) From: "Fred Fish" Cc: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Federico Di Gregorio" at Jan 12, 95 08:09:42 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 854 > Running the configure script from libobjects-0.1.2 with sh configure (sh > from gcc 2.6.3 dist.) gives me an error: floating exception. > Running the configure from libobjects-0.1.0 with sh from 2.6.1 dist. > gives no error. I don't think there is an error in the script (but I > can't be sure, i am really bad at sh scripts). Because the new sh > replacedc the old I can't try the version that worked fine... Do you have an FPU? Which version of ixemul.library is installed, the one with FPU support of soft-float support? There has been a reproducible problem here that I have noticed quite a while where if I use the soft-float version of ixemul on an A4000 I get similar problems, but installing the FPU version makes them go away. Perhaps that is the case here... I hope to track this down before the release of FreshFish Vol 8... -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Jan 12 17:50:57 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <92750-1>; Thu, 12 Jan 1995 17:48:50 +0200 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA04180; Thu, 12 Jan 1995 16:52:13 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9501121552.AA04180@decap2.zdv.uni-tuebingen.de> Subject: Writing Libraries with gcc To: amiga-gcc-port@nic.funet.fi Date: Thu, 12 Jan 1995 16:52:11 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 317 Hi, I would like to write a library with gcc. Besides the Library init stuff (which can be done in assembler) the only problem is to tell gcc that certain arguments arrive in registers. How can this be done? And is it possible to backup/initialize/restore the a4 register, if -fbaselrel would work finally? Jochen From amiga-gcc-port-owner@nic.funet.fi Thu Jan 12 22:28:16 1995 Received: from godot.lysator.liu.se ([130.236.254.154]) by nic.funet.fi with ESMTP id <92794-1>; Thu, 12 Jan 1995 22:26:44 +0200 Received: from lysita (nisse@lysita.lysator.liu.se [130.236.254.153]) by godot.lysator.liu.se (8.6.8.1/8.6.6) with ESMTP id VAA14272; Thu, 12 Jan 1995 21:26:30 +0100 Received: from localhost (nisse@localhost) by lysita (8.6.5/8.6.5) id VAA17332; Thu, 12 Jan 1995 21:26:13 +0100 Date: Thu, 12 Jan 1995 21:26:13 +0100 From: nisse@lysator.liu.se Message-Id: <199501122026.VAA17332@lysita> To: gt1567b@prism.gatech.edu CC: amiga-gcc-port@nic.funet.fi In-reply-to: <199501120601.BAA01937@acmez.gatech.edu> (gt1567b@prism.gatech.edu) Subject: Re: AmigaGuide > I've got a SMALL test program I'm using that just does the AmigaGuide stuff, > but I can't make it work- GCC says it can't find where the AmigaGuide functions > are supposed to go- "t:cc9994881.o: Undefined symbol _OpenAmigaGuide > referenced from text segment" > I've put the only .h files that came with AmigaGuide in the proper place, > either clib/ or libraries. You have to either include the corresponding inline file, for example . This will tell gcc how to call the functions directly with register arguments. Or you have to link with a library with stub functions. I'm not sure if such a library is included with gcc. There used to be a libamy.a file, that was free and contained the necessary stub functions. You can also run hunk2gcc on C= amiga.lib to create the libamiga.a file, that I think is not included with gcc, as it is copyrighted by C=. From amiga-gcc-port-owner@nic.funet.fi Fri Jan 13 02:26:54 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <92542-2>; Fri, 13 Jan 1995 02:25:33 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Fri, 13 Jan 95 01:24 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Fri, 13 Jan 95 01:21 MET Message-Id: Subject: amidocumentation To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Fri, 13 Jan 1995 01:21:44 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 817 i uploaded the first version of amidocumentation to philips ftp-site. its not ready yet but i dont have much time to spend, so i will call this a alpha-release for all co-devellopers(porters). some major parts are missing : - building a library - building a device - iff because i have some problems with the asm-codes provided from C=. if somebody is willing to take the task of makeing this *.i as compatible i can offer a smal awk script to convert the baisc types. Some fine-tuning is still nessesary. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Jan 13 10:05:21 1995 Received: from dfunms.rus.uni-stuttgart.de ([129.69.1.162]) by nic.funet.fi with SMTP id <92774-4>; Fri, 13 Jan 1995 09:59:54 +0200 Received: from ifr1.luftfahrt.uni-stuttgart.de by dfunms.rus.uni-stuttgart.de with SMTP id AA13135 (5.65c8/DFUE-M1.0 for ); Fri, 13 Jan 1995 08:59:46 +0100 Received: from ifr10 by ifr1.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-1.0NeXT+) id AA24596; Fri, 13 Jan 95 08:59:45 +0100 Message-Id: <9501130759.AA24596@ifr1.Luftfahrt.Uni-Stuttgart.DE> Received: by ifr10.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-S1.0NeXT+) id AA14314; Fri, 13 Jan 95 08:59:42 +0100 Date: Fri, 13 Jan 95 08:59:42 +0100 From: raimund@ifr.luftfahrt.uni-stuttgart.de Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: amiga-gcc-port@nic.funet.fi Subject: libgnat.a Hi, where can I find libgnat.a or the sources for this library for amiga. I am trying to compile and link some stuff with the Gnat1.82 package from aminet. Compiling is running well but linking didn't work so far. Anybody out there who can help? Thanks Raimund From amiga-gcc-port-owner@nic.funet.fi Fri Jan 13 12:57:18 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <92818-1>; Fri, 13 Jan 1995 12:55:44 +0200 Received: by colombo.telesys-innov.fr; Fri, 13 Jan 1995 11:17:53 +0100 From: Philippe BRAND Message-Id: <199501131017.LAA05804@colombo.telesys-innov.fr> Subject: Hollidays To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Fri, 13 Jan 1995 11:17:51 +0100 (MEZ) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 276 I'm going on Hollidays this afternoon, Friday 13th until Sunday 22th. I plan to have my personnal A3000 rebuilt after. PS: I've moved and compressed Walter's files into /pub/amigados-gnu. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Fri Jan 13 15:09:04 1995 Received: from laphroaig.cs.hut.fi ([130.233.192.94]) by nic.funet.fi with SMTP id <92785-4>; Fri, 13 Jan 1995 14:59:50 +0200 Received: by laphroaig.cs.hut.fi id AA04928 (5.65c8/HUTCS-C 1.3 for amiga-gcc-port@nic.funet.fi (amiga gcc-list)); Fri, 13 Jan 1995 14:57:41 +0200 Date: Fri, 13 Jan 1995 14:57:41 +0200 Message-Id: <199501131257.AA04928@laphroaig.cs.hut.fi> From: Tomi Ollila Reply-To: To: Walter Harms Cc: amiga-gcc-port@nic.funet.fi (amiga gcc-list) Subject: amidocumentation In-Reply-To: References: Walter Harms writes: > > > i uploaded the first version of amidocumentation > to philips ftp-site. its not ready yet but i dont > have much time to spend, so i will call this a > alpha-release for all co-devellopers(porters). > some major parts are missing : > > - building a library > - building a device > - iff > I have written some library romtag routines in C. The library I am working on is not ready yet, but since I don't currently have time working on it, I'll upload the current code to file ftp://kampi.hut.fi/AmiTCP/deblib.lha. I have been compiling this with gcc 2.6.0 crosscompiler on a sun. The first module, `resbase.c' gives some warnings that some code as required to be constant is not constant, but the romtag table will be located at the start of executable file. The code I uploaded will compile, but it is not working correctly. I have had problems starting a daemon process from librarybase initroutine. If someone has time and interest to look more closely to the code that would be nice (the code will be GPL'ed). > walter Tomi From amiga-gcc-port-owner@nic.funet.fi Fri Jan 13 15:16:14 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <92782-3>; Fri, 13 Jan 1995 15:08:50 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Fri, 13 Jan 95 14:06 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Fri, 13 Jan 95 13:53 MET Message-Id: Subject: re:hollidays To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Fri, 13 Jan 1995 13:53:51 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 442 hi philip, without internet, amiga even computers in the holliday's ? ;) walter ps: the files were already compressed ! i only tar compressed files ! -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Jan 13 20:28:47 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <92542-1>; Fri, 13 Jan 1995 20:25:15 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189465>; Fri, 13 Jan 1995 19:24:30 +0100 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA21409; Fri, 13 Jan 1995 19:24:18 +0100 Date: Fri, 13 Jan 1995 19:24:18 +0100 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9501131824.AA21409@nereid.rz.Uni-Osnabrueck.DE> To: amiga-gcc-port@nic.funet.fi It seems that libnix has problems with std-functions, that is i.e. printf cannot print doubles or not knowing about ioctl(). clearly this is not the object of libnix, as it only glues Amiga-functions, but when compiling with -noixemul (my way to invoke libnix) I expect strongly that ld gets the objects from libc (compiler option -v tells me I'm right). This is not the case and I can't get ld to link with libnix AND the proper standart-lib. This wouldn't be a problem as I can live without libnix, but I am not able to call Amiga-functions with ixemul. This problem is discussed before and the answer was to use inline/xxx.h or libamiga.a. I have tried this w/o any results. I used version 2.6.3 w/ -m68030 -m68881. For testing libnix, try: main() { printf("%lf\n",3.141); Delay(50); } Delay() works ok, but look at the printout. To test it with ixemul (simply removed -noixemul from option list) add: #include Now, the _Delay() is unknown. Can anybody help me ? May the source be with you ! Thomas From amiga-gcc-port-owner@nic.funet.fi Sun Jan 15 02:40:46 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <92951-3>; Sun, 15 Jan 1995 02:37:49 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189465>; Sun, 15 Jan 1995 01:37:38 +0100 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA17124; Sun, 15 Jan 1995 01:37:25 +0100 Date: Sun, 15 Jan 1995 01:37:25 +0100 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9501150037.AA17124@nereid.rz.Uni-Osnabrueck.DE> To: amiga-gcc-port@nic.funet.fi Subject: ld bug report I have recently send a bug report about library handling in ld (or piping to ld). I said that one cannot glue the libamiga.a when using ixemul. This problem is general. When giving an option -llibraryname (amiga for example) to gcc or pipe this option with Wl,-llibraryname directly to ld, then look (use -v) what happens. ld will link first your library, next the object file created from your source. This order is evidently not correct. Before knowing about external references in your object code, searching in other libraries is senseless. My way to avoid that is to compile and assemble first and then link by hand, that is to give all options at linker level (nothing is piped to ld). To give an example: ld [search paths] [object code from source] [link-libraryies (-lamiga, -lc i.e.)] It's messy but it works ! If you don't know about search paths etc. then try the following steps: Compile dummy source with gcc -v and use your options (like -m68881) on command line (or specs). This will give you a report about what gcc is doing. Next, clip the part beginning with ld ... from screen and put it into your editor (conclip (from aminet) is easiest). Finally, rename the temp file t:xxxxx in the clip to whatever gcc calls the object when compiling with -c (no linking) (file.o I think it's named) and place all link libraries BEHIND (!) it. Maybe you save work if you use the inlining capabilities of gcc. But then you must have the .fd files and much more memory than I have (4MB). If there are other ways to avoid the misplacement of external link libraries then let me know. so long folks, Thomas From amiga-gcc-port-owner@nic.funet.fi Sun Jan 15 11:43:59 1995 Received: from deep.rsoft.bc.ca ([204.174.16.4]) by nic.funet.fi with SMTP id <93131-2>; Sun, 15 Jan 1995 11:42:28 +0200 Received: from mindlink.bc.ca by deep.rsoft.bc.ca with smtp (Smail3.1.28.1 #5) id m0rTRNv-000Ba7C; Sun, 15 Jan 95 01:36 PST Message-Id: Date: Sun, 15 Jan 95 01:36:23 -0800 To: amiga-gcc-port@nic.funet.fi Subject: GCC Configuration From: Colin_Fox@mindlink.bc.ca (Colin Fox) This sounds to me like a stupid question, but is there a way to get the gcc compiler to read compilation options out of a file instad of off of the command line? I've gone though the .guide files, and I haven't seen anything obvious. I'm writing a GUI based option program (much like SAS's SCOpts program), and I'd like to have it work a bit more elegantly than I have now. At the moment, I have a rexx script that invokes the compiler with a special file my options program creates. But this could cause problems in that a command line can't be more than 255 chars (at least, I believe that that is the limit). If anyone's interested in the options program (I plan to release it as freeware), it'll be available RSN (Real Soon Now), but I have to wait for my friend to finish his GUI library. (BTW, it's much nicer than MUI, and it's only 20k. :) -- ------ Colin Fox ------ Live Wire Designs ---------------------- ------ Colin_Fox@mindlink.bc.ca -------------------------------- From amiga-gcc-port-owner@nic.funet.fi Sun Jan 15 12:02:36 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <93134-2>; Sun, 15 Jan 1995 12:01:20 +0200 Received: by theseas.ntua.gr with UUCP; Sat, 14 Jan 1995 22:09:33 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05jz@kriton.UUCP>; Sat, 14 Jan 95 21:51:42 EET Date: Sat, 14 Jan 95 21:51:42 EET Message-Id: <9501141951.05jz@kriton.UUCP> In-Reply-To: <9501131824.AA21409@nereid.rz.Uni-Osnabrueck.DE> (from thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke)) (at Fri, 13 Jan 1995 19:24:18 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1808 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Re: Thomas Radtke's problesm w/ printf/Delay (Thomas Radtke), in <9501131824.AA21409@nereid.rz.Uni-Osnabrueck.DE> on Jan 13 wrote: > I used version 2.6.3 w/ -m68030 -m68881. For testing libnix, try: > > main() { printf("%lf\n",3.141); Delay(50); } > > Delay() works ok, but look at the printout. It prints 3.141--what should it print? If it prints "%ld", then you forgot to link with the math library (-lm switch): libnix, like the libraries of many amiga compilers, has an integer-only version of printf in the standard library, and a full implementation, including floats and doubles, in the math library. This saves you a few bytes if you don't need floating point numbers. > To test it with ixemul (simply removed -noixemul from option list) add: > > #include > > Now, the _Delay() is unknown. Can anybody help me ? The functions in are defined as "extern __inline". The "__inline" part only works if optimization is turned on, while, apparently, the "extern" part means "dont define this function if it is not inlined". I believe that the latter part is a recent addition, and I'm not sure I agree with it. As things are, you can only use the inline headers if you turn optimization on. Alternatively, you can link with libamiga.a, but you need to be careful not to use the wrong version of subroutines common in libamiga.a and libc.a, e.g., printf. One way to do this is to link using: -lc -lamiga. This way, you force the loader to scan libc.a first. (If you only specify -lamiga, libamiga.a will be scanned first, resulting in all kinds of weirdness.) Hope this helps, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "What's the use of a good quotation, if you can't change it?" ----- From amiga-gcc-port-owner@nic.funet.fi Sun Jan 15 21:51:06 1995 Received: from access4.digex.net ([164.109.10.7]) by nic.funet.fi with SMTP id <93326-1>; Sun, 15 Jan 1995 21:48:25 +0200 Received: by access4.digex.net id AA13203 (5.67b8/IDA-1.5 for List GCC ); Sun, 15 Jan 1995 14:48:15 -0500 Date: Sun, 15 Jan 1995 14:48:15 -0500 (EST) From: Nick Zajerko-McKee To: List GCC Subject: Does 2.6.3 Distribution support Sockets? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I have a package I'm trying to port from the UN*X world that uses sockets and was wondering if GCC 2.6.3 have socket capabilities? The package uses sockets locally to communicate with several sub tasks it spawned off. If GCC 2.6.3 does not, can someone point me in a good alternative? Thanks in advance, Nick Zajerko-McKee From amiga-gcc-port-owner@nic.funet.fi Mon Jan 16 13:23:32 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <92797-4>; Mon, 16 Jan 1995 13:17:11 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA22866 (5.65c8/IDA-1.4.4 for ); Mon, 16 Jan 1995 12:16:57 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA16651; Mon, 16 Jan 95 12:16:56 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9501161116.AA16651@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: your mail To: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Date: Mon, 16 Jan 1995 12:16:55 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9501131824.AA21409@nereid.rz.Uni-Osnabrueck.DE> from "Thomas Radtke" at Jan 13, 95 07:24:18 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 853 > > I used version 2.6.3 w/ -m68030 -m68881. For testing libnix, try: > > main() { printf("%lf\n",3.141); Delay(50); } > > Delay() works ok, but look at the printout. > Add -lm to the list of compiler options: libnix is a link library and this way you can save some code size in those cases you don't need floating point printout (this is the same way SAS does it). > To test it with ixemul (simply removed -noixemul from option list) add: > > #include > > Now, the _Delay() is unknown. Can anybody help me ? > Add -O3 to the list of options and it should work: gcc inlines functions only when optimizing. (Don't know why the linker doesn't look into libamiga.a. Maybe the specs file is broken.) Btw: With gcc2.6.3 you can use '#include ' like on any other Amiga compiler. Hope it helps. Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Jan 16 16:20:22 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <93674-2>; Mon, 16 Jan 1995 16:10:48 +0200 Received: by ceylon.informatik.uni-rostock.de id PAA21892; Mon, 16 Jan 1995 15:10:34 +0100 Received: by honshu.informatik.uni-rostock.de id PAA26236; Mon, 16 Jan 1995 15:10:33 +0100 From: Gunther Nikl Message-Id: <199501161410.PAA26236@honshu.informatik.uni-rostock.de> Subject: Re: ld bug report To: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Date: Mon, 16 Jan 1995 15:10:33 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9501150037.AA17124@nereid.rz.Uni-Osnabrueck.DE> from "Thomas Radtke" at Jan 15, 95 01:37:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 999 > I have recently send a bug report about library handling in ld (or piping to > ld). I said that one cannot glue the libamiga.a when using ixemul. This > problem is general. When giving an option -llibraryname (amiga for example) > to gcc or pipe this option with Wl,-llibraryname directly to ld, then look > (use -v) what happens. ld will link first your library, next the object file > created from your source. This order is evidently not correct. Before knowing > about external references in your object code, searching in other libraries > is senseless. My way to avoid that is to compile and assemble first and then > link by hand, that is to give all options at linker level (nothing is piped > to ld). To give an example: I do not consider the ld behavior a bug. I would call it normal... Why do you specify a "-l" BEFORE you give ld any object file to link ??? WRONG: gcc -lamiga -o HaHa haha.o CORRECT: gcc -o HaHa haha.o -lamiga Check it out. Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Jan 16 16:35:44 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <93676-2>; Mon, 16 Jan 1995 16:26:18 +0200 Received: by ceylon.informatik.uni-rostock.de id PAA21933; Mon, 16 Jan 1995 15:25:50 +0100 Received: by honshu.informatik.uni-rostock.de id PAA26314; Mon, 16 Jan 1995 15:25:49 +0100 From: Gunther Nikl Message-Id: <199501161425.PAA26314@honshu.informatik.uni-rostock.de> Subject: Re: Thomas Radtke's problesm w/ printf/Delay To: kyrimis@theseas.ntua.gr Date: Mon, 16 Jan 1995 15:25:48 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9501141951.05jz@kriton.UUCP> from "Kriton Kyrimis" at Jan 14, 95 09:51:42 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2015 > The functions in are defined as "extern __inline". The > "__inline" part only works if optimization is turned on, while, > apparently, the "extern" part means "dont define this function if it is > not inlined". I believe that the latter part is a recent addition, and > I'm not sure I agree with it. As things are, you can only use the inline > headers if you turn optimization on. I changed the "static" to a "extern" declaration. I believe its better to do the thing that way. 1. You avoid tons of warnings (function declared static follows nonstatic) 2. You only need the inlines if you are interested in short programs and have enough ram. In that case you obviosly compile with "-O" and then it works. Without "-O" linking with libamiga.a solves all :) problems Please note: Its no longer recommended to use the pair clib+inline. Instead should be used. This ensures that the program can be compiled with another compiler (provided the compiler has protos and the program does not use any gcc specific stuff) > Alternatively, you can link with libamiga.a, but you need to be careful > not to use the wrong version of subroutines common in libamiga.a and > libc.a, e.g., printf. One way to do this is to link using: -lc -lamiga. > This way, you force the loader to scan libc.a first. (If you only > specify -lamiga, libamiga.a will be scanned first, resulting in all > kinds of weirdness.) Currently there is no danger in linking with libamiga.a first, because the 2.6.(1|3) libraries do not contain (f)printf, (f)puts, etc. I saw no reason to to this (who wants those terrible amiga.lib versions anyway?). The only EXCEPTION is "sprintf()". This entry DOES exist in libamiga.a. It uses the exec-function "RawDoFmt()", so this sprintf() is very small but has not all features of a compiler-sprintf (ixemul/libnix). For programs that do not need all things of the "big" sprintf the libamiga.a entry is sufficient. Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Jan 16 20:13:37 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <93734-4>; Mon, 16 Jan 1995 20:10:26 +0200 Received: by theseas.ntua.gr with UUCP; Mon, 16 Jan 1995 20:09:47 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05kt@kriton.UUCP>; Mon, 16 Jan 95 20:04:49 EET Date: Mon, 16 Jan 95 20:04:49 EET Message-Id: <9501161804.05kt@kriton.UUCP> In-Reply-To: <199501161425.PAA26314@honshu.informatik.uni-rostock.de> (from Gunther Nikl ) (at Mon, 16 Jan 1995 15:25:48 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1484 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: gnikl@informatik.uni-rostock.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Thomas Radtke's problesm w/ printf/Delay > 1. You avoid tons of warnings (function declared static follows nonstatic) > 2. You only need the inlines if you are interested in short programs and > have enough ram. In that case you obviosly compile with "-O" and then > it works. > Without "-O" linking with libamiga.a solves all :) problems I'm convinced. Now, if only someone (Philippe?) would fix that broken specs file, so that libamiga.a would be scanned during linking... > Currently there is no danger in linking with libamiga.a first, because Not if you have a libamiga.a derived from amiga.lib. Amiga.lib contains several other goodies apart from stubs and printf, so I think that most people with access to it would prefer it over the version that comes with gcc. > The only EXCEPTION is "sprintf()". This entry DOES exist in libamiga.a. > It uses the exec-function "RawDoFmt()", so this sprintf() is very small > but has not all features of a compiler-sprintf (ixemul/libnix). For > programs that do not need all things of the "big" sprintf the libamiga.a > entry is sufficient. Watch out for things like: sprintf(buf, "%d", x), that will not work using the amiga.lib version. Use "%ld" instead. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Claims of superiority I always find extremely boring. There's always someone better--except in my case, of course." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jan 17 15:27:34 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <93966-4>; Tue, 17 Jan 1995 15:15:28 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Tue, 17 Jan 1995 14:10:16 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA00242; Tue, 17 Jan 95 14:10:15 +0100 Date: Tue, 17 Jan 95 14:10:15 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9501171310.AA00242@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA11999; Tue, 17 Jan 95 14:10:15 +0100 To: amiga-gcc-port@nic.funet.fi Subject: Where are the current patches for GCC Hi, are the patches for GCC and the BFD available per ftp somewhere? On Philippe's site perhaps? In the US? Thanks, Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Tue Jan 17 15:39:46 1995 Received: by nic.funet.fi id <93959-4>; Tue, 17 Jan 1995 15:31:59 +0200 From: Leonard Norrgard To: hoehle@inf-wiss.uni-konstanz.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9501171310.AA00242@inf-wiss.uni-konstanz.de> (hoehle@inf-wiss.uni-konstanz.de) Subject: Re: Where are the current patches for GCC Message-Id: <95Jan17.153159+0200_eet.93959-4+20@nic.funet.fi> Date: Tue, 17 Jan 1995 15:31:55 +0200 >are the patches for GCC and the BFD available per ftp somewhere? On >Philippe's site perhaps? In the US? A set of BFD patches can be found at ftp.funet.fi: /pub/amiga/gnu/gcc/amiga-0.1-gdb-4.12.diffs.gz Rumours say that someone is actively enhancing these pathes and actually writing ptrace(). Maybe they can speak up if a better version of BFD is available? -- vinsci From amiga-gcc-port-owner@nic.funet.fi Tue Jan 17 15:55:15 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <93987-4>; Tue, 17 Jan 1995 15:45:18 +0200 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA14322; Tue, 17 Jan 1995 14:44:07 +0100 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA01854; Tue, 17 Jan 95 14:44:06 +0100 Date: Tue, 17 Jan 95 14:44:06 +0100 From: isthesin@TechFak.Uni-Bielefeld.DE Message-Id: <9501171344.AA01854@moos.techfak.uni-bielefeld.de> To: amiga-gcc-port@nic.funet.fi Subject: Re: Where are the current patches Hi !!! There is at the moment no more recent version than that in /pub/amiga/gnu/gcc/amiga-0.1-gdb-4.12.diffs.gz on ftp.funet.fi Reason is that work on bfd is nearly finished. (Actually, at this very moment I am debugging the new linker...) Be patient..... AFAIK Raphael is still working on ptrace() Bye... Stephan From amiga-gcc-port-owner@nic.funet.fi Tue Jan 17 16:54:56 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <94043-1>; Tue, 17 Jan 1995 16:45:25 +0200 Received: by ceylon.informatik.uni-rostock.de id PAA25357; Tue, 17 Jan 1995 15:45:00 +0100 Received: by honshu.informatik.uni-rostock.de id PAA01472; Tue, 17 Jan 1995 15:45:00 +0100 From: Gunther Nikl Message-Id: <199501171445.PAA01472@honshu.informatik.uni-rostock.de> Subject: Re: Thomas Radtke's problesm w/ printf/Delay To: kyrimis@theseas.ntua.gr Date: Tue, 17 Jan 1995 15:44:59 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9501161804.05kt@kriton.UUCP> from "Kriton Kyrimis" at Jan 16, 95 08:04:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1223 > > Currently there is no danger in linking with libamiga.a first, because > > Not if you have a libamiga.a derived from amiga.lib. Amiga.lib contains > several other goodies apart from stubs and printf, so I think that most > people with access to it would prefer it over the version that comes > with gcc. Arrgh! There is _no_ need in using a converted amiga.lib. Sometimes it is even dangerous using the converted version. The problem are some goodies that use "jsr func(pc)". That breaks totally with gcc. Please note: since 2.6.1 you can (and should) use the libamiga.a's from the gcc distribution. The libraries contain all necessary stuff (complete 3.1 stubs+varargs, hook support, DoMethod(A), CoerceMethod(A), etc). The only missing things are: the ffp-support, int-math support, some assembly entries. I doubt that anyone is missing these function. > Watch out for things like: sprintf(buf, "%d", x), that will not work > using the amiga.lib version. Use "%ld" instead. Oh sorry, I forgot to mention that RawDoFmt() assumes 16bit ints. For large ints its nessecary to provide the "l" as you did above. You are totally right, but with that in mind it can safely be used. Gunther From amiga-gcc-port-owner@nic.funet.fi Tue Jan 17 21:07:25 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <94043-2>; Tue, 17 Jan 1995 21:03:24 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id UAA12577; Tue, 17 Jan 1995 20:02:29 +0100 Received: by cindy.ct.se (uugate-036-SunOS-4.1.3); Tue, 17 Jan 95 18:45:19 +0100 Date: Tue, 17 Jan 95 15:28:00 +0100 Message-ID: From: henrik.laurila@sirius.ct.se (Henrik Laurila) Subject: `special' characters in the command-line To: amiga-gcc-port@lists.funet.fi Reply-To: henrik.laurila@sirius.ct.se X-Mailer: uugate 0.36 (SunOS 4.1.3) I have tested gcc v2.6.3 a little for a while now, and most thing seems to work well, but there is a small irritating bug that is still present in this Amiga-port of gcc. I have not found it in any other port ( I have tested a few). Programs compiled with gcc do have some problems in parsing the command-line if the arguments contains certain `special' characters. The characters that I have problems with are treated as `white space'. The following characters are treated as `white space': ascii LaTeX 196 \"{A} 214 \"{O} 229 {\aa} 246 \"{o} but the these characters are treated normally: 197 {\AA} 228 \"{a} You will find the bug with this program: -- #include main(argc,argv) int argc; unsigned char *argv[]; { int i; for ( i=0; i; Tue, 17 Jan 1995 21:52:16 +0200 Message-ID: <9501171259.AA01271@fishpond.amigalib.com> Subject: Re: `special' characters in the command-line To: henrik.laurila@sirius.ct.se Date: Tue, 17 Jan 1995 12:58:53 +0700 (MST) From: "Fred Fish" Cc: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "sirius.ct.se!henrik.laurila" at Jan 17, 95 03:28:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 753 > The following characters > are treated as `white space': > but the these characters > are treated normally: I just tried this with the version of gcc 2.6.3 that will be on my next FreshFish CD, using the following test program: char string[] = {196, 214, 229, 246, 197, 228, '\n', 0}; #include main(argc,argv) int argc; unsigned char *argv[]; { printf (string); printf ("%s", string); } The string that was printed was identical in both cases, and were the characters you would expect: (output of "od -t u1" on output strings) 196 214 229 246 197 228 10 196 214 229 246 197 228 10 Perhaps there is either something wrong with your gcc, your installation, or I'm not understanding the problem. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Jan 18 01:50:55 1995 Received: from Jane.UH.EDU ([129.7.1.3]) by nic.funet.fi with ESMTP id <92699-1>; Wed, 18 Jan 1995 01:46:58 +0200 Received: from Jetson.UH.EDU by Jetson.UH.EDU (PMDF V4.3-10 #8380) id <01HLYLY1AKCW8Y7EIO@Jetson.UH.EDU>; Tue, 17 Jan 1995 17:26:38 -0600 (CST) Date: Tue, 17 Jan 1995 17:26:38 -0600 (CST) From: ST1NR@Jetson.UH.EDU Subject: "Double define __P" To: amiga-gcc-port@nic.funet.fi Message-id: <01HLYLY1FDYQ8Y7EIO@Jetson.UH.EDU> X-VMS-To: IN%"amiga-gcc-port@nic.funet.fi" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT When compiling it get the following output: g++ -v -c darray.cc gcc -v -c darray.cc Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/cpp -lang-c++ -v -undef -D__GNUC__= GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/lib/g++-include /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. In file included from /gnu/include/stdlib.h:67, from darray.cc:4: /gnu/include/sys/cdefs.h:55: warning: `__P' redefined /gnu/lib/g++-include/libio.h:62: warning: this is the location of the previous definition /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/cc1plus t:cc249264.ii -quiet -dump base darray.cc -version -o t:cc249264.s GNU C++ version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3. as -mc68010 -o darray.o t:cc249264.s I checked both /gnu/include/sys/cdefs.h and /gnu/lib/g++-include/libio.h `__P' defined in both include files. The dates of the files follows. cdefs.h 3074 ----rwed 23-Feb-94 00:16:14 libio.h 7464 ----rwed 31-Jul-94 20:47:50 Clinton Bell From amiga-gcc-port-owner@nic.funet.fi Wed Jan 18 10:45:10 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <92598-3>; Wed, 18 Jan 1995 10:35:09 +0200 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA04571 (5.65c-6/7.3w-FAU); Wed, 18 Jan 1995 09:34:54 +0100 Received: from pctc.chemie.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA18346 (5.65c-6/7.3m-FAU); Wed, 18 Jan 1995 09:34:52 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA24392; Wed, 18 Jan 1995 09:34:40 +0100 Date: Wed, 18 Jan 1995 09:34:40 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9501180834.AA24392@pctc.chemie.uni-erlangen.de> To: amiga-gcc-port@nic.funet.fi Subject: g++ problem (gcc263 aminet) again Hello, I compared the libg++.a from gcc263 with gcc260. The libg++.a have the same date and length. Does this force the problems while linking c++ programs ? Servus -- Thomas Walter walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Wed Jan 18 21:32:09 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91355-4>; Wed, 18 Jan 1995 21:26:41 +0200 Received: by theseas.ntua.gr with UUCP; Wed, 18 Jan 1995 21:26:49 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05lx@kriton.UUCP>; Wed, 18 Jan 95 21:06:20 EET Date: Wed, 18 Jan 95 21:06:20 EET Message-Id: <9501181906.05lx@kriton.UUCP> In-Reply-To: (from henrik.laurila@sirius.ct.se (Henrik Laurila)) (at Tue, 17 Jan 95 15:28:00 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 706 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Re: `special' characters in the command-line Henrik Laurila, in on Jan 17 wrote: > tested a few). Programs compiled with gcc do have some problems in parsing > the command-line if the arguments contains certain `special' characters. > The characters that I have problems with are treated as `white space'. Apparently, the problem lies in the ixemul startup code (printf checks out OK, and compiling with -noixemul eliminates the problem). Looks like crt0.o is not 8-bit clean. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Did you just see what I didn't see?" "No." "Neither did I!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Jan 18 21:32:10 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91273-3>; Wed, 18 Jan 1995 21:26:42 +0200 Received: by theseas.ntua.gr with UUCP; Wed, 18 Jan 1995 21:26:47 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05m2@kriton.UUCP>; Wed, 18 Jan 95 21:13:56 EET Date: Wed, 18 Jan 95 21:13:56 EET Message-Id: <9501181913.05m2@kriton.UUCP> In-Reply-To: <9501171259.AA01271@fishpond.amigalib.com> (from "Fred Fish" ) (at Tue, 17 Jan 1995 12:58:53 +0700 (MST)) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 941 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Re: `special' characters in the command-line Fred Fish, in <9501171259.AA01271@fishpond.amigalib.com> on Jan 17 wrote: > I just tried this with the version of gcc 2.6.3 that will be on my next > FreshFish CD, using the following test program: > > char string[] = {196, 214, 229, 246, 197, 228, '\n', 0}; > > #include > main(argc,argv) > int argc; > unsigned char *argv[]; > { > printf (string); > printf ("%s", string); > } The problem Henrik Laurila was describing referred to parsing the command line incorrectly, and not to printf, which was only used to display the incorrect data. As it looks like the problem lies in ixemul's crt0.o not being 8-bit clean, I'm fairly certain that the FreshFish version has the problem as well. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Did you just see what I didn't see?" "No." "Neither did I!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Jan 18 21:32:11 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <92064-1>; Wed, 18 Jan 1995 21:26:59 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id UAA25056; Wed, 18 Jan 1995 20:26:00 +0100 Received: by cindy.ct.se (uugate-036-SunOS-4.1.3); Wed, 18 Jan 95 19:07:15 +0100 Date: Wed, 18 Jan 95 15:02:00 +0100 Message-ID: From: henrik.laurila@sirius.ct.se (Henrik Laurila) Subject: `special' characters in the command-line To: amiga-gcc-port@nic.funet.fi Reply-To: henrik.laurila@sirius.ct.se X-Mailer: uugate 0.36 (SunOS 4.1.3) In a message of 17 Jan 95 Fred Fish wrote to me: FF> Perhaps there is either something wrong with your gcc, your FF> installation, or I'm not understanding the problem. I probably expressed the problem too vaguely. The problem is not with printf, it's the reading of arguments from the command-line into argv ( and argc) that failes. If I compile this program: -- #include main(argc,argv) int argc; unsigned char *argv[]; { int i; for ( i=1; i TestProgram <229><228><246><197><196><214> ( is a singel character with the value xxx, so the argument to TestProgram is one string of six characters whithout any spaces.) I will get this result: argument 1 = <228> argument 2 = <197> /Henrik Laurila ! FYSIK_KRYO@ursula.lucas.lu.se ! voice:+46-(0)40-960766/ /Kvartettgatan 6 ! laurila@df.lth.se ! modem:+46-(0)40-924190/ ( UUCP Dialup connection ) From amiga-gcc-port-owner@nic.funet.fi Thu Jan 19 01:24:20 1995 Received: from fishpond.amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91355-2>; Thu, 19 Jan 1995 01:14:07 +0200 Message-ID: <9501181619.AA01738@fishpond.amigalib.com> Subject: Re: `special' characters in the command-line To: kyrimis@theseas.ntua.gr Date: Wed, 18 Jan 1995 16:17:57 +0700 (MST) From: "Fred Fish" Cc: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9501181913.05m2@kriton.UUCP> from "kriton!kyrimis" at Jan 18, 95 09:13:56 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2618 > From smtp Wed Jan 18 12:40 MST 1995 > Received: from theseas.ntua.gr by fishpond.amigalib.com; Wed, 18 Jan 95 12:40 MST > Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by cygnus.com (8.6.9/8.6.9) with ESMTP id LAA28028 for ; Wed, 18 Jan 1995 11:32:31 -0800 > Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91273-3>; Wed, 18 Jan 1995 21:26:42 +0200 > Received: by theseas.ntua.gr with UUCP; Wed, 18 Jan 1995 21:26:47 +0200 > Received: by kriton.UUCP (V1.17-beta/Amiga) > id <05m2@kriton.UUCP>; Wed, 18 Jan 95 21:13:56 EET > Date: Wed, 18 Jan 95 21:13:56 EET > Content-Type: text > Message-Id: <9501181913.05m2@kriton.UUCP> > In-Reply-To: <9501171259.AA01271@fishpond.amigalib.com> > (from "Fred Fish" ) > (at Tue, 17 Jan 1995 12:58:53 +0700 (MST)) > X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) > Organization: My Home > Reply-To: kyrimis@theseas.ntua.gr > Content-Length: 941 > From: theseas.ntua.gr!kriton!kyrimis (Kriton Kyrimis) > To: nic.funet.fi!amiga-gcc-port > Subject: Re: `special' characters in the command-line > > Fred Fish, in <9501171259.AA01271@fishpond.amigalib.com> on Jan 17 wrote: > > > I just tried this with the version of gcc 2.6.3 that will be on my next > > FreshFish CD, using the following test program: > > The problem Henrik Laurila was describing referred to parsing the > command line incorrectly, and not to printf, which was only used to > display the incorrect data. As it looks like the problem lies in > ixemul's crt0.o not being 8-bit clean, I'm fairly certain that the > FreshFish version has the problem as well. I just tried it again now that I understand the problem. I'm using the crt0.o from the 2.6.3 gcc distribution on aminet, and ixemul libraries that I compiled myself (see an earlier note on this list, they are available in pub/amiga/files/ixemul-40.4.X.lha on ftp.amigalib.com). I ran this program with gcc:bin/sh: cat >bugtest.c < main(argc,argv) int argc; unsigned char *argv[]; { int i; for (i = 0; i < argc; i++) { printf ("argv[%d] = %s\n", i, argv[i]); } } done gcc -o bugtest bugtest.c echo \304\326\345\366\305\344 bugtest \304\326\345\366\305\344 and got: \304\326\345\366\305\344 argv[0] = bugtest argv[1] = \304\326\345\366\305\344 Where the actual characters have been replaced in this mail by octal characters so that mailers will not croak on it. So it seems to work fine here, where the only significant difference is the use of recompiled ixemul libraries. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Jan 19 22:52:15 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <91269-3>; Thu, 19 Jan 1995 22:47:12 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id VAA15358; Thu, 19 Jan 1995 21:46:12 +0100 Received: by cindy.ct.se (uugate-036-SunOS-4.1.3); Thu, 19 Jan 95 19:15:48 +0100 Date: Thu, 19 Jan 95 14:24:00 +0100 Message-ID: From: henrik.laurila@sirius.ct.se (Henrik Laurila) Subject: `special' characters in the command-line To: amiga-gcc-port@lists.funet.fi Reply-To: henrik.laurila@sirius.ct.se X-Mailer: uugate 0.36 (SunOS 4.1.3) FF> I just tried it again now that I understand the problem. I'm using FF> the crt0.o from the 2.6.3 gcc distribution on aminet, and ixemul FF> libraries that I compiled myself (see an earlier note on this list, FF> they are available in pub/amiga/files/ixemul-40.4.X.lha on FF> ftp.amigalib.com). I have now tested with the ixemul.libraries in this release, but I got different results depending of which ixemul.library I use, from this archive. FF> So it seems to work fine here, where the only significant difference FF> is the use of recompiled ixemul libraries. Which library did you use in your test? The best result I have got was four of the six characters. /Henrik Laurila ! FYSIK_KRYO@ursula.lucas.lu.se ! voice:+46-(0)40-960766/ /Kvartettgatan 6 ! laurila@df.lth.se ! modem:+46-(0)40-924190/ ( UUCP Dialup connection ) From amiga-gcc-port-owner@nic.funet.fi Thu Jan 19 23:16:40 1995 Received: from fishpond.amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <92797-2>; Thu, 19 Jan 1995 23:12:17 +0200 Message-ID: <9501191419.AA04164@fishpond.amigalib.com> Subject: Re: Possible 8-bit clean problem with crt0/ixemul To: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) Date: Thu, 19 Jan 1995 14:19:25 +0700 (MST) From: "Fred Fish" Cc: fnf@fishpond.amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 395 > FF> So it seems to work fine here, where the only significant difference > FF> is the use of recompiled ixemul libraries. > > Which library did you use in your test? The best result I have got was > four of the six characters. I think I currently have the 68040+fpu version installed on my system. I'll try it with one or two others. If I can reproduce it, I will try to fix it. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Jan 20 00:45:48 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <92800-4>; Fri, 20 Jan 1995 00:43:27 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 19 Jan 95 23:39 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 19 Jan 95 23:27 MET Message-Id: Subject: makefile maker To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 19 Jan 1995 23:27:45 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 735 i got a makefile maker from usenet. it takes a *.c file to create a makefile for it. his advantage is, its small ~1000 lines. i compiled it with gcc for amiga no problems so far. problem: files are for borland-make ;) should be easy to change if someone is interessted, mail me. i havent the tiem to check this program out but it looks vert nice for a pc prg. walter ps: its not intendet for large projects i think but for a bit homework ideal. -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Jan 20 01:03:32 1995 Received: from undergrad.math.uwaterloo.ca ([129.97.204.13]) by nic.funet.fi with SMTP id <92805-4>; Fri, 20 Jan 1995 01:00:54 +0200 Received: from napier.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57025-2>; Thu, 19 Jan 1995 18:00:34 -0500 Date: Thu, 19 Jan 1995 18:00:20 -0500 From: Jeff Shepherd Subject: Re: makefile maker To: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Jan 1995, Walter Harms wrote: > > i got a makefile maker from usenet. it takes a *.c file to > create a makefile for it. his advantage is, its small ~1000 lines. > i compiled it with gcc for amiga no problems so far. > problem: files are for borland-make ;) should be easy to change > if someone is interessted, mail me. i havent the tiem to check > this program out but it looks vert nice for a pc prg. > > walter Sometime ago I made a makefile maker (which I called makemake) which outputs gnu make compatible makefiles. Makemake works well for small projects and the code its small. It has been successfully compiled on machines running SunOS and Ultrix so there is no compatibility problems. If there are any requests for this program I could post the source here or upload it to aminet. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/index.html Had this been an actual emergency, we would have fled in terror, and you would not have been informed. From amiga-gcc-port-owner@nic.funet.fi Fri Jan 20 05:21:12 1995 Received: from access4.digex.net ([164.109.10.7]) by nic.funet.fi with SMTP id <92823-2>; Fri, 20 Jan 1995 05:19:28 +0200 Received: by access4.digex.net id AA11408 (5.67b8/IDA-1.5 for List GCC ); Thu, 19 Jan 1995 22:19:06 -0500 Date: Thu, 19 Jan 1995 22:19:05 -0500 (EST) From: Nick Zajerko-McKee To: List GCC Subject: AmiTCP/IP 4.0 libs.... Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I'm trying to port a UN*X program that uses sockets. It has been suggested that I go ahead and get the AmiTCP/IP 4.0 sdk. I got the full kit (sdk & usr) and saw that the libs where in SAS format. I tried hunk2gcc and it said I needed them converted into ALINK format. I wasn't sure how to do that, any suggestions (I own SAS 6.51). Since I couldn't go w/ SAS to make GNU .a file, I tried modifying the smake file to work w/ GCC and now I have several preprocessor errors and compiler errors. Can someone point me in a good direction to continue on? I would like to keep the network capability if possible, but push comes to shove, I guess I can go back and modify the code to run w/ Amiga messages. Thanks, Nick Zajerko-McKee. From amiga-gcc-port-owner@nic.funet.fi Fri Jan 20 15:17:52 1995 Received: from prdnet.polaroid.com ([137.252.9.11]) by nic.funet.fi with ESMTP id <92696-4>; Fri, 20 Jan 1995 15:08:48 +0200 Date: Fri, 20 Jan 1995 08:08:10 -0500 (EST) From: "David J. Ruscak" Subject: AmiTCP/IP 4.0 libs To: amiga-gcc-port@lists.funet.FI Content-transfer-encoding: 7BIT Mailer: Elm [revision: 70.85] Message-Id: <95Jan20.150848+0200_eet.92696-4+24@nic.funet.fi> Re: Nick Zajerko-McKee problems. This arexx program is based on help from Philippe BRAND. /********************************HISTORY********************************** * 18-DEC-94 : DJR : Created * ************************************************************************** * * * Name : saslib2libgcc * * Author : David J. Ruscak ruscakd@polaroid.com * * Created : 18-DEC-94 * * Purpose : to convert SAS libraries to GCC libraries * * * *************************************************************************/ /* To convert a SAS library to a GCC format library several steps are involved. 1) cd to RAM: Either copy the library to RAM: or give the full path name. EX: gnu:saslib2libgcc X11:lib/Xtnb.lib 2) You need the SAS Librarian 'oml' with a version => Library otherwise you'll get an error such as 'unknown hunk'. 3) You need hunk2gcc, mv, ar and ranlib. If your using gcc you have the fastram, VMM2.1 swap works fine too. */ /* TRACE R */ SIGNAL ON ERROR OPTIONS RESULTS IF ~SHOW('l','rexxsupport.library') THEN IF (~ADDLIB("rexxsupport.library",0,-30,0)) THEN DO ECHO "Can't load rexxsupport.library" EXIT 10 END fullname = "" PARSE ARG fullname IF fullname == "" THEN DO ECHO " No Library to convert" ECHO "" ECHO " EX: gnu:saslib2libgcc X11:lib/Xtnb.lib" EXIT 10 END IF (~EXISTS(fullname)) THEN DO ECHO "Can't find" fullname EXIT 10 END ADDRESS COMMAND /* make 2 directories for object files */ IF EXISTS('object') THEN DO ECHO "Directory object exists Please delete or rename it." EXIT END 'makedir object' IF EXISTS('object2') THEN DO ECHO "Directory object2 exists Please delete or rename it. " EXIT END 'makedir object2' 'oml -oobject 'fullname 'X *' /* SAS Object Librarian */ IF EXISTS('object') THEN DO objfiles = SHOWDIR('object','F') /* list of all object files */ nfiles = WORDS(SHOWDIR('object','F')) /* count of object files */ DO UNTIL nfiles == 0 /* must be a more efficient way... */ 'hunk2gcc >NIL: object/'WORD(objfiles,nfiles) /* convert to GCC object */ 'mv >NIL: obj.#? object2/'WORD(objfiles,nfiles) /* restore original names*/ nfiles = nfiles - 1 END END 'cd object2' /* directory of converted objects */ path = PRAGMA('D','object2') IF (INDEX(fullname,':') > 0) THEN /* strip out assign */ fullname = SUBSTR(fullname,LASTPOS(':',fullname) + 1) IF (INDEX(fullname,'/') > 0) THEN /* strip off directories */ libname = SUBSTR(fullname,LASTPOS('/',fullname) + 1) ELSE libname = fullname dot = POS('.',libname) gcclibname = 'lib'SUBSTR(libname,1,dot)'a' 'ar qc 'gcclibname' #?.o' /* archive new library */ 'ranlib 'gcclibname IF EXISTS(gcclibname) THEN DO needslash = LASTPOS(':',path) IF ~(needslash == LENGTH(path)) THEN path = path'/' ECHO " The following indicate a hunk2gcc error:" ECHO " Short reloc into N_DATA, what should I do? ECHO " Short reloc into N_BSS, what should I do? ECHO "" ECHO "" ECHO " Remember to move/rename "path"object2/"gcclibname" appropriately ." END ELSE ECHO "No library created, what could have gone wrong ????" EXIT ERROR: ECHO " error = "RC ECHO " Hope its not the dreaded *Invalid Hunk type*" EXIT From amiga-gcc-port-owner@nic.funet.fi Fri Jan 20 17:41:25 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <92719-2>; Fri, 20 Jan 1995 17:33:52 +0200 Received: from rz-sun1.fh-weingarten.de by noc.BelWue.DE with SMTP id AA10047 (5.65c8/IDA-1.4.4 for ); Fri, 20 Jan 1995 16:33:29 +0100 Received: from by rz-sun1.FH-Weingarten.DE (4.1/BelWue-1.2SUN+) id AB03199; Fri, 20 Jan 95 16:32:52 +0100 Received: From RZ-NOV2/WORKQUEUE by charon.rz.fh-weingarten.de via Charon-4.0-VROOM with IPX id 100.950120162943.896; 20 Jan 95 16:32:45 -100 Message-Id: From: "Herzer Armin Assi(FBP)" Organization: FH-Weingarten (Rechenzentrum) To: amiga-gcc-port@nic.funet.fi Date: Fri, 20 Jan 1995 16:29:33 GMT+200 Subject: kbhit() with amiga gcc Priority: normal X-Mailer: Pegasus Mail v3.22 Hello all, I am using GCC with both, AMIGA and PC (ok, more PC than AMIGA for the last months). But now I want to compile a PC file on AMIGA and found, that there is no kbhit()-function (in DJGPP you find this function in pc.h). kbhit() checks the keyboard and continues with the program execution if no key is or was pressed and (in my case) if pressed prints out some status information and continues after that with the program. Is there a similar function in AMIGA GCC too (sorry if this is a stupid question but I didn't find anything in the includes). Thanks for your help, Armin Armin Herzer Fachhochschule Ravensburg-Weingarten Postfach 1261 88241 Weingarten Germany email: herzer@fbp.fh-weingarten.de From amiga-gcc-port-owner@nic.funet.fi Fri Jan 20 17:53:32 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <92785-4>; Fri, 20 Jan 1995 17:46:00 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA06596; Fri, 20 Jan 1995 15:45:47 GMT From: Peter Ivimey-Cook Message-Id: <22611.199501201545@creda.isltd.insignia.com> Subject: Re: kbhit() with amiga gcc To: HERZER@rz-nov2.rz.fh-weingarten.de (Herzer Armin Assi) Date: Fri, 20 Jan 1995 15:45:04 GMT Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: ; from "Herzer Armin Assi" at Jan 20, 95 4:29 pm X-Mailer: elm X-Mailer: Elm [revision: 109.14] > > Is there a similar function in AMIGA GCC too (sorry if this is a > stupid question but I didn't find anything in the includes). Look into the DOS function to get characters from the console ("GetChar" from memory - its been a while) which, if given a 0 delay does more-or-less what you're after. Otherwise look into the use of the RAW: console stream or using Intuitiion events. Regards, Peter -- Peter Ivimey-Cook Mail Id: peteric@isltd.insignia.com Insignia Solutions, Kingsmead Business Park, London Road, High Wycombe, Buckinghamshire. Telephone: +44-1494-459426 HP11 1JU, U.K. Fax: +44-1494-459720 From amiga-gcc-port-owner@nic.funet.fi Fri Jan 20 19:47:54 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <92826-2>; Fri, 20 Jan 1995 19:44:30 +0200 Received: by theseas.ntua.gr with UUCP; Fri, 20 Jan 1995 19:45:51 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05n1@kriton.UUCP>; Fri, 20 Jan 95 19:39:16 EET Date: Fri, 20 Jan 95 19:39:16 EET Message-Id: <9501201739.05n1@kriton.UUCP> In-Reply-To: (from "Herzer Armin Assi(FBP)" ) (at Fri, 20 Jan 1995 16:29:33 GMT+200) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 2012 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: Herzer Armin Assi@kriton.UUCP Cc: amiga-gcc-port@lists.funet.fi Subject: Re: kbhit() with amiga gcc Hi Herzer (Herzer Armin Assi(FBP)), in on Jan 20 you wrote: > kbhit() checks the keyboard and continues with the program > execution if no key is or was pressed and (in my case) if > pressed prints out some status information and continues > after that with the program. > > Is there a similar function in AMIGA GCC too (sorry if this is a > stupid question but I didn't find anything in the includes). Not readily available, but here are a few functions that will do what you want: raw() will put your window in raw mode, so that every key pressed becomes immediately available to your program. cooked() undoes this behavior. kbhit() returns -1 if no input is available, or the next available character, if such exists. If you call it without having set your window in raw mode, it will only start returning characters when you hit the Enter key. I've included some example code using these three functions. NOTE: This is straight UNIX code, so it will only work with ixemul.library. ------------------------------CUT HERE------------------------------ #include #include void raw() { struct sgttyb sg; ioctl(0, TIOCGETP, &sg); sg.sg_flags |= RAW; ioctl(0, TIOCSETP, &sg); } void cooked() { struct sgttyb sg; ioctl(0, TIOCGETP, &sg); sg.sg_flags &= ~RAW; ioctl(0, TIOCSETP, &sg); } int kbhit() { int n; unsigned char c; ioctl(0, FIONREAD, &n); if (n) { read(0, &c, sizeof(c)); return c; }else{ return -1; } } #ifdef TEST main() { int i, t; raw(); for(i=0; i<1000; i++) { if ((t=kbhit()) >= 0) { printf("hit %c\n", t); } } cooked(); } #endif ------------------------------AND HERE------------------------------ -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I have no silly prejudice against computers--I like them!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Jan 20 19:48:58 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <92803-1>; Fri, 20 Jan 1995 19:44:28 +0200 Received: by theseas.ntua.gr with UUCP; Fri, 20 Jan 1995 19:45:52 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05mr@kriton.UUCP>; Fri, 20 Jan 95 18:54:47 EET Date: Fri, 20 Jan 95 18:54:47 EET Message-Id: <9501201654.05mr@kriton.UUCP> In-Reply-To: (from henrik.laurila@sirius.ct.se (Henrik Laurila)) (at Thu, 19 Jan 95 14:24:00 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1010 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Re: `special' characters in the command-line Henrik Laurila, in on Jan 19 wrote: > I have now tested with the ixemul.libraries in this release, but I got > different results depending of which ixemul.library I use, from this > archive. I would like to confirm Henrik's results. I wrote an "echo" type program, which I invoked with a single argument containing all caracters from 160 to 254. Depending on which version of Fred's library I used, I got different results, all bad (the least bad, in a sense, were the ones I got using the aminet version, but I'm sure that this doesn't signify anything). Compiling with libnix performed flawlessly. My guess is that ixemul uses the arguments' eighth bit during comand line parsing and wildcard expansion, resulting in this confusion. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I have no silly prejudice against computers--I like them!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Jan 20 21:17:31 1995 Received: from fishpond.amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <92699-4>; Fri, 20 Jan 1995 21:15:03 +0200 Message-ID: <9501201222.AA27089@fishpond.amigalib.com> Subject: Re: `special' characters in the command-line To: kyrimis@theseas.ntua.gr Date: Fri, 20 Jan 1995 12:22:22 +0700 (MST) From: "Fred Fish" Cc: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9501201654.05mr@kriton.UUCP> from "kriton!kyrimis" at Jan 20, 95 06:54:47 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2129 > I would like to confirm Henrik's results. I wrote an "echo" type > program, which I invoked with a single argument containing all caracters > from 160 to 254. Depending on which version of Fred's library I used, I > got different results, all bad (the least bad, in a sense, were the ones > I got using the aminet version, but I'm sure that this doesn't signify > anything). Compiling with libnix performed flawlessly. > > My guess is that ixemul uses the arguments' eighth bit during comand > line parsing and wildcard expansion, resulting in this confusion. I still have been unable to reproduce the problem here with my version. Here is the script I am running: ================================ cut here ============================= # Program to generate an echo command line. cat >buggen.c <bugtest.c < main(argc,argv) int argc; unsigned char *argv[]; { printf ("%s\n", argv[1]); } done gcc -o bugtest bugtest.c # Now run the test and capture the output. ./buggen >bugscript sh bugscript >bugout od --format=u1 bugdump cat bugdump ================================ cut here ============================= Here is the output I get: 0000000 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 0000020 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 0000040 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 0000060 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 0000100 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 0000120 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 0000140 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 0000160 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 0000200 10 0000201 Whatever the problem is, it doesn't appear to exist in my version, or else something about my environment causes it to not appear. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Jan 21 06:23:31 1995 Received: from undergrad.math.uwaterloo.ca ([129.97.204.13]) by nic.funet.fi with SMTP id <92831-4>; Sat, 21 Jan 1995 06:21:57 +0200 Received: from noether.math.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56937-1>; Fri, 20 Jan 1995 23:21:29 -0500 Date: Fri, 20 Jan 1995 23:21:18 -0500 From: Jeff Shepherd Sender: Jeff Shepherd Reply-To: Jeff Shepherd Subject: Re: makefile compiler To: amiga gcc-list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I have decided to upload makemake to aminet in the directory dev/gcc. The archive's name is makemake1.02.lha. Fully documented source is included. The code was written in C++ since I was just learning C++ at the time. I have been using it for about a year with no major problems so it should be pretty stable. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/index.html Had this been an actual emergency, we would have fled in terror, and you would not have been informed. From amiga-gcc-port-owner@nic.funet.fi Sat Jan 21 09:14:26 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91246-2>; Sat, 21 Jan 1995 09:13:02 +0200 Received: by theseas.ntua.gr with UUCP; Sat, 21 Jan 1995 09:14:34 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05ni@kriton.UUCP>; Sat, 21 Jan 95 09:11:14 EET Date: Sat, 21 Jan 95 09:11:14 EET Message-Id: <9501210711.05ni@kriton.UUCP> In-Reply-To: <9501201223.AA27085@fishpond.amigalib.com> (from "Fred Fish" ) (at Fri, 20 Jan 1995 12:22:22 +0700 (MST)) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 714 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: fnf@amigalib.com Cc: amiga-gcc-port@lists.funet.fi Subject: Re: `special' characters in the command-line Fred Fish, in <9501201223.AA27085@fishpond.amigalib.com> on Jan 20 wrote: > or else something about my environment causes it to not appear. Yes, you are running the program from sh rather than the amiga shell. I just verified that the program runs fine even with the aminet version of ixemul when called from sh. I seem to recall that the ixemul startup code behaves differently if a program has been invoked from another ixemul program. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "The Malus is pure evil. Given enough energy it will not only destroy him, but everything else... Cheer up!" ----- From amiga-gcc-port-owner@nic.funet.fi Sat Jan 21 19:01:17 1995 Received: from undergrad.math.uwaterloo.ca ([129.97.204.13]) by nic.funet.fi with SMTP id <92838-1>; Sat, 21 Jan 1995 18:59:10 +0200 Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56857-1>; Sat, 21 Jan 1995 11:58:24 -0500 Date: Sat, 21 Jan 1995 11:58:21 -0500 From: Jeff Shepherd Subject: Re: Makefile compiler To: amiga gcc-list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A slight correction from my previous post, it is uploaded into dev/misc NOT dev/gcc. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/index.html Had this been an actual emergency, we would have fled in terror, and you would not have been informed. From amiga-gcc-port-owner@nic.funet.fi Sat Jan 21 22:55:13 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <92845-3>; Sat, 21 Jan 1995 22:53:58 +0200 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA13962; Sat, 21 Jan 1995 21:57:54 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9501212057.AA13962@decap2.zdv.uni-tuebingen.de> Subject: libnix 0.7 signals To: amiga-gcc-port@nic.funet.fi Date: Sat, 21 Jan 1995 21:57:54 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 357 Hi, I saw libnix 0.7 on Aminet on took it home. The history file of the sources says, that the signal handling has changed, but does not tell what's different, neither do the docs. Can anyone enlighten me about that? Jochen P.S: Btw, thanks very much Gunther and Mathias. This makes gcc a real Amiga compiler. If only BFD would be finished now... ;-) From amiga-gcc-port-owner@nic.funet.fi Sat Jan 21 23:31:49 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <92850-3>; Sat, 21 Jan 1995 23:30:02 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Sat, 21 Jan 95 22:29 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Sat, 21 Jan 95 22:25 MET Message-Id: Subject: makefile compiler To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Sat, 21 Jan 1995 22:25:36 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 570 ah, i see, my little questions got a lot attention ;) btw: i was very interessted to hear about kbhit() because i had that problem too. (solved via rawkey), does someone collect this nice berrys ? i would spend my borlandgfx.h ? (i havebt time to do it personaly, sorry) walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Sun Jan 22 00:27:09 1995 Received: from pophh.Hamburg.pop.de ([193.98.9.7]) by nic.funet.fi with SMTP id <92847-2>; Sun, 22 Jan 1995 00:23:36 +0200 Received: from assi.s-link.de by pophh.Hamburg.pop.de (uucp) id m0rVo7q-0001QgC; Sat, 21 Jan 95 23:17 MEZ; (Smail3.1.28.1) Received: by assi.s-link.de with smail (/\==/\ Smail3.1.28.1 #28.1) id ; Sat, 21 Jan 95 19:45 MET To: amiga-gcc-port@nic.funet.fi Message-Id: From: s.zeiger@tecmania.mcnet.de (Stefan Zeiger) Path: multicom.mcnet.de!tecmania.mcnet.de!s.zeiger Organization: WWSP - Wizard Works Software Productions Subject: libnix for shared libraries Date: Fri, 20 Jan 1995 17:46:27 +0100 X-Mailer: MicroDot 1.8 [REGISTERED 00030c] X-Gateway: ZCONNECT UO assi.s-link.de [UNIX/Connect v0.55] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-TELEFON: V+49-6188-2525 X-Z-POST: Seligenstaedter Weg 24, D-63796 Kahl X-Z-VIA: 19950121183355W+1@multicom.mcnet.de Lines: 15 Hi there... I have encountered a problem with using libnix in a shared library. ld gives me an unknown symbol ___UtilityBase. I think some division command needs it (haven't checked the code yet). Opening utility.library myself did not work - for obvious reasons. I will now try to open it and assign the base pointer to ___UtilityBase (or should it be only 2 underscores ?), but that does look almost like a hack to me. Is there a 'cleaner' solution for that problem? -- Stefan Zeiger s.zeiger@tecmania.tms.mc.org ...if(2B|!2B) user->prefs.shakespeare=TRUE; From amiga-gcc-port-owner@nic.funet.fi Mon Jan 23 00:28:26 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <91259-3>; Mon, 23 Jan 1995 00:22:44 +0200 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA14806; Sun, 22 Jan 1995 23:26:26 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9501222226.AA14806@decap2.zdv.uni-tuebingen.de> Subject: Shared libraries with gcc (again) To: amiga-gcc-port@nic.funet.fi Date: Sun, 22 Jan 1995 23:26:25 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 683 Hi, today I tried the shared library example from the libnix distribution. Here's what happened: 4> bin:make gcc -nostdlib -O3 -fbaserel libinit.o simplelib.c -o lib ld: unsupported reloc-size in t:cc0867841.o make: *** [lib] Error 1 Is this the known -fbaserel problem or what else? Btw, Philippe, Lars, Fred, or whoever it may concern: Wouldn't it be possible to get -resident and -fbaserel working *before* releasing future versions of gcc? IMHO these options are much more important for the Amiga gcc than having the latest release available. (I would like to participate, but my HD has just 80 megs, so I cannot afford room even for the sources only.) Jochen From amiga-gcc-port-owner@nic.funet.fi Mon Jan 23 00:40:54 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <92775-1>; Mon, 23 Jan 1995 00:38:25 +0200 Received: by colombo.telesys-innov.fr; Sun, 22 Jan 1995 23:36:19 +0100 From: Philippe BRAND Message-Id: <199501222236.XAA19439@colombo.telesys-innov.fr> Subject: Re: gcc installer script (again) To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Sun, 22 Jan 1995 23:36:18 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9501222230.AA14821@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Jan 22, 95 11:30:30 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 868 Jochen Wiedmann writes: > > Just came back from hollidays. > Welcome back. :-) > Just because I have just posted this in a mail to the list: > > Btw, Philippe, Lars, Fred, or whoever it may concern: Wouldn't it be > > possible to get -resident and -fbaserel working *before* releasing > > future versions of gcc? IMHO these options are much more important > > for the Amiga gcc than having the latest release available. > > (I would like to participate, but my HD has just 80 megs, so I cannot > > afford room even for the sources only.) Well... I personally find that releasing a new version is important, even if resident option is not working. There's too many generic bugs corrected in the compiler in each versions (note that for example I didn't release 2.6.2 to AMinet). -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Jan 23 14:40:38 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <92804-4>; Mon, 23 Jan 1995 14:31:19 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 23 Jan 95 13:29 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 23 Jan 95 13:18 MET Message-Id: Subject: prob with kcon and awk To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 23 Jan 1995 13:18:46 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1004 hi there, while checking my update 261->263 i found this problem with kinkcon v1.3 68020-version list quick | awk '{print "version " $0" >>ram:res1"}' awk: cmd. line:1: '{print awk: cmd. line:1: ^ Invalid char ''' in expression the same line works well in sh. the problem vanish if you write the line in a file but the output cant be redirected anymore. list quick | :gcc/bin/awk -f ram:ver.awk further using -f file in kingcon causes some requesters asking for "./ram" "/local/lib/awk/ram/" "/gnu/lib/awk/ram/" for the "|" i used the std C= pipe(37.4) these message will be forwarded to David Larsson creator Kingcon. if someone can confirm my reports please inform him. f92dala@dd.chalmers.se walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Mon Jan 23 15:39:49 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <92820-4>; Mon, 23 Jan 1995 15:35:39 +0200 Received: by nmrc.ucc.ie (8.6.8.1/8.6.6) with ESMTP id NAA01662; Mon, 23 Jan 1995 13:33:32 GMT From: Lars Hecking Message-Id: <199501231335.NAA07143@mostar.nmrc.ucc.ie> Subject: Re: your mail To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann), phb@colombo.telesys-innov.fr (Philippe Brand) Date: Mon, 23 Jan 1995 13:35:22 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <01HM6PKU4IL200UCUY@mailgate.ucd.ie> from "AMIGA-GCC-PORT-OWNER@NIC.FUNET.FI" at Jan 23, 95 12:36:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1306 Philippe wrote: > Jochen Wiedmann writes: > > > > Just came back from hollidays. > > Welcome back. :-) > > Just because I have just posted this in a mail to the list: > > > Btw, Philippe, Lars, Fred, or whoever it may concern: Wouldn't it be > > > possible to get -resident and -fbaserel working *before* releasing > > > future versions of gcc? IMHO these options are much more important > > > for the Amiga gcc than having the latest release available. > > > (I would like to participate, but my HD has just 80 megs, so I cannot > > > afford room even for the sources only.) I have a spare LPS105. Well, just kidding, it's not really spare ;) I hope to get going as soon as I have a PSU for my 3000. They're difficult to get these days. > Well... I personally find that releasing a new version is important, even if > resident option is not working. There's too many generic bugs corrected in > the compiler in each versions (note that for example I didn't release 2.6.2 to > AMinet). I agree. For -resident I still keep 2.3.3 around. It doesn't always work, eg. for GNU make, but mostly ;) -- Lars Hecking | National Microelectronics Research Centre lhecking@nmrc.ucc.ie | Cork, Ireland |------------------------------------------- | "Victims! Aren't we all?" -- Eric Draven From amiga-gcc-port-owner@nic.funet.fi Mon Jan 23 17:10:15 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <92802-1>; Mon, 23 Jan 1995 17:03:04 +0200 Received: by ceylon.informatik.uni-rostock.de id QAA12357; Mon, 23 Jan 1995 16:02:46 +0100 Received: by honshu.informatik.uni-rostock.de id QAA05645; Mon, 23 Jan 1995 16:02:45 +0100 From: Gunther Nikl Message-Id: <199501231502.QAA05645@honshu.informatik.uni-rostock.de> Subject: Re: libnix for shared libraries To: s.zeiger@tecmania.mcnet.de (Stefan Zeiger) Date: Mon, 23 Jan 1995 16:02:45 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Stefan Zeiger" at Jan 20, 95 05:46:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1295 > I have encountered a problem with using libnix in a > shared library. ld gives me an unknown symbol ___UtilityBase. I > think some division command needs it (haven't checked the code > yet). Opening utility.library myself did not work - for obvious > reasons. I will now try to open it and assign the base pointer to > ___UtilityBase (or should it be only 2 underscores ?), but that > does look almost like a hack to me. > > Is there a 'cleaner' solution for that problem? Yes :) First, the problem results from the integer math routines that use functions from the utility library to do the job (so it requires 2.0) Solutions: 1) link with a library that contains the required functions without utility calls (I could post it) 2) open "utility.library" as you would do it normally. a) compile to asm and replace every _UtilityBase with ___UtilityBase via gcc -E -P -D_UtilityBase=___UtilityBase -o file.s2 file.s gcc -o file.o file.s2 -c b) use symbol redirection: ALIAS(__UtilityBase,UtilityBase); (ALIAS() is a macro defined in the libnix "stabs.h" header) c) do it your way Hope this helps. Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Jan 23 17:14:05 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <92832-2>; Mon, 23 Jan 1995 17:07:26 +0200 Received: by ceylon.informatik.uni-rostock.de id QAA12392; Mon, 23 Jan 1995 16:07:11 +0100 Received: by honshu.informatik.uni-rostock.de id QAA05661; Mon, 23 Jan 1995 16:07:10 +0100 From: Gunther Nikl Message-Id: <199501231507.QAA05661@honshu.informatik.uni-rostock.de> Subject: Re: Shared libraries with gcc (again) To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Mon, 23 Jan 1995 16:07:09 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9501222226.AA14806@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Jan 22, 95 11:26:25 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 672 > today I tried the shared library example from the libnix distribution. > Here's what happened: > > 4> bin:make > gcc -nostdlib -O3 -fbaserel libinit.o simplelib.c -o lib > ld: unsupported reloc-size in t:cc0867841.o > make: *** [lib] Error 1 > > Is this the known -fbaserel problem or what else? Its something else! This time gcc could compile the source but the linker refused the output of the assembler. The problem is, that gcc comes with a brand new assembler but uses a very old linker. Use gas1.38.1 and the problem will go away. I personally prefer and *use* the old gas. Finally using gcc 2.3.3 means also using gas 1.38.1. Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Jan 23 19:10:20 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <92785-1>; Mon, 23 Jan 1995 19:06:24 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA13247 (5.65c8/IDA-1.4.4 for ); Mon, 23 Jan 1995 18:06:03 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA27958; Mon, 23 Jan 95 18:06:02 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9501231706.AA27958@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: libnix for shared libraries To: s.zeiger@tecmania.mcnet.de (Stefan Zeiger) Date: Mon, 23 Jan 1995 18:06:02 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Stefan Zeiger" at Jan 20, 95 05:46:27 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 855 > > I have encountered a problem with using libnix in a > shared library. ld gives me an unknown symbol ___UtilityBase. I > think some division command needs it (haven't checked the code >yet). Yep. 32 bit multiply and division are handled by calling utility.library. Usually the startup code will open it for you. (The 2 '__' are to avoid problems with self-defined library base pointers). > Opening utility.library myself did not work - for obvious > reasons. I will now try to open it and assign the base pointer to > ___UtilityBase (or should it be only 2 underscores ?), but that > does look almost like a hack to me. > No, that's no hack. If you write a shared library you will have to manage those things yourself in the library's init-routine... > Is there a 'cleaner' solution for that problem? > Not currently. Hope it helps. Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Jan 23 19:37:14 1995 Received: from godot.lysator.liu.se ([130.236.254.154]) by nic.funet.fi with ESMTP id <92811-1>; Mon, 23 Jan 1995 19:34:10 +0200 Received: from lysita (nisse@lysita.lysator.liu.se [130.236.254.153]) by godot.lysator.liu.se (8.6.8.1/8.6.6) with ESMTP id SAA18537; Mon, 23 Jan 1995 18:34:04 +0100 Received: from localhost (nisse@localhost) by lysita (8.6.5/8.6.5) id SAA07714; Mon, 23 Jan 1995 18:33:47 +0100 Date: Mon, 23 Jan 1995 18:33:47 +0100 From: nisse@lysator.liu.se Message-Id: <199501231733.SAA07714@lysita> To: kyrimis@theseas.ntua.gr CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9501201654.05mr@kriton.UUCP> (kriton!kyrimis@theseas.ntua.gr) Subject: Re: `special' characters in the command-line Some questions that are slightly related to this: What about "strange" characters (like o with dots) in identifiers? I know this is not standard, and probably not very important, but it would be nice. I think SAS/C has this feature also. I once tried this with gcc (probably gcc-2.3.3), and cpp and cc1 happily accepted my identifiers, but as complained when fed labels containing 8-bit characters. If it's still that way, and it is easy to fix, I think as should be fixed. I guess the problem is that it doesn't use ctype.h. A while back I fixed a similar problem with ls (it refused to display filenames with 8-bit characters properly). What I did was to replace tests like ( c > 0x20 && c < 0x80 ) with ctype.h macros. BTW, was this patch applied to the ls distributed with gcc? I think that I sent it to Phil back then. Regards, Niels Möller From amiga-gcc-port-owner@nic.funet.fi Mon Jan 23 22:58:14 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <92797-3>; Mon, 23 Jan 1995 22:57:05 +0200 Received: by theseas.ntua.gr with UUCP; Mon, 23 Jan 1995 22:56:51 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05ox@kriton.UUCP>; Mon, 23 Jan 95 22:49:15 EET Date: Mon, 23 Jan 95 22:49:15 EET Message-Id: <9501232049.05ox@kriton.UUCP> In-Reply-To: (from "Herzer Armin Assi(FBP)" ) (at Mon, 23 Jan 1995 18:59:52 GMT+200) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1927 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: Herzer Armin Assi@kriton.UUCP Cc: amiga-gcc-port@lists.funet.fi Subject: Re: kbhit trial (and partial success) > thanks for answering my question concerning kbhit(). I tried your > example and it worked quit well. But when it finished it hungs my > CLI. This means, when you type in a command (not displayed on > the screen) I get a 'unknown command' error and after that the > CLI accepts no more commands. Oops! I'm using SKsh which apparently returns the cli window to a sane mode after each command. Anyway, a quick check was enough to discover the error: apart from the obvious typo in cooked(), where I had used |= instead of &=, the problem lay in ixemul's ioctl() implicitly changing several other flags when setting the RAW bit, but not restoring them when clearing it. I'm posting a new version of the subroutines, along with your test program, where cooked() restores the implicitly modified flags, and raw() now modifies them explicitly for good measure. Kbhit() remains unchanged. Hope this helps, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "You're serious, aren't you?" "About what I do, yes--not necessarily the way I do it." ----- #include #include #include void raw() { struct sgttyb sg; ioctl(0, TIOCGETP, &sg); sg.sg_flags |= (RAW | CBREAK); sg.sg_flags &= ~(CRMOD | ECHO); ioctl(0, TIOCSETP, &sg); } void cooked() { struct sgttyb sg; ioctl(0, TIOCGETP, &sg); sg.sg_flags &= ~(RAW | CBREAK); sg.sg_flags |= (CRMOD | ECHO); ioctl(0, TIOCSETP, &sg); } int kbhit() { int n; unsigned char c; ioctl(0, FIONREAD, &n); if (n) { read(0, &c, sizeof(c)); return c; } else { return -1; } } main() { int i, t; raw(); for(i = 0; i < 1000; i++) { if((t=kbhit()) >= 0) { printf("hit %c (%i)\n", t, i); } else { printf("! no key pressed (%i)\n", i); } } cooked(); } From amiga-gcc-port-owner@nic.funet.fi Tue Jan 24 02:34:57 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <91259-3>; Tue, 24 Jan 1995 02:32:18 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189443>; Tue, 24 Jan 1995 01:32:03 +0100 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA20186; Tue, 24 Jan 1995 01:31:55 +0100 Date: Tue, 24 Jan 1995 01:31:55 +0100 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9501240031.AA20186@nereid.rz.Uni-Osnabrueck.DE> To: amiga-gcc-port@nic.funet.fi Subject: RAW-Mode Hey, back again with another report of a pseudo-bug ! The problem is with clearing the RAW-Mode by unset the RAW-bit in the sgttyb-struct. This doesnt work with TIOCSETP, because this command flushes the given sgttyb- struct and other bits in your structure will be changed (CBREAK, ECHO i.e.). One solution is to reset all bits to the initial state. The better solution is to use TIOCSETN command, which should NOT flushing the given struct. This works with Aztec-C's ioctl() function at least. The following should happen: ioctl() read the sgttyb-struct, changes internally the modes but leave sgttyb as it was before. This is not the case with gcc's ioctl(). Is this a bug or is it normal in UNIX-systems that ioctl() treats TIOCSETN exactly like TIOCSETP ? P.S.: Im sorry about my bad knowlege of the english language and hope that at least a few do understand me. bye, Thomas From amiga-gcc-port-owner@nic.funet.fi Tue Jan 24 06:09:49 1995 Received: from carbon.cudenver.edu ([132.194.10.4]) by nic.funet.fi with SMTP id <92847-3>; Tue, 24 Jan 1995 06:08:35 +0200 Received: by carbon.cudenver.edu (5.65/DEC-OSF/1.2) id AA09071; Mon, 23 Jan 1995 21:12:12 -0700 Date: Mon, 23 Jan 1995 21:12:11 -0700 (MST) From: Brian Simmons To: amiga-gcc-port@nic.funet.fi Subject: gcc263 bombs first try. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I just loaded gcc263* from merlin.etsu.edu on my system and the first program I wrote in g++ guru'd (81000005). Here is the program: #include class myclass { public: int a; }; main() { myclass obj1,obj2; obj1.a = 10; ojb2.a = 99; cout << obj1.a << "\n"; cout << obj2.a << "\n"; } I typed 'g++ -o test test.c', the thing paused for a 20 sec, printed something like 'incorrect instruction', then a line of garbage, then the guru (8100 0005). The machine rebooted after I pressed the left mouse button. The funny thing is, it produced a working executable! Here are my stats: Amiga 2000 with GVP 030/50Mhz card. 8 megs ram, brand new 700meg hard drive. AmigaDos 2.1 (freshly installed, except I lost the 2.1 extras disk) I don't have the C= devloper headers. I installed everything merlin had (the -020 version of the binaries). I had to hand install it, the installer kept getting an error on the LhA command, even after I rearranged the commands and options. I copied the stuff in GNU:s/user-startup into my s:user-startup. I typed 'protect GNU:/s/#? +s', then then cd GNU: /gnus/RestoreLinks GNU: makelink=makelink I then went to GNU:bin/ and made links to all the binaries that had filenames ending with -020: 'makelink c++ c++-020'. The docs said type 'sh /gnu/s/restorelinks', but I got errors (.key,.IF,etc) I typed in the "hello world!" program in the docs and gcc liked it. G++ didn't like the program above, though. From amiga-gcc-port-owner@nic.funet.fi Tue Jan 24 12:30:46 1995 Received: from deep.rsoft.bc.ca ([204.174.16.4]) by nic.funet.fi with SMTP id <92826-4>; Tue, 24 Jan 1995 12:26:50 +0200 Received: from mindlink.bc.ca by deep.rsoft.bc.ca with smtp (Smail3.1.28.1 #5) id m0rWiLq-000Bi3C; Tue, 24 Jan 95 02:19 PST Message-Id: Date: Tue, 24 Jan 95 02:18:57 -0800 To: amiga-gcc-port@nic.funet.fi Subject: builtin_new From: Colin_Fox@mindlink.bc.ca (Colin Fox) We're using GNU for a special custom hardware project, and for some reason, my test.cpp file comes up at link time with the error messages: "Unresolved reference __builtin_new" "Unresolved reference __builtin_delete" (SOrry I don't have the exact syntax, as my stuff is all at work). ANyone know where the builtin new & delete are defined, and how I can use them? Thanks. -- ------ Colin Fox ------ Live Wire Designs ---------------------- ------ Colin_Fox@mindlink.bc.ca -------------------------------- From amiga-gcc-port-owner@nic.funet.fi Tue Jan 24 12:55:41 1995 Received: from jupiter.pt.hk-r.se ([194.47.132.2]) by nic.funet.fi with ESMTP id <92872-2>; Tue, 24 Jan 1995 12:47:56 +0200 Received: from hyperion.pt.hk-r.se (pi92bn@hyperion.pt.hk-r.se [194.47.132.13]) by jupiter.pt.hk-r.se (8.6.9/8.6.9) with ESMTP id LAA28342 for ; Tue, 24 Jan 1995 11:45:05 +0100 From: Bjoern Nilsson Received: (pi92bn@localhost) by hyperion.pt.hk-r.se (8.6.9/8.6.9) id LAA02811; Tue, 24 Jan 1995 11:44:46 +0100 Date: Tue, 24 Jan 1995 11:44:46 +0100 Message-Id: <199501241044.LAA02811@hyperion.pt.hk-r.se> Illegal-Object: Syntax error in To: address found on nic.funet.fi: To: bsimmons@carbon.cudenver.edu: ^-missing end of address To: Subject: Re: gcc263 bombs first try. Cc: amiga-gcc-port@nic.funet.fi > From amiga-gcc-port-owner@nic.funet.fi Tue Jan 24 05:08:03 1995 > Date: Mon, 23 Jan 1995 21:12:11 -0700 (MST) > From: Brian Simmons > To: amiga-gcc-port@nic.funet.fi > Subject: gcc263 bombs first try. > Mime-Version: 1.0 > Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII> > Content-Length: 1476 > > I just loaded gcc263* from merlin.etsu.edu on my system and the first program > I wrote in g++ guru'd (81000005). Here is the program: > > #include > > class myclass { > public: > int a; > }; > > main() > { > myclass obj1,obj2; > > obj1.a = 10; > ojb2.a = 99; > > cout << obj1.a << "\n"; > cout << obj2.a << "\n"; > } > > I typed 'g++ -o test test.c', the thing paused for a 20 sec, printed > something like 'incorrect instruction', then a line of garbage, then > the guru (8100 0005). The machine rebooted after I pressed the left > mouse button. > The funny thing is, it produced a working executable! > > Here are my stats: > Amiga 2000 with GVP 030/50Mhz card. > 8 megs ram, brand new 700meg hard drive. > AmigaDos 2.1 (freshly installed, except I lost the 2.1 extras disk) > I don't have the C= devloper headers. < cut > Hello! I have had the same problem: a guru and an executable... The 020 version needs a fpu. I dont know if you have any one, you didnt mention it. Buy one or test the 000-version (not 020). I'm running the 000 version on my A1200/28Mhz/ec020/6 Mb and it works fine. /B.Nils +-----------------------------+-------------------------------+ | Name: Bjoern Nilsson | | | Email: pi92bn@pt.hk-r.se | // Only Amiga makes | | Equip: A1200/128/28Mhz/6 | \X/ it possible... | +-----------------------------+-------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Jan 26 00:40:47 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <92996-3>; Thu, 26 Jan 1995 00:34:31 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA27019; Wed, 25 Jan 95 14:35:00 MST Date: Wed, 25 Jan 1995 14:34:59 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: amiga-gcc-port@lists.funet.fi Subject: Tar Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I ran into a problem using tar with the 'z' option. I get the following error message: tar: cannot fork : Function not implemented Can anyone tell me what is wrong? Do I not have my configuration set properly? Paul Ney From amiga-gcc-port-owner@nic.funet.fi Thu Jan 26 00:51:01 1995 Received: from argon.daimi.aau.dk ([130.225.18.161]) by nic.funet.fi with SMTP id <92999-3>; Thu, 26 Jan 1995 00:47:05 +0200 Received: by argon.daimi.aau.dk id AA19199 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Wed, 25 Jan 1995 23:46:58 +0100 Date: Wed, 25 Jan 1995 23:46:58 +0100 From: Lars Balker Rasmussen Message-Id: <199501252246.AA19199@argon.daimi.aau.dk> To: amiga-gcc-port@nic.funet.fi Subject: Re: Tar Paul Ney wrote: > I ran into a problem using tar with the 'z' option. I get the >following error message: > >tar: cannot fork : Function not implemented > >Can anyone tell me what is wrong? Do I not have my configuration set >properly? Not your fault. fork() is a non-trivial (not to say impossible) function to implement under AmigaDOS. Use "zcat | tar -" instead. Regards, -- Lars Balker Rasmussen Click! From amiga-gcc-port-owner@nic.funet.fi Thu Jan 26 02:17:02 1995 Received: from fishpond.amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <92902-2>; Thu, 26 Jan 1995 02:12:44 +0200 Message-ID: <9501251716.AA02804@fishpond.amigalib.com> Subject: Re: Tar To: daimi.aau.dk!gnort (Lars Balker Rasmussen) Date: Wed, 25 Jan 1995 17:15:20 +0700 (MST) From: "Fred Fish" Cc: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199501252246.AA19199@argon.daimi.aau.dk> from "Lars Balker Rasmussen" at Jan 25, 95 11:46:58 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 649 > > I ran into a problem using tar with the 'z' option. I get the > > > >tar: cannot fork : Function not implemented > > > > Not your fault. fork() is a non-trivial (not to say impossible) > function to implement under AmigaDOS. > > Use "zcat | tar -" instead. Works here with the version of tar that will be on FreshFish Vol 8. All it takes is a simple "#define fork vfork" (or the command line equivalent "-Dfork=vfork") when tar is compiled. It does require you have have various other things that come as a standard part of the GNU environment though, like a shell with piping that works, and a gzip executable. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Jan 26 02:19:35 1995 Received: from eeyore.INS.CWRU.Edu ([129.22.8.17]) by nic.funet.fi with ESMTP id <92909-3>; Thu, 26 Jan 1995 02:14:00 +0200 Received: (cz253@localhost) by eeyore.INS.CWRU.Edu (8.6.8.1+cwru/CWRU-2.1-bsdi) id TAA03236; Wed, 25 Jan 1995 19:13:51 -0500 (from cz253) Message-Id: <199501260013.TAA03236@eeyore.INS.CWRU.Edu> Date: Wed, 25 Jan 1995 19:13:51 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: Re: Tar Cc: cz253@cleveland.freenet.edu Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) > >Paul Ney wrote: >> I ran into a problem using tar with the 'z' option. I get the >>following error message: >> >>tar: cannot fork : Function not implemented >> >>Can anyone tell me what is wrong? Do I not have my configuration set >>properly? > >Not your fault. fork() is a non-trivial (not to say impossible) >function to implement under AmigaDOS. > What? I use the 'z' or compress option all the time with tar. Then again I compiled this tar exe myself, with changes to the source code so that it uses gzip instead of compress. The code I modified was version 1.11.1, I believe I replaced the fork()'s with fork2()'s. I'll see if I can dig up my diff file, if anyone is interested. >Use "zcat | tar -" instead. Why? When all I have to is 'tar -f foo.taz -v -z foo'. ;-) .....Dave /* CAUTION - .sig file under deconstruction _ _ - aka cz253@cleveland.freenet.edu / V \ - aka dz253@freenet.scri.fsu.edu _ _ _ _ - aka as937@yfn.ysu.edu / V \ / V \ - aka Dave.Zaroski@launchpad.unc.edu */ ---------------------------------------------------------- | AMCOM BBS (216) 526-9480 -- IBM, AMIGA, MAC, ATARI | |75,000+ files on line - PCBoard 15.2/100 Nodes - 9+ GBytes| ---------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Thu Jan 26 06:23:30 1995 Received: from carbon.cudenver.edu ([132.194.10.4]) by nic.funet.fi with SMTP id <92992-2>; Thu, 26 Jan 1995 06:19:17 +0200 Received: by carbon.cudenver.edu (5.65/DEC-OSF/1.2) id AA27956; Wed, 25 Jan 1995 21:22:48 -0700 Date: Wed, 25 Jan 1995 21:22:45 -0700 (MST) From: Brian Simmons To: amiga-gcc-port@nic.funet.fi Subject: Re: gcc263 bombs first try. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Someone suggested setting the stack to 50000 I tried this and it worked. You know, I thought the whole purpose of the GCCSTACK environment variable was so that the programs could set the stack all by themselves. I guess someone forgot to use it in G++. Why on earth doesn't it set the stack? What *IS* the point of the GCCSTACK variable? From amiga-gcc-port-owner@nic.funet.fi Thu Jan 26 10:22:15 1995 Received: from jupiter.pt.hk-r.se ([194.47.132.2]) by nic.funet.fi with ESMTP id <92902-4>; Thu, 26 Jan 1995 10:12:58 +0200 Received: from diploducus.pt.hk-r.se (pt94emu@diploducus.pt.hk-r.se [194.47.133.21]) by jupiter.pt.hk-r.se (8.6.9/8.6.9) with ESMTP id JAA11110 for ; Thu, 26 Jan 1995 09:10:08 +0100 From: pt94emu@pt.hk-r.se Received: (pt94emu@localhost) by diploducus.pt.hk-r.se (8.6.9/8.6.9) id JAA22255 for amiga-gcc-port@nic.funet.fi; Thu, 26 Jan 1995 09:10:06 +0100 Date: Thu, 26 Jan 1995 09:10:06 +0100 Message-Id: <199501260810.JAA22255@diploducus.pt.hk-r.se> To: amiga-gcc-port@nic.funet.fi Subject: Curses Does anybody out there have the amiga curses lib for gcc ? I need it badly! Edin. From amiga-gcc-port-owner@nic.funet.fi Thu Jan 26 11:38:55 1995 Received: from DRAGON.COM ([155.229.20.1]) by nic.funet.fi with SMTP id <92890-1>; Thu, 26 Jan 1995 11:35:18 +0200 Received: from opera by dragon.com (MX V4.1 VAX) with UUCP; Thu, 26 Jan 1995 04:34:02 EDT Received: by opera.dragon.com (V1.17-beta/Amiga) id <0674@opera.dragon.com>; Thu, 26 Jan 95 04:28:14 EST Date: Thu, 26 Jan 95 04:28:14 EST Message-ID: <201ae5db.8e6b1-cls@opera.dragon.com> X-Mailer: //\\miga Electronic Mail (AmiElm 3.99) From: To: amiga-gcc-port@nic.funet.fi Subject: Curses (fwd) On Jan 26, pt94emu wrote: |-------------------- text of forwarded message follows --------------------| Does anybody out there have the amiga curses lib for gcc ? I need it badly! |------------------------- end of forwarded message ------------------------| I've grabbed Curses and Curses210 from aminet, but don't know that there's a GNU-specific curses package. If there is, I could sure use it, too. If you can't find either of these packages on aminet, let me know and I'll try to put them up somewhere. I grep'd the full index to locate files pertaining to curses. ========================================================================== Charles Streible | cls@opera.dragon.com (home) | cls@dido.opera.dragon.com (home) | streible@landmark.net (work) From amiga-gcc-port-owner@nic.funet.fi Thu Jan 26 15:06:34 1995 Received: from fishpond.amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <93009-3>; Thu, 26 Jan 1995 15:00:52 +0200 Message-ID: <9501260604.AA17623@fishpond.amigalib.com> Subject: Re: Curses (fwd) To: opera.dragon.com!cls Date: Thu, 26 Jan 1995 06:04:04 +0700 (MST) From: "Fred Fish" Cc: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) In-Reply-To: <201ae5db.8e6b1-cls@opera.dragon.com> from "opera.dragon.com!cls" at Jan 26, 95 04:28:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 706 > I've grabbed Curses and Curses210 from aminet, but don't know that there's > a GNU-specific curses package. If there is, I could sure use it, too. > > If you can't find either of these packages on aminet, let me know and I'll > try to put them up somewhere. I grep'd the full index to locate files > pertaining to curses. I recently integrated a copy of the curses library from BSD Lite into the GNU tree for FreshFish Vol 8 and it seems to work better than any of the other curses I could find. I don't recall the specifics of the problems I had with the ones on aminet (either didn't work right, wouldn't compile from source, or whatever) that caused me to go looking for another solution. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Jan 26 15:40:00 1995 Received: from grex.cyberspace.org ([152.160.30.1]) by nic.funet.fi with SMTP id <93010-3>; Thu, 26 Jan 1995 15:34:39 +0200 Received: (from fog@localhost) by grex.cyberspace.org (8.6.9/8.6.9) id IAA25645; Thu, 26 Jan 1995 08:32:34 -0500 Date: Thu, 26 Jan 1995 08:32:29 -0500 (EST) From: Federico Di Gregorio To: Fred Fish cc: Amiga GCC List Subject: Re: Curses (fwd) In-Reply-To: <9501260604.AA17623@fishpond.amigalib.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 26 Jan 1995, Fred Fish wrote: > > I've grabbed Curses and Curses210 from aminet, but don't know that there's > > a GNU-specific curses package. If there is, I could sure use it, too. > > > > If you can't find either of these packages on aminet, let me know and I'll > > try to put them up somewhere. I grep'd the full index to locate files > > pertaining to curses. > > I recently integrated a copy of the curses library from BSD Lite into > the GNU tree for FreshFish Vol 8 and it seems to work better than any > of the other curses I could find. I don't recall the specifics of the > problems I had with the ones on aminet (either didn't work right, > wouldn't compile from source, or whatever) that caused me to go > looking for another solution. Where can we find a copy of it? (apart from fish.8 :) Sources will suffice... Federico From amiga-gcc-port-owner@nic.funet.fi Thu Jan 26 16:50:57 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <92974-1>; Thu, 26 Jan 1995 16:40:34 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 26 Jan 1995 16:40:53 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05pz@kriton.UUCP>; Thu, 26 Jan 95 16:30:18 EET Date: Thu, 26 Jan 95 16:30:18 EET Message-Id: <9501261430.05pz@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1032 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Re: Curses (fwd) On Jan 26, Fred Fish wrote: > of the other curses I could find. I don't recall the specifics of the > problems I had with the ones on aminet (either didn't work right, > wouldn't compile from source, or whatever) that caused me to go > looking for another solution. If you are referring to the version by Simon Raybould, which opens its own screen, has color, etc, etc., it comes complete with a compiled libcurses.a, and works great with several unix programs that I've tried. The only problem I had with it was when I tried to compile an optimized version of it, and one of the modules would compile incorrectly. A bit of binary search helped me locate that module, and it's quite possible that the problem with the optimizer has been fixed in the versions of gcc that followed since I compiled the library. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "We'll all become unpeople, undoing unthings untogether." ----- From amiga-gcc-port-owner@nic.funet.fi Fri Jan 27 00:00:19 1995 Received: from proffa.cc.tut.fi ([130.230.102.14]) by nic.funet.fi with ESMTP id <93050-4>; Thu, 26 Jan 1995 20:32:28 +0200 Received: (from k150471@localhost) by proffa.cc.tut.fi (8.6.8.1/8.6.6) id UAA02430 for amiga-gcc-port@nic.funet.fi; Thu, 26 Jan 1995 20:31:52 +0200 From: Kniivil{ Jarkko Message-Id: <199501261831.UAA02430@proffa.cc.tut.fi> Subject: Building a cross-compiler at the moment To: amiga-gcc-port@nic.funet.fi Date: Thu, 26 Jan 1995 20:31:51 +0200 (EET) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 722 I have a problem regarding where to get the proper patches in order to compile an AmigaDOS cross compiler hosted on a DEC Alpha AXP running OSF/1 3.0. Last time this issue was presented on this list Philippe told us to get the patches from ftp.telesys-innov.fr:/pub/amigados-gnu /beta/gcc-2.6.1-amiga.diffs. But when I tried to get them, ncftp informed that they didn't exist! Philippe, would you please tell where the latest patches are, as building a cross-compiler would be of great interest to me. Yours, Jarkko -- E-Mail: k150471@cc.tut.fi | S-Mail: Jarkko Kniivil\"a % (TEX-format) [ This space unintentionally | Opiskelijankatu 4 F 315 left blank! ] | FIN-33720 TAMPERE From amiga-gcc-port-owner@nic.funet.fi Fri Jan 27 01:27:26 1995 Received: from fishpond.amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <92825-4>; Fri, 27 Jan 1995 01:22:48 +0200 Message-ID: <9501261626.AA18259@fishpond.amigalib.com> Subject: Re: Building a cross-compiler at the moment To: proffa.cc.tut.fi!k150471 (Kniivil{ Jarkko) Date: Thu, 26 Jan 1995 16:26:04 +0700 (MST) From: "Fred Fish" Cc: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste), umueller@wuarchive.wustl.edu (Urban Mueller) In-Reply-To: <199501261831.UAA02430@proffa.cc.tut.fi> from "Kniivil{ Jarkko" at Jan 26, 95 08:31:51 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1407 > I have a problem regarding where to get the proper patches in order to > compile an AmigaDOS cross compiler hosted on a DEC Alpha AXP running > OSF/1 3.0. Last time this issue was presented on this list Philippe > told us to get the patches from ftp.telesys-innov.fr:/pub/amigados-gnu > /beta/gcc-2.6.1-amiga.diffs. But when I tried to get them, ncftp > informed that they didn't exist! Philippe, would you please tell > where the latest patches are, as building a cross-compiler would be > of great interest to me. In theory, you should be able to get complete binaries and sources from aminet, but in practice most of the aminet uploads of GNU code violate the GPL, which says that source for *that* *binary* must be made available alongside the binary. It is not sufficient to just post diffs to the base FSF source without also providing the FSF source, or a fully patched source tree that already incorporates the diffs into the source. It is also not sufficient to provide just a pointer to another location where the sources live if the two locations are not administered in such a way that it is possible for the source to disappear without the binary doing so as well. This policy is intended to prevent just this sort of problem. I'm not beating up on any particular people here, just reminding everyone that there are reasons why the GPL insists that source be readily available. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Jan 27 17:27:31 1995 Received: from clinet.fi ([193.64.6.1]) by nic.funet.fi with SMTP id <93024-1>; Fri, 27 Jan 1995 17:10:26 +0200 Received: from zetor.clinet.fi (root@zetor.clinet.fi [193.64.6.8]) by clinet.fi (8.6.9/8.6.4) with ESMTP id RAA25751 for ; Fri, 27 Jan 1995 17:11:06 +0200 Received: (will@localhost) by zetor.clinet.fi (8.6.8/8.6.4) id RAA01953; Fri, 27 Jan 1995 17:10:16 +0200 Date: Fri, 27 Jan 1995 17:10:11 +0200 (EET) From: Ville-Pertti Keinonen To: amiga-gcc-port@nic.funet.fi Subject: A few comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII After compiling some stuff and linking them with libnix, I got some really strange errors - some files refused to open (with fopen()), complaining that the operation was not supported by the device. This occured when trying to open a file on one of my xfh-partitions (I have an ancient version of xfh, though, I'll ftp a newer one soon and hope it's fixed - otherwise I'll have to add support for the action in question myself). After looking at sources/nix/stdio/open.c, I could understand why this was happening - ChangeMode() was always used after Open(). Not much later, I realized that the problem with opening a file didn't only occur with files on the xfh-partitions but also with eg. CON:, which means that the use of stdio/fd-functions in libnix is restricted to real filesystems supporting ACTION_CHANGE_MODE. This is a serious restriction and I would recommend changing the technique libnix's open() opens a file, since most people very likely need to be able to open CON: and other files not supporting mode-changing. This has probably been suggested before: It would be nice if ixemul.library could handle other/group-protection bits the way they are supposed to be handled - what it does to them now is negation, ie. they are interpreted as 0 - allowed, 1 - not allowed, when they should be the other way around. (When using eg. muFS, it isn't nice to see all the permissions wrong using /gnu/bin/ls). From amiga-gcc-port-owner@nic.funet.fi Fri Jan 27 19:36:49 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <93112-2>; Fri, 27 Jan 1995 19:28:35 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id af02228; 27 Jan 95 15:53 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA006ys; Fri, 27 Jan 95 15:41:06 GMT Date: Fri, 27 Jan 95 15:41:06 GMT Message-Id: <9501271541.AA006yr@flevel.demon.co.uk> Message-Id: <201cd50e.cd140-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 3.99) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Compling GNU Octave 1.1.0 with Amiga GCC V2.6.3 I'm trying to compile Octave 1.1.0 with Amiga GCC V2.6.3 and I am having some problems, my configuration is:- Hardware:- Amiga A3000 030 882 25Mhz 12+2MB Memory 40MB Quantum SCSI (Internal) A4091 SCSI II Card 2*1.2GM MO-MIGA Drives 2*650MB MO-MIGA Drives Courier HST Dual Standard with Fax and ASL Modem HP JaserJet III Software:- WB 3.1 (V40.42) KS 3.1 (V40.70) MultiUser FileSystem AmiTCP 3.0b Amiga Elm Grn Gnu C V2.6.3 Dice C V3.01 VMM Enforcer, MungWall etc. Devpac 3 System Patches:- DosPrefs (Wild Star and ./..) IX Pipe Patch (Fourth Level Patch) King Con (Shell Scrollback etc.) QMouse (Fast mouse and hotkey for shell) Gnu C++ keeps crashing left/right and centre :-) Ive kept changing around my setup, freeing up memory, running/not running VMM and altering the stack. All of the files Ive tried so far have compiled in the end after changing the above things around by trial and error. One setting does not seem to let me compile all the modules. Octave is big enough (12MB source code) and It drives me mad because I can't just leave it on overnight. The following things can happen: a) It works b) Corruption appears on the screen and the compiler locks up. c) Screen goes white and the machine resets. d) Internal compiler error e) Error 1 - Stops compiling f) IO-Error, can't open t:xxxxxxxx g) Virtual Memory exhausted When I run VMM I allocate 80MB of Virtual and have about 9MB of fast ram free. Ive tried GCCSTACK set between 256K and 800K. The other strange thing is that for every C++ file I compile I get a load of warnings in complex.h - One for each inline function saying somethin like: Warning [Function Name] was declared extern and subsequentley static. So I get about 15-20 of these scrolling past my screen. The other warning I had was symbol __P redeclared. I altered gcc:include/sys/cdefs.h :- #if defined(__STDC__) || defined(__cplusplus) #ifndef __P /* I added this line */ #define __P(protos) protos /* full-blown ANSI C */ #endif /* and this one */ Any ideas, I'm lost. Thanks in advance. Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Jan 27 22:39:38 1995 Received: from wuarchive.wustl.edu ([128.252.135.4]) by nic.funet.fi with SMTP id <93029-3>; Fri, 27 Jan 1995 22:37:56 +0200 Received: (from umueller@localhost) by wuarchive.wustl.edu (8.6.9/8.6.9) id OAA05926; Fri, 27 Jan 1995 14:22:23 -0600 From: Urban Mueller Message-Id: <199501272022.OAA05926@wuarchive.wustl.edu> Subject: Aminet and the GPL To: fnf@amigalib.com (Fred Fish) Date: Fri, 27 Jan 1995 14:22:14 -0600 (CST) Cc: proffa.cc.tut.fi!k150471@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <9501261626.AA18262@fishpond.amigalib.com> from "Fred Fish" at Jan 26, 95 04:26:04 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1025 > In theory, you should be able to get complete binaries and sources > from aminet, but in practice most of the aminet uploads of GNU code > violate the GPL, which says that source for *that* *binary* must be > made available alongside the binary. Two issues here. I'm not sure, from this post, if the Aminet GCC dist violates the GPL. The GPL requires you to provide source for the binaries that you redistribute. Those diffs on telesys could well be add-ons to the GCC dist, not sources for binaries distributed with the Aminet gcc dist (AXP crosscompiler on Aminet?). Second, yes, there is a good chance that we have binaries that violate the GPL (because parts of the sources are only available from places that we don't administer). However many of these are not easy to spot at all, remember that we don't even have access to an Amiga when sorting files into Aminet. I usually try to iron these out when the CDs are released. Of course I'm happy to remove any files pointed out to me that violate the GPL. -Urban From amiga-gcc-port-owner@nic.funet.fi Sat Jan 28 04:00:14 1995 Received: from fishpond.amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <92859-1>; Sat, 28 Jan 1995 03:58:06 +0200 Message-ID: <9501271902.AA18197@fishpond.amigalib.com> Subject: Re: Compling GNU Octave 1.1.0 with Amiga GCC V2.6.3 To: flevel.demon.co.uk!dev Date: Fri, 27 Jan 1995 19:01:53 +0700 (MST) From: "Fred Fish" Cc: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) In-Reply-To: <201cd50e.cd140-dev@flevel.demon.co.uk> from "flevel.demon.co.uk!dev" at Jan 27, 95 03:41:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1865 > I'm trying to compile Octave 1.1.0 with Amiga GCC V2.6.3 and I am having > some problems, my configuration is:- I didn't have any of the problems you did, but I had my own set: (1) There is a bug in f2c (sysdep.c) where it doesn't allocate sufficient space for temporary file names. It assumes that getpid() returns a 16 bit integer, which is used to build a temporary file name, and the assumption is that 5 characters max are used to print the value. I fixed it by just taking the getpid() value modulo 1<<16. (2) Many of the C++ files assume that will get the C include file, not the C++ file. This is incorrect since the C++ directory is searched first and since the Amiga has case insensitive file names, is used when was intended. I changed all of these, including some in the readline library and the info directory, to . (3) Two of the library files won't compile with either gcc 2.6.3 or gcc 2.3.3. They crash the machine hard. This is obviously a compiler bug. The files are machine generated by f2c. This is a common problem with machine generated files, they often trigger latent compiler bugs that are never found by running millions of lines of programmer generated code through the compiler. I don't have time right now to chase those bugs, but I'd start by building a cross compiler in a Unix environment in the hopes that compiling the files there will trigger a core dump that can be easily traced back to the root of the problem. Other than these problems, and a couple other files that would compile with gcc 2.3.3 but not 2.6.3, I was able to compile everything. The link of the octave executable failed though, partly because of unresolved globals that are probably supposed to be in the two files that I could not compile. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Jan 28 16:49:55 1995 Received: from deep.rsoft.bc.ca ([204.174.16.4]) by nic.funet.fi with SMTP id <92935-1>; Sat, 28 Jan 1995 16:47:25 +0200 Received: from mindlink.bc.ca by deep.rsoft.bc.ca with smtp (Smail3.1.28.1 #5) id m0rYEJA-000BURC; Sat, 28 Jan 95 06:39 PST Message-Id: Date: Sat, 28 Jan 95 06:39:10 -0800 To: amiga-gcc-port@nic.funet.fi Subject: Activity From: Colin_Fox@mindlink.bc.ca (Colin Fox) I haven't been getting any mail from the GCC mailing list. Is there no activity, or have I been kicked off the mailing list? -- ------ Colin Fox ------ Live Wire Designs ---------------------- ------ Colin_Fox@mindlink.bc.ca -------------------------------- From amiga-gcc-port-owner@nic.funet.fi Sat Jan 28 20:53:03 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <92939-2>; Sat, 28 Jan 1995 20:49:26 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id aa27919; 28 Jan 95 18:41 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA00768; Sat, 28 Jan 95 16:01:31 GMT Date: Sat, 28 Jan 95 16:01:31 GMT Message-Id: <9501281601.AA00767@flevel.demon.co.uk> Message-Id: <201e2b58.53020-dev@flevel.demon.co.uk> In-Reply-To: <9501271902.AA18201@fishpond.amigalib.com> (from Fred Fish ) (at Fri, 27 Jan 1995 19:01:53 +0700 (MST)) X-Mailer: //\\miga Electronic Mail (AmiElm 3.99) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: fnf@amigalib.com Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Compling GNU Octave 1.1.0 with Amiga GCC V2.6.3 Hi Fred, > > I'm trying to compile Octave 1.1.0 with Amiga GCC V2.6.3 and I am having > > some problems, my configuration is:- > > I didn't have any of the problems you did, but I had my own set: > > (1) There is a bug in f2c (sysdep.c) where it doesn't allocate > sufficient space for temporary file names. It assumes that > getpid() returns a 16 bit integer, which is used to build > a temporary file name, and the assumption is that 5 characters > max are used to print the value. I fixed it by just taking > the getpid() value modulo 1<<16. I found the same problem with f2c. I downloaded another later version from Aminet which was compiled for SASC and used the main program with the GCC libraries from the older version. It seems to compile ok but I haven't tried linking yet. > (2) Many of the C++ files assume that will get the C > include file, not the C++ file. This is incorrect > since the C++ directory is searched first and since the Amiga > has case insensitive file names, is used when > was intended. I changed all of these, including > some in the readline library and the info directory, to > . I can't say Ive noticed this, what errors does it cause? > (3) Two of the library files won't compile with either gcc 2.6.3 > or gcc 2.3.3. They crash the machine hard. This is obviously > a compiler bug. The files are machine generated by f2c. This > is a common problem with machine generated files, they often > trigger latent compiler bugs that are never found by running > millions of lines of programmer generated code through the > compiler. I don't have time right now to chase those bugs, > but I'd start by building a cross compiler in a Unix > environment in the hopes that compiling the files there > will trigger a core dump that can be easily traced > back to the root of the problem. Ive managed to make the libraries ok but I haven't tried linking them yet - I'm working on the main program now. libcruft.a 3309578 ----rwed Monday 18:41:07 liboctave.a 2168416 ----rwed Monday 21:12:57 > Other than these problems, and a couple other files that would compile > with gcc 2.3.3 but not 2.6.3, I was able to compile everything. The > link of the octave executable failed though, partly because of unresolved > globals that are probably supposed to be in the two files that I > could not compile. Which files could you not compile? If I do get it working I'll upload an executable to Aminet. Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Sun Jan 29 20:03:54 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <92925-4>; Sun, 29 Jan 1995 20:01:26 +0200 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA25554; Sun, 29 Jan 1995 19:05:18 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9501291805.AA25554@decap2.zdv.uni-tuebingen.de> Subject: Re: Aminet and the GPL To: umueller@wuarchive.wustl.edu (Urban Mueller) Date: Sun, 29 Jan 1995 19:05:17 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199501272022.OAA05926@wuarchive.wustl.edu> from "Urban Mueller" at Jan 27, 95 02:22:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 562 The GPL expects you to a) distribute sources, b) offer to distribute the sources or c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) As far as I can see this is well done by the current gcc distribution: The README's give sufficient information on how to obtain theses sources. Jochen From amiga-gcc-port-owner@nic.funet.fi Sun Jan 29 22:27:03 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <92926-3>; Sun, 29 Jan 1995 22:21:19 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rYgEP-0004nYC; Sun, 29 Jan 95 13:28 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Aminet and the GPL To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Sun, 29 Jan 1995 13:28:20 -0700 (MST) Cc: umueller@wuarchive.wustl.edu, amiga-gcc-port@nic.funet.fi, fnf@amigalib.com (Fred Fish) In-Reply-To: <9501291805.AA25554@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Jan 29, 95 07:05:17 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3753 > The GPL expects you to a) distribute sources, b) offer to distribute > the sources or > > c) Accompany it with the information you received as to the offer > to distribute corresponding source code. (This alternative is > allowed only for noncommercial distribution and only if you > received the program in object code or executable form with such > an offer, in accord with Subsection b above.) > > As far as I can see this is well done by the current gcc distribution: > The README's give sufficient information on how to obtain theses > sources. You left out the all important "Subsection b above", which is: b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, The way I read this (and also corresponds to what I remember about the discussions of this issue in the gnu groups) is that section (c) would only apply to the aminet distributions if whomever provides the binary distribution to aminet also provides Urban (or entity responsible for aminet, whomever that might be) with a *written* *offer* to provide the source for at least 3 years. I seem to recall that this means a physical hard copy, not just an electronic one. It's also not entirely clear from subsection (c), but I seem to recall that "accompany it with the information you received" means that you must also pass on this *written* *offer* to anyone who receives the binaries. If you don't quite understand why these conditions are necessary, download the aminet gcc 2.6.3 binary distribution, unpack it, and then track down and rebuild all the binaries included in the bin directory using only sources available on aminet or on in places pointed to by the documentation included: ar listing wc as ln whoami awk locate xargs basename logname yes bison ls zdiff c++ make zforce c++-020 makeinfo zgrep c++filt mit2mot zmore cat mkdir znew chgrp mot2mit chmod mv chown nice cksum nl cmp nm comm nohup cp objcopy csplit objdump cut od date paste dd patch df pathchk diff pr diff3 printenv dir printf dirname protoize du protoize-020 echo pwd env ranlib expand rm expr rmdir false sdiff fd2inline sed find sh flex size fold sleep g++ sort g++-020 split gasp strings gcc stripc gcc-020 sum gccv tac gccv-020 tail genclass tar gperf tee grep test groups touch gzexe tr gzip true head unexpand hostname uniq hunk2gcc unprotoize id unprotoize-020 install updatedb ixconfig uudecode join uuencode ld vdir Now wait 2 or 3 years, dust off your aminet CD, and do it again. Anyone want to place any bets on how successful you will be in tracking down the source then? :-) I feel pretty strongly about this issue because I know from experience how tough this is. I spent several months doing exactly this exercise for the first set of GNU tools on my Oct '94 FreshFish CD. In most cases, I simply gave up on finding all the right source pieces and started fresh with the baseline FSF source distributions on prep.ai.mit.edu. This is why I not only include the source on each CD, I actually build and test every executable at least once from the provided source. This not only makes sure all the pieces are available, but helps to ensure the overall integrity of the environment, with respect to all the tools playing together properly. -Fred From amiga-gcc-port-owner@nic.funet.fi Sun Jan 29 22:55:10 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <92931-3>; Sun, 29 Jan 1995 22:51:25 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rYghi-0004nYC; Sun, 29 Jan 95 13:58 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Aminet and the GPL To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Sun, 29 Jan 1995 13:58:37 -0700 (MST) Cc: umueller@wuarchive.wustl.edu, amiga-gcc-port@nic.funet.fi, fnf@amigalib.com (Fred Fish) In-Reply-To: <9501291805.AA25554@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Jan 29, 95 07:05:17 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3985 Not to beat this issue to death, but I thought I'd relay one more example of why it is important not only to provide the full ported source, but also either the original FSF source or diffs suitable to convert between the FSF baseline and the Amiga source. Recently there was a port of GNU EMACS 19.XX uploaded to aminet, where "XX" was claimed to be "25". Since the latest available version is 19.28, I decided to try downloading this "19.25" version and forward merging the changes into the FSF 19.28 version, to bring it up to date. So I tracked down a copy of the FSF 19.25 archive, which although it has been deleted from the FSF machine, was fairly easy to find with "archie" on some obscure system where the system admins either were not as tight on disk space as the FSF, or else recognized the value of keeping older versions online. I only had to try two or three of the dozen sites listed by archie before I managed to find one that was actually still online. Then I unpacked the 19.25 FSF archive and ran diff against the unpacked Amiga 19.25 archive. Imagine my surprise when the diff file was about 5 Mb! It turns out that this "19.25" release is actually a mixture of files from more than one release. After poking around, I determine that the earliest release for which files are included in 19.25 appears to be 19.22. So I figure I potentially need *all* the releases between 19.22 and 19.25 to sort the mess out. So back to archie I go looking for 19.22, 19.23, & 19.24. The first two I found again fairly readily, but that all important first baseline 19.22 was still missing. Several hours later, and after checking virtually *every* site listed that was supposed to still have 19.22 online, I finally found one that really did have the archive, but it apparently was on a 9600 baud internet link, because it took another 4 hours to suck the archive over. No back to diff I go. For *every* file in the Amiga 19.25 distribution I diffed it against the same file in the 19.22, 19.23, and 19.24 distributions, and looked for the diff files that were the smallest, and thus should in theory only contain the Amiga specific diffs. After gathering all these minimal diff files, I then apply them with patch to the 19.28 FSF distribution, and resolve the rejects by either applying them by hand or attempting to figure out if they are no longer necessary or otherwise resolving them. After several more fun hours, I finally manage to build a 19.28 emacs that is capable of dumping itself, and editing some basic files. The moral of this story is that I had to go to rather extreme lengths to simply discover what the changes were that were made during the course of doing an Amiga port. Luckily, I was still able to track down all the necessary pieces. Note that it isn't really sufficient to provide just the Amiga source unless you don't care that someone else 6 months or a year from now will be able to build on your work, rather than discarding it and starting over. This is part of the reason why my CD's contain not only the fully compilable Amiga port source, but also the original FSF baseline archives and the diffs that you get when you diff the FSF baseline against the Amiga port. In theory, only two pieces are needed to reconstruct the third. You should be able to derive the Amiga source from the FSF baseline and a full diff file, using patch. You should also be able to derive the diffs from the FSF baseline and the Amiga source. And you could even derive the FSF source from the diffs and the Amiga source. But if you are missing more than one of the three pieces, you are out of luck for doing an easy upgrade unless the baseline source has changed very little and you can still manually sort out the Amiga changes from the other non-Amiga changes that have been made in the baseline source. Sorry to be so long winded, but I think this is vital point to make about why full sources or sources+diffs are so important. -Fred From amiga-gcc-port-owner@nic.funet.fi Sun Jan 29 23:06:24 1995 Received: from wuarchive.wustl.edu ([128.252.135.4]) by nic.funet.fi with SMTP id <92934-4>; Sun, 29 Jan 1995 23:03:00 +0200 Received: (from umueller@localhost) by wuarchive.wustl.edu (8.6.9/8.6.9) id PAA31988; Sun, 29 Jan 1995 15:02:37 -0600 From: Urban Mueller Message-Id: <199501292102.PAA31988@wuarchive.wustl.edu> Subject: Re: Aminet and the GPL To: fnf@amigalib.com (Fred Fish) Date: Sun, 29 Jan 1995 15:02:34 -0600 (CST) Cc: zrawi01@decap2.zdv.uni-tuebingen.de, amiga-gcc-port@nic.funet.fi, fnf@amigalib.com, mscheler@wuarchive.wustl.edu (Matthias Scheler) In-Reply-To: from "Fred Fish" at Jan 29, 95 01:28:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 458 I understand that we have a problem here, but I can hardly help solve it. It's up to the authors of the software submitted to Aminet. I cannot check if all the archives contain compilable sources; I don't even have an Amiga available when I administer files. All I can do is make the auhors aware of the situation, which I've done now by including a note in README.BEFORE.UPLOAD. I'll also contact future uploaders of GNU software without source. -Urban From amiga-gcc-port-owner@nic.funet.fi Sun Jan 29 23:23:19 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <92936-1>; Sun, 29 Jan 1995 23:19:03 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA08377; Sun, 29 Jan 95 14:20:07 MST Date: Sun, 29 Jan 1995 14:20:06 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: Fred Fish Cc: Jochen Wiedmann , umueller@wuarchive.wustl.edu, amiga-gcc-port@nic.funet.fi, Fred Fish Subject: Re: Aminet and the GPL In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 29 Jan 1995, Fred Fish wrote: > Not to beat this issue to death, but I thought I'd relay one more > example of why it is important not only to provide the full ported > source, but also either the original FSF source or diffs suitable to > convert between the FSF baseline and the Amiga source. I agree wholeheartedly. I believe the FSF baseline and diffs is the way sources ought to be distributed with binaries. That way there is always a clear path back to the FSF distribution. And, the sources should ALWAYS be included, at least as a clear option. Sometimes the size of a distribution file can become too large to be practical, but another source only set should be available. I am currently trying to do a port of tar (V1.11.2) from scratch because it seems easier than trying to track down the amiga port sources. I wonder how many others face the same dilemma. Paul Ney From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 03:22:46 1995 Received: from eskimo.com ([204.122.16.13]) by nic.funet.fi with SMTP id <92946-3>; Mon, 30 Jan 1995 03:16:20 +0200 Received: by eskimo.com (5.65c/1.35) id AA10620; Sun, 29 Jan 1995 17:16:09 -0800 Date: Sun, 29 Jan 1995 17:16:09 -0800 From: thought@eskimo.com (Jesse McClusky) Message-Id: <199501300116.AA10620@eskimo.com> To: amiga-gcc-port@nic.funet.fi Subject: Problem with GCC make and sh Okay, I've got a little problem. I just recently got a hard drive, and decided to get the GCC distribution installed on it. However, I ran into a few problems. Most of the utilities from the gcc dist. crash when run from the 'sh'. The also crash on the normal AmigaDOS shell unless you set the stack to 16k+ (a trick which I told about by a kind soul) However, a few still crash (ls is one, but I have 2 other versions of it by different authors, so it's no big deal) make, on the other hand, doesn't work right at all. I keep getting 'missing seperator' errors from it on makefiles that work fine with gnu make on all other systems. Can someone help? It's really important I get it working, as I need to compile a program that has about 3 megs of source code and would be nearly impossible without make. Jesse McClusky (thought@eskimo.com) From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 07:08:08 1995 Received: from eskimo.com ([204.122.16.13]) by nic.funet.fi with SMTP id <92950-2>; Mon, 30 Jan 1995 07:00:16 +0200 Received: by eskimo.com (5.65c/1.35) id AA17186; Sun, 29 Jan 1995 21:00:05 -0800 Date: Sun, 29 Jan 1995 21:00:05 -0800 From: thought@eskimo.com (Jesse McClusky) Message-Id: <199501300500.AA17186@eskimo.com> To: amiga-gcc-port@nic.funet.fi Subject: looking for csh or tcsh Does anyone know where I could get csh or (preferrably) tcsh for the amiga? Specifically, one which will run on a 68000? If not, does anyone know where I can get the gnu sources so I can compile it myself? It would be appreciated, since I can't get the 'sh' which comes with gnu to work properly, and don't like the korne shell in the first place. Jesse McClusky, disgruntalled Amiga GNU user.... From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 11:28:26 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <92925-2>; Mon, 30 Jan 1995 11:23:58 +0200 Received: by colombo.telesys-innov.fr; Mon, 30 Jan 1995 10:21:21 +0100 From: Philippe BRAND Message-Id: <199501300921.KAA12176@colombo.telesys-innov.fr> Subject: Re: Aminet and the GPL To: umueller@wuarchive.wustl.edu (Urban Mueller) Date: Mon, 30 Jan 1995 10:21:16 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199501292102.PAA31988@wuarchive.wustl.edu> from "Urban Mueller" at Jan 29, 95 03:02:34 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 591 Urban Mueller writes: > I understand that we have a problem here, but I can hardly help solve > it. It's up to the authors of the software submitted to Aminet. I cannot > check if all the archives contain compilable sources; I don't even > have an Amiga available when I administer files. It would be really no problem uploading sources to Aminet but due to sizes wouldn't it be better to put sources on another system and include a note in gcc dist pointing to this site (ftp.funet.fi for example) ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 11:35:53 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <92934-1>; Mon, 30 Jan 1995 11:30:21 +0200 Received: by colombo.telesys-innov.fr; Mon, 30 Jan 1995 10:28:02 +0100 From: Philippe BRAND Message-Id: <199501300928.KAA12194@colombo.telesys-innov.fr> Subject: Re: Aminet and the GPL To: fnf@amigalib.com (Fred Fish) Date: Mon, 30 Jan 1995 10:27:57 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Fred Fish" at Jan 29, 95 01:28:20 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 829 Fred Fish writes: > Anyone want to place any bets on how successful you will be in > tracking down the source then? :-) Not providing sources or at least diffs is entirely my fault. In fact back in December when I relased 2.6.3 on Aminet, I had to be responsible for our BBS system in France so I had to move few HD & CDs from my dev system to BBS system. Result is that my system was down for more than one mounth, thus I couldn't release sources nor diffs files. Now last Saturday I finally managed to resolve all my SCSI bus problems (cf c.s.a.hardware) and I restored my DEVEL: & SOURCES: partitions. Asap I'll build gcc263-diffs.lha, and I'd really like to know where I could put, if necessary, all sources: Aminet ? Ftp.funet.fi ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 12:33:10 1995 Received: by nic.funet.fi id <92944-2>; Mon, 30 Jan 1995 12:29:57 +0200 Subject: Re: Activity From: Matti Aarnio To: Colin_Fox@mindlink.bc.ca (Colin Fox) Date: Mon, 30 Jan 1995 12:29:51 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Colin Fox" at Jan 28, 95 06:39:10 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 461 Message-Id: <95Jan30.122957+0200_eet.92944-2+16@nic.funet.fi> > I haven't been getting any mail from the GCC mailing list. Is there no > activity, or have I been kicked off the mailing list? You are not on the list (I looked up "mindlink"), so propably your address has bounced some of its emails, and the admins have removed you.. > -- > ------ Colin Fox ------ Live Wire Designs ---------------------- > ------ Colin_Fox@mindlink.bc.ca -------------------------------- /Matti Aarnio Postmaster From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 13:49:36 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <92939-1>; Mon, 30 Jan 1995 13:46:11 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id MAA18241; Mon, 30 Jan 1995 12:44:56 +0100 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id OAA19111; Mon, 30 Jan 1995 14:16:37 -0500 Date: Mon, 30 Jan 1995 14:16:37 -0500 From: Niklas Hallqvist Message-Id: <199501301916.OAA19111@linda.appli.se> To: phb@colombo.telesys-innov.fr CC: umueller@wuarchive.wustl.edu, amiga-gcc-port@lists.funet.fi In-reply-to: <199501300921.KAA12176@colombo.telesys-innov.fr> (message from Philippe BRAND on Mon, 30 Jan 1995 10:21:16 +0100 (MEZ)) Subject: Re: Aminet and the GPL >>>>> "Philippe" == Philippe BRAND writes: Philippe> Urban Mueller writes: >> I understand that we have a problem here, but I can hardly help >> solve it. It's up to the authors of the software submitted to >> Aminet. I cannot check if all the archives contain compilable >> sources; I don't even have an Amiga available when I administer >> files. Philippe> It would be really no problem uploading sources to Aminet Philippe> but due to sizes wouldn't it be better to put sources on Philippe> another system and include a note in gcc dist pointing to Philippe> this site (ftp.funet.fi for example) ? As a note to Urban maybe, but not as a note to distribute. There is no guarantee at all ftp.funet.fi will keep exactly the sources for the version that you've compiled. Any user should be guaranteed that he can find the sources for GNU software, either in the package, or else in three years time from a guaranteed source. And that is the exact version he has got the binaries for, not a current version of the same piece of software. Believe me, this is a good policy. The easiest way to keep within the GPL is to upload the sources when you upload the binary, then you never need to guarantee anything at all! Niklas From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 14:08:19 1995 Received: by nic.funet.fi id <92959-3>; Mon, 30 Jan 1995 14:01:22 +0200 From: Leonard Norrgard To: Colin_Fox@mindlink.bc.ca CC: amiga-gcc-port@nic.funet.fi In-reply-to: (Colin_Fox@mindlink.bc.ca) Subject: Re: Activity Message-Id: <95Jan30.140122+0200_eet.92959-3+13@nic.funet.fi> Date: Mon, 30 Jan 1995 14:01:13 +0200 Colin Fox writes: > I haven't been getting any mail from the GCC mailing list. Is there no > activity, or have I been kicked off the mailing list? Seems you were removed, Colin. I remember getting loads of mail errors from your host earlier. When such thiungs happen, I try to stand for a week or two, if the error hasn't been fixed by then, I silently remove problem addresses from the list. I whish there was a way I could inform people who get removed this way, but as mail doesn't get through, mailing them is of no use... Colin: you can resubscribe the usual way, ie. send mail like: To: mailserver@lists.funet.fi Subject: subscribe amiga-gcc-port Colin Fox -- vinsci From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 15:16:24 1995 Received: from godot.lysator.liu.se ([130.236.254.154]) by nic.funet.fi with ESMTP id <92952-1>; Mon, 30 Jan 1995 15:06:40 +0200 Received: from lysita (nisse@lysita.lysator.liu.se [130.236.254.153]) by godot.lysator.liu.se (8.6.8.1/8.6.6) with ESMTP id OAA02626 for ; Mon, 30 Jan 1995 14:06:31 +0100 Received: from localhost (nisse@localhost) by lysita (8.6.5/8.6.5) id OAA08984; Mon, 30 Jan 1995 14:06:19 +0100 Date: Mon, 30 Jan 1995 14:06:19 +0100 From: nisse@lysator.liu.se Message-Id: <199501301306.OAA08984@lysita> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: amiga-gcc-port@nic.funet.fi Subject: Memory leak? I've written a rather memory intensive program using gcc, or more specifically the c and the objective-c compiler, version 2.5.8. I open a screen and a window, but all other memory the program needs is allocated by malloc(), or via objc [ .. alloc] which in turn calls malloc(). I have tried allocating memory both in large chunks, and object by objects (most of the objects are 8 - 40 bytes, they are rather many). On most of the memory allocated, I don't call free and instead rely on ixemul to free it when the program exits. I'm using a recent ixemul.library, version 40 if I remember correctly. When I start the program it does some computations and allocates about 1 MB. If I exit at that point, all memory is released to the system. I test this by > avail flush > my_program > avail flush But if I let my program continue until it has used more memory, say 5-6 MB, before it exits, all but about 0.5 - 4 KB is released. Why this leak? Have I made some stupid error, or is it a bug in malloc/ixemul? Regards, Niels Möller From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 15:54:13 1995 Received: from wuarchive.wustl.edu ([128.252.135.4]) by nic.funet.fi with SMTP id <92960-2>; Mon, 30 Jan 1995 15:43:25 +0200 Received: (from umueller@localhost) by wuarchive.wustl.edu (8.6.9/8.6.9) id HAA29118; Mon, 30 Jan 1995 07:42:54 -0600 From: Urban Mueller Message-Id: <199501301342.HAA29118@wuarchive.wustl.edu> Subject: Re: Aminet and the GPL To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Mon, 30 Jan 1995 07:42:53 -0600 (CST) Cc: amiga-gcc-port@nic.funet.fi, fnf@amigalib.com In-Reply-To: <199501300921.KAA12176@colombo.telesys-innov.fr> from "Philippe BRAND" at Jan 30, 95 10:21:16 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 636 > > Urban Mueller writes: > > > I understand that we have a problem here, but I can hardly help solve > > it. It's up to the authors of the software submitted to Aminet. I cannot > > check if all the archives contain compilable sources; I don't even > > have an Amiga available when I administer files. > > It would be really no problem uploading sources to Aminet but due to sizes > wouldn't it be better to put sources on another system and include a note in > gcc dist pointing to this site (ftp.funet.fi for example) ? There is no problem with uploading everything to Aminet. We have enough disk space and bandwidth. -Urban From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 19:57:43 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <92960-3>; Mon, 30 Jan 1995 19:48:57 +0200 Received: by theseas.ntua.gr with UUCP; Mon, 30 Jan 1995 19:48:53 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05rq@kriton.UUCP>; Mon, 30 Jan 95 19:37:41 EET Date: Mon, 30 Jan 95 19:37:41 EET Message-Id: <9501301737.05rq@kriton.UUCP> In-Reply-To: <199501300116.AA10620@eskimo.com> (from thought@eskimo.com (Jesse McClusky)) (at Sun, 29 Jan 1995 17:16:09 -0800) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1201 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: thought@eskimo.com Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Problem with GCC make and sh Hi Jesse (Jesse McClusky), in <199501300116.AA10620@eskimo.com> on Jan 29 you wrote: > make, on the other hand, doesn't work right at all. > > I keep getting 'missing seperator' errors from it on makefiles that work > fine with gnu make on all other systems. Can someone help? It's really Sounds like you're trying to run make using SAS/C makefiles, which allow spaces instead of tabs at the beginning of actions. You'll need to convert your makefiles so that lines like: foo.o: foo.c $(CC) $(CFLAGS) foo.c ^ |___ (one or more spaces) become: foo.o: foo.c $(CC) $(CFLAGS) foo.c ^ |___ (TAB) You can do this conversion automatically using sed: sed -e "s/^ */ /" Makefile.new ^ ^ | |___ (TAB) |________(two consecutive spaces) As for your problems with some of the GNU programs, you might need to increase your stack even more; I use a stack of 20000 and have only problems with cp, which requires even more. (I believe Philippe uses a stack of 50000!) -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I shall be coming back." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 22:02:04 1995 Received: from crew.umich.edu ([141.211.184.10]) by nic.funet.fi with SMTP id <92936-2>; Mon, 30 Jan 1995 21:59:42 +0200 Received: from uri.crew.umich.edu by crew.umich.edu (8.6.9/2.2) with ESMTP id OAA00203; Mon, 30 Jan 1995 14:58:07 -0500 Received: from localhost by uri.crew.umich.edu (8.6.9/dumb-1.0) id OAA23226; Mon, 30 Jan 1995 14:58:06 -0500 Message-Id: <199501301958.OAA23226@uri.crew.umich.edu> To: dev@flevel.demon.co.uk cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi, chymes@crew.umich.edu Subject: Re: Compling GNU Octave 1.1.0 with Amiga GCC V2.6.3 In-reply-to: Your message of "Sat, 28 Jan 1995 16:01:31 GMT." <9501281601.AA00767@flevel.demon.co.uk> <201e2b58.53020-dev@flevel.demon.co.uk> Date: Mon, 30 Jan 1995 14:58:05 -0500 From: Charles Hymes It seems to me you were kicked off. The mailing list is quite busy. Charlweed From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 22:55:29 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <92959-3>; Mon, 30 Jan 1995 22:53:25 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 30 Jan 95 21:52 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 30 Jan 95 21:47 MET Message-Id: Subject: Re: Problem with GCC make and sh To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 30 Jan 1995 21:47:41 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1310 > Sounds like you're trying to run make using SAS/C makefiles, which allow > spaces instead of tabs at the beginning of actions. You'll need to > convert your makefiles so that lines like: > > foo.o: foo.c > $(CC) $(CFLAGS) foo.c > ^ > |___ (one or more spaces) > > become: > > foo.o: foo.c > $(CC) $(CFLAGS) foo.c > ^ > |___ (TAB) > > You can do this conversion automatically using sed: > > sed -e "s/^ */ /" Makefile.new > ^ ^ > | |___ (TAB) > |________(two consecutive spaces) > > As for your problems with some of the GNU programs, you might need to > increase your stack even more; I use a stack of 20000 and have only > problems with cp, which requires even more. (I believe Philippe uses a > stack of 50000!) > -- > i dont see why we should distinguish between space and tabs. they should treated equaly. if the user cant see the difference the programm shouldnt see it either. i remember my c64 times there was no problem with mixing tab & space :) walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Mon Jan 30 23:35:40 1995 Received: from postman.essex.ac.uk ([155.245.10.14]) by nic.funet.fi with SMTP id <92967-1>; Mon, 30 Jan 1995 23:33:16 +0200 Received: from postman.essex.ac.uk by postman.essex.ac.uk with SMTP (PP) id <28032-0@postman.essex.ac.uk>; Mon, 30 Jan 1995 16:06:48 +0000 From: Waland J F Date: Mon, 30 Jan 95 14:05:15 GMT Message-Id: <2404.9501301405@esl3.essex.ac.uk> To: thought Subject: Re: Problem with GCC make and sh Cc: amiga-gcc-port >I keep getting 'missing seperator' errors from it on makefiles that work >fine with gnu make on all other systems. Can someone help? It's really >important I get it working, as I need to compile a program that has about >3 megs of source code and would be nearly impossible without make. check that the editor that you are using actually inserts tabs and not spaces (I had/have this problem, and has always been due to lack of tabs) jon From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 03:47:05 1995 Received: from TIAMAT.DRAGON.COM ([155.229.20.2]) by nic.funet.fi with SMTP id <92939-3>; Tue, 31 Jan 1995 03:45:20 +0200 Received: from opera by dragon.com (MX V4.1 VAX) with UUCP; Mon, 30 Jan 1995 20:44:47 EST Received: by opera.dragon.com (V1.17-beta/Amiga) id <06q4@opera.dragon.com>; Mon, 30 Jan 95 20:45:08 EST Date: Mon, 30 Jan 95 20:45:08 EST Message-ID: <202110d1.71ef4-cls@opera.dragon.com> X-Mailer: //\\miga Electronic Mail (AmiElm 3.99) From: To: amiga-gcc-port@nic.funet.fi Subject: GNU make utility Concerning the space vs. tabs issue expressed here, I guess the question should be: 1. Do we want to insure makefiles developed on AmigaDOS under GNU are fully transportable to unix? - or - 2. Do we want to make sure unix makefiles are fully portable to AmigaDOS? My personal preference would be to allow the "extension" on AmigaDOS of using any amount of white space before the command on a command line, possibly as a GNU make option. For example, a makefile generated under AmigaDOS and under unix using "standard" unix makefile rules (only one white space character before the command) would operate normally using a standard make command such as: make while those in Amiga-land could fill with spaces and tabs to their heart's content, understanding that such a makefile is not portable back to unix. To allow multiple white space characters, use something like: make -W (Don't know if I've chosen a real make switch or not, there) Is it just me, or does this seem like a reasonable solution to others? ========================================================================== Charles Streible | cls@opera.dragon.com (home) | cls@dido.opera.dragon.com (home) | streible@landmark.net (work) From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 09:05:41 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <93075-1>; Tue, 31 Jan 1995 09:00:23 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA15558; Tue, 31 Jan 95 08:59:13 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA04256; Tue, 31 Jan 95 09:01:06 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9501310701.AA04256@hpcl.cti.gr> Subject: Re: Problem with GCC make and sh To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Tue, 31 Jan 1995 09:01:04 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) In-Reply-To: from "Walter Harms" at Jan 30, 95 09:47:41 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 407 > i dont see why we should distinguish between space and tabs. > they should treated equaly. if the user cant see the difference > the programm shouldnt see it either. i remember my c64 times > there was no problem with mixing tab & space :) This is the specification of unix make, and GNU make complies to that. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 10:25:48 1995 Received: from eskimo.com ([204.122.16.13]) by nic.funet.fi with SMTP id <91151-2>; Tue, 31 Jan 1995 10:20:46 +0200 Received: by eskimo.com (5.65c/1.35) id AA12591; Tue, 31 Jan 1995 00:20:32 -0800 Date: Tue, 31 Jan 1995 00:20:32 -0800 From: thought@eskimo.com (Jesse McClusky) Message-Id: <199501310820.AA12591@eskimo.com> To: amiga-gcc-port@nic.funet.fi Subject: Thanks... I appreciate all the help you guys sent.... (: I finally realised 'ed' was translating the tabs into spaces (by using newzap, a hex editor), and so am translating 'ex' (my favorite editor) to the amiga. (I'm writing it in amiga e because it's easier to debug and has dynamic link lists built in, sorry.) I'll also be porting tcsh when I finish with 'ex', and then will be uploading both to the Aminet. Also, I figured out how to get 'sh' to work with a larger stack: run it from the shell. *duh* (I was running it from Fkey originally) Jesse McClusky From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 10:59:52 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91150-1>; Tue, 31 Jan 1995 10:53:40 +0200 Received: by colombo.telesys-innov.fr; Tue, 31 Jan 1995 09:51:28 +0100 From: Philippe BRAND Message-Id: <199501310851.JAA15693@colombo.telesys-innov.fr> Subject: Re: Thanks... To: thought@eskimo.com (Jesse McClusky) Date: Tue, 31 Jan 1995 09:51:27 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199501310820.AA12591@eskimo.com> from "Jesse McClusky" at Jan 31, 95 00:20:32 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 336 Jesse McClusky writes: > I'll also be porting tcsh when I finish with 'ex', and then will be > uploading both to the Aminet. Because bash-1.12 port is nearly complete, you might consider first to take a look at it, finish port then port tcsh :-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 13:39:07 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91153-2>; Tue, 31 Jan 1995 13:26:06 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 31 Jan 95 12:23 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 31 Jan 95 11:43 MET Message-Id: Subject: Re: Problem with GCC make and sh To: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Date: Tue, 31 Jan 1995 11:43:41 +0100 (MET) From: Walter Harms Cc: amiga-gcc-port@lists.funet.fi (amiga gcc-list) In-Reply-To: <9501310701.AA04256@hpcl.cti.gr> from "Kriton Kyrimis" at Jan 31, 95 09:01:04 am X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 937 > > > i dont see why we should distinguish between space and tabs. > > they should treated equaly. if the user cant see the difference > > the programm shouldnt see it either. i remember my c64 times > > there was no problem with mixing tab & space :) > > This is the specification of unix make, and GNU make complies to that. time to change it ! i dont see any reason why we should keep it this way. if spaces are handled like tabs, that shouldnt touch any older makefiles. I am sure that other systems (e.g unix) had the same problem and if noone can say why 'make' needs to distinguish between space and tab this should be abolished. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 14:42:05 1995 Received: from mail.Germany.EU.net ([192.76.144.65]) by nic.funet.fi with ESMTP id <91156-3>; Tue, 31 Jan 1995 14:38:37 +0200 Received: by mail.Germany.EU.net with SMTP (8.6.5:29/EUnetD-2.5.1.c) via EUnet id NAA25008; Tue, 31 Jan 1995 13:40:00 +0100 Message-Id: <9501311232.AA01235@GWEU.softlab.de> Received: from H8 by GWEU.softlab.de with SMTP (5.65/GEN-1.1.8) via EUnet for [192.76.144.65] id AA01235; Tue, 31 Jan 95 13:32:54 +0100 Received: by H8 (1.37.109.4/16.2) id AA09724; Tue, 31 Jan 95 13:39:29 +0100 Date: Tue, 31 Jan 95 13:39:29 +0100 From: REH@softlab.de To: amiga-gcc-port@lists.funet.fi Subject: makefile syntax Charles Streible and Walter Harms advocate changing make on Amiga: > Concerning the space vs. tabs issue expressed here, I guess the question > should be: > 1. Do we want to insure makefiles developed on AmigaDOS under GNU > are fully transportable to unix? > - or - > 2. Do we want to make sure unix makefiles are fully portable to > AmigaDOS? Yes, that's the point! > My personal preference would be to allow the "extension" on AmigaDOS of > using any amount of white space before the command on a command line, > ... > Is it just me, or does this seem like a reasonable solution to others? Well, to me the great value of GNU on Amiga is to have an environment that makes Amiga behave like Unix without running Unix on it. If we start building exceptions into an "Amiga-Version", we loose this behaviour. As a consequence our developments on Amiga will show strange errors when ported (back) to Unix. In other words: please leave make as it is. Gerhard Rehmann From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 14:44:25 1995 Received: from postman.essex.ac.uk ([155.245.10.14]) by nic.funet.fi with SMTP id <91160-4>; Tue, 31 Jan 1995 14:40:59 +0200 Received: from postman.essex.ac.uk by postman.essex.ac.uk with SMTP (PP) id <05202-0@postman.essex.ac.uk>; Tue, 31 Jan 1995 12:38:22 +0000 From: Waland J F Date: Tue, 31 Jan 95 12:37:48 GMT Message-Id: <6975.9501311237@esl11.essex.ac.uk> To: amiga-gcc-port Subject: stack size When setting the stack for a gcc compiled program, where in memory is this actually used? Fast or Chip? I ask because I am writing some code for one of my courses here on a Sparc, and also at home on my A4000/030. The sparc version runs fine, but when I run it at home, I need to set a hideous amount of stack or it crashes (are arrays stored in the stack?). Once the program has run, all of my disk icons dissapear from the workbench (ie when I minimise the shell that I ran it from, the disk icons [dh0 dh1 dh2 ram etc] are missing, but reappear if you click where they should be), and I get locklayer crashes. jon From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 15:04:55 1995 Received: from postman.essex.ac.uk ([155.245.10.14]) by nic.funet.fi with SMTP id <91163-3>; Tue, 31 Jan 1995 15:01:03 +0200 Received: from postman.essex.ac.uk by postman.essex.ac.uk with SMTP (PP) id <05976-0@postman.essex.ac.uk>; Tue, 31 Jan 1995 12:59:28 +0000 From: Waland J F Date: Tue, 31 Jan 95 12:59:22 GMT Message-Id: <7277.9501311259@esl11.essex.ac.uk> To: peteric , walaj@essex.ac.uk Subject: Re: stack size Cc: amiga-gcc-port >Sounds like you haven't got enough memory on your machine at home - as you have >an A4000 you *may* be able to use one of the virtual memory tools to increase >the apparent memory on the machine at the expense of disk space - this is why >the SPARC one works. Nope, I've got 12 Meg, and it doesn't use it all. (well I don't think so;-) [sob] I've only got an EC030 as well :-( > Or redo your >program into smaller files to reduce the apparent complexity of the program. but it's only making large arrays (ie: int array[65536]; two or three times) jon From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 16:50:22 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91158-1>; Tue, 31 Jan 1995 16:39:52 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA17735; Tue, 31 Jan 1995 12:54:38 GMT From: Peter Ivimey-Cook Message-Id: <21105.199501311253@creda.isltd.insignia.com> Subject: Re: stack size To: walaj@essex.ac.uk (Waland J F) Date: Tue, 31 Jan 1995 12:53:06 GMT Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <6975.9501311237@esl11.essex.ac.uk>; from "Waland J F" at Jan 31, 95 12:37 (noon) X-Mailer: elm X-Mailer: Elm [revision: 109.14] > When setting the stack for a gcc compiled program, where in memory is this > actually used? Fast or Chip? It should use whichever is available - i.e. fast first, then chip when that runs out. > > I ask because I am writing some code for one of my courses here on a Sparc, > and also at home on my A4000/030. The sparc version runs fine, > but when I run it at home, I need to set a hideous amount of stack or it > crashes (are arrays stored in the stack?). Once the program has run, all of my > disk icons dissapear from the workbench (ie when I minimise the shell that I > ran it from, the disk icons [dh0 dh1 dh2 ram etc] are missing, but reappear > if you click where they should be), and I get locklayer crashes. Sounds like you haven't got enough memory on your machine at home - as you have an A4000 you *may* be able to use one of the virtual memory tools to increase the apparent memory on the machine at the expense of disk space - this is why the SPARC one works. Virtual memory stuff is dependent upon having a working MMU (memory management unit) in the CPU. *Some* 68EC030 chips have them, all full '030 chips do as do the '040s. If you can't get this to work you have to upgrade to a full '030 with MMU or increase your real memory. I suggest the latter - it's faster. Or redo your program into smaller files to reduce the apparent complexity of the program. BTW. gcc uses (used to use?) alloca() to allocate memory for data structures used to describe your program. Alloca() allocates on stack so that at procedure end the memory is automatically freed. Fine on Unix, with potentially huge stacks, but not very good for Amiga's with small, fixed size ones! Regards, Peter -- Peter Ivimey-Cook Mail Id: peteric@isltd.insignia.com Insignia Solutions, Kingsmead Business Park, London Road, High Wycombe, Buckinghamshire. Telephone: +44-1494-459426 HP11 1JU, U.K. Fax: +44-1494-459720 From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 16:53:32 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91171-3>; Tue, 31 Jan 1995 16:43:58 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA29378; Tue, 31 Jan 95 16:42:33 +0200 Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA01122; Tue, 31 Jan 95 16:44:13 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9501311444.AA01122@hpcl.cti.gr> Subject: Re: stack size To: walaj@essex.ac.uk (Waland J F) Date: Tue, 31 Jan 1995 16:44:13 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) In-Reply-To: <7277.9501311259@esl11.essex.ac.uk> from "Waland J F" at Jan 31, 95 12:59:22 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 219 > but it's only making large arrays (ie: int array[65536]; two or three times) For each of these arrays you use 128k of stack... -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 16:53:33 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91170-2>; Tue, 31 Jan 1995 16:42:54 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA29363; Tue, 31 Jan 95 16:41:19 +0200 Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA01081; Tue, 31 Jan 95 16:43:01 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9501311443.AA01081@hpcl.cti.gr> Subject: Re: stack size To: walaj@essex.ac.uk (Waland J F) Date: Tue, 31 Jan 1995 16:43:00 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) In-Reply-To: <6975.9501311237@esl11.essex.ac.uk> from "Waland J F" at Jan 31, 95 12:37:48 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 831 > When setting the stack for a gcc compiled program, where in memory is this > actually used? Fast or Chip? Any kind of memory the system can grab--usually this means fast mem, if it is available. > crashes (are arrays stored in the stack?). Once the program has run, all of my if you have a function like: int foo(int arg) { int auto1; int auto2[10]; extern int ext; static int st; } Then arg, auto1, and auto2 are kept on the stack, while ext and st are not. This means that if you declare large arrays in your program, you can eat up large amounts of stack. To minimize your stack usage, you can either use malloc to allocate storage dynamically for your arrays (preferred method) or declare them as static. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 17:06:32 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <91172-3>; Tue, 31 Jan 1995 16:57:24 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA15443; Tue, 31 Jan 95 07:58:29 MST Date: Tue, 31 Jan 1995 07:58:26 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: REH@softlab.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: makefile syntax In-Reply-To: <9501311232.AA01235@GWEU.softlab.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 31 Jan 1995 REH@softlab.de wrote: > Well, to me the great value of GNU on Amiga is to have an environment > that makes Amiga behave like Unix without running Unix on it. If we > start building exceptions into an "Amiga-Version", we loose this > behaviour. As a consequence our developments on Amiga will show strange > errors when ported (back) to Unix. In other words: please leave make > as it is. YES YES YES YES!!! Please leave it as it is. The whole purpose I use GNU (besides the c++) is for portability back and forth between UNIX. Paul Ney From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 17:15:53 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91190-1>; Tue, 31 Jan 1995 17:07:41 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Tue, 31 Jan 1995 16:04:19 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA13845; Tue, 31 Jan 95 16:03:51 +0100 Date: Tue, 31 Jan 95 16:03:51 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9501311503.AA13845@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA18312; Tue, 31 Jan 95 16:03:30 +0100 To: walaj@essex.ac.uk (Waland J F) Cc: amiga-gcc-port@nic.funet.fi Subject: Re: stack size In-Reply-To: <21105.199501311253@creda.isltd.insignia.com> References: <6975.9501311237@esl11.essex.ac.uk> <21105.199501311253@creda.isltd.insignia.com> > crashes (are arrays stored in the stack?). Yes, dynamic arrays are there. int foo (n) { char bar[n]; int grr[100]; ... } will take (n + 100*sizeof(int)) bytes from the stack at run-time. So be careful with programs that use this. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 17:20:19 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <91178-3>; Tue, 31 Jan 1995 17:09:42 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA15985; Tue, 31 Jan 95 08:08:37 MST Date: Tue, 31 Jan 1995 08:08:36 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: Kriton Kyrimis Cc: Waland J F , gcc Subject: Re: stack size In-Reply-To: <9501311444.AA01122@hpcl.cti.gr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 31 Jan 1995, Kriton Kyrimis wrote: > > but it's only making large arrays (ie: int array[65536]; two or three times) > > For each of these arrays you use 128k of stack... I thought int => long == 4 bytes. Therefore 64k int's == 256k stack. Am I wrong in this assumption? Paul Ney From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 18:09:26 1995 Received: by nic.funet.fi id <91183-3>; Tue, 31 Jan 1995 17:59:46 +0200 From: Leonard Norrgard To: kyrimis@hpcl.cti.gr CC: walaj@essex.ac.uk, amiga-gcc-port@lists.funet.fi In-reply-to: <9501311444.AA01122@hpcl.cti.gr> (kyrimis@hpcl.cti.gr) Subject: Re: stack size Message-Id: <95Jan31.175946+0200_eet.91183-3+4@nic.funet.fi> Date: Tue, 31 Jan 1995 17:59:37 +0200 >> but it's only making large arrays (ie: int array[65536]; two or three times) > >For each of these arrays you use 128k of stack... ints are four bytes each, so make that 256k of stack. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Tue Jan 31 19:44:35 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91181-1> convert rfc822-to-8bit; Tue, 31 Jan 1995 19:42:11 +0200 Received: by theseas.ntua.gr with UUCP; Tue, 31 Jan 1995 19:35:15 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05sl@kriton.UUCP>; Tue, 31 Jan 95 19:29:58 EET Date: Tue, 31 Jan 95 19:29:58 EET Message-Id: <9501311729.05sl@kriton.UUCP> In-Reply-To: (from Paul Ney ) (at Tue, 31 Jan 1995 08:08:36 -0700 (MST)) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT Content-Length: 559 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: pney@RT66.com Cc: amiga-gcc-port@lists.funet.fi Subject: Re: stack size Hi Paul (Paul Ney), in on Jan 31 you wrote: > I thought int => long == 4 bytes. Therefore 64k int's == 256k stack. Am > I wrong in this assumption? You are of course, correct. This makes matters even worse for the original poster :-( -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If heroes don't exist, it is necessary to invent them--good for public morale!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Feb 1 00:57:53 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91213-4>; Wed, 1 Feb 1995 00:53:39 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id af20565; 31 Jan 95 22:43 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA000bg; Tue, 31 Jan 95 14:24:50 GMT Date: Tue, 31 Jan 95 14:24:50 GMT Message-Id: <9501311424.AA000bf@flevel.demon.co.uk> Message-Id: <2022092e.c8321-dev@flevel.demon.co.uk> In-Reply-To: <9501311232.AA01235@GWEU.softlab.de> (from REH@softlab.de) (at Tue, 31 Jan 95 13:39:29 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 3.99) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Re: makefile syntax Hi REH, > Well, to me the great value of GNU on Amiga is to have an environment > that makes Amiga behave like Unix without running Unix on it. If we > start building exceptions into an "Amiga-Version", we loose this > behaviour. As a consequence our developments on Amiga will show strange > errors when ported (back) to Unix. In other words: please leave make > as it is. Yes, I agree. Its no good if makefiles made one system are not useful on another. It would need a change of all systems GNU make to allow spaces which I doubt will be done. Trefor S. From amiga-gcc-port-owner@nic.funet.fi Wed Feb 1 01:46:07 1995 Received: from landmark.net ([155.229.176.1]) by nic.funet.fi with SMTP id <91218-3>; Wed, 1 Feb 1995 01:43:00 +0200 Received: by gandlf (MX V4.1 VAX) id 1; Tue, 31 Jan 1995 18:43:08 EST Sender: streible@landmark.net Date: Tue, 31 Jan 1995 18:42:25 EST From: "Charles L. Streible" Reply-To: streible@landmark.net To: amiga-gcc-port@nic.funet.fi Message-ID: <0098B4C2.DB7EE000.1@gandlf> Subject: Re: makefile syntax Hi everyone, >> Well, to me the great value of GNU on Amiga is to have an environment >> that makes Amiga behave like Unix without running Unix on it. If we >> start building exceptions into an "Amiga-Version", we loose this >> behaviour. As a consequence our developments on Amiga will show strange >> errors when ported (back) to Unix. In other words: please leave make >> as it is. > >Yes, I agree. Its no good if makefiles made one system are not useful on >another. It would need a change of all systems GNU make to allow spaces >which I doubt will be done. ...and of course, even though many folks out there chomp at the bit to tackle grand modifications to some rather big software packages, nobody would consider enhancing a low-profile tool like make now, would they? :-) >From my experience, it's just a matter of course that you're going to have to deal with gotcha's, whether it's finding out that you can't have more than one white space character at the beginning of a command line, or whether you've received a makefile that no longer works as expected. The important thing is for folks (those attached strongly to unix, in this case) to agree upon what is standard and accepted across all platforms. Admittedly, adding exceptions (even those that don't manifest unless specifically invoked) probably would cause an extra instance or two of frustration (like, it'd probably cause me about 5-minutes of grief before I solved the problem, and then I'd be like - "Oh, well I can fix that!"), yet it's exactly those kinds of frustrations that, taken over a period of time, start to turn one off to the idea of developing on a given platform. ...come to think of it, it's lack of flexibility that usually turns me off, rather than finding unexpected quirks in someone else's work. Quirks are growing pains, while lack of flexibility is bad design, IMHO. If I've touched even one soul out there for the better, with my philosophical rantings, then, well, okay, I guess...it won't bust my day if I'm the only one who thinks like this! :-) Hats off to the GNU porting crew! If there's a list of projects waiting for someone to take the gauntlet, please point me to it. I believe in helping, instead of complaining...and I promise I won't put in any un-authorized enhancements! ;-) -- ============================================================================== +-----------------------+ | +-------------------+ | | | T H E | | Charles L. Streible Also try: | | W E A T H E R | | 2600 Cumberland Parkway cls@opera.dragon.com | | C H A N N E L | | Atlanta, GA 30339 U.S.A. cls@dido.opera.dragon.com | +-------------------+ | (404)-801-2195 (Voice) +-----------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Feb 1 03:14:40 1995 Received: from sxpo.fdn.org ([193.55.4.40]) by nic.funet.fi with SMTP id <91228-2>; Wed, 1 Feb 1995 03:12:53 +0200 Received: by sxpo.fdn.org id AA07698 (5.65c8/IDA-1.4.4/FdN-1.0 for lists.funet.fi!amiga-gcc-port); Wed, 1 Feb 1995 02:12:38 +0100 Received: by ramses.fdn.org (V1.17-beta/Amiga) id <0slo@ramses.fdn.org>; Wed, 1 Feb 95 02:02:02 +0200 Message-Id: <022ac600@ramses.fdn.org> Date: 01 Feb 95 02:02:01 +0200 Organization: RAMSES BBS (France:1-45845623/53791199/1200) X-Mailer: AmiGate 1.1a (8.10.94) From: Philippe_Brand@ramses.fdn.org (Philippe Brand) To: amiga-gcc-port@nic.funet.fi Subject: TEST from AmigaGNU conference on Ramses BBS, please ignore Philippe Brand PhB@colombo.telesys-innov.fr, Ramses SysOp. From amiga-gcc-port-owner@nic.funet.fi Wed Feb 1 13:40:14 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91171-1>; Wed, 1 Feb 1995 13:36:01 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 1 Feb 95 12:34 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 1 Feb 95 11:31 MET Message-Id: Subject: makefile syntax To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 1 Feb 1995 11:31:32 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 467 interessting discussion about make syntax, but i still missing the cause WHY there is a difference for and . What is the reason ? (beside the lazy programmer >;) ) walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Feb 1 16:10:20 1995 Received: by nic.funet.fi id <91180-1>; Wed, 1 Feb 1995 16:00:20 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <95Feb1.160020+0200_eet.91180-1+34@nic.funet.fi> Date: Wed, 1 Feb 1995 16:00:11 +0200 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Wed Feb 1 17:21:19 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <91188-2>; Wed, 1 Feb 1995 17:10:09 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA09083; Wed, 1 Feb 95 08:09:51 MST Date: Wed, 1 Feb 1995 08:09:49 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: Walter Harms Cc: amiga gcc-list Subject: Re: makefile syntax In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 1 Feb 1995, Walter Harms wrote: > > > interessting discussion about make syntax, but i > still missing the cause WHY there is a difference > for and . What is the reason ? (beside the > lazy programmer >;) ) It's not really a problem of lazy programmer. I use Matt Dillon's excellent editor DME. I started learning it early in my use of the Amiga. DME defaults to padding white space with spaces rather than with tabs. Not realizing this, I had a period of frustration trying to get GNU make to work when Lattice and Aztec makes had no problem. When I found the problem and corrected it, I realized that Lattice and Aztec were non-standard as they claimed their makes were 'unix-like'. Fortunately, there is a switch in DME to save white space as tabs and that was the simple solution. I see this problem as partial adherence to unix behavior on the part of non-unix suppliers. Those of us who haven't much experience with true unix assume that these other packages behave "just like unix" and have problems when we run into true unix behavior. If those other suppliers would either not claim "unix-like" behavior, or better yet truly adhere to unix standards, there would be no problem. Paul Ney From amiga-gcc-port-owner@nic.funet.fi Wed Feb 1 18:11:06 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91184-3>; Wed, 1 Feb 1995 18:01:05 +0200 Received: by theseas.ntua.gr with UUCP; Wed, 1 Feb 1995 17:59:32 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05sx@kriton.UUCP>; Wed, 1 Feb 95 17:39:44 EET Date: Wed, 1 Feb 95 17:39:44 EET Message-Id: <9502011539.05sx@kriton.UUCP> In-Reply-To: (from Walter Harms ) (at Wed, 1 Feb 1995 11:31:32 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1722 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: Walter.Harms@arbi.informatik.uni-oldenburg.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: makefile syntax Hi Walter (Walter Harms), in on Feb 1 you wrote: > interessting discussion about make syntax, but i > still missing the cause WHY there is a difference > for and . What is the reason ? (beside the > lazy programmer >;) ) This is a deep philosophical question, to which I simply had to find the answer. The first thing to do in these cases is to RTMF (Read The Manual First). According to the SunOS man page, make considers anything not beginning with TAB or # to be an action. Therefore, the following is a valid makefile: a: touch a (The first line begins with a couple of spaces, and the second line begins with a TAB.) If spaces are valid action specifiers, then the above makefile contains no targets. E.g., SAS smake produces the following error with this makefile: SMAKE (line 0): Nothing to make Making spaces equivalent to tabs would break existing UNIX makefiles. I can hear you say: "ok, so fix make to recognize lines containing colons as rules, even if they begin with white space". Consider the line: gnu:bin/gcc foo.c Is it a rule, or is it an action? It could be an action specifying that foo.c should be compiled using gnu:bin/gcc, but it could also be a rule, specifying that gnu depends on bin/gcc and foo.c. Deciding which is the case requires understanding what the line means, which is something far beyond the scope of a program like make. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Are we just running scared, or are we heading for somewhere in particular?" "The answer to both questions is yes!" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Feb 2 00:51:08 1995 Received: from landmark.net ([155.229.176.1]) by nic.funet.fi with SMTP id <91182-4>; Wed, 1 Feb 1995 19:51:10 +0200 Received: by gandlf (MX V4.1 VAX) id 1; Wed, 01 Feb 1995 12:49:47 EST Sender: streible@landmark.net Date: Wed, 01 Feb 1995 12:49:02 EST From: "Charles L. Streible" Reply-To: streible@landmark.net To: amiga-gcc-port@lists.funet.fi Message-ID: <0098B55A.A790F9C0.1@gandlf> Subject: Re: makefile syntax The problems stated below are further compounded by needing to recognize valid MACRO assignments, such as: BINDIR=NetBSD:bin and the like, not to mention possible "extras" like include files, ifdefs, etc. within makefiles. Knowing what little I know about unix utilities, the creators knew more about what they were doing than we might sometimes give them credit for. Kriton writes: >This is a deep philosophical question, to which I simply had to find the >answer. The first thing to do in these cases is to RTMF (Read The >Manual First). According to the SunOS man page, make considers anything >not beginning with TAB or # to be an action. Therefore, the following is >a valid makefile: > > a: > touch a > >(The first line begins with a couple of spaces, and the second line >begins with a TAB.) > >If spaces are valid action specifiers, then the above makefile contains >no targets. E.g., SAS smake produces the following error with this >makefile: > >SMAKE (line 0): Nothing to make > >Making spaces equivalent to tabs would break existing UNIX makefiles. > >I can hear you say: "ok, so fix make to recognize lines containing >colons as rules, even if they begin with white space". Consider the >line: > gnu:bin/gcc foo.c >Is it a rule, or is it an action? It could be an action specifying that >foo.c should be compiled using gnu:bin/gcc, but it could also be a rule, >specifying that gnu depends on bin/gcc and foo.c. Deciding which is the >case requires understanding what the line means, which is something far >beyond the scope of a program like make. -- ============================================================================== +-----------------------+ | +-------------------+ | | | T H E | | Charles L. Streible Also try: | | W E A T H E R | | 2600 Cumberland Parkway cls@opera.dragon.com | | C H A N N E L | | Atlanta, GA 30339 U.S.A. cls@dido.opera.dragon.com | +-------------------+ | (404)-801-2195 (Voice) +-----------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Feb 2 01:08:44 1995 Received: from undergrad.math.uwaterloo.ca ([129.97.204.13]) by nic.funet.fi with SMTP id <91159-3>; Thu, 2 Feb 1995 01:04:26 +0200 Received: from noether.math.uwaterloo.ca ([129.97.204.16]) by undergrad.math.uwaterloo.ca with SMTP id <56865-2>; Wed, 1 Feb 1995 18:03:57 -0500 Date: Wed, 1 Feb 1995 18:03:50 -0500 From: Jeff Shepherd X-Sender: jsshephe@noether.math.uwaterloo.ca To: amiga-gcc-port@nic.funet.fi Subject: Working GDB?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Has anyone successfully compiled a working version of gdb 4.12 with gcc 2.6.3? I have downloaded 3 different sets of diffs and have compiled gdb with each set with no hassles. The problem lies with running executables under gdb. I can load an executable under gdb, list the source, and set breakpoints but when I type 'run' gdb replies: Don't know how to run. See 'help target'. Typing 'help target' gives me no clues. Heres how I compiled gdb. gunzip gdb-4.12.tar.gz tar xvf gdb-4.12.tar makelink gdb-4.12-amiga gdb-4.12 force;make two links so that the diffs will makelink gdb-4.12-fsf gdb-4.12 force ;work with the original source tree gunzip diffs patch ; Thu, 2 Feb 1995 08:29:38 +0200 Received: by eskimo.com (5.65c/1.35) id AA16914; Wed, 1 Feb 1995 22:29:19 -0800 Date: Wed, 1 Feb 1995 22:29:19 -0800 From: thought@eskimo.com (Jesse McClusky) Message-Id: <199502020629.AA16914@eskimo.com> To: amiga-gcc-port@nic.funet.fi Subject: The source of the problem The source of the problem with Makefiles is that the default editor (as well as a few others) translates tabs into spaces. The person who wrote that part of the Amiga's OS should be shot. Why force a translation on people? There is no reason in the Amiga OS for tabs to be replaced with spaces. At least as far as I've seen, which is quite a bit. Comments? Jesse McClusky From amiga-gcc-port-owner@nic.funet.fi Thu Feb 2 08:42:22 1995 Received: from eskimo.com ([204.122.16.13]) by nic.funet.fi with SMTP id <91169-1>; Thu, 2 Feb 1995 08:39:38 +0200 Received: by eskimo.com (5.65c/1.35) id AA17845; Wed, 1 Feb 1995 22:39:23 -0800 Date: Wed, 1 Feb 1995 22:39:23 -0800 From: thought@eskimo.com (Jesse McClusky) Message-Id: <199502020639.AA17845@eskimo.com> To: amiga-gcc-port@nic.funet.fi Subject: Question I can't seem to find a port of straight yacc anywhere. Anyone know where I could get one? Thanks.... Jesse McClusky From amiga-gcc-port-owner@nic.funet.fi Thu Feb 2 09:53:54 1995 Received: by nic.funet.fi id <91166-4>; Thu, 2 Feb 1995 09:51:54 +0200 From: Leonard Norrgard To: jsshephe@uwaterloo.ca CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Jeff Shepherd on Wed, 1 Feb 1995 18:03:50 -0500) Subject: Re: Working GDB?? Message-Id: <95Feb2.095154+0200_eet.91166-4+28@nic.funet.fi> Date: Thu, 2 Feb 1995 09:51:51 +0200 > Has anyone successfully compiled a working version of gdb 4.12 with gcc > 2.6.3? I have downloaded 3 different sets of diffs and have compiled gdb Your problem is that the C library still misses a crucial function needed to run GDB, namely ptrace(2). It is supposedly being written somewhere, no sources to alpha/beta versions of ptrace() seen yet. Ixemul.library has a stub for ptrace() that always return an error. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Thu Feb 2 17:36:06 1995 Received: from aut.alcatel.at ([146.112.129.1]) by nic.funet.fi with SMTP id <91150-1>; Thu, 2 Feb 1995 17:24:55 +0200 Received: from dnimaild by aut.alcatel.at (4.1/SMI-4.1/AAA-1.29/main) id AA14884; Thu, 2 Feb 95 16:24:39 +0100 Date: Thu, 2 Feb 95 16:24:15 +0100 From: DPL_BETAS@DVAX.dnet.aut.alcatel.at Message-Id: <9502021524.AA14884@aut.alcatel.at> To: amiga-gcc-port@lists.funet.fi Subject: Received: from DVAX.DECnet by dnisun (dnimaild-3.0); Thu, 2 Feb 95 16:24:15 +0100 unsub amiga-gcc-port From amiga-gcc-port-owner@nic.funet.fi Thu Feb 2 17:50:37 1995 Received: from romeo.ic.ac.uk ([155.198.5.9]) by nic.funet.fi with ESMTP id <91185-1>; Thu, 2 Feb 1995 17:48:38 +0200 Received: from eecfsag2.ee.ic.ac.uk by romeo.ic.ac.uk with SMTP (PP); Thu, 2 Feb 1995 15:47:33 +0000 Received: from eecsh.ee.ic.ac.uk (ohm) by eecfsag2.ee.ic.ac.uk (4.1/4.0) id AA24047; Thu, 2 Feb 95 15:43:11 GMT From: s.edgley@ic.ac.uk Date: Thu, 2 Feb 95 15:43:10 GMT Message-Id: <11068.9502021543@eecsh.ee.ic.ac.uk> To: amiga-gcc-port@lists.funet.fi unsub amiga-gcc-port From amiga-gcc-port-owner@nic.funet.fi Fri Feb 3 08:08:02 1995 Received: from pophh.Hamburg.pop.de ([193.98.9.7]) by nic.funet.fi with SMTP id <91150-3>; Fri, 3 Feb 1995 08:04:55 +0200 Received: from assi.s-link.de by pophh.Hamburg.pop.de (uucp) id m0raGtT-0001RhC; Fri, 3 Feb 95 06:49 MEZ; (Smail3.1.28.1) Received: by assi.s-link.de with smail (/\==/\ Smail3.1.28.1 #28.1) id ; Fri, 3 Feb 95 06:29 MET To: amiga-gcc-port@nic.funet.fi Message-Id: From: s.zeiger@tecmania.mcnet.de (Stefan Zeiger) Path: multicom.mcnet.de!tecmania.mcnet.de!s.zeiger Organization: WWSP - Wizard Works Software Productions Subject: Re: Aminet and the GPL Date: Tue, 31 Jan 1995 09:54:45 +0100 Followup-To: sender X-Mailer: MicroDot 1.8 [REGISTERED 00030c] References: <199501300921.KAA12176@colombo.telesys-innov.fr> X-Gateway: ZCONNECT UO assi.s-link.de [UNIX/Connect v0.55] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-TELEFON: V+49-6188-2525 X-Z-POST: Seligenstaedter Weg 24, D-63796 Kahl X-Z-VIA: 19950202002518W+1@multicom.mcnet.de Lines: 11 phb@colombo.telesys-innov.fr (Philippe BRAND) writes: PB> It would be really no problem uploading sources to Aminet but due to sizes PB> wouldn't it be better to put sources on another system and include a note in PB> gcc dist pointing to this site (ftp.funet.fi for example) ? Unfortunately this would be of no help to the people who get everything on the AmiNet CDROMs due to lack of ftp access. -- Stefan Zeiger s.zeiger@tecmania.{mcnet.de|tms.mc.org} From amiga-gcc-port-owner@nic.funet.fi Fri Feb 3 08:28:23 1995 Received: from eskimo.com ([204.122.16.13]) by nic.funet.fi with SMTP id <91159-3>; Fri, 3 Feb 1995 08:25:20 +0200 Received: by eskimo.com (5.65c/1.35) id AA12117; Thu, 2 Feb 1995 22:25:15 -0800 Date: Thu, 2 Feb 1995 22:25:15 -0800 From: thought@eskimo.com (Jesse McClusky) Message-Id: <199502030625.AA12117@eskimo.com> To: amiga-gcc-port@nic.funet.fi Subject: Request I am making a humble request, and ask that people please help... (: First off, you need at least 7 megs ram. You also need at least 10 or 12 megs of hard disk space. If you qualify, ftp to ftp.tu-bs.de and cd /pub/games/lpmud switch to bin mode and get driver3.2.1@79.tar.gz download it, untar/gzip it in it's own directory, then cd to that directory. set the stack to 91072 or higher, and enter the 'sh' Type ./configure It takes awhile, and reports on where it currently is. Please let me know if you figure out the problems (they come near the end) because this script runs on nearly all known unix systems without a hitch. Oh, you also need byacc and egrep (not included with the GNU distribution) It takes about 15 minutes to run on a A2000 with a measley 7.14 mhz 68000 processor in it. The errors I get are: libc.h not found and your choice of: alloca failed or: cannot fork I always reboot right before running it, and close all commodities/etc I can before doing an 'avail flush' and running it. I know I get down to about 120k of fastmem and 120k of chip mem before that last error happens *sigh*. And running it with a stack of less than 91k causes an 'Abort!' requestor about 5 minutes into the script, or crashes. I REALLY don't want to get more memory just yet, as I'm saving up for an accelerator ('030 or higher) and the SupraRAM card for the 2000 doesn't work very will with more than 6 megs on it and an accelerator is in the system. (I've been told this by several people with different accelerators) Anyway, if someone could help it'd be GREATLY appreciated. thanks. JEsse McClusky From amiga-gcc-port-owner@nic.funet.fi Fri Feb 3 14:40:36 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91182-1>; Fri, 3 Feb 1995 14:28:32 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id aa10386; 3 Feb 95 12:02 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA000qj; Fri, 3 Feb 95 10:40:17 GMT Date: Fri, 3 Feb 95 10:40:17 GMT Message-Id: <9502031040.AA000qi@flevel.demon.co.uk> Message-Id: <2025c90e.ea601-dev@flevel.demon.co.uk> In-Reply-To: <199502030625.AA12117@eskimo.com> (from Jesse McClusky ) (at Thu, 2 Feb 1995 22:25:15 -0800) X-Mailer: //\\miga Electronic Mail (AmiElm 3.99) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: thought@eskimo.com Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Request Hi Jesse, > libc.h not found Ive looked through the gcc includes, there isn't a libc.h. Have you tried 'configure amigados' I suppose you could try a blank libc.h or get one from a UN*X system. > cannot fork This is usually caused due to lack of memory. Configure scripts run a lot of tasks (Due to pipes I think) and each one uses your 91K of stack, this does mounts up and when there is not enough memory left for another stack a cannot fork error happens. You could desperatley try:- Closing workbench. Setting your screenmode to lowres 2 color. Cutting down the buffers on your hard drive. Dismounting dfx: Or if your have GCC2.6.3 you could set your GCCSTACK to a good value and then drop your shell stack down. > alloca failed This sounds like a memory problem, I could be due to:- a) Too little stack b) Not enough memory If I get a chance I'll try compiling it myself. Good Luck Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Feb 3 16:38:21 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <91226-4>; Fri, 3 Feb 1995 16:30:16 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA24072; Fri, 3 Feb 95 07:31:28 MST Date: Fri, 3 Feb 1995 07:31:28 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: amiga-gcc-port@lists.funet.fi Subject: possible compiler bug (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello all: I ran into a strange situation with g++. I am using gcc V2.6.3 on an A2000 with A2620, 6mb fast ram, 1mb chip ram, Seagate 157N (46 MB), Quantum P40 (40 MB). I tried to recompile a program which successfully compiled and ran under V2.6.0. The results and the program are included below. If anyone has any idea of what is going on, please let me know. g++ -v -c -m68020 -m68881 -O2 -I ../Demon_Commons -idirafter gnu:os-include -c input.cc -o input.o gcc -v -c -m68020 -m68881 -O2 -I ../Demon_Commons -idirafter gnu:os-include -c input.cc -o input.o Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c++ -v -I ../Demon_Commons -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ - D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -D__OPTIMIZE__ -D__HAVE_68881__ -Dmc68020 -idirafter gnu:os-include input.cc DH1:Junk/cc241944.ii GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: ../Demon_Commons /gnu/lib/g++-include /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include gnu:os-include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1plus DH1:Junk/cc241944.ii -quiet -dumpbase input.cc -m68020 -m68881 -O2 -version -o DH1:Junk/cc241944.s GNU C++ version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3 snapshot 941209. input.cc: In function `void input()': input.cc:29: Internal compiler error. input.cc:29: Please submit a full bug report to `bug-g++@prep.ai.mit.edu'. make: *** [input.o] Error 1 *************** Program starts here ******************* #include "declares.h" #include "demon_structs.h" #include "message.h" #include "units.h" extern double xd, x, xact, xerr, xerest, yd, y, zd, z, yact, yerr, yerest; extern double c, c2, t0, errprm; // reads parameters associated with the d. e. calculations. void input () { char line[101]; // print d. e. parameter heading. if (!units.out) { printf ("NULL files are being used.\n"); closfl (); exit (0); } heads (); fprintf (units.out, "\n%s D. E. Parameters %s\n", stars, stars); // skip comments in the input file. // read d. e. parameters. line = skipcm (units.in, line); sscanf (line, "%lf %lf %lf", &c, &t0, &errprm); // print d. e. initial conditions. fprintf (units.out, "\n\n c: %12g\n", c); fprintf (units.out, "\n\n t0: %12g\n", t0); fprintf (units.out, "\n\n err: %12g\n", errprm); } From amiga-gcc-port-owner@nic.funet.fi Fri Feb 3 19:30:54 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91188-1>; Fri, 3 Feb 1995 19:26:16 +0200 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA25124 (5.65c-6/7.3w-FAU); Fri, 3 Feb 1995 17:05:52 +0100 Received: from pctc.chemie.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA16687 (5.65c-6/7.3m-FAU); Fri, 3 Feb 1995 17:05:49 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA19724; Fri, 3 Feb 1995 17:03:58 +0100 Date: Fri, 3 Feb 1995 17:03:58 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9502031603.AA19724@pctc.chemie.uni-erlangen.de> To: pney@RT66.com Cc: amiga-gcc-port@lists.funet.fi In-Reply-To: (message from Paul Ney on Fri, 3 Feb 1995 07:31:28 -0700 (MST)) Subject: Re: possible compiler bug (fwd) Hello, Make a quit check with a stack as large as possible. g++2.6.3 may use a larger stack. This is one of my experiences with g++2.6.3 Nice weekend to all -- Thomas Walter walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Sat Feb 4 03:53:17 1995 Received: from gold.tc.umn.edu ([128.101.115.11]) by nic.funet.fi with SMTP id <91163-1>; Sat, 4 Feb 1995 03:49:48 +0200 Received: by gold.tc.umn.edu; Fri, 3 Feb 95 19:48:12 -0500 Date: Fri, 3 Feb 1995 19:48:11 -0600 (CST) From: Subject: unsubscribe To: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe subscribe tom.thai@dream.future.net From amiga-gcc-port-owner@nic.funet.fi Sat Feb 4 16:02:13 1995 Received: from deep.rsoft.bc.ca ([204.174.16.4]) by nic.funet.fi with SMTP id <91164-4>; Sat, 4 Feb 1995 16:00:29 +0200 Received: from mindlink.bc.ca by deep.rsoft.bc.ca with smtp (Smail3.1.28.1 #5) id m0rakxo-000BoPC; Sat, 4 Feb 95 05:55 PST Message-Id: Date: Sat, 04 Feb 95 05:52:08 -0800 To: amiga-gcc-port@nic.funet.fi Subject: Cross-development From: Colin_Fox@mindlink.bc.ca (Colin Fox) I have a couple of cross development questions. First, does anyone know how I can compile files on my Amiga to run on a PC? I know that this question has come up before, but regretuflly, I don't have those messages. Next, can I compile stuff on my Amiga that can run on an R3000? And lastly, can all three of these setups (Amiga->Amiga, Amiga->PC, Amiga->R3000) exist at the same time? Thanks for any replies. -- ------ Colin Fox ------ Live Wire Designs ---------------------- ------ Colin_Fox@mindlink.bc.ca -------------------------------- From amiga-gcc-port-owner@nic.funet.fi Sat Feb 4 17:38:34 1995 Received: from post.demon.co.uk ([158.152.1.72]) by nic.funet.fi with SMTP id <91172-1>; Sat, 4 Feb 1995 17:37:00 +0200 Received: from iceman.demon.co.uk by post.demon.co.uk id ac26072; 4 Feb 95 15:36 GMT Received: by iceman.demon.co.uk (V1.16/Amiga) id AA00025; Sat, 4 Feb 95 15:36:55 GMT Date: Sat, 4 Feb 95 15:36:55 GMT Message-Id: <9502041536.AA00024@iceman.demon.co.uk> Organization: wit's end with AmiTCP :( X-MailViewer: Mail 1.15 From: Graham Crowder To: amiga-gcc-port@nic.funet.fi Subject: Curses availability? Hi. Am trying to port UNIX apps (including Lynx WWW browser) to AmiTCP on the Amiga. I have GCC 260 but am about to reinstall with GCC263. I note that GNU:include has a curses.h, but I cannot find a matching libcurses.a although I have a libtermcap.a. I am trying to work with a different Curses package (curses210.lha) but that and its include file are designed for SAS C or something similar. So, sorry if it's a FAQ, but is there a stable Curses implementation available specifically with Amiga GCC in mind? TIA Graham Crowder -- Graham Crowder: grahamc@iceman.demon.co.uk: grahamc@kmbcopps.demon.co.uk Amiga A1200/190MB HD/GVP A1230Turbo+SerII/68EC030/68882/10MB RAM/AmiTCP "Any sufficiently advanced technology is indistinguishable from magic" --- Arthur C Clarke From amiga-gcc-port-owner@nic.funet.fi Sat Feb 4 17:46:25 1995 Received: from europe.std.com ([192.74.137.10]) by nic.funet.fi with SMTP id <91178-1>; Sat, 4 Feb 1995 17:45:20 +0200 Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0) id KAB01862; Sat, 4 Feb 1995 10:45:13 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA11993; Sat, 4 Feb 1995 10:45:44 -0500 Date: Sat, 4 Feb 1995 10:45:44 +0001 (EST) From: "Thomas E. Janzen" Subject: gcc 263 (fwd) To: Amiga GCC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi. Earlier I mentioned the corrupt inclib archive. I should also mention that the file GNU:s/Restorelinks and restorelink have problems. The use of arguments in the MAKELINK utility is backwards, the AmigaDOS 2 manual I have says that the phony name is first, the real file second (makelink phony realfile). Also, restorelinks invokes restorelink, which doesn't work under CLI (and it's shown under CLI). The execute command must be used. Also the arguments to RestoreLinks are set up as all required, so you must use COPY, basically, but that didn't work either. I just hard-coded a version and then out of fear I typed in the commands one at a time: cd mdh5:gnu/bin makelink gzip gunzip makelink zcat gzip makelink zcmp zdiff makelink fgrep grep makelink egrep grep makelink d dir makelink v dir makelink vdir dir makelink flex++ flex makelink ginstall install makelink ksh sh makelink gawk awk makelink [ test cd mdh5:gnu/man/man1 makelink gunzip.1 gzip.1 makelink zcat.1 gzip.1 makelink zcmp.1 zdiff.1 The instructions in readme-2.6.3 also use the "sh" command, which doesn't work if you havn't set up a path to that shell yet. Also, the instructions in readme-2.6.3 never mention gcc263-inclib.lha. Also, the instructions in readme-2.6.3 never mention de-archiving gcc263-doc.lha in the right place (above GNU:). But you must dearchive gcc263-doc.lha in order to get s/user-startup and s/restorelinks. Now, since you find out to make gnu directory by reading the document in gcc263-doc, you must have de-archived gcc263-doc in the wrong place. Therefore, gcc263-doc must be de-archived once to get the directions and again to put its files in the right place. Thanks very much for working on this. All I did was write little programs like AlgoRhythms 3.0 and SMUSMIDI. I hope that I can find an uncorrupted inclib file. Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio From amiga-gcc-port-owner@nic.funet.fi Sat Feb 4 17:48:12 1995 Received: from europe.std.com ([192.74.137.10]) by nic.funet.fi with SMTP id <91159-3>; Sat, 4 Feb 1995 17:45:16 +0200 Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0) id KAA01831; Sat, 4 Feb 1995 10:44:53 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA11867; Sat, 4 Feb 1995 10:45:24 -0500 Date: Sat, 4 Feb 1995 10:45:24 +0001 (EST) From: "Thomas E. Janzen" Subject: gcc for amiga (fwd) To: Amiga GCC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII hi. I have downloaded gcc263 for the Amiga from aminet on wuarchive wustl. The file gcc263-inclib.lha is corrupt. I tried twice. I guess I should go find the wuarchive mirrors. Thanks Tom Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio From amiga-gcc-port-owner@nic.funet.fi Sat Feb 4 18:49:45 1995 Received: from head-cfa.harvard.edu ([128.103.42.3]) by nic.funet.fi with SMTP id <91180-1>; Sat, 4 Feb 1995 18:48:30 +0200 Received: from pelf.harvard.edu by head-cfa.harvard.edu (4.1/SMI-4.0) id AA12969; Sat, 4 Feb 95 11:48:24 EST Received: by pelf.harvard.edu (4.1/SMI-4.1) id AA05710; Sat, 4 Feb 95 11:48:23 EST Date: Sat, 4 Feb 95 11:48:23 EST From: dj@pelf.harvard.edu (Diab Jerius) Message-Id: <9502041648.AA05710@pelf.harvard.edu> To: amiga-gcc-port@lists.funet.fi Subject: ANSI libraries for amiga gcc (Let me begin by noting that this is a whine, not a flame!) Are there plans for an ANSI compliant set of libraries for inclusion in the Amiga gcc distribution? The current libraries (both ixemul and libnix) have at least one major deficiency (strtod is implemented, but is far from a full ANSI implementation), and possibly others that I haven't yet come across. The code base for the current set of libraries is of rather mixed heritage: there's some early BSD stuff in there, while strtod, in particular, seems to be from gawk, rather than glibc. Is there some reason why glibc isn't used? (Or NetBSD's libc?) Or, hopefully, is there a port underway? I'm willing to help along with what I know about (provided I can scrounge up some disk space). Thanks! Diab From amiga-gcc-port-owner@nic.funet.fi Sat Feb 4 20:43:20 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91181-2>; Sat, 4 Feb 1995 20:41:12 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rapTx-0004naC; Sat, 4 Feb 95 13:45 EST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Curses availability? To: grahamc@iceman.demon.co.uk (Graham Crowder) Date: Sat, 4 Feb 1995 11:45:16 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9502041536.AA00024@iceman.demon.co.uk> from "Graham Crowder" at Feb 4, 95 03:36:55 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1489 > Hi. Am trying to port UNIX apps (including Lynx WWW browser) to AmiTCP > on the Amiga. I have GCC 260 but am about to reinstall with GCC263. > I note that GNU:include has a curses.h, but I cannot find a matching > libcurses.a although I have a libtermcap.a. I am trying to work with > a different Curses package (curses210.lha) but that and its include > file are designed for SAS C or something similar. > > So, sorry if it's a FAQ, but is there a stable Curses implementation > available specifically with Amiga GCC in mind? I did a quick port of BSD curses that will be on the FreshFish Vol 8 CD. It was used to successfully port a couple other "curses using" unix applications with no changes. I've put the archives in pub/amiga/gnu on ftp.amigalib.com: -r-------- 1 ftp system 28694 Feb 4 04:23 libcurses-8.3-bin.lha -r-------- 1 ftp system 797 Feb 4 04:23 libcurses-8.3-bin.lha.pi -r-------- 1 ftp system 27361 Feb 4 04:23 libcurses-8.3-diffs.lha -r-------- 1 ftp system 797 Feb 4 04:23 libcurses-8.3-diffs.lha.pi -r-------- 1 ftp system 144985 Feb 4 04:23 libcurses-8.3-src.lha -r-------- 1 ftp system 797 Feb 4 04:23 libcurses-8.3-src.lha.pi -r-------- 1 ftp system 133066 Feb 4 04:23 libcurses-8.3.lha -r-------- 1 ftp system 797 Feb 4 04:23 libcurses-8.3.lha.pi The libcurses-8.3-src.lha archive is the amiga port source and the libcurses-8.3.lha archive is the original BSD source. -Fred From amiga-gcc-port-owner@nic.funet.fi Sun Feb 5 00:37:39 1995 Received: from europe.std.com ([192.74.137.10]) by nic.funet.fi with SMTP id <91184-3>; Sun, 5 Feb 1995 00:34:20 +0200 Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0) id RAA03851; Sat, 4 Feb 1995 17:34:06 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA02389; Sat, 4 Feb 1995 17:34:37 -0500 Date: Sat, 4 Feb 1995 17:34:37 +0001 (EST) From: "Thomas E. Janzen" Subject: GCC 263 archives To: Amiga GCC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi. I have everything now. I want to thank everyone's help. The archive is not corrupted, it is in a format only lha can decode. I had used lz -x -a -m x on all of the other archives for an 020 installation, and it worked. So I was surprised that the gcc263-inclib.lha archive wouldn't unpack with lz. So I went and got lha for the first time, installed it, and used it. I just stopped typing this message to edit compile and link a "hi" program. It worked exactly link it does on *ix or LynxOS. Thanks a lot! I now have a home compiler better than the one at work (gcc 1.42 at work). Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio From amiga-gcc-port-owner@nic.funet.fi Sun Feb 5 23:32:59 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91170-2>; Sun, 5 Feb 1995 23:30:07 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Sun, 5 Feb 95 22:29 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Sun, 5 Feb 95 22:26 MET Message-Id: Subject: Cross-development To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Sun, 5 Feb 1995 22:26:29 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 538 hi philip, there where some questions about cross-devlopment from/to other platforms. it seems to me, someone should store a file HOWTO makefile. (looks like that make ppl are interessted or ?) Someone with time and patience to do that ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Mon Feb 6 12:05:25 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91182-1>; Mon, 6 Feb 1995 12:02:31 +0200 Received: by colombo.telesys-innov.fr; Mon, 6 Feb 1995 10:59:44 +0100 From: Philippe BRAND Message-Id: <199502060959.KAA01831@colombo.telesys-innov.fr> Subject: Re: Cross-development To: Colin_Fox@mindlink.bc.ca (Colin Fox) Date: Mon, 6 Feb 1995 10:59:42 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Colin Fox" at Feb 4, 95 05:52:08 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1962 Colin Fox writes: > I have a couple of cross development questions. First, does anyone know how > I can compile files on my Amiga to run on a PC? I know that this question > has come up before, but regretuflly, I don't have those messages. > Next, can I compile stuff on my Amiga that can run on an R3000? > And lastly, can all three of these setups (Amiga->Amiga, Amiga->PC, > Amiga->R3000) exist at the same time? How to generate a cross-compiler, AmigaDOS side: ------------------------------------------------ - Get gcc-2.6.3.tar.gz from ftp.gnu.ai.mit.edu or mirror site - Get ftp.telesys-innov.fr:/pub/amigados-gnu/gcc-2.6.3-amiga.diffs file >From CLI: CLI> sh # zcat gcc-2.6.3.tar.gz | tar xvf - # cd gcc-2.6.3 # zcat ../gcc-2.6.3-amiga.diffs | patch -p1 # ./configure --host=amigados --target=CPU-COMPANY-SYSTEM # make When compilers are built, all you have to do is installing it using make install, and to grab other architecture's libraries (libc.a, etc...), and headers. More infos: See GCC AmigaGuide documentation, look for "Cross-Compiling". How to generate a cross-compiler, Other architecture side: ---------------------------------------------------------- - Get gcc-2.6.3.tar.gz from ftp.gnu.ai.mit.edu or mirror site - Get ftp.telesys-innov.fr:/pub/amigados-gnu/gcc-2.6.3-amiga.diffs file >From CLI: CLI> sh # zcat gcc-2.6.3.tar.gz | tar xvf - # cd gcc-2.6.3 # zcat ../gcc-2.6.3-amiga.diffs | patch -p1 # ./configure --target=amigados (host should be determined by configure itself) # make When compilers are built, all you have to do is installing it using make install, and to grab AmigaDOS GCC libraries (libc.a, etc...), and headers. More infos: See GCC AmigaGuide documentation, look for "Cross-Compiling". A working example of a cross-compiler running on sunos4.1.3 can be found in ftp.telesys-innov.fr:/pub/amigados-gnu/gcc-cross/.... -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Feb 6 12:09:44 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91179-1>; Mon, 6 Feb 1995 12:06:53 +0200 Received: by colombo.telesys-innov.fr; Mon, 6 Feb 1995 11:03:41 +0100 From: Philippe BRAND Message-Id: <199502061003.LAA02062@colombo.telesys-innov.fr> Subject: Binutils 2.5.1 for AMIGA (fwd) To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 6 Feb 1995 11:03:40 +0100 (MEZ) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 877 The files binutils_bin.lha binutils_lib.lha binutils_man.lha Are available on ftp.telesys-innov.fr,:/pub/amigados-gnu/beta and soon on nic.funet.fi:/pub/amiga/gnu/gcc/beta are the first results from porting binutils-2.5.1 to the AMIGA. - The bin archive includes executables for all programs from binutils 2.5.1, excluding gas. - The lib archive contains libbfd.a libiberty.a libopcodes.a - The man archive contains the man pages and .info (.texi) files for the programs in the bin archive. WARNING: The programs are not tested extensively, in fact all but the linker and objdump, objcopy are nearly untested. The purpose of the archives is that they should be tested by someone, who has more time than me. Comments, bugs, etc. to: isthesin@techfak.uni-bielefeld.de -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Feb 6 12:50:51 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91151-1>; Mon, 6 Feb 1995 12:46:24 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 6 Feb 95 11:45 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 6 Feb 95 11:36 MET Message-Id: Subject: Re: Binutils 2.5.1 To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Mon, 6 Feb 1995 11:36:45 +0100 (MET) From: Walter Harms Cc: amiga-gcc-port@lists.funet.fi (amiga gcc-list) In-Reply-To: <199502061003.LAA02062@colombo.telesys-innov.fr> from "Philippe BRAND" at Feb 6, 95 11:03:40 am X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1187 > > The files > binutils_bin.lha > binutils_lib.lha > binutils_man.lha > > Are available on ftp.telesys-innov.fr,:/pub/amigados-gnu/beta and soon on > nic.funet.fi:/pub/amiga/gnu/gcc/beta > > are the first results from porting binutils-2.5.1 to the AMIGA. > - The bin archive includes executables for all programs from binutils 2.5.1, > excluding gas. > - The lib archive contains libbfd.a libiberty.a libopcodes.a > - The man archive contains the man pages and .info (.texi) files for the > programs in the bin archive. > > WARNING: > > The programs are not tested extensively, in fact all but the linker and > objdump, objcopy are nearly untested. > > The purpose of the archives is that they should be tested by someone, who has > more time than me. > > Comments, bugs, etc. to: > isthesin@techfak.uni-bielefeld.de please, can you say what changed since last time ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Mon Feb 6 13:01:16 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91180-2>; Mon, 6 Feb 1995 12:56:39 +0200 Received: by colombo.telesys-innov.fr; Mon, 6 Feb 1995 11:52:40 +0100 From: Philippe BRAND Message-Id: <199502061052.LAA02215@colombo.telesys-innov.fr> Subject: Re: Binutils 2.5.1 To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Mon, 6 Feb 1995 11:52:39 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Walter Harms" at Feb 6, 95 11:36:45 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 199 Walter Harms writes: > please, can you say what changed since last time ? Handling of AmigaDOS hunk format. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Feb 6 16:28:31 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91163-3>; Mon, 6 Feb 1995 16:21:33 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id aa11401; 6 Feb 95 14:05 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA0019s; Mon, 6 Feb 95 11:31:13 GMT Date: Mon, 6 Feb 95 11:31:13 GMT Message-Id: <9502061131.AA0019r@flevel.demon.co.uk> Message-Id: <2029c97e.ef422-dev@flevel.demon.co.uk> In-Reply-To: <199502061003.LAA02062@colombo.telesys-innov.fr> (from Philippe BRAND ) (at Mon, 6 Feb 1995 11:03:40 +0100 (MEZ)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Compling Octave 1.1.0 Hi, Ive managed, after a lot of effort, to compile octave :-) However, the executable is just over 16MB :-( It seems to load with 20MB of VMM :-) However, it reports: Octave: Error -1 And then quits :-((((((( Aaaaahhhhhh The question is, what is error -1 and why does it happen? BTW - Tip for compiling memory hungry programs:- 1) make -n >compile_bat 2) flush 3) sh compile_bat If you get any compile errors, fix them and go back to step 1. This saves quite a bit of memory and the compiling seems to be faster. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Feb 6 16:49:04 1995 Received: from jupiter.pt.hk-r.se ([194.47.132.2]) by nic.funet.fi with ESMTP id <91183-4>; Mon, 6 Feb 1995 16:41:27 +0200 Received: from iguanodon.pt.hk-r.se (iguanodon.pt.hk-r.se [194.47.133.20]) by jupiter.pt.hk-r.se (8.6.9/8.6.9) with ESMTP id PAA19963 for ; Mon, 6 Feb 1995 15:38:53 +0100 From: EDIN MUJKANOVIC Received: (pt94emu@localhost) by iguanodon.pt.hk-r.se (8.6.9/8.6.9) id PAA13165 for amiga-gcc-port@nic.funet.fi; Mon, 6 Feb 1995 15:38:50 +0100 Date: Mon, 6 Feb 1995 15:38:50 +0100 Message-Id: <199502061438.PAA13165@iguanodon.pt.hk-r.se> To: amiga-gcc-port@nic.funet.fi Subject: unsubscribe unsubscribe From amiga-gcc-port-owner@nic.funet.fi Mon Feb 6 17:26:07 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91187-3>; Mon, 6 Feb 1995 17:20:43 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA19256 (5.65c-6/7.3w-FAU); Mon, 6 Feb 1995 16:19:56 +0100 Received: from faui8s1 by faui80.informatik.uni-erlangen.de; id AA05187 (5.x/7.3m-FAU); Mon, 6 Feb 1995 16:19:53 +0100 From: Tobias Ruland Message-Id: <9502061519.AA05187@faui80.informatik.uni-erlangen.de> Date: Mon, 6 Feb 1995 16:19:49 +0100 To: amiga-gcc-port@lists.funet.fi Subject: another bug high all am i telling news if i tell you that the optimizer of amiga-gcc2.6.3 does not work reliably? ive written a program that brings up a message "start of free block corrupt" when compiled using optimizer and works very fine without any optimization. c u tobias From amiga-gcc-port-owner@nic.funet.fi Mon Feb 6 17:55:08 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <91151-3>; Mon, 6 Feb 1995 17:46:11 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.6.9/8.6.9) id QAA29728; Mon, 6 Feb 1995 16:44:54 +0100 Date: Mon, 6 Feb 1995 16:44:54 +0100 From: Ignatios Souvatzis Message-Id: <199502061544.QAA29728@theory.cs.uni-bonn.de> To: tsruland@faui80.informatik.uni-erlangen.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: Tobias Ruland's message of Mon, 6 Feb 1995 16:19:49 +0100 <9502061519.AA05187@faui80.informatik.uni-erlangen.de> Subject: another bug X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a; Mon, 6 Feb 1995 17:54:30 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Mon, 6 Feb 1995 16:54:00 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA00853; Mon, 6 Feb 95 16:53:57 +0100 Date: Mon, 6 Feb 95 16:53:57 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502061553.AA00853@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA20082; Mon, 6 Feb 95 16:53:54 +0100 To: Tobias Ruland Cc: amiga-gcc-port@lists.funet.fi Subject: another bug In-Reply-To: <9502061519.AA05187@faui80.informatik.uni-erlangen.de> References: <9502061519.AA05187@faui80.informatik.uni-erlangen.de> Tobias Ruland writes: > "start of free block corrupt" when compiled using optimizer > and works very fine without any optimization. I got requesters like this from the one or the other old version of GCC (1.38/39/40,2.3.3,2.5.x). The solution was either to increase the stack (if your stack monitoring tool showed an overflow) or to try it again with the next version of GCC... Now if you have a small but reproducible example, some people might want to look at it. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon Feb 6 18:30:45 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91191-3>; Mon, 6 Feb 1995 18:21:33 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rbVxG-0004ncC; Mon, 6 Feb 95 11:06 EST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: another bug To: tsruland@faui80.informatik.uni-erlangen.de (Tobias Ruland) Date: Mon, 6 Feb 1995 09:06:22 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9502061519.AA05187@faui80.informatik.uni-erlangen.de> from "Tobias Ruland" at Feb 6, 95 04:19:49 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 871 > am i telling news if i tell you that the optimizer of amiga-gcc2.6.3 > does not work reliably? ive written a program that brings up a message > "start of free block corrupt" when compiled using optimizer > and works very fine without any optimization. In and of itself, this doesn't prove the optimization is broken. Your program could have a bug that is causing it to overwrite memory that it shouldn't. Without optimization you could be just hitting memory that is not important, but with optimization you hit a different piece of memory that is important. I've compiled my entire GNU tree on the FreshFish Vol 8 CD with optimization, including the compiler, ixemul.library, etc, and not seen any problems except in the GNU ada compiler (which is written in ada, so the bug is in the ada compiler). Recompiling ada without optimization fixed the problem. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Feb 6 19:09:51 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91168-3>; Mon, 6 Feb 1995 19:06:50 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rbX0p-0004nYC; Mon, 6 Feb 95 10:14 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: another bug To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Mon, 6 Feb 1995 10:14:07 -0700 (MST) Cc: tsruland@faui80.informatik.uni-erlangen.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <9502061553.AA00853@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Feb 6, 95 04:53:57 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 839 > Tobias Ruland writes: > > "start of free block corrupt" when compiled using optimizer > > and works very fine without any optimization. > > I got requesters like this from the one or the other old version of > GCC (1.38/39/40,2.3.3,2.5.x). The solution was either to increase the > stack (if your stack monitoring tool showed an overflow) or to try it > again with the next version of GCC... Now if you have a small but > reproducible example, some people might want to look at it. It's not exactly the same error, but it is close: gnu:bin/sort ram:junk I.E. feed sort any really big file, like the "FileList" file from the root directory of one of my CD's, and you get a requester that says: "free: end of block corrupt!" I suspect it is either a bug in sort or in the malloc routines in ixemul.library. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Feb 6 20:34:29 1995 Received: by nic.funet.fi id <91192-4>; Mon, 6 Feb 1995 20:32:25 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: gdb: don't know how to run Message-Id: <95Feb6.203225+0200_eet.91192-4+1@nic.funet.fi> Date: Mon, 6 Feb 1995 16:52:37 +0200 Maybe I should clarify a bit on why GDB says "Don't know how to run". It says so, because the diffs as provided do not configure GDB to include a suitable target that knows how to run programs. See the GDB internals info manual on how to add native support for a new platform. The existance of ptrace() doesn't have to do with the "don't know how to run"-message. Now, on the other hand, as amigados native support is being added to gdb, a completely compatible ptrace routine will have to be written, or perhaps more easier, replacement code to the same effect in amigados-nat.c -- vinsci From amiga-gcc-port-owner@nic.funet.fi Tue Feb 7 05:20:59 1995 Received: from partech.com ([192.133.62.31]) by nic.funet.fi with SMTP id <91151-1>; Tue, 7 Feb 1995 05:18:23 +0200 Received: from tomcat.partech.com by partech.com (4.1/SMI-4.1) id AA19900; Mon, 6 Feb 95 22:18:44 EST Received: by tomcat.partech.com (4.0/SMI-4.0) id AA11009; Mon, 6 Feb 95 22:12:30 EST Date: Mon, 6 Feb 95 22:12:30 EST From: joel@partech.com (Joe Locash) Message-Id: <9502070312.AA11009@tomcat.partech.com> To: amiga-gcc-port@nic.funet.fi Subject: GCC and AmiTCP? Hi - I was wondering if anyone is using gcc to compile AmiTCP applications. I am ussing gcc2.6.3 and have the SDK for AmiTCP 3.0b2 and 4.0. The AMiTCP stuff seems to be gcc ready. Before I consider to try to produce a working environment I would like to know if anyone has done this already and might share his or her experience. Thanks. -Joe From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 14:02:40 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91169-1>; Wed, 8 Feb 1995 13:16:11 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA08796; Wed, 8 Feb 1995 11:16:04 GMT From: Peter Ivimey-Cook Message-Id: <27768.199502081114@creda.isltd.insignia.com> Subject: Re: Symbol generation from GCC To: dev@flevel.demon.co.uk Date: Wed, 08 Feb 1995 11:14:57 GMT Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <202b69ba.0-dev@flevel.demon.co.uk>; from "dev@flevel.demon.co.uk" at Feb 7, 95 5:07 pm X-Mailer: elm X-Mailer: Elm [revision: 109.14] > > How do I stop GCC generating debug symbols? I'm not specifiying -g but they > seem to be in the code all the same! > > Thanks, > You need to prevent the global symbols from being stored in the executable. -g adds in the local syms (per proc. ones), line numbers, structure defs etc. I think the -s flag does this. -- Peter Ivimey-Cook Mail Id: peteric@isltd.insignia.com Insignia Solutions, Kingsmead Business Park, London Road, High Wycombe, Buckinghamshire. Telephone: +44-1494-459426 HP11 1JU, U.K. Fax: +44-1494-459720 From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 14:34:03 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91185-2>; Wed, 8 Feb 1995 14:25:39 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 8 Feb 95 13:24 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 8 Feb 95 13:06 MET Message-Id: Subject: Delivery problems To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 8 Feb 1995 13:06:15 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 546 sometimes i get this mail from nic.funet.fi postmaster > Delivery problems with your mail < for example for the last 2 mail to the gcc-list. the strange thing is that i get (my own mail) from gcc (as gcc-list member). some know whats happening there ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 14:59:50 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91148-3>; Wed, 8 Feb 1995 14:49:21 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Wed, 8 Feb 1995 13:47:35 +0100 Received: from bodman.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA07030; Wed, 8 Feb 95 13:47:34 +0100 Date: Wed, 8 Feb 95 13:47:34 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502081247.AA07030@inf-wiss.uni-konstanz.de> Received: by bodman.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA01345; Wed, 8 Feb 95 13:47:34 +0100 To: amiga-gcc-port@nic.funet.fi Subject: ld, BFD and debug (source line) info Hi, with all that work going on with BFD and ld, I wonder if there's a linker that will generate an executable with standard Amiga debugging information, like it's used by SASC and DICE (I don't mean only the function and global symbols but also source line etc.). That would be nice for our debuggers (PowerVisor, BarFly, CodeProbe, ...) Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 15:06:49 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91180-1>; Wed, 8 Feb 1995 14:56:42 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ab21295; 8 Feb 95 12:42 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA001sr; Wed, 8 Feb 95 11:09:56 GMT Date: Wed, 8 Feb 95 11:09:56 GMT Message-Id: <9502081109.AA001sq@flevel.demon.co.uk> Message-Id: <202c677f.3a981-dev@flevel.demon.co.uk> In-Reply-To: (from Walter Harms ) (at Tue, 7 Feb 1995 22:22:48 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: Walter.Harms@arbi.informatik.uni-oldenburg.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ixemul.library and ENV: Hi Walter, > > > maybe someone can write a programm that caches the > env-vars for ixemul ? maybe i a compressed form for > saving space ? (most env are text a simple huffman > should do the trick) Thats a good idea. I don't think compression is needed though, my env: directory (Which is quite large) only runs to 25K. I think the thing that takes the time is actually doing the scanning and reading of the entries. Maybe if ixemu kept it's resultant table in memory. It could then do an add-notify and re-scan any changes. The only problem is I don't know anyone who is willing to write it. I certainly don't have the time :-( Regards, Trefor S. From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 15:48:42 1995 Received: by nic.funet.fi id <91192-2>; Wed, 8 Feb 1995 15:23:05 +0200 From: Leonard Norrgard To: Walter.Harms@arbi.informatik.uni-oldenburg.de CC: amiga-gcc-port@lists.funet.fi In-reply-to: (message from Walter Harms on Wed, 8 Feb 1995 13:06:15 +0100 (MET)) Subject: Re: Delivery problems Message-Id: <95Feb8.152305+0200_eet.91192-2+27@nic.funet.fi> Date: Wed, 8 Feb 1995 15:22:56 +0200 Walter Harms write: > sometimes i get this mail from nic.funet.fi postmaster > > Delivery problems with your mail < > for example for the last 2 mail to the gcc-list. > the strange thing is that i get (my own mail) from > gcc (as gcc-list member). > > some know whats happening there ? Well, for mails yesterday or today, the problem was probably the reorganization of the /pub/amiga/gnu dir on ftp.funet.fi. I moved the archive files of the mailing lists to a new directory (/pub/amiga/gnu/mailing-lists), but forgot to fix the protection on the directory. This probably caused the mailer to hickup for the archive log entry in the mailing list. Sorry about the inconveience. > walter -- vinsci From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 15:57:30 1995 Received: by nic.funet.fi id <91163-3>; Wed, 8 Feb 1995 15:49:15 +0200 From: Leonard Norrgard To: hoehle@inf-wiss.uni-konstanz.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9502081247.AA07030@inf-wiss.uni-konstanz.de> (hoehle@inf-wiss.uni-konstanz.de) Subject: Re: ld, BFD and debug (source line) info Message-Id: <95Feb8.154915+0200_eet.91163-3+35@nic.funet.fi> Date: Wed, 8 Feb 1995 15:49:14 +0200 >with all that work going on with BFD and ld, I wonder if there's a >linker that will generate an executable with standard Amiga debugging >information, like it's used by SASC and DICE (I don't mean only the As you probably know, there is no standard for debugging information on the Amiga. That SAS kept their format a secret didn't really help to promote their format as a standard either. Amiga gcc (and gdb when reading amigados executables) currently use the stabs format (there is a texinfo document describing the format somewhere). There are no plans to change this as far as I have heard. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 16:30:28 1995 Received: by nic.funet.fi id <91188-4>; Wed, 8 Feb 1995 16:19:48 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: debugging formats, ixemul trap handler Message-Id: <95Feb8.161948+0200_eet.91188-4+28@nic.funet.fi> Date: Wed, 8 Feb 1995 16:19:39 +0200 BTW, many moons ago, I talked to the author of BarFly, Hi Laire! :-), about adding basic stabs support to BarFly, which would be really easy, IMHO. I don't recall if he ever did it. I sent him the stabs documentation, though. Laire, how about it? A problem with debugging which hasn't been resolved yet, I think, is that we need to shut off/override the ixemul.library trap handler in order to be able to run a debugger on programs using it. R Luebbert reported last year (archives are great) that he did some debuggin on ixemul.library using the powervisor debugger, with its "dirty" option turned on. I suppose "dirty" means "violating the enforcer guidelines", so I am reluctant to follow that approach. There are two scenarios here: 1) We attach the debugger to a process that is also running. (the first GDB for amigados will probably not support this immediately). Need to halt the process, find out if it's using ixemul.library, then poke around in it to disable the trap handler. 2) We run the program to be debugged using gdb. Since gdb does the LoadSeg()ing and actually starts the task/process, it could perhaps tweak some flag/patch some (system) function to make the OS ignore the programs request to install its traphandler. I haven't really thought about that part yet... For now, I'd be glad to debug non-ixemul programs; but I suppose traphandlers are so frequently used now that we need to intercept the installation of new ones and ignore them if they are for the program being debugged. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 16:43:48 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91212-4>; Wed, 8 Feb 1995 16:30:37 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 8 Feb 95 15:29 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 8 Feb 95 15:25 MET Message-Id: Subject: Re: ld, BFD and debug (source line) info To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 8 Feb 1995 15:24:54 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1662 > >with all that work going on with BFD and ld, I wonder if there's a > >linker that will generate an executable with standard Amiga debugging > >information, like it's used by SASC and DICE (I don't mean only the > > As you probably know, there is no standard for debugging information > on the Amiga. That SAS kept their format a secret didn't really help > to promote their format as a standard either. > Amiga gcc (and gdb when reading amigados executables) currently use > the stabs format (there is a texinfo document describing the format > somewhere). There are no plans to change this as far as I have heard. > forget sas, whats about debugging at all ? there is no working profiler or debugger available from gnu for the amiga. this causes sometimes big trouble for my (no fun to debug via k/printf !). in know there is a ptrace() port on the way, if there is a problem i am willing to help and sacrifice a part of my time (realy, there is no left). on the other side it would be nice to fix the symboltables that way profilers like aprof can use it, maybe an amiga-specific switch ? and what about a programm making specs more accessabel ? that would be a great help to identify conflicting options e.g. with -Ox. we cant be sure to find all (asume 10 options, and you get 10! combinations (nearly, ok ?;)) conflicts but why not try it. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 16:43:48 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91216-3>; Wed, 8 Feb 1995 16:32:59 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Wed, 8 Feb 1995 15:29:41 +0100 Received: from bodman.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA07394; Wed, 8 Feb 95 15:29:40 +0100 Date: Wed, 8 Feb 95 15:29:40 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502081429.AA07394@inf-wiss.uni-konstanz.de> Received: by bodman.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA01422; Wed, 8 Feb 95 15:29:39 +0100 To: amiga-gcc-port@nic.funet.fi Subject: Re: ld, BFD and debug (source line) info In-Reply-To: <95Feb8.154915+0200_eet.91163-3+35@nic.funet.fi> References: <9502081247.AA07030@inf-wiss.uni-konstanz.de> <95Feb8.154915+0200_eet.91163-3+35@nic.funet.fi> Leonard Norrgard writes: > As you probably know, there is no standard for debugging information > on the Amiga. That SAS kept their format a secret didn't really help I believe that SAS and DICE use the same format. And I believe that the non commercial debuggers PowerVisor and Barfly know that format, so information upon it must have been available to at least these people. Isn't it described in the GURU book? > somewhere). There are no plans to change this as far as I have heard. Too bad. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 16:50:47 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91196-2>; Wed, 8 Feb 1995 16:23:19 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA02158; Wed, 8 Feb 95 16:20:45 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA09646; Wed, 8 Feb 95 16:23:23 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502081423.AA09646@hpcl.cti.gr> Subject: binutils_bin.lha truncated in ftp.funet.fi To: amiga-gcc-port@lists.funet.fi (gcc) Date: Wed, 8 Feb 1995 16:23:18 +0200 (EET) Reply-To: kyrimis@theseas.ntua.gr X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 210 The copy of binutils_bin.lha in ftp.funet.fi:/pub/amiga/gnu/beta appears to be truncated (its size is 725504 bytes). -- Kriton (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 17:12:38 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91197-3>; Wed, 8 Feb 1995 17:06:22 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Wed, 8 Feb 1995 16:00:22 +0100 Received: from bodman.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA07530; Wed, 8 Feb 95 16:00:15 +0100 Date: Wed, 8 Feb 95 16:00:15 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502081500.AA07530@inf-wiss.uni-konstanz.de> Received: by bodman.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA01439; Wed, 8 Feb 95 16:00:07 +0100 To: amiga-gcc-port@nic.funet.fi Cc: luebberw@lp.musc.edu Subject: RE: gas-2.2 bug report: .align 2 doesn't work In-Reply-To: <00980FB2.C4870CC0.5726@lp.musc.edu> References: <00980FB2.C4870CC0.5726@lp.musc.edu> Hi, long time ago I posted about gas bugs. Well, all of the ones I know are gone since gas-2.5.2, but here is just a warning: (From an old mail) luebberw@lp.musc.edu writes: > I too have had the same problem while trying to build ixemul.library. > seems pc@(_label-.+2) does not work either. > > R. Luebbert > LuebbeRW@lp.musc.edu I used the pc@(label+2) trick too with previous versions of gas (mainly 1.38). Now it cost me a couple of hours to discover that my fix (adding +2 to the label to really access the label) _must_ be removed with the new bug-fixed gas. Now you just say pc@(label) to get a pc-relative reference. This requires me to correct the few assembly files I'm using :-( Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 18:10:36 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91209-4>; Wed, 8 Feb 1995 18:05:31 +0200 Received: by ceylon.informatik.uni-rostock.de id RAA17121; Wed, 8 Feb 1995 17:04:36 +0100 Received: by honshu.informatik.uni-rostock.de id RAA14014; Wed, 8 Feb 1995 17:04:35 +0100 From: Gunther Nikl Message-Id: <199502081604.RAA14014@honshu.informatik.uni-rostock.de> Subject: Re: LibNix Bugs To: dev@flevel.demon.co.uk Date: Wed, 8 Feb 1995 17:04:35 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <202b850e.ea61-dev@flevel.demon.co.uk> from "dev@flevel.demon.co.uk" at Feb 7, 95 07:03:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1418 Hello! > > > b) han=fopen("PIPE:FILE","w") > > > > > > This does not work. The cause of it is in the 'open.c' file > > > libnix tries to do a 'ChangeMode' on the file handle after > > > opening in. The AmigaDos pipe: handler doesn't support ChangeMode > > > and so it fails. LibNix should really open the file in the > > > correct mode to start with. > > > > Please read the section about the Open()-call in the Amiga-Guru Book > > concerning the open-modes! then you will now why open() calls > > ChangeMode(). > > Sorry, I don't have the Amiga-Guru book. I do have the offical Commodore > AmigaDos book and I can't find any reference to this. > > It does say under ChangeMode that the handler may reject the request. > I don't understand why you want to change mode when the file is opened > as either a strait read or write. I think the ChangeMode() call came in to get a EXCLUSIVE_LOCK for MODE_READWRITE. As one could expect to have one its not true for Kickstart 2.0 and up. > > To fix it, either delete the ChangeMode() call or check the IoErr() > > if ChangeMode() failed (209-unknow paket type) > > BTW, its already fixed (internally) > > My problem is that I want to be able to access PIPE: files in a portable > way. I guess that changemode could also fail on other non disk file system > handlers. Right, it failed also for Con-Handlers :( From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 18:10:36 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91210-3>; Wed, 8 Feb 1995 18:07:54 +0200 Received: by ceylon.informatik.uni-rostock.de id RAA17130; Wed, 8 Feb 1995 17:07:19 +0100 Received: by honshu.informatik.uni-rostock.de id RAA14030; Wed, 8 Feb 1995 17:07:18 +0100 From: Gunther Nikl Message-Id: <199502081607.RAA14030@honshu.informatik.uni-rostock.de> Subject: Re: gas-2.2 bug report: .align 2 doesn't work To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Wed, 8 Feb 1995 17:07:18 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9502081500.AA07530@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Feb 8, 95 04:00:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 631 > (From an old mail) > luebberw@lp.musc.edu writes: > > I too have had the same problem while trying to build ixemul.library. > > seems pc@(_label-.+2) does not work either. > > > > R. Luebbert > > LuebbeRW@lp.musc.edu > > I used the pc@(label+2) trick too with previous versions of gas > (mainly 1.38). Now it cost me a couple of hours to discover that my > fix (adding +2 to the label to really access the label) _must_ be > removed with the new bug-fixed gas. Now you just say pc@(label) to get > a pc-relative reference. This requires me to correct the few assembly > files I'm using :-( Bug-Fixed? ;-( Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 18:15:12 1995 Received: from godot.lysator.liu.se ([130.236.254.154]) by nic.funet.fi with ESMTP id <91211-2>; Wed, 8 Feb 1995 18:11:53 +0200 Received: from lysita (nisse@lysita.lysator.liu.se [130.236.254.153]) by godot.lysator.liu.se (8.6.8.1/8.6.6) with ESMTP id RAA26234 for ; Wed, 8 Feb 1995 17:11:37 +0100 Received: from localhost (nisse@localhost) by lysita (8.6.5/8.6.5) id RAA21787; Wed, 8 Feb 1995 17:11:27 +0100 Date: Wed, 8 Feb 1995 17:11:27 +0100 From: nisse@lysator.liu.se Message-Id: <199502081611.RAA21787@lysita> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: amiga-gcc-port@nic.funet.fi In-reply-to: <95Feb8.161948+0200_eet.91188-4+28@nic.funet.fi> (message from Leonard Norrgard on Wed, 8 Feb 1995 16:19:39 +0200) Subject: Re: debugging formats, ixemul trap handler From: Leonard Norrgard Date: Wed, 8 Feb 1995 16:19:39 +0200 A problem with debugging which hasn't been resolved yet, I think, is that we need to shut off/override the ixemul.library trap handler in order to be able to run a debugger on programs using it. R Luebbert reported last year (archives are great) that he did some debuggin on ixemul.library using the powervisor debugger, with its "dirty" option turned on. I suppose "dirty" means "violating the enforcer guidelines", so I am reluctant to follow that approach. [...] 2) We run the program to be debugged using gdb. Since gdb does the LoadSeg()ing and actually starts the task/process, it could perhaps tweak some flag/patch some (system) function to make the OS ignore the programs request to install its traphandler. I haven't really thought about that part yet... For now, I'd be glad to debug non-ixemul programs; but I suppose traphandlers are so frequently used now that we need to intercept the installation of new ones and ignore them if they are for the program being debugged. If the first step is to be able to use gdb to run and debug programs that use ixemul.library, perhaps the easiest way is to do it with ptrace. I don't know much about debugging under UNIX, but I think the debugger does something like this: if (pid=fork()) { /* Parent uses ptrace() to single step, * read the process' memory, etc */ } else { /* Child. */ ptrace(0); /* Go into ptrace mode */ exec("program_to_debug"); } With ixemul, the fork() can be replaced by vfork(), and no changes are needed to this function. ptrace() must be written, I understand someone is working on this. The ptrace() call has 2 effects: It makes the process halt when any signal is recieved. And it makes it halt after exec(). The last feature makes it necessary to patch exec() too (or if it is execv?). Starting non-ixemul processes under debugger control could perhaps be done the same way, but requires more changes to exec(), asexec() does quite different things if the progrem exec()ed is not an ixemul program. To attach an already running process to the debugger is rather different, I dont't even know how it is done normally, without the extra complication of supporting both Amiga and ixemul programs. From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 19:30:16 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91214-2>; Wed, 8 Feb 1995 19:26:50 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 8 Feb 95 18:24 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 8 Feb 95 18:15 MET Message-Id: Subject: Re: debugging formats, ixemul trap handler To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 8 Feb 1995 18:15:46 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1746 > If the first step is to be able to use gdb to run and debug programs > that use ixemul.library, perhaps the easiest way is to do it with > ptrace. I don't know much about debugging under UNIX, but I think the > debugger does something like this: > > if (pid=fork()) > { > /* Parent uses ptrace() to single step, > * read the process' memory, etc */ > } > else > { > /* Child. */ > ptrace(0); /* Go into ptrace mode */ > exec("program_to_debug"); > } > > With ixemul, the fork() can be replaced by vfork(), and no changes > are needed to this function. ptrace() must be written, I understand > someone is working on this. > > The ptrace() call has 2 effects: It makes the process halt when any > signal is recieved. And it makes it halt after exec(). The last > feature makes it necessary to patch exec() too (or if it is execv?). > > Starting non-ixemul processes under debugger control could perhaps be > done the same way, but requires more changes to exec(), asexec() does > quite different things if the progrem exec()ed is not an ixemul > program. > 1. there is a ptrace() for linux maybe it can adapted to run under amigaos ? (no idea how!) 2. there is a single-step mode in 68K processors, ever used anyone here ? > To attach an already running process to the debugger is rather > different, I dont't even know how it is done normally, without the > extra complication of supporting both Amiga and ixemul programs. > -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 19:36:49 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91218-1>; Wed, 8 Feb 1995 19:34:40 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA27038 (5.65c8/IDA-1.4.4 for ); Wed, 8 Feb 1995 18:34:21 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA10198; Wed, 8 Feb 95 18:34:20 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9502081734.AA10198@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: debugging formats, ixemul trap handler To: nisse@lysator.liu.se Date: Wed, 8 Feb 1995 18:34:20 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199502081611.RAA21787@lysita> from "nisse@lysator.liu.se" at Feb 8, 95 05:11:27 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 735 > > To attach an already running process to the debugger is rather > different, I dont't even know how it is done normally, without the > extra complication of supporting both Amiga and ixemul programs. > For CLI processes you could probably kludge a trap handler into the task and use the Process->pr_CLI->SegList to look where the code lies. I don't know a way (IMO there is none) to get the seglist of a WB started process (except by looking into the WBMessage, but this doesn't help here :-( ). It'll probably be possible to start programs the Workbench way if you give the .info file as filename to ixemul. Then you'd be able to start programs from ksh and attach to them later. (Or to debug the WB startup this way). Matthias From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 20:00:42 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91226-3>; Wed, 8 Feb 1995 19:58:18 +0200 Received: by theseas.ntua.gr with UUCP; Wed, 8 Feb 1995 19:58:20 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05w7@kriton.UUCP>; Wed, 8 Feb 95 19:27:41 EET Date: Wed, 8 Feb 95 19:27:41 EET Message-Id: <9502081727.05w7@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1549 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: beta nm and objdump bugs I tried the new beta versions of nm and objdump with amiga-style object files, obtained with SAS/C. Both nm and objdump do not recognize this kind of file, even if I specify --target=amiga. The versions supplied with 2.6.3 work fine. Well, almost fine: nm (2.6.3 version) gets a bit confused: "nm hello.o" produces: unknown debug hunk type 00000000 ? __writes 00000000 ? _main I suppose the "unknown debug hunk type" comes from encountering SAS/C symbols (the warning goes away if I obtain assembly code from SAS/C and assemble it with a68k), but the question marks should have been valid information ("U" in this case, I think). Both versions of objdump produce numerous "File exists" warnings when the "-i" option is used. E.g., with the new beta version, I get: BFD header file version 2.5 a.out-amiga (header big endian, data big endian) m68k:68020 amiga (header big endian, data big endian) objdump: t:tmp.655088: File exists srec (header big endian, data big endian) objdump: t:tmp.655088: File exists symbolsrec (header big endian, data big endian) objdump: t:tmp.655088: File exists a.out-amiga amiga srec symbolsrec objdump: a.out-amiga: File exists objdump: amiga: File exists objdump: srec: File exists objdump: symbolsrec: File exists m68k:68020 ----------- ----- ---- ---------- -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "You mean the world's gonna end and you've forgotten about it?" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 20:00:42 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91225-4>; Wed, 8 Feb 1995 19:57:42 +0200 Received: by theseas.ntua.gr with UUCP; Wed, 8 Feb 1995 19:58:22 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05w2@kriton.UUCP>; Wed, 8 Feb 95 18:57:08 EET Date: Wed, 8 Feb 95 18:57:08 EET Message-Id: <9502081657.05w2@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1152 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: beta ld bugs I just played a bit with the beta version of the new ld. First of all, I tried to see if it would link files compiled with the -resident option: ld choked on the options: -databss-together -datadata-reloc -fl libb (Apparently, amiga-specific flags have not been implemented yet.) I then thought I'd try linking the files by hand, e.g., ld.new -s gcc:lib/rcrt0.o hello.o gcc:lib/libb/libgcc.a gcc:lib/libb/libc.a I got the error message: Base symbol for base relative reloc not defined, section .text, reloc to symbol__ctype_ Abort trap - Work:T/gnu/bin/ld.new -s gcc:lib/rcrt0.o hello.o gcc:lib/libb/libgcc I then thought I'd give ld something simple. I compiled hello.c without -resident, and tried to link it by hand: ld.new -s gcc:lib/crt0.o hello.o gcc:lib/libgcc.a gcc:lib/libc.a I got: Abort trap - Work:T/gnu/bin/ld.new -s gcc:lib/crt0.o hello.o gcc:lib/libgcc.a Looks like ld needs a bit more work :-( -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "The light at the end of a tunnel is often that of an oncoming train." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 20:06:41 1995 Received: from uni-paderborn.de ([131.234.10.3]) by nic.funet.fi with SMTP id <91228-4>; Wed, 8 Feb 1995 20:04:32 +0200 Received: from haegar2.uni-paderborn.de (laire@haegar2.uni-paderborn.de [131.234.38.2]) by uni-paderborn.de (8.6.9/8.6.9) with ESMTP id TAA19057; Wed, 8 Feb 1995 19:04:15 +0100 From: Ralph Schmidt Received: (laire@localhost) by haegar2.uni-paderborn.de (8.6.9/8.6.9) id TAA24307; Wed, 8 Feb 1995 19:04:12 +0100 Message-Id: <199502081804.TAA24307@haegar2.uni-paderborn.de> Subject: Re: debugging formats, ixemul trap handler To: nisse@lysator.liu.se Date: Wed, 8 Feb 1995 19:04:11 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199502081611.RAA21787@lysita> from "nisse@lysator.liu.se" at Feb 8, 95 05:11:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1266 > > From: Leonard Norrgard > Date: Wed, 8 Feb 1995 16:19:39 +0200 > > A problem with debugging which hasn't been resolved yet, I think, is > that we need to shut off/override the ixemul.library trap handler in > order to be able to run a debugger on programs using it. > R Luebbert reported last year (archives are great) that he did some > debuggin on ixemul.library using the powervisor debugger, with its > "dirty" option turned on. I suppose "dirty" means "violating the > enforcer guidelines", so I am reluctant to follow that approach. > Well...I suggested that years ago to M.Wild..he didn't want to fix this bug...yes it's a bug. The other guy those name i don't remember right now that overtook the ixemul.library also didn't want to fix this bug. I have not the slightest clue why an OpenLibrary has to patch a custom traphandler into a task field. If somebody wants to use a different traphandler he should load it external like tnt and other incarnations. Oh well..my conclusion is that it makes no sense to ask for a fixed version because the responsible people won't do it. -- Ralph Schmidt laire@uni-paderborn.de University of Paderborn (Germany) From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 20:32:54 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91187-3>; Wed, 8 Feb 1995 20:29:56 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rcHK0-0004nYC; Wed, 8 Feb 95 11:41 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: debugging formats, ixemul trap handler To: nisse@lysator.liu.se Date: Wed, 8 Feb 1995 11:40:59 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199502081611.RAA21787@lysita> from "nisse@lysator.liu.se" at Feb 8, 95 05:11:27 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 668 > If the first step is to be able to use gdb to run and debug programs > that use ixemul.library, perhaps the easiest way is to do it with > ptrace. Rather than writing a ptrace emulation, I think it would be better to write a /proc emulation. This is the more modern way of doing things, and provides *much* more control over other processes. > To attach an already running process to the debugger is rather > different, I dont't even know how it is done normally, without the > extra complication of supporting both Amiga and ixemul programs. With /proc you simply open /proc/ and do various ioctls or read/writes on the file id you get back. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 21:46:09 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91194-3>; Wed, 8 Feb 1995 21:43:13 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id aa00842; 8 Feb 95 19:40 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA001ya; Wed, 8 Feb 95 19:04:50 GMT Date: Wed, 8 Feb 95 19:04:50 GMT Message-Id: <9502081904.AA001y9@flevel.demon.co.uk> Message-Id: <202cd6cf.83d61-dev@flevel.demon.co.uk> In-Reply-To: <9502081429.AA07394@inf-wiss.uni-konstanz.de> (from Joerg-Cyril Hoehle ) (at Wed, 8 Feb 95 15:29:40 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: hoehle@inf-wiss.uni-konstanz.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ld, BFD and debug (source line) info Hi Joerg-Cyril, > Leonard Norrgard writes: > > As you probably know, there is no standard for debugging information > > on the Amiga. That SAS kept their format a secret didn't really help > > I believe that SAS and DICE use the same format. And I believe that > the non commercial debuggers PowerVisor and Barfly know that format, > so information upon it must have been available to at least these > people. Isn't it described in the GURU book? > What about devpac, it produces debug info, the options are: none,standard or exports I wonder what format its in? I know the gnu symbols are read ok from monam (source level debugger in devpac). Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 21:48:40 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91199-1>; Wed, 8 Feb 1995 21:46:32 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ab00842; 8 Feb 95 19:40 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA001yf; Wed, 8 Feb 95 19:08:39 GMT Date: Wed, 8 Feb 95 19:08:39 GMT Message-Id: <9502081908.AA001ye@flevel.demon.co.uk> Message-Id: <202cd7b6.ea62-dev@flevel.demon.co.uk> In-Reply-To: (from Walter Harms ) (at Wed, 8 Feb 1995 18:15:46 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: Walter.Harms@arbi.informatik.uni-oldenburg.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: debugging formats, ixemul trap handler Hi Walter, > > Starting non-ixemul processes under debugger control could perhaps be > > done the same way, but requires more changes to exec(), asexec() does > > quite different things if the progrem exec()ed is not an ixemul > > program. > > > 1. there is a ptrace() for linux maybe it can adapted to run under > amigaos ? (no idea how!) > 2. there is a single-step mode in 68K processors, > ever used anyone here ? Ive have written a debugger for the Atari St (Many years ago) and that used the trace mode of the 68K and also breakpoints of various types. Its not too hard to run a trace. Monam (From Devpac) uses tracing on the Amiga. > > To attach an already running process to the debugger is rather > > different, I dont't even know how it is done normally, without the > > extra complication of supporting both Amiga and ixemul programs. I think provisor will do this, maybe the source is available somewhere??? Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 22:54:01 1995 Received: from uni-paderborn.de ([131.234.10.3]) by nic.funet.fi with SMTP id <91198-2>; Wed, 8 Feb 1995 22:50:13 +0200 Received: from haegar2.uni-paderborn.de (laire@haegar2.uni-paderborn.de [131.234.38.2]) by uni-paderborn.de (8.6.9/8.6.9) with ESMTP id TAA19390; Wed, 8 Feb 1995 19:11:12 +0100 From: Ralph Schmidt Received: (laire@localhost) by haegar2.uni-paderborn.de (8.6.9/8.6.9) id TAA24329; Wed, 8 Feb 1995 19:11:10 +0100 Message-Id: <199502081811.TAA24329@haegar2.uni-paderborn.de> Subject: Re: debugging formats, ixemul trap handler To: vinsci@nic.funet.fi (Leonard Norrgard) Date: Wed, 8 Feb 1995 19:11:10 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Feb8.161948+0200_eet.91188-4+28@nic.funet.fi> from "Leonard Norrgard" at Feb 8, 95 04:19:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1083 > > BTW, many moons ago, I talked to the author of BarFly, Hi Laire! :-), > about adding basic stabs support to BarFly, which would be really > easy, IMHO. I don't recall if he ever did it. I sent him the stabs > documentation, though. > Laire, how about it? I did it but after my trouble with the ixemul guys,sources and world in general i didn't really cared for more than source stepping stabs support because i don't use gcc. > 2) We run the program to be debugged using gdb. Since gdb > does the LoadSeg()ing and actually starts the task/process, > it could perhaps tweak some flag/patch some (system) function > to make the OS ignore the programs request to install its > traphandler. That's not possible in a useful way..just remove this bug and the problem is solved as fast as possible. Sorry...for my anger but if i would let my emotions a free run i would write a mega flame against the 2 guys that actually worked on ixemul.library:-) -- Ralph Schmidt laire@uni-paderborn.de University of Paderborn (Germany) From amiga-gcc-port-owner@nic.funet.fi Wed Feb 8 23:56:56 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <91191-4>; Wed, 8 Feb 1995 23:52:53 +0200 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA23758; Wed, 8 Feb 1995 22:57:43 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9502082157.AA23758@decap2.zdv.uni-tuebingen.de> Subject: Re: debugging formats, ixemul trap handler To: laire@uni-paderborn.de (Ralph Schmidt) Date: Wed, 8 Feb 1995 22:57:41 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199502081811.TAA24329@haegar2.uni-paderborn.de> from "Ralph Schmidt" at Feb 8, 95 07:11:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 945 Hi, Laire, > I did it but after my trouble with the ixemul guys,sources and world > in general i didn't really cared for more than source stepping stabs > support because i don't use gcc. You did? Would it be much work to complete this? > > 2) We run the program to be debugged using gdb. Since gdb > > does the LoadSeg()ing and actually starts the task/process, > > it could perhaps tweak some flag/patch some (system) function > > to make the OS ignore the programs request to install its > > traphandler. > > That's not possible in a useful way..just remove this bug and the problem > is solved as fast as possible. If I understood this mail and some others right, this problem concerns ixemul.library only? Thus BarFly with stabs support would at least allow to debug programs compiled with -noixemul. This could be extremely helpful - and would be a good reason for Raphael to fix this bug in ixemul, wouldn't it? :-) Jochen From amiga-gcc-port-owner@nic.funet.fi Thu Feb 9 07:26:25 1995 Received: from uni-paderborn.de ([131.234.10.3]) by nic.funet.fi with SMTP id <91193-2>; Thu, 9 Feb 1995 07:23:01 +0200 Received: from taifun.uni-paderborn.de (laire@taifun.uni-paderborn.de [131.234.30.26]) by uni-paderborn.de (8.6.9/8.6.9) with ESMTP id GAA02992; Thu, 9 Feb 1995 06:18:58 +0100 From: Ralph Schmidt Received: (laire@localhost) by taifun.uni-paderborn.de (8.6.7/8.6.6) id GAA12656; Thu, 9 Feb 1995 06:18:55 +0100 Message-Id: <199502090518.GAA12656@taifun.uni-paderborn.de> Subject: Re: debugging formats, ixemul trap handler To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Thu, 9 Feb 1995 06:18:55 +0100 (MET) Cc: laire@uni-paderborn.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <9502082157.AA23758@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Feb 8, 95 10:57:41 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1282 > > > Hi, Laire, > > > I did it but after my trouble with the ixemul guys,sources and world > > in general i didn't really cared for more than source stepping stabs > > support because i don't use gcc. > You did? Would it be much work to complete this? Well..adding stack,register symbol and structure support is prolly a lot of work. If it's worth is another question. > > > > > 2) We run the program to be debugged using gdb. Since gdb > > > does the LoadSeg()ing and actually starts the task/process, > > > it could perhaps tweak some flag/patch some (system) function > > > to make the OS ignore the programs request to install its > > > traphandler. > > > > That's not possible in a useful way..just remove this bug and the problem > > is solved as fast as possible. > If I understood this mail and some others right, this problem concerns > ixemul.library only? Thus BarFly with stabs support would at least > allow to debug programs compiled with -noixemul. This could be > extremely helpful - and would be a good reason for Raphael to fix this > bug in ixemul, wouldn't it? :-) > Only ixemul. gerlib worked for me so i assume also libnix. -- Ralph Schmidt laire@uni-paderborn.de University of Paderborn (Germany) From amiga-gcc-port-owner@nic.funet.fi Thu Feb 9 09:23:43 1995 Received: from jupiter.pt.hk-r.se ([194.47.132.2]) by nic.funet.fi with ESMTP id <91190-2>; Thu, 9 Feb 1995 09:21:11 +0200 Received: (from pi92bn@localhost) by jupiter.pt.hk-r.se (8.6.9/8.6.9) id IAA19043 for amiga-gcc-port@nic.funet.fi; Thu, 9 Feb 1995 08:18:43 +0100 Date: Thu, 9 Feb 1995 08:18:43 +0100 From: Bjoern Nilsson Message-Id: <199502090718.IAA19043@jupiter.pt.hk-r.se> To: amiga-gcc-port@nic.funet.fi Subject: unsubscribe unsubscribe pi92bn@pt.hk-r.se /Hack away!!! ;-) From amiga-gcc-port-owner@nic.funet.fi Thu Feb 9 09:35:13 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91208-4>; Thu, 9 Feb 1995 09:33:00 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA04616; Thu, 9 Feb 95 09:30:42 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA16748; Thu, 9 Feb 95 09:33:14 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502090733.AA16748@hpcl.cti.gr> Subject: Re: beta nm and objdump bugs To: isthesin@TechFak.Uni-Bielefeld.DE Date: Thu, 9 Feb 1995 09:33:12 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9502081812.AA02446@moos.techfak.uni-bielefeld.de> from "isthesin@TechFak.Uni-Bielefeld.DE" at Feb 8, 95 07:12:13 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 642 > I can not say anything about this, without a look at the files. > What exact commands/options did you use ? sc CPU=68040 NOSTACKCHECK STRMERGE OPT OPTSCHED hello.c nm hello.o objdump --syms -l hello.o > P.S.: The error messages with objdump -i are normal, though I really don't know, > where they come from..... Sounds like someone is trying to access a file that has been opened for write (or locked) by someone else, e.g.: f1 = fopen("file", "w"); f2 = fopen("file", "r"); /* This will fail on the Amiga */ This could be potentially serious. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Thu Feb 9 09:43:22 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91186-1>; Thu, 9 Feb 1995 09:41:19 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA04896; Thu, 9 Feb 95 09:39:25 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA16763; Thu, 9 Feb 95 09:42:09 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502090742.AA16763@hpcl.cti.gr> Subject: Re: beta ld bugs To: isthesin@TechFak.Uni-Bielefeld.DE Date: Thu, 9 Feb 1995 09:42:08 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9502081810.AA02442@moos.techfak.uni-bielefeld.de> from "isthesin@TechFak.Uni-Bielefeld.DE" at Feb 8, 95 07:10:49 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 619 > As to the second error, I can't say anything, without looling at the files..... > Did you try ld.new -o hello /gcc/lib/crt0.o hello.o -L/gcc/lib -lgcc -lc -lgcc ????? I think so, but even if I did, omitting the -L options and specifying the libraries directly should only help. Besides, the only reasonable error that I would expect to get if I'd done something wrong would have been various undefined references. > In fact, I have no time to work any more on ld at the moment (master's thesis....) Good luck with your work! -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Thu Feb 9 11:58:03 1995 Received: from alfred.uib.no ([129.177.30.16]) by nic.funet.fi with ESMTP id <91159-1>; Thu, 9 Feb 1995 11:56:18 +0200 Received: from [129.177.12.18] (actually 129.177.12.18) by alfred.uib.no with SMTP (PP); Thu, 9 Feb 1995 10:56:06 +0100 X-Sender: edpjn@alf.uib.no Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Feb 1995 10:57:40 +0100 To: amiga-gcc-port@nic.funet.fi From: Jarle.Nilsen@edb.uib.no Subject: unsubscribe Message-ID: <"alfred.uib.n:234450:950209095610"@alfredPP.uib.no> unsubscribe From amiga-gcc-port-owner@nic.funet.fi Thu Feb 9 12:50:42 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91184-3>; Thu, 9 Feb 1995 12:45:31 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Thu, 9 Feb 1995 11:44:44 +0100 Received: from hoechst.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10028; Thu, 9 Feb 95 11:44:40 +0100 Date: Thu, 9 Feb 95 11:44:40 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502091044.AA10028@inf-wiss.uni-konstanz.de> Received: by hoechst.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA08119; Thu, 9 Feb 95 11:44:39 +0100 To: amiga-gcc-port@nic.funet.fi Subject: Re: ld, BFD and debug (source line) info In-Reply-To: <9502081904.AA001y9@flevel.demon.co.uk>, <202cd6cf.83d61-dev@flevel.demon.co.uk> References: <9502081429.AA07394@inf-wiss.uni-konstanz.de> <9502081904.AA001y9@flevel.demon.co.uk> <202cd6cf.83d61-dev@flevel.demon.co.uk> Hi, dev@flevel.demon.co.uk writes: > Hi Joerg-Cyril, > What about devpac, it produces debug info, the options are: > > none,standard or exports > > I wonder what format its in? I know the gnu symbols are read ok from > monam (source level debugger in devpac). I thought that devpac and monam are assemblers, so do you need more there than symbols information (just enough to locate globals and functions), which GCC can generate? What a C programmer is missing, is source-line information (C source lines are not assembly source lines), so that the debugger shows to which source line the assembler instructions just executing belongs. That would help a lot. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Feb 9 17:12:37 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91213-4>; Thu, 9 Feb 1995 17:05:26 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id aa20502; 9 Feb 95 14:56 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA0027z; Thu, 9 Feb 95 14:35:44 GMT Date: Thu, 9 Feb 95 14:35:44 GMT Message-Id: <9502091435.AA0027y@flevel.demon.co.uk> Message-Id: <202de93a.a6040-dev@flevel.demon.co.uk> In-Reply-To: <9502091044.AA10028@inf-wiss.uni-konstanz.de> (from Joerg-Cyril Hoehle ) (at Thu, 9 Feb 95 11:44:40 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: hoehle@inf-wiss.uni-konstanz.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ld, BFD and debug (source line) info Hi Joerg-Cyril, > I thought that devpac and monam are assemblers, so do you need more > there than symbols information (just enough to locate globals and > functions), which GCC can generate? Yes you need the line debug info which I'm not sure GCC generates. I know Dice does put this in. > What a C programmer is missing, is source-line information (C source > lines are not assembly source lines), so that the debugger shows to > which source line the assembler instructions just executing > belongs. That would help a lot. If a single C program is compiled with Dice C with debug info on, the executable can be loaded into monam. If you then load the correct .c file into monam as source code then the debugger will track the source code as the PC moves through the program. In that respect monam is a source level debugger. Trefor S. From amiga-gcc-port-owner@nic.funet.fi Thu Feb 9 19:42:28 1995 Received: by nic.funet.fi id <91217-3>; Thu, 9 Feb 1995 19:39:03 +0200 From: Leonard Norrgard To: kyrimis@theseas.ntua.gr CC: amiga-gcc-port@lists.funet.fi In-reply-to: <9502081423.AA09646@hpcl.cti.gr> (kyrimis@hpcl.cti.gr) Subject: Re: binutils_bin.lha truncated in ftp.funet.fi Message-Id: <95Feb9.193903+0200_eet.91217-3+50@nic.funet.fi> Date: Thu, 9 Feb 1995 19:38:58 +0200 > The copy of binutils_bin.lha in ftp.funet.fi:/pub/amiga/gnu/beta > appears to be truncated (its size is 725504 bytes). Confirmed. binutils_bin.lha is truncated. From amiga-gcc-port-owner@nic.funet.fi Thu Feb 9 19:44:15 1995 Received: by nic.funet.fi id <91221-4>; Thu, 9 Feb 1995 19:41:24 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: [mrs@cygnus.com: BSVC Distribution Announcement (68000 Simulator)] Message-Id: <95Feb9.194124+0200_eet.91221-4+30@nic.funet.fi> Date: Thu, 9 Feb 1995 19:41:22 +0200 For your information... -- vinsci Date: Thu, 9 Feb 1995 03:02:45 -0800 From: Mike Stump Xref: news.cygnus.com comp.os.linux.announce:2897 comp.sys.m68k:3289 Path: news.cygnus.com!sgiblab!swrinde!gatech!bloom-beacon.mit.edu!eru.mt.luth.se!news.kth.se!sunic!news.funet.fi!news.csc.fi!news.helsinki.fi!not-for-mail From: bwmott@eos.ncsu.edu (Bradford Wayne Mott) Newsgroups: comp.os.linux.announce,comp.sys.m68k Subject: BSVC Distribution Announcement (68000 Simulator) Followup-To: comp.os.linux.misc,comp.sys.m68k Date: 4 Feb 1995 20:55:20 +0200 Organization: North Carolina State University Lines: 126 Sender: wirzeniu@cc.Helsinki.FI Approved: linux-announce@tc.cornell.edu (Lars Wirzenius) Message-ID: <3h0iio$93h@kruuna.Helsinki.FI> NNTP-Posting-Host: kruuna.helsinki.fi Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Summary: Motorola 68000 simulator for X windows Keywords: simulator, motorola, 68000, m68k, BSVC =============================================================================== BBBBBB SSSSS VVV VVV CCCCC BB BB SS SS VV VV CC CC BB BB SS VV VV CC BBBBB SSSSS VV VV CC "A Microprocessor Simulation Framework" BB BB SS VV VV CC BB BB SS SS VVVV CC CC Version 1.0 BBBBBB SSSSS VV CCCCC =============================================================================== Distribution Announcement ------------------------------------------------------------------------------- BSVC is a microprocessor simulation framework written in C++ and Tcl/Tk. It was developed as a senior project at North Carolina State University by Bradford W. Mott. BSVC provides a graphical user interface and a collection of C++ classes to facilitate the development of microprocessor simulators. So far the BSVC framework has been used to developed a Motorola 68000 simulator and a HECTOR 1600 simulator. The BSVC distribution contains the following: * BSVC Graphical User Interface (written in Tcl/Tk) * BSVC Simulator Framework (C++ classes) * Motorola 68000 simulator & assembler (including the M68681 Dual UART) * Hector 1600 simulator & assembler CHANGES ======= The following changes have been made: 1.0b3 to 1.0: a) The memory viewer has been made larger and faster b) WWW Home Page selection has been added to the help menu This starts a WWW browser pointed at the BSVC Home Page c) Added code to handle the STOP instruction d) Fixed a problem with the RTS instruction e) Unimplemented intructions cause an illegal instruction exception f) Fixed the 68000 assembler's INCLUDE directive so that it can be in any case g) Compiles with GCC 2.6.2 1.0b2 to 1.0b3: a) Added an INCLUDE directive to the 68000 assembler b) Fixed a bug in the Program Listing window that caused it to only work for programs listed in ascending order c) Corrected a small problem with the file selector that caused it to "grab" the mouse while reading a directory (This causes problems with networked file systems that take a long time to read) d) Fixed bugs in two of the Framework classes that caused them not to compile under GCC 2.6.0 1.0b1 to 1.0b2: a) Added a BREAK instruction to the 68000 simulator and assembler that acts like a breakpoint. When the simulator executes this instruction while "running" it will stop running like it hit a breakpoint. b) Added a new file selector to the user interface c) Fixed several small bugs in the HECTOR 1600 simulator Supported Systems ================= The BSVC distribution supports the following systems: * Linux 1.x.x * Ultrix 4.3 * SunOS * HP-UX 9.0 Required Software ================= BSVC requires the following software to compile and run: * gcc and the g++ library * Tcl/Tk (Needs the "wish" executable with the addinput extension) Distribution Sites ================== The BSVC distribution can be obtained from: ftp.eos.ncsu.edu in the pub/bsvc directory as "bsvc-1.0.tar.z". sunsite.unc.edu in the pub/Linux/system/Emulators directory as "bsvc-1.0.tar.z" Contacts ======== If you have any questions regarding the BSVC distribution send mail to: bwmott@eos.ncsu.edu -- Send submissions for comp.os.linux.announce to: linux-announce@news.ornl.gov PLEASE remember Keywords: and a short description of the software. From amiga-gcc-port-owner@nic.funet.fi Thu Feb 9 21:16:36 1995 Received: from post.demon.co.uk ([158.152.1.72]) by nic.funet.fi with SMTP id <91195-4>; Thu, 9 Feb 1995 21:15:05 +0200 Received: from iceman.demon.co.uk by post.demon.co.uk id ac06179; 9 Feb 95 18:57 GMT Received: by iceman.demon.co.uk (V1.16/Amiga) id AA00048; Thu, 9 Feb 95 17:35:49 GMT Date: Thu, 9 Feb 95 17:35:49 GMT Message-Id: <9502091735.AA00047@iceman.demon.co.uk> Organization: wit's end with AmiTCP :( X-MailViewer: Mail 1.15 From: Graham Crowder To: amiga-gcc-port@nic.funet.fi Subject: Using CBM developer files with GCC (fwd) A question (probably a FAQ). I have just received the 5-disk set of CBM includes, libraries, FD files etc. and want to incorporate the software into my existing installation of the GNU CC compiler, which is version 2.6.3 and which was built from the supplied installer script. I have read (but not understood) the guidelines in README-2.6.3 about generating in-line headers and the like. On my system the directory GNU:os-include already has inline and proto subdirectories, which both contain a number of .h header files. GNU:os-lib only contains libamiga.a and libb/libamiga.a which I take to be the distributable versions of libamiga.a referred to in the documentation. The question (probably a FAQ ?) is, where would you suggest as the best place to install the developer includes, FDs and libs? The libs will have to be converted from .lib format to .a, but that is dealt with in the README files ISTR. After building my system I do not intend to distribute it to others, so the restricted stuff can all go inside the GNU: tree if that's what you recommend. I want to try and minimise the changes necessary to port SAS-designed makefiles to GCC, and plan to do quite a bit of porting. Sorry if this is all a bit too "newbie" for all you gurus, but this whole include/fd/inline/proto business is pretty new to me :( TIA -- Graham Crowder: grahamc@iceman.demon.co.uk: grahamc@kmbcopps.demon.co.uk Amiga A1200/190MB HD/GVP A1230Turbo+SerII/68EC030/68882/10MB RAM/AmiTCP "Any sufficiently advanced technology is indistinguishable from magic" --- Arthur C Clarke -- Graham Crowder: grahamc@iceman.demon.co.uk: grahamc@kmbcopps.demon.co.uk Amiga A1200/190MB HD/GVP A1230Turbo+SerII/68EC030/68882/10MB RAM/AmiTCP "Any sufficiently advanced technology is indistinguishable from magic" --- Arthur C Clarke From amiga-gcc-port-owner@nic.funet.fi Thu Feb 9 21:51:31 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <91223-2>; Thu, 9 Feb 1995 21:49:49 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA22397; Thu, 9 Feb 95 12:45:29 MST Date: Thu, 9 Feb 1995 12:45:28 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: amiga-gcc-port@lists.funet.fi Subject: possible gnu c++ bug Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello all! About a week or so ago, I posted a message that I may have found a bug in c++. Several people suggested I increase my stack to see if that solved the problem. I have just now been able to try that. Unfortunately, it seems to have no effect. I tried increasing GCCSTACK to 1000000 and mt shell stack to the same. I get the same result. My setup is: A2500/020, 6meg fast ram, 1meg chip, Seagate st157n HD (46 MB) and Quantum P40 (40MB). Below is the result of using -v with gcc (I got exactly the same result using g++): gcc -v -c -m68020 -m68881 -O2 -I ../Demon_Commons -idirafter gnu:os-include -c input.cc -o input.o Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c++ -v -I ../Demon_Commons -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ - D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -D__OPTIMIZE__ -D__HAVE_68881__ -Dmc68020 -idirafter gnu:os-include input.cc T:cc915704.ii GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: ../Demon_Commons /gnu/lib/g++-include /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include gnu:os-include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1plus T:cc915704.ii -quiet -dumpbase input.cc -m68020 -m68881 -O2 -version -o T:cc915704.s GNU C++ version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3 snapshot 941209. input.cc: In function `void input()': input.cc:29: Internal compiler error. input.cc:29: Please submit a full bug report to `bug-g++@prep.ai.mit.edu'. make: *** [input.o] Error 1 The code follows: #include "declares.h" #include "demon_structs.h" #include "message.h" #include "units.h" extern double xd, x, xact, xerr, xerest, yd, y, zd, z, yact, yerr, yerest; extern double c, c2, t0, errprm; // reads parameters associated with the d. e. calculations. void input () { char line[101]; // print d. e. parameter heading. if (!units.out) { printf ("NULL files are being used.\n"); closfl (); exit (0); } heads (); fprintf (units.out, "\n%s D. E. Parameters %s\n", stars, stars); // skip comments in the input file. // read d. e. parameters. line = skipcm (units.in, line); sscanf (line, "%lf %lf %lf", &c, &t0, &errprm); // print d. e. initial conditions. fprintf (units.out, "\n\n c: %12g\n", c); fprintf (units.out, "\n\n t0: %12g\n", t0); fprintf (units.out, "\n\n err: %12g\n", errprm); } Does anyone know what is going on? It is very important that I get this to work. Paul Ney From amiga-gcc-port-owner@nic.funet.fi Thu Feb 9 22:50:15 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <91240-2>; Thu, 9 Feb 1995 22:48:19 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189451>; Thu, 9 Feb 1995 21:47:57 +0100 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA24953; Thu, 9 Feb 1995 21:47:45 +0100 Date: Thu, 9 Feb 1995 21:47:45 +0100 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9502092047.AA24953@nereid.rz.Uni-Osnabrueck.DE> To: amiga-gcc-port@nic.funet.fi Subject: specs Hey ! can anybody tell me how to change the specs-file in that gcc automatically uses option -m68030 -m68881 ? I have tried to predefine this, but it seems that gcc makes no use of my defines. If this question is too stupid, please tell me what documents will give an answer (this is even better). Is this specs-file a UNIX-convention ? Thomas From amiga-gcc-port-owner@nic.funet.fi Fri Feb 10 11:13:32 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91148-2>; Fri, 10 Feb 1995 11:06:42 +0200 Received: by colombo.telesys-innov.fr; Fri, 10 Feb 1995 10:04:30 +0100 From: Philippe BRAND Message-Id: <199502100904.KAA16732@colombo.telesys-innov.fr> Subject: Re: possible gnu c++ bug To: pney@RT66.com (Paul Ney) Date: Fri, 10 Feb 1995 10:04:29 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Paul Ney" at Feb 9, 95 12:45:28 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 514 Paul Ney writes: > About a week or so ago, I posted a message that I may have found a bug > in c++. Several people suggested I increase my stack to see if that > solved the problem. I have just now been able to try that. I'll try that on beta 2.6.4 asap. > Does anyone know what is going on? It is very important that I get this > to work. Asap, means when I'll have 2.6.4-950203 compiled, somewhat this week-end. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Fri Feb 10 11:24:33 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91159-2>; Fri, 10 Feb 1995 11:16:34 +0200 Received: by colombo.telesys-innov.fr; Fri, 10 Feb 1995 10:14:30 +0100 From: Philippe BRAND Message-Id: <199502100914.KAA16761@colombo.telesys-innov.fr> Subject: Re: binutils_bin.lha truncated in ftp.funet.fi To: vinsci@nic.funet.fi (Leonard Norrgard) Date: Fri, 10 Feb 1995 10:14:28 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95Feb9.193903+0200_eet.91217-3+50@nic.funet.fi> from "Leonard Norrgard" at Feb 9, 95 07:38:58 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 325 Leonard Norrgard writes: > > The copy of binutils_bin.lha in ftp.funet.fi:/pub/amiga/gnu/beta > > appears to be truncated (its size is 725504 bytes). > Confirmed. binutils_bin.lha is truncated. Confirmed++, also on my site. Stephen ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Fri Feb 10 14:04:07 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91186-2>; Fri, 10 Feb 1995 13:55:52 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id aa16437; 10 Feb 95 11:43 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA002su; Fri, 10 Feb 95 09:23:02 GMT Date: Fri, 10 Feb 95 09:23:02 GMT Message-Id: <9502100923.AA002st@flevel.demon.co.uk> Message-Id: <202ef173.5cc61-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: GCC Optimiser bug Last night I tried compling a program called Limbo (Fractal compressor written in ANSI C). When I compiled the program with the -O3 option the maths stopped working correctly. I won't go into detail because its quite a specialised program. I re-compiled with just -O and the program worked fine (Or at least differently to with -O3). BTW - I also used -m68881 -m68030 and there is a lot of FP math in the program. I think with the number of people who are having problems with O2/O3 there is mostly likely a bug in the optimiser. Any ideas? Thanks, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Feb 10 15:13:21 1995 Received: from aleko.kom.auc.dk ([130.225.51.17]) by nic.funet.fi with SMTP id <91180-1>; Fri, 10 Feb 1995 15:04:27 +0200 Received: by aleko.kom.auc.dk (Smail3.1.28.1 #2) id m0rcv0n-000FPaC; Fri, 10 Feb 95 14:03 MET Message-Id: Date: Fri, 10 Feb 95 14:03 MET From: jds@kom.auc.dk (Jes Degn Soerensen) To: dev@flevel.demon.co.uk Cc: amiga-gcc-port@nic.funet.fi Subject: GCC Optimiser bug In-Reply-To: <9502100923.AA002st@flevel.demon.co.uk>, <202ef173.5cc61-dev@flevel.demon.co.uk> References: <9502100923.AA002st@flevel.demon.co.uk> <202ef173.5cc61-dev@flevel.demon.co.uk> dev@flevel.demon.co.uk writes: > Last night I tried compling a program called Limbo (Fractal compressor > written in ANSI C). > > When I compiled the program with the -O3 option the maths stopped working > correctly. I won't go into detail because its quite a specialised program. > > I re-compiled with just -O and the program worked fine (Or at least > differently to with -O3). > > BTW - I also used -m68881 -m68030 and there is a lot of FP math in the > program. > > I think with the number of people who are having problems with O2/O3 there > is mostly likely a bug in the optimiser. I don't think your -O3 problem is a bug in the Amiga port of gcc. When I compiled gdb-4.13 on one of the institutes Sparc 10's running Solaris 2.3, I had a similar problem with -O4 - it simply wouldn't compile. When I switched back to -O2 everything worked perfectly. Generally we don't compile software with optimze levels higher than O2 on our Sparc's, just to be on the safe side. Jes -- Jes Sorensen: jds@kom.auc.dk | If programming was ment to be fun, jes@leech.adsp.sub.org | why did they come up with Intel? From amiga-gcc-port-owner@nic.funet.fi Fri Feb 10 18:25:52 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91180-4> convert rfc822-to-8bit; Fri, 10 Feb 1995 18:16:39 +0200 Received: by theseas.ntua.gr with UUCP; Fri, 10 Feb 1995 18:03:53 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05x9@kriton.UUCP>; Fri, 10 Feb 95 17:59:08 EET Date: Fri, 10 Feb 95 17:59:08 EET Message-Id: <9502101559.05x9@kriton.UUCP> In-Reply-To: (from Paul Ney ) (at Thu, 9 Feb 1995 12:45:28 -0700 (MST)) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT Content-Length: 1262 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: pney@RT66.com Cc: amiga-gcc-port@lists.funet.fi Subject: Re: possible gnu c++ bug Hi Paul (Paul Ney), in on Feb 9 you wrote: > About a week or so ago, I posted a message that I may have found a bug > in c++. Several people suggested I increase my stack to see if that > solved the problem. I have just now been able to try that. > Unfortunately, it seems to have no effect. I tried increasing GCCSTACK > to 1000000 and mt shell stack to the same. I get the same result. My > setup is: A2500/020, 6meg fast ram, 1meg chip, Seagate st157n HD (46 MB) > and Quantum P40 (40MB). Below is the result of using -v with gcc (I got > exactly the same result using g++): Weird--I tried compiling it with the header files that you posted, and it compiled without a hitch. The stack does not appear to be a problem, as stackmon shows that cc1plus's maximum stack usage is about 12K (I tried with both my usual GCCSTACK=250000, and with GCCSTACK=50000 and encountered no problems). -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Is it you, Time Lord?" "Well, as far as I know, there's no one else except you and me here, so it must be me!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Feb 10 20:17:59 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91190-3>; Fri, 10 Feb 1995 20:10:39 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rczyS-0004nYC; Fri, 10 Feb 95 11:21 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: possible gnu c++ bug To: pney@RT66.com (Paul Ney) Date: Fri, 10 Feb 1995 11:21:44 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Paul Ney" at Feb 9, 95 12:45:28 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 618 > The code follows: When I try compiling I get (not unexpectedly): bug.cc:1: declares.h: No such file or directory bug.cc:2: demon_structs.h: No such file or directory bug.cc:3: message.h: No such file or directory bug.cc:4: units.h: No such file or directory Because of the following nonstandard headers: > #include "declares.h" > #include "demon_structs.h" > #include "message.h" > #include "units.h" > Does anyone know what is going on? It is very important that I get this > to work. Try compiling with -E to generate preprocessed code, distill that to an example that fails, and post that example. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Feb 10 21:02:58 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <91184-1>; Fri, 10 Feb 1995 20:58:55 +0200 X400-Received: by /ADMD=FUMAIL/C=fi/; Relayed; Fri, 10 Feb 1995 20:58:45 +0200 X400-Received: by mta funet.fi in /ADMD=FUMAIL/C=fi/; Relayed; Fri, 10 Feb 1995 20:58:45 +0200 X400-Received: by mta d400relay in /PRMD=dfnrelay/ADMD=d400/C=de/; Relayed; Fri, 10 Feb 1995 21:00:23 +0200 X400-Received: by mta fh-regensburg.d400 in /PRMD=dfnrelay/ADMD=d400/C=de/; Relayed; Fri, 10 Feb 1995 20:58:18 +0200 X400-Received: by /PRMD=fh-regensburg/ADMD=d400/C=de/; Relayed; Fri, 10 Feb 1995 20:58:18 +0200 Date: Fri, 10 Feb 1995 20:58:18 +0200 X400-Originator: alexander.sorg@rz.fh-regensburg.d400.de X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=fh-regensburg/ADMD=d400/C=de/;950210195818] X400-Content-Type: P2-1984 (2) Content-Identifier: 52 Alternate-Recipient: Allowed From: Alexander Sorg Message-ID: <52*/G=alexander/S=sorg/OU=rz/PRMD=fh-regensburg/ADMD=d400/C=de/@MHS> To: amiga-gcc-port@lists.funet.fi Subject: README-2.6.3 For users common to gcc a minor problem, but for a newcomer maybe a bigger one: In the "INSTALLATION" chapter is no hint, that the file gcc263-inclib.lha is needed too ;-) Greetings. From amiga-gcc-port-owner@nic.funet.fi Sat Feb 11 02:10:40 1995 Received: from desiree.teleport.com ([192.108.254.11]) by nic.funet.fi with SMTP id <91185-3>; Sat, 11 Feb 1995 02:06:13 +0200 Received: from kelly.teleport.com (markg@kelly.teleport.com [192.108.254.10]) by desiree.teleport.com (8.6.9/8.6.9) with ESMTP id QAA25946 for ; Fri, 10 Feb 1995 16:06:03 -0800 Date: Fri, 10 Feb 1995 16:06:03 -0800 From: "Mark C. Gay" Message-Id: <199502110006.QAA25946@desiree.teleport.com> To: amiga-gcc-port@lists.funet.fi Subject: list digest? Is it possible to recieved this list in a digested form? Sorry for being a bit off topic, I did check out the mailserv help files from funet but didn't see anything about it there. Thanks, --Mark From amiga-gcc-port-owner@nic.funet.fi Sat Feb 11 18:10:53 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91172-4>; Sat, 11 Feb 1995 18:08:36 +0200 Received: by theseas.ntua.gr with UUCP; Sat, 11 Feb 1995 18:02:56 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05xj@kriton.UUCP>; Fri, 10 Feb 95 23:43:10 EET Date: Fri, 10 Feb 95 23:43:10 EET Message-Id: <9502102143.05xj@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 836 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: libnix fread and fwrite are too slow The versions of fread and fwrite provided with libnix are extremely slow. For example, the following two programs: #include main() { int i; char c; for (i=0; i<10000; i++) { fread(&c, sizeof(c), 1, stdin); } return 0; } and #include main() { int i; char c=0; for (i=0; i<10000; i++) { fwrite(&c, sizeof(c), 1, stdout); } return 0; } take 7 and 11 seconds respectively to run on my amiga. The ixemul and SAS/C versions only take a fraction of a second. It looks to me that for some reason fread and fwrite have been implemented as unbuffered instead of buffered! -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I think I'll take this opportunity to remove my ears." ----- From amiga-gcc-port-owner@nic.funet.fi Sat Feb 11 18:12:56 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91169-2>; Sat, 11 Feb 1995 18:10:44 +0200 Received: by theseas.ntua.gr with UUCP; Sat, 11 Feb 1995 18:02:57 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05xe@kriton.UUCP>; Fri, 10 Feb 95 22:13:00 EET Date: Fri, 10 Feb 95 22:13:00 EET Message-Id: <9502102013.05xe@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 6277 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: stack checking! Here is a little hack I made that will add (I think!) stack checking to gcc-compiled code. WARNING! Use at your own risk. This has not been extensively tested, and could very well be completely wrong! What I've put together is a program, stackcheck, that will modify the assembly code produced by gcc to add stack checking, plus a module, stackcheck_setup.c, containing the required set-up and the stack overflow handler. To compile: flex stackcheck.l gcc -s -o stackcheck -O2 lex.yy.c -lfl gcc -c -O2 stackcheck_setup.c To use: Compile all C files as follows: gcc -S (options) -Dmain=stackcheck_main file.c stackcheck file.s gcc -c (cpu options) file.s (This can be semi-automated by adding an appropriate .c.o rule in your makefile.) Link: gcc (link options) stackcheck_setup.o files... What stackcheck does is to add the following code at the beginning of each function: cmpl __StackBottom,sp bccs .+8 jmp __StackOverflow (There's a more readable version #ifdef'ed out in the source, but I think this one is much easier to incorporate into gcc.) _StackBottom and _StackOverflow() are defined in stackchecksetup.c. _StackBottom is set to the bottom of the stack plus some leeway for subroutine arguments (128 bytes). _StackOverflow() sets the stack pointer to a sane value, prints an error message and exits. Even with stack checking, you cannot be completely safe, as overflows are detected on function entry, rather than during function execution. E.g., crash(){ char scribble[100000]; int i; for (i=0; i<100000; i++) scribble[i]=0; check(scribble); } check(char *x){} In the above example, stack overflow and its side-effects will occur in crash(), but it will be detected in check(), when it is too late. (The same thing happens with SAS/C's stack checking, BTW.) If this does indeed work, perhaps we could add the stack checking code into gcc and do away with the stackcheck program--Philippe, is it possible to add a -stackcheck option to gcc, which would add the above three lines to each function's prologue? -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "What do you think of that now, eh? A viking helmet!" "Uh, maybe." "What do you mean, maybe? What do you think it is, a space helmet for a cow?" ----- #!/bin/sh # This is a shell archive (produced by GNU sharutils 4.1). # To extract the files from this archive, save it to some FILE, remove # everything before the `!/bin/sh' line above, then type `sh FILE'. # # Made on 1995-02-10 21:45 EET by . # Source directory was `/Work/T/stackcheck'. # # Existing files will *not* be overwritten unless `-c' is specified. # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 1345 -rwxrwxrwx stackcheck.l # 511 -rwxrwxrwx stackcheck_setup.c # touch -am 1231235999 $$.touch >/dev/null 2>&1 if test ! -f 1231235999 && test -f $$.touch; then shar_touch=touch else shar_touch=: echo echo 'WARNING: not restoring timestamps. Consider getting and' echo "installing GNU \`touch', distributed in GNU File Utilities..." echo fi rm -f 1231235999 $$.touch # # ============= stackcheck.l ============== if test -f 'stackcheck.l' && test X"$1" != X"-c"; then echo 'x - skipping stackcheck.l (file already exists)' else echo 'x - extracting stackcheck.l (text)' sed 's/^X//' << 'SHAR_EOF' > 'stackcheck.l' && %{ #include #include X #define DATA 0 #define TEXT 1 X int mode = DATA; X main(int argc, char *argv[]) { X char buf[256]; X X if (argc != 2) { X fprintf(stderr, "Usage: %s file\n", argv[0]); X return RETURN_FAIL; X } X yyin = fopen(argv[1], "r"); X if (!yyin) { X fprintf(stderr, "Can't open %s\n", argv[1]); X return RETURN_FAIL; X }else{ X fclose(yyin); X } X strcpy(buf, argv[1]); X strcat(buf, ".BAK"); X unlink(buf); X if (rename(argv[1], buf)) { X fprintf(stderr, "Can't rename %s to %s\n", argv[1], buf); X return RETURN_FAIL; X } X yyin = fopen(buf, "r"); X yyout = fopen(argv[1], "w"); X yylex(); X fclose(yyin); X fclose(yyout); X unlink(buf); X return RETURN_OK; } %} %% ^\.data {mode = DATA; ECHO;} ^\.text {mode = TEXT; ECHO;} \.globl\ _[a-zA-Z_][a-zA-Z0-9_]*\n_[a-zA-Z_][a-zA-Z0-9_]*:\n { X char name1[256], name2[256]; X yytext[strlen(yytext)-2] = '\0'; X sscanf(yytext, "%s %s\n%s", name1, name1, name2); X fprintf(yyout, "%s:\n", yytext); X if (mode == TEXT) { X if (strcmp(name1, name2) == 0) { X fprintf(yyout,"\tcmpl __StackBottom,sp\n"); #if 0 X fprintf(yyout,"\tjcc __%s_OK\n", name1); X fprintf(yyout, "\tjmp __StackOverflow\n"); X fprintf(yyout, "__%s_OK:\n", name1); #else X fprintf(yyout, "\tbccs .+8\n"); X fprintf(yyout, "\tjmp __StackOverflow\n"); #endif X } X } } %% SHAR_EOF $shar_touch -am 0210205595 'stackcheck.l' && chmod 0777 'stackcheck.l' || echo 'restore of stackcheck.l failed' shar_count="`wc -c < 'stackcheck.l'`" test 1345 -eq "$shar_count" || echo "stackcheck.l: original size 1345, current size $shar_count" fi # ============= stackcheck_setup.c ============== if test -f 'stackcheck_setup.c' && test X"$1" != X"-c"; then echo 'x - skipping stackcheck_setup.c (file already exists)' else echo 'x - extracting stackcheck_setup.c (text)' sed 's/^X//' << 'SHAR_EOF' > 'stackcheck_setup.c' && #include #include #include X unsigned long _StackBottom; static unsigned long _StackOrig; X int main(int argc, char *argv[]) { X register unsigned long sp asm("sp"); X X _StackBottom = (unsigned long)FindTask(0L)->tc_SPLower + 128; X _StackOrig = sp; X return stackcheck_main(argc, argv); } X void _StackOverflow(void) { X register unsigned long sp asm("sp"); X X sp = _StackOrig; /* Restore stack to a sane value */ X fprintf(stderr, "Stack overflow\n"); X exit(RETURN_FAIL); } SHAR_EOF $shar_touch -am 0210203895 'stackcheck_setup.c' && chmod 0777 'stackcheck_setup.c' || echo 'restore of stackcheck_setup.c failed' shar_count="`wc -c < 'stackcheck_setup.c'`" test 511 -eq "$shar_count" || echo "stackcheck_setup.c: original size 511, current size $shar_count" fi exit 0 From amiga-gcc-port-owner@nic.funet.fi Sat Feb 11 21:17:12 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <91186-3>; Sat, 11 Feb 1995 21:14:52 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA00808; Sat, 11 Feb 95 12:16:13 MST Date: Sat, 11 Feb 1995 12:16:11 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: amiga-gcc-port@lists.funet.fi Subject: Possible c++ bug Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello all: I have come up with a small compilable example program that should demonstrate the "bug". Below is the program, and the result foloows. Program: -------------------------------------------------------------------- // Program to show possible gnu c++ bug. #include main () { char* test1 (char *); char x[10]; // send x array to a function to test for compiler bug. x = test1 (x); char * test1 (char a[]) { long i; // load the array with characters. for (i = 0; i < 10; i++) a[i] = (char) i; return (a); } ------------------------------------------------------------------- Results: g++ -m68020 -m68881 -v -O2 -Wall -c -o Testa.o Testa.cc gcc -m68020 -m68881 -v -O2 -Wall -c -o Testa.o Testa.cc Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc680 00 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -D__OPTIMIZE__ -Wall -D__HAVE_68881__ -Dmc68020 testa.cc T:cc114168.ii GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/lib/g++-include /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1plus T:cc114168.ii -quiet -dumpbase testa.cc -m68020 -m68881 -O2 -Wall -version -o T:cc114168.s GNU C++ version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3 snapshot 941209. testa.cc: In function `int main()': testa.cc:12: Internal compiler error. testa.cc:12: Please submit a full bug report to `bug-g++@prep.ai.mit.edu'. make: *** [Testa.o] Error 1 Paul Ney From amiga-gcc-port-owner@nic.funet.fi Sun Feb 12 12:03:38 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91189-2>; Sun, 12 Feb 1995 11:58:43 +0200 Received: by theseas.ntua.gr with UUCP; Sun, 12 Feb 1995 12:00:15 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05xx@kriton.UUCP>; Sun, 12 Feb 95 11:28:40 EET Date: Sun, 12 Feb 95 11:28:40 EET Message-Id: <9502120928.05xx@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 363 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: libnix scanf bug The libnix version of scanf() reads from stdout rather than stdin! (scanf() calls vscanf(), which calls vfscanf(stdout,format,args)) -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "The trouble with time-travel is one never seems to find the time." ----- From amiga-gcc-port-owner@nic.funet.fi Sun Feb 12 12:04:57 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91198-1>; Sun, 12 Feb 1995 12:00:13 +0200 Received: by theseas.ntua.gr with UUCP; Sun, 12 Feb 1995 12:00:13 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05y2@kriton.UUCP>; Sun, 12 Feb 95 11:46:54 EET Date: Sun, 12 Feb 95 11:46:54 EET Message-Id: <9502120946.05y2@kriton.UUCP> In-Reply-To: <2030b892.186a4-cls@opera.dragon.com> (from ) (at Sat, 11 Feb 95 17:44:53 EST) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 658 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: cls@opera.dragon.com Cc: amiga-gcc-port@lists.funet.fi Subject: Re: libnix fread and fwrite are too slow Hi cls (cls), in <2030b892.186a4-cls@opera.dragon.com> on Feb 11 you wrote: > This might be similar to a quirk I found for myself when using other > run time libraries on various other machines. Try changing your call > from: > > > fread(&c, sizeof(c), 1, stdin); > > to fread(&c, 1, sizeof(c), stdin); Given that sizeof(char) == 1, doing this would have absolutely no effect (it produces the same executable). -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "The trouble with time-travel is one never seems to find the time." ----- From amiga-gcc-port-owner@nic.funet.fi Sun Feb 12 16:29:48 1995 Received: from post.demon.co.uk ([158.152.1.72]) by nic.funet.fi with SMTP id <91199-4>; Sun, 12 Feb 1995 16:26:44 +0200 Received: from iceman.demon.co.uk by post.demon.co.uk id aa22349; 12 Feb 95 14:25 GMT Received: by iceman.demon.co.uk (V1.16/Amiga) id AA00075; Sun, 12 Feb 95 14:28:06 GMT Date: Sun, 12 Feb 95 14:28:06 GMT Message-Id: <9502121428.AA00074@iceman.demon.co.uk> Organization: wit's end with AmiTCP :( X-MailViewer: Mail 1.15 From: Graham Crowder To: amiga-gcc-port@nic.funet.fi Subject: ncurses availability? Hi. Mr.Fish responded to my question about availability of curses for GCC 263 (thanks again). This works, or so it seems (my Lynx project is stalled on the "free: start of block corrupt" problem detailed in another poster's submission "another bug" and followups). If and when I can fix that, the next problem is that Lynx can be built with FANCY_CURSES. This does not work with Mr.Fish's curses, several objects are undefined, eg. A_BOLD. I got the ncurses-1.8.6 distribution from ftp://ftp.netcom.com/pub/zm/zmbenhal/ncurses but I'm not clever enough to be able to port it to GCC/Amiga. I tried. Has anyone succeeded in this? TIA -- Graham Crowder: grahamc@iceman.demon.co.uk: grahamc@kmbcopps.demon.co.uk Amiga A1200/190MB HD/GVP A1230Turbo+SerII/68EC030/68882/10MB RAM/AmiTCP "Any sufficiently advanced technology is indistinguishable from magic" --- Arthur C Clarke From amiga-gcc-port-owner@nic.funet.fi Sun Feb 12 18:31:21 1995 Received: from ios.com ([198.4.75.44]) by nic.funet.fi with SMTP id <91211-3>; Sun, 12 Feb 1995 18:27:40 +0200 Received: (from rasta@localhost) by ios.com (8.6.9/8.6.9) id LAA20182; Sun, 12 Feb 1995 11:26:43 -0500 Date: Sun, 12 Feb 1995 11:26:43 -0500 (EST) From: "formerly freak@acy1.digex.net" Subject: Re: ncurses availability? To: Graham Crowder cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9502121428.AA00074@iceman.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 12 Feb 1995, Graham Crowder wrote: > Hi. Mr.Fish responded to my question about availability of curses for > GCC 263 (thanks again). This works, or so it seems (my Lynx project is > stalled on the "free: start of block corrupt" problem detailed in another > poster's submission "another bug" and followups). > > If and when I can fix that, the next problem is that Lynx can be built > with FANCY_CURSES. This does not work with Mr.Fish's curses, several > objects are undefined, eg. A_BOLD. I got the ncurses-1.8.6 distribution > from ftp://ftp.netcom.com/pub/zm/zmbenhal/ncurses but I'm not clever > enough to be able to port it to GCC/Amiga. I tried. > > Has anyone succeeded in this? > Well, I guess my problem has to do with curses too...whilst compiling something as a test I get a lot of stuff like this: screen.c:459 (t:cc0191441.o): Undefined symbol _putchr referenced from text segment screen.c:459 (t:cc0191441.o): Undefined symbol _tputs referenced from text segment I am also wondering if it is possible to link object files that were created by different conpilers, specifically GCC and SAS. I need to do this because I have a program with net code and the net.c file will only compile under SAS with the AmiTCP includes, but the rest of the program will only compile under GCC. *scream*. Anyway, I have tried to move over some of the AmiTCP includes to GCC but that is like opeining a can of worms. Thanx! From amiga-gcc-port-owner@nic.funet.fi Sun Feb 12 19:12:42 1995 Received: from carbon.cudenver.edu ([132.194.10.4]) by nic.funet.fi with SMTP id <91213-4>; Sun, 12 Feb 1995 19:11:15 +0200 Received: by carbon.cudenver.edu (5.65/DEC-OSF/1.2) id AA10360; Sun, 12 Feb 1995 10:14:57 -0700 Date: Sun, 12 Feb 1995 10:14:57 -0700 (MST) From: Brian Simmons To: amiga-gcc-port@nic.funet.fi Subject: Amiga guide docs problem Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The conversion from info files to guide files is not changing some of the links to .guide. (cpp.info and gdb.info to be exact). I typed: Amigaguide gcc.guide select "C++ Extensions" select "Standard Predefined Macros" and you get an error "couldn't locate cpp.info/Standard Predefined" But if you do Amigaguide cpp.guide and go to Macros/Predefined/Standard Predefined and there it is. I changed all the links #?.info to #?.guide (cpp.info,gdb.info). Shouldn't this be handled automatically? From amiga-gcc-port-owner@nic.funet.fi Sun Feb 12 22:19:48 1995 Received: by nic.funet.fi id <91187-3>; Sun, 12 Feb 1995 22:16:34 +0200 Subject: Re: list digest? From: Matti Aarnio To: markg@teleport.com (Mark C. Gay) Date: Sun, 12 Feb 1995 22:16:30 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi In-Reply-To: <199502110006.QAA25946@desiree.teleport.com> from "Mark C. Gay" at Feb 10, 95 04:06:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 1026 Message-Id: <95Feb12.221634+0200_eet.91187-3+17@nic.funet.fi> > Is it possible to recieved this list in a digested form? > > Sorry for being a bit off topic, I did check out the mailserv > help files from funet but didn't see anything about it there. No, that system (mailserver) "supports" this list by easing the list-owner's job on subscription tasks, but it does NOT participate in any way in message processing. That processing is essentially alias expansion without any other processing, thus the messages will not be filtered, or digested.. We are getting a Revised LISTSERV running on an Alpha/VMS (FIPORT.FUNET.FI), and plan to move LISTS.FUNET.FI to that machine. (At the moment we are doing "FUNTEST" list on it among 3-4 local FUNET persons. It behaves pretty well already.) We intend to move top-10 of nic.funet.fi/lists.funet.fi most popular lists to it. Yours among them :-) (Submission address will exist in here, as well as on lists.funet.fi -- aliases are easy redirectors..) > Thanks, > > --Mark /Matti Aarnio Postmaster From amiga-gcc-port-owner@nic.funet.fi Mon Feb 13 10:32:43 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91164-4>; Mon, 13 Feb 1995 10:28:41 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA00603; Mon, 13 Feb 95 10:25:48 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA11699; Mon, 13 Feb 95 10:28:46 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502130828.AA11699@hpcl.cti.gr> Subject: Re: mixing gcc ans SAS/C code To: rasta@ios.com (formerly freak@acy1.digex.net) Date: Mon, 13 Feb 1995 10:28:43 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: from "formerly freak@acy1.digex.net" at Feb 12, 95 11:26:43 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 879 > I am also wondering if it is possible to link object files that were > created by different conpilers, specifically GCC and SAS. I need to do Try compiling SAS programs using DATA=FAR CODE=FAR, then use the hunk2gcc program to convert the object files from amiga format to sun format. One problem with this approach would be with floating point code and with integer multiplication/division. If you can compile with CPU=68020 (or higher) and MATH=68881, then SAS/C will produce inline code, and you will have no problem. Otherwise, you'll have to grab the necessary modules from the SAS libraries and convert them to sun format as well. (Compiling with the option that produces code that uses utility.library, and linking with -lauto might alleviate the problem.) I hope this helps, -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Mon Feb 13 11:35:51 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91200-4>; Mon, 13 Feb 1995 11:30:52 +0200 Received: by colombo.telesys-innov.fr; Mon, 13 Feb 1995 10:29:30 +0100 From: Philippe BRAND Message-Id: <199502130929.KAA00910@colombo.telesys-innov.fr> Subject: Re: stack checking! To: kyrimis@theseas.ntua.gr Date: Mon, 13 Feb 1995 10:29:29 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9502102013.05xe@kriton.UUCP> from "Kriton Kyrimis" at Feb 10, 95 10:13:00 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 561 Kriton Kyrimis writes: > Here is a little hack I made that will add (I think!) stack checking to > gcc-compiled code. [...] > If this does indeed work, perhaps we could add the stack checking code > into gcc and do away with the stackcheck program--Philippe, is it > possible to add a -stackcheck option to gcc, which would add the above > three lines to each function's prologue? I'll try to integrate this into gcc. Thanks! Ps: and what about stack growing code ? ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Feb 13 13:01:06 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91180-4>; Mon, 13 Feb 1995 12:58:58 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Mon, 13 Feb 1995 11:40:30 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA18422; Mon, 13 Feb 95 11:33:00 +0100 Date: Mon, 13 Feb 95 11:33:00 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502131033.AA18422@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA01205; Mon, 13 Feb 95 11:32:51 +0100 To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@lists.funet.fi, Gunther Nikl Subject: stack checking! In-Reply-To: <9502102013.05xe@kriton.UUCP> References: <9502102013.05xe@kriton.UUCP> Kriton Kyrimis writes: > WARNING! > Use at your own risk. This has not been extensively tested, and could > very well be completely wrong! ... > X _StackBottom = (unsigned long)FindTask(0L)->tc_SPLower + 128; DANGER DANGER DANGER I'd write that warning even bigger, because the above code won't find your bottom of stack in all situations. Even worse it won't find it in the most common (program run from CLI) situations. How to find your stack size First: if SP is between tc_SPLower and tc_SPUpper, assume the above stack size and location and return. This will work with WorkBench launched programs in OS 1.2 -- 3.1. Otherwise: all you can hope is that you'we been lauched as CLI processes are normally launched, which means that your stack begins at pr_ReturnAddr and is of size (ULONG*)*pr_ReturnAddr. You should verify that SP is indeed between these bounds. (Yes, the shell (or Execute(), System() etc.) put the size of the stack in the stack itself at startup. If your shell doesn't do this, it's simply non-conformant and bad). This works from OS 1.2 -- 3.1. Otherwise: you're lost and don't even have an idea about the size of the stack the process launching you gave you. Set StackBottom to 0. That's how to do it. Thank BCPL for the weirdness. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de PS: I simply don't know if the above also works with OS 1.0 and 1.1 :-) From amiga-gcc-port-owner@nic.funet.fi Mon Feb 13 15:46:12 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91208-4>; Mon, 13 Feb 1995 15:35:05 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA10691; Mon, 13 Feb 95 15:32:10 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA15367; Mon, 13 Feb 95 15:35:04 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502131335.AA15367@hpcl.cti.gr> Subject: Re: stack checking! To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Mon, 13 Feb 1995 15:34:59 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) In-Reply-To: <199502130929.KAA00910@colombo.telesys-innov.fr> from "Philippe BRAND" at Feb 13, 95 10:29:29 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 155 > Ps: and what about stack growing code ? ;-) I'm working on it! -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Mon Feb 13 17:38:10 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91185-4>; Mon, 13 Feb 1995 17:26:51 +0200 Received: by colombo.telesys-innov.fr; Mon, 13 Feb 1995 16:18:15 +0100 From: Philippe BRAND Message-Id: <199502131518.QAA03364@colombo.telesys-innov.fr> Subject: Re: stack checking! To: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Date: Mon, 13 Feb 1995 16:18:13 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9502131335.AA15367@hpcl.cti.gr> from "Kriton Kyrimis" at Feb 13, 95 03:34:59 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 421 Kriton Kyrimis writes: > > Ps: and what about stack growing code ? ;-) > I'm working on it! One word: cooool. ;-) To avoid wasting bandwidth with such a reponse ;-) gcc-2.6.4-beta.lha is available on my site, and in a few minutes on the complete mirror nic.funet.fi. I even hadn't time to test it, too much busy this week-end... -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Feb 13 17:45:22 1995 Received: from m1.cs.man.ac.uk ([130.88.13.4]) by nic.funet.fi with SMTP id <91190-2>; Mon, 13 Feb 1995 17:34:58 +0200 Received: from n6h.cs.man.ac.uk by m1.cs.man.ac.uk (4.1/SMI-4.1:AL5l) id AA03390; Mon, 13 Feb 95 15:34:32 GMT Date: Mon, 13 Feb 95 15:34:31 GMT From: Eddie Message-Id: <9502131534.AA01287@n6h.cs.man.ac.uk> To: amiga-gcc-port@nic.funet.fi Subject: unsubscribe unsubscribe From amiga-gcc-port-owner@nic.funet.fi Mon Feb 13 20:24:42 1995 Received: from ios.com ([198.4.75.44]) by nic.funet.fi with SMTP id <91164-3>; Mon, 13 Feb 1995 20:17:43 +0200 Received: (from rasta@localhost) by ios.com (8.6.9/8.6.9) id NAA08695; Mon, 13 Feb 1995 13:14:16 -0500 Date: Mon, 13 Feb 1995 13:14:15 -0500 (EST) From: "formerly freak@acy1.digex.net" Subject: Re: mixing gcc ans SAS/C code To: kyrimis@theseas.ntua.gr cc: gcc In-Reply-To: <9502130828.AA11699@hpcl.cti.gr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 13 Feb 1995, Kriton Kyrimis wrote: > > I am also wondering if it is possible to link object files that were > > created by different conpilers, specifically GCC and SAS. I need to do > > Try compiling SAS programs using DATA=FAR CODE=FAR, then use the hunk2gcc > program to convert the object files from amiga format to sun format. Okay, that worked with no complaints. However, when I went to link: gcc -o myprog nicegcc1.o nicegcc2.o ..... netsas.o I got this rude response: ld: malformed input file (not rel or archive) netsas.o :( From amiga-gcc-port-owner@nic.funet.fi Mon Feb 13 20:38:51 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91188-3>; Mon, 13 Feb 1995 20:29:53 +0200 Received: by theseas.ntua.gr with UUCP; Mon, 13 Feb 1995 20:29:46 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05z7@kriton.UUCP>; Mon, 13 Feb 95 20:23:08 EET Date: Mon, 13 Feb 95 20:23:08 EET Message-Id: <9502131823.05z7@kriton.UUCP> In-Reply-To: <9502131033.AA18422@inf-wiss.uni-konstanz.de> (from hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle)) (at Mon, 13 Feb 95 11:33:00 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1553 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: hoehle@inf-wiss.uni-konstanz.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: stack checking! Hi Joerg-Cyril (Joerg-Cyril Hoehle), in <9502131033.AA18422@inf-wiss.uni-konstanz.de> on Feb 13 you wrote: > I'd write that warning even bigger, because the above code won't find > your bottom of stack in all situations. Even worse it won't find it in > the most common (program run from CLI) situations. On my machine (Kickstart version 37.175. Workbench version 38.12), a program that prints tc_SPLower, tc_SPUpper, and the current value of the stack pointer, showed that the stack pointer is always between tc_SPLower and tc_SPUpper in the following cases: Starting the program from the shell. Starting the program from the workbench. Starting the program using SystemTagList(). Starting the program using Execute(). Starting the program using ixemul's execle(). In all cases I ran the program with and without libnix's stack extension module, swapstack.o. I should think therefore that if there is a case where the stack is not between tc_SPLower and tc_SPUpper, it must be the exception rather than, as you say, the most common situation. Could you provide me with an example where my assumption is not true? (Remember, we are only talking about gcc-compiled programs and not about anything that is possible to run on an amiga. We are probably also talking about AmigaDOS 2.04 or later.) -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "You must *never* kill anyone with a role in recorded history if you can possibly avoid it." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Feb 13 20:41:43 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91172-1>; Mon, 13 Feb 1995 20:34:17 +0200 Received: by theseas.ntua.gr with UUCP; Mon, 13 Feb 1995 20:29:48 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05yx@kriton.UUCP>; Mon, 13 Feb 95 19:13:20 EET Date: Mon, 13 Feb 95 19:13:20 EET Message-Id: <9502131713.05yx@kriton.UUCP> In-Reply-To: <199502131518.QAA03364@colombo.telesys-innov.fr> (from Philippe BRAND ) (at Mon, 13 Feb 1995 16:18:13 +0100 (MEZ)) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 673 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@lists.funet.fi Subject: Re: stack checking! Hi Philippe (Philippe BRAND), in <199502131518.QAA03364@colombo.telesys-innov.fr> on Feb 13 you wrote: > Kriton Kyrimis writes: > > > > Ps: and what about stack growing code ? ;-) > > I'm working on it! > > One word: cooool. ;-) > > To avoid wasting bandwidth with such a reponse ;-) To avoid wasting even more bandwidth, "I'm working on it" was Stephen Hawking's comment on the Enterprise warp engine when he was touring the Start Trek studios at Paramount. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Things are only impossible until they're not." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Feb 13 20:59:01 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91198-1> convert rfc822-to-8bit; Mon, 13 Feb 1995 20:54:44 +0200 Received: by theseas.ntua.gr with UUCP; Mon, 13 Feb 1995 20:49:07 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <05ze@kriton.UUCP>; Mon, 13 Feb 95 20:41:02 EET Date: Mon, 13 Feb 95 20:41:02 EET Message-Id: <9502131841.05ze@kriton.UUCP> In-Reply-To: (from "formerly freak@acy1.digex.net" ) (at Mon, 13 Feb 1995 13:14:15 -0500 (EST)) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT Content-Length: 1171 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: rasta@ios.com Cc: amiga-gcc-port@lists.funet.fi Subject: Re: mixing gcc ans SAS/C code Hi formerly (formerly freak@acy1.digex.net), in on Feb 13 you wrote: > Okay, that worked with no complaints. However, when I went to link: > gcc -o myprog nicegcc1.o nicegcc2.o ..... netsas.o > > I got this rude response: > ld: malformed input file (not rel or archive) netsas.o This may sound stupid, but did you remember to rename hunk2gcc's output (files named obj.*.*) to something usable, e.g., netsas.o? If not, netsas.o is the original sc output, in which case ld was right to complain. BTW, you should also use sc's options NOSTACKCHECK and IDIR=GNU:include. If you are using any of sc's files, you might want to create a directory containing a copy of SAS's proto include directory, and compile using the options IDIR=myinclude IDIR=GNU:include, so that you get sc's prototypes and pragmas rather than the gcc inline functions that sc cannot compile. I hope this helps, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Killing your own clone is still murder." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Feb 13 21:08:12 1995 Received: by nic.funet.fi id <91184-1>; Mon, 13 Feb 1995 21:06:07 +0200 From: Leonard Norrgard To: rasta@ios.com CC: kyrimis@theseas.ntua.gr, amiga-gcc-port@nic.funet.fi In-reply-to: (rasta@ios.com) Subject: Re: mixing gcc ans SAS/C code Message-Id: <95Feb13.210607+0200_eet.91184-1+40@nic.funet.fi> Date: Mon, 13 Feb 1995 21:06:01 +0200 > Okay, that worked with no complaints. However, when I went to link: > gcc -o myprog nicegcc1.o nicegcc2.o ..... netsas.o > > I got this rude response: > ld: malformed input file (not rel or archive) netsas.o Which means that netsas.o isn't an object file in the format used by gcc, ie. netsas.o isn't the output of hunk2gcc. From amiga-gcc-port-owner@nic.funet.fi Mon Feb 13 22:30:51 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91206-3>; Mon, 13 Feb 1995 22:28:35 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0re7J5-0004naC; Mon, 13 Feb 95 15:23 EST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Binutils 2.5.1 for AMIGA To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Mon, 13 Feb 1995 13:23:39 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi, fnf@amigalib.com (Fred Fish) In-Reply-To: <199502061003.LAA02062@colombo.telesys-innov.fr> from "Philippe BRAND" at Feb 6, 95 11:03:40 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1583 > are the first results from porting binutils-2.5.1 to the AMIGA. > ... > The programs are not tested extensively, in fact all but the linker and > objdump, objcopy are nearly untested. > > The purpose of the archives is that they should be tested by someone, who has > more time than me. I thought I'd pass on the results of my testing so far. After Stephan got me the diffs against the baseline FSF source, I merged them forwards into binutils-2.5.2, built a copy of the tools, and then substituted the new linker for my previous stable 1.8.x version. I had to fix a couple of minor bugs, like one that affected C++ constructors, but I was able to rebuild and link most of my GNU tree. A couple exceptions are ixemul.library which requires the -fl linker option (flavors, which are unimplemented at the moment) and a bug in linking ghostscript which I'm currently tracking down. All in all, this is a *very* promising start and Stephan is to be congratulated. So far I've only banged on the linker, and other than the linker itself, haven't tried running many of the programs that the new linker generates. I.E. the linker is currently linked by itself to produce the same executable, and that one is what is running in my otherwise unchanged binary tree. I have several other steps to go through to incrementally install and test the various tools, but these will have to wait until sometime after I return from vacation around the end of the month. Before I leave I'll feed my diffs back to Stephan and Phillipe so progress can continue if they can find the time. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Feb 14 02:09:48 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <91172-2>; Tue, 14 Feb 1995 02:05:50 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189451>; Tue, 14 Feb 1995 01:05:24 +0100 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA23878; Tue, 14 Feb 1995 01:05:13 +0100 Date: Tue, 14 Feb 1995 01:05:13 +0100 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9502140005.AA23878@nereid.rz.Uni-Osnabrueck.DE> To: amiga-gcc-port@nic.funet.fi Subject: Abort! Sometimes, when a task or process sends a CRTL-D to another process, a Abort! requester is coming up. Clicking on the only button results in vanishing of that requester and a new one meets my eyes. I think this is the case when using libnix, but maybe I'm wrong. In other cases a ***abort is written to stderr. Is that reqester a substitution for the normal message of the signalhandler ? And is there a reason for being unable to escape from this requester (of course there is on says a physics law, but is the mistake on my site or is it general) ? -Thomas From amiga-gcc-port-owner@nic.funet.fi Thu Feb 16 10:38:08 1995 Received: from rc1.vub.ac.be ([134.184.15.1]) by nic.funet.fi with ESMTP id <91219-3>; Thu, 16 Feb 1995 10:28:53 +0200 Received: from is2e.vub.ac.be (lferette@is2e.bfu.vub.ac.be [134.184.15.6]) by rc1.vub.ac.be (8.6.8.1/3.4.1.ap (rc1)) id JAA18010; Thu, 16 Feb 1995 09:32:47 +0100 Received: by is2e.vub.ac.be (5.61/BFUCC-920211) id AA03241; Thu, 16 Feb 95 09:28:34 +0100 From: lferette@is1.vub.ac.be (Ferette L.) Message-Id: <9502160828.AA03241@is2e.vub.ac.be> Subject: make doesn't find gcc To: amiga-gcc-port@lists.funet.fi Date: Thu, 16 Feb 1995 09:28:32 +0100 (MET) X-Mailer: ELM [version 2.4 PL23c] Content-Type: text Content-Length: 454 Since I moved to gcc 2.6.*, make doesn't work anymore: it complains 'gcc: command not found' and aborts. It seems I can't tell make where to find commands. My PATH environment variable is set as should be, but it seems that make doesn't look at it (or doesn't find it). How do I tell make where to look for executables (ixconfig options and all). I should add that my shell is csh. Thanks for help, Lionel 'Mac Gyver' Ferette lferette@ulb.ac.be From amiga-gcc-port-owner@nic.funet.fi Thu Feb 16 14:17:07 1995 Received: from dfunms.rus.uni-stuttgart.de ([129.69.1.162]) by nic.funet.fi with SMTP id <91159-4>; Thu, 16 Feb 1995 14:05:47 +0200 Received: from ifr1.luftfahrt.uni-stuttgart.de by dfunms.rus.uni-stuttgart.de with SMTP id AA24139 (5.65c8/DFUE-M1.0 for ); Thu, 16 Feb 1995 13:05:32 +0100 Received: from ifr14 by ifr1.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-1.0NeXT+) id AA13448; Thu, 16 Feb 95 13:05:31 +0100 Message-Id: <9502161205.AA13448@ifr1.Luftfahrt.Uni-Stuttgart.DE> Received: by ifr14.Luftfahrt.Uni-Stuttgart.DE (NX5.67d/BelWue-S1.0NeXT+) id AA00810; Thu, 16 Feb 95 13:05:29 +0100 Date: Thu, 16 Feb 95 13:05:29 +0100 From: raimund@ifr.luftfahrt.uni-stuttgart.de Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: amiga-gcc-port@nic.funet.fi Subject: Gnat ? Hi folks, I saw the Gnat for Amiga on one of Fred Fishs CD, but because I have no CD drive it is hard to get new versions of this compiler. It is possible that the Gnat find his way to Aminet, not 1.8.3 but 2.0.x? I hope this is not the wrong address. Thanks Raimund From amiga-gcc-port-owner@nic.funet.fi Thu Feb 16 16:35:29 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91191-4>; Thu, 16 Feb 1995 16:25:46 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Thu, 16 Feb 1995 15:19:56 +0100 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA29476; Thu, 16 Feb 95 15:19:35 +0100 Date: Thu, 16 Feb 95 15:19:35 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502161419.AA29476@inf-wiss.uni-konstanz.de> Received: by mammern.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA11406; Thu, 16 Feb 95 15:17:32 +0100 To: amiga-gcc-port@nic.funet.fi Subject: ENV: and ixemul startup Hi, I might be completely wrong, but I've always thought that the scanning of ENV: that ixmeul does for programs using it is because that program _might_ use the extern char **environment; variable to access the environment instead of using getenv(). Now, why can't the ixemul libc contain a kind of auto setting a flag for this variable, which when linked in, will cause ixemul to scan ENV: but not scan it for the vast majority of the other programs which do not use it the above environment variable, thus the desired speed-up? Sounds simple, isnt'it? Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Feb 16 17:49:05 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91190-4>; Thu, 16 Feb 1995 17:35:22 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ae21323; 16 Feb 95 15:22 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA006vp; Thu, 16 Feb 95 14:30:20 GMT Date: Thu, 16 Feb 95 14:30:20 GMT Message-Id: <9502161430.AA006vo@flevel.demon.co.uk> Message-Id: <20372279.aae60-dev@flevel.demon.co.uk> In-Reply-To: <9502161205.AA13448@ifr1.Luftfahrt.Uni-Stuttgart.DE> (from raimund@ifr.luftfahrt.uni-stuttgart.de) (at Thu, 16 Feb 95 13:05:29 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: raimund@ifr.luftfahrt.uni-stuttgart.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Gnat ? Hi raimund, > Hi folks, > > I saw the Gnat for Amiga on one of Fred Fishs CD, but because I have > no CD drive it is hard to get new versions of this compiler. > It is possible that the Gnat find his way to Aminet, not 1.8.3 but > 2.0.x? Have you tried the frozen fish collection ftp site? I can't remember what it is but I'm sure Fred Fish will tell you. - Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Feb 16 19:02:02 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91169-4>; Thu, 16 Feb 1995 18:53:00 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 16 Feb 1995 18:39:33 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <0601@kriton.UUCP>; Thu, 16 Feb 95 18:34:54 EET Date: Thu, 16 Feb 95 18:34:54 EET Message-Id: <9502161634.0601@kriton.UUCP> In-Reply-To: <9502161419.AA29476@inf-wiss.uni-konstanz.de> (from hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle)) (at Thu, 16 Feb 95 15:19:35 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 892 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: hoehle@inf-wiss.uni-konstanz.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: ENV: and ixemul startup Hi Joerg-Cyril (Joerg-Cyril Hoehle), in <9502161419.AA29476@inf-wiss.uni-konstanz.de> on Feb 16 you wrote: > I might be completely wrong, but I've always thought that the scanning > of ENV: that ixmeul does for programs using it is because that program > _might_ use the > extern char **environment; A program _might_ also use the third argument of main, as in main(int argc, char **argv, char **envp) > Now, why can't the ixemul libc contain a kind of auto setting a flag > for this variable, which when linked in, will cause ixemul to scan Although it's probably possible to do something for environment, I don't think that anything can be done for envp. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "This must be Thursday. I never could get the hang of Thursdays!" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Feb 16 19:10:26 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91197-3>; Thu, 16 Feb 1995 19:04:23 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id aa23905; 16 Feb 95 17:02 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA006wr; Thu, 16 Feb 95 15:30:45 GMT Date: Thu, 16 Feb 95 15:30:45 GMT Message-Id: <9502161530.AA006wq@flevel.demon.co.uk> Message-Id: <2037309f.445c1-dev@flevel.demon.co.uk> In-Reply-To: <9502161419.AA29476@inf-wiss.uni-konstanz.de> (from Joerg-Cyril Hoehle ) (at Thu, 16 Feb 95 15:19:35 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: hoehle@inf-wiss.uni-konstanz.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ENV: and ixemul startup Hi Joerg-Cyril, > I might be completely wrong, but I've always thought that the scanning > of ENV: that ixmeul does for programs using it is because that program > _might_ use the > extern char **environment; > variable to access the environment instead of using getenv(). > > Now, why can't the ixemul libc contain a kind of auto setting a flag > for this variable, which when linked in, will cause ixemul to scan > ENV: but not scan it for the vast majority of the other programs which > do not use it the above environment variable, thus the desired speed-up? That sounds like a good idea. I not sure who is developing ixemul at the moment, maybe someone could ask him/her to takeup your suggestion. - Trefor S. From amiga-gcc-port-owner@nic.funet.fi Thu Feb 16 20:33:08 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <91200-3>; Thu, 16 Feb 1995 20:30:19 +0200 Received: from pp.dundee.ac.uk by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HN4KRQ5RG0000WSJ@FIPORT.FUNET.FI>; Thu, 16 Feb 1995 18:25:22 +0200 (EET) Received: from kappa.mic.dundee.ac.uk by pp.dundee.ac.uk with SMTP (PP); Thu, 16 Feb 1995 18:26:11 +0000 Received: from lewis.mic.dundee.ac.uk by kappa.mic.dundee.ac.uk (4.1/SMI-4.1) id AA24466; Thu, 16 Feb 95 18:33:31 GMT Date: Thu, 16 Feb 1995 18:15:38 +0000 From: gthorbur@mic.dundee.ac.uk Subject: Inline code in C++ To: amiga-gcc-port@FIPORT.FUNET.FI Message-id: <16648.9502161815@lewis.mic.dundee.ac.uk> Content-transfer-encoding: 7BIT X-Mts: smtp I had some definitions of (short) functions which I had decclared to be inline. It was of the sort- In header file: inline void function_name(); In the code: void function_name() { ... } This compiled ok with gcc 2.5.8 but when compiling with 2.6.3 (which I have just installed it would not work. The programs would compile externally (ie. g++ -c program_name.cc) but when it came to linking (ie. g++ progs.o .......) it generated an error. The error being : No definition in symbol table for function_name . I removed the inline keyword from these functions and it now compiles and runs properly. The Inline bit doesn't really bother me, I mean it works without but was I just missing a flag on compilation or do inline functions not work properly. thanks Gareth. p.s. I read the stuff on inlining headers in the 2.6.3 readme but was quite frankly confused. I know a fair bit about c++ but very little about compilers. From amiga-gcc-port-owner@nic.funet.fi Thu Feb 16 20:47:06 1995 Received: from carbon.daimi.aau.dk ([130.225.18.194]) by nic.funet.fi with SMTP id <91180-2>; Thu, 16 Feb 1995 20:43:46 +0200 Received: by carbon.daimi.aau.dk id AA27478 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Thu, 16 Feb 1995 19:43:10 +0100 Date: Thu, 16 Feb 1995 19:43:10 +0100 From: Lars Balker Rasmussen Message-Id: <199502161843.AA27478@carbon.daimi.aau.dk> To: amiga-gcc-port@nic.funet.fi In-Reply-To: <16648.9502161815@lewis.mic.dundee.ac.uk> (gthorbur@mic.dundee.ac.uk) Subject: Re: Inline code in C++ Reply-To: gnort@daimi.aau.dk gthorbur@mic.dundee.ac.uk wrote: >I had some definitions of (short) functions which I had decclared to be inline. >It was of the sort- > >In header file: > >inline void function_name(); > >In the code: > >void function_name() { >... >} The problem is that inline functions work like macros. That is, the entire definition must be in a header file, if you wish to use the inline function in more than one module. E.g. in your h-file: inline void function_name(void) { /* body of func */ } >The programs would compile externally (ie. g++ -c program_name.cc) but when it >came to linking (ie. g++ progs.o .......) it generated an error. Because the inline code must be known at compilation time of all the modules which uses it. >I removed the inline keyword from these functions and it now compiles and runs >properly. Yes, because now the function has external linkage, and can be called using normal C-call stategies :-) >p.s. I read the stuff on inlining headers in the 2.6.3 readme but was quite >frankly confused. I know a fair bit about c++ but very little about compilers. C++ has two (three) ways of inlining: The implicit one is where you specify a function body for a method inside the class : class foo { int sz; ... public: int size() { return sz; } ... } The explicit is used when you feel that'd clutter up your class-definition too much: class foo { int sz; ... public: inline int size(); ... } inline int size() { return sz; } The final one is of course, when inlining isn't used on a method, and for this, you need to be explicit :-) Regards, -- Lars Balker Rasmussen Click! From amiga-gcc-port-owner@nic.funet.fi Thu Feb 16 20:52:58 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91187-1>; Thu, 16 Feb 1995 20:50:43 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Thu, 16 Feb 1995 19:29:01 +0100 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA00261; Thu, 16 Feb 95 19:28:57 +0100 Date: Thu, 16 Feb 95 19:28:57 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502161828.AA00261@inf-wiss.uni-konstanz.de> To: kyrimis@theseas.ntua.gr, amiga-gcc-port@lists.funet.fi Subject: Re: ENV: and ixemul startup > From kriton!kyrimis@theseas.ntua.gr Thu Feb 16 17:53:04 1995 > main(int argc, char **argv, char **envp) > Although it's probably possible to do something for environment, I don't > think that anything can be done for envp. Why don't we simply kill that option (i.e. supply NULL, except if called through ixemul's exec*e())? I looked at a POSIX book today and it doesn't even mention that third argument to main(). What programs are using it? Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Fri Feb 17 01:31:46 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91184-4>; Fri, 17 Feb 1995 01:27:09 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Fri, 17 Feb 95 00:24 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Fri, 17 Feb 95 00:21 MET Message-Id: Subject: Re: ENV: and ixemul startup To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Fri, 17 Feb 1995 00:21:48 +0100 (MET) From: Walter Harms Cc: amiga-gcc-port@lists.funet.fi (amiga gcc-list) In-Reply-To: <9502161828.AA00261@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Feb 16, 95 07:28:57 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1126 > > > From kriton!kyrimis@theseas.ntua.gr Thu Feb 16 17:53:04 1995 > > > main(int argc, char **argv, char **envp) > > > Although it's probably possible to do something for environment, I don't > > think that anything can be done for envp. > > Why don't we simply kill that option (i.e. supply NULL, except if > called through ixemul's exec*e())? I looked at a POSIX book today and > it doesn't even mention that third argument to main(). > > What programs are using it? if i remember correctly its a defined extension of the ansi-standard. most compiler support is as optional argument but dont fill it with usefull envs. actualy its a very usefull think because here you can read your env-vars like TERM ,..... that reminds we something ... whats about a extention to include a tooltype-array in every WB-stated programm ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Feb 17 09:48:53 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91164-1>; Fri, 17 Feb 1995 09:45:38 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA07804; Fri, 17 Feb 95 09:43:19 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA01410; Fri, 17 Feb 95 09:46:25 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502170746.AA01410@hpcl.cti.gr> Subject: Re: ENV: and ixemul startup To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Fri, 17 Feb 1995 09:46:05 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9502161828.AA00261@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Feb 16, 95 07:28:57 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 784 > Why don't we simply kill that option (i.e. supply NULL, except if > called through ixemul's exec*e())? I looked at a POSIX book today and > it doesn't even mention that third argument to main(). It probably mentions something about a process' environment being in its stack. (Guess where envp is stored!) > What programs are using it? Who knows? And that's the point. Ixemul is supposed to allow you to compile out of the box as many UNIX programs as possible. I think we (including myself) should start using libnix for amiga programs, and keep ixemul only for unix ports (e.g., for gcc). One way to do this would be to make -noixemul the default, to force lazy people like me to use it. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Fri Feb 17 11:13:15 1995 Received: from ios.com ([198.4.75.44]) by nic.funet.fi with SMTP id <91163-1>; Fri, 17 Feb 1995 11:08:57 +0200 Received: (from rasta@localhost) by ios.com (8.6.9/8.6.9) id EAA04051; Fri, 17 Feb 1995 04:08:15 -0500 Date: Fri, 17 Feb 1995 04:08:14 -0500 (EST) From: "formerly freak@acy1.digex.net" Subject: Re: make doesn't find gcc To: "Ferette L." cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9502160828.AA03241@is2e.vub.ac.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 16 Feb 1995, Ferette L. wrote: > Since I moved to gcc 2.6.*, make doesn't work anymore: it complains > 'gcc: command not found' and aborts. It seems I can't tell make where to > find commands. My PATH environment variable is set as should be, but it seems > that make doesn't look at it (or doesn't find it). make sure you got: assign BIN: :gnu/bin somehwere in your user-startup. When you install GCC it should auto- install the user-startupadditions. From amiga-gcc-port-owner@nic.funet.fi Fri Feb 17 12:42:52 1995 Received: from mail.Germany.EU.net ([192.76.144.65]) by nic.funet.fi with ESMTP id <91194-4>; Fri, 17 Feb 1995 12:30:45 +0200 Received: by mail.Germany.EU.net with SMTP (8.6.5:29/EUnetD-2.5.1.d) via EUnet id LAA23798; Fri, 17 Feb 1995 11:32:19 +0100 Message-Id: <9502171026.AA01300@GWEU.softlab.de> Received: from H8 by GWEU.softlab.de with SMTP (5.65/GEN-1.1.8) via EUnet for [192.76.144.65] id AA01300; Fri, 17 Feb 95 11:26:10 +0100 Received: by H8 (1.37.109.4/16.2) id AA07827; Fri, 17 Feb 95 11:32:13 +0100 Date: Fri, 17 Feb 95 11:32:13 +0100 From: REH@softlab.de To: amiga-gcc-port@lists.funet.fi Subject: ENV: and ixemul startu Concerning the ongoing discussion about a third parameter in main() : > > main(int argc, char **argv, char **envp) > called through ixemul's exec*e())? I looked at a POSIX book today and > it doesn't even mention that third argument to main(). > What programs are using it? > if i remember correctly its a defined extension of > the ansi-standard. most compiler support is as optional We should not mix up POSIX with ANSI-C: POSIX today *uses* C or ANSI-C to define an operating system independent programming environment. It will move to a language-independent specification with language bindings for C, Ada, Fortran, ... in the near future. ANSI-C *is* the definition of C. It neither blesses nor forbids a third parameter of main(). The 3rd parameter of main, which is mentioned as a common extension is defined to be char *envp[]. But programs using envp as a third parameter are not *strictly conforming*. I have not seen many programs using it and would prefer to call getenv(), which by the way is also used by POSIX. Does anybody know how Amiga GNU-C implements envp resp. getenv()? Unfortunately the standards leave this issue *implementation dependent* . The interesting question is: what happens if the value of an environment variable changes while the program is running? Will that be reflected when I refer to envp[]? Or is envp a pointer to *my copy* on the stack and always gives me the environment at the time the program was invoked? Will I get the current value when I call getenv()? I don't have the GNU sources available on my Amiga, so maybe somebody can enlighten me? Anyway, if there is a difference, I think we must keep both methods of accessing the environment. Gerhard From amiga-gcc-port-owner@nic.funet.fi Fri Feb 17 15:29:27 1995 Received: from pp.dundee.ac.uk ([134.36.2.60]) by nic.funet.fi with ESMTP id <91243-3>; Fri, 17 Feb 1995 15:16:37 +0200 Received: from kappa.mic.dundee.ac.uk by pp.dundee.ac.uk with SMTP (PP); Fri, 17 Feb 1995 13:15:19 +0000 Received: from lewis.mic.dundee.ac.uk by kappa.mic.dundee.ac.uk (4.1/SMI-4.1) id AA29223; Fri, 17 Feb 95 13:22:36 GMT Message-Id: <19459.9502171304@lewis.mic.dundee.ac.uk> To: amiga-gcc-port@lists.funet.fi Subject: 68000 or 68020 binaries. Date: Fri, 17 Feb 95 13:04:39 +0000 From: gthorbur@mic.dundee.ac.uk X-Mts: smtp I have an amiga 1200 (ie 68020) with 4 mg ram and NO floating point chip. I have installed gcc 2.6.3 and used the 68000 versions not the 68020's because of my lack of a floating point chip. I was just reading through the installation script (I installed it by hand) and it says that if you have a 68020 and above then you should install the 68020 versions. It does not mention the need for an fpp. Which is correct - which version should I install 000 or 020. thanks gareth From amiga-gcc-port-owner@nic.funet.fi Fri Feb 17 23:45:27 1995 Received: from undergrad.math.uwaterloo.ca ([129.97.204.13]) by nic.funet.fi with SMTP id <91195-2>; Fri, 17 Feb 1995 23:42:12 +0200 Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57171-3>; Fri, 17 Feb 1995 16:40:29 -0500 Date: Fri, 17 Feb 1995 16:40:20 -0500 From: Nathaniel Myhre To: amiga-gcc-port@nic.funet.fi Subject: A few questions... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I recently installed the full gnu c/c++/objc compiler and I have a few questions. What are the differences between the options -m68020 and -mc68020? When I compile a c++ program with the -m68020 option I get an EMT TRAP when I try to do a cout on a float (where did float io go?), but -mc68020 seems to work just fine. The docs are no help at all here. How can you use amiga shared libraries other than the standard set supplied by Commodore? I have the iff library by Christian Weber and it seems to require some stubs in a linkable lib to work with gcc. What can I do? The math.h include file has the define: #define HUGE_VAL some_big_number which causes a float exception when used. I changed the define to #define HUGE_VAL FLT_MAX and everything is okay. Is this a problem that is known? Just for the record, I have an A1200 with 4 megs fast and no fpu. ----------------------------------------------------------- Nathaniel Myhre University of Waterloo, 4th year CS undergraduate nmmyhre@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~nmmyhre/ "Of all the things I lost, I miss my mind the most." ----------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Sun Feb 19 00:13:59 1995 Received: from assi.s-link.de ([193.98.225.250]) by nic.funet.fi with SMTP id <91184-4>; Sun, 19 Feb 1995 00:09:05 +0200 Received: by assi.s-link.de with smail (/\oo/\ Smail3.1.29.1 #29.26) id ; Sat, 18 Feb 95 23:27 MET To: amiga-gcc-port@nic.funet.fi Message-Id: From: s.zeiger@tecmania.mcnet.de (Stefan Zeiger) Path: multicom.mcnet.de!tecmania.mcnet.de!s.zeiger Organization: WWSP - Wizard Works Software Productions Subject: ObjectiveAmiga 0.1 available Date: Sat, 18 Feb 1995 12:28:28 +0100 X-Mailer: MicroDot 1.8 [REGISTERED 00030c] X-Gateway: ZCONNECT UO assi.s-link.de [UNIX/Connect v0.55] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-TELEFON: V+49-6188-2525 X-Z-POST: Seligenstaedter Weg 24, D-63796 Kahl X-Z-VIA: 19950218143815W+1@tecmania.mcnet.de X-Z-VIA: 19950218190533W+1@multicom.mcnet.de Lines: 8 I've just uploaded the first snapshot of ObjectiveAmiga (my Objective C runtime system & class libraries) to AmiNet. By the time you read this, it should be available as objam01.lha in dev/gcc. -- *Note:* My EMail addresses at tecmania will expire in a few weeks. Please use my new Internet address s.zeiger@laren.rhein-main.de. From amiga-gcc-port-owner@nic.funet.fi Sun Feb 19 05:00:23 1995 Received: from mach1.wlu.ca ([192.54.242.17]) by nic.funet.fi with SMTP id <91197-1>; Sun, 19 Feb 1995 04:57:20 +0200 Received: by mach1.wlu.ca (5.65/1.35) id AA04528; Sat, 18 Feb 95 21:58:18 -0500 From: mart4678@mach1.wlu.ca (Phil Martin u) Message-Id: <9502190258.AA04528@mach1.wlu.ca> Subject: Missing proto/ dir? To: amiga-gcc-port@nic.funet.fi (gcc Mailing List) Date: Sat, 18 Feb 95 21:58:18 EST X-Mailer: ELM [version 2.2 PL13] Hi. I'm just starting to get gcc up and running on my system. I got the NDUK-v39, and what I _thought_ was the complete gcc distribution, but I can't fing the proto/ and inline/ dirs from the gcc distribution. I downloaded the following files: info2guide.3.lha 5138 ----rwed 14-Jan-95 19:05:11 gcc263-base.lha 1030283 ----rwed 14-Jan-95 19:21:03 gcc263-c++-020.lha 1477098 ----rwed 14-Jan-95 19:44:00 gcc263-c++-020.readme 271 ----rwed 14-Jan-95 19:44:03 gcc263-c-020.lha 712000 ----rwed 14-Jan-95 19:55:07 gcc263-doc.lha 857320 ----rwed 14-Jan-95 20:08:30 gcc263-inclib.lha 1318762 ----rwed 14-Jan-95 20:28:41 gcc263-objc020.lha 622050 ----rwed 14-Jan-95 20:49:15 gcc263-readme.lha 37093 ----rwed 14-Jan-95 20:49:53 gcc263-utildoc.lha 848747 ----rwed 14-Jan-95 21:03:08 gcc263-utils.lha 998836 ----rwed 14-Jan-95 21:18:26 gccdoc.lha 1674382 ----rwed 14-Jan-95 21:44:03 gcctools-920420.lha 102158 ----rwed 14-Jan-95 21:45:42 ixem404lib.lha 380782 ----rwed 14-Jan-95 21:51:34 libg++-2.5.3.lha 751888 ----rwed 14-Jan-95 22:03:09 libnix.lha 154999 ----rwed 14-Jan-95 22:05:29 make-3.68.lha 85011 ----rwed 14-Jan-95 22:06:52 newgccstart.lha 47003 ----rwed 14-Jan-95 22:07:37 sipp.lha 151107 ----rwed 14-Jan-95 22:09:57 The documentation leads me to believe that gcc263-base.lha is supposed to hold these dirs, but I don't find them in there, and lha doesn't warn me that there's anything wrong with the archive. : Also, consider telling us what errors you get. That usually helps. Here are the errors I'm getting when trying to compile the empty.c program that comes with the CNet distribution: t:cc0949201.o: Undefined symbol _FindPort referenced from text segment t:cc0949201.o: Undefined symbol _OpenLibrary referenced from text segment t:cc0949201.o: Undefined symbol _CloseLibrary referenced from text segment t:cc0949201.o: Undefined symbol _PutMsg referenced from text segment t:cc0949201.o: Undefined symbol _WaitPort referenced from text segment t:cc0949201.o: Undefined symbol _GetMsg referenced from text segment t:cc0949201.o: Undefined symbol _DeleteFile referenced from text segment t:cc0949201.o: Undefined symbol _Open referenced from text segment t:cc0949201.o: Undefined symbol _FGets referenced from text segment t:cc0949201.o: Undefined symbol _FPuts referenced from text segment t:cc0949201.o: Undefined symbol _Close referenced from text segment t:cc0949201.o: Undefined symbol _FGets referenced from text segment t:cc0949201.o: Undefined symbol _FPuts referenced from text segment t:cc0949201.o: Undefined symbol _Close referenced from text segment t:cc0949201.o: Undefined symbol _FPuts referenced from text segment Am I right in thinking that this is because I'm missing protos/all.h? Thanks in advance for any help, -- Phil Martin. mart4678@mach1.wlu.ca GCS/S -d+ !p c++ u+ e+(*) m--- s-/++ n++ h-- f+ w+ t r- y?(**) "They'll leave you stripped of all that they can get to, And wait for you to come back again." From amiga-gcc-port-owner@nic.funet.fi Sun Feb 19 16:00:55 1995 Received: from post.demon.co.uk ([158.152.1.72]) by nic.funet.fi with SMTP id <91212-1>; Sun, 19 Feb 1995 15:57:13 +0200 Received: from iceman.demon.co.uk by post.demon.co.uk id aa29464; 19 Feb 95 13:56 GMT Received: by iceman.demon.co.uk (V1.16/Amiga) id AA000ac; Sun, 19 Feb 95 13:59:47 GMT Date: Sun, 19 Feb 95 13:59:47 GMT Message-Id: <9502191359.AA000ab@iceman.demon.co.uk> Organization: wit's end with AmiTCP :( X-MailViewer: Mail 1.15 From: Graham Crowder To: amiga-gcc-port@nic.funet.fi Subject: libnix or ixemul? Confused Hi folks, sorry for this pretty lame question. Am using GCC263 installed in a default manner AFAIK. Have added the CBM includes to GNU:os-include as subscribers have advised (thanks BTW). Am trying to port Lynx to the Amiga with AmiTCP. Lynx is a curses-oriented UNIX WWW browser. Compiling the application without explicitly doing anything about IXEMUL gives me an executable. It crashes when run, with a "Free: start of block corrupt" message. That has already been raised in this list by other people, under the subject "Another bug" I think. (I'd be interested if anyone has found the answer to this BTW.) Compiling the application with -noixemul in the gcc command line for _every_ module, each module compiles down to object correctly (it seems) but the final link phase gives a _large_ number of unresolved references. Some of these are : _sleep, _popen, _pclose, _putenv, _ioctl, _getpid, _getgroups, _geteuid, _kill and _sigprocmask. I've shortened this list :( I'm showing my ignorance here, but I thought from reading the docs that -noixemul automatically brought in necessary libraries. I do not have these errors with ixemul, only with libnix. Documentation suggests that ixemul should be used for UNIX-ish applications, and libnix for Amiga-ish ones. So am I on to a loser from the start? Sorry to ask such a novice question. I am not a C expert, nor an Amiga guru, and this project is the first decent one I've ever attempted on our beloved Amiga. TIA Graham -- Graham Crowder: grahamc@iceman.demon.co.uk: grahamc@kmbcopps.demon.co.uk Amiga A1200/190MB HD/GVP A1230Turbo+SerII/68EC030/68882/10MB RAM/AmiTCP "Any sufficiently advanced technology is indistinguishable from magic" --- Arthur C Clarke From amiga-gcc-port-owner@nic.funet.fi Sun Feb 19 16:28:51 1995 Received: from lamb.sas.com ([192.35.83.8]) by nic.funet.fi with SMTP id <91213-2>; Sun, 19 Feb 1995 16:24:38 +0200 Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA25693; Sun, 19 Feb 1995 09:24:29 -0500 Received: from cdevil.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA08769; Sun, 19 Feb 1995 09:24:11 -0500 Received: by cdevil.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA17268; Sun, 19 Feb 1995 09:24:10 -0500 From: James Cooper Message-Id: <199502191424.AA17268@cdevil.unx.sas.com> Subject: SAS/C & __USE_SYSBASE To: amiga-gcc-port@nic.funet.fi Date: Sun, 19 Feb 1995 9:24:10 EST X-Mailer: Elm [revision: 109.14] Hi, all. I just downloaded gcc 2.6.3 the other day, to see what I could do with it. However, before I even got it installed, I noticed an error! In the README-2.6.3 file, it states that you now have some compatibility with the SAS/C standard #define __USE_SYSBASE, then proceeds to describe it exactly BACKWARDS from the way it should be! By default, for backwards compatibility reasons, SAS/C will generate code that loads A6 from memory location 4 every time you call an exec function. By #defining the __USE_SYSBASE symbol, you change this behaviour to make it look for a global variable named 'SysBase' for each exec call. Hence the name, __USE_SYSBASE == 'Use SysBase instead of loading from address 4' I would suggest taking this out altogether, though. This symbol was only introduced to get around an anachronism in SAS/C, and has never really been used properly. 90% or more of SAS/C code doesn't include this symbol... By removing this symbol from the os-include/proto/exec.h file, that file is reduced to one much simpler. From amiga-gcc-port-owner@nic.funet.fi Sun Feb 19 16:49:06 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <91215-4>; Sun, 19 Feb 1995 16:45:56 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA03311; Sun, 19 Feb 95 07:47:17 MST Date: Sun, 19 Feb 1995 07:47:16 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: Graham Crowder Cc: amiga-gcc-port@nic.funet.fi Subject: Re: libnix or ixemul? Confused In-Reply-To: <9502191359.AA000ab@iceman.demon.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 19 Feb 1995, Graham Crowder wrote: > Hi folks, sorry for this pretty lame question. Am using GCC263 installed > in a default manner AFAIK. Have added the CBM includes to GNU:os-include > as subscribers have advised (thanks BTW). Am trying to port Lynx to the > Amiga with AmiTCP. Lynx is a curses-oriented UNIX WWW browser. > > Compiling the application without explicitly doing anything about IXEMUL > gives me an executable. It crashes when run, with a "Free: start of > block corrupt" message. That has already been raised in this list by > other people, under the subject "Another bug" I think. (I'd be interested > if anyone has found the answer to this BTW.) Where can I get a copy of the source for Lynx? I would like to compile it myself. > Compiling the application with -noixemul in the gcc command line for > _every_ module, each module compiles down to object correctly (it > seems) but the final link phase gives a _large_ number of unresolved > references. Some of these are : _sleep, _popen, _pclose, _putenv, > _ioctl, _getpid, _getgroups, _geteuid, _kill and _sigprocmask. I've > shortened this list :( The -noixemul option is used for compiling programs written expressly for the Amiga environment. It assumes you are going to use "standard" Amiga type libraries (in gcc form, of course). The ixemul library is for compiling programs written expressly for a UNIX environment, and thus it contains the modules you listed above. You should probably stick with this option (using ixemul) for compiling Lynx unless you want to make your own versions of the above UNIX modules. > I'm showing my ignorance here, but I thought from reading the docs > that -noixemul automatically brought in necessary libraries. I do not > have these errors with ixemul, only with libnix. Documentation suggests > that ixemul should be used for UNIX-ish applications, and libnix for > Amiga-ish ones. So am I on to a loser from the start? The problem you are having with the crash may be from a configuration error. I have my own selfish reasons for trying to compile a working version of Lynx, but I will see if I can get this resolved if you let me known where I can get the sources. Paul Ney From amiga-gcc-port-owner@nic.funet.fi Sun Feb 19 18:51:58 1995 Received: from mach1.wlu.ca ([192.54.242.17]) by nic.funet.fi with SMTP id <91209-3>; Sun, 19 Feb 1995 18:46:02 +0200 Received: by mach1.wlu.ca (5.65/1.35) id AA01972; Sun, 19 Feb 95 11:47:10 -0500 From: mart4678@mach1.wlu.ca (Phil Martin u) Message-Id: <9502191647.AA01972@mach1.wlu.ca> Subject: Re: Missing proto/ dir? To: amiga-gcc-port@nic.funet.fi (gcc Mailing List) Date: Sun, 19 Feb 95 11:47:09 EST X-Mailer: ELM [version 2.2 PL13] I wrote: >> Hi. I'm just starting to get gcc up and running on my system. I got the >> NDUK-v39, and what I _thought_ was the complete gcc distribution, but >> I can't fing the proto/ and inline/ dirs from the gcc distribution. > >Keep on searching... > >> >> I downloaded the following files: >> > >> gcc263-inclib.lha 1318762 ----rwed 14-Jan-95 20:28:41 >^^^^^^^^^^^^^^^^^^^^^^ > >This archive containes the "missing" files - >gnu/os-include/inline/*.h and gnu/os-include/proto/*.h. Thank you Mr (or is it Mrs? Forgive me if it is) Peltonen. I don't know how I missed it. However, the program I'm trying to compile refers to "proto/all.h" and "fctype.h", which I can't find anywhere, and installing hte proto/ and inline/ dirs into the gnu:os-include dir still left me with a bunch of these errors: t:cc5422321.o: Undefined symbol _FindPort referenced from text segment t:cc5422321.o: Undefined symbol _CreatePort referenced from text segment t:cc5422321.o: Undefined symbol _OpenLibrary referenced from text segment etc... The file I'm trying to compile _is_ written specifically for the Amiga, are there any command-line options I should be specifying? Thanks in advance, -- Phil Martin. mart4678@mach1.wlu.ca GCS/S -d+ !p c++ u+ e+(*) m--- s-/++ n++ h-- f+ w+ t r- y?(**) "Any girl in the world could have easily known me better, She said 'You're strange, but don't change,' and I let her." From amiga-gcc-port-owner@nic.funet.fi Sun Feb 19 19:18:26 1995 Received: from vinkku.hut.fi ([130.233.245.1]) by nic.funet.fi with SMTP id <91210-3>; Sun, 19 Feb 1995 19:14:33 +0200 Received: from lk-hp-6.hut.fi (lk-hp-6.hut.fi [130.233.244.37]) by vinkku.hut.fi (8.6.9/8.6.7) with ESMTP id TAA18925; Sun, 19 Feb 1995 19:14:24 +0200 Received: (tpeltone@localhost) by lk-hp-6.hut.fi (8.6.8.1/8.6.7) id TAA01711; Sun, 19 Feb 1995 19:14:23 +0200 Date: Sun, 19 Feb 1995 19:14:23 +0200 (EET) From: Teppo Peltonen To: Phil Martin u cc: gcc Mailing List Subject: Re: Missing proto/ dir? In-Reply-To: <9502191647.AA01972@mach1.wlu.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 19 Feb 1995, Phil Martin u wrote: > refers to "proto/all.h" and "fctype.h", which I can't find anywhere, Just a guess: in all.h all the proto -file are included. fctype.h - dunno what it is? I can't access my amiga right now. > dir still left me with a bunch of these errors: > > t:cc5422321.o: Undefined symbol _FindPort referenced from text segment > t:cc5422321.o: Undefined symbol _CreatePort referenced from text segment > t:cc5422321.o: Undefined symbol _OpenLibrary referenced from text segment > > etc... It would help a lot if you would tell what are the command line options that you are using. Are you linking with libamiga.a using the option -lamiga? Check this with option -v which tells gcc to show us which options are used and which libraries are linked. > The file I'm trying to compile _is_ written specifically for the Amiga, > Phil Martin. mart4678@mach1.wlu.ca Teppo Peltonen (Mr.) From amiga-gcc-port-owner@nic.funet.fi Sun Feb 19 19:56:35 1995 Received: from mach1.wlu.ca ([192.54.242.17]) by nic.funet.fi with SMTP id <91207-3>; Sun, 19 Feb 1995 19:54:49 +0200 Received: by mach1.wlu.ca (5.65/1.35) id AA08595; Sun, 19 Feb 95 12:55:59 -0500 From: mart4678@mach1.wlu.ca (Phil Martin u) Message-Id: <9502191755.AA08595@mach1.wlu.ca> Subject: Re: Missing proto/ dir? To: amiga-gcc-port@nic.funet.fi (gcc Mailing List) Date: Sun, 19 Feb 95 12:55:58 EST X-Mailer: ELM [version 2.2 PL13] >It would help a lot if you would tell what are the command >line options that you are using. Are you linking with >libamiga.a using the option -lamiga? Check this with option >-v which tells gcc to show us which options are used >and which libraries are linked. OK, here's the compiler output when I specify -lamiga -v, and nothing else: Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Dmc68010 empty.c t:cc542232.i GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1 t:cc542232.i -quiet -dumpbase empty.c -version -o t:cc542232.s GNU C version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3 snapshot 941209. empty.c: In function `main': empty.c:37: warning: assignment makes pointer from integer without a cast empty.c:56: warning: assignment makes pointer from integer without a cast empty.c:31: warning: return type of `main' is not `int' as -mc68010 -o t:cc5422321.o t:cc542232.s ld /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/gnu/lib -lamiga t:cc5422321.o -lgcc -lc -lgcc t:cc5422321.o: Undefined symbol _FindPort referenced from text segment t:cc5422321.o: Undefined symbol _OpenLibrary referenced from text segment and a bunch more of the "Undefined symbol _xxxx referenced from text segment" errors. Any ideas? -- Phil Martin. mart4678@mach1.wlu.ca GCS/S -d+ !p c++ u+ e+(*) m--- s-/++ n++ h-- f+ w+ t r- y?(**) "Crazy love must surely have this pain, If getting up means going down again." From amiga-gcc-port-owner@nic.funet.fi Mon Feb 20 02:01:46 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <91232-3>; Mon, 20 Feb 1995 01:58:33 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189483>; Mon, 20 Feb 1995 00:58:19 +0100 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA20805; Mon, 20 Feb 1995 00:58:10 +0100 Date: Mon, 20 Feb 1995 00:58:10 +0100 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9502192358.AA20805@nereid.rz.Uni-Osnabrueck.DE> To: amiga-gcc-port@nic.funet.fi From amiga-gcc-port-owner@nic.funet.fi Mon Feb 20 02:14:43 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <91234-3>; Mon, 20 Feb 1995 02:12:16 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189483>; Mon, 20 Feb 1995 01:12:07 +0100 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA24952; Mon, 20 Feb 1995 01:12:04 +0100 Date: Mon, 20 Feb 1995 01:12:04 +0100 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9502200012.AA24952@nereid.rz.Uni-Osnabrueck.DE> To: amiga-gcc-port@nic.funet.fi Subject: Re: Re: Missing proto/ dir? >ld /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/gnu/lib -lamiga t:>cc5422321.o -lgcc -lc -lgcc >t:cc5422321.o: Undefined symbol _FindPort referenced from text segment You possibly have specified the -lamiga before the filename, i.e. gcc -lamiga very_complex_hello.c ? I do the same fault (Ups) and I was told that the order of appearence is relevant. Of course it is (thanks Kriton!). Turn the options to gcc very_complex_hello.c -lamiga and everything works (I hope...). Thomas From amiga-gcc-port-owner@nic.funet.fi Mon Feb 20 02:25:14 1995 Received: from mach1.wlu.ca ([192.54.242.17]) by nic.funet.fi with SMTP id <91235-2>; Mon, 20 Feb 1995 02:22:37 +0200 Received: by mach1.wlu.ca (5.65/1.35) id AA00680; Sun, 19 Feb 95 19:23:45 -0500 From: mart4678@mach1.wlu.ca (Phil Martin u) Message-Id: <9502200023.AA00680@mach1.wlu.ca> Subject: Re: Re: Missing proto/ dir? To: amiga-gcc-port@nic.funet.fi (gcc Mailing List) Date: Sun, 19 Feb 95 19:23:44 EST X-Mailer: ELM [version 2.2 PL13] Thomas Radtke wrote: >You possibly have specified the -lamiga before the filename, i.e. >gcc -lamiga very_complex_hello.c ? >I do the same fault (Ups) and I was told that the order of appearence is >relevant. Of course it is (thanks Kriton!). Turn the options to >gcc very_complex_hello.c -lamiga and everything works (I hope...). Thank you very much, it worked. Now, time to get to work programming! Thanks to all who helped, -- Phil Martin. mart4678@mach1.wlu.ca GCS/S -d+ !p c++ u+ e+(*) m--- s-/++ n++ h-- f+ w+ t r- y?(**) "Like an ocean fish who swam upstream Through nets, by hooks, and hungry bears" From amiga-gcc-port-owner@nic.funet.fi Mon Feb 20 11:20:44 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91262-2>; Mon, 20 Feb 1995 11:14:40 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA29623 (5.65c-6/7.3w-FAU); Mon, 20 Feb 1995 10:14:11 +0100 Received: from faui8s4.informatik.uni-erlangen.de by immd8.informatik.uni-erlangen.de; id AA03247 (5.x/7.3w-FAU); Mon, 20 Feb 1995 10:14:10 +0100 Date: Mon, 20 Feb 1995 10:14:10 +0100 From: Tobias Ruland Message-Id: <9502200914.AA03247@immd8.informatik.uni-erlangen.de> Received: by faui8s4.informatik.uni-erlangen.de (4.1/SMI-4.1) id AA00676; Mon, 20 Feb 95 10:14:09 +0100 To: amiga-gcc-port@nic.funet.fi Subject: GDB high all is there a "ready-to-run"-compiled gdb for amigaos or do i have to download the gdb-sources from colombo/pub/gnu and compile it myself? do these sources compile under amigaos? c u tobias From amiga-gcc-port-owner@nic.funet.fi Mon Feb 20 11:26:13 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91211-1>; Mon, 20 Feb 1995 11:17:49 +0200 Received: by colombo.telesys-innov.fr; Mon, 20 Feb 1995 10:18:11 +0100 From: Philippe BRAND Message-Id: <199502200918.KAA22171@colombo.telesys-innov.fr> Subject: Re: ADA To: NEUMANN_BJOERN@DIODE.donut.ruhr.com (Bjoern Neumann) Date: Mon, 20 Feb 1995 10:18:10 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Bjoern Neumann" at Feb 19, 95 04:34:49 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 297 Bjoern Neumann writes: > do you know where i can find the gnat-compiler for amiga? > at ftp.telesys-innov.fr i cannot find it ;-( I have moved gnat to ftp.funet.fi, waiting for more disk space on my system. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Feb 20 13:20:11 1995 Received: by nic.funet.fi id <91164-2>; Mon, 20 Feb 1995 13:11:03 +0200 From: Leonard Norrgard To: tsruland@immd8.informatik.uni-erlangen.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9502200914.AA03247@immd8.informatik.uni-erlangen.de> (message from Tobias Ruland on Mon, 20 Feb 1995 10:14:10 +0100) Subject: Re: GDB Message-Id: <95Feb20.131103+0200_eet.91164-2+17@nic.funet.fi> Date: Mon, 20 Feb 1995 13:11:01 +0200 >is there a "ready-to-run"-compiled gdb for amigaos or do i have to no. >download the gdb-sources from colombo/pub/gnu and compile it myself? >do these sources compile under amigaos? yes. yes. However, gdb isn't ueful yet -- the port is incomplete. You can load files, disassemble, list source, set breakpoints, read the built in help, nothing else. From amiga-gcc-port-owner@nic.funet.fi Mon Feb 20 13:44:43 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91236-1>; Mon, 20 Feb 1995 13:31:16 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA09563 (5.65c-6/7.3w-FAU); Mon, 20 Feb 1995 12:30:46 +0100 Received: from faui8s4.informatik.uni-erlangen.de by immd8.informatik.uni-erlangen.de; id AA05562 (5.x/7.3w-FAU); Mon, 20 Feb 1995 12:30:46 +0100 Date: Mon, 20 Feb 1995 12:30:46 +0100 From: Tobias Ruland Message-Id: <9502201130.AA05562@immd8.informatik.uni-erlangen.de> Received: by faui8s4.informatik.uni-erlangen.de (4.1/SMI-4.1) id AA01541; Mon, 20 Feb 95 12:30:45 +0100 To: amiga-gcc-port@nic.funet.fi Subject: Re: GDB In-Reply-To: <95Feb20.131103+0200_eet.91164-2+17@nic.funet.fi> References: <9502200914.AA03247@immd8.informatik.uni-erlangen.de> <95Feb20.131103+0200_eet.91164-2+17@nic.funet.fi> reall Leonard Norrgard writes: > >is there a "ready-to-run"-compiled gdb for amigaos or do i have to > no. :-( aint there any ppl who need a debugger for gcc-generated files? > >download the gdb-sources from colombo/pub/gnu and compile it myself? > >do these sources compile under amigaos? > yes. yes. However, gdb isn't ueful yet -- the port is incomplete. > You can load files, disassemble, list source, set breakpoints, read > the built in help, nothing else. this sounds as if amiga-gdb isnt useful at all... :-( who's working on the amiga port? i'm using gdb on my solaris machine here quite often. that's why i'm missing gdb on my good old amiga at home... c u tobias -------------------------------------------------------------------------- Tobias Ruland MAIL: tsruland@immd8.informatik.uni-erlangen.de WWW: http://www8.informatik.uni-erlangen.de/~tsruland (german only, sorry) From amiga-gcc-port-owner@nic.funet.fi Mon Feb 20 14:16:48 1995 Received: from pp.dundee.ac.uk ([134.36.2.60]) by nic.funet.fi with ESMTP id <91186-3>; Mon, 20 Feb 1995 14:07:14 +0200 Received: from kappa.mic.dundee.ac.uk by pp.dundee.ac.uk with SMTP (PP); Mon, 20 Feb 1995 12:05:58 +0000 Received: from lewis.mic.dundee.ac.uk by kappa.mic.dundee.ac.uk (4.1/SMI-4.1) id AA09810; Mon, 20 Feb 95 12:13:09 GMT Message-Id: <26185.9502201155@lewis.mic.dundee.ac.uk> To: amiga-gcc-port@lists.funet.fi Subject: Templates cause crash in 2.6.3 Date: Mon, 20 Feb 95 11:55:08 +0000 From: gthorbur@mic.dundee.ac.uk X-Mts: smtp I recently tried to compile the following program in gcc/g++ 2.6.3 and they came up with a couple of errors and then crashed. My stack was set about 150000 and then upped to 250000 and still it crashed. These programs compiled ok with the 2.5.8 distribution - so what is wrong? I think the code is ok as I copied it from a book. It is basically just test code I used to see if templates work - it is probably meaningless. much obliged - gareth Code follows: The file main.cc #include #include "stack.h" int main() { stack intstack; cout << intstack << endl; } The file stack.h #ifndef STACKH #define STACKH #include typedef int boolean; const int TRUE = 1; const int FALSE = 0; template ostream& operator<<(ostream& strm,const T& obj) { obj.display(strm); return strm; } template class stack { private: T defaultvalue; int stackp; T item[maxsize]; public: stack(); ~stack(); void display(ostream& strm = cout) const; }; template stack::stack() { stackp = -1; defaultvalue = 0; } template stack::~stack() {} template void stack::display(ostream& strm) const { for (int i=0;i; Mon, 20 Feb 1995 14:26:07 +0200 Received: from kappa.mic.dundee.ac.uk by pp.dundee.ac.uk with SMTP (PP); Mon, 20 Feb 1995 12:24:56 +0000 Received: from lewis.mic.dundee.ac.uk by kappa.mic.dundee.ac.uk (4.1/SMI-4.1) id AA09908; Mon, 20 Feb 95 12:32:22 GMT Message-Id: <26315.9502201214@lewis.mic.dundee.ac.uk> To: amiga-gcc-port@lists.funet.fi Subject: templates crash. Date: Mon, 20 Feb 95 12:14:21 +0000 From: gthorbur@mic.dundee.ac.uk X-Mts: smtp Sorry - forgot to say I have an Amiga 1200 with extra 4Mgs Ram. In case it's of relevance. gareth From amiga-gcc-port-owner@nic.funet.fi Mon Feb 20 18:53:25 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91191-4>; Mon, 20 Feb 1995 18:47:56 +0200 Received: by colombo.telesys-innov.fr; Mon, 20 Feb 1995 17:47:57 +0100 From: Philippe BRAND Message-Id: <199502201647.RAA01979@colombo.telesys-innov.fr> Subject: Colombo is nearly dead, switching system To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 20 Feb 1995 17:47:52 +0100 (MEZ) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 357 Colombo, my FTP site is nearly down. One HD is now making more noise than the entire company workers at a soccer game :-((( I'm now swithing from this Compaq 386/33 to a new Dell 466XE and expect the job to be finished on Wednesday 22th. Sorry for any inconvenience. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Feb 20 20:27:54 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91163-2>; Mon, 20 Feb 1995 20:22:04 +0200 Received: by theseas.ntua.gr with UUCP; Mon, 20 Feb 1995 20:23:21 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <061e@kriton.UUCP>; Mon, 20 Feb 95 19:58:34 EET Date: Mon, 20 Feb 95 19:58:34 EET Message-Id: <9502201758.061e@kriton.UUCP> In-Reply-To: <199502201140.MAA17878@honshu.informatik.uni-rostock.de> (from Gunther Nikl ) (at Mon, 20 Feb 1995 12:40:12 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1595 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: gnikl@informatik.uni-rostock.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: stack checking! Hi Gunther (Gunther Nikl), in <199502201140.MAA17878@honshu.informatik.uni-rostock.de> on Feb 20 you wrote: > Ok, on your machine it works, but what proves it will work on every > machine? If you want be on the safe side than you should do the way No proof, but I *am* still waiting for an example that breaks the code I posted. (Interrupts, 680x0 exceptions, and all the other things mentioned on p.469 of the Libraries Reference Manual don't count.) > its documented. And the documentation says: the tc_SP* entries (except > tc_SPReg) should only be used for tasks. Programs invoked from a shell > have to use the value supplied on the stack. >From what I've seen in the documentation (Libraries and AmigaDOS manuals), I can't find any reference to tc_SP* being invalid for tasks. (Besides, aren't processes simply tasks with bits added?) As for getting the stack size of CLI processes from the stack, I've seen no reference to this in the AmigaDOS manual, so I suspect it is an undocumented feature. Now, it is easy to add a couple more lines of code to do some extra checking, but unless I am convinced that checking tc_SP* is not enough in 2.04+ (pointers to the CBM manuals will suffice), I would be reluctant to do so. Looking forward to your reply, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "A shabbily dressed little tramp usually encounters at least a minimum of resistance when trying to enter a zone of strictly regimented military security." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Feb 21 13:36:37 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91233-3>; Tue, 21 Feb 1995 13:27:57 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Tue, 21 Feb 1995 12:27:15 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02980; Tue, 21 Feb 95 12:27:10 +0100 Date: Tue, 21 Feb 95 12:27:10 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502211127.AA02980@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA00932; Tue, 21 Feb 95 12:26:50 +0100 To: amiga-gcc-port@nic.funet.fi Subject: stack location Hi, here is a little program I wrote back in 1990. This was written to show incredulous people that a CLI's process stack pointer was _not_ between SPUpper and SPLower, that the effective stack size for them _is_ found at *(ULONG*)pr_ReturnAddr and that the pr_StackSize field was _not_ indicating the current process stack size (but rather the size of some ancient BCPL thing using pr_StackBase), and that Lattice's way of finding the stack size was broken then (try to run some programs around FishDisk <300, I can't remember exact names). Now I ran this program again and found that at least in OS 3.1 and for simple CLIs, SP is between these two locations. So it would be nice if people with older systems could run this program and tell us what they get. However, what I've been saying since 1990 still applies: If you want to know the stack size, first look at SPLower and SPUpper, then at *pr_ReturnAddr, else complain. Works from 1.2 to 3.1. Do not use pr_StackSize. Ask Randell Jesup or other knowing people for more information. #include #include struct Task *FindTask(); int main(argc) int argc; { struct Task *t; struct Process *p; struct CommandLineInterface *cli; t=FindTask(NULL); p=(struct Process *)t; cli=p->pr_CLI<<2; printf("Current size %ld, @~ %lx\n", *((LONG *)p->pr_ReturnAddr),&argc); printf("Task:\tsize %ld, dn %lx, sp %lx, up %lx\n", (LONG)t->tc_SPUpper-(LONG)t->tc_SPLower, t->tc_SPLower,t->tc_SPReg,t->tc_SPUpper); printf("Proc:\tsize %ld, dn %lx, rt %lx\n", p->pr_StackSize,p->pr_StackBase<<2,p->pr_ReturnAddr); printf("CLI:\tdef %ld\n",cli->cli_DefaultStack<<2); return 0; } begin 644 thisstack.lha M'\TM;&@U+2$- !0%0 X'H/%2 "71H:7-S=&%C:[6M"QA[PO>ZQIMS3_[W M>?/CGTZNMR;(3F/HXV M(PFI?(G_RD]^4J>WQ%65P]R0+_,>-CY M/ NUOZ0!5C_67@KE*NB?-^$BZ &\T>893T'+]R24:Z,[FYSNVF.-0=G,H.LD M7O(EWO]B/=W?1^SJ;KHN]?;_K-1).Y+*B/Q?7^Z[IYG,,WWG59A[M(W=]/[. MI_7_M>=-Q1XGZ#G/SWE;B$#/FZQG:_Q.(Q/JW%/#:[XO5HS[7'(I14:%07Q^T+X]''2+ M?47*@O^YO:,<)_U P<";3B>Y?TK671]"9R*/H-PC*8CZCF,V%K/HX]0+!J'^ M8&3XALN#FG-IJ:!Z)C/EC_? 'U@#SNV#48GT0\JGJ&#UG!?)9M%H>M8=WKS/ M9=Z[9%_K*48S\!QW) '_D-)WGRH*(.6=46 M.#?.OZ4@J"FCD]!Y#M'NNN_8WY*F/?13-\#)17M[3%*PL>VL;H]:214184K' M )\ ^*\WI(T= U7']DD(?]!R\ZL$J!(<7A+OYM/L\F_I&A8/YYU)FX6#N@]\ M0:N^M.I=O+OIPUK"X("_X8_]#W+="(ZY0SZGS,AHVSN3X)T(.CD&\/=E?C85$)NQC\A/>'DF)V M,LE=STB@LP*%8.0/K(A&_:JKS[AD8(9&&W BZ6"XUV!C@S<:*N7=LJ8A&0F! M;@1.;4&JGW30@V#W/4*P/D>QPRQ!L_;E$&X\\^P,%'"E,Q^ICN MNE<['"$'25<6Y6,JZ?$Y>,9X:./L1S]5(K*@Z,J$^;,0 94VG LYU*8XW @] M($&RF^*>AK'R77@;A>L$%>P7A#A?='R;_M 4 M0J[#G^[LF"L+2L!Z&-;8F<5O<(K,%/*E/"_:)0\$P5HW $2.T9L*?$ M:50_9AQE1JC3@<:,2'QZLP\<] _ N!H'*#]W)OVMA$MP2X1,JX'LDL.I:PY. MPC]AE]BUTO\^H2S>P7KD6Y+9GHKG&3?+U\WC'MC(*9DX:FEDF6F>CC[ '%\G MW1,#81.5=! PEJ@UG[?#( ;=J!!]TE&;@8[9.-\S(&-"<9,Z\8^^3C?LUXQR MFK 8U61L;5:&PB,\L"9+2-4"/,K;]$E;;=E*/'=6CNHSX)G^%=CS]7@;7')F M1*@,9\8J V?K+^*HQ18YO&/>V5]]RZ?:J+2:PC-K^6,411AQC/S$K'1HW9?.L8#RQYF/$+@%J<'VQ[PU62 MU)X#[YJ)JEHT/K&>D L_YPL!G_@(\UE2-C"$T MV4\RYP#2V@W7LZNZ_+YCKKNHV79Z1H\]QV2[/Y)F3//BZHA5,0_3>ZKB8OQP ML;2/?XI'Q/W74=_+$MRV69=%N6R?7OAD/-T,OTA[A#W7-WN"3>!@F'CI\[!/ MFR24Q?YS\PS EE)#E_*>/F ;L$X?>%'G\8A1J_O;\0']ENNH6RQ7P!Z7#(PJ MTEW3W7X(=N6,.M\&9E3U=QE<-]@^?&@'L:_X)]$TTJM^]1^!Y&Y7Q^=,HM=.9+^ M9"RV;LS^1OW=-,NO?B7V3,DP:$I/!\_$[O0<%,7%Y_-LE=L"#.>F!W,S-$K?7II1WO_7+Q4 M;\2ATKMFQ7BB07FIDLJT'S)P[5!0&^+5FURCDOV0DOV9J'@B@W?<<*?7O*>L MXZ:3FN;G8E<(U*N?1$@GV L;%=0=B13*K]X)%M56W*9-=:W%3H*&/7[P-7II MJ[07IR_?/+((,2JF=._2^\,Z#LV!CSZ/VV8(<%6;F1\!$)KK5*A_TQ1KO5"O MH'A34%Y D^PEUJ.^&/@AX^11WS7Z1"Y^Q,Y#G+;KPK?<>I':T2[QL_#FT^ML M#I%7IK>>3$O/YK%YH?H)31HL2[V7<+DH,L#1HW](]'_&(K@2B<:8YY0Z=^5% M'5>-N'#P@39;AR;C;BB,->]A U4;5J#6>/WH4J MSUD*VG>R.],S>TG0+*F/OGUA!%DF5F=<'$J6/L"/?T@-D33&.X[3;=K,POZL^^T\1K6^,W&__5]]I!6\_'T_?S_V*^-I1M+_U7Q=+N*]- M57AO55>*Z.Q^X&QY%(;NCI42O3B9CM#M&X1V](C8BGC!#6ELFM>?.-'&F<9N M"C ^F,8L4P9J=B=2U:E4=GS3\0T_(DE9>GFD@(]&%('F(VB9DMV8X@R2B/5( M>G*/=_EBI%34LVD>25H%>^#(K)@4F3P0I?2/=\$,%*',**M53S:@6HC7VV2U MM8)'-5O[Z=24S1-B^4H]1I8=2"/VFGX(Y!]GQ!H61?>J:&D6@]6)A6V26)B- M2 D;(=CXLZD:Q%7J&E2)@)8.RV._*R2]MGA7">7#/FF0O,5A>8V8H$ MZC5F_(-UGJU-.DMP'_LO2/3/(;D"$#VM)_^X)EO*[6D_X,TENTKT3X:6G@/ M1YB"^_?U7M743O:3->];NC><.'@7O*GN5^%TQU1[W5L.\5T12XM0E\*I&SEI MV)LJD:^L[<:^&)L,7%).N%BO[6]H^L.WL:Y)C0_-D#MO"]_0O.?!M!J' :U1ZB(+S5[4[%^RD5 M) ?"=U8_[O'J-G.2V=B.-9S+U?FDQW:'^"+O4:OFU]?5K_<*.+;V"]9-IGCI MA/F1ETGB-"M67NK9O?"AU>(>ZZ;G)$?N$]#1.A[W/2=Z[-C_ASFHDCTQN&GI M6^K[^DS%D35L%%>U_U4*[NI=ZI^$#O.F/@RV'(5 C^)=L$3<[LZ0DZYIBS_T M+4<[\5]\,L:VAO:]X3&.X_SG?@63)' ME:I?7AO\YW1!?#,O^@7[=47\Z+_Q-%_.#M*H,?%*^6,^/K9PD7Z27;&%>1YA MZL8<_BI]8O,.'G_'^U!ZG.[B#3>/YVIH:Q6AX_]#Z$GE?03N&#WF'YFSG^3X M^)XV(?QKS_ICQ65/D2^6/\^#?P#__"/C:^14^1G$5DA4,%->)G_5'_TGOD[?<;GP7A'=>]]C;PBV]]N]MKMYO6D(V,_>0B MO\3#\C;:[S/)X>]/.LC>< >^$LC$Q3]PB\+QO,\K]H_S*#WO&H/$^WQL3$WO M Q4:I3V_TOS7B2H\[ZHU,>JXX"&H+6QH-2U- 0 IP( -=Z#Q4 MT:&ES MW'_=B M2BOC;W=AEG->"J 1MIOD0DU-9P)>6PZ*N?UF@W,J4>@E% +Z#U+#8P$K= 0+ M8-9F$\RKU$C\$).Y&&*[! A+":RH3"4=)HGK.1NP$(3X=YPFF7=[+&-1@6LD M:OQK@JUZRI/.A(84L :"F D9J4/A&7_L]Q9IYXGM%7X?T2BL*6RU]4LRAT8) M\-Z]U61PMJ6B&Y@K$0;5ZT>X$Y:3R$W]V?366S.FY)!8PCAAG\L7BT:L$,@, MK%/:I\P &]? end Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Tue Feb 21 13:59:32 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91231-1>; Tue, 21 Feb 1995 13:49:13 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Tue, 21 Feb 1995 12:48:44 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA03054; Tue, 21 Feb 95 12:48:42 +0100 Date: Tue, 21 Feb 95 12:48:42 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502211148.AA03054@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA00969; Tue, 21 Feb 95 12:48:42 +0100 To: amiga-gcc-port@nic.funet.fi Subject: tcla.library Hi, There seems to be some growing interest in Tcl/Tk ports for the Amiga. Tcl was ported back in 1990 to the Amiga by Karl Lehenbauer and posted to Usenet. There was a lot of discussion in comp.sys.amiga.tech then. In order not to let Karl's work get lost but and to make it usable as a basis for newer ports, I took my archived Tcl files and tested the demo. This archive contains the original .zoo archives from that date. The demo ran, had the usual 1.3->2.0 compatibility problems with assuming a fixed window border size, but at the exit, it GURU'ed. The file tcl-1990.(lha|readme) is currently being uploaded to ftp.funet.fi, incoming/programming/ directory. I don't know where it will be moved from there. Enjoy, Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Tue Feb 21 15:38:52 1995 Received: by nic.funet.fi id <91266-2>; Tue, 21 Feb 1995 15:23:10 +0200 From: Leonard Norrgard To: hoehle@inf-wiss.uni-konstanz.de CC: amiga-gcc-port@nic.funet.fi, amiga-adm@ftp.funet.fi In-reply-to: <9502211146.AA03047@inf-wiss.uni-konstanz.de> (hoehle@inf-wiss.uni-konstanz.de) Subject: Re: programming/tcl-1990.lha Message-Id: <95Feb21.152310+0200_eet.91266-2+14@nic.funet.fi> Date: Tue, 21 Feb 1995 15:22:58 +0200 > There seems to be some growing interest in Tcl/Tk ports for the Amiga. > Tcl was ported back in 1990 to the Amiga by Karl Lehenbauer and posted to ... > The file tcl-1990.(lha|readme) is currently being uploaded to > ftp.funet.fi, incoming/programming/ directory. I don't know where it > will be moved from there. I looked at this, it seems to be a slightly older version than what's available on Fish disk 447 (/pub/amiga/fish/ff401-500/ff447/TCL.lha on ftp.funet.fi). Have you looked at that? -- vinsci From amiga-gcc-port-owner@nic.funet.fi Tue Feb 21 16:16:43 1995 Received: by nic.funet.fi id <91268-1>; Tue, 21 Feb 1995 16:07:38 +0200 From: Leonard Norrgard To: laire@uni-paderborn.de Cc: mw@eunet.ch, amiga-gcc-port@nic.funet.fi In-reply-to: <199502081804.TAA24307@haegar2.uni-paderborn.de> (message from Ralph Schmidt on Wed, 8 Feb 1995 19:04:11 +0100 (MET)) Subject: Re: debugging formats, ixemul trap handler Message-Id: <95Feb21.160738+0200_eet.91268-1+24@nic.funet.fi> Date: Tue, 21 Feb 1995 16:07:25 +0200 Laire writes: > I have not the slightest clue why an OpenLibrary has to patch a custom > traphandler into a task field. If somebody wants to use a different > traphandler he should load it external like tnt and other incarnations. A brief look at the ixemul sources suggests that it's part of the BSD signal emulation. The same trap handler takes care of bus errors and other gurus. The code is hairy at best and incomprehensible at worst, making it quite a project to fix it -- still it's clear that something must be done in order to support debugging. The more complicated thing (?) would be to remove the traphandler from ixemul and replace it with standalone code that would catch traps and fix the signal code to work without it (or with the handler as a separate task). This would allow ixemul programs to be debugged by other debuggers than gdb as well as with gdb. It might be simpler to instead pick up the few references to STRC in the ixemul source and make them work as intended (it doesn't seem to work now). I suppose this was what Markus had in mind once... This would restrict debugging to debuggers that knew how to persuade the program being debugged to turn on its STRC flag. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Tue Feb 21 18:16:10 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91282-1>; Tue, 21 Feb 1995 18:04:39 +0200 Received: from puffin.cms.dmu.ac.uk (se1dp@puffin.cms.dmu.ac.uk [146.227.102.38]) by macondo.dmu.ac.uk (8.6.9/8.6.9) with ESMTP id QAA23587 for ; Tue, 21 Feb 1995 16:05:18 GMT Received: by puffin.cms.dmu.ac.uk (1.37.109.14/3.0.0.beta1) id AA031092595; Tue, 21 Feb 1995 16:03:15 GMT Date: Tue, 21 Feb 1995 16:03:15 +0000 (GMT) From: Derek Piper X-Sender: se1dp@puffin.cms.dmu.ac.uk To: GCC Mail List Subject: Help with GCC for Amiga Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I need some help with GCC and the includes for AmigaDOS 3.0. I have installed GCC Version 2.63 and also the Commodore include files but I am unable to get the examples in the Amiga C Encyclopedia to compile properly. I read somewhere that I need to run some sort of `fixincludes` script. I do not have this script and I do not know where it is. Is GCC incompatible with the 3.0 include files ? Has anybody had these problems before ? (I am new to this list) Cheers. Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Feb 21 20:04:11 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91290-3>; Tue, 21 Feb 1995 19:55:52 +0200 Received: by theseas.ntua.gr with UUCP; Tue, 21 Feb 1995 19:57:37 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <0626@kriton.UUCP>; Tue, 21 Feb 95 18:29:22 EET Date: Tue, 21 Feb 95 18:29:22 EET Message-Id: <9502211629.0626@kriton.UUCP> In-Reply-To: <9502211127.AA02980@inf-wiss.uni-konstanz.de> (from hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle)) (at Tue, 21 Feb 95 12:27:10 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1146 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: hoehle@inf-wiss.uni-konstanz.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: stack location Hi Joerg-Cyril (Joerg-Cyril Hoehle), in <9502211127.AA02980@inf-wiss.uni-konstanz.de> on Feb 21 you wrote: > here is a little program I wrote back in 1990. > > This was written to show incredulous people that a CLI's process stack > pointer was _not_ between SPUpper and SPLower, that the effective > Now I ran this program again and found that at least in OS 3.1 and for > simple CLIs, SP is between these two locations. So it would be nice if > people with older systems could run this program and tell us what they > get. It works fine under 2.1, too. > However, what I've been saying since 1990 still applies: If you want > to know the stack size, first look at SPLower and SPUpper, then at > *pr_ReturnAddr, else complain. Works from 1.2 to 3.1. Do not use > pr_StackSize. What I'm beiginning to suspect is that in 2.0 they fixed exec so that it always updates tc_SPlower and tc_SPUpper. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I haven't changed the course of history; indeed, I'm expressly forbidden so to do!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Feb 21 20:26:21 1995 Received: from chsun.eunet.ch ([146.228.10.15]) by nic.funet.fi with SMTP id <91189-2>; Tue, 21 Feb 1995 20:20:06 +0200 Received: from eunet.ch by chsun.eunet.ch (8.6.4/1.34) id TAA16598; Tue, 21 Feb 1995 19:20:25 +0100 Received: from localhost by eunet.ch (8.6.4/EUnet/CH-LEAF-0.3-SPECIAL) id TAA06685; Tue, 21 Feb 1995 19:21:26 +0100 From: mw@eunet.ch Message-Id: <199502211821.TAA06685@eunet.ch> Subject: Re: debugging formats, ixemul trap handler To: vinsci@nic.funet.fi (Leonard Norrgard) Date: Tue, 21 Feb 1995 19:21:25 +0100 (MET) Cc: laire@uni-paderborn.de, mw@eunet.ch, amiga-gcc-port@nic.funet.fi In-Reply-To: <95Feb21.160738+0200_eet.91268-1+24@nic.funet.fi> from "Leonard Norrgard" at Feb 21, 95 04:07:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1914 > Laire writes: Grin, laire at one of his favorite tasks, bashing ixemul.library :-) > A brief look at the ixemul sources suggests that it's part of the BSD > signal emulation. The same trap handler takes care of bus errors and > other gurus. The code is hairy at best and incomprehensible at worst, > making it quite a project to fix it -- still it's clear that something > must be done in order to support debugging. You got it, it's part of signal handling, and it's perfectly ok to use the trap handler vector. Note: I do *not* patch this vector globally, only tasks running under ixemul are "affected". This is perfectly legal. > The more complicated thing (?) would be to remove the traphandler > from ixemul and replace it with standalone code that would catch > traps and fix the signal code to work without it (or with the handler > as a separate task). This would allow ixemul programs to be debugged > by other debuggers than gdb as well as with gdb. And have ixemul processes somehow register and deregister with that handler? This sounds pretty hairy to me, too... > It might be simpler to instead pick up the few references to STRC in > the ixemul source and make them work as intended (it doesn't seem to > work now). I suppose this was what Markus had in mind once... This > would restrict debugging to debuggers that knew how to persuade the > program being debugged to turn on its STRC flag. Sounds better in my ears.. Anyway, do what you want to that source, I really don't need it any longer, now that I have the real thing :-) I'll still try to answer questions though, if you feel like asking :-) -Markus -- EUnet Switzerland Tel: +41 1 291 45 80 Markus Wild Zweierstrasse 35 Hotline: +41 1 291 45 60 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH >Solaris 2 is not an upgrade from Solaris 1. They just want you to THINK it is. From amiga-gcc-port-owner@nic.funet.fi Tue Feb 21 20:38:12 1995 Received: by nic.funet.fi id <91294-3>; Tue, 21 Feb 1995 20:34:30 +0200 From: Leonard Norrgard To: mw@eunet.ch CC: amiga-gcc-port@nic.funet.fi In-reply-to: <199502211821.TAA06685@eunet.ch> (mw@eunet.ch) Subject: Re: debugging formats, ixemul trap handler Message-Id: <95Feb21.203430+0200_eet.91294-3+31@nic.funet.fi> Date: Tue, 21 Feb 1995 20:34:26 +0200 Markus writes: > > program being debugged to turn on its STRC flag. > I'll still try to answer questions though, if you feel like asking :-) No particulars yet, but perhaps you remember how you had planned to implement/finnish the STRC stuff? How much is missing really? From amiga-gcc-port-owner@nic.funet.fi Wed Feb 22 08:30:44 1995 Received: from virginia.edu ([128.143.2.7]) by nic.funet.fi with SMTP id <91159-4>; Wed, 22 Feb 1995 08:22:58 +0200 Received: from k30hadastra by uvaarpa.virginia.edu id aa06451; 22 Feb 95 1:22 EST Received: by adastra.cvl.va.us (V1.17-beta/Amiga) id <3spa@adastra.cvl.va.us>; Tue, 21 Feb 95 22:20:13 EDT Date: Tue, 21 Feb 95 22:20:13 EDT Message-Id: <9502220220.3spa@adastra.cvl.va.us> In-Reply-To: <9502131823.05z7@kriton.UUCP> from Kriton Kyrimis at Mon, 13 Feb 95 20:23:08 EET X-Mailer: GMail 0.53 (11.2.95) From: "Michael B. Smith" To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: stack checking! > Hi Joerg-Cyril (Joerg-Cyril Hoehle), in <9502131033.AA18422@inf-wiss.uni-konstanz.de> on Feb 13 you wrote: > > I'd write that warning even bigger, because the above code won't find > > your bottom of stack in all situations. Even worse it won't find it in > > the most common (program run from CLI) situations. > > On my machine (Kickstart version 37.175. Workbench version 38.12), a > program that prints tc_SPLower, tc_SPUpper, and the current value of the > stack pointer, showed that the stack pointer is always between > tc_SPLower and tc_SPUpper in the following cases: > > Starting the program from the shell. > Starting the program from the workbench. > Starting the program using SystemTagList(). > Starting the program using Execute(). > Starting the program using ixemul's execle(). The more relevant test is what Shell is being used. As of 2.0+, the C= Shell uses RunCommand() in all cases to set SPUpper and SPLower, and does it how you expect. However, WShell has a (in)famous bug where it does not in all cases. > In all cases I ran the program with and without libnix's stack extension > module, swapstack.o. > > I should think therefore that if there is a case where the stack is not > between tc_SPLower and tc_SPUpper, it must be the exception rather than, > as you say, the most common situation. Could you provide me with an > example where my assumption is not true? (Remember, we are only talking > about gcc-compiled programs and not about anything that is possible to > run on an amiga. We are probably also talking about AmigaDOS 2.04 or > later.) Well, it depends on whether using WShell is considered an exception. I wouldn't. The requirement for _not_ using SPLower and SPUpper for CLI tasks is given in: Bantam AmigaDOS Manual, First Edition, page 160 Bantam AmigaDOS Manual, Second Edition, page 166 Bantam AmigaDOS Manual, Third Edition, page 171 They say, and I quote: "...AmigaDOS obtains this stack from the general free memory heap just before you run the program; it is not, however, the same as the stack that the CLI uses. AmigaDOS pushes a suitable return address onto the stack that tells the CLI to regain control and unload your program. Below this on the stack at 4(SP) is the size of the stack in bytes, which may be usable to you if you wish to perform stack checking." You access that by *(pr->pr_ReturnAddr) where "pr" is a pointer to a CLI "struct Process *". I would also modify the "which may be usable" to "which you must use". Thus, for a CLI, tos = (char *)pr->pr_ReturnAddr + sizeof (ULONG); stk = *(ULONG *)pr->pr_ReturnAddr; bos = tos - stk; Where "tos" is "top of stack", "stk" is "stack size" and "bos" is "bottom of stack". Available stack is the offset from bos to SP. For more detailed, and extremely worthwhile information on this subject, refer to "The Amiga GURU Book" by Ralph Babel, section 2.1.2.1., pp 41-42. -- // Michael B. Smith \X/ mbs@adastra.cvl.va.us -or- uunet.uu.net!virginia.edu!adastra!mbs From amiga-gcc-port-owner@nic.funet.fi Wed Feb 22 14:53:08 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <91163-3>; Wed, 22 Feb 1995 14:41:42 +0200 Received: by nmrc.ucc.ie (8.6.8.1/8.6.6) with ESMTP id MAA24193 for ; Wed, 22 Feb 1995 12:41:07 GMT From: Lars Hecking Message-Id: <199502221243.MAA10205@mostar.nmrc.ucc.ie> Subject: "Free: start of block corrupt": a suggestion To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Wed, 22 Feb 1995 12:43:39 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1364 Recently, I stumbled across . From the man page: GC_malloc and GC_free are plug-in replacements for standard malloc and free. However, GC_malloc will attempt to reclaim inaccessible space automaticaly by invoking a conservative garbage collector at appropriate points. The collector traverses all data structures accessible by following pointers from the machines registers, stack(s), data, and bss segments. Inaccessible structures will be reclaimed. A machine word is considered to be a valid pointer if it is an address inside an object allocated by GC_malloc or friends. The package has been ported to SAS/C 6.x, but it shouldn't be too much of an effort to make this work with gcc. The package has a lot of nice debugging capabilities and I suggest that people porting new stuff (like lynx; sorry, forgot who this was ;) use this package to trace memory leaks/corruption of the application program. I can't think of a feasible way to do this right now, but maybe the GC package could also be used to debug ixemul? Stirring the pool, ;) Lars -- Lars Hecking | National Microelectronics Research Centre lhecking@nmrc.ucc.ie | Cork, Ireland |------------------------------------------- | "Victims ... Aren't we all?" -- Eric Draven From amiga-gcc-port-owner@nic.funet.fi Wed Feb 22 15:39:33 1995 Received: from eeyore.INS.CWRU.Edu ([129.22.8.17]) by nic.funet.fi with ESMTP id <91187-1>; Wed, 22 Feb 1995 15:27:19 +0200 Received: (cz253@localhost) by eeyore.INS.CWRU.Edu (8.6.8.1+cwru/CWRU-2.1-bsdi) id IAA21510; Wed, 22 Feb 1995 08:26:58 -0500 (from cz253) Message-Id: <199502221326.IAA21510@eeyore.INS.CWRU.Edu> Date: Wed, 22 Feb 1995 08:26:58 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: sh ? Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) This question is not really relevant to the gcc porting effort, but is relevant to the somewhat awkward joining of unix and amiga dos. What I am trying to do is run an amigados program, LS Version 4.7ljr, in the shell 'sh'. It runs fine, but...the listing has '\n' appended on the end of each entry. Here's the command line: # ls -cRaTF "%p %10s %25n %C\n" Anyone know how I can get the '\n' to do what it is supposed to do, like print a newline instead of the character representation? Thanx in advance. .....Dave From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 10:43:24 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91184-4>; Thu, 23 Feb 1995 10:39:43 +0200 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA06902 (5.65c-6/7.3w-FAU); Thu, 23 Feb 1995 09:39:31 +0100 Received: from pctc.chemie.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA28861 (5.65c-6/7.3m-FAU); Thu, 23 Feb 1995 09:39:28 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA11338; Thu, 23 Feb 1995 09:39:20 +0100 Date: Thu, 23 Feb 1995 09:39:20 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9502230839.AA11338@pctc.chemie.uni-erlangen.de> To: amiga-gcc-port@lists.funet.fi Subject: problem with system() Hello, recently I tracked down a strange behavior while using using gcc compiled programs. The system() command does not work in all cases. Here the small program called simple.c --- cut here, begin of simple.c ------- int main (int argc, char **argv) { system (argv[1]); } --- cut here, end of simple.c --------- used shell: sh from the gcc263* archives. how I compiled it with amiga gcc2.6.3: sh> gcc -o simple simple.c then I tried the command sh> simple ls It silently does nothing !!!! Then I tried the same command from an Amiga CLI and I got the wanted directory listing. Trying it from csh (V5.39) it works well, too. If I compile it with gcc -noixemul -o simple simple.c it runs fine in all cases. Used AmigaDOS: 3.1 Kickstart: 40.63 Workbench: 40.42 Can anybody explain this ?!?!? Bye and thank you for any hints -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwarz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 11:45:24 1995 Received: from zaz.kom.auc.dk ([130.225.51.10]) by nic.funet.fi with SMTP id <91212-2>; Thu, 23 Feb 1995 11:38:04 +0200 Received: from skoda.kom.auc.dk by zaz.kom.auc.dk with smtp (Smail3.1.28.1 #2) id m0rhZzc-000DIeC; Thu, 23 Feb 95 10:37 MET Received: by skoda.kom.auc.dk (Smail3.1.28.1 #2) id m0rhZzc-0006XSC; Thu, 23 Feb 95 10:37 MET Message-Id: Date: Thu, 23 Feb 95 10:37 MET From: jds@kom.auc.dk (Jes Degn Soerensen) To: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Cc: amiga-gcc-port@lists.funet.fi Subject: problem with system() In-Reply-To: <9502230839.AA11338@pctc.chemie.uni-erlangen.de> References: <9502230839.AA11338@pctc.chemie.uni-erlangen.de> Thomas Walter writes: > > Hello, > recently I tracked down a strange behavior while using using > gcc compiled programs. > The system() command does not work in all cases. > > Here the small program called simple.c > > --- cut here, begin of simple.c ------- > > int > main (int argc, char **argv) > { > system (argv[1]); > } > > > --- cut here, end of simple.c --------- > > > used shell: sh from the gcc263* archives. > > how I compiled it with amiga gcc2.6.3: > > sh> gcc -o simple simple.c > > then I tried the command > > sh> simple ls > > It silently does nothing !!!! > > Then I tried the same command from an Amiga CLI and I got the wanted > directory listing. > Trying it from csh (V5.39) it works well, too. > > If I compile it with > > gcc -noixemul -o simple simple.c > > it runs fine in all cases. > > Used AmigaDOS: 3.1 > Kickstart: 40.63 > Workbench: 40.42 > > Can anybody explain this ?!?!? > > Bye and thank you for any hints I'm not sure, but I guess gcc runs the programs using the $PATH env-variable. Remember there is a difference between the Amiga's path system, and the $PATH variable. Try setting your $PATH to where you got your ls command, ie Set PATH=/bin:/c:/usr/bin:. (just like under UN*X). Remember the last '.' means the current directory. Jes From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 13:01:53 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91169-1>; Thu, 23 Feb 1995 12:53:29 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Thu, 23 Feb 1995 11:33:09 +0100 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA11271; Thu, 23 Feb 95 11:33:08 +0100 Date: Thu, 23 Feb 95 11:33:08 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502231033.AA11271@inf-wiss.uni-konstanz.de> Received: by mammern.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA22158; Thu, 23 Feb 95 11:30:56 +0100 To: Paul Ney Cc: amiga-gcc-port@lists.funet.fi Subject: Re: ixconfig causes enforcer hits In-Reply-To: References: <9501101226.AA08584@inf-wiss.uni-konstanz.de> [Sorry for taking so much time to respond to this one] Paul Ney writes: > > > I just had something strange happen. I was trying to set ixemul.library > > > configuration using ixconfig and started getting some enforcer hits. > > > > Maybe you are using the wrong ixconfig program for this ixemul.library? > > > > Unluckily, R. Luebbert removed the 4 bytes of ARPBase dummy in the > > library base in 40.4, causing older ixconfig to touch the wrong bits. I > > really hope that he will put a long dummy in for 40.5, as that would > > again make most ixconfigs around compatible with almost any > > ixemul.library. > > I am currently using the ixconfig distributed with gcc 2.6.3. Is this > the wrong one to use? If so, which one should I be using? I checked it now: ixemul263.library claims to be version 40.4. It's of a different size than other 40.4 libraries I have. ixconfig263 is the one that was distributed with ixemul40.2, so it just gets the bad offset, poking a wrong address, causing follow-up Enforcer hits in other programs :-( I really hope that Fred, Rafael, Leonard and the other people working on ixemul put those 4 bytes previously used by ArpBase back in for 40.5 or 40.6 (ULONG ixemul_unused_ArpBase or whatever). This incompatibility has already caused too much damage and trouble. Test to see if ixconfig works: set and unset the / translation, and verify each setting with an ixemul-based ls on /RAM. If it's the bad one, better quit all ixemul.library applications, use "avail flush" to throw ixemul.library out of the memory because a wrong address has been poked in the library base and start again with another ixconfig/ixemul.library pair you can find :-( If those 4 bytes had been left in, even an old v38 ixconfig would still work (with the few options that it supported). Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 14:45:50 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91206-2>; Thu, 23 Feb 1995 14:37:18 +0200 Received: from birch.cms.dmu.ac.uk (se1dp@birch.cms.dmu.ac.uk [146.227.102.8]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id MAA05008 for ; Thu, 23 Feb 1995 12:38:10 GMT Received: by birch.cms.dmu.ac.uk (1.37.109.14/3.0.0.beta1) id AA257832964; Thu, 23 Feb 1995 12:36:04 GMT Date: Thu, 23 Feb 1995 12:36:03 +0000 (GMT) From: Derek Piper X-Sender: se1dp@birch.cms.dmu.ac.uk To: GCC Mail List Subject: Help ? Anybody ? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is anyone getting my messages ? or does nobody care.... :-( I need help with the CBM includes and their use with GCC. I am having trouble getting things to compile. I get messages like 'incomplete type' from the middle of the include files during compilation. I would like to use GCC to write Amiga programs, isn't that what we got GCC for ?? Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 15:10:59 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91180-2>; Thu, 23 Feb 1995 14:58:54 +0200 Received: by colombo.telesys-innov.fr; Thu, 23 Feb 1995 13:57:02 GMT From: Philippe BRAND Message-Id: <199502231357.NAA07095@colombo.telesys-innov.fr> Subject: Re: Help ? Anybody ? To: se1dp@dmu.ac.uk (Derek Piper) Date: Thu, 23 Feb 1995 13:57:01 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Derek Piper" at Feb 23, 95 12:36:03 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 614 Derek Piper writes: > Is anyone getting my messages ? or does nobody care.... :-( !?! Didn't receive first post... > I need help with the CBM includes and their use with GCC. I am having trouble > getting things to compile. I get messages like 'incomplete type' from the middle > of the include files during compilation. I would like to use GCC to write > Amiga programs, isn't that what we got GCC for ?? Can you post me *complete* example ? Perhaps you've copied too many CBM headers e.g do not copy SAS specific ones. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 15:30:38 1995 Received: from pp.dundee.ac.uk ([134.36.2.60]) by nic.funet.fi with ESMTP id <91165-3>; Thu, 23 Feb 1995 15:16:33 +0200 Received: from kappa.mic.dundee.ac.uk by pp.dundee.ac.uk with SMTP (PP); Thu, 23 Feb 1995 13:15:27 +0000 Received: from lewis.mic.dundee.ac.uk by kappa.mic.dundee.ac.uk (4.1/SMI-4.1) id AA28027; Thu, 23 Feb 95 13:22:49 GMT Message-Id: <9221.9502231304@lewis.mic.dundee.ac.uk> To: amiga-gcc-port@lists.funet.fi Subject: templates crash. Date: Thu, 23 Feb 95 13:04:42 +0000 From: gthorbur@mic.dundee.ac.uk X-Mts: smtp This is essentially a repost but read on anyway. Could someone who is using gcc2.6.3 please try compiling the following program. It compiles in 2.5.8 ok and I believe the code is ok. When I try it it crashes after giving me warnings about re-definitions in the system header file functions. File main.c #include #include "stack.h" int main() { stack intstack; cout << intstack << endl; } File stack.h #ifndef STACKH #define STACKH #include typedef int boolean; const int TRUE = 1; const int FALSE = 0; template ostream& operator<<(ostream& strm,const T& obj) { obj.display(strm); return strm; } template class stack { private: T defaultvalue; int stackp; T item[maxsize]; public: stack(); ~stack(); void display(ostream& strm = cout) const; }; template stack::stack() { stackp = -1; defaultvalue = 0; } template stack::~stack() {} template void stack::display(ostream& strm) const { for (int i=0;i; Thu, 23 Feb 1995 15:25:29 +0200 Received: from kappa.mic.dundee.ac.uk by pp.dundee.ac.uk with SMTP (PP); Thu, 23 Feb 1995 13:23:41 +0000 Received: from lewis.mic.dundee.ac.uk by kappa.mic.dundee.ac.uk (4.1/SMI-4.1) id AA28036; Thu, 23 Feb 95 13:31:12 GMT Message-Id: <9244.9502231313@lewis.mic.dundee.ac.uk> To: amiga-gcc-port@lists.funet.fi Subject: More crashes withj 2.6.3 Date: Thu, 23 Feb 95 13:13:06 +0000 From: gthorbur@mic.dundee.ac.uk X-Mts: smtp Our uni system has 2.5.8 installed on suns. When this program is compiled it works. When compiled with Amiga port gcc 2.5.8 it also works. However when compiled with 2.6.3 it compiles to an executable ok but when you run the executable you get a floating point exception and a crash. I am not sure whether the flaw is in the actual gnu 2.5.8 src which allows it to work ok, or whether there is a flaw in the 2.6.3 src which prevents it from working. In the interst of not having to rewrite my programs when I get home to my amiga I am switching back to 2.5.8 release. File inter.cc #include #include # define M 16 #define C 2.5066282 #define K 10000 #define I 100 FILE *first; FILE *second; FILE *third; main() { float normrand(); int m,j,k; float x,x1[M][M],x2[M][M],x3[M][M],sigma; float f,av1,av2,av3,lamda; first=fopen("date1","r"); second=fopen("date2","r"); third=fopen("date3","w"); printf("sigma? "); scanf("%f",&sigma); printf("lamda? "); scanf("%f",&lamda); av1 = 0.0; av2=0.0; av3=0.0; for(j=0;j; Thu, 23 Feb 1995 15:28:27 +0200 Received: from kappa.mic.dundee.ac.uk by pp.dundee.ac.uk with SMTP (PP); Thu, 23 Feb 1995 13:27:05 +0000 Received: from lewis.mic.dundee.ac.uk by kappa.mic.dundee.ac.uk (4.1/SMI-4.1) id AA28041; Thu, 23 Feb 95 13:34:35 GMT Message-Id: <9265.9502231316@lewis.mic.dundee.ac.uk> To: amiga-gcc-port@lists.funet.fi Subject: Where are the random functions Date: Thu, 23 Feb 95 13:16:29 +0000 From: gthorbur@mic.dundee.ac.uk X-Mts: smtp Now using 2.5.8 release again. Where are the random functions in this release (and 2.6.3 for that matter) such as drand48 etc. Is there some compilation flag which must be used to use these. Gareth From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 16:27:02 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91191-1>; Thu, 23 Feb 1995 16:13:05 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA20045; Thu, 23 Feb 95 16:09:37 +0200 Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA13961; Thu, 23 Feb 95 16:13:24 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502231413.AA13961@hpcl.cti.gr> Subject: Re: Where are the random functions To: gthorbur@mic.dundee.ac.uk Date: Thu, 23 Feb 1995 16:13:23 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9265.9502231316@lewis.mic.dundee.ac.uk> from "gthorbur@mic.dundee.ac.uk" at Feb 23, 95 01:16:29 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 420 > Where are the random functions in this release (and 2.6.3 for that matter) > such as drand48 etc. Is there some compilation flag which must be used to use > these. I don't think there are ?rand48() functions available with gcc on the Amiga. Use random(), which is the Berkeley equivalent to lrand48(). Seed with srandom(seed); -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 16:32:36 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91169-2>; Thu, 23 Feb 1995 16:13:44 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA19715; Thu, 23 Feb 95 16:05:15 +0200 Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA13892; Thu, 23 Feb 95 16:09:09 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502231409.AA13892@hpcl.cti.gr> Subject: Re: More crashes withj 2.6.3 To: gthorbur@mic.dundee.ac.uk Date: Thu, 23 Feb 1995 16:09:08 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9244.9502231313@lewis.mic.dundee.ac.uk> from "gthorbur@mic.dundee.ac.uk" at Feb 23, 95 01:13:06 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1272 > Our uni system has 2.5.8 installed on suns. When this program is compiled it > works. When compiled with Amiga port gcc 2.5.8 it also works. > However when compiled with 2.6.3 it compiles to an executable ok but when > you run the executable you get a floating point exception and a crash. I tried your program on SunOS 4.1.3 with gcc 2.6.3. There are a couple of things in the program that need correcting (see below). After fixing them, the program indeed crashes. However, this is because it tries to read from the non-existent files "date1" and "date2". There's something to be said about checking the result of fopen() before using it. > #include > #include Add: #include to get the declaration of rand(); On the amiga rand() may be defined elsewhere, or not at all--adjust accordingly. > m = (2*x); x = m/2.0; Change this to: m = (int)(2*x); x = m/2.0; to avoid the warning about assigning a float to int; > a1x = 1 - x*x/2 + x*x*x*x/8 - x*x*x*x*x*x/48 + > x*x*x*x*x*x*x*x/384f1x = a1x/C; ???? I've changed this to: a1x = 1 - x*x/2 + x*x*x*x/8 - x*x*x*x*x*x/48 + x*x*x*x*x*x*x*x/384; f1x = a1x/C; -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 17:22:45 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91199-2>; Thu, 23 Feb 1995 17:15:33 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Thu, 23 Feb 1995 16:15:20 +0100 Received: from bodman.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA11882; Thu, 23 Feb 95 16:15:19 +0100 Date: Thu, 23 Feb 95 16:15:19 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502231515.AA11882@inf-wiss.uni-konstanz.de> Received: by bodman.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA17940; Thu, 23 Feb 95 16:15:10 +0100 To: amiga-gcc-port@lists.funet.fi (gcc) Subject: Re: More crashes withj 2.6.3 In-Reply-To: <9502231409.AA13892@hpcl.cti.gr> References: <9244.9502231313@lewis.mic.dundee.ac.uk> <9502231409.AA13892@hpcl.cti.gr> [Please excuse this being off-topic] > a1x = 1 - x*x/2 + x*x*x*x/8 - x*x*x*x*x*x/48 + > x*x*x*x*x*x*x*x/384; f1x = a1x/C; What about a1x = 1 - x*x/2 *(1 - x*x/4 *(1 - x*x/6 *(1 - x*x/8))); f1x = a1x/C; or even better: x2=x*x and use that. I forgot the name of the mathematics behind that transformation. It's much faster and I believe it's more accurate with floating points. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 17:35:06 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91210-4>; Thu, 23 Feb 1995 17:32:03 +0200 Received: by ceylon.informatik.uni-rostock.de id QAA03560; Thu, 23 Feb 1995 16:31:53 +0100 Received: by honshu.informatik.uni-rostock.de id QAA01508; Thu, 23 Feb 1995 16:31:52 +0100 From: Gunther Nikl Message-Id: <199502231531.QAA01508@honshu.informatik.uni-rostock.de> Subject: stack check To: amiga-gcc-port@nic.funet.fi Date: Thu, 23 Feb 1995 16:31:52 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 617 Hi! I tried the "thisstack"-program with Kickstart 39.106(3.0) and 33.180(1.2). With 1.2 sp was not between sp_Lower and sp_Upper, tried under 3.0 it was. Seems the 1.2 BCPL-Shell did it differently than later shells (written in C I guess). But nethertheless that sp is between sp_Upper and sp_Lower for the default C= shell, does not mean it has to be for every over shell. Replacing the boot-shell with another shell is a totally legal, isn't it? One problem still remains: SwapStack() changes only sp_Lower&&sp_Upper. It cannot update those special dos-entries in the process structure. Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 18:03:00 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91165-4>; Thu, 23 Feb 1995 17:53:32 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Thu, 23 Feb 1995 16:51:33 +0100 Received: from bodman.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA12003; Thu, 23 Feb 95 16:51:23 +0100 Date: Thu, 23 Feb 95 16:51:23 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502231551.AA12003@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@nic.funet.fi, gnikl@informatik.uni-rostock.de Subject: Re: stack check Gunther Nikl writes: > One problem still remains: SwapStack() changes only sp_Lower&&sp_Upper. > It cannot update those special dos-entries in the process structure. You don't need to change anything. If you want to switch to another stack, just do it, using SwapStack() (I wonder why this function is just mentioned, not used in the newer GURU book), but restore to the previous situation afterwards. If you want to switch stacks in order to run another command, use the system calls that'll preserve pr_ReturnAddr and others for you (or create a new process). Do you have more needs that that? > C I guess). But nethertheless that sp is between sp_Upper and sp_Lower for > the default C= shell, does not mean it has to be for every over shell. My method makes the best out of each of these situations. Joerg. From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 18:08:59 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91211-3>; Thu, 23 Feb 1995 17:58:24 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 23 Feb 1995 17:57:37 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <063j@kriton.UUCP>; Thu, 23 Feb 95 17:37:12 EET Date: Thu, 23 Feb 95 17:37:12 EET Message-Id: <9502231537.063j@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 6662 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Stack checking, take 2 As promised, here is the revised stack checking package. Differences from the previous posting: * If the tc_SP* entries are invalid, stack bounds are taken from the pr_ReturnAddr field. If stack bounds are still invalid, no stack checking is performed. * The stack overflow handler now pops up a requester, rather than printing to stderr. To summarize from last time: * Compile stackcheck: flex stackcheck.l gcc -O2 -s -o stackcheck lex.yy.c -lfl (Don't use -noixemul here. Its fread() is unbuffered, and flex parsers take forever to run). * Compile stackcheck_setup.c: gcc -O2 -c stackcheck_setup.c * To compile a program with stackchecking: gcc -O2 '-Dmain=stackcheck_main' -S prog.c stackcheck prog.c gcc -O2 -s -o prog prog.s stackcheck_setup.o As before, use at your own risk, but comments and bug fixes are welcome. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I am not interested in the beliefs of primitives--only in what they *taste* like!" ----- #!/bin/sh # This is a shell archive (produced by GNU sharutils 4.1). # To extract the files from this archive, save it to some FILE, remove # everything before the `!/bin/sh' line above, then type `sh FILE'. # # Made on 1995-02-23 19:25 EET by . # Source directory was `/Work/T/stackcheck'. # # Existing files will *not* be overwritten unless `-c' is specified. # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 1345 -rwxrwxrwx stackcheck.l # 2137 -rwxrwxrwx stackcheck_setup.c # touch -am 1231235999 $$.touch >/dev/null 2>&1 if test ! -f 1231235999 && test -f $$.touch; then shar_touch=touch else shar_touch=: echo echo 'WARNING: not restoring timestamps. Consider getting and' echo "installing GNU \`touch', distributed in GNU File Utilities..." echo fi rm -f 1231235999 $$.touch # # ============= stackcheck.l ============== if test -f 'stackcheck.l' && test X"$1" != X"-c"; then echo 'x - skipping stackcheck.l (file already exists)' else echo 'x - extracting stackcheck.l (text)' sed 's/^X//' << 'SHAR_EOF' > 'stackcheck.l' && %{ #include #include X #define DATA 0 #define TEXT 1 X int mode = DATA; X main(int argc, char *argv[]) { X char buf[256]; X X if (argc != 2) { X fprintf(stderr, "Usage: %s file\n", argv[0]); X return RETURN_FAIL; X } X yyin = fopen(argv[1], "r"); X if (!yyin) { X fprintf(stderr, "Can't open %s\n", argv[1]); X return RETURN_FAIL; X }else{ X fclose(yyin); X } X strcpy(buf, argv[1]); X strcat(buf, ".BAK"); X unlink(buf); X if (rename(argv[1], buf)) { X fprintf(stderr, "Can't rename %s to %s\n", argv[1], buf); X return RETURN_FAIL; X } X yyin = fopen(buf, "r"); X yyout = fopen(argv[1], "w"); X yylex(); X fclose(yyin); X fclose(yyout); X unlink(buf); X return RETURN_OK; } %} %% ^\.data {mode = DATA; ECHO;} ^\.text {mode = TEXT; ECHO;} \.globl\ _[a-zA-Z_][a-zA-Z0-9_]*\n_[a-zA-Z_][a-zA-Z0-9_]*:\n { X char name1[256], name2[256]; X yytext[strlen(yytext)-2] = '\0'; X sscanf(yytext, "%s %s\n%s", name1, name1, name2); X fprintf(yyout, "%s:\n", yytext); X if (mode == TEXT) { X if (strcmp(name1, name2) == 0) { X fprintf(yyout,"\tcmpl __StackBottom,sp\n"); #if 0 X fprintf(yyout,"\tjcc __%s_OK\n", name1); X fprintf(yyout, "\tjmp __StackOverflow\n"); X fprintf(yyout, "__%s_OK:\n", name1); #else X fprintf(yyout, "\tbccs .+8\n"); X fprintf(yyout, "\tjmp __StackOverflow\n"); #endif X } X } } %% SHAR_EOF $shar_touch -am 0210205595 'stackcheck.l' && chmod 0777 'stackcheck.l' || echo 'restore of stackcheck.l failed' shar_count="`wc -c < 'stackcheck.l'`" test 1345 -eq "$shar_count" || echo "stackcheck.l: original size 1345, current size $shar_count" fi # ============= stackcheck_setup.c ============== if test -f 'stackcheck_setup.c' && test X"$1" != X"-c"; then echo 'x - skipping stackcheck_setup.c (file already exists)' else echo 'x - extracting stackcheck_setup.c (text)' sed 's/^X//' << 'SHAR_EOF' > 'stackcheck_setup.c' && #include #include #include #define BASE_EXT_DECL #define BASE_EXT_DECL0 static struct IntuitionBase *IntuitionBase; #include #include X unsigned long _StackBottom; static unsigned long _StackOrig; static int Argc; static char **Argv; X int main(int argc, char *argv[]) { X register unsigned long sp asm("sp"); X unsigned long _StackTop; X unsigned long _StackSize; X struct Task *t; X struct Process *p; X X Argc = argc; X Argv = argv; X t = FindTask(0L); X _StackBottom = (unsigned long)t->tc_SPLower; X _StackTop = (unsigned long)t->tc_SPUpper; X _StackOrig = sp; X if (_StackOrig > _StackTop || _StackOrig < _StackBottom) { X p = (struct Process *)t; X /* pr_ReturnAddr points to the stack size. Next word is the return address, X then the first word outside the stack, i.e., stack bottom + stack size. X This is the reason for the adjustment by 2 * sizeof(ULONG). */ X _StackTop = (unsigned long)p->pr_ReturnAddr + 2 * sizeof(ULONG); X _StackSize = *(unsigned long *)p->pr_ReturnAddr; X _StackBottom = _StackTop - _StackSize; X if (_StackOrig > _StackTop || _StackOrig < _StackBottom) { X _StackBottom = 0; /* No stack checking possible */ X } X } X _StackBottom += 128; /* Leave some space for arguments */ X return stackcheck_main(argc, argv); } X void _StackOverflow(void) { X static struct IntuiText BodyText = X {1, 0, JAM1, 0, 0, NULL, NULL, NULL}; X static struct IntuiText NegText = X {1, 0, JAM1, 0, 0, NULL, (UBYTE *)"QUIT", NULL}; X register unsigned long sp asm("sp"); X static char buf[80]; X X sp = _StackOrig; /* Restore stack to a sane value */ X X if (IntuitionBase == NULL){ X IntuitionBase = (struct IntuitionBase *) X OldOpenLibrary("intuition.library"); X } X if (Argc > 0) { X strcpy(buf, FilePart(Argv[0])); X }else{ X strcpy(buf, ((struct WBStartup *)Argv)->sm_ArgList[0].wa_Name); X } X strcat(buf, ": Stack Overflow"); X BodyText.IText = (UBYTE *)buf; X AutoRequest(NULL, &BodyText, NULL, &NegText, 0, 0, 250, 40); X CloseLibrary((struct Library *)IntuitionBase); X X exit(RETURN_FAIL); } SHAR_EOF $shar_touch -am 0223004195 'stackcheck_setup.c' && chmod 0777 'stackcheck_setup.c' || echo 'restore of stackcheck_setup.c failed' shar_count="`wc -c < 'stackcheck_setup.c'`" test 2137 -eq "$shar_count" || echo "stackcheck_setup.c: original size 2137, current size $shar_count" fi exit 0 From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 18:15:03 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91235-4>; Thu, 23 Feb 1995 18:00:37 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 23 Feb 1995 17:57:35 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <063e@kriton.UUCP>; Wed, 22 Feb 95 19:12:09 EET Date: Wed, 22 Feb 95 19:12:09 EET Message-Id: <9502221712.063e@kriton.UUCP> In-Reply-To: <199502221423.PAA26921@honshu.informatik.uni-rostock.de> (from Gunther Nikl ) (at Wed, 22 Feb 1995 15:23:06 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 649 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: gnikl@informatik.uni-rostock.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: stack checking! Hi Gunther (Gunther Nikl), in <199502221423.PAA26921@honshu.informatik.uni-rostock.de> on Feb 22 you wrote: > > _StackBottom = _StackTop - sizeof(ULONG) - *(unsigned long *)_StackTop; > ^^^^^^^^^^^^^^^ > The 8 byte difference comes from wrong "-". It has to be "+ sizeof(ULONG)". > Then both values (should) match. Thanks! I noticed that something was not quite right with my code :-( -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Anything that's not impossible is merely waiting to happen." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 18:15:04 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91236-1>; Thu, 23 Feb 1995 18:04:13 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 23 Feb 1995 17:57:41 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <0639@kriton.UUCP>; Wed, 22 Feb 95 19:09:09 EET Date: Wed, 22 Feb 95 19:09:09 EET Message-Id: <9502221709.0639@kriton.UUCP> In-Reply-To: <9502220220.3spa@adastra.cvl.va.us> (from "Michael B. Smith" ) (at Tue, 21 Feb 95 22:20:13 EDT) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 2215 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: mbs@adastra.cvl.va.us Cc: amiga-gcc-port@lists.funet.fi Subject: Re: stack checking! Hi Michael (Michael B. Smith), in <9502220220.3spa@adastra.cvl.va.us> on Feb 21 you wrote: > The more relevant test is what Shell is being used. As of 2.0+, the C= > Shell uses RunCommand() in all cases to set SPUpper and SPLower, and does > it how you expect. However, WShell has a (in)famous bug where it does not > in all cases. Something tells me that what it all boils down to is whether stack checking should account for a bug in WShell or not. Philosophically, I think it should not, but pragmatically, given the widespread use of WShell, I understand that it should. It also looks like I might be able to test my code by running the 1.3 CLI. > They say, and I quote: Finally, an argument based on the manual! > "...AmigaDOS obtains this stack from the general free memory > heap just before you run the program; it is not, however, the > same as the stack that the CLI uses. AmigaDOS pushes a suitable > return address onto the stack that tells the CLI to regain > control and unload your program. Below this on the stack at > 4(SP) is the size of the stack in bytes, which may be usable to > you if you wish to perform stack checking." (The reason I didn't see this paragraph is that I was looking in the AmigaDOS data structures section.) > You access that by *(pr->pr_ReturnAddr) where "pr" is a pointer to > a CLI "struct Process *". I would also modify the "which may be usable" > to "which you must use". I would still tend to take this on face value--if tc_SP* are usable, I would use them. > For more detailed, and extremely worthwhile information on this > subject, refer to "The Amiga GURU Book" by Ralph Babel, section > 2.1.2.1., pp 41-42. Everybody seems to be recommending this book--I'd better get myself a copy! Anyway, it seems that, mainly for compatibility with WShell and the 1.3 Shell, stack checking initialization should be made more comprehensive. I'll clean up the code I posted yesterday, and repost the entire thing. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Anything that's not impossible is merely waiting to happen." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 18:20:51 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91184-4>; Thu, 23 Feb 1995 18:09:57 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 23 Feb 95 17:07 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 23 Feb 95 17:01 MET Message-Id: Subject: Re: More crashes withj 2.6.3 (fwd) To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 23 Feb 1995 17:01:00 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1368 Forwarded message: > From arbi.informatik.uni-oldenburg.de!nic.funet.fi!amiga-gcc-port-owner Thu Feb 23 16:49:49 1995 > Date: Thu, 23 Feb 95 16:15:19 +0100 > From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) > Message-Id: <9502231515.AA11882@inf-wiss.uni-konstanz.de> > To: amiga-gcc-port@lists.funet.fi (gcc) > Subject: Re: More crashes withj 2.6.3 > In-Reply-To: <9502231409.AA13892@hpcl.cti.gr> > References: <9244.9502231313@lewis.mic.dundee.ac.uk> <9502231409.AA13892@hpcl.cti.gr> > [Please excuse this being off-topic] > > > a1x = 1 - x*x/2 + x*x*x*x/8 - x*x*x*x*x*x/48 + > > x*x*x*x*x*x*x*x/384; f1x = a1x/C; > > What about > > a1x = 1 - x*x/2 *(1 - x*x/4 *(1 - x*x/6 *(1 - x*x/8))); > f1x = a1x/C; > > or even better: x2=x*x and use that. whats wrong with :x2=x*x*0.5; mult is much faster than div ;) but of cause it only matters if you do much calc (like me) > > I forgot the name of the mathematics behind that transformation. > It's much faster and I believe it's more accurate with floating points. > horner schema or so ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 18:20:51 1995 Received: from beech.soton.ac.uk ([152.78.128.78]) by nic.funet.fi with SMTP id <91208-2>; Thu, 23 Feb 1995 18:06:03 +0200 Received: from bright.ecs.soton.ac.uk (bright.ecs.soton.ac.uk [152.78.64.201]) by beech.soton.ac.uk (8.6.10/hub-8.4) with SMTP id QAA25760 for ; Thu, 23 Feb 1995 16:05:49 GMT From: Chris Goodall Received: from davinci.ecs.soton.ac.uk by whirligig.ecs.soton.ac.uk; Thu, 23 Feb 95 16:05:34 GMT Message-Id: <27677.9502231605@davinci.ecs.soton.ac.uk> Subject: GCC 2.6.3 C++ Crashes To: amiga-gcc-port@nic.funet.fi Date: Thu, 23 Feb 1995 16:05:34 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1440 Hello All!! Please could somebody help a very frustrated student. I have an Amiga 1500, 9Mb RAM, 68EC030 @ 40Mhz, 150Mb Hard Disk etc. ect. which has the 2.1 version of the Amiga Workbench and Kickstart V2.0 installed. The problem is that I have just started a C++ course as part of my Computer Science degree and I am trying to learn the language, all the code that I seem to write - even very simple ones - cause the Amiga to crash ("Software Failure" error messages) and reboot. The software failures only occur when the compiler finds and starts to return error messages from the source code, I have tried installing both the 68020 and 68000 release of the GCC C++ compiler but both cause software crashes. Is it the release of the compiler? My machine configuration? (is doesn't have a FPU) I am very confused. Would any earlier versions of the GNU GCC compiler cure this problem? I had version 2.6.0 before when I was using just the C compiler - rather than the G++ edition. This compiled fine without any problems. Any advice would be greatly appreciated. Thanks in advance, Chris Goodall....... P.S. Which INTERNET sites hold previous GCC versions??? ********************************************** Department of Electronics & Computer Science Southampton University Southampton England Email: csg94@ecs.soton.ac.uk Mobile (Orange): 0973 408941 ********************************************** From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 18:40:19 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91254-1>; Thu, 23 Feb 1995 18:31:18 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 23 Feb 1995 18:29:26 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <0643@kriton.UUCP>; Thu, 23 Feb 95 18:11:48 EET Date: Thu, 23 Feb 95 18:11:48 EET Message-Id: <9502231611.0643@kriton.UUCP> In-Reply-To: <9502230839.AA11338@pctc.chemie.uni-erlangen.de> (from walter@pctc.chemie.uni-erlangen.de (Thomas Walter)) (at Thu, 23 Feb 1995 09:39:20 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 983 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: walter@pctc.chemie.uni-erlangen.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: problem with system() Hi Thomas (Thomas Walter), in <9502230839.AA11338@pctc.chemie.uni-erlangen.de> on Feb 23 you wrote: > Hello, > recently I tracked down a strange behavior while using using > gcc compiled programs. > The system() command does not work in all cases. Ixemul programs behave differently when exec'ed from other ixemul programs than when run using one of the standard methods. Apparently, when a program is run using system(), it gets its file handles (or something) confused, but it does get run. E.g., vim pops up its own window, rather than using the shell's window. You can get around this by compiling using -Dsystem=System. (You should use System() anyway, if you are writing amiga programs.) The libnix version of system() also appears to work fine. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If you had an off switch, doctor, would you not keep it secret?" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 18:44:13 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91253-2>; Thu, 23 Feb 1995 18:31:52 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 23 Feb 1995 18:29:22 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <0648@kriton.UUCP>; Thu, 23 Feb 95 18:13:45 EET Date: Thu, 23 Feb 95 18:13:45 EET Message-Id: <9502231613.0648@kriton.UUCP> In-Reply-To: (from jds@kom.auc.dk (Jes Degn Soerensen)) (at Thu, 23 Feb 95 10:37 MET) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 679 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: jds@kom.auc.dk Cc: amiga-gcc-port@lists.funet.fi Subject: Re: problem with system() Hi Jes (Jes Degn Soerensen), in on Feb 23 you wrote: > I'm not sure, but I guess gcc runs the programs using the $PATH > env-variable. Remember there is a difference between the Amiga's path > system, and the $PATH variable. Try setting your $PATH to where you got > your ls command, ie Set PATH=/bin:/c:/usr/bin:. (just like under That wouldn't change things, as sh's default PATH is .:/bin:/c, and ls is in bin:. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If you had an off switch, doctor, would you not keep it secret?" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 18:50:27 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91186-1>; Thu, 23 Feb 1995 18:39:40 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 23 Feb 1995 18:29:24 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <064d@kriton.UUCP>; Thu, 23 Feb 95 18:21:40 EET Date: Thu, 23 Feb 95 18:21:40 EET Message-Id: <9502231621.064d@kriton.UUCP> In-Reply-To: <9221.9502231304@lewis.mic.dundee.ac.uk> (from gthorbur@mic.dundee.ac.uk) (at Thu, 23 Feb 95 13:04:42 +0000) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 3507 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: gthorbur@mic.dundee.ac.uk Cc: amiga-gcc-port@lists.funet.fi Subject: Re: templates crash. Hi gthorbur (gthorbur), in <9221.9502231304@lewis.mic.dundee.ac.uk> on Feb 23 you wrote: > Could someone who is using gcc2.6.3 please try compiling the following program. > It compiles in 2.5.8 ok and I believe the code is ok. > > When I try it it crashes after giving me warnings about re-definitions in the > system header file functions. I tried your code using gcc 2.6.3 both under SunOS 4.1.3 and AMigaDOS 2.1, and I don't get any crashes or warnings about redefinitions of system functions. What I did get, however, are a bunch of different error messages. stack.h: In method `void stack::display(class ostream & = cout) const': stack.h:40: call of overloaded method `operator <<(int)' is ambiguous GPP_INCLUDE:iostream.h:83: candidates are: ostream::operator <<(long unsigned int) GPP_INCLUDE:iostream.h:71: ostream::operator <<(char) GPP_INCLUDE:iostream.h:72: ostream::operator <<(unsigned char) GPP_INCLUDE:iostream.h:73: ostream::operator <<(signed char) GPP_INCLUDE:iostream.h:85: ostream::operator <<(long long int) GPP_INCLUDE:iostream.h:81: ostream::operator <<(unsigned int) GPP_INCLUDE:iostream.h:82: ostream::operator <<(long int) GPP_INCLUDE:iostream.h:88: ostream::operator <<(short int) GPP_INCLUDE:iostream.h:89: ostream::operator <<(short unsigned int) GPP_INCLUDE:iostream.h:86: ostream::operator <<(long long unsigned int) GPP_INCLUDE:iostream.h:91: ostream::operator <<(bool) GPP_INCLUDE:iostream.h:93: ostream::operator <<(double) GPP_INCLUDE:iostream.h:94: ostream::operator <<(float) stack.h:11: operator <<(ostream &, const int &) GPP_INCLUDE:iostream.h:80: ostream::operator <<(int) stack.h:41: call of overloaded method `operator <<(int)' is ambiguous GPP_INCLUDE:iostream.h:83: candidates are: ostream::operator <<(long unsigned int) GPP_INCLUDE:iostream.h:71: ostream::operator <<(char) GPP_INCLUDE:iostream.h:72: ostream::operator <<(unsigned char) GPP_INCLUDE:iostream.h:73: ostream::operator <<(signed char) GPP_INCLUDE:iostream.h:85: ostream::operator <<(long long int) GPP_INCLUDE:iostream.h:81: ostream::operator <<(unsigned int) GPP_INCLUDE:iostream.h:82: ostream::operator <<(long int) GPP_INCLUDE:iostream.h:88: ostream::operator <<(short int) GPP_INCLUDE:iostream.h:89: ostream::operator <<(short unsigned int) GPP_INCLUDE:iostream.h:86: ostream::operator <<(long long unsigned int) GPP_INCLUDE:iostream.h:91: ostream::operator <<(bool) GPP_INCLUDE:iostream.h:93: ostream::operator <<(double) GPP_INCLUDE:iostream.h:94: ostream::operator <<(float) stack.h:11: operator <<(ostream &, const int &) GPP_INCLUDE:iostream.h:80: ostream::operator <<(int) stack.h: In function `class ostream & operator <<(class ostream &, const char (&)[17])': stack.h:12: request for member `display' in `obj', which is of non-aggregate type `const char[17]' Perhaps this is of some assistance. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If you had an off switch, doctor, would you not keep it secret?" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 19:08:52 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91169-1>; Thu, 23 Feb 1995 18:59:37 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 23 Feb 1995 18:58:08 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <064m@kriton.UUCP>; Thu, 23 Feb 95 18:38:52 EET Date: Thu, 23 Feb 95 18:38:52 EET Message-Id: <9502231638.064m@kriton.UUCP> In-Reply-To: <199502201851.AA02134@cdevil.unx.sas.com> (from James Cooper ) (at Mon, 20 Feb 1995 13:51:10 -0500 (EST)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1257 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: jamie@unx.sas.com Cc: amiga-gcc-port@lists.funet.fi Subject: Re: stack checking! Hi James (James Cooper), in <199502201851.AA02134@cdevil.unx.sas.com> on Feb 20 you wrote: > In SAS/C, if you specify a stack size larger than the current, so that a > new one is created, the new stack parameters are NOT written back into the > tc_SP* fields. > > So, if someone were to try to run code under a shell compiled with SAS/C, > checking the tc_SP* fields would give invalid answers as far as the true > current stack... That's funny, I'm using such a shell (SKsh) and these fields are quite valid! Seriously, the tc_SP* fields refer to the current process, not to processes created by the current process (like, e.g., cli_DefaultStack does), so although a shell might be doing things wrong, its child processes should not have any problems. In any case, I was convinced to revise my code, so even if it is possible to use a combination of SAS/C and gcc to create a contrived example where the tc_SP* fields are invalid in a gcc-compiled program, the new version should be able to handle it. (Famous last words!) -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If you had an off switch, doctor, would you not keep it secret?" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 23:58:15 1995 Received: from ios.com ([198.4.75.44]) by nic.funet.fi with SMTP id <91338-1>; Thu, 23 Feb 1995 21:15:28 +0200 Received: (from rasta@localhost) by ios.com (8.6.9/8.6.9) id OAA02571; Thu, 23 Feb 1995 14:15:06 -0500 Date: Thu, 23 Feb 1995 14:15:05 -0500 (EST) From: "formerly freak@acy1.digex.net" Subject: _atan2(), sh unfriendliness, and where the heck is err.h? To: amiga-gcc-port@nic.funet.fi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hey folks, Just a few things here for the list (I am sure there will be more later): >From what I can see the atan2() function is in the proper GCC includes and libraries, but when I go to link it, I get the unrefed from text seg thing, which means it can't find the function in a library from what I understand. What gives? - I like SH a lot, BUT, a couple things kinda bug me and I was wondering if either there was a workaround or I am doing something wrong. It seems that once you cause Sh to hang (kinda easy, it's very tempremental), that there is no way to kill it. Break ALL does nothing (or gurus) and if you hit Ctrl-C enuff times you are guaranteed a guru. Does this have to do with the signal handling, the Amiga Console, or both? - Is err.h gonna be included anytime soon (hmm that may be a NetBSD specific include). If so, nevermind :) - I am just curious as well about this: Why are there a whole pile of functions in the includes that will surely bomb out when you go to link as 3/4 of the GCC lib*.a libraries arent included in the distribution. This is not a flame, I am just curious. Thanx! From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 23:58:15 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91306-3>; Thu, 23 Feb 1995 20:28:43 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ab06844; 23 Feb 95 18:19 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA002av; Thu, 23 Feb 95 18:04:23 GMT Date: Thu, 23 Feb 95 18:04:23 GMT Message-Id: <9502231804.AA002au@flevel.demon.co.uk> Message-Id: <20408f23.13880-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Re: ENV: and ixemul startup (fwd) On Feb 23, Kriton Kyrimis wrote: |-------------------- text of forwarded message follows --------------------| Hi dev (dev), in <9502171226.AA0076s@flevel.demon.co.uk> on Feb 17 you wrote: > Hows about a simple solution, have 2 version of the ixemul startup, one > that scans the global enviroment variables and one that does not. We could > then do something like:- > > gcc -o myprog myprog.o -noenv Sounds like a reasonable compromise--why don't you post your suggestion to the list, and see what reaction you get from Philippe and the ixemul people? |------------------------- end of forwarded message ------------------------| What do others think? Thanks, - Trefor S. From amiga-gcc-port-owner@nic.funet.fi Thu Feb 23 23:58:15 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91268-1>; Thu, 23 Feb 1995 19:33:56 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 23 Feb 1995 19:30:55 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <065b@kriton.UUCP>; Thu, 23 Feb 95 19:27:11 EET Date: Thu, 23 Feb 95 19:27:11 EET Message-Id: <9502231727.065b@kriton.UUCP> In-Reply-To: <9502231649.AA12273@inf-wiss.uni-konstanz.de> (from hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle)) (at Thu, 23 Feb 95 17:49:38 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 951 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: hoehle@inf-wiss.uni-konstanz.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Stack checking, take 2 Hi Joerg-Cyril (Joerg-Cyril Hoehle), in <9502231649.AA12273@inf-wiss.uni-konstanz.de> on Feb 23 you wrote: > you should check pr_Windowptr (or whatever is the name) to see if > requesters have been disabled for this process (e.g. remote processes > and such). I think you have just found a bug in SAS/C! They also pop up the stack overflow requester without checking! Does anyone have any suggestion as to what the stack overflow handler's behavior should be if requesters have been disabled? Exiting silently does not seem to be enough. One the other hand, one cannot assume the existence of a window on which to print an error message (this is the main reason I replaced the error message with a requester). Thanks, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If you had an off switch, doctor, would you not keep it secret?" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 01:19:47 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91190-2>; Fri, 24 Feb 1995 01:15:22 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Fri, 24 Feb 95 00:14 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Fri, 24 Feb 95 00:10 MET Message-Id: Subject: _atan2(), sh unfriendliness, and where the heck is err.h? (fwd) To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Fri, 24 Feb 1995 00:09:59 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 722 > > >From what I can see the atan2() function is in the proper GCC includes > and libraries, but when I go to link it, I get the unrefed from text seg > thing, which means it can't find the function in a library from what I > understand. What gives? did you compile with -lm ? > - > Is err.h gonna be included anytime soon (hmm that may be a NetBSD > specific include). If so, nevermind :) would be interessting, philipe ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 01:19:48 1995 Received: from virginia.edu ([128.143.2.7]) by nic.funet.fi with SMTP id <91191-1>; Fri, 24 Feb 1995 01:15:11 +0200 Received: from k30hadastra by uvaarpa.virginia.edu id aa23533; 23 Feb 95 18:15 EST Received: by adastra.cvl.va.us (V1.17-beta/Amiga) id <3ssq@adastra.cvl.va.us>; Thu, 23 Feb 95 17:44:00 EDT Date: Thu, 23 Feb 95 17:44:00 EDT Message-Id: <9502232144.3ssq@adastra.cvl.va.us> In-Reply-To: <9502221709.0639@kriton.UUCP> from Kriton Kyrimis at Wed, 22 Feb 95 19:09:09 EET X-Mailer: GMail 0.53 (11.2.95) From: "Michael B. Smith" To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: stack checking! > > The more relevant test is what Shell is being used. As of 2.0+, the C= > > Shell uses RunCommand() in all cases to set SPUpper and SPLower, and does > > it how you expect. However, WShell has a (in)famous bug where it does not > > in all cases. > > Something tells me that what it all boils down to is whether stack > checking should account for a bug in WShell or not. Philosophically, I > think it should not, but pragmatically, given the widespread use of > WShell, I understand that it should. Well, depending upon your perspective, it isn't a bug. Given the paragraph I quoted earlier, it can be reasonably argued that depending on SPUpper and SPLower in a CLI process is a bug. > It also looks like I might be able to test my code by running the 1.3 CLI. Not having a 1.3 system around myself, I can't really say. > > They say, and I quote: > > Finally, an argument based on the manual! Heh. ;) > > You access that by *(pr->pr_ReturnAddr) where "pr" is a pointer to > > a CLI "struct Process *". I would also modify the "which may be usable" > > to "which you must use". > > I would still tend to take this on face value--if tc_SP* are usable, I > would use them. I would disagree, as I noted above. For _AmigaDOS_ _processes_, the _AmigaDOS_Manual_ says to use pr_ReturnAddr. Processes will run in the context of AmigaDOS, tasks never do. Some would say "a process is just a task with more stuff", to which I would be forced to disagree. They have a different ln_Type field in the SysBase entry. > > For more detailed, and extremely worthwhile information on this > > subject, refer to "The Amiga GURU Book" by Ralph Babel, section > > 2.1.2.1., pp 41-42. > > Everybody seems to be recommending this book--I'd better get myself a > copy! I recommend it. > Anyway, it seems that, mainly for compatibility with WShell and the 1.3 > Shell, stack checking initialization should be made more comprehensive. > I'll clean up the code I posted yesterday, and repost the entire thing. Well, there are other shells out there. Mine included. ;) I use RunCommand() so it isn't really an issue for me, but I doubt that all of them do. -- // Michael B. Smith \X/ mbs@adastra.cvl.va.us -or- uunet.uu.net!virginia.edu!adastra!mbs From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 01:24:16 1995 Received: from mail.crl.com ([165.113.1.22]) by nic.funet.fi with SMTP id <91194-3>; Fri, 24 Feb 1995 01:18:02 +0200 Received: from crl12.crl.com by mail.crl.com with SMTP id AA28468 (5.65c/IDA-1.5 for ); Thu, 23 Feb 1995 15:16:22 -0800 Received: by crl12.crl.com id AA26944 (5.65c/IDA-1.5); Thu, 23 Feb 1995 15:17:09 -0800 Date: Thu, 23 Feb 1995 15:17:08 -0800 (PST) From: Will Bow To: dev@flevel.demon.co.uk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ENV: and ixemul startup (fwd) In-Reply-To: <9502231804.AA002au@flevel.demon.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 23 Feb 1995 dev@flevel.demon.co.uk wrote: > On Feb 23, Kriton Kyrimis wrote: > > |-------------------- text of forwarded message follows --------------------| > > Hi dev (dev), in <9502171226.AA0076s@flevel.demon.co.uk> on Feb 17 you wrote: > > > Hows about a simple solution, have 2 version of the ixemul startup, one > > that scans the global enviroment variables and one that does not. We could > > then do something like:- > > > > gcc -o myprog myprog.o -noenv > > Sounds like a reasonable compromise--why don't you post your suggestion > to the list, and see what reaction you get from Philippe and the ixemul > people? > > |------------------------- end of forwarded message ------------------------| > > What do others think? > > Thanks, > > - Trefor S. > I like the idea! ------------------------------------------------------------------------------ "Badges??? ... Badges ??? We don't got to show you no stinkin badges!" _ _ _ _ __ _(_) | | | |__ _____ __ \ \ /\ / / | | | | '_ \ / _ \ \ /\ / / \ V V /| | | | | |_) | (_) \ V V / \_/\_/ |_|_|_| |_.__/ \___/ \_/\_/ wbow@crl.com ------------------------------------------------------------------------------ From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 04:25:28 1995 Received: from eeyore.INS.CWRU.Edu ([129.22.8.17]) by nic.funet.fi with ESMTP id <91207-3>; Fri, 24 Feb 1995 04:23:53 +0200 Received: (cz253@localhost) by eeyore.INS.CWRU.Edu (8.6.10+cwru/CWRU-2.1-bsdi) id VAA04208; Thu, 23 Feb 1995 21:23:36 -0500 (from cz253) Message-Id: <199502240223.VAA04208@eeyore.INS.CWRU.Edu> Date: Thu, 23 Feb 1995 21:23:36 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: rasta@ios.com Subject: Re: _atan2(), sh unfriendliness, and where the heck is err.h? Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) [rasta@ios.com wrote] >I like SH a lot, BUT, a couple things kinda bug me and I was wondering if >either there was a workaround or I am doing something wrong. It seems >that once you cause Sh to hang (kinda easy, it's very tempremental), that >there is no way to kill it. Break ALL does nothing (or gurus) and if you >hit Ctrl-C enuff times you are guaranteed a guru. Does this have to do >with the signal handling, the Amiga Console, or both? I like sh too, and hang it up alot also. But have been quite successful in getting out of it without a visit from the Guru. Try using 'TaskX' to send the Ctrl-C to 'sh', I think you will be surprised. ;-) 'TaskX' should be on aminet somewhere, not sure of it's exact location though, sorry. .....Dave From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 06:10:54 1995 Received: from clinet.fi ([193.64.6.1]) by nic.funet.fi with SMTP id <91209-2>; Fri, 24 Feb 1995 06:09:05 +0200 Received: from zetor.clinet.fi (root@zetor.clinet.fi [193.64.6.8]) by clinet.fi (8.6.9/8.6.4) with ESMTP id GAA06602 for ; Fri, 24 Feb 1995 06:09:01 +0200 Received: (will@localhost) by zetor.clinet.fi (8.6.8/8.6.4) id GAA13835; Fri, 24 Feb 1995 06:08:59 +0200 Date: Fri, 24 Feb 1995 06:08:55 +0200 (EET) From: Ville-Pertti Keinonen To: amiga-gcc-port@nic.funet.fi Subject: misc. garbage Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII (I hope this message gets posted properly, I've been getting a lot of errors earlier..) In an earlier message, I mentioned that ixemul.library interpreted the group/other protection bits the wrong way around. Not having received any comments related to this, I fixed the problem (I also hacked up muFS support while I was at it (breaking locks and writing new getpwuid/getpwnam/getgroups etc.etc. functions), only to find that muFS was *not* suitable for my needs, since it doesn't check group access properly). It didn't take long to realize that the changes had indeed caused problems - make wouldn't run any commands. chmod a+x /bin/* helped, but I don't see why other/group permissions should be checked if you're the owner. The commands would run fine from sh, though, so the problem is probably with make or the way it runs commands. Make also acts sort of strange, sometimes it complains that an option (which I didn't give it) needs an argument (I think it was -j), and sometimes it starts dumping its internals to the stdout (or stderr, it's hard to tell which is in question) after makeing whatever it was invoked to make. Whenever it does this once, it'll do it again every time until an avail flush has been performed. BTW: Why does -msmall-code set -fno-function-cse in the default specs-file? Taking it out certainly didn't seem to harm anything (specs has to be edited, anyhow, since there are lots of spaces missing), the idea might have been (just guessing) to prevent the lea from being non-pc-relative, but the code isn't entirely pc-relative in any case (not at all if compiling for a 68000, a 68020+ compilation needs less relocations since it uses bsrl for jbsr - oh I like MIT-syntax), so this shouldn't really make a difference. From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 10:40:06 1995 Received: from mserv.rug.ac.be ([157.193.40.37]) by nic.funet.fi with SMTP id <91222-3>; Fri, 24 Feb 1995 10:36:42 +0200 Received: from eduserv.rug.ac.be by mserv.rug.ac.be with SMTP id AA27424 (5.67b/IDA-1.5 for ); Fri, 24 Feb 1995 09:35:12 +0100 Received: by eduserv.rug.ac.be (5.x/SMI-SVR4) id AA00969; Fri, 24 Feb 1995 09:35:03 +0100 Date: Fri, 24 Feb 1995 09:35:02 +0100 (MET) From: Bart Van Assche To: Walter Harms Cc: amiga gcc-list Subject: Re: More crashes withj 2.6.3 (fwd) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 23 Feb 1995, Walter Harms wrote: > > or even better: x2=x*x and use that. > > whats wrong with :x2=x*x*0.5; > mult is much faster than div ;) but of cause > it only matters if you do much calc (like me) If you care so much about speed of calculations, why not use ldexp() and frexp() for this purpose ? These functions do not need any floating point manipulations, only integer manipulations. This is probably faster when you don't have an FPU available. I have no idea about the results with FPU. __ /_/ /_/art Van Assche (Bart.VanAssche@rug.ac.be) From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 10:46:50 1995 Received: from mserv.rug.ac.be ([157.193.40.37]) by nic.funet.fi with SMTP id <91225-4>; Fri, 24 Feb 1995 10:43:02 +0200 Received: from eduserv.rug.ac.be by mserv.rug.ac.be with SMTP id AA27536 (5.67b/IDA-1.5 for ); Fri, 24 Feb 1995 09:41:30 +0100 Received: by eduserv.rug.ac.be (5.x/SMI-SVR4) id AA02541; Fri, 24 Feb 1995 09:41:19 +0100 Date: Fri, 24 Feb 1995 09:41:18 +0100 (MET) From: Bart Van Assche To: Chris Goodall Cc: amiga-gcc-port@nic.funet.fi Subject: Re: GCC 2.6.3 C++ Crashes In-Reply-To: <27677.9502231605@davinci.ecs.soton.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 23 Feb 1995, Chris Goodall wrote: > The software failures only occur when the compiler finds and starts to > return > error messages from the source code, I have tried installing both the > 68020 and 68000 release of the GCC C++ compiler but both cause software > crashes. Is it the release of the compiler? My machine configuration? (is > doesn't have a FPU) I am very confused. Without FPU, you need the 68000 version. Please check what version of ixemul.library you have: a 2.6.x version of GCC had the wrong ixemul.library. (It was only for CPU's with FPU ?) __ /_/ /_/art Van Assche (Bart.VanAssche@rug.ac.be) From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 10:51:59 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91228-1>; Fri, 24 Feb 1995 10:46:05 +0200 Received: by colombo.telesys-innov.fr; Fri, 24 Feb 1995 09:45:00 GMT From: Philippe BRAND Message-Id: <199502240945.JAA12255@colombo.telesys-innov.fr> Subject: Re: ENV: and ixemul startup (fwd) To: wbow@crl.com (Will Bow) Date: Fri, 24 Feb 1995 09:44:59 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Will Bow" at Feb 23, 95 03:17:08 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 209 Will Bow writes: > > > gcc -o myprog myprog.o -noenv > > What do others think? > I like the idea! Why not, why not... -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 11:07:49 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91230-4>; Fri, 24 Feb 1995 11:05:05 +0200 Received: by colombo.telesys-innov.fr; Fri, 24 Feb 1995 10:00:42 GMT From: Philippe BRAND Message-Id: <199502241000.KAA12350@colombo.telesys-innov.fr> Subject: Re: Stack checking, take 2 To: kyrimis@theseas.ntua.gr Date: Fri, 24 Feb 1995 10:00:42 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9502231537.063j@kriton.UUCP> from "Kriton Kyrimis" at Feb 23, 95 05:37:12 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 585 Kriton Kyrimis writes: > As promised, here is the revised stack checking package. > Differences from the previous posting: I'll integrate it directly into gcc, adding YACF (Yet Another Compiler Flag). PS: I apologise being not as available as before, things should now be quite ok. I had some problems with my Amiga, having to use my personnal system as the BBS main system, due to some hardware problems. I'll look at latest GNU-C beta snapshots, as work have been done to m68k processors... -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 13:26:30 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <91159-3>; Fri, 24 Feb 1995 13:17:45 +0200 Received: by nmrc.ucc.ie (8.6.8.1/8.6.6) with ESMTP id LAA10669 for ; Fri, 24 Feb 1995 11:17:13 GMT From: Lars Hecking Message-Id: <199502241119.LAA13062@mostar.nmrc.ucc.ie> Subject: Re: _atan2(), sh unfriendliness, and where the heck is err.h? To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Fri, 24 Feb 1995 11:19:44 +0000 (GMT) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1055 David Zaroski wrote: > > [rasta@ios.com wrote] > > >I like SH a lot, BUT, a couple things kinda bug me and I was wondering if > >either there was a workaround or I am doing something wrong. It seems > >that once you cause Sh to hang (kinda easy, it's very tempremental), that > >there is no way to kill it. Break ALL does nothing (or gurus) and if you > >hit Ctrl-C enuff times you are guaranteed a guru. Does this have to do > >with the signal handling, the Amiga Console, or both? > > I like sh too, and hang it up alot also. But have been quite successful in > getting out of it without a visit from the Guru. Try using 'TaskX' to send > the Ctrl-C to 'sh', I think you will be surprised. ;-) 'TaskX' should be > on aminet somewhere, not sure of it's exact location though, sorry. Don't use TaskX! It works, but at the same time creates loads of enforcer hits on my 37.175 system. Use PriMan20.lha util/moni 85K 13+Configurable Task Priority Manager instead. It provides way more capabilities and is *neat* ... -- lhecking@nmrc.ucc.ic From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 14:58:19 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91165-1>; Fri, 24 Feb 1995 14:51:37 +0200 Received: by ceylon.informatik.uni-rostock.de id NAA06801; Fri, 24 Feb 1995 13:51:28 +0100 Received: by honshu.informatik.uni-rostock.de id NAA05519; Fri, 24 Feb 1995 13:51:28 +0100 From: Gunther Nikl Message-Id: <199502241251.NAA05519@honshu.informatik.uni-rostock.de> Subject: Re: misc. garbage To: will@clinet.fi (Ville-Pertti Keinonen) Date: Fri, 24 Feb 1995 13:51:27 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Ville-Pertti Keinonen" at Feb 24, 95 06:08:55 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 410 > BTW: Why does -msmall-code set -fno-function-cse in the default > specs-file? The reason is simple: if you compile with "-msmall-code" your code has to fit (almost) into 32k. Every function should be accessable with "bsr.W". If "-fno-function-cse" is not given gcc may stuff function addresses into registers. Thats not always a good idea (especially if gcc uses a data register). Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 15:06:15 1995 Received: from pan.rz.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91180-4>; Fri, 24 Feb 1995 15:00:50 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by pan.rz.uni-konstanz.de with SMTP(PP); Fri, 24 Feb 1995 13:58:22 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA14836; Fri, 24 Feb 95 13:58:11 +0100 Date: Fri, 24 Feb 95 13:58:11 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9502241258.AA14836@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@nic.funet.fi, dev@flevel.demon.co.uk Subject: Re: ENV: and ixemul startup (fwd) > gcc -o myprog myprog.o -noenv I think that the startup-code is in the library itself, so it won't help. Joerg. From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 15:45:53 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <91169-3>; Fri, 24 Feb 1995 15:39:24 +0200 Received: from theory.cs.uni-bonn.de by funet.fi with SMTP (PP); Fri, 24 Feb 1995 15:39:13 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.6.9/8.6.9) id NAA25631; Fri, 24 Feb 1995 13:11:03 +0100 Date: Fri, 24 Feb 1995 13:11:03 +0100 From: Ignatios Souvatzis Message-Id: <199502241211.NAA25631@theory.cs.uni-bonn.de> To: csg94@ecs.soton.ac.uk CC: amiga-gcc-port@nic.funet.fi In-reply-to: Chris Goodall's message of Thu, 23 Feb 1995 16:05:34 +0000 (GMT) <27677.9502231605@davinci.ecs.soton.ac.uk> Subject: GCC 2.6.3 C++ Crashes X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a; Fri, 24 Feb 1995 15:52:32 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA16267; Fri, 24 Feb 95 06:51:46 MST Date: Fri, 24 Feb 1995 06:51:45 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: Philippe BRAND Cc: Will Bow , Amiga-Gcc Liste Subject: Re: ENV: and ixemul startup (fwd) In-Reply-To: <199502240945.JAA12255@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 24 Feb 1995, Philippe BRAND wrote: > Will Bow writes: > > > > > gcc -o myprog myprog.o -noenv > > > What do others think? > > I like the idea! > > Why not, why not... I love this idea! Paul Ney From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 17:29:31 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91165-1>; Fri, 24 Feb 1995 17:21:16 +0200 Received: from jacobi.cms.dmu.ac.uk (se1dp@jacobi.cms.dmu.ac.uk [146.227.102.69]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id PAA17524 for ; Fri, 24 Feb 1995 15:22:35 GMT Received: by jacobi.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA092169247; Fri, 24 Feb 1995 15:20:47 GMT Date: Fri, 24 Feb 1995 15:20:46 +0000 (GMT) From: Derek Piper X-Sender: se1dp@jacobi.cms.dmu.ac.uk To: GCC Mail List Subject: GCC does less now. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I wrote earlier that I couldn't get programs to compile properly, all I got were a load of incomplete type errors. Well I have re-installed the include files like Eric Johanassen rightly suggested I do. I can't even get GCC to do anything now. When I invoke GCC on even the simplest programs like a helloworld.c program all it does is do some minimal disk access and return. No screen output and no executable. It does not even ask for the includes (I renamed the directories to get it to error (I wanted it to do *something*) but it just does nothing now. I have the GCC includes in GNU:Include, the GCC libs in GNU:Lib, the CBM 3.1 includes in GNU:OS-Include and the CBM 3.1 libs in GNU:OS-Lib. Before I had all includes in GNU:Include and all libs in GNU:Lib when I could compile simple programs, ie. those which only use stdio.h, but now, nothing. Can anybody suggest what I might be doing wrong ? Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 18:09:00 1995 Received: from postman.essex.ac.uk ([155.245.10.14]) by nic.funet.fi with SMTP id <91169-1>; Fri, 24 Feb 1995 18:04:01 +0200 Received: from postman.essex.ac.uk by postman.essex.ac.uk with SMTP (PP) id <03867-0@postman.essex.ac.uk>; Fri, 24 Feb 1995 16:02:38 +0000 From: Waland J F Date: Fri, 24 Feb 95 16:02:34 GMT Message-Id: <15558.9502241602@esl9.essex.ac.uk> To: I-AMIGA , amiga-gcc-port , mui Subject: mui and gcc (I mailed imaga a few days ago - did anyone get anything?) Hi, has anyone created a working libmui.a for gcc using the MUI dev pack? I tried the dice bits but it didn't work. jon From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 18:25:34 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91184-2>; Fri, 24 Feb 1995 18:19:10 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ad22097; 24 Feb 95 16:12 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA002pv; Fri, 24 Feb 95 14:48:02 GMT Date: Fri, 24 Feb 95 14:48:02 GMT Message-Id: <9502241448.AA002pu@flevel.demon.co.uk> Message-Id: <2041b29d.35b60-dev@flevel.demon.co.uk> In-Reply-To: <9502241258.AA14836@inf-wiss.uni-konstanz.de> (from Joerg-Cyril Hoehle ) (at Fri, 24 Feb 95 13:58:11 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: hoehle@inf-wiss.uni-konstanz.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ENV: and ixemul startup (fwd) Hi Joerg-Cyril, > > > gcc -o myprog myprog.o -noenv > I think that the startup-code is in the library itself, so it won't help. But the linked startup code (Which there must be some of) could tell the library if you want to use the enviroment or not. This would mean you can write programs with ixemu which don't take between 0.5 and 2 seconds to startup. Cheers, Trefor S. From amiga-gcc-port-owner@nic.funet.fi Fri Feb 24 19:22:13 1995 Received: from odb.rhein-main.de ([193.141.47.4]) by nic.funet.fi with SMTP id <91187-1>; Fri, 24 Feb 1995 19:19:23 +0200 Received: from laren by odb.rhein-main.de with uucp (Smail3.1.28.1 #5) id m0ri3fN-0003esC; Fri, 24 Feb 95 18:18 MET Received: by laren.rhein-main.de (V1.16/Amiga) id AA002m0; Fri, 24 Feb 95 10:01:32 CET Date: Fri, 24 Feb 95 10:01:32 CET Message-Id: <9502240901.AA002lz@laren.rhein-main.de> X-Mailer: //\\miga Electronic Mail (AmiElm 4.159) Content-Length: 524 From: s.zeiger@laren.rhein-main.de (Stefan Zeiger) To: amiga-gcc-port@nic.funet.fi Subject: ObjectiveAmiga 0.1 available [Note: This is a repost; My first attempt didn't make it onto the mailing list] I've just uploaded the first snapshot of ObjectiveAmiga (my Objective C runtime system & class libraries) to AmiNet. By the time you read this, it should be available as objam01.lha in dev/gcc. -- Stefan Zeiger, Seligenstaedter Weg 24, 63796 Kahl, Germany; Voice: +49-6188-2525 (after 6PM GMT); EMail: s.zeiger@laren.rhein-main.de ADSP: ETG235, stefan@wwsp.adsp.sub.org; FidoNet: 2:244/6302.15; ...if(2B|!2B) user->prefs.shakespeare=TRUE; From amiga-gcc-port-owner@nic.funet.fi Sat Feb 25 10:01:34 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91185-4>; Sat, 25 Feb 1995 09:59:40 +0200 Received: by theseas.ntua.gr with UUCP; Sat, 25 Feb 1995 10:01:18 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <066i@kriton.UUCP>; Fri, 24 Feb 95 22:24:12 EET Date: Fri, 24 Feb 95 22:24:12 EET Message-Id: <9502242024.066i@kriton.UUCP> In-Reply-To: (from Walter Harms ) (at Fri, 24 Feb 1995 00:21:13 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1253 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: Walter.Harms@arbi.informatik.uni-oldenburg.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Stack checking, take 2 Hi Walter (Walter Harms), in on Feb 24 you wrote: > whats bad with a guru ? you can return , opens its own screen ^^^^^^^^^^^^^^^^^^^^^^^ :-) :-) :-) :-) :-) :-) The whole point of stack checking is to reduce the probability of a guru meditation occurring. Opening a screen to display the error message is as bad as poping up a requester, if the program has specifically requested not to get requesters by setting pr_WindowPtr = -1. The solution which I have currently implemented in my working version is the following: * If pr_WindowPtr is not -1, then pop up the requester on pr_WindowPtr (the default, pr_WindowPtr=0, conveniently results in the requester appearing on the Workbench/Default Public Screen). * Otherwise, if Output() is not null, print an error message there. * Otherwise, simply exit. If the program does not want requesters, and it does not provide an output window, then there is little we can do. (Is there?) -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "The thing is, Doctor, is there anything *I* can do?" "Yes, pass me a silicon rod, will you?" ----- From amiga-gcc-port-owner@nic.funet.fi Sun Feb 26 12:41:47 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91220-3>; Sun, 26 Feb 1995 12:38:25 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA16814 (5.65c-6/7.3w-FAU); Sun, 26 Feb 1995 11:38:15 +0100 Received: from faui8s4.informatik.uni-erlangen.de by immd8.informatik.uni-erlangen.de; id AA25686 (5.x/7.3w-FAU); Sun, 26 Feb 1995 11:38:14 +0100 Date: Sun, 26 Feb 1995 11:38:14 +0100 From: Tobias Ruland Message-Id: <9502261038.AA25686@immd8.informatik.uni-erlangen.de> Received: by faui8s4.informatik.uni-erlangen.de (4.1/SMI-4.1) id AA00359; Sun, 26 Feb 95 11:38:13 +0100 To: Derek Piper Subject: GCC does less now. In-Reply-To: References: Cc: amiga-gcc-port@lists.funet.fi high derek Derek Piper writes: > can't even get GCC to do anything now. When I invoke GCC on even the simplest > programs like a helloworld.c program all it does is do some minimal disk access > and return. No screen output and no executable. It does not even ask for the > includes (I renamed the directories to get it to error (I wanted it to do > *something*) but it just does nothing now. > nothing. Can anybody suggest what I might be doing wrong ? maybe you should post the output of gcc hellworld.c -v ^^ sometimes gcc doesnt do anything on my amiga if the stack is too small or memory too fragmented... c u tobias -------------------------------------------------------------------------- Tobias Ruland MAIL: tsruland@immd8.informatik.uni-erlangen.de WWW: http://www8.informatik.uni-erlangen.de/~tsruland From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 00:07:49 1995 Received: from godot.lysator.liu.se ([130.236.254.154]) by nic.funet.fi with ESMTP id <91243-3>; Mon, 27 Feb 1995 00:05:04 +0200 Received: from rune.lysator.liu.se (rune.lysator.liu.se [130.236.254.23]) by godot.lysator.liu.se (8.6.8.1/8.6.6) with ESMTP id WAA05245 for ; Sun, 26 Feb 1995 22:56:27 +0100 Received: (from nisse@localhost) by rune.lysator.liu.se (8.6.8.1/8.6.6) id WAA00625; Sun, 26 Feb 1995 22:56:21 +0100 Date: Sun, 26 Feb 1995 22:56:21 +0100 From: nisse@lysator.liu.se Message-Id: <199502262156.WAA00625@rune.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: amiga-gcc-port@nic.funet.fi In-reply-to: <199502241251.NAA05519@honshu.informatik.uni-rostock.de> (message from Gunther Nikl on Fri, 24 Feb 1995 13:51:27 +0100 (MET)) Subject: Re: misc. garbage > BTW: Why does -msmall-code set -fno-function-cse in the default > specs-file? The reason is simple: if you compile with "-msmall-code" your code has to fit (almost) into 32k. Every function should be accessable with "bsr.W". If "-fno-function-cse" is not given gcc may stuff function addresses into registers. Thats not always a good idea (especially if gcc uses a data register). Gunther I don't understand why it is not good to store function pointers into registers, and in particular I don't understand what makes it bad when using small pc-relative addressing. What's wrong with lea _some_func(pc),a3 ; 16-bit pc-relative addressing jsr (a3) instead of bsr.w _some_func ; 16-bit pc-relative addressing I can't see any significant difference. I haven't looked into what code gcc actually generates, but I think that the above is what it should generate when given the small-code option. /Niels From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 09:37:38 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91265-3>; Mon, 27 Feb 1995 09:34:13 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA11493; Mon, 27 Feb 95 09:30:55 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA04446; Mon, 27 Feb 95 09:35:10 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502270735.AA04446@hpcl.cti.gr> Subject: Re: Stack checking, take 2 To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Mon, 27 Feb 1995 09:35:07 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: from "Walter Harms" at Feb 26, 95 06:01:54 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 556 > i have the strange feeling that there is a basic missunderstanding > about the nature off this guru. my suggestion was to create one > instead a saying nothing with intuition (displayalert(), i hope). I figured as much. My point was that if the user does not want a requester, why on earth would they want a guru instead? (The code I posted would not guru if pr_WindowPtr==-1. It would just pop up an unwanted requester on the default public/workbench screen.) -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 10:41:23 1995 Received: from feld.cvut.cz ([147.32.192.2]) by nic.funet.fi with SMTP id <91234-2>; Mon, 27 Feb 1995 10:37:12 +0200 Received: from k332.feld.cvut.cz by feld.cvut.cz with SMTP (5.65/25-eef) id AA23921; Mon, 27 Feb 95 10:30:20 +0100 Return-Path: Received: by k332.feld.cvut.cz (4.1/SMI-4.1) id AA28163; Mon, 27 Feb 95 08:24:45 GMT From: mjsoft@k332.feld.cvut.cz (Martin Mares) Message-Id: <9502270824.AA28163@k332.feld.cvut.cz> Subject: Re: Stack checking To: amiga-gcc-port@lists.funet.fi Date: Mon, 27 Feb 95 8:24:44 GMT X-Mailer: ELM [version 2.3 PL11] Hi Kriton, > The whole point of stack checking is to reduce the probability of a guru > meditation occurring. Opening a screen to display the error message is as bad > as poping up a requester, if the program has specifically requested not to get > requesters by setting pr_WindowPtr = -1. The solution which I have currently > implemented in my working version is the following: > > * If pr_WindowPtr is not -1, then pop up the requester on pr_WindowPtr > (the default, pr_WindowPtr=0, conveniently results in the requester > appearing on the Workbench/Default Public Screen). > > * Otherwise, if Output() is not null, print an error message there. > > * Otherwise, simply exit. If the program does not want requesters, > and it does not provide an output window, then there is little we > can do. (Is there?) I think that if everything else fails, you should examine also standard error stream (and use it if it's non-NULL). If it's NULL, try pr_ConsoleTask -- if non-NULL, open "*" and use it. If even pr_ConsoleTask is null, you should simply exit without any message. Martin Mares From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 11:38:49 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91169-2>; Mon, 27 Feb 1995 11:30:13 +0200 Received: from hazel.cms.dmu.ac.uk (se1dp@hazel.cms.dmu.ac.uk [146.227.102.14]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id JAA13476 for ; Mon, 27 Feb 1995 09:31:43 GMT Received: by hazel.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA019157402; Mon, 27 Feb 1995 09:30:02 GMT Date: Mon, 27 Feb 1995 09:30:02 +0000 (GMT) From: Derek Piper X-Sender: se1dp@hazel.cms.dmu.ac.uk To: GCC Mail List Subject: GCC slightly better Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, The previous problem was all my fault I'm afraid. Having no luck with compiling anything I though about re-installing the whole lot of GCC files. Upon unarchiving the GCC263-C-020.Lha I realised that when I had removed and re-installed all the libraries and includes from GCC263-Inclib.lha I had forgotten about the main GCC-Lib drawer, found only in the main archive. I can compile standard ANSI C programs now, but I still have the problem of not being able to compile any Amiga-related programs. I have tried to compile this program below, which is Example3.c from the Amiga C Club C Manual part System/AmigaDOS.... /***********************************************************/ /* */ /* Amiga C Encyclopedia (ACE) V3.0 Amiga C Club (ACC) */ /* ------------------------------- ------------------ */ /* */ /* Book: ACM System Amiga C Club */ /* Chapter: AmigaDOS Tulevagen 22 */ /* File: Example3.c 181 41 LIDINGO */ /* Author: Anders Bjerin SWEDEN */ /* Date: 92-05-02 */ /* Version: 1.10 */ /* */ /* Copyright 1992, Anders Bjerin - Amiga C Club (ACC) */ /* */ /* Registered members may use this program freely in their */ /* own commercial/noncommercial programs/articles. */ /* */ /***********************************************************/ /* This example demonstrates how to rename files and directories. It */ /* will rename the file Example 1 created (called "HighScore.dat") to */ /* "Numbers.dat". It will also rename the directory Example 2 created */ /* ("MyDirectory") to "NewDirectory". */ /* This file declares the type BOOL: */ #include void main(); void main() { BOOL ok; /* Rename the file: */ ok = Rename( "RAM:HighScore.dat", "RAM:Numbers.dat" ); /* Check if the file was successfully renamed: */ if( !ok ) printf( "The file could not be renamed!\n" ); /* Rename the directory: */ ok = Rename( "RAM:MyDirectory", "RAM:NewDirectory" ); /* Check if the directory was successfully renamed: */ if( !ok ) printf( "The directory could not be renamed!\n" ); } The result I get when compiling this with the -v option is thus : Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Dmc68010 example3.c t:cc408120.i GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1 t:cc408120.i -quiet -dumpbase example3.c -version -o t:cc408120.s GNU C version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3 snapshot 941209. example3.c: In function `main': example3.c:33: warning: return type of `main' is not `int' as -mc68010 -o t:cc4081201.o t:cc408120.s ld -o Example3 /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/local/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/gnu/lib -L/local/lib -L/local/lib t:cc4081201.o -lgcc -lc -lgcc t:cc4081201.o: Undefined symbol _Rename referenced from text segment t:cc4081201.o: Undefined symbol _Rename referenced from text segment Do I have to include any other files ? or is there something fundamentally wrong with what I am trying to do ? I have tried other programs and examples and all of them give some sort of error messages out. Cheers. Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 11:47:48 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91180-3>; Mon, 27 Feb 1995 11:41:24 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA02076; Mon, 27 Feb 95 11:37:25 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA06927; Mon, 27 Feb 95 11:41:27 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502270941.AA06927@hpcl.cti.gr> Subject: Re: Stack checking To: REH@softlab.de Date: Mon, 27 Feb 1995 11:41:24 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9502270853.AA02421@GWEU.softlab.de > from "REH@softlab.de" at Feb 27, 95 09:58:48 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1941 > If I used stack checking code in my program, I'd like to be notified > if it detects stack overflow. After all that's why I built it in. That's why I don't like the idea of doing nothing if I can't display an error message, either, pr_WindowPtr or not. (After all, disabling requesters is usually done so that the program can continue when something like opening a non-existent file occurs. As the program can't continue execution after a stack overflow, popping up a requester or recoverable alert is not so bad, after all.) > And is a requester really the right choice to notify the user that his > program *must* terminate? Isn't it rather a kind of a recoverable > alert? I don't remember the C= Style Guide too well, but I think it says > that requesters should leave the user a *choice*, such as to insert a > missing disk or to cancel. When the program is out of stack, there's > not much choice left, is it? I don't know what the C= Style guide says on this subject, either, so I can't give a definitive answer. I do know that SAS/C always pops up a requester looking something like: +--------------------------+ | progname: | | Stack Overflow | | ______ | | |EXIT| | | ------ | +--------------------------+ whenever they detect a stack overflow. Given the arguments at the beginning of this message, I would tend to dismiss the complicated solution which I began to implement, where different actions are taken according to the value of pr_WindowPtr and the availability of output windows. Instead, I'd lean towards one of the following two alternatives: 1. Do it the SAS/C way, unconditionally popping up a requester. 2. Unconditionally display a recoverable alert. (Not a guru!) Can someone with access to the Style Guide suggest which one is better? -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 12:00:06 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91165-1>; Mon, 27 Feb 1995 11:54:23 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA02427; Mon, 27 Feb 95 11:50:15 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA07077; Mon, 27 Feb 95 11:54:08 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502270954.AA07077@hpcl.cti.gr> Subject: Re: GCC slightly better To: se1dp@dmu.ac.uk (Derek Piper) Date: Mon, 27 Feb 1995 11:54:02 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: from "Derek Piper" at Feb 27, 95 09:30:02 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1372 > t:cc4081201.o: Undefined symbol _Rename referenced from text segment > t:cc4081201.o: Undefined symbol _Rename referenced from text segment > > > Do I have to include any other files ? or is there something > fundamentally wrong with what I am trying to do ? I have tried other > programs and examples and all of them give some sort of error messages out. This is basically a bug in the way gcc calls the linker, where it forgets to link with libamiga.a when linking ixemul programs. You can get around this in various ways: 1. Use gcc's -noixemul switch. This will link with a different C run-time library, and gcc will call the linker correctly for it. As you are compiling amiga-specific programs, I would recommend this solution. 2. Specifically ask to link with libamiga.a: when linking, add the switch -lamiga in the end of the command line. (If you have replaced libamiga.a with one derived from CBM's amiga.lib, use -lc -lamiga instead, as the two libraries contain some conflicting symbols (e.g., printf), and you don't want to get the amiga.lib versions.) 3. Include appropriate prototype files in your code, and compile with the optimizer turned on. This requires knowing which files to include, e.g. in the program you posted you need to include . If you do this, your program will need more memory to compile. I hope this helps, From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 13:26:06 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91226-4>; Mon, 27 Feb 1995 13:16:41 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA20266; Mon, 27 Feb 1995 11:16:35 GMT From: Peter Ivimey-Cook Message-Id: <23166.199502271115@creda.isltd.insignia.com> Subject: Re: Stack checking To: kyrimis@theseas.ntua.gr Date: Mon, 27 Feb 1995 11:15:04 GMT Cc: REH@softlab.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <9502270941.AA06927@hpcl.cti.gr>; from "Kriton Kyrimis" at Feb 27, 95 11:41 am X-Mailer: elm X-Mailer: Elm [revision: 109.14] > Given the arguments at the beginning of this message, I would tend to > dismiss the complicated solution which I began to implement, where > different actions are taken according to the value of pr_WindowPtr and > the availability of output windows. Instead, I'd lean towards one of > the following two alternatives: > > 1. Do it the SAS/C way, unconditionally popping up a requester. > 2. Unconditionally display a recoverable alert. (Not a guru!) > > Can someone with access to the Style Guide suggest which one is > better? >From what I remember, it doesn't (mention it, that is!) I would suggest the use of pr_WindowPtr if it's OK. If not, then use a recoverable alert. Don't use Output() as it may be redirected to a file & never noticed! On the form of the alert; I would suggest the current stack size, and, if possible nesting depth and current PC was also included in the message printed. I would also prefer a more English way of putting it - remember this may be seen by naieve users too! For example: +--------------------------------------+ | Program "progname" has exceeded it's | | stack limit of %dKb. Please increase | | the stack allocated to it before re- | | running it. | | ______ | | |EXIT| | | ------ | +--------------------------------------+ Whatwver happened to Philippe's attempts to get an automatic stack growth routine working though? Regards, Peter -- Peter Ivimey-Cook Mail Id: peteric@isltd.insignia.com Insignia Solutions, Kingsmead Business Park, London Road, High Wycombe, Buckinghamshire. Telephone: +44-1494-459426 HP11 1JU, U.K. Fax: +44-1494-459720 From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 14:40:55 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91164-3>; Mon, 27 Feb 1995 14:32:17 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA08058; Mon, 27 Feb 95 14:28:50 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA09591; Mon, 27 Feb 95 14:33:06 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502271233.AA09591@hpcl.cti.gr> Subject: Re: Stack checking To: peteric@insignia.co.uk (Peter Ivimey-Cook) Date: Mon, 27 Feb 1995 14:33:03 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <23166.199502271115@creda.isltd.insignia.com> from "Peter Ivimey-Cook" at Feb 27, 95 11:15:04 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 607 > printed. I would also prefer a more English way of putting it - remember > this may be seen by naieve users too! What a novel idea! :-) (Sounds useful, actually.) > Whatwver happened to Philippe's attempts to get an automatic stack growth > routine working though? I wouldn't know, but I'm also looking into it, independently. (My efforts have reached the stage where I've convinced myself that it is possible, and I have a rough idea of what needs to be done, so I'm a long way away from suggesting a solution.) -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 14:57:45 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91163-2>; Mon, 27 Feb 1995 14:50:51 +0200 Received: by colombo.telesys-innov.fr; Mon, 27 Feb 1995 13:47:14 GMT From: Philippe BRAND Message-Id: <199502271347.NAA20300@colombo.telesys-innov.fr> Subject: Re: Stack checking To: kyrimis@theseas.ntua.gr Date: Mon, 27 Feb 1995 13:47:13 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9502271233.AA09591@hpcl.cti.gr> from "Kriton Kyrimis" at Feb 27, 95 02:33:03 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 519 Kriton Kyrimis writes: > I wouldn't know, but I'm also looking into it, independently. (My efforts have > reached the stage where I've convinced myself that it is possible, and I have > a rough idea of what needs to be done, so I'm a long way away from suggesting > a solution.) As for now I'm totally busy compiling new snapshots and test them, a more than that as soon as I've compiled one, a new set of diffs are released ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 16:18:38 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91219-1>; Mon, 27 Feb 1995 16:09:47 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id aa21748; 27 Feb 95 13:57 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA003dp; Mon, 27 Feb 95 09:35:07 GMT Date: Mon, 27 Feb 95 09:35:07 GMT Message-Id: <9502270935.AA003do@flevel.demon.co.uk> Message-Id: <20455dc8.e09c0-dev@flevel.demon.co.uk> In-Reply-To: <199502262156.WAA00625@rune.lysator.liu.se> (from nisse@lysator.liu.se) (at Sun, 26 Feb 1995 22:56:21 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: nisse@lysator.liu.se Cc: amiga-gcc-port@nic.funet.fi Subject: Re: misc. garbage Hi nisse, > > BTW: Why does -msmall-code set -fno-function-cse in the default > > specs-file? > > The reason is simple: if you compile with "-msmall-code" your code > has to fit (almost) into 32k. Every function should be accessable > with "bsr.W". If "-fno-function-cse" is not given gcc may stuff > function addresses into registers. Thats not always a good idea > (especially if gcc uses a data register). > > Gunther > > I don't understand why it is not good to store function pointers into > registers, and in particular I don't understand what makes it bad when > using small pc-relative addressing. What's wrong with > > lea _some_func(pc),a3 ; 16-bit pc-relative addressing > jsr (a3) There is nothing wrong with this. > instead of > > bsr.w _some_func ; 16-bit pc-relative addressing > > I can't see any significant difference. I haven't looked into what > code gcc actually generates, but I think that the above is what it > should generate when given the small-code option. However:- a) bsr.w is a lot faster than an lea followed by a jsr. b) The lea uses a register which leaves you with less registers for parameter passing. c) A lea (pc) can also only address +/- 32K. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 16:26:59 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91220-3>; Mon, 27 Feb 1995 16:15:57 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA14729; Mon, 27 Feb 95 16:12:10 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA11157; Mon, 27 Feb 95 16:15:59 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9502271415.AA11157@hpcl.cti.gr> Subject: Re: Stack checking, take 2 To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Mon, 27 Feb 1995 16:15:56 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9502271343.AA21028@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Feb 27, 95 02:43:00 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1080 > I believe you should check stderr (pr_CES and "*") before Output(). > When you exit, use a return code of 20 or more. Sounds reasonable. > A program can continue execution after this if it's able to handle it. > As an example, CLISP does it own stack checking and jumps to a > top-level loop if this happens. This would mean that the program would supply its own stack overflow handler, in which case whatever the default handler does is irrelevant. > I wouldn't do anything unconditionaly. Examining pr_WindowPtr ist just > ok IMHO. A recoverable alert is not as nice as an autorequest window. I agree about the alerts. The big question is, what should the handler do if its not supposed to pop up a requester, and it can't find a file handle to print an error message. I don't think that exiting without any indication is nice. Perhaps, failing everything, the handler should pop up a requester on the default public screen, even though the program has specifically forbidden it. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 17:05:48 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91231-4>; Mon, 27 Feb 1995 16:49:12 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA21671; Mon, 27 Feb 1995 14:49:05 GMT From: Peter Ivimey-Cook Message-Id: <23960.199502271447@creda.isltd.insignia.com> Subject: Re: Stack checking, take 2 To: kyrimis@theseas.ntua.gr Date: Mon, 27 Feb 1995 14:47:32 GMT Cc: hoehle@inf-wiss.uni-konstanz.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <9502271415.AA11157@hpcl.cti.gr>; from "Kriton Kyrimis" at Feb 27, 95 4:15 pm X-Mailer: elm X-Mailer: Elm [revision: 109.14] Folks, > The big question is, what should the handler do if its not supposed to > pop up a requester, and it can't find a file handle to print an error > message. I don't think that exiting without any indication is nice. > Perhaps, failing everything, the handler should pop up a requester on > the default public screen, even though the program has specifically > forbidden it. I repeat: DO NOT write to arbitrary file handles (and Output() is an arbitrary handle). At *least* ensure it refers to a console task (use the IsFileSystem() calls). Writing to a filehandle could cause all sorts of problems - Output() handles could be used to write binary data just as easily as any other, and the resulting data file would be corrupt without anyone being the wiser. I guess the error stream is less likely, but doesn't always exist! I would say - either use an autorequest or use an alert, or in extremis see if Open("*",..) works & use that. If not - how about writing to sprintf(buf, "t:%s-%d.err", progname, FindTask()); or some such. My preference is AutoRequest(pr_WindowPtr) if not pr_WindowPtr is not -1, which would honour requests to move to another screen, else use Alert(). I would also accept AutoRequest all the time, although the reason for the -1 could be that the program has done something special with the display. Regards, Peter -- Peter Ivimey-Cook Mail Id: peteric@isltd.insignia.com Insignia Solutions, Kingsmead Business Park, London Road, High Wycombe, Buckinghamshire. Telephone: +44-1494-459426 HP11 1JU, U.K. Fax: +44-1494-459720 From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 17:09:09 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91235-3>; Mon, 27 Feb 1995 16:52:07 +0200 Received: by ceylon.informatik.uni-rostock.de id PAA13670; Mon, 27 Feb 1995 15:51:36 +0100 Received: by honshu.informatik.uni-rostock.de id PAA13293; Mon, 27 Feb 1995 15:51:35 +0100 From: Gunther Nikl Message-Id: <199502271451.PAA13293@honshu.informatik.uni-rostock.de> Subject: Re: misc. garbage To: dev@flevel.demon.co.uk Date: Mon, 27 Feb 1995 15:51:34 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <20455dc8.e09c0-dev@flevel.demon.co.uk> from "dev@flevel.demon.co.uk" at Feb 27, 95 09:35:07 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1248 Hello, > I don't understand why it is not good to store function pointers into > registers, and in particular I don't understand what makes it bad when > using small pc-relative addressing. What's wrong with > > lea _some_func(pc),a3 ; 16-bit pc-relative addressing > jsr (a3) > instead of Look at the asm-output. You won't find *any* reference that is pc-relative! Actually the assembler converts absolute "lea function,a?" into pc-relative addressing BUT only if assembling for >mc68020 and if "function" is located in the same source before this place. And what about "move.l #function,d4"? Anyway, if the user specifies "-msmall-code" then he thinks the code fits into 32k. To avoid those ugly "movel" or "lea" I would suggest to turn on "-fno-function-cse". > bsr.w _some_func ; 16-bit pc-relative addressing > > I can't see any significant difference. I haven't looked into what > code gcc actually generates, but I think that the above is what it > should generate when given the small-code option. No! gcc always generates code like "jbsr function". Its upto the assembler to use "bsr" or "jsr". Look at the specs-file "-msmall-code" is a switch for the assembler and not for the compiler. Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Feb 27 17:50:39 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91233-4>; Mon, 27 Feb 1995 17:37:50 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA09561 (5.65c8/IDA-1.4.4 for ); Mon, 27 Feb 1995 16:37:21 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA09068; Mon, 27 Feb 95 16:37:21 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9502271537.AA09068@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Stack checking, take 2 To: peteric@isltd.insignia.com (Peter Ivimey-Cook) Date: Mon, 27 Feb 1995 16:37:21 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <23960.199502271447@creda.isltd.insignia.com> from "Peter Ivimey-Cook" at Feb 27, 95 02:47:32 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1065 > > My preference is AutoRequest(pr_WindowPtr) if not pr_WindowPtr is not -1, which > would honour requests to move to another screen, else use Alert(). I would also > accept AutoRequest all the time, although the reason for the -1 could be that the > program has done something special with the display. > Please don't use Alert(): * I heard that you can't see an alert on some combinations of graphics card/monitor. (Cannot check this myself). * Alert() stops the system completely which is much worse than a requester - and if someone doesn't want to pop up requesters he is most likely doing his work over some remote connection. Guess what he will say to alerts? * A stack overflow (if detected) isn't a sign of a somehow unstable system like other alerts. It is (or should be) more something like: "Please set a higher stack to continue working". No need to frighten users. Just my 3 Cent. My preference for ixemul.library would be raising SIGSEGV, however - exactly like on unix-boxes when you raise your stack over the VM limit. Matthias From amiga-gcc-port-owner@nic.funet.fi Tue Feb 28 02:35:16 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91334-3>; Mon, 27 Feb 1995 20:46:42 +0200 Received: by theseas.ntua.gr with UUCP; Mon, 27 Feb 1995 20:48:48 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <068t@kriton.UUCP>; Mon, 27 Feb 95 20:44:26 EET Date: Mon, 27 Feb 95 20:44:26 EET Message-Id: <9502271844.068t@kriton.UUCP> In-Reply-To: <9502271537.AA09068@sunserv.IZFM.Uni-Stuttgart.DE> (from fleischr@izfm.uni-stuttgart.de (Matthias Fleischer)) (at Mon, 27 Feb 1995 16:37:21 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1506 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: fleischr@izfm.uni-stuttgart.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Stack checking, take 2 Hi Matthias (Matthias Fleischer), in <9502271537.AA09068@sunserv.IZFM.Uni-Stuttgart.DE> on Feb 27 you wrote: > Please don't use Alert(): > * I heard that you can't see an alert on some combinations of > graphics card/monitor. (Cannot check this myself). Oops! forgot about that! > * Alert() stops the system completely which is much worse than a > requester - and if someone doesn't want to pop up requesters he is > most likely doing his work over some remote connection. Guess what > he will say to alerts? Probably the same thing he'll say to the requester that has popped up on the amiga on the other side of the line: #@^%$#@^%$#!!! :-) > * A stack overflow (if detected) isn't a sign of a somehow unstable > system like other alerts. It is (or should be) more something like: > "Please set a higher stack to continue working". No need to frighten > users. I wouldn't trust completely a system where a stack overflow occurred. If the overflow was more than the extra space provided for (128 bytes in SAS's and my implementation), the program has definitely written somewhere where it shouldn't have. > My preference for ixemul.library would be raising SIGSEGV, however - > exactly like on unix-boxes when you raise your stack over the VM limit. Now that's an interesting notion... -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "What would *I* do if I were me?" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Feb 28 02:35:16 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91325-4>; Mon, 27 Feb 1995 20:31:40 +0200 Received: by theseas.ntua.gr with UUCP; Mon, 27 Feb 1995 20:33:51 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <068n@kriton.UUCP>; Mon, 27 Feb 95 20:26:12 EET Date: Mon, 27 Feb 95 20:26:12 EET Message-Id: <9502271826.068n@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 5202 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Stack cecking, take 2 1/2 Summarizing the responses to my previous posting of the stack checking code, we have: * The overflow handler should not pop up requesters indiscriminately. It should respect pr_WindowPtr, displaying its requester on that window, or not at all if pr_WindowPtr=-1. * The overflow handler should not write on any file handlers, as they might point to files, and no one will notice. If the file handler points to a binary file, the file will also get scramble. (I should have known better before I suggested this; this is exactly the reason I came up with the stderrfix hack.) * The overflow handler should not just exit silently. Popping up a requester despite the user's having set pr_WindowPtr=-1 would suffice in general, but someone pointed out that the program might be doing weird things with the screen, so the requester might not be able to appear. Thus, a recoverable alert is preferred to a requester in this case. * The error message should be a bit more informative than simply "stack overflow". I think I have covered all these items in the latest version of stackcheck_setup.c, which I present for your scrutiny. Compile with -DTEST if you want to see the requester without actually causing a stack overflow. (I am not reposting the stackcheck program, hence the "1/2" in the subject line. Philippe is working on adding a stack checking option to gcc, so hopefully we can throw stackcheck away.) As always, comments are welcome, use at your own risk. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "What would *I* do if I were me?" ----- #include #include #include #define BASE_EXT_DECL #define BASE_EXT_DECL0 static struct IntuitionBase *IntuitionBase; #include #include #define SPARE 128 unsigned long _StackBottom; unsigned long _StackTop; static unsigned long _StackOrig; static int Argc; static char **Argv; void _StackOverflow(void); int main(int argc, char *argv[]) { register unsigned long sp asm("sp"); unsigned long _StackSize; struct Task *t; struct Process *p; Argc = argc; Argv = argv; t = FindTask(0L); _StackBottom = (unsigned long)t->tc_SPLower; _StackTop = (unsigned long)t->tc_SPUpper; _StackOrig = sp; if (_StackOrig > _StackTop || _StackOrig < _StackBottom) { p = (struct Process *)t; /* pr_ReturnAddr points to the stack size. Next word is the return address, then the first word outside the stack, i.e., stack bottom + stack size. This is the reason for the adjustment by 2 * sizeof(ULONG). */ _StackTop = (unsigned long)p->pr_ReturnAddr + 2 * sizeof(ULONG); _StackSize = *(unsigned long *)p->pr_ReturnAddr; _StackBottom = _StackTop - _StackSize; if (_StackOrig > _StackTop || _StackOrig < _StackBottom) { _StackBottom = 0; /* No stack checking possible */ } } _StackBottom += SPARE; /* Leave some space for arguments */ #ifdef TEST _StackOverflow(); #else return stackcheck_main(argc, argv); #endif /* TEST */ } #define LINE1 "Program \"%s\" has exceeded its" #define LINE2 "stack limit of %ld bytes." #define LINE3 "Please increase the stack allocated" #define LINE4 "to it before rerunning it." #define HIT "Hit any mouse button to exit program." #define ADDTOALERT(xx, yy, text, contbyte)\ x = xx,\ y = yy,\ memcpy(alertpos, (char *)&x, sizeof(x)),\ memcpy(alertpos+2, (char *)&y, sizeof(y)),\ alertpos += 3,\ strcpy(alertpos, text),\ alertpos += (strlen(text) + 1),\ *alertpos++ = contbyte void _StackOverflow(void) { /* DO NOT use auto variables here, unless you know what you're doing! */ static struct IntuiText Line4 = {1, 0, JAM1, 0, 30, NULL, (UBYTE *)LINE4, NULL}; static struct IntuiText Line3 = {1, 0, JAM1, 0, 20, NULL, (UBYTE *)LINE3, &Line4}; static struct IntuiText Line2 = {1, 0, JAM1, 0, 10, NULL, NULL, &Line3}; static struct IntuiText Line1 = {1, 0, JAM1, 0, 0, NULL, NULL, &Line2}; static struct IntuiText NegText = {1, 0, JAM1, 0, 0, NULL, (UBYTE *)"EXIT", NULL}; register unsigned long sp asm("sp"); static struct Window *w; static UBYTE buf1[60], buf2[32]; static char alertmsg[256], *alertpos; static short x; static unsigned char y; #ifndef TEST sp = _StackOrig; /* Restore stack to a sane value */ #endif /* TEST */ sprintf(buf1, LINE1, (Argc > 0) ? FilePart(Argv[0]) : (STRPTR)((struct WBStartup *)Argv)->sm_ArgList[0].wa_Name); sprintf(buf2, LINE2, _StackTop-_StackBottom+SPARE); Line1.IText = buf1; Line2.IText = buf2; IntuitionBase = (struct IntuitionBase *)OldOpenLibrary("intuition.library"); w = (struct Window *)((struct Process *)FindTask(0L))->pr_WindowPtr; if ((int)w >= 0) { AutoRequest(w, &Line1, NULL, &NegText, 0, 0, 516, 147); }else{ alertpos = alertmsg; ADDTOALERT(8, 10, buf1, 1); ADDTOALERT(8, 20, buf2, 1); ADDTOALERT(8, 30, LINE3, 1); ADDTOALERT(8, 40, LINE4, 1); ADDTOALERT(8, 60, HIT, 0); DisplayAlert(RECOVERY_ALERT, alertmsg, 67); } CloseLibrary((struct Library *)IntuitionBase); exit(RETURN_FAIL); } From amiga-gcc-port-owner@nic.funet.fi Tue Feb 28 19:22:44 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91194-1>; Tue, 28 Feb 1995 19:12:09 +0200 Received: by ceylon.informatik.uni-rostock.de id SAA17355; Tue, 28 Feb 1995 18:11:57 +0100 Received: by honshu.informatik.uni-rostock.de id SAA17457; Tue, 28 Feb 1995 18:11:55 +0100 From: Gunther Nikl Message-Id: <199502281711.SAA17457@honshu.informatik.uni-rostock.de> Subject: Re: Stack cecking, take 2 1/2 To: kyrimis@theseas.ntua.gr Date: Tue, 28 Feb 1995 18:11:55 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9502271826.068n@kriton.UUCP> from "Kriton Kyrimis" at Feb 27, 95 08:26:12 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 618 > void > _StackOverflow(void) > { > /* DO NOT use auto variables here, unless you know what you're doing! */ > static struct IntuiText Line4 = > {1, 0, JAM1, 0, 30, NULL, (UBYTE *)LINE4, NULL}; > static struct IntuiText Line3 = > {1, 0, JAM1, 0, 20, NULL, (UBYTE *)LINE3, &Line4}; > static struct IntuiText Line2 = > {1, 0, JAM1, 0, 10, NULL, NULL, &Line3}; > sprintf(buf1, LINE1, (Argc > 0) ? FilePart(Argv[0]) ^^^^^^^^^^^^^^^^^ This a a 2.0+ function of dos.library. If you use this function you can also use EasyRequestArgs() for the requester! Gunther From amiga-gcc-port-owner@nic.funet.fi Tue Feb 28 22:15:00 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91207-1>; Tue, 28 Feb 1995 22:12:25 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 28 Feb 95 13:50 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 28 Feb 95 13:45 MET Message-Id: Subject: Re: Stack checking, take 2 To: kyrimis@theseas.ntua.gr Date: Tue, 28 Feb 1995 13:44:58 +0100 (MET) From: Walter Harms Cc: amiga-gcc-port@lists.funet.fi (amiga gcc-list) In-Reply-To: <9502271844.068t@kriton.UUCP> from "Kriton Kyrimis" at Feb 27, 95 08:44:26 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2342 > > Hi Matthias (Matthias Fleischer), in <9502271537.AA09068@sunserv.IZFM.Uni-Stuttgart.DE> on Feb 27 you wrote: > > > Please don't use Alert(): > > * I heard that you can't see an alert on some combinations of > > graphics card/monitor. (Cannot check this myself). > > Oops! forgot about that! who cares ? guru's are a part of the system. if they cant display them forget them. > > > * Alert() stops the system completely which is much worse than a > > requester - and if someone doesn't want to pop up requesters he is > > most likely doing his work over some remote connection. Guess what > > he will say to alerts? > > Probably the same thing he'll say to the requester that has popped up on > the amiga on the other side of the line: #@^%$#@^%$#!!! :-) > 1. stop completely you are in a multitasking enviroment, leaving the stack means poking in regions where no programm was before ? of cause not, you simply dont know whats going on there. 2. wasnt there a patch that sended requestern e.a. to the remote one ? working with parnet ? > > * A stack overflow (if detected) isn't a sign of a somehow unstable > > system like other alerts. It is (or should be) more something like: > > "Please set a higher stack to continue working". No need to frighten > > users. > maybe but maybe not, who knows ? to be on the safe side cant be wrong at all. > I wouldn't trust completely a system where a stack overflow occurred. If > the overflow was more than the extra space provided for (128 bytes in > SAS's and my implementation), the program has definitely written > somewhere where it shouldn't have. > > > My preference for ixemul.library would be raising SIGSEGV, however - > > exactly like on unix-boxes when you raise your stack over the VM limit. > > Now that's an interesting notion... i have a code (asm,mmu) for mem protection somewhere. shall i post it ? CFD: an other idea would be to patch the OS in general, there are several tools that do unixdirs,.. etc. maybe we can end in a new(er) OS ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Mar 1 13:42:52 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91263-1>; Wed, 1 Mar 1995 13:34:59 +0200 Received: from pine.cms.dmu.ac.uk (se1dp@pine.cms.dmu.ac.uk [146.227.102.22]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id LAA07117 for ; Wed, 1 Mar 1995 11:36:03 GMT Received: by pine.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA080867658; Wed, 1 Mar 1995 11:34:18 GMT Date: Wed, 1 Mar 1995 11:34:18 +0000 (GMT) From: Derek Piper X-Sender: se1dp@pine.cms.dmu.ac.uk To: GCC Mail List Subject: Reading Long Words Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I am currently trying to read long words (32bit integers) from a certain address in memory. I cannot work out how to do this though. I tried an Exec library function READ_LONG but it doesn't seem to work properly. All I want to be able to do is to load the value of an area of memory into a variable. I think it might be something to do with pointers, but I am not sure. Can anyone help ? Del. PS: Thanks to everyone who has helped me out in these past weeks. I has been very useful for me. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 1 14:06:15 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91221-3>; Wed, 1 Mar 1995 14:00:36 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA04487; Wed, 1 Mar 1995 12:00:27 GMT From: Peter Ivimey-Cook Message-Id: <25529.199503011158@creda.isltd.insignia.com> Subject: Re: Reading Long Words To: se1dp@dmu.ac.uk (Derek Piper) Date: Wed, 01 Mar 1995 11:58:46 GMT Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: ; from "Derek Piper" at Mar 1, 95 11:34 am X-Mailer: elm X-Mailer: Elm [revision: 109.14] > > I am currently trying to read long words (32bit integers) from > a certain address in memory. I cannot work out how to do this though. I tried > an Exec library function READ_LONG but it doesn't seem to work properly. All I > want to be able to do is to load the value of an area of memory into a variable. > I think it might be something to do with pointers, but I am not sure. Can anyone > help ? > You don't say which language you are using - I will assume C as this is the gcc list :) Try something like this: /* this one is fast, but can't cope with addresses which aren't aligned to 4 byte boundaries. */ main(int argc, char *argv[]) { unsigned long *ptr; /* where the value is */ unsigned long val; /* somewhere to put the value */ ptr = 0x1234; /* the memory address of the word, must be 4 - byte * aligned (bittom 2 bits of this numbe MUST be 0). * You should change 1234 to be the appropriate * address (I have used hex here). */ val = *ptr; /* read the value! */ printf("val at %08lx is %08lx\n", ptr, val); /* print it, so we know what happened */ } /* this one is much slower, but it can cope with addresses which aren't aligned. */ main(int argc, char *argv[]) { unsigned char *ptr; unsigned long val; ptr = 0x1234; val = *ptr++; /* read first byte */ val |= ((*ptr++) << 8); /* OR in the second byte */ val |= ((*ptr++) << 16); /* ditto */ val |= ((*ptr++) << 24); /* ditto */ printf("val at %08lx is %08lx\n", ptr, val); /* print it, so we know what happened */ } Notes: 1. if the address is a chip register then yuo will have to read & understand the manual; some registers are writable & not readable, some readable not writable and some change the value every time you read them. 2. If you want to read multiple words from arbitrary locations in memory, look into using the graphics library fns. CopyMem() and CopyMemQuick(). 3. Remember that locations in memory CHANGE. Do not assume that system structures, or in fact anything you do not control yourself, cannot move, either between machines or even during program execution. For example, message ports can be closed AT ANY TIME! I hope this helps. Peter. -- Peter Ivimey-Cook Mail Id: peteric@isltd.insignia.com Insignia Solutions, Kingsmead Business Park, London Road, High Wycombe, Buckinghamshire. Telephone: +44-1494-459426 HP11 1JU, U.K. Fax: +44-1494-459720 From amiga-gcc-port-owner@nic.funet.fi Wed Mar 1 16:11:45 1995 Received: by nic.funet.fi id <91209-1>; Wed, 1 Mar 1995 16:00:07 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <95Mar1.160007+0200_eet.91209-1+25@nic.funet.fi> Date: Wed, 1 Mar 1995 16:00:05 +0200 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Wed Mar 1 20:40:33 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91188-2>; Wed, 1 Mar 1995 20:36:38 +0200 Received: by theseas.ntua.gr with UUCP; Wed, 1 Mar 1995 20:38:19 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <069e@kriton.UUCP>; Wed, 1 Mar 95 19:33:50 EET Date: Wed, 1 Mar 95 19:33:50 EET Message-Id: <9503011733.069e@kriton.UUCP> In-Reply-To: <199502281711.SAA17457@honshu.informatik.uni-rostock.de> (from Gunther Nikl ) (at Tue, 28 Feb 1995 18:11:55 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 704 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: gnikl@informatik.uni-rostock.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Stack cecking, take 2 1/2 Hi Gunther (Gunther Nikl), in <199502281711.SAA17457@honshu.informatik.uni-rostock.de> on Feb 28 you wrote: > > sprintf(buf1, LINE1, (Argc > 0) ? FilePart(Argv[0]) > ^^^^^^^^^^^^^^^^^ > This a a 2.0+ function of dos.library. If you use this function you Thanks for pointing this out. In the next version I'll use an equivalent construct using strrchr(). -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "It is... um... somewhat... uncomplimentary, Captain; Herbert was a minor official, notorious for his rigid and limited patterns of thought." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Mar 1 20:46:44 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91191-4>; Wed, 1 Mar 1995 20:41:31 +0200 Received: by theseas.ntua.gr with UUCP; Wed, 1 Mar 1995 20:38:20 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <069j@kriton.UUCP>; Wed, 1 Mar 95 20:34:10 EET Date: Wed, 1 Mar 95 20:34:10 EET Message-Id: <9503011834.069j@kriton.UUCP> In-Reply-To: <9502280137.3sz7@adastra.cvl.va.us> (from "Michael B. Smith" ) (at Mon, 27 Feb 95 21:37:55 EDT) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 829 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: mbs@adastra.cvl.va.us Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Stack cecking, take 2 1/2 I changed my working version to do the following: 1. If this is a CLI process, get the stack bounds from the stack. 2. If this is not a CLI process, or step 1 produced invalid bounds, get the stack bounds from tc_SP*. 3. If the computed stack bounds are invalid, disable stack checking. In step 2 I have added checking tc_SP* for CLI processes that for some reason don't have their stack bounds in their stack. As I check again for valid bounds after this, it shouldn't hurt, and it might actually help in some cases. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "It is... um... somewhat... uncomplimentary, Captain; Herbert was a minor official, notorious for his rigid and limited patterns of thought." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Mar 1 22:09:48 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91215-4>; Wed, 1 Mar 1995 22:05:12 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id af05098; 1 Mar 95 20:00 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA0049y; Wed, 1 Mar 95 16:30:46 GMT Date: Wed, 1 Mar 95 16:30:46 GMT Message-Id: <9503011630.AA0049x@flevel.demon.co.uk> Message-Id: <20486234.35b61-dev@flevel.demon.co.uk> In-Reply-To: <9502242044.066s@kriton.UUCP> (from Kriton Kyrimis ) (at Fri, 24 Feb 95 22:44:38 EET) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ENV: and ixemul startup Hi Kriton, You asked about the problem I was having with libnix, they are:- 1) If you try and open a file using fopen which is a non standard handler then libnix fails. This is because it tries to do a ChangeMode() on the file handle when it is not needed, eg:- FILE* han=fopen("PIPE:MYPIPE","w"); Will always fail. 2) If you try to open "nil:" then libnix crashes:- FILE* han=fopen("nil:","w"); I'm pretty sure this is caused by the ChangeMode call. 3) I think there is a problem with the CLI argument passing, sometimes a blank argument is left in, for example:- main(int argc,char** argv) { char line[256]; if (argc>2) { printf("0=%s\n",argv[0]; printf("1=%s\n",argv[1]; printf("2=%s\n",argv[2]; } while (!feof(stdin)) gets(line); } Try running this program from cli:- >test 1 2 0=test 1=1 2=2 Then then try adding to uulib:aliases the line:- testbox:: "|test 1 2" And then sending an email to textbox, you sometimes get:- >sendmail ; Thu, 2 Mar 1995 10:13:17 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA12757; Thu, 2 Mar 95 10:09:27 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA12065; Thu, 2 Mar 95 10:13:48 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9503020813.AA12065@hpcl.cti.gr> Subject: Re: Stack cecking, take 2 1/2 To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Thu, 2 Mar 1995 10:13:46 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9503012011.AA29708@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Mar 1, 95 09:11:10 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1230 > I just feel that first checking tc_* then eventually checking > *pr_Returnaddr will give you the same results in the good cases and > less Enforcer hits in the bad cases. tc_* is known to everyone and does > certainly contain something, whereas some programmers of shells or > other launching programs might not have thought about pr_Returnaddr. > > So: Just swap 1 and 2 ("1" being checking pr_ReturnAddr, "2" being checking tc_SP*.) If you look at take 2 1/2, you'll notice that this is the way I did it originally. However, I was being pressed to do it the other way, so I finally gave in. This reminds me of one of the stories going around in this part of the world, about a character known under different names in various countries, called Hotza in Greece. He once wanted to build a brick oven. Every time he'd finish building it, one of his neighbours would suggest that it would be better if the oven's opening faced towards a different direction, so Hotza would demolish it and rebuild it according to the latest suggestion. He finally gave up and built the oven on a cart, so that he could rotate the oven to face wherever everybody liked. I have the feeling that this project is becoming like Hotza's oven. :-( From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 10:50:49 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91206-3>; Thu, 2 Mar 1995 10:45:42 +0200 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA14313 (5.65c-6/7.3w-FAU); Thu, 2 Mar 1995 09:45:31 +0100 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de (8.6.10/7.4a-FAU) with SMTP id JAA12343 for ; Thu, 2 Mar 1995 09:45:23 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA15149; Thu, 2 Mar 1995 09:45:21 +0100 Date: Thu, 2 Mar 1995 09:45:21 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9503020845.AA15149@pctc.chemie.uni-erlangen.de> To: amiga-gcc-port@lists.funet.fi Subject: sh problem ? Hello, I don't know whether this is the right list for reporting this problem. Recently I tried to configure git-4.3.5 for amigados. The configure script knows this machine, but 1.) while doing the test for long filenames it uses in a never ending story the memory it can get til to a rest of 100 - 200K. Then it always reads an writes to it forever. 2.) Starting make after some hand fixes you will get an error saying cpp is called with wrong arguments!! doing a "make -n" will show you that it should be a call to gcc. Is it possible that the generated command line is too long? Sorry about this question, I may have not seen a limit of command line length in sh. Used compiler gcc-2.6.3 Used AmigaDOS: 3.1 Used machine: Amiga 2000, with 68030 Real memory: 7MB VMM: I tried it with 6MB virtual memory and with 10MB. -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 11:48:21 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91185-3>; Thu, 2 Mar 1995 11:43:53 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA17505 (5.65c-6/7.3w-FAU); Thu, 2 Mar 1995 10:43:42 +0100 Received: from faui8s1 by immd8.informatik.uni-erlangen.de; id AA25690 (5.x/7.3w-FAU); Thu, 2 Mar 1995 10:43:41 +0100 From: Tobias Ruland Message-Id: <9503020943.AA25690@immd8.informatik.uni-erlangen.de> Date: Thu, 2 Mar 1995 10:43:39 +0100 To: amiga-gcc-port@lists.funet.fi Subject: signal handlers high all does anybody have an example code to install own signal handlers under gcc? i'm not interested in Amiga-Exec-Signalhandlers but those real UNIX signal handlers for signals defined in /usr/include/sys/signal.h is it possible to install gcc-unix-like-signal-handlers (e.g. for SIGALRM or SIGFPE) that work under amigaos/ixemul.library? thnx & cu tobias From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 12:21:33 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <91199-3>; Thu, 2 Mar 1995 12:11:21 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id LAA21470; Thu, 2 Mar 1995 11:09:15 +0100 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id KAA06938; Thu, 2 Mar 1995 10:09:59 +0100 Date: Thu, 2 Mar 1995 10:09:59 +0100 From: Niklas Hallqvist Message-Id: <199503020909.KAA06938@linda.appli.se> To: kyrimis@theseas.ntua.gr CC: hoehle@inf-wiss.uni-konstanz.de, amiga-gcc-port@lists.funet.fi.niclas In-reply-to: <9503020813.AA12065@hpcl.cti.gr> (kyrimis@hpcl.cti.gr) Subject: Re: Stack cecking, take 2 1/2 >>>>> "Kriton" == Kriton Kyrimis writes: Kriton> This reminds me of one of the stories going around in this Kriton> part of the world, about a character known under different Kriton> names in various countries, called Hotza in Greece. He once Kriton> wanted to build a brick oven. Every time he'd finish building Kriton> it, one of his neighbours would suggest that it would be Kriton> better if the oven's opening faced towards a different Kriton> direction, so Hotza would demolish it and rebuild it according Kriton> to the latest suggestion. He finally gave up and built the Kriton> oven on a cart, so that he could rotate the oven to face Kriton> wherever everybody liked. I had never heard this tale before. It is remarkable that such a modern issue like software configurability was recognized long before software engineering were even pronounced. Actually I cannot think of another story about this issue. The "three little piggies" is rather about getting the correct structure built the first time. Many stories is about good internal design rather than a nice UI (the beauty and the beast etc). I guess the traditional stories have many things to tell about SE. Not to mention ancient philosophy. Plato is clearly the author of ADTs, maybe even object-orientedness... Even ancient warlords recognized important design notions, Caesar invented "divide and conquer". Hmm... Maybe ancient history should be compulsory for computer science students :-) Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 13:07:24 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91273-2>; Thu, 2 Mar 1995 12:57:11 +0200 Received: from eagle.cms.dmu.ac.uk (se1dp@eagle.cms.dmu.ac.uk [146.227.102.27]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id KAA13388 for ; Thu, 2 Mar 1995 10:57:54 GMT Received: by eagle.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA148441765; Thu, 2 Mar 1995 10:56:05 GMT Date: Thu, 2 Mar 1995 10:56:05 +0000 (GMT) From: Derek Piper X-Sender: se1dp@eagle.cms.dmu.ac.uk To: GCC Mail List Subject: Illegal Instruction Gurus Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I written this small program as a test piece to write a program that does something marginally useful. The listing is included after my sig. The problem I am having is not so much the C program as the resultant executable. The C program compiles with no warnings or errors and generates an executable. This executable when run performs its task and upon exiting throws up a Software Failure requester with the guru meditation of #80000004 which, as AlertPatch informs me, is an Illegal Instruction error. I am compiling with the -noixemul option. It does not work with ixemul. If anyone could compile this program and perhaps spot any ommissions or errors I would be most grateful. I am using an Amiga1200 6MB RAM, 120MB HD and 40Mhz 68882. I have got GCC2.6.3, 020+881 version. I have not changed any machine configuration files. I would like to know how to do this too if anyone knows :-) Cheers. Del. PS: Thanks to Tobias Ruland and Peter Ivimey-Cook for the hints on long word reading, also to Trefor S who replied today. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ /* Vector Checker - For monitoring system vectors. */ #include int coldcapture = 0; int coolcapture = 0; int warmcapture = 0; int kickmemptr = 0; int kicktagptr = 0; int kickchecksum = 0; /* Vector Addresses */ int cldcpt = 0x20082E; int colcpt = 0x200832; int wrmcpt = 0x200836; int kmmptr = 0x200A26; int ktgptr = 0x200A2A; int kchksm = 0x200A2E; int errs = 0; main () { char title[30], passed[10], failed[10], check[10]; strcpy (title, "VectorChecker V1.0 - By D.Piper 1995"); strcpy (passed, "OK"); strcpy (failed, "WARNING"); /* Use CopyMemQuick to get vector values */ CopyMemQuick (cldcpt, coldcapture, 4); CopyMemQuick (colcpt, coolcapture, 4); CopyMemQuick (wrmcpt, warmcapture, 4); CopyMemQuick (kmmptr, kickmemptr, 4); CopyMemQuick (ktgptr, kicktagptr, 4); CopyMemQuick (kchksm, kickchecksum, 4); printf ("\n %s\n\n Vector Address Value Status\n\n", title); if (coldcapture == 0) strcpy (check, passed); else { ++errs; strcpy (check, failed); printf (" ColdCapture (%08lx) : %08lx --> %s\n", cldcpt, coldcapture, check); } if (coolcapture == 0) strcpy (check, passed); else { ++errs; strcpy (check, failed); } printf (" CoolCapture (%08lx) : %08lx --> %s\n", colcpt, coolcapture, check); if (warmcapture == 0) strcpy (check, passed); else { ++errs; strcpy (check, failed); } printf (" WarmCapture (%08lx) : %08lx --> %s\n", wrmcpt, warmcapture, check); if (kickmemptr == 0) strcpy (check, passed); else { ++errs; strcpy (check, failed); } printf (" KickMemPtr (%08lx) : %08lx --> %s\n", kmmptr, kickmemptr, check); if (kicktagptr == 0) strcpy (check, passed); else { ++errs; strcpy (check, failed); } printf (" KickTagPtr (%08lx) : %08lx --> %s\n", ktgptr, kicktagptr, check); if (kickchecksum == 0) strcpy (check, passed); else { ++errs; strcpy (check, failed); } printf (" KickCheckSum (%08lx) : %08lx --> %s\n", kchksm, kickchecksum, check); printf ("\n %d Vector(s) have been changed.\n", errs); } From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 13:19:35 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91352-1>; Thu, 2 Mar 1995 13:10:28 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA22588; Thu, 2 Mar 95 13:07:04 +0200 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA15316; Thu, 2 Mar 95 13:11:40 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9503021111.AA15316@hpcl.cti.gr> Subject: Re: Stack cecking, take 2 1/2 To: niklas@appli.se (Niklas Hallqvist) Date: Thu, 2 Mar 1995 13:11:36 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <199503020909.KAA06938@linda.appli.se> from "Niklas Hallqvist" at Mar 2, 95 10:09:59 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 825 > I had never heard this tale before. It is remarkable that such a > modern issue like software configurability was recognized long before > software engineering were even pronounced. Actually I cannot think of What I was getting at was not that we should make this kind of code configurable, as it would be as usefull as a wood-burning brick oven built on a (wooden) cart. I was simply pointing out the problem of having several alternatives suggested to me, all seemingly correct, and all contradicting each other. There are two solutions to this: I either pick the alternative I think is best, or the people who expressed the different alternatives fight it out among themselves, and I implement the suggestion of the survivor. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 17:03:43 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91445-4>; Thu, 2 Mar 1995 16:58:28 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 2 Mar 1995 15:57:15 +0100 Received: from manzell.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02863; Thu, 2 Mar 95 15:57:08 +0100 Date: Thu, 2 Mar 95 15:57:08 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503021457.AA02863@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@nic.funet.fi, se1dp@dmu.ac.uk Subject: Re: Illegal Instruction Gurus Hi Derek, Without looking deeper into the code, the following strikes me: /* Use CopyMemQuick to get vector values */ CopyMemQuick (cldcpt, coldcapture, 4); CopyMemQuick (colcpt, coolcapture, 4); CopyMemQuick (wrmcpt, warmcapture, 4); CopyMemQuick (kmmptr, kickmemptr, 4); CopyMemQuick (ktgptr, kicktagptr, 4); CopyMemQuick (kchksm, kickchecksum, 4); Bug: You must pass memory copying functions the address of the places to copy, which means &coldcapture, &coolcapture etc. Then there are alignment constraints with CopyMemQuick() that might not be respected in this case. Efficiency: Where did you get the idea of using CopyMemQuick to copy 4 bytes of memory where a simple pointer derefenrence would suffice? (code for this was posted to this newsgroup upon your request) (hint: coldcapture = *(ULONG*)cldcpt;). Joerg Hoehle hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 17:18:37 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91410-1>; Thu, 2 Mar 1995 17:10:06 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 2 Mar 1995 16:09:46 +0100 Received: from manzell.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02926; Thu, 2 Mar 95 16:09:35 +0100 Date: Thu, 2 Mar 95 16:09:35 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503021509.AA02926@inf-wiss.uni-konstanz.de> To: niklas@appli.se, kyrimis@theseas.ntua.gr Subject: Re: Stack cecking, take 2 1/2 Cc: amiga-gcc-port@lists.funet.fi Kriton writes: >There are two solutions to this: I either pick the alternative I think >is best, or the people who expressed the different alternatives fight >it out among themselves, and I implement the suggestion of the >survivor. Ok, as I'm one of the warriors, let me motivate my preference: The tc_SP* fields are known to everybody since day one (Exec has been better documented than dos). Even if they do not point to the current stack in some situations, they are not likely to contain garbage, they might just point to an old stack. So checking whether sp lies between them causes no harm. If SP is between them, I believe that we all agree that it would be extremely improbable that they would not indicate the correct stack location (and therefore size), so we just use these values. The *pr_ReturnAddr is not known to any programmer who's been launching other programs by writing a shell or anything else. Who knows that the stack size has to be pushed on the stack before running a CLI program? So this memory location may contain garbage, thus I tend to use it last, if ever. People might argue whether the value found there should be checked further (i.e. between say 170 and 10MB). Thus I first check tc_SP*, then *pr_ReturnAddr, else fail. Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 17:28:52 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91432-4>; Thu, 2 Mar 1995 17:22:53 +0200 Received: from cantor.cms.dmu.ac.uk (se1dp@cantor.cms.dmu.ac.uk [146.227.102.62]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id PAA22023; Thu, 2 Mar 1995 15:24:10 GMT Received: by cantor.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA127787742; Thu, 2 Mar 1995 15:22:22 GMT Date: Thu, 2 Mar 1995 15:22:22 +0000 (GMT) From: Derek Piper X-Sender: se1dp@cantor.cms.dmu.ac.uk To: Joerg-Cyril Hoehle Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Illegal Instruction Gurus In-Reply-To: <9503021457.AA02863@inf-wiss.uni-konstanz.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 2 Mar 1995, Joerg-Cyril Hoehle wrote: > Hi Derek, > > Without looking deeper into the code, the following strikes me: > > /* Use CopyMemQuick to get vector values */ > > CopyMemQuick (cldcpt, coldcapture, 4); > CopyMemQuick (colcpt, coolcapture, 4); > CopyMemQuick (wrmcpt, warmcapture, 4); > CopyMemQuick (kmmptr, kickmemptr, 4); > CopyMemQuick (ktgptr, kicktagptr, 4); > CopyMemQuick (kchksm, kickchecksum, 4); > > Bug: > You must pass memory copying functions the address of the places to > copy, which means &coldcapture, &coolcapture etc. Then there are > alignment constraints with CopyMemQuick() that might not be respected > in this case. I will try CopyMem(), as this is apparently alright with anything. I thought the addresses were aligned but this would explain the Illegal Instruction errors if it were incorrect. > Efficiency: > Where did you get the idea of using CopyMemQuick to copy 4 bytes of > memory where a simple pointer derefenrence would suffice? (code for > this was posted to this newsgroup upon your request) (hint: > coldcapture = *(ULONG*)cldcpt;). Tobias Ruland suggested it as a *possible* solution for copying lots of bytes to different places. I don't think I had mentioned what I was going to do with it. I had problems getting GCC to do the other things suggested. I may well implement your idea, if I can get it to work :-) I was unaware of the speed implications of the two methods. > Joerg Hoehle Thanks Joerg. Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 18:52:03 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91354-1>; Thu, 2 Mar 1995 18:40:21 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA15546; Thu, 2 Mar 1995 16:40:13 GMT From: Peter Ivimey-Cook Message-Id: <19871.199503021638@creda.isltd.insignia.com> Subject: Re: Illegal Instruction Gurus To: se1dp@dmu.ac.uk Date: Thu, 02 Mar 1995 16:38:28 GMT Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: ; from "Derek Piper" at Mar 2, 95 3:22 pm X-Mailer: elm X-Mailer: Elm [revision: 109.14] > Tobias Ruland suggested it as a *possible* solution for copying lots of bytes > to different places. I don't think I had mentioned what I was going to do > with it. I had problems getting GCC to do the other things suggested. I may > well implement your idea, if I can get it to work :-) I was unaware of the > speed implications of the two methods. > Derek, Please post the gcc code which failed either to the list or to me - I think the problem you have us much easier to solve using assignment - CopyMem is *real* overkill here. We are probably talking about 100's of instructions for CopyMem vs 1 for assignment! Regards, Peter -- Peter Ivimey-Cook Mail Id: peteric@isltd.insignia.com Insignia Solutions, Kingsmead Business Park, London Road, High Wycombe, Buckinghamshire. Telephone: +44-1494-459426 HP11 1JU, U.K. Fax: +44-1494-459720 From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 18:56:20 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91395-3>; Thu, 2 Mar 1995 18:42:43 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA15567; Thu, 2 Mar 1995 16:42:17 GMT From: Peter Ivimey-Cook Message-Id: <19892.199503021640@creda.isltd.insignia.com> Subject: Re: Stack cecking, take 2 1/2 To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Thu, 02 Mar 1995 16:40:32 GMT Cc: niklas@appli.se, kyrimis@theseas.ntua.gr, amiga-gcc-port@nic.funet.fi In-Reply-To: <9503021509.AA02926@inf-wiss.uni-konstanz.de>; from "Joerg-Cyril Hoehle" at Mar 2, 95 4:09 pm X-Mailer: elm X-Mailer: Elm [revision: 109.14] > > Thus I first check tc_SP*, then *pr_ReturnAddr, else fail. > > Joerg Hoehle. > This seems sensible to me. Peter -- Peter Ivimey-Cook Mail Id: peteric@isltd.insignia.com Insignia Solutions, Kingsmead Business Park, London Road, High Wycombe, Buckinghamshire. Telephone: +44-1494-459426 HP11 1JU, U.K. Fax: +44-1494-459720 From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 20:25:17 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91398-3>; Thu, 2 Mar 1995 20:20:03 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 2 Mar 1995 20:22:07 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06af@kriton.UUCP>; Thu, 2 Mar 95 19:56:42 EET Date: Thu, 2 Mar 95 19:56:42 EET Message-Id: <9503021756.06af@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 838 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Libnix argument parsing weirdness Compile the following echo-type program using -noixemul: #include main(int argc, char *argv[]) { int i; FILE *f = fopen("foo", "w"); for (i=0; iNULL: NULL: ; Thu, 2 Mar 1995 20:33:55 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ab05081; 2 Mar 95 18:26 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA004kv; Thu, 2 Mar 95 15:42:42 GMT Date: Thu, 2 Mar 95 15:42:42 GMT Message-Id: <9503021542.AA004ku@flevel.demon.co.uk> Message-Id: <2049a870.c8322-dev@flevel.demon.co.uk> In-Reply-To: <25529.199503011158@creda.isltd.insignia.com> (from Peter Ivimey-Cook ) (at Wed, 01 Mar 1995 11:58:46 GMT) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Re: Reading Long Words Hi Peter, > /* this one is fast, but can't cope with addresses which aren't aligned to 4 byte boundaries. */ I think the address only needs to be aligned to *2* byte boundarys with a 68000/680010. And does not need alignment at all if you have 68020+. > main(int argc, char *argv[]) > { > unsigned long *ptr; /* where the value is */ > unsigned long val; /* somewhere to put the value */ > > ptr = 0x1234; /* the memory address of the word, must be 4 - byte > * aligned (bittom 2 bits of this numbe MUST be 0). > * You should change 1234 to be the appropriate > * address (I have used hex here). > */ > > val = *ptr; /* read the value! */ > > printf("val at %08lx is %08lx\n", ptr, val); /* print it, so we know what happened */ > } > Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 20:44:25 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91411-1>; Thu, 2 Mar 1995 20:39:01 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ad05081; 2 Mar 95 18:26 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA004l5; Thu, 2 Mar 95 15:46:30 GMT Date: Thu, 2 Mar 95 15:46:30 GMT Message-Id: <9503021546.AA004l4@flevel.demon.co.uk> Message-Id: <2049a954.88b82-dev@flevel.demon.co.uk> In-Reply-To: <199502271451.PAA13293@honshu.informatik.uni-rostock.de> (from Gunther Nikl ) (at Mon, 27 Feb 1995 15:51:34 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: gnikl@informatik.uni-rostock.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: misc. garbage Hi Gunther, > > I don't understand why it is not good to store function pointers into > > registers, and in particular I don't understand what makes it bad when > > using small pc-relative addressing. What's wrong with > > > > lea _some_func(pc),a3 ; 16-bit pc-relative addressing > > jsr (a3) > > instead of > > Look at the asm-output. You won't find *any* reference that is pc-relative! > Actually the assembler converts absolute "lea function,a?" into pc-relative > addressing BUT only if assembling for >mc68020 and if "function" is located > in the same source before this place. > And what about "move.l #function,d4"? Anyway, if the user specifies > "-msmall-code" then he thinks the code fits into 32k. To avoid those ugly > "movel" or "lea" I would suggest to turn on "-fno-function-cse". > > > bsr.w _some_func ; 16-bit pc-relative addressing > > > > I can't see any significant difference. I haven't looked into what > > code gcc actually generates, but I think that the above is what it > > should generate when given the small-code option. > > No! gcc always generates code like "jbsr function". Its upto the > assembler to use "bsr" or "jsr". Look at the specs-file "-msmall-code" > is a switch for the assembler and not for the compiler. Sorry, you have lost me here. I think you were replying to someone else ;-) Cheers, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Mar 2 20:55:43 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91210-2>; Thu, 2 Mar 1995 20:50:50 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA16578; Thu, 2 Mar 1995 18:50:44 GMT From: Peter Ivimey-Cook Message-Id: <29113.199503021848@creda.isltd.insignia.com> Subject: Re: Reading Long Words To: dev@flevel.demon.co.uk Date: Thu, 02 Mar 1995 18:48:58 GMT Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <2049a870.c8322-dev@flevel.demon.co.uk>; from "dev@flevel.demon.co.uk" at Mar 2, 95 3:42 pm X-Mailer: elm X-Mailer: Elm [revision: 109.14] Trefor, > I think the address only needs to be aligned to *2* byte boundarys with a > 68000/680010. And does not need alignment at all if you have 68020+. Ok - I've been using RISC machines too much :) However, the '020 takes speed penalties (2 memory cycles wather than one) for doing such accesses - avoid if possible. -- Peter Ivimey-Cook Mail Id: peteric@isltd.insignia.com Insignia Solutions, Kingsmead Business Park, London Road, High Wycombe, Buckinghamshire. Telephone: +44-1494-459426 HP11 1JU, U.K. Fax: +44-1494-459720 From amiga-gcc-port-owner@nic.funet.fi Fri Mar 3 11:14:29 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91264-4>; Fri, 3 Mar 1995 11:06:14 +0200 Received: from tlaloc.cms.dmu.ac.uk (se1dp@tlaloc.cms.dmu.ac.uk [146.227.102.4]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id JAA18969 for ; Fri, 3 Mar 1995 09:07:35 GMT Received: by tlaloc.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA265511546; Fri, 3 Mar 1995 09:05:46 GMT Date: Fri, 3 Mar 1995 09:05:46 +0000 (GMT) From: Derek Piper X-Sender: se1dp@tlaloc.cms.dmu.ac.uk To: GCC Mail List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Mar 3 11:17:05 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91277-1>; Fri, 3 Mar 1995 11:07:49 +0200 Received: from tlaloc.cms.dmu.ac.uk (se1dp@tlaloc.cms.dmu.ac.uk [146.227.102.4]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id JAA18993 for ; Fri, 3 Mar 1995 09:09:18 GMT Received: by tlaloc.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA267241649; Fri, 3 Mar 1995 09:07:30 GMT Date: Fri, 3 Mar 1995 09:07:29 +0000 (GMT) From: Derek Piper X-Sender: se1dp@tlaloc.cms.dmu.ac.uk To: GCC Mail List Subject: VectorMonitor Finished Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I have re-written the VectorMonitor (changed the name too) and it works fine. Feel free to recompile it and play about with it. I have gotten rid of the CopyMem instructions, I realised they were overkill - I couldn't get the pointer dereference (my prefered idea from the start) to work. I had 5 different versions from 5 different people. Anyway I HAVE implemented it now and it DOES work. Let me know whether the style is good C programming or not. The program also uses ReadArgs() to get an option flag FLUSH, to clear the vectors if required. I have learnt important lessons from doing this. Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ /* Vector Monitor - For monitoring system vectors. */ /* A small program by D.Piper 1995 */ #include #include int *coldcapture = (int *) 0x20082E; int *coolcapture = (int *) 0x200832; int *warmcapture = (int *) 0x200836; int *kickmemptr = (int *) 0x200A26; int *kicktagptr = (int *) 0x200A2A; int *kickchecksum = (int *) 0x200A2E; int rdarg, errs, clear = 0; int **option[1]; main (int argc) { if (argc > 1) { rdarg = ReadArgs ("F=Flush/S", option, NULL); if (rdarg != NULL) { if (option[1] != 0) clearvectors (); } } else { printvectors (); checkvectors (); } FreeArgs (rdarg); } checkvectors () { char r; if (*coldcapture != 0) { ++errs; printf (" WARNING : ColdCapture Vector at $%08lx instead of $00000000\n", *coldcapture); } if (*coolcapture != 0) { ++errs; printf (" WARNING : CoolCapture Vector at $%08lx instead of $00000000\n", *coolcapture); } if (*warmcapture != 0) { ++errs; printf (" WARNING : WarmCapture Vector at $%08lx instead of $00000000\n", *warmcapture); } if (*kickmemptr != 0) { ++errs; printf (" WARNING : KickMemPtr Vector at $%08lx instead of $00000000\n", *kickmemptr); } if (*kicktagptr != 0) { ++errs; printf (" WARNING : KickTagPtr Vector at $%08lx instead of $00000000\n", *kicktagptr); } if (*kickchecksum != 0) { ++errs; printf (" WARNING : KickCheckSum Vector at $%08lx instead of $00000000\n", *kickchecksum); } if (errs == 0) printf (" Vectors OK.\n"); else { printf ("\n %d Vector(s) found to be non-standard.\n Use 'VectorMonitor flush' to flush vectors.\n", errs); } } printvectors () { printf ("\n VectorMonitor V1.0 - By D.Piper 1995\n\n"); printf (" Vector Address Value\n\n"); printf (" ColdCapture ($0020082E) : $%08lx\n", *coldcapture); printf (" CoolCapture ($00200832) : $%08lx\n", *coolcapture); printf (" WarmCapture ($00200836) : $%08lx\n", *warmcapture); printf (" KickMemPtr ($00200A26) : $%08lx\n", *kickmemptr); printf (" KickTagPtr ($00200A2A) : $%08lx\n", *kicktagptr); printf (" KickCheckSum ($00200A2E) : $%08lx\n\n", *kickchecksum); } clearvectors () { CopyMem (&clear, 0x20082E, 4); CopyMem (&clear, 0x200832, 4); CopyMem (&clear, 0x200826, 4); CopyMem (&clear, 0x200A26, 4); CopyMem (&clear, 0x200A2A, 4); CopyMem (&clear, 0x200A2E, 4); printf (" Vectors cleared.\n"); } From amiga-gcc-port-owner@nic.funet.fi Fri Mar 3 11:17:05 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91350-2>; Fri, 3 Mar 1995 11:08:50 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA26376 (5.65c-6/7.3w-FAU); Fri, 3 Mar 1995 10:08:41 +0100 Received: from faui8s1 by immd8.informatik.uni-erlangen.de; id AA03549 (5.x/7.3w-FAU); Fri, 3 Mar 1995 10:08:41 +0100 From: Tobias Ruland Message-Id: <9503030908.AA03549@immd8.informatik.uni-erlangen.de> Date: Fri, 3 Mar 1995 10:08:37 +0100 To: amiga-gcc-port@lists.funet.fi Subject: unix signal handling high walter thnx for your answer. Walter Harms writes: > > does anybody have an example code to install own signal handlers > > under gcc? i'm not interested in Amiga-Exec-Signalhandlers but those > > real UNIX signal handlers for signals defined in /usr/include/sys/signal.h > > is it possible to install gcc-unix-like-signal-handlers (e.g. for SIGALRM or > > SIGFPE) that work under amigaos/ixemul.library? > > > i have a example concerning ctrl-C because thats seems to > be the only think whats implemented (or working) ctrl-c? i've written a small program (for solaris) that installs a SIGALRM handler and uses getitimer/setitimer to force the OS to call my handler. i've not tried to compile it under amiga-os/ixemul.lib yet but it seems that there's no chance to get that UNIX-code working after what you've said. c u tobias From amiga-gcc-port-owner@nic.funet.fi Fri Mar 3 12:27:45 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91363-1>; Fri, 3 Mar 1995 12:17:15 +0200 Received: by ceylon.informatik.uni-rostock.de id LAA25988; Fri, 3 Mar 1995 11:16:54 +0100 Received: by honshu.informatik.uni-rostock.de id LAA03745; Fri, 3 Mar 1995 11:16:54 +0100 From: Gunther Nikl Message-Id: <199503031016.LAA03745@honshu.informatik.uni-rostock.de> Subject: Re: VectorMonitor Finished To: se1dp@dmu.ac.uk (Derek Piper) Date: Fri, 3 Mar 1995 11:16:53 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Derek Piper" at Mar 3, 95 09:07:29 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 986 Hi! > /* Vector Monitor - For monitoring system vectors. */ > /* A small program by D.Piper 1995 */ > > int *coldcapture = (int *) 0x20082E; > int *coolcapture = (int *) 0x200832; > int *warmcapture = (int *) 0x200836; > int *kickmemptr = (int *) 0x200A26; > int *kicktagptr = (int *) 0x200A2A; > int *kickchecksum = (int *) 0x200A2E; ^^^^^^^^ What the hell is THIS ??? Are you accessing memory directly? Where do you think your program will work? I definetly know it will produce *lots* of enforcer hits on my amiga (I do not have any memory at those addresses)! All your mentioned vectors above are located in ***SysBase***. So please use SysBase->CoolCapture,etc. if you want to copy the value simply use "ULONG coolcapture = *SysBase->CoolCapture". BTW, that your first version crashed could be due to the fact that a buffer size was too small (your strcpy() copied over the field bound into your local stackframe) Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Mar 3 12:33:39 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91391-4>; Fri, 3 Mar 1995 12:20:58 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 3 Mar 1995 11:20:34 +0100 Received: from manzell.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA05630; Fri, 3 Mar 95 11:20:18 +0100 Date: Fri, 3 Mar 95 11:20:18 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503031020.AA05630@inf-wiss.uni-konstanz.de> To: se1dp@dmu.ac.uk Subject: Re: VectorMonitor Finished Cc: amiga-gcc-port@nic.funet.fi Derek writes: >int *kickchecksum = (int *) 0x200A2E; You should avoid the type int for things that do not belong to you because the size of an int may vary from compiler to compiler or even depend on a compiler option. Use some of the exec/types.h instead, like ULONG* instead. Flame: BTW, who told you that these vectors are found near 0x200A2E? That'll not work on any A3000 or A4000. These fields are part of the ExecBase structure and as such, you have to get a pointer to exec.library first (it may be found in the SysBase variable in most libc.a libraries). Thus use SysBase->eb_coldcapture or whatever that structure accessors are called. Look at the includes in exec/execbase.h to see how coldcapture and the others are defined. Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Fri Mar 3 14:02:10 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91356-1>; Fri, 3 Mar 1995 13:41:28 +0200 Received: from birch.cms.dmu.ac.uk (se1dp@birch.cms.dmu.ac.uk [146.227.102.8]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id LAA24448 for ; Fri, 3 Mar 1995 11:42:58 GMT Received: by birch.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA196560866; Fri, 3 Mar 1995 11:41:06 GMT Date: Fri, 3 Mar 1995 11:41:06 +0000 (GMT) From: Derek Piper X-Sender: se1dp@birch.cms.dmu.ac.uk To: GCC Mail List Subject: VectorMonitor - Oops ! Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The crashes in the previous version was due to mis-aligned destination addresses when I was farting around with CopyMemQuick() :-) I didn't realise the vector addresses would be different on different machines, (didn't stop to think about it really :-|), I will rectify this obvious bug immediately, thankyou all for the feedback - I need it !! :-) Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Mar 3 14:08:06 1995 Received: by nic.funet.fi id <91377-2>; Fri, 3 Mar 1995 13:48:30 +0200 From: Leonard Norrgard To: hoehle@inf-wiss.uni-konstanz.de CC: se1dp@dmu.ac.uk, amiga-gcc-port@nic.funet.fi In-reply-to: <9503031020.AA05630@inf-wiss.uni-konstanz.de> (hoehle@inf-wiss.uni-konstanz.de) Subject: Re: VectorMonitor Finished Message-Id: <95Mar3.134830+0200_eet.91377-2+27@nic.funet.fi> Date: Fri, 3 Mar 1995 13:48:29 +0200 Someone wrote: > Flame: > BTW, who told you that these vectors are found near 0x200A2E? That'll Please refrain from flaming people who are trying to learn something. From amiga-gcc-port-owner@nic.funet.fi Fri Mar 3 18:30:55 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91364-3>; Fri, 3 Mar 1995 18:23:29 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id aa00358; 3 Mar 95 16:17 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA004sm; Fri, 3 Mar 95 09:42:54 GMT Date: Fri, 3 Mar 95 09:42:54 GMT Message-Id: <9503030942.AA004sl@flevel.demon.co.uk> Message-Id: <204aa59b.cd141-dev@flevel.demon.co.uk> In-Reply-To: <29113.199503021848@creda.isltd.insignia.com> (from Peter Ivimey-Cook ) (at Thu, 02 Mar 1995 18:48:58 GMT) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: peteric@insignia.co.uk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Reading Long Words Hi Peter, > > I think the address only needs to be aligned to *2* byte boundarys with a > > 68000/680010. And does not need alignment at all if you have 68020+. > > Ok - I've been using RISC machines too much :) > > However, the '020 takes speed penalties (2 memory cycles wather than one) > for doing such accesses - avoid if possible. Yes, your right, it is a low slower if you are not on an even address. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Mar 3 20:38:09 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91367-3>; Fri, 3 Mar 1995 20:31:47 +0200 Received: by ceylon.informatik.uni-rostock.de id TAA27677; Fri, 3 Mar 1995 19:31:41 +0100 Received: by honshu.informatik.uni-rostock.de id TAA06142; Fri, 3 Mar 1995 19:31:40 +0100 Date: Fri, 3 Mar 1995 19:31:40 +0100 From: Gunther Nikl Message-Id: <199503031831.TAA06142@honshu.informatik.uni-rostock.de> To: amiga-gcc-port@nic.funet.fi Subject: Libnix argument parsing weirdness X-Sun-Charset: US-ASCII >From daemon Thu Mar 2 19:25:16 1995 Return-Path: amiga-gcc-port-owner@nic.funet.fi Received: by ceylon.informatik.uni-rostock.de id TAA23868; Thu, 2 Mar 1995 19:25:11 +0100 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91398-3>; Thu, 2 Mar 1995 20:20:03 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 2 Mar 1995 20:22:07 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06af@kriton.UUCP>; Thu, 2 Mar 95 19:56:42 EET Date: Thu, 2 Mar 95 19:56:42 EET Message-Id: <9503021756.06af@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 838 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@nic.funet.fi Subject: Libnix argument parsing weirdness Status: RO Hi! > Compile the following echo-type program using -noixemul: > > #include > > main(int argc, char *argv[]) > { > int i; > FILE *f = fopen("foo", "w"); > > for (i=0; i fprintf(f, "%d \"%s\"\n", i, argv[i]); > } > fclose(f); > return 0; > } > > Then run it using "runback a.out 1 2". The contents of the output file > will be: > > 0 "a.out" > 1 "" > 2 "1" > 3 "2" > > Where did that spurious argument come from? This is a bug in the libnix command line parser :( It doesn't handle trailing whitespaces. It didn't show because the _shell_ removes trailing whitespaces (at least the shell of OS3.0 does). I checked several runbacks (from Fish 65,72, 152,214,240). Only two showed the reported error. The reason for this was that some RunBack versions had two whitespaces before the arguments. Oops... (RunBack ist not needed to get the above result: -> "a.out <>nil: 1 2" ^^ two spaces) Should be fixed in the next version. Solution so far: 1) Do not use Runback :) 2) if you use ">" or "<" between command and arguments make sure that only ONE space is between the "<>" and the arguments Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Mar 3 21:40:10 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91369-1>; Fri, 3 Mar 1995 21:34:49 +0200 Received: from guava.cms.dmu.ac.uk (se1dp@guava.cms.dmu.ac.uk [146.227.102.13]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id TAA06755 for ; Fri, 3 Mar 1995 19:35:58 GMT Received: by guava.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA200869246; Fri, 3 Mar 1995 19:34:06 GMT Date: Fri, 3 Mar 1995 19:34:06 +0000 (GMT) From: Derek Piper X-Sender: se1dp@guava.cms.dmu.ac.uk To: GCC Mail List Subject: Flames Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I do not mind comments or CONSTRUCTIVE critiscm but I do not enjoy being flamed about things that couldn't really be expected to know about. My program VectorMonitor is a LEARNING activity, my first one at that, and as such is bound to have large errors. I did not know the correct ways of implementing ideas. It is nice to be informed about the recognised ways of doing things and encouraged to follow suit, but it is very disheartening to have stupid comments like "What the hell is this ?" and flames from experienced programmers. I thought this GCC list is for people who want to get to know and use C better and not for experienced programmers to have a go at new C programmers. Luckily it is just one or two people that have this selfish attitude with other people like Peter Ivimey-Cook (:-)) being genuinely helpful and courteous. I know it can be annoying to have relatively 'simple' problems come up but you don't HAVE to reply if you don't want to. Thankyou. Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Sat Mar 4 09:15:05 1995 Received: from clinet.fi ([193.64.6.1]) by nic.funet.fi with SMTP id <91390-2>; Sat, 4 Mar 1995 09:12:12 +0200 Received: from zetor.clinet.fi (root@zetor.clinet.fi [193.64.6.8]) by clinet.fi (8.6.10/8.6.4) with ESMTP id JAA23387; Sat, 4 Mar 1995 09:12:06 +0200 Received: (will@localhost) by zetor.clinet.fi (8.6.10/8.6.4) id JAA01935; Sat, 4 Mar 1995 09:12:06 +0200 Date: Sat, 4 Mar 1995 09:12:04 +0200 (EET) From: Ville-Pertti Keinonen To: gnikl@informatik.uni-rostock.de cc: amiga-gcc-port@nic.funet.fi Subject: Re: misc. garbage In-Reply-To: <199502241251.NAA05519@honshu.informatik.uni-rostock.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The reason is simple: if you compile with "-msmall-code" your code > has to fit (almost) into 32k. Every function should be accessable > with "bsr.W". If "-fno-function-cse" is not given gcc may stuff > function addresses into registers. Thats not always a good idea > (especially if gcc uses a data register). But proper support for small-code models doesn't really exist, in any case, since absolute subroutine calls are created anyhow, if the call isn't in the same source file (if they are in the same source, relative calls are always produced whenever possible). Having such strict restrictions for the generation of actual small code doesn't really make sense, so at least for me, the only use of the option is for reducing the number of relocations required when compiling for '020 and higher CPUs. Actually, the use of long relative branches instead of absolute ones could make sense as a default option, since usually this is preferable. (Since small code doesn't make sense unless there is really support - using actual "Amiga"-compilers, such as DICE and probably SAS/C, too, almost any program can be compiled using small code and small data models (sometimes some modifications are required for the latter, or even both, eg. in the case of compiling Amiga CircleMUD using small code/data models (it *is* possible, even though the executable is huge))) From amiga-gcc-port-owner@nic.funet.fi Sat Mar 4 10:02:27 1995 Received: from clinet.fi ([193.64.6.1]) by nic.funet.fi with SMTP id <91393-1>; Sat, 4 Mar 1995 09:58:33 +0200 Received: from zetor.clinet.fi (root@zetor.clinet.fi [193.64.6.8]) by clinet.fi (8.6.10/8.6.4) with ESMTP id JAA24353; Sat, 4 Mar 1995 09:58:18 +0200 Received: (will@localhost) by zetor.clinet.fi (8.6.10/8.6.4) id JAA02353; Sat, 4 Mar 1995 09:58:19 +0200 Date: Sat, 4 Mar 1995 09:58:17 +0200 (EET) From: Ville-Pertti Keinonen To: Paul Ney cc: amiga-gcc-port@nic.funet.fi Subject: Re: ENV: and ixemul startup (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 24 Feb 1995, Paul Ney wrote: > > On Fri, 24 Feb 1995, Philippe BRAND wrote: > > > Will Bow writes: > > > > > > > gcc -o myprog myprog.o -noenv > > > > What do others think? > > > I like the idea! > > > > Why not, why not... > > I love this idea! Since it seems that everyone else likes the idea, I'll have to be the one to disagree (ie. I *don't* like the idea). Wouldn't it make much more sense to just have the environment information quickly available? That would speed up the startup of *all* programs without even requiring recompilation. This could very easily be done by just storing the global environment in ixemul.librarys base (or even the data-section). Of course the global environment can change, but that can easily be solved by having ixemul.library keep a process that checks for changes in the env:-directory and re-creates the data for the global environment when necessary. This is not difficult to do and I'm certainly going to do it myself if the author(s) of ixemul.library don't. (My ixemul.library is rather different from the 'official' one, anyhow) From amiga-gcc-port-owner@nic.funet.fi Sat Mar 4 14:54:25 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91164-2>; Sat, 4 Mar 1995 14:51:39 +0200 Received: by theseas.ntua.gr with UUCP; Sat, 4 Mar 1995 14:53:33 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06b6@kriton.UUCP>; Fri, 3 Mar 95 18:23:14 EET Date: Fri, 3 Mar 95 18:23:14 EET Message-Id: <9503031623.06b6@kriton.UUCP> In-Reply-To: <9503031021.AA05635@inf-wiss.uni-konstanz.de> (from hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle)) (at Fri, 3 Mar 95 11:21:09 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 896 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: hoehle@inf-wiss.uni-konstanz.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Libnix argument parsing weirdness Hi Joerg-Cyril (Joerg-Cyril Hoehle), in <9503031021.AA05635@inf-wiss.uni-konstanz.de> on Mar 3 you wrote: > Maybe you should examine the RunBack source closer. It may be the culprit. I did, and I found an easier way to reproduce the problem. Simply run the echo-type program from the Commodore shell using: a.out main(int argc, char *argv[]) { int i; for (i=0; i; Sun, 5 Mar 1995 00:28:08 +0200 Received: by theseas.ntua.gr with UUCP; Sun, 5 Mar 1995 00:30:09 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06bg@kriton.UUCP>; Sat, 4 Mar 95 14:56:22 EET Date: Sat, 4 Mar 95 14:56:22 EET Message-Id: <9503041256.06bg@kriton.UUCP> In-Reply-To: <199503031831.TAA06142@honshu.informatik.uni-rostock.de> (from Gunther Nikl ) (at Fri, 3 Mar 1995 19:31:40 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 657 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: gnikl@informatik.uni-rostock.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Libnix argument parsing weirdness Hi Gunther (Gunther Nikl), in <199503031831.TAA06142@honshu.informatik.uni-rostock.de> on Mar 3 you wrote: > Should be fixed in the next version. Solution so far: > > 1) Do not use Runback :) > 2) if you use ">" or "<" between command and arguments make sure that only > ONE space is between the "<>" and the arguments 3) Recompile runback, removing that second space--I tried it and it works! -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Starship captains are a special breed of beings who boldly go, et cetera." ----- From amiga-gcc-port-owner@nic.funet.fi Sun Mar 5 14:09:41 1995 Received: from cs.ru.ac.za ([146.231.128.67]) by nic.funet.fi with SMTP id <91165-4>; Sun, 5 Mar 1995 14:05:44 +0200 Received: by cs.ru.ac.za (Smail3.1.28.1 #1) id m0rlF3c-001IdJC; Sun, 5 Mar 95 14:05 EET Message-Id: From: g91b8620@cs.ru.ac.za (Simon Barratt) Subject: /gny/s/ missing in gcc263-base.lha ? To: amiga-gcc-port@lists.funet.fi Date: Sun, 5 Mar 1995 14:05:08 +0200 (EET) X-Mailer: ELM [version 2.4 PL20] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 220 Hi there I've just recently join the list server, so this problem has probably been already dealt with, could somebody plese let me know where I can get the /gnu/s/ directory for gcc 6.2.3 from please. Thanks Simon From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 10:56:34 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91159-3>; Mon, 6 Mar 1995 10:49:05 +0200 Received: by colombo.telesys-innov.fr; Mon, 6 Mar 1995 09:49:11 GMT From: Philippe BRAND Message-Id: <199503060949.JAA12341@colombo.telesys-innov.fr> Subject: Re: /gny/s/ missing in gcc263-base.lha ? To: g91b8620@cs.ru.ac.za (Simon Barratt) Date: Mon, 6 Mar 1995 09:49:10 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Simon Barratt" at Mar 5, 95 02:05:08 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 399 Simon Barratt writes: > I've just recently join the list server, so this problem has > probably been already dealt with, could somebody plese let me > know where I can get the /gnu/s/ directory for gcc 6.2.3 from > please. Next time I'll call gcc263-readme.lha gcc263-get-me-first-please-and-read-me.lha ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 11:04:17 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91165-1>; Mon, 6 Mar 1995 10:56:38 +0200 Received: by colombo.telesys-innov.fr; Mon, 6 Mar 1995 09:56:48 GMT From: Philippe BRAND Message-Id: <199503060956.JAA12371@colombo.telesys-innov.fr> Subject: Re: ENV: and ixemul startup (fwd) To: will@clinet.fi (Ville-Pertti Keinonen) Date: Mon, 6 Mar 1995 09:56:48 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Ville-Pertti Keinonen" at Mar 4, 95 09:58:17 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 530 Ville-Pertti Keinonen writes: > This is not difficult to do and I'm certainly going to do it > myself if the author(s) of ixemul.library don't. (My ixemul.library is > rather different from the 'official' one, anyhow) Ahem... I quite don't like the idea of having multiple ixemul sources and libraries... Couldn't you just share your code with "official" ixemul mainteners ? Having people working alone won't make the thing going faster. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 11:37:32 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91191-3>; Mon, 6 Mar 1995 11:30:00 +0200 Received: from kola.cms.dmu.ac.uk (se1dp@kola.cms.dmu.ac.uk [146.227.102.17]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id JAA06351 for ; Mon, 6 Mar 1995 09:31:31 GMT Received: by kola.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA247922181; Mon, 6 Mar 1995 09:29:41 GMT Date: Mon, 6 Mar 1995 09:29:40 +0000 (GMT) From: Derek Piper X-Sender: se1dp@kola.cms.dmu.ac.uk To: GCC Mail List Subject: Few questions Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I have a few questions to ask, firstly, why do the original CBM includes namely the exec, dos and graphics library protos generate *so* many warnings with GCC ? Granted this does not stop compilation nor even seem to degrade the program, it seems like a certain incompatibility with GCC. I have compiled with the -noixemul option. Secondly, does anybody know of any nice fast clock procedures ? I have been playing around with a number of ideas at the weekend, but I wondered whether anybody had a nice fast idea, I am going to have clock as part of a program so it has to run fast so as not to impede execution of the program. And finally, I will ask as to the best way to read characters from a custom screen, custom window so as not to output anything to the screen, so I can't use a string gadget, I have looked at a rawkey reader that hits the hardware directly (ie. CIA A) to return the rawkey code. This seems to be too low level for what I need. Any help is greatly appreciated. Cheers. Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 13:21:24 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91159-2>; Mon, 6 Mar 1995 13:13:49 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA15577; Mon, 6 Mar 1995 11:13:43 GMT From: Peter Ivimey-Cook Message-Id: <15332.199503061111@creda.isltd.insignia.com> Subject: Re: Few questions To: se1dp@dmu.ac.uk (Derek Piper) Date: Mon, 06 Mar 1995 11:11:41 GMT Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: ; from "Derek Piper" at Mar 6, 95 9:29 am X-Mailer: elm X-Mailer: Elm [revision: 109.14] Derek, > I have a few questions to ask, firstly, why do the original > CBM includes namely the exec, dos and graphics library protos generate *so* > many warnings with GCC ? Granted this does not stop compilation nor even seem > to degrade the program, it seems like a certain incompatibility with GCC. I > have compiled with the -noixemul option. I found this too - Most of the errors are because gcc doesn't automatically invent null structure definitions when it sees a declaration referencing an undefined structure. Most are easy to avoid by defining a null structure ref: struct xxx; but the typedefs can't be done this way. The real solution is to include the structure defs. before the protos. But this ends up in *big* files! > Secondly, does anybody know of any nice fast clock procedures ? > I have been playing around with a number of ideas at the weekend, but I wondered > whether anybody had a nice fast idea, I am going to have clock as part of a > program so it has to run fast so as not to impede execution of the program. What do you mean. The simplest way of getting the time of day is to look at the DOS clock function CurrentTime(), or it's C-lib equivalent time(); Won't this do. If you want to update a clock on-screen you could always use the IntuiTick event, if you're running under Intuition, or do something similar using setitimer() and SIGVTALRM if using gcc. Remember that either type of tick is delivered *some time after* it occurred. not necessarily "on the dot". > And finally, I will ask as to the best way to read characters > from a custom screen, custom window so as not to output anything to the screen, > so I can't use a string gadget, I have looked at a rawkey reader that hits the > hardware directly (ie. CIA A) to return the rawkey code. This seems to be too > low level for what I need. Use an Intuition event handler on the window and use either of the two Key type events. You've really got to read the manual ("Amiga Rom Kernel Manual: Libraries", Addison Wesley, 3rd (4th?) Ed.) for this. You could try unsetting the ECHO param in a termios structure referring to a con: window opened on the screen (look at the TCGETA & TCSETA ioctl() functions. But I don't know is this has been implemented in ixemul. Hope this helps. -- Peter Ivimey-Cook Mail Id: peteric@isltd.insignia.com Insignia Solutions, Kingsmead Business Park, London Road, High Wycombe, Buckinghamshire. Telephone: +44-1494-459426 HP11 1JU, U.K. Fax: +44-1494-459720 From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 13:28:30 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91165-2>; Mon, 6 Mar 1995 13:21:16 +0200 Received: from nutmeg.cms.dmu.ac.uk (se1dp@nutmeg.cms.dmu.ac.uk [146.227.102.20]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id LAA09050 for ; Mon, 6 Mar 1995 11:22:15 GMT Received: by nutmeg.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA232098824; Mon, 6 Mar 1995 11:20:24 GMT Date: Mon, 6 Mar 1995 11:20:23 +0000 (GMT) From: Derek Piper X-Sender: se1dp@nutmeg.cms.dmu.ac.uk To: GCC Mail List Subject: Books Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I know I should read the books, I want to get some but I don't know what to get exactly. I was thinking of a basic C manual as well as a Rom Kernal Manual. Does anybody think I should get any other type of book ? Can anybody recommend a book that they find useful ? Cheers. Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 13:33:52 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91208-1>; Mon, 6 Mar 1995 13:25:32 +0200 Received: by colombo.telesys-innov.fr; Mon, 6 Mar 1995 12:25:55 GMT From: Philippe BRAND Message-Id: <199503061225.MAA13402@colombo.telesys-innov.fr> Subject: Re: /gny/s/ missing in gcc263-base.lha ? To: peteric@insignia.co.uk (Peter Ivimey-Cook) Date: Mon, 6 Mar 1995 12:25:55 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <15475.199503061118@creda.isltd.insignia.com> from "Peter Ivimey-Cook" at Mar 6, 95 11:17:59 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 260 Peter Ivimey-Cook writes: [text about installer script deleted] Could the one who made the installer script (sorry, don't have his name here) have a look at it ? Thanks! -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: _PhB_ From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 13:40:37 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91210-4>; Mon, 6 Mar 1995 13:33:43 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA28097 (5.65c8/IDA-1.4.4 for ); Mon, 6 Mar 1995 12:33:25 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA14996; Mon, 6 Mar 95 12:33:24 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503061133.AA14996@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Libnix argument parsing weirdness To: kyrimis@theseas.ntua.gr Date: Mon, 6 Mar 1995 12:33:24 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503021756.06af@kriton.UUCP> from "Kriton Kyrimis" at Mar 2, 95 07:56:42 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 12407 > > Compile the following echo-type program using -noixemul: > > Where did that spurious argument come from? > Obviously a bug in the commandline parser module nobody reported until now :-). You can use the following bug-fix (beware of even more bugs ;-) ). Matthias begin 644 libnix-fix.lha M&9(M;&AD+1X @&-F'B ! 504 4.U!!P!171C4& L G-O=7)C M97/_!P!4P/%:+P (+0M;&@U+<0* J%P ]H-E'B !!VAI$\ M#)*1):R3;;"43 ..-S0"-MAN2X044(*75DGC>[BDU?3C]]_Q**3=PUNV MOA[@.[6R-)WW>WW6ZJ&^')W>WNL9,VALRXM=6J;6NO4R?D[/;V,?0Y]2ZYF* MU+;7R=/MZ65.?NE]>CV]3-JNABXVO9RH:%3KFPET\*C .MVT9%T*_PNF@0G;%JZ6_F,B MI=,L1">]>Z"GLH8]AD=I_-CW8\@T"N>=-/=*JETCK3A2GB+T\%,V,K5HZ>[Y M\_8JVPP,HMII5T]/T58O4Q-J0B\3XQY,H^%>_XS6;K^%?\1OJ7PE\1HS:]L8 MC(6UC;]22K/3U67]T?BK:Y_>H!7@W569\ZUO\8J]H"EL'(T:)M?>O2YXT$<2 MHU,C,/D0?466I\\T@D&,E;)F0@L1!&UK'4TB+'-\^WY9N9 )<_W<_;]4RQ8# M@]5VJTU)S^$7KK8ZV"A)5LSJ1I['B^W%+-WL=8RL9;.RED;HNKX)TMCW:GKJ,(EU";Z@%"[PQ[N<-V2@[!) MI_!CQI^<1"U,>,-]BN4;!^/\>L$[KF*D,LY?;6H;E>8+*MK;X9@;'OX1>SIK MK>C4(>G/Z_[*3 MM+TAL0R2+9I%:\['O<-<0C]_X8CW6*7&ANAH'*OY!W5I ODV <=& Z6TMCNS MW:,Q#9*CVM8[8X2Y7LS=B9QV@_3A%.=TR"%DQQ_ *O")A P,RL&-(0R+/!M= M#E(R5%._XE,DPD65!!VV8LEG6LN4.$T*A''3WQ&A+3BU8N/-Q!/SO85S5#1S M]PR4-#^I&AI_QM@6+D_=)VX%;2*2"IG;/7BC)8-'. >CXW8L MC8#[E?:G0O,))[GZ.OMYS]0.R\\23QWD83N-E$ ^B4[IW( M:4-A@4SP20KHG;950Z[ [ C<6C1;.W9!OKRGY5.GN^6'$OX8X.55(_J2.[O' M.Y2G,)AJ%=3=2\ZY &]=S3$73C2FHH8K$"'UE+#C$ ='07]3KJ4-THIA_7F* M%.[AUO'8"P>/U9545%_$8)3A[ MF\D?PI^B(=CH-\$-[2U=!.B6R>,$>C,H_&@H5GX:9/.R&ZI(4?R M.M.@Z*#32:ZNZV_9L+G'USWO+H*\OR:Q0#AGTYV8K">LX@L(-*+ '%^^XCAH M-D;-"H<"> !\E#N3_VR@+#.,%2P_?1-X"6N%"5Z+TIMF9GY6AF8:\C(@G M*JILH$W:HO9^NH C1@S++ :[WM 94'FXB/7"8B.E5[8IL0S()DA] 0JQ(E2[3="OW MMN00X];P56D^85<\WZ*YA->[NM;J60SA*.])@I(!3,*YU>3" ,RT:"*J8B)) MLL5T4=;IU>S%CD?O^>#KG6:=3S>?S9>GK]_/HZN?_/1\?ESY$I3%4 '>E MAHKAC9O[V/T9VUCT^->_AVV6#0MX/L=#7HJL+5P5Z VG2 M*7%F3 LZ[RTW18S)%A#W3#JZQ7:BO+%3(R05DV2+8(-SE^:3!Y#-=2Q(:ORJ MK>^FV?4S?D=XAY1Y&%SVTLX40;K+IY0&RQ7&)!+Z5^?P'9;@2\4%&LU$,.*< M7[Z]O,7P"W]3+ $ UB%-V_>"O/[*P1_U2D;[2%*'E M>5"G#O52O<:EC"CHP MA8"?SMH2U+CO@C*EB7@V0C]U-MU??J8*0=8HJ/W+#L7@@N]AK1@HJ:*3&@2U)BY!)(V88PT_B M$W.(P>A<(]IW6?WM-8Y+Z_^W1\D6:]P,BEGY.'I4BKM:EHYA+?IN8$G'A)Q> MRV.-8TB2-U(VC!=U(RO@4SUY_2:T*+*N#]\NJ+5,,Z\.K0L> -\=7>&L#?6A&5&B@@8:Z@9-M:*'S_; MBALK1%_4W8@0PZ5S>CT7H!B:R=L:LKT>CQW#Q0ENMV$C%FWE6&H$$?COX)TO M.S88R$71*[D1:S^F&+&L["Q\-J[,TIP<3QRHE;ZSP/DEW@&#QFD4.D7A;\;' M- CY_?U]WG&Z?RM%W0&YOV5\%V/ME?0YD',;=N5L0E\WI)W68.595$I0//+Q M3O#P6U]1L!8/5,&(LTR>#W7OI CL:[@[TCM;%[&C7V'B5CL=%Y4N6#4/X2H1KS4P)JCXUD1E%&J6\RNJ:. 4N[ MA3K;LF%'_P!0E#X0ORN7-$ODA !+1@0L-[:B6&,9Y(BDO ++2/8$8],4$I9F MWT_5]/5##H%/^JL8IU'5S_] M>%H@QG?Y2V*;IM?SX&:$SVV"Y-1G?3:T6I)H.>% K[,UVR YT?++IJT=/=,:33L M+;VM5@[KA24W>"=?GP*WA3F7T#_ZLI"J#2UC&0%'A3*K([M_BVY7Q/8\A3D? M2517?:C!A 4!V_QA(W8GC,RLV.)-EEX/0^!&^-_D1[DP&7 M>6L3?%U=%M/CE<_(&:4M;&AD+2< BF-F'B ! 504 4.U!!P!1 M71C4&!0 G-O=7)C97/_;FEX7VUA:6[_!P!4U/%:+P *F\M;&@U+> " !O M!0 (X%E'B !$5]?;F]C;VUM86YD;&EN92YC_%15!0!0I($' %%=&-08% " M?@'QW)8DDH781 MW?!TTV5 N%4K;>0!C9;":=<]+6B1L3CF"H5_-WG)+2TIA+9A;4VV]=A>"$.K M.FD"X.$J9IA8*F@@\\Z59@0M7Z+W2M03+8%!TJ!\Z&U$?H!+:0,X.#_B9#F6 MDEMP#Z,YV!"A=%!U2DRA@C_M*D3U2B'QI M;*E?#G^6X*=.7<&/B*+M T+9HW$2KINES8)-*,P&-SX^OE,;8B)4Z';KF)N7 M;2-3 %14=]()/EK)>'Q:+%!9.)C'9F1&%V$.89B8$I43 DQC:N]TO;4UR=LI M%'J,J52G,Y:G65@_-#%6M"I:RI#0[.3IU-HW9R"I&?%3FC>>NVW6S5'8=31& MD&YSM+H0E"Y:IQ#,)6^)[]U<1\+P &"8-"ZBLOWSG0-B;ET =0+\%$-7@Z1# ML'AER0JUXFP"EAM&*BE5!8D4NH%>PX+W2_ZK-PQDJ2W=AB]7A?[$ON M&@>\@3,_YSM))CZ\.& H5\K;&'N0PG1&Z)_6J:2;;A2S4?3)Q?Y_L<:8G=X' M6Y:S19;4>^D%S 0Y4&:-<>N5JWSO/PEH5)[K+Y026YYP7IYUH^HH?3%MMU%Q MW,5_%]#7L?W@@@K8SOJ]#.+WP1V@\XM_]B\S#T8ST"^4?Q?"XF"O%'LSK ] M8 ^>J" =!&!=]C'X-Z2_T=&3H-AP8[YNK)D-AR8^?S=&5@G[M3E^C!%T1$WK M7SILH@>373&$\44F_^?ZW[/;PSIG=!\46IIV#G_'!\.W8CV*P;^HW;0/MD]] M@W*OOT8AH?],_[A[FU,KAC2]IUX"NI5_,!;*[UQN]71#TLOO:\%OW.VFO2>] M+*6= TEG=X+":I2'?G<6EZW#%I!3;EKSV4>( $1 M7U]N;V-O;6UA;F1L:6YE+F-PX54% %"D@0< 45T8U!@3 )S;W5R8V5S_VYI M>&UA:6[_!P!40LI9+P !"%KU]&FW//FQX ]-DB/F!9+5MOA=-W_<^;;@!)%K%=\VW@)MX=HVVV[^1CPR31%%[95 M12&S>K1R6*@9?H6'BTETH3V[1&M">O,4\.CBE41*IM4XZ.(L8H(/=BZ>:""L MN,>0QR\2T=M0\2)>(/_:$:6T!RR2EK&P@TK$3!J2A6\[8- Y\!A3Q&CL>#TD MS,$V"_114G$8ZA!^@@(G/"\+B=%>+&#!1 )$UX!.\5!=#H(D3KK"[L>V!1 % MA1ITD/$MPZ1DQY39UI"1!\XJB,IZ2*529H5"ZN7X4+"#JY5QBZ)<[UC8I8( ME89&LQ_C\P% T*C0M9:%:W?Q=.'"QR.9&KM$B,5;*+ 2VD-T@4@!V-&XZX I M^S5/0? R8PP'=RR"N>O'\UA5AV2'= &Q#+_ 4K19COV9Y%C?QZBGK/K?1CO7 MX,>&]SX,-\8WPF -IX(1?H93F2_EZ^Q2QP.R.YR2Z8+J<^$TJFNRNC.&(2D"-"@ZX^3I$*D6T]A3TY>FU+J2\ MT-K^XW, M%D?8I&7B@D1:B)E+OO'8R#^W"?7 ?US]0N,<>>;1DU<:]!I"N&LV7%O0_PBX M?K]9^/R55R/PCHH:[A0R6K3U-%!KEQYLXYX*&JI$S)*3K>J%M1OX\-*,I*O) M*4]&M%4EJC7[)7>1[T[XJ'Q:NJK?D]B1H+J/ MMM9WG-C@7-BS9GXA-BGE7-AV+*5.D MQR*#-]15.NSAUPG8&.1ES ZKF:;07&I7UC=7!%]*7 TN7\F3'D@PX,5^#+CQP8<>+W>BDY MTE*MCUIVO.Y1-5C>4ZJ_O([OL,-&[-%D7GLT^^S+_=DC-AD82K>IT]+ZOMV# M\%>NCFD1*5@T;W_:IY0S>(2;.%:<@>.*'B14Q4Z3LU/UZLH8ACVZ:&UT0R5: M170TBOV65-UN+664> Y27UV=<&R-]-7=,C]H_TF)L#5A>_?/>&2N>S9CA!.[ M$&[S04-2RM:!1S'A49!Y5[T #!XWLK?%2O7O9@Q8,KGCXE=NY^?&":607_X8 M0;J%VD 9=RUL:&0M)@ !=8V8>( $ !5!0!0[4$' %%=&-08$P " MF%M$ EFHTFSW&@426X M9"B5"2W:\)XW_^2DDW!9L!>/<>X-M'=8VVV]YDK*Y#4**].U!'/*U^RTAF'0 M34QI-9C$VYLE&2CDE\R<1N,E>XGRR?!2$N-WH:0JSD^.3L3XJ)I08D_1T4@:]C"5[-;B>*V?1I+7/(A;V[B ML\DGA6YN],6,VH5)^%555;G5.3_*)CS@'K1Y.D6P @=%(+(6G1Q SYRO+GT\ MB34UE@ !E+?'8)1!&D.UCMA9#"(L*E<6Z%[-]!575V=7=5U]7;W5508G,#$E.?R^@S^AU&' T&\ ML\QQ[PI[%*BJ'8S)N2"%[11#K='+ZBBMU_X+-O%QK@@VV^ (#.*G!]TOXN/" MT3A 816,!IB-&_.^7\;GL_"P^KW_Q_\!,O^P#QJ?&KW[/1PE]%%A=)(]AV.] M:OH8X?2@/-_=QL,VYO&U[998++/C<-& M+,Q\OK)G"Y<(_ +:]PJB%*P_^--R5C3B3L_;KZR/0VQ*RO#/2I(8Z[6)6/1[ M!T+A%+S(?,0KC(6=*]8XY3HPZVM2QJ7[B6!I>EEPC1C5R8'H7LMU*+")!>;% MM#2R,4<$R.42M3&6Y[S&C1R3'IQ0/-HF.*0-9:$=*8]/ ,#BV/ M#4UZ7)X7O=C@M*,4!0$)M&"IN%B;XUD83>&C\=^$**HZ:+K,ANKIJ'#2&)#$P:@ MZ6HA021FHD=@8Z\Q91TGL@ ]DT\\V4?W 3>*N$C0T&I\A6H+! CUAP4P*&P7 MZV;]-O 0+*J36TK4C\"?()-))?( $';F-R=# N4^!3504 M4*2!!P!171C4&!, G-O=7)C97/_\-__):2 M;FN& O!N+9K]=H'96@-+&AJ.<-F7%/BGY MI=P44>0?R0_M=J(&?W1XOZHM5MO#]\ ]!DO^;&O@'[Z)9;6TCPMX0!TY2!_ M/LZY"]L@HD6;MUU*%E';;*F*%E)),6I3*E24TH]$OX>^I#S40X#T>CR[>E+7 M/!"WMVAS@E:7Q>K89KI@&%Q_.$5#J2 _7UJC&^66'UFDDL9L0J0V.:FFD[++ M!BXH8-RW$U^I*%RWDNM(GO-L1W_.\2C-HF-[;_8WMFI[]KNH9X%V':ZC")DF M-D'U\G-'@9^3C'+-HY>*Z-./J]SQZD^?DC#J/"J6B32UE@@% >YV!@(,)!]K M':I92X&CJ%Y5(-<@=\CA0LQL?V86Z7T5%__4C0S]FXIIT=2%G\>TF&W CT0? M6] &4J,I-.M9WI8MP/\4+ Y$6&2N+9D\L%\,8.ONZ_"GLZ^_PIIYJ)C9=ZE^ MBI/PY\DU9>_E4+'$@B2KL)0CW4+V3.MS\_$,S=7W$/<)!'TP8[@Z0FRMCO[INA?GZRSR_Y4I=?#O?06S'%?&F!J'ZVK&V91/"Y[&PQDG\[7MEE@L MLV%E$8<35X^,<8V4#..A=:5ZBOPK1?ZVM2QJ7[0L'+3++?%.--)Q^%Z[=*C:I MC=&%X&6-P?"2I>WDTTC%5BDBPD5*8RW-=T9\_--71@@>C/-620/9:,9J(^GD M-WPZ"AS/>M]U]K>//+$X8BH8V$GX)2_TP271$GR.>YD[B9]Y*G8$[YW4$Y$1 M,,@L&ZQ[V>N=CBM)\$!.,)L]ZIWEEU^%5FX(9L1LIK8AR_Y>/V.K[:_Q&2$P MZHBS="I4.#:S64Q]8Y*-P,6-)K-;3QV(U,?XQV/E+HM$4=!.:^CAJ*TM1"C( M&:0CHW+1.3B.D]D /9-DR38R_<2;BMY)4AF>8#-0:"!+UAX*8-(@U;K9_6B> M\@L;"DU-,U);6\1<:3"ZBB\&^OO@%A=QQX_!4_<="_4:&,3[ ;/4 LAX^ZH] M+C7I1* AHBUL:#4M?P4 *D, "-:&0>( $(;G)C%P9.!IIR31@8!VT2T0"62Z2;3;B0*1+<,A1*I)$\(]X;_)*233U=&&X M\-R[:.[1MMMWT!9F'*9+24(,%!&&69!&G\C QI%MUUA2HI@TJ6&JFD/++PS< M,WWQ^@8J> *-@?'A]Z#'93WF6!$E#XRM82S!+R9\W&$O+RYA- M>E04:]3 \4J\TQ^@@?DM0KJK.&HS29L7 (+G%E2(1L JD_PUY6'>/^U0'JK$ ML%KP.T/,[>\*M:&G$)!KV/2?[*U@SO5K04-;# WO,"5)QVO7:[6-[M'TAL$O M286R%*?=&* 8JH4A6:D^D](%-I.DS(XY^C].KWJ70GQ 0_'-DCCK7.)U85 '+EJ?W]?-S3]G;U=?,#A>29S[5ZZ$"][-E5"D"]\47#J0,GHIYS?0[7@&F^ MC7%>DZV- 8FKV!C 9_BP[J):4' ?KSHA&6.-_UGBBJ5Y&1$3)(6:.WJ4>N:. M[MFS]TA.-W=FN@@EDLA)1Z^#%Q$X]&+"+.?NX,$,1R4:QHFDVC%!]H$5B*RR M$RCUH2:+2M50CG.+:TPN$-/X*UK"HS&$U&CC<3=WM%N4&):E;(O"F9"9/JS- MLIH+;_C2% .]S,KF;OJN,ZX?&!'4T$:86BJ4,=G6WC=<\'!KG/HZ"?S1%Z_Z MG5(7DNAGZYYYRD:2=A_W-(7BW"*&,L#NAF0I19;BATL:3+(7)#JY5RR%=*=G MF2N(N^6-MC^]Y,UR-)F@C:#?.*D8<)UUV1!%BR9ISI.W'D^G)ITFD)>U+F2R M7H3BA%VY)?:CK"S.^4ED!WP+?$UFY#Y-'WWLXE4"+!:0?D;.7N-+&6PCSX($ MEQ(4:T\VC$27.BRIVR(&2RIVT_C3=[\65 M(?/SB]>:'5S'NB'CEA5#X4#/-RGTZTTLCVT)/2!D^3D0RO1CWBA8G_!=.T6] M23N6-Y"TAY$1(Z]UJEF@^=;5CI=?EDS[G]YOU M_]_X-S&7460L0M@5CVU]?;0C#:O;3!@%R@1E)DE.G4[;24UW6M9U+.W8%0 M^&P+U6T#7X0;']TH)"/_%N=6;^:3W=O!9(E(**9=O(H0I5\.IG9&MN<7BT0T MCTCXTCL#[^G@.-)*FCXX>[/Y=L'R:(X#AAB92X:6G)2[I>DN* GPIIM9.T3- M8)0R\3=BG%R(!+_"%FMSJN9ZUV,%I-NR$\6BY4V"W&]]LUTWEF*=9GS8!6D+ M_$VIX#U22RR9'?L!-HJP2Z=(ZDAR.F(] NZOX(4,ZALJ2K;F:P$.V7( M/0LBSN\K7A<3116W+29K@-M_> *ZY_<3[53_86X .9AW (=$ &VJD0H 3 end From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 14:06:10 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91165-2>; Mon, 6 Mar 1995 13:58:34 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA16042; Mon, 6 Mar 1995 11:58:29 GMT From: Peter Ivimey-Cook Message-Id: <23696.199503061156@creda.isltd.insignia.com> Subject: Re: Books To: se1dp@dmu.ac.uk Date: Mon, 06 Mar 1995 11:56:27 GMT Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: ; from "Derek Piper" at Mar 6, 95 11:20 am X-Mailer: elm X-Mailer: Elm [revision: 109.14] > > > Hi, > > I know I should read the books, I want to get some but I don't know > what to get exactly. I was thinking of a basic C manual as well as a Rom > Kernal Manual. Does anybody think I should get any other type of book ? > Can anybody recommend a book that they find useful ? > Three books should be on your "really useful" list: "The C Programming Language" 2nd Ed., B. Kerninghan, D. Ritchie, Pub. Prentice-Hall, ISBN 0-87692-596-4 -- *The* reference manual on C. If it's not here, it's not C! You might *probably will) find easier books to read, but this is perfectly adequate, and includes the technical stuff many others leave to the imagination. Worth the money, IMHO. "Amiga Rom Kernel Reference Manual: Libraries" 3rd Ed., Commodore-Amiga, Pub. Addison Welsey. -- useful stuff on how the amiga works -- essential reading IMHO. "AmigaDOS Reference Manual"?? 3rd Ed. Pub. Bantam Press. -- the only place AmigaDOS is described *at all*! I have all these at home, but can't remember the precise details of the last two - I may have the title's slightly wrong. If you're adventurous, get the "RKRM: Devices" and "RKRM: Intuition Style Guide" too. Unless you're into games writing forget the Hardware manual; it's only really useful for direct chip access (something we should try to avoid) or more info on the blitter (which can be useful but isn't enough on it's own to buy it, IMHO. The RKRM: Includes and Autodocs is useful (& includes many functions which aren't described elsewhere), but mostly in the gcc or C= develpers distrib anyway - you're better off getting the C= developers pack. Hope this helps, Peter -- Peter Ivimey-Cook Mail Id: peteric@isltd.insignia.com Insignia Solutions, Kingsmead Business Park, London Road, High Wycombe, Buckinghamshire. Telephone: +44-1494-459426 HP11 1JU, U.K. Fax: +44-1494-459720 From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 14:46:09 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <91211-1>; Mon, 6 Mar 1995 14:35:57 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id MAA21310; Mon, 6 Mar 1995 12:34:33 GMT From: Lars Hecking Message-Id: <199503061237.MAA02972@mostar.nmrc.ucc.ie> Subject: Re: Books To: se1dp@dmu.ac.uk (Derek Piper) Date: Mon, 6 Mar 1995 12:37:12 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Content-Type: text/plain; charset==ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 830 > Hi, > > I know I should read the books, I want to get some but I don't know > what to get exactly. I was thinking of a basic C manual as well as a > Rom Kernal Manual. Does anybody think I should get any other type of book ? > Can anybody recommend a book that they find useful ? > > Cheers. > > Del. Hi Derek Everything you're looking for is in the Amiga Related Books FAQ. It's available by anon-ftp from rtfm.mit.edu and from the web as Hope this helps. Lars -- Unix on a PC is, well, it's like putting cards in your bike spokes and calling it a motorcycle. Brrrrrrr...... But understandable on a computer that comes with a "Turbo button". -- Doug Howard in <3igeje$57e@noether.mke.cg.jci.com>, 2/23/95 From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 16:32:41 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91191-3>; Mon, 6 Mar 1995 16:16:15 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id aa11384; 6 Mar 95 14:08 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA005g1; Mon, 6 Mar 95 09:53:08 GMT Date: Mon, 6 Mar 95 09:53:08 GMT Message-Id: <9503060953.AA005g0@flevel.demon.co.uk> Message-Id: <204e9c81.83d60-dev@flevel.demon.co.uk> In-Reply-To: <9503041256.06bg@kriton.UUCP> (from Kriton Kyrimis ) (at Sat, 4 Mar 95 14:56:22 EET) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@nic.funet.fi, gnikl@informatik.uni-rostock.de Subject: Re: Libnix argument parsing weirdness Hi Kriton, > Hi Gunther (Gunther Nikl), in <199503031831.TAA06142@honshu.informatik.uni-rostock.de> on Mar 3 you wrote: > > > Should be fixed in the next version. Solution so far: > > > > 1) Do not use Runback :) > > 2) if you use ">" or "<" between command and arguments make sure that only > > ONE space is between the "<>" and the arguments > > 3) Recompile runback, removing that second space--I tried it and it works! That will stop the symptoms but not cure libnix ;-( The definition of argument passing to C programs allows for any number of white spaces between each argument without affecting the data passed to the program. Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 16:45:06 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91216-3>; Mon, 6 Mar 1995 16:31:44 +0200 Received: by ceylon.informatik.uni-rostock.de id PAA04698; Mon, 6 Mar 1995 15:31:30 +0100 Received: by honshu.informatik.uni-rostock.de id PAA15157; Mon, 6 Mar 1995 15:31:29 +0100 From: Gunther Nikl Message-Id: <199503061431.PAA15157@honshu.informatik.uni-rostock.de> Subject: Re: Few questions To: peteric@isltd.insignia.com (Peter Ivimey-Cook) Date: Mon, 6 Mar 1995 15:31:28 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <15332.199503061111@creda.isltd.insignia.com> from "Peter Ivimey-Cook" at Mar 6, 95 11:11:41 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1537 > I found this too - Most of the errors are because gcc doesn't automatically > invent null structure definitions when it sees a declaration referencing an > undefined structure. Most are easy to avoid by defining a null structure ref: > > struct xxx; > > but the typedefs can't be done this way. The real solution is to include the > structure defs. before the protos. But this ends up in *big* files! Big files? What do you mean? The size of the resulting executable should be the same with or without the missing include (as long as only a prototype requires a structure definition). Only compile time will increase. I recommend not to use the clib/* prototypes. Better to use "proto/libname.h" where libname is "exec", "intuition", etc. Those files include all missing files, so the warnings should go away. > > Secondly, does anybody know of any nice fast clock procedures ? > > I have been playing around with a number of ideas at the weekend, but I wondered > > whether anybody had a nice fast idea, I am going to have clock as part of a > > program so it has to run fast so as not to impede execution of the program. > > What do you mean. The simplest way of getting the time of day is to look at > the DOS clock function CurrentTime(), or it's C-lib equivalent time(); > Won't this do. CurrentTime() is an intuition function. If you want measure execution time of a function and your program shall only run with OS2.0: use GetSysTime() and SubTime() - two functions from the timer.device. Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 17:05:17 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91263-2> convert rfc822-to-8bit; Mon, 6 Mar 1995 17:02:15 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id aa12337; 6 Mar 95 15:00 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA005ma; Mon, 6 Mar 95 14:39:29 GMT Date: Mon, 6 Mar 95 14:39:29 GMT Message-Id: <9503061439.AA005m9@flevel.demon.co.uk> Message-Id: <204edf9e.83d61-dev@flevel.demon.co.uk> In-Reply-To: (from Derek Piper ) (at Mon, 6 Mar 1995 11:20:23 +0000 (GMT)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT From: dev@flevel.demon.co.uk To: se1dp@dmu.ac.uk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Books Hi Derek, > I know I should read the books, I want to get some but I don't know > what to get exactly. I was thinking of a basic C manual as well as a Rom > Kernal Manual. Does anybody think I should get any other type of book ? > Can anybody recommend a book that they find useful ? You could try:- New C Primer Plus Howard W. Sams and Co. By. Mitchell Waite and Stephan Prata. If you to learn C from scratch. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 18:37:00 1995 Received: by nic.funet.fi id <91274-4>; Mon, 6 Mar 1995 18:26:17 +0200 From: Leonard Norrgard To: se1dp@dmu.ac.uk CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Derek Piper on Mon, 6 Mar 1995 09:29:40 +0000 (GMT)) Subject: Re: Few questions Message-Id: <95Mar6.182617+0200_eet.91274-4+37@nic.funet.fi> Date: Mon, 6 Mar 1995 18:26:13 +0200 > I have a few questions to ask, firstly, why do the original >CBM includes namely the exec, dos and graphics library protos generate *so* >many warnings with GCC ? Granted this does not stop compilation nor even seem Sloppy programming at CBM, sloppy compiler at SAS. CBM used the SAS compiler to write that stuff and the compiler silently accepted references to undefined structures, making lots of the include declarations lip-service without a true functionality. Oh well, the fix is to include the needed files from . For your other programming questions, you'll probably get better help on the usenet newsgroup comp.sys.amiga.programmer. From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 18:45:10 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91264-3>; Mon, 6 Mar 1995 18:32:19 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <105-3>; Mon, 6 Mar 1995 17:17:26 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209155-2>; Mon, 6 Mar 1995 17:17:32 +0100 Subject: ld problem From: Christian Stieber To: amiga-gcc-port@lists.funet.fi Date: Mon, 6 Mar 1995 17:17:27 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3695 Message-Id: <95Mar6.171732+0100mesz.209155-2+440@hphalle0.informatik.tu-muenchen.de> Hi all, I finally decided to adapt my environment to GNU C, allowing me to compile with my old SAS/C V5.10b as well as with the current GNU C without source code changes. However, I seem to be unable to link baserelative stuff: ------------------------------ Cut here ------------------------------ [0] Work:lc/Projekte/MyLib> delete main.o main.o Deleted [0] Work:lc/Projekte/MyLib> make gcc -MyLib -fbaserel -v -Wall -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Werror -nostdinc -I. -I- -I/gnu/MyLib -I/gnu/os-include -I/gnu/include -c main.c -o main.o Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c -nostdinc -v -I. -I- -I/gnu/MyLib -I/gnu/os-include -I/gnu/include -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Wall -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Werror -Dmc68010 main.c t:cc126032.i GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: . #include <...> search starts here: /gnu/MyLib /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1 t:cc126032.i -quiet -dumpbase main.c -Wall -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Werror -version -fbaserel -o t:cc126032.s GNU C version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3 snapshot 941209. as -mc68010 -o main.o t:cc126032.s gcc -MyLib -fbaserel -v -o ADtoHT main.o File.o Includes.o ProcessDir.o AVL.o Autodocs.o AdditionalDocs.o FormatNode.o Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 ld -shortdata -fl MyLib -databss-together -fl libb -o ADtoHT /gnu/lib/MyLib/libb/Startup.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/gnu/lib main.o File.o Includes.o ProcessDir.o AVL.o Autodocs.o AdditionalDocs.o FormatNode.o -lgcc -lMyLib -lamiga -lgcc ld: unsupported reloc-size in main.o make: *** [ADtoHT] Error 1 [1] Work:lc/Projekte/MyLib> ------------------------------ Cut here ------------------------------ I have never seen this error before, but I haven't used -fbaserel before either. However, "unsupported reloc-size" sounds like a baserel problem to me. Is there a better linker out there? Or is my specs file broken (some missing option, perhaps)? Is there a workaround? I really hate the idea of having spent all this time creating libMyLib.a, just to find out that I can't use it :( If there is no fix/workaround: can sobja *reliably* convert a.out files to hunks (to let me use blink)? Thanks for your help, Christian P.S: why are you people working on adding "fast" to GNU-C? "chip" is okay, although "far", "saveds" and "interrupt" are probably more useful. "fast", however, is very dangerous since there is no reason to ever use it. However, when this keyword is available people will use it ("hey! my program is faster than yours, since I used 'fast' on all my variables!") and their programs will fail on systems with no fastmem. Same applies for MEMF_FAST, but that's not a compiler problem. Also, since "chip" implies "far": will "far" be added as well? -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP key: finger stieber@ftp.leo.org -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 18:54:16 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <91169-2>; Mon, 6 Mar 1995 18:43:43 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id QAA23259; Mon, 6 Mar 1995 16:43:00 GMT From: Lars Hecking Message-Id: <199503061645.QAA03274@mostar.nmrc.ucc.ie> Subject: Re: Few questions To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Mon, 6 Mar 1995 16:45:37 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Content-Type: text/plain; charset==ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1104 In <15332.199503061111@creda.isltd.insignia.com>, Peter wrote: > > but the typedefs can't be done this way. The real solution is to include the > > structure defs. before the protos. But this ends up in *big* files! In <199503061431.PAA15157@honshu.informatik.uni-rostock.de>, Gunther wrote: > Big files? What do you mean? The size of the resulting executable should > be the same with or without the missing include (as long as only a > prototype requires a structure definition). Only compile time will increase. > I recommend not to use the clib/* prototypes. Better to use "proto/libname.h" You're right about the executable file size, Gunther, but intermediate file size goes up with all the additional includes (cpp output). It's not unusual to have an 100k+ .i file in T: for a 3k executable. This is a problem on machines with small amounts of RAM. -- Lars G. Hecking lhecking@nmrc.ucc.ie GE/Mgc[failed] d--- H+>H--- s:->s++ g+ p0>? !au a- w+ v+>v++ C(+++) US++ P+>+++ L>L++ 3- E+ N+ K- W-->--- M- V- -po+ Y+ t+ 5 !j R G? tv- b+ D-- B? e++++ u++(-) h* f r++ n+ y+* From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 19:53:09 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91275-3>; Mon, 6 Mar 1995 19:42:25 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA12497 (5.65c8/IDA-1.4.4 for ); Mon, 6 Mar 1995 18:42:12 +0100 Received: from sunserv2.izfm.uni-stuttgart.de by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA15491; Mon, 6 Mar 95 18:42:12 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503061742.AA15491@sunserv.IZFM.Uni-Stuttgart.DE> Subject: libnix question! (fwd) To: amiga-gcc-port@nic.funet.fi Date: Mon, 6 Mar 1995 18:36:23 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 689 > > > > The program works OK but the printf() function prints > > "funny" characters (ie + -, /) instead of numbers. > > Oh, yes I know about this one :-(. I got a bug report about the cast operator not working correctly from Andreas Wolff and this helped me to nail this one down: The Fix() functions of mathieeesingbas.library and mathieeedoubbas.library seem to round to nearest on 68040 processors (instead of just cutting the number off). This affects libnix's cast operator as well as ixemul.library's. And it prints funny characters on libnix since libnix relies on the cast operator working right. If anybody's got an easy solution please tell me - I could need one. Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 20:55:43 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91208-2>; Mon, 6 Mar 1995 20:51:42 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <86-1>; Mon, 6 Mar 1995 19:51:10 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209155-2>; Mon, 6 Mar 1995 19:51:14 +0100 Subject: Re: Few questions From: Christian Stieber To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Mon, 6 Mar 1995 19:50:57 +0100 (MEZ) Cc: gnikl@informatik.uni-rostock.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <199503061645.QAA03274@mostar.nmrc.ucc.ie> from "Lars Hecking" at Mar 6, 95 04:45:37 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1083 Message-Id: <95Mar6.195114+0100mesz.209155-2+477@hphalle0.informatik.tu-muenchen.de> > You're right about the executable file size, Gunther, but intermediate file > size goes up with all the additional includes (cpp output). It's not unusual > to have an 100k+ .i file in T: for a 3k executable. This is a problem on > machines with small amounts of RAM. Not really. I'm currently *very* low on memory (can't use the optimizer :(), and therefore my T: is really Work:t/ (i.e. on disk). Converning the prototypes problem: -Wstrict-prototypes never works, since function pointers in structures don't have prototypes. This is another Commodore-related problem. Also, Commodore decided that "const" isn't a good thing; none of the prototypes has it. You can't use -Wcast-qual because of that. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP key: finger stieber@ftp.leo.org -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Mon Mar 6 23:16:03 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91163-2>; Mon, 6 Mar 1995 23:12:51 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id aa22795; 6 Mar 95 21:07 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA005q7; Mon, 6 Mar 95 18:35:41 GMT Date: Mon, 6 Mar 95 18:35:41 GMT Message-Id: <9503061835.AA005q6@flevel.demon.co.uk> Message-Id: <204f16fb.4e200-dev@flevel.demon.co.uk> In-Reply-To: <9503061742.AA15491@sunserv.IZFM.Uni-Stuttgart.DE> (from Matthias Fleischer ) (at Mon, 6 Mar 1995 18:36:23 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: fleischr@izfm.uni-stuttgart.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: libnix question! (fwd) Hi Matthias, > > > The program works OK but the printf() function prints > > > "funny" characters (ie + -, /) instead of numbers. > > > > Oh, yes I know about this one :-(. I got a bug report about > the cast operator not working correctly from Andreas Wolff > and this helped me to nail this one down: > > The Fix() functions of mathieeesingbas.library and > mathieeedoubbas.library seem to round to nearest on 68040 processors > (instead of just cutting the number off). > This affects libnix's cast operator as well as ixemul.library's. > And it prints funny characters on libnix since libnix relies on the > cast operator working right. Hows about: Fix(Floor(x)) ??? Regards. Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 11:52:28 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91396-2>; Tue, 7 Mar 1995 11:38:57 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA14510 (5.65c-6/7.3w-FAU); Tue, 7 Mar 1995 10:38:40 +0100 Received: from faui8s1 by immd8.informatik.uni-erlangen.de; id AA11004 (5.x/7.3w-FAU); Tue, 7 Mar 1995 10:38:39 +0100 From: Tobias Ruland Message-Id: <9503070938.AA11004@immd8.informatik.uni-erlangen.de> Date: Tue, 7 Mar 1995 10:38:37 +0100 To: amiga-gcc-port@nic.funet.fi Subject: Stack Size! high all some days ago we've had a discussion here about stack size. my suggestion is: include a link-lib (libstack.a :-) ) with two functions: - long unsigned int stack_size() - getting actual stacksize - int stack_size(long unsigned int) - setting stack size ^ error code that should be easy to implement for one of you exec-stack-freaks :-) and would be very very helpful for all others. and it would make sure, that the stack is accessed in a amiga-os-compatible and safe way. any comments? tobias From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 12:57:33 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91402-3>; Tue, 7 Mar 1995 12:48:19 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA21517; Tue, 7 Mar 95 12:41:20 +0200 Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA01807; Tue, 7 Mar 95 12:45:54 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9503071045.AA01807@hpcl.cti.gr> Subject: Re: Stack Size! To: tsruland@immd8.informatik.uni-erlangen.de (Tobias Ruland) Date: Tue, 7 Mar 1995 12:45:53 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9503070938.AA11004@immd8.informatik.uni-erlangen.de> from "Tobias Ruland" at Mar 7, 95 10:38:37 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1967 > include a link-lib (libstack.a :-) ) with two functions: > - long unsigned int stack_size() - getting actual stacksize This should be easy to implement, as soon as we resolve what is the best way of determining the stack size--there's still some uncertainty concerning the correct order of doing things. (Should pr_ReturnAddr be checked before, or after tc_SP*?) SAS/C provides a set of such functions, so we should probably provide a similar set for compatibility. > - int stack_size(long unsigned int) - setting stack size > ^ error code This is more difficult to implement. The contents of the old stack will have to be copied to the new stack, which is tricky, but not impossible. However, after such copying, there will still be references to the old stack in the subroutines that called stack_size, resulting in confusion. Consider for example: sub() { int x; foo(&x); return x; } If foo() changes the stack, then sub will not return the correct result. The reason automatic stack extenders and setting the stack size at startup work is that only the subroutine that changes the stack, and its children get to use the new stack. In the second case, the stack swapping module restores the original stack before returning to the startup code, while in the first case, the stack extension routine modifies the stack so that the subroutine that called it returns to a subroutine that deallocates the new stack and then returns to the original caller. (*Very* tricky!) > that should be easy to implement for one of you exec-stack-freaks :-) As you see, it's not that easy. Why would you need this, anyway? I would think that setting the stack size at startup (already supported by libnix, and there's a stderrfix-style hack for ixemul), or automatic stack extension (when and if it becomes available) should be adequate for most needs. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 14:09:40 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91418-1>; Tue, 7 Mar 1995 14:02:57 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA22273 (5.65c-6/7.3w-FAU); Tue, 7 Mar 1995 13:00:29 +0100 Received: from faui8s1 by immd8.informatik.uni-erlangen.de; id AA14111 (5.x/7.3w-FAU); Tue, 7 Mar 1995 13:00:28 +0100 From: Tobias Ruland Message-Id: <9503071200.AA14111@immd8.informatik.uni-erlangen.de> Date: Tue, 7 Mar 1995 13:00:25 +0100 To: kyrimis@theseas.ntua.gr Cc: tsruland@immd8.informatik.uni-erlangen.de (Tobias Ruland), amiga-gcc-port@lists.funet.fi (gcc) Subject: Re: Stack Size! In-Reply-To: <9503071045.AA01807@hpcl.cti.gr> References: <9503070938.AA11004@immd8.informatik.uni-erlangen.de> <9503071045.AA01807@hpcl.cti.gr> high kriton (and all the others) Kriton Kyrimis writes: > > include a link-lib (libstack.a :-) ) with two functions: > > - long unsigned int stack_size() - getting actual stacksize > This should be easy to implement, as soon as we resolve what is the > best way of determining the stack size--there's still some uncertainty > concerning the correct order of doing things. (Should pr_ReturnAddr be > checked before, or after tc_SP*?) SAS/C provides a set of such > functions, so we should probably provide a similar set for > compatibility. I thought, that one won the battle :-) > > - int stack_size(long unsigned int) - setting stack size > > ^ error code > This is more difficult to implement. The contents of the old stack will > have to be copied to the new stack, which is tricky, but not impossible. > However, after such copying, there will still be references to the old stack > in the subroutines that called stack_size, resulting in confusion. > Consider for example: > > sub() > { > int x; > foo(&x); > return x; > } > > If foo() changes the stack, then sub will not return the correct > result. you're right. thats a problem that wouldnt be THAT easy to solve :-) BUT there might be a simple solution for that problem (maybe, im not sure): suppose, you have a MMU :-) millions of amiga users would be happy about a unix-like stack management. when a gcc-compiled program starts up, it gets a own new stack with a virtual (!) address/SP. once there's a stack overflow we get an exception that causes a stack-extending routine to allocate a new/bigger block of memory, copies the old stack into the new area, FREEs the old stack and sets the MMU table according to the new memory area. i'm a scientist and not that amiga-freak, but imho that could solve the problem?! > As you see, it's not that easy. Why would you need this, anyway? I > would think that setting the stack size at startup (already supported > by libnix, and there's a stderrfix-style hack for ixemul), or automatic > stack extension (when and if it becomes available) should be adequate > for most needs. no no no. no program nor any programmer will/can KNOW how much space a particular application will require. that is only true for very very simple programs. in general you need a stack of unknown size. solution: set stack size to 1 GB and you'll never have any problems :-) thats the first way. the second (and better) way is to let the stack grow when it becomes too small. imho THAT is the way to go. c u tobias, waiting for comments From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 15:33:13 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91421-4>; Tue, 7 Mar 1995 15:24:58 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Tue, 7 Mar 1995 14:23:45 +0100 Received: from bodman.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA16531; Tue, 7 Mar 95 14:23:43 +0100 Date: Tue, 7 Mar 95 14:23:43 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503071323.AA16531@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@lists.funet.fi Subject: Re: Stack Size! kyrimis@hpcl.cti.gr (Kriton Kyrimis) writes: > >From: tsruland@immd8.informatik.uni-erlangen.de (Tobias Ruland) > > include a link-lib (libstack.a :-) ) with two functions: > > - long unsigned int stack_size() - getting actual stacksize Nothing to say against this one except that it must be prepared for an error erturn code (perhaps 0) if the size could not be determined. > > - int stack_size(long unsigned int) - setting stack size > > ^ error code > > This is more difficult to implement. The contents of the old stack will > have to be copied to the new stack, which is tricky, but not impossible. Copying or anything like this is a huge no-no. You don't know what's on the stack, what you are copying and why you are copying it: copying it is completely, absolutely senseless. What can be done (and has already been suggested in several places), is to call a new function with a stack of a given size. e.g. main() (or any function) calls big_stack_main() (or any other function) with the stack pointer set to the new value. This can even be written in C, but is easier to write in assembler. Things that prevent the general solution of this issue in a non-dynamic typed language are function arguments, function return types and set-/longjmp(). > The reason automatic stack extenders and setting the stack size at > startup work is that only the subroutine that changes the stack, and > its children get to use the new stack. Exactly, the new function gets called with a new stack. The old one is restored upon function return. Stack extenders need to be supported by the C lib as special care must be taken for longjmp(). Only switching to some stack at startup (even before calling main) is easy for the writer of the startup module. > As you see, it's not that easy. Joerg Hoehle hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 15:55:26 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91426-3>; Tue, 7 Mar 1995 15:39:06 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Tue, 7 Mar 1995 14:38:35 +0100 Received: from bodman.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA16586; Tue, 7 Mar 95 14:38:30 +0100 Date: Tue, 7 Mar 95 14:38:30 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503071338.AA16586@inf-wiss.uni-konstanz.de> To: tsruland@immd8.informatik.uni-erlangen.de, amiga-gcc-port@lists.funet.fi Subject: Re: Stack Size! > suppose, you have a MMU :-) millions of amiga users would be happy about > a unix-like stack management. when a gcc-compiled program starts up, > it gets a own new stack with a virtual (!) address/SP. once there's a stack > overflow we get an exception that causes a stack-extending routine > to allocate a new/bigger block of memory, copies the old stack into > the new area, FREEs the old stack and sets the MMU table according to the > new memory area. i'm a scientist and not that amiga-freak, but imho > that could solve the problem?! If you had an MMU and would want to use it, there would still be no reason to copy the old stack. Let the MMU solve the reference to the old stack if the program has a need for it. > first way. the second (and better) way is to let the stack grow when it > becomes too small. imho THAT is the way to go. I believe this is the way to go for a certain class of applications. Most applications have very limited stack requirements which is even independent on program input. But if we had automatic stack growth, maybe we should switch the programming language from C to something that doesn't make it much more difficult for the programmer to handle constructs of unknown (at compile-time) size than the usual char foo[MAX_FOO_LEN][MAX_BAR_SIZE]; constructs which cause so many bugs in programs that do not check everything, like most programs do (I'm not criticizing lazy programmers that do not check all and everything here here, because these checks take a lot of programming effort. I'm critiquing programming languages which make dynamic, but safe programming a burden rather than a pleasure). With such languages, it's much more fun to have automatic stack growth. Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 16:00:22 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91423-2>; Tue, 7 Mar 1995 15:43:03 +0200 Received: by ceylon.informatik.uni-rostock.de id OAA08813; Tue, 7 Mar 1995 14:42:31 +0100 Received: by honshu.informatik.uni-rostock.de id OAA03091; Tue, 7 Mar 1995 14:42:30 +0100 From: Gunther Nikl Message-Id: <199503071342.OAA03091@honshu.informatik.uni-rostock.de> Subject: Re: Few questions To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Tue, 7 Mar 1995 14:42:29 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199503061645.QAA03274@mostar.nmrc.ucc.ie> from "Lars Hecking" at Mar 6, 95 04:45:37 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 345 > Lars G. Hecking wrote: > > You're right about the executable file size, Gunther, but intermediate file > size goes up with all the additional includes (cpp output). It's not unusual > to have an 100k+ .i file in T: for a 3k executable. This is a problem on > machines with small amounts of RAM. Oh! never noticed that :-( Gunther From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 16:12:59 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91430-4>; Tue, 7 Mar 1995 15:59:37 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA28844 (5.65c-6/7.3w-FAU); Tue, 7 Mar 1995 14:55:18 +0100 Received: from faui8s1 by immd8.informatik.uni-erlangen.de; id AA15574 (5.x/7.3w-FAU); Tue, 7 Mar 1995 14:55:16 +0100 From: Tobias Ruland Message-Id: <9503071355.AA15574@immd8.informatik.uni-erlangen.de> Date: Tue, 7 Mar 1995 14:55:13 +0100 To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Cc: tsruland@immd8.informatik.uni-erlangen.de, amiga-gcc-port@lists.funet.fi Subject: Re: Stack Size! In-Reply-To: <9503071338.AA16586@inf-wiss.uni-konstanz.de> References: <9503071338.AA16586@inf-wiss.uni-konstanz.de> Joerg-Cyril Hoehle writes: > > suppose, you have a MMU :-) millions of amiga users would be happy about > > a unix-like stack management. when a gcc-compiled program starts up, > > it gets a own new stack with a virtual (!) address/SP. once there's a stack > > overflow we get an exception that causes a stack-extending routine > > to allocate a new/bigger block of memory, copies the old stack into > > the new area, FREEs the old stack and sets the MMU table according to the > > new memory area. i'm a scientist and not that amiga-freak, but imho > > that could solve the problem?! > If you had an MMU and would want to use it, there would still be no > reason to copy the old stack. Let the MMU solve the reference to the > old stack if the program has a need for it. right. i forgot. no need to copy. just extend the stack and map the new stack part to the right logical address. > > first way. the second (and better) way is to let the stack grow when it > > becomes too small. imho THAT is the way to go. > [...]I believe this is the way to go for a certain class of applications. > Most applications have very limited stack requirements which is even > independent on program input. > > But if we had automatic stack growth, maybe we should switch the > programming language from C to something that doesn't make it much more > difficult for the programmer to handle constructs of unknown (at > compile-time) size than the usual > char foo[MAX_FOO_LEN][MAX_BAR_SIZE]; > constructs which cause so many bugs in programs that do not check > everything, like most programs do (I'm not criticizing lazy programmers > that do not check all and everything here here, because these checks > take a lot of programming effort. I'm critiquing programming languages > which make dynamic, but safe programming a burden rather than a > pleasure). your example is exactly what i had in my mind. in scientific applications it is a COMPLETELY NORMAL thing to have something like x_size=calculate_x_size_from_input(...); y_size=calculate_y_size_from_input(...); z_size=calculate_z_size_from_input(...); if(z_size>0) { my_datastructure Huge[x_size][y_size]; .... } even in normal applications where you dont know the size of the input i can imagine a various number of situations where similar stack requirements can happen. > With such languages, it's much more fun to have automatic stack growth. i can't see any reasonable reason why there should be no automatic stack growth with C/Assembler/... on our good old amiga. c u tobias From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 16:31:54 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91425-3>; Tue, 7 Mar 1995 16:16:17 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ah11211; 7 Mar 95 13:57 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA005t9; Tue, 7 Mar 95 09:57:51 GMT Date: Tue, 7 Mar 95 09:57:51 GMT Message-Id: <9503070957.AA005t8@flevel.demon.co.uk> Message-Id: <204fef12.e09c2-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Amiga GCC v PC GCC Hi, Ive just installed gcc/g++ for the PC (djgpp) and I have noticed that it seems to be quite a bit more stable than the Amiga version (I does sometimes crash but the machine doesn't go down like it does on the Amiga). Could this be because gcc on the PC is run through a program called 'go32' which gives GCC it's own virtual memory and memory protection? Also ive noticed that when running your final executables with 'go32' (Unless you convert it to .exe) that when there is a bug in the program which wipes over memory then the program just quits with a register/stack dump. The other nice thing about 'go32' is that because it gives each program it's own virtual memory (Of variable size) then you don't run out of memory (Unless your hard drive is full). It is hell trying to compile un*x style programs on the PC (No multitasking ,nasty msdos,8 char files names, no decent OS. ...). I'd much rather use an Amiga but is there any chance of a program like 'go32' for the Amiga?? (Ive got a good mind to write something better than MSDOS, it should take me a week or two ;-) maybe a port of Xinu [1] !!!!) Cheers, Trefor S. [1] - Xinu Is Not Unix +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 16:35:10 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91407-4>; Tue, 7 Mar 1995 16:17:54 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Tue, 7 Mar 1995 15:17:22 +0100 Received: from bodman.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA16736; Tue, 7 Mar 95 15:17:20 +0100 Date: Tue, 7 Mar 95 15:17:20 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503071417.AA16736@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@lists.funet.fi Subject: Re: Stack Size! Tobias Ruland writes: > x_size=calculate_x_size_from_input(...); > y_size=calculate_y_size_from_input(...); > z_size=calculate_z_size_from_input(...); > if(z_size>0) > { my_datastructure Huge[x_size][y_size]; Some C compilers (GNU among others) allow this, and it's very useful. But there are still cases not covered by that feature. Something like structures (containing strings or whatever) that grow as needed. Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 16:39:57 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91456-3>; Tue, 7 Mar 1995 16:29:24 +0200 Received: by ceylon.informatik.uni-rostock.de id PAA09098; Tue, 7 Mar 1995 15:29:10 +0100 Received: by honshu.informatik.uni-rostock.de id PAA03411; Tue, 7 Mar 1995 15:29:09 +0100 From: Gunther Nikl Message-Id: <199503071429.PAA03411@honshu.informatik.uni-rostock.de> Subject: Re: ld problem To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Tue, 7 Mar 1995 15:29:08 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Mar6.171732+0100mesz.209155-2+440@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Mar 6, 95 05:17:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2196 Hello! > Christian Stieber wrote: > > ------------------------------ Cut here ------------------------------ > ld -shortdata -fl MyLib -databss-together -fl libb -o ADtoHT /gnu/lib/MyLib/libb/Startup.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/gnu/lib main.o File.o Includes.o ProcessDir.o AVL.o Autodocs.o AdditionalDocs.o FormatNode.o -lgcc -lMyLib -lamiga -lgcc > ld: unsupported reloc-size in main.o > make: *** [ADtoHT] Error 1 > [1] Work:lc/Projekte/MyLib> > ------------------------------ Cut here ------------------------------ > > I have never seen this error before, but I haven't used -fbaserel before either. > However, "unsupported reloc-size" sounds like a baserel problem to me. Its a linker problem :-/. The assembler of 2.6.3 is newer than the linker and produces "short" relocs that the linker doesn't know. But thats no surprise because the ld is from binutils1.8 and the gas from 2.5. If you want be able to use "-fbaserel" you need a compatile version of gas. -> 1.38.1 (as used with gcc2.3.3). Remember, the newer versions of gcc have problems with "-fbaserel". Unfortunately gcc accesses some internal support function over its data segment in this case: "jbsr a4@(___mulsi3:W)" resulting in a "baserelative text relocation" error from the linker! Solution: Compile for a processor that does not need any internal support function (nevertheless bcopy() should be ok). If you need access to hardware register, do not use a declaration like this: "extern struct Custom *custom" This would need a "__far" keyword :( Soulution: "#define custom (*((struct Custom *)0xdff000l)) Make sure that you do not have a variable with the same name as a function somewhere in a library. This becomes an interesting error. If the varibale is not initialized, it will be placed in the bss section. BUT ld silently merges initiliazed and unintiliazed data - even if data is in the code section. For "-fbaserel" this gives the "baserelative text relocation" error. However, for large data you will get a wrong executable... poking directly into your code section! Hope, that clears some problmes ;-) Gunther From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 16:46:15 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91438-2>; Tue, 7 Mar 1995 16:37:00 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA28933; Tue, 7 Mar 95 16:31:50 +0200 Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA02899; Tue, 7 Mar 95 14:43:09 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9503071243.AA02899@hpcl.cti.gr> Subject: Re: Stack Size! To: tsruland@immd8.informatik.uni-erlangen.de (Tobias Ruland) Date: Tue, 7 Mar 1995 14:43:08 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9503071200.AA14111@immd8.informatik.uni-erlangen.de> from "Tobias Ruland" at Mar 7, 95 01:00:25 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1676 > > As you see, it's not that easy. Why would you need this, anyway? I > > would think that setting the stack size at startup (already supported > > by libnix, and there's a stderrfix-style hack for ixemul), or automatic > > stack extension (when and if it becomes available) should be adequate > > for most needs. > no no no. no program nor any programmer will/can KNOW how much space a > particular application will require. that is only true for very very simple > programs. in general you need a stack of unknown size. solution: > set stack size to 1 GB and you'll never have any problems :-) thats the > first way. the second (and better) way is to let the stack grow when it > becomes too small. imho THAT is the way to go. Isn't this exactly what I said? * Setting stack at startup: unsigned long __stack = 1073741824; /* :-) */ and forget about any stack problems. * Automatic stack checking: Let the program automatically increase the stack when it becomes too small. With a set_stacksize() subroutine that could be called from anywhere, you would have to determine yourself in which subroutines the stack might get too small (compared to what?), and how much stack each would require, which I don't think is very practical. Regarding your suggestion of using the MMU to obtain essentially unlimited stack space, I feel that this should be part of the operating system, and not of any run-time library. For example, how do you make messages allocated on the virtual address space of the stack visible to other programs? Perhaps this will be in AmigaDOS 4.0. ;-) -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 16:46:15 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91439-4>; Tue, 7 Mar 1995 16:37:06 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA27316; Tue, 7 Mar 1995 14:37:00 GMT Date: Tue, 7 Mar 1995 14:34:53 +0000 (GMT) From: Ruth Cook To: dev@flevel.demon.co.uk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Amiga GCC v PC GCC In-Reply-To: <9503070957.AA005t8@flevel.demon.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 7 Mar 1995 dev@flevel.demon.co.uk wrote: > It is hell trying to compile un*x style programs on the PC (No multitasking > ,nasty msdos,8 char files names, no decent OS. ...). I'd much rather use an > Amiga but is there any chance of a program like 'go32' for the Amiga?? Memory protection - the 68000 doesn't have any, nor do many '020 or '030 chips. (Mostly Amigas have the no-MMU versions). Doing a VMM without hardware memory protection means you'd have to emulate the MMU in software - which means emulating the whole processor. Very slow! > (Ive got a good mind to write something better than MSDOS, it should take me > a week or two ;-) maybe a port of Xinu [1] !!!!) :) Why don't yuo try Linux? From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 17:08:11 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91434-3>; Tue, 7 Mar 1995 17:03:43 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA02088 (5.65c-6/7.3w-FAU); Tue, 7 Mar 1995 15:51:36 +0100 Received: from faui8s1 by immd8.informatik.uni-erlangen.de; id AA15918 (5.x/7.3w-FAU); Tue, 7 Mar 1995 15:51:34 +0100 From: Tobias Ruland Message-Id: <9503071451.AA15918@immd8.informatik.uni-erlangen.de> Date: Tue, 7 Mar 1995 15:51:33 +0100 To: kyrimis@theseas.ntua.gr Cc: tsruland@immd8.informatik.uni-erlangen.de (Tobias Ruland), amiga-gcc-port@lists.funet.fi (gcc) Subject: Re: Stack Size! In-Reply-To: <9503071243.AA02899@hpcl.cti.gr> References: <9503071200.AA14111@immd8.informatik.uni-erlangen.de> <9503071243.AA02899@hpcl.cti.gr> re kriton Kriton Kyrimis writes: > Isn't this exactly what I said? > * Setting stack at startup: > unsigned long __stack = 1073741824; /* :-) */ > and forget about any stack problems. > * Automatic stack checking: > Let the program automatically increase the stack when it becomes too small. as joerg pointed out it is a "dont do it" to let the program itself change it's stack "somewhere". dynamic stack growth should be supported by OS or OS-extension. thats no thing any programmer should worry about. > With a set_stacksize() subroutine that could be called from anywhere, > you would have to determine yourself in which subroutines the stack > might get too small (compared to what?), and how much stack each would > require, which I don't think is very practical. right. > Regarding your suggestion of using the MMU to obtain essentially > unlimited stack space, I feel that this should be part of the operating > system, and not of any run-time library. For example, how do you make > messages allocated on the virtual address space of the stack visible to > other programs? messages? good question. here's the old same message problem again :-) i dont have any solution. and im not sure if this is really a problem. as far as i remember theres only ONE global MMU table for ALL tasks. as far as i remember theres no MMU-state-change at task switches. if dynamic stack growth is not part of your f*^$$%ng OS it could be a "quick&dirty" solution to put some if these "virtual-stack"-routines into a gcc-startup-lib. then only gcc-programs could use that "new os feature" and the documentation could give some "warnings" to the programmer. that would give a minimum of safety :-) > Perhaps this will be in AmigaDOS 4.0. ;-) :-) c u tobias From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 17:33:26 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91479-1>; Tue, 7 Mar 1995 17:28:42 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <118-1>; Tue, 7 Mar 1995 16:28:07 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209195-1>; Tue, 7 Mar 1995 16:28:07 +0100 Subject: Re: Stack Size! From: Christian Stieber To: tsruland@immd8.informatik.uni-erlangen.de (Tobias Ruland) Date: Tue, 7 Mar 1995 16:28:00 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503070938.AA11004@immd8.informatik.uni-erlangen.de> from "Tobias Ruland" at Mar 7, 95 10:38:37 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1146 Message-Id: <95Mar7.162807+0100mesz.209195-1+1115@hphalle0.informatik.tu-muenchen.de> > include a link-lib (libstack.a :-) ) with two functions: > - long unsigned int stack_size() - getting actual stacksize > - int stack_size(long unsigned int) - setting stack size > ^ error code > > that should be easy to implement for one of you exec-stack-freaks :-) > and would be very very helpful for all others. and it would make sure, > that the stack is accessed in a amiga-os-compatible and safe way. It won't be safe. GCC might allocate something on the stack before stack_size() gets called. When get_size returns, the stack would be different and the program would be very confused :) The only safe way, IMHO, is to: call_with_new_stack(size_t StackSize, /* some function prototype */) or adding a new __attribute__((stacksize,n)). Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP key: finger stieber@ftp.leo.org -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 17:55:48 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91446-3>; Tue, 7 Mar 1995 17:47:49 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <120-4>; Tue, 7 Mar 1995 16:43:23 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209155-1>; Tue, 7 Mar 1995 16:43:28 +0100 Message-Id: <95Mar7.164328+0100mesz.209155-1+1119@hphalle0.informatik.tu-muenchen.de> From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Tue, 7 Mar 1995 16:43:22 +0100 >From stieber Tue Mar 7 16:38:19 1995 remote from hphalle6d Subject: Re: ld problem To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Tue, 7 Mar 1995 16:38:19 +0100 (MEZ) In-Reply-To: <199503071429.PAA03411@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Mar 7, 95 03:29:08 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2151 Sender: stieber > Its a linker problem :-/. The assembler of 2.6.3 is newer than the linker > and produces "short" relocs that the linker doesn't know. But thats no > surprise because the ld is from binutils1.8 and the gas from 2.5. If > you want be able to use "-fbaserel" you need a compatile version of gas. > -> 1.38.1 (as used with gcc2.3.3). Hm.. I'll try thst. Thanks! > Remember, the newer versions of gcc have problems with "-fbaserel". > Unfortunately gcc accesses some internal support function over its data > segment in this case: > > "jbsr a4@(___mulsi3:W)" > > resulting in a "baserelative text relocation" error from the linker! No surprise :) Actually, is -fbaserel something that the amiga-people added (making this error an amiga-only error) or is it an "official" m68k option? I believe that one should try to get this fixed :) > Solution: Compile for a processor that does not need any internal > support function (nevertheless bcopy() should be ok). Hm... that's not very good for distributing software. I guess I'll try to set up a script that fixes those baserelative jbsr statements. > If you need access to hardware register, do not use a declaration like > this: I don't. I'm not into hardware poking, except for debugging. > "extern struct Custom *custom" > This would need a "__far" keyword :( I know. Any chance we'll see __attribute__((far)) at some point? IMHO that should be easier to implement than __attribute__((chip)) (which implies far)... > error. However, for large data you will get a wrong executable... poking > directly into your code section! Wow... finally we're back at self modifying code! > Hope, that clears some problmes ;-) Yep... it always helps to get some background information. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP key: finger stieber@ftp.leo.org -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 18:34:18 1995 Received: from EKU.ACS.EKU.EDU ([157.89.8.64]) by nic.funet.fi with ESMTP id <91440-4>; Tue, 7 Mar 1995 18:23:41 +0200 Received: from ACS.EKU.EDU by ACS.EKU.EDU (PMDF V4.3-7 #7621) id <01HNUP8TU3X00098QK@ACS.EKU.EDU>; Tue, 7 Mar 1995 11:21:46 EST Date: Tue, 07 Mar 1995 11:21:46 -0500 (EST) From: AISTERWI@ACS.EKU.EDU Subject: Libnix & floats To: amiga-gcc-port@nic.funet.fi Message-id: <01HNUP8TU3X20098QK@ACS.EKU.EDU> X-VMS-To: IN%"amiga-gcc-port@nic.funet.fi" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT More on the Libnix and Floating point problem: When I compile using: gcc -noixemul -o scale scale.c -lm printf() of floating point numbers produce weird characters (+ - , etc) along with some numbers. If I compile using: gcc -noixemul -m68030 -o scale scale.c -lm the printf() works ok but the precision of the number is off. Also the atof() for example on input of the number 2 reports via printf() a value of 2.00004. If I drop the -noixemul parm, everything works OK but I'd like to not have to use the shared library and I'd also like not to have to limit my executable to the -m68030 option. Thanks, Earl aisterwi@acs.eku.edu From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 18:55:10 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91485-2>; Tue, 7 Mar 1995 18:43:24 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA07586 (5.65c8/IDA-1.4.4 for ); Tue, 7 Mar 1995 17:43:07 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA16370; Tue, 7 Mar 95 17:43:06 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503071643.AA16370@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Stack Size! To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Tue, 7 Mar 1995 17:43:06 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503071323.AA16531@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Mar 7, 95 02:23:43 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1494 > > > The reason automatic stack extenders and setting the stack size at > > startup work is that only the subroutine that changes the stack, and > > its children get to use the new stack. > Exactly, the new function gets called with a new stack. The old one is > restored upon function return. Stack extenders need to be supported by > the C lib as special care must be taken for longjmp(). Only switching > to some stack at startup (even before calling main) is easy for the > writer of the startup module. > Switching to a new stack if needed at any function entry is also relatively easy: The compiler has to insert code that checks the current value of the stackpointer against some global variable (that leaves a healthy pad, say 2k of stack) and calls a 'void extend_stack(int required_size)' function if necessary. This function then takes it's returnaddress off the stack, changes to a new stackframe and puts the address of some 'void shrink_stack(void)' before it's own returnaddress back on the new stack. This way it provides a new stack segment to it's caller. (Of course all this has to happen _before_ registers are saved on stack). After the caller has done the work it can fall through its end and automatically call 'shrink_stack' which cleans up. There are only 2 problems remaining: * Both these special functions have to be written in assembly ;-). * This doesn't help a bit against big local arrays or alloca() (alloca() could be replaced, however). Matthias From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 20:17:56 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91400-4>; Tue, 7 Mar 1995 20:09:59 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ab18577; 7 Mar 95 18:05 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA005x6; Tue, 7 Mar 95 18:03:51 GMT Date: Tue, 7 Mar 95 18:03:51 GMT Message-Id: <9503071803.AA005x5@flevel.demon.co.uk> Message-Id: <20506101.dbba0-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Help - Pipes and things Can anyone help me, ive written a program called 'ixpipepatch' which is designed to allow programs to access pipes easily for example:- FILE* han=fopen("|list #?.c ^)","r"); Opens a file handle which is connected to the standard output of the list command. FILE* han=fopen("|}sort ^ ^}filename","w"); Would generate a file handle whose output would be sorted and saved as 'filename'. I know this is messy but it works. The patch is places into the op/sys "Open" command which then runs the needed command line with the correct filenames (using PIPE:). I would now like to re-write the pipe command so it is not just Amiga only. I want to do this by writing some C routines say 'popen' which will perform the same function and so remove the OS patch. I have noticed there is a un*x style command called 'pipe' which generates 2 file handles which are connected via a pipe however this is not very useful because some commands which I wish to use in a pipe take file name arguments and don't use stdin/out. This isn't a problem with 'ixpipepatch' because it just passes PIPE:IXnnnn as the filename. Any help would be gratefully received. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 20:22:00 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91403-3>; Tue, 7 Mar 1995 20:12:09 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ad18577; 7 Mar 95 18:05 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA005ww; Tue, 7 Mar 95 14:16:45 GMT Date: Tue, 7 Mar 95 14:16:45 GMT Message-Id: <9503071416.AA005wv@flevel.demon.co.uk> Message-Id: <20502bcb.9c41-dev@flevel.demon.co.uk> In-Reply-To: <9503070901.AA15644@sunserv.IZFM.Uni-Stuttgart.DE> (from Matthias Fleischer ) (at Tue, 7 Mar 1995 10:01:15 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: fleischr@izfm.uni-stuttgart.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: libnix question! Hi Matthias, > > Hows about: Fix(Floor(x)) ??? > > > Good idea, but you'll need > > x>0?Fix(Floor(x)):Fix(Ceil(x)) > > to do it right - and that's really a lot of overhead > for this very common operator. True. > Another way would be checking SysBase for the coprocessor > flag and calculating Fix(x) directly if set. This wouldn't > be much overhead (neither with nor without coprocessor) but > I don't know how good the idea of checking this flag is :-(. I think it's perfectly ok to have such a check, isn't there an OS function to do it in any case? Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 20:22:00 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91395-2>; Tue, 7 Mar 1995 20:13:28 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ac18577; 7 Mar 95 18:05 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA005wr; Tue, 7 Mar 95 14:12:46 GMT Date: Tue, 7 Mar 95 14:12:46 GMT Message-Id: <9503071412.AA005wq@flevel.demon.co.uk> Message-Id: <20502adb.b98c2-dev@flevel.demon.co.uk> In-Reply-To: <9503071338.AA16586@inf-wiss.uni-konstanz.de> (from Joerg-Cyril Hoehle ) (at Tue, 7 Mar 95 14:38:30 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: hoehle@inf-wiss.uni-konstanz.de Cc: tsruland@immd8.informatik.uni-erlangen.de, amiga-gcc-port@nic.funet.fi Subject: Re: Stack Size! Hi Joerg-Cyril, > With such languages, it's much more fun to have automatic stack growth. I not sure how it works but Dice C does automatic stack growing if you turn it on. I not quite sure what all the fuss is about though, if you put in your shell startup "stack 256000" then you don't seem to get a problem ;-) I suppose this fits in with my earlier posting (which you will get later!) which suggests a program which is used to launch GCC compiled exes (like on the PC) which would provide MMU protection, Virtual memory and stack growing?? I suppose it could be put into the startup code instead? Would anyone like to write it this evening over a bottle of wine;-)) Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 22:12:07 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91465-4>; Tue, 7 Mar 1995 22:07:21 +0200 Received: by theseas.ntua.gr with UUCP; Tue, 7 Mar 1995 21:29:55 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06e2@kriton.UUCP>; Tue, 7 Mar 95 18:53:58 EET Date: Tue, 7 Mar 95 18:53:58 EET Message-Id: <9503071653.06e2@kriton.UUCP> In-Reply-To: <199503060949.JAA12341@colombo.telesys-innov.fr> (from Philippe BRAND ) (at Mon, 6 Mar 1995 09:49:10 +0000 (GMT)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 649 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@lists.funet.fi Subject: Re: gcc263-get-me-first-please-and-read-me.lha ;-) Hi Philippe (Philippe BRAND), in <199503060949.JAA12341@colombo.telesys-innov.fr> on Mar 6 you wrote: > Next time I'll call gcc263-readme.lha > gcc263-get-me-first-please-and-read-me.lha ;-) How about: DONT-README-ON-PAIN-OF-DEATH? Reverse psychology can work wonders some times. (Yes, I've been guilty of reading this file as a last resort, too!) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I always believe everything, except an alternate Tuesdays." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 22:13:57 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91466-1>; Tue, 7 Mar 1995 22:07:34 +0200 Received: by theseas.ntua.gr with UUCP; Tue, 7 Mar 1995 21:29:51 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06eh@kriton.UUCP>; Tue, 7 Mar 95 20:06:50 EET Date: Tue, 7 Mar 95 20:06:50 EET Message-Id: <9503071806.06eh@kriton.UUCP> In-Reply-To: <9503071451.AA15918@immd8.informatik.uni-erlangen.de> (from Tobias Ruland ) (at Tue, 7 Mar 1995 15:51:33 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1445 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: tsruland@immd8.informatik.uni-erlangen.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Stack Size! Hi Tobias (Tobias Ruland), in <9503071451.AA15918@immd8.informatik.uni-erlangen.de> on Mar 7 you wrote: > > * Automatic stack checking: > > Let the program automatically increase the stack when it becomes too small. > as joerg pointed out it is a "dont do it" to let the program itself > change it's stack "somewhere". dynamic stack growth should be supported > by OS or OS-extension. thats no thing any programmer should worry about. I think that automatic stack extension by allocating new stack frames should be part of the run-time system (as opposed to extending the current stack by mapping additional memory pages, contiguous to the current stack, to a task's address space when a page fault occurs, which is definitely a job for the operating system). Both SAS/C and DICE do this, though I don't know if they handle longjmp properly. BTW, what Joerg said was that stack extenders need special support from the run-time library, to take care of things such as longjmp. I have no idea how this could be achieved, though. :-( As a point of interest, has anyone ever used SAS's or Dice's stack extension feature? I've found that allocating a big enough stack at the beginning usually covers my needs. Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I always believe everything, except an alternate Tuesdays." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 22:13:57 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91464-3>; Tue, 7 Mar 1995 22:06:45 +0200 Received: by theseas.ntua.gr with UUCP; Tue, 7 Mar 1995 21:29:49 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06e7@kriton.UUCP>; Tue, 7 Mar 95 19:28:44 EET Date: Tue, 7 Mar 95 19:28:44 EET Message-Id: <9503071728.06e7@kriton.UUCP> In-Reply-To: <9503061133.AA14996@sunserv.IZFM.Uni-Stuttgart.DE> (from fleischr@izfm.uni-stuttgart.de (Matthias Fleischer)) (at Mon, 6 Mar 1995 12:33:24 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 547 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: fleischr@izfm.uni-stuttgart.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Libnix argument parsing weirdness > Obviously a bug in the commandline parser module nobody reported > until now :-). You can use the following bug-fix (beware of even more > bugs ;-) ). It works! Given that you've made all the other changes mentioned in the history file since v0.7 (they also seem to work, BTW), you might want to release a v0.8. Thanks, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I always believe everything, except an alternate Tuesdays." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Mar 7 23:37:08 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91477-2> convert rfc822-to-8bit; Tue, 7 Mar 1995 23:33:57 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id aa25663; 7 Mar 95 21:28 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA005yy; Tue, 7 Mar 95 18:17:03 GMT Date: Tue, 7 Mar 95 18:17:03 GMT Message-Id: <9503071817.AA005yx@flevel.demon.co.uk> Message-Id: <2050641c.2bf22-dev@flevel.demon.co.uk> In-Reply-To: (from Ruth Cook ) (at Tue, 7 Mar 1995 14:34:53 +0000 (GMT)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT From: dev@flevel.demon.co.uk To: peteric@insignia.co.uk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Amiga GCC v PC GCC Hi Ruth, > Memory protection - the 68000 doesn't have any, nor do many '020 or '030 > chips. (Mostly Amigas have the no-MMU versions). Doing a VMM without > hardware memory protection means you'd have to emulate the MMU in > software - which means emulating the whole processor. Very slow! Alot don't have an mmu but A3000/030, A3000/4000 040 and some 030 upgrade cards have mmu's. A lot of developers have an MMU because they need to run enforcer and soft kick different versions of the OS. I do find enforcer useful but it doesn't stop crashes it just lets you know when something fatal is happening ;-) Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 01:16:50 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91209-4>; Wed, 8 Mar 1995 01:10:09 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 8 Mar 95 00:09 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 8 Mar 95 00:04 MET Message-Id: Subject: many patches ? To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 8 Mar 1995 00:04:08 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 977 i followed the discussed and got the impression that some ppl would like to rewrite parts of the OS. Several ideas (like path-name-conversion) are already in ixemul. i have the feeling that ixemul is becoming some kind of 2. amigados. that takes me to the idea that we should think about replacing the amiDOS. In AmiOS >2.0 are several thing implemented that were missing from the earlyer one's like pipe's usw. but several things seem still be missing which can be added and the amiOS can fade out. fortunaly (;) i dont have time to do that but here is enought brainpower collected to discuss this seriously. walter ps: for short dont use 1000 patch, replace the whole thing. -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 04:01:05 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91210-4>; Wed, 8 Mar 1995 03:57:13 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rmBKl-0004nYC; Tue, 7 Mar 95 19:18 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: octave 1.1.1 To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Tue, 7 Mar 1995 19:18:43 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 947 I've managed to build and install a copy of octave 1.1.1 now, but when I run it all I get is: fishbait> octave octave: Error -1 fishbait> Needless to say, this is a very uninformative message about where to start looking for the problem. Is anyone interested in trying to debug this 4Mb monster? I can provide diffs against the FSF baseline code, as well as a couple of diffs against "ar" from binutils-1.8.x, that were necessary to get archives that included all the objects they were supposed to. You will also need to set your stack to 500Kb or more before compiling it. You also need about 30Mb of free disk space for the source and binaries. You may also need patches to f2c if you are running with a version other than from my FreshFish Vol 8 CD. Oh yes, I almost forgot, there are also patches to libm since octave requires both libF77/libI77 and libm, which both contain a couple of functions of the same name that clash. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 12:10:25 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91273-1>; Wed, 8 Mar 1995 12:00:58 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA26567 (5.65c-6/7.3w-FAU); Wed, 8 Mar 1995 10:58:53 +0100 Received: from faui8s1 by immd8.informatik.uni-erlangen.de; id AA00668 (5.x/7.3w-FAU); Wed, 8 Mar 1995 10:58:52 +0100 From: Tobias Ruland Message-Id: <9503080958.AA00668@immd8.informatik.uni-erlangen.de> Date: Wed, 8 Mar 1995 10:58:50 +0100 To: Walter Harms Subject: Re: many patches ? In-Reply-To: References: Cc: amiga-gcc-port@lists.funet.fi high walter Walter Harms writes: > i followed the discussed and got the impression > that some ppl would like to rewrite parts of the > OS. Several ideas (like path-name-conversion) are > already in ixemul. i have the feeling that ixemul > is becoming some kind of 2. amigados. that takes me > to the idea that we should think about replacing > the amiDOS. In AmiOS >2.0 are several thing > implemented that were missing from the earlyer one's > like pipe's usw. but several things seem still be > missing which can be added and the amiOS can fade > out. fortunaly (;) i dont have time to do that but > here is enought brainpower collected to discuss > this seriously. > > walter > > ps: for short > dont use 1000 patch, replace the whole thing. you're completely right. ive had a crazy idea in my mind for quite a long time: to create a completely new unix-like operating system including some of that cool amiga-features we all know [you wouldnt necessarily have to run X11 on such a system :-) ] maybe that could be a way to keep the amiga alive :-) NetBSD and amiga-linux CANT give me that kick :-) c u tobias From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 12:24:25 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91278-2>; Wed, 8 Mar 1995 12:15:38 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 8 Mar 95 11:13 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 8 Mar 95 11:08 MET Message-Id: Subject: mmu-example To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 8 Mar 1995 11:08:49 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 8638 this is (hopefully) an example how-to-use-your-mmu. the idea to install some memory protection is with that example a bit easier (i hope). oh, of cause its not my code it was provided as example from an german amiga-mag. walter begin 644 MMU.LHA M+&DM;&@U+08# "P) G)"(&P %FUM=2UAJKAENX.B#Y;U?].QJ^8 S)K\GY8M/0"#:NOI8 ($"! @0($ M"! @0($"#\F$FCP% @0($"! @0($"! @_17"XE=6F=:AUPSKBG7,.O+.O/.N MN=>H=>L=>PY(;CT 5FD_P'U^$Z[9;SRX\'?G\E(I>T O_>3--ANM3;ILL=2I M3GM+M:0Z;WZ"CGN\E7,=[*N2.>P/9W1SX1RV.>@/ VQSLCGT#DJ4\XY\0YI# MDICW!RL.<4<_L[$WI4HE(8HF%3XJ?F+YIHX1/]IC07J4Z)/K78'U78'_I0/(I,M-Y#:]!S22HWI.[ [1<.1HT MV^S47JTG=/V"A]-99;F,CXN9K%-5H%K[AT[0;:R^<6@J MP3\HV@:I&+?@VKS^(YZ/-O/QW'Y]ZLW)W?N<^6W2,U(::&/RB?&\7;1'H#F^ M&@_Q3P);Y4_E-4VS3&F6S4"\S[Y=_[6WX'(?C]O(FS39HOV2?CU#+M3BI!(O MQWG)<"6R?ZO^0# %+6QH-2VG!P EA( )J0B!L !IM;74M87)T:6ME;%Q- M355497-T,#,P+F%S;2;J!B-TE[&U(Y;;*&V)?2R+#_\S$D@;V:Y+#BQEYWL;;;>WC/>$9K1O\WO!0.;QHDR_8#9 C4$ACR6& MC[>#O!,(_\/]$*1+%'.)#D-=A2$\X^&U?>9^-IDA9ZOEZ^.F(. 1+O(F,*BS MPII9-'.H02?R5XH%%C22P9Q#A+J0CS1 /AY^*K!NN-,)H1'*#W0>A#%FVR1M M/((C,F4D;=$YB)A'(:]IGX,(9T"NAQ\B6P$?[G(K!)(:<2M">>IE4ZCI)="4 MH)Q#ICSB")4:04C5.1:6NH\CHC7V,=" G$J]J#S3*$1SG$NWD1R=JA9HDUZ- M$(IM&G0M<8TQ 1<5WG(OK*QA2GH3#)IDBL..&-SW[?(]Q/%Y1R0(TP@;;#ZA M!PE_GR1'FL1[?_.O0&B5/AKZ8Y%:8U1RR<-/C0/B#:)>X+"#>[I/$'.&C$$F M_:>_.V["\8WZ-@%_<(T+6^2&L1Y\'/A^5_%@NXW87QY[]W%BP?M@OFNH1+!\ M0@'C4+9D&A>'RS2 83!T=I>#:1<+"<6G5 5J@010(5>K>NHWGXR[ ./KB#N! M%W@)B[VX?CW73UA1WG<K/6T\__ /?I!2)[["KO[3W&T1)#(@2<8,VT%^#81-^T(-_9(2> M(>I/>U'/C=.__Z%UC<:8*[\LW@/01[\=(P%QC.'(N0"D"R:9@3D4=0-*$!N[ M,GU-W)N'>%0K1$;XAVJE28H"ZY^4@H6PUHC_<\D* P?6 )E.K'W"'0C$_FQR MZ5"XC4+:9P5XJ*@?8-U#0-[QI&.-@0G70UPC17+O=K*JX+ MN?GZFT-,RW1E'^KQ*K!=S"+B/,$&0H_,"K=K)A4J#8VB8U25%43T"BPOS&M& M1T&PV*-* 1]M?:Q2OE\7W)RWW504\4"9B8AKD,+N[$:9\YZ0C6 NB,4];6G, M*]+]^J>A^U;MMO**.;;M5G 5(J]+C(BJ@^GJ9#M!HF'D7'>RANVR,;NED8-% M6&70$S!]&<.NE@WCII3=XHGU]+41?]$1?J1%]I[$,VN*R^]4&K<3ID[@3Y"X M1*BLH&R0%;^&Q@+U:T*?V(4_ZU,:;A;5>SC:V,I,:E:K@O9ZD=PG_^_^9H[?Q"*4$;;0C3%UBR$/42J@Z-1^&4'S2 M,NJ["C$-6V7\1LNKET7*MW2I+$5B IL5#-?3,4##J+-1PH(O-"HXEW"5X#_: M5:XS*(HW5UB@X,@X+S)-]D9E+02MM;[*DU(-A2 %E*OT?:^ M\1#76Z8O#'P';B-T1W^ZF&UH4RSIZXLHTB@;#5UC!> XAJ@@52U)F-=^NLIV M?N4QPO5LAH)?-)W'1'":O]42^A0MRP)22I?/1,,R]K=-J_,A;34V'.MA27&E MBN8:VMA=. YWUWZU^M=^OZ&]UFTS"THF5O.TX4F3/*E0NK@[6X/ ]]MX@ZKI M]^IXSI.($!W:N:TOGM5<[+E5 0[/-735*8!VR0B2Y8_.#M'+'%I;7DF70;*% MT5]6ESV'#A=MMQ'"D3]':$CF:!";&8WN&C5=K!G%SX^^E#N:17P/H"J]9]"$ MM5Z+HF"3%&.-,GPUXZ(AN#ZQJHQR:\4:V/M/IS,P.%T-OF-&[Y8OCTI^GP9'I1[.54+J11Y MQM)2OA&Z[DQXPB;Q=X\6\;!)4/!S9%\^7 MFNW+1N$1/+S7KG(OAOE_^7FY;CSFNG'2=]KD8DO$W(><_%0^H+>HMJT^(F[% MP]2TDQ(O2<811S M=EXK7^!JEMF]'3AIV/5VAZADK<'H,N.,5'4M6&^\_4GPES =*/#@R@G1'(=M M4S[AS]0<.'(O7AGE-YCAZ+Q3'=@E9J$BUJBI239_">/M&A\6R3L$N*H2B06Y M+!'"((-9H[#!%@B*$$$>@L-@L"X M+(X>RN%' CF:PL]97[)>(YM_G M#I'GQ: TS?$\-)7T$?/ L+Q.0V_KHU$/FT;B'V7J2'7M[YG-6>M>G;LL9?#Z MR1_P(3/L8-L\@Q'W'3.0#O.=UD>'9V&8"/XA]&>!OA[6>2OZ4?U,8M?_'\R: M/BA\OGNH;^U90ZV]:,\*SUKT[<09?#Z^/]=R<7'4X*4/#3 ,5 M M;&@U+7,! !@ @ \@1"' &VUM=2UAJ8\P\-VT,T9 'GT)?&\3]C^@AF]: MQ=0<&J>KV1]H8B:P1\8&7"?:]B 7BQU"/5BUZY'PC 4'PW72/Q'7!R9_$7H[ M.:]S]7Z(TOR,/?+M,"XRB]-E:,Y#4!L$3+)'O1F=:^+FO%C[<1HU\XC#62 M4'36=(SM*P1Y^^+8:/-D3#[,K3%M@M!,.LJJ<=S#4B;,5/J?OD%HC9FJ[$K^ M<@LZY&JJP@X.3L+3GR@\7,W?8WT'7__\#1;IT7&Y--MQOBHU).]NZWO@9W!5 MJTM_2GTJ,ZK4I5H/^0 LJBUL:#4M\0$ "0# "+=4,; 6;6UU+6%R=&EK M96Q<4VEN=7-+=7)V93R; 9]B8MK&U"__=>@)8&,,3&@<]H*4HB98")1>*U:X M6\**JP\]6];?:Z]W'6]C96!S)18=@9#"PV!8&A,30+ L)01@,1BH,!*PF V_ M?^]W9PW1(TVY2*A^R7Y!?[T8'_![];^ C?B*GNDR[C_OVUN(+X[A(I*)X8BX MQ<@%H^S*H>M3WC9P7[E%XKA%]Z3E*^6NW8B0HW([CS_!NQSZB'(^@[CT::T] M>H7 %:)JL>>.%9,3*D0+%0-WS5.S1ZN@BEFK +ZSC'(N5"7-4[7 YRB+V\4X M9:G4J,;@W]0;_>XR19>-O9](E_F]=?,CR2_3T%"W8.7YBU6^[\]'R:.L<35T MO"O@G/*L&>Y]'Q;5:JE^\F"3!>DCW'VKZ<+5I^-KL=SPH?D::4W=5T9Z8S3&6QG5&:((\8S6&0671&>:,@LN64](%0_1P#KP6 MA9:-0QW8:]O=7%^D:^R%JKV S\BS]B#"L^J-&=G8GKA;*?%)L]7;D?JIPX)Z MPKQOOP<@!L8>G7KYNB-\UQP_VX88C+^LR_B3 J)XC7"G?2J>(/X:8KQO6UP! M'#.>]<.0HK+JN9^'W#-0V8 PE"UL:#4M(P0 *0) "(=4,; :;6UU+6%R M=&EK96Q<4VEN=7-+=7)V92YAQIMR76Y> /230C;J@T-@.YCRY M<3!!#*,# 49+I&<"^@Z1')WEP!'XH31N]-*Z'^Y(2$.9:[;;,MMT+HW> ZMI MN/<-P9^=?\RQ'S5#^>E6,)]^D^>3GT0[OHJF\/)^.A6LZCQHY MY_'_F'_ >3.D 1(M>+!$!JD1+J%7S:@;-5%%JCV!^!/0XW X/K9=O7GO:]9) M@[P1>/F29/P(3K+=WB!?E#"@$3/ AD#C>6=;V&D 5681&_&*686 SC9G)SW(=#YM$DIXN8KM] M]DPBH@CVBKO'D4N9[8TK4/"[R,!XM"W3ETOG0N-7H]ML&7%AC2KD-7Y14+&, M1I%+1#R$U"/TMIJ_&BM6BQ-S$[;)C!3N$$%\OW67NC2/-W0G6B"$RAC#[HQ&CH,H:(_ :)ZO_%EH*MASQ&+23 M;=XQ]_J=SZ66W_@.L=-?C$M6K_43#/'TJ36_T&IA3V_W"@OG3X\JIK)[WWRL M+TKY%PF49%3M_AU:XE^];FZ%H2+?*Q>8O(Z^[?+5Y1>,)V,ZX%W$%C M%GZEH8#[%O-CI6%]3'D?,N//I2=2@+R83[@BY5M2 T2O;&7&HP\=LP'9CNXU MG&TLH2(+$!X01X?B/@EH>==Z./O$+D.B>!ZK&M>4UF6;A)]>A=L70CY?$$H+ MKU%MF]ZHTEKLGP<2K N5HQ#2VCK$R#YK8+[A;20=4OK#-9$7>6WYH(&<9-]S M_G;'];O#H;FT3H9980%<$=4]A%Z/$#09=2R[0.. ,6B <1BX'GH=UEA!*CZ" M_:U0<2X&!PWK7Y 0@ON,V7:-=:<((X$_9("9<"SG++B>GRW9#'9@>9!B]2._ M$1H"0;-Q_$0IIX:8?H:\,:5F*.0)<:=.,SPUM,Q7SO>_)W1D09 C'[AGTGR_ M+@(X+@-F6:@'XY^/&OU(9-G.HTB4B I2$2J1IJ;-,-=\Z\VCN6\$*FV566G+ M#^22_GFU:H;GX^]MSA[Y#P*TMV*U*/U@?1I4WT.4I'SJB!M9\>D/MQ+T:9+= MZYE='X!?MF]@QO7';5QY^5!:>PO^OB@Q.W.QW%P#+MJSVX6V?V5_R M7;]K!DWL+[HNF"^\U+ K$N8GI^?PSYOAD^;TLF<-B^"LO BG0LP093;N,DYL MT0,IU-P.- D)!QU-3? &(0>'5]WM>:\;G2PNXUOW=$(O4=*T3OV MFC7X+6QH-2T+ 0 VP$ &NMQX !]M;74M87)T:6ME;%Q3:6YU@! O2<;;O]6BCY[2=[7UF72?R_[,\CG?[V>B MS]:3]C&+K_Y_4;5\T?)Z[2/4V*Z.IMV#=Y;ZZ].[AW)X?5Q?KD-YXU&+G+X^ M#BW]VD_O4P QS"UL:#4M&P$ "H" #6 D(< ;;6UU+6%R=&EK96Q<4VEN M=7-+=7)V92YI;F9O4\ [EIBMC:BOJVI8*KW+M#0Z:C0S%U"Q4.1W+$R"&T5 MAL%"Y& Q'"PD1)[!8VT%8+@4-83 4- 01@:)D*'?Z[K6X$00;8H,C@N(P<#) MV#4&Z-4/!T..<&U<']''O_NC91I/0#;OE.C5:U-1XP-.> M[R@(:;Y'LM-!'Q#),<9'[CQFURY2]&#MQ=WASD;O,/KTK6]_U(WWQ?ZZUJVL MCTB/E@[]%AH16SWD4&5=^S<6PRP&R44$O()%3Q(DL?YIG/AI/&) M*[2WJ3LD85GS'&1F4>8UXQA"C15(3;D&N,*5//0FJG.8>255(H3FV.BZ/,CL <1'VX.FZ+U<><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 12:31:14 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91349-1>; Wed, 8 Mar 1995 12:19:13 +0200 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA27516 (5.65c-6/7.3w-FAU); Wed, 8 Mar 1995 11:15:09 +0100 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id LAA01714 (8.6.10/7.4a-FAU);; Wed, 8 Mar 1995 11:14:59 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA17827; Wed, 8 Mar 1995 11:14:57 +0100 Date: Wed, 8 Mar 1995 11:14:57 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9503081014.AA17827@pctc.chemie.uni-erlangen.de> To: dev@flevel.demon.co.uk Cc: fleischr@izfm.uni-stuttgart.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <9503071416.AA005wv@flevel.demon.co.uk> (dev@flevel.demon.co.uk) Subject: Re: libnix question! Hi, I want to give some info about the Fix() problem, too. I only can speak about 68000 and 68030, but some years ago (the time I baught my 68030) I read in a book (an Amiga book or the SASC manual) that there exists a flag or variable which says the 68030 how to do rounding. Maybe this will give some additional help. Servus -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 12:46:13 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91354-3>; Wed, 8 Mar 1995 12:33:49 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA28644 (5.65c8/IDA-1.4.4 for ); Wed, 8 Mar 1995 11:33:36 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA16901; Wed, 8 Mar 95 11:33:36 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503081033.AA16901@sunserv.IZFM.Uni-Stuttgart.DE> Subject: more about stack extension To: amiga-gcc-port@nic.funet.fi Date: Wed, 8 Mar 1995 11:33:36 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 4528 Hello everybody, here is some little concept I want to add to libnix to build an automatic stack extension feature (if nobody has any objections). If you find any big design problems please tell me ;-). Automatic stack checking and extension with compiler support ------------------------------------------------------------ 1. Why the compiler? Most systems build stack extension directly into the kernel, but you'll need a MMU for this - and not all Amigas have such a Hardware add-on. Some people may argue that software developers tend to have such a thing, but then: Maybe they want to develop software for people that don't ;-). Integrating compiler support to extend the stack isn't that much strange after all - even some Un*xs (HP/UX to name an example) do it and live well with it. Most other amiga compilers do it, too. 2. How? 2.1 Stack extension: To automatically expand the stack if needed you have to check everytime you need more of it, expanding it if necessary. If you don't need it anymore you will have to clean up to be able to fall back to the old stack. The most natural place to check for this is at the start of every function. Therefore I want to invent a function void __stack_extend_size(unsigned long needed_size); that checks if there is enough stack space left, allocating a new stack segment if necessary. If the stack gets actually extended this function places the address of some cleanup-routine on top of the new stackframe. The caller then just needs to fall through its end to clean up. Therefore the compiler doesn't need to emit cleanup code - it just needs to add something like movel #needed_size,sp@- jbsr ___stack_extend_size addqw #4,sp directly after the function label - and the __stack_extend_size function can do the rest. Unfortunately calling a function at every function entry may make up a big performance problem. Therefore a second concept for functions that need only little stack my be appropriate. All you need is some global variable to check against the stackpointer to determine if there is enough stack space left (lets say 2k) for small needs. The code the compiler has to emit is very similar to the previous one: cmpl sp,___top_of_stackframe bhi l jbsr ___stack_extend l: Which leads to void *__top_of_stackframe; void __stackextend(void); Some functions may want to use alloca() or variable sized arrays. This needs another concept with explicit cleanup. If the compiler needs more stack in the middle of a function it may emit (like previously): movel #needed_size,sp@- jbsr ___stack_extend_dynamic addql #4,sp And get a new stackframe with enough space left. But when it doesn't need the space any more and wants to decrease the stackpointer above the bottom of the stackframe it runs into problems. Therefore it's necessary to emit a jbsr ___stack_shrink_dynamic instruction which restores the stackpointer to the previous state if necessary. You need only these two functions to do this magic: void __stack_extend_dynamic(unsigned long size); void __stack_shrink_dynamic(void); 2.2 Stack checking Automatic stack extension is a nice feature but needs a lot of CPU time if the stack is very dynamic. Often it's sufficient to just tell the user that there is not enough space to run the program and exit. All you need are two functions void __stack_check_size(unsigned long needed_size); void __stack_check(void); which work exactly like the two previous ones except that __stack_check() doesn't return at all. And you don't need a shrink function since you never increase the stack. Both concepts may even live in peace together since there are no collisions between the two. 3. Summarization You'll need 7 things: /* Stack extension at function entry */ void __stack_extend_size(unsigned long needed_size); void *__top_of_stackframe; void __stack_extend(void); /* Dynamically extend stack in the middle of functions */ void __stack_extend_dynamic(unsigned long needed_size); void __stack_shrink_dynamic(void); /* Stack checking at any level */ void __stack_check_size(unsigned long needed_size); void __stack_check(void); 4. Conclusion Complete stack checking and extension is possible if there is enough compiler support. A stack concept similar to SAS or Dice is even easier: You only have to emit code at one special point: At function entry. BTW: Philippe, is it possible to add a -stack_check and -stack_extend option at this simple level. Is it possible for alloca(), etc too? So: Should I do it? Matthias From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 12:54:46 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91350-4>; Wed, 8 Mar 1995 12:41:17 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id aa08152; 8 Mar 95 10:32 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA0065y; Wed, 8 Mar 95 09:23:13 GMT Date: Wed, 8 Mar 95 09:23:13 GMT Message-Id: <9503080923.AA0065x@flevel.demon.co.uk> Message-Id: <20513876.5cc61-dev@flevel.demon.co.uk> In-Reply-To: (from Fred Fish ) (at Tue, 7 Mar 1995 19:18:43 -0700 (MST)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: fnf@amigalib.com Cc: amiga-gcc-port@nic.funet.fi Subject: Re: octave 1.1.1 Hi Fred, > I've managed to build and install a copy of octave 1.1.1 now, but when > I run it all I get is: > > fishbait> octave > octave: Error -1 > fishbait> I got the same thing, my executable was just over 16MB, I left the debug info in :-( I though at the time it might be due to memory. I had to run VMM to execute the program. Maybe I'll start looking in the source code to find out what error -1 is. Did you use -m68030 -m68881? I didn't but I'm going to try again with these options enabled. > Needless to say, this is a very uninformative message about where to > start looking for the problem. Is anyone interested in trying to > debug this 4Mb monster? I can provide diffs against the FSF baseline What did you alter? I just did a small change to stop octave trying to use file name completion (csh feature I think). > code, as well as a couple of diffs against "ar" from binutils-1.8.x, > that were necessary to get archives that included all the objects they > were supposed to. You will also need to set your stack to 500Kb or Strange, I didn't notice this problem. > more before compiling it. You also need about 30Mb of free disk space > for the source and binaries. You may also need patches to f2c if you > are running with a version other than from my FreshFish Vol 8 CD. There is a more upto-date version on Aminet. It's labeled as an SASC version but it works with the older GCC link library. > Oh yes, I almost forgot, there are also patches to libm since octave > requires both libF77/libI77 and libm, which both contain a couple of > functions of the same name that clash. I not sure if this is the correct way or not but I just removed the duplicate functions from a backup of libF77/libI77 and it seemed to compile. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 13:02:53 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91352-1>; Wed, 8 Mar 1995 12:47:14 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ac08152; 8 Mar 95 10:32 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA00668; Wed, 8 Mar 95 09:27:42 GMT Date: Wed, 8 Mar 95 09:27:42 GMT Message-Id: <9503080927.AA00667@flevel.demon.co.uk> Message-Id: <20513986.3a980-dev@flevel.demon.co.uk> In-Reply-To: (from Walter Harms ) (at Wed, 8 Mar 1995 00:05:52 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: Walter.Harms@arbi.informatik.uni-oldenburg.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Help - Pipes and things Hi Walter, > > I would now like to re-write the pipe command so it is not just Amiga > > only. I want to do this by writing some C routines say 'popen' which will > > perform the same function and so remove the OS patch. > > > > > Any help would be gratefully received. > > > i have somewhere a prg floating around that offers > popen(),... can that be a help ? Is it the same as the un*x popen which generates file handles instead of file names? Cheers, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 13:09:13 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91357-2>; Wed, 8 Mar 1995 12:53:11 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA29788 (5.65c-6/7.3w-FAU); Wed, 8 Mar 1995 11:52:56 +0100 Received: from faui8s1 by immd8.informatik.uni-erlangen.de; id AA01888 (5.x/7.3w-FAU); Wed, 8 Mar 1995 11:52:53 +0100 From: Tobias Ruland Message-Id: <9503081052.AA01888@immd8.informatik.uni-erlangen.de> Date: Wed, 8 Mar 1995 11:52:51 +0100 To: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Cc: dev@flevel.demon.co.uk, fleischr@izfm.uni-stuttgart.de, amiga-gcc-port@nic.funet.fi Subject: Re: libnix question! In-Reply-To: <9503081014.AA17827@pctc.chemie.uni-erlangen.de> References: <9503071416.AA005wv@flevel.demon.co.uk> <9503081014.AA17827@pctc.chemie.uni-erlangen.de> high Thomas Walter writes: > I want to give some info about the Fix() problem, too. > > I only can speak about 68000 and 68030, but some years ago (the time I > baught my 68030) I read in a book (an Amiga book or the SASC manual) > that there exists a flag or variable which says the 68030 how to do rounding. as far as i remember there's a status bit in 68881/68882. i can study my motorola 68881/68882 manual if someone wants me to. c u tobias From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 13:31:39 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <91164-2>; Wed, 8 Mar 1995 13:22:42 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA07727; Wed, 8 Mar 1995 11:17:31 GMT From: Lars Hecking Message-Id: <199503081119.LAA06144@mostar.nmrc.ucc.ie> Subject: Re: many patches? To: tsruland@immd8.informatik.uni-erlangen.de (Tobias Ruland), Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Wed, 8 Mar 1995 11:19:54 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1947 Tobias Ruland wrote: > high walter ;-) > Walter Harms writes: > > i followed the discussed and got the impression > > that some ppl would like to rewrite parts of the > > OS. Several ideas (like path-name-conversion) are > > already in ixemul. i have the feeling that ixemul > > is becoming some kind of 2. amigados. that takes me > > to the idea that we should think about replacing > > the amiDOS. In AmiOS >2.0 are several thing > > implemented that were missing from the earlyer one's > > like pipe's usw. but several things seem still be > > missing which can be added and the amiOS can fade > > out. fortunaly (;) i dont have time to do that but > > here is enought brainpower collected to discuss > > this seriously. > > > > walter > > > > ps: for short > > dont use 1000 patch, replace the whole thing. > > you're completely right. ive had a crazy idea in my mind for > quite a long time: to create a completely new unix-like operating > system including some of that cool amiga-features we all know > [you wouldnt necessarily have to run X11 on such a system :-) ] > maybe that could be a way to keep the amiga alive :-) NetBSD and > amiga-linux CANT give me that kick :-) About three weeks ago, a mailing list for the "Amiga OS replacement project" has been installed. Send 'subsribe aos' (empty Subject: line) to majordomo@mail.warped.com. The list has been virtually dead since :(, but maybe it's only a matter of getting started ... Btw, if you have the occasional look into comp.unix.amiga, you might find that there's slightly more to Amiga Unix than just Amix, Linux and NetBSD ... Slan leat, Lars -- Lars Hecking | Yes I know my enemies lhecking@nmrc.ucc.ie | They're the teachers who taught me to fight me NMRC | Compromise, conformity, assimilation, submission Cork, Ireland | Ignorance, hypocrisy, brutality, the elite | ALL OF WHICH ARE AMERICAN DREAMS From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 14:11:52 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91353-4>; Wed, 8 Mar 1995 13:59:34 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA11518; Wed, 8 Mar 95 13:54:42 +0200 Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA08193; Wed, 8 Mar 95 13:59:50 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9503081159.AA08193@hpcl.cti.gr> Subject: Re: libnix question! To: amiga-gcc-port@lists.funet.fi (gcc) Date: Wed, 8 Mar 1995 13:59:49 +0200 (EET) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9503081014.AA17827@pctc.chemie.uni-erlangen.de> from "Thomas Walter" at Mar 8, 95 11:14:57 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 520 > I only can speak about 68000 and 68030, but some years ago (the time I > baught my 68030) I read in a book (an Amiga book or the SASC manual) > that there exists a flag or variable which says the 68030 how to do rounding. If you have SAS/C, have a look at the "source" directory. There's an fp initialization file that does this sort of thing, documenting (I think) the various options. I'll have a look at it at home tonight. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 14:37:45 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91361-4>; Wed, 8 Mar 1995 14:29:37 +0200 Received: from eagle.cms.dmu.ac.uk (se1dp@eagle.cms.dmu.ac.uk [146.227.102.27]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id MAA15456 for ; Wed, 8 Mar 1995 12:30:50 GMT Received: by eagle.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA016365735; Wed, 8 Mar 1995 12:28:55 GMT Date: Wed, 8 Mar 1995 12:28:54 +0000 (GMT) From: Derek Piper X-Sender: se1dp@eagle.cms.dmu.ac.uk To: GCC Mail List Subject: System friendly waits Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, What is the nicest, ie. most system friendly way, to make a program wait idle? I need such a 'multitasking wait' for the main loop of a program and I wondered exactly how to go about it. If anybody has a good idea on it then I would be most interested. Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Slurm, n.: | | The slime that accumulates on the underside of a soap bar when | | it sits in the dish too long. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 15:05:53 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91268-2>; Wed, 8 Mar 1995 14:57:49 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA04722; Wed, 8 Mar 1995 12:57:34 GMT From: Peter Ivimey-Cook Message-Id: <6869.199503081255@creda.isltd.insignia.com> Subject: Re: System friendly waits To: se1dp@dmu.ac.uk (Derek Piper) Date: Wed, 08 Mar 1995 12:55:22 GMT Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: ; from "Derek Piper" at Mar 8, 95 12:28 (noon) X-Mailer: elm X-Mailer: Elm [revision: 109.14] Derek, > What is the nicest, ie. most system friendly way, to make a > program wait idle? I need such a 'multitasking wait' for the main loop of a > program and I wondered exactly how to go about it. If anybody has a good > idea on it then I would be most interested. > I can think of two, depending on what you want to wake the program up again: 1. If the period is fixed - i.e. just poll something every second - try using the Dos function Delay(). The parameter is the number of clock ticks to wait. see the definition of CLK_TICK in dos.h? for how many ticks per second. Note: Don't use Delay when Wait will serve. 2. If you want to wait for "something" use Wait() or WaitPort(). Wait expects a signal mask of signals which will cause the Wait to terminate. One should almost certainly be SIGBREAKF_CTRLC - the control-C signal. Use AllocSignal() or reas the signal bit from a message port (1 << mp_sigBit) and or ( | ) all possibles together. WaitPort is a convenience function which, basically, does: Wait(1L << port->mp_SigBit); i.e. wait on a specific message port. Lastly, there are two other methods: set up the timer.device (the mechanism Delay uses, but more flexible if you use it yourself) or count IntuiTicks on an Intuition Window port. Setting up timer.device isn't very hard, but you do need the docs. Counting Intuiticks is easy, and has the benefit you are still alive if Intuition wants to send other messages (e.g. a refresh). But of course it requires an open window. Regards, Peter -- Peter Ivimey-Cook Mail Id: peteric@isltd.insignia.com Insignia Solutions, Kingsmead Business Park, London Road, High Wycombe, Buckinghamshire. Telephone: +44-1494-459426 HP11 1JU, U.K. Fax: +44-1494-459720 From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 15:22:13 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <91351-4>; Wed, 8 Mar 1995 15:13:14 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.6.9/8.6.9) id OAA15929; Wed, 8 Mar 1995 14:12:27 +0100 Date: Wed, 8 Mar 1995 14:12:27 +0100 From: Ignatios Souvatzis Message-Id: <199503081312.OAA15929@theory.cs.uni-bonn.de> To: se1dp@dmu.ac.uk CC: amiga-gcc-port@nic.funet.fi In-reply-to: Derek Piper's message of Wed, 8 Mar 1995 12:28:54 +0000 (GMT) Subject: System friendly waits X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a; Wed, 8 Mar 1995 16:07:46 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id aa13168; 8 Mar 95 13:52 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA0066s; Wed, 8 Mar 95 10:49:49 GMT Date: Wed, 8 Mar 95 10:49:49 GMT Message-Id: <9503081049.AA0066r@flevel.demon.co.uk> Message-Id: <20514ccb.57e41-dev@flevel.demon.co.uk> In-Reply-To: (from Walter Harms ) (at Wed, 8 Mar 1995 11:08:49 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: Walter.Harms@arbi.informatik.uni-oldenburg.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: mmu-example Hi Walter, > > this is (hopefully) an example how-to-use-your-mmu. > the idea to install some memory protection is with that > example a bit easier (i hope). oh, of cause its not my > code it was provided as example from an german amiga-mag. Great, the only problem is I don't speak german. Ive tried running the executable (On a A3000/30/882/MMU) and it just locks up the system :-( If anyone could quickly translate the text (It's only short) I would be grateful. Thanks, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 16:37:46 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91360-2>; Wed, 8 Mar 1995 16:24:55 +0200 Received: by ceylon.informatik.uni-rostock.de id PAA13597; Wed, 8 Mar 1995 15:24:33 +0100 Received: by honshu.informatik.uni-rostock.de id PAA08177; Wed, 8 Mar 1995 15:24:33 +0100 From: Gunther Nikl Message-Id: <199503081424.PAA08177@honshu.informatik.uni-rostock.de> Subject: ar question To: amiga-gcc-port@nic.funet.fi Date: Wed, 8 Mar 1995 15:24:32 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 642 Hello! I have a question concerning "ar". I do not use the gnu version of "ar" but a older (bsd?) version from gcc 2.3.3. I decided not to use gnu-ar because it truncates filenames longer than 16 characters but my old ar does not! I find it much more useful to have the full names instead of truncated ones. Also I only need the a.out format. Then I looked into and found an interesting #define for an "extended" header in link-libraries that my ar can generate. And even ld must be able to understand it since I had no trouble so far with my link-libraries. So why does gnu-ar not support an extended header? Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 16:51:28 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91363-1>; Wed, 8 Mar 1995 16:41:00 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA04357 (5.65c8/IDA-1.4.4 for ); Wed, 8 Mar 1995 15:40:47 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA17396; Wed, 8 Mar 95 15:40:47 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503081440.AA17396@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: more about stack extension To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Wed, 8 Mar 1995 15:40:46 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503081325.AA14759@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Mar 8, 95 02:25:35 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1417 > > I would *highly* appreciate, if you could add such a thing to > gcc. > Oh, I can only add support for it to libnix and possibly provide some patches for basic parts of changes to the compiler. I'm no expert for gcc internals. > > However, I don't see any reason for what you call extending the stack > in the middle of the function or "at any level". (What do you mean by > that?) As far as I know, stack is *only* allocated, if a new function > is entered. > Oh, I give you 3 reasons ;-): void function(int f,int a,int b) { char *c; if(f) { char d[100]; /* Reason 1: Needs more stack if and only if f is set */ char e[a]; /* Reason 2: Don't know how much stack is needed at function entry */ c=alloca(b); /* Reason 3: alloca is generated inline (no function call) */ /* do something */ }/* At this point c,d and e are freed */ /* do something */ } > > dynamic stack checking. Thus, if you could the first part, this would > be completely sufficient, IMO, and less dangerous. (There were mails > within the last days which explained why such a thing would be > dangerous.) > The first part would be sufficient for a lot of programs but sure not for gcc itself. The second thing wouldn't be dangerous if implemented right (since it works hidden from the programmer) but very hard to implement. At least not more dangerous than number one :-). Matthias From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 17:03:14 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <91365-3>; Wed, 8 Mar 1995 16:49:54 +0200 Received: by RT66.com (4.1/SMI-4.1) id AA25620; Wed, 8 Mar 95 07:50:50 MST Date: Wed, 8 Mar 1995 07:50:48 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: Tobias Ruland Cc: Thomas Walter , dev@flevel.demon.co.uk, fleischr@izfm.uni-stuttgart.de, amiga-gcc-port@nic.funet.fi Subject: Re: libnix question! In-Reply-To: <9503081052.AA01888@immd8.informatik.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 8 Mar 1995, Tobias Ruland wrote: > high > > Thomas Walter writes: > > I want to give some info about the Fix() problem, too. > > > > I only can speak about 68000 and 68030, but some years ago (the time I > > baught my 68030) I read in a book (an Amiga book or the SASC manual) > > that there exists a flag or variable which says the 68030 how to do rounding. > > as far as i remember there's a status bit in 68881/68882. i can study > my motorola 68881/68882 manual if someone wants me to. I went ahead and looked it up. The rounding done in the '881/882 is done to control the accumulation of error in floating point calculations. The method of rounding can be controled by setting the four most significant bits in the mode control byte. This, however, would not solve the problem of Fix(). Paul Ney From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 17:11:38 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91367-1>; Wed, 8 Mar 1995 17:00:59 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rmNXj-0004nYC; Wed, 8 Mar 95 08:20 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ar question To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Wed, 8 Mar 1995 08:20:54 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199503081424.PAA08177@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Mar 8, 95 03:24:32 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1794 > I have a question concerning "ar". I do not use the gnu version of "ar" > but a older (bsd?) version from gcc 2.3.3. I decided not to use gnu-ar > because it truncates filenames longer than 16 characters but my old ar > does not! I find it much more useful to have the full names instead of > truncated ones. Perhaps this explains the problem I had recently when I built octave. The makefiles for octave want to make a library from sources in several subdirectories, so they go to each subdir, do a compile and then when done, build the archive from the upper level directory, so that the names of the files passed to ar contain full pathnames, which GNU ar then wants to use as the name as the file in the archive, like: foo/blah.o bar/bell.o etc This caused several collisions when truncating to a fixed length, and then somewhere along the line, the duplicate files were tossed out rather than just building an archive with two files that had the same truncated name. I solved the problem by patching the ar source so that if truncation occurs, it first occurs by stripping off the leading pathname components. This doesn't help though if the basename itself is too long, and is suboptimal in other obvious ways. > Also I only need the a.out format. Then I looked into > and found an interesting #define for an "extended" header in > link-libraries that my ar can generate. And even ld must be able to > understand it since I had no trouble so far with my link-libraries. > So why does gnu-ar not support an extended header? The binutils 1.8.x version does not appear to support this, though the latest bfd binutils does I think. Perhaps until I switch to the new bfd binutils I should look at snarfing the ar source from BSD 4.4 lite and using that... -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 17:32:19 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91370-3>; Wed, 8 Mar 1995 17:28:37 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <157-2>; Wed, 8 Mar 1995 16:24:31 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209155-2>; Wed, 8 Mar 1995 16:24:26 +0100 Subject: Re: Amiga GCC v PC GCC From: Christian Stieber To: dev@flevel.demon.co.uk Date: Wed, 8 Mar 1995 16:24:11 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <204fef12.e09c2-dev@flevel.demon.co.uk> from "dev@flevel.demon.co.uk" at Mar 7, 95 09:57:51 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1264 Message-Id: <95Mar8.162426+0100mesz.209155-2+1736@hphalle0.informatik.tu-muenchen.de> > It is hell trying to compile un*x style programs on the PC (No multitasking > ,nasty msdos,8 char files names, no decent OS. ...). I'd much rather use an > Amiga but is there any chance of a program like 'go32' for the Amiga?? This is difficult. I once wrote a such a beast for AmigaOS --- an "unix" kernel which gave each program its own address space, full memory protection and virtual memory, just like Unix does. You could, however, only use Unix programs with that, since the AmigaOS works by passing pointers around and writing/reading memory that another process "owns". Basically, AmigaOS needs all available RAM to be fully "shared", which means Amiga programs couldn't use my kernel. Therefore, there is *no* chance for an Amiga-go32, IMHO. Christian P.S.: don't ask me for the kernel. I didn't have a backup when I lost parts of my HD... I'll probably redo it at some time, though :( -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP key: finger stieber@ftp.leo.org -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 19:00:11 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91371-1>; Wed, 8 Mar 1995 18:55:38 +0200 Received: by theseas.ntua.gr with UUCP; Wed, 8 Mar 1995 18:56:20 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06f2@kriton.UUCP>; Tue, 7 Mar 95 21:55:38 EET Date: Tue, 7 Mar 95 21:55:38 EET Message-Id: <9503071955.06f2@kriton.UUCP> In-Reply-To: <9503071803.AA005x5@flevel.demon.co.uk> (from dev@flevel.demon.co.uk) (at Tue, 7 Mar 95 18:03:51 GMT) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1093 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: dev@flevel.demon.co.uk Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Help - Pipes and things Hi dev (dev), in <9503071803.AA005x5@flevel.demon.co.uk> on Mar 7 you wrote: > Can anyone help me, ive written a program called 'ixpipepatch' which is > designed to allow programs to access pipes easily for example:- > > FILE* han=fopen("|list #?.c ^)","r"); . . . > only. I want to do this by writing some C routines say 'popen' which will > perform the same function and so remove the OS patch. Um, isn't this exactly the description of the UNIX function popen()? Ixemul.library already has such a function, but I'm not sure it works, especially with non-ixemul programs. I have a version of popen() that uses intermediate files, adapted from a subroutine that came with gawk, originally intended for the PC. The usual Copyleft notice is absent, so it's quite likely that this subroutine is PD. If anyone's interested, I could post it to the list. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Life is a hereditary disease, sexually transmitted and invariably fatal." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 19:36:03 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91366-2>; Wed, 8 Mar 1995 19:32:19 +0200 Received: by theseas.ntua.gr with UUCP; Wed, 8 Mar 1995 19:34:08 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06g5@kriton.UUCP>; Wed, 8 Mar 95 19:17:12 EET Date: Wed, 8 Mar 95 19:17:12 EET Message-Id: <9503081717.06g5@kriton.UUCP> In-Reply-To: <9503081159.AA08193@hpcl.cti.gr> (from kyrimis@hpcl.cti.gr (Kriton Kyrimis)) (at Wed, 8 Mar 1995 13:59:49 +0200 (EET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1107 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Re: libnix question! In <9503081159.AA08193@hpcl.cti.gr> on Mar 8 I wrote: > If you have SAS/C, have a look at the "source" directory. There's an fp > initialization file that does this sort of thing, documenting (I think) the > various options. > > I'll have a look at it at home tonight. The file was _FPINIT.C, and the initialization consists of doing a: fmovel #0,fpcr if the 68881 flag is set in SysBase->AttnFlags. A bit more checking showed that fpcr is 0 for ixemul programs and 0x90 for libnix programs. I'm afraid I don't know what these values mean, but I do know that the following program: #include main() { printf("%f\n", 1.0); asm("fmovel #0,fpcr"); printf("%f\n", 1.0); return 0; } on my 68040 prints: 1.000004 1.00001+ Both numbers are not quite correct, especially the second one. When linked with ixemul, the program prints 1.000000 in both cases. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "One small step for Mankind, one great leap, or words to that effect." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 21:31:50 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91387-3> convert rfc822-to-8bit; Wed, 8 Mar 1995 21:29:20 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ab21346; 8 Mar 95 19:22 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA0069z; Wed, 8 Mar 95 14:30:21 GMT Date: Wed, 8 Mar 95 14:30:21 GMT Message-Id: <9503081430.AA0069y@flevel.demon.co.uk> Message-Id: <2051807a.ea602-dev@flevel.demon.co.uk> In-Reply-To: (from Derek Piper ) (at Wed, 8 Mar 1995 12:28:54 +0000 (GMT)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT From: dev@flevel.demon.co.uk To: se1dp@dmu.ac.uk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: System friendly waits Hi Derek, > What is the nicest, ie. most system friendly way, to make a > program wait idle? I need such a 'multitasking wait' for the main > loop of a Wait for what? > program and I wondered exactly how to go about it. If anybody has a good > idea on it then I would be most interested. You can use: Delay(ticks); // Ticks=1/50th of a second Wait(signals); // signals is the sig bits to wait for. This is // most common. Wait(1L<UserPort->mp_sigbit); // Waits for an intution signal on your window. // For example a gadget down or a key. Wait(0L); // Waits forever :-( (At least until a reboot!) WaitTOF(); // Waits until the next Vbl WaitBOVP(vp); // Waits until the bottom of a view port WaitPort(port); // Waits for a message port WaitBlit(); // Waits for the blitter to finish. You can also do: Delay(0L); // Causes a task switch but doesn't delay // any longer. system("wait until 12:15"); // A QDS to waiting a long time period You can also open the timer.device and use that. This is more tricky but also more flexible and accurate. You can wait for an IO operation. I hope that helps. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 21:38:44 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91372-2>; Wed, 8 Mar 1995 21:36:28 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA07363; Wed, 8 Mar 1995 19:35:49 GMT Date: Wed, 8 Mar 1995 19:33:32 +0000 (GMT) From: Peter Ivimey-Cook To: dev@flevel.demon.co.uk Cc: se1dp@dmu.ac.uk, amiga-gcc-port@nic.funet.fi Subject: Re: System friendly waits In-Reply-To: <9503081430.AA0069y@flevel.demon.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 8 Mar 1995 dev@flevel.demon.co.uk wrote: > You can also do: > > Delay(0L); // Causes a task switch but doesn't delay > // any longer. > Careful with this. There was a bug in 1.1/1.2/1.3 dos.library which meant that this failed - I think it waited forever or something like that. Of course if you program already requires 2.04 there's no problem. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Wed Mar 8 21:40:51 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91373-4>; Wed, 8 Mar 1995 21:38:39 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <150-3>; Wed, 8 Mar 1995 20:37:22 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209155-2>; Wed, 8 Mar 1995 20:37:18 +0100 Subject: Re: System friendly waits From: Christian Stieber To: dev@flevel.demon.co.uk Date: Wed, 8 Mar 1995 20:37:15 +0100 (MEZ) Cc: se1dp@dmu.ac.uk, amiga-gcc-port@nic.funet.fi In-Reply-To: <2051807a.ea602-dev@flevel.demon.co.uk> from "dev@flevel.demon.co.uk" at Mar 8, 95 02:30:21 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 479 Message-Id: <95Mar8.203718+0100mesz.209155-2+1786@hphalle0.informatik.tu-muenchen.de> > WaitBOVP(vp); // Waits until the bottom of a view port That one should be avoided. It busy-waits :( Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP key: finger stieber@ftp.leo.org -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Thu Mar 9 10:15:45 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91205-1>; Thu, 9 Mar 1995 10:11:20 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA17949; Thu, 9 Mar 95 10:06:38 +0200 Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA11225; Thu, 9 Mar 95 10:11:51 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9503090811.AA11225@hpcl.cti.gr> Subject: Re: System friendly waits To: peteric@isltd.insignia.com (Peter Ivimey-Cook) Date: Thu, 9 Mar 1995 10:11:50 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: from "Peter Ivimey-Cook" at Mar 8, 95 07:33:32 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 395 > > Delay(0L); // Causes a task switch but doesn't delay > > // any longer. > > Careful with this. There was a bug in 1.1/1.2/1.3 dos.library which > meant that this failed - I think it waited forever or something like that. Even worse, it used to trash track 40 (the root) of FD0: ! -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Thu Mar 9 12:38:53 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <91216-1>; Thu, 9 Mar 1995 12:34:05 +0200 Received: from noc.BelWue.DE by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HNXFP14CW00015W2@FIPORT.FUNET.FI>; Thu, 09 Mar 1995 10:13:26 +0200 (EET) Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA24823 (5.65c8/IDA-1.4.4 for ); Thu, 9 Mar 1995 11:17:18 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA18104; Thu, 9 Mar 95 11:17:18 +0100 Date: Thu, 09 Mar 1995 11:17:18 +0100 (MET) From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Subject: Re: more about stack extension In-reply-to: <9503081636.AA16968@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Mar 8, 95 05:36:23 pm To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Cc: amiga-gcc-port@nic.funet.fi Message-id: <9503091017.AA18104@sunserv.IZFM.Uni-Stuttgart.DE> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL23] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 8bit Content-length: 2622 > > > Oh, I can only add support for it to libnix and possibly provide > > some patches for basic parts of changes to the compiler. I'm no > > expert for gcc internals. > Why? If I understood you right, it is the task of the compiler to > generate code, that upon function entry calls a certain funtion. This > could, for example, well be copied into a separate library. > And that's exactly the point. I can write this function and I can write the simple patch for the compiler to generate the code at function entry. I'm not able to write the compiler patch for alloca(). > > > char d[100]; /* Reason 1: Needs more stack if and only if f is set */ > Aztec-C and Dice (which are the only ones I ever looked at the > assembler output) would allocate the space for this variable upon > function entry. (Which is, IMO, the best solution.) What does gcc? > Hmm. It's always the same if you don't check things out: gcc does that, too (good news, OMI) ;-). > > > char e[a]; /* Reason 2: Don't know how much stack is needed at > > function entry */ > Huuuh, is this possible? :-) I admit, that this is surprising. > Of course it is ;-). It's an ANSI extension of gcc and means asking for trouble if you want to code stack extension. > > > c=alloca(b); /* Reason 3: alloca is generated inline (no function call) */ > Hmmm, silly question: How is alloca solved internally? > Silly answer: Exactly like variable sized arrays (2). The stack is memorized (to restore it later), lowered by (long word aligned) b and provided as result. After the lifetime of c has expired the memorized stack is restored to the previous state. The big problem with this is that gcc uses alloca() a lot internally (otherwise you could just decide to drop it and variable sized arrays). > > What's dangerous with number one? > Number one is dangerous as soon as the user starts doing some stack magic himself. BTW: I already changed part of my interface (simple performance reasons): at function entry gcc has to insert something like: movel #stack_needed,d0 jbsr ____stack_extend_size instead. This spares 2 bytes at every function entry and some more CPU cycles. The first few instructions of this function are: ___stack_extend_size: movel sp,d1 subl d0,d1 cmpl ___bottom_of_stackframe,d1 bcs extend rts ___stack_extend: clrl d0 extend: | do my magic: needs the required stacksize in d0 | and the returnaddress on the top of stack Which I hope is very efficient. If anybody can squeeze some more cycles out of it then please tell me - it'll be worth it ;-). Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Mar 9 15:07:09 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <91211-4>; Thu, 9 Mar 1995 15:04:08 +0200 Received: from faui45.informatik.uni-erlangen.de by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HNXKGKNYEO000XMF@FIPORT.FUNET.FI>; Thu, 09 Mar 1995 12:29:23 +0200 (EET) Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA15837 (5.65c-6/7.3w-FAU); Thu, 9 Mar 1995 13:22:35 +0100 Received: from faui8s1 by immd8.informatik.uni-erlangen.de; id AA26545 (5.x/7.3w-FAU); Thu, 9 Mar 1995 13:22:34 +0100 Date: Thu, 09 Mar 1995 13:22:30 +0100 From: Tobias Ruland Subject: Dynamic Stack To: amiga-gcc-port@FIPORT.FUNET.FI Message-id: <9503091222.AA26545@immd8.informatik.uni-erlangen.de> Content-transfer-encoding: 7BIT re all i had a mail exchange with Martin Apel, author of VMM. he says: "dont worry about dynamic stack growing. use my vmm library, allocate a huge virtual stack via VMM.library and be happy" :-) IMHO that doesnt solve the original problem that you can never know how much stack space your program really needs. must i send my amiga to hell, buy a PC and use linux??? or are we going to create a new cool OS? :-) so long... tobias From amiga-gcc-port-owner@nic.funet.fi Thu Mar 9 15:08:51 1995 Received: from dfunms.rus.uni-stuttgart.de ([129.69.1.162]) by nic.funet.fi with SMTP id <91368-4>; Thu, 9 Mar 1995 15:07:55 +0200 Received: from ifr1.luftfahrt.uni-stuttgart.de by dfunms.rus.uni-stuttgart.de with SMTP id AA25611 (5.65c8/DFUE-M1.0 for ); Thu, 9 Mar 1995 14:07:45 +0100 Received: from ifr10 by ifr1.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-1.0NeXT+) id AA10479; Thu, 9 Mar 95 14:07:44 +0100 Message-Id: <9503091307.AA10479@ifr1.Luftfahrt.Uni-Stuttgart.DE> Received: by ifr10.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-S1.0NeXT+) id AA10673; Thu, 9 Mar 95 14:07:41 +0100 Date: Thu, 9 Mar 95 14:07:41 +0100 From: raimund@ifr.luftfahrt.uni-stuttgart.de Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: amiga-gcc-port@nic.funet.fi Subject: strip ? Hi, is there somewhere a strip like program? Thanks Raimund From amiga-gcc-port-owner@nic.funet.fi Thu Mar 9 15:22:48 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91399-3>; Thu, 9 Mar 1995 15:19:07 +0200 Received: by colombo.telesys-innov.fr; Thu, 9 Mar 1995 14:18:56 GMT From: Philippe BRAND Message-Id: <199503091418.OAA03674@colombo.telesys-innov.fr> Subject: Re: strip ? To: raimund@ifr.luftfahrt.uni-stuttgart.de Date: Thu, 9 Mar 1995 14:18:55 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9503091307.AA10479@ifr1.Luftfahrt.Uni-Stuttgart.DE> from "raimund@ifr.luftfahrt.uni-stuttgart.de" at Mar 9, 95 02:07:41 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 240 raimund@ifr.luftfahrt.uni-stuttgart.de writes: > is there somewhere a strip like program? As for now no, so I suggest to use "-s" flag while compiling. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB From amiga-gcc-port-owner@nic.funet.fi Thu Mar 9 15:43:22 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91221-2>; Thu, 9 Mar 1995 15:34:07 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA04851; Thu, 9 Mar 95 15:29:01 +0200 Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA16271; Thu, 9 Mar 95 15:34:13 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9503091334.AA16271@hpcl.cti.gr> Subject: Re: strip ? To: raimund@ifr.luftfahrt.uni-stuttgart.de Date: Thu, 9 Mar 1995 15:34:12 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9503091307.AA10479@ifr1.Luftfahrt.Uni-Stuttgart.DE> from "raimund@ifr.luftfahrt.uni-stuttgart.de" at Mar 9, 95 02:07:41 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 627 > is there somewhere a strip like program? There are two strip-like programs on aminet: MYSTRIP.lha dev/misc 5K 13+Strip symbol/debug hunks from executable. V1.0 Strip37_2.lha util/misc 16K 27+V37 symbol and debug hunk stripper Unfortunately, they don't always work with gcc programs. You could also get a copy of blink (or use slink, if you have SAS/C), and use something like: blink FROM a.out TO a.out.strip NODEBUG blink67.lzh dev/misc 23K 125 Linker by the Software Distillery I hope this helps, -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Thu Mar 9 15:45:49 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91420-4>; Thu, 9 Mar 1995 15:38:13 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA01217 (5.65c8/IDA-1.4.4 for ); Thu, 9 Mar 1995 14:38:00 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA18589; Thu, 9 Mar 95 14:38:00 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503091338.AA18589@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Dynamic Stack To: tsruland@immd8.informatik.uni-erlangen.de (Tobias Ruland) Date: Thu, 9 Mar 1995 14:37:59 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503091222.AA26545@immd8.informatik.uni-erlangen.de> from "Tobias Ruland" at Mar 9, 95 01:22:30 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 541 > > i had a mail exchange with Martin Apel, author of VMM. he says: > "dont worry about dynamic stack growing. use my vmm library, > allocate a huge virtual stack via VMM.library and be happy" :-) > I'm sure this library needs a MMU which means that this doesn't solve all problems (e.g. you can't ship programs compiled with it since not everybody has a MMU) :-(. > must i send my amiga to hell, buy a PC and use linux??? > or are we going to create a new cool OS? :-) > Or buy a PC and run the cool new Amiga OS on it ;-). Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Mar 9 16:30:07 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91404-2>; Thu, 9 Mar 1995 16:25:36 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA00344 (5.65c8/IDA-1.4.4 for ); Thu, 9 Mar 1995 14:32:27 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA18567; Thu, 9 Mar 95 14:32:26 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503091332.AA18567@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: strip ? To: raimund@ifr.luftfahrt.uni-stuttgart.de Date: Thu, 9 Mar 1995 14:32:26 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503091307.AA10479@ifr1.Luftfahrt.Uni-Stuttgart.DE> from "raimund@ifr.luftfahrt.uni-stuttgart.de" at Mar 9, 95 02:07:41 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 156 > > is there somewhere a strip like program? > Somewhere between other tools shipped with the autodocs there is a strip program. Hope it helps Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Mar 9 17:06:08 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91165-4>; Thu, 9 Mar 1995 17:01:17 +0200 Received: by ceylon.informatik.uni-rostock.de id QAA17383; Thu, 9 Mar 1995 16:00:55 +0100 Received: by honshu.informatik.uni-rostock.de id QAA12977; Thu, 9 Mar 1995 16:00:55 +0100 From: Gunther Nikl Message-Id: <199503091500.QAA12977@honshu.informatik.uni-rostock.de> Subject: Re: strip ? To: amiga-gcc-port@nic.funet.fi Date: Thu, 9 Mar 1995 16:00:55 +0100 (MET) In-Reply-To: <9503091334.AA16271@hpcl.cti.gr> from "Kriton Kyrimis" at Mar 9, 95 03:34:12 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 454 > Kriton Kyrimis wrote: > > There are two strip-like programs on aminet: > > MYSTRIP.lha dev/misc 5K 13+Strip symbol/debug hunks from executable. V1.0 > Strip37_2.lha util/misc 16K 27+V37 symbol and debug hunk stripper > > Unfortunately, they don't always work with gcc programs. Did you make this expirience yourself? I tried Strip37_2 and had no problems. Nethertheless I still use PowerPacker 4.0a's hunklab :) Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Mar 9 17:09:35 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <91186-2>; Thu, 9 Mar 1995 17:02:41 +0200 Received: by ceylon.informatik.uni-rostock.de id QAA17390; Thu, 9 Mar 1995 16:02:24 +0100 Received: by honshu.informatik.uni-rostock.de id QAA13050; Thu, 9 Mar 1995 16:02:24 +0100 From: Gunther Nikl Message-Id: <199503091502.QAA13050@honshu.informatik.uni-rostock.de> Subject: Re: System friendly waits To: amiga-gcc-port@nic.funet.fi Date: Thu, 9 Mar 1995 16:02:23 +0100 (MET) In-Reply-To: from "Peter Ivimey-Cook" at Mar 8, 95 07:33:32 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 363 > > Delay(0L); // Causes a task switch but doesn't delay > > // any longer. > > Careful with this. There was a bug in 1.1/1.2/1.3 dos.library which > meant that this failed - I think it waited forever or something like that. > Of course if you program already requires 2.04 there's no problem. It crashed the computer hard :-( Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Mar 9 18:08:30 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <91263-2>; Thu, 9 Mar 1995 18:02:41 +0200 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA09862; Thu, 9 Mar 95 17:58:25 +0200 Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA19228; Thu, 9 Mar 95 18:03:39 +0200 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9503091603.AA19228@hpcl.cti.gr> Subject: Re: strip ? To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Thu, 9 Mar 1995 18:03:38 +0200 (EET) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <199503091500.QAA12977@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Mar 9, 95 04:00:55 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 516 > > Unfortunately, they don't always work with gcc programs. > > Did you make this expirience yourself? I tried Strip37_2 and had no > problems. Nethertheless I still use PowerPacker 4.0a's hunklab :) One of these programs mentions the problem in the documentation. It could be that the other one works fine, but I'm under the impression that neither could not strip the one gcc program that I tried (probably "hello"). -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Fri Mar 10 03:18:43 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91169-2>; Fri, 10 Mar 1995 03:15:52 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rmteS-0004nYC; Thu, 9 Mar 95 18:38 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: unrunnable executables To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Thu, 9 Mar 1995 18:37:59 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1070 In the last few days I have hit a problem I've never seen before, on two completely different programs (octave 1.1.1 and gnat 2.0.3). Both of these are monsterous (by amiga standards) executables, weighing in at almost 3 Mb for gnat1 and 4.5 Mb for octave. To use gnat1 as an example, when run from a CLI and the file is resident on a disk: > gnat1 gnat1: Error -1 or when resident in ram: > ram:gnat1 ram:gnat1: file is not executable This is the same exact file, the execute permission is set, and avail shows that my largest free memory hunk is 27 Mb. I've put a copy of the executable in pub/amiga/gnu/ on ftp.amigalib.com: -r-------- 1 ftp system 1154687 Mar 9 04:16 gnat1-bad.lha in the hopes that one of you system gurus will grab a copy and see if you can figure out if there is something obviously wrong with the file. It was built with gcc 2.6.3 off my FreshFish Vol 8 CD, with no errors from the compiler, assembler, or linker. I did the build twice and got exactly the same executable twice, byte for byte. Thanks for any help! -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Mar 10 09:19:18 1995 Received: from piglet.INS.CWRU.Edu ([129.22.8.16]) by nic.funet.fi with ESMTP id <91208-1>; Fri, 10 Mar 1995 09:16:19 +0200 Received: (cz253@localhost) by piglet.INS.CWRU.Edu (8.6.10+cwru/CWRU-2.1-bsdi) id CAA21876; Fri, 10 Mar 1995 02:16:06 -0500 (from cz253) Message-Id: <199503100716.CAA21876@piglet.INS.CWRU.Edu> Date: Fri, 10 Mar 1995 02:16:06 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: ___datadata_relocs Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Just tried to compile a version of pdksh, and gcc 2.6.3 is squawking that '___datadata_relocs' is undefined. Where is '___datadata_relocs' located? Thanks in advance. .....Dave From amiga-gcc-port-owner@nic.funet.fi Fri Mar 10 10:59:40 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91382-3>; Fri, 10 Mar 1995 10:55:17 +0200 Received: from tlaloc.cms.dmu.ac.uk (se1dp@tlaloc.cms.dmu.ac.uk [146.227.102.4]) by macondo.dmu.ac.uk (8.6.10/8.6.10) with ESMTP id IAA24001; Fri, 10 Mar 1995 08:56:39 GMT Received: by tlaloc.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA277075680; Fri, 10 Mar 1995 08:54:42 GMT Date: Fri, 10 Mar 1995 08:54:40 +0000 (GMT) From: Derek Piper X-Sender: se1dp@tlaloc.cms.dmu.ac.uk To: Gunther Nikl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: strip ? In-Reply-To: <199503091500.QAA12977@honshu.informatik.uni-rostock.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > > Kriton Kyrimis wrote: > > > > There are two strip-like programs on aminet: > > > > MYSTRIP.lha dev/misc 5K 13+Strip symbol/debug hunks from executable. V1.0 > > Strip37_2.lha util/misc 16K 27+V37 symbol and debug hunk stripper > > > > Unfortunately, they don't always work with gcc programs. > > Did you make this expirience yourself? I tried Strip37_2 and had no > problems. Nethertheless I still use PowerPacker 4.0a's hunklab :) > > Gunther > The Commodore devtools, which came with the includes, have a source code comments remover as well a hunk stripper which removes debug and symbol hunks from a file. Crunching with Imploder or PowerPacker also removes the symbol and debug hunks. Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | HTML Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | "It's a perfectly good program, it just doesn't work. That's all." | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Mar 10 13:02:31 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91383-4>; Fri, 10 Mar 1995 12:19:14 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA25003 (5.65c8/IDA-1.4.4 for ); Fri, 10 Mar 1995 11:18:55 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA20502; Fri, 10 Mar 95 11:18:55 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503101018.AA20502@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: ___datadata_relocs To: cz253@cleveland.freenet.edu Date: Fri, 10 Mar 1995 11:18:54 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199503100716.CAA21876@piglet.INS.CWRU.Edu> from "David Zaroski" at Mar 10, 95 02:16:06 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 467 > > Just tried to compile a version of pdksh, and gcc 2.6.3 is squawking that > '___datadata_relocs' is undefined. Where is '___datadata_relocs' located? > ___datadata_relocs is generated by the linker as soon as you start compiling resident programs. It's a list of all pointers to the data hunk. Remember: Every time you start a resident program a new data hunk is allocated by the startup code - and pointers to it need to be adopted. Hope it helps. Matthias From amiga-gcc-port-owner@nic.funet.fi Fri Mar 10 13:02:31 1995 Received: from partech.com ([192.133.62.31]) by nic.funet.fi with SMTP id <91199-1>; Fri, 10 Mar 1995 05:28:23 +0200 Received: from tomcat.partech.com by partech.com (4.1/SMI-4.1) id AA24857; Thu, 9 Mar 95 22:28:41 EST Received: by tomcat.partech.com (4.0/SMI-4.0) id AA19785; Thu, 9 Mar 95 22:21:55 EST Date: Thu, 9 Mar 95 22:21:55 EST From: joel@partech.com (Joe Locash) Message-Id: <9503100321.AA19785@tomcat.partech.com> To: amiga-gcc-port@nic.funet.fi Subject: stdio functions and sockets Hi all - first, can someone tell me if the I/O functions in stdio (getc,fgetc, etc) can handle socket streams? I can open a stream with fdopen() and passing the descriptor returned by a call to socket() (more on this in a sec) but a call to getc() doesn't seem to return. I am using gcc2.6.3/KS 40.70 if that makes a difference. Now for the socket() stuff. I have been working on porting the AmiTCP API to gcc. I think I have most of it worked out - I am testing it now. The hard part was finding/fixing the bugs and missing stuff in the inline headers. I have been able to compile programs which automatically open/close the bsdsocket.library of AmiTCP at the startup and exit of a program. I have been able to call functions in bsdsocket.library and achieve the expected results. I have only tested a few of the functions but everything seems to be working fine. As soon as I have everything working I will let the list know. To test my work I have started to port some Unix programs. I took the Unix ftp source and compiled it. It compiled out of the box fine except for a few warnings (I still have some things to fix in the AmiTCP includes). I am getting hung up in the getc() call so before I write one the can handle the socket stuff I figured I'd ask. Anyone have a clue? -Joe From amiga-gcc-port-owner@nic.funet.fi Fri Mar 10 13:11:56 1995 Received: by nic.funet.fi via suspension id <91191-4>; Fri, 10 Mar 1995 13:10:17 +0200 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91207-3>; Fri, 10 Mar 1995 13:08:06 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA17578; Fri, 10 Mar 1995 11:07:59 GMT Date: Fri, 10 Mar 1995 11:05:40 +0000 (GMT) From: Peter Ivimey-Cook To: Joe Locash Cc: amiga-gcc-port@nic.funet.fi Subject: Re: stdio functions and sockets In-Reply-To: <9503100321.AA19785@tomcat.partech.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Joe, > > Now for the socket() stuff. I have been working on porting the AmiTCP API to > gcc. I think I have most of it worked out - I am testing it now. The hard > part was finding/fixing the bugs and missing stuff in the inline headers. I > have been able to compile programs which automatically open/close the > bsdsocket.library of AmiTCP at the startup and exit of a program. I have been > able to call functions in bsdsocket.library and achieve the expected results. > I have only tested a few of the functions but everything seems to be working > fine. As soon as I have everything working I will let the list know. > > To test my work I have started to port some Unix programs. I took the Unix ftp > source and compiled it. It compiled out of the box fine except for a few > warnings (I still have some things to fix in the AmiTCP includes). I am > getting hung up in the getc() call so before I write one the can handle the > socket stuff I figured I'd ask. Anyone have a clue? I have been trying to port the pine 3.91 mail reader using gcc; of course I had to start off by compiling the AmiTCP libraries. I dl'd the AmiTCP 4.0 SDK which seems to include most library source but so far haven't had the chance to get very far with it. Any chance of sharing our efforts on this? Regards Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Fri Mar 10 16:47:39 1995 Received: from waldorf.informatik.uni-dortmund.de ([129.217.4.42]) by nic.funet.fi with SMTP id <91385-1>; Fri, 10 Mar 1995 16:44:20 +0200 Received: from speedy.informatik.uni-dortmund.de by waldorf.informatik.uni-dortmund.de with SMTP (Sendmail 8.6.10/UniDo 2.0.28) id PAA13763; Fri, 10 Mar 1995 15:44:10 +0100 Message-Id: <9503101444.AA27592@speedy.informatik.uni-dortmund.de> Received: from localhost by speedy.informatik.uni-dortmund.de id AA27592; Fri, 10 Mar 95 15:44:09 +0100 To: amiga-gcc-port@nic.funet.fi Subject: Virtual mem & mem protect (was Re: Amiga GCC v PC GCC) In-Reply-To: Your message of "Wed, 08 Mar 1995 16:24:11 +0100." <95Mar8.162426+0100mesz.209155-2+1736@hphalle0.informatik.tu-muenchen.de> Date: Fri, 10 Mar 1995 15:44:08 +0100 From: Michael Balzer Hi fellow AmigaOS fans ;-), Christian Stieber wrote: > > It is hell trying to compile un*x style programs on the PC (No multitasking > > ,nasty msdos,8 char files names, no decent OS. ...). I'd much rather use an > > Amiga but is there any chance of a program like 'go32' for the Amiga?? > > This is difficult. I once wrote a such a beast for AmigaOS --- an "unix" > kernel which gave each program its own address space, full memory > protection and virtual memory, just like Unix does. You could, however, > only use Unix programs with that, since the AmigaOS works by passing > pointers around and writing/reading memory that another process "owns". I suppose you knew of the problems before you began writing that beast. Under AmigaOS/Exec, the IMO only proper way to implement virtual memory and memory protection is to extend the memory pools interface. That is: Put up some new mem flags to be used with CreatePool(), one named MEMF_VIRTUAL, the other MEMF_PROTECTED. Any GCC (and any other) program would then be able to just request it's own protected pool for data that *can* be protected. If you need to pass pointers of your objects to other processes, just put those objects into an unprotected pool. Maybe something like sharing protected pools between certain processes could be implemented as well, that would solve some of those problems. For a go32 like thingy, we would further have to implement some kind of special program loader, or maybe a patch to LoadSeg(), to get also the program code into protected memory. But beware of passing callback function pointers to other processes... maybe a compiler flag (__shared) could be introduced for declaring data and code to be placed in the unprotected pool. Cleaning up is still some problem, but pools are quite a good step towards ressource tracking. (Btw: I haven't looked at GCC lately, I would love to see it using pools for all std mem handling... ;-) Anyway, an extension of the pools interface would be a transparent and completely optional way of implementing virtual and protected memory. On a machine without MMU or without this patch, the new CreatePool() flags would just be ignored. Michael PS: This idea is neither new nor mine, it's a basic idea behind the introduction of memory pools. PPS: Christian, just a thought: How many work would it be to transform your attempt into something like this? >;-) From amiga-gcc-port-owner@nic.funet.fi Fri Mar 10 19:28:59 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91517-2>; Fri, 10 Mar 1995 18:48:36 +0200 Received: by theseas.ntua.gr with UUCP; Fri, 10 Mar 1995 18:49:32 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06hr@kriton.UUCP>; Fri, 10 Mar 95 00:18:57 EET Date: Fri, 10 Mar 95 00:18:57 EET Message-Id: <9503092218.06hr@kriton.UUCP> In-Reply-To: <9503091017.AA18104@sunserv.IZFM.Uni-Stuttgart.DE> (from fleischr@izfm.uni-stuttgart.de (Matthias Fleischer)) (at Thu, 09 Mar 1995 11:17:18 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1210 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: fleischr@izfm.uni-stuttgart.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: more about stack extension Hi Matthias (Matthias Fleischer), in <9503091017.AA18104@sunserv.IZFM.Uni-Stuttgart.DE> on Mar 09 you wrote: > BTW: I already changed part of my interface (simple performance reasons): > at function entry gcc has to insert something like: > > movel #stack_needed,d0 > jbsr ____stack_extend_size > > Which I hope is very efficient. If anybody can squeeze some more cycles > out of it then please tell me - it'll be worth it ;-). This will probably add a cycle or two, but the first line should probably be something like: movel ___STKNEED,d0 This way, the user can specify the minimum amount of stack needed by each function. Thus, if the default is not enough (or too much!) one need only specify "long ___STKNEED=" to override the default. SAS/C does it this way. __STKNEED is the name of the variable they use, and we might want to keep the same name for compatibility. The default value for __STKNEED is 400. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "But you have access to the greatest source of knowledge in the Universe..." "Oh, I do talk sometimes to myself, yes!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Mar 10 19:28:59 1995 Received: from eeyore.INS.CWRU.Edu ([129.22.8.17]) by nic.funet.fi with ESMTP id <91513-3>; Fri, 10 Mar 1995 18:40:14 +0200 Received: (cz253@localhost) by eeyore.INS.CWRU.Edu (8.6.10+cwru/CWRU-2.1-bsdi) id LAA27588; Fri, 10 Mar 1995 11:34:24 -0500 (from cz253) Message-Id: <199503101634.LAA27588@eeyore.INS.CWRU.Edu> Date: Fri, 10 Mar 1995 11:34:24 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: fleischr@izfm.uni-stuttgart.de Subject: Re: ___datadata_relocs Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) > >> >> Just tried to compile a version of pdksh, and gcc 2.6.3 is squawking that >> '___datadata_relocs' is undefined. Where is '___datadata_relocs' located? >> >___datadata_relocs is generated by the linker as soon as you start >compiling resident programs. It's a list of all pointers to the data hunk. >Remember: Every time you start a resident program a new data hunk >is allocated by the startup code - and pointers to it need to >be adopted. > >Hope it helps. > Somewhat yes and no. So why would I be getting the undefined error for '___datadata_relocs'? I've compiled this version of pdksh with gcc 2.3.3 with no problems, but now with gcc 2.6.3 I get this problem. :( Also, when I compile the simple example in the readme from 2.6.3: #include main() { printf("Hello World!\n"); } Via, 'gcc -resident -o hello hello.c', I get: ld: unsupported reloc-size in /gnu/lib/libb/libgcc.a(__main.o) A problem with ld? .....Dave From amiga-gcc-port-owner@nic.funet.fi Fri Mar 10 20:12:43 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91217-2>; Fri, 10 Mar 1995 20:07:19 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26607-1>; Fri, 10 Mar 1995 18:52:28 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209155-1>; Fri, 10 Mar 1995 18:52:12 +0100 Subject: Re: ___datadata_relocs From: Christian Stieber To: cz253@cleveland.freenet.edu Date: Fri, 10 Mar 1995 18:52:07 +0100 (MEZ) Cc: fleischr@izfm.uni-stuttgart.de, amiga-gcc-port@lists.funet.fi In-Reply-To: <199503101634.LAA27588@eeyore.INS.CWRU.Edu> from "David Zaroski" at Mar 10, 95 11:34:24 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 926 Message-Id: <95Mar10.185212+0100mesz.209155-1+2862@hphalle0.informatik.tu-muenchen.de> > Also, when I compile the simple example in the readme from 2.6.3: > Via, 'gcc -resident -o hello hello.c', I get: > > ld: unsupported reloc-size in /gnu/lib/libb/libgcc.a(__main.o) > > A problem with ld? Yep. I'm having the same problem. I'm currently working around the problem by using an older version of as (from the gcc2.3.3 package), but since there are bugs in gcc 2.6.3 which may produce seriously incorrect code if -fbaserel is used (which is used when you specify -resident), you should probably not use 2.6.3 for resident code at all. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP key: finger stieber@ftp.leo.org -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Fri Mar 10 21:26:36 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <91277-1>; Fri, 10 Mar 1995 21:22:45 +0200 Received: from tiny.lysator.liu.se (tiny.lysator.liu.se [130.236.253.10]) by konrad.lysator.liu.se (8.6.10/8.6.10) with ESMTP id UAA21834; Fri, 10 Mar 1995 20:22:41 +0100 From: Niels M|ller Received: (nisse@localhost) by tiny.lysator.liu.se (8.6.10/8.6.10) id UAA07926; Fri, 10 Mar 1995 20:22:30 +0100 Date: Fri, 10 Mar 1995 20:22:30 +0100 Message-Id: <199503101922.UAA07926@tiny.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: balzer@irb.informatik.uni-dortmund.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9503101444.AA27592@speedy.informatik.uni-dortmund.de> (message from Michael Balzer on Fri, 10 Mar 1995 15:44:08 +0100) Subject: Re: Virtual mem & mem protect (was Re: Amiga GCC v PC GCC) Michael Balzer wrote: Hi fellow AmigaOS fans ;-), Christian Stieber wrote: > > It is hell trying to compile un*x style programs on the PC (No multitasking > > ,nasty msdos,8 char files names, no decent OS. ...). I'd much rather use an > > Amiga but is there any chance of a program like 'go32' for the Amiga?? > > This is difficult. I once wrote a such a beast for AmigaOS --- an "unix" > kernel which gave each program its own address space, full memory > protection and virtual memory, just like Unix does. You could, however, > only use Unix programs with that, since the AmigaOS works by passing > pointers around and writing/reading memory that another process "owns". I suppose you knew of the problems before you began writing that beast. Under AmigaOS/Exec, the IMO only proper way to implement virtual memory and memory protection is to extend the memory pools interface. That is: Put up some new mem flags to be used with CreatePool(), one named MEMF_VIRTUAL, the other MEMF_PROTECTED. Any GCC (and any other) program would then be able to just request it's own protected pool for data that *can* be protected. [ ... ] Michael I think this idea sounds really good. I recently tried VMM, and it seems rather hazardous to let ordinary AllocMem() calls return virtual memory, without the caller asking for it. It is good if you have a big program (like AdPro, or Maple) and you run out of physical memory, but it is a dangerous way to add virtual memory to the system. Also, I'm not sure how much protection of memory is implemented in VMM. But perhaps VMM can be used almost as is by ixemul.library, at least for data memory? Just add an option to ixemul, to let malloc() allocate virtual or protected memory, either by using vmm.library directly, or by using memory pools. Also each process must have a flag that it can set or clear to change the behaviour of malloc, so that some allocations can be unprotected (even such simple things as window titles must *not* be protected). One of the tricky parts in implementing virtual memory on the amiga, I guess, is that exec's context switching must somehow be patched. I think VMM patches the exec funtion Switch(). With ixemul library patching exec is perhaps not necessary, as the context switching can be handled by the functions installed by ixemul in the *task's* tc_Launch and tc_Switch fields? Does this make sense? /Regards, Niels Möller From amiga-gcc-port-owner@nic.funet.fi Sun Mar 12 21:32:39 1995 Received: from clinet.fi ([193.64.6.1]) by nic.funet.fi with SMTP id <92077-4>; Sun, 12 Mar 1995 08:43:41 +0200 Received: from zetor.clinet.fi (root@zetor.clinet.fi [193.64.6.8]) by clinet.fi (8.6.10/8.6.4) with ESMTP id IAA08273; Sun, 12 Mar 1995 08:42:16 +0200 Received: (will@localhost) by zetor.clinet.fi (8.6.10/8.6.4) id IAA16152; Sun, 12 Mar 1995 08:42:15 +0200 Date: Sun, 12 Mar 1995 08:42:13 +0200 (EET) From: Ville-Pertti Keinonen To: phb@colombo.telesys-innov.fr cc: amiga-gcc-port@nic.funet.fi Subject: Re: ENV: and ixemul startup (fwd) In-Reply-To: <199503060956.JAA12371@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Ahem... I quite don't like the idea of having multiple ixemul sources and > libraries... Couldn't you just share your code with "official" ixemul > mainteners ? Having people working alone won't make the thing going faster. I know, I don't like the idea of multiple versions either, but diffing what I have done so far would only result in a mess, since I had to make lots of modifications to even be able to compile the library (the 40.4 source distribution was really horrible). Additionally, I had originally implemented certain additions using 3.x+ specific features and I'm now rewriting most of what I've done to the library in order to make it 2.x-compatible. (So far, I've fixed the protection bits, fixed chown(), added fchown(), wrote much faster global environment management and partially completed internal and muFS (almost everything can be configured before compilation using #defines) accouting features (although the internal ones don't really provide any security unless a filesystem supporting ixemul is used). There's still a lot more that I intend to do). I would like to share the changes with other people, but as I said earlier, diffing would make a mess. I'll do it, if necessary, but according to what I've heard (more like read) and seen (more like not seen), the current ixemul maintainer hasn't been particularly interested in further development of ixemul.library. If this is correct, it might be possible for me to take over the development of the library - or does anyone have something against that? From amiga-gcc-port-owner@nic.funet.fi Mon Mar 13 11:43:25 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91186-2>; Mon, 13 Mar 1995 11:35:26 +0200 Received: by colombo.telesys-innov.fr; Mon, 13 Mar 1995 10:35:40 GMT From: Philippe BRAND Message-Id: <199503131035.KAA25568@colombo.telesys-innov.fr> Subject: New 2.6.4 beta available To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 13 Mar 1995 10:35:38 +0000 (GMT) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 440 A new beta-version of gcc-2.6.4 is available on both ftp.funet.fi and my site. There is no new features implemented, I plan to do it in a few days for the stack checking code, so this is only a generic bug fxes release, only for the C part. This version has succesfully recompiled all GNU software. Fred: expect a diff file tonight or tomorrow morning. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB From amiga-gcc-port-owner@nic.funet.fi Mon Mar 13 11:52:23 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91392-4>; Mon, 13 Mar 1995 11:43:31 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA03532 (5.65c8/IDA-1.4.4 for ); Mon, 13 Mar 1995 10:43:10 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA21796; Mon, 13 Mar 95 10:43:10 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503130943.AA21796@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: more about stack extension To: amiga-gcc-port@nic.funet.fi Date: Mon, 13 Mar 1995 10:43:09 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 5558 > > This will probably add a cycle or two, but the first line should > probably be something like: > movel ___STKNEED,d0 > This way, the user can specify the minimum amount of stack needed by > each function. Thus, if the default is not enough (or too much!) one > need only specify "long ___STKNEED=" to override the default. > > SAS/C does it this way. __STKNEED is the name of the variable they use, > and we might want to keep the same name for compatibility. The default > value for __STKNEED is 400. > IMO that's not necessary since gcc knows EXACTLY how much stack your function needs. Therefore you need not set any default values but can use the real thing. This is true even if you use large fixed sized arrays (thanks Christian for this information). Problems arise as soon as you start using variable sized arrays or alloca(). Both are extensions to the ANSI standard and might be solved later :-}. BTW: Here is a first beta testing example of automatic stack extension code for libnix. It contains the code, a makefile and a simple example program that needs a really large amount of stack but runs well with a 4096 bytes one. Of course I inserted some lines into the assembler code by hand ;-). Matthias begin 666 stack.lha M'D@M;&@U+>H !U 0 86!L'@ "&UA:V5F:6QEYPT Z%J7K;41YM_P!^A< MFJ'X#GCR5$;:AN%N&H/&TA+^YAII$LF#<#XWVVS&X7@: $<2;JW?&VKVKF*K MP$OE+&"5W S_"6UBVF5W)JH+9?$8?9M',3E/ M 1;F5E9'-L87)G97-T86-K+F.PC@)B8Y>MMJE< MT?@"U9PRJTHW9;KK+MEL@Y*;@$) EKE$Y(Y<\.R31O 8,>-WVW9-:J9(0ED< M!P".4XQ',"1R&8#1MM.OHG&03Z*)4]"UPO7N(I ^N@G&.LZ^NNC,'.JL(O/! M<-CH.%Y)33[4!!$H", ):CUK. P=@^@+IPALG@0S M1#>?Q$)BB]+K.^8Y1J1[VMP : &>)C%@^6TJ8G'!,6)-W M9%S;<1V3%M7,;&4QI [H2[L)?K@Q##_FLS8^"6(/R';EE MA!%K/"T[VYA;LIV>+L3?W\Y6_CP %\/ 5DJUU3&Z@?X,F+'_QDQ9.\9 CX) M=HOXL<7RS8M\$#/3:^%THG$ '=PM;&@U+9,# 8"P !&!L'@ !W-T86)S M+FCA-P,";)>QMM8W6C\ ?B>@)2J.-*+*&1UYE8R:%;N$T'F+.37-M E MW,[N5@_'+_^YMIR#M),*7#8-&AK&^;IM&P> AOO#5MIN=;HSHG/G"7'DP=&. M7URVK8^U"#[T-KEXPR:3K.!E'!::CA4;,I*PSI4&DR)Z:$: 3G!>NJ9-+#34 MG"A K:C,H2BT''RM@HL_WG4&8R K&'.;@F;!]GH8*,Y?"P0E@.!E>"V8'LKT,44-TO_*CO63.6.5O0-")IY[)RQ(B% M;!"#[->HX9@?CCOL/^+ CDOSF88(_+?F6N"#O"/3TQXL./(04AS>(6=.1\,P M/-GSA6X!84"U4TAJ51[C,&:I% JO,Q*E@-7!H)9[BR!]GMQY F.')%']7FOB MA\U\?'WA'#UX2"(KH.X0RRDHE+UEEACC@O!EM!\?[@2>][$H1MJ217(+/>2* M/ZQJMW 3J[/B!"4?T!-[W\@(56, W;;=*91E:W7:^%MNA\W -"CW!F2#9GZ. M1Z1RS[*--U2%[)^V"$PGL?BDTQZ6LXZ;C05--906>=11::UWE3HQ]/5Z=^ MCVS16^[(6]#_%+V/H-4>&Y!=>K4E3#SPNX?6ZJ5C43Z&U""SCZVQ\>0+V9&D"#BXLMIV1.R MH,I5#:JO;E=B0'N?*RI/N&W!I(5ZO/R%DI\)!@]GJ?$061W:Z%9]6@>"WY/7 MHP8L7 -;ICY?._)=Y_M@A-(]O#V5DRU!N&_A%!KM==;!%=0@!<'OC8@_R;8M M8K4Q;D(HMVIDLMMLH'5/TC?/(6#3M[OTG,?ZSD<9_P[0MR<9#ERUM&2F7^A[ MK_8/&_X/;0[=VX$# /'+R]^2FS#K@HLO]=\)+$Y4)?B@_>4[,WXOF =F T7@ M 8[ "7Q'!_ %C_L.^-A>;@'2^.;^1%S?X.MF8'-X#J3Q'1?$D ?,?R?^5V]( MWY_@@[]4+/P0>2)O+./3G1GM "-X+6QH-2UE! 4 L *M;;!X US=&%C M:V5X=&5N9"YC)UX#S&N[S;4HD:2DIU*&NY6D.#C@R$J&$4$MO%$[ M(YQ O9;MO#R62WLW@V^'NK;3CVM+/$:B,H]W*@ZC^ MPO@6+9Z]X7JGC.G0FM)43("*T(25(HB4,$$7;(@DQ1>(ACTI1VYR^"L-:K&M M5CS$RXVM24X1^RV.6>A)< \J"]\IZ$^<"&G*1!4X!GS3CR'1&5"1V_8$3X.? MIZ!J/3 8Y5'6F\L(A,40PJ/EA/)#7"\(@!I43C:P8R=Y>6,&M!>Z@J5.Q'!C'%UD0.VH(\]A71T MBI8OI0YAG?&L8!X1V*TOM6CE2-764<5"$%G4,\Y5E=QQP=NFA3#>>>(M,#G/ MF'1/ZPY;G4*Y9Y5!0U+J_=[SM5PGFF)/'BEG+R3A1J0@16W$:5=LP_4'":5U MY?IJJ= Z##[JJC7$R_N4\CK*F/+@=S>#\0_ LA*#*9?G $(_K^XY9X^DB>UW MFZL6)ZYO*BAQ\^(^8J'MBNS>$7D(1$S.VA.;)H@'[A']S/YY'[UT0>OQ,?(8 M!I2[PKOO/'"L1"^B3 )R8_>4SBT)Q-&0SD=UGG%-E,Y#J/[%O9$ERF$" M<0I-4Z<])+ZS4)A$9"Y&)J!H )??)6#-]_)5Z #0]PF&1*'(4$E25D0$X2./ MNS.:VX"^QL)=J](YQG":I+OOTM6<#4]WEQJQZ:ELO,N,Z:%]B M"#->$SB380@= <[UW43]O!6";C:'U$_;%H-=]D?,'F/;,AVPW+KIJ,] M2]KFP,.[Z:S'FYB&1KT5MFDD#NJS;W 8QXF'X'I_EXN7CAY^KWXN3AKF'W5& MCQ;):]EMKA/0:.?[U#^)5!P-S61RTV A0T.U[O1Q=/5T_]>GB (NZ;ZZ%>QM/?+1_5!-%L8&VQT0SG/*O8I7#@AJSMGNI5<*!G M<=:5GA OF#_.S*N%>@T]!&@JJ ^%3KM9V:]OMUMLRF?/?3JZP!>+2-Z^26+]&*:M)[5( end From amiga-gcc-port-owner@nic.funet.fi Mon Mar 13 15:13:49 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91393-3>; Mon, 13 Mar 1995 14:32:41 +0200 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA12402 (5.65c-6/7.3w-FAU); Mon, 13 Mar 1995 13:32:17 +0100 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id NAA01880 (8.6.10/7.4a-FAU); for ; Mon, 13 Mar 1995 13:32:11 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA19630; Mon, 13 Mar 1995 13:32:03 +0100 Date: Mon, 13 Mar 1995 13:32:03 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9503131232.AA19630@pctc.chemie.uni-erlangen.de> To: amiga-gcc-port@nic.funet.fi Subject: principal question about glibc Hello, I have a principal question to all of you working on the port of gcc for the amiga. Is it worth or are there any dis- / advantages of doing a port of glibc-1.09 to the amiga ?? Regards -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Mon Mar 13 17:07:48 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91425-4>; Mon, 13 Mar 1995 16:34:42 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 13 Mar 1995 15:34:19 +0100 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA03407; Mon, 13 Mar 95 15:34:20 +0100 Date: Mon, 13 Mar 95 15:34:20 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503131434.AA03407@inf-wiss.uni-konstanz.de> Received: by mammern.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA03419; Mon, 13 Mar 95 15:31:51 +0100 To: dev@flevel.demon.co.uk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Stack Size! In-Reply-To: <9503071412.AA005wq@flevel.demon.co.uk>, <20502adb.b98c2-dev@flevel.demon.co.uk> References: <9503071338.AA16586@inf-wiss.uni-konstanz.de> <9503071412.AA005wq@flevel.demon.co.uk> <20502adb.b98c2-dev@flevel.demon.co.uk> dev@flevel.demon.co.uk writes: > I not quite sure what all the fuss is about though, if you put in your > shell startup "stack 256000" then you don't seem to get a problem ;-) Obviously you've never compiled bigger programs :-) Adding yet another 0 would leave enough stack for everything I've seen so far, but then can you afford that much memory as the default stack? (Remember that every process from there on gets a stack that large: make, gcc, cc1, more, anything in that shell ...). Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Mon Mar 13 17:31:52 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91443-3>; Mon, 13 Mar 1995 17:11:48 +0200 Received: from fermat.cms.dmu.ac.uk (fermat.cms.dmu.ac.uk [146.227.102.65]) by macondo.dmu.ac.uk (8.6.11/8.6.11) with ESMTP id PAA05503 for ; Mon, 13 Mar 1995 15:13:04 GMT Received: by fermat.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA138517462; Mon, 13 Mar 1995 15:11:02 GMT Date: Mon, 13 Mar 1995 15:11:01 +0000 (GMT) From: Derek Piper X-Sender: se1dp@fermat.cms.dmu.ac.uk To: GCC Mail List Subject: To Tobias Ruland Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Tobias, I have lost your e-mail address for which to send that small owl picture you requested ages ago. Sorry I never got around to it before. Now that I have I do not know where to send it. Apologies to other GCC users for using the list for a non-gcc request :-) Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | World Wide Web Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Foolproof operation: All parameters are hard coded. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Mar 13 18:17:31 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91405-4>; Mon, 13 Mar 1995 17:43:09 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26466-2>; Mon, 13 Mar 1995 16:29:51 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209155-2>; Mon, 13 Mar 1995 16:29:39 +0100 Subject: Preprocessor problem From: Christian Stieber To: amiga-gcc-port@lists.funet.fi Date: Mon, 13 Mar 1995 16:29:31 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 868 Message-Id: <95Mar13.162939+0100mesz.209155-2+424@hphalle0.informatik.tu-muenchen.de> Hi all, apparentky either gcc or ixemul have a serious problem: gcc -MM ProcessDir.h yields processdir.o: processdir.c AVL.h main.h ProcessDir.h Apparently, something changed the case, which makes it impossible to generate makefiles automatically without editing them (okay, sed can do the job). Is that an Amiga-only bug, or is this a general gcc problem? I believe that it is Amiga-related, since someone probably would have complained about it if it shows up on Unix systems as well :) Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP key: finger stieber@ftp.leo.org -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 12:39:19 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91422-2>; Tue, 14 Mar 1995 12:31:05 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id ag07466; 14 Mar 95 10:23 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA007eo; Tue, 14 Mar 95 10:20:24 GMT Date: Tue, 14 Mar 95 10:20:24 GMT Message-Id: <9503141020.AA007en@flevel.demon.co.uk> Message-Id: <20592ee6.7ef40-dev@flevel.demon.co.uk> In-Reply-To: <95Mar13.162939+0100mesz.209155-2+424@hphalle0.informatik.tu-muenchen.de> (from Christian Stieber ) (at Mon, 13 Mar 1995 16:29:31 +0100 (MEZ)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: stieber@informatik.tu-muenchen.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Preprocessor problem Hi Christian, > Hi all, > > apparentky either gcc or ixemul have a serious problem: > > gcc -MM ProcessDir.h yields > processdir.o: processdir.c AVL.h main.h ProcessDir.h > > Apparently, something changed the case, which makes it impossible > to generate makefiles automatically without editing them (okay, sed > can do the job). > > Is that an Amiga-only bug, or is this a general gcc problem? I > believe that it is Amiga-related, since someone probably would have > complained about it if it shows up on Unix systems as well :) Surely the case should not matter on the Amiga because the file system is not case dependant :-) Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 12:39:19 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91415-4>; Tue, 14 Mar 1995 12:29:11 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id af07466; 14 Mar 95 10:23 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA007ej; Tue, 14 Mar 95 10:18:34 GMT Date: Tue, 14 Mar 95 10:18:34 GMT Message-Id: <9503141018.AA007ei@flevel.demon.co.uk> Message-Id: <20592e78.75300-dev@flevel.demon.co.uk> In-Reply-To: <9503131434.AA03407@inf-wiss.uni-konstanz.de> (from Joerg-Cyril Hoehle ) (at Mon, 13 Mar 95 15:34:20 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: hoehle@inf-wiss.uni-konstanz.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Stack Size! Hi Joerg-Cyril, > dev@flevel.demon.co.uk writes: > > I not quite sure what all the fuss is about though, if you put in your > > shell startup "stack 256000" then you don't seem to get a problem ;-) > > Obviously you've never compiled bigger programs :-) Adding yet another I have, I use the GCCSTACK enviroment variable for that :-) > 0 would leave enough stack for everything I've seen so far, but then > can you afford that much memory as the default stack? (Remember that > every process from there on gets a stack that large: make, gcc, cc1, > more, anything in that shell ...). I not sure that any program other than things such as C compilers should use more than 100K of stack. I suppose some do though:-( Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 12:52:02 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91433-4>; Tue, 14 Mar 1995 12:43:31 +0200 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA08920 (5.65c-6/7.3w-FAU); Tue, 14 Mar 1995 11:42:04 +0100 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA00605 (5.x/7.3w-FAU); Tue, 14 Mar 1995 11:41:56 +0100 From: Tobias Ruland Message-Id: <9503141041.AA00605@immd8.informatik.uni-erlangen.de> Date: Tue, 14 Mar 1995 11:41:54 +0100 To: dev@flevel.demon.co.uk Cc: hoehle@inf-wiss.uni-konstanz.de, amiga-gcc-port@nic.funet.fi Subject: Re: Stack Size! In-Reply-To: <9503141018.AA007ei@flevel.demon.co.uk>, <20592e78.75300-dev@flevel.demon.co.uk> References: <9503131434.AA03407@inf-wiss.uni-konstanz.de> <9503141018.AA007ei@flevel.demon.co.uk> <20592e78.75300-dev@flevel.demon.co.uk> dev@flevel.demon.co.uk writes: > I not sure that any program other than things such as C compilers should > use more than 100K of stack. I suppose some do though:-( ^^^^^^^^^^^^^^^^^^ sure. mankind visited the moon using a 64k RAM computer... no problem. :-) c u tobias From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 13:52:04 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91529-3>; Tue, 14 Mar 1995 13:42:49 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA12173; Tue, 14 Mar 1995 11:42:17 GMT Date: Tue, 14 Mar 1995 11:40:20 +0000 (GMT) From: Peter Ivimey-Cook To: dev@flevel.demon.co.uk Cc: stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi Subject: Re: Preprocessor problem In-Reply-To: <9503141020.AA007en@flevel.demon.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII refor S. wrote: > > Surely the case should not matter on the Amiga because the file system > is not case dependant :-) > But is 'make' case insensitive too? I too wasn't quite sure what the problem was - perhaps the original poser could expand on it. However, as a general point, it would seem sensible to maintain the case of files even if it doesn't actually matter re. the amiga file system. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 18:12:45 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91587-1>; Tue, 14 Mar 1995 18:04:51 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26545-1>; Tue, 14 Mar 1995 16:24:55 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209155-2>; Tue, 14 Mar 1995 16:24:47 +0100 Subject: Re: Preprocessor problem From: Christian Stieber To: peteric@insignia.co.uk (Peter Ivimey-Cook) Date: Tue, 14 Mar 1995 16:24:41 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Peter Ivimey-Cook" at Mar 14, 95 11:40:20 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1001 Message-Id: <95Mar14.162447+0100mesz.209155-2+1075@hphalle0.informatik.tu-muenchen.de> > > Surely the case should not matter on the Amiga because the file system > > is not case dependant :-) > > > But is 'make' case insensitive too? I too wasn't quite sure what the > problem was - perhaps the original poser could expand on it. Well, I actually never tried to use make with the wrong case. GNU make was written for Unix; therefore I just assumed that it is case sensitive. And that's why I wanted the correct case. > However, as a general point, it would seem sensible to maintain the case > of files even if it doesn't actually matter re. the amiga file system. That's true. It makes things more readable. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP key: finger stieber@ftp.leo.org -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 18:22:19 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91594-1>; Tue, 14 Mar 1995 18:14:50 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA13755; Tue, 14 Mar 1995 16:14:08 GMT Date: Tue, 14 Mar 1995 16:12:08 +0000 (GMT) From: Peter Ivimey-Cook To: Amiga GCC List Cc: joel@partech.com, Tomi Ollila , amitcp-group@nsdi.fi Subject: Re: AmiTCP API gcc development. In-Reply-To: <199503141544.AA10268@cardhu.cs.hut.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks, There seems to be a group of people interested in developing the AmiTCP/IP development environment to work with gcc. Currently, the libraries and files are targetted at SAS C. It would seem that the best way to go is a fairly close integration into the ixemul and libnix libraries, but none of us seem sure who is currently maintaining these libraries. So I have a couple of questions: 1. Do people think it would be good to have a close integration of gcc libraries and AmiTCP, to the exclusion of other networking libraries? If not, Which other libraries would you want to support and where is the documentation on them? 2. Who should we contact to get up to date information about ixemul and libnix? Does anyone know anything about the networking code in ixemul - I seem to remember it tried to open "net.library" at one point, and has certain net-ish include files. What are they from? Thanks for any info, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 19:14:32 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91599-4>; Tue, 14 Mar 1995 19:10:42 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA28188 (5.65c8/IDA-1.4.4 for ); Tue, 14 Mar 1995 18:10:29 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA23746; Tue, 14 Mar 95 18:10:28 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503141710.AA23746@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: AmiTCP API gcc development. To: peteric@isltd.insignia.com (Peter Ivimey-Cook) Date: Tue, 14 Mar 1995 18:10:28 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Peter Ivimey-Cook" at Mar 14, 95 04:12:08 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 925 > > 1. Do people think it would be good to have a close integration of gcc > libraries and AmiTCP, to the exclusion of other networking libraries? > I personally installed AmiTCP 2 weeks ago and it seems to run well, so I'd prefer it over other networking packages. But why exclude other networking software? Where are the big differences? > If > not, Which other libraries would you want to support and where is the > documentation on them? > I'd like to support any PD TCP/IP protocol stack someone's going to write in the future ;-). Currently I think AmiTCP is the best bet because it seems to be the only one you find on aminet. > 2. Who should we contact to get up to date information about ixemul > and libnix? For information about libnix, bug-reports, etc. contact either Gunther (gnikl@informatik.uni-rostock.de) or me or just post into this list :-). > > Thanks for any info, > Hope it helps. Matthias From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 19:28:10 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91600-3>; Tue, 14 Mar 1995 19:19:55 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26486-4>; Tue, 14 Mar 1995 17:29:49 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209155-2>; Tue, 14 Mar 1995 17:29:36 +0100 Subject: Re: Preprocessor problem From: Christian Stieber To: dev@flevel.demon.co.uk Date: Tue, 14 Mar 1995 17:29:24 +0100 (MEZ) Cc: stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <20592ee6.7ef40-dev@flevel.demon.co.uk> from "dev@flevel.demon.co.uk" at Mar 14, 95 10:20:24 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 826 Message-Id: <95Mar14.172936+0100mesz.209155-2+1107@hphalle0.informatik.tu-muenchen.de> > > Apparently, something changed the case, which makes it impossible > > to generate makefiles automatically without editing them (okay, sed > > can do the job). > Surely the case should not matter on the Amiga because the file system > is not case dependant :-) But 'make' is case dependent. Obviously, since it knows how to make a ".s" file from a ".S" file :) Therefore, it won't know how to make ProcessDir.o if the rule calls it "processdir.o". Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP key: finger stieber@ftp.leo.org -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 19:32:51 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91601-1>; Tue, 14 Mar 1995 19:31:32 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA14306; Tue, 14 Mar 1995 17:31:16 GMT Date: Tue, 14 Mar 1995 17:29:17 +0000 (GMT) From: Peter Ivimey-Cook To: Christian Stieber Cc: dev@flevel.demon.co.uk, stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi Subject: Re: Preprocessor problem In-Reply-To: <95Mar14.172936+0100mesz.209155-2+1107@hphalle0.informatik.tu-muenchen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 14 Mar 1995, Christian Stieber wrote: > > Surely the case should not matter on the Amiga because the file system > > is not case dependant :-) > > But 'make' is case dependent. Obviously, since it knows how to make > a ".s" file from a ".S" file :) > Therefore, it won't know how to make ProcessDir.o if the rule calls it > "processdir.o". > But as I understand it only if the two names are mixed within the makefile, which I guess they may be :( Someone like to fix this? Sorry - I nether have the machine power nor, really, the time. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 19:35:14 1995 Received: from rpi.edu ([128.113.1.7]) by nic.funet.fi with SMTP id <91602-4>; Tue, 14 Mar 1995 19:32:03 +0200 Received: from toshiki (toshiki.stu.rpi.edu) by rpi.edu (4.1/SMHUB41); id AA03392; Tue, 14 Mar 95 12:31:34 EST for amiga-gcc-port@nic.funet.fi Received: by toshiki.stu.rpi.edu (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Tue, 14 Mar 95 12:20:38 From: exidor@toshiki.stu.rpi.edu (Christopher "Exidor" Masto) Message-Id: <20594b04.37aa-exidor@toshiki.stu.rpi.edu> Subject: Re: AmiTCP API gcc development. In-Reply-To: (from Peter Ivimey-Cook ) (at Tue, 14 Mar 1995 16:12:08 +0000 (GMT)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) To: peteric@isltd.insignia.com Cc: joel@partech.com, too@cs.hut.fi, amitcp-group@nsdi.fi, amiga-gcc-port@nic.funet.fi Date: Tue, 14 Mar 95 12:20:38 Hi Peter, > There seems to be a group of people interested in developing the > AmiTCP/IP development environment to work with gcc. Currently, the > libraries and files are targetted at SAS C. > > It would seem that the best way to go is a fairly close integration into > the ixemul and libnix libraries, but none of us seem sure who is > currently maintaining these libraries. So I have a couple of questions: I agree that ixemul.library should attempt to emulate Unix network functions. Not sure about libnix though.. if I understand, its purpose is for Amiga-specific programs? Then there would be no need for it to include networking, since bsdsocket.library can be called directly. > 1. Do people think it would be good to have a close integration of gcc > libraries and AmiTCP, to the exclusion of other networking libraries? If > not, Which other libraries would you want to support and where is the > documentation on them? Perhaps it's possible to have a seperate version of ixemul.library for AmiTCP/AS225/NoNet such that ixemul-using programs need have no knowledge of which is in use. > 2. Who should we contact to get up to date information about ixemul > and libnix? Does anyone know anything about the networking code in ixemul > - I seem to remember it tried to open "net.library" at one point, and has > certain net-ish include files. What are they from? I have had some very good success in compiling network programs with GCC, using the libamitcp2.a provided in "amitcp2.x_gcc.lha". I use the include files that came with gcc 2.6.3 and link with -lamitcp2 -lamiga. The other method is to fix the inlines that come with AmiTCP, which I think several people have worked on.. The biggest problem I have encountered is with select(). Unix programs tend to use it to multiplex between a terminal and a socket. Unfortunately, gcc/ixemul has a select() that understands files and terminals, and AmiTCP has a select() that understands sockets. Neither of them seem to work with both (though I noticed that the ixemul sources have a comment for select saying that it was fixed to work better with networks). In addition, an AmiTCP socket() call will return 0, which, to gcc, is the fd for stdin. This makes it impossible to create a proper fd_set for the select() call. The method I used was to send ACTION_WAIT_CHAR packets to the console handler and use AmiTCP's WaitSelect() with the socket fd and the reply msgport signal. From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 19:43:59 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91603-1>; Tue, 14 Mar 1995 19:40:38 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA14396; Tue, 14 Mar 1995 17:40:06 GMT Date: Tue, 14 Mar 1995 17:38:08 +0000 (GMT) From: Peter Ivimey-Cook To: Christopher Exidor Masto Cc: joel@partech.com, too@cs.hut.fi, amitcp-group@nsdi.fi, amiga-gcc-port@nic.funet.fi Subject: Re: AmiTCP API gcc development. In-Reply-To: <20594b04.37aa-exidor@toshiki.stu.rpi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I agree that ixemul.library should attempt to emulate Unix network > functions. Not sure about libnix though.. if I understand, its purpose is > for Amiga-specific programs? Then there would be no need for it to include > networking, since bsdsocket.library can be called directly. Ok. This seems reasonable. Wouldn't we need a stubs library for bsdsocket.library though? > Perhaps it's possible to have a seperate version of ixemul.library for > AmiTCP/AS225/NoNet such that ixemul-using programs need have no knowledge > of which is in use. So what should happen if networking program is run on a system with the no-net ixemul? I would have thought that given the small ammount of code added (low tens of K at a guess, possibly less) we should just extend ixemul to cope correctly with networking (in all it's routines). Your point about select() being a good one. > I have had some very good success in compiling network programs with GCC, > using the libamitcp2.a provided in "amitcp2.x_gcc.lha". I use the include > files that came with gcc 2.6.3 and link with -lamitcp2 -lamiga. The Perhaps I should downgrade to AMiTCP 2 then :) > other method is to fix the inlines that come with AmiTCP, which I think > several people have worked on.. Anyone know who? Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 20:16:16 1995 Received: from cardhu.cs.hut.fi ([130.233.192.95]) by nic.funet.fi with SMTP id <91611-3>; Tue, 14 Mar 1995 20:12:38 +0200 Received: by cardhu.cs.hut.fi id AA10705 (5.65c8/HUTCS-C 1.3 for amiga-gcc-port@nic.funet.fi); Tue, 14 Mar 1995 20:11:13 +0200 Date: Tue, 14 Mar 1995 20:11:13 +0200 Message-Id: <199503141811.AA10705@cardhu.cs.hut.fi> From: Tomi Ollila Reply-To: To: exidor@toshiki.stu.rpi.edu (Christopher "Exidor" Masto) Cc: peteric@isltd.insignia.com, joel@partech.com, amitcp-group@nsdi.fi, amiga-gcc-port@nic.funet.fi Subject: Re: AmiTCP API gcc development. In-Reply-To: <20594b04.37aa-exidor@toshiki.stu.rpi.edu> References: <20594b04.37aa-exidor@toshiki.stu.rpi.edu> Christopher Masto writes: > Hi Peter, > > > There seems to be a group of people interested in developing the > > AmiTCP/IP development environment to work with gcc. Currently, the > > libraries and files are targetted at SAS C. > > > > It would seem that the best way to go is a fairly close integration into > > the ixemul and libnix libraries, but none of us seem sure who is > > currently maintaining these libraries. So I have a couple of questions: > > I agree that ixemul.library should attempt to emulate Unix network > functions. Not sure about libnix though.. if I understand, its purpose is > for Amiga-specific programs? Then there would be no need for it to include > networking, since bsdsocket.library can be called directly. The way that AmiTCP/IP 4.x SDK handles calls to file and socket routines is, that bsdsocket.library send() and recv() -functions are called directly, but read() and write() (and derivatives of these all) are calls to AmiTCP/IP net.lib. This, of course makes the executable binary AmiTCP/IP dependent, but is fast. The ixemul/libnix filedescriptor system must be extended to include sockets (of all kind) in their fd tables and read/write/select/ioctl and close -calls. > I have had some very good success in compiling network programs with GCC, > using the libamitcp2.a provided in "amitcp2.x_gcc.lha". I use the include > files that came with gcc 2.6.3 and link with -lamitcp2 -lamiga. The > other method is to fix the inlines that come with AmiTCP, which I think > several people have worked on.. Hmm, I have completely forgotten this library. Thanks for reminding. > > The biggest problem I have encountered is with select(). Unix programs tend > to use it to multiplex between a terminal and a socket. Unfortunately, > gcc/ixemul has a select() that understands files and terminals, and AmiTCP > has a select() that understands sockets. Neither of them seem to work with > both (though I noticed that the ixemul sources have a comment for select > saying that it was fixed to work better with networks). In addition, an > AmiTCP socket() call will return 0, which, to gcc, is the fd for stdin. > This makes it impossible to create a proper fd_set for the select() call. Yes. This is the biggest problem. One reason why bsdsocket.library 4.0 API includes a new function, called GetSocketEvents(), is to provide other-than-amitcp -centered select() handling (with WaitSelect() the select() call must wait in AmiTCP/IP WaitSelect()). With GetSocketEvents(), the select() scanning can be done like UNIX select() does it at it's lowest levels. > > The method I used was to send ACTION_WAIT_CHAR packets to the console handler > and use AmiTCP's WaitSelect() with the socket fd and the reply msgport signal. The method I used is to send ACTION_READ packet to the console handler and wait it to return. If, for some reason, I want that packet to be returned before it has any change to read data, I send ACTION_STACK packet with '\n' as a data to it. All current console handlers (and for example, inet-handler) returns the sent ACTION_READ packet in this case. I'll include the functions I use to get the ACTION_READ packet to return. First, AbortPacket() is used to send aborting information to the Filehandle where ACTION_READ -packet is sent. Then, WaitMessage() is used to wait for requested ACTION_READ -message to return. (Earlier, I tried to use `WaitPacket' - call for waiting, but then I learned from experience, that OS3.1 console-handler sets the DosPacket structure message port field to NULL while it is kept by the handler, and therefore old AmiTCP/IP telnet clients used to lock up). These functions are quaranteed to work. If the used dos handler doesn't handle the ACTION_STACK -packet as wanted, the WaitMessage() -call will wait until there is some data to be returned with ACTION_READ -packet. Well, this went a way out of the subject, but I think these functions are useful for many of the programmers (and we need an `official' way to abort a pending ACTION_READ -packet, and Ralph Babel agrees with me than this is the way of doing it in current situation). Feel free to use these functions freely in any kind of Amiga software. Tomi Ollila ---->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8---- #include /* should i say const char abrt = '\n'; /* * Function to abort pending ACTION_READ packet. (uses DoPkt) */ void AbortPacket(struct FileHandle * fh) { extern struct DosLibrary * DOSBase; /* register LONG _res __asm("d0"); */ register struct DosLibrary * a6 __asm("a6") = DOSBase; register struct MsgPort * d1 __asm("d1") = fh->fh_Type; register long d2 __asm("d2") = ACTION_STACK; register long d3 __asm("d3") = fh->fh_Arg1; register char * d4 __asm("d4") = &abrt; register long d5 __asm("d5") = 1; __asm __volatile ("jsr a6@(-0xf0)" : /* "=r" (_res) */ : "r" (a6), "r" (d1), "r" (d2), "r" (d3), "r" (d4), "r" (d5) : "a0","a1","d0","d1","d2","d3","d4","d5","d6","d7", "memory"); /* return _res; */ } /* * Waits for requested packet to return * returns # of messages queued in same msgport where packet returned. */ int WaitMessage(struct Message * msg, struct MsgPort * replyport) { struct Message * msgnode; UWORD i, found = FALSE; struct List list; NewList(&list); while (1) { WaitPort(replyport); Disable(); while ((msgnode = GetMsg(replyport))) { if (msgnode == msg) found = TRUE; else /* * Put other messages to local list (if any). */ AddTail(&list, &msgnode->mn_Node); } if (found) { struct Message * next; i = 0; /* * put other messages back to the port (sets signal implicitly). */ for (msgnode = (struct Message *)list.lh_Head; (next = (struct Message *)msgnode->mn_Node.ln_Succ); msgnode = next, i++) PutMsg(replyport, msgnode); Enable(); return i; } Enable(); } } From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 20:36:07 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <91606-4>; Tue, 14 Mar 1995 20:32:34 +0200 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA13560; Tue, 14 Mar 1995 19:37:53 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9503141837.AA13560@decap2.zdv.uni-tuebingen.de> Subject: de.comp.sys.amiga.gcc To: amiga-gcc-port@nic.funet.fi Date: Tue, 14 Mar 1995 19:37:52 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 434 Hi, list, rather frequently I see postings to c.s.a.(programmer|misc|applications) asking questions about gcc. Obviously this list isn't known enough. On the other hand the traffic on the list is way enough for a newsgroup and newsgroups are usually better known than mailing lists. Thus I ask myself (and you :-) if it wouldn't be a good idea to call for a newsgroup comp.sys.amiga.gcc or comp.sys.amiga.programmer.gcc? Jochen From amiga-gcc-port-owner@nic.funet.fi Tue Mar 14 23:04:00 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91637-2>; Tue, 14 Mar 1995 23:00:18 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26702-4>; Tue, 14 Mar 1995 21:33:42 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209195-1>; Tue, 14 Mar 1995 21:33:32 +0100 Subject: Re: de.comp.sys.amiga.gcc From: Christian Stieber To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Tue, 14 Mar 1995 21:33:18 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503141837.AA13560@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Mar 14, 95 07:37:52 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1144 Message-Id: <95Mar14.213332+0100mesz.209195-1+1115@hphalle0.informatik.tu-muenchen.de> > rather frequently I see postings to c.s.a.(programmer|misc|applications) > asking questions about gcc. Obviously this list isn't known enough. The usual "I never RTFM" problem. :( > On > the other hand the traffic on the list is way enough for a newsgroup > and newsgroups are usually better known than mailing lists. Agreed. And they help to reduce the size of my mailbox :) > Thus I ask myself (and you :-) if it wouldn't be a good idea to call > for a newsgroup comp.sys.amiga.gcc or comp.sys.amiga.programmer.gcc? Hm... How about comp.sys.amiga.gnu? That way people would have the chance to talk about other GNU software as well. If the traffic turns out to be *huge* it could be changed into comp.syy.amiga.gnu.gcc etc... (hm.. how many levels are allowed?) Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP key: finger stieber@ftp.leo.org -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 01:07:58 1995 Received: from partech.com ([192.133.62.31]) by nic.funet.fi with SMTP id <91643-3>; Wed, 15 Mar 1995 01:01:42 +0200 Received: from eclipse.partech.com by partech.com (4.1/SMI-4.1) id AA07599; Tue, 14 Mar 95 16:43:35 EST Received: by eclipse.partech.com (5.57/Ultrix3.0-C) id AA08106; Tue, 14 Mar 95 16:42:12 -0500 Date: Tue, 14 Mar 95 16:42:12 -0500 From: joel@partech.com (Joe Locash) Message-Id: <9503142142.AA08106@eclipse.partech.com> To: exidor@toshiki.stu.rpi.edu, peteric@isltd.insignia.com Subject: Re: AmiTCP API gcc development. Cc: amiga-gcc-port@nic.funet.fi, amitcp-group@nsdi.fi, joel@partech.partech.com, too@cs.hut.fi >From peteric@isltd.insignia.com Tue Mar 14 16:16:19 1995 > >> I have had some very good success in compiling network programs with GCC, >> using the libamitcp2.a provided in "amitcp2.x_gcc.lha". I use the include >> files that came with gcc 2.6.3 and link with -lamitcp2 -lamiga. The > >Perhaps I should downgrade to AMiTCP 2 then :) > I have created a similar library for AmiTCP3.0b2. I have just started moving what I have done over to 4.1 and should have that working within a day or two (time permiting) so there is no need to 'downgrade' ;). >> other method is to fix the inlines that come with AmiTCP, which I think >> several people have worked on.. > >Anyone know who? > I think I have most of the problems worked out with them. I will be moving that over to 4.1 also. -Joe From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 01:14:35 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91642-3>; Wed, 15 Mar 1995 01:11:27 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 15 Mar 95 00:10 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 15 Mar 95 00:05 MET Message-Id: Subject: de.comp.sys.amiga.gcc To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 15 Mar 1995 00:05:57 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 839 I support the idea, because there is less and less support for amiga C-compilers (who wonders ?) and the ppl will look for gcc as a serious option. the list has reached a good size (a steady stream) and we should beware to grow to big. btw: because so many pple show interessed in gcc we should provide something like gcc-examples. i have started this with amiga-only-examples (actualy that from the krm) but i dont how the time (now) to maintain it. but atleast one should provide beginner with apropriate examples. volunteers ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:52 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91169-2>; Mon, 13 Mar 1995 16:48:02 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 13 Mar 1995 15:47:36 +0100 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA03447; Mon, 13 Mar 95 15:47:34 +0100 Date: Mon, 13 Mar 95 15:47:34 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503131447.AA03447@inf-wiss.uni-konstanz.de> Received: by mammern.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA03450; Mon, 13 Mar 95 15:45:02 +0100 To: fnf@amigalib.com (Fred Fish) Cc: gnikl@informatik.uni-rostock.de (Gunther Nikl), amiga-gcc-port@nic.funet.fi Subject: Re: ar question In-Reply-To: References: <199503081424.PAA08177@honshu.informatik.uni-rostock.de> Hi, Fred Fish writes: > > I have a question concerning "ar". I do not use the gnu version of "ar" > > but a older (bsd?) version from gcc 2.3.3. I decided not to use gnu-ar > > because it truncates filenames longer than 16 characters but my old ar > Perhaps this explains the problem I had recently when I built octave. > The makefiles for octave want to make a library from sources in several > subdirectories, so they go to each subdir, do a compile and then when I sent a bug-report to this list not too long ago (mid-July 1994). It looks like it didn't catch the attention of the ar maintainers here (BTW, who are they?): >>>>>>>>>>>>>>>>>>>> part of old mail follows First, ar doesn't strip dirnames as documented in the manpage: Files are named in the archive by a single component, i.e., if a file referenced by a path containing a slash (``/'') is archived it will be named by the last component of that path. When matching paths listed on the command line against file names stored in the archive, only the last component of the path will be compared. ar -rv lib/libclisp.a startup/main.o startup/wbmain.o startup/exit.o misc/setjmp.o startup/gcc2__main.o r - startup/main.o r - startup/wbmain.o r - startup/exit.o r - misc/setjmp.o r - startup/gcc2__main.o ar: member name `startup/wbmain.o' truncated to `startup/wbmai.o' ar: member name `startup/gcc2__main.o' truncated to `startup/gcc2_.o' The ar distributed with gcc-1.40 did strip correctly. The ar distributed with gcc-2.3.3 did strip correctly. Second, when I switched from ar258 to ar233 I discovered than ranlib seems to call ar with an undocumented s option: 12.Ben:p/gccsmalllib> ranlib lib/libclisp.a ar: illegal option -- s usage: ar -d [-Tv] archive file ... [...] >>>>>>>>>>>>>>>>>>>> On a Sun and per documentation, ar should strip dirnames. Newer ars don't. > I solved the problem by patching the ar source so that if truncation I solved the problem by using ar233 :-( Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:52 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91396-2>; Mon, 13 Mar 1995 17:26:03 +0200 Received: from fermat.cms.dmu.ac.uk (fermat.cms.dmu.ac.uk [146.227.102.65]) by macondo.dmu.ac.uk (8.6.11/8.6.11) with ESMTP id PAA06131 for ; Mon, 13 Mar 1995 15:27:12 GMT Received: by fermat.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA139548316; Mon, 13 Mar 1995 15:25:16 GMT Date: Mon, 13 Mar 1995 15:25:16 +0000 (GMT) From: Derek Piper X-Sender: se1dp@fermat.cms.dmu.ac.uk To: GCC Mail List Subject: GCC 2.6.4 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Does anybody know where on ftp.funet.fi the archives for GCC 2.6.4 are ? Will they be placed on the Aminet soon ? Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | World Wide Web Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Foolproof operation: All parameters are hard coded. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:53 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91524-2>; Tue, 14 Mar 1995 15:22:24 +0200 Received: by theseas.ntua.gr with UUCP; Tue, 14 Mar 1995 15:16:50 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06mf@kriton.UUCP>; Tue, 14 Mar 95 15:11:16 EET Date: Tue, 14 Mar 95 15:11:16 EET Message-Id: <9503141311.06mf@kriton.UUCP> In-Reply-To: <9503141020.AA007en@flevel.demon.co.uk> (from dev@flevel.demon.co.uk) (at Tue, 14 Mar 95 10:20:24 GMT) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 770 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: dev@flevel.demon.co.uk Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Preprocessor problem Hi dev (dev), in <9503141020.AA007en@flevel.demon.co.uk> on Mar 14 you wrote: > Surely the case should not matter on the Amiga because the file system > is not case dependant :-) It might not matter on the Amiga, but it does matter if one is preparing something that is intended to run on a unix system. The Amiga, with ixemul and all the ported unix utilities offers a sufficiently unix-like environment to permit one to bring work at home. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "This is not my planet, I didn't choose to be here, I don't want to get involved, just get me out of here, and get me to a party with people I can relate to!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:53 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91402-2>; Tue, 14 Mar 1995 13:13:15 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA16693 (5.65c8/IDA-1.4.4 for ); Tue, 14 Mar 1995 12:13:02 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA23237; Tue, 14 Mar 95 12:13:02 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503141113.AA23237@sunserv.IZFM.Uni-Stuttgart.DE> Subject: even more about stack extension To: amiga-gcc-port@nic.funet.fi Date: Tue, 14 Mar 1995 12:13:01 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 732 Hello everybody, after some investigation in the gcc sources (to find the location of alloca) I found some conditional compilation with the following defines (explow.c): HAVE_save_stack_block (memorize sp at the start of a block) HAVE_save_stack_function (at function entry) HAVE_save_stack_nonlocal (alloca & variable sized arrays?) HAVE_restore_stack_block (restore stack pointer from the above) HAVE_restore_stack_function HAVE_restore_stack_nonlocal HAVE_allocate_stack (allocate some stackspace) (all together with a matching gen_* macro) I think they are meant for systems where stack extension is nontrivial. Isn't this exactly what we need? How do I tell gcc to insert the right code? And what code should I use? Matthias From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:53 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91711-2>; Wed, 15 Mar 1995 10:48:00 +0200 Received: by colombo.telesys-innov.fr; Wed, 15 Mar 1995 09:46:36 GMT From: Philippe BRAND Message-Id: <199503150946.JAA06382@colombo.telesys-innov.fr> Subject: Re: AmiTCP API gcc development. To: joel@partech.com (Joe Locash) Date: Wed, 15 Mar 1995 09:46:36 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9503142142.AA08106@eclipse.partech.com> from "Joe Locash" at Mar 14, 95 04:42:12 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 479 Joe Locash writes: > I have created a similar library for AmiTCP3.0b2. I have just started moving > what I have done over to 4.1 and should have that working within a day or two > (time permiting) so there is no need to 'downgrade' ;). When you'll finish job adapting it to 4.1 could you then send it to my FTP site for inclusion into gcc distribution, both Aminet & Fred Fish CD ? Thanks. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:53 1995 Received: from ios.com ([198.4.75.44]) by nic.funet.fi with SMTP id <91724-1>; Wed, 15 Mar 1995 11:17:20 +0200 Received: (from rasta@localhost) by ios.com (8.6.9/8.6.9) id EAA19520; Wed, 15 Mar 1995 04:10:44 -0500 Date: Wed, 15 Mar 1995 04:10:44 -0500 (EST) From: "formerly freak@acy1.digex.net" Subject: Re: AmiTCP API gcc development. To: Joe Locash cc: exidor@toshiki.stu.rpi.edu, peteric@isltd.insignia.com, amiga-gcc-port@nic.funet.fi, amitcp-group@nsdi.fi, joel@partech.partech.com, too@cs.hut.fi In-Reply-To: <9503142142.AA08106@eclipse.partech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 14 Mar 1995, Joe Locash wrote: > >From peteric@isltd.insignia.com Tue Mar 14 16:16:19 1995 > > > >> I have had some very good success in compiling network programs with GCC, > >> using the libamitcp2.a provided in "amitcp2.x_gcc.lha". I use the include > >> files that came with gcc 2.6.3 and link with -lamitcp2 -lamiga. The > > > >Perhaps I should downgrade to AMiTCP 2 then :) > > > I have created a similar library for AmiTCP3.0b2. I have just started moving > what I have done over to 4.1 and should have that working within a day or two > (time permiting) so there is no need to 'downgrade' ;). > > >> other method is to fix the inlines that come with AmiTCP, which I think > >> several people have worked on.. > > > >Anyone know who? > > > I think I have most of the problems worked out with them. I will be moving > that over to 4.1 also. > > -Joe > Yom fire off the Amitcp 3.0b2 stuff to us guys who don't want the commercial cheese! Thanx! From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:53 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <91623-4>; Tue, 14 Mar 1995 21:40:15 +0200 Received: from tiny.lysator.liu.se (tiny.lysator.liu.se [130.236.253.10]) by konrad.lysator.liu.se (8.6.10/8.6.10) with ESMTP id UAA06728; Tue, 14 Mar 1995 20:35:40 +0100 From: Niels M|ller Received: (nisse@localhost) by tiny.lysator.liu.se (8.6.10/8.6.10) id UAA07814; Tue, 14 Mar 1995 20:33:04 +0100 Date: Tue, 14 Mar 1995 20:33:04 +0100 Message-Id: <199503141933.UAA07814@tiny.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: stieber@informatik.tu-muenchen.de CC: peteric@insignia.co.uk, amiga-gcc-port@nic.funet.fi In-reply-to: <95Mar14.162447+0100mesz.209155-2+1075@hphalle0.informatik.tu-muenchen.de> (message from Christian Stieber on Tue, 14 Mar 1995 16:24:41 +0100 (MEZ)) Subject: Re: Preprocessor problem Another nuisance from this case conversion happens when using emacs. Say I edit a file "MyProgram.c" in a buffer of the same name. Then I compile by M-x compile, and a few errors are found. Then I use C-x ` to locate the error. But, in the error messages "MyProgram.c" is converted to "myprogram.c". As this name is different from the name of the file I started with, emacs creates another buffer, with name "myprogram.c", reads in the same file once more, and puts the point at the error. Then either emacs or I is confused because I edit the same file in two different buffers. The only solution I have found so far is to write all names of source files in lower case. Instead I want to follow the Objective-C practice to name files like MyClass.h and MyClass.m . I really can't see any good reason for this filename conversion. Is it ixemul, or the gcc frontend that does it? From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:53 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91713-3>; Wed, 15 Mar 1995 10:52:40 +0200 Received: by colombo.telesys-innov.fr; Wed, 15 Mar 1995 09:49:46 GMT From: Philippe BRAND Message-Id: <199503150949.JAA06401@colombo.telesys-innov.fr> Subject: Re: de.comp.sys.amiga.gcc To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Wed, 15 Mar 1995 09:49:46 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95Mar14.213332+0100mesz.209195-1+1115@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Mar 14, 95 09:33:18 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 442 Christian Stieber writes: > Hm... How about comp.sys.amiga.gnu? That way people would have the > chance to talk about other GNU software as well. If the traffic > turns out to be *huge* it could be changed into comp.syy.amiga.gnu.gcc > etc... (hm.. how many levels are allowed?) Indeed this is really a good idea... I would vote for c.s.a.gnu newsgroup. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:53 1995 Received: from mits.mdata.fi ([192.98.43.1]) by nic.funet.fi with SMTP id <91883-3>; Wed, 15 Mar 1995 15:54:19 +0200 Received: from localhost (petrin@localhost) by mits.mdata.fi (8.6.5/8.6.5) id PAA13258 for amiga-gcc-port@lists.funet.fi; Wed, 15 Mar 1995 15:54:13 +0200 From: Petri Nordlund Message-Id: <199503151354.PAA13258@mits.mdata.fi> Subject: Bug in aligned-attribute? To: amiga-gcc-port@nic.funet.fi Date: Wed, 15 Mar 1995 15:54:13 +0200 (EET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 423 Is there a bug in the aligned-attribute or am I doing something wrong: int main(int argc, char **argv) { short i; int x __attribute__ ((aligned (4))); printf( "%d\n", &x ); printf( "%d\n", __alignof__(x) ); } Outputs: 20266658 4 Looks OK, but 20266658 / 4 = 5066664.5, so x is NOT aligned to long word boundary as it should be. I'm using GCC 2.6.3. I don't know if this is Amiga-only or 68000-only bug/feature. From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:53 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91837-2>; Wed, 15 Mar 1995 14:26:54 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 15 Mar 1995 13:26:33 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10985; Wed, 15 Mar 95 13:26:34 +0100 Date: Wed, 15 Mar 95 13:26:34 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503151226.AA10985@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA07719; Wed, 15 Mar 95 13:26:34 +0100 To: amiga-gcc-port@nic.funet.fi Subject: Re: AmiTCP API gcc development. Hi, Christopher Masto writes: > Perhaps it's possible to have a seperate version of ixemul.library for > AmiTCP/AS225/NoNet such that ixemul-using programs need have no knowledge > of which is in use. I don't much like the idea of yet another ixemul.library. Fred Fish already has four of them (68000, 680x0 FPU or not, 68040) and having NoNet, AmiTCP and AS225 versions around would bring us two twelve (12!) possible versions, a nightmare for developers and users, software and installation scripts :-( I'd been dreaming of an ixemnet.library opened by ixemul.library to do the interface stub. There would be an ixemnet for AS225 and one for AmiTCP (maybe even DNet?). There would be no proliferation of ixemul libraries. I don't know how easy this could be or if it's not already made superfluous by the fact that there is an AS225->AmiTCP library (I forgot the name, maybe it's even the other way round), thus there could be just one ixemul with built-in AS225 and AmiTCP users would use the converter library. Peter Ivimey-Cook writes: > 1. Do people think it would be good to have a close integration of gcc > libraries and AmiTCP, to the exclusion of other networking libraries? If > not, Which other libraries would you want to support and where is the > documentation on them? Since AmiTCP switched from GNU status to a commercial package, I wonder how "compatible" is the integration of a GNU-copyrighted library or program (meaning full source is available, meaning the right to modify almost anything) with a commercial package like AmiTCP (or AS225) where programmers and users have very restricted rights. I remember AmiTCP30b2 disappearing from all FTP sites just because the AmiTCP group decided that its availability would harm their commercial 4.0. What if they decided you had to pay for the includes needed to make the library tomorrow? But I would find it weird to only include support for one networking package. Why only one? > and libnix? Does anyone know anything about the networking code in ixemul > - I seem to remember it tried to open "net.library" at one point, and has > certain net-ish include files. What are they from? This was the time of ixemul.library v 45 or 47. There existed versions with built-in AS225 and AmiTCP support. This was used by DaggeX (version around 0.9), a free X server for the Amiga. I don't know what's left of it in the current sources and who did this version. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:53 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91592-2> convert rfc822-to-8bit; Tue, 14 Mar 1995 20:06:22 +0200 Received: from flevel.demon.co.uk by gate.gate.demon.co.uk id af03762; 14 Mar 95 17:55 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA007kj; Tue, 14 Mar 95 14:18:32 GMT Date: Tue, 14 Mar 95 14:18:32 GMT Message-Id: <9503141418.AA007ki@flevel.demon.co.uk> Message-Id: <205966b5.ea602-dev@flevel.demon.co.uk> In-Reply-To: (from Peter Ivimey-Cook ) (at Tue, 14 Mar 1995 11:40:20 +0000 (GMT)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT From: dev@flevel.demon.co.uk To: peteric@insignia.co.uk Cc: stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi Subject: Re: Preprocessor problem Hi Peter, > refor S. wrote: > > > > > Surely the case should not matter on the Amiga because the file system > > is not case dependant :-) > > > But is 'make' case insensitive too? I too wasn't quite sure what the > problem was - perhaps the original poser could expand on it. Make is case sensitive but this does not make any difference as long as you don't have the same filename repeated twice with different cases. > However, as a general point, it would seem sensible to maintain the case > of files even if it doesn't actually matter re. the amiga file system. Yes, I agree. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:53 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91764-1>; Wed, 15 Mar 1995 12:33:18 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA11885 (5.65c8/IDA-1.4.4 for ); Wed, 15 Mar 1995 11:32:46 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA25621; Wed, 15 Mar 95 11:32:46 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503151032.AA25621@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: de.comp.sys.amiga.gcc To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Wed, 15 Mar 1995 11:32:46 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503141837.AA13560@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Mar 14, 95 07:37:52 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 358 > > Thus I ask myself (and you :-) if it wouldn't be a good idea to call > for a newsgroup comp.sys.amiga.gcc or comp.sys.amiga.programmer.gcc? > I can live with it as long as I can find this group on my local news-server :-). It'll reduce traffic in other lists and concentrate requests for help on gcc. And it'll clean my mailbox up. Why not. Matthias From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 16:14:53 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <91571-4>; Tue, 14 Mar 1995 16:40:00 +0200 Received: from tiny.lysator.liu.se (tiny.lysator.liu.se [130.236.253.10]) by konrad.lysator.liu.se (8.6.10/8.6.10) with ESMTP id PAA02165 for ; Tue, 14 Mar 1995 15:39:52 +0100 From: Niels M|ller Received: (nisse@localhost) by tiny.lysator.liu.se (8.6.10/8.6.10) id PAA05748; Tue, 14 Mar 1995 15:39:12 +0100 Date: Tue, 14 Mar 1995 15:39:12 +0100 Message-Id: <199503141439.PAA05748@tiny.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: amiga-gcc-port@nic.funet.fi Subject: Bug in objc compiler The objective-c compiler bug I wrote about is not amiga specific. Compiling my program (after first preprocessing it at home) on a sun4, running solaris2.4, gives the following message: sparc-sun-solaris2.4-gcc: Internal compiler error: program cc1obj got fatal signal 11 Does anybody know if it is fixed in 2.6.4? From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 18:16:01 1995 Received: from lamb.sas.com ([192.35.83.8]) by nic.funet.fi with SMTP id <91205-2>; Wed, 15 Mar 1995 18:09:10 +0200 Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA13102; Wed, 15 Mar 1995 11:08:34 -0500 Received: from cdevil.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA25913; Wed, 15 Mar 1995 11:05:55 -0500 Received: by cdevil.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA28350; Wed, 15 Mar 1995 11:05:54 -0500 From: James Cooper Message-Id: <199503151605.AA28350@cdevil.unx.sas.com> Subject: Re: AmiTCP API gcc development. (fwd) To: amiga-gcc-port@nic.funet.fi Date: Wed, 15 Mar 1995 11:05:54 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1241 > There seems to be a group of people interested in developing the > AmiTCP/IP development environment to work with gcc. Currently, the > libraries and files are targetted at SAS C. This is a GOOD thing. It will help GCC users write network clients, etc. > It would seem that the best way to go is a fairly close integration into > the ixemul and libnix libraries, but none of us seem sure who is > currently maintaining these libraries. So I have a couple of questions: This is a BAD thing. It would tie GCC owners to AmiTCP, and would make it that much harder to write network code for AS225, Envoy, DNet, Liana, or any other network solution *other* thatn AmiTCP. > 1. Do people think it would be good to have a close integration of gcc > libraries and AmiTCP, to the exclusion of other networking libraries? If > not, Which other libraries would you want to support and where is the > documentation on them? I say it would be a BAD idea. Some other networking libraries are commercial, some FD, etc., so documentation is spread all over the place. It would be much easier to write GCC code to handle what the SAS/C code does now, as far as AmiTCP goes, but KEEP IT SEPARATE from ixemul.library and libnix, as it is now. From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 18:32:32 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91165-2>; Wed, 15 Mar 1995 18:26:33 +0200 Received: by colombo.telesys-innov.fr; Wed, 15 Mar 1995 17:25:12 GMT From: Philippe BRAND Message-Id: <199503151725.RAA07546@colombo.telesys-innov.fr> Subject: Re: Bug in objc compiler To: nisse@lysator.liu.se (Niels M|ller) Date: Wed, 15 Mar 1995 17:25:11 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199503141439.PAA05748@tiny.lysator.liu.se> from "Niels M|ller" at Mar 14, 95 03:39:12 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 196 Niels M|ller writes: > Does anybody know if it is fixed in 2.6.4? Don't know: I don't have your program :-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 18:40:34 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91209-1>; Wed, 15 Mar 1995 18:29:30 +0200 Received: by colombo.telesys-innov.fr; Wed, 15 Mar 1995 17:26:32 GMT From: Philippe BRAND Message-Id: <199503151726.RAA07557@colombo.telesys-innov.fr> Subject: Re: GCC 2.6.4 To: se1dp@dmu.ac.uk (Derek Piper) Date: Wed, 15 Mar 1995 17:26:32 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Derek Piper" at Mar 13, 95 03:25:16 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 397 Derek Piper writes: > Does anybody know where on ftp.funet.fi the archives for GCC > 2.6.4 are ? Will they be placed on the Aminet soon ? These are BETA versions.... Only available on my site: ftp.telesys-innov.fr:/pub/amigados-gnu/beta or on nic.funet.fi (MUCH faster) nic.funet.fi:/pub/amiga/gnu/beta -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 18:45:18 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91262-2>; Wed, 15 Mar 1995 18:30:22 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA19849; Wed, 15 Mar 1995 16:29:46 GMT Date: Wed, 15 Mar 1995 16:27:45 +0000 (GMT) From: Peter Ivimey-Cook To: James Cooper Cc: amiga-gcc-port@nic.funet.fi Subject: Re: AmiTCP API gcc development. (fwd) In-Reply-To: <199503151605.AA28350@cdevil.unx.sas.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII James wrote: > > 1. Do people think it would be good to have a close integration of gcc > > libraries and AmiTCP, to the exclusion of other networking libraries? If > > not, Which other libraries would you want to support and where is the > > documentation on them? > > I say it would be a BAD idea. Some other networking libraries are > commercial, some FD, etc., so documentation is spread all over the place. > > It would be much easier to write GCC code to handle what the SAS/C code > does now, as far as AmiTCP goes, but KEEP IT SEPARATE from ixemul.library > and libnix, as it is now. Unfortunately, as far as I understand the code at present, this is very difficult to do possible in general, which is why I asked for *specific* other systems in my note. The ixemul code must be modified to underatand that amongst other things, file descriptors may refer to things other than files or terminals; unfortunately the implementation of sockets varies hugely, as do the calls and the nature of the args. Saying "we want to be able to use Any network library" is equivalent to saying we want to use any dos library, (which is basically what ixemul is) or any graphics library (e.g. an MIT X11 to Amiga graphics.library converter) - it is possible but only: a. when the general parameters of the other libraries are known in advance, b. at the cost in code space & time of another! ixemul-like conversion library. This intermediate library is likely to be difficult to write and would also very likely be quite large if it has to cope with the vagaries of many different styles of networking library and still provide complete networking support within ixemul itself. This is the reason I asked for specific examples & docs. If I am overstating the case please correct me. However, simply stating "I want everything" will not win the day! I *do* understand the wish to support things other than AmiTCP - but if this is to happen we need a practical way of doing it! Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 18:48:43 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91207-2>; Wed, 15 Mar 1995 18:37:47 +0200 Received: from jasmine.cms.dmu.ac.uk (jasmine.cms.dmu.ac.uk [146.227.102.16]) by macondo.dmu.ac.uk (8.6.11/8.6.11) with ESMTP id QAA25715; Wed, 15 Mar 1995 16:38:40 GMT Received: by jasmine.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA262735390; Wed, 15 Mar 1995 16:36:30 GMT Date: Wed, 15 Mar 1995 16:36:29 +0000 (GMT) From: Derek Piper X-Sender: se1dp@jasmine.cms.dmu.ac.uk To: Philippe BRAND Cc: Amiga-Gcc Liste Subject: Re: GCC 2.6.4 In-Reply-To: <199503151726.RAA07557@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Mar 1995, Philippe BRAND wrote: > Derek Piper writes: > > > Does anybody know where on ftp.funet.fi the archives for GCC > > 2.6.4 are ? Will they be placed on the Aminet soon ? > > These are BETA versions.... Only available on my site: > > ftp.telesys-innov.fr:/pub/amigados-gnu/beta > > or on nic.funet.fi (MUCH faster) > > nic.funet.fi:/pub/amiga/gnu/beta > Cheers, do you mean by BETA that they should not be used ? Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | World Wide Web Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Foolproof operation: All parameters are hard coded. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 18:53:03 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91362-1>; Wed, 15 Mar 1995 18:42:59 +0200 Received: by colombo.telesys-innov.fr; Wed, 15 Mar 1995 17:40:52 GMT From: Philippe BRAND Message-Id: <199503151740.RAA08094@colombo.telesys-innov.fr> Subject: Re: GCC 2.6.4 To: se1dp@dmu.ac.uk (Derek Piper) Date: Wed, 15 Mar 1995 17:40:50 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Derek Piper" at Mar 15, 95 04:36:29 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 320 Derek Piper writes: > Cheers, do you mean by BETA that they should not be used ? It means: - Test it asap - Report, even if it works ok - Do not flame me if your entire building explode while using beta version - Do not distribute -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 18:54:16 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91372-2>; Wed, 15 Mar 1995 18:47:19 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rowXG-0004nYC; Wed, 15 Mar 95 10:07 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: AmiTCP API gcc development. To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Wed, 15 Mar 1995 10:07:01 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503151226.AA10985@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Mar 15, 95 01:26:34 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2011 > I don't much like the idea of yet another ixemul.library. Fred Fish > already has four of them (68000, 680x0 FPU or not, 68040) and having > NoNet, AmiTCP and AS225 versions around would bring us two twelve > (12!) possible versions, a nightmare for developers and users, > software and installation scripts :-( Actually, my FreshFish CD has more than just four: ixemul.library 120216 ----rwed 05-Jan-95 11:41:18 ixemul.trace 144180 ----rwed 05-Jan-95 11:41:19 ixemul020.library 112172 ----rwed 05-Jan-95 11:41:20 ixemul020.trace 136156 ----rwed 05-Jan-95 11:41:21 ixemul020fpu.library 110248 ----rwed 05-Jan-95 11:41:22 ixemul020fpu.trace 134232 ----rwed 05-Jan-95 11:41:22 ixemul030.library 113168 ----rwed 05-Jan-95 11:41:21 ixemul030.trace 137152 ----rwed 05-Jan-95 11:41:21 ixemul030fpu.library 111244 ----rwed 05-Jan-95 11:41:23 ixemul030fpu.trace 135228 ----rwed 05-Jan-95 11:41:23 ixemul040fpu.library 111588 ----rwed 05-Jan-95 11:41:23 ixemul040fpu.trace 135572 ----rwed 05-Jan-95 11:41:24 I don't see any great problem with having multiple versions, as long as there are not multiple flavors of multiple versions. I.E. we don't want "Fred Fish's ixemul.library", "R. Luebbert's ixemul.library", "Phillipe Brand's ixemul.library", etc. I think it is very important that there be on master source repository. I'll be happy to act as that repository, if I can get all the people that are working on ixemul.library to send their changes to me. Otherwise I'll be happy to work with someone else if the developer base prefers it that way. > I'd been dreaming of an ixemnet.library opened by ixemul.library to do > the interface stub. There would be an ixemnet for AS225 and one for > AmiTCP (maybe even DNet?). There would be no proliferation of ixemul > libraries. I agree that a separate set of libraries is probably better than more combinatorial expansion of the number of ixemul versions. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 19:14:50 1995 Received: by nic.funet.fi id <91206-3>; Wed, 15 Mar 1995 19:10:54 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: networking interfaces, ixemul Message-Id: <95Mar15.191054+0200_eet.91206-3+19@nic.funet.fi> Date: Wed, 15 Mar 1995 19:10:49 +0200 Ixemul has built-in support for tcp/ip networking by using the library inet.library, which was distributed by CBM as part of AS 225r2. I'm not sure if that version was ever distributed to the public, but people not having it could still use ixemuls networking together with a library that replaced inet.library and used AmiTCP instead of AS225. To ixemul, this didn't matter. As long as there's a library "inet.library" available that is call-compatible with CBM's, ixemul is happy. It has no other knowledge of the underlying networking mechanism. It's up to the authors of the other C libraries to decide if they want to go through the trouble to provide unix source code comptaibility for tcp/ip sockets, or if they prefer incompatible source code. For ixemul hackers, it could be noted that it's not really necessary to open inet.library for each program. Instead, it is possible to point all networking function offsets to an "opener", which upon succesful open of inet.library patches the function vectors to the real functions. Compare how this is done for the math functions now. Using that approach, inet.library wouldn't be opened until a networking function is actually called, allowing non-net programs to live wihtout it altogether. Big deal. From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 19:24:18 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91210-4>; Wed, 15 Mar 1995 19:20:11 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA20275; Wed, 15 Mar 1995 17:20:04 GMT Date: Wed, 15 Mar 1995 17:18:03 +0000 (GMT) From: Peter Ivimey-Cook To: Leonard Norrgard Cc: amiga-gcc-port@nic.funet.fi Subject: Re: networking interfaces, ixemul In-Reply-To: <95Mar15.191054+0200_eet.91206-3+19@nic.funet.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Leonard, Re: > Ixemul has built-in support for tcp/ip networking by using the library > inet.library, which was distributed by CBM as part of AS 225r2. I'm > not sure if that version was ever distributed to the public, but > people not having it could still use ixemuls networking together with > a library that replaced inet.library and used AmiTCP instead of AS225. > To ixemul, this didn't matter. As long as there's a library > "inet.library" available that is call-compatible with CBM's, ixemul is > happy. It has no other knowledge of the underlying networking mechanism. Does anyone know of the docs on inet.library - if we can write a version which will patch through to the equivalent AmiTCP calls it seems a sensible way to go - no mods to ixemul being a Good Thing! Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 20:11:34 1995 Received: by nic.funet.fi id <91215-2>; Wed, 15 Mar 1995 20:04:42 +0200 From: Leonard Norrgard To: peteric@isltd.insignia.com CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Peter Ivimey-Cook on Wed, 15 Mar 1995 17:18:03 +0000 (GMT)) Subject: Re: networking interfaces, ixemul Message-Id: <95Mar15.200442+0200_eet.91215-2+27@nic.funet.fi> Date: Wed, 15 Mar 1995 20:04:33 +0200 > Does anyone know of the docs on inet.library - if we can write a version > which will patch through to the equivalent AmiTCP calls it seems a sensible > way to go - no mods to ixemul being a Good Thing! Docs for inet.library can be found in the ixemul.library source. AFAIK, there's no official documentation (probably because CBM thought anyone would ever need to actually call inet.library). There was/is a freeware library (also) called inet.library that routed the calls to AmiTCP. If someone has a copy of the AmiTCP 3.02b distribution (still under the GPL), let's put it up for FTP. Likewise for the amitcp inet.library. I don't think it's a good idea to spend programming time on supporting AmiTCP 4 (let the AmiTCP company do it if they wan't poeple to program for their library). -- vinsci From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 21:25:02 1995 Received: from crew.umich.edu ([141.211.184.10]) by nic.funet.fi with SMTP id <91264-4>; Wed, 15 Mar 1995 21:21:08 +0200 Received: from uri.crew.umich.edu by crew.umich.edu (8.6.10/2.2) with ESMTP id OAA24815; Wed, 15 Mar 1995 14:20:56 -0500 Received: from localhost by uri.crew.umich.edu (8.6.10/dumb-1.0) id OAA09385; Wed, 15 Mar 1995 14:20:55 -0500 Message-Id: <199503151920.OAA09385@uri.crew.umich.edu> To: too@nsdi.fi cc: peteric@isltd.insignia.com, joel@partech.com, amitcp-group@nsdi.fi, amiga-gcc-port@nic.funet.fi Subject: I've done a port of GCC and AmiTCP includes for compatablity. Date: Wed, 15 Mar 1995 14:20:55 -0500 From: Charles Hymes Frist, I appologise in advance for any incomprehensile things I may see here. Ive got a very bad cold, and I cant seem to thik well. Before my important hacking was cut short by the triviality of my dissertation, I got the AmiTCP API to compile under GCC. The source is avalable at http://geneva.crew.umich.edu:80/~chymes/Outbox/AmiTCP-4.0-sdk-gnu.lha The most important file is AmiTCP-4.0/src/netlib-raw/changelog, which records what I had to do to get it to compile. I'm including that file at the end of this message. The most important issue for me in all of this is that regardless of what happens to ixemul.lib, GCC or AmiTCP, the point is to get unix networking APPLICATIONS to compile with a minimum of changes. I want the WAIS, Gopher, and http servers to compile, and to be as similar as possible to the "standard" versions. The easier this is, the more of them will be available. If we have to change, or provide a large number of differnt ixemuls, to go along with the users networking software, that is better than every application be ported to every networking option. To me the whole point of GCC's value is to get an application, type "cofigure", then make, and that's it. No one wants to have to distribute a differnt binary for every networking option. Charlweed P.S. So Tomi how do I get my AMITCP commercial version? Sun 30-Oct-94 14:42:36 > Createed Makefile and MakeGNUProtos Sun 30-Oct-94 14:43 > Created GNU-Defines to define macros that SAS does Sun 30-Oct-94 14:51:10 > Put __VERSION__ and __REVISION__ in macro file Sun 30-Oct-94 15:01:07 > Lines like RCS_ID_C="$Id: strerror.c,v 4.1 1994/09/29 23:09:02 jraja Exp $"; kill the compiler. So I defined RCS_ID_C as a macro to make it diassapear. Sun 30-Oct-94 15:33:01 > In files netinclude/unstd.h and netinclude/clib/netlib_protos.h changed prototypes of select to match inlined function Sun 30-Oct-94 15:58:46 > Changed autoinit.c to not use sizeof in preprocessor Sun 30-Oct-94 16:58:00 > Changed prototype of netinclude/clib/netlib_protos.h to match inlined Sun 30-Oct-94 20:55:10 > Manx can't define a #define, so I copied all the source excluding the RCS stuff. Sun 30-Oct-94 22:44:52 > defined df_set as void because netinclude/inlines/socket.h caused errors. I cnt figure out what an fd_set is, or where it is defined. Actually, I cnd find where WaitSelect() is defined either. Sun 30-Oct-94 23:03:47 > stdio.h wants include files sys/commsize.h sys/commlist.h sys/commnull.h They don't exist. I define commsze,commlist & commnull so they dont get included Mon 31-Oct-94 00:01:16 > stdio.h changed to include stdargs.h when usung gcc ( or manx) Mon 31-Oct-94 00:01:16 > ENDSTREAMCH defined as (-1) it's a reasonable guess. Mon 31-Oct-94 00:12:01 > changed sys/type.h to conditional defintion of u_char etc Mon 31-Oct-94 00:17:45 > Ah Ha! so sys/types.h is where fdset is declared. Well, inlines/socket.h needs to include it. Mon 31-Oct-94 00:31:04 > The stubs interfere with the inline definitions. Added INLINE_SOCKET_H to stubs.c to fix. Changed type of select to return LONG and nfds LONG to match clib/netlib_protos.h Mon 31-Oct-94 09:22:37 > The file sys/fctl.h tries to include sys/commifmt.h This does not exist, so I define COMMIFMT_H to prevent. > netinclude/unistd.h does not match inline prototype. So I added #indef INLINE_SOCKET_H to it. > same story for clib/netlib_protos.h Mon 31-Oct-94 18:52:00 > Yet another problem with including both the prototypes and the includes. This time /gnu/os-include/inline/dos.h defines something, which ruins the inclusion of /gnu/os-include/proto/dos.h. So I added the line #define CLIB_DOS_PROTOS_H to inline/dos.h Mon 31-Oct-94 19:25:00 > I defined __interrupt to nothing in order to get popen.c to compile on gcc. I expect this breaks it. Something to fix guys! Mon 31-Oct-94 19:44:03 > ios1.h is a SAS specific file. So I added a conditional include to netinclude/ios1.h so _dup will compile. Mon 31-Oct-94 19:53:00 > dos.h is not found. So I'm adding sys/ to the search path Mon 31-Oct-94 21:18:44 > ufbflg is not defined except on SAS. So I hacked together a definition, and put it in ios1.h Tue 01-Nov-94 16:03:01 > stdio changed to include gnu:include/stdio.h if using GCC Thu 03-Nov-94 16:56:56 > created exterm struct UFB *__ufbs and *__nufbs in file ios1.h Thu 03-Nov-94 17:14:49 > Defined UFB_SOCK UFB_WA and UFB_RA to get _chkbuf to compile. This surely breaks it. Thu 03-Nov-94 17:23:49 > Defined UFB_NC UFB_CLO UFB_TEMP to get _close to compile. This surely breaks it. Thu 03-Nov-94 17:33:19 > Defined a bunch of defines to get _open to compile. This surely breaks it. Thu 03-Nov-94 17:49:46 > isatty is defined as a macro which conflicts with the real defiinition in isatty.c. So I undefine the macro. I think this should be handeled with a smarter conditional compilation directive in fcntl.h. Thu 03-Nov-94 18:21:34 > First sucessful compilation of netlib. Now, repeat without USEIO Thu 03-Nov-94 18:22:17 > Need to get smarter about conflicts between os-include and gnu-include. Thu 03-Nov-94 18:22:17 > I hacked at gnu:include and include:stdio.h to reconsile them. Hopefully most users won't have to. Thu 03-Nov-94 19:03:43 > Now there is a conflict between the prototypes declared in the standard includes and thoese in netinclude/clib/netlib_protos.h. There was not an underscore after _STDIO_H_. A hope this is not GCC specific Fri 04-Nov-94 12:18:03 > the macro defintion of sys_nerr confliceted with gcc:include/stdio.h, so I added the condition __GNUC__ to errno.h Fri 04-Nov-94 12:36:15 > The popen pclose stuff is too complicated. The gnu:include/stdio.h file should not have the prototypes defined it it. Oh well. I added conditional lines to gnu:include/stdio.h to allow those prototypes to be skipped, and defined SKIP_GNUC_POPEN and SKIP_GNUC_PCLOSE in the global macros. I hate modifying the GNU includes, but I don't see a cleaner way. Fri 04-Nov-94 13:52:40 > Popen uses DOSBase without defining it. Hmm, so I guess I SASC defines *DOSBase for each object file? So I define it. Fri 04-Nov-94 13:02:08 > access.c uses the macros R_OK W_OK and X_OK, and they are not defined if USE_DOSIO is not defined. Hmm, well, to get to to compile. I will add them to the global macro. But I am also going to edit the Makefile so they will not be compiled unless asked for with USE_DOSIO. I need a list of the files which all go together with USE_DOSIO Sat 05-Nov-94 16:23:43 > Now that I'm trying to compile stuff, I see some things are still missing. In order to compile with AMITCP you need the netincludes. But in the netincludes are included, than alot og GCC stuff is not. So I am making several files include the gcc includes if GCC is the compiler. Sat 05-Nov-94 16:53:21 > Found GNU copyies of R_OK etc. So I can remove them from the global define. Be sure to define __AMITCP__ when compiling. From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 21:55:38 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91164-4>; Wed, 15 Mar 1995 21:53:17 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rozVG-0004nYC; Wed, 15 Mar 95 13:17 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: large GNU executables (revisited) To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Wed, 15 Mar 1995 13:17:10 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish), phb@colombo.telesys-innov.fr (Philippe BRAND) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4097 Sometime back I posted a message to this list about problems I was having running large GNU executables. Since I hadn't gotten a resolution of this problem, I decided to bite the bullet and tackle it myself. First off, I found by writing a simple program that just tried to LoadSeg() the executable, that it was LoadSeg that was failing. LoadSeg returned 0, and IoErr() afterwards returned -1. Strange. So I then wrote a hunk dumper and examined the file structure in detail, while also reading the appropriate chapter of "The Amiga Guru Book". This line caught my eye: "For compatibility with 2.0, the number of offsets per hunk number must not exceed 65536. Hmmm... So I went back and looked at a dump of the gnat1 executable that did work, and sure enough, that one had 64468 relocs for the text section, and the one that failed had 68444. Although the Guru Book didn't explicitly say that this "bug" affected versions after 2.0, I figured it was a pretty good guess that it might. It took about an hour to understand the relevant linker code due to our favorite hacker's zero-tolerance for comments :-), and about ten minutes to fix it to split large reloc tables into 65536 or less sized chunks. I then rebuild ld, rebuilt gnat1, and it now works. Here is the patch I applied to ld.c in binutils 1.8.x. I'm pretty sure that the similar fix for the bfd based linker will be much uglier, if even possible. If not possible, a simple executable postprocessor should suffice, since this is a rare problem (and the bfd linker should warn about excess relocs). -Fred diff -rc gnu-work:gnu/src/amiga/binutils-1.8.x/ld.c binutils-1.8.x/ld.c *** gnu-work:gnu/src/amiga/binutils-1.8.x/ld.c Sun Aug 21 18:39:46 1994 --- binutils-1.8.x/ld.c Wed Mar 15 12:01:14 1995 *************** *** 7009,7015 **** * subhunks can be output only after the {code,data}-Hunks, AND there * can be more than one after each of them */ ! long *hunk_rel_tab[3], hunk_rel_tab_size[3], hunk_rel_tab_index[3]; void init_reloc_hunk() --- 7009,7017 ---- * subhunks can be output only after the {code,data}-Hunks, AND there * can be more than one after each of them */ ! long *hunk_rel_tab[3]; /* Dynamically allocated tables of relocs */ ! long hunk_rel_tab_size[3]; /* Size (in longs) of allocation of each table */ ! long hunk_rel_tab_index[3]; /* Index of next free table entry */ void init_reloc_hunk() *************** *** 7063,7069 **** write_reloc_hunk() { int i, j; ! long *tab, size, index; /* only write a hunk-header & -end, if we really output some relocs */ int did_start_hunk = 0; --- 7065,7071 ---- write_reloc_hunk() { int i, j; ! long *tab, size, index, nwritten, nleft, nwrite; /* only write a hunk-header & -end, if we really output some relocs */ int did_start_hunk = 0; *************** *** 7092,7097 **** --- 7094,7100 ---- else j++; } + hunk_rel_tab_index[i] = index; if (!did_start_hunk++) { *************** *** 7099,7108 **** mywrite(&j, 1, sizeof(long), outstream); } ! mywrite(&index, 1, sizeof(long), outstream); ! mywrite(&i, 1, sizeof(long), outstream); ! mywrite(tab, 1, index*sizeof(long), outstream); ! hunk_rel_tab_index[i] = index; } } if (did_start_hunk) --- 7102,7124 ---- mywrite(&j, 1, sizeof(long), outstream); } ! /* Starting apparently with AmigaDOS 2.0, the number of ! offsets per hunk number must not exceed 65536. So ! split large tables into smaller ones. */ ! nwritten = 0; ! nleft = index; ! do ! { ! nwrite = min (nleft, 65536); ! if (trace_files) ! fprintf (stderr, "wrh: nwritten %d, nleft %d, nwrite %d\n", ! nwritten, nleft, nwrite); ! mywrite(&nwrite, 1, sizeof(long), outstream); ! mywrite(&i, 1, sizeof(long), outstream); ! mywrite(tab + nwritten, 1, nwrite*sizeof(long), outstream); ! nwritten += nwrite; ! nleft -= nwrite; ! } while (nleft > 0); } } if (did_start_hunk) From amiga-gcc-port-owner@nic.funet.fi Wed Mar 15 22:35:17 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <91274-2>; Wed, 15 Mar 1995 22:31:08 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id VAA23400; Wed, 15 Mar 1995 21:28:25 +0100 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id VAA05157; Wed, 15 Mar 1995 21:13:44 +0100 Date: Wed, 15 Mar 1995 21:13:44 +0100 From: Niklas Hallqvist Message-Id: <199503152013.VAA05157@linda.appli.se> To: fleischr@izfm.uni-stuttgart.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9503141113.AA23237@sunserv.IZFM.Uni-Stuttgart.DE> (fleischr@izfm.uni-stuttgart.de) Subject: Re: even more about stack extension >>>>> "Matthias" == Matthias Fleischer writes: Matthias> Hello everybody, after some investigation in the gcc sources Matthias> (to find the location of alloca) I found some conditional Matthias> compilation with the following defines (explow.c): Matthias> HAVE_save_stack_block (memorize sp at the start of a block) Matthias> HAVE_save_stack_function (at function entry) Matthias> HAVE_save_stack_nonlocal (alloca & variable sized arrays?) Matthias> HAVE_restore_stack_block (restore stack pointer from the Matthias> above) HAVE_restore_stack_function Matthias> HAVE_restore_stack_nonlocal HAVE_allocate_stack (allocate Matthias> some stackspace) (all together with a matching gen_* macro) Matthias> I think they are meant for systems where stack extension is Matthias> nontrivial. Isn't this exactly what we need? How do I tell Matthias> gcc to insert the right code? And what code should I use? If you are seriously interested in hacking GCC you should probably join gcc2@cygnus.com (I'd guess the subscription request address is gcc2-request@cygnus.com, but I don't really remember). The list isn't open to every single soul, but rather people who actively do work on GCC, either code, ports or tests otherwise untested platforms. You should state why you want to get on the list in the subscription request. When you're on the list, you're also entitled to get GCC snapshots if you want to work on current code. Ask me or Philippe where to get them once you're on gcc2. Anyway, if this query of yours doesn't generate useful answers for you, try mailing it to gcc2. This you can do anyway, even if you're not on the list. Just tell the responders to be sure to include you in the reply as you aren't on the list. BTW. I mailed this to amiga-gcc-port in order to explain to other parties interested in active work on GCC who to do. "Just" beta-testing of the Amiga port doesn't count as "work" I'd guess. That's what this list (amiga-gcc-port) is for. Don't get me wrong, such work is of course valuable as well. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Thu Mar 16 10:45:10 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91159-4>; Thu, 16 Mar 1995 10:42:33 +0200 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA17884 (5.65c-6/7.3w-FAU); Thu, 16 Mar 1995 09:42:26 +0100 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id JAA20352 (8.6.10/7.4a-FAU); for ; Thu, 16 Mar 1995 09:42:21 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA19525; Thu, 16 Mar 1995 09:42:19 +0100 Date: Thu, 16 Mar 1995 09:42:19 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9503160842.AA19525@pctc.chemie.uni-erlangen.de> To: amiga-gcc-port@nic.funet.fi Subject: stackoverflow Hello, recently I installed the macro processor m4 on our UNIX machine (a rs6000 running AIX) and on the Amiga. This macro processor may use much memory and so they included code to check for stack overflow. The code is in the file stackovf.c . The short description says that they try to watch the stack pointer. If it is close to the end of the stack they generate a SIGSEGV. Perhaps it is worth for those of you working on a stack extension to have a look at this to give you another idea. PS: I succeded in compiling m4 for the amiga. It passes all the checks shipped with the archive, except check 53.esyscmd and check 54.syseval. I hope this helps a bit bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Thu Mar 16 11:08:21 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91188-1>; Thu, 16 Mar 1995 11:05:40 +0200 Received: by colombo.telesys-innov.fr; Thu, 16 Mar 1995 10:04:19 GMT From: Philippe BRAND Message-Id: <199503161004.KAA10297@colombo.telesys-innov.fr> Subject: Re: even more about stack extension To: niklas@appli.se (Niklas Hallqvist) Date: Thu, 16 Mar 1995 10:04:18 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199503152013.VAA05157@linda.appli.se> from "Niklas Hallqvist" at Mar 15, 95 09:13:44 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 494 Niklas Hallqvist writes: > If you are seriously interested in hacking GCC you should probably > join gcc2@cygnus.com (I'd guess the subscription request address is > gcc2-request@cygnus.com, but I don't really remember). Then I can provide latests diffs against snapshots. I plan to have a http daemon installed on colombo in a very near future, could somebody write a nice url for me about amigados-gnu ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB From amiga-gcc-port-owner@nic.funet.fi Thu Mar 16 15:48:59 1995 Received: from cardhu.cs.hut.fi ([130.233.192.95]) by nic.funet.fi with SMTP id <91390-4>; Thu, 16 Mar 1995 12:31:47 +0200 Received: by cardhu.cs.hut.fi id AA16126 (5.65c8/HUTCS-C 1.3 for amiga-gcc-port@nic.funet.fi); Thu, 16 Mar 1995 12:31:11 +0200 Date: Thu, 16 Mar 1995 12:31:11 +0200 Message-Id: <199503161031.AA16126@cardhu.cs.hut.fi> From: Tomi Ollila Reply-To: To: Peter Ivimey-Cook Cc: amiga-gcc-port@nic.funet.fi Subject: Re: networking interfaces, ixemul In-Reply-To: References: <95Mar15.191054+0200_eet.91206-3+19@nic.funet.fi> Peter Ivimey-Cook writes: > Leonard, > > Re: > > > Ixemul has built-in support for tcp/ip networking by using the library > > inet.library, which was distributed by CBM as part of AS 225r2. I'm > > not sure if that version was ever distributed to the public, but > > people not having it could still use ixemuls networking together with > > a library that replaced inet.library and used AmiTCP instead of AS225. > > To ixemul, this didn't matter. As long as there's a library > > "inet.library" available that is call-compatible with CBM's, ixemul is > > happy. It has no other knowledge of the underlying networking mechanism. > > Does anyone know of the docs on inet.library - if we can write a version > which will patch through to the equivalent AmiTCP calls it seems a sensible > way to go - no mods to ixemul being a Good Thing! AS225 comes with inet.library and socket.library. inet.library handles some of the lower-level stuff and socket.library provides normal BSD socket API to the programmers. We just wonder where they had that change to break those things apart, since We'd figure socket stuff goes deep into inet.library code... maybe looking the ixemul.library code would clear some thoughts up. I used to think how ixemul.library coule be broken into many separate sublibraryes, which are then loaded on demand. The whole library base would be present, but the LVO:s which code is not already loaded, points to the function that does the loading of the corresponding sublibrary. Perhaps the greatest problem comes with some globals that keep the whose system up (either direct or baserelative). All the globals needed by all sublibraries should be but in a single space pointed by one address register (hmm, in a library base) and all references to these globals should be renamed to use this global data pointer and then indirectly reference the needed global. Normal global reference cannot be used (unless it is sublibrary spesific) since each load module redefines these globals in their own context and/or therefore sublibraries could not be delevoped separately. If there is interest to develop / test this approach in ixemul development I'd like to put some development effort on this. (un)fortunately the modern operating systems solves these problems using virtual memory/ dynamic link libraries (not all of these, though). > > Regards, > > Peter Ivimey-Cook. Tomi From amiga-gcc-port-owner@nic.funet.fi Thu Mar 16 15:48:59 1995 Received: from cardhu.cs.hut.fi ([130.233.192.95]) by nic.funet.fi with SMTP id <91483-4>; Thu, 16 Mar 1995 13:57:03 +0200 Received: by cardhu.cs.hut.fi id AA16601 (5.65c8/HUTCS-C 1.3 for amiga-gcc-port@nic.funet.fi); Thu, 16 Mar 1995 13:56:44 +0200 Date: Thu, 16 Mar 1995 13:56:44 +0200 Message-Id: <199503161156.AA16601@cardhu.cs.hut.fi> From: Tomi Ollila Reply-To: To: Peter Ivimey-Cook Cc: Tomi Ollila , amiga-gcc-port@nic.funet.fi Subject: Re: networking interfaces, ixemul In-Reply-To: References: <199503161031.AA16126@cardhu.cs.hut.fi> Peter Ivimey-Cook writes: > Tomi wrote: > > > I used to think how ixemul.library coule be broken into many separate > > sublibraryes, which are then loaded on demand. The whole library base would > > be present, but the LVO:s which code is not already loaded, points to the > > function that does the loading of the corresponding sublibrary. > > The approach is practical, although you would have to have many stub > functions in order to tell which of the newly-loaded library's functions > to call; you can't use the pc to infer this as the stacked return address > will not point to the function table. The stub functions could be as > simple as oushing the LVO onto the stack though. Now I am in a hurry, but I get back to this issue. Now fast. put jsr instead of jmp in that LVO call. The table needs to be created by hand (or change those jsr:s afterwards, and some kludgeing must be done... but this amiga specific anyway... > Regards, > > Peter Ivimey-Cook. > Tomi From amiga-gcc-port-owner@nic.funet.fi Thu Mar 16 15:48:59 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91444-4>; Thu, 16 Mar 1995 13:11:02 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA25045; Thu, 16 Mar 1995 11:10:41 GMT Date: Thu, 16 Mar 1995 11:08:36 +0000 (GMT) From: Peter Ivimey-Cook To: Tomi Ollila Cc: amiga-gcc-port@nic.funet.fi Subject: Re: networking interfaces, ixemul In-Reply-To: <199503161031.AA16126@cardhu.cs.hut.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Tomi wrote: > AS225 comes with inet.library and socket.library. inet.library handles some > of the lower-level stuff and socket.library provides normal BSD socket API > to the programmers. We just wonder where they had that change to break those > things apart, since We'd figure socket stuff goes deep into inet.library > code... maybe looking the ixemul.library code would clear some thoughts up. I've been a bit busy of late, but I did manage to down load the ixemul 40.4 source in order to look at the code and any docs. I'll get on to it ASAP. > I used to think how ixemul.library coule be broken into many separate > sublibraryes, which are then loaded on demand. The whole library base would > be present, but the LVO:s which code is not already loaded, points to the > function that does the loading of the corresponding sublibrary. The approach is practical, although you would have to have many stub functions in order to tell which of the newly-loaded library's functions to call; you can't use the pc to infer this as the stacked return address will not point to the function table. The stub functions could be as simple as oushing the LVO onto the stack though. > Perhaps the greatest problem comes with some globals that keep the whose > system up (either direct or baserelative). All the globals needed by all > sublibraries should be but in a single space pointed by one address > register (hmm, in a library base) and all references to these globals > should be renamed to use this global data pointer and then indirectly > reference the needed global. Normal global reference cannot be used (unless > it is sublibrary spesific) since each load module redefines these globals > in their own context and/or therefore sublibraries could not be delevoped > separately. I guess in such a system the loaded code segs probably shouldn't be fully fledged libraries, although I can see that they could be. It just seems easier to simply LoadSeg the relevant code portions. Do you think there would be significant gains in being able to load "arbitrary" libraries (of course they would have to conform to some standard, as the xpr libraries do). Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Thu Mar 16 15:48:59 1995 Received: from zaz.kom.auc.dk ([130.225.51.10]) by nic.funet.fi with SMTP id <91527-4>; Thu, 16 Mar 1995 15:09:30 +0200 Received: from skoda.kom.auc.dk by zaz.kom.auc.dk with smtp (Smail3.1.28.1 #2) id m0rpFIX-000DL2C; Thu, 16 Mar 95 14:09 MET Received: by skoda.kom.auc.dk (Smail3.1.28.1 #2) id m0rpFIX-0008J6C; Thu, 16 Mar 95 14:09 MET Message-Id: Date: Thu, 16 Mar 95 14:09 MET From: jds@kom.auc.dk (Jes Degn Soerensen) To: Philippe BRAND Cc: nisse@lysator.liu.se (Niels M|ller), amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Subject: Re: Bug in objc compiler In-Reply-To: <199503151725.RAA07546@colombo.telesys-innov.fr> References: <199503141439.PAA05748@tiny.lysator.liu.se> <199503151725.RAA07546@colombo.telesys-innov.fr> Philippe BRAND writes: > Niels M|ller writes: > > > Does anybody know if it is fixed in 2.6.4? > > Don't know: I don't have your program :-) Don't know either, but we had the same problem here with gcc-2.6.3. It was solved by compiling libobjc without optimizer-flags. Have someone tried that on Amiga gcc? Jes From amiga-gcc-port-owner@nic.funet.fi Thu Mar 16 16:01:44 1995 Received: from EKU.ACS.EKU.EDU ([157.89.8.64]) by nic.funet.fi with ESMTP id <91550-3>; Thu, 16 Mar 1995 15:50:11 +0200 Received: from ACS.EKU.EDU by ACS.EKU.EDU (PMDF V4.3-7 #7621) id <01HO74HCOACW00EHRW@ACS.EKU.EDU>; Thu, 16 Mar 1995 08:43:44 EST Date: Thu, 16 Mar 1995 08:43:44 -0500 (EST) From: AISTERWI@ACS.EKU.EDU Subject: ASL file requestor pgm compile To: amiga-gcc-port@nic.funet.fi Message-id: <01HO74HCPCXU00EHRW@ACS.EKU.EDU> X-VMS-To: IN%"amiga-gcc-port@nic.funet.fi" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Is it possible with GCC 2.6.3 to compile a program such as the sample filereq.c program in the RKM sources which uses an ASL requestor? I get all sorts of errors in the header includes when trying to compile it. The gcc readme talks about converting FD headers to inline (which I do not have). How do I get a program to use the ASL file requestor with gcc? Thanks, Earl Terwilliger aisterwi@acs.eku.edu From amiga-gcc-port-owner@nic.funet.fi Thu Mar 16 16:42:26 1995 Received: from afrodite.kih.no ([158.36.9.69]) by nic.funet.fi with ESMTP id <91185-1>; Thu, 16 Mar 1995 16:37:06 +0200 Received: by afrodite.kih.no (1.37.109.15/16.2) id AA042214432; Thu, 16 Mar 1995 15:33:52 +0100 Date: Thu, 16 Mar 1995 15:33:51 +0100 (MET) From: Erik Johannessen To: AISTERWI@ACS.EKU.EDU Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ASL file requestor pgm compile In-Reply-To: <01HO74HCPCXU00EHRW@ACS.EKU.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 16 Mar 1995 AISTERWI@ACS.EKU.EDU wrote: > Is it possible with GCC 2.6.3 to compile > a program such as the sample filereq.c program > in the RKM sources which uses an ASL requestor? Are you sure you are using the files that was included with gcc. If you installed the proto directory from the Commodore includes you should install the os-includes/proto directory from the gcc distribution. > I get all sorts of errors in the header includes > when trying to compile it. The gcc readme talks > about converting FD headers to inline (which I > do not have). This shouldn't be necessary. > How do I get a program to use the ASL file > requestor with gcc? Follow the example in RKM:Libraries. I haven't had any problems with the RKM examples. -Erik From amiga-gcc-port-owner@nic.funet.fi Thu Mar 16 17:56:05 1995 Received: from EKU.ACS.EKU.EDU ([157.89.8.64]) by nic.funet.fi with ESMTP id <91278-2>; Thu, 16 Mar 1995 17:46:18 +0200 Received: from ACS.EKU.EDU by ACS.EKU.EDU (PMDF V4.3-7 #7621) id <01HO78QEIVZK00D1N4@ACS.EKU.EDU>; Thu, 16 Mar 1995 10:44:00 EST Date: Thu, 16 Mar 1995 10:44:00 -0500 (EST) From: AISTERWI@ACS.EKU.EDU Subject: Header files for ASL requestor To: amiga-gcc-port@nic.funet.fi Message-id: <01HO78QEKRHU00D1N4@ACS.EKU.EDU> X-VMS-To: IN%"amiga-gcc-port@nic.funet.fi" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I do have the GCC include library installed and it has the protos. I have the RKM sources from the fish disk but no documentation :( The filereq.c program has the following includes: #include #include #include #include #include #include What do I change them to in order for GCC to work? Thanks, Earl From amiga-gcc-port-owner@nic.funet.fi Fri Mar 17 00:06:27 1995 Received: from unixg.ubc.ca ([137.82.27.14]) by nic.funet.fi with SMTP id <91410-4>; Thu, 16 Mar 1995 19:32:05 +0200 Received: from interchg.ubc.ca by unixg.ubc.ca (8.6.10/1.14) id JAA20336; Thu, 16 Mar 1995 09:31:24 -0800 Date: Thu, 16 Mar 1995 09:31:22 -0800 (PST) From: Warren Van Winckel X-Sender: warrenvw@interchg.ubc.ca To: amiga-gcc-port@nic.funet.fi Subject: C++ Compiler In-Reply-To: <01HO74HCPCXU00EHRW@ACS.EKU.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello all, I have a question regarding getting the C++ compiler to work. I can't use the G++-020 compiler yet. The libg++ file (in the 2.6.3 release of GNU GCC says to make all. I do this and my computer stalls. I apologize for any specifics, and I have tried all I know. Nothing seems to be working. In simple language, is there anything I should do? i.e. Compile the g++-020 file or what? How would I do this? I would think that the compiler would be ready to work (like gcc-020 = which I understand is simply C as it doesn't conform to C++ standards) but it isn't. I am lost... Thanks in advance for any help. Warren ................................................................. : "The brain is wonderful; it starts working the moment you get : : up in the morning and doesn't stop until you get to work." : .................... warrenvw@unixg.ubc.ca .... \/\/\/\/\/ ...... From amiga-gcc-port-owner@nic.funet.fi Fri Mar 17 00:06:27 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91414-1>; Thu, 16 Mar 1995 19:40:36 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id aa01955; 16 Mar 95 17:14 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA0008k; Thu, 16 Mar 95 11:12:49 GMT Date: Thu, 16 Mar 95 11:12:49 GMT Message-Id: <9503161112.AA0008j@flevel.demon.co.uk> Message-Id: <205bde2b.13881-dev@flevel.demon.co.uk> In-Reply-To: (from Walter Harms ) (at Wed, 8 Mar 1995 00:05:52 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: Walter.Harms@arbi.informatik.uni-oldenburg.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Help - Pipes and things Hi Walter, After looking at the pipe code you sent me I realised that using temporary files (instead of PIPE:) is a good idea for writing portable code. I wrote a new pipe called "fancy pipe" which as the functions: FILE* fpopen(char* filename,char* mode); void uclose(FILE* handle); These act as normal file open/close functions on standard file names and work with pipes, for example: FILE* han=fpopen("|list #?","r"); Gives a pipe from the list command: FILE* han=fpopen("|sort { }|list #?","r"); Gives a sorted pipe from the list command, '{' and '}' are used to give the filename of the input and output data stream. FILE* han=fpopen("|tee backup|sendmail","w"); Opens a pipe to a file handle which sends an email and saves a backup to the file 'backup'. FILE* han=fpopen("|join {[sort { }|list c:] {[sort { }|list s:] as }","r"); Opens a file handle to a file which is a sorted directory of c: joined to a sorted directory of s: (All files opened with fpopen must be closes with uclose). Anyway, my problem with pipes is now solved, if anyone is interested in "fancy pipe" I'll upload a copy to aminet. Thanks, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Mar 17 00:06:27 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <91385-3>; Thu, 16 Mar 1995 18:54:56 +0200 Received: by theseas.ntua.gr with UUCP; Thu, 16 Mar 1995 18:52:47 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06oj@kriton.UUCP>; Thu, 16 Mar 95 18:41:34 EET Date: Thu, 16 Mar 95 18:41:34 EET Message-Id: <9503161641.06oj@kriton.UUCP> In-Reply-To: <01HO74HCPCXU00EHRW@ACS.EKU.EDU> (from AISTERWI@ACS.EKU.EDU) (at Thu, 16 Mar 1995 08:43:44 -0500 (EST)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 991 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: AISTERWI@ACS.EKU.EDU Cc: amiga-gcc-port@lists.funet.fi Subject: Re: ASL file requestor pgm compile Hi AISTERWI (AISTERWI), in <01HO74HCPCXU00EHRW@ACS.EKU.EDU> on Mar 16 you wrote: > I get all sorts of errors in the header includes > when trying to compile it. The gcc readme talks Actually, they are warnings--the file compiles correctly. To make the code compile without getting any warnings, substitute the two lines: #include #include with: #include #include This will eliminate all the warnings except one. To eliminate the last one, make main() int instead of void, and add a "return 0;" before main()'s closing brace. BTW, these changes are also appropriate for SAS/C (though SAS/C prints a warning about the empty statement at the beginning of the file). I hope this helps, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Logic, my dear Zoe, merely enables one to be wrong with authority." ----- From amiga-gcc-port-owner@nic.funet.fi Fri Mar 17 00:06:27 1995 Received: from undergrad.math.uwaterloo.ca ([129.97.204.13]) by nic.funet.fi with SMTP id <91519-1>; Thu, 16 Mar 1995 22:38:58 +0200 Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57081-1>; Thu, 16 Mar 1995 15:38:14 -0500 Date: Thu, 16 Mar 1995 15:38:00 -0500 From: Nathaniel Myhre To: amiga-gcc-port@nic.funet.fi Subject: More gcc bugs... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've run into another bug in gcc. I posted a list of bugs I had found previously and I received no reply concerning them. Does this mean no one cares or should I be posting these somewhere else? Can someone please give me some feedback like, yes I've run into the bug or no I haven't. Try this: declare a structure of the following form: struct test{ unsigned char a : 4; unsigned char b : 4; }; A sizeof(struct test) returns 2 instead of 1 (it only takes up 1 byte!). I'm using gcc 2.6.3 by the way. ----------------------------------------------------------- Nathaniel Myhre University of Waterloo, 4th year CS undergraduate nmmyhre@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~nmmyhre/ "Of all the things I lost, I miss my mind the most." ----------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Fri Mar 17 01:35:30 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91273-2>; Fri, 17 Mar 1995 01:32:07 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rpPPU-0004nYC; Thu, 16 Mar 95 16:56 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: More gcc bugs... To: nmmyhre@undergrad.math.uwaterloo.ca (Nathaniel Myhre) Date: Thu, 16 Mar 1995 16:56:56 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Nathaniel Myhre" at Mar 16, 95 03:38:00 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 571 > struct test{ > unsigned char a : 4; > unsigned char b : 4; > }; > > A sizeof(struct test) returns 2 instead of 1 (it only takes up 1 byte!). > I'm using gcc 2.6.3 by the way. K&R 2nd edition, page 213: "It is advisable to read the language rules for storing bit-fields as "implementation-dependent" without qualification. Structures with bit-fields may be used ... as a non-portable way to describe a storage layout known at the bit level." I.E., how bitfields are packed is implementation defined. The compiler is free to use two bytes if it wants. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Mar 17 10:59:00 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91211-2>; Fri, 17 Mar 1995 10:54:57 +0200 Received: by colombo.telesys-innov.fr; Fri, 17 Mar 1995 09:53:38 GMT From: Philippe BRAND Message-Id: <199503170953.JAA28656@colombo.telesys-innov.fr> Subject: Gcc-2.6.4 passed faulty prog To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Fri, 17 Mar 1995 09:53:38 +0000 (GMT) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5097 >A program I'm writing makes cc1obj-2.6.3 crash. I have tried compiling >both on my Amiga (68k processor) and on a sun4 running solaris-2.4, >and on a SparcStation 10. Here is output from gcc-2.6.4-950310 (don't pay attention to version numbers here as they are taken from cpp.out): 8.Sources:tmp> gcc -c cpp.c In file included from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include/objc/Object.h:2 from ./SmartMemory.h:4, from smartmemory.m:9: /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include/objc/objc.h:135: parse error before ` In file included from ./SmartMemory.h:4, from smartmemory.m:9: /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include/objc/Object.h:36: parse error before In file included from smartmemory.m:9: ./SmartMemory.h:26: `SmartMemNode' defined as wrong kind of tag ./SmartMemory.h:42: parse error before `@' ./SmartMemory.h:47: parse error before `@' ./SmartMemory.h:52: `SmartMemNode' defined as wrong kind of tag ./SmartMemory.h:53: parse error before `}' ./SmartMemory.h:91: conflicting types for `freeList' ./SmartMemory.h:52: previous declaration of `freeList' ./SmartMemory.h:91: invalid type argument of `->' ./SmartMemory.h:91: warning: data definition has no type or storage class ./SmartMemory.h:92: parse error before `if' ./SmartMemory.h:121: warning: data definition has no type or storage class ./SmartMemory.h:121: parse error before `}' smartmemory.m:36: parse error before `@' smartmemory.m:40: conflicting types for `defaultChunkSize' smartmemory.m:34: previous declaration of `defaultChunkSize' smartmemory.m:40: warning: data definition has no type or storage class smartmemory.m:41: parse error before `return' smartmemory.m:47: conflicting types for `chunkSize' ./SmartMemory.h:46: previous declaration of `chunkSize' smartmemory.m:47: initializer element is not constant smartmemory.m:47: warning: data definition has no type or storage class smartmemory.m:48: parse error before `return' smartmemory.m:82: `newClass' undeclared here (not in a function) smartmemory.m:82: warning: data definition has no type or storage class smartmemory.m:83: parse error before `}' smartmemory.m:90: redefinition of `class' smartmemory.m:82: `class' previously defined here smartmemory.m:90: warning: initialization makes integer from pointer without a cast smartmemory.m:90: warning: data definition has no type or storage class smartmemory.m:91: conflicting types for `size' ./SmartMemory.h:51: previous declaration of `size' smartmemory.m:91: initializer element is not constant smartmemory.m:91: warning: data definition has no type or storage class smartmemory.m:91: `SmartMemNode' defined as wrong kind of tag smartmemory.m:92: redefinition of `freeList' ./SmartMemory.h:91: `freeList' previously defined here smartmemory.m:92: warning: data definition has no type or storage class smartmemory.m:93: parse error before `return' smartmemory.m:107: parse error before `void' smartmemory.m:108: initializer element is not constant smartmemory.m:108: warning: data definition has no type or storage class smartmemory.m:109: parse error before `if' smartmemory.m:113: warning: initialization makes integer from pointer without a cast smartmemory.m:113: initializer element is not constant smartmemory.m:113: warning: data definition has no type or storage class smartmemory.m:114: parse error before `if' smartmemory.m:118: conflicting types for `chunkList' ./SmartMemory.h:45: previous declaration of `chunkList' smartmemory.m:118: initializer element is not constant smartmemory.m:118: warning: data definition has no type or storage class smartmemory.m:121: parse error before `for' smartmemory.m:121: conflicting types for `p' smartmemory.m:105: previous declaration of `p' smartmemory.m:121: invalid type argument of `->' smartmemory.m:121: parse error before `++' smartmemory.m:125: redefinition of `freeList' smartmemory.m:92: `freeList' previously defined here smartmemory.m:125: invalid type argument of `->' smartmemory.m:125: warning: data definition has no type or storage class smartmemory.m:126: parse error before `}' smartmemory.m:127: initializer element is not constant smartmemory.m:127: warning: data definition has no type or storage class smartmemory.m:128: redefinition of `freeList' smartmemory.m:125: `freeList' previously defined here smartmemory.m:128: invalid type argument of `->' smartmemory.m:128: warning: data definition has no type or storage class smartmemory.m:129: parse error before `if' smartmemory.m:138: parse error before `void' smartmemory.m:139: parse error before `[' smartmemory.m:139: warning: data definition has no type or storage class smartmemory.m:140: parse error before `->' smartmemory.m:155: redefinition of `freeList' smartmemory.m:128: `freeList' previously defined here smartmemory.m:155: initializer element is not constant smartmemory.m:155: warning: data definition has no type or storage class smartmemory.m:156: parse error before `return' 8.Sources:tmp> -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB From amiga-gcc-port-owner@nic.funet.fi Fri Mar 17 13:19:05 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91356-3>; Fri, 17 Mar 1995 13:16:51 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA01907; Fri, 17 Mar 1995 11:14:49 GMT Date: Fri, 17 Mar 1995 11:12:40 +0000 (GMT) From: Peter Ivimey-Cook To: dev@flevel.demon.co.uk Cc: Walter.Harms@arbi.informatik.uni-oldenburg.de, amiga-gcc-port@nic.funet.fi Subject: Re: Help - Pipes and things In-Reply-To: <9503161112.AA0008j@flevel.demon.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 16 Mar 1995 dev@flevel.demon.co.uk wrote: > Hi Walter, > > After looking at the pipe code you sent me I realised that using temporary > files (instead of PIPE:) is a good idea for writing portable code. I wrote > a new pipe called "fancy pipe" which as the functions: There is one big disadvantage of files - they must be stored. Some assembler output files are huge, which makes the -pipe option of gcc particularly useful, as the file never need be stored in it's entirety. > > FILE* fpopen(char* filename,char* mode); > void uclose(FILE* handle); If we're to have pipe functions, why not call them popen and pclose, as per Unix? > Gives a pipe from the list command: > > FILE* han=fpopen("|sort { }|list #?","r"); Does fopen parse this itself, or does hand the command line over to a shell (e.g. pdksh) to execute? Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Fri Mar 17 17:12:33 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91352-2>; Fri, 17 Mar 1995 17:07:42 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 17 Mar 1995 16:04:48 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA19615; Fri, 17 Mar 95 16:04:45 +0100 Date: Fri, 17 Mar 95 16:04:45 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503171504.AA19615@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA08375; Fri, 17 Mar 95 16:04:45 +0100 To: amiga-gcc-port@nic.funet.fi Subject: Re: Help - Pipes and things In-Reply-To: References: <9503161112.AA0008j@flevel.demon.co.uk> Peter Ivimey-Cook writes: > There is one big disadvantage of files - they must be stored. Some assembler > output files are huge, which makes the -pipe option of gcc particularly > useful, as the file never need be stored in it's entirety. The programs involved in the pipes must be running, which especially with gcc takes much RAM of the system (gcc, cpp, cc1 and as all running at once). On UNIX, even binaries can be swapped out. > If we're to have pipe functions, why not call them popen and pclose, as > per Unix? > > FILE* han=fpopen("|sort { }|list #?","r"); > > Does fopen parse this itself, or does hand the command line over to a shell > (e.g. pdksh) to execute? I thought that fpopen() had that special name because _it_ would parse that names and specials like { and } and call the appropriate actions? So it's rather different from the real popen(). Now I don't understand why this pipe specific function is necessary when there's already APIPE: or PIPE:. Why yet another syntax ({ and } instead of PIPE:'s :in and :out)? Why the starting "|" symbol for a pipe one reads from? Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Fri Mar 17 17:21:43 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91351-1>; Fri, 17 Mar 1995 17:18:29 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26502-4>; Fri, 17 Mar 1995 16:17:15 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209161-2>; Fri, 17 Mar 1995 16:17:01 +0100 Subject: Re: More gcc bugs... From: Christian Stieber To: nmmyhre@undergrad.math.uwaterloo.ca (Nathaniel Myhre) Date: Fri, 17 Mar 1995 16:16:49 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Nathaniel Myhre" at Mar 16, 95 03:38:00 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 782 Message-Id: <95Mar17.161701+0100mesz.209161-2+64@hphalle0.informatik.tu-muenchen.de> > Try this: declare a structure of the following form: > > struct test{ > unsigned char a : 4; > unsigned char b : 4; > }; > > A sizeof(struct test) returns 2 instead of 1 (it only takes up 1 byte!). This is quite correct. GNU C always pads structures to an even size. According to the standard, the compiler is free to do so, so this is not a bug. In fact, I wouldn't mind padding to 4 byte multiples... Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP public key available -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Fri Mar 17 17:37:30 1995 Received: by nic.funet.fi id <91353-4>; Fri, 17 Mar 1995 17:35:03 +0200 From: Leonard Norrgard To: peteric@isltd.insignia.com CC: too@nsdi.fi, amiga-gcc-port@nic.funet.fi In-reply-to: (message from Peter Ivimey-Cook on Thu, 16 Mar 1995 11:08:36 +0000 (GMT)) Subject: Re: networking interfaces, ixemul Message-Id: <95Mar17.173503+0200_eet.91353-4+21@nic.funet.fi> Date: Fri, 17 Mar 1995 17:35:01 +0200 Peter wrote: > I've been a bit busy of late, but I did manage to down load the ixemul > 40.4 source in order to look at the code and any docs. I'll get on to it > ASAP. I discovered today that ixemul 40.4, the version included with gcc2.6.3 on the net (by Luebbert) doesn't actually provide any networking whatsoever (I personally use a version of ixemul that I built myself last year). Looking at the source, it's just excluded with #if 0. Yet the version number is higher than the versions of ixemul.library that does provide networking. This means that this version of ixemul.library has broken call compatibility, among other things. I'm not happy at all with this situation. The ixemul conspiration is working on fixing this as soon as possible. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Fri Mar 17 18:31:21 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <91363-3>; Fri, 17 Mar 1995 18:26:05 +0200 Received: from tiny.lysator.liu.se (tiny.lysator.liu.se [130.236.253.10]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id RAA13006; Fri, 17 Mar 1995 17:20:39 +0100 From: Niels M|ller Received: (nisse@localhost) by tiny.lysator.liu.se (8.6.11/8.6.11) id RAA14704; Fri, 17 Mar 1995 17:18:54 +0100 Date: Fri, 17 Mar 1995 17:18:54 +0100 Message-Id: <199503171618.RAA14704@tiny.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: phb@colombo.telesys-innov.fr CC: amiga-gcc-port@nic.funet.fi In-reply-to: <199503170953.JAA28656@colombo.telesys-innov.fr> (message from Philippe BRAND on Fri, 17 Mar 1995 09:53:38 +0000 (GMT)) Subject: Re: Gcc-2.6.4 passed faulty prog You say you compiled the test file with 8.Sources:tmp> gcc -c cpp.c Doesn't gcc assume that the file is c-source, if invoked that way? (That's why it complains about @:s in the code). Could you try to compile with gcc -c -x objective-c cpp.c to make sure gcc treats it as objective-c source? (simply renaming the source file to cpp.m would do too, I guess). Regards, Niels Möller From amiga-gcc-port-owner@nic.funet.fi Sat Mar 18 23:24:47 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91833-3>; Sat, 18 Mar 1995 22:24:47 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id as17512; 18 Mar 95 20:19 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA000gf; Fri, 17 Mar 95 15:03:16 GMT Date: Fri, 17 Mar 95 15:03:16 GMT Message-Id: <9503171503.AA000ge@flevel.demon.co.uk> Message-Id: <205d65b2.88b82-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Bounced Mails Hi, I keep getting bounced mails from postings I made to the list a few days ago, ive emailed postmaster but had no response, is anyone else having this problem? Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Sat Mar 18 23:24:47 1995 Received: from undergrad.math.uwaterloo.ca ([129.97.204.13]) by nic.funet.fi with SMTP id <91412-4>; Fri, 17 Mar 1995 21:08:27 +0200 Received: from noether.math.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57140-1>; Fri, 17 Mar 1995 14:07:27 -0500 Date: Fri, 17 Mar 1995 14:07:25 -0500 From: Nathaniel Myhre To: Christian Stieber cc: amiga-gcc-port@nic.funet.fi Subject: Re: More gcc bugs... In-Reply-To: <95Mar17.161701+0100mesz.209161-2+64@hphalle0.informatik.tu-muenchen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 17 Mar 1995, Christian Stieber wrote: > > > Try this: declare a structure of the following form: > > > > struct test{ > > unsigned char a : 4; > > unsigned char b : 4; > > }; > > > > A sizeof(struct test) returns 2 instead of 1 (it only takes up 1 byte!). > > This is quite correct. GNU C always pads structures to an even size. > According to the standard, the compiler is free to do so, so this is > not a bug. In fact, I wouldn't mind padding to 4 byte multiples... > > Christian Can you turn the padding off? ----------------------------------------------------------- Nathaniel Myhre University of Waterloo, 4th year CS undergraduate nmmyhre@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~nmmyhre/ "Of all the things I lost, I miss my mind the most." ----------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Sat Mar 18 23:24:47 1995 Received: from undergrad.math.uwaterloo.ca ([129.97.204.13]) by nic.funet.fi with SMTP id <91411-3>; Fri, 17 Mar 1995 21:07:40 +0200 Received: from noether.math.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57123-2>; Fri, 17 Mar 1995 14:06:47 -0500 Date: Fri, 17 Mar 1995 14:06:34 -0500 From: Nathaniel Myhre To: Fred Fish cc: amiga-gcc-port@nic.funet.fi Subject: Re: More gcc bugs... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 16 Mar 1995, Fred Fish wrote: > > struct test{ > > unsigned char a : 4; > > unsigned char b : 4; > > }; > > > > A sizeof(struct test) returns 2 instead of 1 (it only takes up 1 byte!). > > I'm using gcc 2.6.3 by the way. > > K&R 2nd edition, page 213: > > "It is advisable to read the language rules for storing > bit-fields as "implementation-dependent" without qualification. > Structures with bit-fields may be used ... as a non-portable > way to describe a storage layout known at the bit level." > > I.E., how bitfields are packed is implementation defined. The compiler > is free to use two bytes if it wants. > > -Fred > What threw me was the fact that it was not using the second byte, ie. it was packing the two bitfields into a single byte. In addition, the gcc version at school returned a sizeof 1 (it was running on a Sun). I needed the structure to have a size of 1 because it was a data structure used on a network simulation for a school project. Sending an extra unused byte for every packet hurts performance and reduces my mark. I find it hard to believe that the compiler can legally pad a single byte structure to 2 bytes without my consent. Can I turn the padding off? I would assume not. ----------------------------------------------------------- Nathaniel Myhre University of Waterloo, 4th year CS undergraduate nmmyhre@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~nmmyhre/ "Of all the things I lost, I miss my mind the most." ----------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Sat Mar 18 23:24:47 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91832-2>; Sat, 18 Mar 1995 22:24:43 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id ar17512; 18 Mar 95 20:19 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA000mo; Sat, 18 Mar 95 10:20:31 GMT Date: Sat, 18 Mar 95 10:20:31 GMT Message-Id: <9503181020.AA000mn@flevel.demon.co.uk> Message-Id: <205e74ec.be6e2-dev@flevel.demon.co.uk> In-Reply-To: <9503171504.AA19615@inf-wiss.uni-konstanz.de> (from Joerg-Cyril Hoehle ) (at Fri, 17 Mar 95 16:04:45 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: hoehle@inf-wiss.uni-konstanz.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Help - Pipes and things Hi Joerg-Cyril, > Peter Ivimey-Cook writes: > > There is one big disadvantage of files - they must be stored. Some assembler > > output files are huge, which makes the -pipe option of gcc particularly > > useful, as the file never need be stored in it's entirety. > > The programs involved in the pipes must be running, which especially > with gcc takes much RAM of the system (gcc, cpp, cc1 and as all > running at once). On UNIX, even binaries can be swapped out. Which, of course, tempory files means only 1 executable is running at once. > > If we're to have pipe functions, why not call them popen and pclose, as > > per Unix? I didn't call it popen and pclose because they already exist and could cause a clash. > > > FILE* han=fpopen("|sort { }|list #?","r"); > > > > Does fopen parse this itself, or does hand the command line over to a shell > > (e.g. pdksh) to execute? It handles all this itself and then calls the shell commands using 'system(char*)' > I thought that fpopen() had that special name because _it_ would parse > that names and specials like { and } and call the appropriate actions? > So it's rather different from the real popen(). Yes it is different, it's a pipe that I wrote to do what _I_ want it to do. > Now I don't understand why this pipe specific function is necessary > when there's already APIPE: or PIPE:. Why yet another syntax ({ and } > instead of PIPE:'s :in and :out)? Why the starting "|" symbol for a > pipe one reads from? PIPE: is Amiga only, this means I can't just re-compile the code on another machine (e.g. a PC). Swings and roundabouts! Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Sun Mar 19 01:28:43 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <91188-1>; Sun, 19 Mar 1995 01:26:28 +0200 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA20574; Sun, 19 Mar 1995 00:31:48 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9503182331.AA20574@decap2.zdv.uni-tuebingen.de> Subject: Two questions To: amiga-gcc-port@nic.funet.fi Date: Sun, 19 Mar 1995 00:31:47 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 870 Hello, list, two questions today: 1.) Is there a function like fdtofh in libnix? (Get FileHandle associated to file descriptor.) 2.) When linking a program I get the following error message: 5> gcc -noixemul -DSTDC_HEADERS=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DRETSIGTYPE=void -DHAVE_SYS_TIME_H=1 -DHAVE_STRING_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_RANDOM=1 -DHAVE_GETHOSTNAME=1 -DX_LOCALE=1 -DATTENTION -D_amigados -DDEBUG -I.. -IMUI:Developer/C/include -pedantic -Wall -g -c childio.c 5> gcc -o AmyBoard -LMUI:Developer/C/GNU/Lib -lmui -g parser.o amyboard.o backend.o moves.o childio.o muiclass.o time.o args.o bitmaps.o gettimeofday.o fdtofh.o -lm -lmui -lamiga -lauto ld: relocation address out of range in childio.o What can be wrong? Jochen From amiga-gcc-port-owner@nic.funet.fi Mon Mar 20 11:23:48 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91360-1>; Mon, 20 Mar 1995 11:18:15 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA04004 (5.65c8/IDA-1.4.4 for ); Mon, 20 Mar 1995 10:18:01 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA29802; Mon, 20 Mar 95 10:18:00 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503200918.AA29802@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Two questions To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Mon, 20 Mar 1995 10:18:00 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503182331.AA20574@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Mar 19, 95 00:31:47 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 199 > > 1.) Is there a function like fdtofh in libnix? (Get FileHandle > associated to file descriptor.) > You mean something like fileno()? No. But the macro in stdio.h should work ;-). Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Mar 20 11:31:14 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91363-2>; Mon, 20 Mar 1995 11:29:04 +0200 Received: by colombo.telesys-innov.fr; Mon, 20 Mar 1995 10:27:47 GMT From: Philippe BRAND Message-Id: <199503201027.KAA21993@colombo.telesys-innov.fr> Subject: YAGB To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 20 Mar 1995 10:27:46 +0000 (GMT) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 269 Yet Another Gcc Beta is available on both nic.funet.fi:/pub/amiga/gnu/beta and on my site ftp.telesys-innov.fr:/pub/amigados-gnu/beta. File is gcc-2.6.4-950310.lha Please report asap. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB From amiga-gcc-port-owner@nic.funet.fi Mon Mar 20 11:43:16 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91365-3>; Mon, 20 Mar 1995 11:40:06 +0200 Received: from linnet.cms.dmu.ac.uk (linnet.cms.dmu.ac.uk [146.227.102.34]) by macondo.dmu.ac.uk (8.6.11/8.6.11) with ESMTP id JAA29435; Mon, 20 Mar 1995 09:41:26 GMT Received: by linnet.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA032362338; Mon, 20 Mar 1995 09:38:58 GMT Date: Mon, 20 Mar 1995 09:38:57 +0000 (GMT) From: Derek Piper X-Sender: se1dp@linnet.cms.dmu.ac.uk To: Philippe BRAND Cc: Amiga-Gcc Liste Subject: Re: YAGB In-Reply-To: <199503201027.KAA21993@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 20 Mar 1995, Philippe BRAND wrote: > Yet Another Gcc Beta is available on both nic.funet.fi:/pub/amiga/gnu/beta > and on my site ftp.telesys-innov.fr:/pub/amigados-gnu/beta. > File is gcc-2.6.4-950310.lha > Please report asap. The file is really gcc-2.6.4-950318.lha - dated 20th of March. Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | World Wide Web Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Foolproof operation: All parameters are hard coded. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Mar 20 13:48:11 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <91360-4>; Mon, 20 Mar 1995 13:39:30 +0200 X400-Received: by /ADMD=FUMAIL/C=fi/; Relayed; Mon, 20 Mar 1995 13:39:15 +0200 X400-Received: by mta funet.fi in /ADMD=FUMAIL/C=fi/; Relayed; Mon, 20 Mar 1995 13:39:15 +0200 X400-Received: by /PRMD=Switch/ADMD=Arcom/C=Ch/; Relayed; Mon, 20 Mar 1995 13:38:58 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Mon, 20 Mar 1995 13:38:47 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Mon, 20 Mar 1995 13:40:17 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Mon, 20 Mar 1995 13:39:49 +0200 Date: Mon, 20 Mar 1995 13:39:49 +0200 X400-Originator: Trutmann@ztl.ch X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;<91F5C1171F@dim.ztl.ch>] X400-Content-Type: P2-1984 (2) Content-Identifier: Problems with... Alternate-Recipient: Allowed From: Benno Trutmann Message-ID: <91F5C1171F@dim.ztl.ch> To: amiga-gcc-port@lists.funet.fi Subject: Problems with option -resident Reply-To: trutmann@ztl.ch X-mailer: Pegasus Mail/Windows (v1.11a) Hello, I installed gcc v2.6.3 and tried to compile the source code 'hello.c' #include main() { printf("Hello World!\n"); } with the following command gcc -resident -o hello hello.c and got the following error message hello.c: In function `main': hello.c:6: internal error--unrecognizable insn: (call_insn 6 4 8 (call (mem:QI (symbol_ref:SI ("__main"))) (const_int 0)) -1 (nil) (nil) (nil)) Abort trap gcc: Internal compiler error: program cc1 got fatal signal 6 This error occours only if I compile with option -resident. Did I do something wrong or is this a bug of gcc? It would be nice if somebody could send me a note. Thanks in advance Benno From amiga-gcc-port-owner@nic.funet.fi Mon Mar 20 17:39:56 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <91164-2>; Mon, 20 Mar 1995 17:33:43 +0200 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA22908; Mon, 20 Mar 1995 16:38:47 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9503201538.AA22908@decap2.zdv.uni-tuebingen.de> Subject: Re: Two questions To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Mon, 20 Mar 1995 16:38:44 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503200918.AA29802@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Mar 20, 95 10:18:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 616 Hmmm, Matthias, > > 1.) Is there a function like fdtofh in libnix? (Get FileHandle > > associated to file descriptor.) > > > You mean something like fileno()? No. But the macro in stdio.h > should work ;-). Either you or me misunderstood something: As far as I know fileno() returns the file descriptor associated to a FILE pointer. I want to go one step more: I'd like to get the BPTR to the AmigaDOS FileHandle. With Dice I do a FILE *fp; BPTR fh = fdtofh(fileno(fp)); Is there something similar in stdio.h? I apologize, if I didn't notice something. Jochen P.S: Ok, macros are welcome, too. ;-) From amiga-gcc-port-owner@nic.funet.fi Mon Mar 20 18:08:24 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91357-2>; Mon, 20 Mar 1995 18:00:48 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26466-1>; Mon, 20 Mar 1995 16:59:42 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209171-2>; Mon, 20 Mar 1995 16:59:25 +0100 Subject: Re: Bounced Mails From: Christian Stieber To: dev@flevel.demon.co.uk Date: Mon, 20 Mar 1995 16:59:13 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <205d65b2.88b82-dev@flevel.demon.co.uk> from "dev@flevel.demon.co.uk" at Mar 17, 95 03:03:16 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 664 Message-Id: <95Mar20.165925+0100mesz.209171-2+64@hphalle0.informatik.tu-muenchen.de> > > Hi, > > I keep getting bounced mails from postings I made to the list a few days > ago, ive emailed postmaster but had no response, is anyone else having > this problem? Same here. I never really looked at the bounced mails; I was assuming that somebody on the list is having a problem. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP public key available -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Mon Mar 20 18:13:45 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91360-4>; Mon, 20 Mar 1995 18:00:58 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA26670 (5.65c8/IDA-1.4.4 for ); Mon, 20 Mar 1995 17:00:11 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA00619; Mon, 20 Mar 95 17:00:11 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503201600.AA00619@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Two questions To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Mon, 20 Mar 1995 17:00:10 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503201538.AA22908@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Mar 20, 95 04:38:44 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 756 > > Either you or me misunderstood something: As far as I know fileno() > returns the file descriptor associated to a FILE pointer. Exactly. > I want to go > one step more: I'd like to get the BPTR to the AmigaDOS > FileHandle. Ah, I understand. Isn't that something really nasty you want to do ;-) ? > Is there something similar in stdio.h? No, there isn't. Internally the Un*x filedescriptor is an index into the unsigned long *__stdfiledes; array which holds the AmigaDOS filehandles. Be prepared that the address might change at any open(). (And that the implementation might change as well.) > P.S: Ok, macros are welcome, too. ;-) Then try this one: extern BPTR *__stdfiledes; #define fdtofh(a) (__stdfiledes[a]) Hope it helps. Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Mar 20 18:51:34 1995 Received: from mordor.cs.du.edu ([130.253.192.87]) by nic.funet.fi with SMTP id <91362-4>; Mon, 20 Mar 1995 18:49:01 +0200 Received: from nyx.cs.du.edu by mordor.cs.du.edu with SMTP id AA05273 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 09:35:19 -0700 Received: by nyx.cs.du.edu (4.1/SMI-4.1) id AA02779; Mon, 20 Mar 95 09:44:29 MST From: wmiler@nyx.cs.du.edu (Wyatt Miler) Message-Id: <9503201644.AA02779@nyx.cs.du.edu> X-Disclaimer: Nyx is a public access Unix system run by the University of Denver. The University has neither control over nor responsibility for the opinions or correct identity of users. Subject: Re: Bounced Mails To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Mon, 20 Mar 1995 09:44:27 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Mar20.165925+0100mesz.209171-2+64@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Mar 20, 95 04:59:13 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 971 > > > > Hi, > > > > I keep getting bounced mails from postings I made to the list a few days > > ago, ive emailed postmaster but had no response, is anyone else having > > this problem? > > Same here. I never really looked at the bounced mails; I was assuming > that somebody on the list is having a problem. > They may be bouncing from my host, as we've been having mail problems of late. The mail here seems to be working ok now . - Wyatt - ------------------------------------------------------------------------- Internet: wmiler@nyx.cs.du.edu MicroMUSE: Vampire StormMUSE: Vampire FutureMUTE: Vampire Thought: Now that we know what VR is, what do we do with it? :) Educate! Disclaimer: I don't claim to know everything, my opinions are my own, and nobody elses... -------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Mon Mar 20 19:35:57 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <91210-4>; Mon, 20 Mar 1995 19:31:57 +0200 X400-Received: by /ADMD=FUMAIL/C=fi/; Relayed; Mon, 20 Mar 1995 19:31:46 +0200 X400-Received: by mta funet.fi in /ADMD=FUMAIL/C=fi/; Relayed; Mon, 20 Mar 1995 19:31:46 +0200 X400-Received: by mta d400relay in /PRMD=dfnrelay/ADMD=d400/C=de/; Relayed; Mon, 20 Mar 1995 19:33:24 +0200 X400-Received: by mta fh-regensburg.d400 in /PRMD=dfnrelay/ADMD=d400/C=de/; Relayed; Mon, 20 Mar 1995 19:31:16 +0200 X400-Received: by /PRMD=fh-regensburg/ADMD=d400/C=de/; Relayed; Mon, 20 Mar 1995 19:31:16 +0200 Date: Mon, 20 Mar 1995 19:31:16 +0200 X400-Originator: alexander.sorg@rz.fh-regensburg.d400.de X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=fh-regensburg/ADMD=d400/C=de/;950320183116] X400-Content-Type: P2-1984 (2) Content-Identifier: 71 Alternate-Recipient: Allowed From: Alexander Sorg Message-ID: <71*/G=alexander/S=sorg/OU=rz/PRMD=fh-regensburg/ADMD=d400/C=de/@MHS> To: amiga-gcc-port@nic.funet.fi Subject: Basic_Problems After updating to ver. 2.6.3 I have even Problems compiling following code: #include main() { cout << "Hallo Welt!\n" ; } I used to compile with the command: gcc-020 -v -lg++ hallo.cc Sometimes I get the following output: Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Dmc68010 hallo.cc t:cc384104.ii GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/lib/g++-include /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1plus t:cc384104.ii -quiet -dumpbase hallo.cc -version -o t:cc384104.s Can't allocate new stack! And sometimes I get: Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Dmc68010 hallo.cc t:cc434696.ii GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/lib/g++-include /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1plus t:cc434696.ii -quiet -dumpbase hallo.cc -version -o t:cc434696.s GNU C++ version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3 snapshot 941209. as -mc68010 -o t:cc4346961.o t:cc434696.s ld /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/local/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/gnu/lib -L/local/lib -L/local/lib -lg++ t:cc4346961.o -lgcc -lc -lgcc t:cc4346961.o: Undefined symbol _cout referenced from text segment t:cc4346961.o: Undefined symbol ___ls__7ostreamPCc referenced from text segment So, what's going on? I have my Stack set to 100000 or 200000 Bytes and there are about 2MB or more free. I have an A 1200, with 4MB Fast-Ram, a Blizzard 1230/No MMU/Yep FPU turboboard, Overdrive-CD. Please help. Thanx. From amiga-gcc-port-owner@nic.funet.fi Mon Mar 20 19:46:55 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91207-2>; Mon, 20 Mar 1995 19:43:49 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA16121; Mon, 20 Mar 1995 17:43:34 GMT Date: Mon, 20 Mar 1995 17:41:10 +0000 (GMT) From: Peter Ivimey-Cook To: Alexander Sorg Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Basic_Problems In-Reply-To: <71*/G=alexander/S=sorg/OU=rz/PRMD=fh-regensburg/ADMD=d400/C=de/@MHS> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Alexander, your compile line is the first problem: > gcc-020 -v -lg++ hallo.cc should be > gcc-020 -v hallo.cc -lg++ -- read the linker manual! > /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1plus t:cc384104.ii -quiet > -dumpbase hallo.cc -version -o t:cc384104.s > Can't allocate new stack! > Sounds like you've got too *much* stack allocated, so when it tries to allocate stack for the cc1plus process (which is big) there isn't enough left - try reducing it (I would suggest between 50k and 100k in 10k steps). 2Mb isn't that much leeway. It might also help if you ensure all the files, including t: temps, are stored on disk, and there aren't other memory-hogging processes around. You may wish to look at the new stack vars in gcc2.6.3 (GCC_STACK ??) I can't remember the names. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Tue Mar 21 11:10:21 1995 Received: by nic.funet.fi id <91159-2>; Tue, 21 Mar 1995 11:06:33 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi In-reply-to: <95Mar20.165925+0100mesz.209171-2+64@hphalle0.informatik.tu-muenchen.de> (message from Christian Stieber on Mon, 20 Mar 1995 16:59:13 +0100 (MEZ)) Subject: Re: Bounced Mails Message-Id: <95Mar21.110633+0200_eet.91159-2+12@nic.funet.fi> Date: Tue, 21 Mar 1995 11:06:29 +0200 Normally, you will not get bounced mails (they are automatically redirected to the address amiga-gcc-port-owner@lists.funet.fi where I eventually get to read them). If the mail you send however includes a Cc: line with one or more addresses and one of these addresses bounce, that bounce message will get back to you directly (because that message is sent both through the mailing list and directly from you to the address). If you get mail bounces on messages without a Cc: or Bcc: line, we have something interesting going on. From amiga-gcc-port-owner@nic.funet.fi Tue Mar 21 11:27:40 1995 Received: from dream.future.net ([204.130.134.1]) by nic.funet.fi with SMTP id <91188-3>; Tue, 21 Mar 1995 11:21:54 +0200 Received: (from tomthai@localhost) by dream.future.net (8.6.10/8.6.9) id DAA01516; Tue, 21 Mar 1995 03:21:06 GMT Date: Tue, 21 Mar 1995 03:21:06 +0000 (GMT) From: "Tom T. Thai" To: amiga-gcc-port@nic.funet.fi Subject: unsub In-Reply-To: <95Mar21.110633+0200_eet.91159-2+12@nic.funet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe tom@future.net unsubscribe tomthai@future.net From amiga-gcc-port-owner@nic.funet.fi Tue Mar 21 15:20:37 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91275-3>; Tue, 21 Mar 1995 15:12:00 +0200 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA01309 (5.65c-6/7.3w-FAU); Tue, 21 Mar 1995 14:11:41 +0100 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id OAA22464 (8.6.10/7.4a-FAU);; Tue, 21 Mar 1995 14:11:35 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA19653; Tue, 21 Mar 1995 14:11:31 +0100 Date: Tue, 21 Mar 1995 14:11:31 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9503211311.AA19653@pctc.chemie.uni-erlangen.de> To: vinsci@nic.funet.fi Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Mar21.110633+0200_eet.91159-2+12@nic.funet.fi> (message from Leonard Norrgard on Tue, 21 Mar 1995 11:06:29 +0200) Subject: Re: Bounced Mails Hello, here I will send you an example of a bounced mail with no Cc: or Bcc:. I only send the message to amiga-gcc-port@nic.funet.fi Perhaps this helps you to check the problem. ------- start of bounced mail -------- >From <> Thu Mar 16 15:32:06 1995 To: From: The Post Office Sender: mailer-daemon@nic.funet.fi Subject: Delivery problems with your mail Cc: The Post Office Mime-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="A41C67FC8.795364017=_/nic.funet.fi" Date: Thu, 16 Mar 1995 16:26:58 +0200 --A41C67FC8.795364017=_/nic.funet.fi Content-Type: text/plain A copy of your message is being returned to you due to difficulties encountered while attempting to deliver your mail. The following errors occurred during message delivery processing: : ...\ expired after 3 days, problem was: 500 (connect to indi5.iam.uni-bonn.de [131.220.223.76]: Connection timed out) --A41C67FC8.795364017=_/nic.funet.fi Content-Type: message/delivery-status Original-MTS-Type: INET Final-MTS-Type: INET Final-MTA: nic.funet.fi Rcpt: toerne@indi5.iam.uni-bonn.de Action: failed Status: 500 (connect to indi5.iam.uni-bonn.de [131.220.223.76]: Connection timed out) --A41C67FC8.795364017=_/nic.funet.fi Content-Type: message/rfc822 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <91393-3>; Mon, 13 Mar 1995 14:32:41 +0200 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA12402 (5.65c-6/7.3w-FAU); Mon, 13 Mar 1995 13:32:17 +0100 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id NAA01880 (8.6.10/7.4a-FAU); for ; Mon, 13 Mar 1995 13:32:11 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA19630; Mon, 13 Mar 1995 13:32:03 +0100 Date: Mon, 13 Mar 1995 13:32:03 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9503131232.AA19630@pctc.chemie.uni-erlangen.de> To: amiga-gcc-port@nic.funet.fi Subject: principal question about glibc Hello, I have a principal question to all of you working on the port of gcc for the amiga. Is it worth or are there any dis- / advantages of doing a port of glibc-1.09 to the amiga ?? Regards -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- --A41C67FC8.795364017=_/nic.funet.fi-- ------- end of bounced mail -------- Regards -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Tue Mar 21 17:33:47 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <91215-3>; Tue, 21 Mar 1995 17:30:07 +0200 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA24182; Tue, 21 Mar 1995 16:29:42 +0100 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA09765; Tue, 21 Mar 95 16:29:41 +0100 Date: Tue, 21 Mar 95 16:29:41 +0100 From: isthesin@TechFak.Uni-Bielefeld.DE Message-Id: <9503211529.AA09765@moos.techfak.uni-bielefeld.de> To: amiga-gcc-port@nic.funet.fi Subject: Shared executables for Amiga GNU ports Hi !!! As more and more GNU software is being ported to the AMIGA, a problem is becoming more serious: The size of the executables. It seems to me that an utility, like 'objdump' should NOT be >100k in size. As a matter of fact, many utilities share code, e.g. all utilities from binutils-2.5.2 share libbfd.a. So we have several utilities, >=100k on disk, while most of the code in each utility is not used by it, but must be included, due to static linking. On most UN*X boxes, this is not a problem, since they use shared runtime libraries and the executables are small. On the AMIGA, we also have the concept of a shared library, so the question comes up: Can we build shared libraries to reduce the code of the executables? This brings up some questions: - How can one seperate the data from different utilities, calling the library? - How can the code be changed to produce these libraries from the binary distributions? - How can we distinguish different versions of utilities (e.g. gcc2.6.3 and gcc2.6.4)? IMHO it is impossible to go on with static linked libraries, since the executable size (and with it the load time and disk consumption) can no longer be tolerated. I would really like to hear any comments on this, esp. from the guys being busy with porting GNU software to the AMIGA. Bye... Stephan From amiga-gcc-port-owner@nic.funet.fi Tue Mar 21 18:06:57 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91165-2>; Tue, 21 Mar 1995 17:59:55 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Tue, 21 Mar 1995 16:59:40 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA04293; Tue, 21 Mar 95 16:59:38 +0100 Date: Tue, 21 Mar 95 16:59:38 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503211559.AA04293@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA09604; Tue, 21 Mar 95 16:59:38 +0100 To: isthesin@TechFak.Uni-Bielefeld.DE Cc: amiga-gcc-port@nic.funet.fi Subject: Shared executables for Amiga GNU ports In-Reply-To: <9503211529.AA09765@moos.techfak.uni-bielefeld.de> References: <9503211529.AA09765@moos.techfak.uni-bielefeld.de> isthesin@techfak.uni-bielefeld.de writes: > As more and more GNU software is being ported to the AMIGA, a problem is becoming > more serious: The size of the executables. It would be very, very nice to have something done in this area. > On most UN*X boxes, this is not a problem, since they use shared runtime libraries > and the executables are small. This can be a problem even on UNIX as far as disk storage is required. Even there, libbfd, libtcl, libtk are _not_ shared libraries and they are merged into the executables. I get crazy when I see all those programs here built using TCL that use at least 300KB, programs built using TK take at least 500KB, every program using the jpeg library taking xxxKB and so on on the Suns here... Can anyone tell me how to make shared libraries on a Sun?? > This brings up some questions: I'd add: how can we build shared libraries without gcc-2.3.3? > I would really like to hear any comments on this, esp. from the guys being > busy with porting GNU software to the AMIGA. I'd say that using shared libraries doesn't solve all size problems. UNIX-SW, especially GNU-SW makes big executables because the programs can do a lot. One way to reduce executable size is to reduce the functionality of the program by throwing off things that do not make sense in the normal case on an Amiga. For example I once removed the option (and the code) for paging and piping the output to the lpr program in a port of GNU-diff. But this costs the authors of the ports time and effort. The size of libbfd could be reduced by leaving only knowledege about the AmigaDOS hunk structure in, throwing other formats away. But it's easier to just say "configure; make". I guess that there's not much we can do. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Tue Mar 21 18:42:33 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <91351-2>; Tue, 21 Mar 1995 18:37:27 +0200 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA24838; Tue, 21 Mar 1995 17:37:09 +0100 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA10159; Tue, 21 Mar 95 17:37:07 +0100 Date: Tue, 21 Mar 95 17:37:07 +0100 From: isthesin@TechFak.Uni-Bielefeld.DE Message-Id: <9503211637.AA10159@moos.techfak.uni-bielefeld.de> To: amiga-gcc-port@nic.funet.fi Subject: Shared executables for Amiga GNU ports hoehle@inf-wiss.uni-konstanz.de writes: >isthesin@techfak.uni-bielefeld.de writes: >> As more and more GNU software is being ported to the AMIGA, a problem is becoming > > more serious: The size of the executables. >It would be very, very nice to have something done in this area. :-) > > > On most UN*X boxes, this is not a problem, since they use shared runtime libraries > > and the executables are small. >This can be a problem even on UNIX as far as disk storage is >required. Even there, libbfd, libtcl, libtk are _not_ shared libraries >and they are merged into the executables. I get crazy when I see all >those programs here built using TCL that use at least 300KB, programs >built using TK take at least 500KB, every program using the >jpeg library taking xxxKB and so on on the Suns here... Can anyone >tell me how to make shared libraries on a Sun?? > Well, AFAIK, on a sun3 you may compile with -PIC (generate position independent code) and the add -Bshared to the linker......or something like this (never tried..) > > This brings up some questions: >I'd add: how can we build shared libraries without gcc-2.3.3? This is a major problem: When is -resident (or -fbaserel) support reestablished? (Phillipe?) > > > I would really like to hear any comments on this, esp. from the guys being > > busy with porting GNU software to the AMIGA. > >I'd say that using shared libraries doesn't solve all size >problems. UNIX-SW, especially GNU-SW makes big executables because the >programs can do a lot. One way to reduce executable size is to reduce >the functionality of the program by throwing off things that do not >make sense in the normal case on an Amiga. > Well, but in fact most GNU sw, I have compiled so far, uses libs, e.g. libbfd.a If we can figure out a way to transform these static link libs into runtime shared libs, it WOULD give us shorter executables. >For example I once removed the option (and the code) for paging and >piping the output to the lpr program in a port of GNU-diff. But this >costs the authors of the ports time and effort. The size of libbfd >could be reduced by leaving only knowledege about the AmigaDOS hunk >structure in, throwing other formats away. But it's easier to just say >"configure; make". Unfortunately, this does not give you too much. Support for a.out and hunk format is desired in libbfd.a. A problem is that you can not leave out code for reading object files, if you don't need it. The whole code has to be drawn into the executable. (This seems to be a major design flaw of bfd, but is a trade-off of portability, IMHO) Anyhow, why should one have 10 or so utilities, all statically linked against libbfd.a, if there could be a single bfd.library in LIBS:, loaded only once, allocating space on disk only once? In fact, the code of the binutils consists to 10-20% (estimated) of code, special to the utility and the rest is code from libbfd.a, libopcode.a, etc. So 10 utils 'a 100k=> 700k disk space wasted (80k per file minus space for shared lib) > >I guess that there's not much we can do. > Joerg Hoehle. >hoehle@inf-wiss.uni-konstanz.de Bye... Stephan From amiga-gcc-port-owner@nic.funet.fi Tue Mar 21 19:15:17 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91349-4>; Tue, 21 Mar 1995 19:07:27 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA15812 (5.65c8/IDA-1.4.4 for ); Tue, 21 Mar 1995 18:07:21 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA03716; Tue, 21 Mar 95 18:07:20 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503211707.AA03716@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Shared executables for Amiga GNU ports To: isthesin@techfak.uni-bielefeld.de Date: Tue, 21 Mar 1995 18:07:20 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503211637.AA10159@moos.techfak.uni-bielefeld.de> from "isthesin@TechFak.Uni-Bielefeld.DE" at Mar 21, 95 05:37:07 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1090 > > Well, but in fact most GNU sw, I have compiled so far, uses libs, e.g. libbfd.a > If we can figure out a way to transform these static link libs into runtime shared libs, it > WOULD give us shorter executables. > Speaking theoretically this can be done in a similar way as SAS does it: Upon each opening of the shared library you create a new jumptable including a new library base (for global variables used by the lib). If you call a specific function in the lib, some assembly stub tranforms the base pointer a6 into the data segment pointer a4, puts the arguments on the stack (registerized parameters) and finally calls the function itself. This way you need only one additional shared library startup and some assembly stubs - you need not change functions of the library itself. This is possible as long as you don't call other shared libraries. If you do this you got one more problem: To open this library. This could be done by collecting (sub)library base pointers into one set and opening them all at once - by I don't think it'd work for ixemul.library :-(. Matthias From amiga-gcc-port-owner@nic.funet.fi Tue Mar 21 22:24:44 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91374-2>; Tue, 21 Mar 1995 22:21:03 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26483-2>; Tue, 21 Mar 1995 21:20:47 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209163-1>; Tue, 21 Mar 1995 21:20:38 +0100 Subject: Re: Shared executables for Amiga GNU ports From: Christian Stieber To: isthesin@techfak.uni-bielefeld.de Date: Tue, 21 Mar 1995 21:20:23 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503211637.AA10159@moos.techfak.uni-bielefeld.de> from "isthesin@techfak.uni-bielefeld.de" at Mar 21, 95 05:37:07 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 837 Message-Id: <95Mar21.212038+0100mesz.209163-1+424@hphalle0.informatik.tu-muenchen.de> > >I'd add: how can we build shared libraries without gcc-2.3.3? What is the problem with building shared libraries with 2.6.3? I don't have any problems... am I doing something wrong, or are we talking about different things (I'm talking about *.library files)? > This is a major problem: When is -resident (or -fbaserel) support reestablished? (Phillipe?) That would be nice, but AFAIK neither -fbaserel nor -msmall-code are required to build shared libraries. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP public key available -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 01:43:54 1995 Received: from bos1c.delphi.com ([192.80.63.6]) by nic.funet.fi with ESMTP id <91383-2>; Wed, 22 Mar 1995 01:39:09 +0200 Received: from bix.com by delphi.com (PMDF V4.3-9 #7804) id <01HOEOV33H2O94G4LP@delphi.com>; Tue, 21 Mar 1995 18:39:02 -0500 (EST) Received: by bix.com (CoSy3.31.1.50) id <9503211838.memo.81834@BIX.com>; Tue, 21 Mar 1995 18:38:16 -0500 (EST) Date: Tue, 21 Mar 1995 18:38:16 -0500 (EST) From: wpk@BIX.com Subject: unsubscribe To: amiga-gcc-port@nic.funet.fi Message-id: <9503211838.memo.81834@BIX.com> Content-transfer-encoding: 7BIT X-CoSy-To: amiga-gcc-port@nic.funet.fi unsubscribe wpk@bix.com From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 02:39:45 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91372-3>; Wed, 22 Mar 1995 02:37:48 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id ab11700; 21 Mar 95 10:21 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA000s0; Tue, 21 Mar 95 10:01:39 GMT Date: Tue, 21 Mar 95 10:01:39 GMT Message-Id: <9503211001.AA000rz@flevel.demon.co.uk> Message-Id: <20626500.ef422-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: GCC Bug - tmpnam(char*) Ive just been doing some porting of a program from Dice->Amiga GCC->PC GCC and ive found that both the Amiga and PC version of Gnu C have a bug in the tmpnam function. Ansi defines tmpnam as:- tmpnam(NULL) creates a string that is not the name of an existing file, and returns a pointer to an internal static array. tmpnam(s) stores the string in s as well as returning it as the function value;s must have romm for at least L_tmpnam characters. tmpnam generates a different name each time it is called; at most TMP_MAX different names are guaranteed during execution of the program. However the GCC version generates the same name each time it is called :-( For the moment I have written my own version which goes something like: char* mytemp(char* s) { static char str[256]; static int count=0; sprintf(str,"t:t_%lx.%d",(long)FindTask(NULL),count); if (s) strcpy(s,str); return(str); } Any ideas about what is up with the GCC version. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 02:43:46 1995 Received: from peach.newcastle.edu.au ([134.148.96.108]) by nic.funet.fi with SMTP id <91388-2>; Wed, 22 Mar 1995 02:42:13 +0200 Received: (from c9412417@localhost) by peach.newcastle.edu.au (8.6.10/8.6.9) id KAA03397 for amiga-gcc-port@lists.funet.fi; Wed, 22 Mar 1995 10:41:54 +1000 From: Robert Atkins Message-Id: <199503220041.KAA03397@peach.newcastle.edu.au> Subject: gcc gives me gurus! To: amiga-gcc-port@nic.funet.fi Date: Wed, 22 Mar 1995 10:41:54 +1000 (EST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 779 Help! Firstly, my system consists of an Amiga 4000/LC040 - ie MMU but no FPU. I have 10 meg of RAM and plenty of HD space so I thought I may as well install gcc - I am learning c++ at university. I downloaded and installed all the 020 archives, unpacked them and did all the assigns. I tried to compile hello.c . The machine thought about it for a couple of seconds and then gave me an 8000 000B guru. I deleted everything, downloaded the 68000 versions, re-installed, and it did exactly the same thing. Hellllp!! TIA, -- +--- -- - Robert Atkins, c9412417@peach.newcastle.edu.au | "When is Microsoft going to use its resources : : to do something truly revolutionary?" | - WiReD 2.10 - -- ---+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 02:48:19 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91389-3>; Wed, 22 Mar 1995 02:47:12 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id aj11700; 21 Mar 95 10:24 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA000rl; Tue, 21 Mar 95 09:25:42 GMT Date: Tue, 21 Mar 95 09:25:42 GMT Message-Id: <9503210925.AA000rk@flevel.demon.co.uk> Message-Id: <20625c94.493e0-dev@flevel.demon.co.uk> In-Reply-To: <9503201644.AA02779@nyx.cs.du.edu> (from Wyatt Miler ) (at Mon, 20 Mar 1995 09:44:27 -0700 (MST)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: wmiler@nyx.cs.du.edu Cc: amiga-gcc-port@nic.funet.fi, stieber@informatik.tu-muenchen.de Subject: Re: Bounced Mails Hi Wyatt, > > > > > > > Hi, > > > > > > I keep getting bounced mails from postings I made to the list a few days > > > ago, ive emailed postmaster but had no response, is anyone else having > > > this problem? > > > > Same here. I never really looked at the bounced mails; I was assuming > > that somebody on the list is having a problem. > > > They may be bouncing from my host, as we've been having mail problems of > late. The mail here seems to be working ok now could mess up again>. Thanks for letting me know. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 11:28:11 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91159-1> convert rfc822-to-8bit; Wed, 22 Mar 1995 11:18:30 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id ac12413; 22 Mar 95 6:15 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA00105; Tue, 21 Mar 95 19:23:04 GMT Date: Tue, 21 Mar 95 19:23:04 GMT Message-Id: <9503211923.AA00104@flevel.demon.co.uk> Message-Id: <2062e896.7ef40-dev@flevel.demon.co.uk> In-Reply-To: (from Nathaniel Myhre ) (at Thu, 16 Mar 1995 15:38:00 -0500) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT From: dev@flevel.demon.co.uk To: nmmyhre@undergrad.math.uwaterloo.ca Cc: amiga-gcc-port@nic.funet.fi Subject: Re: More gcc bugs... Hi Nathaniel, > I've run into another bug in gcc. I posted a list of bugs I had found > previously and I received no reply concerning them. Does this mean no > one cares or should I be posting these somewhere else? Can someone > please give me some feedback like, yes I've run into the bug or no I haven't. > > Try this: declare a structure of the following form: > > struct test{ > unsigned char a : 4; > unsigned char b : 4; > }; > > A sizeof(struct test) returns 2 instead of 1 (it only takes up 1 byte!). > I'm using gcc 2.6.3 by the way. I don't think GCC will allocate single bytes of memory because this can cause problems with aligment. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Multi-Media System Developers for Amiga, PC & Apple ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 13:30:25 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <91356-3>; Wed, 22 Mar 1995 13:18:29 +0200 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA07018; Wed, 22 Mar 1995 12:18:12 +0100 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA12161; Wed, 22 Mar 95 12:18:10 +0100 Date: Wed, 22 Mar 95 12:18:10 +0100 From: isthesin@TechFak.Uni-Bielefeld.DE Message-Id: <9503221118.AA12161@moos.techfak.uni-bielefeld.de> To: stieber@informatik.tu-muenchen.de Subject: Re: Shared executables for Amiga GNU ports Cc: amiga-gcc-port@nic.funet.fi From stieber@informatik.tu-muenchen.de Tue Mar 21 22:20:23 1995 > >I'd add: how can we build shared libraries without gcc-2.3.3? What is the problem with building shared libraries with 2.6.3? I don't have any problems... am I doing something wrong, or are we talking about different things (I'm talking about *.library files)? Actually, we need to have -fbaserel support, since the link libs are designed to be accessed by one program only, whereas shared libs MUST support multiple callers. > This is a major problem: When is -resident (or -fbaserel) support reestablished? (Phillipe?) That would be nice, but AFAIK neither -fbaserel nor -msmall-code are required to build shared libraries. It is required, unfortunately... Christian Bye.... Stephan From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 14:54:31 1995 Received: by nic.funet.fi id <91209-1>; Wed, 22 Mar 1995 14:41:05 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Cc: hoehle@inf-wiss.uni-konstanz.de Subject: Re: AmiTCP30b2 Message-Id: <95Mar22.144105+0200_eet.91209-1+24@nic.funet.fi> Date: Wed, 22 Mar 1995 14:41:04 +0200 AmiTCP 3.0b2, amigados tcp/ip networking software covered by the GNU General Public License, is now again available on the net at ftp.funet.fi in the directory /pub/amiga/gnu/tcpip. Note that the GPL requires people who distributed binaries also to provide sources on request, so removing version 3 from the net just because version 4 is commercial is not OK. -rw-r--r-- 1 vinsci ftp 670333 Mar 21 19:25 AmiTCP-api-30b2.lha -rw-r--r-- 1 vinsci ftp 702954 Mar 17 19:48 AmiTCP-bin-30b2.lha -rw-r--r-- 1 vinsci ftp 11134 Mar 17 19:48 AmiTCP-bin-30b2.readme -rw-r--r-- 1 vinsci ftp 1240756 Mar 17 18:13 AmiTCP-src-30b2.lha -rw-r--r-- 1 vinsci ftp 471929 Mar 21 19:16 AmiTCP-txt-20.lha -rw-r--r-- 1 vinsci ftp 6232 Mar 17 19:45 AmiTCP_telnet36 lrwxrwxrwx 1 vinsci ftp 10 Mar 22 14:27 COPYING -> ../COPYING -rw-r--r-- 1 vinsci ftp 11271 Mar 22 14:26 COPYRIGHTS -rw-r--r-- 1 vinsci ftp 2100 Mar 17 18:03 tcp_AmiTCP -- vinsci From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 15:00:36 1995 Received: by nic.funet.fi id <91211-4>; Wed, 22 Mar 1995 14:43:28 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Thanks to... Message-Id: <95Mar22.144328+0200_eet.91211-4+32@nic.funet.fi> Date: Wed, 22 Mar 1995 14:43:21 +0200 I almost forgot! Many thanks to Joerg-Cyril Hoehle for going through the trouble of uploading AmiTCP 3.0b2 here. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 15:00:36 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <91215-2>; Wed, 22 Mar 1995 14:44:32 +0200 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA07779; Wed, 22 Mar 1995 13:43:54 +0100 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA12603; Wed, 22 Mar 95 13:43:52 +0100 Date: Wed, 22 Mar 95 13:43:52 +0100 From: isthesin@TechFak.Uni-Bielefeld.DE Message-Id: <9503221243.AA12603@moos.techfak.uni-bielefeld.de> To: zrawi01@decap2.zdv.uni-tuebingen.de Subject: Re: Shared executables for Amiga GNU ports Cc: amiga-gcc-port@nic.funet.fi From zrawi01@decap2.zdv.uni-tuebingen.de Wed Mar 22 14:14:12 1995 > Actually, we need to have -fbaserel support, since the link libs are > designed to be accessed by one program only, whereas shared libs > MUST support multiple callers. In contrary I think that exactly this point is better done without -fbaserel. What does baserel mean? It tells the compiler that you don't want to use more than 64K of global and static data, so that he may reserve the a4 register for addressing data. In terms of our library this means, that we need to initialize the a4 register eny time, the library is entered, so that we can do something like move.l 36(a4),a6 ; _SysBase is the 9'th long word of the jsr.l _LVOAllocMem(a6) ; of the data segment Without -fbaserel this reads as move.l $0x200452 ; _SysBase is stored at this address jsr.l _LVOAllocMem(a6) where the address is created by LoadSeg() and never modified as long as the library lives. The first code obviously depends on the a4 register being initilized, thus it is even safer to leave -fbaserel away. I think there is some misunderstanding here... The problem is the following: The static link libs contain code AND data. By linking against the static lib, all code and data is drawn into the executable. So code and data are part of exactly one program (the executable). With this, access to data can be done in the usual way, without -fbaserel. BUT: If we build a shared lib from the static link lib, code exists only once and is SHARED between callers of the lib (callers means different executables, using the lib) Here the problem comes up that the DATA MUST not be shared between different callers. This is because it is PRIVATE to the individual caller. IMHO the only way to realize multiple callers is the use of -fbaserel, since now access is relative to the A4 register and thus, every program can have IT'S OWN data, without interferring with each other. If someone has a differnt idea, please tell me, since I dislike the limitations of -fbaserel too (only 64k data seg, which seems to be not enough for some programs, like gcc itself). > It is required, unfortunately... What for? Jochen Bye... Stephan Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA25069; Wed, 22 Mar 1995 13:14:12 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9503221214.AA25069@decap2.zdv.uni-tuebingen.de> Subject: Re: Shared executables for Amiga GNU ports To: isthesin Date: Wed, 22 Mar 1995 13:14:12 +0100 (MET) In-Reply-To: <9503221118.AA12161@moos.techfak.uni-bielefeld.de> from "isthesin@techfak.uni-bielefeld.de" at Mar 22, 95 12:18:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1063 Status: R From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 15:19:15 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91268-4>; Wed, 22 Mar 1995 15:08:19 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA27291; Wed, 22 Mar 1995 13:08:11 GMT Date: Wed, 22 Mar 1995 13:05:39 +0000 (GMT) From: Peter Ivimey-Cook To: isthesin@techfak.uni-bielefeld.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Shared executables for Amiga GNU ports In-Reply-To: <9503221243.AA12603@moos.techfak.uni-bielefeld.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 22 Mar 1995 isthesin@techfak.uni-bielefeld.de wrote: > > BUT: If we build a shared lib from the static link lib, code exists only once > and is SHARED between callers of the lib (callers means different executables, using the lib) > Here the problem comes up that the DATA MUST not be shared between different callers. > This is because it is PRIVATE to the individual caller. > IMHO the only way to realize multiple callers is the use of -fbaserel, since now access > is relative to the A4 register and thus, every program can have IT'S OWN data, without > interferring with each other. It depends on the way the library is constructed. Most Amiga libraries are written to be re-entrant - i.e. they don't use global data items which would require loading - they use the stack. For items which can't be done this way, there are two solutions - 1. Use the library data space. It's global, unless you make provision for it to be otherwise - and availabl easily off a6. 2. Manage your own data space, using tags or whatever to allocate space for callers. Note that the only indication you have as to who is the current caller is the result of FindTask(). So, in general libraries try to make required data passed through parameters, or available on the stack, or shareably global. In which case no baserel or anything else is required. Come to think of it, how would using baserel help anyway? Can you give me an example? Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 16:06:40 1995 Received: from cip2.e-technik.uni-erlangen.de ([131.188.139.62]) by nic.funet.fi with SMTP id <91361-2>; Wed, 22 Mar 1995 15:56:16 +0200 Received: (from theurung@localhost) by cip2.e-technik.uni-erlangen.de (8.6.10/8.6.6) id OAA27484 for amiga-gcc-port@lists.funet.fi; Wed, 22 Mar 1995 14:56:08 +0100 From: Thomas Heurung Message-Id: <199503221356.OAA27484@cip2.e-technik.uni-erlangen.de> Subject: bgui To: amiga-gcc-port@nic.funet.fi Date: Wed, 22 Mar 95 14:56:07 MEZ Mailer: Elm [revision: 70.85] Is there anybody with experience with gcc and bgui? I've tried to work with gcc and bgui, i.e. i converted the include files to match the format of gcc, but i failed to compile the simple demo programs for bgui. May someone help me? Ciao thomas From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 16:52:25 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <91354-2>; Wed, 22 Mar 1995 16:44:53 +0200 Received: from amigalib.com (165.247.33.2) by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HOFUYKHVC0002C1V@FIPORT.FUNET.FI>; Wed, 22 Mar 1995 14:44:30 +0200 (EET) Received: by amigalib.com (Smail3.1.28.1 #64) id m0rrRxK-0004nYC; Wed, 22 Mar 95 08:04 MST Date: Wed, 22 Mar 1995 08:04:18 -0700 (MST) From: fnf@amigalib.com (Fred Fish) Subject: Re: Shared executables for Amiga GNU ports In-reply-to: <9503221118.AA12161@moos.techfak.uni-bielefeld.de> from "isthesin@TechFak.Uni-Bielefeld.DE" at Mar 22, 95 12:18:10 pm To: isthesin@TechFak.Uni-Bielefeld.DE Cc: stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi Message-id: MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL23] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-length: 364 > That would be nice, but AFAIK neither -fbaserel nor -msmall-code are > required to build shared libraries. > > It is required, unfortunately... I'm currently building my ixemul.library versions with gcc 2.6.3 (without -fbaserel or -msmall-code) and they seem to work just fine. Is there a bug here somewhere I don't know about, just waiting to bite? -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 17:18:16 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <91371-2>; Wed, 22 Mar 1995 17:08:04 +0200 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA27464; Wed, 22 Mar 1995 16:13:31 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9503221513.AA27464@decap2.zdv.uni-tuebingen.de> Subject: Re: Shared executables for Amiga GNU ports (fwd) To: amiga-gcc-port@nic.funet.fi Date: Wed, 22 Mar 1995 16:13:30 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1508 Forwarded message: >From zrawi01 Wed Mar 22 16:11:40 1995 Subject: Re: Shared executables for Amiga GNU ports To: fnf@amigalib.com (Fred Fish) Date: Wed, 22 Mar 1995 16:11:40 +0100 (MET) In-Reply-To: from "Fred Fish" at Mar 22, 95 08:04:18 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1155 > > > That would be nice, but AFAIK neither -fbaserel nor -msmall-code are > > required to build shared libraries. > > > > It is required, unfortunately... > > I'm currently building my ixemul.library versions with gcc 2.6.3 (without > -fbaserel or -msmall-code) and they seem to work just fine. Is there a > bug here somewhere I don't know about, just waiting to bite? Christian, Stephan and I misunderstood each other somewhat. Matthias's posting and private mails cleared up things. To recall it - Of course it is possible to write shared libraries (ixemul.library, for example) with gcc, but *only* if the source is written with a shared library in mind. - It is possible (Matthias told how) to develop a solution that would allow to use existing source of link libraries for shared libraries (libbfd sources, for example) with at most very minor modifications - -fbaserel would be a must for the above solution. On the other hand it is not possible yet, at least not without going to the assembler level. (Really deep, not just using some headers with asm keywords.) I hope, this clears up things. Jochen From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 17:27:39 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91465-1>; Wed, 22 Mar 1995 17:18:56 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26493-3>; Wed, 22 Mar 1995 16:16:08 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209163-2>; Wed, 22 Mar 1995 16:15:48 +0100 Subject: Re: bgui From: Christian Stieber To: theurung@cip.e-technik.uni-erlangen.de (Thomas Heurung) Date: Wed, 22 Mar 1995 16:15:42 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199503221356.OAA27484@cip2.e-technik.uni-erlangen.de> from "Thomas Heurung" at Mar 22, 95 02:56:07 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1001 Message-Id: <95Mar22.161548+0100mesz.209163-2+865@hphalle0.informatik.tu-muenchen.de> > Is there anybody with experience with gcc and bgui? No, but... > I've tried to work with gcc and bgui, i.e. i converted > the include files to match the format of gcc, but i failed > to compile the simple demo programs for bgui. How about giving us some idea what happened? Did you get errors from the compiler (what errors?)? Did you get linker errors (again, what errors?)? Did it crash? Quite often the problem is nt actually related to some special library, but applies to all libraries. So, by giving us more detailed information, even ppl that never used bgui might be able to help you just by looking at the errors. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer PGP public key available -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 18:31:47 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91379-2>; Wed, 22 Mar 1995 18:16:53 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 22 Mar 1995 17:11:29 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA08441; Wed, 22 Mar 95 17:11:27 +0100 Date: Wed, 22 Mar 95 17:11:27 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503221611.AA08441@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA09825; Wed, 22 Mar 95 17:11:21 +0100 To: amiga-gcc-port@nic.funet.fi Subject: Re: AmiTCP30b2 In-Reply-To: <95Mar22.144105+0200_eet.91209-1+24@nic.funet.fi> References: <95Mar22.144105+0200_eet.91209-1+24@nic.funet.fi> Leonard Norrgard writes: > -rw-r--r-- 1 vinsci ftp 702954 Mar 17 19:48 AmiTCP-bin-30b2.lha > -rw-r--r-- 1 vinsci ftp 6232 Mar 17 19:45 AmiTCP_telnet36 > -rw-r--r-- 1 vinsci ftp 2100 Mar 17 18:03 tcp_AmiTCP I should mention that AmiTCP_telnet36 is a bug-fix (by the AmiTCP/IP group) to the telnet program in the bin-archive, whereas the extra tcp_AmiTCP is old and should be deleted (I can't remember if it was for AmiTCP2.3). Use the one on the bin archive (EMACS subdir) instead. Enjoy, Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 19:02:23 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91384-4>; Wed, 22 Mar 1995 18:37:12 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rrTp6-0004nYC; Wed, 22 Mar 95 10:03 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: GNU Fortran To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Wed, 22 Mar 1995 10:03:56 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 840 I know this is a "gcc list", but I thought that perhaps some people on it might be interested to know that I've integrated the latest GNU FORTRAN compiler into my source and binary tree for the next FreshFish CD. For the first release of a compiler for a significantly complex language, the results are encouraging. I've been able to use it to compile various scientific type libraries (eispack for example) and run several fairly complex programs (paranoia for example). However there are still a number of unimplemented features that prevents other stable FORTRAN code from building, so it's not quite ready for prime time. I does however seem stable, in that it hasn't crashed once, and when it does choke on something, it does so gracefully without crashing the system, itself, or wiping out my hard drive. :-) Just FYI... -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 19:05:47 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91365-3>; Wed, 22 Mar 1995 18:47:38 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 22 Mar 1995 17:39:29 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA08550; Wed, 22 Mar 95 17:39:27 +0100 Date: Wed, 22 Mar 95 17:39:26 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503221639.AA08550@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA09864; Wed, 22 Mar 95 17:39:27 +0100 To: amiga-gcc-port@nic.funet.fi Subject: Re: Shared executables for Amiga GNU ports (fwd) In-Reply-To: <9503221513.AA27464@decap2.zdv.uni-tuebingen.de> References: <9503221513.AA27464@decap2.zdv.uni-tuebingen.de> Jochen Wiedmann writes: > - Of course it is possible to write shared libraries (ixemul.library, > for example) with gcc, but *only* if the source is written with a > shared library in mind. Could you elaborate on that so that we know a little more about it, please? Does it mean that you can't use any global variable? Or only one but declare it with something like__asm__("a4") and use it as a base pointer? Does it imply that you must use the inline/*.h? Does it imply that you must use a special startup code (of course :-), what must it do? Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 20:12:31 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91273-1>; Wed, 22 Mar 1995 20:08:08 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 22 Mar 1995 19:04:21 +0100 Received: from stetten.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA08849; Wed, 22 Mar 95 19:04:19 +0100 Date: Wed, 22 Mar 95 19:04:19 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503221804.AA08849@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA09921; Wed, 22 Mar 95 19:04:20 +0100 To: amiga-gcc-port@nic.funet.fi Subject: Re: Shared executables for Amiga GNU ports In-Reply-To: <9503221243.AA12603@moos.techfak.uni-bielefeld.de> References: <9503221243.AA12603@moos.techfak.uni-bielefeld.de> isthesin@techfak.uni-bielefeld.de writes: > What does baserel mean? It tells the compiler that you don't want to > use more than 64K of global and static data, so that he may reserve > the a4 register for addressing data. In terms of our library this Why can't GCC be told to use a6, as it's already pointing to the library base? All variables could be kept there, couldn't they? > If someone has a differnt idea, please tell me, since I dislike the limitations of -fbaserel too > (only 64k data seg, which seems to be not enough for some programs, like gcc itself). Obviously there must be other solutions. Being able to build a library is not far away from being able to build a pure (=residentable) program, and gcc-2.3.3 was both largely above 64KB in size and residentable. So what's the trick? Joerg. From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 20:31:19 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <91380-2>; Wed, 22 Mar 1995 20:25:39 +0200 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA29337; Wed, 22 Mar 1995 18:25:17 GMT Date: Wed, 22 Mar 1995 18:22:45 +0000 (GMT) From: Peter Ivimey-Cook To: Joerg-Cyril Hoehle Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Shared executables for Amiga GNU ports In-Reply-To: <9503221804.AA08849@inf-wiss.uni-konstanz.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Obviously there must be other solutions. Being able to build a library > is not far away from being able to build a pure (=residentable) > program, and gcc-2.3.3 was both largely above 64KB in size and > residentable. So what's the trick? > Don't use global data referenced absolutely! residentable implies reentrant, which means that global data is read-only apart from the first instance (i.e. it's OK to initialise it, once, but once initialised it can't be modified or reinitialised). This effectively means the only data used in the must be on the stack or referenced from it by pointers, as the stack is separate for different invocations of a resident program. Of course this does pose a major headache for programs which use lots of global data. And watch out for library use too! Failing this, one must use a global data access mechanism which allows: (a) the base address to be set up - e.g. by calling AllocMem() and storing the result in a register (NOT a global!) (b) *all* accesses to "global" data are relative to this register. I think this is what baserel starts to do, but as I haven't ued it I'm not sure. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 20:59:56 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91185-3>; Wed, 22 Mar 1995 20:56:46 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26482-3>; Wed, 22 Mar 1995 19:56:31 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209163-2>; Wed, 22 Mar 1995 19:56:16 +0100 Subject: Re: Shared executables for Amiga GNU ports (fwd) From: Christian Stieber To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Wed, 22 Mar 1995 19:56:13 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503221639.AA08550@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Mar 22, 95 05:39:26 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1608 Message-Id: <95Mar22.195616+0100mesz.209163-2+908@hphalle0.informatik.tu-muenchen.de> > Jochen Wiedmann writes: > > - Of course it is possible to write shared libraries (ixemul.library, > > for example) with gcc, but *only* if the source is written with a > > shared library in mind. > > Could you elaborate on that so that we know a little more about it, > please? - keep in mind that all callers use the same global and static variables; that means: either protect them with semaphores (e.g. if your library is using a memory pool), or allocate a block of memory inside your library and pass pointers around. - the "startup" code will contain the ROMTag structure and related data, as well as stubs to push parameters on the stack, calling the C function, cleaning up the stack. - I generally write the libOpen(), libClose(), libInit() etc. functions as normal C functions, but some people might prefer to put them into the "startup code". That's about all. It also means that many link-lib functions (e.g. from libnix) can't be used; this has to be decided on a per-function basis. It's pretty safe to say that you can't use stdio and malloc(). strcpy(), isdigit() are safe, etc. Just be careful. Think about what the function does; that should give you an idea whether you can use it or not. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Mar 22 23:23:54 1995 Received: from picard.anderson.edu ([199.8.4.1]) by nic.funet.fi with SMTP id <91394-2>; Wed, 22 Mar 1995 23:19:31 +0200 Received: by picard.anderson.edu (1.38.193.5/16.2) id AA28734; Wed, 22 Mar 1995 16:23:30 -0500 From: Ran-D Cox Subject: Other C compilers? To: amiga-gcc-port@nic.funet.fi Date: Wed, 22 Mar 95 16:23:30 EST Full-Name: Ran-D Cox Mailer: Elm [revision: 70.85.2.1] Message-Id: <95Mar22.231931+0200_eet.91394-2+44@nic.funet.fi> Hello, All! I bought my A1200 1.5 years ago and have been ACHING to program the thing. I've learned C here at Anderson, but GCC takes 4MB of RAM. My stock A1200 has only 2MB. Can anyone recommend another (preferably free) C compiler that will work? --Randy Cox rkc@picard.anderson.edu -- -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- "Surely this is the stuff heaven is made of." - Ralph Waldo Emerson (describing nitrous oxide) From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 01:09:00 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <91358-2>; Thu, 23 Mar 1995 01:03:02 +0200 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA28954; Thu, 23 Mar 1995 00:02:50 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9503222302.AA28954@decap2.zdv.uni-tuebingen.de> Subject: Re: Shared executables for Amiga GNU ports To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Thu, 23 Mar 1995 00:02:47 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503221639.AA08550@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Mar 22, 95 05:39:26 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 890 > > Jochen Wiedmann writes: > > - Of course it is possible to write shared libraries (ixemul.library, > > for example) with gcc, but *only* if the source is written with a > > shared library in mind. > > Could you elaborate on that so that we know a little more about it, > please? > > Does it mean that you can't use any global variable? Or only one but > declare it with something like__asm__("a4") and use it as a base > pointer? Does it imply that you must use the inline/*.h? Does it imply > that you must use a special startup code (of course :-), what must it > do? In short: You may well use something like struct ExecBase *SysBase; and read this variable from anywhere within your program, because you can a) initialize it from the library startup code and b) be sure that it never changes but you must not use global or static data otherwise. Jochen From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 11:49:01 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91411-3>; Thu, 23 Mar 1995 11:38:21 +0200 Received: from guava.cms.dmu.ac.uk (guava.cms.dmu.ac.uk [146.227.102.13]) by macondo.dmu.ac.uk (8.6.11/8.6.11) with ESMTP id JAA13618; Thu, 23 Mar 1995 09:39:33 GMT Received: by guava.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA293631427; Thu, 23 Mar 1995 09:37:07 GMT Date: Thu, 23 Mar 1995 09:37:07 +0000 (GMT) From: Derek Piper X-Sender: se1dp@guava.cms.dmu.ac.uk To: Thomas Heurung Cc: amiga-gcc-port@nic.funet.fi Subject: Re: bgui In-Reply-To: <199503221356.OAA27484@cip2.e-technik.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 22 Mar 1995, Thomas Heurung wrote: > Is there anybody with experience with gcc and bgui? > I've tried to work with gcc and bgui, i.e. i converted > the include files to match the format of gcc, but i failed > to compile the simple demo programs for bgui. > May someone help me? I don't use BGUI, (I didn't like it), I use GadToolsBox20c. GadToolsBox generated source compiles and runs fine, even though the IDCMP handler is a bit ropey and in need of tweaking. I suggest you try this and as someone else mentioned, include any errors or warnings that the compilation produces. Which includes did you convert by the way ? Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | World Wide Web Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Foolproof operation: All parameters are hard coded. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 12:27:24 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91462-1>; Thu, 23 Mar 1995 12:21:08 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA22563 (5.65c8/IDA-1.4.4 for ); Thu, 23 Mar 1995 11:20:59 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA05944; Thu, 23 Mar 95 11:20:58 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503231020.AA05944@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Shared executables for Amiga GNU ports To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Thu, 23 Mar 1995 11:20:57 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503221804.AA08849@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Mar 22, 95 07:04:19 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 522 > > Why can't GCC be told to use a6, as it's already pointing to the library > base? All variables could be kept there, couldn't they? > Theoretically yes, but practically gcc can't preserve the contents of the (fixed) global data segment pointer (without major changes to the compiler). Therefore you would lose the ability to call other shared libraries from your library. Another problem is that all that wear and tear in a6 could probably give worse code than using two registers for two different things. Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 12:50:32 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91399-2>; Thu, 23 Mar 1995 12:38:34 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AB27327 (5.65c8/IDA-1.4.4 for ); Thu, 23 Mar 1995 11:38:15 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA05963; Thu, 23 Mar 95 11:38:14 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503231038.AA05963@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Shared executables for Amiga GNU ports (fwd) To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Thu, 23 Mar 1995 11:38:14 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Mar22.195616+0100mesz.209163-2+908@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Mar 22, 95 07:56:13 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 702 [A lot of things about shared libraries deleted] > > That's about all. It also means that many link-lib functions (e.g. from > libnix) can't be used; this has to be decided on a per-function basis. > It's pretty safe to say that you can't use stdio and malloc(). strcpy(), > isdigit() are safe, etc. Just be careful. Think about what the function does; > that should give you an idea whether you can use it or not. > Just for the log: isdigit() isn't 100% save, too. It depends on the current locale which _might_ be different for different callers. Curiously enough, fprintf() is save (but calls vfprintf() which isn't) etc. You really have to know your library in and out to decide this. Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 13:02:25 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91426-1>; Thu, 23 Mar 1995 12:52:07 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA29181 (5.65c8/IDA-1.4.4 for ); Thu, 23 Mar 1995 11:52:02 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA06028; Thu, 23 Mar 95 11:52:01 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503231052.AA06028@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Problems with gcc2.6.3 To: amiga-gcc-port@nic.funet.fi Date: Thu, 23 Mar 1995 11:52:01 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 406 Hello, there are two things I want to mention on gcc2.6.3: 1. The preprocessor option -P doesn't work anymore and - even more strange - it swallows the following option, too. What's the reason for this? 2. When building a crosscompiler --host=sparc-sun --target=amigados the compiler tries to insert the special stack swapping code. Take care if you want to build a crosscompiler. Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 17:30:45 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91437-1>; Thu, 23 Mar 1995 17:23:50 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26469-3>; Thu, 23 Mar 1995 16:23:32 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209167-2>; Thu, 23 Mar 1995 16:23:20 +0100 Subject: Re: Other C compilers? From: Christian Stieber To: rkc@picard.anderson.edu (Ran-D Cox) Date: Thu, 23 Mar 1995 16:23:19 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Mar22.231931+0200_eet.91394-2+44@nic.funet.fi> from "Ran-D Cox" at Mar 22, 95 04:23:30 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1250 Message-Id: <95Mar23.162320+0100mesz.209167-2+1357@hphalle0.informatik.tu-muenchen.de> > I bought my A1200 1.5 years ago and have been ACHING to > program the thing. I've learned C here at Anderson, but > GCC takes 4MB of RAM. My stock A1200 has only 2MB. Can > anyone recommend another (preferably free) C compiler > that will work? Hm.. that's difficult. Well, actually: the answer is "no, but...". On some older fish disk is an early, freely distributable version of Dice. It isn't ANSI compliant, and probably doesn't work very well, but it's free :) You can write your own compiler, but that means you'd need an compiler to compile it -> no go. Btw, that's not a joke. Setting up a simple compiler isn't *that* difficult. The complicated things are the optimizer and getting the thing to produce good quality code and usable diagnostics. If you can live with bad code, it gets easier :) So, the best thing would be to get another 2MB of FastRAM :) Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 17:49:45 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <91449-2>; Thu, 23 Mar 1995 17:43:44 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26467-4>; Thu, 23 Mar 1995 16:43:18 +0100 Received: by hphalle0.informatik.tu-muenchen.de id <209163-2>; Thu, 23 Mar 1995 16:43:05 +0100 Subject: Re: Shared executables for Amiga GNU ports From: Christian Stieber To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Thu, 23 Mar 1995 16:43:01 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503222302.AA28954@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Mar 23, 95 00:02:47 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1128 Message-Id: <95Mar23.164305+0100mesz.209163-2+1364@hphalle0.informatik.tu-muenchen.de> > In short: You may well use something like > > struct ExecBase *SysBase; > > and read this variable from anywhere within your program, because you > can > > a) initialize it from the library startup code and > b) be sure that it never changes > > but you must not use global or static data otherwise. Not necessarily. For example, you can do this: static void *MemoryPool; static struct Semaphore MallocSemaphore; void *malloc(size_t Size) { size_t *Memory; Size+=sizeof(size_t); ObtainSemaphore(&MallocSemaphore); Memory=LibAllocPooled(MemoryPool,Size); ReleaseSemaphore(&MallocSemaphore); if (Memory) { *Memory=Size; Memory++; } return Memory; } To get a malloc() that can be used anywhere inside the library. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 17:54:51 1995 Received: from lamb.sas.com ([192.35.83.8]) by nic.funet.fi with SMTP id <91456-1>; Thu, 23 Mar 1995 17:45:49 +0200 Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA06226; Thu, 23 Mar 1995 10:45:25 -0500 Received: from cdevil.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA01922; Thu, 23 Mar 1995 10:45:11 -0500 Received: by cdevil.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA20489; Thu, 23 Mar 1995 10:45:10 -0500 From: James Cooper Message-Id: <199503231545.AA20489@cdevil.unx.sas.com> Subject: Re: Other C compilers To: amiga-gcc-port@nic.funet.fi Date: Thu, 23 Mar 1995 10:45:10 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1270 >> I bought my A1200 1.5 years ago and have been ACHING to >> program the thing. I've learned C here at Anderson, but >> GCC takes 4MB of RAM. My stock A1200 has only 2MB. Can >> anyone recommend another (preferably free) C compiler >> that will work? > >Hm.. that's difficult. Well, actually: the answer is "no, but...". > >On some older fish disk is an early, freely distributable version >of Dice. It isn't ANSI compliant, and probably doesn't work very well, >but it's free :) SAS/C is still available, and at the student price of $99.50 (or DM160+VAT) in Europe, its not too expensive... >Btw, that's not a joke. Setting up a simple compiler isn't *that* >difficult. The complicated things are the optimizer and getting the >thing to produce good quality code and usable diagnostics. If you can >live with bad code, it gets easier :) True. A real Masochist could probably write a compiler in ARexx. One massive, slow script, there. >So, the best thing would be to get another 2MB of FastRAM :) Don't you mean "get another 2MB of FastRAM to START, and plan to get more if you want to do anything complex, or run the optimizer a lot. Also, a Harddrive is *required* for GCC on the Amiga."? SAS/C, DICE, HCC, etc. will all run from floppies... From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 17:59:51 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91465-4>; Thu, 23 Mar 1995 17:54:40 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rrpay-0004naC; Thu, 23 Mar 95 09:18 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Other C compilers? To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Thu, 23 Mar 1995 09:18:48 -0700 (MST) Cc: rkc@picard.anderson.edu, amiga-gcc-port@nic.funet.fi In-Reply-To: <95Mar23.162320+0100mesz.209167-2+1357@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Mar 23, 95 04:23:19 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 709 > > GCC takes 4MB of RAM. My stock A1200 has only 2MB. Can > > anyone recommend another (preferably free) C compiler > > that will work? > > Hm.. that's difficult. Well, actually: the answer is "no, but...". > > On some older fish disk is an early, freely distributable version > of Dice. It isn't ANSI compliant, and probably doesn't work very well, > but it's free :) > > You can write your own compiler, but that means you'd need an > compiler to compile it -> no go. One of the things I hope to eventually add to my FreshFish CD is a port of lcc, which is much smaller and faster than gcc, and apparently somewhat more ANSI compliant. I just haven't had time yet to look at doing so. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 18:06:35 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <91450-3>; Thu, 23 Mar 1995 17:57:11 +0200 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA25141 (5.65c8/IDA-1.4.4 for ); Thu, 23 Mar 1995 16:56:10 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA06896; Thu, 23 Mar 95 16:56:09 +0100 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9503231556.AA06896@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Other C compilers? To: amiga-gcc-port@nic.funet.fi Date: Thu, 23 Mar 1995 16:56:09 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 744 > > Btw, that's not a joke. Setting up a simple compiler isn't *that* > difficult. The complicated things are the optimizer and getting the > thing to produce good quality code and usable diagnostics. If you can > live with bad code, it gets easier :) > Don't know if it's feasible, but: Is it possible to create a stripped down (to the bare bones) version of gcc that would be able to run on a 2MB machine? Let's say you remove every optimization and target options, rtl dumping, etc. in the main compiler pass, use defaults for the specs file (sparing the parser in the front end) use static linking (sparing another 150k for ixemul.library), putting intermediate files into SYS:T instead of T: and so on. Or is it too much work? Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 18:13:40 1995 Received: from lamb.sas.com ([192.35.83.8]) by nic.funet.fi with SMTP id <91452-4>; Thu, 23 Mar 1995 17:59:20 +0200 Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA07993; Thu, 23 Mar 1995 10:59:03 -0500 Received: from cdevil.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA05527; Thu, 23 Mar 1995 10:58:48 -0500 Received: by cdevil.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA20527; Thu, 23 Mar 1995 10:58:47 -0500 From: James Cooper Message-Id: <199503231558.AA20527@cdevil.unx.sas.com> Subject: Re: Other C compilers To: amiga-gcc-port@nic.funet.fi Date: Thu, 23 Mar 1995 10:58:47 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 360 >SAS/C is still available, and at the student price of $99.50 (or DM160+VAT) >in Europe, its not too expensive... Arrggghhhh! I do this all the time... that's why I always recommend contacting the SAS Europe HQ directly... The student price is more like DM184 + VAT. DM160+VAT is the price to upgrade from V6.0 to V6.50. Or did I screw it up again? :-( From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 18:13:40 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91453-1>; Thu, 23 Mar 1995 17:59:59 +0200 Received: by colombo.telesys-innov.fr; Thu, 23 Mar 1995 16:55:13 GMT From: Philippe BRAND Message-Id: <199503231655.QAA11243@colombo.telesys-innov.fr> Subject: Re: Problems with gcc2.6.3 To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Thu, 23 Mar 1995 16:55:12 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9503231052.AA06028@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Mar 23, 95 11:52:01 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 353 Matthias Fleischer writes: > 2. When building a crosscompiler --host=sparc-sun --target=amigados the > compiler tries to insert the special stack swapping code. > Take care if you want to build a crosscompiler. My fault, it's already corrected in 2.6.4-beta. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 18:18:52 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <91464-4>; Thu, 23 Mar 1995 18:06:53 +0200 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 23 Mar 1995 17:04:42 +0100 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA11685; Thu, 23 Mar 95 17:04:37 +0100 Date: Thu, 23 Mar 95 17:04:37 +0100 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503231604.AA11685@inf-wiss.uni-konstanz.de> To: fnf@amigalib.com Subject: Re: Other C compilers? Cc: amiga-gcc-port@nic.funet.fi > From: fnf@amigalib.com (Fred Fish) > One of the things I hope to eventually add to my FreshFish CD is a > port of lcc, which is much smaller and faster than gcc, and apparently > somewhat more ANSI compliant. I just haven't had time yet to look Maybe you should also ask the DICE group if they still have a freely distribuable version like they had for DICE2.02, 2.06.37, 2.07.xx and maybe newer versions. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 18:27:26 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <91188-1>; Thu, 23 Mar 1995 18:20:02 +0200 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA00983; Thu, 23 Mar 1995 17:19:53 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9503231619.AA00983@decap2.zdv.uni-tuebingen.de> Subject: Re: Other C compilers? To: amiga-gcc-port@nic.funet.fi Date: Thu, 23 Mar 1995 17:19:52 +0100 (MET) In-Reply-To: from "Fred Fish" at Mar 23, 95 09:18:48 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 271 > One of the things I hope to eventually add to my FreshFish CD is a > port of lcc, which is much smaller and faster than gcc, and apparently > somewhat more ANSI compliant. I just haven't had time yet to look > at doing so. What's lcc? I never heard of it. Jochen From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 18:33:46 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91159-4>; Thu, 23 Mar 1995 18:23:35 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rrq4t-0004nYC; Thu, 23 Mar 95 09:49 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Other C compilers? To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Thu, 23 Mar 1995 09:49:43 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <9503231604.AA11685@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Mar 23, 95 05:04:37 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 763 > > One of the things I hope to eventually add to my FreshFish CD is a > > port of lcc, which is much smaller and faster than gcc, and apparently > > somewhat more ANSI compliant. I just haven't had time yet to look > > Maybe you should also ask the DICE group if they still have a freely > distribuable version like they had for DICE2.02, 2.06.37, 2.07.xx and > maybe newer versions. Won't work. In the toolset I'm building on the FreshFish CD's, source is an absolute requirement. The basic premise is that everything is provided to rebuild every part of the environment. The only exception I've made so far (and that is only an exception to allow use of SAS/C which isn't provided on the CD) is for GNU emacs, since it is such an important piece. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 18:43:11 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <91400-2>; Thu, 23 Mar 1995 18:35:23 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0rrqGs-0004nYC; Thu, 23 Mar 95 10:02 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Other C compilers? To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Thu, 23 Mar 1995 10:02:05 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503231619.AA00983@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Mar 23, 95 05:19:52 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2529 > > One of the things I hope to eventually add to my FreshFish CD is a > > port of lcc, which is much smaller and faster than gcc, and apparently > > somewhat more ANSI compliant. I just haven't had time yet to look > > at doing so. > > What's lcc? I never heard of it. ============================ begin inclusion =========================== lcc is the retargetable compiler for ANSI C described in our book `A Retargetable C Compiler: Design and Implementation' (Benjamin Cummings, 1995, ISBN 0-8053-1670-1), which will be available in December 1994. lcc is in production use at Princeton University and AT&T Bell Laboratories. The public distribution directory contains the following files. README this file. install.{ps,txt} describes the distribution and gives installation instructions. install.ps is the PostScript generated from the HTML document, install.html, which is included in the the distribution. X.Y.tar.{Z,gz} a compressed tar files for the distribution of version X.Y, e.g., 3.0.tar.Z the tar file compressed with compress. This distribution includes user documentation, the front end, the driver program, code generators for the SPARC, MIPS R3000 and x86, and the code-generator generator that produced them. A .gz file is the tar file compressed with gzip instead of compress. The distribution is available via `anonymous' ftp from ftp.cs.princeton.edu (128.112.152.13) in the directory pub/lcc. Obtaining and extracting the distribution into its own directory is accomplished by the following commands. Replace `3.0' with the latest version, which is the only one typically available; versions like `3.0a' identify minor updates and versions like `3.1beta' identify pre-releases (which might be incomplete). As suggested, use your login as the password, and use ftp's binary transfer mode. mkdir lcc cd lcc ftp ftp.cs.princeton.edu anonymous yourlogin cd pub/lcc binary get 3.0.tar.Z dist.tar.Z quit zcat dist.tar | tar xpof - rm dist.tar.Z To be added to the lcc mailing list, send a message with the 1-line body subscribe lcc to majordomo@cs.princeton.edu. This line must appear in the message body; `Subject:' lines are ignored. To learn more about mailing lists served by majordomo, send a message with the body `help' to majordomo@cs.princeton.edu. Additional information about lcc and about our book is available on the WWW at URL http://www.cs.princeton.edu/software/lcc. Chris Fraser / cwf@research.att.com David Hanson / drh@cs.princeton.edu Thu Aug 18 13:36:15 EDT 1994 From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 23:05:36 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91537-4>; Thu, 23 Mar 1995 22:12:43 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id ae29908; 23 Mar 95 19:13 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA001m0; Thu, 23 Mar 95 16:42:55 GMT Date: Thu, 23 Mar 95 16:42:55 GMT Message-Id: <9503231642.AA001lz@flevel.demon.co.uk> Message-Id: <2065660c.dbba0-dev@flevel.demon.co.uk> In-Reply-To: <95Mar22.231931+0200_eet.91394-2+44@nic.funet.fi> (from Ran-D Cox ) (at Wed, 22 Mar 95 16:23:30 EST) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: rkc@picard.anderson.edu Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Other C compilers? Hi Ran-D, > I bought my A1200 1.5 years ago and have been ACHING to > program the thing. I've learned C here at Anderson, but > GCC takes 4MB of RAM. My stock A1200 has only 2MB. Can > anyone recommend another (preferably free) C compiler > that will work? I don't know of any another free C compilers apart from an "example" C compiler whose source is on Aminet. You could try the "freeware" version of Dice V2 if you don't want to buy Dice V3. If would like the lastest freeware version then please ask. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 23:05:37 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <91426-2>; Thu, 23 Mar 1995 19:12:05 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id RAA25567; Thu, 23 Mar 1995 17:11:04 GMT From: Lars Hecking Message-Id: <199503231712.RAA12848@mostar.nmrc.ucc.ie> Subject: Re: Other C compilers? To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Thu, 23 Mar 1995 17:12:11 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1090 > > Btw, that's not a joke. Setting up a simple compiler isn't *that* > > difficult. The complicated things are the optimizer and getting the > > thing to produce good quality code and usable diagnostics. If you can > > live with bad code, it gets easier :) > > > Don't know if it's feasible, but: > Is it possible to create a stripped down (to the bare bones) version > of gcc that would be able to run on a 2MB machine? > Let's say you remove every optimization and target options, rtl dumping, > etc. in the main compiler pass, use defaults for the specs file (sparing > the parser in the front end) use static linking (sparing another 150k for > ixemul.library), putting intermediate files into SYS:T instead of T: > and so on. > Or is it too much work? Back in dark ages, I had the BRP port (1.38? based) running on my 1.5MB/one floppy A2k. Methinks it's still around on funet ... -- Lars Hecking | National Microelectronics Research Centre lhecking@nmrc.ucc.ie | Cork, Ireland |------------------------------------------- | "Victims ... Aren't we all?" -- Eric Draven From amiga-gcc-port-owner@nic.funet.fi Thu Mar 23 23:05:37 1995 Received: from gate.demon.co.uk ([158.152.1.65]) by nic.funet.fi with SMTP id <91542-4>; Thu, 23 Mar 1995 22:18:17 +0200 Received: from flevel.demon.co.uk by gate.demon.co.uk id af29908; 23 Mar 95 19:13 GMT Received: by flevel.demon.co.uk (V1.16/Amiga) id AA001m5; Thu, 23 Mar 95 16:53:28 GMT Date: Thu, 23 Mar 95 16:53:28 GMT Message-Id: <9503231653.AA001m4@flevel.demon.co.uk> Message-Id: <20656887.27101-dev@flevel.demon.co.uk> In-Reply-To: <9503222302.AA28954@decap2.zdv.uni-tuebingen.de> (from Jochen Wiedmann ) (at Thu, 23 Mar 1995 00:02:47 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: zrawi01@decap2.zdv.uni-tuebingen.de Cc: amiga-gcc-port@nic.funet.fi, hoehle@inf-wiss.uni-konstanz.de Subject: Re: Shared executables for Amiga GNU ports Hi Jochen, > struct ExecBase *SysBase; > > and read this variable from anywhere within your program, because you > can > > a) initialize it from the library startup code and > b) be sure that it never changes > > but you must not use global or static data otherwise. I once wrote a shared library which had a small amount of global data, the solution is to either a) Forbid/Permit Way:- static char name[256]; Forbid(); // forbid strcpy(name,"Hello"); // Alter Data Permit(); You must change the global data quickly using this method. You must not cause a wait because this will break the Forbid. b) Provide a locking mechanism for the data by either 1) The QDS method - generally works ok:- static int lockname; static char name[256]; while (lockname) Delay(0); // Force a task switch lockname++; // Lock the data strcpy(name,"Hello"); // Alter the data lockname--; // Unlock it 2) A fancy method using message ports :-( I used method b1 because it was easy :-) Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Mar 24 11:19:25 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <91440-4>; Fri, 24 Mar 1995 11:06:46 +0200 Received: by colombo.telesys-innov.fr; Fri, 24 Mar 1995 10:05:39 GMT From: Philippe BRAND Message-Id: <199503241005.KAA18835@colombo.telesys-innov.fr> Subject: Re: Other C compilers? To: fnf@amigalib.com (Fred Fish) Date: Fri, 24 Mar 1995 10:05:39 +0000 (GMT) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Fred Fish" at Mar 23, 95 09:18:48 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 401 Fred Fish writes: > One of the things I hope to eventually add to my FreshFish CD is a > port of lcc, which is much smaller and faster than gcc, and apparently > somewhat more ANSI compliant. I just haven't had time yet to look > at doing so. Afaik there's no 680x0 backend for lcc... Do you plan to write one ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB From amiga-gcc-port-owner@nic.funet.fi Fri Mar 24 12:45:10 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91460-1>; Fri, 24 Mar 1995 12:30:10 +0200 Received: from bittern.cms.dmu.ac.uk (bittern.cms.dmu.ac.uk [146.227.102.24]) by macondo.dmu.ac.uk (8.6.11/8.6.11) with ESMTP id KAA29543 for ; Fri, 24 Mar 1995 10:31:38 GMT Received: by bittern.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA131720985; Fri, 24 Mar 1995 10:29:45 GMT Date: Fri, 24 Mar 1995 10:29:44 +0000 (GMT) From: Derek Piper X-Sender: se1dp@bittern.cms.dmu.ac.uk To: GCC Mail List Subject: Byeee ! Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Thanks again to all the people who helped me out with my initial programming exploits, I have been reading my new RKRM manual busily since. Signing off for Easter break. Cheers Del. +---------------+---------------------------+------------------------------+ | Derek Piper | E-Mail: se1dp@dmu.ac.uk | Software Engineering Year 1 | | | | DeMontfort University, Leic | +---------------+---------------------------+------------------------------+ | World Wide Web Home page : HTTP://www.cms.dmu.ac.uk/~se1dp | +--------------------------------------------------------------------------+ | Foolproof operation: All parameters are hard coded. | +--------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Mar 24 12:51:51 1995 Received: from macondo.dmu.ac.uk ([146.227.1.4]) by nic.funet.fi with SMTP id <91461-4>; Fri, 24 Mar 1995 12:31:11 +0200 Received: from bittern.cms.dmu.ac.uk (bittern.cms.dmu.ac.uk [146.227.102.24]) by macondo.dmu.ac.uk (8.6.11/8.6.11) with ESMTP id KAA29565 for ; Fri, 24 Mar 1995 10:32:40 GMT Received: by bittern.cms.dmu.ac.uk (1.37.109.15/3.0.0) id AA131841045; Fri, 24 Mar 1995 10:30:45 GMT Date: Fri, 24 Mar 1995 10:30:44 +0000 (GMT) From: Derek Piper X-Sender: se1dp@bittern.cms.dmu.ac.uk To: GCC Mail List Subject: UNSUBSCRIBE Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From amiga-gcc-port-owner@nic.funet.fi Fri Mar 24 13:18:25 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <91475-2>; Fri, 24 Mar 1995 13:07:20 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Fri, 24 Mar 95 12:05 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Fri, 24 Mar 95 12:01 MET Message-Id: Subject: Re: Other C compilers? To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Fri, 24 Mar 1995 12:00:54 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 577 no 680x0 Backend for LCC ? there where ~10 ppl replying for 'Other C compilers?' if fred chopps his prg in handy parts and everyone get a small piece to translate then he has very fast a handy backend :) walter btw: did i mention i will be virtualy off the next 2 weeks atleast ? -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Mar 24 15:20:30 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <91188-4>; Fri, 24 Mar 1995 15:10:54 +0200 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA02728; Fri, 24 Mar 1995 14:10:30 +0100 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9503241310.AA02728@decap2.zdv.uni-tuebingen.de> Subject: Re: Shared executables for Amiga GNU ports (fwd) To: amiga-gcc-port@nic.funet.fi Date: Fri, 24 Mar 1995 14:10:29 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 937 Forwarded message: >From zrawi01 Fri Mar 24 14:09:51 1995 Subject: Re: Shared executables for Amiga GNU ports To: dev@flevel.demon.co.uk Date: Fri, 24 Mar 1995 14:09:51 +0100 (MET) In-Reply-To: <20656887.27101-dev@flevel.demon.co.uk> from "dev@flevel.demon.co.uk" at Mar 23, 95 04:53:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 568 Hello, Trevor, Christian, > > but you must not use global or static data otherwise. Of course you are right, that one can even write into global memory within shared libraries by using semaphores. (Forbid(), Permit() would not be sufficient in any way: For example, if you use an OS routine, that calls Wait(). Neither do I think that the locking mechanism of incrementing a variable is 100% safe.) However, this is obviously not just "writing" the global variable. Within the context of converting link libraries into shared ones I'd still say: Don't. Jochen From amiga-gcc-port-owner@nic.funet.fi Sun Mar 26 16:10:16 1995 Received: by nic.funet.fi id <1519-3>; Sun, 26 Mar 1995 16:06:19 +0300 Subject: (resent email) Re: Other C compilers ? From: Matti Aarnio To: amiga-gcc-port@nic.funet.fi Date: Sun, 26 Mar 1995 16:06:17 +0200 (EET DST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1375 Message-Id: <95Mar26.160619+0300_eet_dst.1519-3+83@nic.funet.fi> (Due to a symlink error, the amiga-gcc-port was missing for a while.) Subject: Re: Other C compilers? From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 24 Mar 1995 17:20:50 +0100 (MEZ) In-Reply-To: <9503231556.AA06896@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Mar 23, 95 04:56:09 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 735 Message-Id: <95Mar24.172101+0100mesz.209163-2+1912@hphalle0.informatik.tu-muenchen.de> > ixemul.library), putting intermediate files into SYS:T instead of T: > and so on. No!!!!! Never ever put anything into SYS:t. Put it into T:, or maybe even /tmp == tmp: ; if users don't have much memory they can assign it to a more convient place (Work:t on my machine, for example). SYS:t is a very bad idea, since changing that is more difficult on some systems. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue --A4372.796217330=_/hamsterix.funet.fi-- From amiga-gcc-port-owner@nic.funet.fi Mon Mar 27 17:09:26 1995 Received: from cip2.e-technik.uni-erlangen.de ([131.188.139.62]) by nic.funet.fi with SMTP id <4012-4>; Mon, 27 Mar 1995 16:58:37 +0300 Received: (from theurung@localhost) by cip2.e-technik.uni-erlangen.de (8.6.10/8.6.6) id PAA16865 for amiga-gcc-port@lists.funet.fi; Mon, 27 Mar 1995 15:57:39 +0200 From: Thomas Heurung Message-Id: <199503271357.PAA16865@cip2.e-technik.uni-erlangen.de> Subject: bgui, more detailed To: amiga-gcc-port@nic.funet.fi Date: Mon, 27 Mar 95 15:57:34 MSZ Mailer: Elm [revision: 70.85] OK, here is a more detailed description of my problems with bgui: The files bgui_lib.fd, bgui_protos.h and font.c are part of the bgui package, available on every aminet mirror (i think:-) creation of inline/bgui.h: fd2inline >gnu:os-include/inline/bgui.h bguiinclude:fd/bgui_lib.fd bguiinclude:clib/bgui_protos.h got errors in inline/bgui.h: did not find in line 26. did not find in line 27. did not find in line 28. BGUI_Private0 has no prototype. BGUI_Private1 has no Prototype. inserted by hand in inline/bgui.h: #ifndef NO_INLINE_STDARG #define BGUI_DoGadgetMethod(a0, a1, a2, tags...) \ ({ struct TagItem _tags[] = { tags }; BGUI_DoGadgetMethodA ((a0), (a1), (a2), _tags); }) #endif /* not NO_INLINE_STDARG Changed by Thomas Heurung*/ #ifndef NO_INLINE_STDARG #define BGUI_NewObject(a0, tags...) \ ({ struct TagItem _tags[] = { tags }; BGUI_NewObjectA ((a0), _tags); }) #endif /*not NO_INLINE_STDARG Changed by Thomas Heurung*/ #ifndef NO_INLINE_STDARG #define BGUI_Request(a0, a1, tags...) \ ({ struct TagItem _tags[] = { tags }; BGUI_RequestA ((a0), (a1), _tags); }) #endif /* not NO_INLINE_STDARG Changed by thomas Heurung*/ build proto/bgui.h: #ifndef BGUI_PROTO_H #define BGUI_PROTO_H #include #if defined(__OPTIMIZE__) && !defined(__NOINLINES__) #include #endif #include #include #ifndef __NOLIBBASE__ extern struct Library *BGUIBase; #endif #endif compiling bgui:demos/font.c: gcc -noixemul bgui:demos/font.c got errors: t:cc0630881.o: Undefined symbol _BGUI_RequestA referenced from text segment t:cc0630881.o: Undefined symbol _BGUI_NewObject referenced from text segment t:cc0630881.o: Undefined symbol _BGUI_NewObject referenced from text segment t:cc0630881.o: Undefined symbol _BGUI_NewObject referenced from text segment t:cc0630881.o: Undefined symbol _BGUI_NewObject referenced from text segment t:cc0630881.o: Undefined symbol _BGUI_NewObject referenced from text segment t:cc0630881.o: Undefined symbol _BGUI_NewObject referenced from text segment t:cc0630881.o: Undefined symbol _BGUI_NewObject referenced from text segment t:cc0630881.o: Undefined symbol _BGUI_NewObject referenced from text segment t:cc0630881.o: Undefined symbol _BGUI_NewObject referenced from text segment t:cc0630881.o: More undefined symbol _BGUI_NewObject refs follow compiling bgui:demos/font.c: gcc -O3 -noixemul bgui:demos/font.c got errors: font.c:100: unterminated macro call It would be fine if anyone could help me. Ciao thomas From amiga-gcc-port-owner@nic.funet.fi Mon Mar 27 18:38:30 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <3846-4>; Mon, 27 Mar 1995 18:17:06 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id QAA20173 for ; Mon, 27 Mar 1995 16:16:29 +0100 From: Lars Hecking Message-Id: <199503271517.QAA07525@verona.nmrc.ucc.ie> Subject: SAS/C -> Gcc To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Mon, 27 Mar 1995 16:17:48 +0100 (BST) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1018 Hi folks I'm currently porting a package (a link library, basically) from SAS/C to gcc. The only problem remaining are the following vars from a function which relies on the standard SAS startup code: extern struct WBStartup *_WBenchMsg; extern long __base; extern long __stack; To get going, I do the following in my application, which is to be linked against my.a: - define global vars struct WBStartup *_WBenchMsg, long __base, __stack - the first thing in main() is initialising _WBenchMsg from argv (if argc==0), __stack from [(struct Process *)FindTask(NULL)->] pr_StackSize and __base from BADDR(pr_StackBase) (or __base = pr_StackBase - pr_StackSize??) Is there something fundamentally wrong? The proper solution would of course involve an extension to crt0. Cheers, Lars -- Lars Hecking | National Microelectronics Research Centre lhecking@nmrc.ucc.ie | Cork, Ireland |------------------------------------------- | "Victims ... Aren't we all?" -- Eric Draven From amiga-gcc-port-owner@nic.funet.fi Mon Mar 27 18:54:35 1995 Received: from post.demon.co.uk ([158.152.1.72]) by nic.funet.fi with SMTP id <666-4>; Mon, 27 Mar 1995 18:53:10 +0300 Received: from flevel.demon.co.uk by post.demon.co.uk id ao27922; 27 Mar 95 14:32 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA002c2; Mon, 27 Mar 95 11:16:44 GMT Date: Mon, 27 Mar 95 11:16:44 GMT Message-Id: <9503271116.AA002c1@flevel.demon.co.uk> Message-Id: <206a5f98.d6d81-dev@flevel.demon.co.uk> In-Reply-To: <95Mar24.174553+0100mesz.209168-1+1899@hphalle0.informatik.tu-muenchen.de> (from Christian Stieber ) (at Fri, 24 Mar 1995 17:45:49 +0100 (MEZ)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: stieber@informatik.tu-muenchen.de Cc: zrawi01@decap2.zdv.uni-tuebingen.de, amiga-gcc-port@nic.funet.fi, hoehle@inf-wiss.uni-konstanz.de Subject: Re: Shared executables for Amiga GNU ports Hi Christian, > > > b) Provide a locking mechanism for the data by either > > > > 1) The QDS method - generally works ok:- > > > > static int lockname; > > static char name[256]; > > > > while (lockname) Delay(0); // Force a task switch > > lockname++; // Lock the data > > > > strcpy(name,"Hello"); // Alter the data > > > > lockname--; // Unlock it > > Yack. You really use this kind of hack? > You'll have to study the generated code to make sure it works. Too much > work. > Basically, you are trying to implement something that already exists: > Semaphores. Contrary to AmigaOS semaphores, you busy-wait, and your > code breaks if the compiler either doesn't reload "lockname" in the > while-loop (if the inlines are done properly (maybe they are, at some day > in the future)...), or if ++/-- are not atomic operations. > > Use real semaphores. That's exactly the situation they were invented for... Sure, your right - Guess who is lazy :-)) Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Mar 27 19:14:54 1995 Received: by nic.funet.fi id <3910-3>; Mon, 27 Mar 1995 19:02:22 +0300 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: nic.funet.fi up and running again... Message-Id: <95Mar27.190222+0300_eet_dst.3910-3+31@nic.funet.fi> Date: Mon, 27 Mar 1995 19:02:13 +0300 OK, seems the lists are up and running again after the switch from the Sun machine to a brand new DEC 3000/900 + HZ40 RAID5 disk system. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Tue Mar 28 15:13:41 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <3773-2>; Tue, 28 Mar 1995 15:03:37 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Tue, 28 Mar 1995 14:03:18 +0200 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA24209; Tue, 28 Mar 95 14:03:19 +0200 Date: Tue, 28 Mar 95 14:03:19 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503281203.AA24209@inf-wiss.uni-konstanz.de> Received: by mammern.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA05775; Tue, 28 Mar 95 14:03:18 +0200 To: amiga-gcc-port@nic.funet.fi Subject: bug-report and wishes: ixemul.library, tar, PIPE: and VMM. Hi, I'm using ixemul.library from ixem404lib.lha by R.Luebbert. I don't know if this report applies to other version. Everything was run on an A4040/3.1. o ixemul writes too large stdio chunks to the console. I used gzip -c foo.gz or simply cat. Both are ixemul programs (from gcc258). They sent the output to the console in very large amounts, blocking other writing tasks in this screen and not allowing me to temporarily stop the output by hitting any key. The RKM recommends ("256 is a nice round number") no more than 256 bytes being written in one pass to the console. I think that ixemul should discover that it's writing to a terminal and reduce its output buffer size. I think that this is a function that ixemul must implement transparently to the application (we're not going to change the gzip or cat source codes). o I don't know if the following shows a race problem with concurrent uses of ixemul or if it's caused by a bug in PIPE: or where ever: I did a pipe zcat foo.tar.gz | tar tvf - in an original Amiga shell (thus using PIPE:, not IXPIPE:) while GCC was compiling something, I got a ?--------- 0/0 0 Mar 13 15:54 1995 unknown file type ' ' tar: Skipping to next file header... I did a pipe zcat T:foo.tar.gz | tar tvf - in a shell and tar tvf T:bar.tar in another. I started the non-piping command later. As soon as it began to output something, I got the above error message in the shell with the pipe. Sometimes one command in the pipe even seems to get a signal, causing it to display "Interrupt", the shell "*** Abbruch" (German) and PIPE "Broken pipe". Sometimes I also get a tar: Skipping to next file header... *** Abbruch Broken pipe. I don't think that the bug is in zcat as I can replace it with SKsh:bin/cat foo.tar with the same symptoms. I don't think either it's in Andy's pipe command, as I observe the same with Shell1> tar tvBf - run zcat t:ffcall_035.tar.gz >pipe:foo or with Shell2> run sksh:bin/cat t:ffcall_035.tar >pipe:foo Shell3> tar tvf T:ffcal_035.tar Sometimes the error also appears with a non-ixemul program in Shell3 Maybe it's a bug in PIPE: when the CPU is busy under heavy load?? o BTW, why doesn't tar from gcc258 or 263 support the -Z (or -z) option? ixemul seems to provide all it should need. However: tar: cannot fork : Function not implemented o When using VMM (2.1 tested), the stack watcher doesn't work (sends SIGSEGV every so often). I believe that this is because when swapping, VMM switches SP to a stack that is guaranteed to be in psysical memory. Depending on when the SP check is done, an application might see SP out of its bonds (for example, StackMon does this, Xoper not). I don't know if the difference is that StackMon checks the pointer from within an interrupt. It would be nice if the stack overflow check code in ixemul would work even with VMM active. To quote the VMM documentation: To prevent pagefaults while in supervisor mode (task-switching), the stack is replaced by a temporary stack large enough to contain all registers pushed onto the stack during a context switch. When the task is re-launched, the original stack is used again. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de PS: didn't somebody (Heinz Wrobel?) write a "better" PIPE:? I might try that one. From amiga-gcc-port-owner@nic.funet.fi Tue Mar 28 15:13:42 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <92-4>; Tue, 28 Mar 1995 14:53:06 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Tue, 28 Mar 1995 13:52:46 +0200 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA24161; Tue, 28 Mar 95 13:52:44 +0200 Date: Tue, 28 Mar 95 13:52:44 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503281152.AA24161@inf-wiss.uni-konstanz.de> Received: by mammern.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA05766; Tue, 28 Mar 95 13:52:38 +0200 To: amiga-gcc-port@nic.funet.fi Subject: Bug report: UNIX configure scripts and ksh Hi, I've lots of problems trying to get some UNIX configure scripts to work. The problems so far are all due to incompatibilities between the sh distributed with gcc (2.6.3), which appears in fact to be a (pd-)ksh and not the real Bourne Shell. I don't know if the solution of the problem would be a port of a real Bourne shell (??) or if incompatibilities can be considered as bugs. Here is a list: o the shell is not able to start scripts beginning with #! /bin/sh. It doesn't like the space, although this works on UNIX. o `inexistant_command` should not give a return status of 0. This causes this autoconfig/config.guess line to fail: UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown o echo is a built-in alias on print, which appears to eat all things beginning with -, which causes configure's command line parsing to fail echo --config_cache gives a blank line, whereas GCC:bin/echo gives --config-cache, unchanged. unalias echo helps, but I don't feel like editing every UNIX script. o ksh does special treatment of { and } when there's a ] earlier in the line. { and } disappear: # echo "[]\${bar}" []$bar # echo "[\${bar}" [${bar} # echo "]\${bar}" ]$bar # echo "\]\${bar}" \]$bar # echo "]{bar}]" ]bar] # echo "]\{tbar}]" ] bar] I couldn't find a work around this bug. This causes the following line in configure to produce garbage: sed -n "s/^\([a-zA-Z0-9_]*_cv_[a-zA-Z0-9_]*\)=\(.*\)/\1=\${\1='\2'}/p" \ This last bug is not in pdksh from gcc-2.5.8. I don't know who did the port of the pdksh included in Philippe Brand's GCC distribution, but I'd be very grateful if this email was forwared to them. Regards, Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Tue Mar 28 19:56:32 1995 Received: by nic.funet.fi id <3711-3>; Tue, 28 Mar 1995 19:31:32 +0300 From: Leonard Norrgard To: Nathaniel Myhre Cc: amiga-gcc-port@nic.funet.fi Subject: Packing structures Message-Id: <95Mar28.193132+0300_eet_dst.3711-3+62@nic.funet.fi> Date: Tue, 28 Mar 1995 19:31:31 +0300 Nathaniel Myhre wrote: > On Thu, 16 Mar 1995, Fred Fish wrote: > > > > struct test{ > > > unsigned char a : 4; > > > unsigned char b : 4; > > > }; > > > > > > A sizeof(struct test) returns 2 instead of 1 (it only takes up 1 byte!). > > > I'm using gcc 2.6.3 by the way. > > > > K&R 2nd edition, page 213: > > > > "It is advisable to read the language rules for storing > > bit-fields as "implementation-dependent" without qualification. > > Structures with bit-fields may be used ... as a non-portable > > way to describe a storage layout known at the bit level." > > > > I.E., how bitfields are packed is implementation defined. The compiler > > is free to use two bytes if it wants. > > > > -Fred > > > > What threw me was the fact that it was not using the second byte, ie. it > was packing the two bitfields into a single byte. In addition, the gcc > version at school returned a sizeof 1 (it was running on a Sun). I > needed the structure to have a size of 1 because it was a data structure > used on a network simulation for a school project. Sending an extra > unused byte for every packet hurts performance and reduces my mark. I > find it hard to believe that the compiler can legally pad a single byte > structure to 2 bytes without my consent. Can I turn the padding off? I > would assume not. Read the GCC manual, section "Variable Attributes" under "C Extensions". "__attribute__ ((packed))" seems to be what you're looking for: | `packed' | The `packed' attribute specifies that a variable or structure field | should have the smallest possible alignment--one byte for a | variable, and one bit for a field, unless you specify a larger | value with the `aligned' attribute. | | Here is a structure in which the field `x' is packed, so that it | immediately follows `a': | | struct foo | { | char a; | int x[2] __attribute__ ((packed)); | }; In your case, you might want to try placing the attribute after the whole structure rather than on only a structure member. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 19:33:19 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <3253-1>; Wed, 29 Mar 1995 19:30:16 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26566-4>; Wed, 29 Mar 1995 18:29:55 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209168-2>; Wed, 29 Mar 1995 18:29:43 +0100 Subject: Re: Bug report: UNIX configure scripts and ksh From: Christian Stieber To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Wed, 29 Mar 1995 18:29:37 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503281152.AA24161@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Mar 28, 95 01:52:44 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1035 Message-Id: <95Mar29.182943+0100mesz.209168-2+1709@hphalle0.informatik.tu-muenchen.de> > I've lots of problems trying to get some UNIX configure scripts to > work. The problems so far are all due to incompatibilities between the > sh distributed with gcc (2.6.3), which appears in fact to be a > (pd-)ksh and not the real Bourne Shell. Well, the sh that was distributed with gcc-2.3.3 was indeed a port of pdksh. I believe that the sh that comes with gcc-2.6.3 is still that port. It's not easy to port an Unix shell, due to the lack of fork() on the Amiga. That means that a lot of hacking is required to get around the fork() :( And, no, it's impossible to implement fork() on the Amiga. No way. It's a fundamental difference between Unix and AmigaOS. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 21:01:35 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <3743-2>; Wed, 29 Mar 1995 20:45:47 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26577-3>; Wed, 29 Mar 1995 19:45:27 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209174-2>; Wed, 29 Mar 1995 19:45:19 +0100 Subject: Re: bug-report and wishes: ixemul.library, tar, PIPE: and VMM. From: Christian Stieber To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Wed, 29 Mar 1995 19:45:11 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503281203.AA24209@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Mar 28, 95 02:03:19 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1012 Message-Id: <95Mar29.194519+0100mesz.209174-2+1733@hphalle0.informatik.tu-muenchen.de> > o I don't know if the following shows a race problem with concurrent > uses of ixemul or if it's caused by a bug in PIPE: or where ever: AFAIK, PIPE: does indeed have a bug when dealing with blocks that are larger than the internal buffer of PIPE:. Maybe that's the cause the problem; I don't know. > o BTW, why doesn't tar from gcc258 or 263 support the -Z (or -z) option? > ixemul seems to provide all it should need. However: > tar: cannot fork : Function not implemented gtar is using fork() to run the compressor/decompressor. It is not using pipe(). Therefore it would require a rewrite of the appropiate part of gtar. Any volunteers? Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 21:12:17 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <3969-3>; Wed, 29 Mar 1995 21:06:11 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0ru2XW-0004nZC; Wed, 29 Mar 95 11:32 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: bug-report and wishes: ixemul.library, tar, PIPE: and VMM. To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Wed, 29 Mar 1995 11:32:21 -0700 (MST) Cc: hoehle@inf-wiss.uni-konstanz.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <95Mar29.194519+0100mesz.209174-2+1733@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Mar 29, 95 07:45:11 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 288 > gtar is using fork() to run the compressor/decompressor. It is not > using pipe(). Therefore it would require a rewrite of the appropiate > part of gtar. > Any volunteers? I fixed this problem a long time ago in my distributions with a simple "-Dfork=vfork" in the compilation. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 21:12:58 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <3700-2>; Wed, 29 Mar 1995 19:06:37 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26576-2>; Wed, 29 Mar 1995 18:06:10 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209171-1>; Wed, 29 Mar 1995 18:06:04 +0100 Subject: Re: error using -fbasere From: Christian Stieber To: y0000135@ws.rz.tu-bs.de (Sven Heithecker) Date: Wed, 29 Mar 1995 18:05:57 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Mar29.184130+0300_eet_dst.1008-4+17@nic.funet.fi> from "Sven Heithecker" at Mar 29, 95 05:40:01 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 799 Message-Id: <95Mar29.180604+0100mesz.209171-1+1635@hphalle0.informatik.tu-muenchen.de> > When I compile any prg (even a plain helloword) with the gcc-2-6-3-compiler with > the -fbaserel option, i get a brunch of internal error messages. > > Is this a compiler bug or did i do something wrong ? Hm.. we should make a FAQ :) -fbaserel support is broken with all gcc Versions after 2.3.3, so this is indeed a compiler bug. It can be used, but it's not that simple. So it's better to hope that somebody finds the bug... Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 21:13:45 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <3262-2>; Wed, 29 Mar 1995 21:11:13 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26566-2>; Wed, 29 Mar 1995 20:10:46 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209168-1>; Wed, 29 Mar 1995 20:10:41 +0100 Subject: Re: bug-report and wishes: ixemul.library, tar, PIPE: and VMM. From: Christian Stieber To: fnf@amigalib.com (Fred Fish) Date: Wed, 29 Mar 1995 20:10:40 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Fred Fish" at Mar 29, 95 11:32:21 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 779 Message-Id: <95Mar29.201041+0100mesz.209168-1+1671@hphalle0.informatik.tu-muenchen.de> > > > gtar is using fork() to run the compressor/decompressor. It is not > > using pipe(). Therefore it would require a rewrite of the appropiate > > part of gtar. > > Any volunteers? > > I fixed this problem a long time ago in my distributions with a simple > "-Dfork=vfork" in the compilation. Oops.. I didn't know that it was *that* simple. Usually getting rid of fork() is a little more difficult, AFAIK :( Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 21:14:21 1995 Received: from DBSTU1.RZ.TU-BS.DE ([134.169.1.1]) by nic.funet.fi with SMTP id <1008-4>; Wed, 29 Mar 1995 18:41:30 +0300 Received: from rzserv0.rz.tu-bs.de by DBSTU1.RZ.TU-BS.DE (IBM VM SMTP V2R2) with TCP; Wed, 29 Mar 95 17:40:15 MEZ Received: by rzserv0.rz.tu-bs.de (1.37.109.4/15.6) id AA24954; Wed, 29 Mar 95 17:40:03 +0200 From: Sven Heithecker Subject: error using -fbasere To: amiga-gcc-port@nic.funet.fi (Gcc-Mailing-List) Date: Wed, 29 Mar 1995 17:40:01 +0100 (MESZ) X-Mailer: ELM [version 2.4 PL11] Content-Type: text Content-Length: 315 Message-Id: <95Mar29.184130+0300_eet_dst.1008-4+17@nic.funet.fi> Hello ! When I compile any prg (even a plain helloword) with the gcc-2-6-3-compiler with the -fbaserel option, i get a brunch of internal error messages. Is this a compiler bug or did i do something wrong ? ____ |_||_ Ceterum Censeo MEGAHARD Esse Delendam | | _| HTS Sven Heithecker s.heithecker@tu-bs.de From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 21:31:46 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <3666-3>; Wed, 29 Mar 1995 21:15:14 +0300 Received: from loriot.u-strasbg.fr (loriot [130.79.80.18]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id UAA02342 for ; Wed, 29 Mar 1995 20:14:06 +0200 From: fernande@loriot.u-strasbg.fr Message-Id: <199503291814.UAA02342@isis.u-strasbg.fr> Date: Wed, 29 Mar 95 20:13 ETE To: fnf@amigalib.com (Fred Fish), Christian Stieber Cc: amiga-gcc-port@nic.funet.fi Subject: Re: bug-report and wishes: ixemul.library, tar, PIPE: and VMM. Content-Type: text Content-Length: 12 subscribe?? From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 21:31:58 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <3269-4>; Wed, 29 Mar 1995 19:25:46 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0ru10h-0004nYC; Wed, 29 Mar 95 09:54 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Bug report: UNIX configure scripts and ksh To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Wed, 29 Mar 1995 09:54:22 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9503281152.AA24161@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Mar 28, 95 01:52:44 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 501 > I've lots of problems trying to get some UNIX configure scripts to > work. Initially I had some of the same sorts of problems, so I ported autoconf and made some amiga specific changes to work around the problems I found. Now I simply regenerate the configure scripts using this autoconf from my FreshFish CD's, and generally things just work fine after that, using the shell and other tools from my CD. I'd recommend that approach, rather than hacking each configure script individually. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 21:32:09 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <3217-2>; Wed, 29 Mar 1995 19:49:59 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 29 Mar 95 18:47 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 29 Mar 95 13:58 MET DST Message-Id: Subject: ney-includes To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 29 Mar 1995 13:58:13 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 440 Where are the tcpip-includes for gcc on nic.funet.fi (or else) ? i have a *very* slow connection and would like to avoid to be exspelt be the ftpd :( walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 21:35:58 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <3584-3>; Wed, 29 Mar 1995 20:59:54 +0300 Received: from loriot.u-strasbg.fr (loriot [130.79.80.18]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id TAA02214 for ; Wed, 29 Mar 1995 19:58:59 +0200 From: fernande@loriot.u-strasbg.fr Message-Id: <199503291758.TAA02214@isis.u-strasbg.fr> Date: Wed, 29 Mar 95 19:58 ETE To: Walter Harms , amiga-gcc-port@nic.funet.fi (amiga gcc-list) Subject: Re: ney-includes Content-Type: text Content-Length: 20 HOW TO UNSUBSCRIBE? From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 21:49:27 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <3497-2>; Wed, 29 Mar 1995 17:22:57 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 29 Mar 1995 16:22:29 +0200 Received: from manzell.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA28398; Wed, 29 Mar 95 16:22:30 +0200 Date: Wed, 29 Mar 95 16:22:30 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503291422.AA28398@inf-wiss.uni-konstanz.de> Received: by manzell.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA01003; Wed, 29 Mar 95 16:22:29 +0200 To: Lars Hecking Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Bug reports ... In-Reply-To: <199503291148.MAA17880@mostar.nmrc.ucc.ie> References: <199503291148.MAA17880@mostar.nmrc.ucc.ie> Hi, BTW, did you respond only to me? I get nothing from the list just now, even not what I write. But your response shows me that something went through. Lars Hecking writes: > have some problems ... for one, I cannot even compile amiga-pdksh-4.9 > due to the nonworking -resident in gcc-2.6.[34] :( > The original port of pdksh was done by Markus Wild. Philippe probably > recompiles it (or not?) for every new gcc release. How did Philippe get it to work without -resident then? > Highly interesting. I'll go and try this one, if I can lay my hands on it. I can send it to you, if you wish. > Which stack watcher? I use VMM3.0 w/o probs. The stack watcher built into ixemul. See ixconfig. (Beware of using the wrong ixconfig/ixemul pair, i.e. don't use ixconfig from the gcc263 archive with the ixemul.library there (v40.4 by R.Luebbert)). Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 21:54:25 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <3777-3>; Wed, 29 Mar 1995 21:03:40 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0ru2WE-0004nYC; Wed, 29 Mar 95 11:31 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Bug reports ... To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Wed, 29 Mar 1995 11:31:02 -0700 (MST) Cc: lhecking@nmrc.ucc.ie, amiga-gcc-port@nic.funet.fi In-Reply-To: <9503291422.AA28398@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Mar 29, 95 04:22:30 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 536 > > have some problems ... for one, I cannot even compile amiga-pdksh-4.9 > > due to the nonworking -resident in gcc-2.6.[34] :( > > > The original port of pdksh was done by Markus Wild. Philippe probably > > recompiles it (or not?) for every new gcc release. > > How did Philippe get it to work without -resident then? It has to be compiled with gcc 2.3.3, which is the prime reason why I still keep that version around on my CD. Once -resident is working in the latest version of gcc, I'll nuke the 2.3.3 version. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Mar 29 22:20:16 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <140-2>; Wed, 29 Mar 1995 22:18:59 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 29 Mar 1995 21:17:23 +0200 Received: from manzell.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA29384; Wed, 29 Mar 95 21:17:21 +0200 Date: Wed, 29 Mar 95 21:17:21 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503291917.AA29384@inf-wiss.uni-konstanz.de> Received: by manzell.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA01106; Wed, 29 Mar 95 21:17:18 +0200 To: Lars Hecking Cc: amiga-gcc-port@nic.funet.fi Subject: SAS/C -> Gcc In-Reply-To: <199503271517.QAA07525@verona.nmrc.ucc.ie> References: <199503271517.QAA07525@verona.nmrc.ucc.ie> Lars Hecking writes: > I'm currently porting a package (a link library, basically) from SAS/C > to gcc. > extern struct WBStartup *_WBenchMsg; > extern long __base; > extern long __stack; Isn't that used to request a specific stack size set when linking with a special startup? Is this variable set or referenced? > - the first thing in main() is initialising _WBenchMsg from argv (if argc==0), Seems correct. Check the startup code you're using if it does fill argv in this case. > __stack from [(struct Process *)FindTask(NULL)->] pr_StackSize and > __base from BADDR(pr_StackBase) (or __base = pr_StackBase - pr_StackSize??) If setting __stack is a request to obtain a given stack size, then this is certainly wrong. BTW, pr_StackSize is not defined to be the stack size the current program got. See a recent thread in this list on that subject. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Mar 30 08:24:06 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <154-2>; Wed, 29 Mar 1995 23:41:07 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id VAA12975 for ; Wed, 29 Mar 1995 21:40:23 +0100 From: Lars Hecking Message-Id: <199503292041.VAA18586@mostar.nmrc.ucc.ie> Subject: SAS/C -> Gcc To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Wed, 29 Mar 1995 21:41:34 +0100 (BST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1582 > Lars Hecking writes: > > I'm currently porting a package (a link library, basically) from SAS/C > > to gcc. > > > extern struct WBStartup *_WBenchMsg; > > extern long __base; > > extern long __stack; > Isn't that used to request a specific stack size set when linking with > a special startup? Is this variable set or referenced? Right. The SAS startup code checks the cli_DefaultStack against __stack and allocates a new stack if __stack is larger (Jim, I checked c.a; it's not pr_StackSize ;) > > - the first thing in main() is initialising _WBenchMsg from argv (i= > f argc=0), > Seems correct. Check the startup code you're using if it does fill > argv in this case. It does. See library/ix_startup.c and library/_main.c. *wb_msg should be made global for compatibility. Rafael? > > __stack from [(struct Process *)FindTask(NULL)->] pr_StackSize an= > d > > __base from BADDR(pr_StackBase) (or __base =3D pr_StackBase - pr_= > StackSize??) > If setting __stack is a request to obtain a given stack size, then this is > certainly wrong. I admit to this .. > BTW, pr_StackSize is not defined to be the stack size the current program > got. See a recent thread in this list on that subject. Found it ;-) Seems to be more reliable using SPUpper, SPLower and pr_ReturnAddr. Thanks to all who responded, Lars -- Lars Hecking | I woke the same as any other day lhecking@nmrc.ucc.ie | Except a voice was in my head NMRC | It said seize the day, pull the trigger, Cork, Ireland | Drop the blade | And watch the rolling heads From amiga-gcc-port-owner@nic.funet.fi Thu Mar 30 11:29:17 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <127-1>; Thu, 30 Mar 1995 11:27:37 +0300 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA24215; Thu, 30 Mar 95 10:22:30 +0300 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA03591; Thu, 30 Mar 95 10:29:24 +0300 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9503300729.AA03591@hpcl.cti.gr> Subject: Re: SAS/C -> Gcc To: amiga-gcc-port@lists.funet.fi (gcc) Date: Thu, 30 Mar 1995 10:29:22 +0300 (EET DST) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <9503291917.AA29384@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Mar 29, 95 09:17:21 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 289 > got. See a recent thread in this list on that subject. It looks like the thread ended without ever resolving what is the best order of checking tc_SP* and pr_ReturnAddr to obtain the stack bounds. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Thu Mar 30 12:09:43 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <120-3>; Thu, 30 Mar 1995 12:08:10 +0300 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA24110; Thu, 30 Mar 95 10:17:44 +0300 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA03543; Thu, 30 Mar 95 10:24:38 +0300 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9503300724.AA03543@hpcl.cti.gr> Subject: Re: bug-report and wishes: ixemul.library, tar, PIPE: and VMM. To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Thu, 30 Mar 1995 10:24:35 +0300 (EET DST) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <95Mar29.194519+0100mesz.209174-2+1733@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Mar 29, 95 07:45:11 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 427 > gtar is using fork() to run the compressor/decompressor. It is not > using pipe(). Therefore it would require a rewrite of the appropiate > part of gtar. In the version of tar that I compiled myself, -Z/-z appear to work. I'm sure that the only tampering with the source that I may have done would be to compile tar with -Dfork=vfork. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Thu Mar 30 18:37:04 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <145-4>; Thu, 30 Mar 1995 18:32:05 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26530-2>; Thu, 30 Mar 1995 17:30:53 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209168-1>; Thu, 30 Mar 1995 17:30:46 +0100 Subject: Re: bgui, more detailed From: Christian Stieber To: theurung@cip.e-technik.uni-erlangen.de (Thomas Heurung) Date: Thu, 30 Mar 1995 17:30:31 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199503271357.PAA16865@cip2.e-technik.uni-erlangen.de> from "Thomas Heurung" at Mar 27, 95 03:57:34 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2087 Message-Id: <95Mar30.173046+0100mesz.209168-1+2201@hphalle0.informatik.tu-muenchen.de> > compiling bgui:demos/font.c: > gcc -noixemul bgui:demos/font.c > > got errors: > t:cc0630881.o: Undefined symbol _BGUI_RequestA referenced from text segment > ... This is because you didn't optimize. Inline functions only get inlined when -O is used. Since you didn't do that, it tries to use stub functions which aren't there. Solution: make some stub functions. > compiling bgui:demos/font.c: > gcc -O3 -noixemul bgui:demos/font.c > > got errors: > font.c:100: unterminated macro call This is because the inlined varargs aren't useful at all. Do #define NO_INLINE_STDARG (or whatever it is called), and create varargs stubs like this: Prototype: BOOL SomeFunction(int, char *, ...); and BOOL SomeFunctionA(int, char *, APTR); Stub function: #define NO_INLINE_STDARG #include BOOL SomeFunction(int A, char *B, ...) { return SomeFunctionA(A,B,(&B)+1); } That isn't really ANSI-C, but it works on all Amiga compilers I know of. Create a .c file for every function, compile, ar and link it to the program. Make sure the optimizer is on, else SomeFunctionA won't be inlined. How to create stubs for non-varargs functions: In order to be able to compiler without -O, you want to create stubs for the inline functions as well: #define NO_INLINE_STDARG #define SomeFunctionA InlinedSomeFunctionA #include #undef SomeFunctionA BOOL SomeFunctionA(int A, char *B, APTR C) { return InlinedSomeFunctionA(A,B,C); } Again, create such a file for every function and put the *.o files into the archive mentioned above. Christian (I'll leave tomorrow, so don't expect any answers from me in case you have more questions. But there are more ppl on the list). -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Thu Mar 30 19:00:11 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <105-3>; Thu, 30 Mar 1995 18:56:30 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 30 Mar 95 17:55 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 30 Mar 95 17:30 MET DST Message-Id: Subject: net-includes To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 30 Mar 1995 17:30:47 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 379 Where can i find the tcpip-includes (and libs) for gcc. dont hide , i know they exist ! walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Thu Mar 30 19:06:38 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <214-4>; Thu, 30 Mar 1995 19:03:53 +0300 Received: by RT66.com (4.1/SMI-4.1) id AA01065; Thu, 30 Mar 95 09:05:06 MST Date: Thu, 30 Mar 1995 09:05:05 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: Joerg-Cyril Hoehle Cc: amiga-gcc-port@nic.funet.fi Subject: Re: bug-report and wishes: ixemul.library, tar, PIPE: and VMM. In-Reply-To: <9503281203.AA24209@inf-wiss.uni-konstanz.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 28 Mar 1995, Joerg-Cyril Hoehle wrote: > o I don't know if the following shows a race problem with concurrent > uses of ixemul or if it's caused by a bug in PIPE: or where ever: > > I did a pipe zcat foo.tar.gz | tar tvf - in an original Amiga shell (thus > using PIPE:, not IXPIPE:) while GCC was compiling something, I got a > ?--------- 0/0 0 Mar 13 15:54 1995 unknown file type ' ' > tar: Skipping to next file header... > > I did a pipe zcat T:foo.tar.gz | tar tvf - in a shell and tar tvf T:bar.tar > in another. I started the non-piping command later. As soon as it began to > output something, I got the above error message in the shell with the pipe. > > Sometimes one command in the pipe even seems to get a signal, causing it to > display "Interrupt", the shell "*** Abbruch" (German) and PIPE "Broken > pipe". > > Sometimes I also get a > tar: Skipping to next file header... > *** Abbruch > Broken pipe. > > I don't think that the bug is in zcat as I can replace it with SKsh:bin/cat > foo.tar with the same symptoms. I don't think either it's in Andy's pipe > command, as I observe the same with > Shell1> tar tvBf - Shell2> run zcat t:ffcall_035.tar.gz >pipe:foo or with > Shell2> run sksh:bin/cat t:ffcall_035.tar >pipe:foo > Shell3> tar tvf T:ffcal_035.tar > Sometimes the error also appears with a non-ixemul program in Shell3 > Maybe it's a bug in PIPE: when the CPU is busy under heavy load?? > > o BTW, why doesn't tar from gcc258 or 263 support the -Z (or -z) option? > ixemul seems to provide all it should need. However: > tar: cannot fork : Function not implemented I obtained tar 1.11.2 from somwhere on the net (Fred perhaps?) that had been modified for compiling on the Amiga. I made a simple (as I remember it) change to the Makefile to include the z option. I basically defined fork as vfork. I can upload it to wherever would be useful if anyone wants it. I cannot vouch that it is bug free as I ony use it for simple backups. I have run into a similar problem with pipes. When I use the 'z' option in tar, somtimes I get a 'gzip: broken pipe' message as well. I assumed it was a problem with the disk I was using to backup to (an old Bernoulli drive). But after reading your message, it may be a problem with the Amiga pipe mechanism. Paul Ney From amiga-gcc-port-owner@nic.funet.fi Thu Mar 30 19:18:16 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <387-4>; Thu, 30 Mar 1995 19:14:35 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 30 Mar 1995 18:14:26 +0200 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02241; Thu, 30 Mar 95 18:14:27 +0200 Date: Thu, 30 Mar 95 18:14:27 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503301614.AA02241@inf-wiss.uni-konstanz.de> Received: by mammern.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA09742; Thu, 30 Mar 95 18:14:25 +0200 To: amiga-gcc-port@nic.funet.fi Subject: tar and -z or -Z Hi, thanks for all the tips about tar. It would be nice if someone among all the persons who ported a working tar would upload a recent ixemul- compiled with -Dfork=vfork version to Aminet, which would also be included in the next gcc distribution. Another thing about tar and pipes: while playing with PIPE: and FIFO:, I recognized that I needed the -i or -B option for the tar and pipe pair to work correctly. This depends on the implementation of the pipe (i.e. whether Read() always returns the number of characters asked for, whether multiple readers or writers are allowed) and of the tar program (i.e. if it does subsequent reads after an EOF). Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Mar 30 19:29:36 1995 Received: from RT66.com ([198.59.162.1]) by nic.funet.fi with SMTP id <672-3>; Thu, 30 Mar 1995 19:25:46 +0300 Received: by RT66.com (4.1/SMI-4.1) id AA02480; Thu, 30 Mar 95 09:27:05 MST Date: Thu, 30 Mar 1995 09:27:04 -0700 (MST) From: Paul Ney X-Sender: pney@mack To: Joerg-Cyril Hoehle Cc: Lars Hecking , amiga-gcc-port@nic.funet.fi Subject: Re: Bug reports ... In-Reply-To: <9503291422.AA28398@inf-wiss.uni-konstanz.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 29 Mar 1995, Joerg-Cyril Hoehle wrote: > The stack watcher built into ixemul. See ixconfig. (Beware of using > the wrong ixconfig/ixemul pair, i.e. don't use ixconfig from the > gcc263 archive with the ixemul.library there (v40.4 by R.Luebbert)). Which ixconfig should we use for ixemul v40.4? Paul Ney From amiga-gcc-port-owner@nic.funet.fi Thu Mar 30 19:44:12 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <148-1>; Thu, 30 Mar 1995 19:39:20 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 30 Mar 1995 18:39:03 +0200 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02310; Thu, 30 Mar 95 18:39:04 +0200 Date: Thu, 30 Mar 95 18:39:04 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9503301639.AA02310@inf-wiss.uni-konstanz.de> Received: by mammern.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA09784; Thu, 30 Mar 95 18:39:02 +0200 To: pney@RT66.com, amiga-gcc-port@nic.funet.fi Subject: Re: which ixconfig? > Which ixconfig should we use for ixemul v40.4? If you're using R.Luebbert ixem404lib.lha, use ixconfig from there. It's actually called bin in that archive :-( [generic] 2925 5396 54.2% -lh5- b464 Sep 3 1994 ixem/bin The ixemul.library from the gcc263 archive is R.Luebbert's 40.4. If you're using another one: Fred Fish's: I don't know whether he removed the ArpBase field in the include/library/ixemul.h file. R.Luebbert removed it between his 40.2 and 40.4, which was a big mistake IMHO (as this mail and others show). So I don't know which ixconfig is good for him. Leonard's: He told me that he had never removed this field, so get any old ixconfig you'll find. The one from the gcc263 archive will do. Confusing, isnt'it? Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Mar 30 21:03:01 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <149-2>; Thu, 30 Mar 1995 20:57:01 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id SAA20258; Thu, 30 Mar 1995 18:55:47 +0100 From: Lars Hecking Message-Id: <199503301756.SAA19833@mostar.nmrc.ucc.ie> Subject: Preprocessor bug in 2.6.3/4 To: fnf@amigalib.com (Fred Fish), phb@colombo.telesys-innov.fr (Philippe Brand) Date: Thu, 30 Mar 1995 18:56:46 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 1443 Hi Fred and Philippe I just pulled gzip-1.2.4.tar.gz from the net to test my continously varying gcc setup, and stumbled into a serious cpp bug. The gzip archive includes match.S with optimized assembly routines for i386 and mc68000/mc68000. This file is ran through the preprocessor $(CPP) -Dmc68020 match.S >_match.s to get a "pure" assembly file, and then through gcc/as. Tons of preprocessor definitions are expanded utterly _wrong_. Example: #define imm(data) \#data #define predec(An) An@- #define pushreg 16184 /* d2-d7/a2-a4 */ moveml imm(pushreg),predec(Stack_Pointer) expands to moveml \"pushreg" , sp @- wheras the correct version is moveml #16184 , sp @- I have checked the following gcc versions: - Amiga: gcc2.3.3 (M. Wild): correct gcc2.3.3 (FreshFish): correct gcc263 (Aminet): wrong gcc263-020 (Aminet): wrong gcc263 (FreshFish): wrong gcc264 (snapshot 950318): wrong (yes, they're all installed ;-) [The next ones were run via gcc -E -undef -Dmc68020] - DEC (mips-dec-ultrix) gcc256: correct - Sun (sparc-sun-sunos4.1.3) gcc256: correct gcc263: wrong This looks like a machine-independant problem of gcc-2.6.0+. Thanks, Lars -- Lars Hecking | I woke the same as any other day lhecking@nmrc.ucc.ie | Except a voice was in my head NMRC | It said seize the day, pull the trigger, Cork, Ireland | Drop the blade | And watch the rolling heads From amiga-gcc-port-owner@nic.funet.fi Thu Mar 30 21:22:36 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <672-3>; Thu, 30 Mar 1995 21:16:42 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0ruPEV-0004nYC; Thu, 30 Mar 95 11:46 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Preprocessor bug in 2.6.3/4 To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 30 Mar 1995 11:46:14 -0700 (MST) Cc: fnf@amigalib.com, phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi In-Reply-To: <199503301756.SAA19833@mostar.nmrc.ucc.ie> from "Lars Hecking" at Mar 30, 95 06:56:46 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 360 > Tons of preprocessor definitions are expanded utterly _wrong_. > ... > This looks like a machine-independant problem of gcc-2.6.0+. I think this is a feature, though you will have to dig through the docs to figure out why. The "-traditional" arg will cause the expansions to be done differently, but still not in a way that is acceptable to gas. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Mar 31 00:18:26 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <995-2>; Fri, 31 Mar 1995 00:13:59 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id WAA21378; Thu, 30 Mar 1995 22:13:29 +0100 From: Lars Hecking Message-Id: <199503302114.WAA19981@mostar.nmrc.ucc.ie> Subject: Re: your mail To: fnf@amigalib.com (Fred Fish) Date: Thu, 30 Mar 1995 22:14:41 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <01HOR8WWU9JM00G7CJ@mailgate.ucd.ie> from "AMIGA-GCC-PORT-OWNER@NIC.FUNET.FI" at Mar 30, 95 06:22:42 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 693 > > Tons of preprocessor definitions are expanded utterly _wrong_. > > ... > > This looks like a machine-independant problem of gcc-2.6.0+. > > I think this is a feature, though you will have to dig through the > docs to figure out why. The "-traditional" arg will cause the > expansions to be done differently, but still not in a way that > is acceptable to gas. An unfortunate encounter of "stringification" and nested macros :( -- Lars Hecking | National Microelectronics Research Centre lhecking@nmrc.ucc.ie | Cork, Ireland |------------------------------------------- | "Victims ... Aren't we all?" -- Eric Draven From amiga-gcc-port-owner@nic.funet.fi Fri Mar 31 09:06:07 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <3198-4>; Fri, 31 Mar 1995 08:58:24 +0300 Received: by theseas.ntua.gr with UUCP; Fri, 31 Mar 1995 08:59:28 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06u4@kriton.UUCP>; Thu, 30 Mar 95 23:42:58 EET Date: Thu, 30 Mar 95 23:42:58 EET Message-Id: <9503302142.06u4@kriton.UUCP> In-Reply-To: <199503301756.SAA19833@mostar.nmrc.ucc.ie> (from Lars Hecking ) (at Thu, 30 Mar 1995 18:56:46 +0100 (BST)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1065 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: lhecking@nmrc.ucc.ie Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Preprocessor bug in 2.6.3/4 Hi Lars (Lars Hecking), in <199503301756.SAA19833@mostar.nmrc.ucc.ie> on Mar 30 you wrote: I just compiled gzip today, and ran against the same problem. The problem is caused by the imm() macro, which is interpreted according to ANSI rules, where # is the stringification operator. To compile this file using gcc, do the following: 1. Look at match.S, and find the definition of the imm() macro. There are three such definitions, one using the & prefix, which is irrelevant, one using the \# prefix, and one using the # prefix. Check what symbols you need to define or undefine to get the "#" version. (I edited the file, trying to find out what was going on, so I don't remember what is appropriate.) 2. Edit the Makefile, and add -traditional and the appropriate -D or -U options (depending on what you determined above) to CPPFLAGS. I hope this helps, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "The best way to fight is not to be there." ----- From amiga-gcc-port-owner@nic.funet.fi Fri Mar 31 22:19:23 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <108-4>; Fri, 31 Mar 1995 22:15:08 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id UAA28365 for ; Fri, 31 Mar 1995 20:14:31 +0100 From: Lars Hecking Message-Id: <199503311915.UAA13985@verona.nmrc.ucc.ie> Subject: tar-1.11.2 diffs To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Fri, 31 Mar 1995 20:15:57 +0100 (BST) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 4723 Found it on my HD ;-) Here you go. Patch, configure and -Dfork=vfork. These diffs were from Markus Wild initially, and also include some new stuff to deal with amiga protection flags. Sorry if this post gets messed up, but I cannot seem to do anything about it. This is the last column-------------------------------------v begin 640 t.lha M'ELM;&@U+74+ #)( D[;U&@ "'1AANYO#7>$N[ :QQQMMU]YX*K#F:,)6XZJ]9=>LQMPI[6Q4#Y'WH M73/(X&=BD'7][?X+P4QW' \_ 8-Q):[9!IH)##_]@%?\W!P( (1Z^V!T7Y!U M5^$P!>28SGX<@ED!QQTTCD;^26(Y(]O+=NW<6MW%\_+MNX/+ MUU='+ZA<(2-]!L$+>,P5-P&-LM_01)SA_(X*@B'I/^@#F(4%J;F03!?'@;I' MG&;2%@HM45=M(0^\%)S(KHV?"G]CM4_ M0ZB^ZCN+[WGDI^IWKV+MI8?R[G/%>RO<67LL6)SRR-YH8 I<>#[=W?Y5@PFE M-#T!2H>+BX>3CO>*@JL%"K06"NJC@]"RWLX.4>R1OPRO$Q*)?01;S"P!S11\ M_,:$6"&W55\\-!7.NX=:CZMXF2<@0F,[(<-V26<$F,S\HBM)X<(*2JNLX;*X M]@V5[>DX6;HX5B?M0N5M/9">7U.:,S?/M[$_/6MP8X(+*;M<&39.IP9.(\N+ M*=P8P+XD85NTG@#U_HF,^]22E MGG2N5.FLE*+LS4)8B+[.9N.$SN"*%P4@U3IC"VII4/*;'%T$X5Z(H,HZ))D, MX#T<6,"T60G$@NI ;CV/RH-!H MQE5B0GN+!B,V*;E7P(_ZQ\O;[>5TLVCX&#(:/'(J?$U$4G9&RTE8%ZB['9LC MINC&W^$4:NAWM[333I.5]U;VE2.,=<#\Q;#K%L)Q;6HT;IEC;,)^$1:3C@6YVE=,!;%R&E$S(@ MRXVY.<,S\$"-7@,]*=;@ESWWGQ)8ZF;8HDFK''NZ'H.[YI;+V#G,;(=]9ZO4 M%+$,3E+6SJ[TN3!O\GFW_&'J O'R3^/VE50_+=U4N /7GBE.K;/;D)A!$(6 M2<[^1R/*Z%0',L<8]WGB^$0)9/9CL0_B:@?.+Z[\H8\HT#(>/+%^TXW".@$D MC#A,CL*)Y$9%\HHFQ!\L#M ^V*?J1RGZ\OIAQR;P*)YASGJW_@]M6PM_^.V= MV=Z]CW-07H<;8P$^5J:@SY"G5 OV;HM1/>U!SB^F!@&"4N?UF;6;* MS.AJ"/M83*&H90^%^4[#"9^GO<&[Y.0)V58\O?>G>:-8.I@_O7^'!Q[O+]-_ M=X;VB7&TXRE).;3ERT[PMN<\D#6*5+-MN [:^1&J]9-WO+O\7C3I3!:5P"\ MK*#M^^M1)I\@#=.2!]Q^6#T(TO6@1 _)W/1T8^I )&+I>@KCWY: M_1Z#H%"[\8KEWX,3 <=_-Y]8N+6+.B%91@6YT TPD@Q%90\:(%WOA*^P6^; M<1"Y_M"CZ83G1O5)$*'_>%$F(B5_'U& N+ 3VPQAPA,*21,/8,,.5W+CR:W4 M%ID:-:SIHUPO@;0P2!+(A:<1I3!*O4U-1!025%T,RR9E!-+YI9G>S0NIH*G0BX_+=>Z@ M\7*XT&?1/$W+K*UU>WGCL*O1+F\2*_I#5C_3FR@@D#TR%?9P^ MGO'ACS=(EK0^C$,ZU'F,[0]P/TBZ=$'/E=(_$#I"2 MAW*1W,PJ-6*]?;/MX;(^J?+P>#<'ET/3/!7;-),$N6<,$'_(:!H.PU*AZ!AT MC+II>-I-XL@Y5E0/$/F$4,O3GT:M$]"YG!IZ%*G_1XZNJZFFAD:V>&2*/N9X M(Q]3/!&*H55=XA6;!@>%1=:M"[!%EVQK9X)%.IW:NP-5>[V>%FN4A!GB31]K ML\A>EP'].[]E[!P_7X]_R_"B'H[DY>7]V G8_\/XEW53H9Z'X': ;0LI=J67 MT4-OVT+%-7>A=*"^1']573#(%ND]H00$G>YB'R[><#XVKF\^(I]HISGD97QI%0DT2DA8YSV*!]$@,27UTPY0&EG19):V*AKK0&<(%9PW2D'T< MWZX1.VMIE0QI-]BS.\2SZD=(";>>M!WX;QIT.>&UH;'NI\5DJ?"@C#U(^A(, M595BS0FC*G:K!\SV!V+ YB'"&@P>M9(-DC-(:/H$*C=T!4@EH-'2/1IT!VRD M0A-F.#KG"J-^C/I3;PLU:KHS4_7G(IQ]<:<=:SMV?^E#V;>D6V$E=^&4J4 V>C>8QDEQ($BO'6M<5I= M76M7=%H6MKLK6V-"8X#Y"E.HHFG+HV]%7B&6:35V!K]RR;>DK-U3#V1[VFP; MB$C8-_../Q'N8J4.6O/"6'5JME&^U9F#"B);=,^RVXX5R6(!D$XP*.4)Q,1, MI'^98=#YAIV?/5*G5A?4/Z'IW!/5;_3978#F]$I71$2H;RP2A?W/E=5.97CO M;WAX.+Q?7OW_(KI?DZS##VF&'^S#;(P]#-E1%W)*[,-NNOEM8S7IP!"2!)55 MD[Y_S@"=J(\-UF$3.>]7PELPI@NU7LL$"-PD4C,C;&RO'8%G'L[I_$E0K%9C MP\GC/>1Y%2+#O@R,6N!_Q=L&1BZZS4R5E4^,&1BU7Y)B>=. ]*?P/0-X=;,72*BBXIH83[>J"E - end -- Lars Hecking | I woke the same as any other day lhecking@nmrc.ucc.ie | Except a voice was in my head NMRC | It said seize the day, pull the trigger, Cork, Ireland | Drop the blade | And watch the rolling heads From amiga-gcc-port-owner@nic.funet.fi Sat Apr 1 15:15:05 1995 Received: from xenologics.com ([194.77.5.1]) by nic.funet.fi with SMTP id <3159-3>; Sat, 1 Apr 1995 15:13:32 +0300 Received: from DARKNESS.gun.de (darkness@localhost) by xenologics.com (8.6.8.1/8.6.6) with UUCP id OAA24609 for nic.funet.fi!amiga-gcc-port; Sat, 1 Apr 1995 14:16:09 +0200 X-ZC-VIA: 19950401131829W+1@DARKNESS.gun.de Subject: V2.6.3 Bug in system() Message-Id: Date: Sat, 1 Apr 95 13:11:10 CET Organization: CDC X-ZC-POST: Postfach 11 12;31596 Uchte Path: DARKNESS.gun.de From: DARKSTAR@DARKNESS.gun.de (Carsten Meyer) X-Mailer: MicroDot 1.10 [UNREGISTRIERT] via Connectline-CLMSortin 2.17 To: amiga-gcc-port@nic.funet.fi X-Gateway: ZConnect CL DARKNESS.gun.de [Connectline/AmigaOS] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi Folks! Amiga GNU C V2.6.3 ------------ bug ------------------------------------- system ( NULL ) returns a wrong (not ANSI) value and crashes my amiga. ------------ bug ------------------------------------- Will this bug be fixed in V2.6.4. ? c u DarkStar -- MicroDot 1.8 From amiga-gcc-port-owner@nic.funet.fi Sat Apr 1 17:05:35 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <3814-1>; Sat, 1 Apr 1995 17:04:23 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA07509 (5.65c8/IDA-1.4.4 for ); Sat, 1 Apr 1995 16:04:08 +0200 Received: from sunserv2.izfm.uni-stuttgart.de by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA21218; Sat, 1 Apr 95 16:04:08 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9504011404.AA21218@sunserv.IZFM.Uni-Stuttgart.DE> Subject: sstack extension (beta) To: amiga-gcc-port@nic.funet.fi Date: Sat, 1 Apr 1995 15:50:00 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 20585 Hello everybody, this archive contains everything you need for stack extension with gcc and libnix (including some patches for the 2.6.3 gcc). Please read the file README for more details. Matthias begin 777 stack.lha M)V@M;&@U+>`%``!H&```X'.!'@``$7-T86-K7&)I9W1E/>$2B=;9-)7)86,"_'/_NY]W.21 MNTM0`D&N#7(V!"-MX\D>#>'=P':1M..W_Q\&3[_#X7LLTQO<5'FHTO-QI!P:>;3E?(]Q M54=%3V/C(G#EUS9LS_>3IGP?\K%@/P891P)M&JQF)*58F>CR/XXWKVJB5\6#8B-7/FTU>-> M,4DGG9CT=&86KCDK1M^-/Y:(RU/XXGKTL\_D'(#"X`E(64F+`'`Q#K;V]K\O M)=K$H#SOWSX=>I['$*IYZM;U[3S#]>,+0C+VA&581EZPCIS:>5^5&&_6%^@6 M,)T&(4@KW%PJ:"E^4N&4KV,$2.%7#.9GT'.G*+;ZZ1WJ_FO(G'Z$>OI@YM7: M<>N%1:C'5B]]B>!?T\@L@E"K&^F$7VM>4X[,KGE,H,Q MV8[\"+U#HE[`J0TWI48L'"!>`3RZ#DF>O>732F`)<,V/C+OAA-VPP&7#`9K+ M7SD))^2P6N/5T.7".FVPZS&BKAU<1S89%:[#.=D21L,KH@$*>I/T2!&&40F, MX)I3MB3%*<(Q*"]LNF<1`1_\5LI<6"<\E/!L;MA&#K$M6HB3`+-0.9IFW4?F MQAW2G$L.Y3D*0K"DXA2>#9'6G@2:_@;!"3`W M[A"9-:L)5;]4V9T,FS+W39G1)Z1C"L8SB,9]PQATC'\16.7=-Z&[H/(2;>? M`/0XM8')GY&;#7 M15GT:MU%.O)KE@L2K*75FB*P.C]P=1)X,IJ>?94MK`:(F^F.:X*0^BK[ ME`2D-[E)J@4N6.DD[*;FZI$[*T_8EMO%\JZ*@A+CJ/:=4#,!K-[J#6>TD MF\NB>I9O9\9+B0;:_PNSN7^-)J;9%4A+?[8N-C&'9`^=3C*@?%A-W824BNPB M&WL&ZACC6,'9A.1K:`J#IV479LC>S91[PW3*]ZZJ=)4@6ZH0"R] MG]50CLJH_K3K@4OT9&'_*J,"P?2JD'8R?VYL-A)>N,>OPCY/5&W6\`TTMD(? MPJ=`,?MJ=0,;Z5.P['JJ=\_/*E&)\3H8\GKH,=\FR/A07&3R5_P)(=0DQ?6. MTT?OA;53W)CI6,J'<@ZQ;1_4&ID^.!,CYOCMPU:V:GFFY5^#C5D&Q;*,HN\% M_W*SWT[=BN9XA;;2BKYZZVV-U.4>[C=Z6[:$VR>&")X)XLM;&@U+=(%```[&```X'.!'@``$7-T86-K7&)I M9W1E"Y3SZ($&'.7S;;>H',UX`H6#`."N0'XDI))<3PG)F-;Q_\-`842 M5@[@.TC:<=WOU\6/\_'X MX.2FDN.GFRY\EE=7#/!CQX^3-T-P<=,\'#R6NB$6%8BL_/DS6^56,4D_I9CU].06MFG6C=Z9'Y2(Y+8<4L%ZBJKSC MD!@<`B4+03#?#?8AU-_>%K[M8A`>F'>/@T9X,4HJGGMT07LW,/UX@VA*7M"4 MJ@E*\);,F;S8Z(A"EH34%%78>!GVJ9]A:!.906#$$4[A5P5%?NZA`"C18+E) M^>\B"[42E2"5@9"2]"@KZ>>'>(E"I%:HB%A>Y;*X<02/UPC1B"9K#(TY,/A> M.ER"02H3#M9)_V5)6NC4"524[#G%2IV:8+2F9!<'=!<4T[S61!9\&O*<=F6= MY&7"FC)VBH*4%0`12)=$^\2XFEG%AO\$N_I,5&"B2E&LYZ$*3HS6)@G1$!BX MB[(>S=L/1E0]&:Y.\>S?TM$P>1+1 M#))'8P"P,;F!9MTP%:3CTRALR#*:"JI6D:8(M:CA2J(E@'0H;6`1"@:,6`"= MT$2_@:1"1`%\1"9-VH)4[],X)XF3@E[IP3Q3^T8P6,9Q&,^L8P]0Q_P M*QRMD-5,R49K1D7"DU/LF@-MZ'#]LT)U30GU30D(?5-$V0-DT+>4)>S7V"!J MF=(B:`-:7(SC\;SF1Q[.MQ5ARE2(C^D8U3"&'AWO*-P^TW(NTW(E&Y%[*1^W1 M:RD>'09A7TJWCQ\O&S9:*[>7+GUT2BMRT&96N:"A,?2Q,T16!X?N#R5'!539 MSZ:DI0$2DV4O;7!0($J^YH$)#8Y2*G!#ECI)]U--=48[J;>+Y4V[J;/J)>-1 M+Q_671],IV3!N[SG1M.F#BZYE#W3*31,'V@,-^A73"R79O*),'TFEJ*N:6:( M4P#ZD'#X4YG7'?U!K(H-9.^OMVUSXQ0_U70R?.NA%)3_`[Y5-S+_^N!71Z5B M3_91Z+..-F`UDDTA*X)%0C:B+;ROIH26=C\2&[CW5Z7?2%5(`C#^*JUW88WK M^C7!:+,Z^O\I$]?TF[K\ZAUF4.LWPL]Q6?79[ZJ*;6/QA#<'T97=9X]=!Y49 MCW`7Y5S*=;Z^_B*Z\[7T*8N*-^5XOT;C277([279&.OPA)/=&VMX!IB7PA M_2I8`Q^VI9`QOM4M#L>JI;1RKCE(\2\8\_901[)-HOI00&1R-_R)(=0DR_>. MTTWSA;33Q(CI4,JZA]P_Q?W!J9'C:S1=[XZL-.MILYJ?,KP7Z<@V'31BEV`O M^Y6?.G->KD^#&J+KI0%<]:VV-U.4>[C=]3=N9&7_EA%WK";_5@OEX4.28.GS MG)E;36`<(^@/RHM=\$<]^`/A(R7UN$MVV`&E.!B\3P$FCQCH3UU]@_+ M=;I=<14C\;O__>MN/;;.!C"*,C(#P/$]#'<`*VTW-MA-AES1I-Q9:8PG]'1Q MM:$4H1:4=(8TZ4,H8PIRZGE-/3CR$C:VXTX@F2;V7[_)?;02@)J<0^5I/ MP"ENV\<[36ZX:^G#FHRA/,:E.6DSFZT+.KS?PS4PO0--=4X1K0MDK0=KK:,8 M!AFU#6T'%":J7>94)?-B0$J8_?-YCP5-_'"^\7RVVA-.:B8E=<%==L]6T.OG M8KW-R`PB_USFFGI-/D&B8?))J1D@PFLB"/_FHK]2*`1%*DV466,R**$?'+88 M["E;;+RJ*(EP+4@G$QL4]#8"?0XE#&`'2'1#?K4.U4(Y0P0*]2;9!;9.(()' M75EXPL$F"&3P8AHK)M0DT5H=-1;>JHOSJ+R)99\*-A/N:B>XCE$;J$W>7A+C MN92#NO[V"U5'0@\&,ANL:UC)ET;O:,99 MYN<=NK!>/GS19L1NF)FOU[7K]#"]9,5[^-],1UHNO/42O4':T:^ZPO>U8TE\ MS@&6AS[9KNILW5J)8@FUIW`S[N7N[=RJA4<^8MM5R?9<#>_]P.S.*HI%:R&& M\RB^(1&;0UVM;H<[;'.VWXN5QCE<\G*ZQRN^3E>8Y7OV3- MYCGO>4FWZTJ(55:;/GR;7,XF*+'L?Q->DWGE+@WM1;B-D8X.^,<#?^B_#WQ? MA_L75^1(3(7X8/<4;)`695>VAGBR&#*5+6QH-2VZ!P``)Z/LTD^G3I^X$SOH(R&ZO"%6R"5BTBI:2'PLV5)] M2I4_(33K\A#@&P"2=I-2U5K'`-/1\8CTE*Z"2E@#8!1$;`LH@/G4G@&(?T?S M3(\*#)^J`_D,?(&`CRT4:['&LZN\O@(Z1Z-9A=QP*)\:!]MZ,D*`+PX$`:D> M8I#NC?%W^?26PUZ9L6-\()(PCPD"$D4CD8#GOGVH4]?,`!"UL,GP@"^.U'%D M*14P)-OF4><`,810]3*2EOF`#R[I`?:,01<^-M]XH,,;1@!RF`A2":+B"<$4 M1';9L4CK<:SK_G(LV]$\%$J)2ZFC=5^5`+VVZ^R1`$:1D*TC'MNCK2^H'*B4 MHS!,-@,8`N7MU;?X%;MS>VKR`>/?V]HX+*4:`4-B&@(70F-_1]#'YR,+"5;[ M%%(1WS^]`RA'EW"@.D"Y=N;FXKN9CPSEYJITN<5OY@9SM5%+7 MM""74$-GDL(5)%%$VB MRZ&)T4]5&!9"+H0ESM7'G%4DQA(QQESJN0`:-"3DC&6471)]0C''OW+ORJWU MMI7Y+G#N7\1I?^J&FR1IMXDV;>OW-GY]GYE=GYYU&,8WI(UFG%\$6H8<4OLV M"ODOJ[VU.HZ70!=34Y@,4G*10//-*:5\Y(?2+7L,C`M-#*AA"1X7(?BB")O] MY`=DBC#B&20/BY&W`X:6)5#B],9(M8TOH\\:4E;U^[P[-_ANJK7MO]JJWBW^ M'>VKEW]@)5^Q;J=6L@G54R+=3JV$$TT\RW2RM'5FH(1<3:*Y#"1<9`5#RQQQ M1N!X(O*\*7828%BS8XOI1\PP!<4J?N:AAUZ95:TPO200/PQ@T)WKR1ONKQML M'?$`RR(A0'K&U>N?%EQ\7O@2RZ+1<;'/ZI>XC<<./[R-QZ;M*CW"KB'3)SZ/N$G?##+_/96#'T'=" M[/H/\PM^K>^&TH(`2[86=E)"SEJ^!]DJM?(VD+8X-&==V!;.+_]49J`:@5$[ M9M!+`9;:>%*P;N_?W[N_N7#0;VVM#'1GY)I1/+CIIBZ8PB^.JI7I9:;WUNE3 M28XHQAU<:R(NITL]?5NK#/TWN'=\W,4'\R/_Z1I:$J6#GC45".WF MGJK/$(R1FE-(<]:Z@ZEW'@4YD]N:+K](Q7TIC&]J\7&WN-;P1+(K-=A^F MHQ_Q/J=W,33O[L23$TSG)N=_IB;,Q5._LQ1_LD9V+G:]RL:9WPPV-@:);4U) MI^1J-$K'T[E+_!GBEN2AN5S9"`0$7&"B4P@;B!I>(6=!SUW@*7VMZ`-<&]E+ M96L())ULM+97&^SL8YQV,H9V*4IL7K:]E8+^YK[1"NR-;?QA5R<2Q:PTRBNF M%;*CW53RM$SOSA4B)6<8FSKQ:EC>)_G"J[R)\".WTPI?^$3S0IM"-,D)S+P8 MUQEEM[`#Q,`TEHLN/2.\0LLY&8\S0QZAOK9D42404&;YC9D4'B&%*_AF9D$T M6H'VFHB1A4V`L6\C-_;%+^V*'ZF@BNFL20PEM>)J0DU+;$?@``5UCTHVEJ^I\S`GX"7K71V*B33044E5%,D7H1? M`_`*+H<$4S%OK15#&R=M`U=3W`?(4,_2^T^CII-JRL*_H/9D7FW6W!IH!XNT M:FPD*[BS\`_YYE`.(>.P)R,.2,DT7U!>!#.U09H<::A2S9RTU'_SU&:%I=36 M?U_7+GC]I=;@PZ$-+O;6F`/_DL]5>^3D@7)]G$H43/ZG3%=/Q"XSH3C^('5V(7^V M-`DBF,_5%1++0#HIC0,HUZLR#LJ,O1Z&L$`/3?4.BP7H3`)FHM;&@U+04!``"J`0``6*M\ M'@``$'-T86-K7&EN:71?MM0[GG@#`027+51!X6MJ)J*4* M5HW;FI++^C"W2))+G&3>-WY=J/`NH`6I)SH2I&&-H%\OIBW+[0W`CL^9"X-ZU!$0F2SD-@G M8ET=&N>>+B/H>.=%]BV6@QO(HFU:;19)4ESVYG_\!/PA2MG!)H,T.>>&$GSSWN%J=X+N-EO4#[^&0?%QX``!-S=&%C:UQL:6YK M7V$U7S!?9BYC]K@`D5.3;2E?-;X#'A6)&8)#ASPG@)Y+,9RP"X-#9(^3*B47;Z-'Q8@48(*/Y*L0? MCFXPC"OC.Q0@U\/3.5Z*'VRGC`0N:T#0VZR.0'2)J6&D,#*I]RE]$)?`&*KU MH-J__/T?)^A>TB=*P:>1AUT?ZZ-%63/<.GA:=9FX```4I*B/>W6'&!1C?0Z3`_+1PA&%G&E9]OU+4&`C0@T\_;'P\I MTL"0GW2G%O8P!(M?;',!J,)TAJP`NNG<=/39#C`@KX`L]DZ&]TM_H5'NA4)_ M.XU)!@YE(U&YK])190+#E'#F8"61+6QH-2W/````5P$``)D$@1X```]S=&%C M:UQL;VYG:FUP+F.4+@#56Y-MIPOF<\`M!P@BK*H0ELC<-\!;DBED=I@ELF;8 M*\&\WS45J6)`$M*;DPW;&![*62TZ+P6-.KXRMB#8RQOZX38S3QYL!T(?@;>5 M23``_1,E[GB@K(78R7H1C0$R1&!A+P402=G"IU>9MY+I_AE<-)%MO>[T3#CJ M3YFWR@6@+J[-W+XY_6^J%;`ZVH8-:U%[&B^<-19&0I/1&'',K5[A3.+/XI-: M#UE^&8M6VO+W?<__DW1C3SO^T4C02R>4U%'FY7]*;W#.T-49LW_+`"0X+6QH M-2V4`0``50,``,QS@1X```YS=&%C:UQM86ME9FEL94(*`79CEZVVIES5^`/Q M*;+7).(U$<,%`$2W);AU$02.,:_7')F21O9QW*7(\;_R1V7`D9'@&I6$JG.XCS[`.]PT+>MK M!L(_B[:Z#M[@?W*8&0G&>E M9C%><@6+W7/%-<8AN75B8A_DR<8;PQ!JO>IE$=6]=!8+\5.X)L4+),J$Z20B MI$ON(#T3O@8W)LD!;%O1<^LB-BV5H'VH]:*?.6B$S65?BWO*$AB>ZLN?*,J- M*__TI%R-\:G M%@AG7XFT"X#^!0EO,VAPL(QASFSR')RR<6H^2OGX$L:N]5N\O'XO(B'ASYH% M_)`O_Z!F>C3_CGINZ3]^`-#2\^;1K460&@```,^>YS_&576.QKA1AA_[(D65O\-"V.&*+J??_Y+Z=*"E655;:-U]GFE MQ;5A`7[Z7,O:"Y<+@3VG*D'?^YIQ0H'K&R`EC?B,_47*W!"=O\Y(1Y'_0GO=_:$@R* M7597`"O*+6QH-2UT#0``$2(``$IQ@1X``!5S=&%C:UQS=&%C:V5X=&5N9"YD M;V,"S@G`=+KNC;:DZ\^_`'?'6S'622RPO4\,I:3"]G!;G6@=V9V9,UI:F]Z) M+4+=47L[W]W#WM8VVV_],KLN>EZ^QE=#4<[EOH M92NM52TTLT.>J;JSZ;F3K/UO8^G'T*3XTG\4K['KK_4Q3D]% M*V.FU+M@"\`&CGK;.M/O;9FS9)V6Y8?[^0Z]^I:9KK;5UO3Z*F:5)]GN3D^S MR9^/*G4!(I/6NWM!'U,>N>)X:E5STLKTIF;58JU"/`"=YT_.? M8LM;,MSC!;'^)R6ZPB9G80+9]]X1\:5$86I0X2%4TI5H:%-,?G210W.N52F= M="KJ7FF4("='MCX9+VM3Y_'DSH M1\UQG.^ZL%B.YVMN3,JM.E;^]G76Q^HAHC=/D_0W61NZVV]01RRL* M/>IE(#'Q)^MP9XQ!X_?,IS)B]?HGZU5S+GQ]W0RM:0;82Z7!])(PW]TBCU+5 M.1D]QWP:_,RX-T2,_-O+3,3@`_J.>+P]_(0CUUP9!)^\TMAPV=*R:R'G"\ZU MDULH-@AMHEKDB&ZN<,,O'R1W$GG3Z`UH'"PO@T]@-SMFN(C$Y`WWK63:CC4K M!]G!7\Q&(Q[ETT94ATY/M]47#EVKH)KRBU9,"3L<^U@;H5HI7G1_D%O%G)3R M,6TW7;6.ZL\H`GU`A6CBWH#2K2IE90-@2%%('ZJPG`-!$:>FUNMR=':&\ MZUVJ-XIUBYF*I@"(0@9UE`C";R<>!E6+K)!S]01F$8T4+.&Y8UE84X&MJVVU M![GTGV_.$4&DX1'7KJ3Z`[M=7,;Z0ZP>GZ(_9QO6F9(?8-:+P_844X("W/ MF$PV(D;80S%/1O+$XF46."3X1;:E`A@V2[6JPO_4!U%=M%HEWYT_4UZSB?H( M5R"(BF*MTFV,XQN0UIP/@VKE3$Y6"*)8T%NE-"P8"\:,&RCD";G79FV0.#`4 MCREX.!1^Y@@CHC$**/)U5AC/4/[43'&'?+A2/(P]D])HQ#)]!ME2,!-=U6@0 M\`LR_NAX.*SL@==M``KH9INM+GYD\_8#(^$H:>S..;4VZLX],([(6*@#1BY\ M\65/MU!I.YQR2S5ODRI!#7D)M8V1\S2CFQ6]()-HHPT*&MG&.` M@$1_9V%Y1]A+S[R'-ITH8ASI"(@J"V`@'ME090H!EB2DL0+M:NTJ'$Z(9=[G M(\.FY5JJWA_A2:F5LJNJ)2Y1/HA/P6DCO6EGC2HG`7A214K57=9%ZD!Z\U8A M>$Q5?W7,ZU"I">48",VXYA'A,;Q4606WTK1S-Y"._N8>).NTH=5KML$,?>@H M;A.2\)DAC+-@`.$RS?]L)"O[E5A.0)$3EX\0F+VUB5B3`IMQ46MJ$O]RZM!> M:,;5?:?*A#=M6B-%MM2ZLTE""A9\.GIZ7/Z@-MB$>VU95/+N^&3*D-Q7]/Q0 M8!T=KQT*5T`)?W6^ZT%3%M'A!I]L8W3B>)PC?]Y$]-`(OW"L)P&W=SL,J;`G-81X<:(PBD;*G4JSIGXTU7!P?1!'0@.!$R" MIDC.+*G<#0Z#:9VA*UI.NB>.%R1D(6%*/9PX1^"RD2HYRD_*P<`QD,0Y:,@K M"U]A5KA5?<>/?'AR_]28()>])7BJ$DX5^G%F=9XLZ>@=L4!I,\%*_K2VF?:O M9E&`SSH_09=S)3>LE?>O&F5PHB807+4Y(0R"#YRQ(5_DK%^49\4;9N'3[8C] MUISOHTY16A6D%4=H4#""O!9R%2>"#?ZFK@%H*&!3[8F^%5"_&VN.V3DNJ-H5 M7O.#I/A@X[Y[LJII;J_%&D4DUN#U7)]L6OM@XUP6J&QBJ88JC-0945F-DN5$^CT%7`FEO_T;W M:Z(5!MTJ\O3/Q'$)^F%V>5W/"N#7*%PK"'^5?C&W9@!SH>U>7-/Q!)_I)98- MVA'>LF+]#MZQMM8;*0<&G49#JC?PC7Y3@5-?^)C0,7W$)BP?>@`*$<`)E%&G M)?^PO;Q;H)EV@D!NL,`%:77%:T_L@3,*?.^'3`"@!0AV;,Z/M.A-_0P.`WO& MW_RW'>@-#PB/`D<)8IVSGXDQN)8HW5X7X1Y87HP08Y8IAYTEC;]O&&/WX&V.%:[ZD[H*Q9-;XA+WX#]2=,TPA)V'"2'MQP"YQ" M3BA2A2H&0_%EEG26$E=J;<*"XYH4)8PPE@+NQ0RT:X5:A!SDS\V?R%@(P#T' M=B*MFU%25$0NEK\<1KD+Q$GLI+0(/*<27/%K`6SSRR$49`\,,[*0H$R^P(@+ MR>(!N`7A5"7R-[QAK:?H>4/-XQN8P;\ZBB)"KH(O"P8)7!PDI0^$5@^.HTKG M,;V)^<4`[H6]IT`TTHLV"THQ3X*-@M7WXT6PSDL&`S8F\!3"D`V)]]IU;S4] M](CHA@`B!)*TR&DP7`"(X;:>XZI,FC@I`.FZ82IXTLLK9>1VGC`"P^M3.S&5 M]%(4\+`D`@O_:<,`J%62-[_,#@#*%0J'.ZDEE=5Z+F4SG850S[9P*":2A.!B M@2MHP&=5U.R(A-TI]K:]/P]*CS$?G#I/J:=/-@WM?1=@*?&>:(EC0L"H%["B M!JER-36]1&L<^2VZQ\;4X\!P,R,DYZ#"O_&CA=CW2M$^Z%=*9U$B:E:10='8 ML4#+KEDTG-$1`HASX8:J=L'/H9^;'K(#"Y-8ZU0J3_!]8J&P@A7>F15[+>]6 M7=V/CO1$6`K@FTF0LF786+\A21B$?L[L=R:^N&%Y_;"[G93%:,;7;BA M49.;E)<0R(](9#<0'.3T=1=VX0U%3_[.0H5/XL8O1AY@>B$,+NRRIO__C7;2 MKM8QN#SR$*2SL,D%D*!7)+F64L"X"336>6L'-A:&C`)G.BV)R1TY7G3Y.3Y.;S# MJ_3'`7]^/-*?1+'&PR'G?DEN&HG&("N7"R>=&P-!U!DTJ4:&H=-?TLA?0=D* MZ.HAS_P816OY6OFTPN3BY2,'W!LV]->VVF(M93U<+A2&K@C3JMO+Q)EYP?/@ M[(38^S@V1+.&7M<_R7XXIMU[B_\O,"^^H\L20)@X9B6)U>Y/W1PG2LS@]5A2Y M]^KP_76BG/(ZLQ.[]'4(G^ODV%^A1@]_U0GN_9 M-#-,$89?Y^CJKYMQO8'9=BHDN&`\ZUX:<<3Q3M:!^X_+R7B;DY./$:T/V(=X_)S8@[R?T\VT.\O-YD',HD3:$1FH8E6 M76P*'CX]H!W_4OL*P37&0*1(Q\_%R\6'#YN+;T>7B0C^T:9/?UL.-Q^;EQ$O MR>;S0J,I+[Y[+6%AB9U]B9BQX``!1S=&%C:UQS=&M?87)G8GET97,N8W%O=6YS:6=N960@;&]N9R!?7W-T M:U]A71EQX``!1S=&%C:UQS M=&M?;6EN9G)A;64N8^9!=6YS:6=N960@;&]N9R!?7W-T:U]M:6YFF]N M92YC_;UU;G-I9VYE9"!L;VYG(%]?=+6QH M-2UI````QP```.:E?!X``!%S=&%C:UQS=&MC:&M?9#`N8R@N`%Q3DVFHGS6^ M`SB61FFYE\'V"`Y$H!-;"/G/#%X-Q+&``XC&I/@P0R6'E=M0O"FVM#KU,"(D M63N\B?G^DS$=P>8A2&AA@MKWF"6Y8YNG;XJ1QG%?4OAR>Y*W["&JIOYN/,^K MI;^NSCT$)%DM;&@U+:<$``#A"P``]&B!'@``#G-T86-K7'-T:V5X="YC-'P# MSVN[T;3A][TL#M8/Z M#:%`_K6A.I#VG3I6SJ'HTR^?'APAVS,+F\O%TRJ`'WW0:)]Z=.T$/'@QKIT9 M+?^73C/`\\]X&G"=*IN\#+IK[)T/;T';'!GA;Z)>'2H%@K:"S'0@R@US+8"E MX0R'SAAY)!A4/'%]<C6!F),>N82J/.!NR9FPTD`V6P%NAU M\KQGSC[TLW:/K)4-[7`A)E'KT8LL(U1=7$..2LC8SHCJ0=@&HJGU5W2V2E0< M::>ZR"V'>=6MO:7O>!>%0'9A5`@])!?."_N.>D@IMF%`J`4V,F27\LV`(R,8 MF#-YKD MYU!2=0&C0!Z*L"*N0;O5BDI8LU'FT8N-Q0"PC@;Y:F+9@MCOY<$TYFV=UO;W"W^_N,5?$)'R0VWUFO_O[) M+A&L5!UU3-5PT_D9HK;JS:+15^24]1I4J)CC1>O3RX&"3ITDWC/=@2@+`E"U M/R3#@QP]E9LA!(F,F"':M`02\@IGFH;Y@X6+%HDMT;0Z=8RCANO%O(CAMKN2 M%M&E_G6-#Y6XEQH7F^'-RZ>?Z>[Y?'DW*/CSM4=[2HYJCVJ!QL[J8I,N_9AC M;;X==E-)VREZ5E@EC?E/,@)'T>J*\A[!`IL4L5R5NP(31-NTI:RQNKR]2UPD M=EUHV1BO($-)*.\CB?1GN+B`2XS:&SC]@+C^Q:C0@OW0*G+R_KF+7O>!OF"V M?[$TZ4RZ7"1M.J8^I`7MN'UK'?7!0>%TLX*XQ?%V"Y`&-T<89(I(V@9T%*^ MCL/3B6M8Y)-_QK>T;>$AMLC'+XZC?XRK:A=B_;2:@94J@8T.,]>X%' M9&[?A.1?C<)*W*_NL M0:S*_3"*]4X4,+7`55XL#>R.\YUUM_G2I"YB8Y0N.+!+V7_L(E?P>2R M2(];OC65L3O^-V[#1R7?$'%\UV&'*[##NPF__@NXWT>N+=OMO'D]4`]0`DURUL:#4M30```%8```"%O'L>```.$O'/L-.` M"TW4C8T,N1_J*GU?XJY.6QL(BHG27[!23PKVIK:PE$\DMM2"24SP6*5J9M&R'^$''_B>?\V MB!/XL'Q?TH0B]JF&-O;$QARIP98+E\#*,9/!PF M`IX@/=`![MX7]V(B1&$[&KL)-[AW*;@4B:UP7"G?L%B<"&R>;R1#\IY"NW'G M9'IB>UX.<+,:BUM<=#%C)`X4J9&%>!;>=,)Z%[&#P&%11?.G)U+6VO]Q MNR98&;A!:^!S'H0;5+6+LNT#[SPFL5#A2&P0L]R1\1K3 MUSP,=L!X0LE&>MMUR-6K5 M!()-O/]$(\DQR7,^/)B'5Z*_/-%M_:#9_T*8V\\S3_P[C7!&?P6W6N!4;ON) M\TW+Y:9D7-W"M`4SE?5FE]KEH_"CQZ*+?3D6@KYPIX_2RBR=%?*JAQWRXU=U=?>>*CAQR9YA/ MNF0=%??B64>Q0$>U!ZK MV''9YET\D.T'54B#]6P3?V:_E:,&1T5?&;UEJN?=/%^H5GOA684>#RP?#HKRKAUS;9[M3//.;^KC M?/R0C23B@*K+R:`RJ.UFW*:IH:UX4+HR$`/U/HXC)UY)%K4N+GT-Y./^_IVJ M&5`-(6A!=N,J8,0T=5#)#^>GL/R<-1)?8E_P23M&"ZEL%/.CI& M*%>I/N=7BR6-IT=M%6*27C[1JRPA.WI M5TSH&>;\/R$R4/!`?)N`>#(MJ\)::(\5V;%/F^QMB,SXBN//'0RLV*AC_?N7 MN[Y>9VQ"YYHU1^*`)_\M;&@U+;X```!0`0``JYA_'@``$7-T86-K7'-U8E]D M,%]S<"YC^"(`KUMSC3<,;?_`'*YB5854S`8ERRM:9+,\X]2$BM"_"Q'P%N.< M`V"BL@"1-+UKMJ.]KO3X2*V)PZ_(BM'S;A#A%W[&73L'6RZZ'W88$1)>PFJ) M(;"7VGV)=!7101VQ*1!_?!Q@D.7M.M6OZ=ON(2QS!JLO=3X9L$>Q'6^N.0ME M50'+6L8EW\;C%S53IN8PJQ\`6KED^>(9H_2QM7Q=$[?*E?W]<_R8BQ/SL4_^@R.`(W(M;&@U+8D```"T````R7AS'@``#7-T86-K M7'AC;W9F+F-7IJ%\[X`_-<+MP3T401%@@B@U47&C+^%)%+/]K!%XW M.X(HH`8:2R.@M]S!#.R,D3W*W0;Z)(F/=UQ#-?%S`2FT?%PR(ZXPD0+:JT*B M'`JZ014$B4ON$;QM[/CY!JH,>,VB#>C!^D*.']11.0`!P<1[ --?'E9N37IV;9B>S``!4$ ` end From amiga-gcc-port-owner@nic.funet.fi Mon Apr 3 16:32:08 1995 Received: by nic.funet.fi id <3148-2>; Mon, 3 Apr 1995 16:26:20 +0300 From: Leonard Norrgard To: fleischr@izfm.uni-stuttgart.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9504011404.AA21218@sunserv.IZFM.Uni-Stuttgart.DE> (fleischr@izfm.uni-stuttgart.de) Subject: Re: sstack extension (beta) Message-Id: <95Apr3.162620+0300_eet_dst.3148-2+13@nic.funet.fi> Date: Mon, 3 Apr 1995 16:26:13 +0300 Please don't mail large uuencoded files to the mailing list, upload them by ftp instead (/pub/amiga/incoming/gnu) to make them available by ftp. I've put stack.lha in the /pub/amiga/gnu/beta/ directory. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Mon Apr 3 16:33:05 1995 Received: by nic.funet.fi id <3124-1>; Mon, 3 Apr 1995 16:28:27 +0300 From: Leonard Norrgard To: DARKSTAR@DARKNESS.gun.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: (DARKSTAR@DARKNESS.gun.de) Subject: Re: V2.6.3 Bug in system() Message-Id: <95Apr3.162827+0300_eet_dst.3124-1+16@nic.funet.fi> Date: Mon, 3 Apr 1995 16:28:24 +0300 > system ( NULL ) returns a wrong (not ANSI) value and > crashes my amiga. Which library? From amiga-gcc-port-owner@nic.funet.fi Mon Apr 3 17:56:31 1995 Received: by nic.funet.fi id <3217-2>; Mon, 3 Apr 1995 17:54:43 +0300 From: Leonard Norrgard To: Robert Atkins Cc: amiga-gcc-port@nic.funet.fi Subject: gcc gurus on 68040 without FPU Message-Id: <95Apr3.175443+0300_eet_dst.3217-2+16@nic.funet.fi> Date: Mon, 3 Apr 1995 17:54:38 +0300 Robert Atkins writes: > Help! > > Firstly, my system consists of an Amiga 4000/LC040 - ie MMU but no FPU. I > have 10 meg of RAM and plenty of HD space so I thought I may as well install > gcc - I am learning c++ at university. > > I downloaded and installed all the 020 archives, unpacked them and did all > the assigns. I tried to compile hello.c . The machine thought about it > for a couple of seconds and then gave me an 8000 000B guru. I deleted > everything, downloaded the 68000 versions, re-installed, and it did > exactly the same thing. Looking at the sources, it seems that ixemul.library might have difficulties with the 68040 math emulation (if loaded). Ixemul uses some floating point instructions while in supervisor mode, if the system indicates it has an 68881 FPU installed. This is exactly what the system indicate if you have a 68040 without FPU, but with math emulation loaded. I suspect that the math emulation doesn't work from supervisor mode or from trap handlers. You might want to try running GCC without having loaded the 68040 math emulation code (see the instructions on how to do this that hopefully came with your computer). Since I don't have a system like yours, I can't test this out myself. Please report your observations back. > +--- -- - Robert Atkins, c9412417@peach.newcastle.edu.au -- vinsci From amiga-gcc-port-owner@nic.funet.fi Mon Apr 3 18:19:11 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <751-1>; Mon, 3 Apr 1995 18:17:32 +0300 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA18571; Mon, 3 Apr 95 18:11:11 +0300 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA09675; Mon, 3 Apr 95 18:18:23 +0300 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9504031518.AA09675@hpcl.cti.gr> Subject: Re: gcc gurus on 68040 without FPU To: amiga-gcc-port@lists.funet.fi (gcc) Date: Mon, 3 Apr 1995 18:18:20 +0300 (EET DST) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <95Apr3.175443+0300_eet_dst.3217-2+16@nic.funet.fi> from "Leonard Norrgard" at Apr 3, 95 05:54:38 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 601 > > Firstly, my system consists of an Amiga 4000/LC040 - ie MMU but no FPU. I > > Looking at the sources, it seems that ixemul.library might have > difficulties with the 68040 math emulation (if loaded). Ixemul uses MMU=Memory Management Unit, not math emulation. The 68020 version will probably not work in such a configuration, as I believe it requires a FPU. The 68000 version should work just fine however, and compiling with -m68040 -msoft-float should produce executables appropriate for this machine. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Mon Apr 3 18:45:08 1995 Received: by nic.funet.fi id <3723-2>; Mon, 3 Apr 1995 18:44:07 +0300 From: Leonard Norrgard To: kyrimis@theseas.ntua.gr CC: amiga-gcc-port@lists.funet.fi In-reply-to: <9504031518.AA09675@hpcl.cti.gr> (kyrimis@hpcl.cti.gr) Subject: Re: gcc gurus on 68040 without FPU Message-Id: <95Apr3.184407+0300_eet_dst.3723-2+18@nic.funet.fi> Date: Mon, 3 Apr 1995 18:44:05 +0300 > > Looking at the sources, it seems that ixemul.library might have > > difficulties with the 68040 math emulation (if loaded). Ixemul uses > > MMU=Memory Management Unit, not math emulation. The 68020 version will > probably not work in such a configuration, as I believe it requires a FPU. > The 68000 version should work just fine however, and compiling with -m68040 > -msoft-float should produce executables appropriate for this machine. The problem is (probably) in the assembler source, the assembler source being the same for both 68000 and other versions of the library. So the 68000 version won't work either (just as the original message stated). All that matters is if execbase has the AFF_M68881 flag set. Loading the 68040 math emulation software sets this flag. Note that ixemul.library was originally written to be self-configuring to different CPU/FPU setups. The actual changes in the 40.4 versions between CPU variants are minimal, most of them are only there to save a few bytes (a goal I disagree with, since the library exists in only one copy in memory anyway). I'd much prefer a single generic self-targeting version of ixemul.library, but we'll see what turns up. Maybe we'll have both a generic as well as CPU-tuned variants. Anyone actually using GCC successfully on a 68040 without FPU? Guess not... ;-) -- vinsci From amiga-gcc-port-owner@nic.funet.fi Mon Apr 3 19:50:16 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <387-3>; Mon, 3 Apr 1995 19:47:53 +0300 Received: by theseas.ntua.gr with UUCP; Mon, 3 Apr 1995 19:49:31 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06vf@kriton.UUCP>; Mon, 3 Apr 95 19:45:16 EET Date: Mon, 3 Apr 95 19:45:16 EET Message-Id: <9504031745.06vf@kriton.UUCP> In-Reply-To: <95Apr3.184407+0300_eet_dst.3723-2+18@nic.funet.fi> (from Leonard Norrgard ) (at Mon, 3 Apr 1995 18:44:05 +0300) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 991 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: vinsci@nic.funet.fi Cc: amiga-gcc-port@lists.funet.fi Subject: Re: gcc gurus on 68040 without FPU Hi Leonard (Leonard Norrgard), in <95Apr3.184407+0300_eet_dst.3723-2+18@nic.funet.fi> on Apr 3 you wrote: > The problem is (probably) in the assembler source, the assembler > source being the same for both 68000 and other versions of the > library. So the 68000 version won't work either (just as the original > message stated). All that matters is if execbase has the AFF_M68881 > flag set. Loading the 68040 math emulation software sets this flag. Yes, but *why* would one load the emulation software (which uses the 68040 FPU) on an FPU-less 68040? (Or is 68040.library so stupid that it always loads it on 68040s? In this case, using an older version of 68040.library, e.g. 36.2, the one shipped with the Fusion-40, which doesn't do FPU emulation might help.) -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Did you just see what I didn't see?" "No." "Neither did I!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Apr 4 11:31:48 1995 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <3980-3>; Tue, 4 Apr 1995 11:29:50 +0300 Received: by hald.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr4.112950+0300_eet_dst.3980-3+43@nic.funet.fi> From: To: Date: Tue, 4 Apr 1995 11:29:46 +0300 Date: Tue, 4 Apr 1995 10:30:58 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Function arguments in registers? How? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, How do I make GNU C call functions with the arguments in registers? What I mean is that functions should take their arguments from registers rather than popping them from the stack. How do I do it? Thanks in advance. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP2.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue Apr 4 11:34:50 1995 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <3796-3>; Tue, 4 Apr 1995 11:34:22 +0300 Received: by hald.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr4.113422+0300_eet_dst.3796-3+44@nic.funet.fi> From: To: Date: Tue, 4 Apr 1995 11:34:19 +0300 Date: Tue, 4 Apr 1995 10:35:31 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: How do I get inline header files? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, How can I generate inline header files? I've tried fd2inline, but the only thing it does it to crash. I call it like fd2inline INCLUDE:/fd/exec_lib.fd INCLUDE:clib/exec_protos.h but it just crashes without generating any inline headers. As I don't have perl, I can't use geninline, and most of the supplied inline headers don't work (FreeMem() calls disappear, for example). Can anybody help me? Thanks in advance. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP2.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue Apr 4 15:12:02 1995 Received: by nic.funet.fi id <3265-3>; Tue, 4 Apr 1995 15:09:50 +0300 From: Leonard Norrgard To: kyrimis@theseas.ntua.gr CC: amiga-gcc-port@lists.funet.fi In-reply-to: <9504031745.06vf@kriton.UUCP> (kriton!kyrimis@theseas.ntua.gr) Subject: Re: gcc gurus on 68040 without FPU Message-Id: <95Apr4.150950+0300_eet_dst.3265-3+49@nic.funet.fi> Date: Tue, 4 Apr 1995 15:09:45 +0300 > Yes, but *why* would one load the emulation software (which uses the > 68040 FPU) on an FPU-less 68040? (Or is 68040.library so stupid that it > always loads it on 68040s? In this case, using an older version of > 68040.library, e.g. 36.2, the one shipped with the Fusion-40, which > doesn't do FPU emulation might help.) Even on an FPU-less 040 it would, IMHO, make sense to provide software (-only) emulation of the FPU instructions in order to keep binary software compatibility. Thus I see nothing strange in the emulation library providing it. From amiga-gcc-port-owner@nic.funet.fi Tue Apr 4 17:04:46 1995 Received: from leon.nrcps.ariadne-t.gr ([143.233.2.1]) by nic.funet.fi with SMTP id <3862-3>; Tue, 4 Apr 1995 17:00:30 +0300 Received: from hpcl.cti.gr by leon.nrcps.ariadne-t.gr (4.1/25-MHS-7.0) id AA22060; Tue, 4 Apr 95 16:52:08 +0300 Received: from hpcl2.cti.gr by hpcl.cti.gr (4.1/SMI-4.1) id AA13892; Tue, 4 Apr 95 16:59:27 +0300 From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Message-Id: <9504041359.AA13892@hpcl.cti.gr> Subject: Re: gcc gurus on 68040 without FPU To: vinsci@nic.funet.fi (Leonard Norrgard) Date: Tue, 4 Apr 1995 16:59:25 +0300 (EET DST) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-To: kyrimis@theseas.ntua.gr In-Reply-To: <95Apr4.150950+0300_eet_dst.3265-3+49@nic.funet.fi> from "Leonard Norrgard" at Apr 4, 95 03:09:45 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 685 > Even on an FPU-less 040 it would, IMHO, make sense to provide software > (-only) emulation of the FPU instructions in order to keep binary > software compatibility. Thus I see nothing strange in the emulation > library providing it. Yes, but if such emulation actually existed, there wouldn't be any problem in executing FPU instructions. I am under the impression that FPU emulation on 68040-equipped amigas requires an 68040 FPU, and only emulates those 68882 instructions that are not implemented in the 68040 FPU. Could someone more versed in such things give a more definitive opinion? -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Tue Apr 4 18:18:16 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <3816-1>; Tue, 4 Apr 1995 18:15:09 +0300 Received: by ceylon.informatik.uni-rostock.de id RAA29165; Tue, 4 Apr 1995 17:14:35 +0200 Received: by honshu.informatik.uni-rostock.de id RAA27204; Tue, 4 Apr 1995 17:14:33 +0200 From: Gunther Nikl Message-Id: <199504041514.RAA27204@honshu.informatik.uni-rostock.de> Subject: inline problems (was: your mail) To: gc948374@gbar.dtu.dk Date: Tue, 4 Apr 1995 17:14:32 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Apr4.113422+0300_eet_dst.3796-3+44@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Apr 4, 95 11:34:19 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 701 > Rask Lambertsen wrote: > > How can I generate inline header files? I've tried fd2inline, but > the only thing it does it to crash. I call it like > > fd2inline INCLUDE:/fd/exec_lib.fd INCLUDE:clib/exec_protos.h > > but it just crashes without generating any inline headers. > > As I don't have perl, I can't use geninline, and most of the supplied > inline headers don't work (FreeMem() calls disappear, for example). I never had problems with the inline-headers, so I am not able to locate your problem. But please post some source code, that may help. There is really no need to generate the inlines yourself. The files with gcc2.6.3 cover all OS-Versions upto 3.1 Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Apr 6 17:55:25 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <158-1>; Thu, 6 Apr 1995 17:48:58 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA14251 (5.65c8/IDA-1.4.4 for ); Thu, 6 Apr 1995 16:48:43 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA28510; Thu, 6 Apr 95 16:48:42 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9504061448.AA28510@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: V2.6.3 Bug in system() (fwd) To: amiga-gcc-port@nic.funet.fi Date: Thu, 6 Apr 1995 16:48:42 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1356 Forwarded message (some stuff deleted): > From DARKSTAR@DARKNESS.gun.de Tue Apr 4 01:09:22 1995 > > Kleines Testprogramm test.c > ------------------------------ Schnipp ------------------------------ > #include > #include > > int main(void) > { > printf("Shell %svorhanden\n",system(NULL) ? "" : "nicht "); > return EXIT_SUCCESS; > } > ------------------------------ Schnapp ------------------------------ > > Protokoll GNU C unter irgendeiner UNIX Kiste > --------------------------------------------------------------- > CS > hphalle6f.(0)./usr/stud/stieber> gcc -Wall test.c > CS > hphalle6f.(0)./usr/stud/stieber> a.out > CS > Shell vorhanden > CS > hphalle6f.(0)./usr/stud/stieber> > --------------------------------------------------------------- > > Protokoll GNU C unter AmigaOS > --------------------------schnipp------------------------ > 1.Ram Disk: 0> gcc -Wall test.c > 1.Ram Disk: 0> a.out > [CLI 4] > Shell nicht vorhanden > 1.Ram Disk: 0> > > Anschliessend stuerzt der Rechner ziemlich unmotiviert ab. > --------------------------schnapp------------------------ > In english: ANSI demands that system(NULL) returns whether there exists a shell or not (should be 1 on the amiga). ixemul.library doesn't check for NULL and therefore crashes the system. I guess this should be easy to fix :-). Matthias From amiga-gcc-port-owner@nic.funet.fi Tue Apr 11 11:06:20 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <941-2>; Tue, 11 Apr 1995 11:02:04 +0300 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA16347 (5.65c-6/7.3w-FAU); Tue, 11 Apr 1995 10:01:59 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id KAA17617 (8.6.10/7.4a-FAU); for ; Tue, 11 Apr 1995 10:01:54 +0200 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA22731; Tue, 11 Apr 1995 09:01:53 +0100 Date: Tue, 11 Apr 1995 09:01:53 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9504110801.AA22731@pctc.chemie.uni-erlangen.de> To: amiga-gcc-port@nic.funet.fi Subject: atan2() in libnix has a bug Hello, the function atan2(y,x) in the math part of libnix gives wrong results. The description of atan2() says the result must be in the interpall [-pi:pi]. The rules are: 1.) y > 0 and -inf < x < +inf : the result is from pi (x=-inf) to 0 (x=inf) 2.) y < 0 and -inf < x < +inf : the result is from -pi (x=-inf) to 0 (x=inf) I hope this will you. Have happy easter holydays ! Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Thu Apr 13 02:11:59 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <3987-2>; Thu, 13 Apr 1995 01:58:03 +0300 Received: from decap2.zdv.uni-tuebingen.de by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HP8WM5A4R4005G5W@FIPORT.FUNET.FI>; Wed, 12 Apr 1995 09:44:42 +0200 (EET) Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA28321; Wed, 12 Apr 1995 11:44:18 +0200 Date: Wed, 12 Apr 1995 11:44:17 +0200 (MET DST) From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Subject: New GCC installer script To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@nic.funet.fi Message-id: <9504120944.AA28321@decap2.zdv.uni-tuebingen.de> X-Mailer: ELM [version 2.4 PL23] Content-type: text Content-transfer-encoding: 7BIT Content-length: 4505 Hello, Philippe (and list), I have uploaded an archive with a new installer script for GCC to your host (incoming/Amiga) and to Aminet. (It is just small, thus could easily be replaced, if there should be bugs again. I add the readme below. Please, anyone of you, try it, if possible. Especially tell me, what you think of the idea to modify the specs file to use GNUINCLUDE: (which can then be assigned to a directory with the OS headers.) and tell me, if this works for you. Jochen P.S: Am I the only one, who doesn't receive mails from the list since some days? About GCC-Install ================= This archive contains an installer script for the GNU C compiler. It may be used independent from the version you want to install or deinstall. This file should replace the existing installer script, which is known to be buggy (sorry) and lacks some features which seem to me to be rather important, considering all those questions which would never be asked, if people would use this script. GCC-Install's new features are - does not depend on external files, textfiles that should be created are contained in the script. - can make gcc to use the Commodore OS headers without copying them to GNU:os-include - can be used for deinstallation or reconfiguration only I beg anyone downloading gcc, to download this file too. Try it. Currently one cannot expect it to be more than a beta version, but replacing it will be lots easier than replacing the complete gcc archive. Let me know, if you find any problems or don't like something. My emal address is jochen.wiedmann@zdv.uni-tuebingen.de GCC-Install behaves completely different, depending on whether an assign GNU: exists. If it does, the script opens a window on startup, which allows to switch between the choices 1) Deinstall existing GNU C version 2) Install and configure new version 3) Configure existing version 4) All of the above 5) Exit If no assign GNU: exists, this window is suppressed and choice 2) is assumed silently. 1) Deinstalling existing GNU C version -------------------------------------- The user may select a directory with the version to deinstall (default GNU:). Deinstallation is done in one of two possible ways: a) Complete deinstallation b) Partial deinstallation Complete deinstallation means to remove the complete directory (except for directories which are in use, for example GNU:bin aka bin:), partial deinstallation will remove only lib/gcc-lib. 2) Installing a new GNU C version --------------------------------- The user may select a directory which will be the parent drawer of GNU:. A subdrawer "gnu" will be created, from now on being referred as GNU:. (Sorry for those of you which have more than one version of GNU C installed, but the name "gnu" is fixed in the LhA archives.) Installation begins with unpacking the archives. The user may select the archives he wants to be unpacked to GNU:. If the machine is equipped with a 68020 or better, the user will be asked, if he wants to use the 020 binaries. Some files are missing in the archives: Those which may be installed as links to other files. The user is asked if he wants to use links (hard links now, usually bin: will reside on only one partition and soft links *do* make problems.) or copy the files. If the 020 binaries have been installed, the installation ends with asking the user, if he wants to rename gcc-020 to gcc, g++-020 to g++ and so on. Finally the installer script continues with step 3 to configure the new GNU C installation. 3) Configuring a GNU C version ------------------------------ Configuration starts with asking the user for environment variables he wants to copy from GNU:envarc to envarc:. The user is asked, if he has the Commodore OS headers. If this is the case, he may select the directory where they are installed and the specs file will be modified to use the option "-I GNUINCLUDE:". (The assign will be created from within GNU:s/User-Startup.) Note, that GNU:s/User-Startup can be modified, so that GNUINCLUDE: is a multiassign. Finally the s:User-Startup is modified, so that it creates an assign GNU: and executes GNU:s/User-Startup. This file will be created (it is contained in the installer script, an external file is no longer being used.) Existing specs and GNU:s/User-Startup files are considered obsolete. A directory GNU:obsolete is created, where the old versions will be copied to. Jochen Wiedmann From amiga-gcc-port-owner@nic.funet.fi Thu Apr 13 09:52:48 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <3145-2>; Thu, 13 Apr 1995 09:48:27 +0300 Received: from proffa.cc.tut.fi by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HP9ZFB9DAO0051J6@FIPORT.FUNET.FI>; Thu, 13 Apr 1995 04:16:13 +0200 (EET) Received: (from k150471@localhost) by proffa.cc.tut.fi (8.6.8.1/8.6.6) id HAA09512 for amiga-gcc-port@lists.funet.fi; Thu, 13 Apr 1995 07:15:50 +0300 Date: Thu, 13 Apr 1995 07:15:50 +0200 (EET DST) From: Kniivil{ Jarkko Subject: Source of libm.a found in the Amiga GCC 2.6.3 distribution (?) To: amiga-gcc-port@nic.funet.fi Message-id: <199504130415.HAA09512@proffa.cc.tut.fi> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit Content-length: 1129 Hello fellow gcc hackers! This morning I realized that the libm.a math library distributed along Amiga GCC might be of some use to other platforms as well---namely [don't utter that word ;-) ] to the Atari MiNT target. Now I'm wondering how this library came into the distribution, and if somebody knows where I can get the sources to this thing. (I looked at the most obvious places, ie. AMINET and colombo, but couldn't locate them.) This library might be of better use (more efficient (?)) instead of the PML (Portable Math Library) incidentally written by Fred Fish (!) over a decade ago. Now, you might ask yourself why an Amigan needs to be concerned about Atarian, but that's because I have a friend whose acquainted with that platform; I'm just being curious. [Hope this will revive some of the discussion we've been missing since a couple of weeks. What's up? Why don't you ask about the wheather? :-) ] ~ Jarkko -- E-Mail: k150471@cc.tut.fi | S-Mail: Jarkko Kniivil\"a % (TEX-format) [ This space unintentionally | Opiskelijankatu 4 F 315 left blank! ] | FIN-33720 TAMPERE From amiga-gcc-port-owner@nic.funet.fi Thu Apr 13 11:00:53 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <3685-3>; Thu, 13 Apr 1995 10:59:06 +0300 Received: by colombo.telesys-innov.fr; Thu, 13 Apr 1995 09:59:06 +0100 From: Philippe BRAND Message-Id: <199504130859.JAA22065@colombo.telesys-innov.fr> Subject: Re: Source of libm.a found in the Amiga GCC 2.6.3 distribution (?) To: k150471@proffa.cc.tut.fi (Kniivil{ Jarkko) Date: Thu, 13 Apr 1995 09:59:05 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199504130415.HAA09512@proffa.cc.tut.fi> from "Kniivil{ Jarkko" at Apr 13, 95 07:15:50 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 756 Kniivil{ Jarkko writes: > Hello fellow gcc hackers! This morning I realized that the libm.a math > library distributed along Amiga GCC might be of some use to other platforms > as well---namely [don't utter that word ;-) ] to the Atari MiNT target. > Now I'm wondering how this library came into the distribution, and if > somebody knows where I can get the sources to this thing. This is my entire fault. Now that I have enough disk space on my FTP server, I should put all sources on-line. I'll do it asap. libm.a comes from the BSD world, standard libm-5.4 (from memory). -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Apr 13 12:37:49 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <3842-4>; Thu, 13 Apr 1995 12:35:43 +0300 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA22738; Thu, 13 Apr 1995 11:35:21 +0200 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA12320; Thu, 13 Apr 95 11:35:20 +0200 Date: Thu, 13 Apr 95 11:35:20 +0200 From: isthesin@TechFak.Uni-Bielefeld.DE Message-Id: <9504130935.AA12320@moos.techfak.uni-bielefeld.de> To: dev@flevel.demon.co.uk Subject: Re: Shared executables for Amiga GNU ports Cc: amiga-gcc-port@nic.funet.fi From: dev@flevel.demon.co.uk Hi isthesin, > IMHO it is impossible to go on with static linked libraries, since the > executable size (and with it the load time and disk consumption) can no > longer be tolerated. I agree with you here. How's about stealing the one good idea that Microsoft has had: Dynamic Link Libraries. This would mean the C code would remain the same and the linker could (Optionally) make any of the link library calls into DLL's. The linker could then insert the correct startup code to link the DLL's. ixemu library could then control loading and flushing out DLL's as needed. Hmm, sounds good, but I do not know how DLL's work. I suppose they make use of the segmentation 'feature' of the INTEL chips to supply each program with it's own data space ? The idea of putting dynamic link libs into ixemul.library is great! It should be possible to tell the linker to create special output and to have ixemul handle that on startup..... Still, we need -fbaserel support.....PHILIPPE ???????????????????????? How about it ? Any progress? I know this would be quite a bit of work to code but I think it would be very useful. Indeed. Regards, Trefor S. Bye... Stephan From amiga-gcc-port-owner@nic.funet.fi Thu Apr 13 13:08:52 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <3612-1>; Thu, 13 Apr 1995 13:06:16 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 13 Apr 1995 12:03:33 +0200 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA08688; Thu, 13 Apr 95 12:03:37 +0200 Date: Thu, 13 Apr 95 12:03:37 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9504131003.AA08688@inf-wiss.uni-konstanz.de> Received: by mammern.inf-wiss.ivp.uni-konstanz.de (4.1/SMI-4.1) id AA03290; Thu, 13 Apr 95 12:03:37 +0200 To: amiga-gcc-port@nic.funet.fi Subject: GCC struct return badly configured since at least 2.5.8 Hi, since a friend of mine couldn't believe that there exists an m68k GNU-C compiler which wouldn't return (or receive) a struct address in register A1 for struct returning functions, I did a couple of tests with gcc-1.40, gcc-2.3.3, gcc-2.5.8 and gcc-2.6.3: --------foo.c typedef struct { int a; int b; int c; int d; int e; } foo; foo foo1(f1) foo f1; { foo f2; f2 = f1; return f2; } void foo2() { foo f; foo1(f); } foo foo3(n) int n; { foo f; f.a = f.b = f.c = f.d = f.e = n; return f; } foo foo4(f,n) foo f; int n; { f.a = f.b = f.c = f.d = f.e = n; return f; } -------- gcc-1.40 -O #NO_APP gcc_compiled.: .text .even .globl _foo1 _foo1: link a5,#-20 movel a2,sp@- lea a5@(8),a0 lea a5@(-20),a2 movel a0@+,a2@+ movel a0@+,a2@+ movel a0@+,a2@+ movel a0@+,a2@+ movel a0@,a2@ lea a5@(-20),a0 movel a1,a2 movel a0@+,a1@ addqw #4,a2 movel a0@+,a2@+ movel a0@+,a2@+ movel a0@+,a2@+ movel a0@,a2@ movel a1,d0 movel a5@(-24),a2 unlk a5 rts .even .globl _foo2 _foo2: link a5,#-40 movel a5,a0 movel a0@-,sp@- movel a0@-,sp@- movel a0@-,sp@- movel a0@-,sp@- movel a0@-,sp@- lea a5@(-40),a1 jbsr _foo1 unlk a5 rts .even .globl _foo3 _foo3: link a5,#-20 moveml #0x30,sp@- movel a5@(8),d0 lea a5@(-20),a0 movel d0,a0@(16) movel d0,a0@(12) movel d0,a0@(8) movel d0,a0@(4) movel d0,a5@(-20) movel a0,a2 movel a1,a3 movel a0@,a1@ addqw #4,a3 addqw #4,a2 movel a2@+,a3@+ movel a2@+,a3@+ movel a2@+,a3@+ movel a2@,a3@ movel a1,d0 moveml a5@(-28),#0xc00 unlk a5 rts .even .globl _foo4 _foo4: link a5,#0 moveml #0x30,sp@- movel a5@(28),d0 lea a5@(8),a0 movel d0,a0@(16) movel d0,a0@(12) movel d0,a0@(8) movel d0,a0@(4) movel d0,a5@(8) movel a0,a2 movel a1,a3 movel a0@,a1@ addqw #4,a3 addqw #4,a2 movel a2@+,a3@+ movel a2@+,a3@+ movel a2@+,a3@+ movel a2@,a3@ movel a1,d0 moveml a5@(-8),#0xc00 unlk a5 rts -------- gcc-2.3.3 -O1 #NO_APP gcc2_compiled.: .text .even .globl _foo1 _foo1: link a5,#-20 movel a1,d0 movel a5@(8),a5@(-20) movel a5@(12),a5@(-16) movel a5@(16),a5@(-12) movel a5@(20),a5@(-8) movel a5@(24),a5@(-4) movel d0,a0 movel a5@(-20),a0@+ movel a5@(-16),a0@+ movel a5@(-12),a0@+ movel a5@(-8),a0@+ movel a5@(-4),a0@ unlk a5 rts .even .globl _foo2 _foo2: link a5,#-40 lea a5@(-4),a0 movel a0@,sp@- movel a0@-,sp@- movel a0@-,sp@- movel a0@-,sp@- movel a0@-,sp@- lea a5@(-40),a1 jbsr _foo1 unlk a5 rts .even .globl _foo3 _foo3: link a5,#-20 movel a1,d0 movel a5@(8),d1 movel d1,a5@(-4) movel d1,a5@(-8) movel d1,a5@(-12) movel d1,a5@(-16) movel d1,a5@(-20) movel d0,a0 movel a5@(-20),a0@+ movel a5@(-16),a0@+ movel a5@(-12),a0@+ movel a5@(-8),a0@+ movel a5@(-4),a0@ unlk a5 rts .even .globl _foo4 _foo4: link a5,#0 movel a1,d0 movel a5@(28),d1 movel d1,a5@(24) movel d1,a5@(20) movel d1,a5@(16) movel d1,a5@(12) movel d1,a5@(8) movel d0,a0 movel a5@(8),a0@+ movel a5@(12),a0@+ movel a5@(16),a0@+ movel a5@(20),a0@+ movel a5@(24),a0@ unlk a5 rts -------- gcc-2.5.8 -O1 #NO_APP gcc2_compiled.: ___gnu_compiled_c: .lcomm LF0,20 .text .even .globl _foo1 _foo1: link a5,#-20 movel a5@(8),a5@(-20) movel a5@(12),a5@(-16) movel a5@(16),a5@(-12) movel a5@(20),a5@(-8) movel a5@(24),a5@(-4) movel a5@(-20),LF0 movel a5@(-16),LF0+4 movel a5@(-12),LF0+8 movel a5@(-8),LF0+12 movel a5@(-4),LF0+16 movel #LF0,d0 unlk a5 rts .even .globl _foo2 _foo2: link a5,#-20 lea a5@(-4),a0 movel a0@,sp@- movel a0@-,sp@- movel a0@-,sp@- movel a0@-,sp@- movel a0@-,sp@- jbsr _foo1 unlk a5 rts .lcomm LF1,20 .even .globl _foo3 _foo3: link a5,#-20 movel a5@(8),d0 movel d0,a5@(-4) movel d0,a5@(-8) movel d0,a5@(-12) movel d0,a5@(-16) movel d0,a5@(-20) movel d0,LF1 movel a5@(-16),LF1+4 movel a5@(-12),LF1+8 movel a5@(-8),LF1+12 movel a5@(-4),LF1+16 movel #LF1,d0 unlk a5 rts .lcomm LF2,20 .even .globl _foo4 _foo4: link a5,#0 movel a5@(28),d0 movel d0,a5@(24) movel d0,a5@(20) movel d0,a5@(16) movel d0,a5@(12) movel d0,a5@(8) movel d0,LF2 movel a5@(12),LF2+4 movel a5@(16),LF2+8 movel a5@(20),LF2+12 movel a5@(24),LF2+16 movel #LF2,d0 unlk a5 rts -------- gcc-2.6.3 -O1 #NO_APP gcc2_compiled.: ___gnu_compiled_c: .lcomm LF0,20 .text .even .globl _foo1 _foo1: link a5,#-20 movel a5@(8),a5@(-20) movel a5@(12),a5@(-16) movel a5@(16),a5@(-12) movel a5@(20),a5@(-8) movel a5@(24),a5@(-4) movel a5@(-20),LF0 movel a5@(-16),LF0+4 movel a5@(-12),LF0+8 movel a5@(-8),LF0+12 movel a5@(-4),LF0+16 movel #LF0,d0 unlk a5 rts .even .globl _foo2 _foo2: link a5,#-20 lea a5@(-4),a0 movel a0@,sp@- movel a0@-,sp@- movel a0@-,sp@- movel a0@-,sp@- movel a0@(-4),sp@- jbsr _foo1 unlk a5 rts .lcomm LF1,20 .even .globl _foo3 _foo3: link a5,#-20 movel a5@(8),d0 movel d0,a5@(-4) movel d0,a5@(-8) movel d0,a5@(-12) movel d0,a5@(-16) movel d0,a5@(-20) movel d0,LF1 movel a5@(-16),LF1+4 movel a5@(-12),LF1+8 movel a5@(-8),LF1+12 movel a5@(-4),LF1+16 movel #LF1,d0 unlk a5 rts .lcomm LF2,20 .even .globl _foo4 _foo4: link a5,#0 movel a5@(28),d0 movel d0,a5@(24) movel d0,a5@(20) movel d0,a5@(16) movel d0,a5@(12) movel d0,a5@(8) movel d0,LF2 movel a5@(12),LF2+4 movel a5@(16),LF2+8 movel a5@(20),LF2+12 movel a5@(24),LF2+16 movel #LF2,d0 unlk a5 rts -------- It appears that at least gcc-2.5.8 and gcc-2.6.3 use the non-reentrant static buffer struct return convention, whereas former versions used the same convention that other m68k compilers use (like m68k Suns). Almost needless to say, where we are trying to build shared libraries and reentrant programs, the static buffer passing convention makes no sense. It would be very nice if newer versions of GCC would return to the old but much more sensible GCC-1.x and -2.3.3 behaviour. BTW, one wonders why GCC>=2.5.8 make so stupid use of the LF* addresses. They don't even put them into a register. NB: This has nothing to do with the -fpcc-struct-return or -freg-struct-return switches, as they only tell gcc what to do with very short structures (those that may fit in a register). It would be very nice if at some not too distant point in the future, I was able to drop GCC 1.40, and 2.3.3 to the bit bucket and use only a new GCC. The current situation with lots of different as/ld/gcc and ixemul.library is extremely annoying. I hope that disconvering these incompatibilites which I believe result from past bad configurations will take us nearer to that point. I know that a few people may be reluctant to switch the struct passing convention, claiming that ixemul.library contains a few struct passing calls. I'd just say that as nobody seemed to notice the bad switch somewhere between 2.3.3 and 2.5.8 and the impact on ixemul.libraries built with one of these compilers, it doesn't look like it would do much harm. IMHO, passing structs using a static buffer is a big configuration mistake and potentially dangerous with reentrant programs or shared libraries. Regards, Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Apr 13 15:25:01 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <3391-2>; Thu, 13 Apr 1995 15:19:48 +0300 Received: by colombo.telesys-innov.fr; Thu, 13 Apr 1995 14:18:56 +0100 From: Philippe BRAND Message-Id: <199504131318.OAA00616@colombo.telesys-innov.fr> Subject: Re: Shared executables for Amiga GNU ports To: isthesin@TechFak.Uni-Bielefeld.DE Date: Thu, 13 Apr 1995 14:18:54 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9504130935.AA12320@moos.techfak.uni-bielefeld.de> from "isthesin@TechFak.Uni-Bielefeld.DE" at Apr 13, 95 11:35:20 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 876 isthesin@TechFak.Uni-Bielefeld.DE writes: > I agree with you here. How's about stealing the one good idea that > Microsoft has had: Dynamic Link Libraries. This would mean the C code would Ahem... I really don't think that MickeySoft has invented this one... > Still, we need -fbaserel support.....PHILIPPE ???????????????????????? How about it ? Any progress? Well I'm still busy trying to compile latest snapshots.... We would perhaps need another guy to work on this one... who's time to gigure out exactly where is the problem, compiling small examples with 2.3.3 and 2.6.3. Should be somewhat easy to track but one need time... and time, as for now, is really difficult for me to find. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Apr 13 16:58:47 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <957-4>; Thu, 13 Apr 1995 16:56:59 +0300 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA24876; Thu, 13 Apr 1995 15:56:32 +0200 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA12749; Thu, 13 Apr 95 15:56:31 +0200 Date: Thu, 13 Apr 95 15:56:31 +0200 From: isthesin@TechFak.Uni-Bielefeld.DE Message-Id: <9504131356.AA12749@moos.techfak.uni-bielefeld.de> To: dev@flevel.demon.co.uk Subject: Re: Shared executables for Amiga GNU ports Cc: amiga-gcc-port@lists.funet.fi >From: dev@flevel.demon.co.uk > [...] >> >> I agree with you here. How's about stealing the one good idea that >> Microsoft has had: Dynamic Link Libraries. This would mean the C code would >> remain the same and the linker could (Optionally) make any of the link >> library calls into DLL's. The linker could then insert the correct startup >> code to link the DLL's. ixemu library could then control loading and flushing >> out DLL's as needed. >> [...] >No, I don't think so. I think this is how it works:- > >a) The linker takes each library call and inserts a jsr/bsr to a jump table > at the end of the program. > >b) The jump table is left blank but a note is made in a different segment > of the executable as to which library and call each jmp refers to. > >c) When the program is loaded into memory the op-sys scans the list of > DLL's the program requires. Any DLL that is not in memory is loaded. > Next each jmp in the table is pointed to the correct routine in the > DLL. > >d) The program runs. > >e) When the program quits a note is made that it is no longer using the DLL > so it can be flushed. > > >In the case of the Amiga the startup code would have to fill in the DLL >jump table using ixemul.library. > >The DLL could be a standard Amiga executable with the symbols left in. >ixemul.library could LoadSeg the DLL and keep a copy of the symbol table. >When a DLL JUMP Table is to be filled in the relevant symbol table for the >requested library could be scanned and therefore the routines addresses >can be filled in. Yep, I suppose it is possible to do it this way. Here is what I think about it: - program can be compiled as usual up to linking stage. - Introduce new linker option -shared (or -dynamic, or...) - Linker samples all references to linker symbols (code and data) in some place of the executable (format of this info follows..) - Linking is performed with a new startup code (maybe dcrt0.o :-) - When program runs, ixemul is called to perform the startup inits: o ixemul scans list of required run time libs and loads them, if not in memory, here a new data segment is allocated for each library. o all references are patched with the (now known) addresses in memory. This does not require -fbaserel to work, but rather a modified linker and support for this in ixemul library, together with a conversion program to convert link libs to these run time libs, as mentioned above. The disadvantage is that we can not compile programs with -fbaserel and therefore can NOT produce residentable programs. But since the size of the programs is drastically reduced by the method, there are only rather small base programs left and the need for resident programs is not that large anymore. E.g. for a program like 'objdump' from binutils 2.5.2 the size now is about 200k (I think) By using dynamic linkage, the base program reduces to about 20-30k (If I recall it right that is). The format of the above mentioned symbol reference is merely a HUNK_EXT hunk: +-----------------+ \ | LLEN | Size of library name in long words \ +-----------------+ \ | LIBNAME | LLEN long words of library name \ +-----------------+ \ | SLEN | Size of symbol name in long words \ \ +-----------------+ \ \ | SYMNAME | SLEN long words of symbol name \ => may be repeated +-----------------+ =>may be repeated / | RNUM | Number of references to this symbol / / +-----------------+ / / | REFS | RNUM addresses of symbol references / / +-----------------+ / | 0L | End of symbol blocks / +-----------------+ | 0L | End of lib blocks +-----------------+ NB: The addresses (REFS) in the above table are generated by the AMIGA loader, when the executable is loaded into memory. In the executable file, they are offsets relative to the resepctive hunks. But since we do need the addresses of the offsets anyway, we can let the loader do the work. Now, the startup code in ixemul has to search each lib, open it, and create a new data segment thereby. Then it has to search for the symbols in the lib, calculate the addresses (for symbols, referencing the data segment) and fill them in in the executable image by adding the symbol address to the contents of the location, referenced by an address from REFS. Voila, everything done. Next issue: Can we translate link libs automagically [:-)] into run time libs? They have to keep the symbol information somewhere and must be able to allocate a new data segment for every opener. Bye... Stephan From amiga-gcc-port-owner@nic.funet.fi Thu Apr 13 22:37:16 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <1012-3>; Thu, 13 Apr 1995 22:33:03 +0300 Received: from lysita.lysator.liu.se (lysita.lysator.liu.se [130.236.254.153]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id VAA01480; Thu, 13 Apr 1995 21:32:46 +0200 From: Niels M|ller Received: (nisse@localhost) by lysita.lysator.liu.se (8.6.11/8.6.11) id VAA27201; Thu, 13 Apr 1995 21:32:41 +0200 Date: Thu, 13 Apr 1995 21:32:41 +0200 Message-Id: <199504131932.VAA27201@lysita.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: isthesin@TechFak.Uni-Bielefeld.DE CC: dev@flevel.demon.co.uk, amiga-gcc-port@nic.funet.fi In-reply-to: <9504131356.AA12749@moos.techfak.uni-bielefeld.de> (isthesin@TechFak.Uni-Bielefeld.DE) Subject: Re: Shared executables for Amiga GNU ports As I have understood it, the *tricky* part of dynamic linking is to resolve references from the library to symbols in the executable. For example, a shared clib may reference symbols like _stdout, which are part of the executable program's data space, and are different for each program that is linked with the library. I don't know how this is solved under UNIX, one might guess that some MMU magic is involved. I think that dynamic linking consists of several parts: The main shared dynamic library (libm.so, for example), a smallstatically linked library (libm.sa), and special startup code. As far as I can see, the easiest way is to have the static part of the library hold a table of pointers to all symbols that the library needs. This table is "filled in" during linking with the static part. Variables defined as "globals" in the library are also placed in this structure. Then the address of this table is passed as an extra parameter with each call to the library, which uses the pointer to find all variables it need, both its own and those defined in the program being linked. Now there are two questions. First, how to implement this under AmigaOS, and second, how to create and handle shared libraries *conveniently*. Ideally, the difference between creating a shared or a static library should be just a compiler flag. One implementation idea: Let the code of the library be handle as a standard amiga library, with one extra convention: When calling the library, not only should the library base be passed in a6, also a data pointer should be passed, say in a5. By this pointer, the library can find all globals it need (here "globals" are global to one program, variables that are global to *all* users of the library should be placed in the normal library structure). With this approach, using a shared library should be straight forward, a little more complicated than using standard amiga libs, but not much. The question remains how to create a shared lib. If the library source code be independent of how it is to be linked, the compiler must create extra indirection via the data pointer for accesses to symbols that are "external" to the library, and then build a structure holding pointers to all externals (for the static part of the linking) and all variables the library defines itself. (Probably *only* variables that are used by the library startup code should be placed in the standard library structure). This may be difficult, I don't know enough of gcc to tell. Also, I have no idea of how to handle the situation that two shared libs reference eachother's global variables. I think this approch may be useful, even if for some time the structures have to be created by hand. To create a shared library, you need the library code, referencing variables through the data pointer (a5), a static library holding the library's globals together with pointers to externals, startup code for the .library file, and at last, just as with ordinary amiga libraries, inline headers/stubs and a library similar to libauto for opening the library. Anyone with more insight into unix-style shared libs that can tell us how dynamic linking is done under unix? Regards, Niels From amiga-gcc-port-owner@nic.funet.fi Fri Apr 14 00:20:11 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <3098-1>; Fri, 14 Apr 1995 00:19:02 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0rzWFO-000FjpC; Thu, 13 Apr 95 23:16 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <06z1@wyst.hobby.nl>; Thu, 13 Apr 95 23:15:07 CET Message-Id: <9504132215.06z1@wyst.hobby.nl> Date: Thu, 13 Apr 1995 23:15:05 +0000 (CET) Content-Type: text Content-Length: 7731 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Subject: Shared executables using dld-3.2.6 I have just uploaded dld-3.2.6.lha to nic.funet.fi. It should appear in pub/amiga/gnu/beta as I do not consider it to be finished before I know what you all think of this port. Given the current discussion on shared libraries this port is rather appropriate, I think. The readme.amiga that I have included in that distribution follows: ---------------------------------------------------------------------- A few notes on this Amiga port of dld-3.2.6, the GNU dynamic link editor. The original archive is available (among other places) from prep.ai.mit.edu in pub/gnu/jacal/dld-3.2.6.tar.gz. It is the successor of dld-3.2.3.tar.gz in the directory pub/gnu. It fixes at least one bug and adds c++ support, so that's why I choose this one to work from. When I started looking at dld I didn't expect that it could work at all on the Amiga, let alone with a relatively minor porting effort. However, I was able to compile the dld-library in one go, so the code itself was clean. After reading through the code I saw that the dld_init function reads the symbols of the variables in the executable and their values in a list. Other functions do the same thing for objects and *.a archives. The format used by GCC for objects and archives is currently identical to the BSD format, which was also used in dld. So, that part worked OK. The executable, however, uses hunks to store the symbols, so all I had to do was to add a function that would scan the executable for the symbols and figure out their real values. After implementing that, I suddenly had a working version of dld. Most of the tests ran without a problem (except for one or two weird ones that depend on a UNIX process environment). The implementation of the symbol hunk scan was done in two stages: the first stage was to make a program to list all the symbols, the second stage patched that into dld. The scanning program is useful in its own right, so I included it in this archive (showsyms.c). I also changed the file reads and seeks to their buffered counterparts (fread, fseek) improving the performance. Now, this is all very nice, but it doesn't make it possible to use it as you would use a shared library. After all, you have to do a dld_init, get all the values of the functions you want to call using dld_get_symbol, etc. However, with a bit of thought I was able to put it to that use. The idea is to realize that for every program you do know one entry point: main. So I made a wrapper program, which initializes dld, forces it to link with the real program, using 'main' as a reference (more about that later), specifying the libraries to use for resolving all externals, and then it asks for the address of the main function of the program you want to call, dld finds at for you, resolving all externals and loading all the code and data stuff in the process. Then you call that function. So you need this wrapper program to start up the real program. The 'real' program cannot be a executable, as the normal linker would then try to resolve all externals, which is precisely what you do not want. Instead, the program is either a single object or a group of objects. In the last case you must pull them together into one *.a archive. Don't forget to 'ranlib' this! Unfortunately, the main function of your program must be redefined to dld_main. Either by changing the program or passing -Dmain=dld_main to the compiler. The reason for this is 1) the compiler apparently does something special for main functions (I encountered a reference to a __main function right after the start of main) and 2) dld_get_symbol("main") would return the address of the main function of the wrapper executable and not the one from your own program. While compiling wrap.c (the wrapper program) you can add a define -DADDLIBS="lib1;lib2;...". This define is a semi-colon separated list of libraries that should be passed to dld for dynamic linking. The default value is "/gnu/lib/libgcc.a;/gnu/lib/libc.a". Only one thing left to do: how to incorporate your own program into the wrapper program. One possibility was to just let wrap link your own program from a separate file (e.g. if your wrapper was called 'find' it would try to dynamically link a file 'find.o' or 'find.a' from the same place). But it much better and elegant to somehow add it into the wrapper so that there is only one file. I have decided to misuse the debughunk for that. The debughunk is never loaded into memory (which is what you want, as dld_link reads from file anyway) and when scanning through the hunks for the symbol definitions during the dld_init, the dld library can remember the offset and size of the debughunk on the fly. IF the debughunk starts with the magic cookie for a BSD object or archive, THEN it knows where to link in the object/archive. I wrote a small utility to put the object or archive into the debughunk of the wrapper executable. The source is ar2hunk.c. One small point remains: the dld linker needs the filename of the object/archive to link. It does not do to specify the name of the executable, as that is already used up by the dld_init. The filename was stored by dld so that it thinks that it already loaded that file. So I introduced a small hack into dld: if the filename passed to dld_link ends with ASCII code 1 (0x01 hex) it knows that it should read the debughunk from the file with the given filename but without the trailing 0x01 code. It's dirty, but for a first version it works very well. As a practical example, I ported the GNU find utility using this scheme. All stays the same, except for giving -Dmain=dld_main to GCC. The link step is a bit more complex: first compile the wrapper with the right setting for ADDLIBS. In this case, one would copy libfind.a to gnu:lib and specify: gcc -O -o find wrap.c \ -DADDLIBS="/gnu/lib/libfind.a;/gnu/lib/libgcc.a;/gnu/lib/libc.a". Next do: ar q f.a *.o ranlib f.a ar2hunk find f.a And that does the trick. Except for the fact that the resulting find executable is actually bigger than it would have been without using this shared library mechanism, as all the symbol information takes up space too, and the dld library must be statically linked into the wrapper executable, with takes another 15-20 Kb. Now, before officially sending the diffs to Fred Fish, I'd like to have your thoughts on this port. Personally, I have problems with: 1) The use of a debughunk for the objects/archive. However, I was unable to find another way of storing the object/archive in the wrapper exe without it being loaded into memory. I know there is a way to do this in Kickstart 3.0, but I don't have that, and I don't consider that as a reasonable option. 2) Too many symbols are stored in the wrapper executable. Is there a way to filter them out? Is there another way of reducing the number of symbols used? Especially when your program is a collection of objects, you'd like to be able to 'prelink' these objects, leaving only the real externals. 3) Does this library work with the new 2.5.2 binary utilities that are currently being ported/tested? 4) It should be possible to implement a scheme where the code hunks are loaded only once, and they can then be used by others too. Of course, this is only possible if the code concerned is reentrant. But it's possible to check for that. Please let me know what you all think of this. Enjoy! Hans Verkuil April 13, 1995 -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Apr 14 17:53:58 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <142-2>; Fri, 14 Apr 1995 17:52:10 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA00809 (5.65c-6/7.3w-FAU); Fri, 14 Apr 1995 16:51:56 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA11694 (5.x/7.3w-FAU); Fri, 14 Apr 1995 16:51:55 +0200 From: Tobias Ruland Message-Id: <9504141451.AA11694@immd8.informatik.uni-erlangen.de> Date: Fri, 14 Apr 1995 16:51:51 +0200 To: amiga-gcc-port@lists.funet.fi Subject: PLS HELP (Solaris) high freaks sorry that i'm off-topic but i know that some of you are working under solaris and i'm full of hope to get some help... :-) what wrong with this simple program? it does not create my thread... any ideas? c u tobias p.s. i tried flags:"THE_NEW_LWP", too, but it didnt work... ---------------- CUT HERE ---------------- #include #include #include #ifndef NULL #define NULL 0L #endif void *test(void *a) { unsigned long int i; double s; for(i=0;i<100000;i++) s=768.543; thr_exit(NULL); return NULL; } int main() { int z=thr_create(0,0,test,0,0,0); if(z) cout << "Error (thr_create-test): " << strerror(z) << "\n"; else cout << "test created\n"; return 0; } ---------------- CUT HERE ---------------- From amiga-gcc-port-owner@nic.funet.fi Fri Apr 14 23:56:35 1995 Received: from unixg.ubc.ca ([137.82.27.14]) by nic.funet.fi with SMTP id <3436-2>; Fri, 14 Apr 1995 23:53:30 +0300 Received: from interchg.ubc.ca by unixg.ubc.ca (8.6.10/1.14) id NAA15024; Fri, 14 Apr 1995 13:53:05 -0700 Date: Fri, 14 Apr 1995 13:53:03 -0700 (PDT) From: Warren Van Winckel X-Sender: warrenvw@interchg.ubc.ca To: amiga-gcc-port@nic.funet.fi Subject: Header Files In-Reply-To: <9504141451.AA11694@immd8.informatik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello everyone. I would like to know what is going wrong with a very simple program. It actually has nothing to do directly with the program, but more to do with missing files. I am wondering why I didn't get these files in the GCC-2.6.3 distribution. If anyone can direct my attention to where I can find these, and perhaps a C++ Manual/Tutorial (on disk), that would be great... ------------------------- In file included from /gnu/include/inline/intuition.h:5, from send.cc:10: /gnu/include/inline/stubs.h:8: exec/lists.h: No such file or directory In file included from /gnu/include/inline/intuition.h:5, from send.cc:10: /gnu/include/inline/stubs.h:14: intuition/classes.h: No such file or directory /gnu/include/inline/stubs.h:17: graphics/displayinfo.h: No such file or directory ------------------------- I have a feeling that I am missing a few others. If I am missing a whole .lha file, that would explain a few things... The funny thing was I believe I downloaded all I was required to download! .................... warrenvw@unixg.ubc.ca .... \/\/\/\/\/ ...... From amiga-gcc-port-owner@nic.funet.fi Sat Apr 15 07:35:54 1995 Received: from clinet.fi ([193.64.6.1]) by nic.funet.fi with SMTP id <3632-2>; Sat, 15 Apr 1995 07:34:30 +0300 Received: from zetor.clinet.fi (root@zetor.clinet.fi [193.64.6.8]) by clinet.fi (8.6.10/8.6.4) with ESMTP id HAA17868; Sat, 15 Apr 1995 07:34:24 +0300 Received: (will@localhost) by zetor.clinet.fi (8.6.10/8.6.4) id HAA22145; Sat, 15 Apr 1995 07:34:25 +0300 Date: Sat, 15 Apr 1995 07:34:24 +0300 (EET DST) From: Ville-Pertti Keinonen To: zrawi01@decap2.zdv.uni-tuebingen.de cc: amiga-gcc-port@nic.funet.fi Subject: Re: New GCC installer script In-Reply-To: <9504120944.AA28321@decap2.zdv.uni-tuebingen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > - can make gcc to use the Commodore OS headers without copying > them to GNU:os-include There are other ways - I use symlinks (to the subdirectories) to share includes between compilers. (Which is a much more unix-like solution than copying or the assign) From amiga-gcc-port-owner@nic.funet.fi Sat Apr 15 19:42:03 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <3803-1>; Sat, 15 Apr 1995 19:40:27 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0s0ArJ-000FbAC; Sat, 15 Apr 95 18:38 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <06zy@wyst.hobby.nl>; Sat, 15 Apr 95 18:29:56 CET Message-Id: <9504151729.06zy@wyst.hobby.nl> Date: Sat, 15 Apr 1995 18:29:54 +0000 (CET) Content-Type: text Content-Length: 702 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Subject: How to create a pty? Hello, I've been trying to port Expect, but Expect creates a pty/tty pair. As far as I understand it, this makes Expect function as the terminal from the point of view of the spawned application. A kind of two-way pipe. The question is, how do I setup such a construction? Normal pipes are to my knowledge one-way only, and cannot be used for that reason. Any help and ideas are welcome! Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Apr 18 18:40:51 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <4855-2>; Tue, 18 Apr 1995 15:37:02 +0300 Received: from indi1.u-strasbg.fr (indi1 [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id OAA06747 for ; Tue, 18 Apr 1995 14:35:34 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA29921; Tue, 18 Apr 95 14:06:50 GMT Date: Tue, 18 Apr 95 14:06:50 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9504181406.AA29921@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: CLOCKS_PER_SEC, where ??? Hi, I want to port a raytracing which use clock() and CLOCKS_PER_SEC. It's works well, on SGI Irix system (with gcc), but with gcc on Amiga, it doesn't know CLOCKS_PER_SEC :-( My question is: Can I use clock() with gcc on Amiga, but in a portable way (i.e use the same source for several system) ??? If not, how can I do the same thing with another portable C function ??? -------- I'm doing something like that: main() { clock_t start,end; start = clock(); /*** some calculation ***/ end = clock(); /*** seconds = (end - start) / CLOCKS_PER_SEC ***/ } \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier | Etudiant en Doctorat | Centre de Recherche en Informatique E-Mail: | Universite Louis Pasteur papier@dpt-info.u-strasbg.fr | Strasbourg - FRANCE ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Tue Apr 18 18:48:48 1995 Received: from www.utbm.fr ([193.48.246.2]) by nic.funet.fi with ESMTP id <2630-1>; Tue, 18 Apr 1995 18:22:54 +0300 Received: from (news@localhost) by www.utbm.fr (8.6.10/jtpda-5.1) id RAA14254 for ; Tue, 18 Apr 1995 17:23:10 +0100 From: Rene.Garcia@utbm.fr Received: from sunserv.ipse.fr(193.48.202.1) by www.utbm.fr via smap (V1.3) id sma014252; Tue Apr 18 17:23:10 1995 Received: by sunserv.ipse.fr (5.x/SMI-SVR4) id AA14811; Tue, 18 Apr 1995 17:22:13 +0100 Date: Tue, 18 Apr 1995 17:22:13 +0100 Message-Id: <9504181622.AA14811@sunserv.ipse.fr> To: amiga-gcc-port@nic.funet.fi Subject: C++ exception handling X-Sun-Charset: US-ASCII Does anyone know about a C++ compiler (or frontal) that can handle the C++ exceptions (try, catch and throw instructions). I guess that GCC does not support them in version 6.3.2. If someone can tell me if it will be implemented in a further release I would be grateful. ANSI defined the exception handler syntax more than 2 years ago but I still haven't found any C++ compiler with this feature. Thanks in advance, RGC From amiga-gcc-port-owner@nic.funet.fi Tue Apr 18 19:02:46 1995 Received: from zaz.kom.auc.dk ([130.225.51.10]) by nic.funet.fi with SMTP id <2349-2>; Tue, 18 Apr 1995 09:35:35 +0300 Received: from skoda.kom.auc.dk by zaz.kom.auc.dk with smtp (Smail3.1.29.1 #3) id m0s16sY-000DIVC; Tue, 18 Apr 95 08:35 MET DST Received: by skoda.kom.auc.dk (Smail3.1.29.1 #3) id m0s16sX-0008JrC; Tue, 18 Apr 95 08:35 MET DST Message-Id: Date: Tue, 18 Apr 95 08:35 MET DST From: jds@kom.auc.dk (Jes Degn Soerensen) To: Tobias Ruland Cc: amiga-gcc-port@lists.funet.fi Subject: PLS HELP (Solaris) In-Reply-To: <9504141451.AA11694@immd8.informatik.uni-erlangen.de> References: <9504141451.AA11694@immd8.informatik.uni-erlangen.de> Tobias Ruland writes: > high freaks > > sorry that i'm off-topic but i know that some of you > are working under solaris and i'm full of hope to get some > help... :-) > > what wrong with this simple program? it does not create my thread... Maybe it does and maybe it doesn't I cannot say for sure, but you'll have to wait for the thread to exit in your main-program. Otherwise the exit in your main-program will kill your thread before it gets started. Second, you should probably do some initializing of the thread system before you start creating threads. I think I have some examples somewhere, send me an email if you wan't them. Last but probably the most important part: thr_create returns != NULL if it is successfull and NULL if its unsuccesfull, you check the other way round. A little quite from the man-page of thr_create: When new_thread is not NULL then it points to a location where the ID of the new thread is stored if thr_create() is successful. The ID is only valid within the calling pro- cess. Regards Jes > ---------------- CUT HERE ---------------- > #include > #include > #include > > #ifndef NULL > #define NULL 0L > #endif > > void *test(void *a) > { unsigned long int i; > double s; > for(i=0;i<100000;i++) s=768.543; > thr_exit(NULL); > return NULL; > } > > int main() > { int z=thr_create(0,0,test,0,0,0); > if(z) try if (z == NULL) > cout << "Error (thr_create-test): " << strerror(z) << "\n"; > else > cout << "test created\n"; > > return 0; > } > ---------------- CUT HERE ---------------- From amiga-gcc-port-owner@nic.funet.fi Tue Apr 18 19:03:47 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <2190-1>; Tue, 18 Apr 1995 18:43:36 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA06838; Tue, 18 Apr 1995 17:37:15 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9504181537.AA06838@decap2.zdv.uni-tuebingen.de> Subject: Re: New GCC installer script To: amiga-gcc-port@nic.funet.fi Date: Tue, 18 Apr 1995 17:37:15 +0200 (MET DST) In-Reply-To: from "Ville-Pertti Keinonen" at Apr 15, 95 07:34:24 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1601 Hello, > > - can make gcc to use the Commodore OS headers without copying > > them to GNU:os-include > > There are other ways - I use symlinks (to the subdirectories) to share > includes between compilers. (Which is a much more unix-like solution than > copying or the assign) Hard links won't work in any case, at least not, if the header directory is on another partition. And from my experience I discourage using soft links: Sooner or later you *will* get problems. (Typical example: Do a "rm -rf GNU:". Be prepared, that flex is deleted before flex++ ... In my opinion an installation script should choose a safe method. Btw, I modified the specs file as below: *predefines: -I/GNUINCLUDE -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA Result is 6> gcc -v hello.c -o hello Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Dmc68010 hello.c t:cc037528.i GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. hello.c:4: intuition/intuition.h: No such file or directory Any ideas what's wrong? Jochen From amiga-gcc-port-owner@nic.funet.fi Tue Apr 18 21:51:40 1995 Received: from clinet.fi ([193.64.6.1]) by nic.funet.fi with SMTP id <2067-4>; Tue, 18 Apr 1995 21:46:19 +0300 Received: from zetor.clinet.fi (root@zetor.clinet.fi [193.64.6.8]) by clinet.fi (8.6.10/8.6.4) with ESMTP id VAA16979; Tue, 18 Apr 1995 21:46:02 +0300 Received: (will@localhost) by zetor.clinet.fi (8.6.10/8.6.4) id VAA14633; Tue, 18 Apr 1995 21:46:02 +0300 Date: Tue, 18 Apr 1995 21:45:59 +0300 (EET DST) From: Ville-Pertti Keinonen To: Jochen Wiedmann cc: amiga-gcc-port@nic.funet.fi Subject: Re: New GCC installer script In-Reply-To: <9504181537.AA06838@decap2.zdv.uni-tuebingen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Hard links won't work in any case, at least not, if the header > directory is on another partition. And from my experience I discourage > using soft links: Sooner or later you *will* get problems. (Typical > example: Do a "rm -rf GNU:". Be prepared, that flex is deleted before > flex++ ... With soft links, it doesn't matter if the file gets deleted before the link, problems only occur if you use hard links (which are implemented rather poorly in the Amiga FFS). On unix filesystems, both kinds of links work fine, but hard links are usually not supported for directories (except "." and "..", of course). From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 01:44:54 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <2136-1>; Wed, 19 Apr 1995 01:43:39 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 00:44:10 +0100 From: Philippe BRAND Message-Id: <199504182344.AAA15494@colombo.telesys-innov.fr> Subject: New beta on its way To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Wed, 19 Apr 1995 00:44:09 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1399 I will put tomorrow morning a new gcc 2.6.4 beta. After looking around in my todo list I've found a neat feature from Kriton Kyrimis, the stack checking routine. I've included it into gcc itself, with a new compil flag: -stackcheck. Both beta and associated diff file will be available on my site, along with complete source code for gcc-current (at last :-) But *rt0.o have to be modified... Could ixemul mainteners and libnix add those few lines just before call to real main ? unsigned long _StackBottom; static unsigned long _StackOrig; [...] __main() { register unsigned long sp asm("sp"); ... _StackBottom = (unsigned long)FindTask(0L)->tc_SPLower + 128; _StackOrig = sp; _main(); ... } void _StackOverflow(void) { register unsignd long sp asm("sp"); sp = _StackOrig; Printf("StackOverflow\n"); exit(RETURN_FAIL); } Maybe inclusion into existing *rt0.c files is ok, or why not create special .c files for stack handling... In this case I'll have to change link specs. PS: Sorry Kriton, just found your 10-Feb-95 email :-) PS2: no, his gcc beta was not compiled with -stackcheck, I have first to get those *rt0.o files and I don't have time now to look into both ixemul & libnix sources... -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 09:50:35 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <2238-2>; Wed, 19 Apr 1995 09:42:29 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HPIOIMBUO08WWSTI@LEON.CTI.GR>; Wed, 19 Apr 1995 09:40:45 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA19925; Wed, 19 Apr 95 09:44:12 +0300 Date: Wed, 19 Apr 1995 09:44:11 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: New beta on its way In-reply-to: <199504182344.AAA15494@colombo.telesys-innov.fr> from "Philippe BRAND" at Apr 19, 95 00:44:09 am To: phb@colombo.telesys-innov.fr (Philippe BRAND) Cc: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9504190644.AA19925@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 691 > _StackBottom = (unsigned long)FindTask(0L)->tc_SPLower + 128; > _StackOrig = sp; There was a long discussion in the list following my posting, which resulted in a more complex (but more fire-proof) method of getting the stack bounds. If you don't have the final version around, let me know and I'll send you a copy. On the other hand, I would revommend adding to gcc the changes proposed by Matthias Fleischer that add stack checking and stack extension to gcc, using the -mstackcheck and -mstackext options. Matthias has provided libnix support for these features along with the diffs to gcc. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 10:15:47 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <2492-2>; Wed, 19 Apr 1995 10:13:51 +0300 Received: from indi1.u-strasbg.fr (indi1 [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id JAA14708 for ; Wed, 19 Apr 1995 09:12:34 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA04528; Wed, 19 Apr 95 08:42:05 GMT Date: Wed, 19 Apr 95 08:42:05 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9504190842.AA04528@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: ar and make trouble I try to install gcc 2.6.3 from aminet. gcc works fine, but make gives me guru and ar random error (like bus error, floating point exception ...) :-( I have installed gcc263-base, gcc263-inclib and gcc263-c-020. I have a 68030 and a 68882. Could someone help me ??? Could it be a (too small) stack trouble ??? \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier | Etudiant en Doctorat | Centre de Recherche en Informatique E-Mail: | Universite Louis Pasteur papier@dpt-info.u-strasbg.fr | Strasbourg - FRANCE ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 11:05:52 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <2081-1>; Wed, 19 Apr 1995 11:04:44 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 10:05:17 +0100 From: Philippe BRAND Message-Id: <199504190905.KAA16470@colombo.telesys-innov.fr> Subject: Re: ar and make trouble To: papier@indi1.u-strasbg.fr (Laurent Papier) Date: Wed, 19 Apr 1995 10:05:16 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9504190842.AA04528@indi1.u-strasbg.fr> from "Laurent Papier" at Apr 19, 95 08:42:05 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 710 Laurent Papier writes: > I try to install gcc 2.6.3 from aminet. gcc works fine, but make gives me > guru and ar random error (like bus error, floating point exception ...) :-( > I have installed gcc263-base, gcc263-inclib and gcc263-c-020. > I have a 68030 and a 68882. > Could someone help me ??? Sorry for english dudes.... Mets une pile au minimum de 50.000. Pour ar, cela depend de la taille de la librairie, mais generalement 250000 semble etre une bonne valeur. C'est pas dans la doc ca ? ;-) (trans: raise your stack). -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 11:08:24 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <2870-3>; Wed, 19 Apr 1995 11:08:08 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 10:07:41 +0100 From: Philippe BRAND Message-Id: <199504190907.KAA16486@colombo.telesys-innov.fr> Subject: Re: New beta on its way To: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Date: Wed, 19 Apr 1995 10:07:40 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9504190644.AA19925@hpcl.cti.gr> from "Kriton Kyrimis" at Apr 19, 95 09:44:11 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1007 Kriton Kyrimis writes: > There was a long discussion in the list following my posting, which resulted > in a more complex (but more fire-proof) method of getting the stack bounds. > If you don't have the final version around, let me know and I'll send you a > copy. Hum... seems that this discussion happened when I was quite asleep, I do think I've missed some points... > On the other hand, I would revommend adding to gcc the changes proposed by > Matthias Fleischer that add stack checking and stack extension to gcc, using > the -mstackcheck and -mstackext options. Matthias has provided libnix > support for these features along with the diffs to gcc. Could someone post them to me ? Well anyway "hard" work was only to add another flag to gcc and pass it to compiler so changing methodology won't take me much time. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 11:11:25 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <2513-2>; Wed, 19 Apr 1995 11:11:04 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 10:11:35 +0100 From: Philippe BRAND Message-Id: <199504190911.KAA16514@colombo.telesys-innov.fr> Subject: Please forward! (fwded) To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Wed, 19 Apr 1995 10:11:34 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4751 Matthias Pruksch writes: > From bb.maus.de!fUe.maus.de!Matthias_Pruksch@eisbaer.bb.bawue.de Wed Apr 19 07:14:22 1995 > Message-Id: > From: Matthias_Pruksch@fUe.maus.de (Matthias Pruksch) > Subject: Please forward! > To: phb@colombo.telesys-innov.fr > Organization: MausNet (Mitglied im IN e.V.) > Date: Mon, 17 Apr 95 15:57:00 GMT > X-Gateway: MausGate/Mail 1.25/bb > MIME-Version: 1.0 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 8bit > > Hello Philippe, > > sorry for this inconvenince, but I am not used to mailinglists and not > allowed to subscribe to one (Maus-Net all msgs <16K!). > > Also, for me it is not clear what address to use, if I want to reach the > list itsself and not the serverprogram! :-( > > Thank you for the installer-script! But it does not handle the assign USR:! > No problem at all, but I suppose you can easily fix that for the next > release. BTW, I am using now gcc-2.6.3. > > Now to something completly strange: > > I do have a little problem with the GNU C++ compiler since version 2.6.0 > versions 2.6.1 and 2.6.3 show the same effect. > > Source code following: > > This is file > x--------------Schnipp-----------------x > /* > FILE : op.hpp > ... > email: > Matthias_Pruksch@fue.maus.de > */ > > #ifndef COFAP_OP_HPP > #define COFAP_OP_HPP > > #include > > /////////////////////////////////// > // Define class > > class Op { > public: > enum op { > NOP, CLR, MOV, > ADD, SUB, MUL, DIV, > NOT, AND, NAND, OR, NOR, XOR, XNOR > } operation; > // Constructor, Destructor > Op(const Op::op Operation=Op::NOP) > { operation = Operation; } > virtual ~Op() {} > // Operators > // Member functions > // I/O-functions > void printOn (ostream& Strm=cout) const; > void scanFrom(istream& Strm=cin); > }; > > > /////////////////////////////////// > // Inline functions > #include > > #endif // COFAP_OP_HPP > > x--------------Schnapp-----------------x > > This is file > x--------------Schnipp-----------------x > > /* > FILE : inline/op.hpp > ... > > email: > Matthias_Pruksch@fue.maus.de > */ > > #ifndef COFAP_INLINE_OP_HPP > #define COFAP_INLINE_OP_HPP > > #include > > /////////////////////////////////// > // Overload functions > inline ostream& operator << (ostream& Strm,const Op Operation) { > Operation.printOn(Strm); > return Strm; > } > > inline istream& operator >> (istream& Strm,Op& Operation) { > Operation.scanFrom(Strm); > return Strm; > } > > > #endif // COFAP_INLINE_OP_HPP > > x--------------Schnapp-----------------x > > > This is file test/ctrl/op.cpp > x--------------Schnipp-----------------x > > /* > FILE : op.cpp > ... > > Email : > Matthias_Pruksch@fue.maus.de > */ > > #include > > int main(void) > { > Op o1=Op::MOV, o2; > > cout << "o1 = Op::MOV : " << o1 << endl; > cout << "o2 = Op::NOP : " << o2 << endl; > if(o2.operation!=Op::NOP) return(10); > > cout << "*** COFAP/ctrl/Op: Test sucessfully passed" << endl << endl; > return(0); > } > > x--------------Schnapp-----------------x > > If I try to compile this source: > -------------------------------- > > Shell output: > > > gcc op.cpp -o op.exe -liostr > In file included from /gnu/lib/g++-include/iostream.h:31, > from /gnu/lib/g++-include/stream.h:31, > from /gnu/include/cofap/ctrl/Op.hpp:44, > from op.cpp:39: > /gnu/lib/g++-include/streambuf.h:219: `ios::operator void *(...)' must take > `void' > /gnu/lib/g++-include/streambuf.h:219: `ios::operator void *(...)' cannot > have default arguments > > -------------------------------- > > The compiler will never come back! The Amiga system doesn't crash. > Using the IBM-PC version of gcc 2.6.0, the same code will compile without > problems and the resulting program will perform as intended. > > So, what is wrong? > > > With kind regards > > Matthias Pruksch > >O< > > > PS: Please contact me straight under: Matthias_Pruksch@fue.maus.de > as I am not allowed to subscribe a mailinglist. All msgs <16K! > -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 12:03:56 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <7275-2>; Wed, 19 Apr 1995 12:02:31 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 11:02:55 +0100 From: Philippe BRAND Message-Id: <199504191002.LAA17291@colombo.telesys-innov.fr> Subject: Re: New beta on its way To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Wed, 19 Apr 1995 11:02:35 +0100 (BST) In-Reply-To: <9504190851.AA07817@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Apr 19, 95 10:51:34 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 448 Sender: phb@colombo.telesys-innov.fr Jochen Wiedmann writes: > would it be possible to add /GNUINCLUDE to the compiler's search path? > That way we could finally fix the problem with the OS headers. ??? Was it discussed on gccport list ? Hum.... I really think I've got here a serious mailer problem... -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 12:18:05 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <10271-2>; Wed, 19 Apr 1995 12:16:46 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 19 Apr 1995 11:16:21 +0200 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA04150; Wed, 19 Apr 95 11:16:27 +0200 Date: Wed, 19 Apr 95 11:16:27 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9504190916.AA04150@inf-wiss.uni-konstanz.de> To: zrawi01@decap2.zdv.uni-tuebingen.de, phb@colombo.telesys-innov.fr Subject: Re: New beta on its way Cc: amiga-gcc-port@lists.funet.fi PhB wrote about GNUINCLUDE: >??? Was it discussed on gccport list ? >Hum.... I really think I've got here a serious mailer problem... I can't remember that there was a general agreement about introducing yet another assign. I can remember myself that there was an agreement long time ago about reducing the number of assigns to only one: GNU: Hmm. Maybe we should tell people how to modify their specs file to set flags for cpp, cc1 or gcc. Maybe that's a bad idea. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 12:19:37 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <10538-1>; Wed, 19 Apr 1995 12:18:49 +0300 Received: by bohr.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr19.121849+0300_eet_dst.10538-1+238@nic.funet.fi> From: To: Date: Wed, 19 Apr 1995 12:18:44 +0300 Date: Wed, 19 Apr 1995 11:20:00 +0200 (METDST) From: Rask Lambertsen To: Jochen Wiedmann Cc: amiga-gcc-port@nic.funet.fi Subject: Re: New GCC installer script In-Reply-To: <9504181537.AA06838@decap2.zdv.uni-tuebingen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 18 Apr 1995, Jochen Wiedmann wrote: > > Hello, > > > > > - can make gcc to use the Commodore OS headers without copying > > > them to GNU:os-include > > > > There are other ways - I use symlinks (to the subdirectories) to share > > includes between compilers. (Which is a much more unix-like solution than > > copying or the assign) > > Hard links won't work in any case, at least not, if the header > directory is on another partition. And from my experience I discourage > using soft links: Sooner or later you *will* get problems. (Typical > example: Do a "rm -rf GNU:". Be prepared, that flex is deleted before > flex++ ... Yes, avoid soft links if you can, they sometimes behave strangely (try deleting a soft link that points to a directory/file that doesn't exist, it's a lot of fun - NOT!). Personally, I use the -I option to make GCC find my OS includes. Works fine. > Btw, I modified the specs file as below: > > *predefines: > -I/GNUINCLUDE -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA ^^^^^^^^^^^^^ This makes CPP look in GNUINCLUDE: for include files, right? Maybe try -I GNUINCLUDE: > Result is > > 6> gcc -v hello.c -o hello > Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs > gcc version 2.6.3 > /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c -v -undef > -D__GNUC__=2 -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados > -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ > -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados > -D__MCH_AMIGA -D__AMIGA -Dmc68010 hello.c t:cc037528.i > GNU CPP version 2.6.3 (68k, MIT syntax) > #include "..." search starts here: > #include <...> search starts here: > /gnu/local/include > /gnu/mc68020-cbm-amigados/include > /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include > /gnu/os-include > /gnu/include > End of search list. > hello.c:4: intuition/intuition.h: No such file or directory > > Any ideas what's wrong? I'm not sure, but I think a missing Assign could cause the problem. Otherwise, typing #include "intuition/intuition.h" instead of #include could cause the problem. I don't know what hello.c looks like, so I can't say if that is the problem. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP3.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 12:22:37 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <10965-4>; Wed, 19 Apr 1995 12:21:54 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 11:21:26 +0100 From: Philippe BRAND Message-Id: <199504191021.LAA17417@colombo.telesys-innov.fr> Subject: Re: /GNUINCLUDE To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Wed, 19 Apr 1995 11:21:26 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9504190918.AA07921@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Apr 19, 95 11:18:19 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 622 Jochen Wiedmann writes: > I asked on the list, whether using /GNUINCLUDE would be a good idea > and all answers were positive. In fact, I tried to add this tothe > installer script. However, modifying the specs file to > > *predefines: > -I/GNUINCUDE -Dmc68000 ... > > doesn't work. Do you have an idea why and how I could fix this? But... why do you want to add /GNUINCLUDE when cpp looks for gnu:include and gnu:os-include ???? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 12:23:41 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <10983-3>; Wed, 19 Apr 1995 12:22:07 +0300 Received: by bohr.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr19.122207+0300_eet_dst.10983-3+205@nic.funet.fi> From: To: Date: Wed, 19 Apr 1995 12:21:59 +0300 Date: Wed, 19 Apr 1995 11:23:30 +0200 (METDST) From: Rask Lambertsen To: Ville-Pertti Keinonen Cc: Jochen Wiedmann , amiga-gcc-port@nic.funet.fi Subject: Re: New GCC installer script In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 18 Apr 1995, Ville-Pertti Keinonen wrote: > > Hard links won't work in any case, at least not, if the header > > directory is on another partition. And from my experience I discourage > > using soft links: Sooner or later you *will* get problems. (Typical > > example: Do a "rm -rf GNU:". Be prepared, that flex is deleted before > > flex++ ... > > With soft links, it doesn't matter if the file gets deleted before the > link, problems only occur if you use hard links (which are implemented > rather poorly in the Amiga FFS). On unix filesystems, both kinds of links It seems to work the other way around for me. I have had trouble deleting a soft link after I deleted the directory it pointed to. Hard links don't seem to have that sort of problems. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP3.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 12:29:54 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <1367-3>; Wed, 19 Apr 1995 12:28:54 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 11:29:16 +0100 From: Philippe BRAND Message-Id: <199504191029.LAA17452@colombo.telesys-innov.fr> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Wed, 19 Apr 1995 11:29:15 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95Apr19.121849+0300_eet_dst.10538-1+238@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Apr 19, 95 12:18:44 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1596 gc948374@gbar.dtu.dk writes: > > > > - can make gcc to use the Commodore OS headers without copying > > > > them to GNU:os-include ? Advantages ? > > > There are other ways - I use symlinks (to the subdirectories) to share > > > copying or the assign) > > > > Hard links won't work in any case, at least not, if the header > > directory is on another partition. And from my experience I discourage > > using soft links: Sooner or later you *will* get problems. (Typical > > example: Do a "rm -rf GNU:". Be prepared, that flex is deleted before > > flex++ ... > > Yes, avoid soft links if you can, they sometimes behave strangely (try > deleting a soft link that points to a directory/file that doesn't exist, > it's a lot of fun - NOT!). Soft links are ok to use PROVIDED you use correct delete..... and not Commodore delete.... which is buggy regarding to link support. I do have a deletelink somebody posted me long time ago which is able to delete pointing-to-nowhere-links... -Iwhatever_directory_you_want must me added to *cpp part of specs file. you can add as many new options you want, so perhaps different include sets. *cpp: %{-usemyheaders:-Idir_I_want}%{m68881:-D__HAVE_68881__ }%{!ansi:%{m68020:-Dmc68020}%{mc68020:-Dmc68020}%{m68030:-Dmc68030}%{mc68030:-Dmc68030}%{m68040:-Dmc68040}%{mc68040:-Dmc68040}%{!mc68020:%{!m68020:%{!mc68030:%{!m68030:%{!mc68040:%{!m68040:-Dmc68010}}}}}}} -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 13:05:50 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <2571-3>; Wed, 19 Apr 1995 13:02:54 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 12:02:29 +0100 From: Philippe BRAND Message-Id: <199504191102.MAA17547@colombo.telesys-innov.fr> Subject: Re: /GNUINCLUDE To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Wed, 19 Apr 1995 12:02:29 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9504190947.AA08019@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Apr 19, 95 11:47:07 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1039 Jochen Wiedmann writes: > Ok, probably we need to discuss how to install the OS headers. The > possible solutions are: Yeah, so don't forget to Cc: to mailing-list... ;-) > 3) copying the headers to /GNU/os-headers: Seems to me to be a waste > of HD space, as most users have more than one compiler installed. > (Look on your own HD, please ... :-) Additionally I think that > OS headers and System headers should really be separated. Ask user if he want to copy them, if not, put a message asking him to manually place them into gnu:os-include and, ig he's using another compiler, change INCLUDE: assign from user-startup (for SAS). > IMO, an installer script should choose a safe and easy method of > installation, so I wouldn't like to choose another method than > 4) or 5). I really think we should have only one assign, e.g. GNU:. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 13:11:44 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <2516-1>; Wed, 19 Apr 1995 13:11:26 +0300 Received: by bohr.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr19.131126+0300_eet_dst.2516-1+239@nic.funet.fi> From: To: Date: Wed, 19 Apr 1995 13:11:25 +0300 Date: Wed, 19 Apr 1995 12:12:52 +0200 (METDST) From: Rask Lambertsen To: Philippe BRAND Cc: Jochen Wiedmann , Amiga-Gcc Liste Subject: Re: /GNUINCLUDE In-Reply-To: <199504191102.MAA17547@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 19 Apr 1995, Philippe BRAND wrote: > Jochen Wiedmann writes: > > > Ok, probably we need to discuss how to install the OS headers. The > > possible solutions are: > > Yeah, so don't forget to Cc: to mailing-list... ;-) > > > 3) copying the headers to /GNU/os-headers: Seems to me to be a waste > > of HD space, as most users have more than one compiler installed. > > (Look on your own HD, please ... :-) Additionally I think that > > OS headers and System headers should really be separated. > > Ask user if he want to copy them, if not, put a message asking him > to manually place them into gnu:os-include and, ig he's using another > compiler, change INCLUDE: assign from user-startup (for SAS). > > > IMO, an installer script should choose a safe and easy method of > > installation, so I wouldn't like to choose another method than > > 4) or 5). > > I really think we should have only one assign, e.g. GNU:. How about 6) Add a line to the specs file so you OS includes are in the search path. This means no copying of the OS include (no waste of harddisk space) and no extra assigns (so file requesters aren't flooded with assigns). And if your existing compiler has the include files places somewhere else, there's no problem. Personally, I have DICE installed too, so this seems to be a good solution. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP3.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 14:13:02 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <2376-1>; Wed, 19 Apr 1995 14:10:30 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA10408; Wed, 19 Apr 1995 13:10:12 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9504191110.AA10408@decap2.zdv.uni-tuebingen.de> Subject: Re: /GNUINCLUDE (fwd) To: amiga-gcc-port@nic.funet.fi Date: Wed, 19 Apr 1995 13:10:11 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1890 Forwarded message: >From zrawi01 Wed Apr 19 11:47:06 1995 Subject: Re: /GNUINCLUDE To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Wed, 19 Apr 1995 11:47:06 +0200 (MET DST) In-Reply-To: <199504191021.LAA17417@colombo.telesys-innov.fr> from "Philippe BRAND" at Apr 19, 95 11:21:26 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1520 Ok, probably we need to discuss how to install the OS headers. The possible solutions are: 1) hard links to /GNU/os-headers: Won't work in any case (if they are installed on a different partition than GNU:) 2) soft links to /GNU/os-headers: I personally reject them, as I had much trouble. (Try removing flex++ which is a link to flex, when flex doesn't exist. This is *not* a problem of Commo Delete: rm won't work, either.) 3) copying the headers to /GNU/os-headers: Seems to me to be a waste of HD space, as most users have more than one compiler installed. (Look on your own HD, please ... :-) Additionally I think that OS headers and System headers should really be separated. 4) Modifying the specs file: Could well be done in the installer script; however, modifying it to look in /GNUINCLUDE seems to me to be better than looking in /Work/MyHeaders/include: That way the user doesn't notice what to change, for example, if he moves the headers to another place. 5) Make gcc look in /GNUINCLUDE >From my experience with other compilers I like an assign GNUINCLUDE: For example, you can well add other directories. (Multiassigns) And it is quite easy. (Note, that only gcc users ask, how to install the OS headers. And quite much of them do. I see 5 or 6 postings a week asking this question.) IMO, an installer script should choose a safe and easy method of installation, so I wouldn't like to choose another method than 4) or 5). Jochen From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 14:28:13 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <2434-3>; Wed, 19 Apr 1995 14:26:47 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HPIYFCNA348WXXO5@LEON.CTI.GR>; Wed, 19 Apr 1995 14:24:23 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA24369; Wed, 19 Apr 95 14:27:55 +0300 Date: Wed, 19 Apr 1995 14:27:54 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: /GNUINCLUDE (fwd) In-reply-to: <9504191110.AA10408@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Apr 19, 95 01:10:11 pm To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Cc: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9504191127.AA24369@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 1655 > Ok, probably we need to discuss how to install the OS headers. The > possible solutions are: > > 1) hard links to /GNU/os-headers: Won't work in any case (if they are > installed on a different partition than GNU:) > 2) soft links to /GNU/os-headers: I personally reject them, as I had > much trouble. (Try removing flex++ which is a link to flex, when > flex doesn't exist. This is *not* a problem of Commo Delete: rm > won't work, either.) > 3) copying the headers to /GNU/os-headers: Seems to me to be a waste > of HD space, as most users have more than one compiler installed. > (Look on your own HD, please ... :-) Additionally I think that > OS headers and System headers should really be separated. > 4) Modifying the specs file: Could well be done in the installer > script; however, modifying it to look in /GNUINCLUDE seems to me > to be better than looking in /Work/MyHeaders/include: That way > the user doesn't notice what to change, for example, if he > moves the headers to another place. > 5) Make gcc look in /GNUINCLUDE 6) Take advantage of the fact that cpp looks at the environment path C_INCLUDE_PATH for additional include directories. E.g., use something like: setenv C_INCLUDE_PATH /GNU/include:/sc/include (C_INCLUDE_PATH is checked before other includes, so if you get your includes from another compiler, e.g., SAS/C, you must specify the GNU directory as well.) For some reason I actually have C_INCLUDE_PATH point to a multi-assign in my amiga. I don't remember why. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 14:35:14 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <2463-4>; Wed, 19 Apr 1995 14:33:54 +0300 Received: by bohr.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr19.143354+0300_eet_dst.2463-4+226@nic.funet.fi> From: To: Date: Wed, 19 Apr 1995 14:33:53 +0300 Date: Wed, 19 Apr 1995 13:35:27 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Cross compilation question Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, If I want to use GCC as a cross compiler, will I need to recompile GCC, or is it enough to use the -m switch? Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP3.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 14:37:12 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <2473-1>; Wed, 19 Apr 1995 14:34:28 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 13:32:19 +0100 From: Philippe BRAND Message-Id: <199504191232.NAA17759@colombo.telesys-innov.fr> Subject: Re: /GNUINCLUDE (fwd) To: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Date: Wed, 19 Apr 1995 13:32:19 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9504191127.AA24369@hpcl.cti.gr> from "Kriton Kyrimis" at Apr 19, 95 02:27:54 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 532 Kriton Kyrimis writes: > (C_INCLUDE_PATH is checked before other includes, so if you get your includes > from another compiler, e.g., SAS/C, you must specify the GNU directory as > well.) Hum.... perhaps that would be corrrect choice... In this case installer script should ask for headers location and automagically set this env... What about this ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 14:38:42 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <1443-1>; Wed, 19 Apr 1995 14:37:10 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 13:37:17 +0100 From: Philippe BRAND Message-Id: <199504191237.NAA17782@colombo.telesys-innov.fr> Subject: Re: /GNUINCLUDE To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Wed, 19 Apr 1995 13:37:17 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9504191117.AA10442@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Apr 19, 95 01:17:00 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 568 Jochen Wiedmann writes: > And how about having different gcc versions installed? gcc frontend has a flag to call different versions so this is not a problem. > We *do* have about 10 assigns. :-) But, if you reject an assign: > How about environment variables GNUINCLUDE or GCCOPTIONS? As far as I > know, this could be integrated into the gcc binary. Well C_INCLUDE_PATH can be use... -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 14:40:13 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <2423-4>; Wed, 19 Apr 1995 14:39:12 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 13:39:28 +0100 From: Philippe BRAND Message-Id: <199504191239.NAA17794@colombo.telesys-innov.fr> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Wed, 19 Apr 1995 13:39:27 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95Apr19.143354+0300_eet_dst.2463-4+226@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Apr 19, 95 02:33:53 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 534 gc948374@gbar.dtu.dk writes: > If I want to use GCC as a cross compiler, will I need to recompile > GCC, or is it enough to use the -m switch? $ gtar xvfz gcc-2.6.3.tar.gz $ cd gcc-2.6.3 $ patch -p1 <../gcc-2.6.3-amiga.diffs $ ./configure --target=amigados $ vi foobar.c __foobar() {} $ gcc -c foobar.c $ ar qc libgcc1.a foobar.o $ rm foobar* $ make -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 14:42:11 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <1297-4>; Wed, 19 Apr 1995 14:40:52 +0300 X-Address: Insignia Solutions Ltd., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA00940; Wed, 19 Apr 1995 12:39:06 +0100 Date: Wed, 19 Apr 1995 12:38:17 +0100 (BST) From: Peter Ivimey-Cook To: Philippe BRAND Cc: Kriton Kyrimis , Amiga-Gcc Liste Subject: Re: /GNUINCLUDE (fwd) In-Reply-To: <199504191232.NAA17759@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 19 Apr 1995, Philippe BRAND wrote: > Kriton Kyrimis writes: > > > (C_INCLUDE_PATH is checked before other includes, so if you get your includes > > from another compiler, e.g., SAS/C, you must specify the GNU directory as > > well.) > > Hum.... perhaps that would be corrrect choice... In this case installer > script should ask for headers location and automagically set this > env... > What about this ? Sounds excellent to me. I was thinking the same thing. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 14:42:57 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <1150-3>; Wed, 19 Apr 1995 14:41:12 +0300 Received: by bohr.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr19.144112+0300_eet_dst.1150-3+214@nic.funet.fi> From: To: Date: Wed, 19 Apr 1995 14:41:12 +0300 Date: Wed, 19 Apr 1995 13:42:45 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: How do I disable calls to the constructor __main? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I am using my own startup code with GCC, but GCC seems to insert a call to __main in the very beginning of main, how to i get rid of that call? Currently, I have to declare static __inline void _main (void) {} to work around it. Is there a better solution? Thanks in advance. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP3.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 14:44:16 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <1528-3>; Wed, 19 Apr 1995 14:42:50 +0300 Received: by bohr.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr19.144250+0300_eet_dst.1528-3+215@nic.funet.fi> From: To: Date: Wed, 19 Apr 1995 14:42:50 +0300 Date: Wed, 19 Apr 1995 13:44:03 +0200 (METDST) From: Rask Lambertsen To: Philippe BRAND Cc: Kriton Kyrimis , Amiga-Gcc Liste Subject: Re: /GNUINCLUDE (fwd) In-Reply-To: <199504191232.NAA17759@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 19 Apr 1995, Philippe BRAND wrote: > Kriton Kyrimis writes: > > > (C_INCLUDE_PATH is checked before other includes, so if you get your includes > > from another compiler, e.g., SAS/C, you must specify the GNU directory as > > well.) > > Hum.... perhaps that would be corrrect choice... In this case installer > script should ask for headers location and automagically set this > env... > What about this ? That is a good idea. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP3.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 14:46:00 1995 Received: from www.utbm.fr ([193.48.246.2]) by nic.funet.fi with ESMTP id <1428-3>; Wed, 19 Apr 1995 14:45:10 +0300 Received: from (news@localhost) by www.utbm.fr (8.6.10/jtpda-5.1) id NAA23994 for ; Wed, 19 Apr 1995 13:45:31 +0100 From: Rene.Garcia@utbm.fr Received: from sunserv.ipse.fr(193.48.202.1) by www.utbm.fr via smap (V1.3) id sma023991; Wed Apr 19 13:45:28 1995 Received: by sunserv.ipse.fr (5.x/SMI-SVR4) id AA28249; Wed, 19 Apr 1995 13:44:33 +0100 Date: Wed, 19 Apr 1995 13:44:33 +0100 Message-Id: <9504191244.AA28249@sunserv.ipse.fr> To: amiga-gcc-port@nic.funet.fi Subject: ADA standard I/O X-Sun-Charset: US-ASCII I know that this is a GCC only mail server but I have a request someone may help me : I'm looking for an ADA package to make I/O with text text stands for dynamic strings of characters with all standard methods (string comparaison, write & read from a text file, and so on...) Thanks Note: if someone heard about an ADA mail_list let me know ;-) From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 22:03:28 1995 Received: from zorn.mnet.medstroms.se ([193.44.236.3]) by nic.funet.fi with SMTP id <4318-4>; Wed, 19 Apr 1995 18:56:12 +0300 Received: from maxinet.medstroms.semaxinet (8.ts2.mnet.medstroms.se [193.44.236.48]) by zorn.mnet.medstroms.se (8.6.10/8.6.6) with SMTP id RAA15896 for ; Wed, 19 Apr 1995 17:55:15 +0200 Received: by maxinet.medstroms.semaxinet (uucp2smtp 0.35 (is@beverly.rhein.de)) Received: by maxinet.medstroms.se (UMS-UUCP/sendmail 0.8); Wed, 19 Apr 95 17:54:28 +0100 To: "amiga-gcc-port" From: "Erik Rissanen" Date: Wed, 19 Apr 95 17:51:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: IntuiNews 1.2b (31.7.94) Subject: how to join asm and gcc? Message-ID: <40063025@maxinet.medstroms.se> I am new to gcc and am not especially experienced programmer. I have a problem. I want to write parts of my program in assembler. I call these "assembler funktions" from C. The problem is that I am not able to compile it. First I assembled the asm part with a68k and tried to convert the object module with hunk2gcc. This doesn't work. Has this something to do with small/large model? Is that (hunk2gcc) the way amiga objects are converted into sun format? Then I tried to assemble with GNU assembler, but I keep getting 'Undefined symbol _ referenced from text segment'-messages. The asm code looks something like this: -- cut here -- .text 0 _: -- cut here -- I have before used a68k and DICE without problems. When I did that I XDEFed _. How is that done in GNU assembler? I haven't found it in the documentation. Sorry for such a trivial question, but this is my last change to get help. I have tried for about a week to find a solution myself, but in vain :(. Is there any FAQ for gcc? I looked in colombo.telesys-innov.fr but couldn't find one. -- / Sorry for my bad English. \ | Erik Rissanen | \ erik.rissanen@mn.medstroms.se / From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 22:28:09 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <4965-1>; Wed, 19 Apr 1995 15:19:25 +0300 Received: from indi1.u-strasbg.fr (indi1 [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id OAA18221 for ; Wed, 19 Apr 1995 14:18:01 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA09088; Wed, 19 Apr 95 13:47:03 GMT Date: Wed, 19 Apr 95 13:47:03 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9504191347.AA09088@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: Best way to use 68882 ??? I need to compile a floating point program (with cosinus and sinus). I have a 68030 and a 68882. How can I get the fastest executable (gcc -m68030 -m68881) ? Currently, I'm using math.h. Do math-68881.h produce faster executable ? What are the differences ? Thanks \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier | Etudiant en Doctorat | Centre de Recherche en Informatique E-Mail: | Universite Louis Pasteur papier@dpt-info.u-strasbg.fr | Strasbourg - FRANCE ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 22:28:20 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <4776-2>; Wed, 19 Apr 1995 20:26:10 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26480-2>; Wed, 19 Apr 1995 19:25:45 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209171-1>; Wed, 19 Apr 1995 19:25:37 +0100 Subject: Re: your mail From: Christian Stieber To: gc948374@gbar.dtu.dk Date: Wed, 19 Apr 1995 19:25:30 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Apr19.144112+0300_eet_dst.1150-3+214@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Apr 19, 95 02:41:12 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 977 Message-Id: <95Apr19.192537+0100mesz.209171-1+1340@hphalle0.informatik.tu-muenchen.de> > I am using my own startup code with GCC, but GCC seems to insert a call > to __main in the very beginning of main, how to i get rid of that call? > Currently, I have to declare > > static __inline void _main (void) {} > > to work around it. Is there a better solution? Well, my startup-code simply calls AmigaMain() instead of main(). One of the reasons I called it AmigaMain() was to avoid the special treatment that main() gets; the other reason was to avoid warnings due to the different prototypes: my library allows void AmigaMain(void) and int AmigaMain(void), while main() always returns an int. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 22:32:02 1995 Received: by nic.funet.fi id <4033-2>; Wed, 19 Apr 1995 16:43:15 +0300 From: Leonard Norrgard To: hans@wyst.hobby.nl CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9504132215.06z1@wyst.hobby.nl> (hans@wyst.hobby.nl) Subject: Re: Shared executables using dld-3.2.6 Message-Id: <95Apr19.164315+0300_eet_dst.4033-2+171@nic.funet.fi> Date: Wed, 19 Apr 1995 16:43:12 +0300 dld-3.2.6 is now in /pub/amiga/gnu/beta. Thanks! -- vinsci From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 22:32:13 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <3867-3>; Wed, 19 Apr 1995 15:04:39 +0300 Received: by bohr.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr19.150439+0300_eet_dst.3867-3+216@nic.funet.fi> From: To: Date: Wed, 19 Apr 1995 15:04:33 +0300 Date: Wed, 19 Apr 1995 14:06:07 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: How do I make registerized function call with gcc? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I have been using DICE for some time, and DICE has a switch that makes functions pass their arguments in registers instead of passing them on the stack. Is it possible with GCC? Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP3.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ P.S. Why does my subject line disappear? From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 22:32:19 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <5038-3>; Wed, 19 Apr 1995 22:05:22 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26488-2>; Wed, 19 Apr 1995 21:05:07 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209197-1>; Wed, 19 Apr 1995 21:05:03 +0100 Subject: Re: how to join asm and gcc? From: Christian Stieber To: d5dos@medstroms.se (Erik Rissanen) Date: Wed, 19 Apr 1995 21:04:56 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <40063025@maxinet.medstroms.se> from "Erik Rissanen" at Apr 19, 95 05:51:26 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 718 Message-Id: <95Apr19.210503+0100mesz.209197-1+1361@hphalle0.informatik.tu-muenchen.de> > Then I tried to assemble with GNU assembler, but I keep getting > 'Undefined symbol _ referenced from text segment'-messages. > > I have before used a68k and DICE without problems. When I did that I XDEFed > _. How is that done in GNU assembler? I haven't found it in the > documentation. It's there. You do a .globl _function Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 22:32:24 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <3646-2>; Wed, 19 Apr 1995 15:03:52 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA28610 (5.65c8/IDA-1.4.4 for ); Wed, 19 Apr 1995 14:02:51 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA03342; Wed, 19 Apr 95 14:02:50 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9504191202.AA03342@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: _main() To: gc948374@gbar.dtu.dk Date: Wed, 19 Apr 1995 14:02:50 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Apr19.144112+0300_eet_dst.1150-3+214@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Apr 19, 95 02:41:12 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 186 > > Currently, I have to declare > > static __inline void _main (void) {} > > to work around it. Is there a better solution? > No. AFAIK this is the best thing you can do. Matthias From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 22:32:30 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <3230-3>; Wed, 19 Apr 1995 18:07:51 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 17:08:28 +0100 From: Philippe BRAND Message-Id: <199504191608.RAA01167@colombo.telesys-innov.fr> Subject: Apurify To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Wed, 19 Apr 1995 17:08:27 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 433 A friend of mine has programmed Apurify, which works somewhat like Unix purify program, testing bad mem alloc/free, etc... He'll do memory leaks checking also in a near future. I'm planning to integrate it into gcc, adding another pass, on user request. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 22:38:52 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <1923-4>; Wed, 19 Apr 1995 14:56:02 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Apr 1995 13:56:27 +0100 From: Philippe BRAND Message-Id: <199504191256.NAA17898@colombo.telesys-innov.fr> Subject: Re: your mail To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Wed, 19 Apr 1995 13:56:27 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Rask Lambertsen" at Apr 19, 95 01:51:28 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 288 Rask Lambertsen writes: > I'm not that much of an expert. Does it require me to recompile GCC itself? Yes. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Apr 19 22:42:55 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <1643-1>; Wed, 19 Apr 1995 14:50:15 +0300 Received: by bohr.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr19.145015+0300_eet_dst.1643-1+243@nic.funet.fi> From: To: Date: Wed, 19 Apr 1995 14:50:08 +0300 Date: Wed, 19 Apr 1995 13:51:28 +0200 (METDST) From: Rask Lambertsen To: Philippe BRAND Cc: Amiga-Gcc Liste Subject: Re: your mail In-Reply-To: <199504191239.NAA17794@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ^^^^^^^^^^^^^^^^^^^^^^^ Why does my subject line disappear? It was: Cross compilation question On Wed, 19 Apr 1995, Philippe BRAND wrote: > gc948374@gbar.dtu.dk writes: > > > If I want to use GCC as a cross compiler, will I need to recompile > > GCC, or is it enough to use the -m switch? > > $ gtar xvfz gcc-2.6.3.tar.gz > $ cd gcc-2.6.3 > $ patch -p1 <../gcc-2.6.3-amiga.diffs > $ ./configure --target=amigados > $ vi foobar.c > __foobar() {} > $ gcc -c foobar.c > $ ar qc libgcc1.a foobar.o > $ rm foobar* > $ make I'm not that much of an expert. Does it require me to recompile GCC itself? Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP3.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Apr 20 08:51:24 1995 Received: from erlang.gbar.dtu.dk ([130.225.87.177]) by nic.funet.fi with ESMTP id <7165-2>; Thu, 20 Apr 1995 08:49:44 +0300 Received: by erlang.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr20.084944+0300_eet_dst.7165-2+219@nic.funet.fi> From: To: Date: Thu, 20 Apr 1995 08:49:43 +0300 Date: Thu, 20 Apr 1995 07:52:05 +0200 (METDST) From: Rask Lambertsen To: Erik Rissanen Cc: amiga-gcc-port Subject: Re: how to join asm and gcc? In-Reply-To: <40063025@maxinet.medstroms.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 19 Apr 1995, Erik Rissanen wrote: > I am new to gcc and am not especially experienced programmer. I have a > problem. I want to write parts of my program in assembler. I call these > "assembler funktions" from C. The problem is that I am not able to compile > it. > > First I assembled the asm part with a68k and tried to convert the object > module with hunk2gcc. This doesn't work. Has this something to do with > small/large model? Is that (hunk2gcc) the way amiga objects are converted > into sun format? I use sobja to convert the object files produced by gcc to the Amiga object format. Then I simply link all the object files with an Amiga linker to get my executable. This works as long as I don't declare BSS space in the C source. For example, struct ExecBase *SysBase; will cause a linker error (somethink like "COMMON symbol not supported"), but struct ExecBase *SysBase = NULL; gives no such problems, so that's what I do. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP3.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Apr 20 11:14:48 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <9518-3>; Thu, 20 Apr 1995 11:10:10 +0300 Received: by colombo.telesys-innov.fr; Thu, 20 Apr 1995 10:08:39 +0100 From: Philippe BRAND Message-Id: <199504200908.KAA00638@colombo.telesys-innov.fr> Subject: Re: APurify !! To: bernard@informatik.uni-kl.de (Frank Bernard) Date: Thu, 20 Apr 1995 10:08:39 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9504200254.aa27803@kerry.informatik.uni-kl.de> from "Frank Bernard" at Apr 20, 95 02:54:01 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 402 Frank Bernard writes: > Is APurify PD, Share or somewhat else ? > Can I get it ? > Does it run on machines without a MMU ?? In order: yes, yes, I don't know but I think so ;-) You can get latest version, 1.1, on Aminet. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Apr 20 11:17:08 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <9507-3>; Thu, 20 Apr 1995 11:16:54 +0300 Received: by tycho.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr20.111654+0300_eet_dst.9507-3+263@nic.funet.fi> From: To: Date: Thu, 20 Apr 1995 11:16:48 +0300 Date: Thu, 20 Apr 1995 10:17:28 +0200 (METDST) From: Rask Lambertsen To: Philippe BRAND Cc: Frank Bernard , Amiga-Gcc Liste Subject: Re: APurify !! In-Reply-To: <199504200908.KAA00638@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Frank Bernard writes: > Does it run on machines without a MMU ?? Yes. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP3.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Apr 20 11:32:37 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <9997-4>; Thu, 20 Apr 1995 11:31:14 +0300 Received: by colombo.telesys-innov.fr; Thu, 20 Apr 1995 10:31:05 +0100 From: Philippe BRAND Message-Id: <199504200931.KAA00765@colombo.telesys-innov.fr> Subject: stack cheking & auto-extend To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Thu, 20 Apr 1995 10:31:04 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 704 Okay I've generated a new 2.6.4b version using Matthias' changes to support stackextend. I'll make a new beta archive tonight. I still have to modify specs in order to automatically add libstack.a. - Matthias: I couldn't make all stuff to build libstack.a, it stops with an assembler error (sorry, can't remember where as for now). - Leonnard: could you integrate libstack.a into ixemul please ? So that I'll be able to build a gcc version which does use stackextend ? Thanks to people that sent me all archives I missed. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Apr 20 12:02:20 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <9682-2>; Thu, 20 Apr 1995 12:00:52 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA28412 (5.65c8/IDA-1.4.4 for ); Thu, 20 Apr 1995 11:00:38 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA07876; Thu, 20 Apr 95 11:00:37 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9504200900.AA07876@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: how to join asm and gcc? To: d5dos@medstroms.se (Erik Rissanen) Date: Thu, 20 Apr 1995 11:00:36 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <40063025@maxinet.medstroms.se> from "Erik Rissanen" at Apr 19, 95 05:51:26 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 492 > > Then I tried to assemble with GNU assembler, but I keep getting > 'Undefined symbol _ referenced from text segment'-messages. > Add a line like .globl _ to make it a non-local symbol. > > I have tried for about a week to find a solution myself, but in vain :(. > Yes, documentation about the MIT assembler syntax isn't easy to find. The most trivial way to learn it is looking at the assembler output (Option: -S) of the compiler :-). Hope it helps. Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Apr 20 12:10:51 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <10056-3>; Thu, 20 Apr 1995 12:10:09 +0300 Received: from indi1.u-strasbg.fr (indi1 [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id LAA28861 for ; Thu, 20 Apr 1995 11:08:51 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA14565; Thu, 20 Apr 95 10:35:50 GMT Date: Thu, 20 Apr 95 10:35:50 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9504201035.AA14565@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: clock() return value ?? What is the unit time of clock() return value in libnix (and in ixemul) ?? Is it microseconds ?? Thanks. \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier | Etudiant en Doctorat | Centre de Recherche en Informatique E-Mail: | Universite Louis Pasteur papier@dpt-info.u-strasbg.fr | Strasbourg - FRANCE ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Thu Apr 20 12:20:19 1995 Received: from www.utbm.fr ([193.48.246.2]) by nic.funet.fi with ESMTP id <9880-4>; Thu, 20 Apr 1995 12:19:12 +0300 Received: from (news@localhost) by www.utbm.fr (8.6.10/jtpda-5.1) id LAA00622 ; Thu, 20 Apr 1995 11:19:21 +0100 From: Rene.Garcia@utbm.fr Received: from sunserv.ipse.fr(193.48.202.1) by www.utbm.fr via smap (V1.3) id sma000620; Thu Apr 20 11:19:06 1995 Received: by sunserv.ipse.fr (5.x/SMI-SVR4) id AA05105; Thu, 20 Apr 1995 11:17:55 +0100 Date: Thu, 20 Apr 1995 11:17:55 +0100 Message-Id: <9504201017.AA05105@sunserv.ipse.fr> To: papier@indi1.u-strasbg.fr Subject: Re: clock() return value ?? Cc: amiga-gcc-port@nic.funet.fi X-Sun-Charset: US-ASCII > What is the unit time of clock() return value in libnix (and in ixemul) ?? > Is it microseconds ?? You may not assume that clock() returns microseconds or scheduler ticks. It depends on compilators and plateforms. To assure portability use the CLK_TCK constant defined in ( or maybe in for gcc, just grep on .h files ;) ) { time_t t1,t2; long seconds t1 = clock(); ... ... t2 = clock(); seconds = (t2-t1) / CLK_TCK; } I hope this will help you From amiga-gcc-port-owner@nic.funet.fi Thu Apr 20 12:50:34 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <9437-2>; Thu, 20 Apr 1995 12:49:42 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.ivp.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 20 Apr 1995 11:49:26 +0200 Received: from mammern.inf-wiss.ivp.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA07691; Thu, 20 Apr 95 11:49:23 +0200 Date: Thu, 20 Apr 95 11:49:23 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9504200949.AA07691@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@nic.funet.fi Subject: Re: clock() return value, CLOCK_PER_SEC and CLK_TCK Hi, Rene Garcia wrote: >To assure portability use the CLK_TCK constant defined in ( or maybe in > for gcc, just grep on .h files ;) ) CLK_TCK is not that portable. It's not defined on a BSD system like the Sun (under SunOS4.x). On the other side, the only reference to CLOCKS_PER_SEC I found is in a Mac Think_C C source file. I found one reference to CLK_TCK in a PeeCee Turbo_C source file and in a POSIX book. The book also mentions CLOCKS_PER_SECOND. It further says that clock is not required by POSIX and absent in BSD. The SunOS4.1.x manpage doesn't mention any #define usable with clock(). It simply says that the value is in microseconds for compatibility with other systems. It doesn't look like clock() is portable at all. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Apr 20 16:49:15 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <9503-3>; Thu, 20 Apr 1995 16:44:51 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA08654 (5.65c-6/7.3w-FAU); Thu, 20 Apr 1995 15:44:31 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA13586 (5.x/7.3w-FAU); Thu, 20 Apr 1995 15:44:30 +0200 From: Tobias Ruland Message-Id: <9504201344.AA13586@immd8.informatik.uni-erlangen.de> Date: Thu, 20 Apr 1995 15:44:28 +0200 To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Subject: Re: clock() return value, CLOCK_PER_SEC and CLK_TCK Cc: amiga-gcc-port@nic.funet.fi Joerg-Cyril Hoehle writes: > CLK_TCK is not that portable. It's not defined on a BSD system like the > Sun (under SunOS4.x). ei h"at"a! (no problem) ----------------------------------------------------------------------- sysconf(3C) C Library Functions sysconf(3C) NAME sysconf - get configurable system variables SYNOPSIS #include long sysconf(int name); MT-LEVEL Safe DESCRIPTION The sysconf() function provides a method for an application to determine the current value of a configurable system limit or option (variable). The name argument represents the system variable to be queried. The following table lists the minimal set of sys- tem variables from and that can be returned by sysconf(), and the symbolic constants, defined in that are the corresponding values used for name. _SC_ARG_MAX ARG_MAX Max combined size of argv[] and envp[] _SC_CHILD_MAX CHILD_MAX Max processes allowed to any UID _SC_CLK_TCK CLK_TCK Ticks per second (clock_t) [...] ----------------------------------------------------------------------- calling long ticks=sysconf(_SC_CLK_TCK); should work on amiga, too ?! (c-library function!) c u tobias --------------------------------------------------------------------------- Tobias Ruland (student at Dept. of Artificial Intelligence, Univ. Erlangen) MAIL: tsruland@immd8.informatik.uni-erlangen.de (Please write in ENGLISH, GERMAN or FINNISH) WWW: http://www8.informatik.uni-erlangen.de/~tsruland From amiga-gcc-port-owner@nic.funet.fi Thu Apr 20 22:15:32 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <9375-4>; Thu, 20 Apr 1995 22:12:36 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26468-3>; Thu, 20 Apr 1995 21:12:25 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209197-1>; Thu, 20 Apr 1995 21:12:19 +0100 Subject: Re: /GNUINCLUDE (fwd) From: Christian Stieber To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Thu, 20 Apr 1995 21:12:16 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9504191110.AA10408@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Apr 19, 95 01:10:11 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2534 Message-Id: <95Apr20.211219+0100mesz.209197-1+1865@hphalle0.informatik.tu-muenchen.de> > 2) soft links to /GNU/os-headers: I personally reject them, as I had > much trouble. Works fine for me. > (Try removing flex++ which is a link to flex, when > flex doesn't exist. This is *not* a problem of Commo Delete: rm > won't work, either.) It *is* a problem of Delete, and a problem of rm. The explanation is simple: both programs try to determine whether something they want to Delete() is a directory or a file. So... they Lock() it to be able to Exmine() it. Of course, they can't get a lock on an orphan link... > 3) copying the headers to /GNU/os-headers: Seems to me to be a waste > of HD space, as most users have more than one compiler installed. > (Look on your own HD, please ... :-) Additionally I think that > OS headers and System headers should really be separated. Err... what's the difference between OS-header and system-header? There is os-include and include... so you can separate something. > 5) Make gcc look in /GNUINCLUDE No, please don't. Or if you do, use it only if it is really assigned. I just hate to have millions and millions of unnecessary assigns. > >From my experience with other compilers I like an assign GNUINCLUDE: > For example, you can well add other directories. (Multiassigns) And it > is quite easy. (Note, that only gcc users ask, how to install the OS > headers. And quite much of them do. I see 5 or 6 postings a week > asking this question.) Of course. SAS/C has them included; they are installed automagically. Don't know about DICE. Also, installing the OS-headers is trivial *if you read the readme*. People just don't know how to read, you can't help them. Other than that, a simple cd gnu: dir will tell you where to put the headers --- if somebody doesn't get the idea, maybe [s]he shouldn't try to program at all. GNU-C is not a word processor. If you want to use GNU-C, you should have some basic understanding about computers and the Amiga; therefore there is no need for a fool-proof install script. And GNU-C *is* easy to install. The readme tells you everything you need to know --- where to put what assigns, where to put ixemul.library etc. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Fri Apr 21 14:24:07 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <9753-3>; Fri, 21 Apr 1995 13:40:32 +0300 Received: by tycho.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr21.134032+0300_eet_dst.9753-3+348@nic.funet.fi> From: To: Date: Fri, 21 Apr 1995 13:40:21 +0300 Date: Fri, 21 Apr 1995 12:41:01 +0200 (METDST) From: Rask Lambertsen To: Jochen Wiedmann Cc: amiga-gcc-port@nic.funet.fi Subject: Re: /GNUINCLUDE (fwd) In-Reply-To: <9504202129.AA15468@decap2.zdv.uni-tuebingen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 20 Apr 1995, Jochen Wiedmann wrote: > Hello, Christian, > > > > > > >From my experience with other compilers I like an assign GNUINCLUDE: > > > For example, you can well add other directories. (Multiassigns) And it > > > is quite easy. (Note, that only gcc users ask, how to install the OS > > > headers. And quite much of them do. I see 5 or 6 postings a week > > > asking this question.) > > > > Of course. SAS/C has them included; they are installed automagically. > > Don't know about DICE. > > At least registered Dice didn't have them included. I'm sure you are wrong. I got the OS includes with the registered version 2.06 of DICE. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP3.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Fri Apr 21 14:24:13 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <9878-2>; Fri, 21 Apr 1995 00:29:54 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA15468; Thu, 20 Apr 1995 23:29:50 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9504202129.AA15468@decap2.zdv.uni-tuebingen.de> Subject: Re: /GNUINCLUDE (fwd) To: amiga-gcc-port@nic.funet.fi Date: Thu, 20 Apr 1995 23:29:50 +0200 (MET DST) In-Reply-To: <95Apr20.211219+0100mesz.209197-1+1865@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Apr 20, 95 09:12:16 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1578 Hello, Christian, > > 3) copying the headers to /GNU/os-headers: Seems to me to be a waste > > of HD space, as most users have more than one compiler installed. > > (Look on your own HD, please ... :-) Additionally I think that > > OS headers and System headers should really be separated. > > Err... what's the difference between OS-header and system-header? > There is os-include and include... so you can separate something. My mistake. Read: OS headers and gcc headers. Installing OS headers in a subdirectory of GNU: doesn't mean separating to me. > > 5) Make gcc look in /GNUINCLUDE > > No, please don't. Or if you do, use it only if it is really assigned. > I just hate to have millions and millions of unnecessary assigns. The installer script now asks whether to create this assign or not. This should satisfy anyone, hopefully. > > > >From my experience with other compilers I like an assign GNUINCLUDE: > > For example, you can well add other directories. (Multiassigns) And it > > is quite easy. (Note, that only gcc users ask, how to install the OS > > headers. And quite much of them do. I see 5 or 6 postings a week > > asking this question.) > > Of course. SAS/C has them included; they are installed automagically. > Don't know about DICE. At least registered Dice didn't have them included. > Also, installing the OS-headers is trivial *if you read the readme*. > People just don't know how to read, you can't help them. Sigh. Christian, we all know that this is true. And we all know that people are asking anyway. Jochen From amiga-gcc-port-owner@nic.funet.fi Fri Apr 21 14:24:19 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <10799-2>; Fri, 21 Apr 1995 13:23:58 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA19677 for ; Fri, 21 Apr 1995 11:23:15 +0100 From: Lars Hecking Message-Id: <199504211024.LAA18718@krakow.nmrc.ucc.ie> Subject: Re: /GNUINCLUDE (fwd) To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Fri, 21 Apr 1995 11:24:12 +0100 (BST) In-Reply-To: from "Christian Stieber" at Apr 20, 95 09:12:16 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 495 Christian Stieber wrote: > GNU-C is not a word processor. If you want to use GNU-C, you should have > some basic understanding about computers and the Amiga; therefore there is > no need for a fool-proof install script. > And GNU-C *is* easy to install. The readme tells you everything you need > to know --- where to put what assigns, where to put ixemul.library etc. You should post this to csa.programmers twice a day -- "Christians Inofficial Amiga Gcc FAQ v-0.1" ;-) Lars ]B=8} From amiga-gcc-port-owner@nic.funet.fi Fri Apr 21 18:04:23 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <9638-2>; Fri, 21 Apr 1995 17:59:34 +0300 Received: by tuminfo2.informatik.tu-muenchen.de via suspension id <26520-2>; Fri, 21 Apr 1995 16:59:22 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26566-1>; Fri, 21 Apr 1995 16:50:46 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209197-2>; Fri, 21 Apr 1995 16:46:57 +0100 Subject: GNU-C for novice programmers? From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 21 Apr 1995 16:46:20 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2049 Message-Id: <95Apr21.164657+0100mesz.209197-2+2453@hphalle0.informatik.tu-muenchen.de> Lars Hecking wrote: > > Also, installing the OS-headers is trivial *if you read the readme*. > > People just don't know how to read, you can't help them. > > And GNU-C *is* easy to install. The readme tells you everything you need > > to know --- where to put what assigns, where to put ixemul.library etc. > > You should post this to csa.programmers twice a day -- "Christians Inofficial > Amiga Gcc FAQ v-0.1" ;-) Jochen Wiedmann wrote: > Sigh. Christian, we all know that this is true. And we all know that > people are asking anyway. Well, maybe I should really try to understand Joe I-want-to-program-but- don't-know-anything User. To tell the truth, I've never written an application; so I don't even know how difficult it is to come up with an installation script for a normal application (as opposed to some programming tool). But thinking about it, I believe it is impossible to come up with a script that installs something properly on every system. I never use install scripts --- I've never seen one that works properly on my system :( An installing a compiler *is* indeed difficult, since every programmer has a different setup for his/her tools, docs, headers, libraries, scripts etc. Or am I just thinking too much about Joe Expert? If you really want to target GNU-C at the novice programmer (which isn't a bad choice), there are probably more problems related to the documentation: how do you link *.lib files? How do you create *.a files? Why does the RKM example spit out a million errors and warnings? Why does GNU-C crash all the time? Why do varargs functions make problems? How about baserel? I don't understand this stupid assembler syntax. etc... Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Fri Apr 21 19:39:00 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <9284-2>; Fri, 21 Apr 1995 19:34:46 +0300 Received: by colombo.telesys-innov.fr; Fri, 21 Apr 1995 18:33:16 +0100 From: Philippe BRAND Message-Id: <199504211733.SAA06055@colombo.telesys-innov.fr> Subject: Re: GNU-C for novice programmers? To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Fri, 21 Apr 1995 18:33:16 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95Apr21.164657+0100mesz.209197-2+2453@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Apr 21, 95 04:46:20 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 742 Christian Stieber writes: > Or am I just thinking too much about Joe Expert? If you really want to > target GNU-C at the novice programmer (which isn't a bad choice), there > are probably more problems related to the documentation: how do you link > *.lib files? How do you create *.a files? Why does the RKM example spit > out a million errors and warnings? Why does GNU-C crash all the time? > Why do varargs functions make problems? How about baserel? I don't > understand this stupid assembler syntax. etc... Wanna start the long_waited amiga-gcc FAQ ? ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sat Apr 22 08:14:31 1995 Received: from clinet.fi ([193.64.6.1]) by nic.funet.fi with SMTP id <9844-2>; Sat, 22 Apr 1995 08:12:45 +0300 Received: from zetor.clinet.fi (root@zetor.clinet.fi [193.64.6.8]) by clinet.fi (8.6.10/8.6.4) with ESMTP id IAA26422; Sat, 22 Apr 1995 08:12:36 +0300 Received: (will@localhost) by zetor.clinet.fi (8.6.10/8.6.4) id HAA11810; Sat, 22 Apr 1995 07:48:46 +0300 Date: Sat, 22 Apr 1995 07:48:45 +0300 (EET DST) From: Ville-Pertti Keinonen To: Rask Lambertsen cc: Jochen Wiedmann , amiga-gcc-port@nic.funet.fi Subject: Re: New GCC installer script In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > It seems to work the other way around for me. I have had trouble deleting a > soft link after I deleted the directory it pointed to. Hard links don't > seem to have that sort of problems. If you delete a file before you delete a hard link to it, you're in a lot more trouble than if you make a soft link invalid. (You end up with a somewhat corrupt filesystem) Soft links are safe, the deletion problem can easily be worked around and doesn't really cause any damage. From amiga-gcc-port-owner@nic.funet.fi Sat Apr 22 20:34:01 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <9653-1>; Sat, 22 Apr 1995 20:30:38 +0300 Received: from tiny.lysator.liu.se (tiny.lysator.liu.se [130.236.253.10]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id TAA08612; Sat, 22 Apr 1995 19:30:09 +0200 From: Niels M|ller Received: (nisse@localhost) by tiny.lysator.liu.se (8.6.11/8.6.11) id TAA28429; Sat, 22 Apr 1995 19:28:47 +0200 Date: Sat, 22 Apr 1995 19:28:47 +0200 Message-Id: <199504221728.TAA28429@tiny.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: phb@colombo.telesys-innov.fr CC: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-reply-to: <199504191256.NAA17898@colombo.telesys-innov.fr> (message from Philippe BRAND on Wed, 19 Apr 1995 13:56:27 +0100 (BST)) Subject: Re: Cross compiling Rask Lambertsen writes: > I'm not that much of an expert. Does it require me to recompile GCC itself? Philippe BRAND answers: Yes. This is true, unless the "other" machine is also m68k based. For example, a while ago I compiled the linux-m68k kernel under amiga-os. In this case what was needed was only a new assembler, a new linker, and linux-specific headers and libraries. From amiga-gcc-port-owner@nic.funet.fi Sun Apr 23 10:32:26 1995 Received: from ariel.ucs.unimelb.EDU.AU ([128.250.20.3]) by nic.funet.fi with SMTP id <9730-3>; Sun, 23 Apr 1995 10:30:56 +0300 Received: (from vkelim@localhost) by ariel.ucs.unimelb.EDU.AU (8.6.10/8.6.10) id RAA05753; Sun, 23 Apr 1995 17:30:39 +1000 Date: Sun, 23 Apr 1995 17:30:38 +1000 (AEST) From: David Pat Shui Fong Subject: libnix To: amiga-gcc-port@nic.funet.fi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello all! For some reason, the -libnix option, when I try to use it with gcc, doesn't work. gcc attempts to find files which don't exist, like libibnix.a, or look for files which do exist in the wrong place. My spec file probably set up wrongly, but I don't know how to modify it! It would seem that the libnix installation program didn't do the job properly. Where is the documentation file for the `spec' configuration, so I can modify the spec file myself? In addition, there was a program which I compiled with `libnix' (using manually specified files in the gcc command line) which didn't work. It does work with IBM etc. gccs, it also works with Amiga gcc when the ixemul.library is being used. The problem was that it printed floats in some demented fashion. The problem resolved when I replaced all mention of floats with double. David Fong From amiga-gcc-port-owner@nic.funet.fi Mon Apr 24 03:00:54 1995 Received: from edina.xenologics.com ([194.77.5.1]) by nic.funet.fi with SMTP id <10172-2>; Mon, 24 Apr 1995 02:57:44 +0300 Received: from DARKNESS.gun.de (root@localhost) by edina.xenologics.com (8.6.8.1/8.6.6) with UUCP id CAA20275 for nic.funet.fi!amiga-gcc-port; Mon, 24 Apr 1995 02:00:47 +0200 X-ZC-VIA: 19950423220558W+1@DARKNESS.gun.de Subject: env: subdir for gcc? Message-Id: Date: Sun, 23 Apr 95 18:52:51 CET Return-Receipt-To: DARKSTAR@DARKNESS.gun.de (Carsten Meyer) Organization: CDC X-ZC-POST: Postfach 11 12;31596 Uchte Path: DARKNESS.gun.de From: DARKSTAR@DARKNESS.gun.de (Carsten Meyer) X-Mailer: MicroDot 1.10 [UNREGISTRIERT] via Connectline-CLMSortin 2.17 To: amiga-gcc-port@nic.funet.fi X-Gateway: ZConnect CL DARKNESS.gun.de [Connectline/AmigaOS] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi! Is it possible to create an env: and envarc: subdir for gcc settings? c u DarkStar -- MicroDot 1.10 From amiga-gcc-port-owner@nic.funet.fi Mon Apr 24 08:34:45 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <9233-4> convert rfc822-to-8bit; Mon, 24 Apr 1995 08:31:20 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa22378; 24 Apr 95 6:31 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id ab02627; 24 Apr 95 6:30 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA0045t; Sun, 23 Apr 95 12:46:38 GMT Date: Sun, 23 Apr 95 12:46:38 GMT Message-Id: <9504231246.AA0045s@flevel.demon.co.uk> Message-Id: <208e0d2d.35b60-dev@flevel.demon.co.uk> In-Reply-To: (from David Pat Shui Fong ) (at Sun, 23 Apr 1995 17:30:38 +1000 (AEST)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT From: dev@flevel.demon.co.uk To: vkelim@ariel.ucs.unimelb.edu.au Cc: amiga-gcc-port@nic.funet.fi Subject: Re: libnix Hi David, > In addition, there was a program which I compiled with `libnix' > (using manually specified files in the gcc command line) which didn't > work. It does work with IBM etc. gccs, it also works with Amiga gcc when > the ixemul.library is being used. The problem was that it printed floats > in some demented fashion. The problem resolved when I replaced all Did you remember that %f (In printf) takes a double not a float? Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Apr 24 11:27:09 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <9636-2>; Mon, 24 Apr 1995 11:25:05 +0300 Received: by colombo.telesys-innov.fr; Mon, 24 Apr 1995 10:24:56 +0100 Received: from arbi.informatik.uni-oldenburg.de by colombo.telesys-innov.fr; Sun, 23 Apr 1995 23:49:12 +0100 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Sun, 23 Apr 95 23:49 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Sun, 23 Apr 95 23:44 MET DST Message-Id: Subject: Re: GNU-C for novice programmers? To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Sun, 23 Apr 1995 23:44:12 +0200 (MET DST) From: Walter Harms In-Reply-To: <199504211733.SAA06055@colombo.telesys-innov.fr> from "Philippe BRAND" at Apr 21, 95 06:33:16 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2176 Sender: phb@colombo.telesys-innov.fr > > Christian Stieber writes: > > > Or am I just thinking too much about Joe Expert? If you really want to > > target GNU-C at the novice programmer (which isn't a bad choice), there > > are probably more problems related to the documentation: how do you link > > *.lib files? How do you create *.a files? Why does the RKM example spit > > out a million errors and warnings? Why does GNU-C crash all the time? > > Why do varargs functions make problems? How about baserel? I don't > > understand this stupid assembler syntax. etc... > > Wanna start the long_waited amiga-gcc FAQ ? ;-) > > -- > Philippe BRAND > phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB > AmigaDOS GNU Project, AmigOS Net/WWW coordinator. > http://www.telesys-innov.fr/about/PhB.html > i have some good news, while being frustated from my diploma i compiled the most krm-demos for gcc that means 1. they compile without errors !! (hi cristian :) 2. they are correct now ! (some of them simply didnt work)_ 3. the bad news: not all everything with __CHIP or CHIP isnt ready yet all asm.demos eg. sample.library are not converted yet printerdriver are not convert usw.. philip, i will down load this to your ftp-site. there is no diff availabel. all: this will be an alpha release ! because some files are still missing and others are only in the '30/881 version available but everyone is invited to check the files BUT again these are ONLY the RKRM-Files already available. i have added some not-yet-ready thinks (eg. amigaguide) but everybody is free to add his personal example for things not discussed yet. (eg. NETSUPPORT !,most 3.x things) oh, yes - the simpletask demo isnt working, but compiling without any error, (it aktualy work but the main prozess ist stoped while the other is running). i had correct it once, but i dont find how any a HINT ?? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Mon Apr 24 11:34:47 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <9642-1>; Mon, 24 Apr 1995 11:33:58 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA09442 (5.65c8/IDA-1.4.4 for ); Mon, 24 Apr 1995 10:33:26 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA10789; Mon, 24 Apr 95 10:33:25 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9504240833.AA10789@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: libnix To: vkelim@ariel.ucs.unimelb.EDU.AU (David Pat Shui Fong) Date: Mon, 24 Apr 1995 10:33:25 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "David Pat Shui Fong" at Apr 23, 95 05:30:38 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 649 > For some reason, the -libnix option, when I try to use it with > gcc, doesn't work. gcc attempts to find files which don't exist, like > libibnix.a, or look for files which do exist in the wrong place. Try -noixemul. -libnix means linking (-l) with library 'ibnix' (libibnix.a). > > the ixemul.library is being used. The problem was that it printed floats > in some demented fashion. The problem resolved when I replaced all > mention of floats with double. > What do you mean by 'demented'? Do you own a 68040 based amiga (there seems to be an OS bug with 68040's mathematical operations)? What version of libnix do you use? Matthias From amiga-gcc-port-owner@nic.funet.fi Tue Apr 25 21:17:17 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <9918-4>; Tue, 25 Apr 1995 21:03:58 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id TAA23766 for ; Tue, 25 Apr 1995 19:03:14 +0100 From: Lars Hecking Message-Id: <199504251804.TAA13250@mostar.nmrc.ucc.ie> Subject: misc To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Tue, 25 Apr 1995 19:04:38 +0100 (BST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 767 1. /gnu/include/dirent.h should include 2. : the prototype for getpgrp () should be pid_t getpgrp __P((pid_t)); 3. why is fflush (stderr) = EBADF on the Amiga and = 0 on any **IX system I tried? (simple test prg: #include int main (void) { printf ("%d\n",fflush(stderr)); exit(0); } ) 4. has anybody tried to compile perl5.001? I couldn't even 'sh ./Configure' with 40MB(!!) of VMM (6MB physical ...) Slan, Lars -- Lars Hecking | I woke the same as any other day lhecking@nmrc.ucc.ie | Except a voice was in my head NMRC | It said seize the day, pull the trigger, Cork, Ireland | Drop the blade | And watch the rolling heads From amiga-gcc-port-owner@nic.funet.fi Wed Apr 26 01:35:00 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <9482-1>; Wed, 26 Apr 1995 01:31:15 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 26 Apr 95 00:30 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 26 Apr 95 00:24 MET DST Message-Id: Subject: linklib sources To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 26 Apr 1995 00:24:23 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 493 the most linklibraries for gcc are well know but 2 are missing thats amiga.lib & debug.lib. because the source is partly open it should be possible to close these huge gap. is there some interesse ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Apr 26 11:10:16 1995 Received: from afrodite.kih.no ([158.36.9.69]) by nic.funet.fi with ESMTP id <10148-2>; Wed, 26 Apr 1995 11:06:25 +0300 Received: by afrodite.kih.no (1.37.109.16/16.2) id AA045493496; Wed, 26 Apr 1995 10:04:56 +0200 Date: Wed, 26 Apr 1995 10:04:55 +0200 (METDST) From: Erik Johannessen To: Lars Hecking Cc: Amiga GCC List Subject: Re: misc In-Reply-To: <199504251804.TAA13250@mostar.nmrc.ucc.ie> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 25 Apr 1995, Lars Hecking wrote: > 4. has anybody tried to compile perl5.001? I couldn't even > 'sh ./Configure' with 40MB(!!) of VMM (6MB physical ...) Yes, but I ran into the same problem. I think there was some discussion about this a few weeks ago. I found another (older) pdksh port on ftp.funet.fi (in pub/amiga/shells (I think)) without the memory problems, however this one crashes somewhere near the end of Configure. There was also some talk about porting bash. Any news? I was able to compile pdksh-5.0.6 yesterday, however there are some problems with process management/job control. I had to replace a fork with a vfork. This may cause some problems too. After executing a command it never returns to the command line. -Erik -- erik2@afrodite.kih.no Erik From amiga-gcc-port-owner@nic.funet.fi Wed Apr 26 12:55:16 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <9480-4>; Wed, 26 Apr 1995 12:53:24 +0300 Received: from bastion.nmrc.ucc.ie (nmrc.ucc.ie) by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HPSG8ST58W001KMY@FIPORT.FUNET.FI>; Wed, 26 Apr 1995 09:31:50 +0200 (EET) Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id KAA26543; Wed, 26 Apr 1995 10:29:03 +0100 Date: Wed, 26 Apr 1995 10:30:29 +0100 (BST) From: Lars Hecking Subject: Re: misc In-reply-to: from "Erik Johannessen" at Apr 26, 95 10:04:55 am To: erik2@afrodite.kih.no (Erik Johannessen) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Message-id: <199504260930.KAA13666@mostar.nmrc.ucc.ie> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL24] Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit Content-length: 2650 Erik Johannessen wrote: > On Tue, 25 Apr 1995, Lars Hecking wrote: > > 4. has anybody tried to compile perl5.001? I couldn't even > > 'sh ./Configure' with 40MB(!!) of VMM (6MB physical ...) > Yes, but I ran into the same problem. I think there was some > discussion about this a few weeks ago. I found another (older) > pdksh port on ftp.funet.fi (in pub/amiga/shells (I think)) without > the memory problems, however this one crashes somewhere near the > end of Configure. I'm using aminet:util/shell/pdksh-920711.lha, freshly compiled with good ole' gcc-2.3.3 to make it residentable, executable size ~82k. The problem with this version (4.9) is, that it doesn't release any malloc'd memory before the very end of the configuration. It's _real_fun_ to have VMMUsage running and see sh allocating >30MB vm :( > There was also some talk about porting bash. Any news? Je ne sais pas ;) Would be dead kewl, I suppose ... > I was able to compile pdksh-5.0.6 yesterday, however there > are some problems with process management/job control. > I had to replace a fork with a vfork. This may cause > some problems too. After executing a command it never returns > to the command line. pdksh-5.1.3 configure's like a charm and compiles without any problems. I managed to patch in the relevant diffs from 4.9 in jobs.c, table.c, alloc.c (off my head), which require gcc-2.3.3 for compilation (-resident). Nevertheless, I'm still facing the same problem as you, with or without any patches :( I dug out the README from mwild's gcc222/333, which has something to say about fork()/vfork(): - fork() creates an identical copy of the parents process image, which is usually overlayed later on with one of the exec*() calls to run a new program concurrently. - vfork()[ixemul 446, the new version]: the child runs on the parent's process segments and stack _while_the_parent_is_sleeping. So, if fork() is to be simulated w/ vfork(), stack and malloc'd data need to be copied, but that's just not enough, because the parent sleeps while the child is running. - for that reason, Markus introduced vfork_resume() [ixemul 325], where the child switches to it's own stack, wakes up parent and both run concurrently. This is what the patch in jobs.c/exec_child() is about. I have a strong feeling that I simply missed to copy some data/structures, which are new in pdksh 5. Slan, Lars -- Lars Hecking | I woke the same as any other day lhecking@nmrc.ucc.ie | Except a voice was in my head NMRC | It said seize the day, pull the trigger, Cork, Ireland | Drop the blade | And watch the rolling heads From amiga-gcc-port-owner@nic.funet.fi Wed Apr 26 14:56:46 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <9500-1>; Wed, 26 Apr 1995 14:54:54 +0300 Received: by ceylon.informatik.uni-rostock.de id NAA15963; Wed, 26 Apr 1995 13:54:33 +0200 Received: by honshu.informatik.uni-rostock.de id NAA14932; Wed, 26 Apr 1995 13:54:32 +0200 From: Gunther Nikl Message-Id: <199504261154.NAA14932@honshu.informatik.uni-rostock.de> Subject: Re: linklib sources To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Wed, 26 Apr 1995 13:54:31 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi (amiga gcc-list) In-Reply-To: from "Walter Harms" at Apr 26, 95 00:24:23 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 377 > the most linklibraries for gcc are well know but 2 are missing > thats amiga.lib & debug.lib. because the source is partly open > it should be possible to close these huge gap. is there some > interesse ? ?? The (nearly) complete source for libamiga.a can be found in gcc263-inclib.lha on Aminet. The missing functions are very rarely used at all. Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Apr 26 21:06:01 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <9575-2>; Wed, 26 Apr 1995 21:01:24 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0s4BNs-000FeaC; Wed, 26 Apr 95 20:00 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <076d@wyst.hobby.nl>; Wed, 26 Apr 95 08:13:27 CET Message-Id: <9504260713.076d@wyst.hobby.nl> Date: Wed, 26 Apr 1995 08:13:25 +0000 (CET) In-Reply-To: <199504251804.TAA13250@mostar.nmrc.ucc.ie> from "Lars Hecking" at Apr 25, 95 07:04:38 pm Content-Type: text Content-Length: 921 From: hans@wyst.hobby.nl (Hans Verkuil) To: lhecking@nmrc.ucc.ie Cc: amiga-gcc-port@nic.funet.fi Subject: Re: misc Lars, > 4. has anybody tried to compile perl5.001? I couldn't even > 'sh ./Configure' with 40MB(!!) of VMM (6MB physical ...) Yes, I have. I could run 'sh configure', but I got into trouble later on. I was able to compile perl5.000, but don't ask me about it as I lost it after a disk crash. I'm going to wait for perl5.002 before trying again, as there were more people who had problems with perl5.001. What exactly goes wrong? Provided you have all the GNU utilities it should work, although it is very tedious (one wrong answer and you can start all over again...). Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu Apr 27 10:51:43 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <9338-1>; Thu, 27 Apr 1995 10:47:05 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Apr27.104705+0300_eet_dst.9338-1+573@nic.funet.fi> From: To: Date: Thu, 27 Apr 1995 10:47:04 +0300 Date: Thu, 27 Apr 1995 09:48:15 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Error in GNU:os-include/inline/alib.h Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, There is an error in GNU:os-include/inline/alib.h, it uses the keyword "asm" instead of "__asm", this causes lots of trouble when compiling with the option -ansi. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP3.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Apr 27 11:15:26 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <9396-1>; Thu, 27 Apr 1995 11:11:05 +0300 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA09405 (5.65c-6/7.3w-FAU); Thu, 27 Apr 1995 10:10:45 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id KAA27862 (8.6.10/7.4a-FAU);; Thu, 27 Apr 1995 10:10:38 +0200 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA22785; Thu, 27 Apr 1995 10:10:37 +0200 Date: Thu, 27 Apr 1995 10:10:37 +0200 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9504270810.AA22785@pctc.chemie.uni-erlangen.de> To: lhecking@nmrc.ucc.ie Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199504251804.TAA13250@mostar.nmrc.ucc.ie> (message from Lars Hecking on Tue, 25 Apr 1995 19:04:38 +0100 (BST)) Subject: Re: misc Hello, about perl5.001: I asked some weeks ago about perl5.000. I got an answer from Fred Fish. He said he succeeds in compiling perl5.000 but he has a "powered up" amiga: The original answer from Fred: I did this recently as well, and was finally able to run the Configure script to completion after using VMM to add 32Mb of virtual memory to my A4000 that has 32Mb of real memory. There is a memory leak in pdksh that gradually consumes all available memory when a particular instance of a shell is run for a long time, and the Configure script is the King Kong of shell scripts. -Fred I tried it as well with an AMIGA with 7MB RAM and vmm and fails too. I think with a not memory friendly shell and not mich real memory you will always fail. In some other post to this list I read about some people working on a new or better port of pdksh (bash ??) so this will help. Servus -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Thu Apr 27 15:25:30 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <9687-2>; Thu, 27 Apr 1995 15:15:56 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id MAA04038; Thu, 27 Apr 1995 12:10:32 +0100 From: Lars Hecking Message-Id: <199504261821.TAA14139@mostar.nmrc.ucc.ie> Subject: Re: misc To: hans@wyst.hobby.nl (Hans Verkuil) Date: Wed, 26 Apr 1995 19:21:47 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9504260713.076d@wyst.hobby.nl> from "Hans Verkuil" at Apr 26, 95 08:13:25 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1742 > Lars, > > > 4. has anybody tried to compile perl5.001? I couldn't even > > 'sh ./Configure' with 40MB(!!) of VMM (6MB physical ...) > > Yes, I have. I could run 'sh configure', but I got into trouble later on. > I was able to compile perl5.000, but don't ask me about it as I lost it > after a disk crash. I'm going to wait for perl5.002 before trying again, as > there were more people who had problems with perl5.001. What are your machine specs (RAM, VMM, CPU)? > What exactly goes wrong? Provided you have all the GNU utilities it should > work, although it is very tedious (one wrong answer and you can start all > over again...). I suppose it would work in 40MB VMM, as sh has allocated less than 30MB when configure is 75% through. I have all the GNU utils, most of them compiled with the old gcc-2.6.4 snapshot and -O only, with the exception of pdksh, which I compiled w/ gcc233 to make it residentable. Configure crashed every time I ran it, sometimes pretty soon, sometimes near the end. It _could_ be a memory (VMM) problem, but other than that, I haven't the slightest clue :(. The random nature of crashes does not allow me to be more specific. Perl's configure is badly designed, IMHO. I think the amount of memory sh is accumulating is determined by the number of variables/data ./configure needs to store. When I configure pdksh-5.1.3, sh allocates <7MB (size of configure script: 72k). For perl (./configure size: 170k), sh needs ~38MB, extrapolated guess ;) Slan, Lars -- Lars Hecking | I woke the same as any other day lhecking@nmrc.ucc.ie | Except a voice was in my head NMRC | It said seize the day, pull the trigger, Cork, Ireland | Drop the blade | And watch the rolling heads From amiga-gcc-port-owner@nic.funet.fi Thu Apr 27 15:34:49 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <10087-2>; Thu, 27 Apr 1995 15:33:31 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 27 Apr 95 14:33 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 27 Apr 95 14:21 MET DST Message-Id: Subject: createtask()-problem To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 27 Apr 1995 14:21:31 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 496 i compiled the rkm-example for createtask(). it did compile without problems but it seems that the parent- task is frozen while the child is running. What went wrong ? i will send sources at request. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Apr 28 01:12:52 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <10042-3>; Fri, 28 Apr 1995 01:06:09 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Fri, 28 Apr 95 00:06 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Fri, 28 Apr 95 00:03 MET DST Message-Id: Subject: createtask-problem : the programm To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Fri, 28 Apr 1995 00:03:15 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2164 this is the original C= createtask() demo beside 1. the clib/include 2. a bunch of warnings this programm compiles withpout problems but it frezes its parent task. what is the problem ? ==========8<--------------------------- #include #include #include #include #ifdef LATTICE #include #include #endif #include #include #ifdef LATTICE int CXBRK(void) { return(0); } /* Disable Lattice CTRL/C handling */ int chkabort(void) {return(0);} #endif #define STACK_SIZE 1000L /* Task name, pointers for allocated task struct and stack */ struct Task *task = NULL; char *simpletaskname = "SimpleTask"; ULONG sharedvar; /* our function prototypes */ void simpletask(void); void cleanexit(UBYTE *,LONG); void main(int argc,char **argv) { sharedvar = 0L; task = (struct Task *)CreateTask(simpletaskname,0,simpletask,STACK_SIZE); if(!task) cleanexit("Can't create task",RETURN_FAIL); printf("This program initialized a variable to zero, then started a\n"); printf("separate task which is incrementing that variable right now,\n"); printf("while this program waits for you to press RETURN.\n"); printf("Press RETURN now: "); getchar(); printf("The shared variable now equals %ld\n",sharedvar); /* We can simply remove the task we added because our simpletask does not make */ /* any system calls which could cause it to be awakened or signalled later. */ Forbid(); DeleteTask(task); Permit(); cleanexit("",RETURN_OK); } void simpletask() { while(sharedvar < 0x800000) sharedvar++; /* Wait forever because main() is going to RemTask() us */ Wait(0L); } void cleanexit(UBYTE *s, LONG e) { if(*s) printf("%s\n",s); exit(e); } ==========8<--------------------------- -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Apr 28 20:14:31 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <10014-2>; Fri, 28 Apr 1995 20:08:55 +0300 Received: by theseas.ntua.gr with UUCP; Fri, 28 Apr 1995 20:09:48 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06xq@kriton.UUCP>; Fri, 28 Apr 95 19:55:20 EET Date: Fri, 28 Apr 95 19:55:20 EET Message-Id: <9504281755.06xq@kriton.UUCP> In-Reply-To: (from Walter Harms ) (at Fri, 28 Apr 1995 00:03:15 +0200 (MET DST)) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1031 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: Walter.Harms@arbi.informatik.uni-oldenburg.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: createtask-problem : the programm Hi Walter (Walter Harms), in on Apr 28 you wrote: > this programm compiles withpout problems but it frezes its parent > task. > printf("Press RETURN now: "); > > getchar(); When you say that the parent task freezes, do you mean that you don't see the "Press RETURN now: " prompt? If so, try hitting RETURN--you might be surprised. (If you have linked with libnix, then getchar() does not flush the output buffer, so you only get to see the prompt when the result is printed. The program works OK when linked with ixemul.) Apart from this minor glitch, I haven't noticed any problems with this program--I always get a result printed when I hit RETURN. As a side note, this program does not work at all (it always prints 0) when compiled with SAS/C 6.55. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Go, before I unleash a terrible something on you!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Apr 28 20:25:37 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <10102-1>; Fri, 28 Apr 1995 20:19:46 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26466-1>; Fri, 28 Apr 1995 19:19:35 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209163-1>; Fri, 28 Apr 1995 19:19:21 +0100 Subject: Re: createtask-problem : the programm From: Christian Stieber To: amiga-gcc-port@lists.funet.fi Date: Fri, 28 Apr 1995 19:19:13 +0200 (MESZ) In-Reply-To: <9504281755.06xq@kriton.UUCP> from "Kriton Kyrimis" at Apr 28, 95 07:55:20 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 598 Message-Id: <95Apr28.191921+0100mesz.209163-1+281@hphalle0.informatik.tu-muenchen.de> > As a side note, this program does not work at all (it always prints 0) > when compiled with SAS/C 6.55. Are you sure you turned off baserelative adressing? As an alternative, you could add the __saveds keyword to the child task. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Sat Apr 29 00:20:55 1995 Received: from edina.xenologics.com ([194.77.5.1]) by nic.funet.fi with SMTP id <9695-4>; Sat, 29 Apr 1995 00:16:48 +0300 Received: from DARKNESS.gun.de (root@localhost) by edina.xenologics.com (8.6.8.1/8.6.6) with UUCP id XAA22753 for nic.funet.fi!amiga-gcc-port; Fri, 28 Apr 1995 23:19:15 +0200 X-ZC-VIA: 19950428211742W+1@DARKNESS.gun.de Subject: Bug in gnu/os-include/exec/tasks.h? Message-Id: Date: Fri, 28 Apr 95 21:04:22 CET Organization: CDC X-ZC-POST: Postfach 11 12;31596 Uchte Path: DARKNESS.gun.de From: DARKSTAR@DARKNESS.gun.de (Carsten Meyer) X-Mailer: MicroDot 1.10 [UNREGISTRIERT] via Connectline-CLMSortin 2.18 To: amiga-gcc-port@nic.funet.fi X-Gateway: ZConnect CL DARKNESS.gun.de [Connectline/AmigaOS] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi folks! Is there a bug in GNU:os-include/exec/tasks.h ? Some output ... --------------------------- cut here -------------------------------- In file included from /gnu/os-include/exec/ports.h:22, from /gnu/os-include/exec/io.h:14, from /gnu/os-include/proto/exec.h:5, from filerequest.c:12: /gnu/os-include/exec/tasks.h:43: parse error before `(' /gnu/os-include/exec/tasks.h:43: warning: no semicolon at end of struct or union /gnu/os-include/exec/tasks.h:44: warning: data definition has no type or storage class /gnu/os-include/exec/tasks.h:47: parse error before `}' --------------------------- cut here -------------------------------- The guilty one ... ----------------------- part of tasks.h ------------------------ struct Task { ... [Stuff deleted] void (*tc_Switch)(); /* task losing CPU */ void (*tc_Launch)(); /* task getting CPU */ ... [Stuff deleted] }; ! -----------------------part of tasks.h ------------------------- It seems to me that there are no "voids" in this Functionpointer declaration. If I modify this version of tasks.h like the following one no errors accur. --------------- part of "void"-modified tasks.h ---------------- struct Task { ... [Stuff deleted] void (*tc_Switch) (void); /* task losing CPU */ void (*tc_Launch) (void); /* task getting CPU */ ... [Stuff deleted] }; ! -------------- part of "void"-modified tasks.h ----------------- Is it a bug? If yes why does nobody else had found it until now? c u DarkStar -- MicroDot 1.10 From amiga-gcc-port-owner@nic.funet.fi Tue May 2 09:12:42 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <10910-4>; Mon, 1 May 1995 09:26:43 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0s5ow7-000Fb8C; Mon, 1 May 95 08:26 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <079x@wyst.hobby.nl>; Mon, 1 May 95 08:20:10 CET Message-Id: <9505010720.079x@wyst.hobby.nl> Date: Mon, 1 May 1995 08:20:08 +0000 (CET) Content-Type: text Content-Length: 1256 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi, fnf@fishpond.cygnus.com Subject: Context sensitive patch to fix memory trashing bug Fred Fish pointed out that my previous patch to fix the memory trashing bug in ixemul.library didn't state which file to patch and wasn't context sensitive. In all the excitement I forgot :-). So here it is again (relative to ixemul-40.4 vfork.c): --------- cut here --------- *** ixemul-40.4/library/vfork.c Thu Jan 5 08:23:54 1995 --- ixemul-40.5/library/vfork.c Sun Apr 30 15:47:08 1995 *************** *** 226,230 **** { struct death_msg *dm = 0; ! int i; /* overkill? */ --- 226,230 ---- { struct death_msg *dm = 0; ! int i, errno_dummy; /* overkill? */ *************** *** 246,249 **** --- 246,253 ---- all_free (); + /* Since errno (= *u.u_errno) is still used by ix_sleep we point it + to our own temporary errno dummy variable */ + u.u_errno = &errno_dummy; + /* DP(("vforked: _exit in progress, rc = %ld.\n", rc)); */ --------- cut here --------- -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue May 2 09:37:43 1995 Received: by nic.funet.fi id <10895-3>; Mon, 1 May 1995 16:00:03 +0300 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <95May1.160003+0300_eet_dst.10895-3+664@nic.funet.fi> Date: Mon, 1 May 1995 16:00:01 +0300 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Tue May 2 09:39:22 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <9731-4>; Sun, 30 Apr 1995 16:59:13 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0s5ZW8-000FgsC; Sun, 30 Apr 95 15:58 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <079j@wyst.hobby.nl>; Sun, 30 Apr 95 15:48:46 CET Message-Id: <9504301448.079j@wyst.hobby.nl> Date: Sun, 30 Apr 1995 15:48:44 +0000 (CET) Content-Type: text Content-Length: 3485 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi, fnf@fishpond.cygnus.com, lhecking@nmrc.ucc.ie Subject: sh memory leak fixed. Included is a patch to jobs.c (pdksh-4.9) and to vfork.c in the ixemul.library. The latter patch changes the comments only. The bug was that the old (4.5) sh used the old vfork() function, which was renamed to vfork2() a few months later by Markus Wild. If you recompile sh with the new ixemul.library the wrong vfork() was used. This meant that lots of malloc's were done using the parents memory list instead of that of the client. So every time you run a program from the shell, you will get a memory leak. And they add up fairly quickly! The moral is: NEVER use vfork_resume() together with vfork(), use vfork2() instead! Cheers, Hans ---------- cut here, patch to jobs.c ------------- *** j.c Sun Apr 30 15:39:51 1995 --- jobs.c Sun Apr 30 14:51:16 1995 *************** *** 385,389 **** #ifdef __amigados__ /* use vfork () instead of fork(), and later try to do fork() `by hand'... */ ! #define fork vfork #endif /* create child process */ --- 385,389 ---- #ifdef __amigados__ /* use vfork () instead of fork(), and later try to do fork() `by hand'... */ ! #define fork vfork2 #endif /* create child process */ *************** *** 736,743 **** #ifdef JOBS if (flag[FMONITOR]) ! pid = waitpid(-1, &status, (WNOHANG|WUNTRACED)); else #endif ! pid = wait(&status); if (pid == 0 || pid < 0 && errno == ECHILD) { --- 736,743 ---- #ifdef JOBS if (flag[FMONITOR]) ! pid = waitpid(-1, (int *)&status, (WNOHANG|WUNTRACED)); else #endif ! pid = wait((int *)&status); if (pid == 0 || pid < 0 && errno == ECHILD) { ---------- cut here, patch to jobs.c ------------- ---------- cut here, patch to vfork.c ------------- *** v.c Sun Apr 30 15:37:12 1995 --- vfork.c Sun Apr 30 15:38:56 1995 *************** *** 374,384 **** /* ! * this is an implementation extension to the `real' vfork(). Normally you * can only cause the parent to resume by calling _exit() or execve() from * the child. Since I can't provide a real fork() on the Amiga, this function * is a third possibility to make the parent resume. You have then two * concurrent processes sharing the same frame and global data... Please be ! * EXTREMLY careful what you may do and what not. vfork() itself is a hack, * this is an even greater one... * * Note that this function should really be static, but if you make it static --- 374,387 ---- /* ! * this is an implementation extension to the `real' vfork2(). Normally you * can only cause the parent to resume by calling _exit() or execve() from * the child. Since I can't provide a real fork() on the Amiga, this function * is a third possibility to make the parent resume. You have then two * concurrent processes sharing the same frame and global data... Please be ! * EXTREMELY careful what you may do and what not. vfork2() itself is a hack, * this is an even greater one... + * + * DO NOT use this function in combination with vfork(), or you'll get a big + * memory leak. Only use it with vfork2(). * * Note that this function should really be static, but if you make it static ---------- cut here, patch to vfork.c ------------- -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue May 2 09:40:03 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <10098-3>; Sun, 30 Apr 1995 15:30:10 +0300 Received: by theseas.ntua.gr with UUCP; Sun, 30 Apr 1995 15:30:17 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06yf@kriton.UUCP>; Sat, 29 Apr 95 14:06:43 EET Date: Sat, 29 Apr 95 14:06:43 EET Message-Id: <9504291206.06yf@kriton.UUCP> In-Reply-To: (from DARKSTAR@DARKNESS.gun.de (Carsten Meyer)) (at Fri, 28 Apr 95 21:04:22 CET) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 889 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: DARKSTAR@DARKNESS.gun.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Bug in gnu/os-include/exec/tasks.h? Hi Carsten (Carsten Meyer), in on Apr 28 you wrote: > GNU:os-include/exec/tasks.h ? Works fine for me--I'm using the includes that come with SAS/C 6.55. ("Works fine" means that I was able to compile the following program without getting any errors or warnings: ----------------------- #include struct Task t; ----------------------- > void (*tc_Switch)(); /* task losing CPU */ > void (*tc_Launch)(); /* task getting CPU */ My version has: VOID (*tc_Switch)(); /* task losing CPU */ VOID (*tc_Launch)(); /* task getting CPU */ whitch should be equivalent. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I'm a knight-errant, not an errant fool!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue May 2 09:40:08 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <9822-2>; Sun, 30 Apr 1995 15:28:08 +0300 Received: by theseas.ntua.gr with UUCP; Sun, 30 Apr 1995 15:30:18 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <06ya@kriton.UUCP>; Sat, 29 Apr 95 14:00:55 EET Date: Sat, 29 Apr 95 14:00:55 EET Message-Id: <9504291200.06ya@kriton.UUCP> In-Reply-To: <95Apr28.191921+0100mesz.209163-1+281@hphalle0.informatik.tu-muenchen.de> (from Christian Stieber ) (at Fri, 28 Apr 1995 19:19:13 +0200 (MESZ)) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 710 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: stieber@informatik.tu-muenchen.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: createtask-problem : the programm Hi Christian (Christian Stieber), in <95Apr28.191921+0100mesz.209163-1+281@hphalle0.informatik.tu-muenchen.de> on Apr 28 you wrote: > > As a side note, this program does not work at all (it always prints 0) > > when compiled with SAS/C 6.55. > > Are you sure you turned off baserelative adressing? As an alternative, > you could add the __saveds keyword to the child task. Oops! I hadn't! I just tried the 6.55 equivalent of the 5.10 options suggested in the manual, and the example now works. Thanks, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I'm a knight-errant, not an errant fool!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue May 2 12:54:03 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <9821-3>; Tue, 2 May 1995 12:51:24 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id KAA01398; Tue, 2 May 1995 10:49:41 +0100 From: Lars Hecking Message-Id: <199505020951.KAA19356@mostar.nmrc.ucc.ie> Subject: Re: sh memory leak fixed. To: hans@wyst.hobby.nl (Hans Verkuil) Date: Tue, 2 May 1995 10:51:20 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9504301448.079j@wyst.hobby.nl> from "Hans Verkuil" at Apr 30, 95 03:48:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 672 > Included is a patch to jobs.c (pdksh-4.9) and to vfork.c in the > ixemul.library. The latter patch changes the comments only. The bug was > that the old (4.5) sh used the old vfork() function, which was renamed to > vfork2() a few months later by Markus Wild. If you recompile sh with the > new ixemul.library the wrong vfork() was used. This meant that lots of > malloc's were done using the parents memory list instead of that of the > client. So every time you run a program from the shell, you will get a > memory leak. And they add up fairly quickly! Works like a charm now with 4.5 (aminet). I'll try 4.9 later. It does not help with 5.1.3, though :( Lars From amiga-gcc-port-owner@nic.funet.fi Tue May 2 18:05:56 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <9374-1>; Tue, 2 May 1995 18:01:49 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26497-3>; Tue, 2 May 1995 17:01:18 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209197-2>; Tue, 2 May 1995 17:01:10 +0100 Subject: Re: Bug in gnu/os-include/exec/tasks.h? From: Christian Stieber To: darkstar@darkness.gun.de (Carsten Meyer) Date: Tue, 2 May 1995 17:00:59 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Carsten Meyer" at Apr 28, 95 09:04:22 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 757 Message-Id: <95May2.170110+0100mesz.209197-2+921@hphalle0.informatik.tu-muenchen.de> > Is there a bug in > > GNU:os-include/exec/tasks.h ? Hm.. never had any problems. > ... > /gnu/os-include/exec/tasks.h:47: parse error before `}' > ... > > Is it a bug? If yes why does nobody else had found it until now? I don't think it's a bug. Could you - tell us the compiler options - your source file up to the #include<...> - the output of gcc -v ...your options... ?? Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Tue May 2 18:12:27 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <9302-4>; Tue, 2 May 1995 18:06:53 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa06554; 2 May 95 16:05 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id ad04571; 2 May 95 16:05 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA006k3; Tue, 2 May 95 16:02:16 GMT Date: Tue, 2 May 95 16:02:16 GMT Message-Id: <9505021602.AA006k2@flevel.demon.co.uk> Message-Id: <209a1886.13883-dev@flevel.demon.co.uk> In-Reply-To: <199505020951.KAA19356@mostar.nmrc.ucc.ie> (from Lars Hecking ) (at Tue, 2 May 1995 10:51:20 +0100 (BST)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: bsdsocket.library & socket.library? Hi, I decided to do a bit of programming AmiTCP so I digged out some of my archives (AmiTCP 3.0b2 includes and link libraries) and found the link library was for SASC. After looking a bit further I found some docs for bsdsocket.library and a set of pragmas :-) However, I seem to have socket.library but not bsdsocket.library :-( I thought they may be the same thing, but some of the library calls just fall off the end of socket.library so it must be different. So, where do I either: a) Get the pragmas and docs for socket.library or b) Get bsdsocket.library Thanks in advance. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue May 2 20:33:22 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <9278-2>; Tue, 2 May 1995 20:29:27 +0300 Received: from yosemite.inesc.pt by inesc.inesc.pt with SMTP; id AA16893 (/); Tue, 2 May 1995 19:26:18 +0200 Received: by yosemite.inesc.pt (5.57/OSversion) id AA05903; Tue, 2 May 95 19:29:17 +0200 Date: Tue, 2 May 95 19:29:17 +0200 From: pmt@yosemite.inesc.pt (Pedro Miguel S. J. Teixeira) Message-Id: <9505021729.AA05903@yosemite.inesc.pt> To: amiga-gcc-port@nic.funet.fi Subject: bsdsocket.library or socket.library >>So, where do I either: >> a) Get the pragmas and docs for socket.library >> b) Get bsdsocket.library Obviously there is a major confusion around there! socket.library does NOT belong to the AmiTCP package! bsdsocket.library does. socket.library is from the Commodore pack AS225 (Argh!). The best thing you should do is get the last AmiTCP pack from aminet AND This includes a new part exclusively to gcc users (has a gcc link library inside confiled, ready to roll). - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Tue May 2 20:35:55 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <9311-3>; Tue, 2 May 1995 20:35:26 +0300 Received: from yosemite.inesc.pt by inesc.inesc.pt with SMTP; id AA17001 (/); Tue, 2 May 1995 19:31:37 +0200 Received: by yosemite.inesc.pt (5.57/OSversion) id AA05909; Tue, 2 May 95 19:34:38 +0200 Date: Tue, 2 May 95 19:34:38 +0200 From: pmt@yosemite.inesc.pt (Pedro Miguel S. J. Teixeira) Message-Id: <9505021734.AA05909@yosemite.inesc.pt> To: amiga-gcc-port@nic.funet.fi Subject: Stack Check and Context >> Are you sure you turned off baserelative adressing? Even more critical than forgeting to use absolute addressing or restore the data section base (A4) using __saveds, you' should NEVER use the stack check or stack extend options!!!! It causes major problems. When such peace of code starts to run out of the context it was loaded from, it check his USP, which returs a totaly idiotic value for that task.... - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Tue May 2 21:39:38 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <9746-3>; Tue, 2 May 1995 21:37:37 +0300 Received: from yosemite.inesc.pt by inesc.inesc.pt with SMTP; id AA20485 (/); Tue, 2 May 1995 20:34:44 +0200 Received: by yosemite.inesc.pt (5.57/OSversion) id AA05962; Tue, 2 May 95 20:37:45 +0200 Date: Tue, 2 May 95 20:37:45 +0200 From: pmt@yosemite.inesc.pt (Pedro Miguel S. J. Teixeira) Message-Id: <9505021837.AA05962@yosemite.inesc.pt> To: amiga-gcc-port@lists.funet.fi Subject: Virtual memory in gcc Acording to request from gcc's author, I post a result on test using gcc whith VMM3.0: I must say that gcc should be an example to all programers that DON'T respect Commodore guide-lines and common-sense when allocating code and data sppace. GCC works with ABSOLUTELY no problem in VMM. You may alow total use of it, since, including its CODE, everything can be swapped out. I made some dreadfull teste like using only 100Kb of phisical memory to map ALL GCC MEMORY, including program and data, and, after a couple of hours (!) the test was completed and the system was still 100% sane! I have a tiny in-kernel debugger which trigers a huge page of internal information each time a BERR might cause system insane. Such a page I never saw during the wole test... Before I forget, my system consists in: -A4000/030 w 68030@50MHz - 2Mb Chip RAM + 2Mb Fast RAM -GCC 2.6.3 (ixemul 40.4) -VMM 3.0 - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Wed May 3 11:29:46 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <9992-4>; Wed, 3 May 1995 11:27:01 +0300 Received: by tycho.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May3.112701+0300_eet_dst.9992-4+14@nic.funet.fi> From: To: Date: Wed, 3 May 1995 11:26:58 +0300 Date: Wed, 3 May 1995 10:26:41 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Error in GNU:os-include/inline/alib.h Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Error in GNU:os-include/inline/alib.h Hi, There is an error in GNU:os-include/inline/alib.h, it uses the keyword "asm" instead of "__asm", this causes lots of trouble when compiling with the option -ansi. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://wuarchive.wustl.edu:80/pub/aminet/priv/RILHP4.html | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed May 3 11:50:12 1995 Received: from dream.future.net ([204.130.134.1]) by nic.funet.fi with SMTP id <9317-2>; Wed, 3 May 1995 11:47:35 +0300 Received: (from tomthai@localhost) by dream.future.net (8.6.10/8.6.9) id DAA12890; Wed, 3 May 1995 03:41:19 -0500 Date: Wed, 3 May 1995 03:41:18 -0500 (CDT) From: "Tom T. Thai" To: amiga-gcc-port@nic.funet.fi Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe .............. .......................... Thomas T. Thai INFOMEDIA tom@future.net Interactive Communications From amiga-gcc-port-owner@nic.funet.fi Wed May 3 12:13:09 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <9309-2>; Wed, 3 May 1995 12:11:57 +0300 Received: from disperse.demon.co.uk by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HQ27KY2E7K0033FL@FIPORT.FUNET.FI>; Wed, 03 May 1995 09:12:04 +0200 (EET) Received: from post.demon.co.uk by disperse.demon.co.uk id aa10405; 3 May 95 10:09 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id aa11337; 3 May 95 10:05 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA006sa; Wed, 3 May 95 09:14:25 GMT Date: Wed, 03 May 1995 09:14:25 +0000 (GMT) From: dev@flevel.demon.co.uk Subject: Re: bsdsocket.library or socket.library In-reply-to: <9505021729.AA05903@yosemite.inesc.pt> (from "Pedro Miguel S. J. Teixeira" ) (at Tue, 2 May 95 19:29:17 +0200) To: pmt@yosemite.inesc.pt Cc: amiga-gcc-port@nic.funet.fi Message-id: <9505030914.AA006s9@flevel.demon.co.uk> Message-id: <209b0a6e.b98c0-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: Content-transfer-encoding: 7BIT Hi Pedro, > >>So, where do I either: > >> a) Get the pragmas and docs for socket.library > >> b) Get bsdsocket.library > > Obviously there is a major confusion around there! socket.library > does NOT belong to the AmiTCP package! bsdsocket.library does. > socket.library is from the Commodore pack AS225 (Argh!). The best Strange, socket.library came from the AmiTCP Dis (Demon Internet) installer?? > thing you should do is get the last AmiTCP pack from aminet AND > This includes a new part exclusively to gcc users (has a gcc link > library inside confiled, ready to roll). As long as it works with AmiTCP V3.0b2. Anyway, I found that the reason I didn't have bsdsocket.library in my libs: directory is because AmiTCP adds it to the system library list after you do a startnet (Stack As Shared Libraries). Stupid Me @-) Ive now got the Bsd Sockets working fine without any link libraries... What are the link libraries for in any case? Thanks for you help. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed May 3 16:24:41 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <9396-2>; Wed, 3 May 1995 16:22:24 +0300 Received: from yosemite.inesc.pt by inesc.inesc.pt with SMTP; id AA29777 (/); Wed, 3 May 1995 15:19:22 +0200 Received: by yosemite.inesc.pt (5.57/OSversion) id AA06502; Wed, 3 May 95 15:22:22 +0200 Date: Wed, 3 May 95 15:22:22 +0200 From: pmt@yosemite.inesc.pt (Pedro Miguel S. J. Teixeira) Message-Id: <9505031322.AA06502@yosemite.inesc.pt> To: amiga-gcc-port@nic.funet.fi Subject: Re: bsdsocket.library or socket.library >>What are the link libraries for in any case? When working with GCC, there are 2 ways to call shared libraries: 1- Use inline includes which substitute calls to a function to it's jsr _LVO...(A6). 2- Use link libraries which have stubbs for the shared libraries functions. Work like amiga.lib... A way to generate these link libraries is to compile the inline includes removing the static and inline statements... The link library that comes with amitcp for gcc has, therefore, stubs for bsdsocket.library plus a add to startup code which initialises SocketBase automaticaly. This way is a very confortable way to work with shared libraries since you don't have to wory about library_base, LVO's, param registers, etc... AmiTCP pack also includes sources to generate the same link libraries to work with SASC (libnet.lib). - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Thu May 4 00:05:37 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <9766-4>; Thu, 4 May 1995 00:00:04 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id VAA15760 for ; Wed, 3 May 1995 21:59:31 +0100 From: Lars Hecking Message-Id: <199505032101.WAA21114@mostar.nmrc.ucc.ie> Subject: dos/CreateNewProc() To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Wed, 3 May 1995 22:01:09 +0100 (BST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 120 A quickie tonite: ;) under which circumstances, besides low mem, may dos.library/CreateNewProc() fail? Slan, Lars From amiga-gcc-port-owner@nic.funet.fi Thu May 4 00:06:06 1995 Received: from blue.UnivNorthCo.EDU ([138.86.1.6]) by nic.funet.fi with SMTP id <10186-3>; Thu, 4 May 1995 00:00:44 +0300 Received: by blue.UnivNorthCo.EDU (AIX 3.2/UCB 5.64/4.03) id AA21782; Wed, 3 May 1995 15:00:15 -0600 Date: Wed, 3 May 1995 15:00:15 -0600 (MDT) From: Kenneth F Sauer To: amiga-gcc-port@nic.funet.fi Subject: unsubscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From amiga-gcc-port-owner@nic.funet.fi Thu May 4 03:53:26 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <9276-1>; Thu, 4 May 1995 03:52:27 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0s6poq-0004ndC; Wed, 3 May 95 18:35 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: dos/CreateNewProc() To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Wed, 3 May 1995 18:35:08 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199505032101.WAA21114@mostar.nmrc.ucc.ie> from "Lars Hecking" at May 3, 95 10:01:09 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 496 > A quickie tonite: ;) > under which circumstances, besides low mem, may dos.library/CreateNewProc() > fail? Don't know if it's relevant or not, since you don't mention why you are asking, but AmigaDOS won't run any executable when it has any single hunk that has more than 64K relocations. I stumbled over this when I did a port of GNU octave, and had to modify the linker to split hunks with excessive relocations into two ore more consecutive hunks with less than 64K relocations. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu May 4 11:19:05 1995 Received: from uci.agh.edu.pl ([149.156.96.9]) by nic.funet.fi with SMTP id <9293-1>; Thu, 4 May 1995 11:15:04 +0300 Received: from icslab.agh.edu.pl by uci.agh.edu.pl (8.6.10/ALLMAN-8.6.9) id KAA28318; Thu, 4 May 1995 10:14:55 +0200 Organization: University of Mining and Metallurgy Address: Mickiewicza 30, 30-059 Krakow, POLAND Received: by icslab.agh.edu.pl (4.1/SMI-4.1) id AA17926; Thu, 4 May 95 10:16:53 +0200 Date: Thu, 4 May 1995 10:16:53 +0200 (MET DST) From: Kamil Iskra Subject: GCC 2.6.3 bugs and questions To: amiga-gcc-port@lists.funet.fi Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I'm new on this group and I'm beginner in using GCC so I think you will find my questions pretty simple but at least I hope that my questions won't be stupid :-). I posted some of them to "comp.sys.amiga.programmer", but no one have answered :-(. BUGS: 1. When I compile this simple two-lines source: #include #include CPP produces the following warning: In file included from /gnu/include/stdlib.h:67, from bug.cxx:2: /gnu/include/sys/cdefs.h:55: warning: `__P' redefined /gnu/lib/g++-include/libio.h:62: warning: this is the location of the previous definition When I swap the lines in source, ie. first include , then , everything works well. 2. When I use "g++" to compile even very simple projects, it crashes the machine. It seems that "g++" overflows the stack, for increasing it manually (using "stack") to "100000" fixes the problem. But why "gcc" uses "GCCSTACK" environment variable and "g++" does not? Is it a bug or is it intentional? 3. When I compile this simple source: template void function(Type a) { char *str=" "; } void func() { int a; function(a); } It compiles well. But please try to change the space between double quotes to hardspace - GCC seems to output some stupid messages: bug.cxx: In function `void function(int)': bug.cxx:4: Unterminated string bug.cxx:11: parse error at end of input The problem is not only with hardspace - it seems that most (if not all) 8-bit ASCII characters causes GCC to fail when they are inside the templates. 4. When I compile this simple source with the default options: #include int main() { cout << 3.1415 << endl; cout << "abc\n"; return 0; } It compiles and runs well. But when I compile it with "-m68020", everything I get when I run it is a message: "EMT trap" - program aborts during first "<<". I don't have FPU, but I didn't set any options that would need it, so what's going on? I think that verbose-output might be helpful, so here it is: gcc -v -m68020 -o bug bug.cxx -lg++ Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Dmc68020 bug.cxx t:cc128864.ii GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/lib/g++-include /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1plus t:cc128864.ii -quiet -dumpbase bug.cc -m68020 -version -o t:cc128864.s GNU C++ version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3 snapshot 941209. as -mc68020 -o t:cc1288641.o t:cc128864.s ld -fl libm020 -o bug /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/local/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/gnu/lib -L/local/lib -L/local/lib t:cc1288641.o -lg++ -lgcc -lc -lgcc I thought that the problem might be somehow connected with the fact that I use "accelerated" version of gcc without FPU (more about it later) so I reinstalled 68000 version, but this didn't change anything. QUESTIONS: 1. Where is the documentation of GNU linker, 'LD'?! Is it not necessary? 2. "README-2.6.3" states that files from archives "...020" are "68020+68881" versions. Does it mean that I can't used them on A1200 without FPU? I thought so, but when I tried, everything seemed to work well (I was able to compile and run programs, even if they used floating point operations). 3. Does GCC really have to use so much stack? I personally don't like it and would prefer if it dynamically allocated needed memory. I have read that these huge stack requirements are caused by extensive usage of function "alloca()", which allocates memory directly on stack. I wonder if it would be possible to add one "#define" that would redirect every call to "alloca()" to our own function, which would simply perform "malloc()"? 4. Why GCC binaries are not pure (ie. they don't have "p" bit set")? I think that making them resident would make compilation slightly faster, especially when compiling projects consisting of many source files (no need to read these megabytes from HDD). 5. Is debug-output produced by the compiler compatible with anything? I know there is no GNU-debugger for the Amiga, but I've tried to use "FindHit" to find source of Enforcer/MungWall hits and was unsuccessful. Thank you for your attention. / Kamil Iskra - AMIGA 1200, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu May 4 11:31:34 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <9514-2>; Thu, 4 May 1995 11:29:38 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa29694; 4 May 95 9:29 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id ad16786; 4 May 95 9:28 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA006z7; Wed, 3 May 95 18:10:09 GMT Date: Wed, 3 May 95 18:10:09 GMT Message-Id: <9505031810.AA006z6@flevel.demon.co.uk> Message-Id: <209b8800.88b81-dev@flevel.demon.co.uk> In-Reply-To: <9505031322.AA06502@yosemite.inesc.pt> (from "Pedro Miguel S. J. Teixeira" ) (at Wed, 3 May 95 15:22:22 +0200) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: pmt@yosemite.inesc.pt Cc: amiga-gcc-port@nic.funet.fi Subject: Re: bsdsocket.library or socket.library Hi Pedro, > >>What are the link libraries for in any case? > > When working with GCC, there are 2 ways to > call shared libraries: > 1- Use inline includes which substitute > calls to a function to it's jsr _LVO...(A6). > 2- Use link libraries which have stubbs > for the shared libraries functions. Work like > amiga.lib... > A way to generate these link libraries > is to compile the inline includes removing the > static and inline statements... > > The link library that comes with > amitcp for gcc has, therefore, stubs for > bsdsocket.library plus a add to startup code > which initialises SocketBase automaticaly. > This way is a very confortable way > to work with shared libraries since you don't > have to wory about library_base, LVO's, > param registers, etc... > AmiTCP pack also includes sources > to generate the same link libraries to > work with SASC (libnet.lib). Right I see. What about using pragmas? Thanks for your help. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu May 4 13:35:37 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <9547-1>; Thu, 4 May 1995 13:32:55 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA20171; Thu, 4 May 1995 11:32:01 +0100 From: Lars Hecking Message-Id: <199505041033.LAA21507@mostar.nmrc.ucc.ie> Subject: Re: dos/CreateNewProc() To: fnf@amigalib.com (Fred Fish) Date: Thu, 4 May 1995 11:33:42 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Fred Fish" at May 3, 95 06:35:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 872 > > > A quickie tonite: ;) > > under which circumstances, besides low mem, may dos.library/CreateNewProc() > > fail? > > Don't know if it's relevant or not, since you don't mention why you are > asking, but AmigaDOS won't run any executable when it has any single > hunk that has more than 64K relocations. I stumbled over this when I > did a port of GNU octave, and had to modify the linker to split hunks > with excessive relocations into two ore more consecutive hunks with > less than 64K relocations. A german gcc user reported an error "make: vfork: too many prcesses". This is, presumably, from ixem40.4/library/vfork.c(_vfork), when CreateNewProc() fails (errno = EPROCLIM). I'll get more details soon. It happened during the make of ghostscript-3.33 w/ gcc-2.6.3. Btw, is ixem40.4-src from FreshFish the same _source_code as the archive from Aminet? From amiga-gcc-port-owner@nic.funet.fi Thu May 4 14:58:23 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <9469-2>; Thu, 4 May 1995 14:56:38 +0300 Received: by colombo.telesys-innov.fr; Thu, 4 May 1995 13:57:48 +0100 From: Philippe BRAND Message-Id: <199505041257.NAA02371@colombo.telesys-innov.fr> Subject: Re: dos/CreateNewProc() To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 4 May 1995 13:57:47 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199505041033.LAA21507@mostar.nmrc.ucc.ie> from "Lars Hecking" at May 4, 95 11:33:42 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 445 Lars Hecking writes: > Btw, is ixem40.4-src from FreshFish the same _source_code as the archive > from Aminet? BTW, when will new ixemul be ready ? I would really need it, with both stack checking and auto-extend, in order to build a gcc with those features... -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu May 4 17:45:05 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <9324-2>; Thu, 4 May 1995 17:42:34 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26578-4>; Thu, 4 May 1995 16:41:59 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209197-1>; Thu, 4 May 1995 16:41:43 +0100 Subject: Re: dos/CreateNewProc() From: Christian Stieber To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 4 May 1995 16:41:33 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199505032101.WAA21114@mostar.nmrc.ucc.ie> from "Lars Hecking" at May 3, 95 10:01:09 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 797 Message-Id: <95May4.164143+0100mesz.209197-1+2470@hphalle0.informatik.tu-muenchen.de> > A quickie tonite: ;) > under which circumstances, besides low mem, may dos.library/CreateNewProc() > fail? Failure to create/duplicate things such as stdin/stdout, CurrentDir etc. Probably depends a lot on the tags you pass in. Other than that, I can't imagine any other reason for CreateNewProc() to fail, but you must _always_ be prepared to handle failure --- dos/exec may do some internal stuff that you don't know about. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Thu May 4 17:57:20 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <9648-4>; Thu, 4 May 1995 17:54:16 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26578-1>; Thu, 4 May 1995 16:54:00 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209197-1>; Thu, 4 May 1995 16:53:47 +0100 Subject: Re: bsdsocket.library or socket.library From: Christian Stieber To: dev@flevel.demon.co.uk Date: Thu, 4 May 1995 16:53:43 +0200 (MESZ) Cc: pmt@yosemite.inesc.pt, amiga-gcc-port@nic.funet.fi In-Reply-To: <209b8800.88b81-dev@flevel.demon.co.uk> from "dev@flevel.demon.co.uk" at May 3, 95 06:10:09 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1746 Message-Id: <95May4.165347+0100mesz.209197-1+2476@hphalle0.informatik.tu-muenchen.de> > > A way to generate these link libraries > > is to compile the inline includes removing the > > static and inline statements... That's not a good idea. I always do it like this: SomeFunction.c: #if !defined(__OPTIMIZE__) #error This file must be compiled with -O #else #define SomeFunction InlinedSomeFunction #include xx (SomeFunction)(....) { return InlinedSomeFunction(....); } #endif /* __OPTIMIZE__ */ Create one .c file for every function. This works a lot better, since you get a separate .o file for every function. Just removing the "extern inline" stuff will always pull in all stubs. > Right I see. What about using pragmas? There is no need to implement this #pragma stuff (although it would be nice :)) since inline/asm() can be used instead. Implementing #pragma to generate the proper code to call shared libraries would mean additional hacking in GNU-C. IMHO -fbaserel should be fixed first :) (yes, I know, it's easy demand that. Give me some CPU horsepower and a large HD if you want me to take a look myself. I just don't have the resources :() The only problem is that library-bases have to be globally visible for the inline stuff to work --- you have to add another parameter to the functions if this is not what you want. Using __attribute__ or #pragma would make it possible to use any type of library base pointer (AFAICS). Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Thu May 4 17:59:09 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <10806-4>; Thu, 4 May 1995 17:56:35 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0s72zC-0004ndC; Thu, 4 May 95 08:38 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: dos/CreateNewProc() To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Thu, 4 May 1995 08:38:42 -0700 (MST) Cc: lhecking@nmrc.ucc.ie, amiga-gcc-port@nic.funet.fi In-Reply-To: <199505041257.NAA02371@colombo.telesys-innov.fr> from "Philippe BRAND" at May 4, 95 01:57:47 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 540 > > Btw, is ixem40.4-src from FreshFish the same _source_code as the archive > > from Aminet? No. > BTW, when will new ixemul be ready ? I would really need it, > with both stack checking and auto-extend, in order to build a gcc > with those features... I'm hoping to see a version 41.0 released in the next couple of weeks. I've integrated a number of bug fixes in the last week or so, and have been trying to reach Leonard Norrgard to resync with his work, since he has also made some significant improvements in the source. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu May 4 18:09:36 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <10162-1>; Thu, 4 May 1995 18:08:04 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26475-1>; Thu, 4 May 1995 17:07:26 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209197-2>; Thu, 4 May 1995 17:07:18 +0100 Subject: Re: GCC 2.6.3 bugs and questions From: Christian Stieber To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Thu, 4 May 1995 17:07:13 +0200 (MESZ) Cc: amiga-gcc-port@lists.funet.fi In-Reply-To: from "Kamil Iskra" at May 4, 95 10:16:53 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1251 Message-Id: <95May4.170718+0100mesz.209197-2+2514@hphalle0.informatik.tu-muenchen.de> > 4. Why GCC binaries are not pure (ie. they don't have "p" bit set")? I > think that making them resident would make compilation slightly > faster, especially when compiling projects consisting of many source > files (no need to read these megabytes from HDD). The problem is that -resident requires -fbaserel. And -fbaserel ist currently broken (it doesn't work properly with all GNU-C versions after 2.3.3). Apparently that's the only reason why Fred Fish still has a gcc-2.3.3 on this CDs. > 5. Is debug-output produced by the compiler compatible with anything? > I know there is no GNU-debugger for the Amiga, but I've tried to use > "FindHit" to find source of Enforcer/MungWall hits and was > unsuccessful. Hm.. I didn't try FindHit yet, but an assembler debugger knows about function names and some variable names. So the debugging stuff must be compatible to "something" :) Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Thu May 4 21:22:43 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <10076-1>; Thu, 4 May 1995 21:20:26 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 4 May 95 20:19 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 4 May 95 20:16 MET DST Message-Id: Subject: no subject (file transmission) To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 4 May 1995 20:16:43 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 4160 TABLE OF CONTENTS debug.lib/KCmpStr *ixemul* debug.lib/KGetChar debug.lib/KGetNum debug.lib/KMayGetChar debug.lib/KPrintF *done* debug.lib/KPutChar *done* debug.lib/KPutStr *untested* debug.lib/KCmpStr debug.lib/KCmpStr NAME KCmpStr - compare two null terminated strings SYNOPSIS mismatch = KCmpStr(string1, string2) D0 A0 A1 FUNCTION string1 is compared to string2 using the ASCII coalating sequence. 0 indicates the strings are identical. debug.lib/KGetChar debug.lib/KGetChar NAME KGetChar - get a character from the console (defaults to the serial port at 9600 baud) SYNOPSIS char = KGetChar() D0 FUNCTION busy wait until a character arrives from the console. KGetChar is the assembly interface, _KGetChar and _kgetc are the C interfaces. debug.lib/KGetNum debug.lib/KGetNum NAME KGetNum - get a number from the console SYNOPSIS number = KGetNum() D0 FUNCTION get a signed decimal integer from the console. This will busy wait until the number arrives. REMARK: GURU-BOOK says "charakters can be erase with BS ($08)" and "input and with CR ($0D)" debug.lib/KMayGetChar debug.lib/KMayGetChar NAME KMayGetChar - return a character if present, but don't wait (defaults to the serial port at 9600 baud) SYNOPSIS flagChar = KMayGetChar() D0 FUNCTION return either a -1, saying that there is no character present, or whatever character was waiting. KMayGetChar is the assembly interface, _KMayGetChar is the C interface. debug.lib/KPrintF debug.lib/KPrintF NAME KPrintF - print formatted data to the console (defaults to the serial port at 9600 baud) SYNOPSIS KPrintF("format string",values) A0 A1 FUNCTION print a formatted C-type string to the console. See the exec RawDoFmt() call for the supported % formatting commands. INPUTS "format string" - A C style string with % commands to indicate where paramters are to be inserted. values - A pointer to an array of paramters, to be inserted into specified places in the string. KPutFmt and KPrintF are identical assembly interfaces that want the two pointers in registers. _KPrintF and _kprintf are C interfaces that expect the format string pointer on the stack, and the paramters on the stack above that. SEE ALSO exec.library/RawDoFmt, any C compiler's "printf" call. _KPrintF: MOVE.L 4(SP),A0 LEA 8(SP),A1 KPutFmt: MOVEM.L A2,-(SP) LEA KPutChar(PC),A2 BSR.S KDoFmt MOVEM.L (SP)+,A2 RTS KDoFmt: MOVE.L A6,-(SP) MOVE.L 4,A6 JSR -522(A6) MOVE.L (SP)+,A6 RTS debug.lib/KPutChar debug.lib/KPutChar NAME KPutChar - put a character to the console (defaults to the serial port at 9600 baud) SYNOPSIS char = KPutChar(char) D0 D0 FUNCTION Put a character to the console. This function will not return until the character has been completely transmitted. INPUTS KPutChar is the assembly interface, the character must be in D0. _KPutChar and _kputc are the C interfaces, the character must be a longword on the stack. KPutChar: MOVE.L A6,-(SP) MOVE.L 4,A6 JSR -516(A6) MOVE.L (SP)+,A6 RTS debug.lib/KPutStr debug.lib/KPutStr NAME KPutStr - put a string to the console (defaults to the serial port at 9600 baud) SYNOPSIS KPutStr(string) A0 FUNCTION put a null terminated string to the console. This function will not return until the string has been completely transmitted. INPUTS KPutStr is the assembly interface, a string pointer must be in A0. _KPutStr and _kputs are the C interfaces, the string pointer must be on the stack. KPUTSTR: move.l a6,-(sp) move.l 4,a6 tst (a0) beq ende weiter: move.b (a0)+,d0 jsr -516(a6) ; a0 wird hoffendlich nicht veraendert tst (a0) bne weiter ende: move.l (sp)+,a6 rts From amiga-gcc-port-owner@nic.funet.fi Thu May 4 22:36:04 1995 Received: from evitech.evitech.fi ([193.64.220.1]) by nic.funet.fi with SMTP id <9471-2>; Thu, 4 May 1995 22:34:51 +0300 Received: by evitech.evitech.fi (1.37.109.4/16.2) id AA00941; Thu, 4 May 95 22:36:04 +0200 Date: Thu, 4 May 1995 22:36:04 +0200 (EET) From: Mika Kuoppala Subject: unsubscribe To: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From amiga-gcc-port-owner@nic.funet.fi Fri May 5 16:04:37 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <9390-3> convert rfc822-to-8bit; Fri, 5 May 1995 16:00:05 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa09248; 5 May 95 13:56 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id aa18371; 5 May 95 13:56 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA007f2; Fri, 5 May 95 09:50:20 GMT Date: Fri, 5 May 95 09:50:20 GMT Message-Id: <9505050950.AA007f1@flevel.demon.co.uk> Message-Id: <209db5da.d1f61-dev@flevel.demon.co.uk> In-Reply-To: (from Mika Kuoppala ) (at Thu, 4 May 1995 22:36:04 +0200 (EET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Socket Timeout? Does anyone know how I can wait for data to arrive at a socket for upto a certain time limit? At the moment I'm doing this by making the socket non-blocking and then polling every 4/50th of a second, I guess there must be a better way. Something like the Amiga's WaitForChar function would be great. Any ideas? BTW - Please could people not post their unsubscribes to the list, it just wastes band width and fills up our mailboxes! Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri May 5 16:31:07 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <9587-3>; Fri, 5 May 1995 16:28:45 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA01329; Fri, 5 May 1995 14:28:28 +0100 Date: Fri, 5 May 1995 14:29:03 +0100 (BST) From: Peter Ivimey-Cook To: dev@flevel.demon.co.uk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Socket Timeout? In-Reply-To: <9505050950.AA007f1@flevel.demon.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 5 May 1995 dev@flevel.demon.co.uk wrote: > Does anyone know how I can wait for data to arrive at a socket for upto > a certain time limit? > > At the moment I'm doing this by making the socket non-blocking and then > polling every 4/50th of a second, I guess there must be a better way. Try using the function select() - it takes a bitmap of file descriptors for read, for write and for other things and a timeout value. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Sat May 6 22:18:16 1995 Received: from VIRGO.BSUVC.BSU.EDU ([147.226.56.55]) by nic.funet.fi with ESMTP id <136714-3>; Sat, 6 May 1995 21:59:28 +0300 Received: from BSUVC.bsu.edu by BSUVC.bsu.edu (PMDF V4.3-7 #6522) id <01HQ6KSHWG928WYBT3@BSUVC.bsu.edu>; Sat, 6 May 1995 12:29:36 EST Date: Sat, 06 May 1995 12:29:36 -0500 (EST) From: 00palundy@bsuvc.bsu.edu Subject: 2.6.3 install help Sender: 00PALUNDY@bsuvc.bsu.edu To: amiga-gcc-port@lists.funet.fi Reply-to: 00palundy@bsuvc.bsu.edu Message-id: <01HQ6KSHWG948WYBT3@BSUVC.bsu.edu> X-VMS-To: IN%"amiga-gcc-port@lists.funet.fi" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I just installed 2.6.3 c and c++ versions. I got them from AMinet5 CD. I have an A4000/040. an A4000/040. I tried using the GCC install program which seemed to work. When I try the following, I get some error: #include int main() { cout << "+--+" << endl << "+ +" << endl << "+ +" << endl << "+--+" << endl; return 0; } c++ -o test.c /gnu/lib/crt0.o Undefined symbol _main referenced from text segment g++ -o test.c same result # includ #include main() { printf ("Hello world!\n"); } gcc -o hello.c hello gcc: hello: No such file or directory gcc: no input files gcc -o hello hello.c cpp: Usage: cpp [switches] input output I'm guessing something is not in the right location. (the first # inclu isn't really there. I couldn't delete it from the mail program. oops.) Did I get a BAD file? The stack was set to 100000. the sh gnu/s/restorelinks file was not in the archive, can this be a problem. The readme said to do this. Pete Lundy 00palundy@leo.bsuvc.bsu.edu From amiga-gcc-port-owner@nic.funet.fi Sat May 6 22:19:30 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <92056-1>; Sat, 6 May 1995 17:44:38 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa23964; 6 May 95 13:26 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id ab29862; 6 May 95 13:26 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA007fm; Fri, 5 May 95 16:16:34 GMT Date: Fri, 5 May 95 16:16:34 GMT Message-Id: <9505051616.AA007fl@flevel.demon.co.uk> Message-Id: <209e1061.0-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Sun NFS for Amiga? I know this is a bit off topic but I think someone on this list will know. Is there a version of the Sun NFS for AmiTCP? I have an Amiga on a TCP/IP network and would like to share drives. Thanks in advance. Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Sat May 6 22:20:49 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <92057-3> convert rfc822-to-8bit; Sat, 6 May 1995 17:44:38 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa23952; 6 May 95 13:26 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id aa29862; 6 May 95 13:26 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA007fh; Fri, 5 May 95 15:53:58 GMT Date: Fri, 5 May 95 15:53:58 GMT Message-Id: <9505051553.AA007fg@flevel.demon.co.uk> Message-Id: <209e0b15.493e0-dev@flevel.demon.co.uk> In-Reply-To: (from Peter Ivimey-Cook ) (at Fri, 5 May 1995 14:29:03 +0100 (BST)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT From: dev@flevel.demon.co.uk To: Peter.Ivimey-Cook@isltd.insignia.com Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Socket Timeout? Hi Peter, > > Does anyone know how I can wait for data to arrive at a socket for upto > > a certain time limit? > > > > At the moment I'm doing this by making the socket non-blocking and then > > polling every 4/50th of a second, I guess there must be a better way. > > Try using the function select() - it takes a bitmap of file descriptors > for read, for write and for other things and a timeout value. Ah, I was looking at that but I couldn't work out what the bitmap was meant to be. Now you say it's a bitmap of file descriptors I understand :-) Thanks. Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Sun May 7 09:42:36 1995 Received: from zaz.kom.auc.dk ([130.225.51.10]) by nic.funet.fi with SMTP id <98525-4>; Sun, 7 May 1995 09:40:49 +0300 Received: from skoda.kom.auc.dk by zaz.kom.auc.dk with smtp (Smail3.1.29.1 #3) id m0s8013-000DKcC; Sun, 7 May 95 08:40 MET DST Received: by skoda.kom.auc.dk (Smail3.1.29.1 #3) id m0s8013-0008JzC; Sun, 7 May 95 08:40 MET DST Message-Id: Date: Sun, 7 May 95 08:40 MET DST From: jds@kom.auc.dk (Jes Degn Soerensen) To: dev@flevel.demon.co.uk Cc: amiga-gcc-port@nic.funet.fi Subject: Sun NFS for Amiga? In-Reply-To: <9505051616.AA007fl@flevel.demon.co.uk>, <209e1061.0-dev@flevel.demon.co.uk> References: <9505051616.AA007fl@flevel.demon.co.uk> <209e1061.0-dev@flevel.demon.co.uk> dev@flevel.demon.co.uk writes: > I know this is a bit off topic but I think someone on this list will know. > > Is there a version of the Sun NFS for AmiTCP? > > I have an Amiga on a TCP/IP network and would like to share drives. Well there is an NFS implementation in AmiTCP, isn't that a SUN NFS port? I have tried it against a Linux/386 machine and it works fine (we did not enable the PCNFS demon). Jes From amiga-gcc-port-owner@nic.funet.fi Mon May 8 15:13:55 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <10945-3>; Mon, 8 May 1995 15:01:15 +0300 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id OAA16730 (8.6.12/7.4b-FAU);; Mon, 8 May 1995 14:01:00 +0200 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA20952; Mon, 8 May 1995 14:00:57 +0200 Date: Mon, 8 May 1995 14:00:57 +0200 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9505081200.AA20952@pctc.chemie.uni-erlangen.de> To: 00palundy@bsuvc.bsu.edu Cc: amiga-gcc-port@lists.funet.fi In-Reply-To: <01HQ6KSHWG948WYBT3@BSUVC.bsu.edu> (00palundy@bsuvc.bsu.edu) Subject: Re: 2.6.3 install help Hello, as far as I know you have to daclare main() as int main (int argc, char **argv) because C++ is type specific and requires ANSI declarations. Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Tue May 9 10:41:32 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <110665-1>; Tue, 9 May 1995 10:39:03 +0300 Received: from freenet-a.fim.uni-erlangen.de by uni-erlangen.de with SMTP; id AA15562 (5.65c-7/7.3w-FAU); Tue, 9 May 1995 09:38:56 +0200 Received: by fim.uni-erlangen.de; id AA19532 (4.1/7.3r-FAU); Tue, 9 May 95 09:37:51 +0200 Date: Tue, 9 May 95 09:37:51 +0200 Message-Id: <9505090737.AA19532@freenet-a.fim.uni-erlangen.de> From: cu154@fim.uni-erlangen.de (Federico Di Gregorio) To: amiga-gcc-port@lists.funet.fi Subject: Unix, sockets and AmiTCP Reply-To: cu154@fim.uni-erlangen.de Hi everybody. I'm porting a little nice mud driver to the amiga and i need socket support. I tought to use AmiTCP (v3.0b) but I have some problems. Using the inlines works good but when I run the program and I telnet, nothing happens after the connection. The program uses the same functions (i.e., open(), ioctl(), etc.) for files and sockets... !? :( Can someone give me some hints about using AmiTCP and gcc togheter? Thank you. -- *-=< Federico Di Gregorio cu154@fim.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Tue May 9 11:58:40 1995 Received: from www.utbm.fr ([193.48.246.2]) by nic.funet.fi with ESMTP id <136787-3>; Tue, 9 May 1995 11:54:57 +0300 Received: from (news@localhost) by www.utbm.fr (8.6.10/jtpda-5.1) id KAA07303 for ; Tue, 9 May 1995 10:55:09 +0100 From: Rene.Garcia@utbm.fr Received: from sunserv.ipse.fr(193.48.202.1) by www.utbm.fr via smap (V1.3) id sma007299; Tue May 9 10:55:08 1995 Received: from sun1.IPSe.fr by sunserv.ipse.fr (5.x/SMI-SVR4) id AA08462; Tue, 9 May 1995 10:54:19 +0100 Received: by sun1.IPSe.fr (5.x/SMI-SVR4) id AA05167; Tue, 9 May 1995 10:52:50 +0100 Date: Tue, 9 May 1995 10:52:50 +0100 Message-Id: <9505090952.AA05167@sun1.IPSe.fr> To: amiga-gcc-port@nic.funet.fi Subject: AmiTCP sockets, UNIX, NFS X-Sun-Charset: US-ASCII Hi, I was on holliday this last week and I didn't see that you where talking about AmiTCP. I've worked on this question with GNU C 2.6.3 and this is what I have done : - Opening bsdsocket.library and initialisation can be done using a set element and adding it to the libauto.a, since it does the same thing than the autoopen routines of SAS/C. - read(), write(), close(),... have to be rewriten to support sockets. You can use sockets only with revc() and send(). I'm working on it now (Help is welcome). net.lib sources for SAS/C can't be compiled for GNU/C since they use AmigaDOS Open() Read(),...routines. I can use sockets as long as I don't use level 1 I/O routines. If you want to have some details about my configuration (if you have problems using AmiTCP/IP 3.0b2) ask me. Currently I am using an A1200 + 68030 + 68882 + VMM 3.0 + AmiTCP 3.0b2 + MultiuserFS and everything seems to work fine. Answer to Trefor S. ~~~~~~~~~~~~~~~~~~~ Did you try using AmiNSF, documentation tells that it is SUN NFS 2.0 compatible. I cannot try it since I have no SUN :( AmiNFS is part of AmiTCP 3.0b2 user pack. Regards, Rene From amiga-gcc-port-owner@nic.funet.fi Tue May 9 12:52:49 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <101251-4>; Tue, 9 May 1995 12:50:52 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA17656; Tue, 9 May 1995 10:50:47 +0100 Date: Tue, 9 May 1995 10:51:35 +0100 (BST) From: Peter Ivimey-Cook To: Federico Di Gregorio Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Unix, sockets and AmiTCP In-Reply-To: <9505090737.AA19532@freenet-a.fim.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 9 May 1995, Federico Di Gregorio wrote: > I'm porting a little nice mud driver to the amiga and i need socket > support. I tought to use AmiTCP (v3.0b) but I have some problems. Using the > inlines works good but when I run the program and I telnet, nothing happens > after the connection. The program uses the same functions (i.e., open(), > ioctl(), etc.) for files and sockets... !? :( > Can someone give me some hints about using AmiTCP and gcc togheter? > Thank you. I guess the problem is that you're using ixemul.library, which includes open/close/select etc calls which know nothing about networking. So if you use AmiTCP functions, they'll work on networking but ot files, and ixemul works on files not networking. I'm (slowly) trying to integrate the two, but it's a BIG task and I'm quite busy with other things. Joe Locash was also working on this; I'm not sure where he got to. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Tue May 9 18:17:39 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <80839-4>; Tue, 9 May 1995 18:13:36 +0300 Received: from yosemite.inesc.pt by inesc.inesc.pt with SMTP; id AA10862 (/); Tue, 9 May 1995 17:09:50 +0200 Received: by yosemite.inesc.pt (5.57/OSversion) id AA14125; Tue, 9 May 95 17:12:54 +0200 Date: Tue, 9 May 95 17:12:54 +0200 From: pmt@yosemite.inesc.pt (Pedro Miguel S. J. Teixeira) Message-Id: <9505091512.AA14125@yosemite.inesc.pt> To: amiga-gcc-port@nic.funet.fi >Can someone give me some hints about using AmiTCP and gcc togheter? Well, the port from SASC libs is not a very hard thing. to do! Anyway there is a pack in AmiNET which contains 2 libs: libamitcp.a and libsana.a. The first one should solve your problem directly. Linking with these libs you dont have to use libauto or any kind of method to solve bsdsocket.library open and LVO. All this (including a startup code that opens the lib) is inside the link lib and works automaticaly. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Tue May 9 19:11:39 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <104587-4>; Tue, 9 May 1995 19:09:33 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa20602; 9 May 95 17:05 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id aa07391; 9 May 95 17:05 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA007pc; Tue, 9 May 95 10:21:03 GMT Date: Tue, 9 May 95 10:21:03 GMT Message-Id: <9505091021.AA007pb@flevel.demon.co.uk> Message-Id: <20a3030e.222e1-dev@flevel.demon.co.uk> In-Reply-To: <9505090737.AA19532@freenet-a.fim.uni-erlangen.de> (from Federico Di Gregorio ) (at Tue, 9 May 95 09:37:51 +0200) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: cu154@fim.uni-erlangen.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Unix, sockets and AmiTCP Hi Federico, > I'm porting a little nice mud driver to the amiga and i need socket > support. I tought to use AmiTCP (v3.0b) but I have some problems. Using the > inlines works good but when I run the program and I telnet, nothing happens > after the connection. The program uses the same functions (i.e., open(), > ioctl(), etc.) for files and sockets... !? :( > Can someone give me some hints about using AmiTCP and gcc togheter? I just got GNU C working with AmiTCP myself. Basically you just compile using the standard GCC V2.6.3 includes (Don't use the inlines) and then link with the AmiTCP/GCC link library (which is on aminet). I hope that helps. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed May 10 11:30:08 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <101251-4>; Wed, 10 May 1995 11:26:33 +0300 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id KAA11317 (8.6.12/7.4b-FAU); for ; Wed, 10 May 1995 10:26:23 +0200 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA13367; Wed, 10 May 1995 10:26:21 +0200 Date: Wed, 10 May 1995 10:26:21 +0200 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9505100826.AA13367@pctc.chemie.uni-erlangen.de> To: amiga-gcc-port@nic.funet.fi Subject: problem with large files Hello, Excuse me, I know the following may not belong to this list. But I have a serious problem with large files and I know there are some people very familar with the AmigaDOS. Curently I want to install the sc655patch, but it always hangs up if it tries to decompress and patch sccxx.library. This happens also if I install the original SAS/C 6.50 version. First I thaught it is a stack problem or a installer problem. But it isn't. I decompressed sccxx.library by hand and called the spatch by hand, also. It works fine on RAM: disk. Then I tried to copy the new scxx.library to my HD and the AMIGA hangs up. I tried with the AmigaDOS command, from csh with its builtin cp and with the cp command from gcc263. The latter is the worst of them. It made the HD partition invalid and I had to validate it with disksalv. For the next try I packed the sccxx.library -- it has 583412 Bytes -- with lha -- it results in an archive with about 225 KBytes-- and it is no problem to copy it to the HD. But if I call lha to unpack the archive on the HD the Amiga hangs up in the middle of the archive (always, I tried it some times). Unpacking to the RAM: disk works always fine. A similar behavior I found while I installed gcc263 with the C++preprocessor which is a very large file too, but there the trick with lha worked. Guessing from my mind, I believe there was no problem if I used gzip, but I am not shure. I hope there is anybody who can give me some hints. My system is: Amiga 2000, 68030 board from Commo, GVP SCSI-II controller, FASTprep version 4.15, 420 MB SCSI HD from Quantum with 5 partitions, 7MB RAM, AmigaDOS 3.1 Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Wed May 10 12:45:20 1995 Received: from gryzmak.pdi.lodz.pl ([193.59.40.129]) by nic.funet.fi with SMTP id <136855-2>; Wed, 10 May 1995 12:43:52 +0300 Received: (from robert@localhost) by gryzmak.pdi.lodz.pl (8.6.10/1.33) id LAA01879; Wed, 10 May 1995 11:41:21 +0200 Date: Wed, 10 May 1995 11:41:21 +0200 (MET DST) From: Robert Ramiega To: "Pedro Miguel S. J. Teixeira" cc: amiga-gcc-port@nic.funet.fi Subject: Re: your mail In-Reply-To: <9505091512.AA14125@yosemite.inesc.pt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 9 May 1995, Pedro Miguel S. J. Teixeira wrote: > Well, the port from SASC libs is not a very hard thing. > to do! Anyway there is a pack in AmiNET which contains 2 libs: > libamitcp.a and libsana.a. The first one should solve your > problem directly. Well i might be blind but can someone tell me the exact location of this files on aminet (and archive name of course) BTW: are they AmiTCP 3.0b only or can they be used with AmiTCP 4.0Demo > > - Pedro Teixeira - > Kind regards Robert R. +-------------------------------------------------------------------------+ | Robert Ramiega PDi (Public Internet Access) | | E-Mail: robert@pdi.lodz.pl IRC: _robert_ (#amiga) | +-------------------------------------------------------------------------+ | /// Amiga: The computer for the creative mind. /// | | __/// You get more fun per MHz! __/// | | \XX/ Only Amiga makes it possible. \XX/ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed May 10 14:02:36 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <127667-4>; Wed, 10 May 1995 14:00:57 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA06871; Wed, 10 May 1995 11:59:47 +0100 From: Lars Hecking Message-Id: <199505101101.MAA26575@mostar.nmrc.ucc.ie> Subject: Re: problem with large files To: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Date: Wed, 10 May 1995 12:01:32 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9505100826.AA13367@pctc.chemie.uni-erlangen.de> from "Thomas Walter" at May 10, 95 10:26:21 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 548 > It works fine on RAM: disk. Then I tried to copy the new scxx.library to > my HD and the AMIGA hangs up. I tried with the AmigaDOS command, from > csh with its builtin cp and with the cp command from gcc263. > > The latter is the worst of them. It made the HD partition invalid and > I had to validate it with disksalv. I found that /bin/cp _always_ crashes my machine if stack is less than 32k. Bear that in mind for 'sh ./configure'! Sorry, can't help with the other stuff, but it seems like a GVP/MaxTransfer problem to me. Lars From amiga-gcc-port-owner@nic.funet.fi Wed May 10 17:32:32 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <85178-3>; Wed, 10 May 1995 17:29:12 +0300 Received: from yosemite.inesc.pt by inesc.inesc.pt with SMTP; id AA07563 (/); Wed, 10 May 1995 16:25:51 +0200 Received: by yosemite.inesc.pt (5.57/OSversion) id AA15014; Wed, 10 May 95 16:28:55 +0200 Date: Wed, 10 May 95 16:28:55 +0200 From: pmt@yosemite.inesc.pt (Pedro Miguel S. J. Teixeira) Message-Id: <9505101428.AA15014@yosemite.inesc.pt> To: amiga-gcc-port@nic.funet.fi Subject: RE: problem with large files Thomas Walter wrote: >serious problem with large files... >Amiga 2000, 68030 board... You don't happen to be using VMM, are you ? - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Wed May 10 17:44:02 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <103918-2>; Wed, 10 May 1995 17:41:50 +0300 Received: from yosemite.inesc.pt by inesc.inesc.pt with SMTP; id AA08204 (/); Wed, 10 May 1995 16:38:22 +0200 Received: by yosemite.inesc.pt (5.57/OSversion) id AA15034; Wed, 10 May 95 16:41:27 +0200 Date: Wed, 10 May 95 16:41:27 +0200 From: pmt@yosemite.inesc.pt (Pedro Miguel S. J. Teixeira) Message-Id: <9505101441.AA15034@yosemite.inesc.pt> To: amiga-gcc-port@nic.funet.fi Subject: amitcp_gcc on AmiNET Robert R wrote : >Well i might be blind but can someone tell me the exact location of this >files on aminet (and archive name of course) Well, I understand you are using V3 of AmiTCP. I'm using ver 2.3 so, when I took the pack from Aminet it was on: phoenix.doc.ic.ac.uk /computing/systems/amiga/comm/net amitcp2.x_gcc.lha I supose there must be a pack something like amitcp3.x_gcc.lha ... by now. If it doesn't try using this one. If it doesn't work nag the writer! ... well, it's good enough as a start point... - Pedro Miguel Teixeira - From amiga-gcc-port-owner@nic.funet.fi Wed May 10 19:05:48 1995 Received: from gryzmak.pdi.lodz.pl ([193.59.40.129]) by nic.funet.fi with SMTP id <126170-3>; Wed, 10 May 1995 19:00:46 +0300 Received: (from robert@localhost) by gryzmak.pdi.lodz.pl (8.6.10/1.33) id SAA17685; Wed, 10 May 1995 18:00:07 +0200 Date: Wed, 10 May 1995 18:00:06 +0200 (MET DST) From: Robert Ramiega To: "Pedro Miguel S. J. Teixeira" cc: amiga-gcc-port@nic.funet.fi Subject: Re: amitcp_gcc on AmiNET In-Reply-To: <9505101441.AA15034@yosemite.inesc.pt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 10 May 1995, Pedro Miguel S. J. Teixeira wrote: > > Robert R wrote : > >Well i might be blind but can someone tell me the exact location of this > >files on aminet (and archive name of course) > > Well, I understand you are using V3 of AmiTCP. I'm using ver 2.3 Nope. I'm using 4.0 demo right now. > so, when I took the pack from Aminet it was on: > > phoenix.doc.ic.ac.uk > /computing/systems/amiga/comm/net > amitcp2.x_gcc.lha > > I supose there must be a pack something like amitcp3.x_gcc.lha ... > by now. There is no such file and AFAIK there never was. > If it doesn't try using this one. If it doesn't work nag the writer! Ok. I'll try this one. Thanks! > > ... well, it's good enough as a start point... > > > > - Pedro Miguel Teixeira - > BTW: Sometime ago there was posting on this list with URL to gcc libraries for AmiTCP 4.0. When I tried that URL i got message that I dont have permission to get it. What I want to ask is: did someone succeded in getting those files? (and sorry but i dont remeber that URL :( ) regards Robert +-------------------------------------------------------------------------+ | Robert Ramiega PDi (Public Internet Access) | | E-Mail: robert@pdi.lodz.pl IRC: Jedi (#amiga) | +-------------------------------------------------------------------------+ | /// Amiga: The computer for the creative mind. /// | | __/// You get more fun per MHz! __/// | | \XX/ Only Amiga makes it possible. \XX/ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed May 10 19:30:04 1995 Received: from braae.ru.ac.za ([146.231.129.15]) by nic.funet.fi with SMTP id <9376-1>; Wed, 10 May 1995 19:28:54 +0300 Received: (g91b8620@localhost) by braae.ru.ac.za (8.6.8/Braae-1.0) id SAA05140 for amiga-gcc-port@nic.funet.fi; Wed, 10 May 1995 18:28:19 +0200 From: Simon Barratt Message-Id: <199505101628.SAA05140@braae.ru.ac.za> Subject: Re: AmiTCP and gcc To: amiga-gcc-port@nic.funet.fi Date: Wed, 10 May 1995 18:28:17 +0200 (SAT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 710 Hi there I realise that this must be a very tired topic, but here goes... Could somebody please explain where exactly gcc and the libraries that come with it fall down when it comes to using AmiTCP? What's missing etc. Then, Why can't (I assume you can't since veryone says you can't) use the C= Developers kit with gcc without fiddling. Some REAL detail here would be good - I've studied compilers etc, but not the Amiga :) If this topic has already been discussed and anyone has the discussion, please could they mail it to me to save the rest of the group the tedious re-read of old post. Many thanks Simon Barratt csnb@cs.ru.ac.za Dept Computer Science Rhodes University Grahamstown South Africa From amiga-gcc-port-owner@nic.funet.fi Wed May 10 19:54:01 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <10195-3>; Wed, 10 May 1995 19:52:22 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA27540; Wed, 10 May 1995 17:52:10 +0100 Date: Wed, 10 May 1995 17:52:52 +0100 (BST) From: Peter Ivimey-Cook To: Simon Barratt Cc: amiga-gcc-port@nic.funet.fi Subject: Re: AmiTCP and gcc In-Reply-To: <199505101628.SAA05140@braae.ru.ac.za> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 10 May 1995, Simon Barratt wrote: > Could somebody please explain where exactly gcc and the libraries > that come with it fall down when it comes to using AmiTCP? > > What's missing etc. > > Then, Why can't (I assume you can't since veryone says you can't) > use the C= Developers kit with gcc without fiddling. The problems are: a) gcc uses it's own object module and library format, so lots of the GNU tools don't have to change too. b) gcc uses ixemul by default, which is not compatible directly with the SAS libraries supplied with AmiTCP. a) is just a design decision, and indeed there are tools to convert. (b) is harder to see; basically the SAS AmiTCP libraries assume the environment of SAS/C, complete with references to the SAS FILE structure internals and the functions which aren't in SAS or which need to be patched to work with AmiTCP. In addition, the netincludes supplied with the AmiTCP port include many items and structure definitions which are also defined in gcc, albeit differently, resulting in a very confised compiler if you mix them. Unfortunately, a simplistic port (recompile with the right -I directives) fails for two reasons; the includes are wrong, and even if they were matched, the SAS-directed library patches the wrong things. Resulting in an executable which will fail to operate as expected (it might work OK, or it might not - depends what you call & when). What is needed is a new library - take out the duplicate definitions, patch the right functions and remake the library for gcc. Does this help? Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Wed May 10 23:53:01 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <136837-1>; Wed, 10 May 1995 23:50:04 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa26374; 10 May 95 19:27 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id aa03939; 10 May 95 19:27 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA0004t; Wed, 10 May 95 15:15:32 GMT Date: Wed, 10 May 95 15:15:32 GMT Message-Id: <9505101515.AA0004s@flevel.demon.co.uk> Message-Id: <20a49992.afc80-dev@flevel.demon.co.uk> In-Reply-To: <9505100826.AA13367@pctc.chemie.uni-erlangen.de> (from Thomas Walter ) (at Wed, 10 May 1995 10:26:21 +0200) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: walter@pctc.chemie.uni-erlangen.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: problem with large files Hi Thomas, > Excuse me, I know the following may not belong to this list. But I have a > serious problem with large files and I know there are some people very > familar with the AmigaDOS. > > Curently I want to install the sc655patch, but it always hangs up if it > tries to decompress and patch sccxx.library. This happens also if I install > the original SAS/C 6.50 version. First I thaught it is a stack problem > or a installer problem. But it isn't. > > I decompressed sccxx.library by hand and called the spatch by hand, also. > > It works fine on RAM: disk. Then I tried to copy the new scxx.library to > my HD and the AMIGA hangs up. I tried with the AmigaDOS command, from > csh with its builtin cp and with the cp command from gcc263. It sounds like you have your maxtransfer set incorrectly for your hard drive. Try setting it down lower (Say 65K) and see what happens. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu May 11 05:48:25 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <103921-1>; Thu, 11 May 1995 05:46:09 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0s9OyD-0004nnC; Wed, 10 May 95 20:31 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: ixemul merging To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Wed, 10 May 1995 20:31:25 -0700 (MST) Cc: vinsci@nic.funet.fi (Leonard Norrgard), fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 706 If anyone on this list has any ixemul bug fixes or changes which have not yet been sent to me, please forward them now. I'd like to do a new release of ixemul in the next couple of weeks. Does anyone know how to reach Leonard Norrgard other than via the email address. I've sent several email messages about the important work he was doing a few weeks ago on ixemul.library and have not gotten any response. We were going to coordinate a new release but he seems to have dropped out of sight in the last few weeks and I don't want to delay doing another release any longer. Did anyone else get a copy of the changes he was working on that they can forward to me? Thanks! -Fred From amiga-gcc-port-owner@nic.funet.fi Thu May 11 05:56:44 1995 Received: from io.org ([142.77.27.2]) by nic.funet.fi with SMTP id <85603-4>; Thu, 11 May 1995 05:55:38 +0300 Received: from "io.org" (timper.net5b.io.org [199.166.191.38]) by io.org (8.6.12/8.6.12) with SMTP id WAA17796 for ; Wed, 10 May 1995 22:55:24 -0400 Received: by "io.org" (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 10 May 95 22:55:44 From: tjhayko@timper (Tom Hayko) Message-Id: <20a5056e.be0e1-tjhayko@timper> Subject: C cross reference generator X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Reply-To: tjhayko@io.org To: amiga-gcc-port@nic.funet.fi Date: Wed, 10 May 95 22:55:44 Does anybody know of a program that can generate a cross reference of function definitions and calls? I'm looking for something that can handle large amounts of code (ie. over 3 million lines of code). -- Tom Hayko tjhayko@io.org From amiga-gcc-port-owner@nic.funet.fi Thu May 11 10:30:53 1995 Received: from lillep.gbar.dtu.dk ([130.225.87.179]) by nic.funet.fi with ESMTP id <9595-2>; Thu, 11 May 1995 10:28:12 +0300 Received: by lillep.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May11.102812+0300_eet_dst.9595-2+20@nic.funet.fi> From: To: Date: Thu, 11 May 1995 10:28:11 +0300 Date: Thu, 11 May 1995 09:30:30 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: GNU GPL question Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: GNU GPL question Hi, If I compile one of my sources with gcc, do I have to distribute it under the GPL? I'm not using any GNU libraries or startup or anything. My interpretation of the GPL is that i don't have to, but one of the teacher (lecturers?) say that I have to. Who's right? Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu May 11 11:43:35 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <126170-4>; Thu, 11 May 1995 11:42:01 +0300 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id KAA29881 for ; Thu, 11 May 1995 10:40:18 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA08966; Thu, 11 May 95 10:40:04 GMT Date: Thu, 11 May 95 10:40:04 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9505111040.AA08966@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: Gcc + Enforcer, how ?? Hi, I want to use Gcc and Enforcer. Is there a FindHit tool for gcc executable ?? \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier | Etudiant en Doctorat | Centre de Recherche en Informatique E-Mail: | Universite Louis Pasteur papier@dpt-info.u-strasbg.fr | Strasbourg - FRANCE ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Thu May 11 12:42:40 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <9275-3>; Thu, 11 May 1995 12:40:51 +0300 Received: from freenet-a.fim.uni-erlangen.de by uni-erlangen.de with SMTP; id AA02679 (5.65c-7/7.3w-FAU); Thu, 11 May 1995 08:54:19 +0200 Received: by fim.uni-erlangen.de; id AA12952 (4.1/7.3r-FAU); Thu, 11 May 95 08:53:13 +0200 Date: Thu, 11 May 95 08:53:13 +0200 Message-Id: <9505110653.AA12952@freenet-a.fim.uni-erlangen.de> From: cu154@fim.uni-erlangen.de (Federico Di Gregorio) To: amiga-gcc-port@lists.funet.fi Subject: Last question about AmiTCP! Reply-To: cu154@fim.uni-erlangen.de I grabbed the libraries on Aminet but... That will solve my problem? What I mean is: can I now call open(), close(), etc... both on files and sockets??? Thank you ALL for your help :) -- *-=< Federico Di Gregorio cu154@fim.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Thu May 11 12:53:51 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <9616-1>; Thu, 11 May 1995 12:52:25 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id LAA09621; Thu, 11 May 1995 11:50:51 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id LAA18611; Thu, 11 May 1995 11:54:45 +0200 Date: Thu, 11 May 1995 11:54:45 +0200 From: Niklas Hallqvist Message-Id: <199505110954.LAA18611@linda.appli.se> To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95May11.102812+0300_eet_dst.9595-2+20@nic.funet.fi> (gc948374@gbar.dtu.dk) >>>>> "Rask" == gc948374 writes: Rask> If I compile one of my sources with gcc, do I have to Rask> distribute it under the GPL? I'm not using any GNU libraries or Rask> startup or anything. My interpretation of the GPL is that i Rask> don't have to, but one of the teacher (lecturers?) say that I Rask> have to. Who's right? You are. The GPL (and LGPL) only covers distributed code, not code generated by tools which are GPL:ed. As there are code which get linked by GCC distributed with GCC, libgcc.a, one might think that the GPL would apply to generated code, but no, libgcc.a is written without GPL just to enable that use of the GNU compiler. Think about it, several object-only commercial applications including OSes are compiled by GCC for enhanced performance, would they do that if they had to give up their objectcode-only policy? The key behind the GPL is that no code based on work GPLed, should be locked to to that specific compilation, but the user should be able to customize the GPLed code as he wants to and recompile. You are still allowed to protect your own source as you see fit. For example, let's say you use som LGPLed library libfoo.a in your application app. When you distribute it you must also distribute a linkable objectfile app.o which, when linked with the distibuted libfoo.a (with source) generates app. If the end-user wants, he should be able to customize libfoo, and relink it with app.o to get a customized app. It's not a very severe limitation on distribution rights IMHO. Remember that the (L)GPL was written to give programmers more Freedom, not to limit their chance of protecting their own work. As long as their own work is clearly delimited from others GPLed work, it's perfectly OK to keep a separate copyright policy on it. In your case, your lecturer has misunderstood the intentions of the (L)GPL which is easy to do. These discussions come up ever so often because of the legaleze used to express the GPL. Too bad many get the GPL wrong, as rumours like "you cannot use GNU products for business work" severly harms the usage of GNU products. To name a few uses of GCC where the program did NOT fall under the GPL: Dell Unix SVR4, NextStep & some OSF/1 port. Tell your lecturer about these, and ask him why he thinks the GPL prevents them to be sold during other than GPL conditions? I ask you to actually convince him he was wrong as it is harmful for the programming society that such misconceptions exist. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Thu May 11 12:56:09 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <9863-1>; Thu, 11 May 1995 12:55:03 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA00504 (5.65c-7/7.3w-FAU); Thu, 11 May 1995 11:54:43 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA04789 (5.x/7.3w-FAU); Thu, 11 May 1995 11:54:42 +0200 From: Tobias Ruland Message-Id: <9505110954.AA04789@immd8.informatik.uni-erlangen.de> Date: Thu, 11 May 1995 11:54:40 +0200 To: cu154@fim.uni-erlangen.de Cc: amiga-gcc-port@lists.funet.fi Subject: Last question about AmiTCP! In-Reply-To: <9505110653.AA12952@freenet-a.fim.uni-erlangen.de> References: <9505110653.AA12952@freenet-a.fim.uni-erlangen.de> high frederico Federico Di Gregorio writes: > I grabbed the libraries on Aminet but... > That will solve my problem? What I mean is: can I now call > open(), close(), etc... both on files and sockets??? > Thank you ALL for your help :) you cannot "open" a socket because the "socket"-call does this for you and returns a standard-filedescriptor. you can read/write/close using this filedescriptor. see unix manual page "socket". after that close(2), fcntl(2), ioctl(2), read(2), write(2), accept(3N), bind(3N), connect(3N), getsockname(3N), getsockopt(3N), listen(3N), recv(3N), recvfrom(3N), setsockopt(3N), send(3N), shutdown(3N), socketpair(3N) hope this helps. tobias --------------------------------------------------------------------------- Tobias Ruland (student at Dept. of Artificial Intelligence, Univ. Erlangen) MAIL: tsruland@immd8.informatik.uni-erlangen.de (Please write in ENGLISH, GERMAN or FINNISH) WWW: http://www8.informatik.uni-erlangen.de/~tsruland From amiga-gcc-port-owner@nic.funet.fi Thu May 11 15:42:30 1995 Received: from ild.alkymi.unit.no ([129.241.113.1]) by nic.funet.fi with SMTP id <136881-4>; Thu, 11 May 1995 15:39:51 +0300 Received: from vann.alkymi.unit.no (vann.alkymi.unit.no [129.241.113.2]) by ild.alkymi.unit.no (8.6.12/8.6.11MS-serv) with ESMTP id OAA17741 for ; Thu, 11 May 1995 14:39:39 +0200 From: Torgeir Lilleskog Received: (tli@localhost) by vann.alkymi.unit.no (8.6.12/8.6.11MS-cli) id OAA05365 for amiga-gcc-port@lists.funet.fi; Thu, 11 May 1995 14:39:38 +0200 Message-Id: <199505111239.OAA05365@vann.alkymi.unit.no> Subject: Is g++ stable? To: amiga-gcc-port@nic.funet.fi Date: Thu, 11 May 1995 14:39:36 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1226 Hello! I recently installed gcc 2.6.3 on my amiga 4000/030 with the installer-script on AmiNet. Now it seems that gcc works completely fine when compiling normal c-programs, but when compiling c++ programs it seems to crash whenever I introduce some tiny syntax-error in my program. I have also had trouble with g++ when using the libg++ package. here is my test program: #include #include <_String.h> int main() { String s("Hello World"); cout << "Everybody say: " << s << endl; } when I compile this with: g++ -o test test.cc -lg++ I get the response: t:cc0823601.o: Undefined symbol String::String(const char *) referenced from text segment t:cc0823601.o: Undefined symbol __ls__FR7ostreamRC6String referenced from text segment t:cc0823601.o: Undefined symbol 6String::~6String() referenced from text segment I suppose this could be related to the installation, but I don't know how. Any help would be appreciated. regards -Torgeir Lilleskog -- ------------------------------------------------------------------------------- "I will never let malfunctioning brakes stop me" - tli@alkymi.unit.no ------------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Thu May 11 17:05:58 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <109886-2>; Thu, 11 May 1995 17:02:50 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0s9ZWX-0004noC; Thu, 11 May 95 07:47 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Is g++ stable? To: tli@alkymi.unit.no (Torgeir Lilleskog) Date: Thu, 11 May 1995 07:47:33 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199505111239.OAA05365@vann.alkymi.unit.no> from "Torgeir Lilleskog" at May 11, 95 02:39:36 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1064 > I have also had trouble with g++ when using the libg++ package. > > here is my test program: > > #include > #include <_String.h> > > int main() > { > > String s("Hello World"); > > cout << "Everybody say: " << s << endl; > } > > when I compile this with: g++ -o test test.cc -lg++ I just tried it with gcc off my FreshFish Vol 9 CD, and after I changed the String.h include to it compiles and runs fine. Note that *will* pick up the correct C++ String.h file from the g++ include dir and not the C include file from gnu:include. There is no need to change the name of String.h (and change all the C source that uses it). If C++ uses the C include then fow now the source will need to be changed to include , as a workaround of the case independent name clash between string.h and String.h. There is apparently a way to work around this as well using a mapping file in the g++ include directory, and it's on my list of things to look at for the next release. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu May 11 18:10:59 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <136712-1>; Thu, 11 May 1995 18:06:45 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26520-4>; Thu, 11 May 1995 17:06:00 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209220-1>; Thu, 11 May 1995 17:05:49 +0100 Subject: Re: your mail From: Christian Stieber To: gc948374@gbar.dtu.dk Date: Thu, 11 May 1995 17:05:33 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95May11.102812+0300_eet_dst.9595-2+20@nic.funet.fi> from "gc948374@gbar.dtu.dk" at May 11, 95 10:28:11 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1670 Message-Id: <95May11.170549+0100mesz.209220-1+2923@hphalle0.informatik.tu-muenchen.de> > If I compile one of my sources with gcc, do I have to distribute it > under the GPL? No. Just using GNU-C doesn't do that. Even the libgcc functions are covered by a special exception, so you can e.g. use long long without turning the program into a GPL program. You just have to be careful about the libraries you link with. If one of them is covered by the GPL, your program will be GPL, too. AFAIK this is not true for libnix, but _please_ check that first. Of course, there may be other reason why your program might be GPL --- if you use a bison parser, for example. > I'm not using any GNU libraries or startup or anything. IN that case, you can use any licence you wish for your program. > My interpretation of the GPL is that i don't have to, but one of the > teacher (lecturers?) say that I have to. Who's right? You are right. Sometimes people say "GNU-C", but they really mean the compiler AND some libraries. If one of these libraries is GPL, they say that "GNU-C compiled programs are GPL". Also note the differences between GPL and LGPL, just in case your teacher confuses the two. If you link a commercial program with an LGPL library, you don't have to provide sources AFAIK. You just need to provide an object file that can be linked with another version of the library. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Thu May 11 20:20:26 1995 Received: by nic.funet.fi id <136823-3>; Thu, 11 May 1995 20:15:30 +0300 From: Leonard Norrgard To: mikaak@evitech.fi CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Mika Kuoppala on Thu, 4 May 1995 22:36:04 +0200 (EET)) Subject: Re: unsubscribe Message-Id: <95May11.201530+0300_eet_dst.136823-3+44@nic.funet.fi> Date: Thu, 11 May 1995 20:15:30 +0300 done. From amiga-gcc-port-owner@nic.funet.fi Thu May 11 21:41:33 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <1026-3>; Thu, 11 May 1995 21:40:11 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id UAA11872; Thu, 11 May 1995 20:38:43 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id TAA00673; Thu, 11 May 1995 19:21:20 +0200 Date: Thu, 11 May 1995 19:21:20 +0200 From: Niklas Hallqvist Message-Id: <199505111721.TAA00673@linda.appli.se> To: amiga-gcc-port@nic.funet.fi Subject: [owinebar@nickel.ucs.indiana.edu: GPLed Libraries (was Re: your mail)] [ I think Lynn meant to send this message to the list instead of only to me, so I'm forwarding a copy. -NH ] Return-Path: owinebar@nickel.ucs.indiana.edu From: onnie lynn winebarger Subject: GPLed Libraries (was Re: your mail) To: niklas@appli.se (Niklas Hallqvist) Date: Thu, 11 May 1995 12:57:36 -0500 (EST) In-Reply-To: <199505110954.LAA18611@linda.appli.se> from "Niklas Hallqvist" at May 11, 95 11:54:45 am [good question and some of the response deleted] > You are. The GPL (and LGPL) only covers distributed code, not code > generated by tools which are GPL:ed. As there are code which get > linked by GCC distributed with GCC, libgcc.a, one might think that the > GPL would apply to generated code, but no, libgcc.a is written without > GPL just to enable that use of the GNU compiler. Think about it, While we are on the subject, does anyone have a convenient list of GPLed libraries? I've just got the latest FreshFish, and the number of files is a bit overwhelming - i.e. I don't know where to look for this stuff. (Not really a complaint - Thanks Fred!) Lynn From amiga-gcc-port-owner@nic.funet.fi Fri May 12 14:54:53 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90867-3>; Fri, 12 May 1995 14:51:12 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id MAA26732 for ; Fri, 12 May 1995 12:50:32 +0100 From: Lars Hecking Message-Id: <199505121152.MAA28718@mostar.nmrc.ucc.ie> Subject: Bash To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Fri, 12 May 1995 12:52:19 +0100 (BST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 112 Anybody out there working on bash? Please get in touch with me. -- Lars G. Hecking lhecking@nmrc.ucc.ie From amiga-gcc-port-owner@nic.funet.fi Fri May 12 18:37:19 1995 Received: by nic.funet.fi id <90760-1>; Fri, 12 May 1995 18:33:49 +0300 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: pong Message-Id: <95May12.183349+0300_eet_dst.90760-1+41@nic.funet.fi> Date: Fri, 12 May 1995 18:33:43 +0300 Just a short note to say I'm alive and well in the real world (being off-net for a couple of weeks is pretty interesting). I handed my ixemul development sources over to Fred Fish today (actually, I put them up for ftp on ftp.funet.fi: /pub/amiga/gnu/beta/ss-ixemul-950512.tar.gz). A new specialized mailing list for the maintainers of ixemul.library is being created. More info when it's available. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Fri May 12 18:53:26 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90891-3>; Fri, 12 May 1995 18:50:52 +0300 Received: by colombo.telesys-innov.fr; Fri, 12 May 1995 17:52:20 +0100 From: Philippe BRAND Message-Id: <199505121652.RAA06521@colombo.telesys-innov.fr> Subject: Re: pong To: vinsci@nic.funet.fi (Leonard Norrgard) Date: Fri, 12 May 1995 17:52:20 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95May12.183349+0300_eet_dst.90760-1+41@nic.funet.fi> from "Leonard Norrgard" at May 12, 95 06:33:43 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 305 Leonard Norrgard writes: > /pub/amiga/gnu/beta/ss-ixemul-950512.tar.gz). That's a cool present for my birthday, thanks! :-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri May 12 21:59:50 1995 Received: from nickel.ucs.indiana.edu ([129.79.10.5]) by nic.funet.fi with SMTP id <90723-2>; Fri, 12 May 1995 21:56:00 +0300 Received: by nickel.ucs.indiana.edu (5.65c+/10jsm) id AA09859; Fri, 12 May 1995 13:54:41 -0500 From: onnie lynn winebarger Subject: Amiga GCC FAQ To: amiga-gcc-port@nic.funet.fi Date: Fri, 12 May 1995 13:54:41 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1704 Message-Id: <95May12.215600+0300_eet_dst.90723-2+49@nic.funet.fi> Well, it's been a long time since the FAQ idea was presented, and, so far as I know, everybody's been too busy stress testing gcc to bother :-) At any rate, I was thinking about grabbing some archives of this list and doing some cutting and pasting to hack together a beginning for this FAQ. I am hoping that it would act as a "seed crystal" for this little project, so that someone more qualified than I am will take it on (After all, I'm one of the folks who could use that FAQ). A few of the questions I can already see being in there: How do I deal with AmiTCP using gcc? (from recent questions) What Amiga Specific options are tacked onto GCC, what default behaviors should I know about, and how do I go about changing them? (This is derived from the ixemul.library problem) What is this startup code business, how (and maybe why) should I change it? (The kind of thing that is compiler dependent, so that a language specification/text won't talk about it, and OS dependent, so that GNU portability issues mean their docs won't talk about it) (Closely related to the previous question) What can I use without needing to worry about the GPL affecting my software? And then there are the questions asked so frequently that they are included in various readme files so that the porter won't get spammed with e-mail: Stack Requirements Sources of GCC ports Why are both the latest version and 2.3.3 included on FreshFish volumes? Hardware and Memory Minimums Who to thank (and report bugs to) A history section for Amiga specific changes/bug fixes. And I'm sure there's plenty more where those came from (that is, me :-) ) Lynn owinebar@indiana.edu From amiga-gcc-port-owner@nic.funet.fi Sat May 13 22:56:49 1995 Received: from emerald.oz.net ([198.68.184.2]) by nic.funet.fi with SMTP id <90727-3>; Sat, 13 May 1995 22:54:04 +0300 Received: from tnight.oz.net by emerald.oz.net via SMTP (931110.SGI/930416.SGI) for amiga-gcc-port@nic.funet.fi id AA20683; Sat, 13 May 95 12:51:55 -0700 Message-Id: <950513125540.AA2826272@tnight.oz.net> Reply-To: tnight@oz.net From: terry@tnight.oz.net (Terry Nightingale) Date: Sat May 13 12:55:40 1995 To: amiga-gcc-port@nic.funet.fi Subject: re: Amiga GCC FAQ The most important question for the FAQ, IMHO, is where to get the Commodore includes, now that Commodore is no more. Terry Nightingale tnight@oz.net From amiga-gcc-port-owner@nic.funet.fi Sun May 14 19:19:21 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90618-1>; Sun, 14 May 1995 19:16:49 +0300 Received: from relay3.UU.NET by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HQHZMOLH0G001VSX@FIPORT.FUNET.FI>; Sun, 14 May 1995 16:17:04 +0200 (EET) Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQypsa28208; Sun, 14 May 1995 12:10:35 -0400 Received: from merccap.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Sun, 14 May 1995 12:10:40 -0400 Received: from dpg.rnb.com (ramsay) by dpg (4.1/SMI-4.1) id AA16134; Sun, 14 May 95 12:02:12 EDT Received: by dpg.rnb.com (4.1/SMI-4.1) id AA02015; Sun, 14 May 95 12:02:12 EDT Date: Sun, 14 May 1995 12:02:11 -0400 (EDT) From: Petros Michalis Subject: Help with g++ In-reply-to: <950513125540.AA2826272@tnight.oz.net> To: ramsay!uunet!nic.funet.fi!amiga-gcc-port@uunet.uu.net Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Hello everybody, I recently "moved" from SAS C to gcc only to find the following strange problem: I installed the whole gcc distribution and I did manage to get C programs to compile fine but g++ refuses to work... Whatever I do, I get an internal compiler error after a while...I'd apreciate any comments on that problem.... Thank you, Petros ------------------------------------------------------------------------------ Petros Michalis // email: Derivative Products Group \\ // michalis@dpg.rnb.com Republic National Bank of New York \X/ michalis@panix.com From amiga-gcc-port-owner@nic.funet.fi Sun May 14 20:59:02 1995 Received: from nickel.ucs.indiana.edu ([129.79.10.5]) by nic.funet.fi with SMTP id <90949-2>; Sun, 14 May 1995 20:57:09 +0300 Received: by nickel.ucs.indiana.edu (5.65c+/10jsm) id AA05326; Sun, 14 May 1995 12:56:52 -0500 From: onnie lynn winebarger Subject: Re: Amiga GCC FAQ To: tnight@oz.net Date: Sun, 14 May 1995 12:56:50 -0500 (EST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <950513125540.AA2826272@tnight.oz.net> from "Terry Nightingale" at Mar 7, 24 07:31:24 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 621 Message-Id: <95May14.205709+0300_eet_dst.90949-2+20@nic.funet.fi> > > The most important question for the FAQ, IMHO, is where to get the > Commodore includes, now that Commodore is no more. Well, I know there on the FreshFish CD-ROMs. But you're in oz, so I dont know what his distribution is like over there. > Terry Nightingale > tnight@oz.net While we're on the subject, I started my research, and found that the gcc README is oh so much more complete than the last time I checked it out (around abouts April of 1994). Also, while perusing the '94 archive of this list, discovered some other folks had made some up. Anybody still got those laying around? Lynn From amiga-gcc-port-owner@nic.funet.fi Mon May 15 00:51:50 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90585-3>; Mon, 15 May 1995 00:49:15 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Sun, 14 May 95 23:49 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Sun, 14 May 95 23:47 MET DST Message-Id: Subject: gcc &tcpip - examples To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Sun, 14 May 1995 23:47:26 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 553 i am happy to see that there are so many ppl programming networks :). because i converted some krm-examples for gcc i would like to see some easy examples in this field too (not only for me). please remeber this before you remove old files from you HD !! walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Mon May 15 02:11:47 1995 Received: from relay3.UU.NET ([192.48.96.8]) by nic.funet.fi with SMTP id <90562-4>; Mon, 15 May 1995 02:10:46 +0300 Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQyptc28433; Sun, 14 May 1995 19:10:38 -0400 Received: from merccap.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Sun, 14 May 1995 19:10:39 -0400 Received: from dpg.rnb.com (ramsay) by dpg (4.1/SMI-4.1) id AA23765; Sun, 14 May 95 19:04:46 EDT Received: by dpg.rnb.com (4.1/SMI-4.1) id AA05942; Sun, 14 May 95 19:04:45 EDT Date: Sun, 14 May 1995 19:04:45 -0400 (EDT) From: Petros Michalis To: Fred Fish Cc: ramsay!uunet!nic.funet.fi!amiga-gcc-port@uunet.uu.net Subject: Re: Help with g++ In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 14 May 1995, Fred Fish wrote: > > Hello everybody, > > I recently "moved" from SAS C to gcc only to find the following strange > > problem: I installed the whole gcc distribution and I did manage to > > get C programs to compile fine but g++ refuses to work... Whatever I do, > > I get an internal compiler error after a while...I'd apreciate any > > comments on that problem.... > > You don't say where you got the version you are running, but I assume > from aminet. Yes, I got version 2.6.3 from aminet. > I'd suggest trying the version from the FreshFish Vol 9 > CD, which undergoes much more testing. You can also try setting your > stack to some very high value, like 500K. > > -Fred > I have my stack at 250K, are 500K values normal for g++? (as you're suggesting?). Thanks for the answer, Petros From amiga-gcc-port-owner@nic.funet.fi Mon May 15 03:28:16 1995 Received: from nickel.ucs.indiana.edu ([129.79.10.5]) by nic.funet.fi with SMTP id <90721-2>; Mon, 15 May 1995 03:26:35 +0300 Received: by nickel.ucs.indiana.edu (5.65c+/10jsm) id AA12994; Sun, 14 May 1995 19:25:59 -0500 From: onnie lynn winebarger Subject: FAQ start To: amiga-gcc-port@nic.funet.fi Date: Sun, 14 May 1995 19:25:59 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 14832 Message-Id: <95May15.032635+0300_eet_dst.90721-2+5@nic.funet.fi> Ok, folks, I woke up early this morning and had nothing better to do, so here's my first stab at a table of contents + some mild answers. I will welcome any suggestions or (gasp) answers you've got. Note that I've only made it about 12% of the archive of amiga-gcc-port, and haven't been reading it at all regularly since about March or April of last year (or programming - I had to swear myself off for graduate school, but it's summer now). Hence, I only have 2 names (besides the actual porters and authors of libnix and ixemul.library) for contributors. I include them because (a) they reported lots of bugs and (b) it seemed like their suggestions were useful to the porters, and actually had some effect. At any rate, I don't mean to slight anyone, I just haven't gotten that far along in reading ;-). I've already thought of some more topics, but feel like taking a break for a while. ----------------------------------------------------------------------------- Amiga GNU CC FAQ Version 0.1 This FAQ is intended to answer most (all, if possible) common questions concerning the Amiga Port of GCC. It is divided into the following sections: 0. General Introduction a. The FSF, the GNU Project, and the GPL b. What GCC has to offer c. Hardware and Software requirements 1. Obtaining and Installing the Beast a. Sources of GCC b. The breakdown of the distribution c. Installation d. Common Problems with the Installation 2. Initial problems using GCC a. Set your stack properly b. Amiga specific library options i) ixemul.library ii) libnix iii) libamiga.a and others c. The object file format of GCC i) Converting libraries to this format d. Getting the Commodore includes e. The frontend of the compiler f. Optimization may work where no optimization doesn't 3. Amiga-specific extensions a. The CHIP keyword (is this implemented?) b. Command Line options i) -noixemul (maybe goes in 2. (b)) ii) Others (Need input here) c. Startup Code options 4. Advanced Questions a. How do I build a cross-compiler? b. Working with AmiTCP c. Writing code for ixemul.library d. Writing code for libnix e. What is -fbaserel useful for (I would like to know) 5. C++ and Objective C (don't know much about these, except that they're not as well developed yet as the C compiler) 6. Support Utilities a. Frontends b. Debuggers c. What else? 8. Additional Support a. amiga-gcc-port mailing list b. snail mail (?) - for people getting it off of CD-ROM c. You never know, it could be a problem in base FSF code (is there a newsgroup to point to here?) 9. Known Bugs a.-resident option 10. Maintainers and Contributors 11. Future 12. History Appendix A: How does the GPL affect programs compiled by GCC? Section 0, General Introduction ------------------------------- a. The FSF, the GNU Project, and the GPL The Free Software Foundation (FSF) is an institution dedicated to the free flow of software (and information in general (?)). To this end it has start the GNU (GNU's Not Unix) project, a collection of widely portable software of all sorts (compilers and Un*x utilities for the most part, but some other stuff as well). But I'm sure Richard Stallman, director and founder of the FSF, can say it better than I: (good quote from Stallman describing FSF to be inserted here) The GNU Public License (GPL) was written in order to keep software published under it free. Here's an excerpt from the Preamble of the GPL: (Preamble) More information regarding the FSF, GNU, and the GPL can be obtained at rtfm.mit.edu. Note that the source code of any GPLed software must be made available by the distributor (is this wording accurate?). The GPL may also affect how you distribute your programs, or maybe not. For more information, check out Appendix A of this FAQ. (Do this before believing all the bad hype about it. Then decide for yourself). b. What GCC has to offer. A FREE C compiler, for starters. Sure there's some other stuff. c. Hardware and Software Requirements This depends upon what you're doing. Here's an excerpt from Phillipe Brand's readme for his distribution on the net: (quote) Yes, it can take a lot of resources, but that's a function of its portability. Be glad you can count on having the same compiler on your Amiga at home or the Unix system at work (or vice versa :-)). 1. Obtaining and Installing the Beast a. Sources of the Amiga port of GCC There are a couple of options for getting GCC. If you have access to the Internet, and ftp service, you can obtain the current version of GCC from Aminet, in dev/ (somebody fill this in). The main site of Aminet is ftp.wustl.edu in /pub/aminet, and has mirrors world-wide. (list of sites?). ftp.funet.fi also serves to mirror Phillipe Brand's Amiga GCC tree directly, so that you may always find it there (particularly to guarantee the availability of source code). The distribution is broken up into several parts, both to make it easier to download and to respect the GPL. Thus each archive is broken into two parts, one for binaries and one for sources. (clip from Brand's README.lha describing the distribution) The second way is to utilize your CD-ROM and get one of Fred Fish's great CD-ROM collections. Any of the FreshFish or GoldFish Vol. 2 will have it, though the later the CD-ROM the later the version. He also includes as many ports of GNU utilities as he can. His restriction is simply that the binaries he includes must be compilable from the sources he includes (this has been a problem in the past, and Fred is a stringent observer of the GPL). So, yes, you also get all the sources with the binaries. (If you've got a CD-ROM drive, you should get one of these anyway; it's a great deal). These CD-ROMs may be purchased from Amiga Library Services by: Snail Mail: Amiga Library Services 610 N. Alma School Road, Suite 18 Chandler, AZ 85224-3687 USA FAX or Voice: (602) 491-0048 Phone: (800) 804-0833 or Email: orders@amigalib.com (but sending credit card information over e-mail is not secure, so one of the other methods would be preferable. Fred is working on using some kind of encryption though. More details when they're available.) There may be other CD-ROMs containing GCC, I just know of Fred's since he is directly involved in the porting of it. The breakdown of this distribution is different. Check the specific CD-ROM for details. They also include the Commodore Native Developer Updates (no Autodocs) for 2.04, 3.0, and 3.1, which is a big bonus. c. Installation Installation procedures may vary depending on your source, but the final directory structure should be the same. Check the README files included in your distribution package for more details. I believe the Internet distribution (Phillipe Brand's) contains an Installer program (last I checked, anyhow). (More details, anyone?) d. Common Installation Problems Need suggestions here. See 2 (c) about the GCC object format. You'll need to convert some standard libraries. 2. Initial Problems with GCC a. Set your stack properly. GCC needs a lot of stack to run. For a nice, small (<1000 lines) source, a stack of 50,000 should do just fine. For more complicated code, you may need more, but 250,000 should do in any case, for gcc alone. Note that using make may increase the demands on the stack size, so the above suggestions may not hold. A word from Phillipe Brand's README: (quote) b. Amiga specific Library options i) Ixemul.Library This library was developed by Markus Wild when originally started porting GCC (up to version 2.3.3). It is a shared library that emulates a lot of Un*x functions, making life a lot easier for folks porting GNU utilities and such. Unfortunately, it is fairly resource hungry by Amiga standards, and has caused not a little irritation among Amiga users. GCC opens ixemul.library by default, so if you want to avoid it, you'll have to use -noixemul on the command line (see below in Amiga specific extensions and/or coding with x.lib) and link to one of the libraries below. The general rule of thumb should be to use ixemul.library if you're writing something non-Amiga specific (e.g. porting something) or one of the below link libraries when writing something specifically for the Amiga. ii) libnix This is a standard link library to replace the functionality of ixemul.library. Make sure you link to it if you use the -noixemul command line option for gcc. Here's the readme file from the distribution: Short: A library for amiga specific development on gcc Type: dev/gcc Uploader: fleischr@izfm.uni-stuttgart.de Author: fleischr@izfm.uni-stuttgart.de, gnikl@informatik.uni-rostock.de This is libnix, a static (i.e. link) library for gcc 2.3.3 or above. It's not a replacement for ixemul.library (though it's possible to recompile most of the gcc environment with libnix) but a good thing for amiga specific development on gcc: * It's mostly compatible to SAS's way of handling things, i.e. you get even an automatic shared library opening feature and some other things you may miss in ixemul.library. This also means it's ANSI compliant. * It doesn't need any shared libraries than normal Amiga OS ones. * It is not copyrighted by the FSF. Therefore you neither need to include sources nor objects together with your executable. (read the GLGPL _before_ flaming on this statement) * And it's short! I was able to compile a 492 byte 'hello, world' using normal main. * It uses OS20 features whenever necessary. To cut it short: Use ixemul.library for porting Un*x programs, libnix for compiling amiga-only programs and gcc becomes one of the best Amiga compilers. There is no need to download this archive if you use gcc2.6.0 or above since the libraries itself are included with the normal gcc distribution. But if you use an older gcc version or if you want to get the sources you can take this package. But be warned: The ld that comes with earlier versions of gcc has some serious trouble with set elements. You cannot use libnix without the fixed linker that comes with gcc2.6.0. iii) Gerlib Obsolete (?) iv) the PDC library Obsolete (?) c. The object file format of GCC GCC uses a different format for object files than other Amiga C compilers. This is merely a design decision. (Include recent mail from the list about this and incompatibility with SAS object files - from AmiTCP discussion) i) Converting libraries to this format Clipped from Brand's README: As I'm not able to ditribute amiga libraries, you'll have to generate one using hunk2gcc, the AmigaDOS object converter made by Markus Wild, or using libnix sources to generate libamiga.a. 1) To achieve this, simply grab a copy of latest amiga.lib (from Commodore Development Kit) and make a new directory where you want your converted object files to go, cd into it, and enter hunk2gcc amiga.lib [..further libs if you like..] This generats an a.out object file for every program unit present in the hunk file (in this case, from amiga.lib). As the final step convert all those files into an a.out style library by issuing: ar qc libamiga.a obj.* ranlib libamiga.a The ranlib run builds a symbol table in the archive, and makes accesses to the library much faster. 2) Creating a libamiga.a library with libnix is fairly easy, but takes some time. You'll have to provide fd files and protos (from CBM Developper Kit). Just uncompress sources.lha and run a 'make libamiga.a'. NOTE: As long as you make no AmigaDOs specific calls, you can create a dummy library using: cat "int dummy;" >dummy.c gcc -c dummy.c ar crv libamiga.a dummy.o mv libamiga.a gcc:lib A small libamiga.a (dummy) is also provided with libnix. d. Getting the Commodore includes Only place I know of is Fred Fish's CD-ROMs these days. Anyone else? e. The frontend of the compiler amigados-gcc and gcc are the same thing. f. Optimization may work where no optimization doesn't The folks who write GCC almost always use -O when compiling GCC and other stuff. Hence, the -O routines are better tested than those without optimization. 3. Amiga-specific extensions a. The CHIP keyword (is this implemented?) b. Command Line options i) -noixemul (maybe goes in 2. (b)) ii) Others (Need input here) c. Startup Code options (maybe redundant) 4. Advanced Questions a. How do I build a cross-compiler? b. Working with AmiTCP c. Writing code for ixemul.library After looking at Markus Wild's README, I couldn't see anything to include in particular, and the thing is way too long to put here. Any specific suggestions of stuff to clip out? d. Writing code for libnix f. What is -fbaserel useful for (I would like to know) 5. C++ and Objective C a. C++ i) Use _complex.h instead of complex.h Because Amiga Dos is not case-sensitive, and there are both complex.h and Complex.h on the Unix distribution, one had to be changed. This choice was recommended by the libg++ maintainer. (don't know much about these, except that they're not as well developed yet as the C compiler) 6. Support Utilities a. Frontends b. Debuggers (Maybe just GDB?) c. What else? 8. Additional Support a. amiga-gcc-port mailing list b. snail mail (?) - for people getting it off of CD-ROM c. You never know, it could be a problem in base FSF code (is there a newsgroup to point to here?) 9. Known Bugs a. C compiler i) -resident option This has been broken since 2.3.3. Hence, you'll need to get that version if you want to compile a program you can make resident. (Did I get that wording right?) b. C++ compiler (g++) c. Objective C compiler 10. Maintainers and Contributors Gcc v2.2.2 port: Markus Wild Gcc v2.3.3 port: Markus Wild Gcc v2.4.5 port: Philippe Brand, Lars Hecking, Fred Fish Gcc v2.5.0 and up: Philippe Brand, Fred Fish, Leonard Norrgard Ixemul.library: Markus Wild, Leonard Norrgard, R. Luebbert Libnix: Matthias Fleischer, Gunther Nikl Also, much testing, suggestions and debate have been provided by Jorg Hoehle Peter Ivemey-Cook Many others, I'm sure. Any suggestions (especially Phillipe, Fred, and Leonard)? 11. Future 12. History Appendix A: How does the GPL affect programs compiled by GCC? This is where I'd like to put that list of libraries that are GPLed. From amiga-gcc-port-owner@nic.funet.fi Mon May 15 10:49:15 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <90549-3>; Mon, 15 May 1995 10:46:09 +0300 Received: by tycho.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May15.104609+0300_eet_dst.90549-3+12@nic.funet.fi> From: To: Date: Mon, 15 May 1995 10:45:57 +0300 Date: Mon, 15 May 1995 09:44:23 +0200 (METDST) From: Rask Lambertsen To: tnight@oz.net Cc: amiga-gcc-port@nic.funet.fi Subject: re: Amiga GCC FAQ In-Reply-To: <950513125540.AA2826272@tnight.oz.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 13 May 1995, Terry Nightingale wrote: > The most important question for the FAQ, IMHO, is where to get the > Commodore includes, now that Commodore is no more. They are available via FTP from ftp.dfv.rwth-aachen.de in directory cdrom/bbs/cbm. URL: file://ftp.dfv.rwth-aachen.de/cdrom/bbs/cbm/ The latest package is nduk-v40.lha. It includes includes (asm and C), fd-files and a few developer tools (Atom, Alink, ...). Just to advertice a little for my homepage (sorry), I keep an up-to-date link to the OS includes. They seem to move around from time to time. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ P.S. My homepage URL recently changed, hopefully to something permanent. From amiga-gcc-port-owner@nic.funet.fi Mon May 15 11:01:38 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90560-4>; Mon, 15 May 1995 10:59:52 +0300 Received: by colombo.telesys-innov.fr; Mon, 15 May 1995 10:01:45 +0100 From: Philippe BRAND Message-Id: <199505150901.KAA13226@colombo.telesys-innov.fr> Subject: Re: FAQ start To: owinebar@nickel.ucs.indiana.edu (onnie lynn winebarger) Date: Mon, 15 May 1995 10:01:45 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95May15.032635+0300_eet_dst.90721-2+5@nic.funet.fi> from "onnie lynn winebarger" at May 14, 95 07:25:59 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2349 onnie lynn winebarger writes: > I will welcome any suggestions or (gasp) answers you've got. Thanks for starting FAQ! > a. Set your stack properly. > GCC needs a lot of stack to run. For a nice, small (<1000 lines) > source, a stack of 50,000 should do just fine. For more complicated > code, you may need more, but 250,000 should do in any case, for gcc alone. > Note that using make may increase the demands on the stack size, so > the above suggestions may not hold. Starting from 2.6.0 you can set GCCSTACK env variable to whatever you want, this value will be used by all compiler passes. In 2.7.0, there will be automatic stack-growing code so it won't be anymore necessary to care about stak size. > c. The object file format of GCC > GCC uses a different format for object files than other Amiga C > compilers. This is merely a design decision. > (Include recent mail from the list about this and incompatibility > with SAS object files - from AmiTCP discussion) Gcc now handles already AmigaDOS hunk format in beta stage, thanks for the BFD port. > As I'm not able to ditribute amiga libraries, you'll have to generate > one using hunk2gcc, the AmigaDOS object converter made by Markus Wild, or > using libnix sources to generate libamiga.a. This is not true anymore. libamiga.a is distributed with gcc. But this chapter is ok for other libraries. > 3. Amiga-specific extensions > > a. The CHIP keyword (is this implemented?) It will. > f. What is -fbaserel useful for (I would like to know) -resident option. Used to be broken, was assembler's fault. Will be fixed in next release, which will be 2.7.0. > b. Debuggers (Maybe just GDB?) Work is in progress. > b. snail mail (?) - for people getting it off of CD-ROM Ramses The Amiga Flying BBS - Main AmigaDOS-GNU BBS support site. I can be reached on fidonet: 2:320/104.0 Phone numbers: +33-1-45845623/53791199/53791200 > i) -resident option > This has been broken since 2.3.3. Hence, you'll need to get > that version if you want to compile a program you can make resident. > (Did I get that wording right?) Will be fixed in 2.7.0 -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon May 15 11:07:40 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90874-1>; Mon, 15 May 1995 11:05:42 +0300 Received: by colombo.telesys-innov.fr; Mon, 15 May 1995 10:07:37 +0100 From: Philippe BRAND Message-Id: <199505150907.KAA13253@colombo.telesys-innov.fr> Subject: gcc dedicate To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 15 May 1995 10:07:36 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 386 I've lost a good friend two days ago, Pierre Carette, co-author of BrowserII on Amiga, and if nobody is against it, I would like to dedicate forthcoming version 2.7.0 to him, mentioning it in general README. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon May 15 11:15:05 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <90536-1>; Mon, 15 May 1995 11:13:33 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA11936; Mon, 15 May 1995 10:13:25 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9505150813.AA11936@decap2.zdv.uni-tuebingen.de> Subject: libnix implying <= 64K data segment? To: amiga-gcc-port@nic.funet.fi Date: Mon, 15 May 1995 10:13:24 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 477 Hello, this weekend I was compiling a program with a very large data segment with -noixemul. However, it was refused by ld with a message like "unknown relocation size" or something similar. "gcc -v" showed, that gcc used ld with an option "-shortdata" and, indeed, "-noixemul" seems to imply this option in any case, according to the specs file. What is the exact meaning of this option? And if it restricts the data segments size, is it possible to remove it? Jochen From amiga-gcc-port-owner@nic.funet.fi Mon May 15 11:23:25 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <90745-1>; Mon, 15 May 1995 11:21:43 +0300 Received: by tycho.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May15.112143+0300_eet_dst.90745-1+11@nic.funet.fi> From: To: Date: Mon, 15 May 1995 11:21:36 +0300 Date: Mon, 15 May 1995 10:20:49 +0200 (METDST) From: Rask Lambertsen To: Niels M|ller Cc: phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi Subject: Re: Cross compiling In-Reply-To: <199504221728.TAA28429@tiny.lysator.liu.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject : Re: Cross compiling On Sat, 22 Apr 1995, Niels M|ller wrote: > Rask Lambertsen writes: > > > I'm not that much of an expert. Does it require me to recompile GCC itself? > > Philippe BRAND answers: > > Yes. > > This is true, unless the "other" machine is also m68k based. For > example, a while ago I compiled the linux-m68k kernel under > amiga-os. In this case what was needed was only a new assembler, a new > linker, and linux-specific headers and libraries. Could you tell which options you used (-b? -m?)? Also, if you specify another target, wouldn't gcc look for ccpp, cc1, as, and ld in another directory? Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon May 15 11:35:52 1995 Received: from uni-kl.de ([131.246.136.50]) by nic.funet.fi with SMTP id <90565-4>; Mon, 15 May 1995 11:29:34 +0300 Received: from uklirb.informatik.uni-kl.de by stepsun.uni-kl.de id af01767; 15 May 95 10:29 MET DST Received: from kerry.informatik.uni-kl.de by uklirb.informatik.uni-kl.de id aa07251; 15 May 95 10:28 MET DST Date: Mon, 15 May 95 4:20:31 EDT From: Frank Bernard To: amiga-gcc-port@nic.funet.fi Subject: Libnix ! Message-ID: <9505150420.aa17225@kerry.informatik.uni-kl.de> Hi All ! How can I get a program, which didn't need the ixemul-library ? Which options and objects I should use ? I tried something with ncrt0.o and -noixemul, but it results in a very large executable ... :-( Ciao // Frank 'AntiFrust' Bernard \X/ bernard@informatik.uni-kl.de From amiga-gcc-port-owner@nic.funet.fi Mon May 15 12:54:06 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <90353-2>; Mon, 15 May 1995 12:49:41 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA12020; Mon, 15 May 1995 11:13:31 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9505150913.AA12020@decap2.zdv.uni-tuebingen.de> Subject: Re: FAQ start To: owinebar@nickel.ucs.indiana.edu (onnie lynn winebarger) Date: Mon, 15 May 1995 11:13:29 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95May15.032635+0300_eet_dst.90721-2+5@nic.funet.fi> from "onnie lynn winebarger" at May 14, 95 07:25:59 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 8560 > 1. Obtaining and Installing the Beast > a. Sources of the Amiga port of GCC > There are a couple of options for getting GCC. > If you have access to the Internet, and ftp service, you can obtain > the current version of GCC from Aminet, in dev/gcc. ^^^ Note: Sources are in dev/gcc, too. I've uploaded them a few weeks ago. However, I was not able to rebuild gcc on my Amiga: cc1 crashed immediately. > The main site of Aminet is ftp.wustl.edu in /pub/aminet, and has mirrors > world-wide. (list of sites?). ftp.funet.fi also serves to mirror. USA (MO) ftp.wustl.edu USA (WI) ftp.netnet.net USA (TX) ftp.etsu.edu Scandinavia ftp.luth.se Switzerland ftp.eunet.ch Switzerland ftp.math.ethz.ch Germany kelly.uni-paderborn.de Germany ftp.uni-paderborn.de Germany ftp.uni-stuttgart.de Germany ftp.uni-erlangen.de Germany ftp.cs.tu-berlin.de Germany ftp.tu-chemnitz.de Germany ftp.fh-augsburg.de Germany ftp.uni-bremen.de Germany ftp.uni-kl.de Germany ftp.uni-trier.de Germany ftp.informatik.rwth-aach France ftp.cnam.fr Portugal ftp.ci.ua.pt UK ftp.doc.ic.ac.uk UK micros.hensa.ac.uk > c. Installation > Installation procedures may vary depending on your source, but > the final directory structure should be the same. Check the README > files included in your distribution package for more details. > I believe the Internet distribution (Phillipe Brand's) contains > an Installer program (last I checked, anyhow). The latest (almost :-) version of the installer script is in dev/gcc on Aminet, too. IMO all common installation problems should be fixed with the script: OS header installation, GNU: assign and OS header installation. Philippe, when is 2.7.0 coming? I'd like to include my latest version then. Some suggestions: - Write the FAQ in texinfo. This way you get it in AmigaGuide, Ascii and dvi, which is excellent for a FAQ. (You could use the tools of the AmigaFAQ for adding a toc and similar things.) 2d.) Getting the Commodore Includes & AutoDocs You can obtain the includes and some developer tools from any Fish CD and some other CD's as well. However, you will be missing the autodocs, which are definitely the best information source for the OS functions. You can get them either by buying the The Amiga ROM Kernel Manual: Includes and Autodocs, ISBN 0-201-56773-3 (about 50-60$, as far as I know), or by buying the so-called NDU (Native developers update kit, 5 disks, about 40$) from Fa. Hirsch & Wolf Mittelstr. 33 56564 Neuwied Germany Phone: (0049) +2631 83990 Email: hhhirsch@carla.adsp.sub.org Sorry, but this is still the *only* source for the NDU, at least as long as CATS (Commodore Amiga Technical Support) isn't alive. I'd prefer buying the NDU, because it contains the same informations than the book and I prefer it online. 2g.) Using the OS functions with gcc. Let's write a simple "HelloWorld.c": /* Compile me with gcc -noixemul -o HelloWorld HelloWorld.c -lauto */ #include #include #include int main(int argc, char *argv[]) { struct EasyRequest er; er.es_StructSize = sizeof(er); er.es_Flags = 0; er.es_Title = "Message"; er.es_TextFormat = "Hello, world!\nintuition.library is at 0x8l."; er.es_GadgetFormat = "Ok"; EasyRequest(NULL, &er, NULL, IntuitionBase); exit(0); } Some notes: - We are using the function EasyRequestArgs() from intuition.library. Thus we have to include the appropriate headers: intuition/intuition.h for the structures and constants, proto/intuition.h for the function prototypes. Do not use headers from other compilers (for example pragmas/intuition.h), gcc headers (inline/intuition.h, included by proto/intuition.h) or even OS headers (clib/intuition_protos.h). The only exception are clib/alib_protos.h and clib/alib_stdio_protos.h: These represent link libraries and not shared libraries. - We did *not* open intuition.library. gcc does this for you by including proto/intuition.h and linking against libauto.a. However, this works only for OS libraries. Consult the GNU:libauto directory, if you want to know how to get the same possibilities for other shared libraries. Using proto/intuition.h you are safe and even source compatible to SAS/C and Dice. - If you *need* to open a library manually, do it as follows: #include #include #include #include struct IntuitionBase *IntuitionBase = NULL; /* Explicit initialization with NULL is a *must*! */ void Cleanup(void) { if (IntuitionBase) CloseLibrary(IntuitionBase); } int main(int argc, char *argv[]) { if (atexit(Cleanup)) { perror("atexit"); exit(20); } if (!(IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library", 37))) { fprintf(stderr, "Cannot open intuition.library, V37"); exit(20); } /* Same program as above */ } Note the use of atexit(), which makes exit() calling Cleanup(). 4f.) How do I save RAM? A simple try is to do a setenv TMP MyHardDrive:t before compiling. This will create temporary files on the harddisk and not in RAM. Depending on what you compile this can save some 100K of RAM while compiling and it doesn't slow down the compiler very much. Another try is to turn off optimization. This prevents the "inline" headers from being included, which need *very* much RAM. If you like optimization (for example because of the additional checks!) you can use the options -O -D__NOINLINES__ which turn on optimization, but prevent the inline headers from being included. (The negative effect is, that you need an additional function call any time, you use an OS function, but one can live with it.) 8d.) Other FAQ's Amiga FAQ General Amiga FAQ. Newsgroups: comp.sys.amiga.misc, comp.sys.amiga.programmer (biweekly). FTP: Aminet, docs/misc, rtfm.mit.edu, /pub/usenet/comp.sys.amiga.misc Maintainer: Ignaz Kellerer, kellerer@informatik.tu-muenchen.de Amiga related books FAQ This is a list of books for the Amiga, including short discussions, prices and sources. Newsgroups: comp.sys.amiga.misc, comp.sys.amiga.introduction, comp.sys.amiga.programmer (monthly) Ftp: rtfm.mit.edu, pub/usenet/comp.sys.amiga.misc. Maintainer: Marc Atkins, atkin@cs.umass.edu AmiTCP/IP FAQ This is for users of AmiTCP/IP, a set of programs which allows to include an Amiga into a TCP/IP network. (Most well known nets, Internet for example use TCP/IP.) Newsgroups: comp.sys.amiga.misc, comp.sys.amiga.datacomm, comp.sys.amiga.networking (biweekly) Ftp: rtfm.mit.edu, pub/usenet/comp.sys.amiga.networking Maintainer: Neil J. McRae (atcpfaq@domino.demon.co.uk) Amiga Networking FAQ Unlike the AmiTCP/IP FAQ this one wants to cover all aspects of networking, including TCP/IP and Envoy. Newsgroups: comp.sys.amiga.datacomm, comp.sys.amiga.hardware Ftp: rtfm.mit.edu, pub/usenet/comp.sys.amiga.networking Maintainer: Richard Norman (norman@afas.msfc.nasa.gov) Point Manager FAQ Networking seems to be quite a problem: This FAQ os for Point Manager, a FidoNet-client (so-called points). Newsgroups: comp.sys.amiga.datacomm Ftp: rtfm.mit.edu, pub/usenet/comp.sys.amiga.datacomm Maintainer: Eric Krieger (pm_faq@quasar.hacktic.nl) All about FTP Explains the usage of the file transfer program FTP. See FTP. Newsgroups: comp.sys.amiga.misc (monthly) Ftp: Aminet, info/start Maintainer: Urban Dominik Mueller (umueller@amiga.icu.net.ch) From amiga-gcc-port-owner@nic.funet.fi Mon May 15 14:47:12 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90145-2>; Mon, 15 May 1995 14:43:45 +0300 Received: by colombo.telesys-innov.fr; Mon, 15 May 1995 13:44:35 +0100 From: Philippe BRAND Message-Id: <199505151244.NAA13930@colombo.telesys-innov.fr> Subject: Re: FAQ start To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Mon, 15 May 1995 13:44:34 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9505150913.AA12020@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at May 15, 95 11:13:29 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1028 Jochen Wiedmann writes: > Philippe, when is 2.7.0 coming? I'd like to include my latest version > then. GENERIC 2.7.0 should be out next week. However I won't release Amiga version until: - 2.7.0 beta distribution is TESTED and people REPORT on it. - proper installation script is done - ixemul changes are done, support for stack checking & auto-stack growing - pdksh fix for allocation is integrated (BTW seems I've lost this fix). - assembler is fixed so that we can now reuse -resident flag. - latest binutils is compiled - latest libnix is ready (0.8 ?) - at least a beta version of FAQ is ready So let's start now: I would need to know exact state of all applications and libraries, and release dates for all of them. I couldn't make pdksh work. binutils can't compile on my system due to probably headers mistake, I'll fix it with Fred. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon May 15 14:56:19 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90215-3>; Mon, 15 May 1995 14:54:30 +0300 Received: from disperse.demon.co.uk by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HQJ4RHEWCG002RW6@FIPORT.FUNET.FI>; Mon, 15 May 1995 11:54:45 +0200 (EET) Received: from post.demon.co.uk by disperse.demon.co.uk id aa27887; 15 May 95 12:19 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id ac20428; 15 May 95 12:19 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA000m2; Mon, 15 May 95 09:56:40 GMT Date: Mon, 15 May 1995 09:56:40 +0000 (GMT) From: dev@flevel.demon.co.uk Subject: Re: Libnix ! In-reply-to: <9505150420.aa17225@kerry.informatik.uni-kl.de> (from Frank Bernard ) (at Mon, 15 May 95 4:20:31 EDT) To: bernard@informatik.uni-kl.de Cc: amiga-gcc-port@nic.funet.fi Message-id: <9505150956.AA000m1@flevel.demon.co.uk> Message-id: <20aae657.57e40-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: Content-transfer-encoding: 7BIT Hi Frank, > > How can I get a program, which didn't need the ixemul-library ? > > Which options and objects I should use ? > > I tried something with ncrt0.o and -noixemul, but it results > in a very large executable ... :-( I think just using -noixemul will work fine. The executable might be larger because all the functions you would have used from the shared library will be linked into the code instead. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon May 15 15:10:13 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <90251-1>; Mon, 15 May 1995 15:08:04 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA14282; Mon, 15 May 1995 14:06:42 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9505151206.AA14282@decap2.zdv.uni-tuebingen.de> Subject: Re: FAQ start To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Mon, 15 May 1995 14:06:38 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199505151244.NAA13930@colombo.telesys-innov.fr> from "Philippe BRAND" at May 15, 95 01:44:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 302 Hello, Philippe, > GENERIC 2.7.0 should be out next week. However I won't release Amiga version > until: [List of useful properties deleted] I second this. Especially stack-growing code and -resident is extremely welcome. Btw, will GCCSTACK still be needed then? And how about -fbaserel? Jochen From amiga-gcc-port-owner@nic.funet.fi Mon May 15 15:21:57 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90220-2>; Mon, 15 May 1995 15:19:57 +0300 Received: by colombo.telesys-innov.fr; Mon, 15 May 1995 14:21:41 +0100 From: Philippe BRAND Message-Id: <199505151321.OAA14188@colombo.telesys-innov.fr> Subject: Re: FAQ start To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Mon, 15 May 1995 14:21:40 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9505151206.AA14282@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at May 15, 95 02:06:38 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 446 Jochen Wiedmann writes: > I second this. Especially stack-growing code and -resident is > extremely welcome. Btw, will GCCSTACK still be needed then? And how > about -fbaserel? GCCSTACK won't be necessary then. -fbaserel problem is directly tied with -resident ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon May 15 17:34:19 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <90366-2>; Mon, 15 May 1995 17:32:12 +0300 Received: from kalle.lysator.liu.se (kalle.lysator.liu.se [130.236.254.26]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id QAA02178; Mon, 15 May 1995 16:31:27 +0200 From: Niels M|ller Received: (nisse@localhost) by kalle.lysator.liu.se (8.6.11/8.6.11) id QAA01106; Mon, 15 May 1995 16:30:06 +0200 Date: Mon, 15 May 1995 16:30:06 +0200 Message-Id: <199505151430.QAA01106@kalle.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: gc948374@gbar.dtu.dk cc: amiga-gcc-port@nic.funet.fi In-reply-to: "gc948374@gbar.dtu.dk"'s message of Mon, 15 May 95 10:21 MET Subject: gcc crosscompiling linux On Sat, 22 Apr 1995, Niels M|ller wrote: > Rask Lambertsen writes: > > > I'm not that much of an expert. Does it require me to recompile GCC itself? > > Philippe BRAND answers: > > Yes. > > This is true, unless the "other" machine is also m68k based. For > example, a while ago I compiled the linux-m68k kernel under > amiga-os. In this case what was needed was only a new assembler, a new > linker, and linux-specific headers and libraries. Could you tell which options you used (-b? -m?)? Also, if you specify another target, wouldn't gcc look for ccpp, cc1, as, and ld in another directory? This was some time ago, and things might have changed, but if I remember correctly, these were the necessary steps: Create a directory lib/gcc-lib/m68k-linux/2.6.3 (or whatever version you use) Copy or link amigados/2.6.3/cc1 and cpp to the above directory (works because linux and amigados uses the same processor, and the same calling conventions) Install linux specific specs file, libraries, assembler and linker in the same directory. Install linux header files in m68k-linux/include. The specs file makes the compiler find them automatically. Compile with gcc -b m68k-linux. Alternatively, and this is what I did, use a linux specific gcc frontend that has this as the default. Look in the linux/680x0 hierarchy, for example at ftp://lysator.liu.se/pub/linux I think that the file to get is tools/amiga/tools-amiga.tar.gz. To actually cross compile anything for linux, you probably need the kernel source archive too, to get the system include files. For those who are curious, linux works pretty well, but unfortunately I have some hardware problem (spurious memory errors) that makes both amigados and linux highly unstable, so I have not been able to do much hacking lately. Anyone who has a working 68030 card for a A1200? Mine is a Microbotics 1230, and I think it is the guilty component in the system. From amiga-gcc-port-owner@nic.funet.fi Mon May 15 18:15:46 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90247-3>; Mon, 15 May 1995 18:12:42 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26615-2>; Mon, 15 May 1995 17:06:15 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209163-1>; Mon, 15 May 1995 17:06:05 +0100 Subject: Re: FAQ start From: Christian Stieber To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Mon, 15 May 1995 17:05:55 +0200 (MESZ) Cc: owinebar@nickel.ucs.indiana.edu, amiga-gcc-port@nic.funet.fi In-Reply-To: <9505150913.AA12020@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at May 15, 95 11:13:29 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1134 Message-Id: <95May15.170605+0100mesz.209163-1+724@hphalle0.informatik.tu-muenchen.de> > The Amiga ROM Kernel Manual: Includes and Autodocs, ISBN > 0-201-56773-3 > I'd prefer buying the NDU, because it contains the same informations ^^^^ > than the book and I prefer it online. No, the NDU contains _more_ information than the book: the book covers AmigaOS 2.0, the NDU covers AmigaOS 3.1. > struct EasyRequest er; > > er.es_StructSize = sizeof(er); This seems to be correct, but I suggest hardcoding 5*sizeof(ULONG) here. That field serves as version information; using sizeof() and compiling with newer headers would tell the OS that you're using the new structure. But the additional fields will contain garbage... Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Mon May 15 19:20:57 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89996-3>; Mon, 15 May 1995 19:18:03 +0300 Received: by colombo.telesys-innov.fr; Mon, 15 May 1995 18:19:44 +0100 From: Philippe BRAND Message-Id: <199505151719.SAA15326@colombo.telesys-innov.fr> Subject: Question To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 15 May 1995 18:19:43 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 277 I've got one question: who's in contact with Amiga Technologies in Germany ? Just wondering... ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon May 15 20:24:22 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <90809-1>; Mon, 15 May 1995 20:21:09 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189455>; Mon, 15 May 1995 19:20:28 +0200 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA20744; Mon, 15 May 1995 19:20:13 +0200 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9505151720.AA20744@nereid.rz.Uni-Osnabrueck.DE> Subject: mmath-68881.h To: amiga-gcc-port@nic.funet.fi Date: Mon, 15 May 1995 19:20:13 +0200 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 310 Hi, There is is problem with math-68881.h. In the pow(x,y) function, if x<0 the code does a log(x). I have replaced it by log(fabs(x)). This works so far. One question: Will gcc 2.7.0 have that apurify-thing built in ? It is extreme usefull for me, because I dont have a mmu :(. Thomas From amiga-gcc-port-owner@nic.funet.fi Tue May 16 06:19:55 1995 Received: from nickel.ucs.indiana.edu ([129.79.10.5]) by nic.funet.fi with SMTP id <90744-3>; Tue, 16 May 1995 06:16:23 +0300 Received: by nickel.ucs.indiana.edu (5.65c+/10jsm) id AA25094; Mon, 15 May 1995 22:15:58 -0500 From: onnie lynn winebarger Subject: Re: FAQ start To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Mon, 15 May 1995 22:15:57 -0500 (EST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9505150913.AA12020@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at May 15, 95 11:13:29 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1586 Message-Id: <95May16.061623+0300_eet_dst.90744-3+5@nic.funet.fi> > Note: Sources are in dev/gcc, too. I've uploaded them a few weeks ago. > However, I was not able to rebuild gcc on my Amiga: cc1 crashed > immediately. Is this a local problem, something with the gcc code, or buggy cc1? > The latest (almost :-) version of the installer script is in dev/gcc > on Aminet, too. IMO all common installation problems should be fixed > with the script: OS header installation, GNU: assign and OS header > installation. Ok, I'll stick this in that section ("Use the Installer script!!!") (or something like that). Does this apply to the FreshFish distribution as well? > Some suggestions: > > - Write the FAQ in texinfo. This way you get it in AmigaGuide, Ascii > and dvi, which is excellent for a FAQ. (You could use the tools of the > AmigaFAQ for adding a toc and similar things.) Actually, that's one of the reasons for writing it like this, ie broken down into sections. Once I get that done, making it texi shouldn't be such a big deal - I also like having a toc so I'll know what else I need to work on. [many new parts logged for inclusion] [with changes suggested by others, of course] > - We did *not* open intuition.library. gcc does this for you by > including proto/intuition.h and linking against libauto.a. > However, this works only for OS libraries. Consult the GNU:libauto > directory, if you want to know how to get the same possibilities for > other shared libraries. Question: how do you specify the version number? All right, all right, I'll RTFM. Thanks for the additions! Lynn From amiga-gcc-port-owner@nic.funet.fi Tue May 16 06:22:37 1995 Received: from nickel.ucs.indiana.edu ([129.79.10.5]) by nic.funet.fi with SMTP id <90564-1>; Tue, 16 May 1995 06:19:39 +0300 Received: by nickel.ucs.indiana.edu (5.65c+/10jsm) id AA25334; Mon, 15 May 1995 22:19:16 -0500 From: onnie lynn winebarger Subject: Re: FAQ start To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Mon, 15 May 1995 22:19:15 -0500 (EST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199505151244.NAA13930@colombo.telesys-innov.fr> from "Philippe BRAND" at May 15, 95 01:44:34 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 277 Message-Id: <95May16.061939+0300_eet_dst.90564-1+4@nic.funet.fi> > - at least a beta version of FAQ is ready GAK! Ok, I'll start pushing :-) > -- > Philippe BRAND > phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB > AmigaDOS GNU Project, AmigOS Net/WWW coordinator. > http://www.telesys-innov.fr/about/PhB.html Lynn From amiga-gcc-port-owner@nic.funet.fi Tue May 16 06:33:17 1995 Received: from nickel.ucs.indiana.edu ([129.79.10.5]) by nic.funet.fi with SMTP id <90744-1>; Tue, 16 May 1995 06:30:55 +0300 Received: by nickel.ucs.indiana.edu (5.65c+/10jsm) id AA25966; Mon, 15 May 1995 22:30:46 -0500 From: onnie lynn winebarger Subject: Another question (asm()) To: amiga-gcc-port@nic.funet.fi Date: Mon, 15 May 1995 22:30:45 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 239 Message-Id: <95May16.063055+0300_eet_dst.90744-1+5@nic.funet.fi> I forgot this before, but it seemed like there were some people having trouble with asm() (at least there were lots of questions at one time). Some syntax and some about register use. Anybody have a standard answer for these things? Lynn From amiga-gcc-port-owner@nic.funet.fi Tue May 16 07:51:21 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90744-3>; Tue, 16 May 1995 07:48:01 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sBFHb-0004nqC; Mon, 15 May 95 22:35 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: FAQ start To: owinebar@nickel.ucs.indiana.edu (onnie lynn winebarger) Date: Mon, 15 May 1995 22:35:03 -0700 (MST) Cc: zrawi01@decap2.zdv.uni-tuebingen.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <95May16.061623+0300_eet_dst.90744-3+5@nic.funet.fi> from "onnie lynn winebarger" at May 15, 95 10:15:57 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1019 > > However, I was not able to rebuild gcc on my Amiga: cc1 crashed > > immediately. > Is this a local problem, something with the gcc code, or buggy cc1? Must be a local problem. Gcc is very stable here. > > The latest (almost :-) version of the installer script is in dev/gcc > > on Aminet, too. IMO all common installation problems should be fixed > > with the script: OS header installation, GNU: assign and OS header > > installation. > Ok, I'll stick this in that section ("Use the Installer script!!!") > (or something like that). > Does this apply to the FreshFish distribution as well? No. To run gcc off the FreshFish CD all you have to do is arrange to run the "startup script" on the CD from your s:User-Startup. No other installation per se is required. You can of course copy everything off the CD to a hard drive if you have the space and need the faster speed, but the difference is not as great as you might think, particularly if you have a quad speed or greater CD-ROM drive. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue May 16 09:45:36 1995 Received: from zaz.kom.auc.dk ([130.225.51.10]) by nic.funet.fi with SMTP id <90431-4>; Tue, 16 May 1995 09:43:51 +0300 Received: from skoda.kom.auc.dk (jds@skoda.kom.auc.dk [130.225.51.24]) by zaz.kom.auc.dk (8.6.12/8.6.12) with ESMTP id IAA14667; Tue, 16 May 1995 08:43:43 +0200 Received: (from jds@localhost) by skoda.kom.auc.dk (8.6.12/8.6.12) id IAA16582; Tue, 16 May 1995 08:43:42 +0200 Date: Tue, 16 May 1995 08:43:42 +0200 From: Jes Degn Soerensen Message-Id: <199505160643.IAA16582@skoda.kom.auc.dk> To: Philippe BRAND Cc: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) Subject: Question In-Reply-To: <199505151719.SAA15326@colombo.telesys-innov.fr> References: <199505151719.SAA15326@colombo.telesys-innov.fr> Philippe BRAND writes: > I've got one question: who's in contact with Amiga Technologies in Germany ? > Just wondering... ;-) Well the good old CBMNet is still alive in Germany, Denmark, Holland & Switzerland (and maybe a few others, I'm not sure), so I would consider myself to be in the cathegory. Good old Dr. Peter Kittel can't stay away from the net, so he hooked up from home, after he was layed off from C= Germany. He has already spoken about the importance of getting the developers programme back on track ASAP, so I don't think it will take long before they will accept new people on the net. If any of you used to have access to CBMNet, but lost it with the collapse of your national C= subsidary, I suggest you contact Thomas Giger who is still kinda "boss" on the net at giger@ganesha.com, to get you on the mailinglists. People who are not registered developers might be able to get on the adsp.adsp list aswell, but I think only one should ask that question and post the result here, before Thomas gets his harddisk filled with letters. Remember Thomas is not associated with Escom (AFAIK) but he's the one that connects CBMNet to the Internet (for his own money btw). Regards Jes From amiga-gcc-port-owner@nic.funet.fi Tue May 16 11:01:08 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90247-1>; Tue, 16 May 1995 10:59:44 +0300 Received: by colombo.telesys-innov.fr; Tue, 16 May 1995 10:01:29 +0100 From: Philippe BRAND Message-Id: <199505160901.KAA17242@colombo.telesys-innov.fr> Subject: Re: Avis à tous To: ensta!citi2.fr!jussieu.fr!fdn.fr!sxpo.fdn.org!ramses.fdn.org!pred@taloa.unice.fr (Paul Redondo) Date: Tue, 16 May 1995 10:01:28 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <2fb8387b@ramses.fdn.org> from "Paul Redondo" at May 15, 95 11:30:35 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 761 Paul Redondo writes: > Bon vent Gilles :-), et n'oublies pas le petit monde francophone :-). > Relations presse ? Alors tu vas lacher encore plus difficilement les > niouzes toutes fraiches que tu as l'habitude de detenir ??? ;-) Dur... Et son point sur Ramses alors ? ;-) Il le conserve donc aura de toute facon acces aux News. > Amiga Technologies... Qui aurait cru que l'Amiga redeviendrait un jour > une societe a part entiere, comme a ses debuts... Il en a coule de l'eau > sous les ponts depuis... "Amiga Computer". Ils ont change hier apres-midi, dixit Gilles hier soir. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue May 16 11:03:41 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90312-2>; Tue, 16 May 1995 11:02:14 +0300 Received: by colombo.telesys-innov.fr; Tue, 16 May 1995 10:03:30 +0100 From: Philippe BRAND Message-Id: <199505160903.KAA17266@colombo.telesys-innov.fr> Subject: Re: FAQ start To: hans@wyst.hobby.nl (Hans Verkuil) Date: Tue, 16 May 1995 10:03:29 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9505151906.07eq@wyst.hobby.nl> from "Hans Verkuil" at May 15, 95 08:06:45 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 543 Hans Verkuil writes: > Replace the vfork() call in jobs.c by vfork2(). That's all! That's the nicest patch I ever heard about ;-) > Due to the -resident fix all base-relative libraries need to be recompiled, > the current base-relative libraries are completely useless. Oh now I know why I couldn't get pdksh working... "just" forgot to recompile libgcc.a ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue May 16 12:13:19 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90359-4>; Tue, 16 May 1995 12:11:42 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May16.121142+0300_eet_dst.90359-4+14@nic.funet.fi> From: To: Date: Tue, 16 May 1995 12:11:41 +0300 Date: Tue, 16 May 1995 11:09:11 +0200 (METDST) From: Rask Lambertsen To: Hans Verkuil Cc: amiga-gcc-port@nic.funet.fi, fnf@fishpond.cygnus.com, lhecking@nmrc.ucc.ie Subject: Re: sh memory leak fixed. In-Reply-To: <9504301448.079j@wyst.hobby.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject : Re: sh memory leak fixed. On Sun, 30 Apr 1995, Hans Verkuil wrote: > ! * this is an implementation extension to the `real' vfork2(). Normally you > * can only cause the parent to resume by calling _exit() or execve() from > * the child. Since I can't provide a real fork() on the Amiga, this function > * is a third possibility to make the parent resume. You have then two > * concurrent processes sharing the same frame and global data... Please be > ! * EXTREMELY careful what you may do and what not. vfork2() itself is a hack, > * this is an even greater one... > + * > + * DO NOT use this function in combination with vfork(), or you'll get a big > + * memory leak. Only use it with vfork2(). > * > * Note that this function should really be static, but if you make it static I'm curious: Why isn't it possible to provide a real fork()? Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue May 16 12:57:44 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90431-1>; Tue, 16 May 1995 12:54:57 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id LAA03968; Tue, 16 May 1995 11:53:26 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id KAA09479; Tue, 16 May 1995 10:54:52 +0200 Date: Tue, 16 May 1995 10:54:52 +0200 From: Niklas Hallqvist Message-Id: <199505160854.KAA09479@linda.appli.se> To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95May16.121142+0300_eet_dst.90359-4+14@nic.funet.fi> (gc948374@gbar.dtu.dk) >>>>> "Rask" == gc948374 writes: Rask> I'm curious: Why isn't it possible to provide a real fork()? fork(2)'s semantics states that a copy of the original process' address space be created and that both processes should be able to run simultaneously in these distinct address spaces. This is only possible with either a MMU used to map the same virtual addresses to different physical ones, or by swapping complete address spaces at every task switch. Otherwise, both processes would clobber each others memory. Now, not all Amiga's have an MMU (even if they had, it would be somewhat nasty as AmigaOS uses the concept of a snigle address space throughout the system code, e.g. IPC is done by passing an address, not by copy, or a mapping (copy-on-write). So that leaves the swapping solution, which would be quite expensive even if swapped to RAM as well as being tricky if asynchrounous IPC occurred (interrupts, DMA, or reads of messages from a process when the process address space has moved). I challenge you to write a real fork(2) for AmigaOS, you'll soon discover that it isn't easy ;-). However, there is a solution, run a real OS instead, like NetBSD or maybe Linux/m68k (I have hopes of Mach/Lites or Mach/Hurd sometime in the future) :-). I only run AmigaDOS as a bootloader these days anyway. Of course a Nice AmigaOS emulator for some of the above mentioned systems would be great (esp. for Mach). Niklas From amiga-gcc-port-owner@nic.funet.fi Tue May 16 13:14:22 1995 Received: from zaz.kom.auc.dk ([130.225.51.10]) by nic.funet.fi with SMTP id <90476-3>; Tue, 16 May 1995 13:11:43 +0300 Received: from skoda.kom.auc.dk (jds@skoda.kom.auc.dk [130.225.51.24]) by zaz.kom.auc.dk (8.6.12/8.6.12) with ESMTP id MAA21545; Tue, 16 May 1995 12:11:21 +0200 Received: (from jds@localhost) by skoda.kom.auc.dk (8.6.12/8.6.12) id MAA23904; Tue, 16 May 1995 12:11:19 +0200 Date: Tue, 16 May 1995 12:11:19 +0200 From: Jes Degn Soerensen Message-Id: <199505161011.MAA23904@skoda.kom.auc.dk> To: Philippe BRAND Cc: ensta!citi2.fr!jussieu.fr!fdn.fr!sxpo.fdn.org!ramses.fdn.org!pred@taloa.unice.fr (Paul Redondo), amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) Subject: Re: Avis à tous In-Reply-To: <199505160901.KAA17242@colombo.telesys-innov.fr> References: <2fb8387b@ramses.fdn.org> <199505160901.KAA17242@colombo.telesys-innov.fr> Philippe BRAND writes: > Paul Redondo writes: > > > Bon vent Gilles :-), et n'oublies pas le petit monde francophone :-). > > Relations presse ? Alors tu vas lacher encore plus difficilement les > > niouzes toutes fraiches que tu as l'habitude de detenir ??? ;-) Dur... > > Et son point sur Ramses alors ? ;-) Il le conserve donc aura de toute facon > acces aux News. > > > Amiga Technologies... Qui aurait cru que l'Amiga redeviendrait un jour > > une societe a part entiere, comme a ses debuts... Il en a coule de l'eau > > sous les ponts depuis... > > "Amiga Computer". Ils ont change hier apres-midi, dixit Gilles hier soir. Naa fatter i heller ikke en brik af dette? Well maybe I should try a rough english version: don't you understand anything of the text above aswell? Jes From amiga-gcc-port-owner@nic.funet.fi Tue May 16 13:22:56 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90261-2>; Tue, 16 May 1995 13:21:54 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May16.132154+0300_eet_dst.90261-2+22@nic.funet.fi> From: To: Date: Tue, 16 May 1995 13:21:50 +0300 Date: Tue, 16 May 1995 12:20:34 +0200 (METDST) From: Rask Lambertsen To: Jes Degn Soerensen Cc: Philippe BRAND , Paul Redondo , Amiga-Gcc Liste Subject: Re: Avis à tous In-Reply-To: <199505161011.MAA23904@skoda.kom.auc.dk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 16 May 1995, Jes Degn Soerensen wrote: > Philippe BRAND writes: > > Paul Redondo writes: > >=20 > > > Bon vent Gilles :-), et n'oublies pas le petit monde francophone :-)= .. > > > Relations presse ? Alors tu vas lacher encore plus difficilement les > > > niouzes toutes fraiches que tu as l'habitude de detenir ??? ;-) Dur.= ... > >=20 > > Et son point sur Ramses alors ? ;-) Il le conserve donc aura de toute = facon > > acces aux News. > >=20 > > > Amiga Technologies... Qui aurait cru que l'Amiga redeviendrait un jo= ur > > > une societe a part entiere, comme a ses debuts... Il en a coule de l= 'eau > > > sous les ponts depuis... > >=20 > > "Amiga Computer". Ils ont change hier apres-midi, dixit Gilles hier so= ir. >=20 > Naa fatter i heller ikke en brik af dette? N=D7, absolut intet. Men manden ser ud til at v=D7re glad. =20 > Well maybe I should try a rough english version: don't you understand > anything of the text above aswell? I understand absolutely nothing of the above. Can we agree on keeping=20 this mailing list in english? Regards, __________________________________________________________________________= _ / = \ | Rask Ingemann Lambertsen or = | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ = | | Keyboard error: and are stuck - press to continue = | \__________________________________________________________________________= _/ From amiga-gcc-port-owner@nic.funet.fi Tue May 16 13:24:22 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <90222-2>; Tue, 16 May 1995 13:23:13 +0300 Received: from kalle.lysator.liu.se (kalle.lysator.liu.se [130.236.254.26]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id MAA15126; Tue, 16 May 1995 12:22:58 +0200 From: Niels M|ller Received: (nisse@localhost) by kalle.lysator.liu.se (8.6.11/8.6.11) id MAA03529; Tue, 16 May 1995 12:21:38 +0200 Date: Tue, 16 May 1995 12:21:38 +0200 Message-Id: <199505161021.MAA03529@kalle.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: niklas@appli.se CC: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-reply-to: <199505160854.KAA09479@linda.appli.se> (message from Niklas Hallqvist on Tue, 16 May 1995 10:54:52 +0200) Niklas wrote: However, there is a solution, run a real OS instead, like NetBSD or maybe Linux/m68k (I have hopes of Mach/Lites or Mach/Hurd sometime in the future) :-). I only run AmigaDOS as a bootloader these days anyway. Of course a Nice AmigaOS emulator for some of the above mentioned systems would be great (esp. for Mach). Niklas A little off topic, but I'm curious: Are you making any progress on Mach? From amiga-gcc-port-owner@nic.funet.fi Tue May 16 13:25:53 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90050-3>; Tue, 16 May 1995 13:25:28 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HQKLEEZXI88WW4VY@LEON.CTI.GR>; Tue, 16 May 1995 13:01:53 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA03180; Mon, 15 May 95 13:21:29 +0300 Date: Mon, 15 May 1995 13:21:28 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: FAQ start In-reply-to: <9505150913.AA12020@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at May 15, 95 11:13:29 am To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Cc: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9505151021.AA03180@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 788 > - If you *need* to open a library manually, do it as follows: > > #include > #include > #include > #include . . . > if (!(IntuitionBase = (struct IntuitionBase *) > OpenLibrary("intuition.library", 37))) { As OpenLibrary is a function in exec.library, I would recommend adding #include in the list of included files, so that the appropriate prototype/inline function is included. (The cast to struct IntuitionBase * should be kept, as OpenLibrary returns a struct Library * .) -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Need a genius to unravel it..." "But you *are* a genius!" "Oh, yes! I definitely remember that!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue May 16 13:32:21 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <90312-2>; Tue, 16 May 1995 13:31:26 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA17559 (5.65c-7/7.3w-FAU); Tue, 16 May 1995 12:31:02 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA10748 (5.x/7.3w-FAU); Tue, 16 May 1995 12:31:00 +0200 From: Tobias Ruland Message-Id: <9505161031.AA10748@immd8.informatik.uni-erlangen.de> Date: Tue, 16 May 1995 12:30:57 +0200 To: bug-gdb@prep.ai.mit.edu Subject: Bug - what else Cc: amiga-gcc-port@lists.funet.fi dear gdb developers i've found a bug in gdb. Version: GDB 4.14 (sparc-sun-solaris2.4) Interface: XEmacs Bug Description: GDB does not get/set always correct arguments for functions. Bug reproducing procedure: Use the following example C++ program: ------------------------ CUT HERE ---------------------------- double test(double a,double b,double c,double d,double e,double f) { return 0; } int main() { int a; a=0; return a; } ------------------------ CUT HERE ---------------------------- compile it (-ggdb) and load it into gdb/xemacs. now: (gdb) b main Breakpoint 1 at 0x107e4: file bug.cxx, line 7. (gdb) run Starting program: .../a.out Breakpoint 1, main () at bug.cxx:7 (gdb) b test Breakpoint 2 at 0x107b0: file bug.cxx, line 2. (gdb) p test(0,1,2,3,4,5) Breakpoint 2, test (a=4.9406564584124654e-324, b=4.2439915834127416e-314, c=8.4879831663314175e-314, d=1.3087544257612877e-314, e=-2.027766907068094e+295, f=-5.9590254483644624e+256) at bug.cxx:2 The program being debugged stopped while in a function called from GDB. [...] as you can see the argument list is completely nonsense. while stepping through 'test' the function uses those wrong arguments, too. any ideas/fixes/comments? pls answer! c u tobias --------------------------------------------------------------------------- Tobias Ruland (student at Dept. of Artificial Intelligence, Univ. Erlangen) MAIL: tsruland@immd8.informatik.uni-erlangen.de (Please write in ENGLISH, GERMAN or FINNISH) WWW: http://www8.informatik.uni-erlangen.de/~tsruland From amiga-gcc-port-owner@nic.funet.fi Tue May 16 13:44:40 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90803-1>; Tue, 16 May 1995 13:41:55 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA26137; Tue, 16 May 1995 11:40:47 +0100 From: Lars Hecking Message-Id: <199505161042.LAA02826@mostar.nmrc.ucc.ie> Subject: fork() and friends To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Tue, 16 May 1995 11:42:37 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Rask Lambertsen" at May 16, 95 11:09:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 5575 > I'm curious: Why isn't it possible to provide a real fork()? Excerpt from an old ixemul readme (pre-39.45): Markus M. Wild March 16, 1992 [loads deleted] Some notes to vfork() and friends ================================= **IX/BSD process management is one of the most nasty design differences between AmigaDOS ans **IX/BSD. `fork()' for example is hardly possible to implement on AmigaDOS, as it requires to create an identical copy of the parent process. This is only feasible with virtual memory, where processes can be mapped at equal places in memory. Under AmigaDOS this would have to be simulated by copying of stack and malloc'd data whenever a process is activated, and copying them to a safe place before it is disactivated. This problem can be avoided, if the program to be run under AmigaDOS is only fork()ing, because it just wants to start another process. In that case, no such copying as described before is necessary, and BSD therefore invented the `vfork()' function, which works like `fork', but runs the child on the parents memory segments (stack and malloc'd data). While the child is using the parents resources, the parent is sleeping in a not interruptible state. That much for theory;-) I tried to implement an as compatible as possible vfork() function, that behaves like the BSD one. This should work under any OS version, for Kickstart 1.3 the arp.library is used, starting with OS 2.0 dos.library is powerful enough to do it itself. Since I won't try to implement `fork', I provided a possible alternative (you tell me;-)). As an extension, you get the `vfork_resume()' function, which causes the parent to resume, just like it would if you called `_exit()' or one of the `exec*()' functions. Since this function is quite dangerous (and an even bigger hack than vfork() itself..), here's what's happening in `vfork_resume()': o the child switches to its own stack. After vfork(), the child is using the stack of the parent process. Since no two processes can share the same stack in parallel, vfork_resume() causes a switch to the `real' stack of the child. o the parent is sent a wakeup message. o both processes run concurrently The first point is the most important one: Since vfork_resume() changes the stack pointer of the running process, you can't refer to any variables or parameters anymore after calling vfork_resume()! Only register variables survive such a call, and you have to explicitly store values in register variables that are subject to survive! There's another potential problem with vfork_resume(): ************************************************************************** Don't exit() from the parent before all vfork()'d children have died!! ************************************************************************** Since exiting from the parent causes the parents code and data segments to be deallocated, the child would find itself without code space to run on, and would probably cause a severe machine crash! So always call at least `wait (0)' before returning from the parent. exec*() ======= In most cases, you just use `vfork()' to later overlay the process with a new image, that is you want to start another program. The way AmigaDOS loads processes is not too well suited to do `exec' style program starting, yet it is possible, although with slight resource wasting.. First problem is, that all exec* functions pass an argument vector to the new program, whereas AmigaDOS programs expect to be passed an argument line (instead of the vector of arguments). Since in my opinion it would be a good thing if a program could get an argument vector directly (in that case the inherent problem of passing multi word arguments to a program would be finally solved, no more weird quoting needed!). That's why I provided a mechanism that allows this vector passing, and it works like this (look at crt0.c for a concrete implementation of this concept!): The program has to provide a magic header at the first executable location in its code. This magic header looks like this: o JMP instruction to common AmigaDOS startup o struct exec area. Use the OMAGIC a_magic code. o provide an alternate entry vector in a_entry. execve() jumps thru this vector to pass vectors to your program, instead of going thru the normal AmigaDOS startup part. As long as you use my crt0.o and libc.a, this whole thing is completely transparent to your program, you only have to care for it, if you want to support the mechanism in other languages as well. The second problem is how to start `old' AmigaDOS programs from execve(). If the program has the described magic header, starting is easy. Else another approach is taken, depending on the OS version. Common to both OS versions (1.3 and 2.0) is redirection of stdin and stdout. Since the new program can't refer to the real file descriptors (I can't pass the open library without my startup code), I have to setup DOS fields to use my filehandles. This may succeed or not, depending on whether the descriptors in question are realized by DOS files or not (in the future a not-compatible alternative would be descriptors that refer to sockets!). Actual starting of the program is done with RunCommand() under 2.0, and some own hack under 1.3. If someone is interested to get this working well under 1.3, I'd be happy to include a better starter function, my kludge doesn't particularly deal graceful with BCPL functions... [rest deleted] Hope this helps. Slan agat, Lars From amiga-gcc-port-owner@nic.funet.fi Tue May 16 13:49:50 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <90237-3>; Tue, 16 May 1995 13:49:19 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA18402 (5.65c-7/7.3w-FAU); Tue, 16 May 1995 12:48:44 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA11237 (5.x/7.3w-FAU); Tue, 16 May 1995 12:48:42 +0200 From: Tobias Ruland Message-Id: <9505161048.AA11237@immd8.informatik.uni-erlangen.de> Date: Tue, 16 May 1995 12:48:39 +0200 To: Lars Hecking Cc: gc948374@gbar.dtu.dk (Rask Lambertsen), amiga-gcc-port@nic.funet.fi (Amiga GCC List) Subject: fork() and friends In-Reply-To: <199505161042.LAA02826@mostar.nmrc.ucc.ie> References: <199505161042.LAA02826@mostar.nmrc.ucc.ie> Lars Hecking writes: > > > I'm curious: Why isn't it possible to provide a real fork()? > > Excerpt from an old ixemul readme (pre-39.45): > > Markus M. Wild March 16, 1992 > > [loads deleted] > > Some notes to vfork() and friends > ================================= > [...] maybe it would be helpful if you all try to contribute to the amiga-os-replace- ment-project. i would UNIX not call a "real" or good operating system... c u tobias --------------------------------------------------------------------------- Tobias Ruland (student at Dept. of Artificial Intelligence, Univ. Erlangen) MAIL: tsruland@immd8.informatik.uni-erlangen.de (Please write in ENGLISH, GERMAN or FINNISH) WWW: http://www8.informatik.uni-erlangen.de/~tsruland From amiga-gcc-port-owner@nic.funet.fi Tue May 16 13:55:29 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <90825-4>; Tue, 16 May 1995 13:54:07 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA03185; Tue, 16 May 1995 11:53:34 +0100 Date: Tue, 16 May 1995 11:53:06 +0100 (BST) From: Peter Ivimey-Cook To: Tobias Ruland Cc: Lars Hecking , Rask Lambertsen , Amiga GCC List Subject: Re: fork() and friends In-Reply-To: <9505161048.AA11237@immd8.informatik.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Tobias wrote: > maybe it would be helpful if you all try to contribute to the amiga-os-replace- > ment-project. i would UNIX not call a "real" or good operating system... > Please could you keep such comments to comp.sys.amiga.advocacy or similar. Bot Unix and AmigaDOS have their strengths and weaknesses - yuo just try running NT, OS/2, or Unix on Amiga hardware! Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Tue May 16 14:12:21 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <90618-4>; Tue, 16 May 1995 14:10:45 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA19478 (5.65c-7/7.3w-FAU); Tue, 16 May 1995 13:09:43 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA11433 (5.x/7.3w-FAU); Tue, 16 May 1995 13:09:38 +0200 From: Tobias Ruland Message-Id: <9505161109.AA11433@immd8.informatik.uni-erlangen.de> Date: Tue, 16 May 1995 13:09:35 +0200 To: Peter Ivimey-Cook Cc: Tobias Ruland , Lars Hecking , Rask Lambertsen , Amiga GCC List Subject: Re: fork() and friends In-Reply-To: References: <9505161048.AA11237@immd8.informatik.uni-erlangen.de> Peter Ivimey-Cook writes: > Tobias wrote: > > > maybe it would be helpful if you all try to contribute to the amiga-os-replace- > > ment-project. i would UNIX not call a "real" or good operating system... > > Please could you keep such comments to comp.sys.amiga.advocacy or > similar. Bot Unix and AmigaDOS have their strengths and weaknesses - yuo > just try running NT, OS/2, or Unix on Amiga hardware! IMO that has nothing to do with "comp.sys.amiga.advocacy". a "good" operating system would have to combine the safety and "developer friendliness" of unix with the user comfortability and flexibility of amiga os. or would you call UNIX "user friendly and flexible" ??? c u tobias btw: is there a NT for amiga? :-) (big smiley) From amiga-gcc-port-owner@nic.funet.fi Tue May 16 15:06:37 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90909-1>; Tue, 16 May 1995 15:04:25 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Tue, 16 May 1995 14:03:16 +0200 Received: from mammern.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA29749; Tue, 16 May 95 14:03:21 +0200 Date: Tue, 16 May 95 14:03:21 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9505161203.AA29749@inf-wiss.uni-konstanz.de> To: tsruland@immd8.informatik.uni-erlangen.de Subject: Re: fork() and friends Cc: amiga-gcc-port@nic.funet.fi Tobias Ruland wrote: >maybe it would be helpful if you all try to contribute to the amiga-os-replace- >ment-project. i would UNIX not call a "real" or good operating system... Go and contribute if you wish. I'm not looking forward to having UNIX or X as a "standard" on my Amiga. Keep AmigaOS slick and fast and clean and nice! What we can do is ease the porting of programs and that's what this mailing-list is for, but I'm sure that most people on this list don't want to start programming X (or maybe Windows) applications or use all of the tricks of ioctl() and fork() here as if AmigaOS was some variant of UNIX. 'The difference makes it!' Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Tue May 16 15:39:48 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90669-1>; Tue, 16 May 1995 15:38:28 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Tue, 16 May 1995 14:37:53 +0200 Received: from mammern.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA29928; Tue, 16 May 95 14:37:59 +0200 Date: Tue, 16 May 95 14:37:59 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9505161237.AA29928@inf-wiss.uni-konstanz.de> Received: by mammern.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA09755; Tue, 16 May 95 14:37:57 +0200 To: Ville-Pertti Keinonen Cc: amiga-gcc-port@nic.funet.fi Subject: Re: New GCC installer script In-Reply-To: References: Please excuse the reply to an old mail: Ville-Pertti Keinonen writes: > If you delete a file before you delete a hard link to it, you're in a lot > more trouble than if you make a soft link invalid. (You end up with a > somewhat corrupt filesystem) Soft links are safe, the deletion problem > can easily be worked around and doesn't really cause any damage. Are you sure this wasn't a known bug of the 3.0 (V39) filesystem (maybe even 2.x?) which has been fixed in 3.1 (V40)? Didn't some developer notes (or Randell himself) state something along this? Anybody care to comment? This "bug report" has been cited and repeated too many times, while I believe that the bug has been fixed a long time ago. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Tue May 16 16:00:00 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90665-1>; Tue, 16 May 1995 15:58:52 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May16.155852+0300_eet_dst.90665-1+30@nic.funet.fi> From: To: Date: Tue, 16 May 1995 15:58:48 +0300 Date: Tue, 16 May 1995 14:57:31 +0200 (METDST) From: Rask Lambertsen To: Joerg-Cyril Hoehle Cc: Ville-Pertti Keinonen , amiga-gcc-port@nic.funet.fi Subject: Re: New GCC installer script In-Reply-To: <9505161237.AA29928@inf-wiss.uni-konstanz.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject : Re: New GCC installer script On Tue, 16 May 1995, Joerg-Cyril Hoehle wrote: > Please excuse the reply to an old mail: > > Ville-Pertti Keinonen writes: > > If you delete a file before you delete a hard link to it, you're in a lot > > more trouble than if you make a soft link invalid. (You end up with a > > somewhat corrupt filesystem) Soft links are safe, the deletion problem > > can easily be worked around and doesn't really cause any damage. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Are you sure this wasn't a known bug of the 3.0 (V39) filesystem (maybe > even 2.x?) which has been fixed in 3.1 (V40)? Didn't some developer notes > (or Randell himself) state something along this? Anybody care to comment? > This "bug report" has been cited and repeated too many times, while I > believe that the bug has been fixed a long time ago. There is no such bug in 2.04 (V37) (not on my system at least) so maybe it was one of the numerous DOS bugs in 2.0 (V36). Soft links can give you lots of "fun" if you delete the file they point to. Easily worked around? How? Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue May 16 16:05:18 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90642-2>; Tue, 16 May 1995 16:04:21 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Tue, 16 May 1995 15:04:06 +0200 Received: from mammern.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA00146; Tue, 16 May 95 15:04:11 +0200 Date: Tue, 16 May 95 15:04:11 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9505161304.AA00146@inf-wiss.uni-konstanz.de> Received: by mammern.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA09789; Tue, 16 May 95 15:04:07 +0200 To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Subject: 2.7.0 and reentrant struct return convention (Was: Re: FAQ start) In-Reply-To: <199505151244.NAA13930@colombo.telesys-innov.fr> References: <9505150913.AA12020@decap2.zdv.uni-tuebingen.de> <199505151244.NAA13930@colombo.telesys-innov.fr> Philippe BRAND writes: > GENERIC 2.7.0 should be out next week. However I won't release Amiga version > until: > > - 2.7.0 beta distribution is TESTED and people REPORT on it. > - ixemul changes are done, support for stack checking & auto-stack growing > - latest libnix is ready (0.8 ?) [...] I'd say that as a new GCC and a new ixemul and a new libnix are to be shipped, we should consider switching back to the good old 2.3.3 (and earlier) _non_-static structure return convention that I mentioned a few weeks ago. Actually I'm wondering if my mail went through because it caused no reaction at all. Thus, to repeat myself: - Since > 2.3.3 (at least for 2.5.6-8 and 2.6.3), GCC on the Amiga uses the braind-damaged static struct return convention, making it impossible to write safe reentrant or resident programs using functions that return structures. This was not the case in 2.3.3 and 1.4.0 where structure space would be allocated from the stack by the calling function. + Changing this back to a reasonable behaviour is a matter of configuring GCC. But it could also be a matter of recompiling libnix and ixemul as maybe two or three functions are concerned. This causes a minor compatibility issue. I say minor because it seems that no ixemul client suffered from the change from reentrant to static, so why should it be different on the way back? Just another 2 cents... Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Tue May 16 16:16:46 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90631-2>; Tue, 16 May 1995 16:15:31 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 16 May 95 15:14 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 16 May 95 14:58 MET DST Message-Id: Subject: Re: fork() and friends To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 16 May 1995 14:58:24 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 624 it seems i dindt get the point. you cant implement fork() because you will avoid collisions between the child and parent task, right ? but this can only happen with global-vars, something where the programmer should care about. all other vars are local and will not affect an other. btw: will we see trace() in ixemul v41.0 ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Tue May 16 16:37:26 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <90610-4>; Tue, 16 May 1995 16:36:11 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa25855; 16 May 95 13:56 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id ab28137; 16 May 95 13:55 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA000yn; Tue, 16 May 95 12:03:57 GMT Date: Tue, 16 May 95 12:03:57 GMT Message-Id: <9505161203.AA000ym@flevel.demon.co.uk> Message-Id: <20ac55ac.c8320-dev@flevel.demon.co.uk> In-Reply-To: <9505161048.AA11237@immd8.informatik.uni-erlangen.de> (from Tobias Ruland ) (at Tue, 16 May 1995 12:48:39 +0200) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: tsruland@immd8.informatik.uni-erlangen.de Cc: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi, lhecking@nmrc.ucc.ie Subject: Re: fork() and friends Hi Tobias, > > > I'm curious: Why isn't it possible to provide a real fork()? > > > > Excerpt from an old ixemul readme (pre-39.45): > > > > Markus M. Wild March 16, 1992 > > > > [loads deleted] > > > > Some notes to vfork() and friends > > ================================= > > [...] > > maybe it would be helpful if you all try to contribute to the amiga-os-replace- > ment-project. i would UNIX not call a "real" or good operating system... Do you know an email address for the people who are working on this os-replacement project?? Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue May 16 16:40:10 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90635-4>; Tue, 16 May 1995 16:39:52 +0300 Received: by colombo.telesys-innov.fr; Tue, 16 May 1995 15:41:11 +0100 From: Philippe BRAND Message-Id: <199505161441.PAA21750@colombo.telesys-innov.fr> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Tue, 16 May 1995 15:41:10 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95May16.155852+0300_eet_dst.90665-1+30@nic.funet.fi> from "gc948374@gbar.dtu.dk" at May 16, 95 03:58:48 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 601 gc948374@gbar.dtu.dk writes: > > > somewhat corrupt filesystem) Soft links are safe, the deletion problem > > > can easily be worked around and doesn't really cause any damage. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Soft links can give you lots of "fun" if you delete the file they point to. > Easily worked around? How? Get MakeLink & DeleteLink from Aminet. With DeleteLink you'll be able to throw away orphan links. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue May 16 16:43:00 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90555-3>; Tue, 16 May 1995 16:42:33 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id OAA27830; Tue, 16 May 1995 14:40:54 +0100 From: Lars Hecking Message-Id: <199505161342.OAA03113@mostar.nmrc.ucc.ie> Subject: Re: fork() and friends To: dev@flevel.demon.co.uk Date: Tue, 16 May 1995 14:42:39 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <20ac55ac.c8320-dev@flevel.demon.co.uk> from "dev@flevel.demon.co.uk" at May 16, 95 12:03:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 247 > Do you know an email address for the people who are working on this > os-replacement project?? Try and -- WindowError:002 No error ... yet. From amiga-gcc-port-owner@nic.funet.fi Tue May 16 17:07:31 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90607-4>; Tue, 16 May 1995 16:55:15 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id PAA15778; Tue, 16 May 1995 15:53:26 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id OAA10790; Tue, 16 May 1995 14:51:32 +0200 Date: Tue, 16 May 1995 14:51:32 +0200 From: Niklas Hallqvist Message-Id: <199505161251.OAA10790@linda.appli.se> To: nisse@lysator.liu.se CC: amiga-gcc-port@nic.funet.fi, amiga-mach@nic.funet.fi, jclark@synergy.encinitas.ca.us In-reply-to: <199505161021.MAA03529@kalle.lysator.liu.se> (message from Niels M|ller on Tue, 16 May 1995 12:21:38 +0200) Subject: Re: Rhetorical Quesiton.... Reply-To: amiga-mach@nic.funet.fi [ This is an answer to two messages seen on different lists, however I made a Reply-To: header so that replies will get to the right spot. -NH ] >>>>> "John" == John E. Clark writes: John> Is this list essentially dead, and if not, where is John> any recent version of amiga-mach... Se below... >>>>> "Nisse" == Niels M|ller writes: Nisse> A little off topic, but I'm curious: Are you making any Nisse> progress on Mach? It's in coma :-) or maybe more like the Sleeping Beauty's deep sleep. I did last fall make a commitment to port Mach4 and LITES to the m68k architecture, because it looked like I would get some spare time at last. Several independent events made this spare time both vanish and turnover into a huge demand of "real" (ie. paid) work on my behalf, which won't go away until June or so, maybe not even then. The things I managed to get done before things got messed up, was only to compile a toolchain usable on NetBSD/m68k and AIX 3.2.5/PowerPC and a directory structure. I never got to actually test my toolchain as I never got to compile anything. I hope to begin this work again, I just don't know when... Niklas PS. Followups to Amiga-mach, or otherwise several people will get upset. Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Tue May 16 17:16:45 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90667-1>; Tue, 16 May 1995 17:16:02 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id QAA20337; Tue, 16 May 1995 16:08:25 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id PAA10850; Tue, 16 May 1995 15:01:47 +0200 Date: Tue, 16 May 1995 15:01:47 +0200 From: Niklas Hallqvist Message-Id: <199505161301.PAA10850@linda.appli.se> To: Walter.Harms@arbi.informatik.uni-oldenburg.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Walter Harms on Tue, 16 May 1995 14:58:24 +0200 (MET DST)) Subject: Re: fork() and friends >>>>> "Walter" == Walter Harms writes: Walter> it seems i dindt get the point. you cant implement Walter> fork() because you will avoid collisions between the child and Walter> parent task, right ? but this can only happen with Walter> global-vars, something where the programmer should care Walter> about. all other vars are local and will not affect an other. Nice try, but no go... Even the stack address space would be shared in a strict fork implementation. Thus this program would be hard to solve right: #include int main () { int i = 1; int *p = &i; int w; if (fork () > 0) { wait (&w); assert (i == 1); } else *p = 2; return 0; } As you see you can't copy the stack as then you will get p to point to another stack. Still, the i variable in both the parent and child needs to be distinct, i.e. not shared. Belive me, it's not easy to solve the traditional fork semantics in the Amiga OS. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Tue May 16 18:29:34 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90796-3>; Tue, 16 May 1995 18:27:35 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HQKVHCHFE88WW4TF@LEON.CTI.GR>; Tue, 16 May 1995 17:50:35 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA03180; Mon, 15 May 95 13:21:29 +0300 Date: Mon, 15 May 1995 13:21:28 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: FAQ start In-reply-to: <9505150913.AA12020@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at May 15, 95 11:13:29 am To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Cc: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9505151021.AA03180@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 788 > - If you *need* to open a library manually, do it as follows: > > #include > #include > #include > #include . . . > if (!(IntuitionBase = (struct IntuitionBase *) > OpenLibrary("intuition.library", 37))) { As OpenLibrary is a function in exec.library, I would recommend adding #include in the list of included files, so that the appropriate prototype/inline function is included. (The cast to struct IntuitionBase * should be kept, as OpenLibrary returns a struct Library * .) -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Need a genius to unravel it..." "But you *are* a genius!" "Oh, yes! I definitely remember that!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue May 16 18:38:44 1995 Received: by nic.funet.fi id <90751-4>; Tue, 16 May 1995 18:38:02 +0300 From: Leonard Norrgard To: zrawi01@decap2.zdv.uni-tuebingen.de CC: owinebar@nickel.ucs.indiana.edu, amiga-gcc-port@nic.funet.fi In-reply-to: <9505150913.AA12020@decap2.zdv.uni-tuebingen.de> (zrawi01@decap2.zdv.uni-tuebingen.de) Subject: Re: FAQ start Message-Id: <95May16.183802+0300_eet_dst.90751-4+35@nic.funet.fi> Date: Tue, 16 May 1995 18:37:52 +0300 > The main site of Aminet is ftp.wustl.edu in /pub/aminet, and has mirrors > world-wide. (list of sites?). ftp.funet.fi also serves to mirror. ftp.funet.fi doesn't mirror Aminet and has no plans to (to make a long story short). -- vinsci From amiga-gcc-port-owner@nic.funet.fi Tue May 16 18:53:36 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90913-3>; Tue, 16 May 1995 18:52:10 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26532-3>; Tue, 16 May 1995 17:51:41 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209262-1>; Tue, 16 May 1995 17:51:20 +0100 Subject: Re: fork() and friends From: Christian Stieber To: tsruland@immd8.informatik.uni-erlangen.de (Tobias Ruland) Date: Tue, 16 May 1995 17:51:19 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9505161109.AA11433@immd8.informatik.uni-erlangen.de> from "Tobias Ruland" at May 16, 95 01:09:35 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1294 Message-Id: <95May16.175120+0100mesz.209262-1+1592@hphalle0.informatik.tu-muenchen.de> > > > ment-project. i would UNIX not call a "real" or good operating system... > > > > Please could you keep such comments to comp.sys.amiga.advocacy or > > IMO that has nothing to do with "comp.sys.amiga.advocacy". a "good" > operating system would have to combine the safety and "developer friendliness" > of unix with the user comfortability and flexibility of amiga os. > or would you call UNIX "user friendly and flexible" ??? Depends. First of all, unix is "old". It's probably one of the oldest OSes that are still being used and developed a lot. Personally I'm very fond of microkernel architectures. With a microkernel OS, you could have Unix as the "main OS", but you could also bypass it if you want to do something that Unix can't do --- simply because Unix would just be another library. Of course, you could also have OS/2.library, AmigaOS.library and probably NT.library, all available at the same time :) Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Tue May 16 18:56:27 1995 Received: by nic.funet.fi id <90744-3>; Tue, 16 May 1995 18:55:54 +0300 From: Leonard Norrgard To: phb@colombo.telesys-innov.fr CC: hans@wyst.hobby.nl, amiga-gcc-port@lists.funet.fi In-reply-to: <199505160903.KAA17266@colombo.telesys-innov.fr> (message from Philippe BRAND on Tue, 16 May 1995 10:03:29 +0100 (BST)) Subject: Re: FAQ start Message-Id: <95May16.185554+0300_eet_dst.90744-3+39@nic.funet.fi> Date: Tue, 16 May 1995 18:55:51 +0300 > > Replace the vfork() call in jobs.c by vfork2(). That's all! > > That's the nicest patch I ever heard about ;-) There's been shorter patches... Rms once toggled a single bit in a binary to make a login program (I think) not ask for passwords, but instead print the passfords for all users... (The background to this patch was socio-philosophical, if memory serves, in case anyone wonders why rms did that). -- vinsci From amiga-gcc-port-owner@nic.funet.fi Tue May 16 19:13:18 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90657-1>; Tue, 16 May 1995 19:11:42 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26555-1>; Tue, 16 May 1995 18:10:58 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209262-2>; Tue, 16 May 1995 18:10:51 +0100 Subject: Re: New GCC installer script From: Christian Stieber To: gc948374@gbar.dtu.dk Date: Tue, 16 May 1995 18:10:42 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95May16.155852+0300_eet_dst.90665-1+30@nic.funet.fi> from "gc948374@gbar.dtu.dk" at May 16, 95 03:58:48 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 979 Message-Id: <95May16.181051+0100mesz.209262-2+1524@hphalle0.informatik.tu-muenchen.de> BTW, your mail system is messed up. The headers show up in the body of the mail... > Soft links can give you lots of "fun" if you delete the file they point to. > Easily worked around? How? There is _no_ delete-bug with softlinks in _any_ AmigaOS version. The problem is with the c:delete program, not with the softlinks. c:delete Lock()s the file before deleting it, in order to find out whether it is a file or a directory. Since Lock()ing an orphan link fails, c:delete cannot delete an orphan link. The "workaround" is a program that simply calls DeleteFile() on its arguments, without locking them first. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Tue May 16 19:14:34 1995 Received: by nic.funet.fi id <90278-3>; Tue, 16 May 1995 19:14:05 +0300 From: Leonard Norrgard To: Walter.Harms@arbi.informatik.uni-oldenburg.de CC: amiga-gcc-port@lists.funet.fi In-reply-to: (message from Walter Harms on Tue, 16 May 1995 14:58:24 +0200 (MET DST)) Subject: Re: fork() and friends Message-Id: <95May16.191405+0300_eet_dst.90278-3+43@nic.funet.fi> Date: Tue, 16 May 1995 19:13:59 +0300 > btw: will we see trace() in ixemul v41.0 ? What should trace() do?. If you mean ptrace(), chances for seeing it in working condition anytime soon are rather small. It's possible to do it, though. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Tue May 16 19:26:46 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90186-2>; Tue, 16 May 1995 19:24:44 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26549-4>; Tue, 16 May 1995 18:24:25 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209279-2>; Tue, 16 May 1995 18:24:07 +0100 Subject: Re: 2.7.0 and reentrant struct return convention From: Christian Stieber To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Tue, 16 May 1995 18:24:02 +0200 (MESZ) Cc: amiga-gcc-port@lists.funet.fi In-Reply-To: <9505161304.AA00146@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at May 16, 95 03:04:11 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 735 Message-Id: <95May16.182407+0100mesz.209279-2+1527@hphalle0.informatik.tu-muenchen.de> [ Changing struct return convention back to something safe ] > Actually I'm wondering if my mail went through because it caused no > reaction at all. Thus, to repeat myself: Just to cause a reaction: assuming that the stuff you say about the struct return convention is true (and I don't a reason why you might lie to us), I agree with you :) Just in case you care, Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Tue May 16 19:54:48 1995 Received: by nic.funet.fi id <90920-2>; Tue, 16 May 1995 19:53:28 +0300 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: New list for ixemul internals development Message-Id: <95May16.195328+0300_eet_dst.90920-2+39@nic.funet.fi> Date: Tue, 16 May 1995 19:53:22 +0300 For the few people that do active development on the internals of the ixemul library, a new mailing list now exists. This list is not for "normal" programmers that are merely using GCC and ixemul.library together to write software. It is for people who write ixemul.library itself. To get on the list, send mail to with the contents: sub ixemul firstname lastname Please note that the ixemul list exists on an other machine than amiga-gcc-port, and is run by using other list management software. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Wed May 17 10:55:18 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <90342-2>; Wed, 17 May 1995 10:52:01 +0300 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id JAA25678 for ; Wed, 17 May 1995 09:50:12 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA19307; Wed, 17 May 95 09:51:26 GMT Date: Wed, 17 May 95 09:51:26 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9505170951.AA19307@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: Shared librarie with libnix ? Hi, I see some lib*.o and dev*.o with libnix librarie. So, is it possible to easily create shared librarie with libnix ? And if yes, how to do this ? Thanks. \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier | Etudiant en Doctorat | Centre de Recherche en Informatique E-Mail: | Universite Louis Pasteur papier@dpt-info.u-strasbg.fr | Strasbourg - FRANCE ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Wed May 17 10:56:06 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <90774-4>; Wed, 17 May 1995 10:55:05 +0300 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id JAA25759 for ; Wed, 17 May 1995 09:53:20 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA19320; Wed, 17 May 95 09:54:34 GMT Date: Wed, 17 May 95 09:54:34 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9505170954.AA19320@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: Debug hunk info need ?? A few days ago, I have asked for a FindHit tool compatible with amigados-gcc executable. I ask Michael Sinz and he send me the source of FindHit. Now, I need to know what is the structure of gcc debug hunk. Thanks. \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier | Etudiant en Doctorat | Centre de Recherche en Informatique E-Mail: | Universite Louis Pasteur papier@dpt-info.u-strasbg.fr | Strasbourg - FRANCE ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Wed May 17 15:51:15 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <90572-2>; Wed, 17 May 1995 12:04:41 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA21795 (5.65c-7/7.3w-FAU); Wed, 17 May 1995 11:04:25 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA06584 (5.x/7.3w-FAU); Wed, 17 May 1995 11:04:22 +0200 From: Tobias Ruland Message-Id: <9505170904.AA06584@immd8.informatik.uni-erlangen.de> Date: Wed, 17 May 1995 11:04:22 +0200 To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Cc: tsruland@immd8.informatik.uni-erlangen.de, amiga-gcc-port@nic.funet.fi Subject: Re: fork() and friends In-Reply-To: <9505161203.AA29749@inf-wiss.uni-konstanz.de> References: <9505161203.AA29749@inf-wiss.uni-konstanz.de> Joerg-Cyril Hoehle writes: > Go and contribute if you wish. I'm not looking forward to having UNIX > or X as a "standard" on my Amiga. Keep AmigaOS slick and fast and clean > and nice! What we can do is ease the porting of programs and that's > what this mailing-list is for, but I'm sure that most people on this > list don't want to start programming X (or maybe Windows) applications > or use all of the tricks of ioctl() and fork() here as if AmigaOS was > some variant of UNIX. did i say anything that sounded like "from now X on all amigas!"??? X is an old and slow and bad concept... forget it. c u tobias From amiga-gcc-port-owner@nic.funet.fi Wed May 17 15:52:31 1995 Received: by nic.funet.fi id <90206-3>; Wed, 17 May 1995 14:09:59 +0300 From: Leonard Norrgard To: papier@indi1.u-strasbg.fr Cc: amiga-gcc-port@nic.funet.fi In-reply-to: <9505170954.AA19320@indi1.u-strasbg.fr> (papier@indi1.u-strasbg.fr) Subject: Re: Debug hunk info need ?? Message-Id: <95May17.140959+0300_eet_dst.90206-3+29@nic.funet.fi> Date: Wed, 17 May 1995 14:09:58 +0300 Nice with the original source for FindHit... In case it's OK to put it up for ftp, I'd appreciate if you would upload it to ftp.funet.fi:/pub/amiga/incoming/gnu and send me some mail. There are two sources for documentation on the Amiga GCC debug hunk. One would be the Amiga GCC linker source, the other one is a texinfo document that comes with the sources to GDB, the debugger. (stabs.texinfo). You will need to look at both. It should be pretty easy to convert FindHit to read the stabs debug info from the debug hunk -- Amiga GCC uses the unix a.out object file format stabs debug info stuffed into the amiga debug hunk. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Wed May 17 15:54:09 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90020-3>; Wed, 17 May 1995 15:31:28 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sBizG-0004nqC; Wed, 17 May 95 06:18 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Debug hunk info need ?? To: papier@indi1.u-strasbg.fr (Laurent Papier) Date: Wed, 17 May 1995 06:18:05 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9505170954.AA19320@indi1.u-strasbg.fr> from "Laurent Papier" at May 17, 95 09:54:34 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 520 > A few days ago, I have asked for a FindHit tool compatible with amigados-gcc > executable. I ask Michael Sinz and he send me the source of FindHit. > Now, I need to know what is the structure of gcc debug hunk. I believe Amiga gcc is currently configured to use "stabs" as the debugging format. The best documentation for stabs that I know of is in the gdb distribution, in the "doc" directory. Either ftp a copy from prep.ai.mit.edu in pub/gnu, or snarf a copy from one of my CDs if you have one available. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed May 17 23:04:53 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <90204-1>; Wed, 17 May 1995 16:14:45 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA10576 (5.65c8/IDA-1.4.4 for ); Wed, 17 May 1995 15:14:28 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA14580; Wed, 17 May 95 15:14:27 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9505171314.AA14580@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Shared librarie with libnix ? To: papier@indi1.u-strasbg.fr (Laurent Papier) Date: Wed, 17 May 1995 15:14:27 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9505170951.AA19307@indi1.u-strasbg.fr> from "Laurent Papier" at May 17, 95 09:51:26 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 306 > > I see some lib*.o and dev*.o with libnix librarie. > So, is it possible to easily create shared librarie with libnix ? > And if yes, how to do this ? > Try to get the libnix package from aminet. There's an example on how to write a shared library in it. But it's not as easy as with SAS... Matthias From amiga-gcc-port-owner@nic.funet.fi Wed May 17 23:05:39 1995 Received: by nic.funet.fi id <90440-3>; Wed, 17 May 1995 16:20:57 +0300 From: Leonard Norrgard To: tsruland@immd8.informatik.uni-erlangen.de CC: hoehle@inf-wiss.uni-konstanz.de, tsruland@immd8.informatik.uni-erlangen.de, amiga-gcc-port@nic.funet.fi In-reply-to: <9505170904.AA06584@immd8.informatik.uni-erlangen.de> (message from Tobias Ruland on Wed, 17 May 1995 11:04:22 +0200) Subject: Re: fork() and friends Message-Id: <95May17.162057+0300_eet_dst.90440-3+15@nic.funet.fi> Date: Wed, 17 May 1995 16:20:46 +0300 > X is an old and slow and bad concept... forget it. Jumping to conclusions? Guess you've never run X natively on a machine. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Thu May 18 13:15:14 1995 Received: from vinkku.hut.fi ([130.233.245.1]) by nic.funet.fi with SMTP id <90625-4>; Thu, 18 May 1995 13:09:58 +0300 Received: from lk-hp-6.hut.fi (lk-hp-6.hut.fi [130.233.244.37]) by vinkku.hut.fi (8.6.11/8.6.7) with ESMTP id NAA06980; Thu, 18 May 1995 13:09:54 +0300 Received: (tpeltone@localhost) by lk-hp-6.hut.fi (8.6.11/8.6.7) id NAA25789; Thu, 18 May 1995 13:09:53 +0300 Date: Thu, 18 May 1995 13:09:52 +0300 (EET DST) From: Teppo Peltonen To: onnie lynn winebarger cc: amiga-gcc-port@nic.funet.fi Subject: Re... not: Another question (asm()) + the new faq In-Reply-To: <95May16.063055+0300_eet_dst.90744-1+5@nic.funet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 15 May 1995, onnie lynn winebarger wrote: > I forgot this before, but it seemed like there were some people having > trouble with asm() (at least there were lots of questions at one time). > Some syntax and some about register use. > Anybody have a standard answer for these things? No way... these asm questions seem to pop up time after time on the list and in c.s.a.prog... And no one really seems to be able to answer them clearly enough for everyone to understand. Well - I've read a couple of those answers with not that much help at all (from the older posts too). Then I started to browse the gcc.guide and encountered an endless mess of all kinds of different asm-things... it was very confusing to try find what the thing was all about. After checking out some header files from os-include/inline/ I was convinced that it was impossible to understand anything from that mess. It is wonderful to see that someone is making a gcc faq. I just wish that the asm questions (and answers) will be there too. How to make inline functions with register arguments? How to really write inline headers for link libraries like mui (yes I know - they are there already... thanks to however wrote the headers). How to generate such headers so that they can be used without problems? How about converting SAS -style inline functions with reg args to gcc style? There's a couple of questions for the faq. And the answers? Well... someone else just has to write them - I don't have a glue. ;-/ > Lynn Teppo Peltonen (tpeltone@snakemail.hut.fi) From amiga-gcc-port-owner@nic.funet.fi Thu May 18 15:49:12 1995 Received: by nic.funet.fi id <90129-3>; Thu, 18 May 1995 15:47:13 +0300 From: Leonard Norrgard To: tpeltone@snakemail.hut.fi CC: owinebar@nickel.ucs.indiana.edu, amiga-gcc-port@nic.funet.fi In-reply-to: (message from Teppo Peltonen on Thu, 18 May 1995 13:09:52 +0300 (EET DST)) Subject: Re: Re... not: Another question (asm()) + the new faq Message-Id: <95May18.154713+0300_eet_dst.90129-3+16@nic.funet.fi> Date: Thu, 18 May 1995 15:47:09 +0300 Rather than writing all about asm() in the FAQ, it would be much better to improve the GCC manual to describe how to use asm() in an understandable way. A way to get this started is to identify the parts of the manual that needs clarifying. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Thu May 18 16:21:41 1995 Received: from nickel.ucs.indiana.edu ([129.79.10.5]) by nic.funet.fi with SMTP id <90665-3>; Thu, 18 May 1995 16:19:57 +0300 Received: by nickel.ucs.indiana.edu (5.65c+/10jsm) id AA00586; Thu, 18 May 1995 08:16:34 -0500 From: onnie lynn winebarger Subject: FAQ update (LONG - 72K) To: amiga-gcc-port@nic.funet.fi Date: Thu, 18 May 1995 08:16:33 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 71746 Message-Id: <95May18.161957+0300_eet_dst.90665-3+17@nic.funet.fi> Sorry this is so long, but there's a lot of FAQ's :-) Seriously, if someone has a better way of redistributing this,let me know. Anyway, it's a lot more complete now, and has some added sections. I haven't incorporated a few things, including (not limited to) Christian's last e-mail about shared libraries, and referencing Walter Harm's examples. Also, need to clean up and complete the AmiTCP section (currently there's just a post from Peter Ivimey-Cook there). Re: making the asm() documentation in GNU info files better, it sounds good. But at the moment it's still one of the more confusing things (from the number of questions, anyhow). How long will it take before the GNU folks would revise their docs? The C++ section is still empty. There have been some questions/answers in the archive about it, but I don't speak C++, so I'm not sure what to clip for it. A lot of the answers are simply cut straight from e-mails to this list, with attributions for most of them. Some of the section numberings might be wrong, as it's gotten long enough to make it a bit more difficult to keep track of. All right, I'm going to see if I can get AmiTCP to work for me. Lynn P.S. For the quote from Richard Stallman, I cut from the GNU Manifesto. Is this allowed (I didn't change anything in the stuff I cut out)? It's too long to stick the whole thing in for a newsgroup post, though putting it in the AmigaGuide/texi format is probably what I'll do. ------------------------------------------------------------------------- Amiga GNU CC FAQ Version 0.2 This FAQ is intended to answer most (all, if possible) common questions concerning the Amiga Port of GCC. It is divided into the following subsections: 0. General Introduction a. The FSF, the GNU Project, and the GPL b. What GCC has to offer c. Hardware and Software requirements 1. Obtaining and Installing the Beast a. Sources of GCC b. The breakdown of the distribution c. Installation d. Common Problems with the Installation 2. Initial problems using GCC a. Set your stack properly b. Amiga specific library options i) ixemul.library ii) libnix iii) libamiga.a and others c. The object file format of GCC i) Converting libraries to this format d. Getting the Commodore includes e. The frontend of the compiler f. Optimization may work where no optimization doesn't g. Using the OS functions (an example) 3. Amiga-specific extensions a. The CHIP keyword (not currently implemented) b. Command Line options i) -noixemul (maybe goes in 2. (b)) ii) -fbaserel iii) -resident iv) Any more? c. Startup Code options 4. Advanced Questions a. How do I build a cross-compiler? b. Working with AmiTCP c. Writing code for ixemul.library d. Writing code for libnix f. Saving some RAM g. Writing shared libraries and resident (pure) code h. I want to change over from SAS/C to GCC i. Inline Headers j. Writing Hooks 5. C++ and Objective C (don't know much about these, except that they're not as well developed yet as the C compiler) 6. Notes for Un*x Hackers a. fork() is not implemented 7. Support Utilities a. Frontends b. Debuggers c. What else? 8. Additional Support a. amiga-gcc-port mailing list b. snail mail (?) - for people getting it off of CD-ROM c. You never know, it could be a problem in base FSF code (is there a newsgroup to point to here?) 9. Known Bugs a. the C compiler i) -resident option ii) -fbaserel option b. the C++ compiler c. the Objective C compiler 10. Maintainers and Contributors 11. Future 12. History Appendix A: How does the GPL affect programs compiled by GCC? Appendix B: GNU ports and who's dealing with them Appendix C: Another free C compiler (for those with little memory) Section 0, General Introduction ------------------------------- a. The FSF, the GNU Project, and the GPL The Free Software Foundation (FSF) is an institution dedicated to the free flow of software (and information in general (?)). To this end it has start the GNU (GNU's Not Unix) project, a collection of widely portable software of all sorts (compilers and Un*x utilities for the most part, but some other stuff as well). But I'm sure Richard Stallman, director and founder of the FSF, can say it better than I: [Note that this is heavily clipped; You should get the original at prep.mit.edu] ---------------------------------------------------------------------- Copyright (C) 1985, 1993 Free Software Foundation, Inc. The GNU Manifesto ***************** Why I Must Write GNU ==================== I consider that the golden rule requires that if I like a program I must share it with other people who like it. Software sellers want to divide the users and conquer them, making each user agree not to share with others. I refuse to break solidarity with other users in this way. I cannot in good conscience sign a nondisclosure agreement or a software license agreement. For years I worked within the Artificial Intelligence Lab to resist such tendencies and other inhospitalities, but eventually they had gone too far: I could not remain in an institution where such things are done for me against my will. So that I can continue to use computers without dishonor, I have decided to put together a sufficient body of free software so that I will be able to get along without any software that is not free. I have resigned from the AI lab to deny MIT any legal excuse to prevent me from giving GNU away. Why GNU Will Be Compatible with Unix ==================================== Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt. How GNU Will Be Available ========================= GNU is not in the public domain. Everyone will be permitted to modify and redistribute GNU, but no distributor will be allowed to restrict its further redistribution. That is to say, proprietary modifications will not be allowed. I want to make sure that all versions of GNU remain free. Why Many Other Programmers Want to Help ======================================= I have found many other programmers who are excited about GNU and want to help. Many programmers are unhappy about the commercialization of system software. It may enable them to make more money, but it requires them to feel in conflict with other programmers in general rather than feel as comrades. The fundamental act of friendship among programmers is the sharing of programs; marketing arrangements now typically used essentially forbid programmers to treat others as friends. The purchaser of software must choose between friendship and obeying the law. Naturally, many decide that friendship is more important. But those who believe in law often do not feel at ease with either choice. They become cynical and think that programming is just a way of making money. By working on and using GNU rather than proprietary programs, we can be hospitable to everyone and obey the law. In addition, GNU serves as an example to inspire and a banner to rally others to join us in sharing. This can give us a feeling of harmony which is impossible if we use software that is not free. For about half the programmers I talk to, this is an important happiness that money cannot replace. How You Can Contribute ====================== I am asking computer manufacturers for donations of machines and money. I'm asking individuals for donations of programs and work. One consequence you can expect if you donate machines is that GNU will run on them at an early date. The machines should be complete, ready to use systems, approved for use in a residential area, and not in need of sophisticated cooling or power. I have found very many programmers eager to contribute part-time work for GNU. For most projects, such part-time distributed work would be very hard to coordinate; the independently-written parts would not work together. But for the particular task of replacing Unix, this problem is absent. A complete Unix system contains hundreds of utility programs, each of which is documented separately. Most interface specifications are fixed by Unix compatibility. If each contributor can write a compatible replacement for a single Unix utility, and make it work properly in place of the original on a Unix system, then these utilities will work right when put together. Even allowing for Murphy to create a few unexpected problems, assembling these components will be a feasible task. (The kernel will require closer communication and will be worked on by a small, tight group.) If I get donations of money, I may be able to hire a few people full or part time. The salary won't be high by programmers' standards, but I'm looking for people for whom building community spirit is as important as making money. I view this as a way of enabling dedicated people to devote their full energies to working on GNU by sparing them the need to make a living in another way. Why All Computer Users Will Benefit =================================== Once GNU is written, everyone will be able to obtain good system software free, just like air.(2) This means much more than just saving everyone the price of a Unix license. It means that much wasteful duplication of system programming effort will be avoided. This effort can go instead into advancing the state of the art. Complete system sources will be available to everyone. As a result, a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him. Users will no longer be at the mercy of one programmer or company which owns the sources and is in sole position to make changes. Schools will be able to provide a much more educational environment by encouraging all students to study and improve the system code. Harvard's computer lab used to have the policy that no program could be installed on the system if its sources were not on public display, and upheld it by actually refusing to install certain programs. I was very much inspired by this. Finally, the overhead of considering who owns the system software and what one is or is not entitled to do with it will be lifted. Arrangements to make people pay for using a program, including licensing of copies, always incur a tremendous cost to society through the cumbersome mechanisms necessary to figure out how much (that is, which programs) a person must pay for. And only a police state can force everyone to obey them. Consider a space station where air must be manufactured at great cost: charging each breather per liter of air may be fair, but wearing the metered gas mask all day and all night is intolerable even if everyone can afford to pay the air bill. And the TV cameras everywhere to see if you ever take the mask off are outrageous. It's better to support the air plant with a head tax and chuck the masks. Copying all or parts of a program is as natural to a programmer as breathing, and as productive. It ought to be as free. --------------------------------------------------------------------- The GNU Public License (GPL) was written in order to keep software published under it free. Here's the Preamble of the GPL: --------------------------------------------------------------------- GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 675 Mass Ave, Cambridge, MA 02139, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. ------------------------------------------------------------------------ More information regarding the FSF, GNU, and the GPL can be obtained at gnu.prep.mit.edu. Note that the source code of any GPLed software must be made available by the distributor (is this wording accurate?). The GPL may also affect how you distribute your programs, or maybe not. For more information, check out Appendix A of this FAQ. (Do this before believing all the bad hype about it. Then decide for yourself). b. What GCC has to offer. A FREE C compiler, for starters. I'm sure there's some other stuff. It's available for a wide range of machines (and thus it can't be beat for cross-compiling, at least on the Amiga). For the interested, a chance to change it as you like, make your own bug fixes, be an active part in the development process. c. Hardware and Software Requirements This depends upon what you're doing. Here's an excerpt from Phillipe Brand's readme for his distribution on the net: - Systems: Any Amiga (ranging from A1000 up to A4000/40, including CD-32 & SX-1) will run amigados-gnu utilities. - Memory: A minimum of 4MB free memory is needed in order to compile small/medium projects. More memory will be needed for large projects, such as recompiling gcc itself. Gigamem is known to work with GCC so *maybe* less memory will work. But in this case, you'll need an MMU equiped amiga (A3000,A4000/40, etc...). VMM40 (Public Domain Virtual memory manager) is also known to work with GCC. [Editor's note: using the g++ compiler can require even more, like at least 6 MB of free RAM] - OS: Starting from this release [2.6.3], 1.3 systems are not longer supported. Gcc runs fine on all other systems, starting from 2.04 up to 3.1 (40.68). - Disk Space; An installation of gcc requires the use of a hard disk. Approximately 10MB is required at present to install the compiler and utilities required to use it. In addition 3MB is required for the Commodore Developer Kit, which is required to be able to compile AmigaDOS specific programs. This kit is available direct from Commodore-Amiga. [Note, this is not true for the FreshFish distribution, which can be run straight off the CD-ROM if desired.] ----------------------------end quote--------------------------------- Yes, it can take a lot of resources, but that's a function of its portability. Be glad you can count on having the same compiler on your Amiga at home or the Unix system at work (or vice versa :-)). 1. Obtaining and Installing the Beast a. Sources of the Amiga port of GCC There are a couple of options for getting GCC. If you have access to the Internet, and ftp service, you can obtain the current version of GCC from Aminet, in dev/gcc. The main site of Aminet is ftp.wustl.edu in /pub/aminet, and has mirrors world-wide: USA (MO) ftp.wustl.edu USA (WI) ftp.netnet.net USA (TX) ftp.etsu.edu Scandinavia ftp.luth.se Switzerland ftp.eunet.ch Switzerland ftp.math.ethz.ch Germany kelly.uni-paderborn.de Germany ftp.uni-paderborn.de Germany ftp.uni-stuttgart.de Germany ftp.uni-erlangen.de Germany ftp.cs.tu-berlin.de Germany ftp.tu-chemnitz.de Germany ftp.fh-augsburg.de Germany ftp.uni-bremen.de Germany ftp.uni-kl.de Germany ftp.uni-trier.de Germany ftp.informatik.rwth-aach France ftp.cnam.fr Portugal ftp.ci.ua.pt UK ftp.doc.ic.ac.uk UK micros.hensa.ac.uk ftp.funet.fi also serves to act as a hub for porting GNU software to the Amiga, and serves to mirror Phillipe Brand's Amiga GCC tree directly, so that you may always find GCC there (particularly to guarantee the availability of source code). The distribution is broken up into several parts, both to make it easier to download and to respect the GPL. Thus each archive is broken into two parts, one for binaries and one for sources. Gcc-2.6.3 is split up into 15 archives: gcc263-readme.lha holds readmes files (include installation notes). gcc263-base.lha basic gcc distribution, hold necessary files. gcc263-inclib.lha headers and libraries. gcc263-c.lha C compiler. gcc263-c-020.lha 68020+68881 version of C compiler. gcc263-c++.lha C++ compiler, headers and libraries. gcc263-c++-020.lha 68020+68881 versions of C++ compiler. gcc263-objc.lha Objective-C compiler, header and libraries. gcc263-objc-020.lha 68020+68881 versions of Objective-C compiler. gcc263-doc.lha Gcc AmigaGuide(tm) documents & manpages. gcc263-utils.lha Useful utilities needed for development. gcc263-utilsdoc.lha Utilities documentation (guide & manpages). gcc263-texi.lha All Texinfo documents. gcc263-diffs.lha Diff files for all binaries. gcc263-src.lha Source for gcc-2.6.3 plus diff file. The second way is to utilize your CD-ROM drive and get one of Fred Fish's great CD-ROM collections. Any of the FreshFish or GoldFish Vol. 2 will have it, though the later the CD-ROM the later the version. He also includes as many ports of GNU utilities as he can. His restriction is simply that the binaries he includes must be compilable from the sources he includes (this has been a problem in the past, and Fred is a stringent observer of the GPL). So, yes, you also get all the sources with the binaries. (If you've got a CD-ROM drive, you should get one of these anyway; it's a great deal). These CD-ROMs may be purchased from Amiga Library Services by: Snail Mail: Amiga Library Services 610 N. Alma School Road, Suite 18 Chandler, AZ 85224-3687 USA FAX or Voice: (602) 491-0048 Phone: (800) 804-0833 or Email: orders@amigalib.com (but sending credit card information over e-mail is not secure, so one of the other methods would be preferable. Fred is working on using some kind of encryption though. More details when they're available.) There may be other CD-ROMs containing GCC, I just know of Fred's since he is directly involved in the porting of it. The breakdown of this distribution is different. Check the specific CD-ROM for details. They also include the Commodore Native Developer Updates (no Autodocs) for 2.04, 3.0, and 3.1, which is a big bonus. c. Installation Installation procedures may vary depending on your source, but the final directory structure should be the same. Check the README files included in your distribution package for more details. The ftp distribution (Phillipe Brand's) contains an Installer program. It utilizes the following layout: Name What Where ---- ---- ----- COPYING GNU LICENSE, read!! All archives COPYING.LIB GNU LIBRARY LICENSE, read!! All archives README-2.6.3 this file All archives NEWS-2.6.3 What's new in gcc-2.6.3 gcc263-base Installer Commodore installer utility gcc263-base GCC-Install Installer script to configure gcc All archives envarc/ global environment variables you should have set when using this programming gcc263-base environment include/ non-amiga specific C/C++ headers gcc263-inclib os-include/proto amiga specific protos headers. gcc263-inclib os-include/inline amiga specific inline C headers. Add gcc263-inclib Commodore headers!! os-lib/ amiga specific libraries gcc263-base guide/ Docs in AmigaGuide(tm) format gcc263-doc man/ this is the root for tons of man pages gcc263-doc bin/ this is /bin, and contains all gcc263-c binaries of this distribution that gcc263-c++ are meant to be directly invoked by gcc263-utils the user (contrary to the executables in lib/gcc-lib/, that are meant to be invoked by a driver program like gcc) lib/ normal (not base relatives) libraries gcc263-inclib lib/libm020/ normal 68020 libraries gcc263-inclib lib/libb/ base relatives libraries gcc263-inclib lib/libb/libm020/ base relatives using 68020 libraries gcc263-inclib lib/libnix/ Non-ixemul libraries gcc263-inclib lib/libm020/libnix/ Non-ixemul 68020 libraries gcc263-inclib lib/libb/libnix/ Non-ixemul base relatives libraries gcc263-inclib lib/libb/libm020/libnix Non-ixemul base relatives 68020 libs gcc263-inclib lib/gcc-lib/ home of compilers called by gcc gcc263-c gcc263-c++ gcc263-objc ixpipe/ a pipe handler needed by the library gcc263-base libs/ ixemul.library gcc263-base rexx/ ARexx wrappers for gcc and g++ gcc263-base src-patches/ source patches gcc263-diffs geninline/ Perl scripts to generate inline headers gcc263-inclib and -lamy glue A standard GNU directory tree structure has been adopted by the porting team to make life easier for everyone. Starting with the assign of GNU: to somewhere, we then have: GNU:amigados GNU:man GNU:Info GNU:etc GNU:bin GNU:include GNU:lib GNU:os-include GNU:os-lib Since one of the aims of porting GNU software is to be able to provide a Un*x like environment under AmigaOS, the porters decided to make a GNU "root directory" (GNU:) in which a standard Un*x directory tree can live, like /etc, /bin, and so on. This decision makes for good Un*x compatibility. Also, in the past, you would have to add many assigns (>=10) to have your GNU utilities working, and now it's just 5 (GNU:, MAN:, INFO:, ETC:, and BIN: ). We no longer have a conflicting assign LIB: (which most other compilers use). d. Common Installation Problems Using the Installer program for the ftp distribution should get rid of these problems. Check out the section on the specs file if you are having problems customizing your installation (say you have another compiler, and don't want to have 2 separate copies of os-include). Also, for those of you who refuse to read the README, you need the Commodore includes. Section 2 (d) tells you where to get them. See 2 (c) about the GCC object format. You may need to convert some standard libraries. Also check 2(a) on setting your stack properly. 2. Initial Problems with GCC a. Set your stack properly. GCC needs a lot of stack to run. For a nice, small (<1000 lines) source, a stack of 50,000 should do just fine. For more complicated code, you may need more, but 250,000 should do in any case, for gcc alone. Note that using make may increase the demands on the stack size, so the above suggestions may not hold. A word from Phillipe Brand's README: You need to have a 50.000 stack size in order to compile with GCC. This should be enough for most projects. Note than while recompiling gcc with itself it has taken more than 300KB stack. Stack can grow due to source complexity. Don't be afraid of it. To set the stack size, see the AmigaDOS Command 'stack'. To use ar and/or ranlib, 50KB is the minimum acceptable. You should have a much larger stack, if you use larger libraries. Starting with 2.6.3 a new environnement variable, GCCSTACK, enables gcc to read this variable and set stack upon startup. Thus now no need to set stack to huge values, only gcc/ld/cpp/cc1#? will automatically set new stack, according to GCCSTACK variable. Simply commit a: setenv GCCSTACK value to set gcc stack to value. Benefits: huge memory savings. ----------------end quote Note that GCC 2.7.0 will include automatic stack growth code, so you won't need to worry about this anymore. b. Amiga specific Library options i) Ixemul.Library This library was developed by Markus Wild when originally started porting GCC (up to version 2.3.3). It is a shared library that emulates a lot of Un*x functions, making life a lot easier for folks porting GNU utilities and such. Unfortunately, it is fairly resource hungry by Amiga standards, and has caused not a little irritation among Amiga users. GCC opens ixemul.library by default, so if you want to avoid it, you'll have to use -noixemul on the command line (see below in Amiga specific extensions and/or coding with x.lib) and link to one of the libraries below. The general rule of thumb should be to use ixemul.library if you're writing something non-Amiga specific (e.g. porting something) or one of the below link libraries when writing something specifically for the Amiga. Using ixconfig to work: ---------------------------------- [Joerg-Cyril Hoehle] > Which ixconfig should we use for ixemul v40.4? If you're using R.Luebbert ixem404lib.lha, use ixconfig from there. It's actually called bin in that archive :-( [generic] 2925 5396 54.2% -lh5- b464 Sep 3 1994 ixem/bin The ixemul.library from the gcc263 archive is R.Luebbert's 40.4. If you're using another one: Fred Fish's: I don't know whether he removed the ArpBase field in the include/library/ixemul.h file. R.Luebbert removed it between his 40.2 and 40.4, which was a big mistake IMHO (as this mail and others show). So I don't know which ixconfig is good for him. Leonard's: He told me that he had never removed this field, so get any old ixconfig you'll find. The one from the gcc263 archive will do. ii) libnix This is a standard link library to replace the functionality of ixemul.library. Make sure you link to it if you use the -noixemul command line option for gcc. Here's the readme file from the distribution: Short: A library for amiga specific development on gcc Type: dev/gcc Uploader: fleischr@izfm.uni-stuttgart.de Author: fleischr@izfm.uni-stuttgart.de, gnikl@informatik.uni-rostock.de This is libnix, a static (i.e. link) library for gcc 2.3.3 or above. It's not a replacement for ixemul.library (though it's possible to recompile most of the gcc environment with libnix) but a good thing for amiga specific development on gcc: * It's mostly compatible to SAS's way of handling things, i.e. you get even an automatic shared library opening feature and some other things you may miss in ixemul.library. This also means it's ANSI compliant. * It doesn't need any shared libraries than normal Amiga OS ones. * It is not copyrighted by the FSF. Therefore you neither need to include sources nor objects together with your executable. (read the GLGPL _before_ flaming on this statement) * And it's short! I was able to compile a 492 byte 'hello, world' using normal main. * It uses OS20 features whenever necessary. To cut it short: Use ixemul.library for porting Un*x programs, libnix for compiling amiga-only programs and gcc becomes one of the best Amiga compilers. There is no need to download this archive if you use gcc2.6.0 or above since the libraries itself are included with the normal gcc distribution. But if you use an older gcc version or if you want to get the sources you can take this package. But be warned: The ld that comes with earlier versions of gcc has some serious trouble with set elements. You cannot use libnix without the fixed linker that comes with gcc2.6.0. iii) Gerlib Obsolete iv) the PDC library Obsolete c. The object file format of GCC Yes, GCC uses its own object file format. This means you aren't currently able to link to AmigaDOS hunk format object files (standard). But hunk2gcc (by Markus Wild) will do the conversion for you as described below. Why does GCC use its own object file format? It's really just a design decision that allows other gnu utilities to deal with these objects (for example, gdb) without having to convert them to deal with AmigaDOS hunks. >From Brand's README-2.6.3 Starting from this release an AmigaDOS compliant library is provided, thanks to libnix authors (Matthias Fleischer and Gunther Nikl). Anyway if you want to rebuild one, there are two methods: 1) Using hunk2gcc; the AmigaDOS object converter made by Markus Wild. To achieve this, simply grab a copy of latest amiga.lib (from Commodore Development Kit) and make a new directory where you want your converted object files to go, cd into it, and enter hunk2gcc amiga.lib [..further libs if you like..] This generates an a.out object file for every program unit present in the hunk file (in this case, from amiga.lib). As the final step convert all those files into an a.out style library by issuing: ar qc libamiga.a obj.* ranlib libamiga.a The ranlib run builds a symbol table in the archive, and makes accesses to the library much faster. 2) Creating a libamiga.a library with libnix is fairly easy, but takes some time. Just uncompress sources.lha from libnix distribution and run a 'make libamiga.a'. NOTE: As long as you make no AmigaDOs specific calls, you can create a dummy library using: cat "int dummy;" >dummy.c gcc -c dummy.c ar crv libamiga.a dummy.o mv libamiga.a gcc:lib A small libamiga.a (dummy) is also provided with libnix. d. Getting the Commodore includes [Jochen Wiedmann] You can obtain the includes and some developer tools from any Fish CD and some other CD's as well. However, you will be missing the autodocs, which are definitely the best information source for the OS functions. You can get them either by buying the The Amiga ROM Kernel Manual: Includes and Autodocs, ISBN 0-201-56773-3 (about 50-60$, as far as I know), or by buying the so-called NDU (Native developers update kit, 5 disks, about 40$) from Fa. Hirsch & Wolf Mittelstr. 33 56564 Neuwied Germany Phone: (0049) +2631 83990 Email: hhhirsch@carla.adsp.sub.org Sorry, but this is still the *only* source for the NDU, at least as long as CATS (Commodore Amiga Technical Support) isn't alive. I'd prefer buying the NDU, because it contains the newer information than the book and I prefer it online. e. The frontend of the compiler amigados-gcc and gcc are the same thing. AREXX scripts: The provided ARexx scripts have been contributed by Loren J. Rittle. If you like ARexx, they're an alternate way of calling gcc. They automatically make sure you're using a large enough stack setting, and enable you to compile C++ programs with less obscure options. This approach is furthermore useful if you're not able to use the g++ /bin/sh script. f. Optimization may work where no optimization doesn't The folks who write GCC almost always use -O when compiling GCC and other stuff. Hence, the -O routines are better tested than those without optimization. So you may want to try it. g.) Using the OS functions with gcc. [Jochen Wiedmann, with a small suggestion by Christian Stieber] Let's write a simple "HelloWorld.c": /* Compile me with gcc -noixemul -o HelloWorld HelloWorld.c -lauto */ #include #include #include int main(int argc, char *argv[]) { struct EasyRequest er; er.es_StructSize = sizeof(er); er.es_Flags = 0; er.es_Title = "Message"; er.es_TextFormat = "Hello, world!\nintuition.library is at 0x8l."; er.es_GadgetFormat = "Ok"; EasyRequest(NULL, &er, NULL, IntuitionBase); exit(0); } Some notes: - We are using the function EasyRequestArgs() from intuition.library. Thus we have to include the appropriate headers: intuition/intuition.h for the structures and constants, proto/intuition.h for the function prototypes. Do not use headers from other compilers (for example pragmas/intuition.h), gcc headers (inline/intuition.h, included by proto/intuition.h) or even OS headers (clib/intuition_protos.h). The only exception are clib/alib_protos.h and clib/alib_stdio_protos.h: These represent link libraries and not shared libraries. - We did *not* open intuition.library. gcc does this for you by including proto/intuition.h and linking against libauto.a. However, this works only for OS libraries. Consult the GNU:libauto directory, if you want to know how to get the same possibilities for other shared libraries. Using proto/intuition.h you are safe and even source compatible to SAS/C and Dice. - If you *need* to open a library manually, do it as follows: #include #include #include #include struct IntuitionBase *IntuitionBase = NULL; /* Explicit initialization with NULL is a *must*! */ void Cleanup(void) { if (IntuitionBase) CloseLibrary(IntuitionBase); } int main(int argc, char *argv[]) { if (atexit(Cleanup)) { perror("atexit"); exit(20); } if (!(IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library", 37))) { fprintf(stderr, "Cannot open intuition.library, V37"); exit(20); } /* Same program as above */ } Note the use of atexit(), which makes exit() calling Cleanup(). Note this possible alteration: > struct EasyRequest er; > > er.es_StructSize = sizeof(er); This seems to be correct, but I suggest hardcoding 5*sizeof(ULONG) here. That field serves as version information; using sizeof() and compiling with newer headers would tell the OS that you're using the new structure. But the additional fields will contain garbage... 3. Amiga-specific extensions a. The CHIP keyword Most C compilers for the Amiga have a CHIP keyword or equivalent to signify that an object should stored CHIP memory when declared. I.e., CHIP struct Image *my_graphics = { ... } will cause the memory for the data to which my_graphics points to be allocated in CHIP memory (pretty handy, huh?) This is obviously Amiga-specific, so of course it's not implemented in the FSF code. BUT, the linker (ld) currently recognizes -chip and -fast options. However, these haven't been put in gcc itself quite yet, though I have been assured they will be here soon (there have been more important things to work on, like getting -resident to work again, see below). So if you're using 2.6.3 or below, here are some basic work-arounds: (I gotta find these) b. Command Line options i) -noixemul (maybe just reference 2. (b)) This option prevents gcc from making your executable open ixemul.library (of course, your program can still do so). Make sure you link to libnix or something similar to access those functions. See also 2. (b) (ii) ii) -fbaserel (currently broken until 2.7.0) [from Christian Stieber] -fbaserel turns on base relative adressing; which means that global/static variables are referenced with a 16 bit offset relative to an address register (a4 is generally used for that). The startup-code loads a4 with a pointer into the data segment. Result: every access to a global/shared variable is only 16 bit instead of the usual 32 bit address -> shorter & faster. It also means that you're limited to at most 64K of global/static variables. iii) -resident [from Christian Stieber] A "resident" program (the correct term is "pure") is a program that can be loaded into memory just once, but executed by serveral processes at the same time. Therefore, "resident" is actually "code sharing". -resident turns on -fbaserel and links with a special startup code. That first thing that special startup code is to allocate some memory, copy the global/static variables into it and load a4 with a pointer to that memory. Then, a normal startup-code and your normal program is run. When the program exists, the memory block is freed. Result: Every process has its very own, private data segment for global/static variables. Since there all global/static variables are accessed via a4+16-bit-offset (because of -fbaserel), the original data segment is untouched. Result: the program can be executed independently by several processes, with every process getting its own data segment. c. Startup Code options (may be redundant) 4. Advanced Questions a. How do I build a cross-compiler? [from Phillipe Brand] How to generate a cross-compiler, AmigaDOS side: ------------------------------------------------ - Get gcc-2.6.3.tar.gz from ftp.gnu.ai.mit.edu or mirror site - Get ftp.telesys-innov.fr:/pub/amigados-gnu/gcc-2.6.3-amiga.diffs file >From CLI: CLI> sh # zcat gcc-2.6.3.tar.gz | tar xvf - # cd gcc-2.6.3 # zcat ../gcc-2.6.3-amiga.diffs | patch -p1 # ./configure --host=amigados --target=CPU-COMPANY-SYSTEM # make When compilers are built, all you have to do is installing it using make install, and to grab other architecture's libraries (libc.a, etc...), and headers. More infos: See GCC AmigaGuide documentation, look for "Cross-Compiling". How to generate a cross-compiler, Other architecture side: ---------------------------------------------------------- - Get gcc-2.6.3.tar.gz from ftp.gnu.ai.mit.edu or mirror site - Get ftp.telesys-innov.fr:/pub/amigados-gnu/gcc-2.6.3-amiga.diffs file >From CLI: CLI> sh # zcat gcc-2.6.3.tar.gz | tar xvf - # cd gcc-2.6.3 # zcat ../gcc-2.6.3-amiga.diffs | patch -p1 # ./configure --target=amigados (host should be determined by configure itself) # make When compilers are built, all you have to do is installing it using make install, and to grab AmigaDOS GCC libraries (libc.a, etc...), and headers. More infos: See GCC AmigaGuide documentation, look for "Cross-Compiling". A working example of a cross-compiler running on sunos4.1.3 can be found in ftp.telesys-innov.fr:/pub/amigados-gnu/gcc-cross/.... b. Working with AmiTCP > Could somebody please explain where exactly gcc and the libraries > that come with it fall down when it comes to using AmiTCP? > > What's missing etc. > > Then, Why can't (I assume you can't since veryone says you can't) > use the C= Developers kit with gcc without fiddling. The problems are: a) gcc uses it's own object module and library format, so lots of the GNU tools don't have to change too. b) gcc uses ixemul by default, which is not compatible directly with the SAS libraries supplied with AmiTCP. a) is just a design decision, and indeed there are tools to convert. (b) is harder to see; basically the SAS AmiTCP libraries assume the environment of SAS/C, complete with references to the SAS FILE structure internals and the functions which aren't in SAS or which need to be patched to work with AmiTCP. In addition, the netincludes supplied with the AmiTCP port include many items and structure definitions which are also defined in gcc, albeit differently, resulting in a very confised compiler if you mix them. Unfortunately, a simplistic port (recompile with the right -I directives) fails for two reasons; the includes are wrong, and even if they were matched, the SAS-directed library patches the wrong things. Resulting in an executable which will fail to operate as expected (it might work OK, or it might not - depends what you call & when). What is needed is a new library - take out the duplicate definitions, patch the right functions and remake the library for gcc. Does this help? Peter Ivimey-Cook. c. Writing code for ixemul.library After looking at Markus Wild's README, I couldn't see anything to include in particular, and the thing is way too long to put here. Any specific suggestions of stuff to clip out? Actually, considering the update activity, the current maintainers/ developers should be providing a new README. Particularly the functions available in the different versions (regular fxns, the ones in the network version, and the conflicts. Somebody recently answered a question about this last part, saying he was trying to integrate the 2). i) Finding bugs with trace() [Joerg-Cyril Hoehle] more than one year ago, I corrected a huge bug in the program trace (a buffer overflow). Together with ixemul.trace, this program allows you to see every ixemul call (aka SnoopDOS for ixemul.library programs) and may be useful for debugging. Before, because of that overflow, trace hung the whole system very often (and very soon) when tracing every ixemul call. Now, I've been able to trace long sessions of gcc compilation to a (K)CON: window without trouble. d. Writing code for libnix Maybe a referral to the libnix docs in the source file, or should I stick them in here (I believe they're only in the source archive, so people may tend not to grab it)? e. Problems with asm() [Insert your answer here,please] f. How do I save RAM? [Jochen Wiedmann] A simple try is to do a setenv TMP MyHardDrive:t before compiling. This will create temporary files on the harddisk and not in RAM. Depending on what you compile this can save some 100K of RAM while compiling and it doesn't slow down the compiler very much. Another try is to turn off optimization. This prevents the "inline" headers from being included, which need *very* much RAM. If you like optimization (for example because of the additional checks!) you can use the options -O -D__NOINLINES__ which turn on optimization, but prevent the inline headers from being included. (The negative effect is, that you need an additional function call any time, you use an OS function, but one can live with it.) g. Writing shared libraries and resident (pure) code Here is some discussion from the amiga-gcc-port mailing list [not cooked up yet] [Peter Ivimey-Cook] > Obviously there must be other solutions. Being able to build a library > is not far away from being able to build a pure (=residentable) > program, and gcc-2.3.3 was both largely above 64KB in size and > residentable. So what's the trick? > Don't use global data referenced absolutely! residentable implies reentrant, which means that global data is read-only apart from the first instance (i.e. it's OK to initialise it, once, but once initialised it can't be modified or reinitialised). This effectively means the only data used in the must be on the stack or referenced from it by pointers, as the stack is separate for different invocations of a resident program. Of course this does pose a major headache for programs which use lots of global data. And watch out for library use too! Failing this, one must use a global data access mechanism which allows: (a) the base address to be set up - e.g. by calling AllocMem() and storing the result in a register (NOT a global!) (b) *all* accesses to "global" data are relative to this register. [Peter Ivimey-Cook] > > BUT: If we build a shared lib from the static link lib, code exists only once > and is SHARED between callers of the lib (callers means different executables, using the lib) > Here the problem comes up that the DATA MUST not be shared between different callers. > This is because it is PRIVATE to the individual caller. > IMHO the only way to realize multiple callers is the use of -fbaserel, since now access > is relative to the A4 register and thus, every program can have IT'S OWN data, without > interferring with each other. It depends on the way the library is constructed. Most Amiga libraries are written to be re-entrant - i.e. they don't use global data items which would require loading - they use the stack. For items which can't be done this way, there are two solutions - 1. Use the library data space. It's global, unless you make provision for it to be otherwise - and availabl easily off a6. 2. Manage your own data space, using tags or whatever to allocate space for callers. Note that the only indication you have as to who is the current caller is the result of FindTask(). So, in general libraries try to make required data passed through parameters, or available on the stack, or shareably global. In which case no baserel or anything else is required. [Jochen Wiedmann] - Of course it is possible to write shared libraries (ixemul.library, for example) with gcc, but *only* if the source is written with a shared library in mind. - It is possible (Matthias told how) to develop a solution that would allow to use existing source of link libraries for shared libraries (libbfd sources, for example) with at most very minor modifications - -fbaserel would be a must for the above solution. On the other hand it is not possible yet, at least not without going to the assembler level. (Really deep, not just using some headers with asm keywords.) [Christian Stieber] > Jochen Wiedmann writes: > > - Of course it is possible to write shared libraries (ixemul.library, > > for example) with gcc, but *only* if the source is written with a > > shared library in mind. > > Could you elaborate on that so that we know a little more about it, > please? - keep in mind that all callers use the same global and static variables; that means: either protect them with semaphores (e.g. if your library is using a memory pool), or allocate a block of memory inside your library and pass pointers around. - the "startup" code will contain the ROMTag structure and related data, as well as stubs to push parameters on the stack, calling the C function, cleaning up the stack. - I generally write the libOpen(), libClose(), libInit() etc. functions as normal C functions, but some people might prefer to put them into the "startup code". That's about all. It also means that many link-lib functions (e.g. from libnix) can't be used; this has to be decided on a per-function basis. It's pretty safe to say that you can't use stdio and malloc(). strcpy(), isdigit() are safe, etc. Just be careful. Think about what the function does; that should give you an idea whether you can use it or not. [Jochen Wiedmann] > Jochen Wiedmann writes: > > - Of course it is possible to write shared libraries (ixemul.library, > > for example) with gcc, but *only* if the source is written with a > > shared library in mind. > > Could you elaborate on that so that we know a little more about it, > please? > > Does it mean that you can't use any global variable? Or only one but > declare it with something like__asm__("a4") and use it as a base > pointer? Does it imply that you must use the inline/*.h? Does it imply > that you must use a special startup code (of course :-), what must it > do? In short: You may well use something like struct ExecBase *SysBase; and read this variable from anywhere within your program, because you can a) initialize it from the library startup code and b) be sure that it never changes but you must not use global or static data otherwise. h. I want to change from SAS/C to GCC Great! [Kriton Kyrimis] > I am also wondering if it is possible to link object files that were > created by different conpilers, specifically GCC and SAS. I need to do Try compiling SAS programs using DATA=FAR CODE=FAR, then use the hunk2gcc program to convert the object files from amiga format to sun format. One problem with this approach would be with floating point code and with integer multiplication/division. If you can compile with CPU=68020 (or higher) and MATH=68881, then SAS/C will produce inline code, and you will have no problem. Otherwise, you'll have to grab the necessary modules from the SAS libraries and convert them to sun format as well. (Compiling with the option that produces code that uses utility.library, and linking with -lauto might alleviate the problem.) ---------------------------------- And here's a little AREXX program to automagically convert sas libs to gcc libs: This arexx program is based on help from Philippe BRAND. /********************************HISTORY********************************** * 18-DEC-94 : DJR : Created * ************************************************************************** * * * Name : saslib2libgcc * * Author : David J. Ruscak ruscakd@polaroid.com * * Created : 18-DEC-94 * * Purpose : to convert SAS libraries to GCC libraries * * * *************************************************************************/ /* To convert a SAS library to a GCC format library several steps are involved. 1) cd to RAM: Either copy the library to RAM: or give the full path name. EX: gnu:saslib2libgcc X11:lib/Xtnb.lib 2) You need the SAS Librarian 'oml' with a version => Library otherwise you'll get an error such as 'unknown hunk'. 3) You need hunk2gcc, mv, ar and ranlib. If your using gcc you have the fastram, VMM2.1 swap works fine too. */ /* TRACE R */ SIGNAL ON ERROR OPTIONS RESULTS IF ~SHOW('l','rexxsupport.library') THEN IF (~ADDLIB("rexxsupport.library",0,-30,0)) THEN DO ECHO "Can't load rexxsupport.library" EXIT 10 END fullname = "" PARSE ARG fullname IF fullname == "" THEN DO ECHO " No Library to convert" ECHO "" ECHO " EX: gnu:saslib2libgcc X11:lib/Xtnb.lib" EXIT 10 END IF (~EXISTS(fullname)) THEN DO ECHO "Can't find" fullname EXIT 10 END ADDRESS COMMAND /* make 2 directories for object files */ IF EXISTS('object') THEN DO ECHO "Directory object exists Please delete or rename it." EXIT END 'makedir object' IF EXISTS('object2') THEN DO ECHO "Directory object2 exists Please delete or rename it. " EXIT END 'makedir object2' 'oml -oobject 'fullname 'X *' /* SAS Object Librarian */ IF EXISTS('object') THEN DO objfiles = SHOWDIR('object','F') /* list of all object files */ nfiles = WORDS(SHOWDIR('object','F')) /* count of object files */ DO UNTIL nfiles == 0 /* must be a more efficient way... */ 'hunk2gcc >NIL: object/'WORD(objfiles,nfiles) /* convert to GCC object */ 'mv >NIL: obj.#? object2/'WORD(objfiles,nfiles) /* restore original names*/ nfiles = nfiles - 1 END END 'cd object2' /* directory of converted objects */ path = PRAGMA('D','object2') IF (INDEX(fullname,':') > 0) THEN /* strip out assign */ fullname = SUBSTR(fullname,LASTPOS(':',fullname) + 1) IF (INDEX(fullname,'/') > 0) THEN /* strip off directories */ libname = SUBSTR(fullname,LASTPOS('/',fullname) + 1) ELSE libname = fullname dot = POS('.',libname) gcclibname = 'lib'SUBSTR(libname,1,dot)'a' 'ar qc 'gcclibname' #?.o' /* archive new library */ 'ranlib 'gcclibname IF EXISTS(gcclibname) THEN DO needslash = LASTPOS(':',path) IF ~(needslash == LENGTH(path)) THEN path = path'/' ECHO " The following indicate a hunk2gcc error:" ECHO " Short reloc into N_DATA, what should I do? ECHO " Short reloc into N_BSS, what should I do? ECHO "" ECHO "" ECHO " Remember to move/rename "path"object2/"gcclibname" appropriately ." END ELSE ECHO "No library created, what could have gone wrong ????" EXIT ERROR: ECHO " error = "RC ECHO " Hope its not the dreaded *Invalid Hunk type*" EXIT h. Inline Headers [Christian Stieber] (maybe should clear out the specific bgui reference) > compiling bgui:demos/font.c: > gcc -O3 -noixemul bgui:demos/font.c > > got errors: > font.c:100: unterminated macro call This is because the inlined varargs aren't useful at all. Do #define NO_INLINE_STDARG (or whatever it is called), and create varargs stubs like this: Prototype: BOOL SomeFunction(int, char *, ...); and BOOL SomeFunctionA(int, char *, APTR); Stub function: #define NO_INLINE_STDARG #include BOOL SomeFunction(int A, char *B, ...) { return SomeFunctionA(A,B,(&B)+1); } That isn't really ANSI-C, but it works on all Amiga compilers I know of. Create a .c file for every function, compile, ar and link it to the program. Make sure the optimizer is on, else SomeFunctionA won't be inlined. How to create stubs for non-varargs functions: In order to be able to compiler without -O, you want to create stubs for the inline functions as well: #define NO_INLINE_STDARG #define SomeFunctionA InlinedSomeFunctionA #include #undef SomeFunctionA BOOL SomeFunctionA(int A, char *B, APTR C) { return InlinedSomeFunctionA(A,B,C); } Again, create such a file for every function and put the *.o files into the archive mentioned above. j. Writing Hooks [Tomi Ollila] > 1) How to I write a hook function - I.E. Specify which registers parameters > should be received in and that the result should be returned in register D0. One way to do this is to write the function entry the following way: ULONG hook(void) { register char * a0 __asm("a0"); char * buffer = a0; register ULONG d0 __asm("d0"); ULONG size = d0; ... return length; } We wrote some macros for AmiTCP/IP project to make it easier to write this kind of function entries... #define RAF2(funname, type1, arg1, reg1, type2, arg2, reg2) \ funname(VOID) \ { \ register type1 reg1 __asm(#reg1); \ type1 arg1 = reg1; \ register type2 reg2 __asm(#reg2); \ type2 arg2 = reg2; would make the above function look like: ULONG RAF2(hook, char *, buffer, a0, ULONG, size, d0) #if 0 { #endif The whole macro file `amiga_raf.h' is available at kampi.hut.fi, directory /AmiTCP. It defines RAF1 - RAF7 for both GNU C and SAS C compilers (someone could write these to DICE as well). > 2) Is there anyway to specify that a function should NOT be made inline (As > I wouldn't want the hook function inlined. Compile it in a separate module. This way gcc doesn't see the function code when compiling. If you give a pointer to the function, then it must also exist as a callable function. 5. C++ and Objective C a. C++ i) Use _complex.h instead of complex.h Because Amiga Dos is not case-sensitive, and there are both complex.h and Complex.h on the Unix distribution, one had to be changed. This choice was recommended by the libg++ maintainer. (don't know much about these, except that they're not as well developed yet as the C compiler) 6. Notes For Un*x Hackers [additions to this section are welcome] a. fork() is not implemented Here's a clip from Markus Wild's README in the ixemul source distribution: Some notes to vfork() and friends ================================= **IX/BSD process management is one of the most nasty design differences between AmigaDOS ans **IX/BSD. `fork()' for example is hardly possible to implement on AmigaDOS, as it requires to create an identical copy of the parent process. This is only feasible with virtual memory, where processes can be mapped at equal places in memory. Under AmigaDOS this would have to be simulated by copying of stack and malloc'd data whenever a process is activated, and copying them to a safe place before it is disactivated. This problem can be avoided, if the program to be run under AmigaDOS is only fork()ing, because it just wants to start another process. In that case, no such copying as described before is necessary, and BSD therefore invented the `vfork()' function, which works like `fork', but runs the child on the parents memory segments (stack and malloc'd data). While the child is using the parents resources, the parent is sleeping in a not interruptible state. That much for theory;-) I tried to implement an as compatible as possible vfork() function, that behaves like the BSD one. This should work under any OS version, for Kickstart 1.3 the arp.library is used, starting with OS 2.0 dos.library is powerful enough to do it itself. Since I won't try to implement `fork', I provided a possible alternative (you tell me;-)). As an extension, you get the `vfork_resume()' function, which causes the parent to resume, just like it would if you called `_exit()' or one of the `exec*()' functions. Since this function is quite dangerous (and an even bigger hack than vfork() itself..), here's what's happening in `vfork_resume()': o the child switches to its own stack. After vfork(), the child is using the stack of the parent process. Since no two processes can share the same stack in parallel, vfork_resume() causes a switch to the `real' stack of the child. o the parent is sent a wakeup message. o both processes run concurrently The first point is the most important one: Since vfork_resume() changes the stack pointer of the running process, you can't refer to any variables or parameters anymore after calling vfork_resume()! Only register variables survive such a call, and you have to explicitly store values in register variables that are subject to survive! There's another potential problem with vfork_resume(): ************************************************************************** Don't exit() from the parent before all vfork()'d children have died!! ************************************************************************** Since exiting from the parent causes the parents code and data segments to be deallocated, the child would find itself without code space to run on, and would probably cause a severe machine crash! So always call at least `wait (0)' before returning from the parent. exec*() ======= In most cases, you just use `vfork()' to later overlay the process with a new image, that is you want to start another program. The way AmigaDOS loads processes is not too well suited to do `exec' style program starting, yet it is possible, although with slight resource wasting.. First problem is, that all exec* functions pass an argument vector to the new program, whereas AmigaDOS programs expect to be passed an argument line (instead of the vector of arguments). Since in my opinion it would be a good thing if a program could get an argument vector directly (in that case the inherent problem of passing multi word arguments to a program would be finally solved, no more weird quoting needed!). That's why I provided a mechanism that allows this vector passing, and it works like this (look at crt0.c for a concrete implementation of this concept!): The program has to provide a magic header at the first executable location in its code. This magic header looks like this: o JMP instruction to common AmigaDOS startup o struct exec area. Use the OMAGIC a_magic code. o provide an alternate entry vector in a_entry. execve() jumps thru this vector to pass vectors to your program, instead of going thru the normal AmigaDOS startup part. As long as you use my crt0.o and libc.a, this whole thing is completely transparent to your program, you only have to care for it, if you want to support the mechanism in other languages as well. The second problem is how to start `old' AmigaDOS programs from execve(). If the program has the described magic header, starting is easy. Else another approach is taken, depending on the OS version. Common to both OS versions (1.3 and 2.0) is redirection of stdin and stdout. Since the new program can't refer to the real file descriptors (I can't pass the open library without my startup code), I have to setup DOS fields to use my filehandles. This may succeed or not, depending on whether the descriptors in question are realized by DOS files or not (in the future a not-compatible alternative would be descriptors that refer to sockets!). Actual starting of the program is done with RunCommand() under 2.0, and some own hack under 1.3. If someone is interested to get this working well under 1.3, I'd be happy to include a better starter function, my kludge doesn't particularly deal graceful with BCPL functions... 7. Support Utilities a. Frontends I'm thinking of GUI's here. There is one (something like GCC_Frontend) on the April 1994 Aminet CD-ROM collection. If I remember correctly though, when I tried using it, it bugged out on me. Anybody know of anything else? b. Debuggers (Maybe just GDB?) GDB is the GNU debugger, and Fred Fish is the port master for it. Here is something from his readme. GDB 4.12 has been ported to the extent that you can build an AmigaDOS executable that knows how to load and examine executables from non-AmigaDOS systems. Much work remains. See the gnu:src/diffs/gdb-4.12-README file. [He's referring to the general gnu:source directory. If you unpack the gdb source archive to your GNU: directory, it should be in that same directory.] c. What else? 8. Additional Support a. amiga-gcc-port mailing list b. snail mail (?) - for people getting it off of CD-ROM c. You never know, it could be a problem in base FSF code gnu.gcc Newsgroup and daughter newsgroups ftp: prep.ai.mit.edu in /pub/gnu is the primary archive for the GNU Project. If you need the FSF baseline code for something, it'll be there. 9. Known Bugs a. C compiler i) -resident option This has been broken since 2.3.3. Hence, you'll need to get that version if you want to compile a program you can easily make resident. Of course, you can always write your code to be resident, it just takes a little more effort (see above). This is fixed in 2.7.0. ii) -fbaserel option Won't be fixed until the -resident option is (as it's the cause of the -resident problem). b. C++ compiler (g++) c. Objective C compiler 10. Maintainers and Contributors Gcc v2.2.2 port: Markus Wild Gcc v2.3.3 port: Markus Wild Gcc v2.4.5 port: Philippe Brand, Lars Hecking, Fred Fish Gcc v2.5.0 and up: Philippe Brand, Fred Fish, Leonard Norrgard Ixemul.library: Markus Wild, Leonard Norrgard, R. Luebbert Libnix: Matthias Fleischer, Gunther Nikl Also, much testing, suggestions and debate have been provided by Jorg Hoehle Peter Ivemey-Cook Christian Stieber Walter Harms Lars Hecking Kriton Kyrimis Niklas Hallqvist Jochen Wiedmann Thomas Walter not necessarily in that order. [ I just compiled this list from looking at the 1995 archive and some of the '94, whoever consistently either (a) made suggestions and wrote some code or (b) has been reporting bugs from attempts at compiling GNU software for a long time (i.e. not someone who's just having problems porting their favorite package). If I've left someone out, or if you have a problem with my criteria, or if you think I should just thank the mailing list as a whole, mail me]. The present FAQ maintainer is Lynn Winebarger (owinebar@indiana.edu). However, you should send corrections to amiga-gcc-port@nic.funet.fi for a look over, as that's what I'll do anyway. [or maybe they should just send them to me, and I can screen out the very common screw-up from people who think they know.] Flames directed to /dev/null. 11. Future 12. History Appendix A: How does the GPL affect programs compiled by GCC? [Niklas Hallqvist] > If I compile one of my sources with gcc, do I have to > distribute it under the GPL? I'm not using any GNU libraries or > startup or anything. My interpretation of the GPL is that i > don't have to, but one of the teacher (lecturers?) say that I > have to. Who's right? You are. The GPL (and LGPL) only covers distributed code, not code generated by tools which are GPL:ed. As there are code which get linked by GCC distributed with GCC, libgcc.a, one might think that the GPL would apply to generated code, but no, libgcc.a is written without GPL just to enable that use of the GNU compiler. Think about it, several object-only commercial applications including OSes are compiled by GCC for enhanced performance, would they do that if they had to give up their objectcode-only policy? The key behind the GPL is that no code based on work GPLed, should be locked to to that specific compilation, but the user should be able to customize the GPLed code as he wants to and recompile. You are still allowed to protect your own source as you see fit. For example, let's say you use som LGPLed library libfoo.a in your application app. When you distribute it you must also distribute a linkable objectfile app.o which, when linked with the distibuted libfoo.a (with source) generates app. If the end-user wants, he should be able to customize libfoo, and relink it with app.o to get a customized app. It's not a very severe limitation on distribution rights IMHO. Remember that the (L)GPL was written to give programmers more Freedom, not to limit their chance of protecting their own work. As long as their own work is clearly delimited from others GPLed work, it's perfectly OK to keep a separate copyright policy on it. In your case, your lecturer has misunderstood the intentions of the (L)GPL which is easy to do. These discussions come up ever so often because of the legaleze used to express the GPL. Too bad many get the GPL wrong, as rumours like "you cannot use GNU products for business work" severly harms the usage of GNU products. To name a few uses of GCC where the program did NOT fall under the GPL: Dell Unix SVR4, NextStep & some OSF/1 port. Tell your lecturer about these, and ask him why he thinks the GPL prevents them to be sold during other than GPL conditions? I ask you to actually convince him he was wrong as it is harmful for the programming society that such misconceptions exist. This is where I'd like to put that list of libraries that are GPLed. Appendix B: GNU Porting activities and who's dealing with them Not really GCC (Which is why it's an Appendix), but certainly one of GCC's main uses. It would be good to keep track of these things anyway, in case someone wants to start working on porting something (just as administratvia). Appendix C: Another Free C compiler (for those without much memory) Warning, apparently lcc is not yet fully ported (no backend) for easy use. [Fred Fish] > > One of the things I hope to eventually add to my FreshFish CD is a > > port of lcc, which is much smaller and faster than gcc, and apparently > > somewhat more ANSI compliant. I just haven't had time yet to look > > at doing so. > > What's lcc? I never heard of it. ============================ begin inclusion =========================== lcc is the retargetable compiler for ANSI C described in our book `A Retargetable C Compiler: Design and Implementation' (Benjamin Cummings, 1995, ISBN 0-8053-1670-1), which will be available in December 1994. lcc is in production use at Princeton University and AT&T Bell Laboratories. The public distribution directory contains the following files. README this file. install.{ps,txt} describes the distribution and gives installation instructions. install.ps is the PostScript generated from the HTML document, install.html, which is included in the the distribution. X.Y.tar.{Z,gz} a compressed tar files for the distribution of version X.Y, e.g., 3.0.tar.Z the tar file compressed with compress. This distribution includes user documentation, the front end, the driver program, code generators for the SPARC, MIPS R3000 and x86, and the code-generator generator that produced them. A .gz file is the tar file compressed with gzip instead of compress. The distribution is available via `anonymous' ftp from ftp.cs.princeton.edu (128.112.152.13) in the directory pub/lcc. Obtaining and extracting the distribution into its own directory is accomplished by the following commands. Replace `3.0' with the latest version, which is the only one typically available; versions like `3.0a' identify minor updates and versions like `3.1beta' identify pre-releases (which might be incomplete). As suggested, use your login as the password, and use ftp's binary transfer mode. mkdir lcc cd lcc ftp ftp.cs.princeton.edu anonymous yourlogin cd pub/lcc binary get 3.0.tar.Z dist.tar.Z quit zcat dist.tar | tar xpof - rm dist.tar.Z To be added to the lcc mailing list, send a message with the 1-line body subscribe lcc to majordomo@cs.princeton.edu. This line must appear in the message body; `Subject:' lines are ignored. To learn more about mailing lists served by majordomo, send a message with the body `help' to majordomo@cs.princeton.edu. Additional information about lcc and about our book is available on the WWW at URL http://www.cs.princeton.edu/software/lcc. Chris Fraser / cwf@research.att.com David Hanson / drh@cs.princeton.edu Thu Aug 18 13:36:15 EDT 1994 From amiga-gcc-port-owner@nic.funet.fi Thu May 18 16:46:06 1995 Received: by nic.funet.fi id <90078-2>; Thu, 18 May 1995 16:45:05 +0300 From: Leonard Norrgard To: owinebar@nickel.ucs.indiana.edu CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95May18.161957+0300_eet_dst.90665-3+17@nic.funet.fi> (message from onnie lynn winebarger on Thu, 18 May 1995 08:16:33 -0500 (EST)) Subject: Re: FAQ update (LONG - 72K) Message-Id: <95May18.164505+0300_eet_dst.90078-2+35@nic.funet.fi> Date: Thu, 18 May 1995 16:45:02 +0300 Well-written patches are easy to get into the official GCC manual. There is no chance of getting the changes into the 2.7.0 manual though, as 2.7.0 is supposed to be released this or next week. From amiga-gcc-port-owner@nic.funet.fi Thu May 18 16:57:24 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <90450-1>; Thu, 18 May 1995 16:55:54 +0300 Received: from kalle.lysator.liu.se (kalle.lysator.liu.se [130.236.254.26]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id PAA22098; Thu, 18 May 1995 15:55:30 +0200 From: Niels M|ller Received: (nisse@localhost) by kalle.lysator.liu.se (8.6.11/8.6.11) id PAA10670; Thu, 18 May 1995 15:54:11 +0200 Date: Thu, 18 May 1995 15:54:11 +0200 Message-Id: <199505181354.PAA10670@kalle.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: vinsci@nic.funet.fi CC: owinebar@nickel.ucs.indiana.edu, amiga-gcc-port@nic.funet.fi In-reply-to: <95May18.154713+0300_eet_dst.90129-3+16@nic.funet.fi> (message from Leonard Norrgard on Thu, 18 May 1995 15:47:09 +0300) Subject: Re: Re... not: Another question (asm()) + the new faq Leonard Norrgard wrote: Rather than writing all about asm() in the FAQ, it would be much better to improve the GCC manual to describe how to use asm() in an understandable way. A way to get this started is to identify the parts of the manual that needs clarifying. -- vinsci I think that one reason why the section on inline assembler (__asm) in the gcc manual is a little diffucult to read is that it uses the syntax of machine descriptions, most of which is described in the section about creating new machine descriptions. However, most users of gcc do not want to learn about machine descriptions. Another reason may be that __asm is primarily designed for inserting assembler code into an ordinary C-function. To use __asm to define a new function call convention, like our inline headers do, get a little messy. A good thing would be some easy syntax (either in the compiler itself, or by some macros) that can be used for defining functions with register arguments and such. Some macros to do this, if I remember correctly originating from AmiTCP, were posted on this list some time ago. They could be a start. Now to the question: How do I create and use functions that take their arguments in registers? I'm not an expert, but I'll nevertheless try to answer. If you define a function like below, the effect is that it takes two arguments, in registers D0 and A0. (I hope I got this right, I have actually never used this myself). int my_func(void /* Don't declare any arguments here */) { register int arg1 __asm("d0"); register int *arg2 __asm("a0"); return do_something(arg1,arg2); } To make gcc call a function that takes registerized arguments is a little more tricky. Here you have to use inline assembler. I quote an example from the gcc manual (I guess the processor used in the example is a sparc): ----------- You can put multiple assembler instructions together in a single `asm' template, separated either with newlines (written as `\n') or with semicolons if the assembler allows such semicolons. The GNU assembler allows semicolons and all Unix assemblers seem to do so. The input operands are guaranteed not to use any of the clobbered registers, and neither will the output operands' addresses, so you can read and write the clobbered registers as many times as you like. Here is an example of multiple instructions in a template; it assumes that the subroutine `_foo' accepts arguments in registers 9 and 10: asm ("movl %0,r9;movl %1,r10;call _foo" : /* no outputs */ : "g" (from), "g" (to) : "r9", "r10"); ----------- This is equivalent to the C-statement foo(from,to); except that "from" and "to" are passed in registers r9 and r10, and not on the stack. To call amiga-style libraries is similar, the inline headers shows how it can be done. Regards, Niels Möller From amiga-gcc-port-owner@nic.funet.fi Thu May 18 17:56:24 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90192-1>; Thu, 18 May 1995 17:55:09 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id QAA09524; Thu, 18 May 1995 16:53:23 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id PAA27444; Thu, 18 May 1995 15:55:11 +0200 Date: Thu, 18 May 1995 15:55:11 +0200 From: Niklas Hallqvist Message-Id: <199505181355.PAA27444@linda.appli.se> To: owinebar@nickel.ucs.indiana.edu CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95May18.161957+0300_eet_dst.90665-3+17@nic.funet.fi> (message from onnie lynn winebarger on Thu, 18 May 1995 08:16:33 -0500 (EST)) Subject: Re: FAQ update (LONG - 72K) >>>>> "Lynn" == onnie lynn winebarger writes: Lynn> Re: making the asm() documentation in GNU info files better, it Lynn> sounds good. But at the moment it's still one of the more Lynn> confusing things (from the number of questions, anyhow). How Lynn> long will it take before the GNU folks would revise their docs? It could be done in about no time provided the docs were written in texinfo and had the structure of the existent docs. I think the problem is not to get it into the FSF distribution but rather writing now docs everyone feel comfortable with. The primary GCC developpers have sufficiently much else to do than rewrite already-written docs, although they might be considered bad or hard to understand. They do however, with pleasure, accept contributions of documentation provided the author agrees to put it under GPL. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Thu May 18 18:23:24 1995 Received: from www.utbm.fr ([193.48.246.2]) by nic.funet.fi with ESMTP id <89958-3>; Thu, 18 May 1995 18:22:33 +0300 Received: from (news@localhost) by www.utbm.fr (8.6.10/jtpda-5.1) id RAA15188 for ; Thu, 18 May 1995 17:22:45 +0100 From: Rene.Garcia@utbm.fr Received: from sunserv.ipse.fr(193.48.202.1) by www.utbm.fr via smap (V1.3) id sma015184; Thu May 18 17:22:37 1995 Received: by sunserv.ipse.fr (5.x/SMI-SVR4) id AA14685; Thu, 18 May 1995 17:21:50 +0100 Date: Thu, 18 May 1995 17:21:50 +0100 Message-Id: <9505181621.AA14685@sunserv.ipse.fr> To: amiga-gcc-port@nic.funet.fi Subject: AmigaOS soft/hard links X-Sun-Charset: US-ASCII There has been a discussion on this list last weeks about links to AmigaOS include files. I'm using OS 3.0 and I had _lots_ of problems with links : I guessed we may not rename (or move) links, consequences are terrible for the filesystem (I'm using DC-FFS) old references are not deleted and new references are shown as a real directory entry. That means that there is 2 real entries are pointing to the same file (or directory if you use the FORCE) and none is marked to be a link. I don't know if this is a bug and if it has been corrected in OS 3.1 since I haven't got it. I'm sure about one thing : I will never rename/move a link again, it's safer to delete it and create it again with the wished name or position. My last experience costed me 59 Mb of lost data on my hard disk (using disksalv to correct the link jam). I hope this will happend to none of you. Bye, Rene From amiga-gcc-port-owner@nic.funet.fi Thu May 18 19:00:09 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <90526-3>; Thu, 18 May 1995 18:57:19 +0300 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id RAA03589; Thu, 18 May 1995 17:55:20 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA00338; Thu, 18 May 95 17:53:27 GMT Date: Thu, 18 May 95 17:53:27 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9505181753.AA00338@indi1.u-strasbg.fr> To: Leonard Norrgard Subject: Re: Debug hunk info need ?? Cc: amiga-gcc-port@nic.funet.fi > Nice with the original source for FindHit... In case it's OK to put > it up for ftp, I'd appreciate if you would upload it to > ftp.funet.fi:/pub/amiga/incoming/gnu and send me some mail. > I can upload it, but only tomorrow because I have deleted the original file. Don't worry I have a copy at home. > There are two sources for documentation on the Amiga GCC debug hunk. > One would be the Amiga GCC linker source, the other one is a texinfo > document that comes with the sources to GDB, the debugger. > (stabs.texinfo). You will need to look at both. It should be pretty > easy to convert FindHit to read the stabs debug info from the debug > hunk -- Amiga GCC uses the unix a.out object file format stabs debug > info stuffed into the amiga debug hunk. Yes, it should not be too difficult to convert FindHit, but I have no experience with the stabs format. Perhaps you, or someone else could do it easier (and faster) than me. \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier | Etudiant en Doctorat | Centre de Recherche en Informatique E-Mail: | Universite Louis Pasteur papier@dpt-info.u-strasbg.fr | Strasbourg - FRANCE ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Thu May 18 19:08:21 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90181-1>; Thu, 18 May 1995 19:05:25 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 18 May 1995 18:05:04 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA08411; Thu, 18 May 95 18:05:09 +0200 Date: Thu, 18 May 95 18:05:09 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9505181605.AA08411@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA03521; Thu, 18 May 95 18:05:10 +0200 To: amiga-gcc-port@nic.funet.fi Subject: as and ld working together Hi, I've been talking with Gunther Nikl several times and he pointed out that it wasn't too good an idea in GCC-2.6.3 to use a new assembler (as->2.5.x) with an old linker (basically from the GCC-1.x). While it worked fine in the general case, I can remember messages like "bad relocation" or something like this which precisely came from the fact that in some cases, as output a newer, thus fancier object format that the old ld couldn't deal with. I don't know what the current state of ld is, but as we all want to see a clean and beautiful GCC-2.7.0, we should clean this up. Is an up-to-date (w.r.t. the current as) ld available? How big is it compared to the old one (I got the impression that some executables size exploded since BFD (see the size of objdump). Regards, Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu May 18 19:11:03 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90662-2>; Thu, 18 May 1995 19:07:34 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 18 May 95 13:28 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 18 May 95 13:07 MET DST Message-Id: Subject: asm() again To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 18 May 1995 13:07:40 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 607 for a hardware project i wrote same asm thinks in gcc (even a interrupt handler). if someone can send me a list of faq's i will see to write some answers BUT (now the other time) i am very busy this weeks and my a2630 is broken and took my HD (with backup, of cause) so i dont have ANY option to test examples. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Thu May 18 19:48:00 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90366-2>; Thu, 18 May 1995 19:47:16 +0300 Received: from mailsun.aber.ac.uk (actually user patman@mailsun.aber.ac.uk) by funet.fi with SMTP (PP); Thu, 18 May 1995 19:47:18 +0300 Received: from aber.ac.uk (actually host mailsun.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Thu, 18 May 1995 17:43:39 +0100 To: amiga-gcc-port@nic.funet.fi Subject: cp source Date: Thu, 18 May 1995 17:43:35 +0100 Message-ID: <24752.800815415@aber.ac.uk> From: Dominic Hi there! Is there anywhere I can find the C source of the UNIX cp command, or anything similar? This (and to a lesser extent, ANY UNIX commands) would be very helpful to me. Anything gratefully recieved! Regards, Dominic ----------------------------------------------------------------------- Dominic Tristram - dbt3@aber.ac.uk http://www.dcs.aber.ac.uk/~dbt3 Department of Computer Science, Aberystwyth /// Amiga Developer /// \\\/// Amiga - The computer for the \XX/ creative mind Intel inside - - Idiot outside From amiga-gcc-port-owner@nic.funet.fi Thu May 18 19:51:41 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <90730-3>; Thu, 18 May 1995 19:51:01 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA22596; Thu, 18 May 1995 17:50:56 +0100 Date: Thu, 18 May 1995 17:52:18 +0100 (BST) From: Peter Ivimey-Cook To: Dominic Cc: amiga-gcc-port@nic.funet.fi Subject: Re: cp source In-Reply-To: <24752.800815415@aber.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 18 May 1995, Dominic wrote: > Hi there! > Is there anywhere I can find the C source of the UNIX cp command, > or anything similar? This (and to a lesser extent, ANY UNIX commands) > would be very helpful to me. Anything gratefully recieved! > Dominic - use ftp to get the GNU utility archive "fileutils.tar.gz" - e.g. from src.doc.ic.ac.uk under /gnu (I think) - there are *many* mirrors of this. ftp.mit.edu is another I think. Ad for things like NetBSD and the Linux code, I can't say where, but it too is widely ftp-able. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Thu May 18 19:55:33 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90780-2>; Thu, 18 May 1995 19:54:59 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id SAA13637; Thu, 18 May 1995 18:53:03 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id RAA28077; Thu, 18 May 1995 17:53:47 +0200 Date: Thu, 18 May 1995 17:53:47 +0200 From: Niklas Hallqvist Message-Id: <199505181553.RAA28077@linda.appli.se> To: hoehle@inf-wiss.uni-konstanz.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9505181605.AA08411@inf-wiss.uni-konstanz.de> (hoehle@inf-wiss.uni-konstanz.de) Subject: Re: as and ld working together >>>>> "Joerg-Cyril" == Joerg-Cyril Hoehle writes: Joerg-Cyril> How big is it compared to the old one (I got the Joerg-Cyril> impression that some executables size exploded since BFD Joerg-Cyril> (see the size of objdump). That's probably correct. BFDs genericity costs quite alot spacewise. Esp. if the full cross-format version of BFD is used. In order to save disk space, one could think of doing a dynamically linkable version of the library. I won't do it, I just suggest it, if someone else wants a spare time project. Hey, I won't probably not even USE it, as I'm never doing AmigaDOS work anymore. I'm just on this list still, due to laziness, and the fact that occasionally generic m68k topics crop up. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Thu May 18 20:20:30 1995 Received: by nic.funet.fi id <90695-3>; Thu, 18 May 1995 20:18:54 +0300 From: Leonard Norrgard To: papier@indi1.u-strasbg.fr CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9505181753.AA00338@indi1.u-strasbg.fr> (papier@indi1.u-strasbg.fr) Subject: Re: Debug hunk info need ?? Message-Id: <95May18.201854+0300_eet_dst.90695-3+33@nic.funet.fi> Date: Thu, 18 May 1995 20:18:45 +0300 > Yes, it should not be too difficult to convert FindHit, but I have > no experience with the stabs format. Perhaps you, or someone else > could do it easier (and faster) than me. Oh, probably but time... I think you'll find that the stabs format is very simple to understand and write software for. The Amigados hunk format on the other hand is a real pig. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Thu May 18 20:21:35 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90764-3>; Thu, 18 May 1995 20:20:58 +0300 Received: from amigalib.com (fishpond.amigalib.com) by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HQNN1N7ZF40045UY@FIPORT.FUNET.FI>; Thu, 18 May 1995 17:21:18 +0200 (EET) Received: by amigalib.com (Smail3.1.28.1 #64) id m0sC9vD-0004nqC; Thu, 18 May 95 11:03 MST Date: Thu, 18 May 1995 11:03:43 -0700 (MST) From: fnf@amigalib.com (Fred Fish) Subject: Re: as and ld working together In-reply-to: <9505181605.AA08411@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at May 18, 95 06:05:09 pm To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Cc: amiga-gcc-port@nic.funet.fi Message-id: MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL23] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-length: 991 > I don't know what the current state of > ld is, but as we all want to see a clean and beautiful GCC-2.7.0, we > should clean this up. I've built the binutils ld here locally and used it when rebuilding my entire GNU tree as a test case, though this was some time ago. As far as I can remember, everything worked except for "linker flavors" and the case where relocations in a single hunk exceed the AmigaDOS limit of 65536 per hunk (such as when linking GNU octave). If these two things are fixed, I think we are very close to having a working BFD based linker. > Is an up-to-date (w.r.t. the current as) ld available? How big is it > compared to the old one (I got the impression that some executables > size exploded since BFD (see the size of objdump). The source is on my FreshFish CD for the version I used, which had some changes that were necessary. I sent the changes back to Stephan, but I'm not sure if they were ever folded back into his source and made available. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu May 18 20:25:12 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90327-2>; Thu, 18 May 1995 20:24:50 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id TAA19616; Thu, 18 May 1995 19:23:01 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id SAA28279; Thu, 18 May 1995 18:19:07 +0200 Date: Thu, 18 May 1995 18:19:07 +0200 From: Niklas Hallqvist Message-Id: <199505181619.SAA28279@linda.appli.se> To: Peter.Ivimey-Cook@isltd.insignia.com CC: dbt3@aber.ac.uk, amiga-gcc-port@nic.funet.fi In-reply-to: (message from Peter Ivimey-Cook on Thu, 18 May 1995 17:52:18 +0100 (BST)) Subject: Re: cp source >>>>> "Peter" == Peter Ivimey-Cook writes: Peter> On Thu, 18 May 1995, Dominic wrote: >> Hi there! Is there anywhere I can find the C source of the UNIX cp >> command, or anything similar? This (and to a lesser extent, ANY >> UNIX commands) would be very helpful to me. Anything gratefully >> recieved! >> Peter> Ad for things like NetBSD and the Linux code, I can't say Peter> where, but it too is widely ftp-able. NetBSD at ftp.netbsd.org! Niklas From amiga-gcc-port-owner@nic.funet.fi Thu May 18 20:39:16 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <90377-1>; Thu, 18 May 1995 20:36:33 +0300 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.6.12/8.6.9) id TAA05289; Thu, 18 May 1995 19:36:09 +0200 Date: Thu, 18 May 1995 19:36:09 +0200 From: Ignatios Souvatzis Message-Id: <199505181736.TAA05289@theory.cs.uni-bonn.de> To: dbt3@aber.ac.uk CC: amiga-gcc-port@nic.funet.fi In-reply-to: Dominic's message of Thu, 18 May 1995 17:43:35 +0100 <24752.800815415@aber.ac.uk> Subject: cp source X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a; Thu, 18 May 1995 21:14:41 +0300 Received: from skoda.kom.auc.dk (jds@skoda.kom.auc.dk [130.225.51.24]) by zaz.kom.auc.dk (8.6.12/8.6.12) with ESMTP id UAA13002; Thu, 18 May 1995 20:14:24 +0200 Received: (from jds@localhost) by skoda.kom.auc.dk (8.6.12/8.6.12) id UAA15170; Thu, 18 May 1995 20:14:22 +0200 Date: Thu, 18 May 1995 20:14:22 +0200 From: Jes Degn Soerensen Message-Id: <199505181814.UAA15170@skoda.kom.auc.dk> To: Niklas Hallqvist Cc: Peter.Ivimey-Cook@isltd.insignia.com, dbt3@aber.ac.uk, amiga-gcc-port@nic.funet.fi Subject: Re: cp source In-Reply-To: <199505181619.SAA28279@linda.appli.se> References: <199505181619.SAA28279@linda.appli.se> Niklas Hallqvist writes: > >>>>> "Peter" == Peter Ivimey-Cook writes: > > Peter> On Thu, 18 May 1995, Dominic wrote: > >> Hi there! Is there anywhere I can find the C source of the UNIX cp > >> command, or anything similar? This (and to a lesser extent, ANY > >> UNIX commands) would be very helpful to me. Anything gratefully > >> recieved! > >> > > Peter> Ad for things like NetBSD and the Linux code, I can't say > Peter> where, but it too is widely ftp-able. > > NetBSD at ftp.netbsd.org! Linux at tsx-11.mit.edu:/pub/linux/680x0 Jes From amiga-gcc-port-owner@nic.funet.fi Thu May 18 21:25:19 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <90268-2>; Thu, 18 May 1995 21:23:43 +0300 Received: from laura.inesc.pt by inesc.inesc.pt with SMTP; id AA17169 (/); Thu, 18 May 1995 20:19:56 +0200 Message-Id: <199505181819.AA17169@inesc.inesc.pt> Received: by laura.inesc.pt (1.38.193.4/16.2) id AA08144; Thu, 18 May 1995 20:17:40 +0200 Date: Thu, 18 May 1995 20:17:40 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Pedro Miguel S.J.Teixeira ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Apparently-To: amiga-gcc-port@nic.funet.fi From: To: >Sorry, can't help with the other stuff, but it seems like a GVP/MaxTransfer >problem to me. Well, to me it doesn't! If it was a problem with MaxTransfer he would not be able to even try to run gcc... - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Thu May 18 22:05:20 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <90325-3>; Thu, 18 May 1995 22:02:18 +0300 Received: from laura.inesc.pt by inesc.inesc.pt with SMTP; id AA18340 (/); Thu, 18 May 1995 20:59:04 +0200 Message-Id: <199505181859.AA18340@inesc.inesc.pt> Received: by laura.inesc.pt (1.38.193.4/16.2) id AA08472; Thu, 18 May 1995 20:56:54 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Pedro Miguel S.J.Teixeira ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Subject: From: To: amiga-gcc-port@nic.funet.fi Date: Thu, 18 May 95 20:56:54 METDST Mailer: Elm [revision: 70.85] >you got VMM running with gcc ? how ? i tried it >desperatly and got only a frozen A2000 ! >i have A2630/A2091 are there know problem with vmm ? >i didnt found anything in the readme ? >walter Tell me, what is the config of your A2000? 68020+68851? 68030? 68040? You're not mad enough to be trying VMM in a 68000, are you? Anyway, if you have one of the above configs it should run smoothly. The only thing you must be aware is that ixemul.library's code must NOR go to virtual memory. Apart from that everything can, and should, be swapped out. My instalation of GCC was no big deal. I imitated directories position just like they apear on a UniX machine. I works OK with both 2.5.8 (Ye') and 2.6.3 (arrrgh). Tell me more specific details about your system... - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Thu May 18 22:11:14 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <90197-3>; Thu, 18 May 1995 22:09:06 +0300 Received: from laura.inesc.pt by inesc.inesc.pt with SMTP; id AA18593 (/); Thu, 18 May 1995 21:05:53 +0200 Message-Id: <199505181905.AA18593@inesc.inesc.pt> Received: by laura.inesc.pt (1.38.193.4/16.2) id AA08485; Thu, 18 May 1995 21:03:42 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Pedro Miguel S.J.Teixeira ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Subject: Re: Help with g++ -Stack From: To: amiga-gcc-port@nic.funet.fi Date: Thu, 18 May 95 21:03:41 METDST Mailer: Elm [revision: 70.85] Petros Michalis wrote : >I have my stack at 250K, are 500K values normal for g++? (as you're >suggesting?). My dear friend, when compiling Z80 emulator for X11, I came across a much nicer figure... 32 Megabytes of RAM and 2 MEGABYTES OF STACK ! - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Thu May 18 22:28:31 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <90189-1>; Thu, 18 May 1995 22:24:09 +0300 Received: from laura.inesc.pt by inesc.inesc.pt with SMTP; id AA19008 (/); Thu, 18 May 1995 21:20:55 +0200 Message-Id: <199505181920.AA19008@inesc.inesc.pt> Received: by laura.inesc.pt (1.38.193.4/16.2) id AA08500; Thu, 18 May 1995 21:18:45 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Pedro Miguel S.J.Teixeira ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Subject: GCC 2.7.0 uses...? From: To: amiga-gcc-port@nic.funet.fi Date: Thu, 18 May 95 21:18:45 METDST Cc: colombo.telesys-innov.fr@laura.inesc.pt Mailer: Elm [revision: 70.85] As I've been folowing, a new release of the GCC is about to be available, version 2.7.0. The thing I would like to ask is for wich lib is it beeing compiled for? The old ixemul writers are back. So, due to a lot of obvious reasons, ixemul V40.x is beeing killed. A new ixemul, following the previous series is almost ready, version 39.48. It is back compatible with V39.47, unlike V40, and includes networking (as V39.47 already did). This absence of compatibility between V40 and V39.47 made X11 developers hell. For these resons I think you must be compiling GCC V2.7.0 for ixemul V39.48 for shure... anyway I just want to be certain...;-) - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Thu May 18 22:30:02 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <90078-3>; Thu, 18 May 1995 22:27:10 +0300 Received: from laura.inesc.pt by inesc.inesc.pt with SMTP; id AA19102 (/); Thu, 18 May 1995 21:23:36 +0200 Message-Id: <199505181923.AA19102@inesc.inesc.pt> Received: by laura.inesc.pt (1.38.193.4/16.2) id AA08510; Thu, 18 May 1995 21:21:25 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Pedro Miguel S.J.Teixeira ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Subject: GCC 2.7.0 uses ...??? From: To: amiga-gcc-port@nic.funet.fi Date: Thu, 18 May 95 21:21:24 METDST Cc: phb@colombo.telesys-innov.fr Mailer: Elm [revision: 70.85] As I've been folowing, a new release of the GCC is about to be available, version 2.7.0. The thing I would like to ask is for wich lib is it beeing compiled for? The old ixemul writers are back. So, due to a lot of obvious reasons, ixemul V40.x is beeing killed. A new ixemul, following the previous series is almost ready, version 39.48. It is back compatible with V39.47, unlike V40, and includes networking (as V39.47 already did). This absence of compatibility between V40 and V39.47 made X11 developers hell. For these resons I think you must be compiling GCC V2.7.0 for ixemul V39.48 for shure... anyway I just want to be certain...;-) - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Fri May 19 00:10:58 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90132-4>; Fri, 19 May 1995 00:08:56 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sCClu-000Fi5C; Thu, 18 May 95 23:06 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07gd@wyst.hobby.nl>; Thu, 18 May 95 21:00:53 CET Message-Id: <9505182000.07gd@wyst.hobby.nl> Date: Thu, 18 May 1995 21:00:51 +0000 (CET) Content-Type: text Content-Length: 1088 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Subject: Leave AOUT format in new binutils! This is a request for the maintainer(s) of the new version of the binutils. Please leave support for the current AOUT format in. I don't mind if the default format will become the Amiga format (why do we want Amiga format? I guess it is for future implementation of the chip etc keywords?) as long as it is still possible to generate AOUT based objects. Why? Because several program dynamically read AOUT based objects. The dld-library springs to mind (has anyone out there tried my port of dld? Otherwise I'll just give it to Fred for inclusion on the Fish CDs.) and perl 5 uses dld to dynamically load other modules. Also GNU Common Lisp uses this method (which I hope to port in the near future). I'm fairly sure that there are more programs that understand the AOUT format. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri May 19 01:41:00 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90529-3>; Fri, 19 May 1995 01:38:55 +0300 Received: by colombo.telesys-innov.fr; Fri, 19 May 1995 00:40:08 +0100 From: Philippe BRAND Message-Id: <199505182340.AAA01416@colombo.telesys-innov.fr> Subject: Re: GCC 2.7.0 uses ...??? To: pmt@laura.inesc.pt Date: Fri, 19 May 1995 00:40:07 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199505181923.AA19102@inesc.inesc.pt> from "pmt@laura.inesc.pt" at May 18, 95 09:21:24 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 362 pmt@laura.inesc.pt writes: > For these resons I think you must be > compiling GCC V2.7.0 for ixemul V39.48 for > shure... anyway I just want to be certain...;-) It IS planned. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri May 19 04:18:36 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90519-4>; Fri, 19 May 1995 04:17:53 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sCHR5-0004nqC; Thu, 18 May 95 19:05 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: GCC 2.7.0 uses ...??? To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Thu, 18 May 1995 19:05:07 -0700 (MST) Cc: pmt@laura.inesc.pt, amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi (none) In-Reply-To: <199505182340.AAA01416@colombo.telesys-innov.fr> from "Philippe BRAND" at May 19, 95 00:40:07 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 554 > > For these resons I think you must be > > compiling GCC V2.7.0 for ixemul V39.48 for > > shure... anyway I just want to be certain...;-) > > It IS planned. As far as I can tell, there was never any working source released for ixemul 39.48. I have copies of 40.4, which is based on 39.44 or 39.45, it's hard to tell for sure, and another copy of 39.47 with some enhancements. I'm currently working to merge all the changes into a new version that will be 41.0. Any changes that Markus made between 39.47 and 39.48 are apparently lost. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri May 19 10:22:22 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90535-1>; Fri, 19 May 1995 09:05:44 +0300 Received: from hgatenl.hobby.nl by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HQODQQLBSW002F83@FIPORT.FUNET.FI>; Fri, 19 May 1995 06:06:00 +0200 (EET) Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sCL4B-000FcWC; Fri, 19 May 95 07:57 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07h5@wyst.hobby.nl>; Thu, 18 May 95 23:39:19 CET Date: Thu, 18 May 1995 23:39:17 +0000 (CET) From: hans@wyst.hobby.nl (Hans Verkuil) Subject: Re: as and ld working together In-reply-to: <199505181553.RAA28077@linda.appli.se> from "Niklas Hallqvist" at May 18, 95 05:53:47 pm To: niklas@appli.se Cc: amiga-gcc-port@nic.funet.fi Message-id: <9505182239.07h5@wyst.hobby.nl> Content-type: text Content-transfer-encoding: 7BIT Content-length: 1515 According to Niklas Hallqvist: > > >>>>> "Joerg-Cyril" == Joerg-Cyril Hoehle writes: > > Joerg-Cyril> How big is it compared to the old one (I got the > Joerg-Cyril> impression that some executables size exploded since BFD > Joerg-Cyril> (see the size of objdump). > > That's probably correct. BFDs genericity costs quite alot spacewise. > Esp. if the full cross-format version of BFD is used. In order to > save disk space, one could think of doing a dynamically linkable > version of the library. I won't do it, I just suggest it, if someone > else wants a spare time project. Hey, I won't probably not even USE > it, as I'm never doing AmigaDOS work anymore. I'm just on this list > still, due to laziness, and the fact that occasionally generic m68k > topics crop up. That's easy to do with my dld-3.2.6 port. It's available for ftp on ftp.funet.fi: /pub/amiga/gnu/beta/dld-3.2.6.lha. I'd very much appreciate it if someone would test dld. Besides the GNU dld library I've included a few utilities that make it easy to create a binary that dynamically includes libraries. In fact, I've tested this with objdump or something like that from the binutils-2.5.2. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri May 19 10:22:40 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90815-1>; Fri, 19 May 1995 09:06:48 +0300 Received: from hgatenl.hobby.nl by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HQODS5RDXS0029HW@FIPORT.FUNET.FI>; Fri, 19 May 1995 06:07:08 +0200 (EET) Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sCL9V-000FcWC; Fri, 19 May 95 08:03 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07ha@wyst.hobby.nl>; Thu, 18 May 95 23:41:45 CET Date: Thu, 18 May 1995 23:41:43 +0000 (CET) From: hans@wyst.hobby.nl (Hans Verkuil) Subject: Re: as and ld working together In-reply-to: <9505181605.AA08411@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at May 18, 95 06:05:09 pm To: hoehle@inf-wiss.uni-konstanz.de Cc: amiga-gcc-port@nic.funet.fi Message-id: <9505182241.07ha@wyst.hobby.nl> Content-type: text Content-transfer-encoding: 7BIT Content-length: 1184 According to Joerg-Cyril Hoehle: > > I've been talking with Gunther Nikl several times and he pointed out > that it wasn't too good an idea in GCC-2.6.3 to use a new assembler > (as->2.5.x) with an old linker (basically from the GCC-1.x). While it > worked fine in the general case, I can remember messages like "bad > relocation" or something like this which precisely came from the fact > that in some cases, as output a newer, thus fancier object format that > the old ld couldn't deal with. I don't know what the current state of > ld is, but as we all want to see a clean and beautiful GCC-2.7.0, we > should clean this up. I strongly suspect that the cause of the relocation problems is that someone tried to compile with -resident. Support for that was broken in the new assembler. Patches have been mailed to Fred Fish, so this is no longer an issue for GCC-2.7.0. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri May 19 10:23:16 1995 Received: from sunmbx.netmbx.de ([192.76.152.9]) by nic.funet.fi with SMTP id <90149-2>; Fri, 19 May 1995 07:23:43 +0300 Received: by sunmbx.netmbx.de (/\==/\ Smail3.1.28.1) from tmpmbx.netmbx.de with smtp id ; Fri, 19 May 95 06:28 MET DST Received: by tmpmbx.netmbx.de (/\==/\ Smail3.1.28.1 #28.6) id ; Fri, 19 May 95 06:22 MES Received: from bamp by zelator.BerliNet.DE with bsmtp (Smail3.1.28.1 #11) id m0sCLSN-0003LWC; Fri, 19 May 95 06:22 MESZ To: amiga-gcc-port@lists.funet.fi Message-Id: <43272130@b.winkelmann.bamp.berlinet.de> From: B.Winkelmann@bamp.berlinet.de (Bert Winkelmann) Path: bamp.berlinet.de!B.Winkelmann Subject: Is g++ stable? Date: Thu, 18 May 1995 11:20:16 +0200 X-Mailer: UMSZer V2.22 public References: <199505111239.OAA05365@vann.alkymi.unit.no> X-Gateway: ZCONNECT U2 zelator.BerliNet.DE [UNIX/Connect v0.71] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 24 [problems with linker errors when using the libg++ Stringclass deleted] I had the same problem and have reinstalled libg++ today and the problem is completely vanished. I have using the 'libg++-2.6.2-bin.lha'-archive from the Fresh-Fish-8-CD. Originally I had installed the libg++ from the gcc-2.6.?-archive: The inline String() ctor will not work, because the #pragma interface keyword avoid inlining (why?). After remove this #pragma ld missed the func String::_substr(int,int) referenced by libg++(String.o) (the func is declared and defined as inline in String.h). Can it be, libg++(String.o) in the gcc-archive is defect? Maybe because '#pragma interface' works not correct with changed filenames like _String.h/String.cc instead String.h/String.cc MfG, Bert. From amiga-gcc-port-owner@nic.funet.fi Fri May 19 12:10:05 1995 Received: from uci.agh.edu.pl ([149.156.96.9]) by nic.funet.fi with SMTP id <90364-3>; Fri, 19 May 1995 12:07:52 +0300 Received: from icslab.agh.edu.pl by uci.agh.edu.pl (8.6.10/ALLMAN-8.6.9) id LAA21476; Fri, 19 May 1995 11:07:37 +0200 Organization: University of Mining and Metallurgy Address: Mickiewicza 30, 30-059 Krakow, POLAND Received: by icslab.agh.edu.pl (4.1/SMI-4.1) id AA10218; Fri, 19 May 95 11:09:42 +0200 Date: Fri, 19 May 1995 11:09:40 +0200 (MET DST) From: Kamil Iskra Subject: Re: your mail To: pmt%laura.inesc.pt@plearn.edu.pl Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199505181819.AA17169@inesc.inesc.pt> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 18 May 1995 pmt%laura.inesc.pt@plearn.edu.pl wrote: > >Sorry, can't help with the other stuff, but it seems like a GVP/MaxTransfer > >problem to me. > > Well, to me it doesn't! If it was a problem with MaxTransfer > he would not be able to even try to run gcc... Not necessairly. If his harddrive is largely fragmented, GCC might be splitted in a few parts on the harddrive, and this way he will be able to run GCC, even though the file size is larger then MaxTransfer value acceptable by his harddrive. Kamil Iskra From amiga-gcc-port-owner@nic.funet.fi Fri May 19 12:27:16 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <90642-1>; Fri, 19 May 1995 12:25:07 +0300 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id LAA01957 (8.6.12/7.4b-FAU);; Fri, 19 May 1995 11:24:34 +0200 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA19233; Fri, 19 May 1995 11:24:30 +0200 Date: Fri, 19 May 1995 11:24:30 +0200 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9505190924.AA19233@pctc.chemie.uni-erlangen.de> To: dbt3@aber.ac.uk Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <24752.800815415@aber.ac.uk> (message from Dominic on Thu, 18 May 1995 17:43:35 +0100) Subject: Re: cp source Hello! To look for the C source of the UNIX commands get the archives sh-utils-x.xx.tar.gz, filesutils-x.xx.tar.gz, textutils-x.xx.tar.gz where the x represent digits from your nerest site that holds the GNU stuff Hope this helps Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Fri May 19 12:43:34 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <90750-2>; Fri, 19 May 1995 12:41:21 +0300 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id LAA02151 (8.6.12/7.4b-FAU);; Fri, 19 May 1995 11:41:11 +0200 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA25507; Fri, 19 May 1995 11:41:04 +0200 Date: Fri, 19 May 1995 11:41:04 +0200 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9505190941.AA25507@pctc.chemie.uni-erlangen.de> To: pmt@laura.inesc.pt Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199505181819.AA17169@inesc.inesc.pt> (pmt@laura.inesc.pt) Hello! >>Sorry, can't help with the other stuff, but it seems like a GVP/MaxTransfer >>problem to me. > Well, to me it doesn't! If it was a problem with MaxTransfer >he would not be able to even try to run gcc... > > - Pedro Teixeira - You are wright. It cannot be a problem of MaxTransfer. I installed the SAS /C leaving out the critical part (the part working with sccxx.library). This part I did by hand and it worked. Then I copied all to the wright place of my HD. All copies fine but not sccxx.library. The Amiga dies with Guru Number 80000004. After reboot I tried to copy it again and --- I don't know why --- it worked without hanging up. The interesting point is, the file making the trouble is NOT the largest one, some guide-files are much bigger. Though I don't know where the problem is. Thank to all who gave some hints Bye PS to Pedro Teixeira: There is something wrong with your internet address. The period in your name is the trouble maker (free after my mailer messages 8-)). -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Fri May 19 12:50:02 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <90573-2>; Fri, 19 May 1995 12:48:40 +0300 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id LAA02286 (8.6.12/7.4b-FAU);; Fri, 19 May 1995 11:48:08 +0200 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA22081; Fri, 19 May 1995 11:48:06 +0200 Date: Fri, 19 May 1995 11:48:06 +0200 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9505190948.AA22081@pctc.chemie.uni-erlangen.de> To: pmt@laura.inesc.pt Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199505181859.AA18340@inesc.inesc.pt> (pmt@laura.inesc.pt) Subject: Re: Hello! About the problem with VMM. I also installed the new version vmm3.0. And I am also unable to make it work. To be more specific: After starting vmm I can do some config datails but if I click on SAVE or USE the Amiga freezes. NO program started which uses ixemul.library before starting vmm. My system: A2000 with A2630, 7MB RAM, 420 MB SCSI HD, Workbench 3.1, Antiflcker card from COMMO. Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Fri May 19 12:52:57 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90074-1>; Fri, 19 May 1995 12:51:45 +0300 Received: by colombo.telesys-innov.fr; Fri, 19 May 1995 11:52:55 +0100 From: Philippe BRAND Message-Id: <199505191052.LAA02890@colombo.telesys-innov.fr> Subject: Re: GCC 2.7.0 uses ...??? To: fnf@amigalib.com (Fred Fish) Date: Fri, 19 May 1995 11:52:54 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Fred Fish" at May 18, 95 07:05:07 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 892 Fred Fish writes: > As far as I can tell, there was never any working source released > for ixemul 39.48. I have copies of 40.4, which is based on 39.44 > or 39.45, it's hard to tell for sure, and another copy of 39.47 with > some enhancements. I'm currently working to merge all the changes > into a new version that will be 41.0. Any changes that Markus made > between 39.47 and 39.48 are apparently lost. Woa... can somebody make a short resume about ixemul ? I'm quite lost now... ;-) current ixemul is based on 39.47 right ? but without network support. vinsci has worked on 39.xx based on what ? I really suggest we delay 2.7.0 until proper ixemul is done. This is really a very stupid situation ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri May 19 13:02:26 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90007-3>; Fri, 19 May 1995 13:00:54 +0300 Received: by colombo.telesys-innov.fr; Fri, 19 May 1995 11:56:39 +0100 From: Philippe BRAND Message-Id: <199505191056.LAA02909@colombo.telesys-innov.fr> Subject: Re: as and ld working together To: hans@wyst.hobby.nl (Hans Verkuil) Date: Fri, 19 May 1995 11:56:38 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9505182239.07h5@wyst.hobby.nl> from "Hans Verkuil" at May 18, 95 11:39:17 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 755 Hans Verkuil writes: > That's easy to do with my dld-3.2.6 port. It's available for ftp on ftp.funet.fi: > /pub/amiga/gnu/beta/dld-3.2.6.lha. I'd very much appreciate it if someone > would test dld. Besides the GNU dld library I've included a few utilities > that make it easy to create a binary that dynamically includes libraries. > In fact, I've tested this with objdump or something like that from the > binutils-2.5.2. If I understand well we should be able to compile libbfd.a resident so that all binutils proggies use same libbfd.library ? Sound nice (if it works). -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri May 19 13:25:37 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <89958-1>; Fri, 19 May 1995 13:21:07 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa09861; 19 May 95 10:12 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id aa28093; 19 May 95 10:12 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA001fb; Fri, 19 May 95 09:57:09 GMT Date: Fri, 19 May 95 09:57:09 GMT Message-Id: <9505190957.AA001fa@flevel.demon.co.uk> Message-Id: <20b02c73.57e42-dev@flevel.demon.co.uk> In-Reply-To: <24752.800815415@aber.ac.uk> (from Dominic ) (at Thu, 18 May 1995 17:43:35 +0100) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: dbt3@aber.ac.uk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: cp source Hi Dominic, > Hi there! > Is there anywhere I can find the C source of the UNIX cp command, > or anything similar? This (and to a lesser extent, ANY UNIX commands) > would be very helpful to me. Anything gratefully recieved! You could try: ftp.cdrom.com In the directory: /FreeBSD And below you will find the source code to a whole version of Berkeley Unix (Kernel to cp) :-) Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri May 19 14:00:04 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90050-2>; Fri, 19 May 1995 13:56:33 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id MAA24845; Fri, 19 May 1995 12:54:51 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id LAA02604; Fri, 19 May 1995 11:53:22 +0200 Date: Fri, 19 May 1995 11:53:22 +0200 From: Niklas Hallqvist Message-Id: <199505190953.LAA02604@linda.appli.se> To: phb@colombo.telesys-innov.fr CC: hans@wyst.hobby.nl, amiga-gcc-port@nic.funet.fi In-reply-to: <199505191056.LAA02909@colombo.telesys-innov.fr> (message from Philippe BRAND on Fri, 19 May 1995 11:56:38 +0100 (BST)) Subject: Re: as and ld working together >>>>> "Philippe" == Philippe BRAND writes: Philippe> Hans Verkuil writes: >> That's easy to do with my dld-3.2.6 port. It's available for ftp on >> ftp.funet.fi: /pub/amiga/gnu/beta/dld-3.2.6.lha. I'd very much >> appreciate it if someone would test dld. Besides the GNU dld >> library I've included a few utilities that make it easy to create a >> binary that dynamically includes libraries. In fact, I've tested >> this with objdump or something like that from the binutils-2.5.2. Philippe> If I understand well we should be able to compile libbfd.a Philippe> resident so that all binutils proggies use same Philippe> libbfd.library ? Sound nice (if it works). That's nice in the long run, but was not what we were talking about as a short term solution to the big disk space consumption problem. Rather a libbfd.a (i.e. a straight ar archive of relocatable a.out objects) could be dynamically linked at runtime of the binutils. This makes no savings in RAM, just on disk, but I think it is an easier way to go than making a real ADOS library. In the end, of course, such a library would be most welcome. Niklas From amiga-gcc-port-owner@nic.funet.fi Fri May 19 14:50:44 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90143-4>; Fri, 19 May 1995 14:46:27 +0300 Received: by colombo.telesys-innov.fr; Fri, 19 May 1995 13:48:06 +0100 From: Philippe BRAND Message-Id: <199505191248.NAA03336@colombo.telesys-innov.fr> Subject: Re: as and ld working together To: niklas@appli.se (Niklas Hallqvist) Date: Fri, 19 May 1995 13:48:06 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199505190953.LAA02604@linda.appli.se> from "Niklas Hallqvist" at May 19, 95 11:53:22 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1006 Niklas Hallqvist writes: > > That's nice in the long run, but was not what we were talking about as > a short term solution to the big disk space consumption problem. > Rather a libbfd.a (i.e. a straight ar archive of relocatable a.out > objects) could be dynamically linked at runtime of the binutils. This > makes no savings in RAM, just on disk, but I think it is an easier way > to go than making a real ADOS library. In the end, of course, such a > library would be most welcome. Hum... seems I was too optimistic ;-) But that's already a *very* nice tool. The "only" thing left to do is hunk support for this dynamic linker... do you think you could manage it in the future ? I'd also like to know if this dynamic link is a on_demand_loading, thus only loaded when needed, or is really loaded in RAM at launch time ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri May 19 15:09:20 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89986-2>; Fri, 19 May 1995 15:05:52 +0300 Received: by colombo.telesys-innov.fr; Fri, 19 May 1995 14:07:44 +0100 From: Philippe BRAND Message-Id: <199505191307.OAA03408@colombo.telesys-innov.fr> Subject: make problem ? To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Fri, 19 May 1995 14:07:44 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 290 I'd like to know if 68020 users out there have problems or not with make from my distribution of 2.6.3. Thanks. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri May 19 15:19:17 1995 Received: from cardhu.cs.hut.fi ([130.233.192.95]) by nic.funet.fi with SMTP id <90097-4>; Fri, 19 May 1995 15:15:58 +0300 Received: by cardhu.cs.hut.fi id AA22737 (5.65c8/HUTCS-C 1.3 for amiga-gcc-port@nic.funet.fi); Fri, 19 May 1995 15:15:38 +0300 Date: Fri, 19 May 1995 15:15:38 +0300 Message-Id: <199505191215.AA22737@cardhu.cs.hut.fi> From: Tomi Ollila Reply-To: To: Niels M|ller Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Re... not: Another question (asm()) + the new faq In-Reply-To: <199505181354.PAA10670@kalle.lysator.liu.se> References: <95May18.154713+0300_eet_dst.90129-3+16@nic.funet.fi> <199505181354.PAA10670@kalle.lysator.liu.se> Niels M|ller writes: > > A good thing would be some easy syntax (either in the compiler itself, > or by some macros) that can be used for defining functions with > register arguments and such. Some macros to do this, if I remember > correctly originating from AmiTCP, were posted on this list some time > ago. They could be a start. > > Now to the question: How do I create and use functions that take their > arguments in registers? > > I'm not an expert, but I'll nevertheless try to answer. > > If you define a function like below, the effect is that it takes two > arguments, in registers D0 and A0. (I hope I got this right, I > have actually never used this myself). > > int my_func(void /* Don't declare any arguments here */) > { > register int arg1 __asm("d0"); > register int *arg2 __asm("a0"); > > return do_something(arg1,arg2); > } This works since those registers are not used for anything else. When declared in this way arg1 and arg2 are hardcoded to registers d0 and a0 (and are therefore not used for anything else when doing register allocations (if alive)). And with scratch registers such as do and a0, a function call will trash the registers if used inside the called function. The "correct" way to make this thing above would be the following: int my_func(void /* Don't declare any arguments here */) { register int d0 __asm("d0"); int arg1 = d0; register int * a0 __asm("a0"); int * arg2 = a0; ... } > > To make gcc call a function that takes registerized arguments is a > little more tricky. Here you have to use inline assembler. I quote an > example from the gcc manual (I guess the processor used in the example > is a sparc): /* example deleted */ We have written some macros to make these things easier. I'll include one of the macro files below. These macros are used as follows: ...To declare a function (named `function') that takes int argument in register d0 and ... void RAF2(function, int, arg, d0 int *, rvp, a0) #if 0 { /* this is for emacs c-mode */ #endif ... and to make a call to this functions (RRAPx -macros also return a value) int main() { int rv; RAP1(function, int, 6, d0, int *, &rv, a0); ... } > > Regards, Niels Möller Tomi Ollila. /* * $Id: rafrap.h,v 3.1 1994/04/17 11:31:54 too Exp $ * * Author: Tomi Ollila * * Created: Fri Apr 15 17:32:12 1994 too * Last modified: Wed Oct 5 20:44:08 1994 too */ #ifndef RAFRAP_H #define RAFRAP_H /* * There can be no prototype checks when using these macros so please * be _VERY_ careful with your code when using these. * (could someone tell me if arguments can be but in register by default * somehow with GCC (too)) */ #define _S(x) #x #if 0 #define RAP1(func, type1, reg1) \ static inline void func(type1 a##reg1)\ {\ register type1 reg1 __asm(#reg1) = a##reg1;\ __asm __volatile(_S(jsr __##func)\ : : "r" (reg1): "a0", "a1", "d0", "d1", "memory");\ } /* the new version below will be more informative */ #endif #define RAP1(func, type1, name1, reg1) \ static inline void func(type1 name1)\ {\ register type1 reg1 __asm(#reg1) = name1;\ __asm __volatile(_S(jsr __##func)\ : : "r" (reg1): "a0", "a1", "d0", "d1", "memory");\ } #define RAP2(func, type1, name1, reg1, type2, name2, reg2) \ static inline void func(type1 name1, type2 name2)\ {\ register type1 reg1 __asm(#reg1) = name1;\ register type2 reg2 __asm(#reg2) = name2;\ __asm __volatile(_S(jsr __##func)\ : : "r" (reg1), "r" (reg2): "a0", "a1", "d0", "d1", "memory");\ } #define RRAP1(rettype, func, type1, name1, reg1) \ static inline rettype func(type1 name1)\ {\ register rettype _res __asm("d0");\ register type1 reg1 __asm(#reg1) = name1;\ __asm __volatile(_S(jsr __##func)\ : "=r" (_res) : "r" (reg1) : "a0", "a1", "d0", "d1", "memory");\ return _res;\ } #define RRAP2(rettype, func, type1, name1, reg1, type2, name2, reg2)\ static inline rettype func(type1 name1, type2 name2)\ {\ register rettype _res __asm("d0");\ register type1 reg1 __asm(#reg1) = name1;\ register type2 reg2 __asm(#reg2) = name2;\ __asm __volatile(_S(jsr __##func)\ : "=r" (_res) : "r" (reg1), "r" (reg2)\ : "a0", "a1", "d0", "d1", "memory");\ return _res;\ } /* * RAFs */ #define RAF1(funname,type1, arg1, reg1) \ funname(VOID) \ { \ register type1 reg1 __asm(#reg1); \ type1 arg1 = reg1; #define RAF2(funname, type1, arg1, reg1, type2, arg2, reg2) \ funname(VOID) \ { \ register type1 reg1 __asm(#reg1); \ type1 arg1 = reg1; \ register type2 reg2 __asm(#reg2); \ type2 arg2 = reg2; #define RAF3(funname, type1, arg1, reg1, \ type2, arg2, reg2, type3, arg3, reg3) \ funname(VOID) \ { \ register type1 reg1 __asm(#reg1); \ type1 arg1 = reg1; \ register type2 reg2 __asm(#reg2); \ type2 arg2 = reg2; \ register type3 reg3 __asm(#reg3); \ type3 arg3 = reg3; #endif RAFRAP_H From amiga-gcc-port-owner@nic.funet.fi Fri May 19 15:29:46 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90670-4>; Fri, 19 May 1995 15:26:33 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id OAA19594; Fri, 19 May 1995 14:22:53 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id NAA03506; Fri, 19 May 1995 13:23:53 +0200 Date: Fri, 19 May 1995 13:23:53 +0200 From: Niklas Hallqvist Message-Id: <199505191123.NAA03506@linda.appli.se> To: phb@colombo.telesys-innov.fr CC: amiga-gcc-port@nic.funet.fi In-reply-to: <199505191248.NAA03336@colombo.telesys-innov.fr> (message from Philippe BRAND on Fri, 19 May 1995 13:48:06 +0100 (BST)) Subject: Re: as and ld working together >>>>> "Philippe" == Philippe BRAND writes: Philippe> Niklas Hallqvist writes: >> That's nice in the long run, but was not what we were talking >> about as a short term solution to the big disk space consumption >> problem. Rather a libbfd.a (i.e. a straight ar archive of >> relocatable a.out objects) could be dynamically linked at runtime >> of the binutils. This makes no savings in RAM, just on disk, but I >> think it is an easier way to go than making a real ADOS library. >> In the end, of course, such a library would be most welcome. Philippe> Hum... seems I was too optimistic ;-) But that's already a Philippe> *very* nice tool. The "only" thing left to do is hunk Philippe> support for this dynamic linker... do you think you could Philippe> manage it in the future ? I'd also like to know if this Philippe> dynamic link is a on_demand_loading, thus only loaded when Philippe> needed, or is really loaded in RAM at launch time ? Clarification: I am not in any way involved in dld or bfd development. I was only proposing a solution to the problem of BFD based binaries becoming huge. As it seems, the dld port to Amiga is usable to get this done. I am not doing this, and I don't know if anybody else is either, I just said it *should* be simple. The dld questions I leave to the porter... Niklas From amiga-gcc-port-owner@nic.funet.fi Fri May 19 15:35:07 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90502-1>; Fri, 19 May 1995 15:31:50 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 19 May 1995 14:31:21 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10986; Fri, 19 May 95 14:31:27 +0200 Date: Fri, 19 May 95 14:31:27 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9505191231.AA10986@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA03841; Fri, 19 May 95 14:31:27 +0200 To: amiga-gcc-port@nic.funet.fi Subject: ixemul.library 39, 40 and 41 versions [sorry for posting the same text to two lists] Hi, R. Luebbert once told me that he updated the version number of ixemul.library because he had added four new functions to the library, making it (potentially) incompatible with previous versions. By the same time, he also modified the startup-code (or the ixemul libc.a or whatever is responsible for the requester) to make programs linked with it require 40.x. Thus programs compiled with gcc-2.6.3 (which includes this new libc.a) don't want to run with an 39.x ixemul anymore, even if they don't use any of the new functions. Thus you can't use the old DaggeX library with builtin network support together with the new programs (gcc-2.6.3 for example). Now what could be done is to check if it would be nice to let a new startup-code allow a 39.x library, maybe with safety checks in the libc.a code of the four new functions (generating an SIGSEGV then???, hmm, sounds bad). Thus: Fred, think twice about changing the version number anew :-) PT> The old ixemul writers are back. So, PT> due to a lot of obvious reasons, ixemul V40.x PT> is beeing killed. A new ixemul, following the it's not killed, everybody is happy that it's ARP-free and more, it's just a question of numbers. I believe that the new version should be version 40.x (not 39, in order to be able to be used by the current libc.a linked programs) while the startup code should require at least 39.y (+ revision number if need be). PhB>I really suggest we delay 2.7.0 until proper ixemul is done. PhB>This is really a very stupid situation ;-) Hopefully it'll clear up soon. It's difficult to take a decision like this one. Bye, Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Fri May 19 15:55:49 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90095-3>; Fri, 19 May 1995 15:52:04 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id NAA25455 for ; Fri, 19 May 1995 13:51:17 +0100 From: Lars Hecking Message-Id: <199505191253.NAA07476@mostar.nmrc.ucc.ie> Subject: Re: ixemul.library 39, 40 and 41 versions To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Fri, 19 May 1995 13:53:10 +0100 (BST) In-Reply-To: <9505191231.AA10986@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at May 19, 95 02:31:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 657 > Now what could be done is to check if it would be nice to let a new > startup-code allow a 39.x library, maybe with safety checks in the > libc.a code of the four new functions (generating an SIGSEGV then???, > hmm, sounds bad). EPERM sounds more reasonable to me, maybe coupled w/ SIGINT, but that depends probably on the syscall/ixemul-function in question. Library version is checked in crt0.o (checks for 40.2 currently). -- Lars Hecking | I woke the same as any other day lhecking@nmrc.ucc.ie | Except a voice was in my head NMRC | It said seize the day, pull the trigger, Cork, Ireland | Drop the blade | And watch the rolling heads From amiga-gcc-port-owner@nic.funet.fi Fri May 19 16:17:42 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <90191-2>; Fri, 19 May 1995 16:13:44 +0300 Received: by roemer.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May19.161344+0300_eet_dst.90191-2+30@nic.funet.fi> From: To: Date: Fri, 19 May 1995 16:13:30 +0300 Date: Fri, 19 May 1995 15:12:20 +0200 (METDST) From: Rask Lambertsen To: Kamil Iskra Cc: pmt%laura.inesc.pt@plearn.edu.pl, amiga-gcc-port@nic.funet.fi Subject: Re: your mail In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 19 May 1995, Kamil Iskra wrote: > On Thu, 18 May 1995 pmt%laura.inesc.pt@plearn.edu.pl wrote: > > > >Sorry, can't help with the other stuff, but it seems like a GVP/MaxTransfer > > >problem to me. > > > > Well, to me it doesn't! If it was a problem with MaxTransfer > > he would not be able to even try to run gcc... > > Not necessairly. If his harddrive is largely fragmented, GCC might be > splitted in a few parts on the harddrive, and this way he will be able to > run GCC, even though the file size is larger then MaxTransfer > value acceptable by his harddrive. I have observed, that files which were not written in one go aren't read back in one go, even if they are not fragmented. This means, that if gcc was extracted from the lha archives, it will most likely be read in small gos (?) when gcc is executed. I don't know why it happens, but it does on my machine (OS 2.1). Copying gcc to a temporary file, deleting gcc and renaming the temporary file to gcc seems to cure the strange behaviour if enough memory is available and the option BUF=0 is used. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Fri May 19 16:44:31 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89940-2>; Fri, 19 May 1995 16:41:25 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 19 May 1995 15:40:53 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA11169; Fri, 19 May 95 15:40:59 +0200 Date: Fri, 19 May 95 15:40:59 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9505191340.AA11169@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA03864; Fri, 19 May 95 15:40:59 +0200 To: amiga-gcc-port@nic.funet.fi Subject: small disassembler Hi, I'm wondering if somebody knows of a small disassembler that works in a shell (i.e. opens no own window) and can disassemble a region of memory given on the command line. The newest version of CLISP allows this on UNIX using GDB. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Fri May 19 17:03:27 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <90640-2>; Fri, 19 May 1995 17:00:10 +0300 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.6.12/8.6.9) id PAA11109; Fri, 19 May 1995 15:59:53 +0200 Date: Fri, 19 May 1995 15:59:53 +0200 From: Ignatios Souvatzis Message-Id: <199505191359.PAA11109@theory.cs.uni-bonn.de> To: hans@wyst.hobby.nl CC: amiga-gcc-port@nic.funet.fi In-reply-to: Hans Verkuil's message of Thu, 18 May 1995 21:00:51 +0000 (CET) <9505182000.07gd@wyst.hobby.nl> Subject: Leave AOUT format in new binutils! X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a; Fri, 19 May 1995 18:53:15 +0300 Received: from laura.inesc.pt by inesc.inesc.pt with SMTP; id AA08042 (/); Fri, 19 May 1995 17:50:02 +0200 Message-Id: <199505191550.AA08042@inesc.inesc.pt> Received: by laura.inesc.pt (1.38.193.4/16.2) id AA10056; Fri, 19 May 1995 17:47:50 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Pedro Miguel S.J.Teixeira ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Subject: Vmm hangs on config? From: To: amiga-gcc-port@nic.funet.fi Date: Fri, 19 May 95 17:47:50 METDST Mailer: Elm [revision: 70.85] Thomas Walter wrote: >Hello! >About the problem with VMM. > I also installed the new version vmm3.0. And I am also unable to make it work. >To be more specific: After starting vmm I can do some config datails but if >I click on SAVE or USE the Amiga freezes. >NO program started which uses ixemul.library before starting vmm. >My system: >A2000 with A2630, 7MB RAM, 420 MB SCSI HD, Workbench 3.1, Antiflcker card from >COMMO. Im sorry, the info you gave me about your system config is not enough. A2630 is not familias to me.... but, from what you describe, it looks like a MC68EC030. This processor DOESN'T have a MMU, so it cannot run VMM or any other virtual memory handler. The thing is that these processors HAVE TC, and all other MMU registers although they do not have any efect. This way is almost impossible to detect that MMU exists or not in the processor from software. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Fri May 19 19:22:54 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <90804-3>; Fri, 19 May 1995 19:18:22 +0300 Received: from laura.inesc.pt by inesc.inesc.pt with SMTP; id AA09369 (/); Fri, 19 May 1995 18:15:02 +0200 Message-Id: <199505191615.AA09369@inesc.inesc.pt> Received: by laura.inesc.pt (1.38.193.4/16.2) id AA10127; Fri, 19 May 1995 18:12:49 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Pedro Miguel S.J.Teixeira ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Subject: MMU testing and Config VMM From: To: Walter.Harms@arbi.informatik.uni-oldenburg.de Date: Fri, 19 May 95 18:12:49 METDST Cc: amiga-gcc-port@nic.funet.fi Mailer: Elm [revision: 70.85] walter wrote> >1. i have a MMU (no EC30) setcpu fastrom works with no problems The best thing to do for testing MMU on your board is to run enforcer and run the test program, I believe, called LawBreaker. If the report matches the one in the DOC, you have a MMU running 100% >My problem was simply i started the installer (no problems) The old installer of VMM had a bug. It did not copied the config to ENVARC: causing the machine to crash. Take a look at this directory. If you don,t find the VMM config file you have to copy it by hand. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Fri May 19 20:00:06 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90662-2>; Fri, 19 May 1995 19:55:57 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id RAA27910; Fri, 19 May 1995 17:54:38 +0100 From: Lars Hecking Message-Id: <199505191656.RAA07672@mostar.nmrc.ucc.ie> Subject: Re: Vmm hangs on config? To: pmt@laura.inesc.pt Date: Fri, 19 May 1995 17:56:29 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199505191550.AA08042@inesc.inesc.pt> from "pmt@laura.inesc.pt" at May 19, 95 05:47:50 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 396 > >A2000 with A2630, 7MB RAM, 420 MB SCSI HD, Workbench 3.1, Antiflcker card from > >COMMO. > > Im sorry, the info you gave me about your system config is not > enough. A2630 is not familias to me.... but, from what you describe, > it looks like a MC68EC030. This processor DOESN'T have a MMU, so it > cannot run VMM or any other virtual memory handler. There are no A2630 with EC030. From amiga-gcc-port-owner@nic.funet.fi Fri May 19 21:46:12 1995 Received: from unixg.ubc.ca ([137.82.27.14]) by nic.funet.fi with SMTP id <90867-2>; Fri, 19 May 1995 21:42:35 +0300 Received: from interchg.ubc.ca by unixg.ubc.ca (8.6.10/1.14) id LAA17891; Fri, 19 May 1995 11:30:22 -0700 Date: Fri, 19 May 1995 11:30:20 -0700 (PDT) From: Warren Van Winckel X-Sender: warrenvw@interchg.ubc.ca To: Philippe BRAND cc: Amiga-Gcc Liste Subject: Re: make problem ? In-Reply-To: <199505191307.OAA03408@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have not been able to use the make program, nor been able to compile C++ code which includes the iostream.h file. Any help would be appreciated. Thanks, Warren .................... warrenvw@unixg.ubc.ca .... \/\/\/\/\/ ...... On Fri, 19 May 1995, Philippe BRAND wrote: > I'd like to know if 68020 users out there have problems or not with > make from my distribution of 2.6.3. Thanks. > -- > Philippe BRAND > phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB > AmigaDOS GNU Project, AmigOS Net/WWW coordinator. > http://www.telesys-innov.fr/about/PhB.html > From amiga-gcc-port-owner@nic.funet.fi Fri May 19 21:59:15 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <90095-1>; Fri, 19 May 1995 21:55:55 +0300 Received: from math.uwaterloo.ca ([129.97.140.144]) by math.uwaterloo.ca with SMTP id <77131-4>; Fri, 19 May 1995 14:55:32 -0400 Date: Fri, 19 May 1995 14:55:21 -0400 From: Jeff Shepherd To: Amiga-Gcc List Subject: make problem? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am having a few problems with make but not life-threatening. From time to time, make dumps its database. Most of the time make dumps after a unsuccessful compile but sometimes after a good one. There is no pattern to it at all. Most of the time I can ^C to stop make, but sometimes I just have to sit through it. It is annoying because make spews out 100K+ of useless information dealing with environment variables and file dependencies. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/index.html The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Fri May 19 23:04:43 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90364-4>; Fri, 19 May 1995 23:03:32 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sCZ19-0004nqC; Fri, 19 May 95 13:51 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: make problem? To: jsshephe@math.uwaterloo.ca (Jeff Shepherd) Date: Fri, 19 May 1995 13:51:31 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Jeff Shepherd" at May 19, 95 02:55:21 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 656 > I am having a few problems with make but not life-threatening. From time > to time, make dumps its database. Most of the time make dumps after a > unsuccessful compile but sometimes after a good one. There is no pattern > to it at all. I don't know what version of make it is we are talking about here, but I had exactly this problem with 3.72.1, which is why I stayed at 3.71 for my CD distributions. I'm now running 3.73 and have not seen that problem. I think it was a generic bug in make since I do seem to recall discussion of this problem on other newsgroups, when someone found a place where make clobbered a location on it's stack. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat May 20 01:54:32 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <90595-3>; Sat, 20 May 1995 01:53:38 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa26984; 19 May 95 23:45 GMT-60:00 Received: from flevel.demon.co.uk by post.demon.co.uk id ab28545; 19 May 95 23:45 GMT-60:00 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA001je; Fri, 19 May 95 14:31:25 GMT Date: Fri, 19 May 95 14:31:25 GMT Message-Id: <9505191431.AA001jd@flevel.demon.co.uk> Message-Id: <20b06cbb.c8321-dev@flevel.demon.co.uk> In-Reply-To: <9505190941.AA25507@pctc.chemie.uni-erlangen.de> (from Thomas Walter ) (at Fri, 19 May 1995 11:41:04 +0200) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: walter@pctc.chemie.uni-erlangen.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: your mail Hi Thomas, > You are wright. It cannot be a problem of MaxTransfer. I installed the > SAS /C leaving out the critical part (the part working with sccxx.library). > This part I did by hand and it worked. > > Then I copied all to the wright place of my HD. All copies fine but not > sccxx.library. The Amiga dies with Guru Number 80000004. After reboot > I tried to copy it again and --- I don't know why --- it worked without > hanging up. The interesting point is, the file making the trouble is NOT > the largest one, some guide-files are much bigger. > > Though I don't know where the problem is. Thank to all who gave some hints Have you tried:- a) Running Snoopdos while the problem happens? b) Running enforcer (If you have an MMU)? c) Checking your DMA mask? d) Running devmon on your hard drive device? e) Running diskspeed on the hard drive (See if it crashes, and if so at what blocksize)? Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Sat May 20 16:53:59 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <90339-4>; Sat, 20 May 1995 16:51:03 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa10513; 20 May 95 14:44 GMT-60:00 Received: from iceman.demon.co.uk by post.demon.co.uk id af29236; 20 May 95 14:44 GMT-60:00 Received: by iceman.demon.co.uk (V1.16/Amiga) id AA001j2; Sat, 20 May 95 14:42:04 GMT Date: Sat, 20 May 95 14:42:04 GMT Message-Id: <9505201442.AA001ix@iceman.demon.co.uk> Organization: wit's end with AmiTCP :( X-MailViewer: Mail 1.15 From: Graham Crowder To: amiga-gcc-port@nic.funet.fi Cc: bryce@gothic.demon.co.uk Subject: AmiTCP 3.0b2-gcc library - where? Hi. A while back ISTR seeing a post which said that the AmiTCP v3 SDK had been amended and now includes specific gcc awareness. I think the archive was called something like AmiTCP-v3.0b2-sdk-gcc.lha or similar. I cannot find this distribution. Can someone please point me in the right direction, or correct me if I am wrong? TIA Graham Crowder From amiga-gcc-port-owner@nic.funet.fi Sat May 20 17:20:28 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90622-2>; Sat, 20 May 1995 17:19:36 +0300 Received: from disperse.demon.co.uk by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HQQ9ALEXOG0050A7@FIPORT.FUNET.FI>; Sat, 20 May 1995 14:19:58 +0200 (EET) Received: from post.demon.co.uk by disperse.demon.co.uk id aa10511; 20 May 95 14:44 GMT-60:00 Received: from iceman.demon.co.uk by post.demon.co.uk id ae29236; 20 May 95 14:44 GMT-60:00 Received: by iceman.demon.co.uk (V1.16/Amiga) id AA001iy; Sat, 20 May 95 14:42:04 GMT Date: Sat, 20 May 1995 14:42:04 +0000 (GMT) From: Graham Crowder Subject: AmiTCP 3.0b2-gcc library - where? To: amiga-gcc-port@nic.funet.fi Cc: bryce@gothic.demon.co.uk Message-id: <9505201442.AA001ix@iceman.demon.co.uk> Organization: wit's end with AmiTCP :( Content-transfer-encoding: 7BIT X-MailViewer: Mail 1.15 Hi. A while back ISTR seeing a post which said that the AmiTCP v3 SDK had been amended and now includes specific gcc awareness. I think the archive was called something like AmiTCP-v3.0b2-sdk-gcc.lha or similar. I cannot find this distribution. Can someone please point me in the right direction, or correct me if I am wrong? TIA Graham Crowder From amiga-gcc-port-owner@nic.funet.fi Sat May 20 17:43:03 1995 Received: from vinkku.hut.fi ([130.233.245.1]) by nic.funet.fi with SMTP id <90383-2>; Sat, 20 May 1995 17:42:32 +0300 Received: from lk-hp-6.hut.fi (lk-hp-6.hut.fi [130.233.244.37]) by vinkku.hut.fi (8.6.11/8.6.7) with ESMTP id RAA13195 for ; Sat, 20 May 1995 17:42:32 +0300 Received: (tpeltone@localhost) by lk-hp-6.hut.fi (8.6.11/8.6.7) id RAA13877; Sat, 20 May 1995 17:42:30 +0300 Date: Sat, 20 May 1995 17:42:29 +0300 (EET DST) From: Teppo Peltonen To: amiga-gcc-port@nic.funet.fi Subject: Re: Re... not: Another question (asm()) + the new faq In-Reply-To: <199505181354.PAA10670@kalle.lysator.liu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Leonard Norrgard wrote: Rather than writing all about asm() in the FAQ, it would be much better to improve the GCC manual to describe how to use asm() in an Yes. You're right ofcourse. It's no use writing another manual. But... I have always thought that the purpose of a faq would be to help beginners to get started with some new subject. It would be a good idea to present the main principals and the essential concepts of the use of asm() in the faq. And I don't mean that they should be completely explained - that's what the manual is for. Instead it would help a lot if the faq provided some info about what parts should the user consult when looking help for some specific problem. understandable way. A way to get this started is to identify the parts of the manual that needs clarifying. -- vinsci Niels M|ller provides some excellent info on the subject: ... A good thing would be some easy syntax (either in the compiler itself, or by some macros) that can be used for defining functions with ^^^^^^ Sounds like a very good idea. arguments in registers? I'm not an expert, but I'll nevertheless try to answer. It is almost always nice if someone who claims not to be an expert answers... so (s)he can see the actual problem much clearer than someone who thinks the answer is obvious. ;-) ... little more tricky. Here you have to use inline assembler. I quote an example from the gcc manual (I guess the processor used in the example This is just what I had in my mind. Just telling: "Read this and this part of the manual to get answer to this problem" helps alot. ... (quote from gcc.guide/C extensions/Extended asm/ deleted) Regards, Niels M=F6ller Thank you for your answer. Teppo Peltonen (tpeltone@snakemail.hut.fi) From amiga-gcc-port-owner@nic.funet.fi Sat May 20 18:32:25 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90006-4>; Sat, 20 May 1995 18:31:32 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sCqSN-000FgYC; Sat, 20 May 95 17:28 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07in@wyst.hobby.nl>; Sat, 20 May 95 16:18:20 CET Message-Id: <9505201518.07in@wyst.hobby.nl> Date: Sat, 20 May 1995 16:18:17 +0000 (CET) In-Reply-To: <199505190953.LAA02604@linda.appli.se> from "Niklas Hallqvist" at May 19, 95 11:53:22 am Content-Type: text Content-Length: 1125 From: hans@wyst.hobby.nl (Hans Verkuil) To: niklas@appli.se Cc: amiga-gcc-port@nic.funet.fi Subject: Re: as and ld working together According to Niklas Hallqvist: > > Philippe> If I understand well we should be able to compile libbfd.a > Philippe> resident so that all binutils proggies use same > Philippe> libbfd.library ? Sound nice (if it works). > > That's nice in the long run, but was not what we were talking about as > a short term solution to the big disk space consumption problem. > Rather a libbfd.a (i.e. a straight ar archive of relocatable a.out > objects) could be dynamically linked at runtime of the binutils. This > makes no savings in RAM, just on disk, but I think it is an easier way > to go than making a real ADOS library. In the end, of course, such a > library would be most welcome. That's precisely what dld does: it dynamically links from either a.out objects or an ar archive. So no RAM is saved, just diskspace. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat May 20 18:33:18 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90832-2>; Sat, 20 May 1995 18:32:51 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sCqSp-000FgYC; Sat, 20 May 95 17:29 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07is@wyst.hobby.nl>; Sat, 20 May 95 16:29:11 CET Message-Id: <9505201529.07is@wyst.hobby.nl> Date: Sat, 20 May 1995 16:29:09 +0000 (CET) In-Reply-To: <199505191056.LAA02909@colombo.telesys-innov.fr> from "Philippe BRAND" at May 19, 95 11:56:38 am Content-Type: text Content-Length: 1192 From: hans@wyst.hobby.nl (Hans Verkuil) To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: as and ld working together According to Philippe BRAND: > > If I understand well we should be able to compile libbfd.a resident > so that all binutils proggies use same libbfd.library ? Sound nice (if it > works). No, there is no need to recompile libraries. Just compile the binutils as usual, but the final link procedure needs to be replaced and the source containing the main() function needs to be compiled with a define (-Dmain=dld_main, if I remember correctly). Instead of normal linking all objects are placed into an archive and this archive is added to a 'wrap' executable. This wrapper uses the dld-library to dynamically link everything together. In a nutshell, instead of linking during the make process you link when the program is started. Concerning -resident: I'm pretty sure that that does not work. Hans PS: the dld-archive contains a readme with a fairly detailed explanation of what I did. -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat May 20 18:34:03 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90126-2>; Sat, 20 May 1995 18:33:36 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sCqUG-000FgYC; Sat, 20 May 95 17:30 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07j2@wyst.hobby.nl>; Sat, 20 May 95 16:56:51 CET Message-Id: <9505201556.07j2@wyst.hobby.nl> Date: Sat, 20 May 1995 16:56:49 +0000 (CET) In-Reply-To: <199505191248.NAA03336@colombo.telesys-innov.fr> from "Philippe BRAND" at May 19, 95 01:48:06 pm Content-Type: text Content-Length: 1304 From: hans@wyst.hobby.nl (Hans Verkuil) To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: as and ld working together According to Philippe BRAND: > > Hum... seems I was too optimistic ;-) But that's already a *very* nice > tool. The "only" thing left to do is hunk support for this dynamic > linker... do you think you could manage it in the future ? I'm not going to add BFD support to dld! For one thing, I think that hunk support will seriously degrade performance (it ain't that fast to begin with) and the dld-library will probably increase substantially in size. Feel free to do it yourself, though :-) The current size of libdld.a is about 25 Kb, most of which needs to be statically linked into the executable itself. Remember: dynamic linking requires that all the symbols are kept with the objects, AND you need to link dld with the exe, so it is useless for small programs. > I'd also like to know if this dynamic link is a on_demand_loading, > thus only loaded when needed, or is really loaded in RAM at launch > time ? Sorry, the dynamic linker goes on linking until all references are resolved. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat May 20 18:34:31 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90247-3>; Sat, 20 May 1995 18:33:42 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sCqUm-000FgYC; Sat, 20 May 95 17:31 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07j7@wyst.hobby.nl>; Sat, 20 May 95 17:04:03 CET Message-Id: <9505201604.07j7@wyst.hobby.nl> Date: Sat, 20 May 1995 17:04:01 +0000 (CET) In-Reply-To: <199505191359.PAA11109@theory.cs.uni-bonn.de> from "Ignatios Souvatzis" at May 19, 95 03:59:53 pm Content-Type: text Content-Length: 1106 From: hans@wyst.hobby.nl (Hans Verkuil) To: ignatios@theory.cs.uni-bonn.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Leave AOUT format in new binutils! According to Ignatios Souvatzis: > > hans@wyst.hobby.nl (Hans Verkuil) typed: > > Why? Because several program dynamically read AOUT based objects. The > dld-library springs to mind (has anyone out there tried my port of dld? > > OH, but dld would use the new format as well, using the binary format > libaries... so it should be no problem, as I understand this. No, dld does NOT support BFD. That's the problem. And I'm not willing to add BFD to dld. I suspect that would entail a substantial speed and size penalty. Besides that, several other programs also directly read aout format. Also, this format is widely used (not only on UNIX, but also all the current objects and libraries created for Amiga GCC!) so I think that it would be wise to keep the support for this format regardless. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sun May 21 07:02:33 1995 Received: from nickel.ucs.indiana.edu ([129.79.10.5]) by nic.funet.fi with SMTP id <90871-1>; Sun, 21 May 1995 07:01:27 +0300 Received: by nickel.ucs.indiana.edu (5.65c+/10jsm) id AA24419; Sat, 20 May 1995 23:01:20 -0500 From: Lynn Winebarger Subject: comp.sys.amiga.gnu To: amiga-gcc-port@nic.funet.fi Date: Sat, 20 May 1995 23:01:18 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 161 Message-Id: <95May21.070127+0300_eet_dst.90871-1+12@nic.funet.fi> So did anyone ever get the ball rolling on this newsgroup? It was mentioned a while back on the mailing list, then seemed to die out. Good idea, though. Lynn From amiga-gcc-port-owner@nic.funet.fi Sun May 21 23:16:54 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90164-4>; Sun, 21 May 1995 23:14:21 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Sun, 21 May 95 22:14 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Sun, 21 May 95 22:09 MET DST Message-Id: Subject: vmm To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Sun, 21 May 1995 22:09:16 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1740 > > > Thomas Walter wrote: > > >Hello! > > >About the problem with VMM. > > > I also installed the new version vmm3.0. And I am also unable to make it work. > >To be more specific: After starting vmm I can do some config datails but if > >I click on SAVE or USE the Amiga freezes. > > >NO program started which uses ixemul.library before starting vmm. > > >My system: > >A2000 with A2630, 7MB RAM, 420 MB SCSI HD, Workbench 3.1, Antiflcker card from > >COMMO. > > Im sorry, the info you gave me about your system config is not > enough. A2630 is not familias to me.... but, from what you describe, > it looks like a MC68EC030. This processor DOESN'T have a MMU, so it > cannot run VMM or any other virtual memory handler. > The thing is that these processors HAVE TC, and all other MMU > registers although they do not have any efect. This way is almost impossible > to detect that MMU exists or not in the processor from software. > > - Pedro Teixeira - > 1. the a2630 is the 68030 card from C=, i dont know of ANY revision with ec30. 2. the same happends to me , and a lot of other ppl i know it seems to be a problem for A2000 owners (most ppl mentioned problems where a2000 owner) and it doesnt depend on the kick version (2.x crashes like 3.x) 3. it look like a VMM problem, someone should inform the author (;) and we should close the discussion until someone finds an A2630-A2000 with working VMM walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Sun May 21 23:34:46 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90678-3>; Sun, 21 May 1995 23:34:15 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Sun, 21 May 95 22:34 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Sun, 21 May 95 22:33 MET DST Message-Id: Subject: Re: small disassembler To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Sun, 21 May 1995 22:33:08 +0200 (MET DST) From: Walter Harms Cc: amiga-gcc-port@lists.funet.fi (amiga gcc-list) In-Reply-To: <9505191340.AA11169@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at May 19, 95 03:40:59 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 670 > > Hi, > > I'm wondering if somebody knows of a small disassembler that works in > a shell (i.e. opens no own window) and can disassemble a region of > memory given on the command line. The newest version of CLISP allows > this on UNIX using GDB. > > Joerg Hoehle. > hoehle@inf-wiss.uni-konstanz.de > i remember, in the begining some librarys (eg. dis.library) doing this. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Mon May 22 11:47:27 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89985-1>; Mon, 22 May 1995 11:45:01 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.10/8.6.12) id KAA11252; Mon, 22 May 1995 10:46:38 +0200 Date: Mon, 22 May 1995 10:46:36 +0200 (MET DST) From: Kamil Iskra Subject: Re: your mail To: Rask Lambertsen cc: pmt%laura.inesc.pt@plearn.edu.pl, amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 19 May 1995, Rask Lambertsen wrote: > On Fri, 19 May 1995, Kamil Iskra wrote: > I have observed, that files which were not written in one go aren't > read back in one go, even if they are not fragmented. This means, that if > gcc was extracted from the lha archives, it will most likely be read in > small gos (?) when gcc is executed. I don't know why it happens, but it > does on my machine (OS 2.1). Copying gcc to a temporary file, deleting > gcc and renaming the temporary file to gcc seems to cure the strange > behaviour if enough memory is available and the option BUF=0 is used. This is completely normal behaviour, in my opinion. Keep in your mind that AmigaDOS filesystem uses extension blocks, one for 72 data blocks (with 512 bytes blocks). If you write a big file using only one dos.library/Write() call, the filesystem writes first 72 data blocks, then writes all extension blocks together and then writes remaining data blocks, all together. This way dos.library/Seek() works rather fast (cause extension blocks are together) and data can be read in big portions. When you write big file using a lot small Write() calls, extension blocks are mixed with data blocks, so the biggest portion of data that can be read using one CMD_READ is 72 blocks. What's more, seeking becomes incredibly slow. The best way do fix it is to reorganize your HD using a disk optimizer. Kamil Iskra From amiga-gcc-port-owner@nic.funet.fi Mon May 22 12:26:58 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <90563-2>; Mon, 22 May 1995 12:25:42 +0300 Received: by ceylon.informatik.uni-rostock.de id LAA28235; Mon, 22 May 1995 11:25:36 +0200 Received: by honshu.informatik.uni-rostock.de id LAA14654; Mon, 22 May 1995 11:25:35 +0200 From: Gunther Nikl Message-Id: <199505220925.LAA14654@honshu.informatik.uni-rostock.de> Subject: Re: make problem? To: amiga-gcc-port@nic.funet.fi Date: Mon, 22 May 1995 11:25:34 +0200 (MET DST) In-Reply-To: from "Fred Fish" at May 19, 95 01:51:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1490 > > I am having a few problems with make but not life-threatening. From time > > to time, make dumps its database. Most of the time make dumps after a > > unsuccessful compile but sometimes after a good one. There is no pattern > > to it at all. > > I don't know what version of make it is we are talking about here, but > I had exactly this problem with 3.72.1, which is why I stayed at 3.71 > for my CD distributions. I'm now running 3.73 and have not seen that > problem. Sorry, but I can't agree. I am using 3.73 too and it has (sometimes) the same problem as earlier versions - dumping its whole database. Fortunately the problem disapears if I close the current shell and open a new one (the new is "clean", I add all gnu-assigns with a script) BTW, I had some problems building this new make. First, configure had its known memory problem, second every make I compiled with gcc2.6.3 and "-O2" failed to work with a "bus error". Only the "-O" version worked ... I also tried to compile a resident version of make with 2.6.3 (do not tell me thats impossible, I was able to compile and link a version), but both tries (-O and -O2) did not work (bus error). Very strange. One questions remains: the new make (3.73) outputs by default (!) "Entering" and "Leaving" if make is invoked from a makefile. All earlier amiga-versions did not show this behavior. However the same versions on other systems did it. Does anybody can explain this? Gunther From amiga-gcc-port-owner@nic.funet.fi Mon May 22 12:30:48 1995 Received: from zaz.kom.auc.dk ([130.225.51.10]) by nic.funet.fi with SMTP id <90178-2>; Mon, 22 May 1995 12:30:11 +0300 Received: from skoda.kom.auc.dk (jds@skoda.kom.auc.dk [130.225.51.24]) by zaz.kom.auc.dk (8.6.12/8.6.12) with ESMTP id LAA04203; Mon, 22 May 1995 11:29:50 +0200 Received: (from jds@localhost) by skoda.kom.auc.dk (8.6.12/8.6.12) id LAA28391; Mon, 22 May 1995 11:29:47 +0200 Date: Mon, 22 May 1995 11:29:47 +0200 From: Jes Degn Soerensen Message-Id: <199505220929.LAA28391@skoda.kom.auc.dk> To: Gunther Nikl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: make problem? In-Reply-To: <199505220925.LAA14654@honshu.informatik.uni-rostock.de> References: <199505220925.LAA14654@honshu.informatik.uni-rostock.de> Gunther Nikl writes: > > > > I don't know what version of make it is we are talking about here, but > > I had exactly this problem with 3.72.1, which is why I stayed at 3.71 > > for my CD distributions. I'm now running 3.73 and have not seen that > > problem. > > Sorry, but I can't agree. I am using 3.73 too and it has (sometimes) the > same problem as earlier versions - dumping its whole database. Fortunately > the problem disapears if I close the current shell and open a new one (the > new is "clean", I add all gnu-assigns with a script) Question: anyone tried 3.74 yet? jds@skoda:~> ll /pack/gnu/make-3.74.tar.gz -r--r--r-- 1 karthy staff 520964 May 19 18:48 /pack/gnu/make-3.74.tar.gz jds@skoda:~> Jes From amiga-gcc-port-owner@nic.funet.fi Mon May 22 13:37:51 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <90396-4>; Mon, 22 May 1995 13:35:55 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa27998; 22 May 95 11:07 +0100 Received: from flevel.demon.co.uk by post.demon.co.uk id ab07929; 22 May 95 11:07 +0100 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA001oa; Mon, 22 May 95 10:28:15 GMT Date: Mon, 22 May 95 10:28:15 GMT Message-Id: <9505221028.AA001o9@flevel.demon.co.uk> Message-Id: <20b4283e.ea60-dev@flevel.demon.co.uk> In-Reply-To: <9505201518.07in@wyst.hobby.nl> (from Hans Verkuil ) (at Sat, 20 May 1995 16:18:17 +0000 (CET)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: hans@wyst.hobby.nl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: as and ld working together Hi Hans, > > That's nice in the long run, but was not what we were talking about as > > a short term solution to the big disk space consumption problem. > > Rather a libbfd.a (i.e. a straight ar archive of relocatable a.out > > objects) could be dynamically linked at runtime of the binutils. This > > makes no savings in RAM, just on disk, but I think it is an easier way > > to go than making a real ADOS library. In the end, of course, such a > > library would be most welcome. > > That's precisely what dld does: it dynamically links from either a.out > objects or an ar archive. So no RAM is saved, just diskspace. Thats a shame. It could be imporved by caching the libraries in memory so the executables load quicker. I'm not really bothered about disk space, I haven't run out yet (1.3GB MO drives go a long way) :-) Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon May 22 13:43:11 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <90010-4>; Mon, 22 May 1995 13:42:56 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA16866; Mon, 22 May 1995 12:42:39 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9505221042.AA16866@decap2.zdv.uni-tuebingen.de> Subject: Suggestion: gcc config file To: amiga-gcc-port@nic.funet.fi Date: Mon, 22 May 1995 12:42:36 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 5892 Hello, in the last weeks we had some discussions concerning the installation of gcc. Here's a suggestion, how most of the problems could be solved without additional assigns or environment variables: Let's introduce a config file with variable definitions. It could look as follows: C_INCLUDE_PATH=Sys:Developer/Include GCCPRIORITY=-1 Now replace getenv() with a function that calls getenv() first and scans the config file, if a variable isn't found. That way we'd be compatible with the existing version, have a user-editable config file (Philippe suggested GNU:etc/gcc.config) which is much simpler than the specs file and don't need additional assigns ore environment variables. I add source code of a gcc_getenv() function below. Philippe would like to use it for gcc, probably ixemul and libnix authors could use it too, if they use getenv()? Jochen /* gcc_getenv.c: getenv() replacement for gcc Copyright(C) 1995 Free Software Foundation, Inc. This file is part of GNU CC. GNU CC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. GNU CC is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with GNU CC; see the file COPYING. If not, write to the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. gcc_getenv() works exactly like getenv(), except, that it scans a config file for environment variables, if getenv() returns NULL. */ #include #include #include #include #ifndef FALSE #define FALSE 0 #endif #ifndef TRUE #define TRUE (!FALSE) #endif typedef struct { char *name; char *value; } EnvVar; static int varsChecked = FALSE; static EnvVar *vars = NULL; static int numVars = 0; #ifndef GCC_CONFIG_NAME #define GCC_CONFIG_NAME "GNU:etc/gcc.config" #endif #define INIT_LINE_LENGTH 4096 #define INIT_NUM_VARS 32 #define CheckArray(array, actualEntries, usedEntries, needed, size) \ if (!(array) || (actualEntries) - (usedEntries) < (needed)) { \ actualEntries = actualEntries << 1; \ array = realloc((array), (actualEntries)); \ if (!(array)) { \ perror("malloc"); \ exit(20); \ } \ } char *gcc_getenv(varName) char *varName; { char *result; int i; /* Call getenv(), return immediately, if successful. */ if ((result = getenv(varName))) { return(result); } /* Scan config file, if not already done. */ if (!varsChecked) { FILE *fp; varsChecked = TRUE; if ((fp = fopen(GCC_CONFIG_NAME, "r"))) { int actualLineLength = INIT_LINE_LENGTH/2; int lineLength = 0; int actualNumVars = INIT_NUM_VARS/2; char *line = NULL; for(;;) { char *res; char *name, *val; /* Get space to read next line. */ CheckArray(line, actualLineLength, lineLength, INIT_LINE_LENGTH/2, sizeof(char)); /* Read next line. */ res = fgets(line + lineLength, actualLineLength - lineLength, fp); if (!res) { break; /* Done. */ } lineLength = strlen(line); if (line[lineLength-1] != '\n') { /* lineLength > 0 */ /* Complete reading the line. */ continue; } /* Line read, scan it. */ if (line[0] == '#') { /* Comment */ lineLength = 0; /* Next line is new line. */ continue; } if (lineLength > 1 && line[lineLength-2] == '\\') { /* Line continued on the next line. */ lineLength -= 2; line[lineLength] = '\0'; continue; } while (lineLength > 0 && (line[lineLength-1] == '\n' || line[lineLength-1] == '\r')) { line[lineLength-1] = '\0'; --lineLength; } lineLength = 0; /* Next line is new line. */ name = line; while (isspace(*name)) { ++name; } val = name; while (*val && *val != '=' && !isspace(*val)) { ++val; } if (name == val) { /* Missing variable name, ignore */ continue; /* this line. */ } while (*val && isspace(*val)) { *val = '\0'; ++val; } if (*val != '=') { /* Missing '=', ignore this line. */ continue; } /* Valid variable definition */ *val = '\0'; /* Make name a valid C string. */ ++val; while(*val && isspace(*val)) { ++val; } CheckArray(vars, actualNumVars, numVars, 1, sizeof(char *)); /* Avoid using strdup(); Ultrix doesn't have it. */ if (!(vars[numVars].name = malloc(strlen(name)+1)) || !(vars[numVars].value = malloc(strlen(val)+1))) { perror("malloc"); exit(20); } strcpy(vars[numVars].name, name); strcpy(vars[numVars].value, val); numVars++; } fclose(fp); #ifdef DEBUG fprintf(stderr, "Configuration environment:\n"); for (i = 0; i < numVars; i++) { fprintf(stderr, "%s = %s\n", vars[i].name, vars[i].value); } } else { fprintf(stderr, "Missing config file %s.\n", GCC_CONFIG_NAME); #endif } } for (i = numVars-1; i >= 0; i--) { /* Double declarations! */ if (strcmp(vars[i].name, varName) == 0) { return(vars[i].value); } } return(NULL); } #ifdef CREATE_TEST_PROGRAM int main(argc, argv) int argc; char *argv[]; { char *var = gcc_getenv("THIS_VARIABLE_IS_NEVER_DEFINED"); } #endif From amiga-gcc-port-owner@nic.funet.fi Mon May 22 16:01:56 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90918-3>; Mon, 22 May 1995 15:59:41 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sDXqY-0004nYC; Mon, 22 May 95 06:48 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: make problem? To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Mon, 22 May 1995 06:48:38 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199505220925.LAA14654@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at May 22, 95 11:25:34 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1560 > > I don't know what version of make it is we are talking about here, but > > I had exactly this problem with 3.72.1, which is why I stayed at 3.71 > > for my CD distributions. I'm now running 3.73 and have not seen that > > problem. > > Sorry, but I can't agree. I am using 3.73 too and it has (sometimes) the > same problem as earlier versions - dumping its whole database. Fortunately > the problem disapears if I close the current shell and open a new one (the > new is "clean", I add all gnu-assigns with a script) Hmm, that is interesting. There were some memory corruption bugs fixed recently in ixemul.library, and also a memory leak fixed in the shell. Perhaps the problem is related to one of those, with 3.71 being unaffected by the bugs but later versions of make being hit by them. I only recently upgraded make to 3.73, and that upgrade was after those bug fixes, and I haven't seen that old behavior at all. > BTW, I had some problems building this new make. First, configure had > its known memory problem Actually a memory leak in the shell, which has been fixed. > One questions remains: the new make (3.73) outputs by default (!) > "Entering" and "Leaving" if make is invoked from a makefile. All > earlier amiga-versions did not show this behavior. However the same > versions on other systems did it. Does anybody can explain this? I noticed this as well. I'd always meant to track down why the Amiga versions did not have this behavior (controlled by the -w switch as well, if I recall correctly). -Fred From amiga-gcc-port-owner@nic.funet.fi Mon May 22 16:11:59 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90710-2>; Mon, 22 May 1995 16:10:30 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sDY16-0004nYC; Mon, 22 May 95 06:59 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Suggestion: gcc config file To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Mon, 22 May 1995 06:59:32 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9505221042.AA16866@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at May 22, 95 12:42:36 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1261 > Let's introduce a config file with variable definitions. It could look > as follows: > > C_INCLUDE_PATH=Sys:Developer/Include > GCCPRIORITY=-1 > > Now replace getenv() with a function that calls getenv() first and > scans the config file, if a variable isn't found. That way we'd be > compatible with the existing version, have a user-editable config file > (Philippe suggested GNU:etc/gcc.config) which is much simpler than the > specs file and don't need additional assigns ore environment > variables. It should be GNU:etc/gnu.config if anything, since more than just gcc would be using it. This effectively gives getenv() special behavior for the GNU tools, and I'm not sure that is such a good idea. This is just one more thing for people to trip over when recompiling with another compiler, like SAS/C or dice for example. Plus it will be hard to mix GNU and non-GNU tools that might want to have access to the same 'environment variable'. I think it was a good idea that we worked to minimize the number of assigns necessary, and eliminate unnecessary ones. I don't see that have a few special environment variables would be enough of a problem to want to hide them in a special config file that only gcc compiled code would find. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon May 22 16:44:54 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <90059-2>; Mon, 22 May 1995 16:43:40 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA12327; Mon, 22 May 1995 15:43:24 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9505221343.AA12327@decap2.zdv.uni-tuebingen.de> Subject: Re: Suggestion: gcc config file To: fnf@amigalib.com (Fred Fish) Date: Mon, 22 May 1995 15:43:21 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Fred Fish" at May 22, 95 06:59:32 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1081 Hello, Fred, > This effectively gives getenv() special behavior for the GNU tools, > and I'm not sure that is such a good idea. This is just one more > thing for people to trip over when recompiling with another compiler, > like SAS/C or dice for example. Plus it will be hard to mix GNU and > non-GNU tools that might want to have access to the same 'environment > variable'. My idea was *not* to exchange getenv() in the libraries. Like you I think that this would be indeed a very bad idea because of loosing compatibility. However, as far as I know especially ixemul is somewhat configurable via environment variables. (Sorry, if this is wrong.) And replacing the *internal* getenv() of ixemul to look for such a config file is a good idea, IMO. My experience with config files is rather positive. (Example: App defaults under X11) By reading this files the user can see what defaults can be changed, especially if they are well documented with comments. And he can still enjoy the benefits of customization, if they are overwritten by environment variables. Jochen From amiga-gcc-port-owner@nic.funet.fi Mon May 22 16:58:48 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90335-3>; Mon, 22 May 1995 16:57:41 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sDYkS-0004nYC; Mon, 22 May 95 07:46 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Suggestion: gcc config file To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Mon, 22 May 1995 07:46:23 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <9505221343.AA12327@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at May 22, 95 03:43:21 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 704 > > This effectively gives getenv() special behavior for the GNU tools, > > and I'm not sure that is such a good idea. This is just one more > > My idea was *not* to exchange getenv() in the libraries. Like you I > think that this would be indeed a very bad idea because of loosing > compatibility. Sorry, I guess I should have read your posting a little more carefully. > defaults under X11) By reading this files the user can see what > defaults can be changed, especially if they are well documented with > comments. And he can still enjoy the benefits of customization, if > they are overwritten by environment variables. Sounds fine. I'll go back and reread the original post and code. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon May 22 17:44:53 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <90050-4>; Mon, 22 May 1995 17:43:22 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA10139 (5.65c8/IDA-1.4.4 for ); Mon, 22 May 1995 16:43:05 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA05072; Mon, 22 May 95 16:43:05 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9505221443.AA05072@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Suggestion: gcc config file To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Mon, 22 May 1995 16:43:04 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9505221042.AA16866@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at May 22, 95 12:42:36 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 911 > > Let's introduce a config file with variable definitions. It could look > as follows: > I add source code of a gcc_getenv() function below. > Sounds like a good idea. I like it. If I see it right the function exits if there's not enough memory left. Wouldn't it be better to return NULL and set errno in that case? This would give more control to the caller (just asking out of curiosity). > > Philippe would > like to use it for gcc, probably ixemul and libnix authors could use > it too, if they use getenv()? > Users of ixemul.library generally have a gnu-assignment - so IMO this is no reason to not include it in ixemul.library. But people using programs compiled with libnix might not have one and get nasty requesters (or might be irritated about a gnu config file in a program that has nothing to do with gcc). Therefore I'd rather not put it into libnix. I hope you understand this :-). Matthias From amiga-gcc-port-owner@nic.funet.fi Mon May 22 17:55:03 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90050-2>; Mon, 22 May 1995 17:54:23 +0300 Received: by colombo.telesys-innov.fr; Mon, 22 May 1995 16:55:39 +0100 From: Philippe BRAND Message-Id: <199505221555.QAA13722@colombo.telesys-innov.fr> Subject: Re: Suggestion: gcc config file To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Mon, 22 May 1995 16:55:38 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9505221443.AA05072@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at May 22, 95 04:43:04 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 654 Matthias Fleischer writes: > Users of ixemul.library generally have a gnu-assignment - so IMO this > is no reason to not include it in ixemul.library. But people using > programs compiled with libnix might not have one and get nasty > requesters (or might be irritated about a gnu config file in a program > that has nothing to do with gcc). > Therefore I'd rather not put it into libnix. > I hope you understand this :-). So let's say ENV:GCCOPTS Now what do you do ? :-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon May 22 18:21:48 1995 Received: by nic.funet.fi id <90050-3>; Mon, 22 May 1995 18:20:45 +0300 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi, gas@cygnus.com Cc: vinsci@nic.funet.fi Subject: the m68k PC relative patch to gas Message-Id: <95May22.182045+0300_eet_dst.90050-3+31@nic.funet.fi> Date: Mon, 22 May 1995 18:20:44 +0300 Can someone mail me the diffs to m68k gas that made it accept code like: lea pc@(Lget_sr),a0 instead of: lea pc@(Lget_sr-.+2), a0 in order to load the address of a label without a generating a reloc. I'm just a bit worried of this. What if the compiler would generate code that depends on the original behaviour? Is this patch also in the official gas distribution? -- vinsci From amiga-gcc-port-owner@nic.funet.fi Mon May 22 18:25:54 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90040-3>; Mon, 22 May 1995 18:25:29 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26468-3>; Mon, 22 May 1995 17:25:10 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209222-1>; Mon, 22 May 1995 17:25:01 +0100 Subject: Re: the m68k PC relative patch to gas From: Christian Stieber To: vinsci@nic.funet.fi (Leonard Norrgard) Date: Mon, 22 May 1995 17:24:58 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi, gas@cygnus.com, vinsci@nic.funet.fi In-Reply-To: <95May22.182045+0300_eet_dst.90050-3+31@nic.funet.fi> from "Leonard Norrgard" at May 22, 95 06:20:44 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 688 Message-Id: <95May22.172501+0100mesz.209222-1+629@hphalle0.informatik.tu-muenchen.de> > I'm just a bit worried of this. What if the compiler would generate > code that depends on the original behaviour? Don't know about the compiler. But since I generate code that depends on the original behavior, I think it means that I'll have to change my sources. I guess GCC could be told to change its output, too. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Mon May 22 18:27:16 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <90177-4>; Mon, 22 May 1995 18:27:01 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA24628 (5.65c8/IDA-1.4.4 for ); Mon, 22 May 1995 17:26:51 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA05167; Mon, 22 May 95 17:26:50 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9505221526.AA05167@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Suggestion: gcc config file To: amiga-gcc-port@nic.funet.fi Date: Mon, 22 May 1995 17:26:50 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 542 Forwarded message: > > So let's say ENV:GCCOPTS > Now what do you do ? :-) > What about activating the scan of gnu:etc/gcc.config when '#define IXPATHS' is set while compiling libnix? This currently activates the conversion of filenames from Un*x style to AmigaOS style and may well do more ;-). Another question is the copyright. libnix is still PD (for people who don't want to distribute sources or object files). May I have a PD version of the function, should I put libnix under GLPL or should I write my own version of it? Matthias From amiga-gcc-port-owner@nic.funet.fi Mon May 22 18:39:13 1995 Received: by nic.funet.fi id <90504-1>; Mon, 22 May 1995 18:38:31 +0300 From: Leonard Norrgard To: zrawi01@decap2.zdv.uni-tuebingen.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9505221343.AA12327@decap2.zdv.uni-tuebingen.de> (zrawi01@decap2.zdv.uni-tuebingen.de) Subject: Re: Suggestion: gcc config file Message-Id: <95May22.183831+0300_eet_dst.90504-1+34@nic.funet.fi> Date: Mon, 22 May 1995 18:38:29 +0300 > via environment variables. (Sorry, if this is wrong.) And replacing > the *internal* getenv() of ixemul to look for such a config file is a > good idea, IMO. ixemul usually calls itself through the publicly defined routines, in order to make it possible to call exec.library:SetFunction() on it, just as on any other library. Ixemul will then itself use the new function as well. A few functions bypass this for performace reasons, I think the string functions for example are among them (why patch those, anyway?). Technically, the choice can be made either way for any specific function call in the ixemul source. Now I don't see any particular reason for modifying (or having an internal version of) getenv() in order to support configuration files. Giving the user the impression of backwards compatibility is bad, since we are adding a new layer of configurability. This new layer would then fall back on the regular environment variables if a configurable variable is not found in the config file. Such things are a mess to maintain and hard thing to debug even for seasoned users (because you will usually forget to look at all possible locations where information is read from if there are more than one location). If we decide to go with a config file, we should have a config file *only*, and a single environment variable (GCC-CONFIG?) that has the name of the config file, or if undefined we can default to something in GNU:etc/. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Mon May 22 18:50:16 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <90335-4>; Mon, 22 May 1995 18:49:23 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA03410; Mon, 22 May 1995 17:49:08 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9505221549.AA03410@decap2.zdv.uni-tuebingen.de> Subject: Re: Suggestion: gcc config file To: vinsci@nic.funet.fi (Leonard Norrgard) Date: Mon, 22 May 1995 17:49:06 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95May22.183831+0300_eet_dst.90504-1+34@nic.funet.fi> from "Leonard Norrgard" at May 22, 95 06:38:29 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 761 Hello, Leonard, > If we decide to go with a config file, we should have a config file > *only*, and a single environment variable (GCC-CONFIG?) that has the > name of the config file, or if undefined we can default to something > in GNU:etc/. I don't agree. I think, that the possibility of overwriting a config file with environment variables is useful and important. For example: - I might use the value TMP=t: in a config file as a default. But I wouldn't like to change the config file, if I am low on RAM sometimes. - Suggesting an Amiga with different users (yes, there are some of them :-) one shouldn't force all of them to use the same defaults. I'd even prefer the existing situation over a config file only. Jochen From amiga-gcc-port-owner@nic.funet.fi Mon May 22 19:31:28 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <90494-1>; Mon, 22 May 1995 19:29:57 +0300 Received: from laura.inesc.pt by inesc.inesc.pt with SMTP; id AA25708 (/); Mon, 22 May 1995 18:26:16 +0200 Message-Id: <199505221626.AA25708@inesc.inesc.pt> Received: by laura.inesc.pt (1.38.193.4/16.2) id AA11702; Mon, 22 May 1995 18:24:02 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Pedro Miguel S.J.Teixeira ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Subject: ixemul history and future From: To: amiga-gcc-port@nic.funet.fi Date: Mon, 22 May 95 18:24:01 METDST Cc: ixemul@nic.funet.fi Mailer: Elm [revision: 70.85] > current ixemul is based on 39.47 right ? but without network support. > vinsci has worked on 39.xx based on what ? No, as far as I've been told from vinsci, V40.4 is based on a mix of older than V39.47 sources. This is bad! It brings back bugs that were already corrected. > I really suggest we delay 2.7.0 until proper ixemul is done. > This is really a very stupid situation ;-) Agree that it is a very stupid situation. The thing that caused all this was't, as many have said, the release of ixemul V40.4. This was good in the way that the original writers were off-line for a long period. The problem is that V40.4 was not back compatible with V39.47. When the original writers came back they found a V40.4 and probably were positivly suprised but, when they took a closer look they found that there were incompatibilities with V39.47 so, as it would be to expect, they forgot all about it and started a new V39.48 from V39.47. My opinion is that the new ixemul should be build from V39.47, the one that had already everything going, with the help from V40.4 notes that will have corrections on V39.47, for shure. Don't take me wrong! I'm not taking credit from the writter of V40.4. I simply think that they should get to a point of undestanding and that this new thing should be back compatible to V39.47 but with all the bug corrections of V40.4. I also think that it should be named V41.0 for convevience. - Pedro Teixeira - PS: It is mandatory that this new version includes networking as if the programer was working over the real NetBSD (like it was on V39.47). I also think that ixemul's network should land on AmiTCP's bsdsocket.library for obvious reasons... From amiga-gcc-port-owner@nic.funet.fi Mon May 22 19:44:34 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90184-3>; Mon, 22 May 1995 19:43:19 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sDbKk-0004nYC; Mon, 22 May 95 10:32 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ixemul history and future To: pmt@laura.inesc.pt Date: Mon, 22 May 1995 10:32:01 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi, ixemul@nic.funet.fi In-Reply-To: <199505221626.AA25708@inesc.inesc.pt> from "pmt@laura.inesc.pt" at May 22, 95 06:24:01 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1788 > No, as far as I've been told from vinsci, V40.4 is based on > a mix of older than V39.47 sources. That is what I thought as well. However when I diffed Markus's original 39.44 and 39.47 releases, to find out what things might have not made it into V40.4, all I found were some things that were deleted in V40.4, mostly code that was ifdef'd away. I.E. I found no significant fixes between 39.44 and 39.47 that could be forward merged into 40.4. > This is bad! It brings back bugs > that were already corrected. Agreed, if it is actually true. I suppose it is possible that 40.4 was based on a version older than 39.44, but I don't think so based on the diffs I've looked at so far between 40.4 and 39.47. > My opinion is that the new ixemul should be build from V39.47, > the one that had already everything going, with the help from V40.4 notes > that will have corrections on V39.47, for shure. Right now I'm working at converging both 40.4 and 39.47 to a new version, picking up the best from both. I've already merged the networking code into 40.4 and am working on resolving the other differences. > I simply think that they should get to a point of undestanding > and that this new thing should be back compatible to V39.47 but with > all the bug corrections of V40.4. I also think that it should be named > V41.0 for convevience. Define what you mean by back compatible. > PS: It is mandatory that this new version includes networking as > if the programer was working over the real NetBSD (like it was on > V39.47). I also think that ixemul's network should land on AmiTCP's > bsdsocket.library for obvious reasons... As I said, I've merged in the networking code. Now I need some simple utilities to test it with. Anyone got any pointers? -Fred From amiga-gcc-port-owner@nic.funet.fi Mon May 22 20:29:54 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90237-3>; Mon, 22 May 1995 20:29:01 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 22 May 1995 19:28:46 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA17324; Mon, 22 May 95 19:28:53 +0200 Date: Mon, 22 May 95 19:28:53 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9505221728.AA17324@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA04531; Mon, 22 May 95 19:28:51 +0200 To: fnf@amigalib.com (Fred Fish) Cc: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann), amiga-gcc-port@nic.funet.fi Subject: Re: Suggestion: gcc config file In-Reply-To: References: <9505221042.AA16866@decap2.zdv.uni-tuebingen.de> Fred Fish writes: > > Let's introduce a config file with variable definitions. It could look > > as follows: > > C_INCLUDE_PATH=Sys:Developer/Include > > GCCPRIORITY=-1 > > (Philippe suggested GNU:etc/gcc.config) which is much simpler than the > > specs file and don't need additional assigns ore environment > > variables. > > It should be GNU:etc/gnu.config if anything, since more than just gcc would > be using it. I believe that the original author only spoke about gcc_getenv(), i.e. a function that only GCC, but not GCC compiled programs would use. I didn't understand from what he wrote that every program (either ixemul or libnix based) should start to use a config (or resource file) from now on. Adding yet another place where configurations may lie makes remote debugging (in the amiga-gcc list) more difficult (i.e. gcc -v output might not be enough to detect a problem). I can remember having trouble with a program Matthew Dillon sent me unless I noticed that his DCCOPTS variable must contain -mR (e.g. use registerized parameters) => Any such extra configuration is possibly "deadly" because of incompatible options. However I must say that I much prefer one single file over a long list of environment variables, one for each purpose (i.e. the current situation). But this file could as well be called GCCOPTS and lie in ENV: (e.g. no config file :-) Matthias Fleischer writes: > What about activating the scan of gnu:etc/gcc.config when > '#define IXPATHS' is set while compiling libnix? And then have libnix-ixpaths.a and libnix-noixpaths.a? Say NO! Jochen Wiedmann writes: > I don't agree. I think, that the possibility of overwriting a config > file with environment variables is useful and important. For example: ... > TMP=t: ... > in a config file as a default. But I wouldn't like to change the > config file, if I am low on RAM sometimes. If the config file were an environment variable, why not temporarily modify that environment variable? Or set TMP on the command line? > I'd even prefer the existing situation over a config file only. I'd favor the existing situation too or one single environment variable for all settings. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon May 22 20:52:13 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <90872-2>; Mon, 22 May 1995 20:51:06 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA03847; Mon, 22 May 1995 19:51:02 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9505221751.AA03847@decap2.zdv.uni-tuebingen.de> Subject: Re: Suggestion: gcc config file To: amiga-gcc-port@nic.funet.fi Date: Mon, 22 May 1995 19:51:02 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1688 Forwarded message: >From zrawi01 Mon May 22 19:50:00 1995 Subject: Re: Suggestion: gcc config file To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Mon, 22 May 1995 19:50:00 +0200 (MET DST) In-Reply-To: <9505221728.AA17324@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at May 22, 95 07:28:53 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1294 Hello, Joerg, > Adding yet another place where configurations may lie makes remote > debugging (in the amiga-gcc list) more difficult (i.e. gcc -v output > might not be enough to detect a problem). I can remember having > trouble with a program Matthew Dillon sent me unless I noticed that > his DCCOPTS variable must contain -mR (e.g. use registerized > parameters) => Any such extra configuration is possibly "deadly" > because of incompatible options. I don't see how the output of "gcc -v" would be touched. > Jochen Wiedmann writes: > > I don't agree. I think, that the possibility of overwriting a config > > file with environment variables is useful and important. For example: > ... > > TMP=t: > ... > > in a config file as a default. But I wouldn't like to change the > > config file, if I am low on RAM sometimes. > If the config file were an environment variable, why not temporarily modify > that environment variable? Or set TMP on the command line? I'd be happy with a config file in ENV:, regardless of the name. However, note that my suggestion is much different from an environment variable like DCCOPTS, which is a collection of compiler option, where I'd like to see a file with lots of comments which shows the user what can be changed. Jochen From amiga-gcc-port-owner@nic.funet.fi Mon May 22 21:13:17 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90203-2>; Mon, 22 May 1995 21:12:28 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 22 May 1995 20:12:12 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA17497; Mon, 22 May 95 20:12:20 +0200 Date: Mon, 22 May 95 20:12:20 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9505221812.AA17497@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA04571; Mon, 22 May 95 20:12:17 +0200 To: pmt Cc: amiga-gcc-port@nic.funet.fi, ixemul@nic.funet.fi Subject: ixemul history and future In-Reply-To: <199505221626.AA25708@inesc.inesc.pt> References: <199505221626.AA25708@inesc.inesc.pt> pmt@laura.inesc.pt writes: > V39.47). I also think that ixemul's network should land on AmiTCP's > bsdsocket.library for obvious reasons... I don't find the reasons that obvious at all. ixemul and libnix are free or (L)GPL, while AmiTCP >=4.0 is a commercial package (demo or not demo: where's the source?). Why support it more than AS225? Why not DNet after all?? 3.0b2's bsdsocket.library might be another thing. But so far I didn't see a GPL'ed FreeTCP emerge and what programmer will write and test SW with both 3.0b2 and newer versions? Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon May 22 21:54:58 1995 Received: from zaz.kom.auc.dk ([130.225.51.10]) by nic.funet.fi with SMTP id <90702-4>; Mon, 22 May 1995 21:53:11 +0300 Received: from skoda.kom.auc.dk (jds@skoda.kom.auc.dk [130.225.51.24]) by zaz.kom.auc.dk (8.6.12/8.6.12) with ESMTP id UAA28237; Mon, 22 May 1995 20:52:40 +0200 Received: (from jds@localhost) by skoda.kom.auc.dk (8.6.12/8.6.12) id UAA12236; Mon, 22 May 1995 20:52:38 +0200 Date: Mon, 22 May 1995 20:52:38 +0200 From: Jes Degn Soerensen Message-Id: <199505221852.UAA12236@skoda.kom.auc.dk> To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Cc: fnf@amigalib.com (Fred Fish), zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann), amiga-gcc-port@nic.funet.fi Subject: Re: Suggestion: gcc config file In-Reply-To: <9505221728.AA17324@inf-wiss.uni-konstanz.de> References: <9505221042.AA16866@decap2.zdv.uni-tuebingen.de> <9505221728.AA17324@inf-wiss.uni-konstanz.de> Hi I have not been participating much in the discussions (atleast not as much as I would like to - school :-( ). I do try to keep up on reading though, and this thing is too important. Joerg-Cyril Hoehle writes: > Fred Fish writes: > > > Let's introduce a config file with variable definitions. It could look > > > as follows: > > > C_INCLUDE_PATH=Sys:Developer/Include > > > GCCPRIORITY=-1 > > > (Philippe suggested GNU:etc/gcc.config) which is much simpler than the > > > specs file and don't need additional assigns ore environment > > > variables. > > > > It should be GNU:etc/gnu.config if anything, since more than just gcc would > > be using it. > > I believe that the original author only spoke about gcc_getenv(), i.e. > a function that only GCC, but not GCC compiled programs would use. I > didn't understand from what he wrote that every program (either ixemul > or libnix based) should start to use a config (or resource file) from > now on. > > Adding yet another place where configurations may lie makes remote > debugging (in the amiga-gcc list) more difficult (i.e. gcc -v output > might not be enough to detect a problem). I can remember having > trouble with a program Matthew Dillon sent me unless I noticed that > his DCCOPTS variable must contain -mR (e.g. use registerized > parameters) => Any such extra configuration is possibly "deadly" > because of incompatible options. Why not let gcc -v output all the output variables it is using then, or maybe a seperate option for this (if this already exists, please forgive me my ignorance). > However I must say that I much prefer one single file over a long list > of environment variables, one for each purpose (i.e. the current > situation). But this file could as well be called GCCOPTS and lie in > ENV: (e.g. no config file :-) Please don't do this! The proper way to do this, is to make config-file somewhere (probably gnu:etc/gcc-config), with all configuration variables, and then make it possible overwrite these with environment variables - one for each option. This is how it works under UNiX, and fx. with PasTeX under AmigaDOS, and it works great! I don't think this will make the configuration system messy, as most people will try to config gcc in the config-file, avoiding too many files in ENV:, and you can always use environment variables to reconfig gcc temporary. A config-file in ENV: must definately NOT contain several options, if things are to be kept in one file it should be located somewhere else, lige gnu:etc. Regards Jes From amiga-gcc-port-owner@nic.funet.fi Mon May 22 23:33:16 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90480-4>; Mon, 22 May 1995 23:31:33 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sDe6K-000FdNC; Mon, 22 May 95 22:29 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07m5@wyst.hobby.nl>; Mon, 22 May 95 22:26:38 CET Message-Id: <9505222126.07m5@wyst.hobby.nl> Date: Mon, 22 May 1995 22:26:36 +0000 (CET) In-Reply-To: <9505221751.AA03847@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at May 22, 95 07:51:02 pm Content-Type: text Content-Length: 844 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Subject: Re: Suggestion: gcc config file According to Jochen Wiedmann: > I'd be happy with a config file in ENV:, regardless of the name. > However, note that my suggestion is much different from an environment > variable like DCCOPTS, which is a collection of compiler option, where > I'd like to see a file with lots of comments which shows the user what > can be changed. Just which settings should be placed in a config file? The only one I can think of is GCCSTACK. Am I missing something? I still fail to see why a config file would be needed, adding to the confusion. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Mon May 22 23:35:43 1995 Received: from relay2.UU.NET ([192.48.96.7]) by nic.funet.fi with SMTP id <90320-2>; Mon, 22 May 1995 23:35:19 +0300 Received: from NeXT.COM by relay2.UU.NET with SMTP id QQyqwg11170; Mon, 22 May 1995 16:31:27 -0400 Received: from laka by oz.NeXT.COM (NX5.67f1/NeXT0.1-Aleph-bf) id AA26628; Mon, 22 May 95 13:31:03 -0700 Message-Id: <9505222031.AA26628@oz.NeXT.COM> Received: by laka.next.com (NX5.67f1/NX3.0X) id AA02898; Mon, 22 May 95 13:30:52 -0700 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.0 v122.1) Received: by NeXT.Mailer (1.122.1) From: Michael Snyder Date: Mon, 22 May 95 13:30:48 -0700 To: Tobias Ruland Subject: Re: Bug - what else Cc: bug-gdb@prep.ai.mit.edu, amiga-gcc-port@nic.funet.fi References: <9505161031.AA10748@immd8.informatik.uni-erlangen.de> Tobias, This is because gdb in essence does not know the prototype for your function "test". Since you gave it integer arguments, it passed them as integers. To get around this, you need to call the function with arguments that are already of the correct type (in this case, double); either by typing explicitly double literals: (gdb) print test(0.0, 1.0, 2.0, 3.0, 4.0, 5.0) or by using casts: (gdb) print test((double)1, (double)2, (double(3), (double)4, (double)5) PS to FSF team: actually, gdb DOES know the prototype; it just doesn't make use of the information in this context. Someday, it would be nice if it would do that. Begin forwarded message: From: Tobias Ruland Date: Tue, 16 May 1995 12:30:57 +0200 To: bug-gdb@prep.ai.mit.edu Subject: Bug - what else Cc: amiga-gcc-port@nic.funet.fi dear gdb developers i've found a bug in gdb. Version: GDB 4.14 (sparc-sun-solaris2.4) Interface: XEmacs Bug Description: GDB does not get/set always correct arguments for functions. Bug reproducing procedure: Use the following example C++ program: ------------------------ CUT HERE ---------------------------- double test(double a,double b,double c,double d,double e,double f) { return 0; } int main() { int a; a=0; return a; } ------------------------ CUT HERE ---------------------------- compile it (-ggdb) and load it into gdb/xemacs. now: (gdb) b main Breakpoint 1 at 0x107e4: file bug.cxx, line 7. (gdb) run Starting program: .../a.out Breakpoint 1, main () at bug.cxx:7 (gdb) b test Breakpoint 2 at 0x107b0: file bug.cxx, line 2. (gdb) p test(0,1,2,3,4,5) Breakpoint 2, test (a=4.9406564584124654e-324, b=4.2439915834127416e-314, c=8.4879831663314175e-314, d=1.3087544257612877e-314, e=-2.027766907068094e+295, f=-5.9590254483644624e+256) at bug.cxx:2 The program being debugged stopped while in a function called from GDB. [...] as you can see the argument list is completely nonsense. while stepping through 'test' the function uses those wrong arguments, too. any ideas/fixes/comments? pls answer! c u tobias --------------------------------------------------------------------------- Tobias Ruland (student at Dept. of Artificial Intelligence, Univ. Erlangen) MAIL: tsruland@immd8.informatik.uni-erlangen.de (Please write in ENGLISH, GERMAN or FINNISH) WWW: ; Tue, 23 May 1995 13:58:26 +0300 Received: from (news@localhost) by www.utbm.fr (8.6.10/jtpda-5.1) id MAA16854 ; Tue, 23 May 1995 12:58:32 +0100 From: Rene.Garcia@utbm.fr Received: from sunserv.ipse.fr(193.48.202.1) by www.utbm.fr via smap (V1.3) id sma016848; Tue May 23 12:58:20 1995 Received: by sunserv.ipse.fr (5.x/SMI-SVR4) id AA11752; Tue, 23 May 1995 12:57:35 +0100 Date: Tue, 23 May 1995 12:57:35 +0100 Message-Id: <9505231157.AA11752@sunserv.ipse.fr> To: amiga-gcc-port@nic.funet.fi Subject: Re: ixemul history and future Cc: ixemul@nic.funet.fi X-Sun-Charset: US-ASCII Joerg Hoehle writes: > pmt@laura.inesc.pt writes: > > V39.47). I also think that ixemul's network should land on AmiTCP's > > bsdsocket.library for obvious reasons... > > I don't find the reasons that obvious at all. ixemul and libnix are > free or (L)GPL, while AmiTCP >=4.0 is a commercial package (demo or > not demo: where's the source?). Why support it more than AS225? Why > not DNet after all?? What about creating a kind of patch to ixemul.library to redefine level 1 I/O functions (using exec's SetFunction()) in order to handle sockets. Several patches could be released for the different TCP/IP stacks. This kind of patching suppose that inner functions in ixemul.library access level 1 I/O functions through a unique address (no several calls possible for the same function, you see what I mean ?) Adding features to handle AmiTCP/IP doesn't mean to include TCP/IP. ixemul.library would be an interface to access bsdsocket.library, nothing more. User would need to get the AmiTCP package by himself since it's not part of the ixemul package. > > 3.0b2's bsdsocket.library might be another thing. But so far I didn't > see a GPL'ed FreeTCP emerge and what programmer will write and test SW > with both 3.0b2 and newer versions? Patching the ixemul library would allow to update the TCP/IP part of the library without udpating ixemul. People who don't use TCP/IP wouldn't have to patch the library. You may think that this is not a clean method to handle sockets. It's just a suggestion. __________________________________________________________________________ ___ __ __ | \ / \ / \ Rene GARCIA - Etudiant en Informatique | / / __ / http://www.utbm.fr/ | \ . \___/ . \___/ public/gi/etudiants/rene.garcia/home.html From amiga-gcc-port-owner@nic.funet.fi Wed May 24 09:14:21 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90239-2>; Wed, 24 May 1995 09:11:42 +0300 Received: from funet.fi by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HQV6YSI7V4002A4G@FIPORT.FUNET.FI>; Wed, 24 May 1995 03:07:07 +0200 (EET) Received: from amigalib.com (actually host fishpond.amigalib.com) by funet.fi with SMTP (PP); Wed, 24 May 1995 06:05:39 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sE7UX-0004nYC; Tue, 23 May 95 20:52 MST Date: Tue, 23 May 1995 20:52:16 -0700 (MST) From: fnf@amigalib.com (Fred Fish) Subject: default stack options To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Cc: fnf@amigalib.com (Fred Fish) Message-id: MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL23] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-length: 785 Now that I've gotten the stack checking and stack extending code integrated into an internal test version of the ixemul.library (actually in libc.a at the moment), I've started thinking about how it should be used. I think that if gcc is used to produce ixemul.library using executables, then the default should be to have stack extension on, and you have to give it an explicit -mno-stackextend or -mfixedstack option to turn off automatic stack extension. This way, the default is basically the same as UNIX, to grow the stack invisibly as needed, and no Makefiles will have to change to use this very valuable new feature. If gcc is used to produce executables that use libnix, then the default should probably be to used a fixed stack, as is the current case. Comments? -Fred From amiga-gcc-port-owner@nic.funet.fi Wed May 24 11:04:08 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90368-1>; Wed, 24 May 1995 11:00:21 +0300 Received: by colombo.telesys-innov.fr; Wed, 24 May 1995 10:02:11 +0100 From: Philippe BRAND Message-Id: <199505240902.KAA19887@colombo.telesys-innov.fr> Subject: Re: default stack options To: fnf@amigalib.com (Fred Fish) Date: Wed, 24 May 1995 10:02:11 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Fred Fish" at May 23, 95 08:52:16 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 613 Fred Fish writes: > This way, the default is basically the same > as UNIX, to grow the stack invisibly as needed, and no Makefiles will > have to change to use this very valuable new feature. So diffs against generic GNU utils will be shorter. Sounds correct. > If gcc is used to produce executables that use libnix, then the default > should probably be to used a fixed stack, as is the current case. Agree for default behavior. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed May 24 11:56:11 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90808-1>; Wed, 24 May 1995 11:55:07 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HQVP88443K90MTHZ@LEON.CTI.GR>; Wed, 24 May 1995 11:50:09 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA21937; Wed, 24 May 95 10:13:28 +0300 Date: Wed, 24 May 1995 10:13:27 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: default stack options In-reply-to: from "Fred Fish" at May 23, 95 08:52:16 pm To: fnf@amigalib.com (Fred Fish) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@theseas.ntua.gr Message-id: <9505240713.AA21937@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 1655 > I think that if gcc is used to produce ixemul.library using executables, > then the default should be to have stack extension on, and you have to > give it an explicit -mno-stackextend or -mfixedstack option to turn off > automatic stack extension. This way, the default is basically the same > as UNIX, to grow the stack invisibly as needed, and no Makefiles will > have to change to use this very valuable new feature. > > If gcc is used to produce executables that use libnix, then the default > should probably be to used a fixed stack, as is the current case. >From what Matthias Fleischer said about libnix stack extension, I gather that programs compiled with stack extension on are going to be significantly slower than programs compiled with stack extension off. On the other hand, I have the impression that apart from a few special cases (gcc and rayshade are the only ones that come readily to mind), where some amiga customization is required anyway, most unix programs should run happily on a moderate stack (e.g., 20K), so I see no reason why stack extension should be made the default. I think that we should follow the example of SAS/C, and make stack *checking* the default, so that the few cases where a small stack is inadequate can be identified during development/porting, and the appropriate action determined on a per program basis. Do ixemul stack checking/extension include preallocating a larger stack by checking the __stack variable, a la SAS/C / libnix? -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Work for? I don't work for anybody. I'm just having fun!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed May 24 14:46:16 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89958-4>; Wed, 24 May 1995 14:44:55 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id MAA06232 for ; Wed, 24 May 1995 12:44:05 +0100 From: Lars Hecking Message-Id: <199505241146.MAA12499@mostar.nmrc.ucc.ie> Subject: VMM To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Wed, 24 May 1995 12:46:01 +0100 (BST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 223 Hi all Could everybody who uses VMM with gcc _and_ has a fairly stable system email me their VMM configs? I'm updating the gcc part of the AmigaFAQ. Thanks, Lars -- WindowError:004 Erronious error. Nothing wrong. From amiga-gcc-port-owner@nic.funet.fi Wed May 24 14:47:23 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <90903-2>; Wed, 24 May 1995 14:46:55 +0300 Received: from freenet-a.fim.uni-erlangen.de by uni-erlangen.de with SMTP; id AA28026 (5.65c-7/7.3w-FAU); Wed, 24 May 1995 13:46:50 +0200 Received: by fim.uni-erlangen.de; id AA29099 (4.1/7.3r-FAU); Wed, 24 May 95 13:45:36 +0200 Date: Wed, 24 May 95 13:45:36 +0200 Message-Id: <9505241145.AA29099@freenet-a.fim.uni-erlangen.de> From: cu154@fim.uni-erlangen.de (Federico Di Gregorio) To: amiga-gcc-port@lists.funet.fi Subject: porting libobj-0.1.10 Reply-To: cu154@fim.uni-erlangen.de Hello Philippe, I am having some problems porting libobj-0.1.10 (std GNU Objective C library) on the amiga. Last version (i.e., 0.1.10) requires the rebuilding of GCC applying some patches (included in the distribution) to make the Object class more NeXTStep compatible and some other little changes. I *don't* have the disk space nor the time to recompile GCC! :( Can you add the patches to the next version of GCC. I think will make little difference to std users and is very important to have a std library for ObjC programmers. Thank you very much, Federico -- *-=< Federico Di Gregorio cu154@fim.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Wed May 24 18:00:42 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90488-3>; Wed, 24 May 1995 17:59:04 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sEIgI-0004nYC; Wed, 24 May 95 08:49 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: default stack options To: kyrimis@theseas.ntua.gr Date: Wed, 24 May 1995 08:49:10 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <9505240713.AA21937@hpcl.cti.gr> from "Kriton Kyrimis" at May 24, 95 10:13:27 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1525 >From what Matthias Fleischer said about libnix stack extension, I gather that > programs compiled with stack extension on are going to be significantly > slower than programs compiled with stack extension off. >From the numbers I've seen, except for the special case of variable sized arrays (a gcc extension), the overhead difference between stack checking and stack extension is not very much. The big jump comes between using a fixed stack and stack checking. Stack extension only adds a marginal amount of additional overhead. > I think that we should follow the example of SAS/C, and make stack > *checking* the default, so that the few cases where a small stack is > inadequate can be identified during development/porting, and the appropriate > action determined on a per program basis. This might be acceptable. The main thing we want to avoid is the continuing trickle of complaints from people that install one of the GNU tools and then complain about it crashing or acting flaky, because they are not using enough stack. For every person that complains and eventually discovers what is wrong, there are probably ten that don't complain and just dismiss the problem as "buggy GNU junk", a perception we certainly don't want. > Do ixemul stack checking/extension include preallocating a larger stack by > checking the __stack variable, a la SAS/C / libnix? Hmm, I missed this code the first time. I just looked and there is a module that supports this. I'll look at integrating that code as well. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed May 24 18:13:25 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90631-2>; Wed, 24 May 1995 18:11:10 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26480-4>; Wed, 24 May 1995 17:10:46 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209215-2>; Wed, 24 May 1995 17:10:30 +0100 Subject: Re: default stack options From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Wed, 24 May 1995 17:10:27 +0200 (MESZ) In-Reply-To: from "Fred Fish" at May 24, 95 08:49:10 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1398 Message-Id: <95May24.171030+0100mesz.209215-2+2108@hphalle0.informatik.tu-muenchen.de> > From the numbers I've seen, except for the special case of variable sized > arrays (a gcc extension), the overhead difference between stack checking > and stack extension is not very much. The big jump comes between using > a fixed stack and stack checking. Stack extension only adds a marginal > amount of additional overhead. Sounds reasonable... I guess the only difference between "extension" and "checking" is the action takes when the "checking" part says that there isn't enough stack. > > I think that we should follow the example of SAS/C, and make stack > > *checking* the default, so that the few cases where a small stack is > > inadequate can be identified during development/porting, and the appropriate > > action determined on a per program basis. > > This might be acceptable. Well, I still prefer stack-extension as default. Apparently it doesn't make difference concerning performance, so why restrict it to putting up a requester? Esp. if the program has been running for some time, on a slow machine... Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed May 24 19:28:15 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <90247-4>; Wed, 24 May 1995 19:27:24 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA05401 (5.65c8/IDA-1.4.4 for ); Wed, 24 May 1995 18:27:06 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA06845; Wed, 24 May 95 18:27:06 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9505241627.AA06845@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: default stack options To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Wed, 24 May 1995 18:27:05 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95May24.171030+0100mesz.209215-2+2108@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at May 24, 95 05:10:27 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 750 > > Sounds reasonable... I guess the only difference between "extension" > and "checking" is the action takes when the "checking" part says that > there isn't enough stack. > Well, almost. There's one minor difference more :-). Because stackchecking works on only one stackframe you need only code for checking. stackextension works with multiple stackframes - therefore a cleanup is necessary to fall back to an old stackframe in a fully system compliant manner (StackSwap). Under certain circumstances (when using alloca or variable sized arrays) this cleanup has even to be called explicitly by inserting code to do so. That's why code compiled with stackextend uses a different amount of memory than code compiled with stackchecking. Matthias From amiga-gcc-port-owner@nic.funet.fi Wed May 24 22:36:41 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90247-2>; Wed, 24 May 1995 22:35:06 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sEMAw-000FbGC; Wed, 24 May 95 21:33 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07n7@wyst.hobby.nl>; Wed, 24 May 95 21:31:26 CET Message-Id: <9505242031.07n7@wyst.hobby.nl> Date: Wed, 24 May 1995 21:31:24 +0000 (CET) Content-Type: text Content-Length: 2721 From: hans@wyst.hobby.nl (Hans Verkuil) To: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi Subject: pdksh-4.9 bug report & fix While working on my Emacs port I stumble over the following pdksh-4.9 bug: given a file 'x' with contents: echo tt | (cat | cat) and then running 'sh x' will output a line 'tt' and after that it gets stuck in a loop: CPU usage goes to 100% and nothing else happens. The bug happens whenever you pipe something into a pipeline grouped by parentheses. The fix consists of two diffs: the first one fixes the first halve of the bug in jobs.c: --------- cut here ---------- *** jobs.c Tue May 23 23:00:47 1995 --- ../sh/jobs.c Tue May 23 23:03:56 1995 *************** *** 515,519 **** #ifdef amigados /* don't need them, and don't own them, so toss them ;-)) */ ! procs = 0; #else for (j = procs; j != NULL; j = j->next) --- 515,519 ---- #ifdef amigados /* don't need them, and don't own them, so toss them ;-)) */ ! procs = j_lastj = 0; #else for (j = procs; j != NULL; j = j->next) --------- cut here ---------- In the newly created process the pointer procs is reset, but the pointer j_lastj (which points to an item within the same list procs points to) was not reset. This caused a process to wait until it would receive a SIGCHLD signal (i.e. a 'process has died' signal). Which obviously would never happen :-). After fixing this, I suddenly got EMT Traps (illegal instructions). After more debugging I found out that a vfork-ed process would return to the original spawner! Something that may NEVER happen. The problem was in an 'if' condition in exec.c. I compared this with the latest version of pdksh (5.1.3) and found out that the condition was changed in that version, so I put it into 4.9. Everything seems to work fine now, but more testing would be nice (use it for configuring and building the GNU tree?). Here is the patch to exec.c: --------- cut here ---------- *** exec.c Tue May 23 23:00:42 1995 --- ../sh/exec.c Tue May 23 22:59:00 1995 *************** *** 292,296 **** fflush(shf[2]); } ! if ((flags&XEXEC) && !(flags&XPIPEI)) exit(rv); /* exit child */ return rv; --- 292,296 ---- fflush(shf[2]); } ! if (flags&XEXEC) exit(rv); /* exit child */ return rv; --------- cut here ---------- Who is (actively) working on pdksh-5.1.3? I get the impression that the new version is substantially improved, so it would be nice to have a port of that version to replace 4.9. Note that the patch to jobs.c might also apply to 5.1.3. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu May 25 00:22:01 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90764-2>; Thu, 25 May 1995 00:20:02 +0300 Received: from funet.fi by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HQW7JDWPTS00305Y@FIPORT.FUNET.FI>; Wed, 24 May 1995 20:34:31 +0200 (EET) Received: from bastion.nmrc.ucc.ie (actually host nmrc.ucc.ie) by funet.fi with SMTP (PP); Wed, 24 May 1995 23:32:39 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id VAA11345; Wed, 24 May 1995 21:30:17 +0100 Date: Wed, 24 May 1995 21:32:14 +0100 (BST) From: Lars Hecking Subject: Re: pdksh-4.9 bug report & fix In-reply-to: <9505242031.07n7@wyst.hobby.nl> from "Hans Verkuil" at May 24, 95 09:31:24 pm To: hans@wyst.hobby.nl (Hans Verkuil) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Message-id: <199505242032.VAA13207@mostar.nmrc.ucc.ie> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL24] Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit Content-length: 693 > put it into 4.9. Everything seems to work fine now, but more testing would > be nice (use it for configuring and building the GNU tree?). I'll keep you posted. > Who is (actively) working on pdksh-5.1.3? I get the impression that the new > version is substantially improved, so it would be nice to have a port of > that version to replace 4.9. Note that the patch to jobs.c might also > apply to 5.1.3. I hope nobody is working on 5.1.3!! 5.2.0 has been out for while now ;-) I'm stuck with either version and my attempt on bash shows the same symptoms :( (I have created an entry for amigados in machines.h, if anybody wants to give it a go ;). And I have exams :( Slan, Lars From amiga-gcc-port-owner@nic.funet.fi Thu May 25 11:15:16 1995 Received: from nickel.ucs.indiana.edu ([129.79.10.5]) by nic.funet.fi with SMTP id <90116-2>; Thu, 25 May 1995 11:07:05 +0300 Received: by nickel.ucs.indiana.edu (5.65c+/10jsm) id AA23876; Thu, 25 May 1995 03:06:52 -0500 From: That One Bad Apple Subject: FAQ "reasonably done" To: amiga-gcc-port@nic.funet.fi Date: Thu, 25 May 1995 03:06:51 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2177 Message-Id: <95May25.110705+0300_eet_dst.90116-2+12@nic.funet.fi> As the subject says, the FAQ is "reasonably done." I incorporated as many of the suggestions/answers as I could remember. Notably missing: Anything significant about g++ or Objective C compiler. The whereabouts of Walter Harms examples. The list of ports and people doing the porting (many of whom are on this list, I'd wager). The Amitcp section is pretty dry, and I think there's probably more that should be included. Particularly good enhancement: I reformatted the section,subsection and subsubsection titles to make them more noticeable, and preceded them all with [#<.#<.#>>] so that people could search for, say, section 9 with [9], or 2 (b)(iii) with [2.b.iii]. Thanks to Joerg for that suggestion. I also cleaned out the "What else" parts (I think I got them all) and replaced requests for more information with "[under construction]". Now, since it was so long, I am not including it here (now 80K). Instead, I uploaded it to Phillipe's site, ftp.telesys-innov.fr, as Amiga-GCC-FAQ.txt. It should be appearing in /pub/amigados-gnu/beta whenever Phillipe gets my mail and puts it there (probably later today). Anyone who wants to rewrite an answer may do so, in order to make it more cogent. I'd prefer single well-written answers to the current method of pasting together old mails, but I don't really know the answers well enough to do the rewrites myself. So what you should do, is cut out the section, removing the current answer, and mail the rewritten section to this list, so that it may be looked over. After some period of time (say a week?) I will incorporate it, with corrections, into the FAQ. Eventually I will get around to texi-ing the FAQ. This version will be more complete, in some respects, as I won't be worrying about bandwidth as much. For example, I will probably include the entire GNU Manifesto and GPL, instead of only parts of them. But this version, as it stands, should be enough to let Joe Novice start using GCC without flooding the net with questions... Lynn P.S. Thanks to all who provided the answers in e-mail in the first place, and to those who made corrections and additions to my original text. From amiga-gcc-port-owner@nic.funet.fi Thu May 25 11:37:54 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <90711-4>; Thu, 25 May 1995 11:30:59 +0300 Received: from freenet-a.fim.uni-erlangen.de by uni-erlangen.de with SMTP; id AA25803 (5.65c-7/7.3w-FAU); Thu, 25 May 1995 10:30:52 +0200 Received: by fim.uni-erlangen.de; id AA15444 (4.1/7.3r-FAU); Thu, 25 May 95 10:29:37 +0200 Date: Thu, 25 May 95 10:29:37 +0200 Message-Id: <9505250829.AA15444@freenet-a.fim.uni-erlangen.de> From: cu154@fim.uni-erlangen.de (Federico Di Gregorio) To: owinebar@nickel.ucs.indiana.edu Subject: Re: FAQ "reasonably done" Cc: amiga-gcc-port@lists.funet.fi Reply-To: cu154@fim.uni-erlangen.de >Notably missing: > > Anything significant about g++ or Objective C compiler. About ObjC, if you want to know somrthing specific, just ask... else just wait some days, I'll try to put something togheter. (i.e., how to use ObjC and BOOPSI without conflict, the std GNU ObjC library, etc...) Hope I can help, Federico -- *-=< Federico Di Gregorio cu154@fim.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Thu May 25 16:31:22 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90065-3>; Thu, 25 May 1995 16:29:50 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 25 May 95 15:29 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 25 May 95 15:25 MET DST Message-Id: Subject: Alpha-tester for debug.lib , where ? To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 25 May 1995 15:25:11 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 541 the basics of the debug.lib are ready now but because my amiga is ooo. i need a tester. requierements: 1 amiga and a second computer on the serport (only Kdebug support yet) capable of writing his own prg's using kprintf,..... voluntiers ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Thu May 25 17:51:28 1995 Received: from inesc.inesc.pt ([146.193.0.1]) by nic.funet.fi with SMTP id <90184-1>; Thu, 25 May 1995 17:50:31 +0300 Received: from laura.inesc.pt by inesc.inesc.pt with SMTP; id AB23992 (/); Thu, 25 May 1995 16:49:50 +0200 Message-Id: <199505251449.AB23992@inesc.inesc.pt> Received: by laura.inesc.pt (1.38.193.4/16.2) id AA17049; Thu, 25 May 1995 16:44:17 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Pedro Miguel S.J.Teixeira ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Subject: Re: patch ixemul for TCP/IP From: To: amiga-gcc-port@nic.funet.fi Date: Thu, 25 May 95 16:44:16 METDST Mailer: Elm [revision: 70.85] > What about creating a kind of patch to ixemul.library to redefine level 1 > I/O functions (using exec's SetFunction()) in order to handle sockets. Do you think a patch is even close to a decent final product? > Several patches could be released for the different TCP/IP stacks. > This kind of patching suppose that inner functions in ixemul.library > access level 1 I/O functions through a unique address (no several calls > possible for the same function, you see what I mean ?) > Adding features to handle AmiTCP/IP doesn't mean to include TCP/IP. > ixemul.library would be an interface to access bsdsocket.library, That's what i've been saying all along, but not through patches! For instance, once read() function is called, if it consernes sockets it will simply call recv() function on bsdsocket.library. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Thu May 25 20:08:07 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <90921-2>; Thu, 25 May 1995 20:07:16 +0300 Received: by disperse.demon.co.uk id ad26059; 25 May 95 17:45 +0100 Received: from post.demon.co.uk by disperse.demon.co.uk id aa22345; 25 May 95 16:36 +0100 Received: from [158.152.38.226] by post.demon.co.uk id ah14116; 25 May 95 16:36 +0100 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA002ei; Thu, 25 May 95 15:51:22 GMT Date: Thu, 25 May 95 15:51:22 GMT Message-Id: <9505251551.AA002eh@flevel.demon.co.uk> Message-Id: <20b86879.3a980-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: C++ Class library docs? Where do I get some docs for the C++ Class library (Things like String etc.) Thanks, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu May 25 23:45:11 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90921-2>; Thu, 25 May 1995 23:43:16 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sEkUE-0004nYC; Thu, 25 May 95 14:30 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: as and ld working together To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Thu, 25 May 1995 14:30:34 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9505181605.AA08411@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at May 18, 95 06:05:09 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 609 > the old ld couldn't deal with. I don't know what the current state of > ld is, but as we all want to see a clean and beautiful GCC-2.7.0, we > should clean this up. Last night I was able to link and run an executable (pdksh) compiled with the latest beta version of gcc, the ixemul.library (plus new crt0.o and libc.a) that I'm working on, and the binutils assembler with fixes installed for the relocation problem. Note I'm still using the older non-bfd based linker because the bfd based one doesn't yet understand "linker flavors". So the gcc 2.7 release should have working -resident support. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri May 26 00:30:45 1995 Received: from nickel.ucs.indiana.edu ([129.79.10.5]) by nic.funet.fi with SMTP id <90688-2>; Fri, 26 May 1995 00:29:52 +0300 Received: by nickel.ucs.indiana.edu (5.65c+/10jsm) id AA21072; Thu, 25 May 1995 16:29:22 -0500 From: That One Bad Apple Subject: Old file at prep.ai.mit.edu need updating To: amiga-gcc-port@nic.funet.fi Date: Thu, 25 May 1995 16:29:21 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3034 Message-Id: <95May26.002952+0300_eet_dst.90688-2+1@nic.funet.fi> Hi all, Enclosed is a file at prep.ai.mit.edu in /pub/gnu/MicrosPorts called Amiga.txt or something close to that. I noticed it was still there while grabbing the GNUmanifesto. (I noticed it last year while browsing the site). It's OLD. Someone should update it, cause the sites listed are probably gone by now (other than ftp.funet.fi, of course). ---------------------------------------------------------------- GNU Software on the Amiga last updated 27 May 91 ^^^^^^^^^^^^^^^^^^^^^^ by Leonard Norrgard Ports to the Amiga of the GNU C compiler (GCC) and related tools can be anonymously ftped from various archives, listed below. Work is currently in progress which eventually will lead to a merge with the official GCC distribution (this is possible due to the very few changes needed). GNU Emacs is also available in early versions, with a new release said to appear soon. Note that Commodore-Amiga independently makes some ports available for use under Amiga Unix (System V, Release 4), notably GCC, which is now the default compiler for Amiga Unix, and GNU Emacs. These ports are included with their software distribution. The porting team for GCC maintains a mailing list based on the machine lists.funet.fi in Finland. The low-volume list primarily discuss technical issues of the current and future ports and related matters. For information on how to subscribe, send a e-mail message with a contents of the words HELP and LIST on two separate lines... HELP LIST ...to the address mailserv@lists.funet.fi and you will receive the information. In the answer to HELP, look for the ``subscribe'' command. In the answer to LIST look for ``amiga-gcc-port''. The subject line of the message is ignored. Mailserv is an automated mail message handler, so don't expect it to answer questions. For information on mailserv itself, contact Matti Aarnio . For further information on the GCC port and related projects subscribe to the amiga-gcc-port mailing list as described above or write to Leonard Norrgard . For further information on GNU Emacs for the Amiga, write to Mark D. Henning . I'd like to thank Markus Wild, Ray Burr and Sam Rushing who all have contributed and continues to contribute to this project in a major way. Thanks! FTP sources for Amiga ports of GNU software: In Europe: ftp.funet.fi (128.214.6.100): ~pub/amiga/gnu and subdirectories. Log in with user name "ftp", enter your full e-mail address as password. In the USA: titan.ksc.nasa.gov (128.159.4.20, 128.159.1.1): ~pub/amiga and subdirectories. Note: Titan is a VMS machine. Log in with user name "anonymous", enter your user id as password. Once logged in change directory with "cd amiga", etc. Also in the USA: karazm.math.uh.edu (129.7.7.6): ~pub/Amiga/Gnu and subdirectories (note the capital letters) Log in with user name "ftp", enter your user id as password. Use only after 5pm and before 9am CST, please. From amiga-gcc-port-owner@nic.funet.fi Fri May 26 02:45:13 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90618-1>; Fri, 26 May 1995 02:43:39 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sEnM8-0004nYC; Thu, 25 May 95 17:34 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: the m68k PC relative patch to gas To: vinsci@nic.funet.fi (Leonard Norrgard) Date: Thu, 25 May 1995 17:34:24 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi, gas@cygnus.com, vinsci@nic.funet.fi In-Reply-To: <95May22.182045+0300_eet_dst.90050-3+31@nic.funet.fi> from "Leonard Norrgard" at May 22, 95 06:20:44 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 559 > Can someone mail me the diffs to m68k gas that made it accept code > like: > lea pc@(Lget_sr),a0 > > instead of: > > lea pc@(Lget_sr-.+2), a0 > > in order to load the address of a label without a generating a reloc. It's a hack, but I've discovered that the code: jmp pc@(_ENTRY-.+2) _ENTRY: nop when compiled by gas 1.38 produces the same object file as the code: jmp pc@(_ENTRY+8:W) _ENTRY: nop when compiled with binutils gas. This might give some clues as to where to look in the binutils gas for how to eliminate the +8 bias. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri May 26 11:21:50 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <89945-1>; Fri, 26 May 1995 11:18:59 +0300 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id KAA27014 (8.6.12/7.4b-FAU);; Fri, 26 May 1995 10:18:49 +0200 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA28673; Fri, 26 May 1995 10:18:44 +0200 Date: Fri, 26 May 1995 10:18:44 +0200 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9505260818.AA28673@pctc.chemie.uni-erlangen.de> To: fleischr@izfm.uni-stuttgart.de Cc: stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <9505241627.AA06845@sunserv.IZFM.Uni-Stuttgart.DE> (fleischr@izfm.uni-stuttgart.de) Subject: Re: default stack options Hello ! What do you think about a message to the user of a program if stack extension is done. Perhaps the old and the new stack size too. Then a possible user may be informed about a too small stack. Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Fri May 26 13:01:12 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90215-1>; Fri, 26 May 1995 13:00:06 +0300 Received: from disperse.demon.co.uk by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HQYDZ04JOG0038CY@FIPORT.FUNET.FI>; Fri, 26 May 1995 10:00:34 +0200 (EET) Received: from post.demon.co.uk by disperse.demon.co.uk id ba03875; 26 May 95 10:45 +0100 Received: from flevel.demon.co.uk by post.demon.co.uk id ac27627; 26 May 95 9:45 +0100 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA002my; Fri, 26 May 95 09:33:21 GMT Date: Fri, 26 May 1995 09:33:21 +0000 (GMT) From: dev@flevel.demon.co.uk Subject: Re: C++ Class library docs? In-reply-to: <199505251756.SAA14428@mostar.nmrc.ucc.ie> (from Lars Hecking ) (at Thu, 25 May 1995 18:56:21 +0100 (BST)) To: lhecking@nmrc.ucc.ie Cc: amiga-gcc-port@nic.funet.fi Message-id: <9505260933.AA002mx@flevel.demon.co.uk> Message-id: <20b96160.222e1-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: Content-transfer-encoding: 7BIT Hi Lars, > > Where do I get some docs for the C++ Class library (Things like String etc.) > > If you mean libg++.a, it's all in the texinfo/info files which come > with the source distrib. I can email you the lot (libg++.texi and > lgpl.texinfo) if you like. Ah, that would explain it. I don't use tex and so I didn't download to docs in tex format. I don't suppose they are available in ascii? I do have tex install but I never worked out how to print things from it. I guess I haven't really put any effort into it. Thanks, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri May 26 13:39:05 1995 Received: by nic.funet.fi id <90256-2>; Fri, 26 May 1995 13:37:15 +0300 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: findhit Message-Id: <95May26.133715+0300_eet_dst.90256-2+13@nic.funet.fi> Date: Fri, 26 May 1995 13:37:13 +0300 Mike Sinz' own original source code for the FindHit program is now available in /pub/amiga/gnu/beta/findhit.c on ftp.funet.fi. Thanks go to Mike, of course, and Laurent Papier for mailing it! This version doesn't yet support amiga gcc. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Fri May 26 15:05:02 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <90306-3>; Fri, 26 May 1995 15:03:49 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa09902; 26 May 95 12:31 +0100 Received: from flevel.demon.co.uk by post.demon.co.uk id ab24453; 26 May 95 12:30 +0100 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA002nn; Fri, 26 May 95 10:01:27 GMT Date: Fri, 26 May 95 10:01:27 GMT Message-Id: <9505261001.AA002nm@flevel.demon.co.uk> Message-Id: <20b967f5.927c0-dev@flevel.demon.co.uk> In-Reply-To: <9505260818.AA28673@pctc.chemie.uni-erlangen.de> (from Thomas Walter ) (at Fri, 26 May 1995 10:18:44 +0200) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: walter@pctc.chemie.uni-erlangen.de Cc: stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi, fleischr@izfm.uni-stuttgart.de Subject: Re: default stack options Hi Thomas, > What do you think about a message to the user of a program if stack extension > is done. Perhaps the old and the new stack size too. Then a possible user may > be informed about a too small stack. Sounds nice in theory but where would you send the message? It can't go to stdout because that may be piped to a file. It can't go to stderr because the programmer might not have re-directed it and it might go to stdout messing up an output file. It can't go to a requester because it may be running as a batch. See what I mean? Cheers, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri May 26 15:27:44 1995 Received: from imada.ou.dk ([130.225.128.15]) by nic.funet.fi with SMTP id <90148-2>; Fri, 26 May 1995 15:26:17 +0300 Received: from langgaard.ou.dk (langgaard.imada.ou.dk) by imada.ou.dk with SMTP id AA24593 (5.65c8/IDA-1.4.4 for ); Fri, 26 May 1995 14:26:13 +0200 From: Anders Hybertz Message-Id: <199505261226.AA24593@imada.ou.dk> Subject: unsubscribe To: amiga-gcc-port@nic.funet.fi Date: Fri, 26 May 1995 14:26:12 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 46 X-Charset: ASCII X-Char-Esc: 29 unsubscribe amiga-gcc-port jeckyl@imada.ou.dk From amiga-gcc-port-owner@nic.funet.fi Fri May 26 15:43:53 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90251-1>; Fri, 26 May 1995 15:42:48 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sEzUk-0004nYC; Fri, 26 May 95 06:32 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: default stack options To: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Date: Fri, 26 May 1995 06:32:06 -0700 (MST) Cc: fleischr@izfm.uni-stuttgart.de, stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <9505260818.AA28673@pctc.chemie.uni-erlangen.de> from "Thomas Walter" at May 26, 95 10:18:44 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1839 > What do you think about a message to the user of a program if stack extension > is done. Perhaps the old and the new stack size too. Then a possible user may > be informed about a too small stack. I think it might be useful to include the capability of collecting data about stack extensions. However this should not be the default behavior. It should probably work somewhat like profiling works in a traditional UNIX environment for programs compiled with the -p option. I.E. the data is collected at runtime, and when the program exits, it is written to a file. A specialized program then interprets this data and presents it in an easy to understand format. For stack monitoring it would be useful to at least know the number of extensions needed, the sizes of the extensions, and where the extensions were required. Can anyone suggest any other useful information to collect. Off the top of my head, one way to control whether or not stack monitoring is enabled is to look at startup at the value of some variable, say "__stackmon". If the variable is not NULL, then it is taken as the name of the file to write at exit. If the variable is NULL, no stack monitoring is done. The default value would be NULL and there would be an object file in libc.a that contains the variable. To enable stack monitoring, you would just link with your own object file that defines the variable to the file name you want to use. Another option would be to make enabling and disabling this feature an ixconfig option, and have ixemul.library handling the gathering of the data (once the stack extension code is part of ixemul.library). This way you could gather stack information about any (and all) programs using ixemul.library with no changes at all to any particular executable, once it was recompiled with the new compiler. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri May 26 15:47:59 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90215-4>; Fri, 26 May 1995 15:47:34 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May26.154734+0300_eet_dst.90215-4+20@nic.funet.fi> From: To: Date: Fri, 26 May 1995 15:47:28 +0300 Date: Fri, 26 May 1995 14:49:09 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Shell (GNU:bin/sh) bug question Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject : Shell (GNU:bin/sh) bug question These has been a lot of talk recently on this mailling list about bug-fixes to (the port of) pdksh. Is that the shell found in GNU:bin/sh? Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Fri May 26 15:52:09 1995 Received: from afrodite.kih.no ([158.36.9.69]) by nic.funet.fi with ESMTP id <90944-3>; Fri, 26 May 1995 15:51:51 +0300 Received: by afrodite.kih.no (1.37.109.16/16.2) id AA206602571; Fri, 26 May 1995 14:49:31 +0200 Date: Fri, 26 May 1995 14:49:30 +0200 (METDST) From: Erik Johannessen To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: your mail In-Reply-To: <95May26.154734+0300_eet_dst.90215-4+20@nic.funet.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 26 May 1995 gc948374@gbar.dtu.dk wrote: > These has been a lot of talk recently on this mailling list about > bug-fixes to (the port of) pdksh. Is that the shell found in GNU:bin/sh? Yes. -Erik -- erik2@afrodite.kih.no http://afrodite.kih.no:8001/~erik2 From amiga-gcc-port-owner@nic.funet.fi Fri May 26 16:02:24 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89945-4>; Fri, 26 May 1995 16:01:27 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sEzoA-0004nYC; Fri, 26 May 95 06:52 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Fri, 26 May 1995 06:52:09 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95May26.154734+0300_eet_dst.90215-4+20@nic.funet.fi> from "gc948374@gbar.dtu.dk" at May 26, 95 03:47:28 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 157 > These has been a lot of talk recently on this mailling list about > bug-fixes to (the port of) pdksh. Is that the shell found in GNU:bin/sh? Yes. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri May 26 16:20:56 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <89982-2>; Fri, 26 May 1995 16:19:50 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA23290 (5.65c8/IDA-1.4.4 for ); Fri, 26 May 1995 15:15:54 +0200 Received: from sunserv2.izfm.uni-stuttgart.de by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA07689; Fri, 26 May 95 15:15:53 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9505261315.AA07689@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: default stack options To: fnf@amigalib.com (Fred Fish) Date: Fri, 26 May 1995 15:12:39 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Fred Fish" at May 26, 95 06:32:06 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1219 > > I think it might be useful to include the capability of collecting > data about stack extensions. However this should not be the default > behavior. > Sounds like a promising idea to me. > > Another option would be to make enabling and disabling this feature an > ixconfig option, and have ixemul.library handling the gathering of the > data (once the stack extension code is part of ixemul.library). This > way you could gather stack information about any (and all) programs > using ixemul.library with no changes at all to any particular > executable, once it was recompiled with the new compiler. > Another possibility is to control it with an external tool similar to one of the latest amiga profilers (can't remember the name - was it AProf?). This profiler sets breakpoints at all function entries (you need unstripped executables to use it) to get the desired information. To do the same thing for stackextension some breakpoints at the small set of stackextending functions in the library would suffice. Additionally the code used to start the subtask and to set/reset the breakpoints and trap handler would be a first step to a fully working AmigaOS gdb :-). (Or am I too optimistic here?) Matthias From amiga-gcc-port-owner@nic.funet.fi Fri May 26 16:22:15 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <90637-1>; Fri, 26 May 1995 16:21:45 +0300 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id PAA00213 (8.6.12/7.4b-FAU);; Fri, 26 May 1995 15:21:32 +0200 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA19549; Fri, 26 May 1995 15:21:28 +0200 Date: Fri, 26 May 1995 15:21:28 +0200 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9505261321.AA19549@pctc.chemie.uni-erlangen.de> To: dev@flevel.demon.co.uk Cc: stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi, fleischr@izfm.uni-stuttgart.de In-Reply-To: <9505261001.AA002nm@flevel.demon.co.uk> (dev@flevel.demon.co.uk) Subject: Re: default stack options Hi Trefor S. I don't understand exactly what you mean if you say it cannot go to a requester because it may be a batch .... The stack extension is used by a program which wants to do it. And this may display a requster like SAS/C does if it informs about to less stack. But may be I'm wrong ?!?! Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Fri May 26 16:45:06 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90310-2>; Fri, 26 May 1995 16:44:34 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sF0TC-0004nYC; Fri, 26 May 95 07:34 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: default stack options To: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Date: Fri, 26 May 1995 07:34:34 -0700 (MST) Cc: dev@flevel.demon.co.uk, stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi, fleischr@izfm.uni-stuttgart.de In-Reply-To: <9505261321.AA19549@pctc.chemie.uni-erlangen.de> from "Thomas Walter" at May 26, 95 03:21:28 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1187 > I don't understand exactly what you mean if you say > it cannot go to a requester because it may be a batch .... > > The stack extension is used by a program which wants to do it. And this > may display a requster like SAS/C does if it informs about to less stack. Part of the point of doing automatic stack extension is so that you will never be bothered by any stack problems. Stack will just be silently allocated as necessary, assuming you have memory available. This way you can start large "batch jobs" running and go away, with a reasonable assurance you won't come back several hours later to find out your job stopped 10 minutes after you left with a requestor that nobody was around to notice and dismiss. Recompiling the entire GNU tree takes almost two days on my 40 Mhz WarpEngine machine. Right now I have to set my stack at 800,000 to ensure that everything that gets run gets enough stack. I think compiling octave is the largest stack consumer in this batch job. If I had to worry about stack usage requestors coming up during the run, I'd either have to never leave my machine for more than a few minutes, or else continue to set my stack at 800,000. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri May 26 18:35:39 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90508-4>; Fri, 26 May 1995 18:31:28 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26584-3>; Fri, 26 May 1995 17:31:11 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209235-1>; Fri, 26 May 1995 17:31:02 +0100 Subject: Re: default stack options From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 26 May 1995 17:31:00 +0200 (MESZ) In-Reply-To: <9505260818.AA28673@pctc.chemie.uni-erlangen.de> from "Thomas Walter" at May 26, 95 10:18:44 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 800 Message-Id: <95May26.173102+0100mesz.209235-1+3749@hphalle0.informatik.tu-muenchen.de> > What do you think about a message to the user of a program if stack extension > is done. Perhaps the old and the new stack size too. Then a possible user may > be informed about a too small stack. No. If ixemul has an option to turn that one, it's okay. But not as default. We don't want to output stuff like "stack extended", "malloc() failed", "open() failed" etc. except, maybe, for debugging. The user doesn't care about that. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Fri May 26 18:52:29 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90642-1>; Fri, 26 May 1995 18:49:20 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26498-2>; Fri, 26 May 1995 17:48:57 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209235-1>; Fri, 26 May 1995 17:48:44 +0100 Subject: Re: C++ Class library docs? From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 26 May 1995 17:48:37 +0200 (MESZ) In-Reply-To: <20b96160.222e1-dev@flevel.demon.co.uk> from "dev@flevel.demon.co.uk" at May 26, 95 09:33:21 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 779 Message-Id: <95May26.174844+0100mesz.209235-1+3754@hphalle0.informatik.tu-muenchen.de> > > If you mean libg++.a, it's all in the texinfo/info files which come > > with the source distrib. I can email you the lot (libg++.texi and > > lgpl.texinfo) if you like. > > Ah, that would explain it. I don't use tex and so I didn't download to > docs in tex format. > > I don't suppose they are available in ascii? Use makeinfo -- the Amiga port can produce pure ASCII as well as AmigaGuide documents. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Fri May 26 19:17:55 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <90510-2>; Fri, 26 May 1995 19:16:54 +0300 Received: by ceylon.informatik.uni-rostock.de id SAA16782; Fri, 26 May 1995 18:16:50 +0200 Received: by honshu.informatik.uni-rostock.de id SAA04742; Fri, 26 May 1995 18:16:49 +0200 From: Gunther Nikl Message-Id: <199505261616.SAA04742@honshu.informatik.uni-rostock.de> Subject: structure padding :-/ To: amiga-gcc-port@nic.funet.fi Date: Fri, 26 May 1995 18:16:48 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 802 Hello! Consider the following structure definiton: struct ColorRegisters { UBYTE red; UBYTE green; UBYTE blue; } What would one expect a "sizeof(struct ColorRegister)" to return? Well, with gcc the result is 4 and not 3 :-(. Apparently gcc pads the structure to a word boundary. As long as you compile all sources with gcc, you will never have any problems, but if one has to use code compiled with an other compiler this will break. I stumbled over this "feature" incrementing a pointer to an array of the above structure with p++. It took me some days to find the bug in my program (a bmp.datatype). Question: Is it possible to prevent gcc from padding structures? I solved my problem using a pointer to an array of UBYTEs and incrementing this pointer by 3. Gunther From amiga-gcc-port-owner@nic.funet.fi Fri May 26 20:03:31 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90681-3>; Fri, 26 May 1995 20:00:52 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id RAA29506; Fri, 26 May 1995 17:52:10 +0100 From: Lars Hecking Message-Id: <199505261654.RAA15301@mostar.nmrc.ucc.ie> Subject: Use and abuse of ixemul.library/vfork_resume() To: hans@wyst.hobby.nl (Hans Verkuil), fnf@cygnus.com (Fred Fish) Date: Fri, 26 May 1995 17:54:09 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1254 I am working on pdksh-5.2.2 right now and have the following problem: Markus' original fork () emulation in jobs.c/exchild() uses vfork () and vfork_resume (). In pdksh-4.5, vfork_resume () gets called at the end of some "#ifdef amigados"'d kludge (yes, that's what it is!) without any args. _But, vfork_resume () does _require an argument (u_int *copy_from_sp) to copy the contents of the parent's stack to the child's stack (presumably). So, when vfork_resume () is called w/o any args, it takes whatever random value it finds on the stack, interprets this as a pointer to the parent's stack, and copies everything until the current stack pointer inside vfork_resume () is reached: vfork_resume (u_int *copy_from_sp) { .. u_int *copy_till_sp = (u_int *)get_sp(); /* basically, this gets A7; lh */ .. do *--sp = *--copy_from_sp; while (copy_from_sp > copy_till_sp); Do I have reason to believe that this behaviour leads to memory trashing? Enforcer hits? How do I find out what to feed into vfork_resume () to make it do what it should? Hans: your KPrintF method indeed confirmed my initial suspicion that exchild () is the bad guy. See where it got me ;-) Lars -- "They answered my questions with questions ..." -- MM From amiga-gcc-port-owner@nic.funet.fi Fri May 26 20:14:44 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <90484-3>; Fri, 26 May 1995 20:13:45 +0300 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.6.12/8.6.9) id TAA08883; Fri, 26 May 1995 19:13:27 +0200 Date: Fri, 26 May 1995 19:13:27 +0200 From: Ignatios Souvatzis Message-Id: <199505261713.TAA08883@theory.cs.uni-bonn.de> To: gnikl@informatik.uni-rostock.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: Gunther Nikl's message of Fri, 26 May 1995 18:16:48 +0200 (MET DST) <199505261616.SAA04742@honshu.informatik.uni-rostock.de> Subject: structure padding :-/ X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a Date: Fri, 26 May 1995 18:16:48 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 802 Hello! Consider the following structure definiton: struct ColorRegisters { UBYTE red; UBYTE green; UBYTE blue; } What would one expect a "sizeof(struct ColorRegister)" to return? Well, with gcc the result is 4 and not 3 :-(. Apparently gcc pads the structure to a word boundary. As long as you compile all sources with gcc, you will never have any problems, but if one has to use code compiled with an other compiler this will break. I stumbled over this "feature" incrementing a pointer to an array of the above structure with p++. It took me some days to find the bug in my program (a bmp.datatype). Question: Is it possible to prevent gcc from padding structures? I solved my problem using a pointer to an array of UBYTEs and incrementing this pointer by 3. Which is the right thing to do. The compiler is free to pad structures how it likes it, if it wants to get some alignment. If you depend on odd-sized structures being the same with all compilers, you can only access them as byte arrays. Ignatios From amiga-gcc-port-owner@nic.funet.fi Fri May 26 20:22:52 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <90578-4>; Fri, 26 May 1995 20:21:46 +0300 Received: by ceylon.informatik.uni-rostock.de id TAA16948; Fri, 26 May 1995 19:21:29 +0200 Received: by honshu.informatik.uni-rostock.de id TAA04870; Fri, 26 May 1995 19:21:29 +0200 From: Gunther Nikl Message-Id: <199505261721.TAA04870@honshu.informatik.uni-rostock.de> Subject: Re: structure padding :-/ To: ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis) Date: Fri, 26 May 1995 19:21:28 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199505261713.TAA08883@theory.cs.uni-bonn.de> from "Ignatios Souvatzis" at May 26, 95 07:13:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 560 Hi! > Question: Is it possible to prevent gcc from padding structures? > > I solved my problem using a pointer to an array of UBYTEs and incrementing > this pointer by 3. > > Which is the right thing to do. The compiler is free to pad structures > how it likes it, if it wants to get some alignment. If you depend on > odd-sized structures being the same with all compilers, you can only > access them as byte arrays. Then I have to thank C= for this "bug". Its very hard to find a problem if you have no clue where to look... Gunther From amiga-gcc-port-owner@nic.funet.fi Fri May 26 21:17:43 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90158-2>; Fri, 26 May 1995 21:16:29 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id TAA00267; Fri, 26 May 1995 19:14:05 +0100 From: Lars Hecking Message-Id: <199505261816.TAA15513@mostar.nmrc.ucc.ie> Subject: Re: structure padding :-/ To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Fri, 26 May 1995 19:16:02 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199505261616.SAA04742@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at May 26, 95 06:16:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 538 > struct ColorRegisters { > UBYTE red; > UBYTE green; > UBYTE blue; > } > > What would one expect a "sizeof(struct ColorRegister)" to return? > Well, with gcc the result is 4 and not 3 :-(. Apparently gcc pads Well, gcc on my SPARC returns "3". Of course, I do not expect you want to link some SPARC code into your program ;-) > Question: Is it possible to prevent gcc from padding structures? No. Although there is __attribute__ ((packed)), it only applies to structure fields, but not entire structures. Lars From amiga-gcc-port-owner@nic.funet.fi Fri May 26 21:21:58 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90671-2>; Fri, 26 May 1995 21:21:11 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sF4nc-0004nYC; Fri, 26 May 95 12:11 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Use and abuse of ixemul.library/vfork_resume() To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Fri, 26 May 1995 12:11:56 -0700 (MST) Cc: hans@wyst.hobby.nl, fnf@cygnus.com, amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi (none) In-Reply-To: <199505261654.RAA15301@mostar.nmrc.ucc.ie> from "Lars Hecking" at May 26, 95 05:54:09 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 799 > I am working on pdksh-5.2.2 right now and have the following problem: > Markus' original fork () emulation in jobs.c/exchild() uses vfork () and > vfork_resume (). The copy I'm running uses vfork2 (via a define of vfork to vfork2). Minor point, but I do recall this was part of a recent bug fix. > So, when vfork_resume () is called w/o any args, it takes whatever > random value it finds on the stack, interprets this as a pointer to the > parent's stack, and copies everything until the current stack pointer > inside vfork_resume () is reached: Ack! That sounds bad. I grep'd the ixemul.library source and also found a place there where vfork_resume might be called with no arguments, but it is inside an #ifdef that appears like it might actually not be used at this point. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat May 27 01:11:05 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90618-3>; Sat, 27 May 1995 01:08:41 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA20507 (5.65b/CWI-3.3); Sat, 27 May 1995 00:08:36 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sF7D2-000FadC; Fri, 26 May 95 23:46 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07p9@wyst.hobby.nl>; Fri, 26 May 95 22:23:34 CET Message-Id: <9505262123.07p9@wyst.hobby.nl> Date: Fri, 26 May 1995 22:23:31 +0000 (CET) In-Reply-To: <199505261654.RAA15301@mostar.nmrc.ucc.ie> from "Lars Hecking" at May 26, 95 05:54:09 pm Content-Type: text Content-Length: 1187 From: hans@wyst.hobby.nl (Hans Verkuil) To: lhecking@nmrc.ucc.ie Cc: amiga-gcc-port@nic.funet.fi, fnf@amigalib.com Subject: Re: Use and abuse of ixemul.library/vfork_resume() According to Lars Hecking: > > vfork_resume (u_int *copy_from_sp) > { > .. > u_int *copy_till_sp = (u_int *)get_sp(); /* basically, this gets A7; lh */ > .. > do > *--sp = *--copy_from_sp; > while (copy_from_sp > copy_till_sp); > > Do I have reason to believe that this behaviour leads to memory trashing? > Enforcer hits? How do I find out what to feed into vfork_resume () to > make it do what it should? Look more closely at vfork.c: the function you cite above is _vfork_resume(), not vfork_resume. That function is written in assembly and is found just before the _vfork() function: _vfork_resume: pea sp@ | pass the sp containing the return address bsr __vfork_resume lea sp@(4),sp rts This pushes the argument to _vfork_resume on the stack. vfork_resume itself requires no arguments. Sorry, nice theory, but you'll have to do some more digging :-) Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat May 27 12:10:23 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90852-3>; Sat, 27 May 1995 12:08:46 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA13129 (5.65b/CWI-3.3); Sat, 27 May 1995 11:08:39 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sFHXe-000FmEC; Sat, 27 May 95 10:48 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07pj@wyst.hobby.nl>; Fri, 26 May 95 23:55:27 CET Message-Id: <9505262255.07pj@wyst.hobby.nl> Date: Fri, 26 May 1995 23:55:25 +0000 (CET) Content-Type: text Content-Length: 361 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Cc: fnf@amigalib.com Subject: ixemul-40.6, purpose of 'tests' directory? Fred, What is the purpose of the 'tests' directory? Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat May 27 13:15:25 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <89984-2>; Sat, 27 May 1995 13:14:33 +0300 Received: from lysita.lysator.liu.se (lysita.lysator.liu.se [130.236.254.153]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id MAA29803; Sat, 27 May 1995 12:13:59 +0200 From: Niels M|ller Received: (nisse@localhost) by lysita.lysator.liu.se (8.6.11/8.6.11) id MAA02177; Sat, 27 May 1995 12:13:54 +0200 Date: Sat, 27 May 1995 12:13:54 +0200 Message-Id: <199505271013.MAA02177@lysita.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi In-reply-to: <95May26.174844+0100mesz.209235-1+3754@hphalle0.informatik.tu-muenchen.de> (message from Christian Stieber on Fri, 26 May 1995 17:48:37 +0200 (MESZ)) Subject: Re: C++ Class library docs? From: Christian Stieber Date: Fri, 26 May 1995 17:48:37 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII Content-Length: 779 > > If you mean libg++.a, it's all in the texinfo/info files which come > > with the source distrib. I can email you the lot (libg++.texi and > > lgpl.texinfo) if you like. > > Ah, that would explain it. I don't use tex and so I didn't download to > docs in tex format. > > I don't suppose they are available in ascii? Use makeinfo -- the Amiga port can produce pure ASCII as well as AmigaGuide documents. I'll try to make this even more clear. The docs, like most or all GNU docs, are *not* written in TeX. They are written in texinfo. This is a format that can be automatically converted into TeX for printing, and can also be converted into several flavors of hypertext, including INFO, for reading in emacs info-mode, AmigaGuide and HTML. You don't need TeX to read these manuals. You only need TeX if you want a nice paper copy. About the libg++, the AmigaGuide version of the manual *should* be included in the documentation archive distributed with the amiga gcc (I'm not *sure* it is there, as I never use C++). Something like dev/gcc/gcc-2.6.3-docs.lha on aminet. From amiga-gcc-port-owner@nic.funet.fi Sat May 27 19:35:28 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90480-3>; Sat, 27 May 1995 19:33:19 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sFPbV-0004nYC; Sat, 27 May 95 10:24 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Stack checking - system friendly? To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Sat, 27 May 1995 10:24:48 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1615 The below posting on comp.sys.amiga.programmer prompted me to ask the question about how system friendly the stack switching code in libnix is, which is the same code I'm integrating into the ixemul library. Can anyone comment on this particular issue? > Xref: news.indirect.com comp.sys.amiga.programmer:68317 > Path: news.indirect.com!news.sprintlink.net!gatech!EU.net!Germany.EU.net!news.dfn.de!fu-berlin.de!cs.tu-berlin.de!fauern!lrz-muenchen.de!iwb.mw.tu-muenchen.de!informatik.tu-muenchen.de!stieber > From: stieber@Informatik.TU-Muenchen.DE (Christian Stieber) > Newsgroups: comp.sys.amiga.programmer > Subject: Re: OS 2.04 vs 3.1 question(s) > Date: 26 May 1995 17:41:35 GMT > Organization: Technische Universitaet Muenchen, Germany > Lines: 19 > Distribution: world > Message-ID: <3q53sf$64e@hpsystem1.informatik.tu-muenchen.de> > References: <1995May26.041623.16791@zippy.dct.ac.uk> > NNTP-Posting-Host: hphalle6c.informatik.tu-muenchen.de > X-Newsreader: TIN [version 1.2 PL2] > > Bil Irving (mcscs3wji@zippy.dct.ac.uk) wrote: > > [ Stack-Switching ] > > > Umm... its relatively easy to do, but not exactly reccomended or OS friendly. > > ??? > > exec.library/StackSwap() > > Christian > > > -- > // Christian Stieber Stieber@Informatik.TU-Muenchen.de > \// Certified Amiga Developer http://www.leo.org/~stieber/ > -------------------------------------------------------------------------- > "Life starts at '030, fun starts at '040, impotence starts at '86" > keyboard not connected -- press F1 to continue > From amiga-gcc-port-owner@nic.funet.fi Sat May 27 22:07:40 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <90510-2>; Sat, 27 May 1995 22:06:34 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa17722; 27 May 95 0:20 +0100 Received: from flevel.demon.co.uk by post.demon.co.uk id ab20317; 27 May 95 0:19 +0100 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA002r3; Fri, 26 May 95 20:02:33 GMT Date: Fri, 26 May 95 20:02:33 GMT Message-Id: <9505262002.AA002r2@flevel.demon.co.uk> Message-Id: <20b9f4d7.aae61-dev@flevel.demon.co.uk> In-Reply-To: <9505261321.AA19549@pctc.chemie.uni-erlangen.de> (from Thomas Walter ) (at Fri, 26 May 1995 15:21:28 +0200) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: walter@pctc.chemie.uni-erlangen.de Cc: stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi, fleischr@izfm.uni-stuttgart.de Subject: Re: default stack options Hi Thomas, > > Hi Trefor S. > > I don't understand exactly what you mean if you say > it cannot go to a requester because it may be a batch .... If you run some commands in a batch file you may not even be at your computer to click on a requestor. I suppose it could go away after a few seconds but it would slow down the program. > The stack extension is used by a program which wants to do it. And this > may display a requster like SAS/C does if it informs about to less stack. > > But may be I'm wrong ?!?! I though we were talking about automatic stack extension here? Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Sun May 28 00:09:33 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90027-1>; Sun, 28 May 1995 00:08:15 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA03708 (5.65b/CWI-3.3); Sat, 27 May 1995 23:08:10 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sFSO6-000FblC; Sat, 27 May 95 22:23 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07pv@wyst.hobby.nl>; Sat, 27 May 95 22:14:07 CET Message-Id: <9505272114.07pv@wyst.hobby.nl> Date: Sat, 27 May 1995 22:14:05 +0000 (CET) Content-Type: text Content-Length: 3677 From: hans@wyst.hobby.nl (Hans Verkuil) To: ixemul@wyst.hobby.nl, amiga-gcc-port@nic.funet.fi Subject: Proposal to remove ixconfig options and drop Amigados globbing Hi everybody, With the upcoming release of ixemul 41 I'd say that now is the time to reorganize a few things. One of the more irritating 'features' are the multitude of options in ixconfig for translating AmigaDOS/UNIX pathnames. The current list of options in the latest version is: ixconfig [-d|-a|-c|-p|-P|-b N|-f|-i|-e|-.|-/|-l|-m N|-r N|-s|-w|-x] -d reset values to defaults -a full AmigaDOS mode, no ./ translations -c open console if no errorstream was provided -p use UNIX-style filename pattern-matching -P use case-sensitive UNIX-style filename pattern-matching -b N N physical block map into 1 logical (stdio) block -f don't accept AmigaDOS notation -i ignore global environment (ENV:) -e don't ignore global environment (ENV:) -. translate . and .. -/ translate /foo -> foo: and a//b -> a/b -l translate contents of symbolic links -m N files upto N bytes are cached in memory -r N set red zone size to N bytes. 0 disables. -s sleep, don't return. -v suppress the "Insert volume in drive" requester -w enable stack watcher -x disable stack watcher I propose to drop the following options: -d, -a, -f, -., -/, -l. A note on softlinks: the new library will write all softlinks in AmigaDOS format, and after reading a softlink will translate it to UNIX format. Currently, the -l option specifies that AmigaDOS softlinks should be translated to Unix, but as the library writes them in UNIX format, it's pretty useless. Anyway, the new library no longer supports UNIX style softlinks, which is a good thing, as AmigaDOS doesn't support them either. The library should recognize fully specified AmigaDOS filenames (i.e., they start with 'volume:'), and all other filenames are considered to be UNIX filenames. Quite reasonable, as this is after all a UNIX emulation library. If this will become the standard, then all those translation options can be dropped. Another proposal is to drop support for AmigaDOS style globbing, i.e. 'egrep f#?.c' is no longer supported, instead standard UNIX style globbing should be used: 'egrep f*.c'. Quite a lot of code went into AmigaDOS globbing, while the support for UNIX styles globbing is a lot shorter, as the library already contains a function to do just that: glob(). I would keep an option to specify how to sort the resulting filelist: case-sensitively or insensitively. That is, will 'echo ?' result in 'a B c D' or in 'B D a c'. I also think that the option -c should be dropped and always be activated. This option causes the library to open the console as errorstream if no such errorstream was provided by the shell that started the command. Without this option the errorstream is set to the stdoutstream, which is a very bad thing to do in my opinion. Finally, the remaining options should be regularized: one option to turn the feature on, another to turn it off. Please let me know what everyone thinks. If I get no feedback I assume everyone agrees and I just start work on reorganizing the options. This will be another step to making the library easier to understand and maintain. Oh, and if I do this work, I'll also write a manpage for ixconfig. A final question: is anyone using the -b, -m or -r options? If no-one is using these, then I'll consider removing these too. Otherwise, I'm interested in hearing your experiences. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sun May 28 05:32:39 1995 Received: from io.org ([142.77.27.2]) by nic.funet.fi with SMTP id <90383-4>; Sun, 28 May 1995 05:31:58 +0300 Received: from "io.org" (timper.net5b.io.org [199.166.191.38]) by io.org (8.6.12/8.6.12) with SMTP id WAA03955 for ; Sat, 27 May 1995 22:31:44 -0400 Received: by "io.org" (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sat, 27 May 95 22:31:58 From: tjhayko@timper (Tom Hayko) Message-Id: <20bb695c.da37b-tjhayko@timper> Subject: Where can I get the 2.7.0 Beta? X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Reply-To: tjhayko@io.org To: amiga-gcc-port@nic.funet.fi Date: Sat, 27 May 95 22:31:58 Is there a Beta version of GNU C 2.7.0 available? I'd like to test out some of my code with it. Is 2.7.0 going to have support for exceptions? -- Tom Hayko tjhayko@io.org From amiga-gcc-port-owner@nic.funet.fi Sun May 28 17:31:17 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <89985-2>; Sun, 28 May 1995 17:29:22 +0300 Received: from lysita.lysator.liu.se (lysita.lysator.liu.se [130.236.254.153]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id QAA12333; Sun, 28 May 1995 16:29:11 +0200 From: Niels M|ller Received: (nisse@localhost) by lysita.lysator.liu.se (8.6.11/8.6.11) id QAA15539; Sun, 28 May 1995 16:29:05 +0200 Date: Sun, 28 May 1995 16:29:05 +0200 Message-Id: <199505281429.QAA15539@lysita.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: hans@wyst.hobby.nl CC: ixemul@wyst.hobby.nl, amiga-gcc-port@nic.funet.fi In-reply-to: <9505272114.07pv@wyst.hobby.nl> (hans@wyst.hobby.nl) Subject: Re: Proposal to remove ixconfig options and drop Amigados globbing > From: hans@wyst.hobby.nl (Hans Verkuil) > > Hi everybody, > > With the upcoming release of ixemul 41 I'd say that now is the time to > reorganize a few things. A suggestion: create a cleaner, prefs-like way of setting ixemul options. One way to do this is as follows: When ixemul is loaded, it tries to FindPort("ixemul-prefs.port"). If it finds a public port with that name, it sends message(s) to that port to find out what options it should use. Then it creates a task that will handle request for changing the ixemul options and setting the bits in ixemulbase accordingly. This subtask also needs a Port, perhaps it is easiest to make it public too. When the library is flushed out of memory it must take steps to remove the child task and tell any program that is communicating with it to stop sending messages (If a public port is used, this is rather easy. Just remove the port from the list of public port, then reply to any pending messages. Then it is the config program's responsibility not to send messages when the port has disappeared). This should be rather straight forward. Then some program is needed that creates a public port as described above, and answers questions about which options to use. This is something like the ixconfig program. Now perhaps you ask what all this is good for? It makes it possible for other programs than ixconfig to tell ixemul.library which options to use, in a clean and well specified way. For example, one could write a ixprefs program that places a NotifyRequest on some file in ENV: and communicates the options to ixemul.library as needed. (Similar to the IPrefs program). Then it is possible to write a nice preferences editor that just manipulates that file. Of course, writing a gui-client for setting the options is non-trivial, and it will probably not happen immediately. But, specifying a message protocol, and creating the necessary ixemul.library code to handle that protocol, would not take too much effort, I hope. The message protocol could be very simple: struct IxOption { int option, int value }; enum IxOptionCommand { ReadOptions, WriteOptions }; /* Passed in the value field if program or library don't recognize an option */ #define IXOPTION_UNKNOWN struct IxConfigMsg { struct Message msg; enum IxOptionCommand cmd; int length; struct IxOption options[1]; /* Variable size array */ }; Alternatively ordinary TagLists could be used. Each option is represented by a unique constant number. And new options and commands can be added as needed, the library and config program(s) should simply ignore options and commands it does not know about. Once this is done, *no* program, not even ixconfig, will have to access ixemulbase directly, which have caused incompatibility problems in the past. Once the new ixconfig method is in use, the developers of ixemul.library are free to add or remove variables and options, without trouble. If the library and the config program are not of the same version, the worst thing that can happen is that the default settings are used for the options that not both the library and the config program are aware of. Just some thoughts, /Niels From amiga-gcc-port-owner@nic.funet.fi Sun May 28 21:57:12 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90276-1>; Sun, 28 May 1995 21:55:42 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Sun, 28 May 95 20:56 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Sun, 28 May 95 20:52 MET DST Message-Id: Subject: profiler To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Sun, 28 May 1995 20:52:19 +0200 (MET DST) From: Walter Harms Cc: amiga-gcc-port@lists.funet.fi (amiga gcc-list) In-Reply-To: <9505261315.AA07689@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at May 26, 95 03:12:39 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 335 great idea ! whats about a profiler for gcc ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Sun May 28 22:05:48 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90419-2>; Sun, 28 May 1995 22:04:47 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Sun, 28 May 95 21:04 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Sun, 28 May 95 21:02 MET DST Message-Id: Subject: test To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Sun, 28 May 1995 21:02:30 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 511 1. sorry for this test mail but got complains that sometime my mail arrives here in MIME format but i use plain ascii with elm. if this mail arrives in mime too please inform me. ! i would realy like to know who did it. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Mon May 29 10:26:48 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <90686-4>; Mon, 29 May 1995 10:25:01 +0300 Received: from freenet-a.fim.uni-erlangen.de by uni-erlangen.de with SMTP; id AA26519 (5.65c-7/7.3w-FAU); Mon, 29 May 1995 09:24:54 +0200 Received: by fim.uni-erlangen.de; id AA14872 (4.1/7.3r-FAU); Mon, 29 May 95 09:23:36 +0200 Date: Mon, 29 May 95 09:23:36 +0200 Message-Id: <9505290723.AA14872@freenet-a.fim.uni-erlangen.de> From: cu154@fim.uni-erlangen.de (Federico Di Gregorio) To: amiga-gcc-port@lists.funet.fi Subject: Objective C and patching GCC Reply-To: cu154@fim.uni-erlangen.de TO Philippe: Last week I posted a message to the list, nobody answered me, so I'll ask again. The GNU std ObjC library (libobjects-0.1.10) now requires to rebuild GCC applying three (3) patches... I don't have the disk space to do it, can you incorporate the partches in the next version of GCC? Thank you very much :) TO objam02 author: Great work, really! But, before working a lot on a library why don't you give a try at libobjects (alpha.gnu.ai.mit.edu/gnu/libobjects-0.1.10.tar.gz)? To the list: I think is a good idea to have ixemul do some profiling (on stack) on request. Federico -- *-=< Federico Di Gregorio cu154@fim.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Mon May 29 11:01:10 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <90239-3>; Mon, 29 May 1995 10:59:58 +0300 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id JAA21702 for ; Mon, 29 May 1995 09:57:45 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA04773; Mon, 29 May 95 09:32:44 GMT Date: Mon, 29 May 95 09:32:44 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9505290932.AA04773@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: Re: findhit > Mike Sinz' own original source code for the FindHit program is now > available in /pub/amiga/gnu/beta/findhit.c on ftp.funet.fi. > > Thanks go to Mike, of course, and Laurent Papier for mailing it! > > This version doesn't yet support amiga gcc. You can find GccFindHit.lha on Aminet in dev/gcc. After my quest for a Findhit with amiga gcc support, Daniel Verite contact me and decide to upload it on Aminet. Thanks go to Daniel, not to me ;-) \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier | Etudiant en Doctorat | Centre de Recherche en Informatique E-Mail: | Universite Louis Pasteur papier@dpt-info.u-strasbg.fr | Strasbourg - FRANCE ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Mon May 29 12:42:24 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <90468-4>; Mon, 29 May 1995 12:41:05 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA28365 (5.65c8/IDA-1.4.4 for ); Mon, 29 May 1995 11:40:52 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA09036; Mon, 29 May 95 11:40:51 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9505290940.AA09036@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Stack checking - system friendly? To: amiga-gcc-port@nic.funet.fi Date: Mon, 29 May 1995 11:40:51 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 710 > > The below posting on comp.sys.amiga.programmer prompted me to ask the > question about how system friendly the stack switching code in libnix > is, which is the same code I'm integrating into the ixemul library. > Can anyone comment on this particular issue? > > > > > exec.library/StackSwap() > > Yes, the code uses StackSwap() to switch forth and back between different stackframes - and StackSwap sets only the tc_SPLower/Upper fields and _not_ the process->pr_CLI->pr_ReturnAddr[x] fields. I _think_ that it's the legal way to use this function but I really don't know for sure. The autodocs only say 'EXEC supported'. If somebody knows more I would be interested in hearing it, too :-). Matthias From amiga-gcc-port-owner@nic.funet.fi Mon May 29 16:59:30 1995 Received: from diva.univ-mlv.fr ([193.55.44.171]) by nic.funet.fi with ESMTP id <90232-3>; Mon, 29 May 1995 16:57:59 +0300 Received: by diva.univ-mlv.fr (1.37.109.16/16.2) id AA161025775; Mon, 29 May 1995 14:56:15 +0100 From: Perret Charles Subject: Floats with Libnix To: amiga-gcc-port@nic.funet.fi Date: Mon, 29 May 1995 14:56:14 +0100 (WETDST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 405 Message-Id: <95May29.165759+0300_eet_dst.90232-3+2@nic.funet.fi> Hi! I cannot display floats with the libnix 0.9,even with the -lm option With a thing like 'printf("%6.1f \n",float)' (I hope the syntax is good),it prints: %6.1f Of course,no problem at all with the ixemul.library. I am a beginner in C,so keep cool if I've done a silly mistake. In advance,thanks. I haven't subscribed to this ML,so mail me something at: perret@diva.univ-mlv.fr Bye... From amiga-gcc-port-owner@nic.funet.fi Mon May 29 17:49:05 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90463-2>; Mon, 29 May 1995 17:46:14 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26950-1>; Mon, 29 May 1995 16:45:50 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209222-2>; Mon, 29 May 1995 16:45:36 +0100 Subject: Re: Stack checking - system friendly? From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Mon, 29 May 1995 16:45:31 +0200 (MESZ) In-Reply-To: from "Fred Fish" at May 27, 95 10:24:48 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1520 Message-Id: <95May29.164536+0100mesz.209222-2+589@hphalle0.informatik.tu-muenchen.de> > > The below posting on comp.sys.amiga.programmer prompted me to ask the > question about how system friendly the stack switching code in libnix > is, which is the same code I'm integrating into the ixemul library. > Can anyone comment on this particular issue? ... > > [ Stack-Switching ] > > > > > Umm... its relatively easy to do, but not exactly reccomended or OS friendly. > > > > ??? > > > > exec.library/StackSwap() Well, I wrote the posting. I strongly believe that using StackSwap() _is_ system friendly (if you SwapStack() the old stack back in before exiting, of course). IMHO the only reason why Commodore put in a function like StackSwap() was to allow dynamically growing stacks (or a fixed size stack allocated at program start, which is the same thing concerning the OS). I believe that the original poster (who wrote the "not system friendly" stuff) didn't know about StackSwap() and thought the only way to do stack switching was poking a7. I currently cannot see a reason why StackSwitch() might cause problems in the future. AmigaOS doesn't care about the stack, only exec really does --- and StackSwap() is an exec function. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Mon May 29 18:41:46 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <90402-4>; Mon, 29 May 1995 18:40:58 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA28047 (5.65c8/IDA-1.4.4 for ); Mon, 29 May 1995 17:40:50 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA09634; Mon, 29 May 95 17:40:49 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9505291540.AA09634@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Floats with Libnix To: perret@univ-mlv.fr (Perret Charles) Date: Mon, 29 May 1995 17:40:49 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95May29.165759+0300_eet_dst.90232-3+2@nic.funet.fi> from "Perret Charles" at May 29, 95 02:56:14 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 326 > > I cannot display floats with the libnix 0.9,even with the -lm option > With a thing like 'printf("%6.1f \n",float)' (I hope the syntax is good),it prints: > %6.1f > For some of gcc's commandline switches it's important where you put them. -lm for example has to be put after .c or .o files. Hope it helps. Matthias From amiga-gcc-port-owner@nic.funet.fi Tue May 30 17:12:11 1995 Received: from ild.alkymi.unit.no ([129.241.113.1]) by nic.funet.fi with SMTP id <90238-1>; Tue, 30 May 1995 17:09:09 +0300 Received: from jord.alkymi.unit.no (jord.alkymi.unit.no [129.241.113.3]) by ild.alkymi.unit.no (8.6.12/8.6.11MS-serv) with ESMTP id QAA10314 for ; Tue, 30 May 1995 16:09:03 +0200 From: Torgeir Lilleskog Received: (tli@localhost) by jord.alkymi.unit.no (8.6.12/8.6.11MS-cli) id QAA09944 for amiga-gcc-port@lists.funet.fi; Tue, 30 May 1995 16:09:02 +0200 Message-Id: <199505301409.QAA09944@jord.alkymi.unit.no> Subject: How to declare variables CHIP To: amiga-gcc-port@nic.funet.fi Date: Tue, 30 May 1995 16:09:01 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 859 Hello! I recently read the FAQ for Amiga-gcc that was posted here not long ago. In this FAQ I read that the CHIP-keyword was not implemented yet. Though there was a notice saying that there was a workaround for this. Could someone tell me how I can declare variables chip. I'd like to declare a Copper-list as a array of int's, but cannot see how I can tell gcc to put it in chip-ram. Is there an easy way to do this? I'd also like to know if it is possible to include a binary in my programs. E.g. I'd like to include a raw bitmap in my program. Any help would be appreciated. regards - Torgeir Lilleskog -- ------------------------------------------------------------------------------- "I will never let malfunctioning brakes stop me" - tli@alkymi.unit.no ------------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Tue May 30 20:20:21 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <90663-3>; Tue, 30 May 1995 20:17:26 +0300 Received: from math.uwaterloo.ca ([129.97.140.144]) by math.uwaterloo.ca with SMTP id <77182-3>; Tue, 30 May 1995 13:15:40 -0400 Date: Tue, 30 May 1995 13:15:38 -0400 From: Jeff Shepherd Reply-To: jsshephe@UNDERGRAD.MATH.UWATERLOO.CA To: Amiga-Gcc List Subject: ar and long filenames Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There seems to be a bug in ar (found in the gcc2.6.3 archive) dealing with long filenames. Here is a simple test that uncovers the bug. touch very_long_filename.o touch short.o ar rc libtest.a very_long_filename.o short.o ar tv libtest.a - which produces very_long_filename.o rwxrwxrwx 0/0 short.o ar x libtest.a - which produces error: cannot stat very_long_filename.o A short aside: ld can use very_long_filename.o even though ar cannot extract it. I though ar truncated filenames. If it doesn't then the code that deals with long filenames must be broken in some way. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/index.html The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Wed May 31 14:41:06 1995 Received: from terra.stack.urc.tue.nl ([131.155.140.128]) by nic.funet.fi with SMTP id <90537-2>; Wed, 31 May 1995 14:38:29 +0300 Received: from turtle.stack.urc.tue.nl (turtle.stack.urc.tue.nl [131.155.140.132]) by terra.stack.urc.tue.nl (8.6.11) with ESMTP id NAA18852 for ; Wed, 31 May 1995 13:38:05 +0200 Received: (raymondp@localhost) by turtle.stack.urc.tue.nl (8.6.10/8.6.4) id NAA14948 for amiga-gcc-port@lists.funet.fi; Wed, 31 May 1995 13:38:23 +0200 From: raymondp@stack.urc.tue.nl (Raymond Penners) Message-Id: <199505311138.NAA14948@turtle.stack.urc.tue.nl> Subject: GNU Emacs 19.25 To: amiga-gcc-port@nic.funet.fi Date: Wed, 31 May 1995 13:38:23 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 554 Hi, First, I am aware that this isn't the right place to ask about this, but I got no replies from usenet and there is a bigger chance that someone from this list is using emacs... My problem is that I can't get the 19.25 port (from aminet) to work. It keeps failing, stating something like "[..]xsetint assertion failure[..]". I tried mailing the author, but he didn't reply. So, if anybody knows what could be the cause of this, or if anyone had the same problems, please mail me (not this list). Thanks, Raymond Penners From amiga-gcc-port-owner@nic.funet.fi Wed May 31 14:47:01 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <90467-3>; Wed, 31 May 1995 14:46:43 +0300 Received: by roemer.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May31.144643+0300_eet_dst.90467-3+14@nic.funet.fi> From: To: Date: Wed, 31 May 1995 14:46:28 +0300 Date: Wed, 31 May 1995 13:44:35 +0200 (METDST) From: Rask Lambertsen To: Hans Verkuil Cc: ixemul@wyst.hobby.nl, amiga-gcc-port@nic.funet.fi Subject: Re: Proposal to remove ixconfig options and drop Amigados globbing In-Reply-To: <9505272114.07pv@wyst.hobby.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject : Re: Proposal to remove ixconfig options and drop Amigados globbing On Sat, 27 May 1995, Hans Verkuil wrote: > Hi everybody, > > With the upcoming release of ixemul 41 I'd say that now is the time to > reorganize a few things. One of the more irritating 'features' are the > multitude of options in ixconfig for translating AmigaDOS/UNIX pathnames. > The current list of options in the latest version is: > > ixconfig [-d|-a|-c|-p|-P|-b N|-f|-i|-e|-.|-/|-l|-m N|-r N|-s|-w|-x] > -d reset values to defaults > -a full AmigaDOS mode, no ./ translations > -c open console if no errorstream was provided > -p use UNIX-style filename pattern-matching > -P use case-sensitive UNIX-style filename pattern-matching > -b N N physical block map into 1 logical (stdio) block > -f don't accept AmigaDOS notation > -i ignore global environment (ENV:) > -e don't ignore global environment (ENV:) > -. translate . and .. > -/ translate /foo -> foo: and a//b -> a/b > -l translate contents of symbolic links > -m N files upto N bytes are cached in memory > -r N set red zone size to N bytes. 0 disables. > -s sleep, don't return. > -v suppress the "Insert volume in drive" requester > -w enable stack watcher > -x disable stack watcher Hmm, a nice little mess. > I propose to drop the following options: > > -d, -a, -f, -., -/, -l. I would like to keep -a, as I prefer AmigaDOS notation to UNIX notation. In paricular, I don't want to have to let go of using / to specify the parent directory. > A note on softlinks: the new library will write all softlinks in > AmigaDOS format, and after reading a softlink will translate it to UNIX > format. Currently, the -l option specifies that AmigaDOS softlinks should > be translated to Unix, but as the library writes them in UNIX format, it's > pretty useless. Anyway, the new library no longer supports UNIX style > softlinks, which is a good thing, as AmigaDOS doesn't support them either. What is the difference between AmigaDOS format and UNIX format? > The library should recognize fully specified AmigaDOS filenames (i.e., they > start with 'volume:'), and all other filenames are considered to be UNIX > filenames. Quite reasonable, as this is after all a UNIX emulation library. I would like an option here, so that it is possible to select between AmigaDOS style and UNIX style. > Another proposal is to drop support for AmigaDOS style globbing, i.e. > 'egrep f#?.c' is no longer supported, instead standard UNIX style globbing > should be used: 'egrep f*.c' Fine with me. > A final question: is anyone using the -b, -m or -r options? If no-one is > using these, then I'll consider removing these too. Otherwise, I'm > interested in hearing your experiences. -b? -r? I haven't got a clue as to what these options do. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed May 31 14:58:36 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <90379-3>; Wed, 31 May 1995 14:57:25 +0300 Received: by roemer.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May31.145725+0300_eet_dst.90379-3+16@nic.funet.fi> From: To: Date: Wed, 31 May 1995 14:57:21 +0300 Date: Wed, 31 May 1995 13:55:54 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Bug in ixemul.library or ls Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject : Bug in ixemul.library or ls I think I have discovered a bug in either ixemul.library or ls. Soft links are displayed as being a "bit" older than they really are. Take a look at this: 5. HD1:> Echo "Test file to show ixemul.library/ls bug" TO testfile 5. HD1:> ln -s testfile softlink 5. HD1:> List testfile softlink DATES testfile 40 ----rwed 30-Maj-95 11:40:51 1 file - 2 blocks used softlink 40 ----rwed 30-Maj-95 11:40:51 1 file - 2 blocks used 5. HD1:> ls -l testfile softlink -rwxrwxrwx 1 amiga amiga 40 May 30 11:40 testfile lrwxrwxrwx 1 amiga amiga 1024 Jan 1 1970 softlink -> testfile ^^^^^^^^^^^^ Obviously, something goes wrong. In case it is needed, here is some system information. 5. HD1:> Version ixemul.library FULL ixemul.library 40.4 5. HD1:> ls --version GNU fileutils 3.12 5. HD1:> ShowConfig PROCESSOR: CPU 68000 CUSTOM CHIPS: ECS PAL Agnus (id=$0020), ECS Denise (id=$00fc) VERS: Kickstart version 37.175, Exec version 37.132, Disk version 38.35 RAM: Node type $a, Attributes $5 (FAST), at $200000-$3fffff (2.0 meg) Node type $a, Attributes $303 (CHIP), at $400-$fffff (~1.0 meg) BOARDS: Board + ROM (HD?) (unidentified): Prod=18260/8($4754/$8) (@$ef0000 64K) I hope someone can shed come light on this. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed May 31 14:59:39 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <90393-1>; Wed, 31 May 1995 14:58:19 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa21100; 31 May 95 6:30 +0100 Received: from flevel.demon.co.uk by post.demon.co.uk id aa26972; 31 May 95 6:30 +0100 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA0034j; Tue, 30 May 95 16:54:16 GMT Date: Tue, 30 May 95 16:54:16 GMT Message-Id: <9505301654.AA0034i@flevel.demon.co.uk> Message-Id: <20bf0eb6.e09c0-dev@flevel.demon.co.uk> In-Reply-To: <199505301409.QAA09944@jord.alkymi.unit.no> (from Torgeir Lilleskog ) (at Tue, 30 May 1995 16:09:01 +0200 (MET DST)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: tli@alkymi.unit.no Cc: amiga-gcc-port@nic.funet.fi Subject: Re: How to declare variables CHIP Hi Torgeir, > I recently read the FAQ for Amiga-gcc that was posted here not > long ago. > > In this FAQ I read that the CHIP-keyword was not implemented > yet. Though there was a notice saying that there was a workaround for > this. > Could someone tell me how I can declare variables chip. > > I'd like to declare a Copper-list as a array of int's, but cannot see > how I can tell gcc to put it in chip-ram. Is there an easy way to do > this? Sure, hows about: int* copper=(int*)AllocMem(COPPER_SIZE,MEMF_CHIP); . . . FreeMem((void*)copper,COPPER_SIZE); > I'd also like to know if it is possible to include a binary in my > programs. > E.g. I'd like to include a raw bitmap in my program. I don't think there is a standard way of doing this. I suggest that if you want to include a file called "hand.raw" you do: 1) Create a file called hand.a which incbins hand.raw. 2) Add hand.a to the makefile so it gets assembled to hand.o and linked. I hope that helps. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed May 31 15:00:35 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <89984-3>; Wed, 31 May 1995 14:58:16 +0300 Received: by roemer.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May31.145816+0300_eet_dst.89984-3+17@nic.funet.fi> From: To: Date: Wed, 31 May 1995 14:58:09 +0300 Date: Wed, 31 May 1995 13:56:43 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Code generation improvement for gcc (bug?) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject : Code generation improvement for gcc (bug?) Hi everybody Having a look a some code generated by gcc, I found out that it doesn't generate as efficient code as it could and should. It uses the "clear.l Dn" instruction instead of the "moveq.l #0,Dn" instruction. Here is a little example: unsigned long int fubar (unsigned short int qwe) { return (qwe); } Saved as clear.l.c, here is the steps I followed: 5. HD1:T> gcc clear.l.c -c -O3 -o clear.l.og 5. HD1:T> sobja clear.l.og clear.l.o SObjA - Version 1.03 5. HD1:T> HD1:DICE/bin/dobj clear.l.o HUNK_UNIT HUNK_CODE #00 ( ) Hunk=000003e9 Size=12 bytes *00.00000000 _fubar: 00.00000000 4280 CLR.L D0 00.00000002 302f 0006 MOVE.W 0006(A7),D0 00.00000006 4e75 RTS 00.00000008 4e71 NOP 00.0000000a 0000 0000 ORI.B #00,D0 5. HD1:T> objdump --disassemble clear.l.og clear.l.og: file format a.out-sunos-big Disassembly of section .text: 00000000 <_fubar> clrl d0 00000002 <_fubar+2> movew sp@(6),d0 00000006 <_fubar+6> rts 00000008 <_fubar+8> nop 0000000a <_fubar+a> Address 0xc is out of bounds. The problem seems to be casting from word-size to longword-size. Just assigning 0 to a longword-sized variable doesn't generate "clear.l Dn" instructions, instead a "moveq.l #0,Dn" instruction is generated. Since "moveq.l #0,Dn" is faster than "clear.l Dn", this should be corrected. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed May 31 16:44:54 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <90945-2>; Wed, 31 May 1995 16:42:29 +0300 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.6.12/8.6.9) id PAA10802; Wed, 31 May 1995 15:42:07 +0200 Date: Wed, 31 May 1995 15:42:07 +0200 From: Ignatios Souvatzis Message-Id: <199505311342.PAA10802@theory.cs.uni-bonn.de> To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: 's message of Wed, 31 May 1995 14:58:09 +0300 <95May31.145816+0300_eet_dst.89984-3+17@nic.funet.fi> X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a Since "moveq.l #0,Dn" is faster than "clear.l Dn", this should be corrected. At least on the 68030, their timing is absolutely identical - even wrt. the pipelining behaviour. Ignatios Souvatzis From amiga-gcc-port-owner@nic.funet.fi Wed May 31 16:45:49 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <90722-4>; Wed, 31 May 1995 16:44:46 +0300 Received: by roemer.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May31.164446+0300_eet_dst.90722-4+29@nic.funet.fi> From: To: Date: Wed, 31 May 1995 16:44:45 +0300 Date: Wed, 31 May 1995 15:42:58 +0200 (METDST) From: Rask Lambertsen To: Ignatios Souvatzis Cc: amiga-gcc-port@nic.funet.fi Subject: Re: your mail In-Reply-To: <199505311342.PAA10802@theory.cs.uni-bonn.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 31 May 1995, Ignatios Souvatzis wrote: > Date: Wed, 31 May 1995 13:56:43 +0200 (METDST) > From: Rask Lambertsen > > Since "moveq.l #0,Dn" is faster than "clear.l Dn", this should be > corrected. > > At least on the 68030, their timing is absolutely identical - even wrt. > the pipelining behaviour. On the 68000, "clear.l Dn" IS slower than "moveq.l #0, Dn". Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed May 31 17:50:42 1995 Received: from epsilon.qmw.ac.uk ([138.37.6.3]) by nic.funet.fi with SMTP id <90814-3>; Wed, 31 May 1995 17:48:08 +0300 Received: from canary.dcs.qmw.ac.uk by epsilon.qmw.ac.uk with SMTP-DNS (PP) id <13221-0@epsilon.qmw.ac.uk>; Wed, 31 May 1995 15:47:49 +0100 Received: from magician.dcs.qmw.ac.uk [192.135.231.242] by canary.dcs.qmw.ac.uk (8.6.12/QMW-server-2.4s) with SMTP; poster "Liu "; id PAA22210; Wed, 31 May 1995 15:48:28 +0100 From: Liu Full-Name: Liu Received: from it046.dcs.qmw.ac.uk by magician.dcs.qmw.ac.uk (4.1/QMW-client-3.2b); for "amiga-gcc-port@nic.funet.fi"; poster "wmliu168"; id AA02780; Wed, 31 May 95 15:47:05 BST Received: from localhost by it046.dcs.qmw.ac.uk (8.6.4/QMW-Minimal-1.14) id PAA02058; Wed, 31 May 1995 15:41:47 +0100 Message-Id: <199505311441.PAA02058@it046.dcs.qmw.ac.uk> Subject: Req: ftp site address To: amiga-gcc-port@nic.funet.fi Date: Wed, 31 May 1995 15:41:45 +0000 (BST) Cc: wmliu168@dcs.qmw.ac.uk (Liu) X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 1251 Gcc'ers... Someone a while back posted the ftp address of a site where the Native Developer Update Kit with the Includes could be obtained. Could someone post that address again? Thanks. -- Raymond W.M.Liu Esq. BSc.(Hons.) ____________________________________________________________________________ | | | | Internet : wmliu168@dcs.qmw.ac.uk | AmigaOS - Pre-emptive multi-tasking | | UUCP : wmliu168@qmw-dcs.uucp | + s/ware MS-DOS/Windows emu... | | JANET : wmliu168@uk.ac.qmw.dcs | + s/ware Macintosh MacOS emu... _ | | | + etc....(ALL Pre-Emptively) // | | Informatics Teaching Laboratory | _ // | | Queen Mary & Westfield College | "..Taking a big Byte out \\ // | | University of London | of a Big Blue Apple..." \X/ | | |_______________________________________| | Tel.: +44 171 975 5252 | |_#_#_#_#_#| | (Direct) 0700-0200 UTC | Tartan desires... |#_#_#_#_#_| |____________________________________|____________________________|_#_#_#_#_#| From amiga-gcc-port-owner@nic.funet.fi Wed May 31 17:57:11 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <90830-3>; Wed, 31 May 1995 17:55:38 +0300 Received: by roemer.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95May31.175538+0300_eet_dst.90830-3+23@nic.funet.fi> From: To: Date: Wed, 31 May 1995 17:55:34 +0300 Date: Wed, 31 May 1995 16:53:23 +0200 (METDST) From: Rask Lambertsen To: Liu Cc: amiga-gcc-port@nic.funet.fi, Liu Subject: Re: Req: ftp site address In-Reply-To: <199505311441.PAA02058@it046.dcs.qmw.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject : Re: Req: ftp site address On Wed, 31 May 1995, Liu wrote: > Gcc'ers... > > Someone a while back posted the ftp address of a site where the > Native Developer Update Kit with the Includes could be obtained. > Could someone post that address again? Thanks. OK, here's the URL: ftp://ftp.dfv.rwth-aachen.de/cdrom/bbs/cbm/ Btw, did this URL ever make it into the FAQ? Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed May 31 21:59:26 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90090-3>; Wed, 31 May 1995 18:45:26 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26499-4>; Wed, 31 May 1995 17:45:08 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209222-2>; Wed, 31 May 1995 17:44:48 +0100 Subject: Re: ar and long filenames From: Christian Stieber To: jsshephe@undergrad.math.uwaterloo.ca Date: Wed, 31 May 1995 17:44:36 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Jeff Shepherd" at May 30, 95 01:15:38 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 727 Message-Id: <95May31.174448+0100mesz.209222-2+2343@hphalle0.informatik.tu-muenchen.de> > There seems to be a bug in ar (found in the gcc2.6.3 archive) dealing with > long filenames. Here is a simple test that uncovers the bug. ... I don't know whether this is related, but I had serious problems with GNU-make concerning the archive(archivemember) stuff. It didn't work with long filenames either... Sorry for not posting a proper bug report :( Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed May 31 22:00:08 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <90933-2>; Wed, 31 May 1995 18:00:08 +0300 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.6.12/8.6.9) id QAA14463; Wed, 31 May 1995 16:59:42 +0200 Date: Wed, 31 May 1995 16:59:42 +0200 From: Ignatios Souvatzis Message-Id: <199505311459.QAA14463@theory.cs.uni-bonn.de> To: wmliu168@dcs.qmw.ac.uk CC: amiga-gcc-port@nic.funet.fi, wmliu168@dcs.qmw.ac.uk In-reply-to: Liu's message of Wed, 31 May 1995 15:41:45 +0000 (BST) <199505311441.PAA02058@it046.dcs.qmw.ac.uk> Subject: Req: ftp site address X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a; Thu, 1 Jun 1995 03:28:48 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id CAA28014; Thu, 1 Jun 1995 02:27:05 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id BAA14603; Thu, 1 Jun 1995 01:25:42 +0200 Date: Thu, 1 Jun 1995 01:25:42 +0200 From: Niklas Hallqvist Message-Id: <199505312325.BAA14603@linda.appli.se> To: gcc2@cygnus.com CC: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-reply-to: <95May31.145816+0300_eet_dst.89984-3+17@nic.funet.fi> (gc948374@gbar.dtu.dk) Subject: Re: Code generation improvement for gcc (bug?) There has come up a complaint about a m68k code generation issue on the Amiga GCC list. On straight m68000's a clr.l instruction is slower than a movq.l, which seems to be noted in m68k.md. I wonder why the comment says we have no choice? Can this really be true? I'm not proposing a change for 2.7.0 here, as it is just a quality of implementation issue. Niklas Excerpt from the define_insn implementing simple (set X:SI Y) insns: if (GET_CODE (operands[1]) == CONST_INT) { if (operands[1] == const0_rtx && (DATA_REG_P (operands[0]) || GET_CODE (operands[0]) == MEM) /* clr insns on 68000 read before writing. This isn't so on the 68010, but we have no alternative for it. */ && (TARGET_68020 || !(GET_CODE (operands[0]) == MEM && MEM_VOLATILE_P (operands[0])))) return \"clr%.l %0\"; else if (DATA_REG_P (operands[0])) return output_move_const_into_data_reg (operands); From amiga-gcc-port-owner@nic.funet.fi Thu Jun 1 09:13:34 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90863-2>; Thu, 1 Jun 1995 09:12:09 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA20455 (5.65b/CWI-3.3); Thu, 1 Jun 1995 08:11:34 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sH3G8-000FjpC; Thu, 1 Jun 95 07:57 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <07t0@wyst.hobby.nl>; Wed, 31 May 95 22:29:30 CET Message-Id: <9505312129.07t0@wyst.hobby.nl> Date: Wed, 31 May 1995 22:29:28 +0000 (CET) In-Reply-To: from "gbar.dtu.dk!gc948374" at May 31, 95 08:49:05 pm Content-Type: text Content-Length: 2532 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi Subject: Re: Proposal to remove ixconfig options and drop Amigados globbing > > A note on softlinks: the new library will write all softlinks in > > AmigaDOS format, and after reading a softlink will translate it to UNIX > > format. Currently, the -l option specifies that AmigaDOS softlinks should > > be translated to Unix, but as the library writes them in UNIX format, it's > > pretty useless. Anyway, the new library no longer supports UNIX style > > softlinks, which is a good thing, as AmigaDOS doesn't support them either. > > What is the difference between AmigaDOS format and UNIX format? If you use 'ln -s ../xx x' to make a softlink 'x' which points to file '../xx', then the old library would make a softlink containing the filename '../xx', but the new library translates this to AmigaDOS format and makes a softlink containing the filename '/xx'. Other non-ixemul programs cannot use UNIX style softlinks, as they search for a directory named '..' which is not present. Use try to 'delete x' and you'll know what I mean :-) > > The library should recognize fully specified AmigaDOS filenames (i.e., they > > start with 'volume:'), and all other filenames are considered to be UNIX > > filenames. Quite reasonable, as this is after all a UNIX emulation library. > > I would like an option here, so that it is possible to select between > AmigaDOS style and UNIX style. The problem with the current ixemul library is that filename handling is not consistent. Some parts of the library honor the option settings, others don't. Also, some UNIX programs can get very confused when passed Amiga style filenames as arguments. I suspect that it is not possible to setup a foolproof translation scheme, but I will look at this aspect again. > > Another proposal is to drop support for AmigaDOS style globbing, i.e. > > 'egrep f#?.c' is no longer supported, instead standard UNIX style globbing > > should be used: 'egrep f*.c' I forgot to mention one important consequence of this change: as far as I am aware, this makes it impossible to use AmigaDOS style filenames such as 'egrep xxxx //files.*'. A final note: Rask, please check your mailer: it is putting a newline after the Subject-line, confusing most if not all other mailreaders. In fact, several mail-headers are duplicated. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu Jun 1 15:19:08 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <90537-2>; Thu, 1 Jun 1995 15:16:09 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA03689 (5.65c8/IDA-1.4.4 for ); Thu, 1 Jun 1995 14:15:57 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA11975; Thu, 1 Jun 95 14:15:57 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506011215.AA11975@sunserv.IZFM.Uni-Stuttgart.DE> Subject: floating point problem To: amiga-gcc-port@nic.funet.fi Date: Thu, 1 Jun 1995 14:15:56 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 625 Hello, do you remember the problems with IEEE*PFix() on certain machines that affect the cast operators of ixemul.library and the floating point output of libnix? Together with Andreas Wolff I found a simple workaround for it (this workaround is the reason why the problem doesn't affect SAS programs): If you open mathieeesingbas.library first _then_ open mathieeedoubbas.library IEEE*PFix() in both libraries rounds to zero like it should. If you open them the other way IEEE*PFix() rounds to nearest on some machines (OS bug). libnix does this and I think ixemul.library does it too - but it's easy to fix :-). Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Jun 1 15:48:22 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90664-4>; Thu, 1 Jun 1995 15:45:40 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id NAA20292; Thu, 1 Jun 1995 13:44:52 +0100 From: Lars Hecking Message-Id: <199506011246.NAA20369@mostar.nmrc.ucc.ie> Subject: Re: floating point problem To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Thu, 1 Jun 1995 13:46:54 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9506011215.AA11975@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Jun 1, 95 02:15:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 508 > If you open mathieeesingbas.library first _then_ open > mathieeedoubbas.library IEEE*PFix() in both libraries rounds to zero > like it should. If you open them the other way IEEE*PFix() rounds to > nearest on some machines (OS bug). libnix does this and I think > ixemul.library does it too - but it's easy to fix :-). No. Ixemul opens dos, intuition, graphics, mathieeesingbas, mathieeedoubbas and mathieeedoubtrans, in this order. But if it didn't, it would be _very easy to fix, indeed ;-) Lars From amiga-gcc-port-owner@nic.funet.fi Thu Jun 1 16:02:53 1995 Received: by nic.funet.fi id <89970-1>; Thu, 1 Jun 1995 16:00:07 +0300 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <95Jun1.160007+0300_eet_dst.89970-1+31@nic.funet.fi> Date: Thu, 1 Jun 1995 16:00:02 +0300 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Thu Jun 1 17:03:22 1995 Received: from eeyore.INS.CWRU.Edu ([129.22.8.17]) by nic.funet.fi with ESMTP id <90402-3>; Thu, 1 Jun 1995 16:59:50 +0300 Received: (cz253@localhost) by eeyore.INS.CWRU.Edu (8.6.10+cwru/CWRU-2.1-bsdi) id JAA29396; Thu, 1 Jun 1995 09:58:41 -0400 (from cz253) Message-Id: <199506011358.JAA29396@eeyore.INS.CWRU.Edu> Date: Thu, 1 Jun 1995 09:58:41 -0400 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: Timing... Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from ignatios@theory.cs.uni-bonn.de of Wed, 31 May > > Date: Wed, 31 May 1995 13:56:43 +0200 (METDST) > From: Rask Lambertsen > > Since "moveq.l #0,Dn" is faster than "clear.l Dn", this should be > corrected. > >At least on the 68030, their timing is absolutely identical - even wrt. >the pipelining behaviour. > > Ignatios Souvatzis > > Sure about that? Moveq.l #0,Dn takes 4 cycles. Clr.l Dn takes 6. I would assume that moveq.l will be faster than clr.l on all 680x0 cpus. .....Dave From amiga-gcc-port-owner@nic.funet.fi Fri Jun 2 00:56:04 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90468-1>; Fri, 2 Jun 1995 00:53:33 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 1 Jun 95 23:54 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 1 Jun 95 23:48 MET DST Message-Id: Subject: Re: Code generation improvement To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 1 Jun 1995 23:48:33 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 385 we have some many ppl how knows about gcc here, why cant we change from mit-68k to moto-68k ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Jun 2 01:52:59 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90344-2>; Fri, 2 Jun 1995 01:51:45 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id AAA06490; Fri, 2 Jun 1995 00:49:53 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id XAA25227; Thu, 1 Jun 1995 23:38:14 +0200 Date: Thu, 1 Jun 1995 23:38:14 +0200 From: Niklas Hallqvist Message-Id: <199506012138.XAA25227@linda.appli.se> To: Walter.Harms@arbi.informatik.uni-oldenburg.de CC: amiga-gcc-port@lists.funet.fi In-reply-to: (message from Walter Harms on Thu, 1 Jun 1995 23:48:33 +0200 (MET DST)) Subject: Re: Code generation improvement >>>>> "Walter" == Walter Harms writes: Walter> we have some many ppl how knows about gcc here, why Walter> cant we change from mit-68k to moto-68k ? Why should we? I'm sure it's easy to write a filter to feed .s-files through to get Motorola syntax, so why bother changing GCC and requiring all people who have used asms in earlier versions to rewrite their source? Or do you want an *assembler* that groks Motorola syntax for your old code? I don't know, maybe gas is configurable in that way, if it isn't, I guess it's easier to write a filter for that conversion as well. Or use an Amiga assembler and a hunk-to-a.out converter. Finally, a subjective note: I've used both Motorola, SGS & MIT syntax, and I must say I like MIT most, although it was the last one I learned. It's just cuter :-) Niklas PS. FYI: The clr.l -> movq.l improvement ought to get into GCC 2.8.0, it's too late for 2.7.0 which is in a release cycle... From amiga-gcc-port-owner@nic.funet.fi Fri Jun 2 03:23:34 1995 Received: from piglet.INS.CWRU.Edu ([129.22.8.16]) by nic.funet.fi with ESMTP id <90063-2>; Fri, 2 Jun 1995 03:22:18 +0300 Received: (cz253@localhost) by piglet.INS.CWRU.Edu (8.6.9/CWRU-2.1-bsdi) id UAA01048; Thu, 1 Jun 1995 20:15:59 -0400 (from cz253) Message-Id: <199506020015.UAA01048@piglet.INS.CWRU.Edu> Date: Thu, 1 Jun 1995 20:15:59 -0400 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: ignatios@theory.cs.uni-bonn.de Subject: Re: Timing... Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from ignatios@theory.cs.uni-bonn.de of Thu, 01 Jun > >David Zaroski replied: > Date: Thu, 1 Jun 1995 09:52:04 -0400 > From: cz253@cleveland.Freenet.Edu (David Zaroski) > Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) > > Reply to message from ignatios@theory.cs.uni-bonn.de of Wed, 31 May > > > > Date: Wed, 31 May 1995 13:56:43 +0200 (METDST) > > From: Rask Lambertsen > > > > Since "moveq.l #0,Dn" is faster than "clear.l Dn", this should be > > corrected. > > > >At least on the 68030, their timing is absolutely identical - even wrt. > >the pipelining behaviour. > > Sure about that? Moveq.l #0,Dn takes 4 cycles. Clr.l Dn takes 6. I would > assume that moveq.l will be faster than clr.l on all 680x0 cpus. > >From Motorolas 68030 Users Manual, page 11-30 and page 11-32: > >head 2, tail 0, In-cache: 2(0/0/0) Out-of-cache: 2(0/1/0) Correct you are. Now as far as the compiler is concerned what would be the best choice, moveq.l or clr.l? Remember...you want to be nice to all 680x0 processors. Moveq.l obviously, unless you want the lower end processors using code that takes longer to execute on the slower machines. Our thinking should not always be 'what is faster on my machine', but what will be faster for all machines. From the '030 up it doesn't matter, but for the '020 down it does. .....Dave From amiga-gcc-port-owner@nic.funet.fi Fri Jun 2 11:25:32 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90696-1>; Fri, 2 Jun 1995 11:23:26 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA04249; Fri, 2 Jun 1995 10:25:22 +0200 Date: Fri, 2 Jun 1995 10:25:20 +0200 (MET DST) From: Kamil Iskra Subject: GCC 2.6.3 Bugs and Suggestions To: amiga-gcc-port@nic.funet.fi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have found two (three?) minor bugs in GCC 2.6.3 (Aminet version): 1. Please try to use "-g" option (debugging on) together with "-m68020". Incorrect argument is passed to the linker, here's the verbose output (commandline: "gcc -v -g -m68020 -o test test.c"): Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -g -Dmc68020 test.c t:cc258048.i GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1 t:cc258048.i -quiet -dumpbase test.c -m68020 -g -version -o t:cc258048.s GNU C version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3 snapshot 941209. as -mc68020 -o t:cc2580481.o t:cc258048.s ld -amiga-debug-hunk-fl libm020 -o test /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/local/lib/gcc-lib/mc68020-cbm-amigados/2.6.3 -L/gnu/lib -L/local/lib -L/local/lib t:cc2580481.o -lgcc -lc -lgcc ld: unrecognized option `-amiga-debug-hunk-fl' Usage: ld [-d] [-dc] [-dp] [-e symbol] [-l lib] [-n] [-noinhibit-exec] [-nostdlib] [-o file] [-r] [-s] [-t] [-u symbol] [-x] [-y symbol] [-z] [-A file] [-Bstatic] [-D size] [-L libdir] [-M] [-N] [-S] [-T[{text,data}] addr] [-V prefix] [-X] [{-a,-amiga-debug-hunk}] [{-f,-flavor} flavor] [file...] [-chip {c,d,b}] [-fast {c,d,b}] [-m,-shortdata] Simply, there is no space between debug-output option and 68020-libs option. BTW: Is it intentional that options "-L/local/lib" and "-lgcc" are specified TWICE in the ld's commandline? 2. To my surprise, the above worked well when I used "-mc68020" instead of "-m68020"! GCC manual states that they are identical. I experimented a bit and that's what I found: In "ld" commandline "-fl libm020" is used when "-m68020" option is specified and NO FLAVOR is used when "-mc68020" option is specified. I have checked other CPU-specific options and they seem to work fine, but option "-m68020-40" (described in the manual) is just not recognized by "cc1"! Now about something different: I am really surprised that GCC for the Amiga STILL does not support putting part of the program's data into CHIP memory. I think somebody on this list wrote that this would require hacking into GCC source code, which everybody would of course prefer to avoid. But is this really true? What about "Variable Attributes"? I didn't experiment with them yet, but it seems that GCC already supports an equivalent of SAS/C "__aligned" keyword (useful for FileInfoBlocks, for example): struct FileInfoBlock fib __attribute__ ((aligned(4))); And it has a "section" attribute - please read this piece of GCC doc: "Sometimes, however, you need additional sections, or you need certain particular variables to appear in special sections, for example to map to special hardware. The `section' attribute specifies that a variable (or function) lives in a particular section." Isn't it EXACTLY what would be needed to support CHIP-data? Wouldn't minor corrections to the linker be enough? Source code using this feature would look something like this: UWORD pointerData[] __attribute__ ((section("data_chip")))={/*...*/}; Not so smart as in Amiga-specific C compilers, but well, better this than nothing... Any ideas? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Jun 2 12:50:22 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <90553-1>; Fri, 2 Jun 1995 12:49:22 +0300 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA06593; Fri, 2 Jun 1995 11:49:04 +0200 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA19888; Fri, 2 Jun 95 11:49:03 +0200 From: isthesin@TechFak.Uni-Bielefeld.DE (Stephan Thesing) Message-Id: <9506021149.ZM19886@moos.TechFak.Uni-Bielefeld.DE> Date: Fri, 2 Jun 1995 11:49:02 +0200 In-Reply-To: Kamil Iskra "GCC 2.6.3 Bugs and Suggestions" (Jun 2, 10:25) References: X-Mailer: Z-Mail (2.1.5 09aug93) To: Kamil Iskra Subject: Re: GCC 2.6.3 Bugs and Suggestions Cc: amiga-gcc-port@nic.funet.fi On Jun 2, 10:25, Kamil Iskra wrote: > Subject: GCC 2.6.3 Bugs and Suggestions > > I have found two (three?) minor bugs in GCC 2.6.3 (Aminet version): > > 1. Please try to use "-g" option (debugging on) together with > "-m68020". Incorrect argument is passed to the linker, here's the > verbose output (commandline: "gcc -v -g -m68020 -o test test.c"): > [... gcc output deleted] > Simply, there is no space between debug-output option and 68020-libs > option. > > BTW: Is it intentional that options "-L/local/lib" and "-lgcc" are > specified TWICE in the ld's commandline? > > 2. To my surprise, the above worked well when I used "-mc68020" > instead of "-m68020"! GCC manual states that they are identical. I > experimented a bit and that's what I found: > > In "ld" commandline "-fl libm020" is used when "-m68020" option is > specified and NO FLAVOR is used when "-mc68020" option is specified. > > I have checked other CPU-specific options and they seem to work fine, > but option "-m68020-40" (described in the manual) is just not > recognized by "cc1"! > > Hmm, maybe one should insert a space into the specs file (/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs) > Now about something different: > > I am really surprised that GCC for the Amiga STILL does not support > putting part of the program's data into CHIP memory. I think somebody > on this list wrote that this would require hacking into GCC source > code, which everybody would of course prefer to avoid. > > But is this really true? What about "Variable Attributes"? I didn't > experiment with them yet, but it seems that GCC already supports an > equivalent of SAS/C "__aligned" keyword (useful for FileInfoBlocks, > for example): > > struct FileInfoBlock fib __attribute__ ((aligned(4))); > > And it has a "section" attribute - please read this piece of GCC doc: > > "Sometimes, however, you need additional sections, or you need certain > particular variables to appear in special sections, for example to map > to special hardware. The `section' attribute specifies that a variable > (or function) lives in a particular section." > > Isn't it EXACTLY what would be needed to support CHIP-data? Wouldn't > minor corrections to the linker be enough? Source code using this > feature would look something like this: > > UWORD pointerData[] __attribute__ ((section("data_chip")))={/*...*/}; > > Not so smart as in Amiga-specific C compilers, but well, better this > than nothing... > > Any ideas? Oooh, well, I haven't read that part of the doc yet, but it sounds good. Actually, there is one problem: Since gcc produces a.out format object files (actually as (gas)) produces them, there are only 3 sections known to the assembler: .text program code .data initial. data .bss uninitial. data The problem is: if you specify something should go into section _foo_, then the assembler output of gcc would be something like this: .foo _pointerData: dc.l 0 So _foo_ must be one of (text, data, bss) and this doesn't help much. The problem is not so much the linker (new linker from binutils2.5.2 can handle chip data sections), but rather that the assembler does not know anything about section other than .text, .data, .bss So: change the assembler (possible?) Bye..... Stephan From amiga-gcc-port-owner@nic.funet.fi Fri Jun 2 13:42:16 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90467-3>; Fri, 2 Jun 1995 13:41:14 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id MAA24556; Fri, 2 Jun 1995 12:38:29 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id KAA00720; Fri, 2 Jun 1995 10:07:06 +0200 Date: Fri, 2 Jun 1995 10:07:06 +0200 From: Niklas Hallqvist Message-Id: <199506020807.KAA00720@linda.appli.se> To: kiskra@ernie.icslab.agh.edu.pl CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Kamil Iskra on Fri, 2 Jun 1995 10:25:20 +0200 (MET DST)) Subject: Re: GCC 2.6.3 Bugs and Suggestions >>>>> "Kamil" == Kamil Iskra writes: Kamil> And it has a "section" attribute - please read this piece of Kamil> GCC doc: Kamil> "Sometimes, however, you need additional sections, or you need Kamil> certain particular variables to appear in special sections, for Kamil> example to map to special hardware. The `section' attribute Kamil> specifies that a variable (or function) lives in a particular Kamil> section." Kamil> Isn't it EXACTLY what would be needed to support CHIP-data? Kamil> Wouldn't minor corrections to the linker be enough? Source code Kamil> using this feature would look something like this: Kamil> UWORD pointerData[] __attribute__ Kamil> ((section("data_chip")))={/*...*/}; Kamil> Not so smart as in Amiga-specific C compilers, but well, better Kamil> this than nothing... Kamil> Any ideas? I'm not really up-to-date on this issue, but I think the problem is that the object-file format of the AmigaDOS GCC config is standard a.out, which only have three sections defined text, data & bss. If we used COFF or ELF from the start GCC would have handled this with no problem, but at that time MW used straight BSD Sun3 utils, which of course only handled a.out. Niklas From amiga-gcc-port-owner@nic.funet.fi Fri Jun 2 17:36:18 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90062-3>; Fri, 2 Jun 1995 17:33:30 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26578-2>; Fri, 2 Jun 1995 16:33:03 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209222-1>; Fri, 2 Jun 1995 16:32:50 +0100 Subject: Re: Code generation improvement From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 2 Jun 1995 16:32:40 +0200 (MESZ) In-Reply-To: <199506012138.XAA25227@linda.appli.se> from "Niklas Hallqvist" at Jun 1, 95 11:38:14 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1100 Message-Id: <95Jun2.163250+0100mesz.209222-1+3829@hphalle0.informatik.tu-muenchen.de> > rewrite their source? Or do you want an *assembler* that groks > Motorola syntax for your old code? I don't know, maybe gas is > configurable in that way, The current gas is supposed to understand Motorola syntax. However, some time ago I wrote a larger part of a program in assembler using gas. I tried Motorola syntax, and I got lots of problems. I switched to MIT syntax, and had fewer problems. I don't know whether they changed it since (I don't know exactly what version I used --- I think it was gas 2.2), but it seemed that gas had some problems with Motorola syntax (I tried other assemblers --- Lattice asm and O.M.A, and they all had problems, so I decided to stick with gas since the rest of the project used GNU-C). Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Sat Jun 3 11:23:59 1995 Received: from clinet.fi ([193.64.6.1]) by nic.funet.fi with SMTP id <90684-1>; Sat, 3 Jun 1995 11:22:08 +0300 Received: from zetor.clinet.fi (root@zetor.clinet.fi [193.64.6.8]) by clinet.fi (8.6.10/8.6.4) with ESMTP id LAA23450 for ; Sat, 3 Jun 1995 11:21:56 +0300 Received: (will@localhost) by zetor.clinet.fi (8.6.10/8.6.4) id LAA18994; Sat, 3 Jun 1995 11:21:53 +0300 Date: Sat, 3 Jun 1995 11:21:51 +0300 (EET DST) From: Ville-Pertti Keinonen To: amiga-gcc-port@nic.funet.fi Subject: Make, bash, etc.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A few weeks ago someone on the list mentioned having trouble compiling make 3.73 with the -O2 option - it seems that whatever the bug in gcc, it is specific to 68000 code generation. I compiled make 3.73 (and later 3.74) with CFLAGS='-O2 -m68020' and LDFLAGS='-s -m68020' (the options I use for most stuff) and they both work fine (sometimes they lock up the entire machine when entering a subdirectory, but this is probably just due to stack overflow) for every makefile I've tried (no bus errors - my EC030 does trap them, even though it doesn't have a functional MMU - this even makes enforcer half-useful). I'm using gcc 2.6.3, the 2.6.4 betas seem a bit unstable. I haven't tried making make without the -m68020 option, building it takes a while. There is a problem I have had with compiling some stuff, though - it seems that libm020/libm.a contains fpu-instructions - as a result, some programs exit due to floating point exceptions (I don't have an FPU) when compiled with the -m68020 option (which gives -fl libm020 to ld at the linking stage). I don't know whether this is intentional, but it certainly isn't valid to assume that anyone with an '020 or higher also has an FPU... There have been a few messages mentioning bash on this list - is anyone actually working on porting it? I've tried to port it to my own operating system, but working around the need for a functional fork()-call seems hopeless (there is a call, fork2(), which starts a new process at a given entry point - intended for use until I can get an MMU and actually write a virtual memory environment - but it can't copy the data- and bss-sections, the malloc() memory pool or the stack, so I would have had to trace every single call that can be called after fork()ing and rewrite a lot of the code...). I did hack up a *very* dirty fork()-call (it actually re-relocates the text (code) section and searches for valid addresses to fix in the data, bss, stack and the malloc() pool) - and it does work in simpler programs - but this seems to trash memory (any pointer that points far enough from whatever is accessed through it can cause this...) and mess up everything... So if anyone has fixed bash so that it can actually make children without an actual fork() call, I would really like to know. From amiga-gcc-port-owner@nic.funet.fi Sat Jun 3 22:29:42 1995 Received: from larry.infi.net ([198.22.1.114]) by nic.funet.fi with SMTP id <90815-4>; Sat, 3 Jun 1995 22:28:11 +0300 Received: from larry by larry.infi.net with SMTP (8.6.12/Server1.12) id PAA20119; Sat, 3 Jun 1995 15:29:06 -0400 Date: Sat, 3 Jun 1995 15:29:05 -0400 (EDT) From: Derrick Hopkins Subject: Need help using Includes To: GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've just installed GCC (again) and I want to use it to help me to learn C. I've tried to compile an example from a tutorial using gcc -o example6 example6.c But after a short while, the compiler says the included file has an incomplete type. It compiles programs without includes just fine. The Progam i'm tring to compile includes intuition.h and it also opens the intuition and graphics libraries. I had this problem before and I was told that with GCC I don't have to open the libraries, just do my calls and GCC would take care of the rest. I deleted the OpenLibrary() function but I still get the 'incomplete type' error. What am I doing wrong? I did'nt want to post the source because I don't want to fill up alot of e-mail boxes with it but if someone want's to see it, I'd be glad to share it. Thanks D Don't Trust Anyone... [ Derrick Hopkins ] Don't Believe Anything... [ dhopkins@infi.net ] Never Turn Your Back... [ Amiga1200/50/50/6 ] And Always Aim For The Head. [ Atari Jaguar/Lynx ] From amiga-gcc-port-owner@nic.funet.fi Mon Jun 5 15:59:47 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <90158-4>; Mon, 5 Jun 1995 15:55:52 +0300 Received: from math.uwaterloo.ca ([129.97.140.144]) by math.uwaterloo.ca with SMTP id <77139-4>; Mon, 5 Jun 1995 08:55:35 -0400 Date: Mon, 5 Jun 1995 08:55:33 -0400 From: Jeff Shepherd To: Amiga-Gcc List Subject: AmiTCP4.x BETA for Gcc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII After some prodding from some people on IRC, I have released my AmiTCP code for gcc on Aminet. This code will compile with gcc only, all the SAS C dependent stuff has been erased. I used this code when porting Pine. I have also tried it with MuiADT and it works. I have integrated the AmiTCP includes with the gcc includes so the files in the net, netinet, sys, rpcsvc of the netinclude directory can overwrite those in gnu:include. One caveat in using this library. You HAVE to use ixemul.library. Some of the ixemul code is present in the source (dealing with file descriptors). Note however that I don't guarantee that this code will work with all projects. For starters, I know this code does not work with servers (imapd, httpd etc). Maybe someone can fix it so it does. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/index.html The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Mon Jun 5 19:10:26 1995 Received: from cpt6.stm.tudelft.nl ([130.161.186.114]) by nic.funet.fi with SMTP id <90138-2>; Mon, 5 Jun 1995 19:09:28 +0300 Received: by cpt6.stm.tudelft.nl (1.38.193.4/16.2) id AA03407; Mon, 5 Jun 1995 18:13:22 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Maarten D.de Jong ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Subject: From: To: amiga-gcc-port@nic.funet.fi Date: Mon, 5 Jun 95 18:13:22 METDST Mailer: Elm [revision: 70.85] Message-Id: <95Jun5.190928+0300_eet_dst.90138-2+22@nic.funet.fi> Hello there. I've just installed GCC 2.6.3, and tried to compile the famous 'Hello World!' program. However, when I try to compile this: #include int main(void) { printf("Hello, world!\n"); } with `gcc -o test test.c', the preprocessor, compiler and assembler work ok, but the linker fails with an test: Undefined symbol ___builtin_printf referenced from text segment error. I've tried 'grep'-ing all the libs, but none of them has this (rather mysterious) ___builtin_printf function available. So, what am I doing wrong? Maarten (dejong@cpt6.stm.tudelft.nl) From amiga-gcc-port-owner@nic.funet.fi Tue Jun 6 01:31:02 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89139-2>; Tue, 6 Jun 1995 01:30:12 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 6 Jun 95 00:29 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 6 Jun 95 00:26 MET DST Message-Id: Subject: Debug.lib please report To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 6 Jun 1995 00:26:02 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 464 this is a call for all alpha-tester to report the current status of the debug.lib. i didnt hear anything and stil i cant check anything self because my amiga broke down :( walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Tue Jun 6 12:34:22 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <89905-3>; Tue, 6 Jun 1995 12:31:54 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA07129 (5.65c8/IDA-1.4.4 for ); Tue, 6 Jun 1995 11:31:37 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA14598; Tue, 6 Jun 95 11:31:36 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506060931.AA14598@sunserv.IZFM.Uni-Stuttgart.DE> Subject: include problem To: dejong@cpt6.stm.tudelft.nl Date: Tue, 6 Jun 1995 11:31:36 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Jun5.190928+0300_eet_dst.90138-2+22@nic.funet.fi> from "dejong@cpt6.stm.tudelft.nl" at Jun 5, 95 06:13:22 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 957 > > test: Undefined symbol ___builtin_printf referenced from text segment > > error. I've tried 'grep'-ing all the libs, but none of them has this (rather > mysterious) ___builtin_printf function available. So, what am I doing wrong? > You're using SAS's header files. I guess you've copied the whole include: directory to gnu:os-include? Then it's likely that you've already trashed all files in gnu:os-include/proto. You should better delete the whole gnu:os-include directory and re-install it in that case. Then to install both compilers simultaneously you should: 1. move (or copy) the normal Commodore includes (all _subdirectories_ except proto/ pragma/ and sys/ if I remember right) to gnu:os-include. Don't copy _simple files_. Let them stay in include: where they are. Then 2. (only if you chose to move) multi-assign gnu:os-include to include: (add "Assign include gnu:os-include add" to your user-startup) Hope it helps Matthias From amiga-gcc-port-owner@nic.funet.fi Tue Jun 6 12:34:56 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <89907-4>; Tue, 6 Jun 1995 12:33:45 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa13013; 6 Jun 95 10:26 +0100 Received: from flevel.demon.co.uk by post.demon.co.uk id bo20252; 6 Jun 95 10:26 +0100 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA003u4; Tue, 6 Jun 95 09:35:55 GMT Date: Tue, 6 Jun 95 09:35:55 GMT Message-Id: <9506060935.AA003u3@flevel.demon.co.uk> Message-Id: <20c7e279.7a122-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Sun NFS for AmiTCP Hi, I thought I'd let you know: The good news: Ive got an NFS server for the Amiga and it works :-))))) The bad news: It's from some commodore developer files (From CIX) so I can't upload it :-( It causes a number of enforcer hits :-( It's quite basic, it stores all the file names from any drive you want to export in a file. This means it takes a long time to get started. You have to re-mount any volumes which you intend to write to, on more than one machine, through the nfs. This means the servers access to shared partitions get slowed down :-( Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Jun 6 12:37:11 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89514-3>; Tue, 6 Jun 1995 12:36:44 +0300 Received: from disperse.demon.co.uk by funet.fi with SMTP (PP); Tue, 6 Jun 1995 12:36:50 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id aa13013; 6 Jun 95 10:26 +0100 Received: from flevel.demon.co.uk by post.demon.co.uk id bo20252; 6 Jun 95 10:26 +0100 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA003u4; Tue, 6 Jun 95 09:35:55 GMT Date: Tue, 6 Jun 95 09:35:55 GMT Message-Id: <9506060935.AA003u3@flevel.demon.co.uk> Message-Id: <20c7e279.7a122-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Sun NFS for AmiTCP Hi, I thought I'd let you know: The good news: Ive got an NFS server for the Amiga and it works :-))))) The bad news: It's from some commodore developer files (From CIX) so I can't upload it :-( It causes a number of enforcer hits :-( It's quite basic, it stores all the file names from any drive you want to export in a file. This means it takes a long time to get started. You have to re-mount any volumes which you intend to write to, on more than one machine, through the nfs. This means the servers access to shared partitions get slowed down :-( Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Jun 6 12:50:17 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89207-3>; Tue, 6 Jun 1995 12:49:45 +0300 Received: by colombo.telesys-innov.fr; Tue, 6 Jun 1995 11:52:03 +0100 From: Philippe BRAND Message-Id: <199506061052.LAA02400@colombo.telesys-innov.fr> Subject: New beta available To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Tue, 6 Jun 1995 11:52:00 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1024 New gcc beta gcc-950606.lha is available both on my site and on nic.funet.fi (prefered). It includes new sh without memory leaks, an ixemul.library 40.6 68000 soft-float, fixed as, fixed ld, and gcc 2.7.0 beta with -mstackcheck and -mstackextend new keywords, -resident flag supposed to work. ftp.telesys-innov.fr:/pub/amigados-gnu/beta/gcc-beta-950606.lha ftp.funet.fi:/pub/amiga/gnu/beta/gcc-beta-950606.lha Note: you need ixemul-40.6 beta distribution also. Note: Do you think there's still a need for a 68020+ version of gcc ? PLEASE TEST THIS MINI-DISTRIBUTION ASAP AND REPORT. DO *NOT* SPREAD THIS VERSION. Also gcc-apurify is now in alpha-state. get sas-based archive on Aminet to know what it can do. A beta version will be available pretty soon, and at last I think it will be integrated in gcc, and a new keyword will activate it. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Jun 6 12:56:17 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89299-2>; Tue, 6 Jun 1995 12:55:48 +0300 Received: by colombo.telesys-innov.fr; Tue, 6 Jun 1995 11:55:31 +0100 From: Philippe BRAND Message-Id: <199506061055.LAA02418@colombo.telesys-innov.fr> Subject: Re: include problem To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Tue, 6 Jun 1995 11:55:30 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9506060931.AA14598@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Jun 6, 95 11:31:36 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 667 Matthias Fleischer writes: > Then to install both compilers simultaneously you should: > 1. move (or copy) the normal Commodore includes (all _subdirectories_ except > proto/ pragma/ and sys/ if I remember right) to gnu:os-include. Don't > copy _simple files_. Let them stay in include: where they are. Then > 2. (only if you chose to move) multi-assign gnu:os-include to include: > (add "Assign include gnu:os-include add" to your user-startup) To be included in GCC FAQ ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Jun 6 19:12:02 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89357-1>; Tue, 6 Jun 1995 19:08:16 +0300 Received: by theseas.ntua.gr with UUCP; Tue, 6 Jun 1995 19:07:11 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <076m@kriton.UUCP>; Tue, 6 Jun 95 19:00:53 EET Date: Tue, 6 Jun 95 19:00:53 EET Message-Id: <9506061700.076m@kriton.UUCP> In-Reply-To: <199506061052.LAA02400@colombo.telesys-innov.fr> (from Philippe BRAND ) (at Tue, 6 Jun 1995 11:52:00 +0100 (BST)) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1010 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@lists.funet.fi Subject: Re: New beta available Hi Philippe (Philippe BRAND), in <199506061052.LAA02400@colombo.telesys-innov.fr> on Jun 6 you wrote: > Note: Do you think there's still a need for a 68020+ version of gcc ? Gcc is a CPU intensive program, so every bit of optimization should help. It might be useful, however, if the 68020+ version was compiled with -msoft-float, so that it could run on FPU-less 1200s (I would think that floating-point number manipulation is only a small part of the compilation process). If the 68020+ version does go away, please make sure that you mention in a prominent place (e.g., the what's new section in README-2.7.0) how to switch from a 68020 to a 68000 setup (e.g., delete gnu:lib/mc68020-cbm-amigados). Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Just remember what curiosity did to the cat." "Why do you think they have nine lives? And why do you think Time Lords have twelve?" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jun 6 19:48:28 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89206-4>; Tue, 6 Jun 1995 19:39:48 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA22790 (5.65c+/IDA-1.4.4); Tue, 6 Jun 1995 18:39:01 +0100 Received: by alfa.ist.utl.pt; (5.65/1.1.8.2/03Jun94-0521PM) id AA08114; Tue, 6 Jun 1995 18:40:01 GMT Date: Tue, 6 Jun 1995 18:40:01 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: amiga-x11@nic.funet.fi Cc: amiga-gcc-port@nic.funet.fi Subject: Compiling Xclients with gcc/SASC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > There isn't, as far as I could tell, a way to quit twm. Shure there is! Press the mouse button away from any window. A menu will appear! Exit is the last option. > As for the other question, I suppose the answer is to get the >Xincludes and link via gcc. Being a SAS/C user myself, this may >cause problems... There is no big deal in compiling or linking Xclients. You must have Xincludes and Xlibs (Xaw,Xmu,Xext,Xt,X11). Compile the thing with gcc and link the usual way specifying these libs before -lc -lamiga. To compile Xclients through SAS/C its not so direct.... There are several problems with the process whatever steps you take. If you compile with SAS/C and link with ld (providing you translate .o`s with hunk2gcc) a problem arises: SAS/C generates several external refs for math functions gcc libs do not know (_CX***). However, if the problem does not use floats, it will work. Compiling with SC and linking with SLINK should be OK as long as you compile all X11R5 and libc (stubs for ixemul) with SAS/C as well. Startup code will have to be managed as well.... Compile X11R5 to be in a shared.library means a lot of work.... i`m trying to solve part of it.... - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Tue Jun 6 20:15:42 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89374-3>; Tue, 6 Jun 1995 20:14:04 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA23427 (5.65c+/IDA-1.4.4 for ); Tue, 6 Jun 1995 19:11:21 +0100 Received: by alfa.ist.utl.pt; (5.65/1.1.8.2/03Jun94-0521PM) id AA22885; Tue, 6 Jun 1995 19:12:22 GMT Date: Tue, 6 Jun 1995 19:12:21 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Philippe BRAND Cc: Amiga-Gcc Liste Subject: Re: New beta available In-Reply-To: <199506061052.LAA02400@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Philippe BRAND wrote: > New gcc beta gcc-950606.lha is available both on my site > and on nic.funet.fi (prefered). It includes new sh without memory leaks, > an ixemul.library 40.6 68000 soft-float, fixed as, fixed ld, and gcc 2.7.0 > beta with -mstackcheck and -mstackextend new keywords, -resident flag > supposed to work. > > ftp.telesys-innov.fr:/pub/amigados-gnu/beta/gcc-beta-950606.lha > ftp.funet.fi:/pub/amiga/gnu/beta/gcc-beta-950606.lha > ... > Philippe BRAND > phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB > AmigaDOS GNU Project, AmigOS Net/WWW coordinator. > http://www.telesys-innov.fr/about/PhB.html I`m kinda lost... Is this ixemul 40.6 a Markus Wild ixemul or is it a 40.4 successor? I suppose Markus Wild last ixemul is 39.48 so I suspect this one is NOT his. BIG PROBLEM! Have you seen the specs of ixemul 40.4? Pretty good! Besides it is compatible with V39.47 (and not with 40.4) which was always prefered due to problems that we all know.... If all of this is true, then I believe it would be good to compile GCC2.7.0 to work with 39.48 as well! - Pedro Teixeira - PS: As it is obvious, my mail on an agreement between M.Wild and P.Brand has not been taken to any consideration. Since these appears to be a war going on between V39.47 & V40.4 successors I think that, since they report to totaly diferent libs (not compatible), ixemul 40.4 and 40.6 (arrived after) SHOULD CHANGE NAME. That way, anyone would know what lib a program was refering to, it is stupid to be devolping a e.g. Xclient and have to build a OpenLibrary() by hand to consult a database with: - 39.47 Yes - 40.4 No - 39.48 Yes - 40.6 No ... From amiga-gcc-port-owner@nic.funet.fi Tue Jun 6 22:02:00 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89449-3>; Tue, 6 Jun 1995 22:00:14 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sJ4ft-0004nYC; Tue, 6 Jun 95 12:52 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New beta available To: l36599@alfa.ist.utl.pt (Pedro Miguel Sequeira Teixeira) Date: Tue, 6 Jun 1995 12:52:29 -0700 (MST) Cc: phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi (none) In-Reply-To: from "Pedro Miguel Sequeira Teixeira" at Jun 6, 95 07:12:21 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2483 > > New gcc beta gcc-950606.lha is available both on my site > > and on nic.funet.fi (prefered). It includes new sh without memory leaks, > > an ixemul.library 40.6 68000 soft-float, fixed as, fixed ld, and gcc 2.7.0 Philippe sort of jumped the gun here since the current ixemul.library 40.6 was supposed to be just for people on the ixemul mailing list (actual ixemul developers) to beta test. I am merging the 40.XX and 39.XX strains to eventually produce a 41.0. There is still a lot of work and testing to be done to complete the merge. The current 40.6 version has additional entry points and thus programs compiled with the new crt0 and libc.a for 40.6 will crash if used with a previous 40.X version (40.4 for example). You do get a requester notifying you of the incompatibility, but when you click continue (the only option currently) a crash is almost guaranteed. Before public release, or even extensive testing past the ixemul beta testers, the version number needs to be bumped to 41.0. Since there are a number of bug fixes in this 40.6 version, and since some of the additions are necessary to beta test the new gcc options for stack checking and stack growth, I guess I will go ahead and bump the version now to 41.0, build and test a release, and then make it generally available. Additional changes made as a result of the 40.X and 39.XX merging can be added to 41.X versions or the number can be bumped again if more fundamental changes are necessary. > I`m kinda lost... Is this ixemul 40.6 a Markus Wild ixemul > or is it a 40.4 successor? It is a merging of features from both. > I suppose Markus Wild last ixemul is > 39.48 so I suspect this one is NOT his. BIG PROBLEM! As far as anybody currently working on ixemul knows, the complete buildable source for 39.48 was never made available and I seem to recall Markus saying at one point that his copy was lost. > PS: As it is obvious, my mail on an agreement between M.Wild and P.Brand > has not been taken to any consideration. What agreement and mail. Please send me a copy of any mail you have archived since I'm coordinating the current ixemul developers. > Since these appears to be a > war going on between V39.47 & V40.4 successors I think that, since No war, we are trying to eliminate the differences and merge to a single strain that all new versions can be based on. However it is slow and tedious work, and each step in the merge has to be verified by extensive testing. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Jun 7 01:12:38 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89026-4>; Wed, 7 Jun 1995 01:11:07 +0300 Received: by colombo.telesys-innov.fr; Wed, 7 Jun 1995 00:03:37 +0100 From: Philippe BRAND Message-Id: <199506062303.AAA05538@colombo.telesys-innov.fr> Subject: Re: New beta available To: fnf@amigalib.com (Fred Fish) Date: Wed, 7 Jun 1995 00:03:36 +0100 (BST) Cc: l36599@alfa.ist.utl.pt, amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi In-Reply-To: from "Fred Fish" at Jun 6, 95 12:52:29 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1133 Fred Fish writes: > Philippe sort of jumped the gun here since the current ixemul.library > 40.6 was supposed to be just for people on the ixemul mailing list > (actual ixemul developers) to beta test. I am merging the 40.XX and > 39.XX strains to eventually produce a 41.0. There is still a lot of > work and testing to be done to complete the merge. Hum... seems I've made The Error of the year here :-) My appologies. I'll pay attention next time to emails distribution list. > only option currently) a crash is almost guaranteed. Before public > release, or even extensive testing past the ixemul beta testers, the > version number needs to be bumped to 41.0. Yep. Let's act as if nobody has seen my error. I remove ixemul.library from beta gcc distribution. > What agreement and mail. Please send me a copy of any mail you have > archived since I'm coordinating the current ixemul developers. Yes: what mail ? I'm curious on this point... -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Jun 7 13:57:08 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89939-4>; Wed, 7 Jun 1995 13:52:24 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA22143; Wed, 7 Jun 1995 12:52:23 +0200 Date: Wed, 7 Jun 1995 12:52:19 +0200 (MET DST) From: Kamil Iskra Subject: Re: New beta available To: kyrimis%theseas.ntua.gr@ernie.icslab.agh.edu.pl cc: phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi In-Reply-To: <9506061700.076m@kriton.UUCP> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Kriton Kyrimis wrote: > Gcc is a CPU intensive program, so every bit of optimization should help. It > might be useful, however, if the 68020+ version was compiled with > -msoft-float, so that it could run on FPU-less 1200s (I would think that > floating-point number manipulation is only a small part of the compilation > process). It must be VERY small part, because I personaly do not have FPU and use 68020 version of GCC. Without any problems that could be explained by this fact. So, I repeat my (never answered :-( question: is 68020 version safe to use without FPU or not? If not, could sombedy please mail an example source code that should not work with such configuration? I'm really curious about this... / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Jun 7 14:15:26 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90551-3>; Wed, 7 Jun 1995 14:13:29 +0300 Received: by colombo.telesys-innov.fr; Wed, 7 Jun 1995 13:14:30 +0100 From: Philippe BRAND Message-Id: <199506071214.NAA07090@colombo.telesys-innov.fr> Subject: Re: New beta available To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Wed, 7 Jun 1995 13:14:29 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Kamil Iskra" at Jun 7, 95 12:52:19 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 354 Kamil Iskra writes: > It must be VERY small part, because I personaly do not have FPU and use > 68020 version of GCC. Aminet gcc-2.6.3 020 version is NOT compiled with FPU. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Jun 7 14:25:39 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90256-3>; Wed, 7 Jun 1995 14:24:15 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA23631; Wed, 7 Jun 1995 13:26:06 +0200 Date: Wed, 7 Jun 1995 13:26:04 +0200 (MET DST) From: Kamil Iskra Subject: Re: New beta available To: Philippe BRAND cc: Amiga-Gcc Liste In-Reply-To: <199506071214.NAA07090@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 7 Jun 1995, Philippe BRAND wrote: > Kamil Iskra writes: > > > It must be VERY small part, because I personaly do not have FPU and use > > 68020 version of GCC. > > Aminet gcc-2.6.3 020 version is NOT compiled with FPU. So this means that there is a mistake in "README-2.6.3" file, cause it states in several places that the 020-files are "68020+68881" versions. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Jun 7 14:35:33 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <90222-4>; Wed, 7 Jun 1995 14:34:32 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA16884; Wed, 7 Jun 1995 13:34:17 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9506071134.AA16884@decap2.zdv.uni-tuebingen.de> Subject: Re: include problem To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Wed, 7 Jun 1995 13:34:15 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9506060931.AA14598@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Jun 6, 95 11:31:36 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1221 Hello, Matthias, > You're using SAS's header files. I guess you've copied the whole > include: directory to gnu:os-include? Then it's likely that you've > already trashed all files in gnu:os-include/proto. You should better delete > the whole gnu:os-include directory and re-install it in that case. > > Then to install both compilers simultaneously you should: > 1. move (or copy) the normal Commodore includes (all _subdirectories_ except > proto/ pragma/ and sys/ if I remember right) to gnu:os-include. Don't > copy _simple files_. Let them stay in include: where they are. Then > 2. (only if you chose to move) multi-assign gnu:os-include to include: > (add "Assign include gnu:os-include add" to your user-startup) Better suggest creating a directory, say, Sys:Developer/Include where to copy/move the Commo-Includes to. That way it is easy to replace them with new includes. (Assumed that there will be new includes some day. :-) To use this directory - with SAS/C, change the include: assign to assign include: Sys:Developer/Include sc:include - with gcc, use the Installer script and either le it modify the specs file or set environment variables to include Sys:Developer/Include. Jochen From amiga-gcc-port-owner@nic.funet.fi Wed Jun 7 16:42:12 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89637-3>; Wed, 7 Jun 1995 16:18:09 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA04930 (5.65c+/IDA-1.4.4 for ); Wed, 7 Jun 1995 15:07:19 +0100 Received: by alfa.ist.utl.pt; (5.65/1.1.8.2/03Jun94-0521PM) id AA17669; Wed, 7 Jun 1995 15:07:58 GMT Date: Wed, 7 Jun 1995 15:07:58 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Fred Fish Cc: phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi, none Subject: About ix40.6 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Philippe sort of jumped the gun here since the current ixemul.library > 40.6 was supposed to be just for people on the ixemul mailing list > (actual ixemul developers) to beta test. I am merging the 40.XX and > 39.XX strains to eventually produce a 41.0. There is still a lot of > work and testing to be done to complete the merge. Does this mean that it will be possible to compile Xclients, as well as other networking soft or is it planed to be only on ix41? > > I`m kinda lost... Is this ixemul 40.6 a Markus Wild ixemul > > or is it a 40.4 successor? > > It is a merging of features from both. Great! I take everything I sayd about a lack of agreement off! ... Then what kind of implementation are you doint for network? Is the network part fully inside ixemul (if so, compatible to which one?) or it calls another library to deal with it (like socket.library or bsdsocket.library). > As far as anybody currently working on ixemul knows, the complete buildable > source for 39.48 was never made available and I seem to recall Markus > saying at one point that his copy was lost. Are you saying there is something wrong with ss-ixemul-xxxxxx pack? I already suspected... > > PS: As it is obvious, my mail on an agreement between M.Wild and P.Brand > > has not been taken to any consideration. > > What agreement and mail. Please send me a copy of any mail you have > archived since I'm coordinating the current ixemul developers. About a month ago, not knowing about your work in making M.Wild and P.Brand versions compatible, I sended a mail to ixemul mailing list saying what was my opinion on how a new ixemul should be... Well, if you don't recall i'll better send it to you again. > > Since these appears to be a > > war going on between V39.47 & V40.4 successors I think that, since I can see now there is no war. Sorry I spoke too soon. Anyway, I didn't know someone was making any efford in straight things up. X11 is one of the major problems this situation causes. It sounds stupid, at first site that It worked OK on previous versions of ixemul and it doesn't now! By the way, I saw a mail in amiga-gcc-port that was about a new pack of AmiTCP that is only for ixemul. Unlike previous versions, ixemul functions WILL KNOW sockets once the AmiTCP pack i loaded. I supose they are making SetFunction() on read(), write()... of ixemul, testing if the handler reports to a ixemul open or bsdsocket and, if it reports to a socket, process is rerouted to bsdsocket instead of ixemul. This kind of process could be already inside ixemul in ix41. If the program uses sockets, the call enters ixemul, but only for a short time. ixemul then calls AmiTCP to handle the job. This would save you the trouble of integrating the full networking procedures inside ixemul and would allow to upgrade the networking part without changing ixemul. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Wed Jun 7 16:43:14 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90826-3>; Wed, 7 Jun 1995 16:42:33 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sJMBB-0004nYC; Wed, 7 Jun 95 07:33 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: About ix40.6 To: l36599@alfa.ist.utl.pt (Pedro Miguel Sequeira Teixeira) Date: Wed, 7 Jun 1995 07:33:57 -0700 (MST) Cc: fnf@amigalib.com, phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi In-Reply-To: from "Pedro Miguel Sequeira Teixeira" at Jun 7, 95 03:07:58 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 856 > Does this mean that it will be possible to compile Xclients, as well as > other networking soft or is it planed to be only on ix41? I hope so, but I don't have any "known to be working" networking using programs at the moment to compile and test it with. > ... Then what kind of implementation are you doint for network? > Is the network part fully inside ixemul (if so, compatible to which one?) > or it calls another library to deal with it (like socket.library or > bsdsocket.library). It has the networking code from the 39.XX that Leonard worked on. > Are you saying there is something wrong with ss-ixemul-xxxxxx pack? I already > suspected... What is "ss-ixemul-xxxxxx pack"? > This kind of process could be already inside ixemul in ix41. No time now. We need 41.0 for gcc 2.7 beta (and eventual release) testing. Perhaps in 42.0. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Jun 7 18:04:00 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <90626-1>; Wed, 7 Jun 1995 18:01:40 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA00572 (5.65c+/IDA-1.4.4 for ); Wed, 7 Jun 1995 16:59:26 +0100 Received: by alfa.ist.utl.pt; (5.65/1.1.8.2/03Jun94-0521PM) id AA23516; Wed, 7 Jun 1995 17:00:12 GMT Date: Wed, 7 Jun 1995 17:00:11 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Jeff Shepherd Cc: amiga-gcc-port@nic.funet.fi Subject: Re: AmiTCP4.x BETA for Gcc In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 5 Jun 1995, Jeff Shepherd wrote: > After some prodding from some people on IRC, I have released my AmiTCP > code for gcc on Aminet. This code will compile with gcc only, all the SAS > C dependent stuff has been erased. Do you meen we can do a ixemul read() on a bsdlibrary socket?! Where is it on? I need it! - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Wed Jun 7 18:07:54 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <89958-2>; Wed, 7 Jun 1995 18:06:59 +0300 Received: from math.uwaterloo.ca ([129.97.140.144]) by math.uwaterloo.ca with SMTP id <77162-2>; Wed, 7 Jun 1995 11:06:16 -0400 Date: Wed, 7 Jun 1995 11:06:08 -0400 From: Jeff Shepherd To: Pedro Miguel Sequeira Teixeira cc: amiga-gcc-port@nic.funet.fi Subject: Re: AmiTCP4.x BETA for Gcc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 7 Jun 1995, Pedro Miguel Sequeira Teixeira wrote: > On Mon, 5 Jun 1995, Jeff Shepherd wrote: > > > After some prodding from some people on IRC, I have released my AmiTCP > > code for gcc on Aminet. This code will compile with gcc only, all the SAS > > C dependent stuff has been erased. > > Do you meen we can do a ixemul read() on a bsdlibrary socket?! > Where is it on? I need it! Yes you can. It is on aminet in the directory comm/tcp. The filename is ATCP-sdk-40-gc.lha jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Wed Jun 7 18:08:52 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <89504-4>; Wed, 7 Jun 1995 18:08:18 +0300 Received: from math.uwaterloo.ca ([129.97.140.144]) by math.uwaterloo.ca with SMTP id <77157-2>; Wed, 7 Jun 1995 11:07:36 -0400 Date: Wed, 7 Jun 1995 11:07:35 -0400 From: Jeff Shepherd X-Sender: jsshephe@math.uwaterloo.ca To: Amiga-Gcc List Subject: AmiTCP for gcc amended. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Due to my shortsightedness (I must be asleep this week), I forgot two include the clib directory in the archive. A little explanation on the directory structure: There are a bunch of directories in netinclude/ - sys, net, netinet, protocols, rpc, rpcsvc, amitcp - the files in these directories go to the corresponding gnu:include directories. The amitcp directory is new. The proto, fd, libraries, devices and clib go into your gnu:os-include directory (or wherever you have the Commodore includes). Also any files in the netinclude directory go into the gnu:include directory. Here are the missing files: ------------------CUT HERE-------------------- begin 777 clib.lha M)=LM;&@U+=`$```E#0``9ZA]'@``#VYE=&QI8E]P0 MP/WL!1^]'IOQ<@,4^1>-$KFO;-PY>#M#CX?8'%[O=QVN*W:M^P/7;Y/;Q\GM MX@EE5-,L+WSE#T^BQ:@L!!O=A&S]`B0C:ZE&!.]7@(DWMX.I3_DUV8,+9)S/PNJ[52-ESJ8_@ M"^R'AI*>:20#2,P.5,IW:J(A5JQ8JA!>_:]<1B^/9>.#"V0R3Q*#\5?-4-HV MXX'XX=QE-HF_PQN7;WOVF,(COJ8FRXR8PZ>%X=* M\;DNT?2Q65LSQCARU=QF M[K['&[5W.D(P&U+7Q_T7^K8Q0HX:I'VELW,5=&JN[U]T3HFS6HFS>9;@N\V# MHVF#HDNR?:66'%S;H//3K@Y68"6DHNXO>2>^I;TB^6"]S7=A=(+X.4F+686H M`3.]JV+?PPE5TKYO4Y@+8,@4*6H'W41A!A.9/.F97+8Z>OJZ`)I+Z/7; MMH;*IE`Z:SVM7%ZN6P7T;BF00R-F5WD),9#E;\F4,23!'VLPC<(7-+@@8G.K M@"=<2'E\\`9#Y9*T#%/GSZ*$#W4D[T&13Z>=2RV4M@!$-'/O(*:;305//O(: MJ?S0=736[,>4H*:7:H[V9&LR!&N074(+G;$JDP)#KBH,):'D,#K2@@2N!;'$ MG1I30;`]FEH2`=J9`@?+P!J!_1HYK('_26E)Y1GJUU"-.6E('9(;&E@TF4F) M4>H*TU$259VZGD\!.MNS%SC$W(67W93[X4T_J)*>:/539LIKK(/O3;XD9L(V M%\E"[-DG@A#X93#63E,-,4[)EY&*B,>Y7\3JF'011`@;@!AP>?0T<4P-3_GW MK1'?.&NY#5+D@>`0=FN`='<(`=)2;RN$KC3/(_7*7L(*.KSWD(LG".$56+4? M:6YHS03P&_/<=_[U)!0"F*44.UWME:YYQ(@3(7.E M;'<:Y,,*I:7!.U'6&I866C!U5>B.'M,43AJ="#*FM&O11J@0.5Q;=+H>`DV* M(!I.59%Q;#`@%FG$_J)I_`F$!9IQHU$Q:!=)&/7=D$J`,CNF_VBEH M8_"#SIFS'-"4N-*]+(V[QV,&WJ!@1"F1#VHZ/AB\-D`^1+$"VS M0OG3))H\"4DWMQH&=_?&9L'DUJ(/'JL"-'\5L3%8PL%=(H\O!`MS)C3# MFJ/J-045RH-KQ6I/S0O4;@N&L\=GKAF'*EPU!#SFU;9RUBA`@F)CBI0M;.DV MFW+.8:LJJRBHTY%-9806MG#@G!CGCC4[OS0R*9D?EU([Y.6_YCEZVFY+S5^`/U2\!1"(&UO!06X#&%M%C%J12!CG1UY.J"'J#WK531=LJ?YYG$MJEZPT*FI)"DL#W#L& M95$XI*Z$*8[WI>8YI@>;L:HV"O8,CJV`UF+F#,,9;J^)A')$=>&(JIEE6WV4 M224?_5=DS?73GUB>21?C7;IF^RF2=4OF0OF<$B)>E>^88U4EM>015SP-4WK; MHB99&70ED:\B"XMJ5[X&U:"'O@CV#03H)N)N[UTMR&2)QV'F"X[X*I+E-^&\ M=8+@1G;H;Z'06BK-FU!:@S_/-F!B-*6V,YV:PH4U$"MVG0;JTJ5I[K2W4H;$ MSVI&Q$A6;W7C?+B-^;'O'J.T8L?1K-66ZUVA,3]2N_'*#UQ6@H7561[MPU9D%J;=\-2F5X=\#[$V-W%0>RI!?)H3C<$O!7@.+M4M5 MQ8DZ4NRR,@3*3IX))_$'_O?,D_3+YOC>2?O+CN._B2_W+@EX$EH4R(E=P^\O MYHMX3"5\+6QH-2WK!0``:!(``"E^D!X```]S;V-K971?<')O=&]S+FB7CP21 M<]O1IMZ:^-3T`]_;?`,(066Q+*W99(DA2M:`"C=UU2R0F-\P=C.Y_ON"4WH: MWI"^[[NY\-D(22ZR[;Q,EDLEEO#W8=8VW''WDED-&60G+SO+I*G+/0=)T7-%O63CN>@G%Z?3QW M>+S7?-QDXOK]7F]/JXN,GPHA^$)+_QG)Y?'8NVK!+7BR*-4[)RH(>0E[3+!R MY+KV0F9$:TO?91+GT))^@J+:98*#ZI[:B3Q>(F(J>H]'2 M1\\VI,IS()S%UEF//I*9-LCQHKC"F]-,04B@E!4%HUEC4*NV+#=(;_XW^7+! M[\E\=&9313:HRD^TOQ+%=%NKFC[K'D*:.61QH3VP/<[T'ORP7L#T%_#6=`R4 MTJ=EU,.>5)=/PWWZ88'X.93`WLCS@0KID*U(7DE-&3, M'BD#SRH24Q)A]4A;T419TDA'TZ,!PW/X#<4.DK1Q@QU#\A2T-'SACK'O!N9EO1QT$5NMEA##N%MEA$<9 M>2I.^PZ$\FQJ?T!ES;-[`K(Q4M)'6J0(P4[D,"GX(42%J$$AWH-\)UG(14\G M!"K(\AZ$N(YPRUZ8JXK7(@>/+@B6DNK3F+143B`J*>:"'-,5^7\Q1T:594!E MWZ1U:B]VH;T;1LNV,G8B8^>\36@<'6'(T*R:F4S9;ZOL$O5,F):BVJ5E`8$T:HEHA6P9+2FM6=JPS%,PZ7-XT\5ZS0Q=(,@P M>N<9H_L2RO*S96%R69//_S**GEW'46B$"\)K5EP%2\$DT.=&TU@/_9O;L!T[ M?-FTG9KH?@_53I4WD4J'S*[^UX@Y(QW^ M8VK-AM9Y8R6@%ZX7$[FQP?ZE>"/M=R05.OX1QNBEM;HIMO-U_AX)Z\>),S^V M>FV3V\^/%@#J7__J*A+=[H:,\[959CH+49,#^Z&4.3:9LN!I(P8J2/*'582U M06&.L!U4!1UU@0I09TJ`AILQP5450:9A(.&`^I(N':TPHZ5,98%J.;5/YV,: M.>2/BMD9A\ZXSNOY4('G&G3'9AD$@>9RT565FK'<@>-R!%[A>NG8/'F2'0_5L+ M+&Q_V]'0Y%]'8XMO1X.?H"#F&F%=FW["L5342JK]\4KP+(4GO,U00-)&`Y>81V&' MI**K6#`$V%&8T.XJYS0XY+/@B08KL'*?,`_-R;GO9#"J@-#>'Q6JZ8NRMO%< M"8('P*NS2!W;A3S^JW:<@P:1J"IIL:T#N66\N%8#KR.DG!/C;,L,74YW8H=W M<`,.7[H-5//O,AJ`[--*8S<9E,G7N.OAL73B,A M`GHEW-))I2R06U3Q/"8KU+^1>/!\-LV-P)MM@=1OU`LMBUY>0;85>/G9:^KR MWF6NJ\O*VUL8A"N-ETF=67"JT17FZ!M3W8_6-J*[/M*GZ;3)J);W4-`X/F!Q M#6CT@F]J+05/!/6`Q-LYZ3=TK78$J/:I%MX/K)W1N]@3(-D>YLW1#=H5EC;2 ='=8V=;4]K>/.VI7$!NS.OWQ]JZ+__=_\BH(Q@`#1 ` end ------------------CUT HERE-------------------- jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/index.html The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Wed Jun 7 19:47:40 1995 Received: from DBSTU1.RZ.TU-BS.DE ([134.169.1.1]) by nic.funet.fi with SMTP id <90554-2>; Wed, 7 Jun 1995 19:43:55 +0300 Received: from rzab0.rz.tu-bs.de by DBSTU1.RZ.TU-BS.DE (IBM VM SMTP V2R2) with TCP; Wed, 07 Jun 95 18:42:27 MEZ Received: by rzab0.rz.tu-bs.de (1.37.109.4/15.6) id AA18450; Wed, 7 Jun 95 18:42:36 +0200 From: Sven Heithecker Subject: sourcelevel-debugger where ? To: amiga-gcc-port@nic.funet.fi (Sven Heithecker) Date: Wed, 7 Jun 1995 18:42:35 +0100 (MESZ) X-Mailer: ELM [version 2.4 PL11] Content-Type: text Content-Length: 352 Message-Id: <95Jun7.194355+0300_eet_dst.90554-2+6@nic.funet.fi> hi ! Is there any Sourcelevel-Debugger for gcc out ? I have heard something about gdb, this * seems * to be a debugger, but i dont know where to get it ! I have searched in Aminet with 'gnu','debug','gdb', but i didnt found anything. So long, ____ |_||_ Ceterum Censeo MEGAHARD Esse Delendam | | _| HTS Sven Heithecker s.heithecker@tu-bs.de From amiga-gcc-port-owner@nic.funet.fi Thu Jun 8 08:29:09 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <90859-1>; Thu, 8 Jun 1995 08:27:13 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA09675 (5.65c+/IDA-1.4.4 for ); Thu, 8 Jun 1995 07:26:41 +0100 Received: by alfa.ist.utl.pt; (5.65/1.1.8.2/03Jun94-0521PM) id AA23172; Thu, 8 Jun 1995 07:27:45 GMT Date: Thu, 8 Jun 1995 07:27:45 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Jeff Shepherd Cc: amiga-gcc-port@nic.funet.fi Subject: Unresolved externals with AmiTCP In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I already took the AmiTCP-4.0 beta for gcc and tryed it but, for some reason I haven't been able to link successfuly. My compile line is: gcc -v -D__AMITCP__ -D__NetBSD__ -DX11_t -DTRANS_CLIENT -DTCPCONN -DX_LOCAL E -Iunix:AmiTCP-4.0-gcc/netinclude -I../xtrans -I/inc6 -I/inc6/extensions -c x11trans.c ... ...compiles with absolutely no problem. When I get to compile gcc -Lunix:AmiTCP-4.0-gcc/src/netlib -LUniX:AmiTCP-4.0-gcc -LUSER:Xdev/X11R6 -lm -lX116 -lc -lamitcp .... I get: (xlibint.o): Undefined symbol _gethostname referenced from text segment (x11trans.o): Undefined symbol _getsockname referenced from text segment (x11trans.o): Undefined symbol _getpeername referenced from text segment (x11trans.o): Undefined symbol _socket referenced from text segment (x11trans.o): Undefined symbol _setsockopt referenced from text segment (x11trans.o): Undefined symbol _inet_addr referenced from text segment (x11trans.o): Undefined symbol _gethostbyname referenced from text segment (x11trans.o): Undefined symbol _getservbyname referenced from text segment (x11trans.o): Undefined symbol _connect referenced from text segment (x11trans.o): Undefined symbol _shutdown referenced from text segment (x11trans.o): Undefined symbol _close referenced from text segment (x11trans.o): Undefined symbol _gethostname referenced from text segment (xrm.o): Undefined symbol _close referenced from text segment (xrm.o): Undefined symbol _close referenced from text segment (xrm.o): Undefined symbol _close referenced from text segment What am I doing wrong?????? - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Thu Jun 8 12:04:02 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <90092-2>; Thu, 8 Jun 1995 12:02:13 +0300 Received: by disperse.demon.co.uk id aa14883; 8 Jun 95 9:59 +0100 Received: from post.demon.co.uk by disperse.demon.co.uk id aa14801; 8 Jun 95 9:58 +0100 Received: from flevel.demon.co.uk by post.demon.co.uk id ac18555; 8 Jun 95 9:57 +0100 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA00491; Thu, 8 Jun 95 09:45:40 GMT Date: Thu, 8 Jun 95 09:45:40 GMT Message-Id: <9506080945.AA00490@flevel.demon.co.uk> Message-Id: <20ca87c3.186a0-dev@flevel.demon.co.uk> In-Reply-To: <95Jun7.194355+0300_eet_dst.90554-2+6@nic.funet.fi> (from Sven Heithecker ) (at Wed, 7 Jun 1995 18:42:35 +0100 (MESZ)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: y0000135@ws.rz.tu-bs.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: sourcelevel-debugger where ? Hi Sven, > Is there any Sourcelevel-Debugger for gcc out ? > > I have heard something about gdb, this * seems * to be a debugger, but i dont > know where to get it ! I have searched in Aminet with 'gnu','debug','gdb', > but i didnt found anything. Yes, gdb is available. The last I heard was that it wasn't much use because because nobody has written the ptrace() function :-( Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk Ami-FileSafe (AFS) ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Jun 8 20:56:53 1995 Received: from pythia.forthnet.gr ([139.91.1.1]) by nic.funet.fi with SMTP id <88973-4>; Thu, 8 Jun 1995 20:54:29 +0300 Received: from acrogate.UUCP by pythia.forthnet.gr via FORTHnet with UUCP; id AA18033 (5.65c/FORTH-ICS-3.0-MHS-7.0); Thu, 8 Jun 1995 20:55:46 +0300 Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0sJnGl-000AzWC; Thu, 8 Jun 95 19:29 GMT Message-Id: Date: Thu, 8 Jun 95 19:29 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Subject: Questions... Hello to everyone! I am a newcomer in GCC. I used to program in Lattice C and SAS C v6.50 but since this is no longer supported, I decided to try GNU C/C++. I would like to congratulate everyone that helped to port this EXCELLENT system to the Amiga. Keep up the good work :-) I would like to ask a few questions, because I am a bit puzzled by the docs: 1. Does gcc support the creation of OVERLAYED executables? If yes, how can I produce one (currently, I'm developing a big program that I would like to make it overlayed, so that it doesn't occupy lots of RAM). 2. I have an Amiga system with the 68000 processor and 5MB of RAM. Can I use GNU C/C++ on this config? 3. Does GNU C allowes the creation of executable programs that DO NOT require ixemul.library? Thank you very much. -Manolis. From amiga-gcc-port-owner@nic.funet.fi Thu Jun 8 22:38:31 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89374-1>; Thu, 8 Jun 1995 22:36:43 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id UAA19161; Thu, 8 Jun 1995 20:35:25 +0100 From: Lars Hecking Message-Id: <199506081936.UAA20950@krakow.nmrc.ucc.ie> Subject: Re: Questions... To: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) Date: Thu, 8 Jun 1995 20:36:15 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Manolis Pappas" at Jun 8, 95 07:29:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 730 > 1. Does gcc support the creation of OVERLAYED executables? If yes, > how can I produce one (currently, I'm developing a big program that > I would like to make it overlayed, so that it doesn't occupy lots of RAM). I'm pretty sure this is not implemented (yet? ;) Looks like a significant amount of work to be done for ld. > 2. I have an Amiga system with the 68000 processor and 5MB of RAM. Can > I use GNU C/C++ on this config? You _might run into problems with g++ or the -On options, but if you run without WB, you should fare well. And, hey, I do not want to mention speed on a 68000 system ;) > 3. Does GNU C allowes the creation of executable programs that DO NOT > require ixemul.library? gcc -noixemul From amiga-gcc-port-owner@nic.funet.fi Thu Jun 8 23:04:56 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89901-3>; Thu, 8 Jun 1995 23:02:23 +0300 Received: by theseas.ntua.gr with UUCP; Thu, 8 Jun 1995 23:04:14 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <077b@kriton.UUCP>; Thu, 8 Jun 95 22:55:36 EET Date: Thu, 8 Jun 95 22:55:36 EET Message-Id: <9506082055.077b@kriton.UUCP> In-Reply-To: <199506081936.UAA20950@krakow.nmrc.ucc.ie> (from Lars Hecking ) (at Thu, 8 Jun 1995 20:36:15 +0100 (BST)) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1289 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Cc: mpap@acrogate.ath.forthnet.gr Subject: Re: Questions... > > 1. Does gcc support the creation of OVERLAYED executables? If yes, > > how can I produce one (currently, I'm developing a big program that > > I would like to make it overlayed, so that it doesn't occupy lots of RAM). > > I'm pretty sure this is not implemented (yet? ;) Looks like a significant > amount of work to be done for ld. There *might* be a way to do overlays with gcc-compiled code, if one converts object files to amiga format using sobja, and links with slink. I assume that this will require linking with the SAS/C libraries, and therefore compiling with the SAS/C header files. (BTW, I seem to remember that sobja produces 4 times more BSS than necessary--a harmless but wasteful bug). Seriously, are overlays really necessary? The only overlayed program I've ever used on the Amiga was DPaint, and that had an option to load everything in memory, which was on by default. I haven't used overlays since my PDP-11 days, where programs were limited to 64k code+data. Those were the days! -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If you can help anybody, like preventing them from being eaten by a monster, then do so--they might be grateful." ----- From amiga-gcc-port-owner@nic.funet.fi Fri Jun 9 11:55:41 1995 Received: from pythia.forthnet.gr ([139.91.1.1]) by nic.funet.fi with SMTP id <90481-4>; Fri, 9 Jun 1995 11:53:49 +0300 Received: from acrogate.UUCP by pythia.forthnet.gr via FORTHnet with UUCP; id AA19938 (5.65c/FORTH-ICS-3.0-MHS-7.0); Fri, 9 Jun 1995 11:54:43 +0300 Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0sK1hF-000Ay0C; Fri, 9 Jun 95 10:53 GMT Message-Id: Date: Fri, 9 Jun 95 10:53 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Subject: Help! Hello to everyone! I am a newcomer in GCC. I used to program in Lattice C and SAS C v6.50 but since this is no longer supported, I decided to try GNU C/C++. I would like to congratulate everyone that helped to port this EXCELLENT system to the Amiga. Keep up the good work :-) I would like to ask a few questions, because I am a bit puzzled by the docs: 1. Does gcc support the creation of OVERLAYED executables? If yes, how can I produce one (currently, I'm developing a big program that I would like to make it overlayed, so that it doesn't occupy lots of RAM). 2. I have an Amiga system with the 68000 processor and 5MB of RAM. Can I use GNU C/C++ on this config? 3. Does GNU C allowes the creation of executable programs that DO NOT require ixemul.library? Thank you very much. -Manolis. From amiga-gcc-port-owner@nic.funet.fi Fri Jun 9 17:21:18 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89726-4>; Fri, 9 Jun 1995 17:19:40 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA07094 (5.65c+/IDA-1.4.4 for ); Fri, 9 Jun 1995 16:17:18 +0100 Received: by alfa.ist.utl.pt; (5.65/1.1.8.2/03Jun94-0521PM) id AA32283; Fri, 9 Jun 1995 16:18:11 GMT Date: Fri, 9 Jun 1995 16:18:10 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Lars Hecking Cc: Manolis Pappas , Amiga GCC List Subject: Re: Questions... In-Reply-To: <199506081936.UAA20950@krakow.nmrc.ucc.ie> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 8 Jun 1995, Lars Hecking wrote: > > > 1. Does gcc support the creation of OVERLAYED executables? If yes, > > how can I produce one (currently, I'm developing a big program that > > I would like to make it overlayed, so that it doesn't occupy lots of RAM). > > I'm pretty sure this is not implemented (yet? ;) Looks like a significant > amount of work to be done for ld. Besides work there is another important issue. GCC was originaly made for machines running **ix. This system has a very specific type of memory management. Overlays doesnt have anything to do with it. Virtual Memory does! Besides, the biggest problem arround fork() is because AmigaOS doesnt support virtual memory originaly. Extern variables, when creating a new task, are shared istead of copyed. > > 2. I have an Amiga system with the 68000 processor and 5MB of RAM. Can > > I use GNU C/C++ on this config? > > You _might run into problems with g++ or the -On options, but if you run > without WB, you should fare well. And, hey, I do not want to mention > speed on a 68000 system ;) Problems? BIG PROBLEMS! I had to increase my memory to 32Mb(2Chip+2Fast+ 28VMM) just to compile Z80 emulator for XWindows with -O3....! (no workbench running!). - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Fri Jun 9 19:18:36 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89660-4> convert rfc822-to-8bit; Fri, 9 Jun 1995 19:17:08 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA09193 (5.65c+/IDA-1.4.4 for ); Fri, 9 Jun 1995 18:15:38 +0100 Received: by alfa.ist.utl.pt; (5.65/1.1.8.2/03Jun94-0521PM) id AA15623; Fri, 9 Jun 1995 18:16:32 GMT Date: Fri, 9 Jun 1995 18:16:32 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@nic.funet.fi, mpap@acrogate.ath.forthnet.gr Subject: gcc with overlays In-Reply-To: <9506082055.077b@kriton.UUCP> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT On Thu, 8 Jun 1995, Kriton Kyrimis wrote: > > > 1. Does gcc support the creation of OVERLAYED executables? If yes, > > > how can I produce one (currently, I'm developing a big program that > > > I would like to make it overlayed, so that it doesn't occupy lots of RAM). > > > > I'm pretty sure this is not implemented (yet? ;) Looks like a significant > > amount of work to be done for ld. > > There *might* be a way to do overlays with gcc-compiled code, if one converts > object files to amiga format using sobja, and links with slink. I assume that > this will require linking with the SAS/C libraries, and therefore compiling > with the SAS/C header files. (BTW, I seem to remember that sobja produces 4 > times more BSS than necessary--a harmless but wasteful bug). Doesnt work! The problem in linking ixemul clients with slink is the startup code. Thing in sasc startup code and things in gcc startup code would become necessary in the generated program. Another problem in mixing these 2 compilers is the fact that they handle math in a TOTALY diferent way. I´ve already succeeded in compiling xclock with sasc and link with ld but it was only possible because the program is VERY simple and, even so, I had to change things in source. The thing, I beleave, you should do is analyse both sasc startup code and overlay manager source. Then decide how to make them work with gcc. Who knows a simple recompilation will do ?! > Seriously, are overlays really necessary? The only overlayed program I've ever > used on the Amiga was DPaint, and that had an option to load everything in > memory, which was on by default. I haven't used overlays since my PDP-11 > days, where programs were limited to 64k code+data. Those were the days! Hey, 68000 doent handle VMM! Overlays are the only escape ...! - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Fri Jun 9 20:42:42 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <90704-2>; Fri, 9 Jun 1995 20:37:23 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA11106 (5.65c+/IDA-1.4.4); Fri, 9 Jun 1995 19:36:20 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA04463; Fri, 9 Jun 1995 19:37:31 GMT Date: Fri, 9 Jun 1995 19:37:30 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: amiga-gcc-port@nic.funet.fi Cc: amiga-x11@nic.funet.fi Subject: Compiling Xclients with gcc/sasc Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1798360214-802726650=:3006" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1798360214-802726650=:3006 Content-Type: TEXT/PLAIN; charset=US-ASCII --0-1798360214-802726650=:3006 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=ole Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: UmVjZWl2ZWQ6IGZyb20gY2lpc3RyMS5pc3QudXRsLnB0IChbMTkzLjEzNi4x MjguMV0pIGJ5IG5pYy5mdW5ldC5maSB3aXRoIFNNVFAgaWQgPDg5MjA2LTQ+ OyBUdWUsIDYgSnVuIDE5OTUgMTk6Mzk6NDggKzAzMDANClJlY2VpdmVkOiBm cm9tIGFsZmEuaXN0LnV0bC5wdCBieSBjaWlzdHIxLmlzdC51dGwucHQgd2l0 aCBTTVRQIGlkIEFBMjI3OTANCiAgKDUuNjVjKy9JREEtMS40LjQpOyBUdWUs IDYgSnVuIDE5OTUgMTg6Mzk6MDEgKzAxMDANClJlY2VpdmVkOiBieSBhbGZh LmlzdC51dGwucHQ7ICg1LjY1LzEuMS44LjIvMDNKdW45NC0wNTIxUE0pDQoJ aWQgQUEwODExNDsgVHVlLCA2IEp1biAxOTk1IDE4OjQwOjAxIEdNVA0KRGF0 ZToJVHVlLCA2IEp1biAxOTk1IDE4OjQwOjAxICswMDAwIChHTVQpDQpGcm9t OglQZWRybyBNaWd1ZWwgU2VxdWVpcmEgVGVpeGVpcmEgPGwzNjU5OUBhbGZh LmlzdC51dGwucHQ+DQpUbzoJYW1pZ2EteDExQG5pYy5mdW5ldC5maQ0KQ2M6 CWFtaWdhLWdjYy1wb3J0QG5pYy5mdW5ldC5maQ0KU3ViamVjdDogQ29tcGls aW5nIFhjbGllbnRzIHdpdGggZ2NjL1NBU0MNCk1lc3NhZ2UtSWQ6IDxQaW5l Lk9TRi4zLjkxLjk1MDYwNjE4MjA0MS4yOTI0N0FAYWxmYS5pc3QudXRsLnB0 Pg0KTWltZS1WZXJzaW9uOiAxLjANCkNvbnRlbnQtVHlwZTogVEVYVC9QTEFJ TjsgY2hhcnNldD1VUy1BU0NJSQ0KDQoNCj4gIFRoZXJlIGlzbid0LCBhcyBm YXIgYXMgSSBjb3VsZCB0ZWxsLCBhIHdheSB0byBxdWl0IHR3bS4NCg0KU2h1 cmUgdGhlcmUgaXMhIFByZXNzIHRoZSBtb3VzZSBidXR0b24gYXdheSBmcm9t IGFueSB3aW5kb3cuDQpBIG1lbnUgd2lsbCBhcHBlYXIhIEV4aXQgaXMgdGhl IGxhc3Qgb3B0aW9uLg0KDQo+ICBBcyBmb3IgdGhlIG90aGVyIHF1ZXN0aW9u LCBJIHN1cHBvc2UgdGhlIGFuc3dlciBpcyB0byBnZXQgdGhlDQo+WGluY2x1 ZGVzIGFuZCBsaW5rIHZpYSBnY2MuICBCZWluZyBhIFNBUy9DIHVzZXIgbXlz ZWxmLCB0aGlzIG1heQ0KPmNhdXNlIHByb2JsZW1zLi4uDQoNCglUaGVyZSBp cyBubyBiaWcgZGVhbCBpbiBjb21waWxpbmcgb3IgbGlua2luZyBYY2xpZW50 cy4NCllvdSBtdXN0IGhhdmUgWGluY2x1ZGVzIGFuZCBYbGlicyAoWGF3LFht dSxYZXh0LFh0LFgxMSkuIENvbXBpbGUNCnRoZSB0aGluZyB3aXRoIGdjYyBh bmQgbGluayB0aGUgdXN1YWwgd2F5IHNwZWNpZnlpbmcgdGhlc2UgbGlicw0K YmVmb3JlIC1sYyAtbGFtaWdhLg0KDQoJVG8gY29tcGlsZSBYY2xpZW50cyB0 aHJvdWdoIFNBUy9DIGl0cyBub3Qgc28gZGlyZWN0Li4uLg0KVGhlcmUgYXJl IHNldmVyYWwgcHJvYmxlbXMgd2l0aCB0aGUgcHJvY2VzcyB3aGF0ZXZlciBz dGVwcyB5b3UgdGFrZS4NCklmIHlvdSBjb21waWxlIHdpdGggU0FTL0MgYW5k IGxpbmsgd2l0aCBsZCAocHJvdmlkaW5nIHlvdSB0cmFuc2xhdGUNCi5vYHMg d2l0aCBodW5rMmdjYykgYSBwcm9ibGVtIGFyaXNlczogU0FTL0MgZ2VuZXJh dGVzIHNldmVyYWwgZXh0ZXJuYWwNCnJlZnMgZm9yIG1hdGggZnVuY3Rpb25z IGdjYyBsaWJzIGRvIG5vdCBrbm93IChfQ1gqKiopLiBIb3dldmVyLCBpZg0K dGhlIHByb2JsZW0gZG9lcyBub3QgdXNlIGZsb2F0cywgaXQgd2lsbCB3b3Jr LiBDb21waWxpbmcgd2l0aCBTQw0KYW5kIGxpbmtpbmcgd2l0aCBTTElOSyBz aG91bGQgYmUgT0sgYXMgbG9uZyBhcyB5b3UgY29tcGlsZQ0KYWxsIFgxMVI1 IGFuZCBsaWJjIChzdHVicyBmb3IgaXhlbXVsKSB3aXRoIFNBUy9DIGFzIHdl bGwuIFN0YXJ0dXANCmNvZGUgd2lsbCBoYXZlIHRvIGJlIG1hbmFnZWQgYXMg d2VsbC4uLi4NCg0KCUNvbXBpbGUgWDExUjUgdG8gYmUgaW4gYSBzaGFyZWQu bGlicmFyeSBtZWFucyBhIGxvdCBvZg0Kd29yay4uLi4gaWBtIHRyeWluZyB0 byBzb2x2ZSBwYXJ0IG9mIGl0Li4uLg0KDQoJCQkJLSBQZWRybyBUZWl4ZWly YSAt --0-1798360214-802726650=:3006-- From amiga-gcc-port-owner@nic.funet.fi Fri Jun 9 22:36:02 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89733-2> convert rfc822-to-8bit; Fri, 9 Jun 1995 22:34:02 +0300 Received: by theseas.ntua.gr with UUCP; Fri, 9 Jun 1995 22:35:57 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <077q@kriton.UUCP>; Fri, 9 Jun 95 22:31:05 EET Date: Fri, 9 Jun 95 22:31:05 EET Message-Id: <9506092031.077q@kriton.UUCP> In-Reply-To: (from Pedro Miguel Sequeira Teixeira ) (at Fri, 9 Jun 1995 18:16:32 +0000 (GMT)) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT Content-Length: 3478 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: l36599@alfa.ist.utl.pt Cc: amiga-gcc-port@lists.funet.fi Subject: Re: gcc with overlays Hi Pedro (Pedro Miguel Sequeira Teixeira), in on Jun 9 you wrote: > Doesnt work! The problem in linking ixemul clients with slink > is the startup code. Thing in sasc startup code and things in gcc I'm wasn't referring to ixemul clients; that's why I mentioned compiling with the SAS headers (to get the corrrect references to the SAS link libraries, which one would have to use if one used the SAS startup code, which is probably required to use overlays). BTW., it is possible to produce ixemul clients with SAS. Have a look at dev/c/ixemul_DiceSas.lha on Aminet. > Another problem in mixing these 2 compilers is the fact that > they handle math in a TOTALY diferent way. True, but not all programs use math. In addition, although this does not apply in the case of the original poster, who has a 68000, one can work around this problem by compiling with -m68881 to produce inline 68881 code rather than references to compiler-specific subroutines. Here's how to compile a program with gcc and link it with the SAS libraries: #include #include main(int argc, char *argv[]) { double x, y; x = atof(argv[1]); y = atof(argv[2]); fprintf(stdout, "%lg/%lg = %lg\n", x, y, x/y); return 0; } * gcc -m68020 -m68881 -O2 -I/include -D__stdargs= -S t.c Specify the SAS include files, and get rid of the SAS-specific __stdargs keyword. * Edit main.s to remove the gcc-specific "jbsr ___main" line. This is IMPORTANT! The SAS library contains a ___main entry point, and your Amiga will crash if you don't edit this line out. * as -m68000 -m68881 -o t.o t.s The two -m options may seem contradicting: we need -m68881 to recognize the 68881 instructions, and -m68000 to aseemble jbsr instructions into a form that sobja can understand. * sobja -b t.o t.obj Convert from sun to amiga format. * slink from lib:c.o t.obj to t sc sd nd noicons lib lib:scmieee.lib lib:sc.lib Link with scmieee.lib--SAS uses some kind of magic (in the debug hunk?) to figure out which math library is being used, and if this information is missing, weird things happen. > > Seriously, are overlays really necessary? The only overlayed program I've ever > > used on the Amiga was DPaint, and that had an option to load everything in > > memory, which was on by default. I haven't used overlays since my PDP-11 > > days, where programs were limited to 64k code+data. Those were the days! > > Hey, 68000 doent handle VMM! Overlays are the only escape ...! Like I said, I've never used an overlayed program, and I've been using Amigas since 1985, when 68000s were the only processors available. True, the smallest configuration I've ever used was a 1000 with 2+0.5M memory, but this amount can hardly be considered a lot these days. Therefore, I'm still not sure whether overlays are really necessary. (The example of gcc requiring 32M to compile a program is actually evidence to the contrary--even if the compiler required, say, 0.5M to load if it were overlayed, rather than the ~1M it requires without overlays, it would still need to malloc that 32M to compile the program!) Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Only I am real--and I do not exist." ----- From amiga-gcc-port-owner@nic.funet.fi Fri Jun 9 22:36:17 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89907-1> convert rfc822-to-8bit; Fri, 9 Jun 1995 22:33:14 +0300 Received: by theseas.ntua.gr with UUCP; Fri, 9 Jun 1995 22:35:56 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <077l@kriton.UUCP>; Fri, 9 Jun 95 20:26:50 EET Date: Fri, 9 Jun 95 20:26:50 EET Message-Id: <9506091826.077l@kriton.UUCP> In-Reply-To: (from Pedro Miguel Sequeira Teixeira ) (at Fri, 9 Jun 1995 16:18:10 +0000 (GMT)) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT Content-Length: 1560 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Re: Questions... Pedro Miguel Sequeira Teixeira, on Jun 9 wrote: > > You _might run into problems with g++ or the -On options, but if you run > > without WB, you should fare well. And, hey, I do not want to mention > > speed on a 68000 system ;) > > Problems? BIG PROBLEMS! I had to increase my memory to 32Mb(2Chip+2Fast+ > 28VMM) just to compile Z80 emulator for XWindows with -O3....! (no > workbench running!). This is a very glum view, especially as this thread was started by a posting by a newcomer to gcc, who won't feel very encouraged to use it given such comments. Of course there exist programs that require 32M to compile. There also exist programs that require 500K of stack to compile. I should think, however, that both categories are the exception. Based on my experience with gcc (not g++) on my gradually expanding system, I would say: 2+1M: Gcc is of little use--after loading the compiler, and allocating a reasonably large stack, there's not much memory left. 4+1M: These extra 2M make a **** of a difference! Now (almost?) everything compiles. 8+1M: I have yet to find a C program that does not compile due to lack of memory. (No, don't send me examples to the contrary--I know they must exist!) In short, I would think that the critical amount is 4M of fast memory. Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I'm as truthful, honest, and about as boring as they come!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Jun 9 23:56:55 1995 Received: from pythia.forthnet.gr ([139.91.1.1]) by nic.funet.fi with SMTP id <89289-3>; Fri, 9 Jun 1995 23:55:31 +0300 Received: from acrogate.UUCP by pythia.forthnet.gr via FORTHnet with UUCP; id AA23711 (5.65c/FORTH-ICS-3.0-MHS-7.0); Fri, 9 Jun 1995 23:57:00 +0300 Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0sKBXw-000AzaC; Fri, 9 Jun 95 21:24 GMT Message-Id: Date: Fri, 9 Jun 95 21:24 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Subject: Questions about GNU Hello, I finally installed the GCC v2.6.3 package in my system. I have some questions: 1. To test the system, I wrote the simple "Hello world" program and I compiled it. I used the command: gcc -noixemul -O3 hello.c -o hello and I producd an executable of 10K in size, which is unacceptable. How can I reduce the size? 2. If I try to compile a program that uses Amiga include files (e.g intuition.h>, I use the command: gcc -noixemul test.c -o test but no executable file is produced (there are no errors). If I also specify the option -lauto, the compiler produces the executable. Is that normal? 3. I used to program in SAS/C v6.50. How can I convert some .lib files I used into a format accessible by GNU? (I suppose that the .lib files are incompatible with GNU!). Thank you! From amiga-gcc-port-owner@nic.funet.fi Sat Jun 10 01:20:40 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89921-3>; Sat, 10 Jun 1995 01:19:50 +0300 Received: by colombo.telesys-innov.fr; Sat, 10 Jun 1995 00:21:54 +0100 From: Philippe BRAND Message-Id: <199506092321.AAA17874@colombo.telesys-innov.fr> Subject: Re: Questions about GNU To: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) Date: Sat, 10 Jun 1995 00:21:53 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Manolis Pappas" at Jun 9, 95 09:24:00 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1472 Manolis Pappas writes: > 1. To test the system, I wrote the simple "Hello world" program and > I compiled it. I used the command: > gcc -noixemul -O3 hello.c -o hello > and I producd an executable of 10K in size, which is unacceptable. How > can I reduce the size? I like the word "unacceptable"... Gcc, as default, uses library ixemul.library, which is somewhat 200KB large. So in fact add those 200KB to your "unacceptable" 10KB, thus making a 210KB program, which is I think then even more unacceptable :-) Ok to reduce executable size, try compiling with -noixemul flag. Avoid -O3, as it's gonna make your executable larger. Use -O2. > 2. If I try to compile a program that uses Amiga include files (e.g > intuition.h>, I use the command: > gcc -noixemul test.c -o test > but no executable file is produced (there are no errors). If I also specify > the option -lauto, the compiler produces the executable. Is that normal? Could you send output of: gcc -v -noixemul -o test test.c > 3. I used to program in SAS/C v6.50. How can I convert some .lib files > I used into a format accessible by GNU? (I suppose that the .lib files > are incompatible with GNU!). This is explained in general README file, in the Aminet gcc263 disrtobution at least. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sat Jun 10 07:42:34 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90145-3>; Sat, 10 Jun 1995 07:41:21 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sKJEZ-0004nYC; Fri, 9 Jun 95 22:37 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Questions about GNU To: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) Date: Fri, 9 Jun 1995 22:37:23 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Manolis Pappas" at Jun 9, 95 09:24:00 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 374 > 1. To test the system, I wrote the simple "Hello world" program and > I compiled it. I used the command: > gcc -noixemul -O3 hello.c -o hello > and I producd an executable of 10K in size, which is unacceptable. How > can I reduce the size? Well, you can try leaving out the -noixemul flag :-) Without it, the executable size is only 1320 bytes. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Jun 10 09:49:06 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <90550-4>; Sat, 10 Jun 1995 09:47:28 +0300 Received: by theseas.ntua.gr with UUCP; Sat, 10 Jun 1995 09:50:42 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <078c@kriton.UUCP>; Sat, 10 Jun 95 09:45:50 EET Date: Sat, 10 Jun 95 09:45:50 EET Message-Id: <9506100745.078c@kriton.UUCP> In-Reply-To: (from mpap@acrogate.ath.forthnet.gr (Manolis Pappas)) (at Fri, 9 Jun 95 21:24 GMT) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 557 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: mpap@acrogate.ath.forthnet.gr Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Questions about GNU Hi Manolis (Manolis Pappas), in on Jun 9 you wrote: > and I producd an executable of 10K in size, which is unacceptable. How > can I reduce the size? Read GNU:guide/libnix.guide Features->Startup Codes to see how you can write a "hello world" program that is 492 bytes long. Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "It's an honour, sir." "The honour's mine." "That's what I meant!" ----- From amiga-gcc-port-owner@nic.funet.fi Sat Jun 10 11:55:35 1995 Received: from pythia.forthnet.gr ([139.91.1.1]) by nic.funet.fi with SMTP id <90839-3>; Sat, 10 Jun 1995 11:54:18 +0300 Received: from acrogate.UUCP by pythia.forthnet.gr via FORTHnet with UUCP; id AA25727 (5.65c/FORTH-ICS-3.0-MHS-7.0); Sat, 10 Jun 1995 11:55:39 +0300 Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0sKNtI-000AxWC; Sat, 10 Jun 95 10:35 GMT Message-Id: Date: Sat, 10 Jun 95 10:35 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Subject: Where is gdb? I've been searching in the Aminet over two days now, but I haven't found (yet) the gdb source level debugger for gnu. I've looked on the aminet/dev/gcc, c, cross and debug but... Whare is it? Also, do you know if powervisor works well with gnu executables? Thank you. From amiga-gcc-port-owner@nic.funet.fi Sat Jun 10 11:57:55 1995 Received: from pythia.forthnet.gr ([139.91.1.1]) by nic.funet.fi with SMTP id <90493-1>; Sat, 10 Jun 1995 11:54:55 +0300 Received: from acrogate.UUCP by pythia.forthnet.gr via FORTHnet with UUCP; id AA25783 (5.65c/FORTH-ICS-3.0-MHS-7.0); Sat, 10 Jun 1995 11:56:28 +0300 Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0sKPdS-000AxWC; Sat, 10 Jun 95 12:27 GMT Message-Id: Date: Sat, 10 Jun 95 12:27 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Subject: SAS .lib -> gnu Hello again! After reading the gcc263-readme files, I tried to convert a library I have that supports popupmenuclasses and boopsi objects. I issued the command: hunk2gcc visualarts.lib but the utility informed me that I must convert the library to ALINK (join type) format. What does ths mean? I've never used ALINK, but as the Lattice C v5.0 manual writes "ti was buggy and didn't supported object codes well". Is there a SAS -> ALINK library converter to the Aminet? Thank you! From amiga-gcc-port-owner@nic.funet.fi Sat Jun 10 11:58:18 1995 Received: from pythia.forthnet.gr ([139.91.1.1]) by nic.funet.fi with SMTP id <90715-2>; Sat, 10 Jun 1995 11:54:51 +0300 Received: from acrogate.UUCP by pythia.forthnet.gr via FORTHnet with UUCP; id AA25769 (5.65c/FORTH-ICS-3.0-MHS-7.0); Sat, 10 Jun 1995 11:56:24 +0300 Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0sKPcr-000AxWC; Sat, 10 Jun 95 12:26 GMT Message-Id: Date: Sat, 10 Jun 95 12:26 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Hi Philippe, > Manolis Pappas writes: > > > 1. To test the system, I wrote the simple "Hello world" program and > > I compiled it. I used the command: > > gcc -noixemul -O3 hello.c -o hello > > and I producd an executable of 10K in size, which is unacceptable. How > > can I reduce the size? > > I like the word "unacceptable"... Well... after using SAS/C for over 4 years, it was quite a shock to see a "Hello, world" program of 10K code size ;-) But, I've tried the same thing on the pc using gnu c 2.6.3 and got a 29kb program, so I just say "great" ;-) That's why I've said "unacceptable" > Gcc, as default, uses library ixemul.library, which is somewhat 200KB large. > So in fact add those 200KB to your "unacceptable" 10KB, thus making a > 210KB program, which is I think then even more unacceptable :-) Totally wrong! ixemul.library is 129k, but still that's "unacceptable" ;-) > Ok to reduce executable size, try compiling with -noixemul flag. Avoid -O3, > as it's gonna make your executable larger. Use -O2. Well... those optimazations care only for speed. I'll try to reduce it somehow different. I am compiling with -noixemul as default, but I've found out that using the -lauto flag also, reduces the executable even more (about 800 bytes). Also, the author of libnix mention somewhere in the docs that he produced a 492 bytes "Hello world" program, so it's a matter of time to find how!! > > > 2. If I try to compile a program that uses Amiga include files (e.g > > intuition.h>, I use the command: > > gcc -noixemul test.c -o test > > but no executable file is produced (there are no errors). If I also specify > > the option -lauto, the compiler produces the executable. Is that normal? > > Could you send output of: > gcc -v -noixemul -o test test.c > > > 3. I used to program in SAS/C v6.50. How can I convert some .lib files > > I used into a format accessible by GNU? (I suppose that the .lib files > > are incompatible with GNU!). > > This is explained in general README file, in the Aminet gcc263 disrtobution > at least. > Thanks. I've got it today. BTW, do you know where I can find gdb? I've searched on aminet/dev/gcc/* aminet/dev/c/* && aminet/dev/cross/* && aminet/dev/debug/* but it isn't there! From amiga-gcc-port-owner@nic.funet.fi Sat Jun 10 16:09:00 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <90171-1>; Sat, 10 Jun 1995 16:07:53 +0300 Received: by theseas.ntua.gr with UUCP; Sat, 10 Jun 1995 16:08:33 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <078w@kriton.UUCP>; Sat, 10 Jun 95 16:01:10 EET Date: Sat, 10 Jun 95 16:01:10 EET Message-Id: <9506101401.078w@kriton.UUCP> In-Reply-To: (from mpap@acrogate.ath.forthnet.gr (Manolis Pappas)) (at Sat, 10 Jun 95 12:27 GMT) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1262 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: mpap@acrogate.ath.forthnet.gr Cc: amiga-gcc-port@lists.funet.fi Subject: Re: SAS .lib -> gnu Hi Manolis (Manolis Pappas), in on Jun 10 you wrote: > but the utility informed me that I must convert the library to ALINK > (join type) format. What does ths mean? I've never used ALINK, but as > the Lattice C v5.0 manual writes "ti was buggy and didn't supported > object codes well". Is there a SAS -> ALINK library converter to the > Aminet? ALINK format is simply a bunch of concatenated object files. SAS libraries are in a newer format that contains indexing information for easier access of the modules in the library. To convert such libraries into the older format, simply extract all object modules from the library using oml, and concatenate them together. As, however, your aim is to create a gcc library, you can skip the concatenation part. E.g., to convert visualarts.lib to libvisualarts.a, you can do the following: oml visualarts.lib x * hunk2gcc *.o ar rc libvisualarts.a obj* ranlib libvisualarts.a I hope this helps, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I am omniscient and omnipotent, extremely vain, and, what is more, I come in a handy self-carrying package." ----- From amiga-gcc-port-owner@nic.funet.fi Sat Jun 10 16:09:30 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <90092-3>; Sat, 10 Jun 1995 16:09:03 +0300 Received: by theseas.ntua.gr with UUCP; Sat, 10 Jun 1995 16:08:30 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <078r@kriton.UUCP>; Sat, 10 Jun 95 15:50:09 EET Date: Sat, 10 Jun 95 15:50:09 EET Message-Id: <9506101350.078r@kriton.UUCP> In-Reply-To: (from mpap@acrogate.ath.forthnet.gr (Manolis Pappas)) (at Sat, 10 Jun 95 12:26 GMT) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 676 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: mpap@acrogate.ath.forthnet.gr Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Hi Manolis (Manolis Pappas), in on Jun 10 you wrote: > Well... after using SAS/C for over 4 years, it was quite a shock to see > a "Hello, world" program of 10K code size ;-) But, I've tried the same > thing on the pc using gnu c 2.6.3 and got a 29kb program, so I just > say "great" ;-) You should try it on VAX/VMS. It's even bigger. Considerably bigger! -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I am omniscient and omnipotent, extremely vain, and, what is more, I come in a handy self-carrying package." ----- From amiga-gcc-port-owner@nic.funet.fi Sun Jun 11 02:15:14 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <90296-4>; Sun, 11 Jun 1995 02:11:13 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189482>; Sun, 11 Jun 1995 01:10:38 +0200 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA28765; Sun, 11 Jun 1995 01:10:28 +0200 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9506102310.AA28765@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: Questions... To: kyrimis@theseas.ntua.gr Date: Sun, 11 Jun 1995 01:10:27 +0200 Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9506091826.077l@kriton.UUCP> from "Kriton Kyrimis" at Jun 9, 95 08:26:50 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1295 > > This is a very glum view, especially as this thread was started by a po= > sting > by a newcomer to gcc, who won't feel very encouraged to use it given su= > ch > comments. Of course there exist programs that require 32M to compile. = > There > also exist programs that require 500K of stack to compile. I should th= > ink, > however, that both categories are the exception. Based on my experience= > =20with > gcc (not g++) on my gradually expanding system, I would say: > > 2+1M: Gcc is of little use--after loading the compiler, and allocating = > a > =09reasonably large stack, there's not much memory left. > 4+1M: These extra 2M make a **** of a difference! Now (almost?) everyth= > ing > =09compiles. > 8+1M: I have yet to find a C program that does not compile due to lack = > of > =09memory. (No, don't send me examples to the contrary--I know they > =09must exist!) > > In short, I would think that the critical amount is 4M of fast memory. Before I decided to upgrade my system to tot. 6MB, I WAS able to compile the complete fudgit source with -O2 on my 4MB A4000 :) The imho most important thing to know is to set the t: assign to a HD- directory. Next would be to flush unneccesary libs and remove all commodities and other needless processes/tasks. Thomas From amiga-gcc-port-owner@nic.funet.fi Sun Jun 11 07:45:18 1995 Received: from unixg.ubc.ca ([137.82.27.14]) by nic.funet.fi with SMTP id <90402-4>; Sun, 11 Jun 1995 07:44:31 +0300 Received: from interchg.ubc.ca by unixg.ubc.ca (8.6.10/1.14) id VAA02718; Sat, 10 Jun 1995 21:44:11 -0700 Date: Sat, 10 Jun 1995 21:44:10 -0700 (PDT) From: Warren Van Winckel X-Sender: warrenvw@interchg.ubc.ca To: amiga-gcc-port@nic.funet.fi Subject: "Hello World" In-Reply-To: <9506082055.077b@kriton.UUCP> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have tried and tried, but am unable to get the iostream header file working on my installation. Any help would greatly be appreciated... Here is the c++ file: #include void main() { cout << "Hello, World! I am "<< 8 << "Today!" << endl; } And the error output: In file included from /gnu/include/iostream.h:31, from test.cc:1: /gnu/include/streambuf.h:219: `ios::operator void *(...)' must take `void' ............ warrenvw@unixg.ubc.ca .. \/\/\/\/\/ ........... From amiga-gcc-port-owner@nic.funet.fi Sun Jun 11 19:15:36 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89044-1>; Sun, 11 Jun 1995 19:12:46 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sKqWF-0004nbC; Sun, 11 Jun 95 10:09 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: "Hello World" To: warrenvw@unixg.ubc.ca (Warren Van Winckel) Date: Sun, 11 Jun 1995 10:09:51 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Warren Van Winckel" at Jun 10, 95 09:44:10 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 485 > I have tried and tried, but am unable to get the iostream header file > working on my installation. Any help would greatly be appreciated... > > Here is the c++ file: > > #include > > void main() { > cout << "Hello, World! I am "<< 8 << "Today!" << endl; > } Hmm, don't know what the problem could be. I tried it with the version of gcc 2.6.3 on my FreshFish CDs and it compiled fine. You don't say what version of gcc you are using or where you got it. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 10:02:02 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90128-4>; Mon, 12 Jun 1995 09:57:32 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun12.095732+0300_eet_dst.90128-4+22@nic.funet.fi> From: To: Date: Mon, 12 Jun 1995 09:57:29 +0300 Date: Mon, 12 Jun 1995 08:57:18 +0200 (METDST) From: Rask Lambertsen To: Manolis Pappas Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Questions... In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 8 Jun 1995, Manolis Pappas wrote: > 2. I have an Amiga system with the 68000 processor and 5MB of RAM. Can > I use GNU C/C++ on this config? I use GNU C with the same configuration (but only 3 MB RAM) so I think you can. > 3. Does GNU C allowes the creation of executable programs that DO NOT > require ixemul.library? Yes. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 10:31:50 1995 Received: from mail.Germany.EU.net ([192.76.144.65]) by nic.funet.fi with ESMTP id <90686-2>; Mon, 12 Jun 1995 10:28:11 +0300 Received: by mail.Germany.EU.net with SMTP (8.6.5:29/EUnetD-2.5.1.g) via EUnet id JAA19263; Mon, 12 Jun 1995 09:29:35 +0200 Message-Id: <9506120716.AA00782@GWEU.softlab.de> Received: from AA by GWEU.softlab.de with SMTP (5.65/GEN-1.1.8) via EUnet for [192.76.144.65] id AA00782; Mon, 12 Jun 95 09:16:25 +0200 Received: from H8 by AA with SMTP (1.37.109.4/16.2) id AA03428; Mon, 12 Jun 95 09:30:05 +0200 Received: by H8 (1.37.109.4/16.2) id AA05780; Mon, 12 Jun 95 09:28:10 +0200 Date: Mon, 12 Jun 95 09:28:10 +0200 From: SMH@softlab.de To: amiga-gcc-port@lists.funet.fi subscribe amiga-gcc-port Hans Schmid From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 11:19:58 1995 Received: from icslab2.icslab.agh.edu.pl ([149.156.98.2]) by nic.funet.fi with SMTP id <90098-3>; Mon, 12 Jun 1995 11:18:13 +0300 Received: (from kiskra@localhost) by icslab2.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA00578; Mon, 12 Jun 1995 10:20:15 +0200 Date: Mon, 12 Jun 1995 10:20:11 +0200 (MET DST) From: Kamil Iskra Subject: Re: your mail To: Manolis Pappas cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 10 Jun 1995, Manolis Pappas wrote: > Hi Philippe, > > > Manolis Pappas writes: > > > > > 1. To test the system, I wrote the simple "Hello world" program and > > > I compiled it. I used the command: > > > gcc -noixemul -O3 hello.c -o hello > > > and I producd an executable of 10K in size, which is unacceptable. How > > > can I reduce the size? > > > > I like the word "unacceptable"... > > Well... after using SAS/C for over 4 years, it was quite a shock to see > a "Hello, world" program of 10K code size ;-) But, I've tried the same > thing on the pc using gnu c 2.6.3 and got a 29kb program, so I just > say "great" ;-) New versions of GCC add symbol informations to the executable by default. Did you remember to use "-s" flag to strip them? It is explained in README file on Amient distribution of GCC. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 12:04:38 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <90376-2>; Mon, 12 Jun 1995 12:03:16 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA05145 (5.65c8/IDA-1.4.4 for ); Mon, 12 Jun 1995 11:03:06 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA18743; Mon, 12 Jun 95 11:03:05 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506120903.AA18743@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: hello world To: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) Date: Mon, 12 Jun 1995 11:03:05 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Manolis Pappas" at Jun 10, 95 12:26:00 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1534 > > Well... those optimazations care only for speed. I'll try to reduce it > somehow different. I am compiling with -noixemul as default, but I've > found out that using the -lauto flag also, reduces the executable even > more (about 800 bytes). Also, the author of libnix mention somewhere in the > docs that he produced a 492 bytes "Hello world" program, so it's a matter > of time to find how!! > OK, here's how :-). To make all executables small compile with: -s to strip the executable -fbaserel to use small data model (you'll need gcc2.3.3 (or 2.7.0 ;-) ) for that) -msmall-code for small code model -O2 to optimize ;-). To make C programs using libnix small don't link with libgcc.a - you'll need it only for C++ programs and for the gnu extensions: gcc -nostdlib -fbaserel nbcrt0.o libnixmain.a your_file.o libnix.a libstubs.a To make amiga-only programs using libnix small: * Don't use printf, use dos.library's Write() function instead. * Don't use argc, argv. Define a global variable int __nocommandline=1; to tell the linker that you don't need it. (you then don't need libnixmain.a any more). * Open the system libraries yourself. Define int __initlibraries=0; to tell the linker that you did this. (you can't use libnix.a then because it needs the auto-open-library feature.) You can combine all these tricks (except the last one) how you like. Only the last one limits you to do everything yourself (some amiga-only programs do this anyway). Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 13:31:42 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <90764-4>; Mon, 12 Jun 1995 13:27:29 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA16791; Mon, 12 Jun 1995 11:26:48 +0100 Date: Mon, 12 Jun 1995 11:26:20 +0100 (BST) From: Peter Ivimey-Cook To: Philippe BRAND Cc: Manolis Pappas , Amiga-Gcc Liste Subject: Re: Questions about GNU In-Reply-To: <199506092321.AAA17874@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 10 Jun 1995, Philippe BRAND wrote: > Manolis Pappas writes: > > gcc -noixemul -O3 hello.c -o hello > > and I producd an executable of 10K in size, which is unacceptable. How > > can I reduce the size? > > I like the word "unacceptable"... > Gcc, as default, uses library ixemul.library, which is somewhat 200KB large. > So in fact add those 200KB to your "unacceptable" 10KB, thus making a > 210KB program, which is I think then even more unacceptable :-) > > Ok to reduce executable size, try compiling with -noixemul flag. Avoid -O3, > as it's gonna make your executable larger. Use -O2. Philippe - he did use -noixemul!! :) I would fully expect that: gcc -O3 hello.c -o hello would produce a smaller program file, at the expense of loading the approx 120Kb of ixemul code. (It's never been 200Kb so far, unless you mean the in-memory image size). By the way, is there anyone doing a standard Amiga C library as a shared lib - i.e. just the string lib, stdio lib etc, but no specifically unix-isms? I was wondering if there might be a middle course for those writing programs from scratch (& thus able to write pure amiga stuff). Out of interest, I compiled hello.c on my work machine (a Unix HPPA using shared libs) and it comes out at 16384 bytes.... Well they always did say RISC meant larger programs... Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 13:52:10 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <90905-2>; Mon, 12 Jun 1995 13:48:43 +0300 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA18122; Mon, 12 Jun 1995 12:48:11 +0200 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA09069; Mon, 12 Jun 95 12:48:10 +0200 From: isthesin@TechFak.Uni-Bielefeld.DE (Stephan Thesing) Message-Id: <9506121248.ZM9067@moos.TechFak.Uni-Bielefeld.DE> Date: Mon, 12 Jun 1995 12:48:10 +0200 In-Reply-To: Peter Ivimey-Cook "Re: Questions about GNU" (Jun 12, 11:26) References: X-Mailer: Z-Mail (2.1.5 09aug93) To: Peter Ivimey-Cook Subject: Re: Questions about GNU Cc: amiga-gcc-port@nic.funet.fi Hi there! On Jun 12, 11:26, Peter Ivimey-Cook wrote: > Subject: Re: Questions about GNU > On Sat, 10 Jun 1995, Philippe BRAND wrote: > > > Manolis Pappas writes: > > > gcc -noixemul -O3 hello.c -o hello > > > and I producd an executable of 10K in size, which is unacceptable. How > > > can I reduce the size? > > > > I like the word "unacceptable"... > > Gcc, as default, uses library ixemul.library, which is somewhat 200KB large. > > So in fact add those 200KB to your "unacceptable" 10KB, thus making a > > 210KB program, which is I think then even more unacceptable :-) > > > > Ok to reduce executable size, try compiling with -noixemul flag. Avoid -O3, > > as it's gonna make your executable larger. Use -O2. > > Philippe - he did use -noixemul!! :) I would fully expect that: > > gcc -O3 hello.c -o hello > > would produce a smaller program file, at the expense of loading the > approx 120Kb of ixemul code. (It's never been 200Kb so far, unless you > mean the in-memory image size). > > By the way, is there anyone doing a standard Amiga C library as a shared > lib - i.e. just the string lib, stdio lib etc, but no specifically > unix-isms? I was wondering if there might be a middle course for those > writing programs from scratch (& thus able to write pure amiga stuff). > > Out of interest, I compiled hello.c on my work machine (a Unix HPPA using > shared libs) and it comes out at 16384 bytes.... This is because on UNIX machines program size must always be a multiple of the memory page size, as imposed by the MMU. So, most likely a HPPA has page size 16k (or 8k and program code is slightly longer than 8k), I suppose...... But then again, who cares if a program has size 1k or 16k ? It only makes a difference, if you compare a program of, say, 100k against one with 40k. But with larger programs, GCC's optimizations produce (most of the time) smaller (and faster) programs than other compilers. > > Well they always did say RISC meant larger programs... > Bye... Stephan From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 15:15:05 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89982-2>; Mon, 12 Jun 1995 15:10:26 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun12.151026+0300_eet_dst.89982-2+27@nic.funet.fi> From: To: Date: Mon, 12 Jun 1995 15:10:19 +0300 Date: Mon, 12 Jun 1995 14:10:02 +0200 (METDST) From: Rask Lambertsen To: Manolis Pappas Cc: Amiga-Gcc Liste Subject: Re: Questions about GNU In-Reply-To: <199506092321.AAA17874@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 10 Jun 1995, Philippe BRAND wrote: Manolis Pappas writes: > 2. If I try to compile a program that uses Amiga include files (e.g > intuition.h>, I use the command: > gcc -noixemul test.c -o test > but no executable file is produced (there are no errors). If I also specify > the option -lauto, the compiler produces the executable. Is that normal? You are probably running short of memory. Then cc1 fails to load, but no error message is given. Check your memory with 5. HD1> Avail FLUSH If the largest free block of memory is smaller than around 920 kb, then cc1 won't load. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 15:23:17 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <90661-3>; Mon, 12 Jun 1995 15:20:14 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA17219; Mon, 12 Jun 1995 13:20:04 +0100 Date: Mon, 12 Jun 1995 13:19:35 +0100 (BST) From: Peter Ivimey-Cook To: Amiga GCC List Subject: Fork problems Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I'm having a go at porting to Amiga the current version of Unix sendmail. However, it relies on forking new children which carry on doing the work of the parent, using the parent's state to tell the child what to do! Of course this isn't going to work on the Amiga - or is it? Is there any way such a system can be made to work? The alternative (which is possible) is to make sendmail single-threaded. It might be simpler to do this than anything else, but I wanted to hear what other more experienced people have to say. Also, has anyone ported bind-4.9 - the internet resolver / named files? If not I'll have to port them too :( Thanks, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 15:28:09 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90663-4>; Mon, 12 Jun 1995 15:24:18 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun12.152418+0300_eet_dst.90663-4+34@nic.funet.fi> From: To: Date: Mon, 12 Jun 1995 15:24:13 +0300 Date: Mon, 12 Jun 1995 14:16:25 +0200 (METDST) From: Rask Lambertsen To: Thomas Radtke Cc: kyrimis@theseas.ntua.gr, amiga-gcc-port@nic.funet.fi Subject: Re: Questions... In-Reply-To: <9506102310.AA28765@nereid.rz.Uni-Osnabrueck.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 11 Jun 1995, Thomas Radtke wrote: > Before I decided to upgrade my system to tot. 6MB, I WAS able to compile > the complete fudgit source with -O2 on my 4MB A4000 :) > The imho most important thing to know is to set the t: assign to a HD- > directory. Next would be to flush unneccesary libs and remove all > commodities and other needless processes/tasks. Yep, those tricks make an incredible difference, particularily the "Assign T: HD1:t" trick claws back a lot of memory from GCC. Maybe these trick should be in the FAQ (if they are not already). Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 16:24:22 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90165-3>; Mon, 12 Jun 1995 16:20:49 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun12.162049+0300_eet_dst.90165-3+35@nic.funet.fi> From: To: Date: Mon, 12 Jun 1995 16:20:49 +0300 Date: Mon, 12 Jun 1995 15:21:01 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Is the 68060 supported by GCC? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Just a quick question (or two): Is the 68060 supported by GCC? If not, when will it be? Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 16:25:30 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <90928-2>; Mon, 12 Jun 1995 16:22:30 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA18115 (5.65c+/IDA-1.4.4 for ); Mon, 12 Jun 1995 15:21:19 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA13983; Mon, 12 Jun 1995 15:22:29 GMT Date: Mon, 12 Jun 1995 15:22:29 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: gcc with overlays In-Reply-To: <9506092031.077q@kriton.UUCP> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 9 Jun 1995, Kriton Kyrimis wrote: > I'm wasn't referring to ixemul clients; that's why I mentioned compiling with > the SAS headers (to get the corrrect references to the SAS link libraries, > which one would have to use if one used the SAS startup code, which is > probably required to use overlays). Whats the point in compiling with GCC unless you are creating a ixemul client????? GCC, mainly on a 68000 is MUCH slower and memory hungry! Even if you still want to use GCC to compile and SLINK to link, it will not work with overlays... The compiler, when compiling to overlays, adds a small code to every funtion entrance and exit. This code is, mainly, to pass control to the overlay manager. If the compiler doesnt know anything about the other compilers implementation of overlays you will have to put all that code BY HAND! > True, but not all programs use math. In addition, although this does not apply > in the case of the original poster, who has a 68000, one can work around this > problem by compiling with -m68881 to produce inline 68881 code rather than > references to compiler-specific subroutines. This is very far from being a solution ...! One thing the original poster can do is assign t: to a directory on hard disk. It will save A LOT of memory at compile time! - Pedro Teixeira - PS: Contrary to what Kirimis sayd, Ive had dificulty to find programs that require less than 4Mb to compile not using the Assign t: to hard disk. From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 17:07:38 1995 Received: from prdnet.polaroid.com ([137.252.9.11]) by nic.funet.fi with ESMTP id <90092-2>; Mon, 12 Jun 1995 17:02:04 +0300 Date: Mon, 12 Jun 1995 09:03:16 -0400 (EDT) From: "David J. Ruscak" Subject: C++ question To: amiga-gcc-port@lists.funet.FI Content-transfer-encoding: 7BIT Full-Name: David J. Ruscak Mailer: Elm [revision: 70.85] Message-Id: <95Jun12.170204+0300_eet_dst.90092-2+29@nic.funet.fi> I'm trying to compile the Virtual Reality Modeling Language library -> QvLib.o so my VRML scripts and be ready when a VRML web browser to appears ;). The following is the output from Make , the file QvFieldData.c++:65 is the culprit. ================================================================================ % make g++ -I ../include -c QvLib.C QvDebugError.c++: In function `static void QvDebugError::post(const char *, const char * ...)': In file included from qvlib.c:11: QvDebugError.c++:12: warning: ANSI C++ forbids implicit conversion from `void *' in argument passing QvFieldData.c++: In method `void QvFieldData::addField(class QvNode *, const char *, const class QvField *)': In file included from qvlib.c:15: QvFieldData.c++:65: invalid use of undefined type `struct QvFieldEntry' QvFieldData.c++:65: invalid use of undefined type `struct QvFieldEntry' QvReadError.c++: In function `static void QvReadError::post(const class QvInput *, const char * ...)': In file included from qvlib.c:38: QvReadError.c++:13: warning: ANSI C++ forbids implicit conversion from `void *' in argument passing QvTexture2.c++: In method `QvTexture2::QvTexture2()': In file included from qvlib.c:59: QvTexture2.c++:16: warning: assignment to `short int' from `double' make: *** [QvLib.o] Error 1 ================================================================================ The following is an excerpts from QvFieldData.c++: struct QvFieldEntry { QvName name; long offset; }; void QvFieldData::addField(QvNode *defobj, const char *fieldName, const QvField *field) { struct QvFieldEntry *newField = new struct QvFieldEntry;<==offending line 65 newField->name = fieldName; newField->offset = (const char *) field - (const char *) defobj; fields.append((void *) newField); } ================================================================================ When redine line 65 to this ==> struct QvFieldEntry *newField; Everything compiles and qvlib.o is produced. I can then compile and link their test program. Suprise,Suprise when I execute it. readTest ; Mon, 12 Jun 1995 17:08:43 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id PAA17110; Mon, 12 Jun 1995 15:06:28 +0100 From: Lars Hecking Message-Id: <199506121408.PAA00753@mostar.nmrc.ucc.ie> Subject: Re: Fork problems To: Peter.Ivimey-Cook@isltd.insignia.com (Peter Ivimey-Cook) Date: Mon, 12 Jun 1995 15:08:38 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Peter Ivimey-Cook" at Jun 12, 95 01:19:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 703 > I'm having a go at porting to Amiga the current version of Unix sendmail. > However, it relies on forking new children which carry on doing the work > of the parent, using the parent's state to tell the child what to do! Of > course this isn't going to work on the Amiga - or is it? See my post on "fork() and friends" from 5/16/1995. I believe it describes the necessary steps to simulate fork() with vfork2()/vfork_resume() reasonably well. One way of dealing with paramaters (stack is volatile after calling vfork()) is using ix_resident eg as in pdksh/jobs.c. The real mess is finding out what goes between vfork2() and vfork_resume() ... really gives me a hard time w/ pdksh-5.2.2 :( From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 17:38:06 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89139-2>; Mon, 12 Jun 1995 17:32:29 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id PAA17339; Mon, 12 Jun 1995 15:31:35 +0100 From: Lars Hecking Message-Id: <199506121433.PAA00801@mostar.nmrc.ucc.ie> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Mon, 12 Jun 1995 15:33:47 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <95Jun12.162049+0300_eet_dst.90165-3+35@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Jun 12, 95 04:20:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 485 > Just a quick question (or two): Is the 68060 supported by GCC? If not, when > will it be? No. None of the machines in config/m68k are currently available with 68060. I presume that -m68020-40 should run well on 060. Unless direct 060 support is there, I'd suggest getting aminet:doc/dev/misc/68060Guide.txt and check if gcc generated code has any instructions which should not be used on a 060. Oh, I'm refering to gcc <=2.6.3, of course. Maybe 2.7.0 is a different story? From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 18:06:42 1995 Received: from crew.umich.edu ([141.211.184.10]) by nic.funet.fi with SMTP id <90402-3>; Mon, 12 Jun 1995 18:03:11 +0300 Received: from uri.crew.umich.edu by crew.umich.edu (8.6.12/2.2) with ESMTP id LAA09591; Mon, 12 Jun 1995 11:02:40 -0400 Received: from localhost by uri.crew.umich.edu (8.6.12/dumb-1.0) id LAA05005; Mon, 12 Jun 1995 11:02:38 -0400 Message-Id: <199506121502.LAA05005@uri.crew.umich.edu> To: Peter Ivimey-Cook , amiga-gcc-port@nic.funet.fi Subject: Re: Fork problems, (Really porting UNIX TCP servers) In-reply-to: Your message of "Mon, 12 Jun 1995 15:56:45 BST." Date: Mon, 12 Jun 1995 11:02:36 -0400 From: Charles Hymes In Message On Date Mon, 12 Jun 95 15:56:45 BST Peter Ivimey-Cook wrote the following: > > Peter, are you using AMITCP? If so, have you modified the GNU or AMITCP > > includes? > > > > I've been (trying) to use the gcc sdk ported by Jeff Sheppherd (who > posted it recently to Aminet &used it to port pine. I've currently got > the gcc includes (from 2.6.3) basically unchanged. Why do you ask? > > Regards, > > Peter Ivimey-Cook. > > Because I am trying to port a Z39.50 (formerly WAIS) client, server and http gateway. I'm having problems, and Jeff Sheppherd's docs say that his port does not work with servers very well yet. If you had fixed that stuff, I would like to know what you did. Charlweed From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 18:30:12 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <90128-2>; Mon, 12 Jun 1995 18:28:53 +0300 Received: from caeiro.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA20394; Mon, 12 Jun 1995 17:29:36 GMT Received: by caeiro.ci.uminho.pt (5.4R2.10/200.1.1.4) id AA17961; Mon, 12 Jun 1995 17:25:08 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506121525.AA17961@caeiro.ci.uminho.pt> Subject: help me with gcc To: amiga-gcc-port@nic.funet.fi Date: Mon, 12 Jun 1995 17:25:07 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 472 when i use flex to generate a scanner gcc says yyout and yyin are not correctly inicialized can anybody say how to do it NOTE: i'm not English, so sorry for the mistakes __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 18:59:01 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <90296-4>; Mon, 12 Jun 1995 18:57:02 +0300 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.6.12/8.6.9) id RAA15243; Mon, 12 Jun 1995 17:55:47 +0200 Date: Mon, 12 Jun 1995 17:55:47 +0200 From: Ignatios Souvatzis Message-Id: <199506121555.RAA15243@theory.cs.uni-bonn.de> To: lhecking@nmrc.ucc.ie CC: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-reply-to: Lars Hecking's message of Mon, 12 Jun 1995 15:33:47 +0100 (BST) <199506121433.PAA00801@mostar.nmrc.ucc.ie> Subject: your mail X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a Date: Mon, 12 Jun 1995 15:33:47 +0100 (BST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 485 > Just a quick question (or two): Is the 68060 supported by GCC? If not, when > will it be? No. None of the machines in config/m68k are currently available with 68060. I presume that -m68020-40 should run well on 060. Unless direct 060 support is there, I'd suggest getting aminet:doc/dev/misc/68060Guide.txt and check if gcc generated code has any instructions which should not be used on a 060. Oh, I'm refering to gcc <=2.6.3, of course. Maybe 2.7.0 is a different story? Should be no problem, as long as the isp and fpsp package are installed in the system (the same way as the 040 fpsp package has to be installed in the system to have full support of the ieee fp instructions with the 68040)... but thats the 68060 system integrators' headache, not yours. Of course, a few microseconds might be gained by - a compiler that knows how to avoid the (few) user space instructions which are emulated; I think only the mul32x32->64 ones would concern you. - a compiler that knows how to order instructions as to fill the 2nd integer execution unit as much as possible, and (a bit far-fetched :-) how to use branches the branch preditctor always (instead of 90%) predicts correctly. I guess no sane compiler would ever create the movep instruction? Of course, some device drivers for sick io cards like the A2060 might benefit from movep, (the A2060 by about 2-3% on a 68030 cpu), but those would be inlined assembler instructions (or inside assembler modules) anyway. Regards, Ignatios Souvatzis From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 22:12:11 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90839-2>; Mon, 12 Jun 1995 22:08:45 +0300 Received: from acl.lanl.gov by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HRMO41Y1TS0001BG@FIPORT.FUNET.FI>; Mon, 12 Jun 1995 19:09:25 +0200 (EET) Received: from booboo.acl.lanl.gov (booboo.acl.lanl.gov [128.165.114.74]) by acl.lanl.gov (8.6.11/8.6.10) with ESMTP id NAA11499 for ; Mon, 12 Jun 1995 13:03:09 -0600 Received: (hinker@localhost) by booboo.acl.lanl.gov (8.6.9/8.6.4) id NAA10505; Mon, 12 Jun 1995 13:03:07 -0600 Date: Mon, 12 Jun 1995 13:03:07 -0600 From: "Paul J. Hinker" Subject: Please unsubscribe me To: amiga-gcc-port@nic.funet.fi Reply-to: "Paul J. Hinker" Message-id: <199506121903.NAA10505@booboo.acl.lanl.gov> Content-transfer-encoding: 7BIT unsubscribe UNSUBSCRIBE From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 23:00:10 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <90136-1>; Mon, 12 Jun 1995 22:59:23 +0300 Received: by theseas.ntua.gr with UUCP; Mon, 12 Jun 1995 23:00:54 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07b9@kriton.UUCP>; Mon, 12 Jun 95 22:18:06 EET Date: Mon, 12 Jun 95 22:18:06 EET Message-Id: <9506122018.07b9@kriton.UUCP> In-Reply-To: <9506121525.AA17961@caeiro.ci.uminho.pt> (from si215603@ci.uminho.pt (Luis Antonio F.Alves)) (at Mon, 12 Jun 1995 17:25:07 +0200 (MET DST)) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1123 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: si215603@ci.uminho.pt Cc: amiga-gcc-port@lists.funet.fi Subject: Re: help me with gcc Hi Luis (Luis Antonio F.Alves), in <9506121525.AA17961@caeiro.ci.uminho.pt> on Jun 12 you wrote: > when i use flex > to generate a scanner gcc says yyout and yyin are not correctly inicialized can > anybody say how to do it It depends on what version you're using. (Flexx --version should tell you.) If you are using version 2.4.7 (the one distributed with the aminet version of gcc 2.6.3) then I believe that this problem only occurs if you use the -l (lex compatibility) switch. You can either try to avoid using this switch, or edit the generated lex.yy.c, and remove the initialization of yyin and yyout to stdin and stdout respectively (you will have to add the initializations in the body of yylex). If you are using version 2.5.0 or 2.5.1, then simply add %option nostdinit as the first line of your lex code. If you are using 2.5.2, this option is the default, so you need not do anything. I hope this helps, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Oh, it's just the unknown, then!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 23:00:49 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <90704-1> convert rfc822-to-8bit; Mon, 12 Jun 1995 23:00:31 +0300 Received: by theseas.ntua.gr with UUCP; Mon, 12 Jun 1995 23:00:59 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07az@kriton.UUCP>; Mon, 12 Jun 95 21:21:41 EET Date: Mon, 12 Jun 95 21:21:41 EET Message-Id: <9506121921.07az@kriton.UUCP> In-Reply-To: (from Pedro Miguel Sequeira Teixeira ) (at Mon, 12 Jun 1995 15:22:29 +0000 (GMT)) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT Content-Length: 1903 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: l36599@alfa.ist.utl.pt Cc: amiga-gcc-port@lists.funet.fi Subject: Re: gcc with overlays Hi Pedro (Pedro Miguel Sequeira Teixeira), in on Jun 12 you wrote: > Whats the point in compiling with GCC unless you are creating a > ixemul client????? I think Matthias Fleischer would like to answer this. > Even if you still want to use GCC to compile and SLINK to link, > it will not work with overlays... The compiler, when compiling > to overlays, adds a small code to every funtion entrance and exit. This is news to me. As far as I know (and from a quick glance I threw at the SAS manual to confirm), all the overlay magic is done by the linker, not the compiler! > This is very far from being a solution ...! True. A possibly better solution is suggested by the SAS manual: "Before deciding to use overlays, consider using multiple shared libraries instead. If memory is tight, the AmigaDOS system removes unused shared libraries, thereby giving you some of the benefits of overlays. On systems with more memory, the AmigaDOS system allows shared libraries to remain resident, which improves performance. Use overlays only in very tight memory situations." (This is how SAS/C is implemented.) > PS: Contrary to what Kirimis sayd, Ive had dificulty to find programs > that require less than 4Mb to compile not using the Assign t: to hard > disk. Perhaps gcc's memory requirements have gone up since the time I used to have "only" 4MB of memory. On the other hand, perhaps assigning T: to the hard disk would come so natural to me, that I don't even remember doing it. I do remember compiling gcc 1.4x on my 4MB machine, so I know that 4MB can be adequate for at least some large applications. Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Oh, it's just the unknown, then!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Jun 12 23:45:29 1995 Received: from minerva.phyast.pitt.edu ([136.142.111.2]) by nic.funet.fi with SMTP id <90661-2>; Mon, 12 Jun 1995 23:43:59 +0300 Received: from durer.phyast.pitt.edu by minerva.phyast.pitt.edu (4.1/1.34) id AA07439; Mon, 12 Jun 95 16:43:34 EDT Date: Mon, 12 Jun 95 16:43:34 EDT From: shaffer@phyast.pitt.edu (C. David Shaffer) Message-Id: <9506122043.AA07439@minerva.phyast.pitt.edu> Received: by durer.phyast.pitt.edu (4.1/SMI-4.1) id AA14161; Mon, 12 Jun 95 16:49:28 EDT To: amiga-gcc-port@nic.funet.fi Subject: Header files Hello, I have looked through the README and files and all of the guides but I can't figure out how to get gcc to look in the right place for my headers. I have assigned INCLUDE to GNU:os-include and have un-arched the CBM headers in that dir. The problem I have, though, is not with these headers but with stdio.h. If I #include this file I get all kinds of "Undefined reference to _builtin_printf" or some such thing. This makes me think that gcc is looking at my SAS/C headers but since I've reassigned INCLUDE: how the heck does gcc know where they are? Anyone have any ideas? BTW I tried snoopdos to follow the gcc file opening attempts but I don't even see it try to open stdio.h. I really a newbie... -David Shaffer -Department of Physics -The University of Pittsburgh -Pittsburgh, PA 15260 -shaffer@phyast.pitt.edu From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 00:04:49 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89101-3>; Tue, 13 Jun 1995 00:03:40 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id WAA20666; Mon, 12 Jun 1995 22:02:32 +0100 From: Lars Hecking Message-Id: <199506122104.WAA01456@mostar.nmrc.ucc.ie> Subject: Re: Header files To: shaffer@phyast.pitt.edu (C. David Shaffer) Date: Mon, 12 Jun 1995 22:04:44 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9506122043.AA07439@minerva.phyast.pitt.edu> from "C. David Shaffer" at Jun 12, 95 04:43:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1091 > > Hello, > > I have looked through the README and files and all of the > guides but I can't figure out how to get gcc to look in the right > place for my headers. I have assigned INCLUDE to GNU:os-include and > have un-arched the CBM headers in that dir. The problem I have, > though, is not with these headers but with stdio.h. If I #include this > file I get all kinds of "Undefined reference to _builtin_printf" or You include SAS's . > some such thing. This makes me think that gcc is looking at my SAS/C > headers but since I've reassigned INCLUDE: how the heck does gcc know > where they are? Anyone have any ideas? BTW I tried snoopdos to > follow the gcc file opening attempts but I don't even see it try to > open stdio.h. I really a newbie... Gcc's include files are in GNU:include, the CBM includes _and_only_the_ CBM_includes_ live in GNU:os-include. You don't need any additional assigns because gcc's searchpaths are relative to /gnu. So, if you just assign INCLUDE: back to SC:include and 'delete GNU:os-include/#?.h' everything should be fine. From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 00:23:58 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <89890-2>; Tue, 13 Jun 1995 00:22:34 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA27540; Mon, 12 Jun 1995 23:22:18 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9506122122.AA27540@decap2.zdv.uni-tuebingen.de> Subject: Re: Header files To: shaffer@phyast.pitt.edu (C. David Shaffer) Date: Mon, 12 Jun 1995 23:22:17 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9506122043.AA07439@minerva.phyast.pitt.edu> from "C. David Shaffer" at Jun 12, 95 04:43:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1589 > > Hello, > > I have looked through the README and files and all of the > guides but I can't figure out how to get gcc to look in the right > place for my headers. I have assigned INCLUDE to GNU:os-include and > have un-arched the CBM headers in that dir. The problem I have, > though, is not with these headers but with stdio.h. If I #include this > file I get all kinds of "Undefined reference to _builtin_printf" or > some such thing. This makes me think that gcc is looking at my SAS/C > headers but since I've reassigned INCLUDE: how the heck does gcc know > where they are? Anyone have any ideas? BTW I tried snoopdos to > follow the gcc file opening attempts but I don't even see it try to > open stdio.h. I really a newbie... The INCLUDE: assign is used by SAS/C, not by gcc. gcc has certain default directories where it looks for headers, GNU:os-includes is one of them. The problem with _builtin_printf sounds very much like you are using headers from SAS/C. If this is the case, remove all files from GNU:os-includes with delete GNU:os-includes/#? (*Don't* use the ALL switch. :-) Probably certain subdirectories need be removed as well, sys for example. If you like an assign (say GNUINCLUDE:) you might wish to use the gcc installer script. I send the latest version with separate mail to you, however, you need to add the GCCSTACK variable to your environment manually after the installation. (The script already assumes gcc 2.7.0, which is in beta stage.) This is done as follows: setenv GCCSTACK 350000 copy ENV:GCCSTACK ENVARC: Good luck, Jochen From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 09:24:17 1995 Received: from minerva.phyast.pitt.edu ([136.142.111.2]) by nic.funet.fi with SMTP id <89023-3>; Tue, 13 Jun 1995 09:23:06 +0300 Received: from durer.phyast.pitt.edu by minerva.phyast.pitt.edu (4.1/1.34) id AA09708; Tue, 13 Jun 95 02:22:47 EDT Date: Tue, 13 Jun 95 02:22:47 EDT From: shaffer@phyast.pitt.edu (C. David Shaffer) Message-Id: <9506130622.AA09708@minerva.phyast.pitt.edu> Received: by durer.phyast.pitt.edu (4.1/SMI-4.1) id AA14251; Tue, 13 Jun 95 02:28:41 EDT To: amiga-gcc-port@nic.funet.fi Subject: Include file problems Thanks to all who replied. The problem came from an assign to GNUINCLUDE: which had pointed at my SAS/C stuff. -David Shaffer -Department of Physics -The University of Pittsburgh -Pittsburgh, PA 15260 -shaffer@phyast.pitt.edu From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 12:06:12 1995 Received: by nic.funet.fi via suspension id <90158-2>; Tue, 13 Jun 1995 12:05:08 +0300 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <90136-1>; Tue, 13 Jun 1995 11:25:36 +0300 Received: from caeiro.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA02262; Tue, 13 Jun 1995 10:26:42 GMT Received: by caeiro.ci.uminho.pt (5.4R2.10/200.1.1.4) id AA02294; Tue, 13 Jun 1995 10:22:09 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506130822.AA02294@caeiro.ci.uminho.pt> Subject: help me with getch To: amiga-gcc-port@nic.funet.fi (amiga) Date: Tue, 13 Jun 1995 10:22:08 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 495 i'm trying to use getch with gcc and it give an error wgetch getch not defined when linking i include the curses.h but the error continue existing. NOTE: Sorry for the English, i'm Port. __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 18:38:52 1995 Received: from mail.Germany.EU.net ([192.76.144.65]) by nic.funet.fi with ESMTP id <90158-3>; Tue, 13 Jun 1995 18:36:43 +0300 Received: by mail.Germany.EU.net with SMTP (8.6.5:29/EUnetD-2.5.1.g) via EUnet id RAA06778; Tue, 13 Jun 1995 17:38:26 +0200 Message-Id: <9506131524.AA01751@GWEU.softlab.de> Received: from AA by GWEU.softlab.de with SMTP (5.65/GEN-1.1.8) via EUnet for [192.76.144.65] id AA01751; Tue, 13 Jun 95 17:24:35 +0200 Received: from H8 by AA with SMTP (1.37.109.4/16.2) id AA07386; Tue, 13 Jun 95 17:38:50 +0200 Received: by H8 (1.37.109.4/16.2) id AA10302; Tue, 13 Jun 95 17:36:59 +0200 Date: Tue, 13 Jun 95 17:36:59 +0200 From: SMH@softlab.de To: amiga-gcc-port@lists.funet.fi SUBSCRIBE amiga-gcc-port Hans Schmid From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 18:54:44 1995 Received: from chx400.switch.ch ([130.59.1.2]) by nic.funet.fi with ESMTP id <89336-4>; Tue, 13 Jun 1995 18:53:47 +0300 Received: from isbiel.ch (actually sunny.isbiel.ch) by chx400.switch.ch with SMTP (PP); Tue, 13 Jun 1995 17:52:36 +0200 Received: from odis.isbiel.ch ([147.87.2.253]) by isbiel.ch (4.1/SMI-4.1.e) id AA11021; Tue, 13 Jun 95 17:52:29 +0200 Received: from ODIS/SpoolDir by odis.isbiel.ch (Mercury 1.21); 13 Jun 95 17:52:29 +200 Received: from SpoolDir by ODIS (Mercury 1.21); 13 Jun 95 17:52:19 +200 From: BOOS CHRISTOPH 1994M1B Organization: Biel School of Engineering To: amiga-gcc-port@nic.funet.fi Date: Tue, 13 Jun 1995 17:52:13 MET+100 Subject: round-problem Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <1F7A7E71B9@odis.isbiel.ch> hello I have trouble with my GNU 2.6.3 (aminet version). I don't know if it is a GNU-bug or if I forgot only one of this thousand options... When I compile and start the following Programm... #include main() { printf("%d %d %d\n",(int)1.5,(int)1.7,(int)2.5,(int)2.7); } ... I get this output: 2 2 2 3 I thought the original ANSI-C should ignore all numbers after the point ( (int)3.14 becomes 3 etc), but my GNU rounds - mostly... (int)2.5 becomes 2 and not 3 !?! in float.h (/include/machine & /lib/gcc-lib/mc680x0/2.6.3/include) I found the FLT_ROUNDS #define and tried several different numbers but without success. So, what can I do? greetings Christoph From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 19:29:18 1995 Received: from prdnet.polaroid.com ([137.252.9.11]) by nic.funet.fi with ESMTP id <89282-2>; Tue, 13 Jun 1995 19:27:18 +0300 Date: Tue, 13 Jun 1995 12:11:06 -0400 (EDT) From: "David J. Ruscak" Subject: round-problem To: amiga-gcc-port@lists.funet.FI Content-transfer-encoding: 7BIT Full-Name: David J. Ruscak Mailer: Elm [revision: 70.85] Message-Id: <95Jun13.192718+0300_eet_dst.89282-2+33@nic.funet.fi> > >#include >main() >{ > printf("%d %d %d\n",(int)1.5,(int)1.7,(int)2.5,(int)2.7); >} >... I get this output: >2 2 2 3 I believe the rounding from 2.5 to 2 is the correct Math, that any number that ends in five (5) is rounded to the nearest EVEN number. Thanks, Dave Ruscak Senior Engineer Polaroid Corp. ruscakd@polaroid.com From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 19:49:28 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89200-1>; Tue, 13 Jun 1995 19:47:19 +0300 Received: by theseas.ntua.gr with UUCP; Tue, 13 Jun 1995 19:48:28 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07c6@kriton.UUCP>; Tue, 13 Jun 95 19:42:40 EET Date: Tue, 13 Jun 95 19:42:40 EET Message-Id: <9506131742.07c6@kriton.UUCP> In-Reply-To: <1F7A7E71B9@odis.isbiel.ch> (from BOOS CHRISTOPH 1994M1B ) (at Tue, 13 Jun 1995 17:52:13 MET+100) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 699 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: BOOSC1@odis.isbiel.ch Cc: amiga-gcc-port@lists.funet.fi Subject: Re: round-problem Hi BOOS (BOOS CHRISTOPH 1994M1B), in <1F7A7E71B9@odis.isbiel.ch> on Jun 13 you wrote: > When I compile and start the following Programm... > > #include > main() > { > printf("%d %d %d\n",(int)1.5,(int)1.7,(int)2.5,(int)2.7); > } > > ... I get this output: > 2 2 2 3 (There is a "%d" missing from the printf format, but this can't be the cause of the problem.) After adding the missing "%d", the above program works fine (it prints "1 1 2 2") on my 68040. Weird! -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Selective retribution will bring any dissident to heel." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 19:51:02 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89681-2>; Tue, 13 Jun 1995 19:50:33 +0300 Received: by theseas.ntua.gr with UUCP; Tue, 13 Jun 1995 19:48:30 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07c1@kriton.UUCP>; Tue, 13 Jun 95 19:21:01 EET Date: Tue, 13 Jun 95 19:21:01 EET Message-Id: <9506131721.07c1@kriton.UUCP> In-Reply-To: <9506130822.AA02294@caeiro.ci.uminho.pt> (from si215603@ci.uminho.pt (Luis Antonio F.Alves)) (at Tue, 13 Jun 1995 10:22:08 +0200 (MET DST)) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1241 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: si215603@ci.uminho.pt Cc: amiga-gcc-port@lists.funet.fi Subject: Re: help me with getch Hi Luis (Luis Antonio F.Alves), in <9506130822.AA02294@caeiro.ci.uminho.pt> on Jun 13 you wrote: > i'm trying to use getch with gcc and it give an > error > > wgetch > getch not defined when linking > > i include the curses.h but the error continue existing. Do the errors you get during linking refer to getch/wgetch or do you get a bunch of unresolved references to various symbols like _tputs, _tgoto and other termcap subroutines? If it is the latter, this simply means you forgot to link with the termcap library, e.g.: gcc main.o -lcurses -ltermcap ^^^^^^^^^ If it is the former, make sure that every file where you invoke getch includes , as getch is a macro (the linker warnings can help you in this case, as they print the name of the file where the reference was encountered). Also make sure that the inclusion of is not prevented by preprocessor macros, e.g., that you don't have things like: #ifdef unix #include #endif I hope this helps, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Selective retribution will bring any dissident to heel." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 20:09:31 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89282-3>; Tue, 13 Jun 1995 20:07:58 +0300 Received: by theseas.ntua.gr with UUCP; Tue, 13 Jun 1995 20:04:26 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07cc@kriton.UUCP>; Tue, 13 Jun 95 19:59:29 EET Date: Tue, 13 Jun 95 19:59:29 EET Message-Id: <9506131759.07cc@kriton.UUCP> In-Reply-To: <95Jun13.192718+0300_eet_dst.89282-2+33@nic.funet.fi> (from "David J. Ruscak" ) (at Tue, 13 Jun 1995 12:11:06 -0400 (EDT)) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1128 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: RUSCAKD@cliffy.polaroid.com Cc: amiga-gcc-port@lists.funet.fi Subject: Re: round-problem Hi David (David J. Ruscak), in <95Jun13.192718+0300_eet_dst.89282-2+33@nic.funet.fi> on Jun 13 you wrote: > I believe the rounding from 2.5 to 2 is the correct Math, that any number > that ends in five (5) is rounded to the nearest EVEN number. This does not seem quite right. Do you mean to say that 1.5->2 2.5->2 3.5->4 4.5->4? Perhaps you meant nearest INTEGER, not nearest EVEN number, which is what the original poster noticed on his machine, but which does not appear to happen on mine, where (int) truncates instead of rounding. According to K&R 2nd ed. p.197, the latter is the correct behavior: "When a value of floating type is converted to integral type, the fractional part is discarded; if the resulting value cannot be represented in the integral type, the behavior is undefined. In particular, the result of converting negative floating values to unsigned integral types is not specified." -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Selective retribution will bring any dissident to heel." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 22:28:05 1995 Received: from cats.ucsc.edu ([128.114.129.22]) by nic.funet.fi with SMTP id <89060-4>; Tue, 13 Jun 1995 22:25:26 +0300 Received: from lick.ucolick.org by cats.ucsc.edu with SMTP id MAA10198; Tue, 13 Jun 1995 12:25:03 -0700 Received: from helios.ucolick.org by lick.ucolick.org (4.1/SMI-4.1) id AA22053; Tue, 13 Jun 95 12:25:02 PDT Received: from (bigdog.ucolick.org) by helios.ucolick.org (helios.ucolick.org) (4.1/SMI-4.1) id AA26761; Tue, 13 Jun 95 12:24:59 PDT From: tra@lick.ucolick.org (Ted Asocks) Received: by (5.65/8.6.10) id AA11947 for amiga-gcc-port@lists.funet.fi; Tue, 13 Jun 1995 12:24:58 -0700 Illegal-Object: Syntax error in Message-Id: value found on nic.funet.fi: Message-Id: <9506131924.AA11947@> ^-illegal subdomain in domain, propably extra '.' at the end of the address Subject: problems compiling ghostscript To: amiga-gcc-port@nic.funet.fi Date: Tue, 13 Jun 1995 12:24:58 -0800 (PDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2541 I have taken the ghostscript tar archive off the FreshFish Vol CD. and am attempting to recompile it in order to add a printer driver. I have not been having much success. I have an A3000/25 with 6MB. The version of gcc is: 17 tra@chicha: gcc -v Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 I first tried to compile the suite with an A3640 (the 4000 040 CPU) card installed, I had many mysterious failures during the build where make would die quietly without an error and simply restarting the build would let it continue. I finally got the object files linked but when I ran it a bus error was reported and crashed the machine. I removed the A3640 (There may be compatibility problems with the hardware) and rebuilt it using the native 3000 hardware. The compile took much longer but it only had to be restarted once. So now I have an executable that still causes a recoverable alert (unless I run enforcer which traps it). When I start it I get: 23 tra@chicha: ./gs Initializing... While reading gs_statd.ps: Error: /ioerror in -filetype- Operand stack: Execution stack: %interp_exit --nostringval-- --nostringval-- --nostringval-- false --nostringval-- --nostringval-- Dictionary stack: 405/547 4/200 405/547 Current file position is 19514 Enforcer reports reads and writes to both low and high addresses. In the effort to discover where the problem was I compiled gs with a -DEBUG flag. The makefile mentions that this makes the code slow, but on my system if I add a debug flag it runs so slow as to be unusable. I do not get any valid output for minutes!!! I also tried running ixtrace but I seem unable to get consistent results. Typically running ixtrace forces the program to lockup when it hits the offending code and output stops in the middle of a fprintf statement. Since I'm not capable of actually "porting" this app to AmigaOS and the source I have is supposed to be amigafied I'm wondering if I'm missing something real simple. Do I need the stderr patch or something to clean this up. Does anyone have any suggestions as to what I should try next? The amiga-gcc.mak file in gs used a -O6 as a CFLAG. I didn't notice that in the documentation, is this an undocumented feature? Thanks. -- --------------------------------------------------------------------------- Ted Asocks tra@ucolick.org Systems Administrator UCO/Lick Observatory From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 22:46:43 1995 Received: from prdnet.polaroid.com ([137.252.9.11]) by nic.funet.fi with ESMTP id <90780-2>; Tue, 13 Jun 1995 22:44:51 +0300 Date: Tue, 13 Jun 1995 15:40:26 -0400 (EDT) From: "David J. Ruscak" Subject: round-problem To: amiga-gcc-port@lists.funet.FI Content-transfer-encoding: 7BIT Full-Name: David J. Ruscak Mailer: Elm [revision: 70.85] Message-Id: <95Jun13.224451+0300_eet_dst.90780-2+36@nic.funet.fi> Kriton, >This does not seem quite right. Do you mean to say that >1.5->2 >2.5->2 >3.5->4 >4.5->4? Yes, thats the rule! ex: 3.5 -> 4 4.5 -> 4 +____ +___ 8.0 -> 8 You see how it AVERAGES OUT . ;-) [trust me ...] Thanks, Dave Ruscak Senior Engineer Polaroid Corp. ruscakd@polaroid.com From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 23:06:18 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89045-1>; Tue, 13 Jun 1995 23:05:19 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sLd6d-0004naC; Tue, 13 Jun 95 14:02 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: problems compiling ghostscript To: tra@lick.ucolick.org (Ted Asocks) Date: Tue, 13 Jun 1995 14:02:39 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199506131929.MAA23434@cygnus.com> from "Ted Asocks" at Jun 13, 95 12:24:58 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1347 > I have taken the ghostscript tar archive off the FreshFish Vol CD. and > am attempting to recompile it in order to add a printer driver. I have not > been having much success. Are you also using the other tools of the FreshFish CD (gcc, sh, make, etc)? Some of the problems you describe sound like problems with your tools. > Since I'm not capable of actually "porting" this app to AmigaOS and the source > I have is supposed to be amigafied I'm wondering if I'm missing something > real simple. Do I need the stderr patch or something to clean this up. Does > anyone have any suggestions as to what I should try next? > > The amiga-gcc.mak file in gs used a -O6 as a CFLAG. I didn't notice that in > the documentation, is this an undocumented feature? I don't think amiga-gcc.mak is even used in my compilations. To compile, here is what I do, assuming that the source is in gnu-src:src/gs-2.6.1.4: makedir build:gs-build cd build:gs-build sh /gnu-src/src/gs-2.6.1.4/configure -v m68k-cbm-amigados make That's it. You should be able to build it using the Makefile that configure generates. Almost all of the tools in my GNU tree are set up to use configure, which also allows you to keep the build and source trees completely separate, thus not corrupting your source distribution with files generated during the build. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Jun 13 23:31:50 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89028-3>; Tue, 13 Jun 1995 23:30:27 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sLdUO-0004naC; Tue, 13 Jun 95 14:27 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ar and long filenames To: jsshephe@UNDERGRAD.MATH.UWATERLOO.CA Date: Tue, 13 Jun 1995 14:27:11 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Jeff Shepherd" at May 30, 95 01:15:38 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 975 > There seems to be a bug in ar (found in the gcc2.6.3 archive) dealing with > long filenames. Here is a simple test that uncovers the bug. > ... In my current GNU tree, which will be on the FreshFish Vol 10 CD, I've switched completely to the BFD based binutils except for the linker. The BFD version of ar works just fine with long filenames, and the archives are still acceptable to the 1.8.X binutils linker. Using the BFD version of ar to generate libtest.a per your example, and then using the older ar to get a table of contents produces: ----w---x 21/21 21 Jan 1 00:00 1970 ARFILENAMES/ rwxrwxrwx 0/ 0 0 Jun 13 12:51 1995 0 y_long_filen rwxrwxrwx 0/ 0 0 Jun 13 12:51 1995 short.o which may look bizarre, but demonstrates that the new ar packs the long name into more than one archive entry in a manner that is at least somewhat backwards compatable (or at least non-fatal) with older tools that examine or use archive contents. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 00:35:53 1995 Received: from cats.ucsc.edu ([128.114.129.22]) by nic.funet.fi with SMTP id <89336-4>; Wed, 14 Jun 1995 00:33:43 +0300 Received: from lick.ucolick.org by cats.ucsc.edu with SMTP id OAA26673; Tue, 13 Jun 1995 14:31:01 -0700 Received: from helios.ucolick.org by lick.ucolick.org (4.1/SMI-4.1) id AA22630; Tue, 13 Jun 95 14:30:55 PDT Received: from (bigdog.ucolick.org) by helios.ucolick.org (helios.ucolick.org) (4.1/SMI-4.1) id AA02572; Tue, 13 Jun 95 14:30:53 PDT From: tra@lick.ucolick.org (Ted Asocks) Received: by (5.65/8.6.10) id AA12931 for amiga-gcc-port@nic.funet.fi; Tue, 13 Jun 1995 14:30:52 -0700 Illegal-Object: Syntax error in Message-Id: value found on nic.funet.fi: Message-Id: <9506132130.AA12931@> ^-illegal subdomain in domain, propably extra '.' at the end of the address Subject: Re: problems compiling ghostscript To: fnf@amigalib.com (Fred Fish) Date: Tue, 13 Jun 1995 14:30:51 -0800 (PDT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Fred Fish" at Jun 13, 95 02:02:39 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1878 My original problem: > > I have taken the ghostscript tar archive off the FreshFish Vol CD. and > > am attempting to recompile it in order to add a printer driver. I have not > > been having much success. Fred Fish writes: > Are you also using the other tools of the FreshFish CD (gcc, sh, make, etc)? > Some of the problems you describe sound like problems with your tools. No, I was using a distribution off of Aminet, all the build tools were local to my disk. I did try and use the FreshFish CD archive but when I assigned etc: to GNU:etc the korn shell didn't like not finding an /etc/ksh.kshrc. Unless you use an internal command you get "undefined error 0" or something like that reported. Perhaps my existing setting of a global ENV: effects that. I will reassign etc to a directory with a startup file and see how that works. > I don't think amiga-gcc.mak is even used in my compilations. To compile, > here is what I do, assuming that the source is in gnu-src:src/gs-2.6.1.4: > > makedir build:gs-build > cd build:gs-build > sh /gnu-src/src/gs-2.6.1.4/configure -v m68k-cbm-amigados > make > > That's it. You should be able to build it using the Makefile that configure > generates. > > Almost all of the tools in my GNU tree are set up to use configure, which > also allows you to keep the build and source trees completely separate, thus > not corrupting your source distribution with files generated during the build. > > -Fred Configure, now there is a nice tool to work with! Thanks for the info, I'll get started on a new build... :-) Thanks!!! -- --------------------------------------------------------------------------- Ted Asocks tra@ucolick.org Systems Administrator VOICE: (408)459-4020 UCO/Lick Observatory FAX: (408)454-9863 From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 09:45:30 1995 Received: from minerva.phyast.pitt.edu ([136.142.111.2]) by nic.funet.fi with SMTP id <89392-3>; Wed, 14 Jun 1995 09:43:11 +0300 Received: from durer.phyast.pitt.edu by minerva.phyast.pitt.edu (4.1/1.34) id AA14114; Wed, 14 Jun 95 02:42:58 EDT Date: Wed, 14 Jun 95 02:42:58 EDT From: shaffer@phyast.pitt.edu (C. David Shaffer) Message-Id: <9506140642.AA14114@minerva.phyast.pitt.edu> Received: by durer.phyast.pitt.edu (4.1/SMI-4.1) id AA14505; Wed, 14 Jun 95 02:48:52 EDT To: amiga-gcc-port@nic.funet.fi Subject: Compiling for non-Amiga 68k Hello, I am using some of the m68k series as embedded controllers. Currently I program them entirely in assembler but I was wondering if I could use the amiga port of gcc for such a configuration. I wonder... "Are there any Amiga dependencies in libgcc.a or libm.a? If so, can they be worked around?" "What about converting the output of ld to Motorola S-format?" "Has anyone built a subset of libg++ which requires no specific operating system? Don't think I'm being silly...there are many general purpose routines in this library." Also, I would like to hear from anyone who is using amiga-gcc for compilation for other processors (such as i960). Any other wisdom (via e-mail if appropriate) on such uses of the amiga port of gcc would be appreciated. -David Shaffer -Department of Physics -The University of Pittsburgh -Pittsburgh, PA 15260 -shaffer@phyast.pitt.edu From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 11:15:26 1995 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <89302-4>; Wed, 14 Jun 1995 11:11:28 +0300 Received: by hald.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun14.111128+0300_eet_dst.89302-4+25@nic.funet.fi> From: To: Date: Wed, 14 Jun 1995 11:11:20 +0300 Date: Wed, 14 Jun 1995 10:11:48 +0200 (METDST) From: Rask Lambertsen To: Ted Asocks Cc: amiga-gcc-port@nic.funet.fi Subject: Re: problems compiling ghostscript In-Reply-To: <9506131929.AA05658@gbar.dtu.dk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 13 Jun 1995, Ted Asocks wrote: > > I have taken the ghostscript tar archive off the FreshFish Vol CD. and > am attempting to recompile it in order to add a printer driver. I have not > been having much success. > > I have an A3000/25 with 6MB. The version of gcc is: > > 17 tra@chicha: gcc -v > Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs > gcc version 2.6.3 > > I first tried to compile the suite with an A3640 (the 4000 040 CPU) card > installed, I had many mysterious failures during the build where make > would die quietly without an error and simply restarting the build would let > it continue. I finally got the object files linked but when I ran it > a bus error was reported and crashed the machine. I removed the A3640 > (There may be compatibility problems with the hardware) and rebuilt it > using the native 3000 hardware. The compile took much longer but it only > had to be restarted once. > > So now I have an executable that still causes a recoverable alert (unless > I run enforcer which traps it). When I start it I get: (output deleted) How much stack are you using? It sounds to me like you are using too small a stack. Try something like 5. HD1> Stack `Eval 64*1024` This gives you 64 kb stack. If you still have problems, try using even more stack. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 11:20:24 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <89418-4>; Wed, 14 Jun 1995 11:17:42 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA21848 (5.65c8/IDA-1.4.4 for ); Wed, 14 Jun 1995 10:17:26 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA21263; Wed, 14 Jun 95 10:17:25 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506140817.AA21263@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: round-problem To: RUSCAKD@cliffy.polaroid.com (David J. Ruscak) Date: Wed, 14 Jun 1995 10:17:25 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Jun13.192718+0300_eet_dst.89282-2+33@nic.funet.fi> from "David J. Ruscak" at Jun 13, 95 12:11:06 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 173 > > >... I get this output: > >2 2 2 3 > Are you using libnix? Then try to get the newest version on nic.funet.fi or on Philippes site colombo.telesys-innov.fr. Matthias From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 11:24:05 1995 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <89499-3>; Wed, 14 Jun 1995 11:21:14 +0300 Received: by hald.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun14.112114+0300_eet_dst.89499-3+15@nic.funet.fi> From: To: Date: Wed, 14 Jun 1995 11:21:02 +0300 Date: Wed, 14 Jun 1995 10:21:41 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: More FTP sites for include files Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I have found more ways of getting the Amiga OS include files via FTP: ftp://ftp.rz.uni-wuerzburg.de/pub/amiga/mpearls2/pearls/dev/includes/c/ The above URL is a directory where the C include files are stored. They are not archived or compressed in any way, and they are stored in the normal OS include subdirectories. The assembler include files are available in the same way: ftp://ftp.rz.uni-wuerzburg.de/pub/amiga/mpearls2/pearls/dev/includes/asm/ Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 11:53:16 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <89505-4>; Wed, 14 Jun 1995 11:50:22 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA03477 (5.65c8/IDA-1.4.4 for ); Wed, 14 Jun 1995 10:50:09 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA21361; Wed, 14 Jun 95 10:50:08 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506140850.AA21361@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: gcc with overlays To: amiga-gcc-port@nic.funet.fi Date: Wed, 14 Jun 1995 10:50:08 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 969 > > > Whats the point in compiling with GCC unless you are creating a > > ixemul client????? > > I think Matthias Fleischer would like to answer this. > Yep :-). I can give you some reasons to use gcc instead of other amiga compilers: >From a beginners point of view who wants to get his first compiler gcc has the advantage that you get a good compiler for almost no money (you may want to count the harddisk space gcc needs if you keep it: about 10$ for 20MB these days). >From a programmers point of view its good to have sources available (to track down bugs (is it the libc or the OS...), change the behaviour of the libc (why is malloc so slow...), etc.) For a software company gcc _guarantees_ that you may get additional licences in the future (to keep the few compiler dependencies you cannot avoid future compatible). I know that there are also some good reasons against gcc, but you wanted to hear some for :-} (and they are not too bad). Matthias From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 14:07:58 1995 Received: from mail.Germany.EU.net ([192.76.144.65]) by nic.funet.fi with ESMTP id <89933-2>; Wed, 14 Jun 1995 14:05:43 +0300 Received: by mail.Germany.EU.net with SMTP (8.6.5:29/EUnetD-2.5.1.g) via EUnet id NAA04336; Wed, 14 Jun 1995 13:07:14 +0200 Message-Id: <9506141052.AA01399@GWEU.softlab.de> Received: from AA by GWEU.softlab.de with SMTP (5.65/GEN-1.1.8) via EUnet for [192.76.144.65] id AA01399; Wed, 14 Jun 95 12:52:43 +0200 Received: from H8 by AA with SMTP (1.37.109.4/16.2) id AA05039; Wed, 14 Jun 95 13:07:41 +0200 Received: by H8 (1.37.109.4/16.2) id AA08149; Wed, 14 Jun 95 13:05:52 +0200 Date: Wed, 14 Jun 95 13:05:52 +0200 From: SMH@softlab.de To: amiga-gcc-port@lists.funet.fi SUB amiga-gcc-port Hans Schmid From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 15:14:44 1995 Received: from acl.lanl.gov ([128.165.147.1]) by nic.funet.fi with SMTP id <89439-3>; Wed, 14 Jun 1995 15:12:02 +0300 Received: from booboo.acl.lanl.gov (booboo.acl.lanl.gov [128.165.114.74]) by acl.lanl.gov (8.6.11/8.6.10) with ESMTP id GAA17190 for ; Wed, 14 Jun 1995 06:10:35 -0600 From: "Paul J. Hinker" Received: (hinker@localhost) by booboo.acl.lanl.gov (8.6.9/8.6.4) id GAA13401; Wed, 14 Jun 1995 06:10:34 -0600 Date: Wed, 14 Jun 1995 06:10:34 -0600 Message-Id: <199506141210.GAA13401@booboo.acl.lanl.gov> To: amiga-gcc-port@nic.funet.fi Reply-To: "Paul J. Hinker" UNSUBSCRIBE amiga-gcc-port hinker@acl.lanl.gov UNSUBSCRIBE amiga-gcc-port hinker@lanl.gov From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 17:02:14 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89282-2>; Wed, 14 Jun 1995 16:59:47 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 14 Jun 1995 15:57:28 +0200 Received: from mammern.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA16072; Wed, 14 Jun 95 15:57:30 +0200 Date: Wed, 14 Jun 95 15:57:30 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9506141357.AA16072@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@lists.funet.fi Subject: Re: round-problem Kriton writes: > This does not seem quite right. Do you mean to say that > 1.5->2 > 2.5->2 > 3.5->4 > 4.5->4? it's funny that the same topic came up a few weeks ago in some LISP group. The rationale behind this behaviour is that by rounding to even (or odd) you prevent yourself from the accumulation of rounding errors and to keep other properties true (there's maths and statistics behind this scheme). Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 18:28:25 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89294-4>; Wed, 14 Jun 1995 18:26:33 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sLvEw-0004nYC; Wed, 14 Jun 95 09:24 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: ixemul 41.0 available To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Wed, 14 Jun 1995 09:24:26 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 985 Version 41.0 of the ixemul.library is now available on aminet in the dev/gcc directory. This version fixes several bugs, including one which trashes memory. It also has networking support merged back in from an earlier version and supports stack checking and stack extension when used with a gcc that supports those features. With the exception of binaries that used one of the following functions, this library should be backwards compatible with existing gcc compiled binaries: connect sendto send sendmsg recvfrom recv recvmsg shutdown setsockopt getsockopt getsockname getpeername unsetenv socket bind listen accept tcdrain tcflush tcflow tcsendbreak The reason for the incompatibility is that the 39.XX and 40.XX versions used 4 library entry points for different purposes. This has been resolved by having those entry points put up a requester if they are ever called, and the functions that collided have been moved to different entry points. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 18:33:07 1995 Received: from undergrad.math.uwaterloo.ca ([129.97.204.13]) by nic.funet.fi with SMTP id <89202-3>; Wed, 14 Jun 1995 18:32:00 +0300 Received: from math.uwaterloo.ca ([129.97.140.144]) by undergrad.math.uwaterloo.ca with SMTP id <56832-2>; Wed, 14 Jun 1995 11:31:43 -0400 Date: Wed, 14 Jun 1995 11:31:34 -0400 From: Jeff Shepherd To: Fred Fish cc: Amiga GCC mailing list Subject: Re: ixemul 41.0 available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 14 Jun 1995, Fred Fish wrote: > With the exception of binaries that used one of the following > functions, this library should be backwards compatible with existing > gcc compiled binaries: > > connect > sendto > send > sendmsg > recvfrom > recv > recvmsg > shutdown > setsockopt > getsockopt > getsockname > getpeername > unsetenv > socket ... I was wondering - what TCP/IP package does this socket code work for? jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 18:46:02 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <89516-3>; Wed, 14 Jun 1995 18:44:32 +0300 Received: from caeiro.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA21233; Wed, 14 Jun 1995 17:44:56 GMT Received: by caeiro.ci.uminho.pt (5.4R2.10/200.1.1.4) id AA10254; Wed, 14 Jun 1995 17:40:22 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506141540.AA10254@caeiro.ci.uminho.pt> Subject: ixemul 41.0 To: amiga-gcc-port@nic.funet.fi (Luis Alves) Date: Wed, 14 Jun 1995 17:40:22 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 369 I went look for it but didn't find it can anybody be more specific. __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 19:22:28 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89362-3>; Wed, 14 Jun 1995 19:20:41 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 14 Jun 95 18:16 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 14 Jun 95 18:11 MET DST Message-Id: Subject: Re: ixemul 41.0 available To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 14 Jun 1995 18:11:20 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 348 does this mean proper autodocs and examples are included ? walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 19:43:50 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89292-3>; Wed, 14 Jun 1995 19:42:31 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sLwN8-0004nYC; Wed, 14 Jun 95 10:36 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ixemul 41.0 available To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Wed, 14 Jun 1995 10:36:58 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Walter Harms" at Jun 14, 95 06:11:20 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 426 > does this mean proper autodocs and examples are included ? No, but everyone should feel free to contribute such things. This is a community effort. I am acting primarily as the repository for the official source, and as coordinator for development projects. I don't have time to do lots of work myself. Merging features from the various versions into the current source base is keeping me busy enough for now. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 19:45:00 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <89513-3>; Wed, 14 Jun 1995 19:43:59 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id ae01317; 14 Jun 95 17:35 +0100 Received: from flevel.demon.co.uk by post.demon.co.uk id ah29687; 14 Jun 95 17:34 +0100 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA005y7; Wed, 14 Jun 95 15:42:38 GMT Date: Wed, 14 Jun 95 15:42:38 GMT Message-Id: <9506141542.AA005y6@flevel.demon.co.uk> Message-Id: <20d2c46d.186a1-dev@flevel.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: amiga-gcc-port@nic.funet.fi Subject: Env: scanning and ixemul Hi, I was just wondering if the author(s) of ixemul were thinking of doing something about ixemul.library scanning env: every time a program is run. It means the compiled programs are so slow I won't even use GNU C. I was talking to someone on the AmigOS mailing list. He says that it takes about 5 seconds, on his machine, for each program that starts up with ixemul. I do think GCC is good but the slowness of ixemul executables really does let it down. Sorry to nag, I know we have had this discussion before and agreed (I think) that something must be done. Surely it wouldn't be too hard to add notification to the env: directory and just re-scan it when it changes?? Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk Ami-FileSafe (AFS) ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 21:35:18 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89459-1>; Wed, 14 Jun 1995 21:33:22 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sLy9l-0004nYC; Wed, 14 Jun 95 12:31 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Env: scanning and ixemul To: dev@flevel.demon.co.uk Date: Wed, 14 Jun 1995 12:31:17 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <20d2c46d.186a1-dev@flevel.demon.co.uk> from "dev@flevel.demon.co.uk" at Jun 14, 95 03:42:38 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 271 > Sorry to nag, I know we have had this discussion before and agreed (I think) that something > must be done. Surely it wouldn't be too hard to add notification to the env: directory and > just re-scan it when it changes?? Do we have a volunteer to work on this? -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Jun 14 21:55:52 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89331-3>; Wed, 14 Jun 1995 21:54:33 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sLyTQ-0004nYC; Wed, 14 Jun 95 12:51 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ixemul 41.0 available To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Wed, 14 Jun 1995 12:51:36 -0700 (MST) Cc: fnf@amigalib.com, vinsci@nic.funet.fi (Leonard Norrgard), amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: <9506141838.AA17000@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Jun 14, 95 08:38:43 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2871 > > With the exception of binaries that used one of the following > > functions, this library should be backwards compatible with existing > > gcc compiled binaries: > [approx 20 names deleted] > > I don't understand why the incompatibility list is so long as only four > functions are concerned. Furthermore, I believe that noone using > X+ixemul(39.47 or 48) programs will be happy with an incompatibility > concerning common networking functions like send and connect. They > won't be able to use the new library (thus it's useless) or did I > misunderstand something? Ok, I'll try to explain it. In the last version released with source from Markus (39.47) the syscall.def file ends with: . . . SYSTEM_CALL (setgid, 445) SYSTEM_CALL (vfork, 446) In the 40.4 version, it ends with: . . . SYSTEM_CALL (setgid, 445) SYSTEM_CALL (vfork, 446) SYSTEM_CALL (tcdrain, 447) SYSTEM_CALL (tcflush, 448) SYSTEM_CALL (tcflow, 449) SYSTEM_CALL (tcsendbreak, 450) In some version (39.48?) from Markus for which I don't have source, it apparently ends with: . . . SYSTEM_CALL (setgid, 445) SYSTEM_CALL (vfork, 446) SYSTEM_CALL (???, 447) SYSTEM_CALL (???, 448) SYSTEM_CALL (???, 449) SYSTEM_CALL (???, 450) Where "???" are networking functions. Which ones, I don't know since I've never seen the source nor gotten a specific list of them. This is just what I was told, and what was the motivation for the change Leonard made. In the 41.0 release, which also matches the source I got from Leonard, it ends with: . . . SYSTEM_CALL (setgid, 445) SYSTEM_CALL (vfork, 446) SYSTEM_CALL (__must_recompile1, 447) SYSTEM_CALL (__must_recompile2, 448) SYSTEM_CALL (__must_recompile3, 449) SYSTEM_CALL (__must_recompile4, 450) SYSTEM_CALL (connect, 451) SYSTEM_CALL (sendto, 452) SYSTEM_CALL (send, 453) SYSTEM_CALL (sendmsg, 454) SYSTEM_CALL (recvfrom, 455) SYSTEM_CALL (recv, 456) SYSTEM_CALL (recvmsg, 457) SYSTEM_CALL (shutdown, 458) SYSTEM_CALL (setsockopt, 459) SYSTEM_CALL (getsockopt, 460) SYSTEM_CALL (getsockname, 461) SYSTEM_CALL (getpeername, 462) SYSTEM_CALL (unsetenv, 463) SYSTEM_CALL (socket, 464) SYSTEM_CALL (bind, 465) SYSTEM_CALL (listen, 466) SYSTEM_CALL (accept, 467) SYSTEM_CALL (tcdrain, 468) SYSTEM_CALL (tcflush, 469) SYSTEM_CALL (tcflow, 470) SYSTEM_CALL (tcsendbreak, 471) Presumably there were only 4 networking functions that were in the ixemul.library in the 18.48 (?) version released by Markus with no source, and the rest were in a static library. Thus as far as I know, and it better be the case or we have just added to the confusion and will have to change things again, the syscall numbers 451-471 have not been used in any previously released version. Syscall numbers 447-450 have been used inconsistently, and thus have to be permanently removed from the set of allowable calls. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Jun 15 02:44:43 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <89492-4>; Thu, 15 Jun 1995 02:43:04 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189498>; Thu, 15 Jun 1995 01:42:24 +0200 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA15144; Thu, 15 Jun 1995 01:42:11 +0200 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9506142342.AA15144@nereid.rz.Uni-Osnabrueck.DE> Subject: BBug in math-68881.h To: amiga-gcc-port@nic.funet.fi Date: Thu, 15 Jun 1995 01:42:10 +0200 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 997 Hi ! As reported earlier (by me and others), the math-68881.h has a very harmfull bug. pow(x,y) fails if x is negative. Everybody can correct this himself by adding a negative sign in the log(x). This leads to log(-x). This bug is present in at least the 41.0 release of ixemul and all versions of gcc starting from at least 2.5.8 (My first gcc experience :). --------------------------------------------------------------------------- __inline static _CONST double _DEFUN(pow, (x, y), _CONST double x _AND _CONST double y) { [...] else /* if (x<0) */ { [...] if ((i & 1) == 0) /* even */ return exp (y * log (x)); ^^^ must be -x ! else return - exp (y * log (x)); ^^^ must be -x ! } [...] } } --------------------------------------------------------------------------- Thomas From amiga-gcc-port-owner@nic.funet.fi Thu Jun 15 11:38:51 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <89833-3>; Thu, 15 Jun 1995 11:34:00 +0300 Received: by tycho.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun15.113400+0300_eet_dst.89833-3+28@nic.funet.fi> From: To: Date: Thu, 15 Jun 1995 11:33:57 +0300 Date: Thu, 15 Jun 1995 10:34:01 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Bug in ixemul.library or ls (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Some time ago, I wrote to the list about some strange date stamps of soft links, but nobody reacted. Here's what I wrote: I think I have discovered a bug in either ixemul.library or ls. Soft links are displayed as being a "bit" older than they really are. Take a look at this: 5. HD1:> Echo "Test file to show ixemul.library/ls bug" TO testfile 5. HD1:> ln -s testfile softlink 5. HD1:> List testfile softlink DATES testfile 40 ----rwed 30-Maj-95 11:40:51 1 file - 2 blocks used softlink 40 ----rwed 30-Maj-95 11:40:51 1 file - 2 blocks used 5. HD1:> ls -l testfile softlink -rwxrwxrwx 1 amiga amiga 40 May 30 11:40 testfile lrwxrwxrwx 1 amiga amiga 1024 Jan 1 1970 softlink -> testfile ^^^^^^^^^^^^ Obviously, something goes wrong. In case it is needed, here is some system information. 5. HD1:> Version ixemul.library FULL ixemul.library 40.4 5. HD1:> ls --version GNU fileutils 3.12 5. HD1:> ShowConfig PROCESSOR: CPU 68000 CUSTOM CHIPS: ECS PAL Agnus (id=$0020), ECS Denise (id=$00fc) VERS: Kickstart version 37.175, Exec version 37.132, Disk version 38.35 RAM: Node type $a, Attributes $5 (FAST), at $200000-$3fffff (2.0 meg) Node type $a, Attributes $303 (CHIP), at $400-$fffff (~1.0 meg) BOARDS: Board + ROM (HD?) (unidentified): Prod=18260/8($4754/$8) (@$ef0000 64K) I hope someone can shed come light on this. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Jun 15 15:51:50 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90283-2>; Thu, 15 Jun 1995 15:47:55 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id NAA21010; Thu, 15 Jun 1995 13:41:47 +0100 From: Lars Hecking Message-Id: <199506151242.NAA28968@krakow.nmrc.ucc.ie> Subject: GNU:include fixes To: fnf@amigalib.com (Fred Fish), phb@colombo.telesys-innov.fr (Philippe Brand), amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Thu, 15 Jun 1995 13:42:30 +0100 (BST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 4343 These pathes apply to GNU:include and ixemul-41.0/include: o dirent.h: now include sys/types.h. I stumbled across this when compiling some Unix stuff on the Amiga. SunOS 4 and OSF/1 V2 do it the same way. o math-68881.h: this has been posted lately, I include it for sake of completeness only ;-) o paths.h: changed amiga path/file names to Unix style, corresponding to Hans Verkuils suggestions for ixemul and ixconfig. NOTE: _PATH_BSHELL and _PATH_VI reflect my personal setup (well, the old definitions reflected MWilds setup, I believe ;-) o unistd.h: a check against the source code for getpgrp () revealed that it takes indeed an argument. This is sometimes important for 'configure', to find out which flavour of process group functions is involved. diff -crw include/dirent.h gnu:include/dirent.h *** include/dirent.h Wed Feb 23 00:16:18 1994 --- gnu:include/dirent.h Tue Apr 25 16:13:07 1995 *************** *** 36,41 **** --- 36,43 ---- #ifndef _DIRENT_H_ #define _DIRENT_H_ + #include + /* * A directory entry has a struct dirent at the front of it, containing its * inode number, the length of the entry, and the length of the name diff -crw include/math-68881.h gnu:include/math-68881.h *** include/math-68881.h Wed Feb 23 00:16:02 1994 --- gnu:include/math-68881.h Thu Jun 15 11:47:18 1995 *************** *** 324,330 **** return value; } } ! else { double temp; --- 324,330 ---- return value; } } ! else /* x < 0 */ { double temp; *************** *** 336,344 **** int i = (int) y; if ((i & 1) == 0) /* even */ ! return exp (y * log (x)); else ! return - exp (y * log (x)); } else { --- 336,344 ---- int i = (int) y; if ((i & 1) == 0) /* even */ ! return exp (y * log (-x)); else ! return - exp (y * log (-x)); } else { diff -crw include/paths.h gnu:include/paths.h *** include/paths.h Wed Feb 23 00:16:26 1994 --- gnu:include/paths.h Thu Jun 1 21:30:34 1995 *************** *** 37,64 **** #define _PATHS_H_ /* Default search path. */ ! #define _PATH_DEFPATH ".:/usr/bin:/c" #define _PATH_BSHELL "/bin/sh" ! #define _PATH_CONSOLE "console:" #define _PATH_CSHELL "/bin/csh" ! #define _PATH_DEVDB "nil:" ! #define _PATH_DEVNULL "nil:" ! #define _PATH_DRUM "nil:" ! #define _PATH_KMEM "nil:" ! #define _PATH_MAILDIR "mail:" ! #define _PATH_MAN "man:" ! #define _PATH_MEM "nil:" ! #define _PATH_NOLOGIN "etc:nologin" ! #define _PATH_SENDMAIL "sbin:sendmail" #define _PATH_TTY "console:" ! #define _PATH_UNIX "nil:" ! #define _PATH_VI "c:ced" /* Provide trailing slash, since mostly used for building pathnames. */ ! #define _PATH_DEV "dev:" ! #define _PATH_TMP "t:" ! #define _PATH_VARRUN "var_run:" ! #define _PATH_VARTMP "t:" #endif /* !_PATHS_H_ */ --- 37,64 ---- #define _PATHS_H_ /* Default search path. */ ! #define _PATH_DEFPATH "/bin:/rcs:/c:." #define _PATH_BSHELL "/bin/sh" ! #define _PATH_CONSOLE "/console" #define _PATH_CSHELL "/bin/csh" ! #define _PATH_DEVDB "/nil" ! #define _PATH_DEVNULL "/nil" ! #define _PATH_DRUM "/nil" ! #define _PATH_KMEM "/nil" ! #define _PATH_MAILDIR "/mail" ! #define _PATH_MAN "/gnu/man" ! #define _PATH_MEM "/nil" ! #define _PATH_NOLOGIN "/etc/nologin" ! #define _PATH_SENDMAIL "/sbin/sendmail" #define _PATH_TTY "console:" ! #define _PATH_UNIX "/nil" ! #define _PATH_VI "/c/vim" /* Provide trailing slash, since mostly used for building pathnames. */ ! #define _PATH_DEV "/dev" ! #define _PATH_TMP "/tmp" ! #define _PATH_VARRUN "/var_run" ! #define _PATH_VARTMP "/tmp" #endif /* !_PATHS_H_ */ diff -crw include/unistd.h gnu:include/unistd.h *** include/unistd.h Sat May 20 15:54:42 1995 --- gnu:include/unistd.h Thu Jun 15 11:56:44 1995 *************** *** 81,87 **** gid_t getgid __P((void)); int getgroups __P((int, int *)); /* XXX (gid_t *) */ char *getlogin __P((void)); ! pid_t getpgrp __P((void)); pid_t getpid __P((void)); pid_t getppid __P((void)); uid_t getuid __P((void)); --- 81,87 ---- gid_t getgid __P((void)); int getgroups __P((int, int *)); /* XXX (gid_t *) */ char *getlogin __P((void)); ! pid_t getpgrp __P((pid_t)); pid_t getpid __P((void)); pid_t getppid __P((void)); uid_t getuid __P((void)); From amiga-gcc-port-owner@nic.funet.fi Thu Jun 15 15:59:02 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <89332-4>; Thu, 15 Jun 1995 15:57:42 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA05027; Thu, 15 Jun 1995 13:56:55 +0100 Date: Thu, 15 Jun 1995 13:56:12 +0100 (BST) From: Peter Ivimey-Cook To: Lars Hecking Cc: Fred Fish , Philippe Brand , Amiga GCC List Subject: Re: GNU:include fixes In-Reply-To: <199506151242.NAA28968@krakow.nmrc.ucc.ie> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 15 Jun 1995, Lars Hecking wrote: > > These pathes apply to GNU:include and ixemul-41.0/include: > o paths.h: changed amiga path/file names to Unix style, corresponding to > Hans Verkuils suggestions for ixemul and ixconfig. NOTE: _PATH_BSHELL > and _PATH_VI reflect my personal setup (well, the old definitions reflected > MWilds setup, I believe ;-) > ! #define _PATH_VI "/c/vim" I would suggest either /bin/vi (which may not exist, but is "reasonable") or /c/ed which will most likely exist. An alternative which may be of value is /system/memacs, but I guess it depends if people have deleted it :) Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Thu Jun 15 22:10:27 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <90701-4>; Thu, 15 Jun 1995 22:03:48 +0300 Received: by theseas.ntua.gr with UUCP; Thu, 15 Jun 1995 22:04:57 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07dl@kriton.UUCP>; Thu, 15 Jun 95 21:59:25 EET Date: Thu, 15 Jun 95 21:59:25 EET Message-Id: <9506151959.07dl@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 650 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: ixconfig -c (ixemul 41.0) I like the new -c option (open console if no errorstream was provided) of ixconfig/ixemul.library 41.0. We can finally do away with that silly stderrfix.o kludge. Is there a reason why -c is not the default? (I believe this is the case for most/all amiga compilers, including gcc/libnix). Regardless of what the default should be, shouldn't there be an option to reverse the effects of the -c option? -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "You don't sit on the entire sum of human knowledge without learning a thing or two." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Jun 15 22:39:45 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90327-2>; Thu, 15 Jun 1995 22:39:07 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id UAA26052; Thu, 15 Jun 1995 20:38:02 +0100 From: Lars Hecking Message-Id: <199506151940.UAA04492@mostar.nmrc.ucc.ie> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Thu, 15 Jun 1995 20:40:15 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <95Jun15.113400+0300_eet_dst.89833-3+28@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Jun 15, 95 11:33:57 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1236 > I think I have discovered a bug in either ixemul.library or ls. > Soft links are displayed as being a "bit" older than they really are. > Take a look at this: > > 5. HD1:> Echo "Test file to show ixemul.library/ls bug" TO testfile > 5. HD1:> ln -s testfile softlink > 5. HD1:> List testfile softlink DATES > testfile 40 ----rwed 30-Maj-95 11:40:51 > 1 file - 2 blocks used > softlink 40 ----rwed 30-Maj-95 11:40:51 > 1 file - 2 blocks used > 5. HD1:> ls -l testfile softlink > -rwxrwxrwx 1 amiga amiga 40 May 30 11:40 testfile > lrwxrwxrwx 1 amiga amiga 1024 Jan 1 1970 softlink -> testfile > ^^^^^^^^^^^^ > Obviously, something goes wrong. I wouldn't exactly call it a bug, it's more like a "missing" feature ;-) The bad guy here is ixemuls lstat/__stat. __stat sets the time of last access, last modification and last file status change to zero (Unix' zero is January 1st 1970). A comment in library/stat.c mentions that these values are accessible by dos/ExNext() only. The problem here seems that dos/Lock() cannot deal with symlinks. Maybe someone fluent in dos could give it a go? (I am not ;) Lars From amiga-gcc-port-owner@nic.funet.fi Thu Jun 15 22:43:19 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <90439-3>; Thu, 15 Jun 1995 22:42:49 +0300 Received: by theseas.ntua.gr with UUCP; Thu, 15 Jun 1995 22:45:49 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07dr@kriton.UUCP>; Thu, 15 Jun 95 22:40:43 EET Date: Thu, 15 Jun 95 22:40:43 EET Message-Id: <9506152040.07dr@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 535 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Problems with ixemul 41.0 stack extension I tried linking with ixemul 41.0 the test program that Mathhias Fleischer provided to test the libnix version of stack extension (bigtest-x.S). After running it 3-4 times, the program gets confused, and instead of extending the stack, it pops up a stack overflow requester. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "That's a bit of a mystery; no one's been able to decipher the carving." "It says `dig hole here'." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Jun 15 23:04:20 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90506-2>; Thu, 15 Jun 1995 23:02:33 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sMM1y-0004nYC; Thu, 15 Jun 95 14:00 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Problems with ixemul 41.0 stack extension To: kyrimis@theseas.ntua.gr Date: Thu, 15 Jun 1995 14:00:50 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9506152040.07dr@kriton.UUCP> from "Kriton Kyrimis" at Jun 15, 95 10:40:43 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 615 > I tried linking with ixemul 41.0 the test program that Mathhias Fleischer > provided to test the libnix version of stack extension (bigtest-x.S). After > running it 3-4 times, the program gets confused, and instead of extending the > stack, it pops up a stack overflow requester. The stack checking and stack extension options should be considered still experimental. I tried recompiling a number of the GNU tools with stack extension as the default and got random problems, as you've noted. I don't have time to work on this, but hopefully someone will, and send back the diffs for any problems found. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Jun 16 14:18:58 1995 Received: from disperse.demon.co.uk ([158.152.1.77]) by nic.funet.fi with SMTP id <90006-3>; Fri, 16 Jun 1995 14:16:31 +0300 Received: from post.demon.co.uk by disperse.demon.co.uk id ab01676; 16 Jun 95 12:14 +0100 Received: from flevel.demon.co.uk by post.demon.co.uk id ad07242; 16 Jun 95 12:14 +0100 Received: by flevel.demon.co.uk (V1.16/Amiga) id AA006pb; Fri, 16 Jun 95 11:39:54 GMT Date: Fri, 16 Jun 95 11:39:54 GMT Message-Id: <9506161139.AA006pa@flevel.demon.co.uk> Message-Id: <20d52e81.a6041-dev@flevel.demon.co.uk> In-Reply-To: (from Fred Fish ) (at Wed, 14 Jun 1995 12:31:17 -0700 (MST)) X-Mailer: //\\miga Electronic Mail (AmiElm 5.42) Reply-To: dev@flevel.demon.co.uk Cc: From: dev@flevel.demon.co.uk To: fnf@amigalib.com Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Env: scanning and ixemul Hi Fred, > > Sorry to nag, I know we have had this discussion before and agreed (I think) that something > > must be done. Surely it wouldn't be too hard to add notification to the env: directory and > > just re-scan it when it changes?? > > Do we have a volunteer to work on this? I wish I could but I don't have time. I guess someone who has been working on ixemul.library should be able to do it quite easily. Regards, Trefor S. +-------------------------------------------------------------------------+ ! Email dev@flevel.demon.co.uk Ami-FileSafe (AFS) ! ! Fourth Level Developments Optical Magneto Drive Systems ! ! Internet Service Providers Dice C distributors ! +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Jun 16 14:35:52 1995 Received: from www.utbm.fr ([193.48.246.2]) by nic.funet.fi with ESMTP id <90421-2>; Fri, 16 Jun 1995 14:34:02 +0300 Received: from (news@localhost) by www.utbm.fr (8.6.10/jtpda-5.1) id NAA19221 for ; Fri, 16 Jun 1995 13:34:02 +0100 From: Rene.Garcia@utbm.fr Received: from sunserv.ipse.fr(193.48.202.1) by www.utbm.fr via smap (V1.3) id sma019218; Fri Jun 16 13:33:37 1995 Received: by sunserv.ipse.fr (5.x/SMI-SVR4) id AA02610; Fri, 16 Jun 1995 13:33:03 +0100 Date: Fri, 16 Jun 1995 13:33:03 +0100 Message-Id: <9506161233.AA02610@sunserv.ipse.fr> To: amiga-gcc-port@nic.funet.fi Subject: ixemul 41 and libm020 X-Sun-Charset: ISO-8859-1 X-Face: $M:C\Jh#{#MIj;w}:W)vgWec)@u+geBF0*dy1yRO}a+@ZN,d8bEk#gx&uw!67?lcoed:*|C []>,tr?alD%zU3<7WXgO3'EEGW.'g-y:$ZL-3Jwsn?Rpby6-F"MIcX'w?|ypbK(sYaJ0?yw^l-E_i| &RJzd8,6Wg%Ha{8?K5]]'k[L'5Zuhz.~0q! Can someone compile libc.a for ixemul.library 41.0 for the /gnu/lib/libm020 directory. Yesterday I tried to compile a program with gcc -m68030 -O3 name.cc and an error occured from ld. crt0.o needs symbols of the new version of libc.a I have no disk space enough to install and compile the libc.a linker library. Thanx in advance René ________________________________________________________________ ___ __ __ | \ / \ / \ Rene GARCIA - Etudiant en Informatique | / / __ / http://www.utbm.fr/ | \ . \___/ . \___/ public/gi/etudiants/rene.garcia/home.html From amiga-gcc-port-owner@nic.funet.fi Fri Jun 16 15:10:17 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90547-4>; Fri, 16 Jun 1995 15:08:45 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HRS0NM9E4W90NVOE@LEON.CTI.GR>; Fri, 16 Jun 1995 15:02:29 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA17265; Fri, 16 Jun 95 15:05:21 +0300 Date: Fri, 16 Jun 1995 15:05:20 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: ixemul 41 and libm020 In-reply-to: <9506161233.AA02610@sunserv.ipse.fr> from "Rene.Garcia@utbm.fr" at Jun 16, 95 01:33:03 pm To: Rene.Garcia@utbm.fr Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@theseas.ntua.gr Message-id: <9506161205.AA17265@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 763 > Can someone compile libc.a for ixemul.library 41.0 for > the /gnu/lib/libm020 directory. Yesterday I tried to > compile a program with gcc -m68030 -O3 name.cc and an > error occured from ld. crt0.o needs symbols of the new > version of libc.a My work-around was to delete the files from libm020 corresponding to the new files provided by the 41.0 distribution. This way I get to link with 68000 start-up code and libraries, but as the main part of the library code is in ixemul.library, for which there are versions for all sorts of configurations, this shouldn't make much difference. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "This must be Thursday. I never could get the hang of Thursdays!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Jun 16 15:18:00 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <89948-1>; Fri, 16 Jun 1995 15:17:28 +0300 Received: from pessoa.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA14302; Fri, 16 Jun 1995 14:17:46 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA16062; Fri, 16 Jun 1995 14:10:50 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506161210.AA16062@pessoa.ci.uminho.pt> Subject: bugson gcc? To: amiga-gcc-port@nic.funet.fi (gcc) Date: Fri, 16 Jun 1995 14:10:49 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 582 i have done a download of beta gcc my machine is a 68000 with gvp card with 9 Mb of mem. with 3.1 roms and only gcc and gccv that come in the package, make my computer reboots can anyone say if this two are 68000 version or its a bug. show me the lights, thanks Luis Alves __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Fri Jun 16 16:11:43 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89958-3>; Fri, 16 Jun 1995 16:10:10 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id OAA02952; Fri, 16 Jun 1995 14:07:59 +0100 From: Lars Hecking Message-Id: <199506161310.OAA05149@mostar.nmrc.ucc.ie> Subject: Re: bugson gcc? To: si215603@ci.uminho.pt (Luis Antonio F.Alves) Date: Fri, 16 Jun 1995 14:10:13 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9506161210.AA16062@pessoa.ci.uminho.pt> from "Luis Antonio F.Alves" at Jun 16, 95 02:10:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 418 > i have done a download of beta gcc > my machine is a 68000 with gvp card with 9 Mb of mem. > with 3.1 roms > > and only gcc and gccv that come in the package, make my computer reboots > can anyone say if this two are 68000 version or its a bug. I haven't actually used the beta for compile jobs yet, but 'gcc -v' gave me some spurious warning message and about 400k worth of enforcer hits (A3000/2.04/2.1). From amiga-gcc-port-owner@nic.funet.fi Fri Jun 16 16:18:55 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <90666-4>; Fri, 16 Jun 1995 16:18:07 +0300 Received: from pessoa.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA15076; Fri, 16 Jun 1995 15:19:21 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA20357; Fri, 16 Jun 1995 15:12:22 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506161312.AA20357@pessoa.ci.uminho.pt> Subject: Bugs on Beta release To: amiga-gcc-port@nic.funet.fi (gcc) Date: Fri, 16 Jun 1995 15:12:22 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 585 If anyone could tell me I have a A2000 68000 GVP CARD 9 Mb of mem And i download the version beta of gcc when i run it on my machine it makes software failure can anybody help me i invoke it like this "gcc --version" or "gcc --help" thanks for the help of anyone Luis Alves __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Fri Jun 16 22:44:24 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <90547-2>; Fri, 16 Jun 1995 22:40:07 +0300 Received: from katarina.lysator.liu.se (katarina.lysator.liu.se [130.236.254.31]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id VAA00302; Fri, 16 Jun 1995 21:38:57 +0200 From: Niels M|ller Received: (nisse@localhost) by katarina.lysator.liu.se (8.6.11/8.6.11) id VAA27120; Fri, 16 Jun 1995 21:40:01 +0200 Date: Fri, 16 Jun 1995 21:40:01 +0200 Message-Id: <199506161940.VAA27120@katarina.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: si215603@ci.uminho.pt CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9506161312.AA20357@pessoa.ci.uminho.pt> (si215603@ci.uminho.pt) Subject: Re: Bugs on Beta release From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Date: Fri, 16 Jun 1995 15:12:22 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 585 If anyone could tell me I have a A2000 68000 GVP CARD 9 Mb of mem And i download the version beta of gcc when i run it on my machine it makes software failure can anybody help me i invoke it like this "gcc --version" or "gcc --help" thanks for the help of anyone Luis Alves Perhaps you should first try a non-beta version of gcc. I'm not sure which one is the most recent, probably 2.6.4 . If that version works for you, then you know that the problems are caused by some bug introduced in 2.7.0. If 2.6.4 doesn't work either, then there is some real problem with gcc on your machine. Advice of the day: Don't rely on the latest beta-versions of gcc, or of any other program. Get an older, more tested version too. From amiga-gcc-port-owner@nic.funet.fi Fri Jun 16 23:55:47 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <90521-1>; Fri, 16 Jun 1995 23:53:43 +0300 Received: from caeiro.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA19768; Fri, 16 Jun 1995 22:54:52 GMT Received: by caeiro.ci.uminho.pt (5.4R2.10/200.1.1.4) id AA15984; Fri, 16 Jun 1995 22:50:16 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506162050.AA15984@caeiro.ci.uminho.pt> Subject: where is 2.6.4 To: amiga-gcc-port@nic.funet.fi (gcc) Date: Fri, 16 Jun 1995 22:50:16 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 324 where is 2.6.4 version __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Sat Jun 17 00:18:57 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <90292-1>; Sat, 17 Jun 1995 00:17:48 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA18810 (5.65c+/IDA-1.4.4 for ); Fri, 16 Jun 1995 23:17:13 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA19486; Fri, 16 Jun 1995 23:18:30 GMT Date: Fri, 16 Jun 1995 23:18:29 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: gcc with overlays In-Reply-To: <9506121921.07az@kriton.UUCP> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > This is news to me. As far as I know (and from a quick glance I threw at the > SAS manual to confirm), all the overlay magic is done by the linker, not the > compiler! True. I'm sorry I sayed such a stupid thing ... lack of sleep, you know... Those call to the overlay manager are, indeed, put in the code but are inserted by the linker and not by the compiler, like you said. > A possibly better solution is suggested by the SAS manual: > > "Before deciding to use overlays, consider using multiple shared libraries > instead. If memory is tight, the AmigaDOS system removes unused shared > libraries, thereby giving you some of the benefits of overlays. On systems > with more memory, the AmigaDOS system allows shared libraries to remain > resident, which improves performance. Use overlays only in very tight memory > situations." OK! Seriously speaking, have you got a clue how so much hard is to make a shared library using gcc ? Like I've said before I'm working on a version of X11 libs in a shared library. The perfect solution is a library like the second kind described in SAS/C manual, that is to say, one that does NOT share near data section. Anyway thats on SAS/C, on gcc is slave laybour... X11, when compiling, becomes a ixemul client. And, since I'm putting apart any kind of hack like -m68881, the job of putting it apart is becoming a hard one. > Perhaps gcc's memory requirements have gone up since the time I used to have > "only" 4MB of memory. Not realy, I just don't seem to remenber the last time I used gcc not to compile a X11-client... See Ya - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Sat Jun 17 00:37:14 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <90705-2>; Sat, 17 Jun 1995 00:35:53 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA19134 (5.65c+/IDA-1.4.4 for ); Fri, 16 Jun 1995 23:35:24 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA20461; Fri, 16 Jun 1995 23:36:36 GMT Date: Fri, 16 Jun 1995 23:36:36 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Jeff Shepherd Cc: Amiga GCC mailing list Subject: TheTCPIP on ixemul 41.0 available In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 14 Jun 1995, Jeff Shepherd wrote: > I was wondering - what TCP/IP package does this socket code work for? > AS225. Is a TCPIP pack from Commodore. Bye. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Sat Jun 17 01:29:01 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90117-2>; Sat, 17 Jun 1995 01:27:55 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sMkmD-0004nYC; Fri, 16 Jun 95 16:26 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: where is 2.6.4 To: si215603@ci.uminho.pt (Luis Antonio F.Alves) Date: Fri, 16 Jun 1995 16:26:13 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9506162050.AA15984@caeiro.ci.uminho.pt> from "Luis Antonio F.Alves" at Jun 16, 95 10:50:16 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 178 > where is 2.6.4 version The latest FSF release is 2.6.3. There was never, and probably never will be, an FSF 2.6.4 release since 2.7.0 is due out in the next few days. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Jun 17 01:35:45 1995 Received: from epsilon.qmw.ac.uk ([138.37.6.3]) by nic.funet.fi with SMTP id <90261-2>; Sat, 17 Jun 1995 01:35:22 +0300 Received: from canary.dcs.qmw.ac.uk by epsilon.qmw.ac.uk with SMTP-DNS (PP) id <14807-0@epsilon.qmw.ac.uk>; Fri, 16 Jun 1995 23:35:13 +0100 Received: from magician.dcs.qmw.ac.uk [192.135.231.242] by canary.dcs.qmw.ac.uk (8.6.12/QMW-server-2.4s) with SMTP; poster "Liu "; id XAA11636; Fri, 16 Jun 1995 23:35:11 +0100 From: Liu Full-Name: Liu Received: from it154.dcs.qmw.ac.uk by magician.dcs.qmw.ac.uk (4.1/QMW-client-3.2b); for "amiga-gcc-port@nic.funet.fi"; poster "wmliu168"; id AA01417; Fri, 16 Jun 95 23:34:54 BST Received: from localhost by it154.dcs.qmw.ac.uk (8.6.4/QMW-Minimal-1.14) id XAA03195; Fri, 16 Jun 1995 23:23:12 +0100 Message-Id: <199506162223.XAA03195@it154.dcs.qmw.ac.uk> Subject: * Missing * manual pages :( ... To: amiga-gcc-port@nic.funet.fi Date: Fri, 16 Jun 1995 23:23:11 +0000 (BST) Cc: wmliu168@dcs.qmw.ac.uk (Liu) X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 1883 Now that the 2.7.0 release is imminent can someone explain what happened to all those missing sections of manual pages...In 2.5.8 there were : cat1/ cat2/ cat3/ cat5/ directories holding most of the unix system call manual pages...it was rather convenient. In the latter releases of GCC from Aminet they all dissappeared except for the now called man1 of the manual pages for the shell binaries like 'ls' etc. Why did the rest ever dissappear? If they are not going to be reincluded in the 2.7.0 release - where can I get them from? Thanks. - BTW what is the status of the FAQ???? -- Raymond W.M.Liu Esq. BSc.(Hons.) ____________________________________________________________________________ | | | 1994/95 : MSc. Adv. Methods in Comp. Sci. (Distributed & Parallel Sys.) | |____________________________________________________________________________| | | | | Internet : wmliu168@dcs.qmw.ac.uk | AmigaOS - Pre-emptive multi-tasking | | Internet : zgac3024@qmw.ac.uk | + s/ware MS-DOS/Windows emu... | | | + s/ware Macintosh MacOS emu... _ | | Informatics Teaching Laboratory | + etc....(ALL Pre-Emptively) // | | Queen Mary & Westfield Collefe | _ // | | University of London | "..Taking a big Byte out \\ // | | | of a Big Blue Apple..." \X/ | | Tel.: +44 171 975 5252 |_______________________________________| | (Direct) 0700-0200 UTC | Tartan desires... |_#_#_#_#_#| |____________________________________|____________________________|_#_#_#_#_#| All standard disclaimers apply .sig design (c) Copyright by W.M.Liu, 1995. From amiga-gcc-port-owner@nic.funet.fi Sun Jun 18 13:19:57 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90428-4>; Sun, 18 Jun 1995 13:12:38 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA28112 (5.65b/CWI-3.3); Sun, 18 Jun 1995 12:12:33 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sNGak-000FlIC; Sun, 18 Jun 95 11:24 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <080k@wyst.hobby.nl>; Sun, 18 Jun 95 11:05:56 CET Message-Id: <9506181005.080k@wyst.hobby.nl> Date: Sun, 18 Jun 1995 11:05:55 +0000 (CET) In-Reply-To: from "Fred Fish" at Jun 13, 95 02:27:11 pm Content-Type: text Content-Length: 979 From: hans@wyst.hobby.nl (Hans Verkuil) To: fnf@amigalib.com Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ar and long filenames Fred, > In my current GNU tree, which will be on the FreshFish Vol 10 CD, I've > switched completely to the BFD based binutils except for the linker. > The BFD version of ar works just fine with long filenames, and the > archives are still acceptable to the 1.8.X binutils linker. Which format do you use? AmigaDOS or AOUT? As I've mentioned in some other posts, it should remain possible to use AOUT if needed as there are some programs that only know about AOUT format. dld and GNU Common Lisp come to mind. How about making two versions of the BFD tools? One, smaller, version supporting only AmigaDOS and AOUT, the other supporting all BFD formats. Just an idea. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sun Jun 18 13:20:17 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90495-1>; Sun, 18 Jun 1995 13:12:48 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA28124 (5.65b/CWI-3.3); Sun, 18 Jun 1995 12:12:41 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sNGav-000FlIC; Sun, 18 Jun 95 11:24 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <080u@wyst.hobby.nl>; Sun, 18 Jun 95 11:23:04 CET Message-Id: <9506181023.080u@wyst.hobby.nl> Date: Sun, 18 Jun 1995 11:23:02 +0000 (CET) In-Reply-To: <199506151940.UAA04492@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jun 15, 95 08:40:15 pm Content-Type: text Content-Length: 1908 From: hans@wyst.hobby.nl (Hans Verkuil) To: lhecking@nmrc.ucc.ie Cc: amiga-gcc-port@nic.funet.fi Subject: Re: your mail > > I think I have discovered a bug in either ixemul.library or ls. > > Soft links are displayed as being a "bit" older than they really are. > > Take a look at this: > > > > 5. HD1:> Echo "Test file to show ixemul.library/ls bug" TO testfile > > 5. HD1:> ln -s testfile softlink > > 5. HD1:> List testfile softlink DATES > > testfile 40 ----rwed 30-Maj-95 11:40:51 > > 1 file - 2 blocks used > > softlink 40 ----rwed 30-Maj-95 11:40:51 > > 1 file - 2 blocks used > > 5. HD1:> ls -l testfile softlink > > -rwxrwxrwx 1 amiga amiga 40 May 30 11:40 testfile > > lrwxrwxrwx 1 amiga amiga 1024 Jan 1 1970 softlink -> testfile > > ^^^^^^^^^^^^ > > Obviously, something goes wrong. > > I wouldn't exactly call it a bug, it's more like a "missing" feature ;-) > The bad guy here is ixemuls lstat/__stat. __stat sets the time of last access, > last modification and last file status change to zero (Unix' zero is January > 1st 1970). A comment in library/stat.c mentions that these values are > accessible by dos/ExNext() only. The problem here seems that dos/Lock() > cannot deal with symlinks. > Maybe someone fluent in dos could give it a go? (I am not ;) The solution would be to scan all directory items whenever the item you want to stat is a softlink. This is a major performance penalty, so the decision was made not to do this. If a future AmigaDOS version makes it easier to obtain the date, then it can be added. Until that time the disadvantages outweigh the advantages. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sun Jun 18 13:20:55 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90407-2>; Sun, 18 Jun 1995 13:12:56 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA28131 (5.65b/CWI-3.3); Sun, 18 Jun 1995 12:12:48 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sNGb0-000FlIC; Sun, 18 Jun 95 11:24 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <080z@wyst.hobby.nl>; Sun, 18 Jun 95 11:26:48 CET Message-Id: <9506181026.080z@wyst.hobby.nl> Date: Sun, 18 Jun 1995 11:26:47 +0000 (CET) In-Reply-To: <9506151959.07dl@kriton.UUCP> from "Kriton Kyrimis" at Jun 15, 95 09:59:25 pm Content-Type: text Content-Length: 920 From: hans@wyst.hobby.nl (Hans Verkuil) To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ixconfig -c (ixemul 41.0) Kriton, > I like the new -c option (open console if no errorstream was provided) > of ixconfig/ixemul.library 41.0. We can finally do away with that silly > stderrfix.o kludge. Is there a reason why -c is not the default? (I believe > this is the case for most/all amiga compilers, including gcc/libnix). When I added the -c option I wasn't sure if it would work everywhere. It seems quite stable, though, and when Fred is done with the ixemul library I'll start work on cleaning up the options. In fact, I want to get rid of the -c option and have it always on. I see no reason why this should be a problem. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sun Jun 18 15:01:20 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90622-2>; Sun, 18 Jun 1995 14:58:04 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Sun, 18 Jun 1995 13:57:50 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA25156; Sun, 18 Jun 95 13:57:55 +0200 Date: Sun, 18 Jun 95 13:57:55 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9506181157.AA25156@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10112; Sun, 18 Jun 95 13:57:50 +0200 To: hans@wyst.hobby.nl (Hans Verkuil) Cc: ixemul@listserv.funet.fi, amiga-gcc-port@nic.funet.fi Subject: Proposal to remove ixconfig options and drop Amigados globbing In-Reply-To: <9505272114.07pv@wyst.hobby.nl> References: <9505272114.07pv@wyst.hobby.nl> Hi, Hans Verkuil writes: > One of the more irritating 'features' are the > multitude of options in ixconfig for translating AmigaDOS/UNIX pathnames. > The library should recognize fully specified AmigaDOS filenames (i.e., they > start with 'volume:'), and all other filenames are considered to be UNIX > filenames. Quite reasonable, as this is after all a UNIX emulation library. I quite disagree. I see ixemul as a library that allows easy ports of UNIX SW. I have several directories with mixed ixemul and non-ixemul programs (look at older GCC archives and you'll find lots of these mixed files) and I don't want to have to know how every program was compiled in order to be able to use it. We're running AmigaOS after all and I expect all programs, ixemul-compiled or not, to be able to get along with AmigaOS pathnames (a global switch is nice). I find the choice of that setting extremely useful. Say you're going to run configure for half an hour, you can get the maximum UNIX compatibility with it, but usually, my ixemul settings are -a -., (precisely those you want to remove). > Another proposal is to drop support for AmigaDOS style globbing, i.e. > 'egrep f#?.c' is no longer supported, instead standard UNIX style globbing No opinion, I didn't even know that those programs would expand *.c internally some time ago :-( > I also think that the option -c should be dropped and always be activated. I agree, but does somebody remember why there was an _optional_ stderrfix and why it wasn't put in inconditionally? Wasn't that the non detachable Run >NIL: ... problem which is gone now? > Without this option the errorstream is set to the stdoutstream, which is a > very bad thing to do in my opinion. It should use "*" (or access what's in pr_ConsoleTask). > Finally, the remaining options should be regularized: one option to turn > the feature on, another to turn it off. Good idea, easier to remember. > A final question: is anyone using the -b, -m or -r options? I've tried to play with them a little, caching small files in mem makes sense (-m), testing for stack overflow is useful in complex situations (-r) (unless you have stackextend), but as everything that's optional, you tend to use the defaults if you can get along with them. Regards, Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Sun Jun 18 15:10:42 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90735-4>; Sun, 18 Jun 1995 15:07:11 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Sun, 18 Jun 1995 14:07:02 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA25170; Sun, 18 Jun 95 14:05:44 +0200 Date: Sun, 18 Jun 95 14:05:44 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9506181205.AA25170@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10113; Sun, 18 Jun 95 14:04:57 +0200 To: Niels M|ller Cc: ixemul@listserv.funet.fi, amiga-gcc-port@nic.funet.fi Subject: Re: Proposal to remove ixconfig options and drop Amigados globbing In-Reply-To: <199505281429.QAA15539@lysita.lysator.liu.se> References: <9505272114.07pv@wyst.hobby.nl> <199505281429.QAA15539@lysita.lysator.liu.se> Hi, Niels Moeller writes: > A suggestion: create a cleaner, prefs-like way of setting ixemul > options. One way to do this is as follows: I don't see the advantage of having a prefs like program over one that you can control with switches. I even prefer the latter. The only thing that may be missing is an easy machine-readable output of ixconfig settings, something like: IGNORE ENV: NO TRANSLATE .: YES TRANSLATE /: NO that would be easily parsed by ARexx. > port to find out what options it should use. Then it creates a task > that will handle request for changing the ixemul options and setting > the bits in ixemulbase accordingly. This subtask also needs a Port, It seems like a waste of resources to me to just launch another task sitting idle most of the time for the sole purpose of setting options. I don't want to have tons of little idle task in my system, there are already too many of them now. > Now perhaps you ask what all this is good for? > > It makes it possible for other programs than ixconfig to tell > ixemul.library which options to use, in a clean and well specified You can always use system("ixconfig" "-option1" "-option2"); No need for an extra program sitting there. Just use the resources (i.e. spawn another task) when you need them, not continuously. > For example, one could write a ixprefs program that places a > NotifyRequest on some file in ENV: and communicates the options to > ixemul.library as needed. (Similar to the IPrefs program). Then it is Why should something in ENV: duplicate the bits that are already found in IxemulBASE? > Of course, writing a gui-client for setting the options is > non-trivial, and it will probably not happen immediately. But, I don't see anything here that's non-trivial, just have a look at an older (1991/2?) Snap archive that contains an ARexx script using rexxarplib.library to open a window and display buttons and see how it finally calls SetSnap to set the options. The same could be done with ixconfig -- no need for complex protocols, or extra code to handle those protocols. Have some interface builder do the work for you if you like GUIs. If you want a GUI for setting options, that doesn't require complex ENV:, public port, messages and protocols, ixconfig should suffice. > Once this is done, *no* program, not even ixconfig, will have > to access ixemulbase directly, which have caused incompatibility > problems in the past. Once the new ixconfig method is in use, the Why would that new model be any better? If you change names, it won't work. R. Luebbert changed an address, so it didn't work. Make ixconfig the only way to change settings, make it use long option names if you like to be verbose and that should be fine with everybody. Summary: o no extra mostly idle process is needed for the sake of setting options o don't waste resources (RAM, time, HD space), do a good design o there should exist a machine-readable output form of ixconfig o ixconfig might get verbose options o somebody might like to write a GUI that would call ixconfig in the end o You don't even need a mostly idle commodity, have toolmanager or any hotkey tool launch that GUI on the adequate keypresses Regards, Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Sun Jun 18 19:45:18 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90495-4>; Sun, 18 Jun 1995 19:39:59 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sNOJn-0004nZC; Sun, 18 Jun 95 10:39 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ar and long filenames To: hans@wyst.hobby.nl (Hans Verkuil) Date: Sun, 18 Jun 1995 10:39:31 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <9506181005.080k@wyst.hobby.nl> from "Hans Verkuil" at Jun 18, 95 11:05:55 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1013 > > In my current GNU tree, which will be on the FreshFish Vol 10 CD, I've > > switched completely to the BFD based binutils except for the linker. > > The BFD version of ar works just fine with long filenames, and the > > archives are still acceptable to the 1.8.X binutils linker. > > Which format do you use? AmigaDOS or AOUT? As I've mentioned in some other > posts, it should remain possible to use AOUT if needed as there are some > programs that only know about AOUT format. dld and GNU Common Lisp come to > mind. The tools currently read and write both formats, however the default remains a.out for objects and AmigaDOS hunk format for executables. At some point it will make sense to switch to AmigaDOS hunk format for objects, but still maintain the ability to read a.out objects. > How about making two versions of the BFD tools? One, smaller, version > supporting only AmigaDOS and AOUT, the other supporting all BFD formats. > Just an idea. The current tools are the "smaller version". -Fred From amiga-gcc-port-owner@nic.funet.fi Sun Jun 18 23:09:05 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <90944-2>; Sun, 18 Jun 1995 23:07:24 +0300 Received: by theseas.ntua.gr with UUCP; Sun, 18 Jun 1995 23:10:44 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07f0@kriton.UUCP>; Sun, 18 Jun 95 22:54:39 EET Date: Sun, 18 Jun 95 22:54:39 EET Message-Id: <9506182054.07f0@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 2305 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: ixemul.library configuration With version 41.0 of ixemul.library, I finally found the need for ixconfig (the -c option), which up to now I had never used. Needless to say, the program is not the most user-friendly program in the world! Wanting a configuration program with a more intuitive interface, I rolled up my sleeves and wrote ixprefs, a graphical configuration program for ixemul.library. Before I unleash it to the world, I would like to discuss what I consider a very important point: The only way to make changes in configuration persistent (i.e., not to lose them when unused libraries are flushed) is to use "ixconfig -s", which causes ixconfig to sleep instead of exiting, thus keeping ixemul.library permanently open. Even if one has memory to burn, keeping those 120+ Kbytes of memory permanently allocated is a big waste, especially as this is done only to keep in memory the few bits of configuration information. Would it be possible to change ixemul.library to read at startup time an environment variable, say IXPREFS, containing the configuration information? This way, ixemul.library can be flushed when it is not needed, and still remember the configuration settings when it is reopened. To give some incentive to ixemul.library maintainers to do this, ixprefs does not provide the equivalent of "ixconfig -s", maintaining the IXPREFS variable instead. This variable contains an ASCII representation of the various fields of ixemul_base that ixprefs handles, namely: ix_no_insert_disk_requester ix_unix_pattern_matching_case_sensitive ix_unix_pattern_matching ix_no_ces_then_open_console ix_ignore_global_env ix_disable_fibcache ix_translate_dots ix_watch_stack ix_force_translation ix_translate_symlinks ix_translate_slash ix_membuf_limit ix_red_zone_size ix_fs_buf_factor E.g., for the default configuration of ixemul.library 41.0, IXPREFS is: 0 0 0 0 0 0 1 0 0 0 1 0 0 64 I think this is much less wasteful than "ixconfig -s". I am currently writing the docs for ixprefs, and hope to upload the program on aminet some time this week. I would appreciate it if I could get some feedback before then. Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "What would *I* do if I were me?" ----- From amiga-gcc-port-owner@nic.funet.fi Sun Jun 18 23:48:44 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89679-4>; Sun, 18 Jun 1995 23:46:47 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sNSAm-0004nZC; Sun, 18 Jun 95 14:46 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ixemul.library configuration To: kyrimis@theseas.ntua.gr Date: Sun, 18 Jun 1995 14:46:28 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi, fnf@amigalib.com (Fred Fish) In-Reply-To: <9506182054.07f0@kriton.UUCP> from "Kriton Kyrimis" at Jun 18, 95 10:54:39 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1191 > Would it be possible to change ixemul.library to read at startup time an > environment variable, say IXPREFS, containing the configuration information? Sounds reasonable to me, as long as someone is willing to implement it. > This variable contains an ASCII representation of the various fields of > ixemul_base that ixprefs handles, namely: > > ix_no_insert_disk_requester > ix_unix_pattern_matching_case_sensitive > ix_unix_pattern_matching > ix_no_ces_then_open_console > ix_ignore_global_env > ix_disable_fibcache > ix_translate_dots > ix_watch_stack > ix_force_translation > ix_translate_symlinks > ix_translate_slash > ix_membuf_limit > ix_red_zone_size > ix_fs_buf_factor > > E.g., for the default configuration of ixemul.library 41.0, IXPREFS is: > 0 0 0 0 0 0 1 0 0 0 1 0 0 64 I'm confused. Is it: IXPREFS=0 0 0 0 0 0 1 0 0 0 1 0 0 64 or IXPREFS=no_insert_disk_requester,unix_pattern_matching_case_sensitive,unix_pattern_matching,...,fs_buf_factor=64 I would be opposed to the first form. Make the contents simple ascii flags or "assignments", with no ordering requirements. > I would appreciate it if I could get some feedback before then. Hope this helps. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 09:22:49 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90362-3>; Mon, 19 Jun 1995 09:21:27 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HRVVKWM0PC90OTEW@LEON.CTI.GR>; Mon, 19 Jun 1995 09:20:41 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA02141; Mon, 19 Jun 95 09:23:45 +0300 Date: Mon, 19 Jun 1995 09:23:44 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: ixemul.library configuration In-reply-to: from "Fred Fish" at Jun 18, 95 02:46:28 pm To: fnf@amigalib.com (Fred Fish) Cc: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9506190623.AA02141@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 862 > > E.g., for the default configuration of ixemul.library 41.0, IXPREFS is: > > 0 0 0 0 0 0 1 0 0 0 1 0 0 64 > > I'm confused. Is it: > > IXPREFS=0 0 0 0 0 0 1 0 0 0 1 0 0 64 > > or > > IXPREFS=no_insert_disk_requester,unix_pattern_matching_case_sensitive,unix_pattern_matching,...,fs_buf_factor=64 It's actually the former. > I would be opposed to the first form. Make the contents simple ascii flags > or "assignments", with no ordering requirements. Sounds reasonable, and easy enough to implement. (In fact I lost some sleep tonight over the issue of order dependence and, what's worse, of relying on a fixed number of options, even though it's quite likely that future versions might have more.) -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I'm a knight-errant, not an errant fool!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 11:19:52 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90385-3>; Mon, 19 Jun 1995 11:17:54 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sNcxf-0004nZC; Mon, 19 Jun 95 02:17 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: make 3.74 short malloc bug To: bug-gnu-utils@prep.ai.mit.edu Date: Mon, 19 Jun 1995 02:17:39 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish), amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 824 I ran into a problem with "make" on a system where it appeared to be a case of overrunning a malloc'd region. After linking make with the dbmalloc library, dbmalloc reported the problem to be in glob.c. The problem appears to be that prefix_array is called with pglob->gl_pathv as its input array. Prefix_array allocates new chunks of memory that are exactly big enough to prepend directory names to the elements of pglob->gl_pathv. Later on, slashes are appended to directory names with the assumption that the space is already malloc'd. Search for the comment "glob_in_dir has already allocated the extra character for us". I fixed it by having prefix_array also allocate one extra byte. Someone with more familiarity with the code should check that this analysis is correct and if so, apply a similar fix. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 11:42:46 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89521-4>; Mon, 19 Jun 1995 11:41:32 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun19.114132+0300_eet_dst.89521-4+20@nic.funet.fi> From: To: Date: Mon, 19 Jun 1995 11:41:29 +0300 Date: Mon, 19 Jun 1995 10:41:02 +0200 (METDST) From: Rask Lambertsen To: Joerg-Cyril Hoehle Cc: Hans Verkuil , ixemul@listserv.funet.fi, amiga-gcc-port@nic.funet.fi Subject: Re: Proposal to remove ixconfig options and drop Amigados globbing In-Reply-To: <9506181157.AA25156@inf-wiss.uni-konstanz.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 18 Jun 1995, Joerg-Cyril Hoehle wrote: > Hi, > > Hans Verkuil writes: > > > I also think that the option -c should be dropped and always be activated. > I agree, but does somebody remember why there was an _optional_ > stderrfix and why it wasn't put in inconditionally? Wasn't that the > non detachable Run >NIL: ... problem which is gone now? Hmm, is stderr set up correctly for programs started by BIN:sh? > > Without this option the errorstream is set to the stdoutstream, which is a > > very bad thing to do in my opinion. > It should use "*" (or access what's in pr_ConsoleTask). How about using "CONSOLE:" instead? I remember that one of the RKRMs state that "*" is considered obsolete and should be replaced by "CONSOLE:". Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 11:47:01 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <89520-2>; Mon, 19 Jun 1995 11:46:41 +0300 Received: from colombo.telesys-innov.fr by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HRVUFM4WTS000ADJ@FIPORT.FUNET.FI>; Mon, 19 Jun 1995 08:47:24 +0200 (EET) Received: by colombo.telesys-innov.fr; Mon, 19 Jun 1995 10:47:51 +0100 Date: Mon, 19 Jun 1995 10:47:50 +0100 (BST) From: Philippe BRAND Subject: gcc-2.7.0 C compiler beta To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Message-id: <199506190947.KAA21688@colombo.telesys-innov.fr> Organization: Telesystemes MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL23] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-length: 765 Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 gcc-2.7.0 C compiler BETA is available on both: ftp.funet.fi:/pub/amiga/gnu/beta/gcc-2.7.0-amiga.lha ane ftp.telesys-innov.fr:/pub/amigados-gnu/beta/gcc-2.7.0-amiga.lha It includes: - C compiler 68000 version - New ixemul 41.0 68000 version - New libnix 0.9 (including stack support) - Fixed as - Fixed ld - Fixed sh BEFORE installing: delete gnu:lib/libgcc.a delete gnu:lib/libb/libgcc.a delete gnu:lib/libb/libm020/libgcc.a delete gnu:lib/libm020/libgcc.a cd gnu:bin rename gcc gcc-2.6.3 rename gccv gccv-2.6.3 then install new version with: cd gnu:/ lha x gcc-2.7.0-amiga.lha -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 12:09:22 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <89154-1>; Mon, 19 Jun 1995 12:08:04 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA05737 (5.65c8/IDA-1.4.4 for ); Mon, 19 Jun 1995 11:07:59 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA25187; Mon, 19 Jun 95 11:07:59 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506190907.AA25187@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Problems with ixemul 41.0 stack extension To: amiga-gcc-port@nic.funet.fi Date: Mon, 19 Jun 1995 11:07:59 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 759 > > > I tried linking with ixemul 41.0 the test program that Mathhias Fleischer > > provided to test the libnix version of stack extension (bigtest-x.S). After > > running it 3-4 times, the program gets confused, and instead of extending the > > stack, it pops up a stack overflow requester. > > The stack checking and stack extension options should be considered > still experimental. [...] > I tried building a ixemul (V41.0 from Aminet) based version of the test-program too, but couldn't run it (the 68000 version gurus 80000003 on my 68000 based machine :-( ). Disassembling the resulting executable I found that there is no cleanup for the allocated stack in it. Could it be that after running it for 3-4 times you ran out of free memory? Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 12:35:20 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89467-1>; Mon, 19 Jun 1995 12:34:27 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA01707; Mon, 19 Jun 1995 11:35:36 +0200 Date: Mon, 19 Jun 1995 11:35:34 +0200 (MET DST) From: Kamil Iskra Subject: GCC 2.6.3 Bugs To: amiga-gcc-port@nic.funet.fi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I think I have found two bugs in GCC 2.6.3: 1. The first one is in g++ and concerns virtual inheritance inside templates. Here is an example source: class SuperClass { }; template class SubClass : virtual public SuperClass { public: SubClass(); ~SubClass(); void aMethod(); }; // This is line 11 template SubClass::SubClass() {}; // This is line 13 template SubClass::~SubClass() {}; template void SubClass::aMethod() {}; int main() { SubClass subobj; return 0; } When I try to compile this simple source, that's what I get: test.cxx: In function `int main()': test.cxx:11: template for method `SubClass' doesn't match any in class `SubClass' test.cxx:13: in attempt to instantiate `template SubClass<...>::SubClass()' declared at this point in file This warnings do not make sense, in my opinion. The first one shows that g++ does not recognize constructor's definition - it thinks it is a simple method. The second one is completely not understandable for me - could somebody please explain what such an error COULD mean if there WAS an error?! The above code compiled without any problems on Borland C++ 3.1. I managed to compile this source when I moved constructor's definition inside its class: template class SubClass : virtual public SuperClass { public: SubClass() {}; ~SubClass(); void aMethod(); }; // This is line 11 The problem is only with constructors - destructors and methods can be defined outside of their class' definition. This source can be also compiled if the SuperClass' inheritance is not virtual, or if SubClass is not a template class. 2. The second think I would like to write about is not really a bug, but it seems to me that Markus Wild made a mistake in "inlines" of Amiga function calls. For example, have a look at this piece of "inline/dos.h": extern __inline void AbortPkt (BASE_PAR_DECL struct MsgPort *port,struct DosPacket *pkt) { BASE_EXT_DECL register struct DosLibrary *a6 __asm("a6") = BASE_NAME; register struct MsgPort *d1 __asm("d1") = port; register struct DosPacket *d2 __asm("d2") = pkt; __asm __volatile ("jsr a6@(-0x108)" : /* no output */ : "r" (a6), "r" (d1), "r" (d2) : "a0","a1","d0","d1","d2", "memory"); } According to "gcc.guide": 'Some instructions clobber specific hard registers. To describe this, write a third colon after the input operands, followed by the names of the clobbered hard registers (given as strings).' So my question is: Why "d2" is on the list of clobbered hard registers? As far as I remember, shared library functions are only allowed to change "a0", "a1", "d0" and "d1" (well, and the 'register' "memory" :-). The above code would be reasonable, if the call was implemented this way: extern __inline void AbortPkt (BASE_PAR_DECL struct MsgPort *port,struct DosPacket *pkt) { BASE_EXT_DECL register struct DosLibrary *a6 __asm("a6") = BASE_NAME; __asm __volatile ("movel %1,d1 movel %2,d2 jsr a6@(-0x108)" : /* no output */ : "r" (a6), "r" (port), "r" (pkt) : "a0","a1","d0","d1","d2", "memory"); } But since the call is implemented as it is, it seems that "d2" is unnecessarily preserved, what most probably hurts the performance. Or did I miss something? >From the last moment: new "fd2inline" has been recently uploaded to Aminet. I haven't had the time yet to test it - does anyone know if it behaves in this subject as the old, pearl one? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 12:37:18 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <89286-2>; Mon, 19 Jun 1995 12:36:58 +0300 Received: by ceylon.informatik.uni-rostock.de id LAA01941; Mon, 19 Jun 1995 11:36:06 +0200 Received: by honshu.informatik.uni-rostock.de id LAA01135; Mon, 19 Jun 1995 11:36:00 +0200 From: Gunther Nikl Message-Id: <199506190936.LAA01135@honshu.informatik.uni-rostock.de> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Mon, 19 Jun 1995 11:35:59 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Jun19.114132+0300_eet_dst.89521-4+20@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Jun 19, 95 11:41:29 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 379 > Rask Lambertsen wrote: > > How about using "CONSOLE:" instead? I remember that one of the RKRMs state > that "*" is considered obsolete and should be replaced by "CONSOLE:". This topic was discussed in a news-group some time ago. There is no need to lose compatibility to use "CONSOLE:" instead of "*", since Open() does not do any *wild card expansion*. Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 12:48:59 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89107-2>; Mon, 19 Jun 1995 12:47:54 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 19 Jun 1995 11:45:52 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA26981; Mon, 19 Jun 95 11:45:34 +0200 Date: Mon, 19 Jun 95 11:45:34 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9506190945.AA26981@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10247; Mon, 19 Jun 95 11:45:27 +0200 To: Rask Lambertsen Cc: ixemul@listserv.funet.fi, amiga-gcc-port@nic.funet.fi Follow-Up: ixemul@listserv.funet.fi Subject: Re: Proposal to remove ixconfig options and drop Amigados globbing In-Reply-To: References: <9506181157.AA25156@inf-wiss.uni-konstanz.de> Rask Lambertsen writes: > How about using "CONSOLE:" instead? I remember that one of the RKRMs state > that "*" is considered obsolete and should be replaced by "CONSOLE:". Well, it depends who dos.library you talk to (at dos.library or at packet level). There's been much talk about this in the german Amiga newsgroups: ask Ralph Babel, the author of the GURU book for details, "*" ist not "CONSOLE:". You probably won't get to CONSOLE: at the packet level ixemul is using. Anyway, that's a detail for the ixemul-writers. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de PS: Followup to ixemul@listserv.funet.fi only? From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 12:53:25 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <89121-4>; Mon, 19 Jun 1995 12:53:02 +0300 Received: from tycho (localhost) by tycho.gbar.dtu.dk with SMTP(1.37.109.15/16.2) Message-Id: <95Jun19.125302+0300_eet_dst.89121-4+24@nic.funet.fi> From: To: Date: Mon, 19 Jun 1995 12:53:00 +0300 Message-Id: <199506190953.AA272545587@gbar.dtu.dk> Date: Mon, 19 Jun 95 11:53:07 0200 Sender: gc948374@gbar.dtu.dk From: Rask Lambertsen Organization: DTU X-Mailer: Mozilla 1.1N (X11; I; HP-UX A.09.03 9000/715) Mime-Version: 1.0 To: amiga-gcc-port@nic.funet.fi Subject: (no subject) X-Url: file:/home35/id/gc948374/mail-test.html Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Mon, 19 Jun 1995, Gunther Nikl wrote: > > > Rask Lambertsen wrote: > > > > How about using "CONSOLE:" instead? I remember that one of the RKRMs state > > that "*" is considered obsolete and should be replaced by "CONSOLE:". > > This topic was discussed in a news-group some time ago. There is no need > to lose compatibility to use "CONSOLE:" instead of "*", since Open() does > not do any *wild card expansion*. Lose compatibility? How? If "*" is considered obsolete, shouldn't we use something else? -- Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 13:01:53 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <89290-4>; Mon, 19 Jun 1995 13:01:14 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA11415; Mon, 19 Jun 1995 11:01:03 +0100 Date: Mon, 19 Jun 1995 11:00:05 +0100 (BST) From: Peter Ivimey-Cook To: Amiga GCC List Subject: Problems with Ixemul 41.0 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks, I recently downloaded the 41.0 ixemul and installed it over my current 2.6.3 install of gcc. It compiled a simple program (using nothing but simple stdio & stdlib calls) fine. However as soon as it was run I get a 80000003 guru - address error. The same program had worked fine with 40.4. I then tried Jeff's Pine, compiled for AmiTCP, which similarly GURU'd in the same manner. Looks like there are problems with the latest version :( I've reverted to 40.4 now and all's well. My config: A2000 (original spec, but 2.04 ROMS) 1+6Mb memory, GVP SCSI card + SCSI disk. WB 2.04, various commodities, incl AmiTCP 4.2, running. I didn't try removing them at the time, except for AmiTCP. Any thoughts? Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 13:07:03 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89464-2>; Mon, 19 Jun 1995 13:06:30 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 19 Jun 1995 12:05:19 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA27071; Mon, 19 Jun 95 12:05:19 +0200 Date: Mon, 19 Jun 95 12:05:19 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9506191005.AA27071@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10252; Mon, 19 Jun 95 12:05:16 +0200 To: Kamil Iskra Cc: amiga-gcc-port@nic.funet.fi Subject: GCC 2.6.3 Bugs In-Reply-To: References: Kamil Iskra writes: > extern __inline void > AbortPkt (BASE_PAR_DECL struct MsgPort *port,struct DosPacket *pkt) > { > BASE_EXT_DECL > register struct DosLibrary *a6 __asm("a6") = BASE_NAME; > __asm __volatile ("movel %1,d1 > movel %2,d2 > jsr a6@(-0x108)" > : /* no output */ > : "r" (a6), "r" (port), "r" (pkt) > : "a0","a1","d0","d1","d2", "memory"); > } This is dangerous, what if pkt (which goes to D2) was held in D1 by GCC so far? Your move instructions doesn't swap the registers, leading to bugs that are really hard to trace. Why do you generate MOVEs just before the JSR when the compiler can load the registers earlier, generating better code? That's bad and incorrect code. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 13:18:02 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89118-2>; Mon, 19 Jun 1995 13:16:04 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA03681; Mon, 19 Jun 1995 12:16:31 +0200 Date: Mon, 19 Jun 1995 12:16:29 +0200 (MET DST) From: Kamil Iskra Subject: Re: GCC 2.6.3 Bugs To: Joerg-Cyril Hoehle cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9506191005.AA27071@inf-wiss.uni-konstanz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Jun 1995, Joerg-Cyril Hoehle wrote: > Kamil Iskra writes: > > extern __inline void > > AbortPkt (BASE_PAR_DECL struct MsgPort *port,struct DosPacket *pkt) > > { > > BASE_EXT_DECL > > register struct DosLibrary *a6 __asm("a6") = BASE_NAME; > > __asm __volatile ("movel %1,d1 > > movel %2,d2 > > jsr a6@(-0x108)" > > : /* no output */ > > : "r" (a6), "r" (port), "r" (pkt) > > : "a0","a1","d0","d1","d2", "memory"); > > } > > This is dangerous, what if pkt (which goes to D2) was held in D1 by > GCC so far? Your move instructions doesn't swap the registers, leading > to bugs that are really hard to trace. Why do you generate MOVEs just > before the JSR when the compiler can load the registers earlier, > generating better code? That's bad and incorrect code. You are right. But please consider that I didn't suggest using such a code - I only gave it as an example of code that would really need preserving of D2 register. My example was buggy, I agree, but the main question still remains - why in original inlines D2 is preserved? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 13:31:45 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <89858-1>; Mon, 19 Jun 1995 13:30:14 +0300 Received: from pan.rz.uni-konstanz.de by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HRVY0144Y80008CB@FIPORT.FUNET.FI>; Mon, 19 Jun 1995 10:30:17 +0200 (EET) Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 19 Jun 1995 12:26:57 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA27147; Mon, 19 Jun 95 12:26:46 +0200 Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10257; Mon, 19 Jun 95 12:26:43 +0200 Date: Mon, 19 Jun 1995 12:26:46 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Subject: ixemul.library configuration In-reply-to: <9506182054.07f0@kriton.UUCP> To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@lists.funet.fi Message-id: <9506191026.AA27147@inf-wiss.uni-konstanz.de> Content-transfer-encoding: 7BIT References: <9506182054.07f0@kriton.UUCP> Kriton Kyrimis writes: > Would it be possible to change ixemul.library to read at startup time an > environment variable, say IXPREFS, containing the configuration information? Well, it would be possible, but as soon as ENV:IXPREFS were introduced, the question would arise about why should ENV:IXPREFS only be used at startup-time and not to set the configuration at any time, resulting in programming notification inside ixemul.library and more code-bloating. BTW, some people argue that things that are just set one time (at program start) or maybe never in a given power-on/off cycle are not to be held in ENV:, since it's just wasted RAM: waiting for the posibility to be used just one time and more boot time for the COPY operation. A file on HD would be fine for that. S: has been used widely in the past. > E.g., for the default configuration of ixemul.library 41.0, IXPREFS is: > 0 0 0 0 0 0 1 0 0 0 1 0 0 64 Programmers should learn to save something else than memory dumps and meaningless (because they are subject to change in the future) sequences of bits and numbers into configuration files: use (possibly structured) symbolic information like ix_no_insert_disk_requester instead. Otherwise they oblige themselves to provide converter programs from version 1.0 -> 1.1 -> 2.0 -> 2.01 -> ... of their programs and run into trouble when configurations are mixed. Saving symbolic information is a bit more work at the beginning, but it has so many benefits in the long run. Regards, Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 13:39:55 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <89902-2>; Mon, 19 Jun 1995 13:39:02 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA11615; Mon, 19 Jun 1995 11:37:09 +0100 Date: Mon, 19 Jun 1995 11:36:10 +0100 (BST) From: Peter Ivimey-Cook To: Fred Fish Cc: kyrimis@theseas.ntua.gr, amiga-gcc-port@nic.funet.fi Subject: Re: ixemul.library configuration In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 18 Jun 1995, Fred Fish wrote: > I'm confused. Is it: > > IXPREFS=0 0 0 0 0 0 1 0 0 0 1 0 0 64 > > or > > IXPREFS=no_insert_disk_requester,unix_pattern_matching_case_sensitive,unix_pattern_matching,...,fs_buf_factor=64 > > I would be opposed to the first form. Make the contents simple ascii flags > or "assignments", with no ordering requirements. > > > I would appreciate it if I could get some feedback before then. > I would agree for two reasons - a) it's much easier for a human to read and b) when we change things, there'll be no problems with backwards compatibility. Please keep it in string (not numeric form). the basic idea sounds good though. Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 14:47:28 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89172-3>; Mon, 19 Jun 1995 14:45:40 +0300 Received: from mailhub.uni-konstanz.de (actually host pan.rz.uni-konstanz.de) by funet.fi with SMTP (PP); Mon, 19 Jun 1995 14:45:23 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 19 Jun 1995 13:23:51 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA27337; Mon, 19 Jun 95 13:23:57 +0200 Date: Mon, 19 Jun 95 13:23:57 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9506191123.AA27337@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10261; Mon, 19 Jun 95 13:23:57 +0200 To: Kamil Iskra Cc: amiga-gcc-port@nic.funet.fi Subject: Re: GCC 2.6.3 Bugs In-Reply-To: References: <9506191005.AA27071@inf-wiss.uni-konstanz.de> Kamil Iskra writes: > My example was buggy, I agree, but the main question still > remains - why in original inlines D2 is preserved? Ok, it seems that D2 needn't be marked as scratched, as it's preserved by the asm statement JSR (like any of D2-D7, A2-A7) and shouldn't be affected by the __asm(D2) register declarations. I don't know if this leaves room for many optimizations though. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 14:49:32 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <89282-2>; Mon, 19 Jun 1995 14:49:12 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HRW6ZYZ6LS90NWW6@LEON.CTI.GR>; Mon, 19 Jun 1995 14:47:24 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA12377; Mon, 19 Jun 95 14:50:28 +0300 Date: Mon, 19 Jun 1995 14:50:28 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: ixemul.library configuration In-reply-to: <9506191026.AA27147@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Jun 19, 95 12:26:46 pm To: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@theseas.ntua.gr Message-id: <9506191150.AA12377@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 1726 > Well, it would be possible, but as soon as ENV:IXPREFS were > introduced, the question would arise about why should ENV:IXPREFS only > be used at startup-time and not to set the configuration at any time, > resulting in programming notification inside ixemul.library and more > code-bloating. No programming notification is required. Ixprefs, like ixconfig, sets the appropriate fields in ixemulbase as soon as you hit "Use" or "Save". > BTW, some people argue that things that are just set one time (at > program start) or maybe never in a given power-on/off cycle are not to > be held in ENV:, since it's just wasted RAM: waiting for the > posibility to be used just one time and more boot time for the COPY > operation. A file on HD would be fine for that. S: has been used > widely in the past. True, but look at all the stuff Commodre preferences programs store in ENV:sys (ixprefs is yet another preferences program). I agree that ENV: has been abused, though: I have had to resort to using a multi-assign for ENV: to keep large environment variables on disk rather than in ram. > > E.g., for the default configuration of ixemul.library 41.0, IXPREFS is: > > 0 0 0 0 0 0 1 0 0 0 1 0 0 64 > Programmers should learn to save something else than memory dumps and Fred Fish (not to mention my troubled nightmares last night) mentioned the same thing. I will convert to using a configuration file containing "field=value" lines before releasing ixprefs. The only reason I used such a cryptic format was to avoid creating a large environment variable. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Selective retribution will bring any dissident to heel." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 15:56:30 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <89841-1>; Mon, 19 Jun 1995 15:53:11 +0300 Received: by math.uwaterloo.ca id <77154-2>; Mon, 19 Jun 1995 08:48:45 -0400 Date: Mon, 19 Jun 1995 08:48:44 -0400 From: Jeff Shepherd To: Amiga-Gcc List Subject: execle() broken in ixemul 41.0 and 40.4. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Execle() fails to use the environment variables passed to it. Attached is a simple test program which illustrates the problem. What the program does is vfork()'s and calls execle on a test shell passing some environment variables to it. When test shell script is executed, it shows that the environment variables are not passed. The good news is that there is a workaround until execle() is fixed. It seems execle() uses what is in environ to pass to the shell and ignores what execle() passes as the environment. The fix is to make environ point to the environment variables needed, call execle() normally and then return environ's previous value. Test2.c illustrates the fix. begin 664 test.lzh M'[,M;&@U+<@```#]````YT73'B`!!G1EO/F"M<*X$X"SPTA*?PRZZULOPG9DR MU;?3)=Z^]@5T*NP>N^NJNPM*-&<=N6H*+.A6P'VVI>'(`$'=&5S="YS:/[8504`4+2! M!P!1+P$:`0<`5$JSY"\````Z2I:M**\^\`?Q7.KX-Y;$X(4')>.M+P/3.``" M=]G16CFF1)*=0=NA`*PXAH#\`?D%T:X\.RG'M,(^#E;)*M.?XO0$0""7+6QH M-2WI````6`$``*Y#TQX@`0=T97-T,BYCV3)5!0!0M($'`%$O`1H!!P!4J6WE M+P```-%;3\=.CA7Y2-VA?._/S#_#*$PAZF,7KQSPBO=N%^I1@^X*[F/+GKA&X" M>:^6!/;K`G6+_`!6,'R.KA&_M\+O0=2F&,CO\66_N:0%^11D=`O3UX\05M; Mon, 19 Jun 1995 17:37:43 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sNisO-0004naC; Mon, 19 Jun 95 08:36 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Problems with ixemul 41.0 stack extension To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Mon, 19 Jun 1995 08:36:36 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi (ixemul.library maintainers) In-Reply-To: <9506190907.AA25187@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Jun 19, 95 11:07:59 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 984 > > The stack checking and stack extension options should be considered > > still experimental. [...] > > > I tried building a ixemul (V41.0 from Aminet) based version of the > test-program too, but couldn't run it (the 68000 version gurus > 80000003 on my 68000 based machine :-( ). Disassembling the resulting > executable I found that there is no cleanup for the allocated stack in > it. Could it be that after running it for 3-4 times you ran out of > free memory? The following note in crt0.c may be relevant: /* FIXME: It appears that libnix restores the value of the stack pointer from ___SaveSP at a point equivalent to this in the libnix *crt0.S files. Do we need to do that also? -fnf */ return (res); I would really appreciate it if someone with more AmigaDOS knowledge than I, and also assembly code expertise, could look at how libnix handles the stack pointer setup and teardown issues, and make the appropriate change in crt0.c if necessary. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 18:11:47 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89096-3>; Mon, 19 Jun 1995 18:08:47 +0300 X400-Received: by /ADMD=FUMAIL/C=fi/; Relayed; Mon, 19 Jun 1995 18:05:58 +0300 X400-Received: by mta funet.fi in /ADMD=FUMAIL/C=fi/; Relayed; Mon, 19 Jun 1995 18:05:58 +0300 X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Mon, 19 Jun 1995 18:05:02 +0300 X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Mon, 19 Jun 1995 18:00:20 +0300 X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Mon, 19 Jun 1995 18:00:16 +0300 X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Mon, 19 Jun 1995 18:00:16 +0300 Date: Mon, 19 Jun 1995 18:00:16 +0300 X400-Originator: mclem@medphys.ucl.ac.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<9506191500.AA10181@medphys.ucl.] X400-Content-Type: P2-1984 (2) Content-Identifier: Debugger Alternate-Recipient: Allowed From: " (Matthew Clemence)" Message-ID: <9506191500.AA10181@medphys.ucl.ac.uk> To: amiga-gcc-port@nic.funet.fi Subject: Debugger I don't know if this is the right place to ask, but .. I am looking for a source debugging tool (like dbxtool or dbx) for use with gcc ? Does one exist ? I have tried various other amiga debuggers (such as powervisor) but they work at an assembly level which is a bit beyond my needs. thanks Matthew Clemence University College London mclem@medphys.ucl.ac.uk From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 18:24:23 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <89690-2>; Mon, 19 Jun 1995 18:21:47 +0300 Received: from katarina.lysator.liu.se (katarina.lysator.liu.se [130.236.254.31]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id RAA18572; Mon, 19 Jun 1995 17:21:30 +0200 From: Niels M|ller Received: (nisse@localhost) by katarina.lysator.liu.se (8.6.11/8.6.11) id RAA00708; Mon, 19 Jun 1995 17:21:37 +0200 Date: Mon, 19 Jun 1995 17:21:37 +0200 Message-Id: <199506191521.RAA00708@katarina.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: kyrimis@theseas.ntua.gr CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9506182054.07f0@kriton.UUCP> (kriton!kyrimis@theseas.ntua.gr) Subject: Re: ixemul.library configuration From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) With version 41.0 of ixemul.library, I finally found the need for ixconfig (the -c option), which up to now I had never used. Needless to say, the program is not the most user-friendly program in the world! Wanting a configuration program with a more intuitive interface, I rolled up my sleeves and wrote ixprefs, a graphical configuration program for ixemul.library. Hero! From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 18:25:14 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89639-1>; Mon, 19 Jun 1995 18:23:41 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26506-3>; Mon, 19 Jun 1995 17:22:53 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209224-2>; Mon, 19 Jun 1995 17:22:36 +0100 Subject: Re: GCC 2.6.3 Bugs From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Mon, 19 Jun 1995 17:22:28 +0200 (MESZ) In-Reply-To: <9506191123.AA27337@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Jun 19, 95 01:23:57 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1825 Message-Id: <95Jun19.172236+0100mesz.209224-2+651@hphalle0.informatik.tu-muenchen.de> > > My example was buggy, I agree, but the main question still > > remains - why in original inlines D2 is preserved? > Ok, it seems that D2 needn't be marked as scratched, as it's preserved > by the asm statement JSR (like any of D2-D7, A2-A7) and shouldn't be > affected by the __asm(D2) register declarations. I don't know if this > leaves room for many optimizations though. Well, unnecessarily saving registers is _always_ bad. Remember, there are some library functions that use more registers, and they are all marked as "scratch", causing GNU-C to reload values that aren't destroyed. And it doesn't sound too complicated to fix (actually, I was surprised to hear that it's still there). As a related matter: some functions don't clobber all of d0/d1/a0/a1, and some functions don't need the library base in a6. Maybe the person who volunteers to fix the inline-generator could also put in a list of functions with different register clobbing (Forbid(), Permit(), Enable(), Disable(), ObtainSemaphore(), utility.library math functions, math functions), so that GNU-C finally knows about these functions. Also, what does "memory" actually do? Whenever I need to make my own inlines for something, I usually don't specify "memory" unless the functions writes to memory that I intend to read somewhere in my program. The problem: I never really understood what "memory" really means :( So, is anyone out there able to shed some light on this? Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 18:52:13 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <89652-4>; Mon, 19 Jun 1995 18:51:09 +0300 Received: from katarina.lysator.liu.se (katarina.lysator.liu.se [130.236.254.31]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id RAA18989; Mon, 19 Jun 1995 17:50:59 +0200 From: Niels M|ller Received: (nisse@localhost) by katarina.lysator.liu.se (8.6.11/8.6.11) id RAA00751; Mon, 19 Jun 1995 17:51:14 +0200 Date: Mon, 19 Jun 1995 17:51:14 +0200 Message-Id: <199506191551.RAA00751@katarina.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: hoehle@inf-wiss.uni-konstanz.de CC: ixemul@listserv.funet.fi, amiga-gcc-port@nic.funet.fi In-reply-to: <9506181205.AA25170@inf-wiss.uni-konstanz.de> (hoehle@inf-wiss.uni-konstanz.de) Subject: Re: Proposal to remove ixconfig options and drop Amigados globbing From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Hi, Niels Moeller writes: > port to find out what options it should use. Then it creates a task > that will handle request for changing the ixemul options and setting > the bits in ixemulbase accordingly. This subtask also needs a Port, It seems like a waste of resources to me to just launch another task sitting idle most of the time for the sole purpose of setting options. I don't want to have tons of little idle task in my system, there are already too many of them now. Well, a small idle task doesn't use much resources, that is, CPU and memory (unless you are running Wind*ws :-), so I don't agree. I'd understand your objection if we were talking about large tasks, trying to hog the CPU all the time. What is important is to have a border between ixemul and the config-program. We don't wnat crashes just because ixemul.library and ixprefs/ixconfig are of different versions. It would also be nice if they can be developed separately Fortunately, we don't have to debate this issue to death, as Kriton is actually writing a new prefs-program, and that's what matters. /Niels From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 18:56:09 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <89295-1>; Mon, 19 Jun 1995 18:55:53 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA14013 (5.65c8/IDA-1.4.4 for ); Mon, 19 Jun 1995 17:55:39 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA26661; Mon, 19 Jun 95 17:55:38 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506191555.AA26661@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: GCC 2.6.3 Bugs To: amiga-gcc-port@nic.funet.fi Date: Mon, 19 Jun 1995 17:55:38 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1102 > > Also, what does "memory" actually do? Whenever I need to make my own > inlines for something, I usually don't specify "memory" unless the > functions writes to memory that I intend to read somewhere in my program. > The problem: I never really understood what "memory" really means :( > So, is anyone out there able to shed some light on this? > Well, you're using it already in the right form: "memory" means that the assembler statement doesn't just clobber registers but writes to memory. This means that gcc is not allowed to cache memory contents in registers. Let's take an example: while(list->lh_Head.ln_Succ!=NULL) { struct Node *node; node=RemHead(list); /* Do something with all list members */ } If 'list' isn't explicitly declared as pointer to volatile and RemHead() doesn't clobber memory the compiler thinks that nothing in the loop can change 'list->lh_Head.ln_Succ' (Remember that RemHead() effectively is no function call but just an assembler statement for gcc) and produces invalid code. If you tell him that RemHead() clobbers memory this doesn't happen. Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 19:03:46 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <89643-1>; Mon, 19 Jun 1995 19:02:32 +0300 Received: by math.uwaterloo.ca id <77158-3>; Mon, 19 Jun 1995 12:00:38 -0400 Date: Mon, 19 Jun 1995 12:00:34 -0400 From: Jeff Shepherd To: Peter Ivimey-Cook cc: Amiga GCC List Subject: Re: Problems with Ixemul 41.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Jun 1995, Peter Ivimey-Cook wrote: > Folks, > > I recently downloaded the 41.0 ixemul and installed it over my current > 2.6.3 install of gcc. > > It compiled a simple program (using nothing but simple stdio & stdlib > calls) fine. However as soon as it was run I get a 80000003 guru - > address error. The same program had worked fine with 40.4. > > I then tried Jeff's Pine, compiled for AmiTCP, which similarly GURU'd in > the same manner. Looks like there are problems with the latest version :( > > I've reverted to 40.4 now and all's well. > > My config: A2000 (original spec, but 2.04 ROMS) 1+6Mb memory, GVP SCSI > card + SCSI disk. > > WB 2.04, various commodities, incl AmiTCP 4.2, running. I didn't try > removing them at the time, except for AmiTCP. > Strange, ixemul 41.0 works fine for me (except for the bug mentionned in a previous mail.) Maybe there is an OS compatibility problem or an AmiTCP problem. I have run pine with ixemul 41.0 with no problems. Setup: A4000/030 2M chip/4M fast, WB 3.0, with AmiTCP 4.0 demo and various commodities (ToolsDaemon 2.1, Yak 1.60, GarshneBlanker, AClock ...) jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 19:08:05 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <89678-3>; Mon, 19 Jun 1995 19:07:41 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA13279; Mon, 19 Jun 1995 17:07:19 +0100 Date: Mon, 19 Jun 1995 17:06:19 +0100 (BST) From: Peter Ivimey-Cook To: Jeff Shepherd Cc: Amiga GCC List Subject: Re: Problems with Ixemul 41.0 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Jun 1995, Jeff Shepherd wrote: > Strange, ixemul 41.0 works fine for me (except for the bug mentionned in > a previous mail.) Maybe there is an OS compatibility problem or an AmiTCP > problem. I have run pine with ixemul 41.0 with no problems. > > Setup: A4000/030 2M chip/4M fast, WB 3.0, with AmiTCP 4.0 demo and various > commodities (ToolsDaemon 2.1, Yak 1.60, GarshneBlanker, AClock ...) > I guess the difference is that the people whove had probems have been using 68000 based amigas, which barf on certain types of memory access that 68020's and 68030s don't. It's probably an invalid pointer dereference somewhere. This was fixed for the 40.0 to 40.1 release (I think it was that pair anyway) - it could be the same problem resurfacing. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 19:14:10 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <89590-4>; Mon, 19 Jun 1995 19:13:24 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA18717 (5.65c8/IDA-1.4.4 for ); Mon, 19 Jun 1995 18:13:07 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA26702; Mon, 19 Jun 95 18:13:07 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506191613.AA26702@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Problems with ixemul 41.0 stack extension To: amiga-gcc-port@nic.funet.fi Date: Mon, 19 Jun 1995 18:13:06 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 896 > > I would really appreciate it if someone with more AmigaDOS knowledge than > I, and also assembly code expertise, could look at how libnix handles > the stack pointer setup and teardown issues, and make the appropriate > change in crt0.c if necessary. > Well, I know how libnix handles the stack pointer setup ;) and I would like to fix it for ixemul - but I need to know how ixemul's exit() is implemented. I took a look at the sources, but still have no clue how it works. (Shouldn't there be a longjmp() or similar somewhere?) Basically exit() has to return to the original stackframe somewhere (otherwise you couldn't 'rts' to dos). After this is done the allocated stack is no longer used and can (must) be freed (this is necessary because the stack extension code caches stackframes for speed). Can I just free the stack after main() returned or is there another exit point? Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 19:15:30 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <89664-4>; Mon, 19 Jun 1995 19:15:07 +0300 Received: by math.uwaterloo.ca id <77150-2>; Mon, 19 Jun 1995 12:14:33 -0400 Date: Mon, 19 Jun 1995 12:14:29 -0400 From: Jeff Shepherd To: Peter Ivimey-Cook cc: Amiga GCC List Subject: Re: Problems with Ixemul 41.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Jun 1995, Peter Ivimey-Cook wrote: > I guess the difference is that the people whove had probems have been using > 68000 based amigas, which barf on certain types of memory access that 68020's > and 68030s don't. It's probably an invalid pointer dereference somewhere. > This was fixed for the 40.0 to 40.1 release (I think it was that pair anyway) > - it could be the same problem resurfacing. > It could be that the 68000 version of the library was compiled using -m68020 by mistake?. I remembered that the 40.3 versions were compiled with the FPU option enabled. It keep popping up a requester saying it needed an FPU installed. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 19:26:27 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <89666-1>; Mon, 19 Jun 1995 19:25:06 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA29706 (5.65c8/IDA-1.4.4 for ); Mon, 19 Jun 1995 18:24:58 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA26743; Mon, 19 Jun 95 18:24:57 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506191624.AA26743@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Problems with Ixemul 41.0 To: amiga-gcc-port@nic.funet.fi Date: Mon, 19 Jun 1995 18:24:57 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 594 > > It could be that the 68000 version of the library was compiled using > -m68020 by mistake?. I remembered that the 40.3 versions were compiled > with the FPU option enabled. It keep popping up a requester saying it > needed an FPU installed. > I don't know if that helps, but hacking the first assembler instruction of crto.0 into 16-bit PC-relative (which was used in V40 crt0.o) replaces the 80000003 by an 8000000b (68020 instruction). Also some code in ixemul V41 itself gurus 8000000b (gcc 2.6.3 doesn't work with the new ixemul on 68000). My machine is an 68000 A2000. Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 19:57:18 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <90349-2>; Mon, 19 Jun 1995 19:55:11 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA13470 (5.65c+/IDA-1.4.4 for ); Mon, 19 Jun 1995 18:53:19 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA01245; Mon, 19 Jun 1995 18:54:23 GMT Date: Mon, 19 Jun 1995 18:54:23 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Peter Ivimey-Cook Cc: Amiga GCC List Subject: Re: Problems with Ixemul 41.0 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Jun 1995, Peter Ivimey-Cook wrote: > Folks, > > I recently downloaded the 41.0 ixemul and installed it over my current > 2.6.3 install of gcc. > > It compiled a simple program (using nothing but simple stdio & stdlib > calls) fine. However as soon as it was run I get a 80000003 guru - > address error. The same program had worked fine with 40.4. > Have you recompiled this program with the new libc.a and startup module (usualy crt0.o) ? Every program should be recompiled to work on ix40.6 and ix41.0... - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 20:01:48 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <90207-3>; Mon, 19 Jun 1995 20:01:19 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA13630; Mon, 19 Jun 1995 18:01:07 +0100 Date: Mon, 19 Jun 1995 18:00:07 +0100 (BST) From: Peter Ivimey-Cook To: Pedro Miguel Sequeira Teixeira Cc: Peter Ivimey-Cook , Amiga GCC List Subject: Re: Problems with Ixemul 41.0 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Jun 1995, Pedro Miguel Sequeira Teixeira wrote: > > I recently downloaded the 41.0 ixemul and installed it over my current > > 2.6.3 install of gcc. > > > > It compiled a simple program (using nothing but simple stdio & stdlib > > calls) fine. However as soon as it was run I get a 80000003 guru - > > address error. The same program had worked fine with 40.4. > > > > Have you recompiled this program with the new libc.a and > startup module (usualy crt0.o) ? Every program should be recompiled > to work on ix40.6 and ix41.0... I installed the ixemul4100-bin archive on top of my existing install, then recompiled the program from scratch (only one .c file). It failed instantly... I'm fairly sure this is a 68000 vs 680[234]0 problem with memory references... Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 23:07:25 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89911-1>; Mon, 19 Jun 1995 20:39:40 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sNljO-0004nZC; Mon, 19 Jun 95 11:39 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Problems with Ixemul 41.0 To: jsshephe@math.uwaterloo.ca (Jeff Shepherd) Date: Mon, 19 Jun 1995 11:39:30 -0700 (MST) Cc: Peter.Ivimey-Cook@isltd.insignia.com, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Jeff Shepherd" at Jun 19, 95 12:14:29 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 379 > It could be that the 68000 version of the library was compiled using > -m68020 by mistake?. Possible, but not very likely. The current source is set up so that all the versions are compiled automatically, using the correct -m options for each version. There is no manual intervention in the process, which is where an error like this would be most likely to happen. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 23:07:57 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89824-4>; Mon, 19 Jun 1995 20:44:31 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sNlnX-0004nZC; Mon, 19 Jun 95 11:43 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Problems with Ixemul 41.0 To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Mon, 19 Jun 1995 11:43:47 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9506191624.AA26743@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Jun 19, 95 06:24:57 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 903 > I don't know if that helps, but hacking the first assembler instruction > of crto.0 into 16-bit PC-relative (which was used in V40 crt0.o) > replaces the 80000003 by an 8000000b (68020 instruction). Be very careful with this. The offset for where the jump is made to will be different in versions of the library assembled with the binutils assembler, which doesn't seem to be able to generate the shorted jump. There is a hack in the loadseg code that recognizes both the short and long versions of the first instruction and compensates accordingly. No fix is yet available for the assembler, unfortunately. > Also some code in ixemul V41 itself gurus 8000000b (gcc 2.6.3 doesn't > work with the new ixemul on 68000). It would be very helpful is someone with the knowledge and experience to hack shared libraries in assembly could track down what the problem is here and recommend a fix. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 23:08:26 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89746-1>; Mon, 19 Jun 1995 20:24:19 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA14086 (5.65c+/IDA-1.4.4 for ); Mon, 19 Jun 1995 19:21:15 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA03809; Mon, 19 Jun 1995 19:22:10 GMT Date: Mon, 19 Jun 1995 19:22:10 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Jeff Shepherd Cc: Peter Ivimey-Cook , Amiga GCC List Subject: Re: Problems with Ixemul 41.0 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I think Peter is right here. All I did was install the 68030 version of > ixemul.library in libs: and went on compiling as normal. Ixemul 41.0 > should be compatible with ixemul 40.4. The only reason to install the new > libc.a and new crt0.o would be to take advantage of new ixemul features. Don't forget ix40.6 is supposed to ge the end of conflict between ix39.47 and ix40.0 (a.k.a: Markus Wild and Philippe Brand). These two awthors used diferent _LVO's for some functions so that programs compiled to one of these ixemul's would hardly work with the other. From now one it is supposed never to happen again but, anyway, it is needed to compile with new libc.a and ctr0.o so that your program uses the new (and final, I hope) stubs. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 23:08:44 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <89717-2>; Mon, 19 Jun 1995 20:16:38 +0300 Received: by math.uwaterloo.ca id <77138-4>; Mon, 19 Jun 1995 13:10:35 -0400 Date: Mon, 19 Jun 1995 13:10:34 -0400 From: Jeff Shepherd To: Peter Ivimey-Cook cc: Pedro Miguel Sequeira Teixeira , Amiga GCC List Subject: Re: Problems with Ixemul 41.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Jun 1995, Peter Ivimey-Cook wrote: > On Mon, 19 Jun 1995, Pedro Miguel Sequeira Teixeira wrote: > > > > I recently downloaded the 41.0 ixemul and installed it over my current > > > 2.6.3 install of gcc. > > > > > > It compiled a simple program (using nothing but simple stdio & stdlib > > > calls) fine. However as soon as it was run I get a 80000003 guru - > > > address error. The same program had worked fine with 40.4. > > > > > > > Have you recompiled this program with the new libc.a and > > startup module (usualy crt0.o) ? Every program should be recompiled > > to work on ix40.6 and ix41.0... > > > I installed the ixemul4100-bin archive on top of my existing install, > then recompiled the program from scratch (only one .c file). It failed > instantly... I'm fairly sure this is a 68000 vs 680[234]0 problem with > memory references... > I think Peter is right here. All I did was install the 68030 version of ixemul.library in libs: and went on compiling as normal. Ixemul 41.0 should be compatible with ixemul 40.4. The only reason to install the new libc.a and new crt0.o would be to take advantage of new ixemul features. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Mon Jun 19 23:09:18 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <88592-3>; Mon, 19 Jun 1995 22:24:47 +0300 Received: from katarina.lysator.liu.se (katarina.lysator.liu.se [130.236.254.31]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id VAA21455; Mon, 19 Jun 1995 21:24:24 +0200 From: Niels M|ller Received: (nisse@localhost) by katarina.lysator.liu.se (8.6.11/8.6.11) id VAA01032; Mon, 19 Jun 1995 21:24:32 +0200 Date: Mon, 19 Jun 1995 21:24:32 +0200 Message-Id: <199506191924.VAA01032@katarina.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: stieber@informatik.tu-muenchen.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95Jun19.172236+0100mesz.209224-2+651@hphalle0.informatik.tu-muenchen.de> (message from Christian Stieber on Mon, 19 Jun 1995 17:22:28 +0200 (MESZ)) Subject: Re: GCC 2.6.3 Bugs From: Christian Stieber > > My example was buggy, I agree, but the main question still > > remains - why in original inlines D2 is preserved? > Ok, it seems that D2 needn't be marked as scratched, as it's preserved > by the asm statement JSR (like any of D2-D7, A2-A7) and shouldn't be > affected by the __asm(D2) register declarations. I don't know if this > leaves room for many optimizations though. It's a long time since I read the assembler programming rules of the RKM, but I seem to remember that it states that d0,d1,a0,a1 *and any additional registers used for passing arguments* may be destroyed by calling OS functions. If this is correct, as far as I understand, the inline header for a function with an argument passed in d2 must have d2 in the list of clobbered registers. I'm sorry I'm not really sure about this, but please check it out carefully before you change these inline headers. /Niels From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 01:17:43 1995 Received: from epsilon.qmw.ac.uk ([138.37.6.3]) by nic.funet.fi with SMTP id <90704-2>; Tue, 20 Jun 1995 01:15:35 +0300 Received: from canary.dcs.qmw.ac.uk by epsilon.qmw.ac.uk with SMTP-DNS (PP) id <21068-0@epsilon.qmw.ac.uk>; Mon, 19 Jun 1995 23:15:07 +0100 Received: from magician.dcs.qmw.ac.uk [192.135.231.242] by canary.dcs.qmw.ac.uk (8.6.12/QMW-server-2.4s) with SMTP; poster "Liu "; id XAA11003; Mon, 19 Jun 1995 23:14:54 +0100 From: Liu Full-Name: Liu Received: from it154.dcs.qmw.ac.uk by magician.dcs.qmw.ac.uk (4.1/QMW-client-3.2b); for "amiga-gcc-port@nic.funet.fi"; poster "wmliu168"; id AA02261; Mon, 19 Jun 95 23:14:51 BST Received: from localhost by it154.dcs.qmw.ac.uk (8.6.4/QMW-Minimal-1.14) id XAA07041; Mon, 19 Jun 1995 23:03:05 +0100 Message-Id: <199506192203.XAA07041@it154.dcs.qmw.ac.uk> Subject: GCC and AmiTCP & FAQ... To: amiga-gcc-port@nic.funet.fi Date: Mon, 19 Jun 1995 23:03:04 +0000 (BST) Cc: zgac3024@qmw.ac.uk In-Reply-To: from "Pedro Miguel Sequeira Teixeira" at Jun 19, 95 06:54:23 pm X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 1688 Guys and Gals... What is the 'official' archive to use for TCP/IP programming on the Amiga using GCC? Do we use the '*sdk*.lha' archive or the other archive '*-gcc.lha*' Could someone put the above information into the FAQ along with HOW to install the stuff as I have been unable to install/get it working i.e. the instructions given are 'half baked'...BTW who is the FAQ getting along... -- Raymond W.M.Liu Esq. BSc.(Hons.) ____________________________________________________________________________ | | | 1994/95 : MSc. Adv. Methods in Comp. Sci. (Distributed & Parallel Sys.) | |____________________________________________________________________________| | | | | Internet : wmliu168@dcs.qmw.ac.uk | AmigaOS - Pre-emptive multi-tasking | | Internet : zgac3024@qmw.ac.uk | + s/ware MS-DOS/Windows emu... | | | + s/ware Macintosh MacOS emu... _ | | Informatics Teaching Laboratory | + etc....(ALL Pre-Emptively) // | | Queen Mary & Westfield Collefe | _ // | | University of London | "..Taking a big Byte out \\ // | | | of a Big Blue Apple..." \X/ | | Tel.: +44 171 975 5252 |_______________________________________| | (Direct) 0700-0200 UTC | Tartan desires... |_#_#_#_#_#| |____________________________________|____________________________|_#_#_#_#_#| All standard disclaimers apply .sig design (c) Copyright by W.M.Liu, 1995. From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 05:29:17 1995 Received: from virginia.edu ([128.143.2.7]) by nic.funet.fi with SMTP id <88937-2>; Tue, 20 Jun 1995 05:28:07 +0300 Received: from k30hadastra by uvaarpa.virginia.edu id aa08664; 19 Jun 95 22:27 EDT Received: by adastra.cvl.va.us (V1.17-beta/Amiga) id <3xp2@adastra.cvl.va.us>; Mon, 19 Jun 95 22:12:27 EDT Date: Mon, 19 Jun 95 22:12:27 EDT Message-Id: <9506200212.3xp2@adastra.cvl.va.us> In-Reply-To: from Peter Ivimey-Cook at Mon, 12 Jun 1995 13:19:35 +0100 (BST) X-Mailer: GMail 0.55 (11.5.95) From: "Michael B. Smith" To: amiga-gcc-port@nic.funet.fi Subject: Re: Fork problems Sorry for the delay, I've been out of town. Peter Ivimey-Cook said: > I'm having a go at porting to Amiga the current version of Unix sendmail. > However, it relies on forking new children which carry on doing the work > of the parent, using the parent's state to tell the child what to do! Of > course this isn't going to work on the Amiga - or is it? > > Is there any way such a system can be made to work? I've spent a _lot_ of time looking at sendmail over the last three years, both because of INetUtils and because of supporting it at work. To make it fully usable, you've either got to do significant amount of rework on its internals, or truly emulate fork(). IMHO. > The alternative (which is possible) is to make sendmail single-threaded. > It might be simpler to do this than anything else, but I wanted to hear You can do this for outgoing mails. For incoming mails, this would be unacceptable. My SMTPd goes through machinations that you wouldn't believe to avoid this being a problem. Only allowing one connect at a time would not work for even a moderately busy site. The delays that RFC-1123 allows (and sendmail therefore allows as well) can make the reception of a 2K message an hour long process. And some propagation delays are truly that bad. Close to it, anyway. :) A custom integrated solution would be workable, but then you get into interface issues. It didn't seem seamlessly workable to me. You should also keep in mind the pure _size_ of sendmail. It's big, just in binary size, never mind the dynamic allocations that it makes. You may not _ever_ get the "dumped" format to work for the configuration file (I never got so far as to look at that); and that would result in a huge performance hit. > Also, has anyone ported bind-4.9 - the internet resolver / named files? > If not I'll have to port them too :( I've ported most of the bind suite two times, from scratch. I did it the second time because I wasn't happy with the results of the first port. DNS is trivial. named is close to impossible to do completely (again, there is a serious fork() dependency) as a port, but as soon as you drop Zone transfers, it becomes fairly simple. There are vfork2() areas that would be required, and I made some things a bit simpler by adding a couple of new command line options and using s_inherit() and s_release() (I think ReleaseSocket() and ObtainSocket() are the AmiTCP equivalents). My work is encumbered, and for AS225r2, but I can offer some advice and/or opinions if you want them. :) -- // Michael B. Smith \X/ mbs@adastra.cvl.va.us From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 11:10:34 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <89007-1>; Tue, 20 Jun 1995 11:08:27 +0300 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id KAA11414 for ; Tue, 20 Jun 1995 10:05:54 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA17470; Tue, 20 Jun 95 08:51:06 GMT Date: Tue, 20 Jun 95 08:51:06 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9506200851.AA17470@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: Probleme with gcc 2.7.0 Hi, I just upload gcc-2.7.0 from funet, but I can't get it to work. `as' and `cpp' don't work, do nothing and end with error -1. My config: A2000/68030/68882 with ixemul030fpu version 41.0 (from aminet) \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier | Etudiant en Doctorat | Centre de Recherche en Informatique E-Mail: | Universite Louis Pasteur papier@dpt-info.u-strasbg.fr | Strasbourg - FRANCE ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 11:29:16 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <88938-4>; Tue, 20 Jun 1995 11:28:07 +0300 Received: by colombo.telesys-innov.fr; Tue, 20 Jun 1995 10:30:03 +0100 From: Philippe BRAND Message-Id: <199506200930.KAA04385@colombo.telesys-innov.fr> Subject: Re: Probleme with gcc 2.7.0 To: papier@indi1.u-strasbg.fr (Laurent Papier) Date: Tue, 20 Jun 1995 10:30:00 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9506200851.AA17470@indi1.u-strasbg.fr> from "Laurent Papier" at Jun 20, 95 08:51:06 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 416 Laurent Papier writes: > I just upload gcc-2.7.0 from funet, but I can't get it to work. > `as' and `cpp' don't work, do nothing and end with error -1. I'll CRC check my executables, as I had some SCSI transfer problemes few days ago. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 13:04:10 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <89114-3>; Tue, 20 Jun 1995 13:02:34 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA09358 (5.65c8/IDA-1.4.4 for ); Tue, 20 Jun 1995 12:02:18 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA27317; Tue, 20 Jun 95 12:02:17 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506201002.AA27317@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Problems with Ixemul 41.0 To: amiga-gcc-port@nic.funet.fi Date: Tue, 20 Jun 1995 12:02:17 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1149 > Be very careful with this. The offset for where the jump is made to > will be different in versions of the library assembled with the > binutils assembler, which doesn't seem to be able to generate the > shorted jump. Strange. AFAIK the 68000 has not even a 32 bit PC-relative addressing mode. That's why I replaced it with the 16 bit version. (But I have to check this - I'm no assembly expert and use it only for things normal C cannot do.) > There is a hack in the loadseg code that recognizes > both the short and long versions of the first instruction and > compensates accordingly. No fix is yet available for the assembler, > unfortunately. As long as I start my programs from normal CLI this should be no problem, I hope :-). > It would be very helpful is someone with the knowledge and experience > to hack shared libraries in assembly could track down what the problem > is here and recommend a fix. At a first guess I'd say that the assembler writes 68020+ code as soon as you start using certain assembler instructions the compiler doesn't produce. (Like for example jmp pc@). That's why nobody noticed it until now. Matthias From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 13:08:03 1995 Received: from specklec.mpifr-bonn.mpg.de ([134.104.20.3]) by nic.funet.fi with SMTP id <88926-3>; Tue, 20 Jun 1995 13:07:41 +0300 Received: from spcklx.mpifr-bonn.mpg.de (spcklx.mpifr-bonn.mpg.de [134.104.20.23]) by specklec.mpifr-bonn.mpg.de (8.6.10/8.6.9) with ESMTP id MAA22364 for ; Tue, 20 Jun 1995 12:02:48 +0200 From: Gerd Schniggenberg Received: (gs@localhost) by spcklx.mpifr-bonn.mpg.de (8.6.9/8.6.9) id MAA21910 for amiga-gcc-port@nic.funet.fi; Tue, 20 Jun 1995 12:03:10 +0200 Message-Id: <199506201003.MAA21910@spcklx.mpifr-bonn.mpg.de> Subject: extendet floats To: amiga-gcc-port@nic.funet.fi Date: Tue, 20 Jun 95 12:03:09 MET DST Return-Receipt-To: "Gerd Schniggenberg" X-Mailer: ELM [version 2.2 PL14] Hi! I found that "long double" has the same accuracy as "double" (float.h). What about the 80Bit extended floats? I'm sure the 68881/2 supports them. I think with coprozessor inline code(-m68881) it could be done. is it possible with the gcc? Gerd -- From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 15:10:35 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <88960-4>; Tue, 20 Jun 1995 15:06:13 +0300 Received: by roemer.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun20.150613+0300_eet_dst.88960-4+29@nic.funet.fi> From: To: Date: Tue, 20 Jun 1995 15:06:10 +0300 Date: Tue, 20 Jun 1995 14:05:29 +0200 (METDST) From: Rask Lambertsen To: " (Matthew Clemence)" Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Debugger In-Reply-To: <9506191500.AA10181@medphys.ucl.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Jun 1995, (Matthew Clemence) wrote: > I don't know if this is the right place to ask, but .. > I am looking for a source debugging tool (like dbxtool or dbx) for use with > gcc ? > Does one exist ? Try the debugger that comes with the Barfly assembler. Get it from Aminet in directory dev/asm, file Barfly1_22.lha or something like that. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ P.S. I'm trying to fix the Subject-line problems, but it is not my mailer that is faulty, and it is not the list server, it seems. From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 18:04:04 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <90665-2>; Tue, 20 Jun 1995 18:01:37 +0300 Received: by roemer.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun20.180137+0300_eet_dst.90665-2+33@nic.funet.fi> From: To: Date: Tue, 20 Jun 1995 18:01:31 +0300 Date: Tue, 20 Jun 1995 17:00:49 +0200 (METDST) From: Rask Lambertsen To: Niklas Hallqvist Cc: Walter.Harms@arbi.informatik.uni-oldenburg.de, amiga-gcc-port@nic.funet.fi Subject: Re: fork() and friends In-Reply-To: <199505161301.PAA10850@linda.appli.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 16 May 1995, Niklas Hallqvist wrote: > Even the stack address space would be shared in a strict fork > implementation. Thus this program would be hard to solve right: > > #include > > int > main () > { > int i = 1; > int *p = &i; > int w; > > if (fork () > 0) > { > wait (&w); > assert (i == 1); > } > else > *p = 2; > return 0; > } > > As you see you can't copy the stack as then you will get p to point to > another stack. Still, the i variable in both the parent and child > needs to be distinct, i.e. not shared. Belive me, it's not easy to > solve the traditional fork semantics in the Amiga OS. How about some sort of relocation? Maybe the compiler could write an extra function whenever there is a fork() call, so that the pointers could be relocated. The compiler knows which variables are pointer variables, so maybe it would be possible. Then when a new stack has been allocated and the contents of the old (parent) one has been copied to the new (child) one, you could call the compiler generated functin to relocate all pointers on the new stack. The relocation function would have to relocate only pointers that point to the parent stack, but that should be no problem. The DICE compiler uses a similar technique to create residentable programs that can have distinct global variables. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 18:38:28 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <88931-3>; Tue, 20 Jun 1995 18:36:54 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA05112 (5.65c+/IDA-1.4.4 for ); Tue, 20 Jun 1995 17:35:58 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA16062; Tue, 20 Jun 1995 17:37:15 GMT Date: Tue, 20 Jun 1995 17:37:15 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Matthias Fleischer Cc: amiga-gcc-port@nic.funet.fi Subject: overlays-Matthias Fleischer answered In-Reply-To: <9506140850.AA21361@sunserv.IZFM.Uni-Stuttgart.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 14 Jun 1995, Matthias Fleischer wrote: > > I think Matthias Fleischer would like to answer this. > > > Yep :-). I can give you some reasons to use gcc instead of other > amiga compilers: > > >From a beginners point of view who wants to get his first compiler gcc > has the advantage that you get a good compiler for almost no money > (you may want to count the harddisk space gcc needs if you keep it: > about 10$ for 20MB these days). This is not the situation of the original poster... > >From a programmers point of view its good to have sources available > (to track down bugs (is it the libc or the OS...), change the behaviour of > the libc (why is malloc so slow...), etc.) I think the original poster would be satisfied to solve his own problems... > For a software company gcc _guarantees_ that you may get additional > licences in the future (to keep the few compiler dependencies you > cannot avoid future compatible). Again, this is not the issue. Quite realy, I'm not saying that GCC is better or worse than SAS/C. But, From the developer point of view, I think mixing GCC compiling and SAS/C linking or vice-versa brings up quite a lot of trouble. As I said before, I'm working on X11 as a shared library and I'm not having much of a choice as to cross these two execelent tools, anyway I think that, for this case, one should try a lot more of things before mentioning cross. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 19:31:09 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89010-3>; Tue, 20 Jun 1995 19:29:23 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sO76V-0004nZC; Tue, 20 Jun 95 10:28 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Problems with Ixemul 41.0 To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Tue, 20 Jun 1995 10:28:46 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi, fnf@amigalib.com (Fred Fish) In-Reply-To: <9506201002.AA27317@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Jun 20, 95 12:02:17 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3865 > > Be very careful with this. The offset for where the jump is made to > > will be different in versions of the library assembled with the > > binutils assembler, which doesn't seem to be able to generate the > > shorted jump. > > Strange. AFAIK the 68000 has not even a 32 bit PC-relative addressing > mode. That's why I replaced it with the 16 bit version. > (But I have to check this - I'm no assembly expert and use it only > for things normal C cannot do.) Below is a copy of the mail I sent to the gas maintainers. So far there is no fix that I know of to gas. I did get a workaround hint, which does seem to cause the right instruction to be generated, but apparently screws up something else that I never was able to get the time to track down. The comment about this is also included below. Unfortunately, now that versions of crt0.o are in use that have this longer instruction sequence, the hack in ixemul.library is going to have to remain there for backward compatibility with executables generated with the crt0.o. > > There is a hack in the loadseg code that recognizes > > both the short and long versions of the first instruction and > > compensates accordingly. No fix is yet available for the assembler, > > unfortunately. > > As long as I start my programs from normal CLI this should be no > problem, I hope :-). As long as you are careful to not change the location to which the first instruction jumps. The ixemul.library uses a hack of looking for a magic number at a specific offset in the beginning of an executable to know whether or not it is starting an ixemul.library using program. If so, it handles passing of command line args and possibly some other things in a more unix compatible way. Unfortunately, this assembler problem causes that magic number to be located 4 bytes further into the executable, so that ixemul.library now has to probe two locations. > > It would be very helpful is someone with the knowledge and experience > > to hack shared libraries in assembly could track down what the problem > > is here and recommend a fix. > > At a first guess I'd say that the assembler writes 68020+ code > as soon as you start using certain assembler instructions the compiler > doesn't produce. (Like for example jmp pc@). That's why nobody noticed > it until now. Ack! That would be nasty of it, but not unheard of I suppose. ============================================================================ I have a short m68k instruction sequence that looks like: .text jmp pc@(_ENTRY) magic: .word 0xDEAD .word 0xBEEF .text .even _ENTRY: link a5,#0 L1: unlk a5 rts A port of gas 1.38 assembles this as: 0000040 4efa 0004 dead beef 4e55 0000 4e5d 4e75 while a current gas (binutils 2.5.2) assembles it as: 0000040 4efb 0170 0000 000a dead beef 4e55 0000 I've looked briefly at a 68030 assembly manual which indicates that the first form uses address mode "(d16,PC)" and the second is "(d8,PC,Xn)". Before I go digging through the assembler, and dust off my extremely rusty knowledge of 68k assembly, can anyone tell me a simply way to get the 1.38 form out of 2.5.2? For backwards compatibility in the environment I'm trying to use the code in, "magic" has to be at the offset generated by the 1.38 form. -Fred ============================================================================ /* FIXME: The "jmp pc@(_ENTRY)" instruction below, when assembled with binutils gas, produces a 12 byte instruction that causes the magic number to not be in the place expected by execve(). Changing it to "jmp pc@(_ENTRY:W)" generates the right 8 byte instruction, but seems to screw something else up so that the programs crash immediately or hang. Need to investigate why. When fixed, need to remove the hack in execve() that allows for either assembled form. */ From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 21:10:22 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <90160-3>; Tue, 20 Jun 1995 21:08:33 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA04199; Tue, 20 Jun 1995 20:07:20 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9506201807.AA04199@decap2.zdv.uni-tuebingen.de> Subject: Problem with gcc-2.7.0 beta To: amiga-gcc-port@nic.funet.fi Date: Tue, 20 Jun 1995 20:07:19 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 385 Hello, I have downloaded the new gcc distribution today. However, I was not able to use it, as cpp could not get started from within gcc. SnoopDos showed the following: gcc ChangeDir NetBSD:gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cpp gcc Load Regards, Jochen P.S: Philippe, what about my suggestion for a gcc config file? From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 22:10:53 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89007-4>; Tue, 20 Jun 1995 22:09:04 +0300 Received: by theseas.ntua.gr with UUCP; Tue, 20 Jun 1995 22:12:03 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07gn@kriton.UUCP>; Tue, 20 Jun 95 22:06:43 EET Date: Tue, 20 Jun 95 22:06:43 EET Message-Id: <9506202006.07gn@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 947 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: ixprefs update #1 I have modified the format in which ixprefs saves the configuration of ixemul.library. The configuration is now saved in S:ixprefs, using an order independent "option=value" format. You can even add comments by prefixing lines with a "#". Here's what S:ixprefs looks like after selecting "Edit->Reset to defaults" and hitting "Save": ix_no_insert_disk_requester=0 ix_unix_pattern_matching_case_sensitive=0 ix_unix_pattern_matching=0 ix_no_ces_then_open_console=1 ix_ignore_global_env=0 ix_disable_fibcache=0 ix_translate_dots=1 ix_watch_stack=0 ix_force_translation=0 ix_translate_symlinks=0 ix_translate_slash=1 ix_membuf_limit=0 ix_red_zone_size=0 ix_fs_buf_factor=64 I still need to write the docs; they should be ready in a day or two. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Circular logic will only make you dizzy!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 22:19:11 1995 Received: from nz11.rz.uni-karlsruhe.de ([129.13.64.7]) by nic.funet.fi with ESMTP id <90104-4>; Tue, 20 Jun 1995 22:18:38 +0300 Received: from rzstud2.rz.uni-karlsruhe.de (actually rzstud1.rz.uni-karlsruhe.de) by nz11.rz.uni-karlsruhe.de with SMTP (PP); Tue, 20 Jun 1995 21:15:10 +0200 Received: by rzstud2.rz.uni-karlsruhe.de (1.37.109.16/16.2) id AA111135710; Tue, 20 Jun 1995 21:15:10 +0200 Subject: Problems with GCC To: amiga-gcc-port@nic.funet.fi Date: Tue, 20 Jun 1995 21:15:09 +0200 (CES) From: ukkw@rz.uni-karlsruhe.de (Martin Zieger) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 1761 Message-ID: <"nz11.rz.un.165:20.06.95.19.16.00"@rz.uni-karlsruhe.de> Hi! I've problems writing Amiga-specific programs with gcc. I'm using gcc 2.6.3 from Aminet. Compiling an example from RKM-Libraries (hotkey.c, page 738) with gcc hotkey.c the following type of warnings occur: ---------------------------- GNUINCLUDE:clib/exec_protos.h:49: warning: `struct MemHeader' declared inside parameter list GNUINCLUDE:clib/exec_protos.h:49: warning: its scope is only this definition or declaration, GNUINCLUDE:clib/exec_protos.h:49: warning: which is probably not what you want. etc. ... t:cc9938161.o: Undefined symbol _OpenLibrary referenced from text segment ---------------------------- and the gcc stops with a return value of 1. Another problem: I've tried to compile the helloworld-example libnix.guide: ---------------------------- GNU:> gcc -v -noixemul -s -O2 -fbaserel wbtest.c Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -Dmc GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: GNUINCLUDE: /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.6.3/cc1 t:cc993816.i -quiet -dumpbase wbtest.c -O2 -version -f GNU C version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3 snapshot 941209. wbtest.c:9: conflicting types for `DOSBase' /gnu/os-include/inline/dos.h:21: previous declaration of `DOSBase' ---------------------------- gcc returned 1. I've generated the inline headers with gen31, but the same result. What's wrong? Please help me! Thanks, -Martin From amiga-gcc-port-owner@nic.funet.fi Tue Jun 20 22:32:44 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <88967-1>; Tue, 20 Jun 1995 22:31:00 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA04421; Tue, 20 Jun 1995 21:30:42 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9506201930.AA04421@decap2.zdv.uni-tuebingen.de> Subject: Re: Problems with GCC To: ukkw@rz.uni-karlsruhe.de (Martin Zieger) Date: Tue, 20 Jun 1995 21:30:41 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <"nz11.rz.un.165:20.06.95.19.16.00"@rz.uni-karlsruhe.de> from "Martin Zieger" at Jun 20, 95 09:15:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 471 Hello, Martin, I'd suggest to get the amiga-gcc-faq, which contains an example. (ftp.funet.fi, /pub/amiga/gnu/beta, I believe) Btw, the FAQ is a little bit funny in that point. In the example there is the following: /* Compile me with gcc -noixemul -o HelloWorld HelloWorld.c -lauto */ Some pages below Gunther is warning about not to use -noixemul -lauto. :-) (Obviously an answer for exactly the same example.) This should be fixed. Jochen From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 01:16:06 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <90104-4>; Wed, 21 Jun 1995 01:14:33 +0300 Received: by theseas.ntua.gr with UUCP; Wed, 21 Jun 1995 01:17:32 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07gz@kriton.UUCP>; Wed, 21 Jun 95 01:12:35 EET Date: Wed, 21 Jun 95 01:12:35 EET Message-Id: <9506202312.07gz@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 619 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Question on configuration options Could someone describe the function of the following ixemul.library configuration options? (I need to add their description to the ixprefs docs.) * Enable stack watcher * Red zone size * Disable fibcache (this option is not available through ixconfig, but as long as it exists, I might as well put it in ixprefs). Thanks, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Your species doesn't, uh, do anything, you know, *awful* when you get too happy, do you? Like, you know, blow up or something?" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 01:16:26 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89188-1>; Wed, 21 Jun 1995 01:14:40 +0300 Received: by colombo.telesys-innov.fr; Wed, 21 Jun 1995 00:16:36 +0100 From: Philippe BRAND Message-Id: <199506202316.AAA13108@colombo.telesys-innov.fr> Subject: Re: Problem with gcc-2.7.0 beta To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Wed, 21 Jun 1995 00:16:36 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9506201807.AA04199@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Jun 20, 95 08:07:19 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 450 Jochen Wiedmann writes: > I have downloaded the new gcc distribution today. However, I was > not able to use it, as cpp could not get started from within gcc. For a unknown reason, files were corrupted because of some SCSI problems. I'll build a new beta for tomorrow. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 01:17:08 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <88944-3>; Wed, 21 Jun 1995 01:14:32 +0300 Received: by theseas.ntua.gr with UUCP; Wed, 21 Jun 1995 01:17:34 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07gu@kriton.UUCP>; Tue, 20 Jun 95 23:39:03 EET Date: Tue, 20 Jun 95 23:39:03 EET Message-Id: <9506202139.07gu@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 586 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: ix_translate_symlinks bug? I think that the ix_translate_symlinks flag of ixemul.library version 41.0 works in the reverse way than the intended: When I set ix_translate_symlinks=1 and create a symbolic link to "..", newlist reports that the link was made to the actual AmigaDOS file. When I set ix_translate_symlinks=0, newlist reports that the list was made to "..". Shouldn't this be the other way round? -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Circular logic will only make you dizzy!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 10:35:29 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <90628-2>; Wed, 21 Jun 1995 10:31:32 +0300 Received: by tycho.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun21.103132+0300_eet_dst.90628-2+10@nic.funet.fi> From: To: Date: Wed, 21 Jun 1995 10:31:31 +0300 Date: Wed, 21 Jun 1995 09:31:21 +0200 (METDST) From: Rask Lambertsen To: Martin Zieger Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Problems with GCC In-Reply-To: <"nz11.rz.un.165:20.06.95.19.16.00"@rz.uni-karlsruhe.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 20 Jun 1995, Martin Zieger wrote: > Hi! > > I've problems writing Amiga-specific programs with gcc. > I'm using gcc 2.6.3 from Aminet. > > Compiling an example from RKM-Libraries (hotkey.c, page 738) with > gcc hotkey.c > the following type of warnings occur: > > ---------------------------- > GNUINCLUDE:clib/exec_protos.h:49: warning: `struct MemHeader' declared inside parameter list > GNUINCLUDE:clib/exec_protos.h:49: warning: its scope is only this definition or declaration, > GNUINCLUDE:clib/exec_protos.h:49: warning: which is probably not what you want. > etc. ... > > t:cc9938161.o: Undefined symbol _OpenLibrary referenced from text segment > ---------------------------- > and the gcc stops with a return value of 1. (stuff deleted) > I've generated the inline headers with gen31, but the same result. > > What's wrong? Please help me! It's very simple: You forgot to #include before . Then GCC know nothing about a struct MemHeader when it finds it in the prototype file, and thus freaks out. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 10:57:32 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90186-3>; Wed, 21 Jun 1995 10:55:46 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id JAA07674; Wed, 21 Jun 1995 09:57:49 +0200 Date: Wed, 21 Jun 1995 09:57:47 +0200 (MET DST) From: Kamil Iskra Subject: GCC 2.7.0 BETA To: amiga-gcc-port@nic.funet.fi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII BUGS: - Executables "cpp" and "as" are broken (reported by others, as well). - Option "-mc68020" does not cause "-fl libm020" to be appended to linker's commandline. - Option "-m68020-40" is not recognized. - "-mstakcheck" does not work well together with "-noixemul". When stack is about to overflow, the task hangs with various error numbers (#4, #A, #B). Sometimes Enforcer/MungWall hits are generated, but from various locations (ROM, RAM), so I think they are not the source of the problem. Here is the source code: #include #define MAXREC 5000 void recursfunct(int b) { if (!(b % 100)) printf("%d\n", b); if (b; Wed, 21 Jun 1995 11:25:58 +0300 Received: by colombo.telesys-innov.fr; Wed, 21 Jun 1995 10:27:45 +0100 From: Philippe BRAND Message-Id: <199506210927.KAA13942@colombo.telesys-innov.fr> Subject: New beta version available To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Wed, 21 Jun 1995 10:27:44 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 374 Ok I've built a new beta version and this time I checked files. new name: gcc-2.7.0-beta-amiga.lha, both on: colombo.telesys-innov.fr:/pub/amigados-gnu/beta, and nic.funet.fi:/pub/amiga/gnu/beta -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 11:49:13 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90208-3>; Wed, 21 Jun 1995 11:46:55 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA09718; Wed, 21 Jun 1995 10:47:53 +0200 Date: Wed, 21 Jun 1995 10:47:52 +0200 (MET DST) From: Kamil Iskra Subject: Re: New beta version available To: Philippe BRAND cc: Amiga-Gcc Liste In-Reply-To: <199506210927.KAA13942@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 21 Jun 1995, Philippe BRAND wrote: > Ok I've built a new beta version and this time I checked files. > new name: gcc-2.7.0-beta-amiga.lha, both on: > colombo.telesys-innov.fr:/pub/amigados-gnu/beta, and > nic.funet.fi:/pub/amiga/gnu/beta Too bad there is no "NEWS" file included - I would like to know what FSF has changed in this release. I would also like to be able to use C++. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 11:56:44 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <89000-1>; Wed, 21 Jun 1995 11:55:13 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id KAA13833; Wed, 21 Jun 1995 10:53:22 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id KAA24127; Wed, 21 Jun 1995 10:49:31 +0200 Date: Wed, 21 Jun 1995 10:49:31 +0200 From: Niklas Hallqvist Message-Id: <199506210849.KAA24127@linda.appli.se> To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95Jun20.180137+0300_eet_dst.90665-2+33@nic.funet.fi> (gc948374@gbar.dtu.dk) Subject: fork(2) on AmigaDOS >>>>> "Rask" == Rask Ingemann Lambertsen writes: >> As you see you can't copy the stack as then you will get p to point >> to another stack. Still, the i variable in both the parent and >> child needs to be distinct, i.e. not shared. Belive me, it's not >> easy to solve the traditional fork semantics in the Amiga OS. Rask> How about some sort of relocation? Maybe the compiler could Rask> write an extra function whenever there is a fork() call, so Rask> that the pointers could be relocated. The compiler knows Rask> which variables are pointer variables, so maybe it would be Rask> possible. Then when a new stack has been allocated and the Rask> contents of the old (parent) one has been copied to the new Rask> (child) one, you could call the compiler generated functin Rask> to relocate all pointers on the new stack. The relocation Rask> function would have to relocate only pointers that point to Rask> the parent stack, but that should be no problem. It's possible to emulate fork(2) on AmigaDOS but it's hard. It's not just stack which needs to be copied, it's also data and bss. So we're left with four possibilities: 1 Swap stack, data, bss & heap (at least those areas that existed at the point of fork) contents on task switch, not necessarily to disk but at least to other places in RAM. 2 Make a relocation pass like you described. This pass has to recognize all pointers to stack, data, bss or heap sections wherever they are. The problem is much like garbage collection, but a conservative algorithm like Boehm's won't suffice as we also want to *alter* the pointer values. So compiler support is needed and the programs must not be to comple wrt C unions, casts and other dynamic type fiddling. 3 Rewrite the compiler to handle pointers to stack, data, bss and heap as always being base-relative wrt a task data pointer. This would require all sections to be allocated consecutively and require reallocation at traditional brk(2) time. Not very AmigaDOS-nice. On top of that, pointers to external entities like OS variables and IPC messages. would have to be specially tagged to not be treated like base relative entities. 4 Only allow fork(2) on MMU systems, make ixemul MMU aware, and use it to map the address spaces exactly alike on those systems. To me, only 4 seems worthwhile. Perhaps I've forgotten something, please speak up if so. Niklas From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 12:31:45 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <88922-2>; Wed, 21 Jun 1995 12:30:05 +0300 Received: by ceylon.informatik.uni-rostock.de id LAA12598; Wed, 21 Jun 1995 11:29:50 +0200 Received: by honshu.informatik.uni-rostock.de id LAA01719; Wed, 21 Jun 1995 11:29:50 +0200 From: Gunther Nikl Message-Id: <199506210929.LAA01719@honshu.informatik.uni-rostock.de> Subject: Re: Problems with GCC To: ukkw@rz.uni-karlsruhe.de (Martin Zieger) Date: Wed, 21 Jun 1995 11:29:49 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <"nz11.rz.un.165:20.06.95.19.16.00"@rz.uni-karlsruhe.de> from "Martin Zieger" at Jun 20, 95 09:15:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2022 Hi! > I've problems writing Amiga-specific programs with gcc. > I'm using gcc 2.6.3 from Aminet. > > Compiling an example from RKM-Libraries (hotkey.c, page 738) with > gcc hotkey.c > the following type of warnings occur: > > ---------------------------- > GNUINCLUDE:clib/exec_protos.h:49: warning: `struct MemHeader' declared inside parameter list > GNUINCLUDE:clib/exec_protos.h:49: warning: its scope is only this definition or declaration, > GNUINCLUDE:clib/exec_protos.h:49: warning: which is probably not what you want. > etc. ... > > t:cc9938161.o: Undefined symbol _OpenLibrary referenced from text segment > ---------------------------- > and the gcc stops with a return value of 1. The way you compiled hotkey.c links it against ixemul. It seems, that it doesn't link with libamiga.a by default (libnix does, however). To get it work: gcc -o hotkey hotkey.c -lc -lamiga Please do it _that_ way! The warnings could be ignored but if you worry: it seems that the Lattice compiler (the one the example was written for) does not care about unknown structures used in function prototypes. These warnings will disappear, if you switch from "clib/*_proto.h" to "proto/*.h" or if you include the header file that contains the missing structure definition. > Another problem: > I've tried to compile the helloworld-example libnix.guide: > wbtest.c:9: conflicting types for `DOSBase' > /gnu/os-include/inline/dos.h:21: previous declaration of `DOSBase' This is an error in the libnix guide :-( Please change the declaration of DOSBase in the example from: struct Library *DOSBase; to struct DosLibrary *DOSBase; and all should be ok. > I've generated the inline headers with gen31, but the same result. No need to do and in fact its a very bad idea. The inlines that are supplied with gcc 2.6.3 are in a few cases *handcrafted* ! (some function use a5, that is not available to the compiler; some function have been created by hand - DoPkt0/.../DoPkt4) Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 12:40:41 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <89744-4>; Wed, 21 Jun 1995 12:38:54 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA24116 (5.65c8/IDA-1.4.4 for ); Wed, 21 Jun 1995 11:38:41 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA28275; Wed, 21 Jun 95 11:38:41 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506210938.AA28275@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Problems with Ixemul 41.0 To: amiga-gcc-port@nic.funet.fi Date: Wed, 21 Jun 1995 11:38:40 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1301 > > A port of gas 1.38 assembles this as: > > 0000040 4efa 0004 dead beef 4e55 0000 4e5d 4e75 > > while a current gas (binutils 2.5.2) assembles it as: > > 0000040 4efb 0170 0000 000a dead beef 4e55 0000 > > I've looked briefly at a 68030 assembly manual which indicates > that the first form uses address mode "(d16,PC)" and the second > is "(d8,PC,Xn)". Before I go digging through the assembler, and > dust off my extremely rusty knowledge of 68k assembly, can anyone > tell me a simply way to get the 1.38 form out of 2.5.2? For > backwards compatibility in the environment I'm trying to use > the code in, "magic" has to be at the offset generated by the > 1.38 form. > gas 2.5.1 seems to be able to compile 'jmp pc@(_ENTRY:W)' into the right form - crt0.o recompiled with this mentioned fix and gcc2.6.3 works on 68000s. For 2.5.2 another fix might be useful (?): 'jra _ENTRY' compiles into a 4 byte pc relative jump as long as _ENTRY is within the 32k limit. The resulting instruction is a 'bra' instead of 'jmp', though. Both fixes allow to compile a working helloworld.c (using gas 2.5.1) on my machine. The other problem with ixemul 41 seems to happen while a child is returning from a vfork(). I will try to be more precise as soon as I found the cause of the problem. Matthias From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 13:02:28 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89305-4>; Wed, 21 Jun 1995 13:00:23 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 21 Jun 1995 11:59:26 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02955; Wed, 21 Jun 95 11:59:25 +0200 Date: Wed, 21 Jun 95 11:59:25 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9506210959.AA02955@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10753; Wed, 21 Jun 95 11:59:21 +0200 To: Niklas Hallqvist Cc: amiga-gcc-port@nic.funet.fi Subject: fork(2) on AmigaDOS In-Reply-To: <199506210849.KAA24127@linda.appli.se> References: <95Jun20.180137+0300_eet_dst.90665-2+33@nic.funet.fi> <199506210849.KAA24127@linda.appli.se> Niklas Hallqvist writes: > It's possible to emulate fork(2) on AmigaDOS but it's hard. It's not > 4 Only allow fork(2) on MMU systems, make ixemul MMU aware, and > use it to map the address spaces exactly alike on those > systems. You'll also have to make sure that memory allocated by the program is allocated in a way that it doesn't share parts of any MMU page with other programs, or those other programs will get confused. And where will IO buffers be located, in which context (task) will they be used? > To me, only 4 seems worthwhile. IMHO: Forget it :-) We should distinguish between what CAN be done and what _can_ be done, as someone pointed out! Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 13:29:23 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90908-2>; Wed, 21 Jun 1995 13:27:20 +0300 Received: by colombo.telesys-innov.fr; Wed, 21 Jun 1995 12:28:21 +0100 From: Philippe BRAND Message-Id: <199506211128.MAA14495@colombo.telesys-innov.fr> Subject: Re: GCC 2.7.0 BETA To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Wed, 21 Jun 1995 12:28:21 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Kamil Iskra" at Jun 21, 95 09:57:47 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1891 Kamil Iskra writes: > - Executables "cpp" and "as" are broken (reported by others, as well). Fixed. > - Option "-mc68020" does not cause "-fl libm020" to be appended to > linker's commandline. As for now use -m68020. I'll fix this but you can already edit "specs" file: *link: %{noixemul:-shortdata -fl libnix} %{fbaserel:%{!resident:-databss-together -fl libb}}%{resident:-databss-together -datadata-reloc -fl libb} %{g:-amiga-debug-h unk} %{m68020:-fl libm020} %{m68030:-fl libm020} %{m68040:-fl libm020}%{mc68020 :-fl libm020} %{mc68030:-fl libm020} %{mc68040:-fl libm020} > - Option "-m68020-40" is not recognized. I'll fix it in next beta or official release. > - "-mstakcheck" does not work well together with "-noixemul". When > stack is about to overflow, the task hangs with various error numbers > (#4, #A, #B). Sometimes Enforcer/MungWall hits are generated, but from > various locations (ROM, RAM), so I think they are not the source of > the problem. Matthias, Gunther ? > "-mstackextend" seems to work well with "-noixemul" on my Amiga, and > both "-mstackcheck" and "-mstackextend" work well without "-noixemul". Cool. Could you test also -resident ? > - In "/gnu/include/sys/cdefs.h", line 55, definition of "__P" macro > should be surrounded with "#ifndef __P/#endif" - this would prevent > some warnings that are generated by g++. Ok. > - Wouldn't it be nice if gcc executables were pure? This is next step ;-) I wanted at first to have a working 2.7.0 with resident support. Now I can try to build a resident one. > right. But why the bugs concerning commandline parsing have not been > fixed? You should read this mailing list more carefully, I think :-). I'll do ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 13:40:57 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <90909-1>; Wed, 21 Jun 1995 13:39:10 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA15218 (5.65c8/IDA-1.4.4 for ); Wed, 21 Jun 1995 12:38:55 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA28392; Wed, 21 Jun 95 12:38:55 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506211038.AA28392@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: overlays-Matthias Fleischer answered To: l36599@alfa.ist.utl.pt (Pedro Miguel Sequeira Teixeira) Date: Wed, 21 Jun 1995 12:38:54 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Pedro Miguel Sequeira Teixeira" at Jun 20, 95 05:37:15 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 733 > > > > I think Matthias Fleischer would like to answer this. > > > > > Yep :-). I can give you some reasons to use gcc instead of other > > amiga compilers: > > > > This is not the situation of the original poster... > > I think the original poster would be satisfied to solve his own problems... > > Again, this is not the issue. > Sorry, this was my fault then. I don't have much experience in mixing SAS and gcc code and are not the right guy to answer questions there. Therefore your question "Whats the point in compiling with GCC unless you are creating a ixemul client?" mislead me to the wrong assumption that you wanted to hear some reasons for using gcc instead of SAS. That's why I tried to give some. Matthias From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 14:13:57 1995 Received: from srv3.gbar.dtu.dk ([130.225.87.163]) by nic.funet.fi with ESMTP id <90423-4>; Wed, 21 Jun 1995 14:11:56 +0300 Received: by srv3.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun21.141156+0300_eet_dst.90423-4+24@nic.funet.fi> From: To: Date: Wed, 21 Jun 1995 14:11:52 +0300 Date: Wed, 21 Jun 1995 13:12:12 +0200 (METDST) From: Rask Lambertsen To: Niklas Hallqvist Cc: amiga-gcc-port@nic.funet.fi Subject: Re: fork(2) on AmigaDOS In-Reply-To: <199506210849.KAA24127@linda.appli.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 21 Jun 1995, Niklas Hallqvist wrote: > It's possible to emulate fork(2) on AmigaDOS but it's hard. It's not > just stack which needs to be copied, it's also data and bss. So we're > left with four possibilities: > > 1 Swap stack, data, bss & heap (at least those areas that > existed at the point of fork) contents on task switch, not > necessarily to disk but at least to other places in RAM. Not feasible at all, IMO. > 2 Make a relocation pass like you described. This pass has to > recognize all pointers to stack, data, bss or heap sections > wherever they are. The problem is much like garbage > collection, but a conservative algorithm like Boehm's won't > suffice as we also want to *alter* the pointer values. So ^^^^^^^ That's exactly what I ment when I wrote "relocate" :-) . > compiler support is needed and the programs must not be to > comple wrt C unions, casts and other dynamic type fiddling. This will require assistance from the compiler, but I think it is the only real solution (on the Amiga anyway). Since the compiler knows where the pointers are, it could "easily" make a list of them. Then it should be simple for a relocation routine to correct the pointers that need to be changed. Or am I overlooking something? To make it short: The compiler will have to make a list of pointer variables and (maybe) insert an extra function call to the relocation routine. > 3 Rewrite the compiler to handle pointers to stack, data, bss > and heap as always being base-relative wrt a task data > pointer. This would require all sections to be allocated > consecutively and require reallocation at traditional brk(2) > time. Not very AmigaDOS-nice. On top of that, pointers to > external entities like OS variables and IPC messages. would > have to be specially tagged to not be treated like base > relative entities. This might require hacking the LoadSeg() function of dos.library, I think. Anyway, this option has lots of nasty implications. I'd say: "Forget it". > 4 Only allow fork(2) on MMU systems, make ixemul MMU aware, and > use it to map the address spaces exactly alike on those > systems. > > To me, only 4 seems worthwhile. This would of course be very tricky to implement if the MMU is also used for virtual memory and memory protection at the same time. But it would be more UN*X like. I'd go for either number 2 or number 4. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ P.S. If anybody manages to get e-mail from me with intact "Subject:", please e-mail me and tell me so. Some sites DO get the subject, other don't. From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 14:15:25 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <88959-2>; Wed, 21 Jun 1995 14:14:01 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA15365; Wed, 21 Jun 1995 13:15:58 +0200 Date: Wed, 21 Jun 1995 13:15:56 +0200 (MET DST) From: Kamil Iskra Subject: Re: GCC 2.6.3 Bugs To: Christian Stieber cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Jun19.172236+0100mesz.209224-2+651@hphalle0.informatik.tu-muenchen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Jun 1995, Christian Stieber wrote: > Well, unnecessarily saving registers is _always_ bad. Remember, there > are some library functions that use more registers, and they are > all marked as "scratch", causing GNU-C to reload values that aren't > destroyed. And it doesn't sound too complicated to fix (actually, I > was surprised to hear that it's still there). I was surprised, as well. I just thought that I didn't consider something. So I asked cause I'm newbee in gcc (seems that "new blood" can be useful sometimes :-). > As a related matter: > some functions don't clobber all of d0/d1/a0/a1, and some functions > don't need the library base in a6. Maybe the person who > volunteers to fix the inline-generator could also put in a list of > functions with different register clobbing (Forbid(), Permit(), Enable(), > Disable(), ObtainSemaphore(), utility.library math functions, math > functions), so that GNU-C finally knows about these functions. OK, I volunteer to make the necessary corrections. But I have no idea how "pearl" works so I'd rather make corrections in "fd2inline.c", which has been recently posted to Aminet. Unfortunately, this "C"-one has some serious bugs that causes it to fail completely on my Amiga (huge amount of Enforcer hits, no result). I think I'll have to have a closer look at it. Somebody also posted that he thinks that all the registers containing arguments are "scratch". I don't think it's true, but I'll check it out in RKM. > Also, what does "memory" actually do? Whenever I need to make my own > inlines for something, I usually don't specify "memory" unless the > functions writes to memory that I intend to read somewhere in my program. > The problem: I never really understood what "memory" really means :( > So, is anyone out there able to shed some light on this? Maybe we should also remove "memory" from the inlines where it is not necessary? But it's rather hard to say when it is and when it's not - so maybe better let it be as it currently is. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 16:45:21 1995 Received: from cpt6.stm.tudelft.nl ([130.161.186.114]) by nic.funet.fi with SMTP id <89344-2>; Wed, 21 Jun 1995 16:34:35 +0300 Received: by cpt6.stm.tudelft.nl (1.38.193.4/16.2) id AA08542; Wed, 21 Jun 1995 15:38:29 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Maarten D.de Jong ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Subject: Fork From: To: amiga-gcc-port@nic.funet.fi Date: Wed, 21 Jun 95 15:38:29 METDST Mailer: Elm [revision: 70.85] Message-Id: <95Jun21.163435+0300_eet_dst.89344-2+34@nic.funet.fi> Hi! Perhaps a stupid question, but can someone explain to me why fork() is so difficult to implement? I know what fork() does -- a little. It's supposed to spawn a process off your main process and run both (allright sofar??) I've seen all kinds of mailings with lots of solutions (MMU, stack swapping, you name it), but somehow, I seem to have lost the point. Why doesn't a CreateProcess() or AddTask() work? Maarten From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 17:00:06 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <89661-4>; Wed, 21 Jun 1995 16:54:34 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id PAA00591; Wed, 21 Jun 1995 15:38:11 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id PAA25526; Wed, 21 Jun 1995 15:40:15 +0200 Date: Wed, 21 Jun 1995 15:40:15 +0200 From: Niklas Hallqvist Message-Id: <199506211340.PAA25526@linda.appli.se> To: hoehle@inf-wiss.uni-konstanz.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9506210959.AA02955@inf-wiss.uni-konstanz.de> (hoehle@inf-wiss.uni-konstanz.de) Subject: Re: fork(2) on AmigaDOS >>>>> "Joerg-Cyril" == Joerg-Cyril Hoehle writes: Joerg-Cyril> Niklas Hallqvist writes: >> It's possible to emulate fork(2) on AmigaDOS but it's hard. It's >> not >> 4 Only allow fork(2) on MMU systems, make ixemul MMU aware, and use >> it to map the address spaces exactly alike on those systems. Joerg-Cyril> You'll also have to make sure that memory allocated by Joerg-Cyril> the program is allocated in a way that it doesn't share Joerg-Cyril> parts of any MMU page with other programs, or those other Joerg-Cyril> programs will get confused. And where will IO buffers be Joerg-Cyril> located, in which context (task) will they be used? Of course, allocations through the Unix-compatibility library (ixemul) won't be usable for AmigaDOS IPC/IO, you have to use AmigaDOS memory allocation routines for that. Anyway, ixemul clients are not really supposed to be aware of Amiga-specific routines anyway. It's also clear that MMU pages shouldn't be shared unless vfork or shared memory (which aren't in ixemul yet, yes?) uses them. >> To me, only 4 seems worthwhile. Joerg-Cyril> IMHO: Forget it :-) I will, the only ixemul program I use is "loadbsd" :-) Joerg-Cyril> We should distinguish between what CAN be done and what Joerg-Cyril> _can_ be done, as someone pointed out! I am only interested in theoretical possibilities here :-) Maybe someday soon I'll use AmigaDOS again, I have an old A2000 for the kids to use when they're ready for it, which is about time now... Niklas From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 17:13:16 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <90814-1>; Wed, 21 Jun 1995 17:10:06 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA26197; Wed, 21 Jun 1995 15:09:57 +0100 Date: Wed, 21 Jun 1995 15:08:49 +0100 (BST) From: Peter Ivimey-Cook To: dejong@cpt6.stm.tudelft.nl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Fork In-Reply-To: <95Jun21.163435+0300_eet_dst.89344-2+34@nic.funet.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 21 Jun 1995 dejong@cpt6.stm.tudelft.nl wrote: > Perhaps a stupid question, but can someone explain to me why fork() is so > difficult to implement? I know what fork() does -- a little. It's supposed to > spawn a process off your main process and run both (allright sofar??) I've seen > all kinds of mailings with lots of solutions (MMU, stack swapping, you name it), > but somehow, I seem to have lost the point. Why doesn't a CreateProcess() or > AddTask() work? Unix fork doesn't just create a new process - that process is an *exact* *copy* of the parent process. Right down to what variables are set to what and where the instruction pointer is. It s usually followed fairly quickly by the Unix exec(2) call, which then overwrites the copy of the parent with a new program executing at the beginning. This isn't too difficult to emulate with ixemul, as the ""fork"" can suspend the parent process while the child starts until the exec happens, at which a CreateProcess can let both carry on. However some programs (such as sendmail and named, I find) use just fork (no exec) to create child processes which can do subtasks the parent wishes to be done in parallel. In this case, AmigaDOS really isn't able to cope; to do Unix fork with any efficiency at all you Must have a memory management unit *and* an OS which uses it and does inter-process communication by copying (rather than by passing pointers around, as Unix does). So, fork(2) on it's own is really a non-starter on AmigaDOS - the OS itself can't cope. (We could get a LOT closer if the message passing were memory-copy-based, rather than pointer-based. That is, at the moment it's legal to pass a message containing a pointer to a data structure private to the app; that would be illegal in an MMU based system. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 17:45:03 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90905-2>; Wed, 21 Jun 1995 17:40:10 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id QAA12610; Wed, 21 Jun 1995 16:38:17 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id QAA25753; Wed, 21 Jun 1995 16:28:41 +0200 Date: Wed, 21 Jun 1995 16:28:41 +0200 From: Niklas Hallqvist Message-Id: <199506211428.QAA25753@linda.appli.se> To: dejong@cpt6.stm.tudelft.nl CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95Jun21.163435+0300_eet_dst.89344-2+34@nic.funet.fi> (dejong@cpt6.stm.tudelft.nl) Subject: Re: Fork >>>>> "Maarten" == dejong writes: Maarten> Hi! Perhaps a stupid question, but can someone explain to me Maarten> why fork() is so difficult to implement? I know what fork() Maarten> does -- a little. It's supposed to spawn a process off your Maarten> main process and run both (allright sofar??) I've seen all Maarten> kinds of mailings with lots of solutions (MMU, stack Maarten> swapping, you name it), but somehow, I seem to have lost the Maarten> point. Why doesn't a CreateProcess() or AddTask() work? The unix fork(2) system call creates not only a new thread of control, but also a new execution environment which is a *copy* of the old one. Note that the word *copy* is important, because changes done in the new environment must *not* propagate back to the old. This means variables must retain their values after a fork, both in the child and the parent thread (process, task, choose whatever name you like, all systems use them differently), *but* writes to these variables must be visible only to the thread that does it. Unix solves this be mapping all memory exactly the same in each process, but still the memory is distinct, i.e. at different physical locations. To do this easily you need a MMU. Niklas From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 18:02:10 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90628-2>; Wed, 21 Jun 1995 17:59:43 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26470-1>; Wed, 21 Jun 1995 16:56:40 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209223-2>; Wed, 21 Jun 1995 16:56:32 +0100 Subject: Re: Fork From: Christian Stieber To: dejong@cpt6.stm.tudelft.nl Date: Wed, 21 Jun 1995 16:56:21 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Jun21.163435+0300_eet_dst.89344-2+34@nic.funet.fi> from "dejong@cpt6.stm.tudelft.nl" at Jun 21, 95 03:38:29 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 2557 Message-Id: <95Jun21.165632+0100mesz.209223-2+2721@hphalle0.informatik.tu-muenchen.de> > > Perhaps a stupid question, but can someone explain to me why fork() is so > difficult to implement? It's not just difficult --- on AmigaOS, it's impossible :) To understand what fork() does, and why AmigaOS can't do it, you first have to understand how Unix creates a process. I'll omit lots of details --- actual Unix implementations handle things a little differently --- so please don't flame me :) A unix process runs in it's own address space, which covers the full 4GB the CPU can address. Code starts at 0x00000000, data is located above the code (and growing upwards), and the stack is located at 0xffffffff and growing downwards. And this exactly the same situation for all processes. This works because Unix uses the MMU --- the program just thinks it's located at 0x00000000 etc. In reality, the Unix kernel maps the virtual addresses (the addresses the program sees) to some address in RAM, but programs don't know this. They never know where stuff is in real RAM. That's also why Unix programs never run into stack problems --- the stack just grows and grows and grows until the system runs out of memory. So, what does fork() do? Fork() simply creates an identical copy of the parent process. It takes the whole 4GB virtual address space described above, and copies it. That means the child operates on the same program code, with the same data and stack as the parent, at the time the parent called fork(). The only way the child knows "I'm the child" is the return value of fork() --- fork() returns a process ID >0 to the parent, 0 to the child and -1 to the parent on error. That's it. Why is it impossible to implement fork() on AmigaOS? Because fork() just copies _everything_, including data. And you can just copy malloc()ed data on AmigaOS --- it might have pointers inside it! Those pointers would point to the parent's data.... and you can't tell whether something is a pointer: union { void *Pointer; ULONG Integer; } WhatAmI; So, there's no way for AmigaOS to change the pointers to point to the child's data, which is why you can't implement a fork(). Feel free to keep asking if it isn't clear now --- I'm not very good at explaining things :( Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 19:03:27 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90344-3>; Wed, 21 Jun 1995 18:59:57 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26470-2>; Wed, 21 Jun 1995 17:57:45 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209223-1>; Wed, 21 Jun 1995 17:57:33 +0100 Subject: Re: GCC 2.6.3 Bugs From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Wed, 21 Jun 1995 17:57:28 +0200 (MESZ) In-Reply-To: from "Kamil Iskra" at Jun 21, 95 01:15:56 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 987 Message-Id: <95Jun21.175733+0100mesz.209223-1+2768@hphalle0.informatik.tu-muenchen.de> > Maybe we should also remove "memory" from the inlines where it is not > necessary? But it's rather hard to say when it is and when it's not - so > maybe better let it be as it currently is. Well, it's rather simple. Most functions that simply "get" something (GetScreenDrawInfo()) don't need "memory". Also, functions that operate on anoymous objects (like setting the cx filter) don't need it. meth functions don't need it. Functions that free, close or dispose something don't need it (usually...)... but that's a lot of work, since you have to look at every function and decide whether you need memory or not.... Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 19:38:47 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90428-3>; Wed, 21 Jun 1995 19:36:52 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id SAA05193; Wed, 21 Jun 1995 18:35:05 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id RAA26103; Wed, 21 Jun 1995 17:44:55 +0200 Date: Wed, 21 Jun 1995 17:44:55 +0200 From: Niklas Hallqvist Message-Id: <199506211544.RAA26103@linda.appli.se> To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Rask Lambertsen on Wed, 21 Jun 1995 13:12:12 +0200 (METDST)) Subject: Re: fork(2) on AmigaDOS >>>>> "Rask" == Rask Lambertsen writes: Rask> On Wed, 21 Jun 1995, Niklas Hallqvist wrote: >> 1 Swap stack, data, bss & heap (at least those areas that existed >> at the point of fork) contents on task switch, not necessarily to >> disk but at least to other places in RAM. Rask> Not feasible at all, IMO. I'm just putting forward the solutions that could possibly work. This could work, I think, but I'd recommend against it, surely. >> 2 Make a relocation pass like you described. This pass has to >> recognize all pointers to stack, data, bss or heap sections >> wherever they are. The problem is much like garbage collection, >> but a conservative algorithm like Boehm's won't suffice as we also >> want to *alter* the pointer values. So Rask> ^^^^^^^ That's exactly what I Rask> ment when I wrote "relocate" :-) . I know, I just said that we cannot use the algorithms from conservative garbage collectors to find possible pointers. >> compiler support is needed and the programs must not be to comple >> wrt C unions, casts and other dynamic type fiddling. Rask> This will require assistance from the compiler, but I think it Rask> is the only real solution (on the Amiga anyway). Since the Rask> compiler knows where the pointers are, it could "easily" make a Rask> list of them. Then it should be simple for a relocation routine Rask> to correct the pointers that need to be changed. Or am I Rask> overlooking something? Well, compiler *and* linker *and* programmer support. All object files can layout pointers here and there. Pointers will not only reside in named entities, e.g. a linked list is only reachable through the head pointer, the compiler must be able to communicate the structure layout to the relocation routine, not exactly simple, but yes, doable. The point is when dealing with things like this: union u { void *vp; int i; }; or even just void pointers which can take on different struct types depending on context. There certainly are cases where the compiler doesn't have the whole picture. Consider this nice doubly-linked list implementation (bad style, I know): struct node { int xor_link; int item; } struct list { struct node *first, *second; }; Now, let xor_link always be the bitwise xor value of the pointer to the element preceding this node and the one following. This way xor_link works as a bidirectional pointer provided you also have one of the preceding pointer in the direction you're traversing the list. If you XOR this pointer with the xor_link you get a pointer to the next. Neat, but bad coding style as it requires sizeof (int) >= sizeof (struct node *), and prohibits conservative GC. It also quite effectively rules out what we're discussing here... >> 3 Rewrite the compiler to handle pointers to stack, data, bss and >> heap as always being base-relative wrt a task data pointer. This >> would require all sections to be allocated consecutively and >> require reallocation at traditional brk(2) time. Not very >> AmigaDOS-nice. On top of that, pointers to external entities like >> OS variables and IPC messages. would have to be specially tagged >> to not be treated like base relative entities. Rask> This might require hacking the LoadSeg() function of Rask> dos.library, I think. Anyway, this option has lots of nasty Rask> implications. I'd say: "Forget it". Well you don't need LoadSeg to load your data in such a consecutive area, crt0.s could move them all for you at startup. Ugly? Yes, very! I will certainly forget it, but it is a *possible* way to get true fork(2) semantics if one would want it really bad. >> 4 Only allow fork(2) on MMU systems, make ixemul MMU aware, and use >> it to map the address spaces exactly alike on those systems. >> >> To me, only 4 seems worthwhile. Rask> This would of course be very tricky to implement if the MMU is Rask> also used for virtual memory and memory protection at the same Rask> time. But it would be more UN*X like. Of course, ixemul tasks would somehow have to be excluded from other MMU handlers. However, there's no reason why ixemul couldn't provide VM and MP for its clients. As AmigaDOS IPC/IO would be outside the client, much of the MP problems could be moot. Rask> I'd go for either number 2 or number 4. I still say 4, if someone ever wants to do such a thing :-) Niklas From amiga-gcc-port-owner@nic.funet.fi Wed Jun 21 22:54:22 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90909-4>; Wed, 21 Jun 1995 22:50:10 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 21 Jun 95 20:43 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 21 Jun 95 19:15 MET DST Message-Id: Subject: Fork() for FAQ To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 21 Jun 1995 19:15:32 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 365 in dont like to say this but this question should be answered in the FAQ. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 03:27:17 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89991-3>; Thu, 22 Jun 1995 03:23:44 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sOazt-0004nZC; Wed, 21 Jun 95 18:23 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Problems with Ixemul 41.0 To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Wed, 21 Jun 1995 18:23:57 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9506210938.AA28275@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Jun 21, 95 11:38:40 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1626 > gas 2.5.1 seems to be able to compile 'jmp pc@(_ENTRY:W)' into > the right form - crt0.o recompiled with this mentioned fix and > gcc2.6.3 works on 68000s. Hmm, interesting. Gas 2.5.2 accepts the syntax but generates an instruction with a negative displacement, which then crashes the machine immediately. > For 2.5.2 another fix might be useful (?): > 'jra _ENTRY' compiles into a 4 byte pc relative jump as long as > _ENTRY is within the 32k limit. The resulting instruction > is a 'bra' instead of 'jmp', though. This seems to work fine, and is what I'm currently using and testing. One minor thing is that it can potentially generate either a 16 bit or 32 bit instruction, depending upon how far away the _ENTRY symbol is. Currently the symbol is more than will fit in a byte, so the instruction is 0x6000 plus a 16 bit offset. I'd really like a way to force the first 4 bytes to always be either the 32 bit form or a 16 bit instruction plus a nop. I wasn't able to quickly find a pseudo op that would force alignment of the next instruction to a 32 bit boundary. If anyone knows of one, please let me know ASAP. This would then avoid having to add yet another pattern to recognize in execve(). If all goes well with testing, I'll release a 41.1 version of the library when I return from a long weekend next Monday, assuming that this fix is sufficient to allow use on a 68000 again. > The other problem with ixemul 41 seems to happen while a child > is returning from a vfork(). I will try to be more precise as soon > as I found the cause of the problem. What is this "other problem". Is it fatal? -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 09:13:47 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90711-3>; Thu, 22 Jun 1995 09:11:52 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA14917 (5.65b/CWI-3.3); Thu, 22 Jun 1995 08:11:45 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sOfEZ-000FlRC; Thu, 22 Jun 95 07:55 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <083s@wyst.hobby.nl>; Wed, 21 Jun 95 23:40:25 CET Message-Id: <9506212240.083s@wyst.hobby.nl> Date: Wed, 21 Jun 1995 23:40:23 +0000 (CET) In-Reply-To: <9506202006.07gn@kriton.UUCP> from "Kriton Kyrimis" at Jun 20, 95 10:06:43 pm Content-Type: text Content-Length: 2070 From: hans@wyst.hobby.nl (Hans Verkuil) To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ixprefs update #1 Kriton, > I have modified the format in which ixprefs saves the configuration of > ixemul.library. The configuration is now saved in S:ixprefs, using an order > independent "option=value" format. You can even add comments by prefixing > lines with a "#". Thanks for the work you've put into this. But before you fix too many things I want to point out that, once Fred has finished merging all the ixemul.library sources, I have volunteered to go over the sources and 1) clean them up a bit, 2) reorganize the options used by the ixemul.library. Some options will disappear (e.g. ix_no_ces_then_open_console should probably be always on) but the main focus will be on the filename translation options. These options will be reduced to only one which selects whether a pathname of the form '/t' means volume 't' or the directory 't' in the parent directory. In other words: it selects whether the handling of the slash is Unix or Amiga like. Dots ('.' and '..') should always be interpreted in a Unix way. No need to change this (unless someone makes heavy use of filenames '.' and '..' ? :-). I will also make sure that this single option is honored throughout the library, which is not the case for the current options. The ix_translate_symlinks will also disappear: in the future all softlinks are written using AmigaDOS filenames in order to stay compatible with other AmigaDOS commands. Just to let you know. Oh, I advise that you add some version check to see whether your program is compatible with the user's ixemul.library. And I also propose that once your program is finished that it should be added to the ixemul.library distribution as the two are so closely linked together. Just as ixconfig is now. IMHO of course. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 09:14:25 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90716-3>; Thu, 22 Jun 1995 09:14:03 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA15044 (5.65b/CWI-3.3); Thu, 22 Jun 1995 08:13:42 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sOfEm-000FlRC; Thu, 22 Jun 95 07:55 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <083x@wyst.hobby.nl>; Thu, 22 Jun 95 00:02:54 CET Message-Id: <9506212302.083x@wyst.hobby.nl> Date: Thu, 22 Jun 1995 00:02:52 +0000 (CET) In-Reply-To: <9506202139.07gu@kriton.UUCP> from "Kriton Kyrimis" at Jun 20, 95 11:39:03 pm Content-Type: text Content-Length: 1864 From: hans@wyst.hobby.nl (Hans Verkuil) To: kyrimis@theseas.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ix_translate_symlinks bug? According to Kriton Kyrimis: > > I think that the ix_translate_symlinks flag of ixemul.library version 41.0 > works in the reverse way than the intended: > > When I set ix_translate_symlinks=1 and create a symbolic link to "..", > newlist reports that the link was made to the actual AmigaDOS file. > When I set ix_translate_symlinks=0, newlist reports that the list was made > to "..". Shouldn't this be the other way round? Um, don't try to understand this one. It was correct, but the name is highly confusing in the latest (41.0) version. In fact, this option should disappear in the near future and should always be set to OFF. When off, all softlinks are written in an AmigaDOS compatible format. When ON, the link is written verbatim and AmigaDOS gets very confused when presented with softlinks like '../t//./hello'. The translation referred to in the name of the option takes place deep in the bowels of the library, when it needs to resolve a softlink: at that point it needs to translate this to AmigaDOS format so that other Amiga functions understand it. However, if this option is turned off other translations are performed at other places in the library (namely from Unix format to AmigaDOS format and vice versa). Still confused? :-) Just remember to always turn this option OFF when using ixemul.library versions 40.6 and higher. However, as a consequence of this some older softlinks may become unusable, so you may have to create these again. But the advantages far outweigh this minor problem. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 09:47:35 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90503-4>; Thu, 22 Jun 1995 09:46:34 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id IAA12455; Thu, 22 Jun 1995 08:44:27 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id IAA30908; Thu, 22 Jun 1995 08:39:17 +0200 Date: Thu, 22 Jun 1995 08:39:17 +0200 From: Niklas Hallqvist Message-Id: <199506220639.IAA30908@linda.appli.se> To: fnf@amigalib.com CC: fleischr@izfm.uni-stuttgart.de, amiga-gcc-port@nic.funet.fi In-reply-to: (fnf@amigalib.com) Subject: Re: Problems with Ixemul 41.0 Fred> I'd really like a way to force the first 4 bytes to always be either Fred> the 32 bit form or a 16 bit instruction plus a nop. I wasn't able to Fred> quickly find a pseudo op that would force alignment of the next Fred> instruction to a 32 bit boundary. If anyone knows of one, please let Fred> me know ASAP. .align 2,VALUE might be possible to use. In old gas versions the value always was a byte, perhaps they now allow halfwords in some way. If so use 0x4c71 as it's the NOP value. Otherwise, find a 16-bit op with the form 0xXYXY where X and Y are hex digits, which doesn't clobber any important regs or branch, and use .align 2,XY Just an idea... Niklas From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 10:05:04 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90628-4>; Thu, 22 Jun 1995 10:04:02 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HS03UYPTA890P44Z@LEON.CTI.GR>; Thu, 22 Jun 1995 10:01:02 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA18683; Thu, 22 Jun 95 10:04:17 +0300 Date: Thu, 22 Jun 1995 10:04:16 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: ixprefs update #1 In-reply-to: <9506212240.083s@wyst.hobby.nl> from "Hans Verkuil" at Jun 21, 95 11:40:23 pm To: hans@wyst.hobby.nl (Hans Verkuil) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@theseas.ntua.gr Message-id: <9506220704.AA18683@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 1997 > Thanks for the work you've put into this. But before you fix too many > things I want to point out that, once Fred has finished merging all the > ixemul.library sources, I have volunteered to go over the sources and 1) > clean them up a bit, 2) reorganize the options used by the ixemul.library. Looks like it might be a good idea for me to wait a bit before releasing ixprefs, so that we don't end up with various incompatible versions of the same program. > Some options will disappear (e.g. ix_no_ces_then_open_console should I would be very reluctant to remove any existing options, given the way ixemul configuration programs currently work. This would be similar to removing obsolete entry points in a shared library--the well-known offsets would change and chaos would result. I would suggest either supporting them for the sake of compatibility, or ignoring them (this would allow for old configuration programs to work). > Oh, I advise that you add some version check to see whether your program is > compatible with the user's ixemul.library. And I also propose that once It already refuses to run for versions lower than 41. > your program is finished that it should be added to the ixemul.library > distribution as the two are so closely linked together. Just as ixconfig is > now. IMHO of course. I guess this should happen at some point--I'm even thinking of adding a CLI interface, so that we can merge ixconfig and ixprefs into one program. It might be a good idea if you could let me know when you've finished making the changes you'll be making (or in advance, if you want to test the changes using ixprefs), so that ixprefs and the cleaned-up version of ixemul.library can be released simultaneously (barring unforeseen difficulties, I think I can produce a new version within a couple of days). Thanks, -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If you can't stand the cold, stay out of the freezer!" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 12:08:46 1995 Received: from noc.BelWue.DE ([129.143.2.1]) by nic.funet.fi with SMTP id <90912-4>; Thu, 22 Jun 1995 12:03:39 +0300 Received: from sunserv.izfm.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA01257 (5.65c8/IDA-1.4.4 for ); Thu, 22 Jun 1995 11:03:30 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA29753; Thu, 22 Jun 95 11:03:29 +0200 From: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Message-Id: <9506220903.AA29753@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Problems with Ixemul 41.0 To: amiga-gcc-port@nic.funet.fi Date: Thu, 22 Jun 1995 11:03:29 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1716 > > > The other problem with ixemul 41 seems to happen while a child > > is returning from a vfork(). I will try to be more precise as soon > > as I found the cause of the problem. > > What is this "other problem". Is it fatal? > The other problem is causing a guru, too. It doesn't affect gcc itself but makes 'make' almost useless. It's caused by exactly the same 'feature' in gas (as I found yesterday): lea pc@(label),a5 compiles into the same wrong addressing mode. The 68000 then simply ignores the lea, executes the 32 bit offset 'label' and crashes the machine soon after. I'd recommend to replace the pc relative addressing (which is only used for speed and code size) by an absolute one as long as gas isn't fixed. Matthias *** include/machine/cpu.h.org Thu Jun 22 00:49:48 1995 --- include/machine/cpu.h Thu Jun 22 00:56:25 1995 *************** *** 124,126 **** FIXME: It is also uncertain if this file is even used. If so, this will error out. ! lea pc@(Lget_sr-.+2),a5 movel 4:w,a6 --- 124,126 ---- FIXME: It is also uncertain if this file is even used. If so, this will error out. ! lea Lget_sr-.+2,a5 | Never used movel 4:w,a6 *** library/machdep.c.org Thu Jun 22 00:50:03 1995 --- library/machdep.c Thu Jun 22 00:53:47 1995 *************** *** 495,497 **** movel a5,a0 ! lea pc@(Lget_sr),a5 movel 4:w,a6 --- 495,497 ---- movel a5,a0 ! lea Lget_sr,a5 movel 4:w,a6 *** library/trap.s.org Thu Jun 22 00:50:18 1995 --- library/trap.s Thu Jun 22 00:54:26 1995 *************** *** 475,477 **** moveml a5/a6,sp@- ! lea pc@(Lreset_fpu),a5 movel 4:w,a6 --- 475,477 ---- moveml a5/a6,sp@- ! lea Lreset_fpu,a5 movel 4:w,a6 From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 12:40:10 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <90691-1>; Thu, 22 Jun 1995 12:38:24 +0300 Received: by ceylon.informatik.uni-rostock.de id LAA17566; Thu, 22 Jun 1995 11:38:05 +0200 Received: by honshu.informatik.uni-rostock.de id LAA09037; Thu, 22 Jun 1995 11:38:03 +0200 From: Gunther Nikl Message-Id: <199506220938.LAA09037@honshu.informatik.uni-rostock.de> Subject: pure cc1 To: amiga-gcc-port@nic.funet.fi Date: Thu, 22 Jun 1995 11:38:03 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 334 Hi! Sometime ago someone requested that the gcc compilers should again be residentable. I doubt that this will ever be possible again, since that requires data+bss to fit into _64k_. Unfortunately with gcc 2.6.3 the data+bss part of the compilers exceed the 64k limit... Better forget the idea of pure compilers :( Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 12:44:41 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <90638-3>; Thu, 22 Jun 1995 12:44:15 +0300 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA05687; Thu, 22 Jun 1995 11:43:17 +0200 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA00857; Thu, 22 Jun 95 11:43:15 +0200 From: isthesin@TechFak.Uni-Bielefeld.DE (Stephan Thesing) Message-Id: <9506221143.ZM855@moos.TechFak.Uni-Bielefeld.DE> Date: Thu, 22 Jun 1995 11:43:15 +0200 In-Reply-To: Gunther Nikl "pure cc1" (Jun 22, 11:38) References: <199506220938.LAA09037@honshu.informatik.uni-rostock.de> X-Mailer: Z-Mail (2.1.5 09aug93) To: Gunther Nikl Subject: Re: pure cc1 Cc: amiga-gcc-port@nic.funet.fi On Jun 22, 11:38, Gunther Nikl wrote: > Subject: pure cc1 > > Hi! > > Sometime ago someone requested that the gcc compilers should again > be residentable. I doubt that this will ever be possible again, since > that requires data+bss to fit into _64k_. Unfortunately with gcc 2.6.3 > the data+bss part of the compilers exceed the 64k limit... > Better forget the idea of pure compilers :( > > Gunther >-- End of excerpt from Gunther Nikl But for MC68020+ there is a 32bit baserelative address mode, so we could do it again, if the compiler outputs correct assembler code and the assembler can handle the offsets..... Bye.... Stephan -- =============================================== = Stephan Thesing = = AG Praktische Informatik = = Technische Fakult"at = = Universit"at Bielefeld = = EMail: isthesin@techfak.uni-bielefeld.de = =---------------------------------------------= = Wer den Spruch erfunden hat : = = "So einfach, wie einem Kind den Lolly = = wegzunehmen", hat noch nie versucht, = = seinem Neffen ein Bonbon zu stibitzen. = =============================================== From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 12:46:04 1995 Received: from srv3.gbar.dtu.dk ([130.225.87.163]) by nic.funet.fi with ESMTP id <90905-4>; Thu, 22 Jun 1995 12:45:41 +0300 Received: by srv3.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun22.124541+0300_eet_dst.90905-4+14@nic.funet.fi> From: To: Date: Thu, 22 Jun 1995 12:45:37 +0300 Date: Thu, 22 Jun 1995 11:45:24 +0200 (METDST) From: Rask Lambertsen To: Gunther Nikl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: pure cc1 In-Reply-To: <199506220938.LAA09037@honshu.informatik.uni-rostock.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 22 Jun 1995, Gunther Nikl wrote: > Sometime ago someone requested that the gcc compilers should again > be residentable. I doubt that this will ever be possible again, since > that requires data+bss to fit into _64k_. Unfortunately with gcc 2.6.3 > the data+bss part of the compilers exceed the 64k limit... > Better forget the idea of pure compilers :( I'm not sure you are right. I think the DICE compiler is able to create residentable programs with data+bss exceeding 64 kb, so it must be possible. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 13:03:28 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90691-4>; Thu, 22 Jun 1995 13:02:16 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 22 Jun 95 11:59 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 22 Jun 95 11:54 MET DST Message-Id: Subject: re: pure cc1 To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 22 Jun 1995 11:54:12 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 372 A 64K limit ? i always tought that was a pc-problem ?? who does it ? (i am just courious) -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 13:18:36 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <90628-2>; Thu, 22 Jun 1995 13:15:01 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA15793 (5.65c-7/7.3w-FAU); Thu, 22 Jun 1995 12:09:24 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA12559 (5.x/7.3w-FAU); Thu, 22 Jun 1995 12:09:23 +0200 From: Tobias Ruland Message-Id: <9506221009.AA12559@immd8.informatik.uni-erlangen.de> Date: Thu, 22 Jun 1995 12:09:20 +0200 To: Walter Harms Cc: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Subject: re: pure cc1 In-Reply-To: References: Walter Harms writes: > A 64K limit ? i always tought that was a pc-problem ?? > who does it ? > (i am just courious) as far as i remember its because Bcc-offsets and (?) PC-relative offsets are of limited WORD width and a pure program may not use any absolute addressing :-) with kind regards tobias --------------------------------------------------------------------------- Tobias Ruland (student at Dept. of Artificial Intelligence, Univ. Erlangen) MAIL: tsruland@immd8.informatik.uni-erlangen.de (Please write in ENGLISH, GERMAN or FINNISH) WWW: http://www8.informatik.uni-erlangen.de/~tsruland From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 13:24:25 1995 Received: from srv3.gbar.dtu.dk ([130.225.87.163]) by nic.funet.fi with ESMTP id <90716-4>; Thu, 22 Jun 1995 13:23:40 +0300 Received: by srv3.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun22.132340+0300_eet_dst.90716-4+15@nic.funet.fi> From: To: Date: Thu, 22 Jun 1995 13:23:40 +0300 Date: Thu, 22 Jun 1995 12:23:20 +0200 (METDST) From: Rask Lambertsen To: Tobias Ruland Cc: Walter Harms , amiga gcc-list Subject: re: pure cc1 In-Reply-To: <9506221009.AA12559@immd8.informatik.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 22 Jun 1995, Tobias Ruland wrote: > > Walter Harms writes: > > A 64K limit ? i always tought that was a pc-problem ?? > > who does it ? > > (i am just courious) > > as far as i remember its because Bcc-offsets and (?) PC-relative offsets > are of limited WORD width and a pure program may not use any absolute > addressing :-) Absolute addressing like global variables? The DICE compiler has no problem generating pure programs with global variables, so why shouldn't gcc be able to do it? Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 13:33:46 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <88982-2>; Thu, 22 Jun 1995 13:32:42 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA26234 (5.65c-7/7.3w-FAU); Thu, 22 Jun 1995 12:32:06 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA12668 (5.x/7.3w-FAU); Thu, 22 Jun 1995 12:32:05 +0200 From: Tobias Ruland Message-Id: <9506221032.AA12668@immd8.informatik.uni-erlangen.de> Date: Thu, 22 Jun 1995 12:32:02 +0200 To: isthesin@TechFak.Uni-Bielefeld.DE (Stephan Thesing) Cc: amiga-gcc-port@nic.funet.fi Subject: Re: pure cc1 Stephan Thesing writes: > The reason is that the MC68000-68012 CPUs have an addressing mode > called 'base register with displacement' this is needed for pure > programs, so they can have their own data segment. > Data is addressed relative to a base register (mostly A4) and > the problem is that MC68000-68012 CPUs the offset has to be 16bit, i.e. > from -32768 to 32767. So only 64kB of global data (and this is > what we speak about) can be accessed. > The MC68020+ CPUs have an extended address mode with 32bit offset and there > is no limit on the size of the global data anymore. aha! now yet another magic amiga computing mystery was solved :-) thnx stephan. with kind regards tobias btw: are there ANY 68000 amigas using gcc??? it's even horribly slow on my good old 68030... so who could USE it on 68000? --------------------------------------------------------------------------- Tobias Ruland (student at Dept. of Artificial Intelligence, Univ. Erlangen) MAIL: tsruland@immd8.informatik.uni-erlangen.de (Please write in ENGLISH, GERMAN or FINNISH) WWW: http://www8.informatik.uni-erlangen.de/~tsruland From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 13:37:40 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <89070-4>; Thu, 22 Jun 1995 13:37:07 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA02078; Thu, 22 Jun 1995 11:36:50 +0100 Date: Thu, 22 Jun 1995 11:35:38 +0100 (BST) From: Peter Ivimey-Cook To: Tobias Ruland Cc: amiga-gcc-port@nic.funet.fi Subject: Re: pure cc1 In-Reply-To: <9506221032.AA12668@immd8.informatik.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 22 Jun 1995, Tobias Ruland wrote: > > btw: are there ANY 68000 amigas using gcc??? it's even horribly slow on > my good old 68030... so who could USE it on 68000? > I do, and so do several others I know of. And yes - it's sloe and painful, but it works (mostly :-) and has a decent environment (thanks everyone) and is free! So please don't remove 68000 support - it's still wanted. Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 13:39:08 1995 Received: from gryzmak.pdi.lodz.pl ([193.59.40.129]) by nic.funet.fi with SMTP id <89353-2>; Thu, 22 Jun 1995 13:38:38 +0300 Received: (from robert@localhost) by gryzmak.pdi.lodz.pl (8.6.10/1.34) id MAA08728; Thu, 22 Jun 1995 12:38:09 +0200 Date: Thu, 22 Jun 1995 12:38:06 +0200 (MET DST) From: Robert Ramiega To: gcc mailing list Subject: Off topic (VMM and Readme 2.6.3) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! Today i downloaded again some parts of gcc 2.6.3 distribution. Among them i donloaded gcc263-readme.lha (from funet). When read throu README-2.6.3 i found that it mentions VMM40. Is VMM 4.0 out? Last version i can find on Aminet is VMM 3.1... Can someone explain this to me? regards Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://www.pdi.lodz.pl/~robert | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 13:39:29 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <89469-4>; Thu, 22 Jun 1995 13:38:56 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA28773 (5.65c-7/7.3w-FAU); Thu, 22 Jun 1995 12:38:24 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA12735 (5.x/7.3w-FAU); Thu, 22 Jun 1995 12:38:23 +0200 From: Tobias Ruland Message-Id: <9506221038.AA12735@immd8.informatik.uni-erlangen.de> Date: Thu, 22 Jun 1995 12:38:20 +0200 To: isthesin@TechFak.Uni-Bielefeld.DE (Stephan Thesing) Subject: Re: pure cc1 Cc: amiga-gcc-port@nic.funet.fi Stephan Thesing writes: > > btw: are there ANY 68000 amigas using gcc??? it's even horribly slow on > > my good old 68030... so who could USE it on 68000? > > > Well, nobody, but some people might want to use programs compiled > by gcc :-))))) if my brain works correctly (i'm not sure about that) the original question was to make GCC pure (and not all programs compiled using gcc). if there are no 68000 amigas using gcc it could be made pure for 68020/30/40 processors only. best regards tobias From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 13:43:50 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <88923-1>; Thu, 22 Jun 1995 13:42:54 +0300 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA06522; Thu, 22 Jun 1995 12:42:44 +0200 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA00954; Thu, 22 Jun 95 12:42:43 +0200 From: isthesin@TechFak.Uni-Bielefeld.DE (Stephan Thesing) Message-Id: <9506221242.ZM952@moos.TechFak.Uni-Bielefeld.DE> Date: Thu, 22 Jun 1995 12:42:43 +0200 In-Reply-To: Tobias Ruland "Re: pure cc1" (Jun 22, 12:38) References: <9506221038.AA12735@immd8.informatik.uni-erlangen.de> X-Mailer: Z-Mail (2.1.5 09aug93) To: Tobias Ruland Subject: Re: pure cc1 Cc: amiga-gcc-port@nic.funet.fi On Jun 22, 12:38, Tobias Ruland wrote: > Subject: Re: pure cc1 > > Stephan Thesing writes: > > > btw: are there ANY 68000 amigas using gcc??? it's even horribly slow on > > > my good old 68030... so who could USE it on 68000? > > > > > Well, nobody, but some people might want to use programs compiled > > by gcc :-))))) > > if my brain works correctly (i'm not sure about that) the original question > was to make GCC pure (and not all programs compiled using gcc). if there are > no 68000 amigas using gcc it could be made pure for 68020/30/40 processors > only. > > best regards > > tobias >-- End of excerpt from Tobias Ruland Ooops, yes should have gone to bed earlier or drunk more coffee this morning....... Hmmm....Could we persuade gcc to generate different output for different target machines? I.e. for =mc68020 generate 32bit, if requested by another option? Bye.... Stephan -- =============================================== = Stephan Thesing = = AG Praktische Informatik = = Technische Fakult"at = = Universit"at Bielefeld = = EMail: isthesin@techfak.uni-bielefeld.de = =---------------------------------------------= = Wer den Spruch erfunden hat : = = "So einfach, wie einem Kind den Lolly = = wegzunehmen", hat noch nie versucht, = = seinem Neffen ein Bonbon zu stibitzen. = =============================================== From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 13:48:41 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <89027-1>; Thu, 22 Jun 1995 13:47:53 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA02783 (5.65c-7/7.3w-FAU); Thu, 22 Jun 1995 12:46:53 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA12853 (5.x/7.3w-FAU); Thu, 22 Jun 1995 12:46:52 +0200 From: Tobias Ruland Message-Id: <9506221046.AA12853@immd8.informatik.uni-erlangen.de> Date: Thu, 22 Jun 1995 12:46:50 +0200 To: Peter Ivimey-Cook Cc: amiga-gcc-port@nic.funet.fi Subject: Re: pure cc1 Peter Ivimey-Cook writes: > > btw: are there ANY 68000 amigas using gcc??? it's even horribly slow on > > my good old 68030... so who could USE it on 68000? > > > I do, and so do several others I know of. And yes - it's sloe and > painful, but it works (mostly :-) and has a decent environment (thanks > everyone) and is free! > > So please don't remove 68000 support - it's still wanted. peter, i'm admiring you! :-) or is there any 68000 120MHz version out that i dont know anything of??? :-) best regards tobias --------------------------------------------------------------------------- Tobias Ruland (student at Dept. of Artificial Intelligence, Univ. Erlangen) MAIL: tsruland@immd8.informatik.uni-erlangen.de (Please write in ENGLISH, GERMAN or FINNISH) WWW: http://www8.informatik.uni-erlangen.de/~tsruland From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 14:02:05 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89132-3>; Thu, 22 Jun 1995 14:01:16 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 22 Jun 1995 12:50:36 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA06030; Thu, 22 Jun 95 12:50:29 +0200 Date: Thu, 22 Jun 95 12:50:29 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9506221050.AA06030@inf-wiss.uni-konstanz.de> To: tsruland@immd8.informatik.uni-erlangen.de Subject: Re: pure cc1 Cc: amiga-gcc-port@nic.funet.fi From: Tobias Ruland > btw: are there ANY 68000 amigas using gcc??? it's even horribly slow on > my good old 68030... so who could USE it on 68000? Sometimes the question is not if it's slow, but if they get the work done, even if it's over night. My old 68000 with 5MB RAM can still do almost anything my A4000 can do, as long as people keep compiling 68000 programs. Of course, this wouldn't prevent the GCC people from saying "only the 68020+ GCC is residentable". Joerg. From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 14:02:33 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <88992-2>; Thu, 22 Jun 1995 14:01:22 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 22 Jun 1995 12:53:54 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA06042; Thu, 22 Jun 95 12:53:50 +0200 Date: Thu, 22 Jun 95 12:53:50 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9506221053.AA06042@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@nic.funet.fi, robert@pdi.lodz.pl Subject: Re: Off topic (VMM and Readme 2.6.3) From: Robert Ramiega > README-2.6.3 i found that it mentions VMM40. Is VMM 4.0 out? Last version > i can find on Aminet is VMM 3.1... Can someone explain this to me? VMM40 was VMM's name as long as it was 68040 only, i.e. before it was made to work with 68030 processors. Then came the name change, VMM 2.x and VMM 3.x. Joerg Hoehle hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 14:03:07 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <89349-4>; Thu, 22 Jun 1995 14:00:51 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA07891 (5.65c-7/7.3w-FAU); Thu, 22 Jun 1995 12:59:35 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA13135 (5.x/7.3w-FAU); Thu, 22 Jun 1995 12:59:34 +0200 From: Tobias Ruland Message-Id: <9506221059.AA13135@immd8.informatik.uni-erlangen.de> Date: Thu, 22 Jun 1995 12:59:31 +0200 To: amiga-gcc-port@nic.funet.fi Subject: Yet Another VMM Question BTW: some days ago i tried to install the latest (available) version of VMM. after i got all necessary libs and stuff together i was able to start up the prefs window, change some preferences and so on. but when i closed the VMM prefs window to get VMM work, i got an error message like "sorry, could not load VMM" and plop. can anyone imagine the reason for that "ERROR: something is wrong"-type message?? has anyone have had that message too and found the problem? thnx tobias --------------------------------------------------------------------------- Tobias Ruland (student at Dept. of Artificial Intelligence, Univ. Erlangen) MAIL: tsruland@immd8.informatik.uni-erlangen.de (Please write in ENGLISH, GERMAN or FINNISH) WWW: http://www8.informatik.uni-erlangen.de/~tsruland From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 14:05:54 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89644-4>; Thu, 22 Jun 1995 14:05:20 +0300 Received: by colombo.telesys-innov.fr; Thu, 22 Jun 1995 13:05:13 +0100 From: Philippe BRAND Message-Id: <199506221205.NAA23836@colombo.telesys-innov.fr> Subject: Re: Off topic (VMM and Readme 2.6.3) To: robert@pdi.lodz.pl (Robert Ramiega) Date: Thu, 22 Jun 1995 13:05:11 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Robert Ramiega" at Jun 22, 95 12:38:06 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 508 Robert Ramiega writes: > Today i downloaded again some parts of gcc 2.6.3 distribution. Among > them i donloaded gcc263-readme.lha (from funet). When read throu > README-2.6.3 i found that it mentions VMM40. Is VMM 4.0 out? Last version > i can find on Aminet is VMM 3.1... Can someone explain this to me? Error. Read: 3.1 -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 14:30:34 1995 Received: from srv3.gbar.dtu.dk ([130.225.87.163]) by nic.funet.fi with ESMTP id <90711-3>; Thu, 22 Jun 1995 14:29:11 +0300 Received: by srv3.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jun22.142911+0300_eet_dst.90711-3+26@nic.funet.fi> From: To: Date: Thu, 22 Jun 1995 14:29:10 +0300 Date: Thu, 22 Jun 1995 13:27:13 +0200 (METDST) From: Rask Lambertsen To: Tobias Ruland Cc: Stephan Thesing , amiga-gcc-port@nic.funet.fi Subject: Re: Is gcc used on 68000? (Was: Re: pure cc1) In-Reply-To: <9506221032.AA12668@immd8.informatik.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 22 Jun 1995, Tobias Ruland wrote: > btw: are there ANY 68000 amigas using gcc??? it's even horribly slow on > my good old 68030... so who could USE it on 68000? I use gcc on my 7.09 MHz 68000 based Amiga 500. It's not slow enough to be unusable. Regards, ___________________________________________________________________________ / \ | Rask Ingemann Lambertsen or | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \___________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 15:32:59 1995 Received: from cony.gsf.de ([146.107.1.2]) by nic.funet.fi with SMTP id <90909-3>; Thu, 22 Jun 1995 15:30:21 +0300 Received: from lulu.gsf.de by cony.gsf.de (8.6.4.2/Arcane-3.00) id OAA04366; Thu, 22 Jun 1995 14:24:26 +0200 Received: by lulu.gsf.de (931110.SGI/930416.SGI) for @cony.gsf.de:amiga-gcc-port@nic.funet.fi id AA19295; Thu, 22 Jun 95 14:20:58 +0200 From: "Wolfgang Baudler" Message-Id: <9506221420.ZM19293@lulu.gsf.de> Date: Thu, 22 Jun 1995 14:20:57 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: amiga-gcc-port@nic.funet.fi Subject: Unsubscribe? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Excuse me for beeing off-topic, but can somebody please tell me how to unsubscribe from the amiga-gcc-list or how to get a list of the subscribed people? Thank you very much. W. Baudler From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 16:37:34 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90534-2>; Thu, 22 Jun 1995 16:35:17 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sOnLX-0004nYC; Thu, 22 Jun 95 07:35 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ixprefs update #1 To: kyrimis@theseas.ntua.gr Date: Thu, 22 Jun 1995 07:35:06 -0700 (MST) Cc: hans@wyst.hobby.nl, amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi (ixemul.library maintainers) In-Reply-To: <9506220704.AA18683@hpcl.cti.gr> from "Kriton Kyrimis" at Jun 22, 95 10:04:16 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1824 > Looks like it might be a good idea for me to wait a bit before releasing > ixprefs, so that we don't end up with various incompatible versions of the > same program. As long as ixprefs verifies that the version of ixemul.library that it is controlling is compatible, and it ignores any options in the prefs files that it doesn't understand (in the case the an older ixprefs is used with a prefs file for a newer library), then I don't see any need to wait to release it. > > your program is finished that it should be added to the ixemul.library > > distribution as the two are so closely linked together. Just as ixconfig is > > now. IMHO of course. > > I guess this should happen at some point--I'm even thinking of adding a CLI > interface, so that we can merge ixconfig and ixprefs into one program. I agree 100%. The only catch is that it should be buildable using gcc, since that is what I use to compile the entire GNU tree, including ixemul. > It might be a good idea if you could let me know when you've finished making > the changes you'll be making (or in advance, if you want to test the changes > using ixprefs), so that ixprefs and the cleaned-up version of ixemul.library > can be released simultaneously (barring unforeseen difficulties, I think I > can produce a new version within a couple of days). I will be tied up with a couple CD-ROM projects (FantaSeas and FrozenFish PC) for the next couple of weeks, and then FreshFish 10 for another week or so, so I won't be able to do any more significant merging for at least another 2-3 weeks. After that, I hope to finish up the merging within a couple weeks. So the target is to have all the major changes done to ixemul by the end of July. Of course I will still be applying patches for bugs fixes and other improvements as they come in. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 17:12:28 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90712-4>; Thu, 22 Jun 1995 17:09:47 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sOntH-0004nYC; Thu, 22 Jun 95 08:09 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Problems with Ixemul 41.0 To: niklas@appli.se (Niklas Hallqvist) Date: Thu, 22 Jun 1995 08:09:58 -0700 (MST) Cc: fnf@amigalib.com, fleischr@izfm.uni-stuttgart.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <199506220639.IAA30908@linda.appli.se> from "Niklas Hallqvist" at Jun 22, 95 08:39:17 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 976 > .align 2,VALUE might be possible to use. In old gas versions the > value always was a byte, perhaps they now allow halfwords in some way. Nope, seems to still be just a byte. At least trying 0x1234 only gave a fill of 0x3434. > If so use 0x4c71 as it's the NOP value. Otherwise, find a 16-bit op > with the form 0xXYXY where X and Y are hex digits, which doesn't > clobber any important regs or branch, and use .align 2,XY Since the first instruction will branch around the fill, it doesn't seem to matter a lot what fill pattern we use. I'm leaning towards a trap instruction (0x4E4E) unless someone else thinks of a more interesting one. This way I can check for the patterns 6000 XXXX XXXX 0107 60XX 4E4E XXXX 0107 of course I could always just simplify this to: 60XX XXXX XXXX 0107 which is probably good enough. Thanks for pointing out the .align instruction. I tried it and hex dumped the object file, and it seemed to do exactly what we need. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 17:50:09 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90168-3>; Thu, 22 Jun 1995 17:48:33 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 22 Jun 95 16:45 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 22 Jun 95 16:39 MET DST Message-Id: Subject: Re: Problems with Ixemul 41.0 (fwd) To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 22 Jun 1995 16:39:06 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 720 > Since the first instruction will branch around the fill, it doesn't > seem to matter a lot what fill pattern we use. I'm leaning towards > a trap instruction (0x4E4E) unless someone else thinks of a more > interesting one. > i would use ILLEGAL (0x4e7E, or so) it is a defined trap on all 68k systems an can not interfere with a somewhere defined TRAP , i never used it myself but its not forbidden so someone else may do. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 18:15:23 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <89055-4>; Thu, 22 Jun 1995 18:13:45 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id RAA21750; Thu, 22 Jun 1995 17:07:59 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id RAA01138; Thu, 22 Jun 1995 17:06:03 +0200 Date: Thu, 22 Jun 1995 17:06:03 +0200 From: Niklas Hallqvist Message-Id: <199506221506.RAA01138@linda.appli.se> To: Walter.Harms@arbi.informatik.uni-oldenburg.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Walter Harms on Thu, 22 Jun 1995 16:39:06 +0200 (MET DST)) Subject: Re: Problems with Ixemul 41.0 (fwd) >>>>> "Walter" == Walter Harms writes: >> Since the first instruction will branch around the fill, it doesn't >> seem to matter a lot what fill pattern we use. I'm leaning towards >> a trap instruction (0x4E4E) unless someone else thinks of a more >> interesting one. >> Walter> i would use ILLEGAL (0x4e7E, or so) it is a defined Walter> trap on all 68k systems an can not interfere with a somewhere Walter> defined TRAP , i never used it myself but its not forbidden so Walter> someone else may do. The point is that the instruction must have both bytes equal, as the .align directive fills every *byte* with the same value. However, as the jump is past this instruction, I would even ignore what gas fills the space with, and just use: .align 2 Niklas From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 18:27:44 1995 Received: from mailgate.ericsson.se ([130.100.2.2]) by nic.funet.fi with SMTP id <89270-3> convert rfc822-to-8bit; Thu, 22 Jun 1995 18:26:06 +0300 Received: from eds05.ericsson.se (eds05.ericsson.se [136.225.9.2]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id RAA20249 for ; Thu, 22 Jun 1995 17:25:53 +0200 Received: from DECNET-MAIL by edt.ericsson.se (PMDF V4.3-10 #7344) id <01HS0JERNQ8W8WX1ZX@edt.ericsson.se>; Thu, 22 Jun 1995 17:26:05 +0200 Date: Thu, 22 Jun 1995 17:26:05 +0200 From: LE DU DENIS Subject: gcc To: amiga-gcc-port@nic.funet.fi Message-id: <01HS0JERO9JM8WX1ZX@edt.ericsson.se> X-Envelope-to: amiga-gcc-port@nic.funet.fi X-VMS-To: IN%"amiga-gcc-port@nic.funet.fi" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT hello all i'm having a big trouble with gcc263 i have installed it on my amiga1200 the first time and configure it manually but then i got gccinstall which install automatically all before installing it with gccinstall i could compile but now i'm having a big trouble here's what i try to compil (i'm a beginner) \include main() éprintf"hello world\n"); \ then for compiling : gcc -o hello hello.c and as an answer cpp the macro compiler answers : cpp \§ input output it seems that the order of the entry and output file is inversed between gcc and cpp any idea!! thanks From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 22:39:16 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89023-1>; Thu, 22 Jun 1995 22:37:17 +0300 Received: by theseas.ntua.gr with UUCP; Thu, 22 Jun 1995 22:40:03 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07j1@kriton.UUCP>; Thu, 22 Jun 95 22:31:19 EET Date: Thu, 22 Jun 95 22:31:19 EET Message-Id: <9506222031.07j1@kriton.UUCP> X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 550 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: ixprefs 1.0 uploaded to aminet I just uploaded ixprefs 1.0 on wuarchive. It should soon appear on an aminet site near you, in dev/gcc/ixprefs1.0.lha. This version will only run under version 41.0 or higher of ixemul.library. In addition, if the library version is *not* 41.0, ixprefs will ask for confirmation before proceeding. Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "It may be irrational of me, but human beings are quite my favourite species." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Jun 22 22:39:35 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <88991-4>; Thu, 22 Jun 1995 22:38:20 +0300 Received: by theseas.ntua.gr with UUCP; Thu, 22 Jun 1995 22:40:03 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07iw@kriton.UUCP>; Thu, 22 Jun 95 20:54:55 EET Date: Thu, 22 Jun 95 20:54:55 EET Message-Id: <9506221854.07iw@kriton.UUCP> In-Reply-To: (from fnf@amigalib.com (Fred Fish)) (at Thu, 22 Jun 1995 07:35:06 -0700 (MST)) X-Mailer: //\\miga Electronic Mail (AmiElm 6.24) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1876 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: fnf@amigalib.com Cc: amiga-gcc-port@lists.funet.fi Subject: Re: ixprefs update #1 Hi Fred (Fred Fish), in on Jun 22 you wrote: > As long as ixprefs verifies that the version of ixemul.library that it > is controlling is compatible, and it ignores any options in the prefs The current version of ixprefs checks to see if ixemul.library is version 41, refusing to run otherwise. It would be nice if someone could tell me from which *future* version onwards (41.1? 42.0?) the library will become incompatible, I will feel comfortable in releasing ixprefs. Meanwhile, I'll put up a warning requester if the version of ixemul.library is higher than 41.0, and upload ixprefs to aminet to get some feedback. > files that it doesn't understand (in the case the an older ixprefs is > used with a prefs file for a newer library), then I don't see any need > to wait to release it. Ixprefs already ignores any options it does not understand, popping up a requester for each unknown option. > > I guess this should happen at some point--I'm even thinking of adding a CLI > > interface, so that we can merge ixconfig and ixprefs into one program. > > I agree 100%. The only catch is that it should be buildable using > gcc, since that is what I use to compile the entire GNU tree, > including ixemul. To paraphrase a question recently posted to the amiga gcc list, what's the point of building an ixemul client if you don't use gcc? (Yes, I *am* using gcc to build ixprefs.) To add a CLI interface, we need to decide whether it will be UNIX-style or Amiga-style. If we decide on an Amiga-style interface, I would appreciate suggestions for the names of the command line options. Thanks, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "It may be irrational of me, but human beings are quite my favourite species." ----- From amiga-gcc-port-owner@nic.funet.fi Fri Jun 23 09:09:37 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90400-2>; Fri, 23 Jun 1995 09:07:26 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sP2pi-0004nYC; Fri, 23 Jun 95 00:07 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Problems with Ixemul 41.0 To: fleischr@izfm.uni-stuttgart.de (Matthias Fleischer) Date: Fri, 23 Jun 1995 00:07:18 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi (ixemul.library maintainers) In-Reply-To: <9506220903.AA29753@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Jun 22, 95 11:03:29 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 788 > The other problem is causing a guru, too. It doesn't affect > gcc itself but makes 'make' almost useless. It's caused by > exactly the same 'feature' in gas (as I found yesterday): > > lea pc@(label),a5 > > compiles into the same wrong addressing mode. The 68000 then > simply ignores the lea, executes the 32 bit offset 'label' > and crashes the machine soon after. > I'd recommend to replace the pc relative addressing (which is only > used for speed and code size) by an absolute one as long as gas > isn't fixed. I applied your patches, rebuilt ixemul.library, and tested it on an Amiga 2000. It now seems to work fine. Thanks much for the fixes. I will do a little more testing when I return from a trip on Monday, and hopefully release 41.1 by Wednesday or Thursday. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Jun 23 11:39:07 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <90746-4>; Fri, 23 Jun 1995 11:37:13 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA13723; Fri, 23 Jun 1995 10:28:07 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9506230828.AA13723@decap2.zdv.uni-tuebingen.de> Subject: Re: gcc To: met.metdlu@memo.ericsson.se (LE DU DENIS) Date: Fri, 23 Jun 1995 10:28:06 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <01HS0JERO9JM8WX1ZX@edt.ericsson.se> from "LE DU DENIS" at Jun 22, 95 05:26:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 580 Hello, > i have installed it on my amiga1200 the first time and configure > it manually > but then i got gccinstall which install automatically all > before installing it with gccinstall i could compile > but now i'm having a big trouble This sound very much to me like you are using an older version of the installer script, which had a nasty bug. The current version (Aminet or linus.zdv.uni-tuebingen.de, incoming/Amiga) should fix this problem, as far as I know. It it doesn't, please contact me directly, so that we can find the reason for the problem. Thanks, Jochen From amiga-gcc-port-owner@nic.funet.fi Fri Jun 23 17:51:21 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90500-2>; Fri, 23 Jun 1995 17:47:07 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id QAA26081; Fri, 23 Jun 1995 16:49:00 +0200 Date: Fri, 23 Jun 1995 16:48:58 +0200 (MET DST) From: Kamil Iskra Subject: GCC 2.7.0 BETA To: amiga-gcc-port@nic.funet.fi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have found a small bug in the latest version of gcc (it's possible that it existed in earlier versions, as well). I have "GCCPRIORITY" environment variable set to "-1". "gcc" changes priority well, but does not preserve original priority and when exits simply lives Shell with priority "-1"... Except for this, new gcc seems to work fine on my Amiga. I created a simple test for "-resident" option and it worked fine. However, I had some ocassional crashes a few times when I was having fun with "-resident", but I couldn't reproduct them or track them down, so maybe this was just a coinsidence... / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Jun 23 18:11:30 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <88917-2>; Fri, 23 Jun 1995 18:09:28 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HS1Z4SD67490OXBY@LEON.CTI.GR>; Fri, 23 Jun 1995 18:07:17 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA23499; Fri, 23 Jun 95 18:10:02 +0300 Date: Fri, 23 Jun 1995 18:10:01 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: GCC 2.7.0 BETA In-reply-to: from "Kamil Iskra" at Jun 23, 95 04:48:58 pm To: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@theseas.ntua.gr Message-id: <9506231510.AA23499@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 765 > I have found a small bug in the latest version of gcc (it's possible that > it existed in earlier versions, as well). I have "GCCPRIORITY" > environment variable set to "-1". "gcc" changes priority well, but does > not preserve original priority and when exits simply lives Shell with > priority "-1"... Changing the priority of a process started from the CLI changes the priority of the invoking CLI (it is the same process). Programs changing their own priority should therefore restore their priority before exiting. (I know this from personal experience :-( ). -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Well, I just put 1.795372 and 2.204628 together." "And what does *that* mean?" "Four!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Jun 23 18:24:37 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89208-2>; Fri, 23 Jun 1995 18:23:15 +0300 Received: by colombo.telesys-innov.fr; Fri, 23 Jun 1995 17:18:44 +0100 From: Philippe BRAND Message-Id: <199506231618.RAA06507@colombo.telesys-innov.fr> Subject: Re: GCC 2.7.0 BETA To: kyrimis@theseas.ntua.gr Date: Fri, 23 Jun 1995 17:18:43 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9506231510.AA23499@hpcl.cti.gr> from "Kriton Kyrimis" at Jun 23, 95 06:10:01 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 486 Kriton Kyrimis writes: > Changing the priority of a process started from the CLI changes the priority > of the invoking CLI (it is the same process). Programs changing their own > priority should therefore restore their priority before exiting. (I know this > from personal experience :-( ). I'll fix it. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Jun 23 19:34:38 1995 Received: from eeyore.INS.CWRU.Edu ([129.22.8.17]) by nic.funet.fi with ESMTP id <88934-4>; Fri, 23 Jun 1995 19:32:35 +0300 Received: (cz253@localhost) by eeyore.INS.CWRU.Edu (8.6.10+cwru/CWRU-2.1-bsdi) id MAA04416; Fri, 23 Jun 1995 12:26:34 -0400 (from cz253) Message-Id: <199506231626.MAA04416@eeyore.INS.CWRU.Edu> Date: Fri, 23 Jun 1995 12:26:34 -0400 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: tsruland@immd8.informatik.uni-erlangen.de Subject: Re: pure cc1 Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from tsruland@immd8.informatik.uni-erlangen.de of Thu, 22 Jun >btw: are there ANY 68000 amigas using gcc??? it's even horribly slow on >my good old 68030... so who could USE it on 68000? Sure there are. :-) It may be slow, but still gets the job done. .....Dave From amiga-gcc-port-owner@nic.funet.fi Sat Jun 24 14:29:18 1995 Received: from dfunms.rus.uni-stuttgart.de ([129.69.1.162]) by nic.funet.fi with SMTP id <90400-4>; Sat, 24 Jun 1995 14:27:26 +0300 Received: from ifr1.luftfahrt.uni-stuttgart.de by dfunms.rus.uni-stuttgart.de with SMTP id AA19833 (5.65c8/DFUE-M1.0 for ); Sat, 24 Jun 1995 13:27:18 +0200 Received: from ifr17 by ifr1.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-1.0NeXT+) id AA18029; Sat, 24 Jun 95 13:27:16 +0200 Message-Id: <9506241127.AA18029@ifr1.Luftfahrt.Uni-Stuttgart.DE> Received: by ifr17.Luftfahrt.Uni-Stuttgart.DE (NX5.67d/BelWue-S1.0NeXT+) id AA01371; Sat, 24 Jun 95 13:27:15 +0200 Date: Sat, 24 Jun 95 13:27:15 +0200 From: raimund@ifr.luftfahrt.uni-stuttgart.de Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: amiga-gcc-port@nic.funet.fi Subject: problems with ixemul41.0 on 68030 & 68881 Hi, I have installed ixemul 41 over my current installation of gcc2.6.3 from FreshFish CD 9. I choose the 030fpu library since I have this combination. Everything is okay if I compile only for plain 68000 code. But when I try to compile for 68030 or 68882 I got some error messages. Here is an easy sample program: /* sintest.c */ #include main() { double x; x = sin(0.5*PI); printf ("\n\t %f\n",x); } Compiling for 68030: gcc -v -o sintest -m68030 sintest.c Reading specs from /gnu/lib/gcc-lib/amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/amigados/2.6.3/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Dmc68030 sintest.c t:cc879904.i GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/amigados/include /gnu/lib/gcc-lib/amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/amigados/2.6.3/cc1 t:cc879904.i -quiet -dumpbase sintest.c -m68030 -version -o t:cc879904.s GNU C version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3. as -mc68030 -o t:cc8799041.o t:cc879904.s ld -fl libm020 -o sintest /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/amigados/2.6.3 -L/local/lib/gcc-lib/amigados/2.6.3 -L/gnu/lib -L/local/lib -L/local/lib t:cc8799041.o -lgcc -lc -lamiga -lc -lgcc /gnu/lib/crt0.o: Undefined symbol ___SaveSP referenced from text segment /gnu/lib/crt0.o: Undefined symbol ___init_stk referenced from text segment If I compile for m68881 I get a different message: gcc -v -o sintest -m68881 sintest.c Reading specs from /gnu/lib/gcc-lib/amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/amigados/2.6.3/cpp -lang-c -v -undef -D__GNUC__=2-D__GNUC_ MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__ amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__ amigados -D__MCH_AMIGA -D__AMIGA -D__HAVE_68881__ -Dmc68010 sintest.c t:cc879 904.i GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/amigados/include /gnu/lib/gcc-lib/amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/amigados/2.6.3/cc1 t:cc879904.i -quiet -dumpbase sintest.c -m68881 -version -o t:cc879904.s GNU C version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3. as -mc68010 -o t:cc8799041.o t:cc879904.s t:cc879904.s: Assembler messages: t:cc879904.s:31: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/68882) -- statement `fmoved a5@(8),fp0' ignored t:cc879904.s:33: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/68882) -- statement `fsinx fp0,fp1' ignored t:cc879904.s:35: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/68882) -- statement `fmoved fp1,a5@(-8)' ignored If I compile for 68030 and 68881 I get the same message as compiling only for 68030. What is wrong? Is the ixemul 41.0 not intended to work with 2.6.3? I tried it with Gnat 2.03 and G77 too and no errors occured. Did I install anything wrong? Thanks Raimund From amiga-gcc-port-owner@nic.funet.fi Sun Jun 25 00:49:48 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <89670-2>; Sun, 25 Jun 1995 00:47:20 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <190183>; Sat, 24 Jun 1995 23:46:52 +0200 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA13622; Sat, 24 Jun 1995 23:46:41 +0200 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9506242146.AA13622@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: problems with ixemul41.0 on 68030 & 68881 To: raimund@ifr.luftfahrt.uni-stuttgart.de Date: Sat, 24 Jun 1995 23:46:41 +0200 Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9506241127.AA18029@ifr1.Luftfahrt.Uni-Stuttgart.DE> from "raimund@ifr.luftfahrt.uni-stuttgart.de" at Jun 24, 95 01:27:15 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 788 > > > Hi, > > I have installed ixemul 41 over my current installation of > gcc2.6.3 from FreshFish CD 9. I choose the 030fpu library since > I have this combination. Everything is okay if I compile > only for plain 68000 code. But when I try to compile for 68030 or > 68882 I got some error messages. [...] > /gnu/lib/crt0.o: Undefined symbol ___SaveSP referenced from text > segment > /gnu/lib/crt0.o: Undefined symbol ___init_stk referenced from text > segment It seems Fred Fish only has supplied the 68000 libs with his ixemul, so the 68030 libc.a is missing. I am using currently a dummy lib to fix this, i.e void __SaveSP() { return; } void __init_stk() { return; } Please read Kritons mail on this problem, as his solution is maybe the better on ;) Thomas From amiga-gcc-port-owner@nic.funet.fi Sun Jun 25 19:46:48 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89081-3>; Sun, 25 Jun 1995 19:43:39 +0300 Received: by theseas.ntua.gr with UUCP; Sun, 25 Jun 1995 19:46:12 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07kh@kriton.UUCP>; Sun, 25 Jun 95 19:41:17 EET Date: Sun, 25 Jun 95 19:41:17 EET Message-Id: <9506251741.07kh@kriton.UUCP> In-Reply-To: <9506242146.AA13622@nereid.rz.Uni-Osnabrueck.DE> (from thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke)) (at Sat, 24 Jun 1995 23:46:41 +0200) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 580 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: Re: problems with ixemul41.0 on 68030 & 68881 > Please read Kritons mail on this problem, as his solution is maybe > the better on ;) Which solution, for those like me who don't archive their mail, was to delete the old files from libm020, namely libc.a, crt0.o, bcrt0.o, and rcrt0.o, to force the linker to use the 68000 version of the library. (A simpler solution might be to specify -m68000 when linking.) Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I'm a knight-errant, not an errant fool!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 00:28:22 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <89696-3>; Mon, 26 Jun 1995 00:26:25 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <190216>; Sun, 25 Jun 1995 23:25:58 +0200 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA23526; Sun, 25 Jun 1995 23:25:55 +0200 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9506252125.AA23526@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: problems with ixemul41.0 on 68030 & 68881 To: kyrimis@theseas.ntua.gr Date: Sun, 25 Jun 1995 23:25:54 +0200 Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9506251741.07kh@kriton.UUCP> from "Kriton Kyrimis" at Jun 25, 95 07:41:17 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 567 > > > Please read Kritons mail on this problem, as his solution is maybe > > the better on ;) > > Which solution, for those like me who don't archive their mail, was to delete > the old files from libm020, namely libc.a, crt0.o, bcrt0.o, and rcrt0.o, to > force the linker to use the 68000 version of the library. > > (A simpler solution might be to specify -m68000 when linking.) Ouch, I have misunderstand you, sorry. I thougt you only replace the new crt0.o with the old one to get rid of that new functions. Is this the third solution ? ;) Thomas From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 09:57:52 1995 Received: from helios.intranet.GR ([146.124.14.200]) by nic.funet.fi with SMTP id <89156-3>; Mon, 26 Jun 1995 09:54:05 +0300 Received: from pilits.intranet.gr by helios.intranet.GR with SMTP (8.6.11/ICM-mailhub-1.0) id JAA27954; Mon, 26 Jun 1995 09:14:13 +0300 From: panto@intranet.GR Received: from pcpanto.intranet.gr by pilits.intranet.gr (4.1/SMI-4.1) id AA11812; Mon, 26 Jun 95 09:55:13 +0300 To: amiga-gcc-port@nic.funet.fi Subject: Port to other Motorolla CPUs (6811, 6816) Date: Mon, 26 Jun 95 07:58: 9 GMT Message-Id: <9506260758.093418@pcpanto.intranet.gr> Return-Receipt-To: panto@intranet.GR X-Mailer: SelectMAIL 1.1 Hi there. This question is somewhat unrelated to the subject of this list but I was wondering. How was the initial port for the GCC was made for the amiga. And how is is possible to port to an entire different architecture (ie 6811, 6816 microcontrollers). I've read the docs about RTL (Register Tranfer Language) but as far as I can see after this pass everything is handed off to gas to produce the object file. Does that mean that a new gas must be written to support the new processor, or is it possible to use a shortcut. Thanks. panto From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 10:10:44 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <88997-1>; Mon, 26 Jun 1995 10:09:22 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HS5P7Q4WN490NR5E@LEON.CTI.GR>; Mon, 26 Jun 1995 10:06:11 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA00445; Mon, 26 Jun 95 10:09:43 +0300 Date: Mon, 26 Jun 1995 10:09:42 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: problems with ixemul41.0 on 68030 & 68881 In-reply-to: <9506252125.AA23526@nereid.rz.Uni-Osnabrueck.DE> from "Thomas Radtke" at Jun 25, 95 11:25:54 pm To: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Cc: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9506260709.AA00445@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 359 > Ouch, I have misunderstand you, sorry. I thougt you only replace the > new crt0.o with the old one to get rid of that new functions. Is this > the third solution ? ;) Very likely, but why experiment? -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I'm a knight-errant, not an errant fool!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 10:52:40 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89696-2>; Mon, 26 Jun 1995 10:51:32 +0300 Received: by colombo.telesys-innov.fr; Mon, 26 Jun 1995 09:53:07 +0100 From: Philippe BRAND Message-Id: <199506260853.JAA12608@colombo.telesys-innov.fr> Subject: Re: Port to other Motorolla CPUs (6811, 6816) To: panto@intranet.GR Date: Mon, 26 Jun 1995 09:53:06 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9506260758.093418@pcpanto.intranet.gr> from "panto@intranet.GR" at Jun 26, 95 07:58:00 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 861 panto@intranet.GR writes: > How was the initial port for the GCC was made for the amiga. And how is is possible > to port to an entire different architecture (ie 6811, 6816 microcontrollers). > I've read the docs about RTL (Register Tranfer Language) but as far as I can see > after this pass everything is handed off to gas to produce the object file. > Does that mean that a new gas must be written to support the new processor, or is it > possible to use a shortcut. Initial port was made using sun3 system. You'll have to add to gas other processor support. And more than that, you'll have to build your own md (machine description) file, which is not something really easy. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 10:59:52 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89205-4>; Mon, 26 Jun 1995 10:58:52 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA09881; Mon, 26 Jun 1995 10:00:54 +0200 Date: Mon, 26 Jun 1995 10:00:53 +0200 (MET DST) From: Kamil Iskra Subject: Some suggestions to GCC To: amiga-gcc-port@nic.funet.fi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 1. I recently had a look at "/gnu/os-include/proto/exec.h" and it really surprised me! There seems to be a bug in the way "__USE_SYSBASE" define is used. As the name clearly says, defining "__USE_SYSBASE" should produce a code that USES SysBase. So please have a look at this piece of "proto/exec.h": #ifdef __USE_SYSBASE #define SysBase ((struct ExecBase *)*(struct Library **)4) #define BASE_EXT_DECL #define BASE_EXT_DECL0 #define BASE_NAME SysBase #endif Apparently, defining this symbol in GCC creates a code that does NOT use SysBase. Nonsense, don't you think so? And incompatibility with other Amiga compilers, as well. I think I understand WHY this bug was made - simply the person who created this file wanted using SysBase to be the default one - since direct dereferencing 0x4 location at every Exec call is very inefficient, especially if Enforcer is running in background. I agree, the more efficient call should be the default one. But, on the other hand, WHO would like to use the LESS efficient one? What for? I would just suggest to GET RID OF this "#ifdef" and ALWAYS use SysBase. 2. There are some problems with ".guide" file when reading them using AmigaGuide v40. As some of you might know, there is an incompatibility between this version and the earlier ones in the way they interpret backslashes '\'. Older versions simply display single backslash when there is one in ".guide" file, while in the latest one backslash is an escape-character and to display a single backslash there have to be two consecutive backslashes in ".guide" file. AWFUL incompatibility, isn't it? And it causes severe problems in guides - '\n' becomes 'n', `\' becomes `', and finally #define USE(var) \ static void *const use_##var = (&use_##var, &var, 0) is displayed in one line, as #define USE(var) X static void *const use_##var = (&use_##var, &var, 0) Where instead of X there is a rectangle. Something has to be done about it. The worst thing is that if we change '\n' to '\\n' everything will be fine for OS 3.1 users, but most people still have OS 2.x/3.0, and they will see '\\n'! My suggestion is to distribute guides in 2.x/3.0 "standard", and together with them to put a small converter that would convert single backslashes to double ones. Of course everybody who has been programming in C for more than a weak can write such a program on his/her own in 10 minutes (for those that can't, I include it below :-), but not everybody is aware of the problem and reading such a "faulty" guides can lead to frustration. This converter could be executed automatically by GCC install script if it finds "amigaguide.library" v40+ - this way average user wouldn't even note anything. OK, below is a source code of the converter - it's written rather nicely (checks for most kinds of errors, displays precise information etc.) so I think it could be used for converting during installation. It is distributed under GNU GPL. #include int main(int argc, char *argv[]) { FILE *source, *dest; int retcode=0; if (argc==3) if (source=fopen(argv[1], "r")) { if (dest=fopen(argv[2], "w")) { int c; while ((c=fgetc(source))!=EOF) { if (c=='\\') fputc('\\', dest); if (fputc(c, dest)==EOF) { perror(argv[2]); retcode=10; break; } } fclose(dest); } else { perror(argv[2]); retcode=10; } fclose(source); } else { perror(argv[1]); retcode=10; } else fprintf(stderr, "Usage: %s \n", argv[0]); return retcode; } / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 11:13:04 1995 Received: from helios.intranet.GR ([146.124.14.200]) by nic.funet.fi with SMTP id <89169-4>; Mon, 26 Jun 1995 11:11:30 +0300 Received: from pilits.intranet.gr by helios.intranet.GR with SMTP (8.6.11/ICM-mailhub-1.0) id KAA01291; Mon, 26 Jun 1995 10:30:48 +0300 From: panto@intranet.GR Received: from pcpanto.intranet.gr by pilits.intranet.gr (4.1/SMI-4.1) id AA12581; Mon, 26 Jun 95 11:11:49 +0300 To: amiga-gcc-port@nic.funet.fi Subject: Port to other Motorolla CPUs (6811, 6816) Date: Mon, 26 Jun 95 09:14:45 GMT Message-Id: <9506260914.2D396C@pcpanto.intranet.gr> X-Mailer: SelectMAIL 1.1 Where can I find the docs about the md file, and how does one add new processor support to gas. Do you have to rewrite it all? If everything is done the hard way (ie rewrite gas, new md file, and fidling with ld) how much time are we talking about. Thanks panto From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 11:43:16 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89212-1>; Mon, 26 Jun 1995 11:42:11 +0300 Received: by colombo.telesys-innov.fr; Mon, 26 Jun 1995 10:44:08 +0100 From: Philippe BRAND Message-Id: <199506260944.KAA12935@colombo.telesys-innov.fr> Subject: gcc-2.7.0 C final pre-release available To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 26 Jun 1995 10:44:07 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 800 Gcc-2.7.0 final pre-release C part available on both: ftp.telesys-innov.fr:/pub/amigados-gnu/beta/gcc-2.7.0-prerelease.lha and ftp.funet.fi:/pub/amiga/gnu/beta/gcc-2.7.0-prerelease.lha Changes to previous beta: - Asm code generation. It was reported that gcc *might* generate some 020 code even when 68000 code was requested, this should be fixed. - m68020-40 option available (optimize for 68040, but still allow execution on 68020). - gcc should now restore original process priority. PLEASE grab this archive and TEST it. This version should be the final 2.7.0. Especially test the compiler on 68000 systems. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 11:53:47 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <89234-1>; Mon, 26 Jun 1995 11:52:52 +0300 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id KAA25400 for ; Mon, 26 Jun 1995 10:50:07 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA13241; Mon, 26 Jun 95 09:21:42 GMT Date: Mon, 26 Jun 95 09:21:42 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) To: Message-Id: <9506260921.AA13241@indi1.u-strasbg.fr> Apparently-To: amiga-gcc-port@nic.funet.fi From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 11:54:10 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89207-4>; Mon, 26 Jun 1995 11:52:51 +0300 Received: by colombo.telesys-innov.fr; Mon, 26 Jun 1995 10:54:53 +0100 From: Philippe BRAND Message-Id: <199506260954.KAA12982@colombo.telesys-innov.fr> Subject: Debug To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 26 Jun 1995 10:54:52 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 711 I was not aware of this, maybe I missed some emails a while ago, but there's actually a debugger, Barfly, shareware, which handles gcc, if compiled with stabs debug, at the source level. Just compile your programs with -g -gstabs. Author says that one couldn't debug a program if generated to use ixemul library, because ixemul used (?) to change process pointer in exec structure. Has this "feature" changed ? (for better explanation read Barfly doc). BTW I forgot in my previous email to add the "PLEASE REPORT asap" statement. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 12:23:10 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89901-3>; Mon, 26 Jun 1995 12:21:17 +0300 Received: by colombo.telesys-innov.fr; Mon, 26 Jun 1995 11:22:30 +0100 From: Philippe BRAND Message-Id: <199506261022.LAA13192@colombo.telesys-innov.fr> Subject: Re: gcc-2.7.0 C final pre-release available To: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Date: Mon, 26 Jun 1995 11:22:29 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9506260907.AA26081@decap2.zdv.uni-tuebingen.de> from "Jochen Wiedmann" at Jun 26, 95 11:07:28 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 471 Jochen Wiedmann writes: > I am missing something: Is ld compiled with stack extension now? Arg! Ok I'll do it. > And, btw, how about the other GNU tools which need large stack, but > are missing in the distribution? (make, grep, ...) I'll rebuild ALL gnu utils with auto-stack extension. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 12:57:58 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <89958-4>; Mon, 26 Jun 1995 12:55:48 +0300 Received: from pessoa.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA18903; Mon, 26 Jun 1995 11:55:59 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA08869; Mon, 26 Jun 1995 11:48:44 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506260948.AA08869@pessoa.ci.uminho.pt> Subject: gcc util updated To: amiga-gcc-port@nic.funet.fi (gcc) Date: Mon, 26 Jun 1995 11:48:43 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 386 When the gcc utils are updated please let us know and tell us were you have put them. __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 13:30:31 1995 Received: from helios.intranet.GR ([146.124.14.200]) by nic.funet.fi with SMTP id <90666-2>; Mon, 26 Jun 1995 13:29:04 +0300 Received: from pilits.intranet.gr by helios.intranet.GR with SMTP (8.6.11/ICM-mailhub-1.0) id MAA05948; Mon, 26 Jun 1995 12:49:12 +0300 From: panto@intranet.GR Received: from pcpanto.intranet.gr by pilits.intranet.gr (4.1/SMI-4.1) id AA12994; Mon, 26 Jun 95 13:30:11 +0300 To: amiga-gcc-port@nic.funet.fi Subject: md files (Was: Port GCC to 6811, 6816) Date: Mon, 26 Jun 95 11:33: 7 GMT Message-Id: <9506261133.073010@pcpanto.intranet.gr> X-Mailer: SelectMAIL 1.1 Damn. I thought it might be easier. BTW, these microcontrollers have some simillarities with the 68k family (although not as many registers), so getting an md file for a 68k md file, could help. Any pointers to a site with these md files? panto From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 13:49:58 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <90606-2>; Mon, 26 Jun 1995 13:48:52 +0300 Received: by ceylon.informatik.uni-rostock.de id MAA00294; Mon, 26 Jun 1995 12:48:39 +0200 Received: by honshu.informatik.uni-rostock.de id MAA20510; Mon, 26 Jun 1995 12:48:38 +0200 From: Gunther Nikl Message-Id: <199506261048.MAA20510@honshu.informatik.uni-rostock.de> Subject: Re: Some suggestions to GCC To: amiga-gcc-port@nic.funet.fi Date: Mon, 26 Jun 1995 12:48:36 +0200 (MET DST) In-Reply-To: from "Kamil Iskra" at Jun 26, 95 10:00:53 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 964 > 1. I recently had a look at "/gnu/os-include/proto/exec.h" and it > really surprised me! There seems to be a bug in the way > "__USE_SYSBASE" define is used. ... > I think I understand WHY this bug was made - simply the person who > created this file wanted using SysBase to be the default one - since > direct dereferencing 0x4 location at every Exec call is very > inefficient, especially if Enforcer is running in background. I agree, > the more efficient call should be the default one. But, on the other > hand, WHO would like to use the LESS efficient one? What for? I would > just suggest to GET RID OF this "#ifdef" and ALWAYS use SysBase. No, please *DO NOT REMOVE* this construct! I thought I might be useful sometimes to avoid a global library base (eg. the exec support function should be compiled this way). You are right, that the define is wrong. It should be called "_USEOLDEXEC_" (thats the original Lattice behaviour). Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 14:27:06 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <89968-2>; Mon, 26 Jun 1995 14:25:27 +0300 Received: from pessoa.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA19657; Mon, 26 Jun 1995 12:44:17 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA13524; Mon, 26 Jun 1995 12:37:00 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506261037.AA13524@pessoa.ci.uminho.pt> Subject: aboout generating code To: amiga-gcc-port@nic.funet.fi (gcc) Date: Mon, 26 Jun 1995 12:36:59 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 472 is it possible that i could compile a program to run on 68000 machines that was compiled in an sun or an avion if it is please tell me how. i would like to try it out. __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 14:27:46 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <90598-1>; Mon, 26 Jun 1995 14:26:44 +0300 Received: from pessoa.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA19669; Mon, 26 Jun 1995 12:45:53 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA13740; Mon, 26 Jun 1995 12:38:37 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506261038.AA13740@pessoa.ci.uminho.pt> Subject: compiling 68000 code in avion or sun station To: amiga-gcc-port@nic.funet.fi (gcc) Date: Mon, 26 Jun 1995 12:38:36 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 427 is it possible to compile code for 68000 in a avion or sun station? if it is please let me know. i would like to try it out __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 14:28:15 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <90025-4>; Mon, 26 Jun 1995 14:26:42 +0300 Received: from pessoa.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA19553; Mon, 26 Jun 1995 12:36:54 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA12324; Mon, 26 Jun 1995 12:29:38 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506261029.AA12324@pessoa.ci.uminho.pt> Subject: Bugs in gcc To: amiga-gcc-port@nic.funet.fi (gcc) Date: Mon, 26 Jun 1995 12:29:38 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 602 when i invoke g++ with a hello world program with 3 lines is says gcc error 10 and its out of mem i have 9MB of mem 68000 A2000 GVP CARD when i invoque g++ my wb bar tells i have 7MB i have workbench 3.1 ROMS 40.1 by emulation please help a like to program in c++ can it be done in gcc?. __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 14:28:46 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <90628-3>; Mon, 26 Jun 1995 14:27:18 +0300 Received: from pessoa.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA19107; Mon, 26 Jun 1995 12:02:28 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA09437; Mon, 26 Jun 1995 11:55:11 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506260955.AA09437@pessoa.ci.uminho.pt> Subject: Bash were is it? To: amiga-gcc-port@nic.funet.fi (gcc) Date: Mon, 26 Jun 1995 11:55:11 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 364 Is anyone using bash? Please tell were y can get the binaries. __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 14:30:53 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <90742-2>; Mon, 26 Jun 1995 14:30:12 +0300 Received: from pessoa.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA17944; Mon, 26 Jun 1995 10:18:31 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA05310; Mon, 26 Jun 1995 10:10:36 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506260810.AA05310@pessoa.ci.uminho.pt> Subject: bugs on 2.7.0 To: amiga-gcc-port@nic.funet.fi (gcc) Date: Mon, 26 Jun 1995 10:10:35 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1054 Can anyone say why 2.7.0 doesm,t work on 68000 machines i have one and gcc, makes may machine rebbot 68000 9MB GVP SCSI CARD Can i do somethin gto prevent this, i'm using the olde version 2.6.3 but i would like to be using 2.7.0 another question: when i try to run g++ with almost 7MB of mem with a program with 3 lines it tells me out of mem can anybody give me an advise and if anyone could give me a phone number were i can find hardware cards in first hand or in second hand, for A2000 my problem is that, because commodore break down no one that i knew sells comodore hardware now and would like to buy an IDE controller and an accelarator card for my computer if anyone can solve my problems, please mail me or mail to gcc list __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 16:59:28 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90101-3>; Mon, 26 Jun 1995 16:57:28 +0300 Received: by colombo.telesys-innov.fr; Mon, 26 Jun 1995 15:56:36 +0100 From: Philippe BRAND Message-Id: <199506261456.PAA14101@colombo.telesys-innov.fr> Subject: Re: compiling 68000 code in avion or sun station To: si215603@ci.uminho.pt (Luis Antonio F.Alves) Date: Mon, 26 Jun 1995 15:56:36 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9506261038.AA13740@pessoa.ci.uminho.pt> from "Luis Antonio F.Alves" at Jun 26, 95 12:38:36 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 478 Luis Antonio F.Alves writes: > is it possible to compile code for 68000 in a avion or sun station? Yes, I do use a cross-compiler built on a sun running sunos4.1.3. This cross-compiler is available on my site: ftp.telesys-innov.fr:/pun/amigados-gnu/gcc-cross. I'm currently upgrading it to 2.7.0. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 17:39:35 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90142-4>; Mon, 26 Jun 1995 17:38:11 +0300 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id QAA15445 (8.6.12/IDA-1.6); Mon, 26 Jun 1995 16:37:53 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA02803; Mon, 26 Jun 95 16:37:52 +0200 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9506261437.AA02803@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: md files (Was: Port GCC to 6811, 6816) To: panto@intranet.GR Date: Mon, 26 Jun 1995 16:37:52 +0200 (MET DST) Cc: amiga-gcc-port@lists.funet.fi In-Reply-To: <9506261133.073010@pcpanto.intranet.gr> from "panto@intranet.GR" at Jun 26, 95 11:33:00 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 384 > > BTW, these microcontrollers have some simillarities with the 68k family > (although not as many registers), so getting an md file for a 68k md file, could help. > Any pointers to a site with these md files? > The .md-files (machine descriptions) are part of the gcc sources. The gcc documentation contains _some_ information how to port gcc to other processors, too. Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Jun 26 23:53:29 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <90423-3>; Mon, 26 Jun 1995 23:47:10 +0300 Received: by theseas.ntua.gr with UUCP; Mon, 26 Jun 1995 23:50:11 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07lq@kriton.UUCP>; Mon, 26 Jun 95 23:44:16 EET Date: Mon, 26 Jun 95 23:44:16 EET Message-Id: <9506262144.07lq@kriton.UUCP> Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 828 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: ixprefs 1.1 uploaded on aminet I just uploaded version 1.1 of ixprefs on aminet. Here are the changes from version 1.0: Made the following enhancements, suggested by Kamil Iskra (kiskra@ernie.icslab.agh.edu.pl): * Ixprefs window is now font adaptive. * Ixprefs window is now activated when opened. * GZZ adjust flag in GadToolsBox turned off. * CheckBox gadgets are now scalable under AmigaDOS 3.x. * NewLook menus under AmigaDOS 3.x * Use OpenFont() rather than DiskFont() to access system font, as this font is always in memory. * Slightly rearranged window layout to avoid problems with sizable gadgets. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Well, I just put 1.795372 and 2.204628 together." "And what does *that* mean?" "Four!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 03:43:33 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89663-2>; Tue, 27 Jun 1995 03:39:33 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sQPei-0004nZC; Mon, 26 Jun 95 18:41 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: problems with ixemul41.0 on 68030 & 68881 To: raimund@ifr.luftfahrt.uni-stuttgart.de Date: Mon, 26 Jun 1995 18:41:36 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9506241127.AA18029@ifr1.Luftfahrt.Uni-Stuttgart.DE> from "raimund@ifr.luftfahrt.uni-stuttgart.de" at Jun 24, 95 01:27:15 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 628 > ld -fl libm020 -o sintest /gnu/lib/crt0.o > /gnu/lib/crt0.o: Undefined symbol ___SaveSP referenced from text > segment > /gnu/lib/crt0.o: Undefined symbol ___init_stk referenced from text > segment Looks like you probably have an old libc.a in the gnu:lib/libm020 directory. Just delete it. > If I compile for m68881 I get a different message: > > gcc -v -o sintest -m68881 sintest.c > ... > as -mc68010 -o t:cc8799041.o t:cc879904.s > t:cc879904.s: Assembler messages: > t:cc879904.s:31: Error: invalid instruction for this architecture; I can't reproduce this error here. What assembler are you using? -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 12:29:12 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <90345-4>; Tue, 27 Jun 1995 12:24:38 +0300 Received: by ceylon.informatik.uni-rostock.de id LAA04530; Tue, 27 Jun 1995 11:24:26 +0200 Received: by honshu.informatik.uni-rostock.de id LAA25120; Tue, 27 Jun 1995 11:24:24 +0200 From: Gunther Nikl Message-Id: <199506270924.LAA25120@honshu.informatik.uni-rostock.de> Subject: Re: problems with ixemul41.0 on 68030 & 68881 To: amiga-gcc-port@nic.funet.fi Date: Tue, 27 Jun 1995 11:24:23 +0200 (MET DST) In-Reply-To: from "Fred Fish" at Jun 26, 95 06:41:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 865 > > If I compile for m68881 I get a different message: > > > > gcc -v -o sintest -m68881 sintest.c > > ... > > as -mc68010 -o t:cc8799041.o t:cc879904.s > > t:cc879904.s: Assembler messages: > > t:cc879904.s:31: Error: invalid instruction for this architecture; > > I can't reproduce this error here. What assembler are you using? This error message will be produced by the newwer gas version (>1.38). I ran into the same problem when I first tried gas 2.2 when it appeared on aminet. FPU instructions will only be accepted if you also compile at least for a 68020. A related problem with the newer gas version are instructions that are not available on a plain 68000 (eg. movec). The assembler will recejct that part (the instruction will only be executed if the proper processor is available). gas 1.38 assembled all nicely... Gunther From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 12:29:32 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <90094-3>; Tue, 27 Jun 1995 12:27:37 +0300 Received: by ceylon.informatik.uni-rostock.de id LAA04551; Tue, 27 Jun 1995 11:27:21 +0200 Received: by honshu.informatik.uni-rostock.de id LAA25211; Tue, 27 Jun 1995 11:27:20 +0200 From: Gunther Nikl Message-Id: <199506270927.LAA25211@honshu.informatik.uni-rostock.de> Subject: Re: bugs on 2.7.0 To: amiga-gcc-port@nic.funet.fi Date: Tue, 27 Jun 1995 11:27:19 +0200 (MET DST) In-Reply-To: <9506260810.AA05310@pessoa.ci.uminho.pt> from "Luis Antonio F.Alves" at Jun 26, 95 10:10:35 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 273 > Can anyone say why 2.7.0 doesm,t work on 68000 > machines Yes, I know. The problem seems to be in the "specs" file causing the assembler to produce instructions not available on 68000! (it defaults gas to 68020, thus jbsr to an external becomes bsr.l) Gunther From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 12:33:17 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90314-3>; Tue, 27 Jun 1995 12:32:51 +0300 Received: by colombo.telesys-innov.fr; Tue, 27 Jun 1995 11:34:30 +0100 From: Philippe BRAND Message-Id: <199506271034.LAA17288@colombo.telesys-innov.fr> Subject: Re: bugs on 2.7.0 To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Tue, 27 Jun 1995 11:34:30 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199506270927.LAA25211@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Jun 27, 95 11:27:19 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 516 Gunther Nikl writes: > Yes, I know. The problem seems to be in the "specs" file causing > the assembler to produce instructions not available on 68000! > (it defaults gas to 68020, thus jbsr to an external becomes bsr.l) Not only from specs file... latest pre-release should correct this (well I'm still waiting for feedback ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 13:14:11 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89968-2>; Tue, 27 Jun 1995 13:12:59 +0300 Received: by colombo.telesys-innov.fr; Tue, 27 Jun 1995 12:15:01 +0100 From: Philippe BRAND Message-Id: <199506271115.MAA17453@colombo.telesys-innov.fr> Subject: gcc2.7.0 cross-compiler available To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Tue, 27 Jun 1995 12:14:59 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 818 I've just built gcc-2.7.0 C part cross-compiler on a sparc-sun-sunos4.1.3. It comes complete with ixemul v41 and libnix0.9, headers etc... You still need to grab CBM headers and put them into: /usr/local/lib/gcc-lib/amigados/2.7.0/sys-include file is: -rw-r--r-- 1 root other 2708541 Jun 27 12:04 gcc270-cross-sunos4.1.3.lha and located both on: ftp.telesys-innov.fr:/pub/amigados-gnu/gcc-cross and ftp.funet.fi:/pub/amiga/gnu/gcc-cross (prefered site is funet, for speed). INSTALLATION: cd / lha x gcc270-cross-sunos4.1.3.lha gcc frontend is now: amigados-gcc Now you can compile "a little bit" faster than on amiga ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 13:21:08 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <90025-3>; Tue, 27 Jun 1995 13:20:27 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA14219 (5.65c-7/7.3w-FAU); Tue, 27 Jun 1995 12:16:38 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA12009 (5.x/7.3w-FAU); Tue, 27 Jun 1995 12:16:37 +0200 From: Tobias Ruland Message-Id: <9506271016.AA12009@immd8.informatik.uni-erlangen.de> Date: Tue, 27 Jun 1995 12:16:35 +0200 To: Philippe BRAND Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Subject: gcc2.7.0 cross-compiler available In-Reply-To: <199506271115.MAA17453@colombo.telesys-innov.fr> References: <199506271115.MAA17453@colombo.telesys-innov.fr> hi philippe Philippe BRAND writes: > I've just built gcc-2.7.0 C part cross-compiler on a sparc-sun-sunos4.1.3. > It comes complete with ixemul v41 and libnix0.9, headers etc... > You still need to grab CBM headers and put them into: > /usr/local/lib/gcc-lib/amigados/2.7.0/sys-include does this crosscompiler even run under SOLARIS2.4 ??? kind regards tobias --------------------------------------------------------------------------- Tobias Ruland (student at Dept. of Artificial Intelligence, Univ. Erlangen) MAIL: tsruland@immd8.informatik.uni-erlangen.de (Please write in ENGLISH, GERMAN or FINNISH) WWW: http://www8.informatik.uni-erlangen.de/~tsruland From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 13:25:30 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90142-4>; Tue, 27 Jun 1995 13:24:46 +0300 Received: by colombo.telesys-innov.fr; Tue, 27 Jun 1995 12:26:22 +0100 From: Philippe BRAND Message-Id: <199506271126.MAA17571@colombo.telesys-innov.fr> Subject: Re: gcc2.7.0 cross-compiler available To: tsruland@immd8.informatik.uni-erlangen.de (Tobias Ruland) Date: Tue, 27 Jun 1995 12:26:21 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9506271016.AA12009@immd8.informatik.uni-erlangen.de> from "Tobias Ruland" at Jun 27, 95 12:16:35 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 323 Tobias Ruland writes: > does this crosscompiler even run under SOLARIS2.4 ??? I'm afraid not... If there's demand for it, I can generate one. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 14:52:07 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90715-3>; Tue, 27 Jun 1995 14:47:34 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Tue, 27 Jun 1995 13:39:48 +0200 Received: from mammern.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA17535; Tue, 27 Jun 95 13:39:23 +0200 Date: Tue, 27 Jun 95 13:39:23 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9506271139.AA17535@inf-wiss.uni-konstanz.de> To: zrawi01@decap2.zdv.uni-tuebingen.de, phb@colombo.telesys-innov.fr Subject: Re: gcc-2.7.0 C final pre-release available Cc: amiga-gcc-port@lists.funet.fi From: Philippe BRAND > I'll rebuild ALL gnu utils with auto-stack extension. Is it really useful to recompile all of them? I mean, doesn't the stack-extension test in every function make them a lot slower? Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 15:07:58 1995 Received: from uranus.esc.k12.in.us ([165.138.7.1]) by nic.funet.fi with SMTP id <90168-2>; Tue, 27 Jun 1995 15:06:24 +0300 Received: by uranus.esc.k12.in.us (5.65/1.2-eef) id AA10892; Sat, 24 Jun 95 07:07:13 -0500 Return-Path: Date: Sat, 24 Jun 1995 07:07:12 -0500 (EST) From: Southwinds Operator To: amiga-gcc-port@lists.funet.fi Subject: All other Amiga Lists Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Pardon the offtopic post, could anyone direct me to all the other Amiga specific lists? I-Amiga must have moved and none of the others I have in the data base is valid. From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 15:11:51 1995 Received: from mailgate.ericsson.se ([130.100.2.2]) by nic.funet.fi with SMTP id <90345-2>; Tue, 27 Jun 1995 15:11:28 +0300 Received: from eds05.ericsson.se (eds05.ericsson.se [136.225.9.2]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id OAA10839 for ; Tue, 27 Jun 1995 14:11:19 +0200 Received: from DECNET-MAIL by edt.ericsson.se (PMDF V4.3-10 #7344) id <01HS7C31A4KW8WYLBZ@edt.ericsson.se>; Tue, 27 Jun 1995 14:11:21 +0200 Date: Tue, 27 Jun 1995 14:11:21 +0200 From: LE DU DENIS Subject: i-amiga To: AMIGA-GCC-PORT@nic.funet.fi Message-id: <01HS7C31ANV68WYLBZ@edt.ericsson.se> X-Envelope-to: AMIGA-GCC-PORT@nic.funet.fi X-VMS-To: IN%"AMIGA-GCC-PORT@nic.funet.fi" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT for i-amiga and other realted stuff there's a gateway listserv\vm1.nodak.edu From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 15:22:12 1995 Received: from uranus.esc.k12.in.us ([165.138.7.1]) by nic.funet.fi with SMTP id <89994-4>; Tue, 27 Jun 1995 15:20:40 +0300 Received: by uranus.esc.k12.in.us (5.65/1.2-eef) id AA10940; Sat, 24 Jun 95 07:20:46 -0500 Return-Path: Date: Sat, 24 Jun 1995 07:20:44 -0500 (EST) From: Southwinds Operator To: amiga-gcc-port@nic.funet.fi Subject: Amiga Mailing Lists Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Pardon the offtopic post, I am trying to find any Active Amiga mailing lists and so far havent had any luck. I-Amiga appears to have moved and all the others in my data base must be no longer valid. Could any here assist? From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 15:43:10 1995 Received: from uranus.esc.k12.in.us ([165.138.7.1]) by nic.funet.fi with SMTP id <90345-4>; Tue, 27 Jun 1995 15:41:36 +0300 Received: by uranus.esc.k12.in.us (5.65/1.2-eef) id AA10964; Sat, 24 Jun 95 07:40:41 -0500 Return-Path: Date: Sat, 24 Jun 1995 07:40:41 -0500 (EST) From: Southwinds Operator To: LE DU DENIS Cc: AMIGA-GCC-PORT@nic.funet.fi Subject: Re: i-amiga In-Reply-To: <01HS7C31ANV68WYLBZ@edt.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 27 Jun 1995, LE DU DENIS wrote: > for i-amiga and other realted stuff there's a gateway > listserv\vm1.nodak.edu Bless you! How would I write this? to:listserv@vm1.nodak.edu ?? sub: LISTS ?? Very sorry for my lack of Inet prowness. regards.. From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 15:46:21 1995 Received: from mailgate.ericsson.se ([130.100.2.2]) by nic.funet.fi with SMTP id <90496-2>; Tue, 27 Jun 1995 15:45:56 +0300 Received: from eds05.ericsson.se (eds05.ericsson.se [136.225.9.2]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id OAA15070 for ; Tue, 27 Jun 1995 14:45:43 +0200 Received: from DECNET-MAIL by edt.ericsson.se (PMDF V4.3-10 #7344) id <01HS7D9NPJEO8WYX81@edt.ericsson.se>; Tue, 27 Jun 1995 14:45:43 +0200 Date: Tue, 27 Jun 1995 14:45:43 +0200 From: LE DU DENIS Subject: re i-amiga To: AMIGA-GCC-PORT@nic.funet.fi Message-id: <01HS7D9NQLZM8WYX81@edt.ericsson.se> X-Envelope-to: AMIGA-GCC-PORT@nic.funet.fi X-VMS-To: IN%"AMIGA-GCC-PORT@nic.funet.fi" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT in the body of the message try help for info on how runs the mailserver and if you want the list type list in it's the way i've done it From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 16:21:13 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90598-1>; Tue, 27 Jun 1995 16:18:33 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sQbO8-0004nYC; Tue, 27 Jun 95 07:13 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: problems with ixemul41.0 on 68030 & 68881 To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Tue, 27 Jun 1995 07:13:16 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199506270924.LAA25120@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Jun 27, 95 11:24:23 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1004 > > > If I compile for m68881 I get a different message: > > > > I can't reproduce this error here. What assembler are you using? > > This error message will be produced by the newwer gas version (>1.38). I don't think that is what is keeping me from reproducing the problem: fishpond> gas -v GNU assembler version 2.5.2 (m68k-cbm-amigados) > I ran into the same problem when I first tried gas 2.2 when it appeared > on aminet. FPU instructions will only be accepted if you also compile > at least for a 68020. Perhaps then this bug was fixed between 2.2 and 2.5.2. > A related problem with the newer gas version are instructions that > are not available on a plain 68000 (eg. movec). The assembler will > recejct that part (the instruction will only be executed if the > proper processor is available). gas 1.38 assembled all nicely... Give me an example of the assembly language and hex values it is supposed to produce, and I'll try 2.5.2 here on those instructions. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 16:47:06 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <90691-4>; Tue, 27 Jun 1995 16:45:12 +0300 Received: by ceylon.informatik.uni-rostock.de id PAA05745; Tue, 27 Jun 1995 15:44:52 +0200 Received: by honshu.informatik.uni-rostock.de id PAA01173; Tue, 27 Jun 1995 15:44:54 +0200 From: Gunther Nikl Message-Id: <199506271344.PAA01173@honshu.informatik.uni-rostock.de> Subject: Re: problems with ixemul41.0 on 68030 & 68881 To: fnf@amigalib.com (Fred Fish) Date: Tue, 27 Jun 1995 15:44:53 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Fred Fish" at Jun 27, 95 07:13:16 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1066 > > > > > If I compile for m68881 I get a different message: > > > > > > I can't reproduce this error here. What assembler are you using? > > > > This error message will be produced by the newwer gas version (>1.38). > > I don't think that is what is keeping me from reproducing the problem: > > fishpond> gas -v > GNU assembler version 2.5.2 (m68k-cbm-amigados) I really think *all newer version of gas (>1.38)* refuse to assemble FPU instructions if "-m68020" has not been selected! > > > I ran into the same problem when I first tried gas 2.2 when it appeared > > on aminet. FPU instructions will only be accepted if you also compile > > at least for a 68020. > > Perhaps then this bug was fixed between 2.2 and 2.5.2. I do not think its a bug. Its a design decision, even if it was a bad one. > Give me an example of the assembly language and hex values it is > supposed to produce, and I'll try 2.5.2 here on those instructions. try "movec vbr,d0". But note: The specs file of 2.7.0 defaults the assembler to 68020! Gunther From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 17:56:20 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90025-2>; Tue, 27 Jun 1995 17:54:07 +0300 Received: by colombo.telesys-innov.fr; Tue, 27 Jun 1995 16:55:25 +0100 From: Philippe BRAND Message-Id: <199506271555.QAA18464@colombo.telesys-innov.fr> Subject: Re: problems with ixemul41.0 on 68030 & 68881 To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Tue, 27 Jun 1995 16:55:25 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199506271344.PAA01173@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Jun 27, 95 03:44:53 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 334 Gunther Nikl writes: > try "movec vbr,d0". But note: The specs file of 2.7.0 defaults the > assembler to 68020! Not latest one I uploaded yesterday. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 18:40:33 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90408-3>; Tue, 27 Jun 1995 18:38:07 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HS7J9ZGWLS00CG16@NET2.WAU.NL>; Tue, 27 Jun 1995 17:37:46 +0000 (GMT) Received: by vines2.wau.nl; Tue, 27 Jun 95 17:42:05 +0100 Date: Tue, 27 Jun 1995 17:23:33 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Fork and similar, problems (LONG) To: amiga-gcc-port@nic.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@nic.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi Everyone, I'm trying to get 'Swish' and 'WWWWais' to work on my machine (A3000 12Mb Fast Kickstart/WB 3.1) with gcc 2.7.0. Swish works OK. BTW Swish is an index utility which allows 'WWWWais' to search it. WWWWais is a CGI program and allows searching either locally or through a wais server. I'm interested to get the local search working, but I'm having problems with the following piece. Its the dreaded fork() !!!! --------------------- snip ------------------------ doswish() { int i, j, k; char *argline[MAXARGS], word[MAXSTRLEN], sourcepath[MAXSTRLEN]; nt pipe0[2], pipe1[2]; FILE *fp0; argline[0] = swishbin; if (version) { argline[1] = (char *) mystrdup("-V"); argline[2] = (char *) 0; } else { sprintf(sourcepath, "%s%s%s", sourcedir, (sourcedir[strlen(sourcedir) - 1] == '/') ? "" : "/", source); argline[1] = (char *) mystrdup("-f"); argline[2] = sourcepath; argline[3] = (char *) mystrdup("-m"); argline[4] = maxhits; argline[5] = (char *) mystrdup("-w"); for (i = 0, k = 6; k < MAXARGS;) { for (j = 0; keywords[i] != '\0' && keywords[i] != ' ' && j < MAXSTRLEN; i++) word[j++] = keywords[i]; word[j] = '\0'; argline[k++] = (char *) mystrdup(word); if (keywords[i] == '\0') break; else if (keywords[i] == ' ') i++; } argline[k] = (char *) 0; } pipe(pipe0); pipe(pipe1); switch(fork()) { case -1: progerr("fork() call failed."); case 0: close(pipe0[1]); close(pipe1[0]); dup2(pipe0[0], 0); dup2(pipe1[1], 1); execv(swishbin, argline); progerr("execv() call failed."); /* doesn't return */ default: close(pipe0[0]); close(pipe1[1]); fp0 = fdopen(pipe1[0], "r"); read_from_swish(fp0); if (!version) { printheader(); printform(); if (entrylist == NULL) { notfound(); return; } printf("Here is the result of your search using "); printf("the keyword(s) "); printf("\"%s\":

\n", keywords); printf("

\n"); printentries(entrylist); printf("
\n"); } } } ----------------- end of snip -------------------------- Compiling is not problem, defining -Dfork=fvork will do but leaving as it is works too. Running is a completly different ball game. The problem appears to be when the 'execve' is called then it simple crashes or when stackstack is enabled I get a warning and the program is removed. Compiling with stackextend doesn't seem to work. Using Stackmon and Snoopdos revealed that a second wwwwais program is started/created and that one is trying to use a HUGE (900Kb) stack which isn't just their. Any way to rewrite a part of this function to start Swish and get output from it. I'm currently trying to construct a new commandline and start Swish as a background process which will leave WWWWais sleeping until Swish is finished. Swish will dump its results into a file which WWWWais then can parse. Which ixemul function should I use I have been scanning the src of ixemul and found a reference to 'system' and 'ssystem' but the documentation is a bit thin to say the least. What is the logic behind the switch statement and the pipe commands ? Is it correct that you can't use -mstackextend and -mstackcheck together with gcc 2.7.0beta ? I tried this but got only the stackcheck code included in my executable (Checked with Resource) Thanks for any help on this. Please respond to me by email and not only on the list since I'm not subscribe to it. I know shame on me but its hard to keep up being subscribe to more than 1 mailinglist when your mailer doesn't do a bit of work. Thanks again, Joop From amiga-gcc-port-owner@nic.funet.fi Tue Jun 27 22:57:12 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89223-4>; Tue, 27 Jun 1995 22:53:28 +0300 Received: by theseas.ntua.gr with UUCP; Tue, 27 Jun 1995 21:35:36 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07me@kriton.UUCP>; Tue, 27 Jun 95 19:47:46 EET Date: Tue, 27 Jun 95 19:47:46 EET Message-Id: <9506271747.07me@kriton.UUCP> In-Reply-To: <199506271344.PAA01173@honshu.informatik.uni-rostock.de> (from Gunther Nikl ) (at Tue, 27 Jun 1995 15:44:53 +0200 (MET DST)) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 629 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: gnikl@informatik.uni-rostock.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: problems with ixemul41.0 on 68030 & 68881 Hi Gunther (Gunther Nikl), in <199506271344.PAA01173@honshu.informatik.uni-rostock.de> on Jun 27 you wrote: > I really think *all newer version of gas (>1.38)* refuse to assemble FPU > instructions if "-m68020" has not been selected! At least in 2.5.1, you can specify the -m68881 switch to ask explicitly for FPU code. Thus, you can do strange combinations like -m68000 -m68881! Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Calling the Doctor! There's no escape. Repeat: there *is* no escape!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Jun 28 06:32:56 1995 Received: from cnts4p07.uwaterloo.ca ([129.97.198.5]) by nic.funet.fi with SMTP id <90785-4>; Wed, 28 Jun 1995 06:31:08 +0300 Received: by cnts4p07.uwaterloo.ca.uwaterloo.ca (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Tue, 27 Jun 95 23:31:49 Date: Wed, 28 Jun 1995 04:31:47 +0500 (UTC) From: Jeff Shepherd Reply-To: jsshephe@undergrad.math.uwaterloo.ca Subject: New AmiTCP SDK for gcc released to aminet Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: amiga-gcc-port@nic.funet.fi OK. I admit it. The first archive was thrown together in 20 minutes without much thought. People had a lot of problems with it and I think those problems are corrected. Anyways I released a new SDK onto aminet. The organization has changed - the includes follow the gcc include hierarchy instead of AmiTCP's. Also a new socket library was included along with the old one. The new code does handle servers. I compiled imapd and httpd with little problems. Here is a copy of the README. ------------------------------------------------------------------------- Short: AmiTCP SDK 4.0 for gcc second release Uploader: jsshephe@undergrad.math.uwaterloo.ca (Jeff Shepherd) Author: jsshephe@undergrad.math.uwaterloo.ca (Jeff Shepherd) Type: comm/tcp This code is strictly BETA!!. It works with MuiADT and Pine, httpd and a few others but does not guarantee it will work with anything else. You are free to modify/correct the code as long as you mail me the changes. This compiles with gcc only!! Almost all of the SASC stuff was removed. If you want to compile with SASC, get the original API archive. This archive includes the src+include+extras for the new amitcp-gcc library plus the source for the old archive I uploaded. The format of the archive has changed. People complained about where the headers go. I reorganized the include directories to comply with the GCC setup. Also I completely recompiled the archive to make sure things did compile. Some people complained about declarations mishaps. I think they are all vanished now. Good news! THE NEW CODE DOES WORK WITH SERVERS!!. I have compiled imapd and httpd1.4.1 successfully with a couple of additions mainly: int s=init_inet_daemon(); set_socket_stdio(s); at the beginning of main(). Look out for the ReleaseSocket/ReleaseCopyofSocket function. They might not work at all. I have not tested them since UNIX don't have equivalent calls. Also you cannot do a select() between sockets and nonsockets. For sockets use WaitSelect() as usual. I found 2 MISTAKES in the archive. The first is ug_SetupContextTags(). It does NOT take a program name argument. Also no syslog() function was supplied. I made one using vprintf(). Enclosed are modified gcc include files in the directory gnu/include and gnu/os-include. You can copy over the ones in gnu:include/. These includes are based upon the ones found in gcc263inclib.lha. If you have the new V41 includes you will have to check what changes there are. You don't have to check the gnu/os-include directory since those are new files. In the main program file, add the following line: const char *_ProgramName = "progname"; where progname is your program name. _ProgramName is needed so that the autoinit function can set up the syslog file correctly. To compile, specify "-D__AMITCP__ -DNO_INLINE_STDARG" + all the other usual entries on the commandline. To use the old socket archive (source in netlib), add -DOLD to the commandline. To link specify "libc.a -lnewamitcp -lamiga -lauto" + all the other usual entries. To use the original library use "libc.a -lamitcp -lamiga -lauto". (Someone figure out why I need to link libc.a first. Without it, things behave very strangely or refuse to function. I think its the autoinit stuff.) A custom version of ixemul 40.4 libc.a and ixemul.41.0 is supplied. (The 40.4 version doesn't have the wrappers for ixemul's pseudo-TCP functions). The only thing different with the 41.0 libc.a is the deletion of fstat.o. Happy networking. ------------------------------------------------------------------------- jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/ The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Wed Jun 28 10:12:05 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <89164-4>; Wed, 28 Jun 1995 10:10:36 +0300 Received: from iagrs01.iag.Uni-Stuttgart.DE (iagrs01-fd.iag.uni-stuttgart.de [129.69.18.166]) by noc.belwue.de with SMTP id JAA04445 (8.6.12/IDA-1.6); Wed, 28 Jun 1995 09:10:17 +0200 Received: by iagrs01.iag.Uni-Stuttgart.DE (AIX 3.2/UCB 5.64/BelWue-2.0RSbeta) id AA31733; Wed, 28 Jun 1995 09:10:17 +0200 Date: Wed, 28 Jun 1995 09:10:17 +0200 From: vaad1649@iag.Uni-Stuttgart.DE (Raimund Dold) Message-Id: <9506280710.AA31733@iagrs01.iag.Uni-Stuttgart.DE> To: fnf@amigalib.com Cc: raimund@ifr.Luftfahrt.Uni-Stuttgart.DE, amiga-gcc-port@nic.funet.fi In-Reply-To: (fnf@amigalib.com) Subject: Re: problems with ixemul41.0 on 68030 & 68881 From: fnf@amigalib.com (Fred Fish) Date: Mon, 26 Jun 1995 18:41:36 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 628 > ld -fl libm020 -o sintest /gnu/lib/crt0.o > /gnu/lib/crt0.o: Undefined symbol ___SaveSP referenced from text > segment > /gnu/lib/crt0.o: Undefined symbol ___init_stk referenced from text > segment > Looks like you probably have an old libc.a in the gnu:lib/libm020 directory. > Just delete it. That solved the problem, all is compiling well now! > If I compile for m68881 I get a different message: > > gcc -v -o sintest -m68881 sintest.c > ... > as -mc68010 -o t:cc8799041.o t:cc879904.s > t:cc879904.s: Assembler messages: > t:cc879904.s:31: Error: invalid instruction for this architecture; > I can't reproduce this error here. What assembler are you using? I am using gas 2.5.1. > -Fred Raimund From amiga-gcc-port-owner@nic.funet.fi Wed Jun 28 12:13:41 1995 Received: from gryzmak.pdi.lodz.pl ([193.59.40.129]) by nic.funet.fi with SMTP id <90586-2>; Wed, 28 Jun 1995 12:11:47 +0300 Received: (from robert@localhost) by gryzmak.pdi.lodz.pl (8.6.10/1.34) id LAA19997; Wed, 28 Jun 1995 11:09:55 +0200 Date: Wed, 28 Jun 1995 11:09:55 +0200 (MET DST) From: Robert Ramiega To: jsshephe%undergrad.math.uwaterloo.ca@plearn.edu.pl cc: amiga-gcc-port@nic.funet.fi Subject: Re: New AmiTCP SDK for gcc released to aminet In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! Thanks for your effort in making AmiTCP SDK gcc friendly :) I have one question thou: Are they still forceing to use ixemul.library? I recon that previous version had something like that. regards Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Jun 28 15:31:53 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <90160-1>; Wed, 28 Jun 1995 15:27:12 +0300 Received: by math.uwaterloo.ca id <77139-4>; Wed, 28 Jun 1995 08:25:14 -0400 Date: Wed, 28 Jun 1995 08:25:12 -0400 From: Jeff Shepherd To: Robert Ramiega cc: amiga-gcc-port@nic.funet.fi Subject: Re: New AmiTCP SDK for gcc released to aminet In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 28 Jun 1995, Robert Ramiega wrote: > Hi! > Thanks for your effort in making AmiTCP SDK gcc friendly :) > I have one question thou: > Are they still forceing to use ixemul.library? I recon that previous > version had something like that. > > regards > Robert Yes it does. In fact some of the ixemul code is present in the archive. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Wed Jun 28 16:03:08 1995 Received: from gryzmak.pdi.lodz.pl ([193.59.40.129]) by nic.funet.fi with SMTP id <90036-3>; Wed, 28 Jun 1995 16:00:50 +0300 Received: (from robert@localhost) by gryzmak.pdi.lodz.pl (8.6.10/1.34) id OAA27790; Wed, 28 Jun 1995 14:56:56 +0200 Date: Wed, 28 Jun 1995 14:56:53 +0200 (MET DST) From: Robert Ramiega To: Jeff Shepherd cc: amiga-gcc-port@nic.funet.fi Subject: Re: New AmiTCP SDK for gcc released to aminet In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi again! Can someone upload it to Funet? It's almost only host i can connect and get resonable transfer rate. If it's already uploaded there than please tell me where can i find it. I also have another request. Sometime ago someone mentioned that Barfly source debugger works with GCC. Since ftp.luth.se is down could someone upload it to Funet as well? Thanks in advance Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// http://plukwa.pdi.lodz.pl - check this space \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Jun 28 18:58:18 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <90622-4>; Wed, 28 Jun 1995 18:51:19 +0300 Received: by math.uwaterloo.ca id <77144-4>; Wed, 28 Jun 1995 11:48:49 -0400 Date: Wed, 28 Jun 1995 11:48:43 -0400 From: Jeff Shepherd To: amiga-gcc-port@nic.funet.fi Subject: Re: New AmiTCP SDK for gcc released to aminet In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII One little thing I forgot to mention in the documentation. You will need to add: #include or #include to any of the files using sockets. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Wed Jun 28 20:18:48 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89577-4>; Wed, 28 Jun 1995 20:16:24 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA14559 (5.65c+/IDA-1.4.4 for ); Wed, 28 Jun 1995 19:12:59 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA17682; Wed, 28 Jun 1995 19:14:22 GMT Date: Wed, 28 Jun 1995 19:14:21 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Niklas Hallqvist Cc: hoehle@inf-wiss.uni-konstanz.de, amiga-gcc-port@nic.funet.fi Subject: fork() with MMU? VMMs problem... In-Reply-To: <199506211340.PAA25526@linda.appli.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Of course, allocations through the Unix-compatibility library (ixemul) > won't be usable for AmigaDOS IPC/IO, you have to use AmigaDOS memory > allocation routines for that. Anyway, ixemul clients are not really > supposed to be aware of Amiga-specific routines anyway. It's also > clear that MMU pages shouldn't be shared unless vfork or shared memory > (which aren't in ixemul yet, yes?) uses them. Great ! Arent you folks forgeting something? ixemul clients, up to today, are not hard to flush totaly into Virtual Memory, both code and data. If ixemul would, sudently, become to be a PMMU manager, most probably these clients would stop using VMM or, even worse, the whole system whould crash!!!!!! THE ONLY CHANCE TO CREATE A REAL FORK() IS TO PUT Fred Fish AND VMM AUTOR TOGETHER. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Thu Jun 29 03:08:10 1995 Received: from Bogon.Tach.Net ([199.0.8.5]) by nic.funet.fi with SMTP id <89095-4>; Thu, 29 Jun 1995 03:06:42 +0300 Received: from zeus (Zeus.Surf.Tach.Net [199.0.9.129]) by Bogon.Tach.Net (8.6.10/8.6.9) with SMTP id UAA00051 for ; Wed, 28 Jun 1995 20:06:14 -0400 Received: by zeus.surf.tach.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 28 Jun 95 20:04:41 From: jeffm@zeus.surf.tach.net (Jeffery C. May) Message-Id: <20e576d2.u7t150e.bc952-jeffm@zeus.surf.tach.net> Subject: ARexx and GNU C? To: amiga-gcc-port@nic.funet.fi Date: Wed, 28 Jun 95 20:04:41 Organization: Wish I had some! I recently got the Commodore Programmer's Guide to Arexx, hoping it would help me in my quest in making adding an ARexx port to my software easier. Is there any GNU C specific examples of ARexx interfacing I can look at, or am I missing something. If it helps, I know something is wrong with my GNU C setup, as the -noixemul switch doesn't work properly. (It causes a TON of "Reference _????? found in text segment" errors, where _?????? is EVERY Amiga library function I have used.) The Simplerexx system doesn't compile properly either. I've typed in one of the header files out of the book, but the other one (the one with the SAS and Aztec #pragmas) I'm not sure how to handle. Any ideas? (BTW- sorry for what I am sure is a simplistic question, in this realm of what seems to be serious OS-level programmers :) Jeff AA AA i Jeffery C. May ONLY A A A A RF Engineer, Harris ESS, Palm Bay, Florida AMIGA AAAA AAAA i B EE 95, Georgia Institute of Technology MAKES IT A A A A i jeffm@zeus.surf.tach.net POSSIBLE From amiga-gcc-port-owner@nic.funet.fi Thu Jun 29 14:09:07 1995 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by nic.funet.fi with SMTP id <90735-2>; Thu, 29 Jun 1995 14:06:26 +0300 Received: from athena.cs.utwente.nl by utrhcs.cs.utwente.nl (5.x/csrelayMX-SVR4_1.1tmp/RB) id AA13648; Thu, 29 Jun 1995 13:06:14 +0200 Received: from kopstoot.cs.utwente.nl by athena.cs.utwente.nl (5.x/csrelay-Sol1.4/RB) id AA14391; Thu, 29 Jun 1995 13:06:13 +0200 Date: Thu, 29 Jun 1995 13:06:13 +0200 From: alberts@cs.utwente.nl (Mert Alberts) Message-Id: <9506291106.AA14391@athena.cs.utwente.nl> To: amiga-gcc-port@lists.funet.fi Subject: Serious g++ problem ... Dear all, My main reason for installing the 020-versions of the gcc 2.63 archive on my A4000/30 with FPU, was to have a full c++ compiler (apart from the fact that I love the concept of public software like GNU and TeX ;)). After installing everything manually (the installer script seemed to have some bug) the "plain" gcc compiler seems to work fine, but .... the g++ compiler crashes on even the simplest of programs. Just before the amiga resets, the compiler responds with "Illegal instruction". To see whether the problem was in the actual compilation phase I tried the option -S. This results in a crash right after the assembly code is generated. The -c and -E options didn't help either. The other thing I tried was to change the GCCSTACK value (both in the gnu/envarc directory and in ENVARC:), from 350K to 750K, and to 1M. Same problem as before. As you may have gathered, I didn't manage to get a compiler report with the -v option because the systems crashes too soon to safe the output. So al I can give you kind souls to help me in solving this problem right now are: - available memory in the A4000/30: 2Mb chip and 8Mb fast - the actual compiler invocation I used: g++ -o simple simple.cxx -v - the listing of `simple' (from Lippman's C++ Primer): #include void read() { cout << "read()\n"; } void sort() { cout << "sort()\n"; } void compact() { cout << "compact()\n"; } void write() { cout << "write()\n"; } int main() { read(); sort(); compact(); write(); return 0; } Any suggestions what (I) might be (doing) wrong? Thanks, Mert. PS. The same example(s) I tried worked fine with the SUN-port of gcc on my Sparc-1 at work. From amiga-gcc-port-owner@nic.funet.fi Thu Jun 29 15:34:36 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <89191-3>; Thu, 29 Jun 1995 15:32:57 +0300 Received: from pessoa by torga.ci.uminho.pt (5.4.1/140.2) id AA26670; Thu, 29 Jun 1995 14:33:52 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA17199; Thu, 29 Jun 1995 14:26:27 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9506291226.AA17199@pessoa.ci.uminho.pt> Subject: INFo about Electronics sites To: amiga-gcc-port@nic.funet.fi (gcc) Date: Thu, 29 Jun 1995 14:26:27 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 430 I would like to know where to find sites with info files describing functionality of certain types of chips like: PIC16C84 __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Thu Jun 29 17:14:09 1995 Received: from wn1.sci.kun.nl ([131.174.8.1]) by nic.funet.fi with SMTP id <90665-3>; Thu, 29 Jun 1995 17:12:27 +0300 Received: from studs.sci.kun.nl by wn1.sci.kun.nl via studs.sci.kun.nl [131.174.124.5] with ESMTP id QAA00693 (8.6.10/2.11) for ; Thu, 29 Jun 1995 16:12:15 +0200 From: Eric Schmeddes Received: by studs.sci.kun.nl id QAA18601 (8.6.10/2.1 for amiga-gcc-port@nic.funet.fi); Thu, 29 Jun 1995 16:12:14 +0200 Date: Thu, 29 Jun 1995 16:12:14 +0200 Message-Id: <199506291412.QAA18601@studs.sci.kun.nl> To: amiga-gcc-port@nic.funet.fi Subject: amiga gcc usenet Why don't we have a usenet group? Something link comp.sys.amiga.gnu.gcc.help would be nice... wouldn't it? Eric. From amiga-gcc-port-owner@nic.funet.fi Thu Jun 29 18:57:51 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90735-2>; Thu, 29 Jun 1995 18:54:25 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26548-4>; Thu, 29 Jun 1995 17:53:34 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209229-1>; Thu, 29 Jun 1995 17:53:24 +0100 Subject: Re: ARexx and GNU C? From: Christian Stieber To: jeffm@zeus.surf.tach.net (Jeffery C. May) Date: Thu, 29 Jun 1995 17:53:15 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <20e576d2.u7t150e.bc952-jeffm@zeus.surf.tach.net> from "Jeffery C. May" at Jun 28, 95 08:04:41 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 755 Message-Id: <95Jun29.175324+0100mesz.209229-1+3272@hphalle0.informatik.tu-muenchen.de> > > If it helps, I know something is wrong with my GNU C setup, as the -noixemul > switch doesn't work properly. (It causes a TON of "Reference _????? found > in text segment" errors, where _?????? is EVERY Amiga library function I > have used.) Ever considered linking with amiga.lib, or including the appropiate files and turning the optimizer on? Usually helps a lot :) Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Thu Jun 29 19:41:31 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90314-1>; Thu, 29 Jun 1995 19:39:14 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sRNaf-0004nYC; Thu, 29 Jun 95 10:41 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Serious g++ problem ... To: alberts@cs.utwente.nl (Mert Alberts) Date: Thu, 29 Jun 1995 10:41:25 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9506291106.AA14391@athena.cs.utwente.nl> from "Mert Alberts" at Jun 29, 95 01:06:13 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 576 > My main reason for installing the 020-versions of the gcc 2.63 archive > on my A4000/30 with FPU, was to have a full c++ compiler (apart from > the fact that I love the concept of public software like GNU and TeX I tried your sample program (simple.cxx) with the exact command line you gave, and it works fine here, including giving the expected output when the program is run. You don't explicitly say where you got the release you are running. I tried it with the GNU tools off FreshFish 9 as well as my current development versions that will be on FreshFish 10. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Jun 29 20:11:16 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <90036-3>; Thu, 29 Jun 1995 20:09:58 +0300 Received: by theseas.ntua.gr with UUCP; Thu, 29 Jun 1995 20:11:06 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07no@kriton.UUCP>; Thu, 29 Jun 95 20:05:20 EET Date: Thu, 29 Jun 95 20:05:20 EET Message-Id: <9506291805.07no@kriton.UUCP> In-Reply-To: <9506291106.AA14391@athena.cs.utwente.nl> (from alberts@cs.utwente.nl (Mert Alberts)) (at Thu, 29 Jun 1995 13:06:13 +0200) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1070 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: alberts@cs.utwente.nl Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Serious g++ problem ... Hi Mert (Mert Alberts), in <9506291106.AA14391@athena.cs.utwente.nl> on Jun 29 you wrote: > My main reason for installing the 020-versions of the gcc 2.63 archive > on my A4000/30 with FPU, was to have a full c++ compiler (apart from > the fact that I love the concept of public software like GNU and TeX > ;)). After installing everything manually (the installer script seemed > to have some bug) the "plain" gcc compiler seems to work fine, but > .... the g++ compiler crashes on even the simplest of programs. Your test program compiles fine on my 2000/Fusion-Forty. One thing to check is the size of your default stack: I managed to crash g++ by reducing my stack to 4000 (this was during linking, however). With my usual setting of 20000 I had no problem (stackmon indicates that your program needs ~15K of stack to compile and link). I hope this helps, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Officially, I am here quite unofficially!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Jun 30 09:39:54 1995 Received: from chx400.switch.ch ([130.59.1.2]) by nic.funet.fi with ESMTP id <89159-1>; Fri, 30 Jun 1995 09:37:49 +0300 Received: from isbiel.ch (actually sunny.isbiel.ch) by chx400.switch.ch with SMTP (PP); Fri, 30 Jun 1995 08:37:23 +0200 Received: from odis.isbiel.ch by isbiel.ch (4.1/SMI-4.1.e) id AA25250; Fri, 30 Jun 95 08:37:20 +0200 Received: from ODIS/SpoolDir by odis.isbiel.ch (Mercury 1.21); 30 Jun 95 08:37:20 +200 Received: from SpoolDir by ODIS (Mercury 1.21); 30 Jun 95 08:37:16 +200 From: BOOS CHRISTOPH 1994M1B Organization: Biel School of Engineering To: amiga-gcc-port@nic.funet.fi Date: Fri, 30 Jun 1995 08:36:46 MET DST Subject: gcc-outputs Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <2ED221024B@odis.isbiel.ch> hi I have a question about gcc - outputs. is there a way to create the prg.i, prg.o and prg (.exe) files at once? I think gcc creates all this files in T: but removes them after creating the exe-file (using gcc -o prg prg.c) I found the -x option but this way i have to call gcc 3 times when i need all outputs. greetings Christoph From amiga-gcc-port-owner@nic.funet.fi Fri Jun 30 21:11:19 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <88981-4>; Fri, 30 Jun 1995 20:59:48 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA12905 (5.65c+/IDA-1.4.4 for ); Fri, 30 Jun 1995 19:56:07 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA21605; Fri, 30 Jun 1995 19:57:34 GMT Date: Fri, 30 Jun 1995 19:57:34 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Amiga GCC Mailling list Cc: Philippe Brand Subject: Baserel support in ld Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII First of all, I've been reconpiling all X11 clients to ix41 and everything has been running smothly (so far). X11 shared library will be delayed due to the fact that i've succeeded (finaly) in running X clients totaly in Virtual Memory, both code and data, making the shared library of little use now... Now for the issue on the subject: I've tried to compile some simple programs with baserel option, mainly because it is very usefull for generating dinamic shared libraries (diferent base for each opener). Worked well in small programs but, once I crosed the line of 64K of (A4) relative data, ld started to complain about "reloc size not supported". OK, next stepp, specify -m68030 option. I was truely hopeing that, once ld was advised of a 68030 processor would generate the 32 bit offsets with no sweat. Didn't work again! Why? I understand that is very dificult to proceed like SAS/C that detects that 64K line was crossed and starts to move data to absolute addressing. Mainly because you may compile two .c files in two different strikes. So, when should one generate assembly for 32 or 16 bit offset ??? I would like to ask, if you think that my exposure of the problems is correct, if you could create a special baserel option that generates ALWAYS 32 bit offset, therefore not limited to 64K. If you are missing the point off this option, I give you a fast one: dinamic shared libraries !! Best Regards, - Pedro Teixeira - PS: Soon I'll release a pack off all the X11 clients I've already compiled to ix41 + and explanation of how to put a X client totaly in VMM + the, so much expected x11.library. From amiga-gcc-port-owner@nic.funet.fi Fri Jun 30 22:03:06 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88999-3>; Fri, 30 Jun 1995 22:00:53 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sRmIT-0004nYC; Fri, 30 Jun 95 13:04 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: ixemul 41.1 released To: ixemul@listserv.funet.fi (ixemul.library maintainers) Date: Fri, 30 Jun 1995 13:04:17 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 321 I just uploaded the ixemul 41.1 release to the new directory on wuarchive.wustl.edu. It should start showing up in dev/gcc on aminet sites shortly. This release should work again on 68000 machines. It also includes 040 versions for people with processors that have been lobotomized by Motorola to have no FPU. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Jul 1 14:47:02 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89027-2>; Sat, 1 Jul 1995 14:45:50 +0300 Received: by colombo.telesys-innov.fr; Sat, 1 Jul 1995 13:48:03 +0100 From: Philippe BRAND Message-Id: <199507011248.NAA02391@colombo.telesys-innov.fr> Subject: Re: gcc-outputs To: BOOSC1@odis.isbiel.ch (BOOS CHRISTOPH 1994M1B) Date: Sat, 1 Jul 1995 13:48:03 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <2ED221024B@odis.isbiel.ch> from "BOOS CHRISTOPH 1994M1B" at Jun 30, 95 08:36:46 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 504 BOOS CHRISTOPH 1994M1B writes: > I have a question about gcc - outputs. > is there a way to create the prg.i, prg.o and prg (.exe) files at > once? I think gcc creates all this files in T: but removes them after > creating the exe-file (using gcc -o prg prg.c) Provided you have enough memory, you can use -pipe option. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sat Jul 1 15:29:12 1995 Received: from cehpx4.cen.uiuc.edu ([128.174.85.5]) by nic.funet.fi with SMTP id <89146-2>; Sat, 1 Jul 1995 15:28:23 +0300 Received: by cehpx4.cen.uiuc.edu id AA01419 (5.67a/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Sat, 1 Jul 1995 07:26:50 -0500 From: Nicolas S Dade Message-Id: <199507011226.AA01419@cehpx4.cen.uiuc.edu> Subject: Re: gcc-outputs To: BOOSC1@odis.isbiel.ch Date: Sat, 1 Jul 1995 07:26:50 -0600 (CDT) Cc: amiga-gcc-port@nic.funet.fi X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 594 BOOS CHRISTOPH 1994M1B writes: > I have a question about gcc - outputs. > is there a way to create the prg.i, prg.o and prg (.exe) files at > once? I think gcc creates all this files in T: but removes them after > creating the exe-file (using gcc -o prg prg.c) You could try making a copy of each file as soon as it was written (while gcc was using it as input to the next stage). I think it would be easiest to use notification to know wait until the file was closed, and then copy the file to a safe place at a higher priority than gcc. -Nicolas Dade / n9rzb / nicolas-dade@uiuc.edu From amiga-gcc-port-owner@nic.funet.fi Sat Jul 1 16:00:57 1995 Received: by nic.funet.fi id <89073-2>; Sat, 1 Jul 1995 16:00:12 +0300 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <95Jul1.160012+0300_eet_dst.89073-2+14@nic.funet.fi> Date: Sat, 1 Jul 1995 16:00:05 +0300 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Sat Jul 1 18:25:14 1995 Received: from asimov.cnam.fr ([163.173.128.6]) by nic.funet.fi with SMTP id <89732-2>; Sat, 1 Jul 1995 18:24:04 +0300 Received: from brunner.cnam.fr (brunner.cnam.fr [163.173.128.15]) by asimov.cnam.fr with ESMTP id RAA01014 (8.6.12/); Sat, 1 Jul 1995 17:23:34 +0200 Received: by brunner.cnam.fr id RAA19978 (8.6.12/); Sat, 1 Jul 1995 17:23:34 +0200 Received: (from daniel@localhost) by brasil.frmug.fr.net (8.6.12/8.6.12) id RAA02709; Sat, 1 Jul 1995 17:23:39 +0200 From: Daniel Verite Message-Id: <199507011523.RAA02709@brasil.frmug.fr.net> Subject: Re: md files (Was: Port GCC to 6811, 6816) To: amiga-gcc-port@nic.funet.fi Date: Sat, 1 Jul 1995 17:23:39 +0200 (MET DST) Cc: panto@intranet.gr In-Reply-To: <9506261437.AA02803@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Jun 26, 95 04:37:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 787 > Damn. I thought it might be easier. > BTW, these microcontrollers have some simillarities with the 68k family > (although not as many registers), so getting an md file for a 68k md file, could help. > Any pointers to a site with these md files? > > panto > Actually, GCC has already been ported for the 6811, but the port hasn't been incorporated into the main archive. You should try an archie with the substring '6811', you would probably find something. If not, you can try to reach the author of the port, Otto Lind (otto@coactive.com) or gcc@coactive.com Or I could mail you the m6811.md, m6811.c, m6811.h files but since I'm missing some parts of the original archive, I'd prefer you try to get the whole thing before. Daniel Verite - daniel@brainstorm.cnam.fr From amiga-gcc-port-owner@nic.funet.fi Sat Jul 1 19:36:29 1995 Received: from asimov.cnam.fr ([163.173.128.6]) by nic.funet.fi with SMTP id <88971-3>; Sat, 1 Jul 1995 19:35:15 +0300 Received: from brunner.cnam.fr (brunner.cnam.fr [163.173.128.15]) by asimov.cnam.fr with ESMTP id SAA01943 (8.6.12/ for ); Sat, 1 Jul 1995 18:35:09 +0200 Received: by brunner.cnam.fr id SAA26215 (8.6.12/ for amiga-gcc-port@lists.funet.fi); Sat, 1 Jul 1995 18:35:09 +0200 Received: (from daniel@localhost) by brasil.frmug.fr.net (8.6.12/8.6.12) id RAA03044 for amiga-gcc-port@lists.funet.fi; Sat, 1 Jul 1995 17:40:33 +0200 From: Daniel Verite Message-Id: <199507011540.RAA03044@brasil.frmug.fr.net> Subject: ld-1.8 as a cross-linker To: amiga-gcc-port@lists.funet.fi Date: Sat, 1 Jul 1995 17:40:32 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 448 Hello, I'm trying to set up ld from binutils-1.8.x as a cross-linker running on a linux box and generating amiga load files The problem is that the PC is little-endian and the Amiga big-endian I didn't notice anything in the #defines or Makefile related to endianness problems So my question is: am I missing something or do I need to patch the whole source to achieve cross-linking ? Any opinion ? Daniel Verite -- daniel@brainstorm.cnam.fr From amiga-gcc-port-owner@nic.funet.fi Sat Jul 1 20:27:34 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <89216-1>; Sat, 1 Jul 1995 20:24:51 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id TAA26218; Sat, 1 Jul 1995 19:22:47 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id SAA11490; Sat, 1 Jul 1995 18:17:44 +0200 Date: Sat, 1 Jul 1995 18:17:44 +0200 From: Niklas Hallqvist Message-Id: <199507011617.SAA11490@linda.appli.se> To: nd8067@coewl.cen.uiuc.edu CC: BOOSC1@odis.isbiel.ch, amiga-gcc-port@nic.funet.fi In-reply-to: <199507011226.AA01419@cehpx4.cen.uiuc.edu> (message from Nicolas S Dade on Sat, 1 Jul 1995 07:26:50 -0600 (CDT)) Subject: Re: gcc-outputs >>>>> "Nicolas" == Nicolas S Dade writes: Nicolas> BOOS CHRISTOPH 1994M1B writes: >> I have a question about gcc - outputs. is there a way to create >> the prg.i, prg.o and prg (.exe) files at once? I think gcc creates >> all this files in T: but removes them after creating the exe-file >> (using gcc -o prg prg.c) Nicolas> You could try making a copy of each file as soon as it was Nicolas> written (while gcc was using it as input to the next Nicolas> stage). I think it would be easiest to use notification to Nicolas> know wait until the file was closed, and then copy the file Nicolas> to a safe place at a higher priority than gcc. Hmm, I think gcc supports saving it's temporary files already, but I don't rememeber the option, and I haven't the source available now. I think it was ssth like -save-temps NH From amiga-gcc-port-owner@nic.funet.fi Sun Jul 2 15:17:57 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <88982-1>; Sun, 2 Jul 1995 15:12:58 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA11729; Sun, 2 Jul 1995 14:12:51 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9507021212.AA11729@decap2.zdv.uni-tuebingen.de> Subject: Re: ld-1.8 as a cross-linker To: daniel@brasil.brainstorm.cnam.fr (Daniel Verite) Date: Sun, 2 Jul 1995 14:12:49 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199507011540.RAA03044@brasil.frmug.fr.net> from "Daniel Verite" at Jul 1, 95 05:40:32 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 362 > > Hello, > > I'm trying to set up ld from binutils-1.8.x as a cross-linker > running on a linux box and generating amiga load files > > The problem is that the PC is little-endian and the Amiga big-endian > I didn't notice anything in the #defines or Makefile related to > endianness problems No chance. You might try the ld from binutils-2.5.2. Jochen From amiga-gcc-port-owner@nic.funet.fi Mon Jul 3 13:58:27 1995 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by nic.funet.fi with SMTP id <89098-1>; Mon, 3 Jul 1995 13:54:45 +0300 Received: from athena.cs.utwente.nl by utrhcs.cs.utwente.nl (5.x/csrelayMX-SVR4_1.1tmp/RB) id AA25588; Mon, 3 Jul 1995 12:54:29 +0200 Received: from kopstoot.cs.utwente.nl by athena.cs.utwente.nl (5.x/csrelay-Sol1.4/RB) id AA01759; Mon, 3 Jul 1995 12:54:21 +0200 Date: Mon, 3 Jul 1995 12:54:21 +0200 From: alberts@cs.utwente.nl (Mert Alberts) Message-Id: <9507031054.AA01759@athena.cs.utwente.nl> To: amiga-gcc-port@nic.funet.fi Subject: Stuff for the FAQ Dear all, I would like to suggest the following additions to the FAQ, since they seem to answer two typical problems encountered when first installing gcc/g++ 2.63. I think it would be a good idea to upload the FAQ (thanks Lynn) to aminet (in dev/gcc) as well. I Simple manual installation procedure: ------------------------------------ When installing gcc263 two weeks ago on my A4000/30, it turned out that the installer script from aminet is somewhat buggy (so I'm told and experienced myself). What worked well for me was to simply unpack the following archives from aminet with "lha x file.lha", resulting in the main package being installed in the appropriate tree structure. (For the 020-version) gcc263-readme.lha holds readmes files (include installation notes). gcc263-base.lha basic gcc distribution, hold necessary files. gcc263-inclib.lha headers and libraries. gcc263-c-020.lha C++ compiler, headers and libraries. gcc263-c++-020.lha 68020+68881 versions of C++ compiler. gcc263-objc-020.lha 68020+68881 versions of Objective-C compiler. gcc263-doc.lha Gcc AmigaGuide(tm) documents & manpages. To get the os-include and os-lib files in the correct format (!) and recognised by gcc, you simply download them from : ftp.dfv.rwth-aachen.de in /cdrom/bbs/cbm/os-include-bin etc. and unpack them in the appropriate directories. The whole set of amiga specific headers and libs is readily available at this site, with a copyright notice about "personal use only". (So you don't need to use genxx or fd2inline !!). I tried some examples from the ACM and they worked fine. II Getting g++ to work: -------------------- Regarding the use of g++ I suggest the following remarks by Kriton Kyrimis and Bert Winkelmann are added to the FAQ: Kriton wrote: > From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) > To: alberts@cs.utwente.nl > Cc: amiga-gcc-port@lists.funet.fi > Subject: Re: Serious g++ problem ... > .... > > Hi Mert (Mert Alberts), in <9506291106.AA14391@athena.cs.utwente.nl> > on Jun 29 you wrote: >> My main reason for installing the 020-versions of the gcc 2.63 archive >> on my A4000/30 with FPU, was to have a full c++ compiler (apart from >> the fact that I love the concept of public software like GNU and TeX >> ;)). After installing everything manually (the installer script seemed >> to have some bug) the "plain" gcc compiler seems to work fine, but >> .... the g++ compiler crashes on even the simplest of programs. > > Your test program compiles fine on my 2000/Fusion-Forty. > One thing to check is the size of your default stack: I managed to > crash g++by reducing my stack to 4000 (this was during linking, > however). With my usual setting of 20000 I had no problem (stackmon > indicates that your program needs ~15K of stack to compile and link). > >I hope this helps, >-- > Kriton (UUCP: pythia!theseas!kriton!kyrimis) > (INTERNET: kyrimis@theseas.ntua.gr) > (WWW: http://www.hpcl.cti.gr/~kyrimis Bert wrote: > From: B.Winkelmann@bamp.berlinet.de (Bert Winkelmann) > Subject: Serious g++ problem ... > Date: Thu, 29 Jun 1995 20:49:51 +0200 > ... > > Hi Mert. > >> either. The other thing I tried was to change the GCCSTACK value (both >> in the gnu/envarc directory and in ENVARC:), from 350K to 750K, and to >> 1M. Same problem as before. > > The env-variable GCCSTACK in version 2.6.3 works AFAIK only with the > c-part, but not with g++. I hope this problem is gone for 2.7.0 with > the automatic stack-extension. For g++-2.6.3 I use a stack of > 40000-60000 for little sources. > > Bert. I tried the above suggestions and they solved the problem. ------------ Thanks to all the people who make this wonderful software available to the Amiga community and provide such great support for FREE. Regards, Mert. -- L.K. Alberts Tel: +31 53 89 4291/3690 University of Twente Department of Computer Science Fax: +31 53 339605 P.O. Box 217 7500 AE Enschede The Netherlands E-mail: alberts@cs.utwente.nl From amiga-gcc-port-owner@nic.funet.fi Mon Jul 3 15:30:22 1995 Received: by nic.funet.fi id <89189-1>; Mon, 3 Jul 1995 15:27:49 +0300 From: Leonard Norrgard To: panto@intranet.GR CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9506261133.073010@pcpanto.intranet.gr> Subject: Re: md files (Was: Port GCC to 6811, 6816) Message-Id: <95Jul3.152749+0300_eet_dst.89189-1+27@nic.funet.fi> Date: Mon, 3 Jul 1995 15:27:42 +0300 GCC was written with some assumptions in mind, assumptions that microcontrollers usually fail to meet. In other words, the internal architecture of GCC depends on CPU features that are not available on most microcontrollers. There are exceptions, Cygnus ported GCC to the Hitachi H300 (I think), and that port is available for ftp on the net. But then again, the H300 is a pretty complete CPU. From amiga-gcc-port-owner@nic.funet.fi Mon Jul 3 15:47:56 1995 Received: by nic.funet.fi id <89107-2>; Mon, 3 Jul 1995 15:47:12 +0300 From: Leonard Norrgard To: si215603@ci.uminho.pt CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9506291226.AA17199@pessoa.ci.uminho.pt> (si215603@ci.uminho.pt) Subject: Re: INFo about Electronics sites Message-Id: <95Jul3.154712+0300_eet_dst.89107-2+38@nic.funet.fi> Date: Mon, 3 Jul 1995 15:47:09 +0300 > I would like to know where to find sites with info files > describing functionality of certain types of chips like: > > PIC16C84 > (The PIC series is a microcontroller made by Microchip). ftp.funet.fi:/pub/microprocs/pic, for example... There are pointers to the PIC mailing list as well as to the manufacturers (Microchip) WWW site there as well. Happy hacking. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Mon Jul 3 16:47:16 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89006-3>; Mon, 3 Jul 1995 16:45:26 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA05168 (5.65c+/IDA-1.4.4 for ); Mon, 3 Jul 1995 15:42:57 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA07877; Mon, 3 Jul 1995 15:44:21 GMT Date: Mon, 3 Jul 1995 15:44:21 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Philippe BRAND Cc: BOOS CHRISTOPH 1994M1B , Amiga-Gcc Liste Subject: Re: gcc-outputs the gcc option you look In-Reply-To: <199507011248.NAA02391@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII BOOS CHRISTOPH 1994M1B writes: > I have a question about gcc - outputs. > is there a way to create the prg.i, prg.o and prg (.exe) files at > once? I think gcc creates all this files in T: but removes them after > creating the exe-file (using gcc -o prg prg.c) I quote the GCC manual: `-save-temps' Store the usual "temporary" intermediate files permanently; place them in the current directory and name them based on the source file. Thus, compiling `foo.c' with `-c -save-temps' would produce files `foo.i' and `foo.s', as well as `foo.o'. End quote. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Mon Jul 3 16:47:41 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89130-4>; Mon, 3 Jul 1995 16:45:10 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 3 Jul 1995 15:44:51 +0200 Received: from mammern.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02778; Mon, 3 Jul 95 15:44:49 +0200 Date: Mon, 3 Jul 95 15:44:49 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9507031344.AA02778@inf-wiss.uni-konstanz.de> To: l36599@alfa.ist.utl.pt Subject: Re: Baserel support in ld Cc: amiga-gcc-port@nic.funet.fi Hi, > X11 shared library will be delayed due to the fact that i've > succeeded (finaly) in running X clients totaly in Virtual Memory, > both code and data, making the shared library of little use now... Having VM doesn't make shared libraries useless at all! Why do you think are there shared C and X libs on Sun's UNIX machines (as an example)? Of course, at first, it's better to have X than not to have it, because the shared library implementation requires more work than the simple one... Joerg Hoehle hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon Jul 3 17:24:45 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <88992-1>; Mon, 3 Jul 1995 17:22:55 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA06158 (5.65c+/IDA-1.4.4 for ); Mon, 3 Jul 1995 16:22:14 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA12498; Mon, 3 Jul 1995 16:23:51 GMT Date: Mon, 3 Jul 1995 16:23:51 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Joerg-Cyril Hoehle Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Baserel support in ld In-Reply-To: <9507031344.AA02778@inf-wiss.uni-konstanz.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 3 Jul 1995, Joerg-Cyril Hoehle wrote: > Hi, > > Having VM doesn't make shared libraries useless at all! Why do you > think are there shared C and X libs on Sun's UNIX machines (as an > example)? > > Of course, at first, it's better to have X than not to have it, because > the shared library implementation requires more work than the simple > one... Hey, don't get me wrong! I was not trying to say that shared libraries were useless! I'm still working on it for any reason... The thing is that I need X to work! Before I had it on VMM with success things were quite dark because I had no memory to work : Phisical memory exaustes quite fast. I began to work on x11.library because of this. I could reduce Xclient executable size up to 1/2Meg! Now, that I solved the other problem I can WORK! X11.library still is valid for all the other reasons, but it is not URGENT. Regards, - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Mon Jul 3 18:25:35 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <88936-2>; Mon, 3 Jul 1995 18:24:30 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA14095; Mon, 3 Jul 1995 17:23:58 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9507031523.AA14095@decap2.zdv.uni-tuebingen.de> Subject: Re: Stuff for the FAQ To: alberts@cs.utwente.nl (Mert Alberts) Date: Mon, 3 Jul 1995 17:23:56 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9507031054.AA01759@athena.cs.utwente.nl> from "Mert Alberts" at Jul 3, 95 12:54:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 736 Hello, Mert, > When installing gcc263 two weeks ago on my A4000/30, it turned out > that the installer script from aminet is somewhat buggy (so I'm > told and experienced myself). What worked well for me was to simply > unpack the following archives from aminet with "lha x file.lha", > resulting in the main package being installed in the appropriate tree > structure. What bugs? Please tell me, so that I can fix them. (Should help more than describing manual installation. :-) > ftp.dfv.rwth-aachen.de in /cdrom/bbs/cbm/os-include-bin etc. It is not a good idea, to publish such links. As you see in the path, this is a CD-Rom. You never know, if the right CD is mounted or not. (It definitely *will* change.) Jochen From amiga-gcc-port-owner@nic.funet.fi Mon Jul 3 19:42:31 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89777-4>; Mon, 3 Jul 1995 19:41:26 +0300 Received: by theseas.ntua.gr with UUCP; Mon, 3 Jul 1995 19:44:21 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07pk@kriton.UUCP>; Mon, 3 Jul 95 19:36:46 EET Date: Mon, 3 Jul 95 19:36:46 EET Message-Id: <9507031736.07pk@kriton.UUCP> Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 902 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: amiga-gcc-port@lists.funet.fi Subject: ixemul.library 41.1 problems I just installed ixemul.library 41.1 (68040+FPU version) and I noticed a couple of problems: 1. Whenever I start a program, I get four "BYTE-READ from 00000000" enforcer hits in ramlib. This may or may not have been happening with previous versions. 2. When I ran a certain program that I had linked with the 41.0 startup code and libraries, the program would not see its CLI arguments (it thought argc < 2). When I recompiled and liked it with the 41.1 startup code and libraries, the program worked fine. This only happened with this one program, so the problem may not be reproducible. :-( -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If they should break through, run as if something very nasty were after you, because something very nasty will be after you." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Jul 3 20:20:50 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88931-2>; Mon, 3 Jul 1995 20:19:21 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sSqAD-0004nYC; Mon, 3 Jul 95 11:24 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ixemul.library 41.1 problems To: kyrimis@theseas.ntua.gr Date: Mon, 3 Jul 1995 11:24:09 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9507031736.07pk@kriton.UUCP> from "Kriton Kyrimis" at Jul 3, 95 07:36:46 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1841 > I just installed ixemul.library 41.1 (68040+FPU version) and I noticed a > couple of problems: This is the same version (040+fpu) that I run here. > 1. Whenever I start a program, I get four "BYTE-READ from 00000000" enforcer > hits in ramlib. This may or may not have been happening with previous > versions. I haven't seen this problem so we'll either need to wait and see if it happens for anyone else or is just reproducible only in your environment for some reason. > 2. When I ran a certain program that I had linked with the 41.0 startup code > and libraries, the program would not see its CLI arguments (it thought > argc < 2). When I recompiled and liked it with the 41.1 startup code and > libraries, the program worked fine. This only happened with this one > program, so the problem may not be reproducible. :-( This may be related to the magic that ixemul uses to determine whether or not a program it is starting is one that uses ixemul itself. See the comments in crt0.c and execve.c. It sounds like the executable that failed was linked with the 41.0 crt0.o, which has a 68020+ instruction as the first instruction, shifting the location of the "magic number" that execve is looking for. The code that handles this in execve got reorganized between 41.0 and 41.1 to account for yet another pattern that was added in 41.1 when the first instruction changed again, back to 68000 compatible one. It is possible that this code is somehow broken now for executables linked with 41.0 crt0.o but using 41.1 ixemul.library. This would result in ixemul.library taking a different branch through the argument processing code, which might be what the problem was. I'll try to confirm that the 41.1 library handles all of the possible permutations of startup instruction and magic number location. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Jul 4 08:39:41 1995 Received: from helios.intranet.GR ([146.124.14.200]) by nic.funet.fi with SMTP id <89261-1>; Tue, 4 Jul 1995 08:38:11 +0300 Received: from pilits.intranet.gr by helios.intranet.GR with SMTP (8.6.11/ICM-mailhub-1.0) id IAA03102; Tue, 4 Jul 1995 08:36:39 +0300 From: panto@intranet.GR Received: from pcpanto.intranet.gr by pilits.intranet.gr (4.1/SMI-4.1) id AA02119; Tue, 4 Jul 95 08:39:31 +0300 To: amiga-gcc-port@nic.funet.fi Subject: Re: Re: md files (Was Port GCC to 6811, 6816) Date: Tue, 4 Jul 95 06:42:18 GMT Message-Id: <9507040642.123194@pcpanto.intranet.gr> X-Mailer: SelectMAIL 1.1 > Leonard Norrgard wrote > > GCC was written with some assumptions in mind, assumptions that > microcontrollers usually fail to meet. In other words, the internal > architecture of GCC depends on CPU features that are not available > on most microcontrollers. > There are exceptions, Cygnus ported GCC to the Hitachi H300 (I > think), and that port is available for ftp on the net. But then > again, the H300 is a pretty complete CPU. By the way I've found the gcc port to 6811, it's located at ftp.ee.ualberta.ca/pub/motorola/68hc11/gcc. As for the 6811/6816 microcontrollers are pretty complete CPU's, and the 6816 is far more powerful than the 6811. So I'll try port gcc to 6186 now. IMHO the assumptions that are needed for a processor to be supported by gcc are o A stack architecture o Enough memory (some microcontrollers can't have _any_ external RAM. o More than a couple of registers. (I could be wrong though, fill in the list if you fill like it). See ya. panto From amiga-gcc-port-owner@nic.funet.fi Tue Jul 4 12:02:09 1995 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by nic.funet.fi with SMTP id <88949-4>; Tue, 4 Jul 1995 12:00:50 +0300 Received: from athena.cs.utwente.nl by utrhcs.cs.utwente.nl (5.x/csrelayMX-SVR4_1.1tmp/RB) id AA21576; Tue, 4 Jul 1995 11:00:33 +0200 Received: from kopstoot.cs.utwente.nl by athena.cs.utwente.nl (5.x/csrelay-Sol1.4/RB) id AA08278; Tue, 4 Jul 1995 11:00:16 +0200 Date: Tue, 4 Jul 1995 11:00:16 +0200 From: alberts@cs.utwente.nl (Mert Alberts) Message-Id: <9507040900.AA08278@athena.cs.utwente.nl> To: zrawi01@decap2.zdv.uni-tuebingen.de Subject: Re: Stuff for the FAQ In-Reply-To: Mail from 'zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann)' dated: Mon, 3 Jul 1995 17:23:56 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi Hi Jochen, > What bugs? Please tell me, so that I can fix them. (Should help more > than describing manual installation. :-) After using the installation script, the call "gcc -o simple simple.c" resulted in an error message from the precompiler. If I remember correctly, it was something like: "wrong option" or "cannot find simple.c". Judging from the discussion in this mailing-list, several people encountered this problem, but there should be an improved version of the installer script (by you?) available by now. Mine was from aminet (at src.doc.ic.ac.uk); I can mail it to you if you want to check the version. By the way, I didn't mean to put down your effort in writing the script. On the contrary, it's great that people like you go to the trouble of writing autmatic installation scripts for complex packages like gcc. > It is not a good idea, to publish such links. As you see in the path, > this is a CD-Rom. You never know, if the right CD is mounted or not. > (It definitely *will* change.) How about making the os-specific includes and libs accessible through aminet? Maybe I'm missing some of the subtle details regarding the distribution of Commodore-copyrighted includes, but making the CD-Rom publically accessible apparently allowed. So why not use aminet for that as well? Regards, Mert. From amiga-gcc-port-owner@nic.funet.fi Tue Jul 4 14:30:15 1995 Received: from decap2.zdv.uni-tuebingen.de ([134.2.1.24]) by nic.funet.fi with SMTP id <88971-2>; Tue, 4 Jul 1995 14:27:05 +0300 Received: by decap2.zdv.uni-tuebingen.de (5.65/DEC-Ultrix/4.3) id AA15045; Tue, 4 Jul 1995 13:26:48 +0200 From: zrawi01@decap2.zdv.uni-tuebingen.de (Jochen Wiedmann) Message-Id: <9507041126.AA15045@decap2.zdv.uni-tuebingen.de> Subject: Re: Stuff for the FAQ To: amiga-gcc-port@nic.funet.fi Date: Tue, 4 Jul 1995 13:26:47 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2091 Forwarded message: >From zrawi01 Tue Jul 4 13:24:22 1995 Subject: Re: Stuff for the FAQ To: alberts@cs.utwente.nl (Mert Alberts) Date: Tue, 4 Jul 1995 13:24:22 +0200 (MET DST) In-Reply-To: <9507040900.AA08278@athena.cs.utwente.nl> from "Mert Alberts" at Jul 4, 95 11:00:16 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1735 Hello, Mert, > After using the installation script, the call "gcc -o simple simple.c" > resulted in an error message from the precompiler. If I remember > correctly, it was something like: "wrong option" or "cannot find > simple.c". Judging from the discussion in this mailing-list, several > people encountered this problem, but there should be an improved > version of the installer script (by you?) available by now. Mine was > from aminet (at src.doc.ic.ac.uk); I can mail it to you if you want to > check the version. This sounds like a known problem, which *should* indeed be fixed by the current version. However, please send me your version, so that I can check it. If it does, the problem should be a missing character in the modified specs file. > By the way, I didn't mean to put down your effort in writing the > script. On the contrary, it's great that people like you go to the > trouble of writing autmatic installation scripts for complex packages > like gcc. I did not understand things this way. :-) I was just looking for possible problems with the installer script. The error above showed me, how much trouble can be avoided. But, of course, only if I know. > How about making the os-specific includes and libs accessible through > aminet? Maybe I'm missing some of the subtle details regarding the > distribution of Commodore-copyrighted includes, but making the CD-Rom > publically accessible apparently allowed. So why not use aminet for > that as well? I'm not a lawyer. But, as far as I know, distributing the includes is bound to a licene. The CD-Rom has this license (costs 1 or 2$ per CD), Aminet doesn't. This is my impression, probably someone else has another opinions. Regards, Jochen From amiga-gcc-port-owner@nic.funet.fi Tue Jul 4 16:10:23 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <89275-2>; Tue, 4 Jul 1995 16:06:56 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HSH817E60090Q7TO@LEON.CTI.GR>; Tue, 4 Jul 1995 16:03:17 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA10715; Tue, 4 Jul 95 16:07:19 +0300 Date: Tue, 04 Jul 1995 16:07:18 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: ixprefs 1.2 uploaded on aminet To: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9507041307.AA10715@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 936 I just uploaded the latest version of ixprefs. This version will not complain if you have the latest version (41.1), of ixemul.library plus there are some new goodies. Here's the extract from the history section of the docs: * Added a UNIX-style CLI interface using getopt_long(). * Modified showrequester() to print messages on stderr if the ixprefs window is not open, so that no requesters pop up when the CLI interface is used. * Updated ixemul.library version check, so that the program now runs under both version 41.0 and 41.1 without producing a warning. * Fixed the dates in this section. Not that anyone cares, but the previous versions of this program were written in June, not May! * Updated the documentation. Enjoy! -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I've had enough excitement for a while; right now, a little boredom wouldn't be amiss!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jul 4 16:14:03 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <89929-1>; Tue, 4 Jul 1995 16:13:18 +0300 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA08067; Tue, 4 Jul 1995 15:13:10 +0200 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA19470; Tue, 4 Jul 95 15:13:09 +0200 From: isthesin@TechFak.Uni-Bielefeld.DE (Stephan Thesing) Message-Id: <9507041513.ZM19468@moos.TechFak.Uni-Bielefeld.DE> Date: Tue, 4 Jul 1995 15:13:08 +0200 In-Reply-To: Pedro Miguel Sequeira Teixeira "Baserel support in ld" (Jun 30, 19:57) References: X-Mailer: Z-Mail (2.1.5 09aug93) To: Pedro Miguel Sequeira Teixeira Subject: Re: Baserel support in ld Cc: amiga-gcc-port@nic.funet.fi On Jun 30, 19:57, Pedro Miguel Sequeira Teixeira wrote: > Subject: Baserel support in ld > > First of all, I've been reconpiling all X11 clients to ix41 > and everything has been running smothly (so far). > X11 shared library will be delayed due to the fact that i've > succeeded (finaly) in running X clients totaly in Virtual Memory, > both code and data, making the shared library of little use now... > > Now for the issue on the subject: I've tried to compile > some simple programs with baserel option, mainly because it is > very usefull for generating dinamic shared libraries (diferent base > for each opener). Worked well in small programs but, once I crosed > the line of 64K of (A4) relative data, ld started to complain about > "reloc size not supported". OK, next stepp, specify -m68030 option. > I was truely hopeing that, once ld was advised of a 68030 processor > would generate the 32 bit offsets with no sweat. Didn't work again! > Why? The problem is that up to 64kB of data you can use a 16bit offset (relative to A4) to address the data. After this you need 32bit offsets (available on >=mc68020 only) The old ld does not support more than 16bit offsets and in fact I am not sure if gcc produces the long format for these (e.g. instead of 'movel a4@(_i:W),d0' an 'movel a4@(_i:L),d0' to address variable 'i'. The linker that comes with binutils2.5.2 does in principle support these offsets but is still an alpha release and I have no time left to work on it to complete it. > I understand that is very dificult to proceed like SAS/C that > detects that 64K line was crossed and starts to move data to absolute > addressing. Mainly because you may compile two .c files in two different > strikes. So, when should one generate assembly for 32 or 16 bit offset ??? > I would like to ask, if you think that my exposure of the problems > is correct, if you could create a special baserel option that generates > ALWAYS 32 bit offset, therefore not limited to 64K. If you are missing > the point off this option, I give you a fast one: dinamic shared > libraries !! > > Best Regards, > - Pedro Teixeira - > > PS: Soon I'll release a pack off all the X11 clients I've already > compiled to ix41 + and explanation of how to put a X client totaly in VMM > + the, so much expected x11.library. > >-- End of excerpt from Pedro Miguel Sequeira Teixeira -- =============================================== = Stephan Thesing = = AG Praktische Informatik = = Technische Fakult"at = = Universit"at Bielefeld = = EMail: isthesin@techfak.uni-bielefeld.de = =---------------------------------------------= = Wer den Spruch erfunden hat : = = "So einfach, wie einem Kind den Lolly = = wegzunehmen", hat noch nie versucht, = = seinem Neffen ein Bonbon zu stibitzen. = =============================================== From amiga-gcc-port-owner@nic.funet.fi Tue Jul 4 17:27:52 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89133-2>; Tue, 4 Jul 1995 17:26:08 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sT9vs-0004nYC; Tue, 4 Jul 95 08:30 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Stuff for the FAQ To: alberts@cs.utwente.nl (Mert Alberts) Date: Tue, 4 Jul 1995 08:30:40 -0700 (MST) Cc: zrawi01@decap2.zdv.uni-tuebingen.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <9507040900.AA08278@athena.cs.utwente.nl> from "Mert Alberts" at Jul 4, 95 11:00:16 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 847 > How about making the os-specific includes and libs accessible through > aminet? Maybe I'm missing some of the subtle details regarding the > distribution of Commodore-copyrighted includes, but making the CD-Rom > publically accessible apparently allowed. So why not use aminet for > that as well? The former CBM was kind enough to give me written permission to include the CBM files on my CD-ROM distributions, and grant unlimited copying off the CD for personal use. However the restrictions are that such copies cannot be redistributed. In summary, it is allowed to make a copy directly off the CD, and you don't even have to have personal possession of the CD (which is why mounting it for ftp access is OK), but once you've made the copy you cannot let anyone else make copies from *that* copy. All copying has to be from the CD. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Jul 4 18:07:48 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89105-4>; Tue, 4 Jul 1995 18:06:47 +0300 Received: by colombo.telesys-innov.fr; Tue, 4 Jul 1995 17:09:00 +0100 From: Philippe BRAND Message-Id: <199507041609.RAA23657@colombo.telesys-innov.fr> Subject: New gcc-2.7.0 C version available To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Tue, 4 Jul 1995 17:09:00 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1045 New 2.7.0 C version is available on both my site and nic.funet.fi. This should be final version. It was linked with ixemulv41.1 (not compiled, just relinked so I didn't test this particular version, didn't have time yesterday night). ixemul.library v41.1 68000 version and associated crt and libc.a are also into archive. Please test it and report. Then I should be able to build a new distribution for Aminet, as an upgrade. Script-makers are very welcome here... in order to write upgrade script ;-) It should be pretty easy. Q: Do you want to overwrite your gcc version with new one ? - no, then rename gnu:bin/gcc gnu:bin/gcc.old etc... - yes, then delete old version, and gnu:lib/gcc-lib/mc68000-cbm-amigados/2.6.3 (or mc68020). Move libraries libgcc.a from lib: to lib:gcc-lib/mc680x0-cbm-amigados/2.6.3 Extract from archive. This *should* be enough. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Jul 4 19:33:14 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89176-2>; Tue, 4 Jul 1995 19:32:02 +0300 Received: by theseas.ntua.gr with UUCP; Tue, 4 Jul 1995 19:07:24 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07q5@kriton.UUCP>; Tue, 4 Jul 95 19:00:15 EET Date: Tue, 4 Jul 95 19:00:15 EET Message-Id: <9507041700.07q5@kriton.UUCP> In-Reply-To: (from fnf@amigalib.com (Fred Fish)) (at Mon, 3 Jul 1995 11:24:09 -0700 (MST)) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1166 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: fnf@amigalib.com Cc: amiga-gcc-port@lists.funet.fi Subject: Re: ixemul.library 41.1 problems Hi Fred (Fred Fish), in on Jul 3 you wrote: > > 1. Whenever I start a program, I get four "BYTE-READ from 00000000" enforcer > > hits in ramlib. This may or may not have been happening with previous > > versions. > > I haven't seen this problem so we'll either need to wait and see if it > happens for anyone else or is just reproducible only in your > environment for some reason. I tried removing everything from my User-Startup and my WBStartup directory, and the problem persists. On the other hand, for enforcer to run on the Fusion-Forty, I have to run a program called movemh, which is supposed to "Move CHIP-mem MemHeader to FAST-mem", whatever that means. (If I don't, I get tons of enforcer hits). This may indicate that the problem is caused by something that is not covered by movemh, and I'm stuck. If there is another Fusion-Forty user on the list, could they check if they also have this problem? Thanks, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I'm what monsters have nightmares about!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jul 4 20:21:15 1995 Received: from epsilon.qmw.ac.uk ([138.37.6.3]) by nic.funet.fi with SMTP id <89223-2>; Tue, 4 Jul 1995 20:20:34 +0300 Received: from canary.dcs.qmw.ac.uk by epsilon.qmw.ac.uk with SMTP-DNS (PP) id <23875-0@epsilon.qmw.ac.uk>; Tue, 4 Jul 1995 18:19:56 +0100 Received: from elgreco.dcs.qmw.ac.uk [192.135.231.232] by canary.dcs.qmw.ac.uk (8.6.12/QMW-server-2.4s) with SMTP; for ""; poster "Liu "; id SAA04981; Tue, 4 Jul 1995 18:19:07 +0100 From: Liu Message-ID: <199507041719.SAA04981@canary.dcs.qmw.ac.uk> Full-Name: Liu Received: locally by elgreco.dcs.qmw.ac.uk (4.1/QMW-client-3.2b); for "amiga-gcc-port@nic.funet.fi"; poster "wmliu168"; id AA02374; Tue, 4 Jul 95 18:22:33 BST Subject: * Test Post Ignore * To: amiga-gcc-port@nic.funet.fi Date: Tue, 4 Jul 1995 18:22:32 +0100 (BST) Priority: Testing Message X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1298 -- Raymond W.M.Liu Esq. BSc.(Hons.) ____________________________________________________________________________ | | | 1994/95 : MSc. Adv. Methods in Comp. Sci. (Distributed & Parallel Sys.) | |____________________________________________________________________________| | | | | Internet : wmliu168@dcs.qmw.ac.uk | AmigaOS - Pre-emptive multi-tasking | | Internet : zgac3024@qmw.ac.uk | + s/ware MS-DOS/Windows emu... | | | + s/ware Macintosh MacOS emu... _ | | Informatics Teaching Laboratory | + etc....(ALL Pre-Emptively) // | | Queen Mary & Westfield Collefe | _ // | | University of London | "..Taking a big Byte out \\ // | | | of a Big Blue Apple..." \X/ | | Tel.: +44 171 975 5252 |_______________________________________| | (Direct) 0700-0200 UTC | Tartan desires... |_#_#_#_#_#| |____________________________________|____________________________|_#_#_#_#_#| All standard disclaimers apply .sig design (c) Copyright by W.M.Liu, 1995. From amiga-gcc-port-owner@nic.funet.fi Tue Jul 4 20:32:42 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89324-1>; Tue, 4 Jul 1995 20:32:00 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26574-2>; Tue, 4 Jul 1995 19:31:33 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209229-1>; Tue, 4 Jul 1995 19:31:21 +0100 Subject: OS-Includes distribution From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Tue, 4 Jul 1995 19:31:20 +0200 (MESZ) Precedence: ic.funet.fi In-Reply-To: from "Fred Fish" at Jul 4, 95 08:30:40 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 988 Message-Id: <95Jul4.193121+0100mesz.209229-1+1530@hphalle0.informatik.tu-muenchen.de> > copies cannot be redistributed. In summary, it is allowed to make a > copy directly off the CD, and you don't even have to have personal > possession of the CD (which is why mounting it for ftp access is OK), > but once you've made the copy you cannot let anyone else make copies > from *that* copy. All copying has to be from the CD. ... which is an interesting concept, since there's no way to tell where a file came from. I could copy them from a friend who copied it from a friend who copied it from the CD. Provided I know someone who owns the CD, how does one prove that I violated the distribution conditions? Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Tue Jul 4 21:52:45 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <89006-4>; Tue, 4 Jul 1995 21:51:36 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id UAA20575; Tue, 4 Jul 1995 20:39:24 +0200 From: Jochen Wiedmann Message-Id: <199507041839.UAA20575@iss1.neckar-alb.de> Subject: Re: ixprefs 1.2 uploaded on aminet To: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Date: Tue, 4 Jul 1995 20:39:23 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9507041307.AA10715@hpcl.cti.gr> from "Kriton Kyrimis" at Jul 4, 95 04:07:18 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 134 Hello, how about a font sensitive version? (Note, that GadToolsBox, which you are using can do that for you.) Greetings, Jochen From amiga-gcc-port-owner@nic.funet.fi Tue Jul 4 23:21:02 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89220-3>; Tue, 4 Jul 1995 23:18:52 +0300 Received: by theseas.ntua.gr with UUCP; Tue, 4 Jul 1995 23:18:25 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07qk@kriton.UUCP>; Tue, 4 Jul 95 23:13:17 EET Date: Tue, 4 Jul 95 23:13:17 EET Message-Id: <9507042113.07qk@kriton.UUCP> In-Reply-To: <199507041839.UAA20575@iss1.neckar-alb.de> (from Jochen Wiedmann ) (at Tue, 4 Jul 1995 20:39:23 +0200 (MET DST)) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 668 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: wiedmann@Neckar-Alb.DE Cc: amiga-gcc-port@lists.funet.fi Subject: Re: ixprefs 1.2 uploaded on aminet Hi Jochen (Jochen Wiedmann), in <199507041839.UAA20575@iss1.neckar-alb.de> on Jul 4 you wrote: > how about a font sensitive version? (Note, that GadToolsBox, which > you are using can do that for you.) Let me guess: you are running version 1.0; ixprefs has been font sensitive since version 1.1, which was released only three days after version 1.0. It was easy to have missed it. Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "There's nothing like a nice walk in the countryside." "And this is nothing like a nice walk in the countryside!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Jul 5 10:53:31 1995 Received: from helios.intranet.GR ([146.124.14.200]) by nic.funet.fi with SMTP id <88931-3>; Wed, 5 Jul 1995 10:52:19 +0300 Received: from pilits.intranet.gr by helios.intranet.GR with SMTP (8.6.11/ICM-mailhub-1.0) id KAA20292; Wed, 5 Jul 1995 10:51:45 +0300 From: panto@intranet.GR Received: from pcpanto.intranet.gr by pilits.intranet.gr (4.1/SMI-4.1) id AA04611; Wed, 5 Jul 95 10:53:25 +0300 To: amiga-gcc-port@nic.funet.fi Subject: Re: Re: md files (Was 6816/6811 GCC) Date: Wed, 5 Jul 95 08:56:10 GMT Message-Id: <9507050856.0A3614@pcpanto.intranet.gr> X-Mailer: SelectMAIL 1.1 > Leonard Norrgard wrote > > GCC was written with some assumptions in mind, assumptions that > microcontrollers usually fail to meet. In other words, the internal > architecture of GCC depends on CPU features that are not available > on most microcontrollers. > There are exceptions, Cygnus ported GCC to the Hitachi H300 (I > think), and that port is available for ftp on the net. But then > again, the H300 is a pretty complete CPU. I've found the gcc port to 6811, it's located at ftp.ee.ualberta.ca/pub/motorola/68hc11/gcc. The 6811/6816 microcontrollers are pretty complete CPU's, and the 6816 is far more powerful than the 6811. IMHO the assumptions that are needed for a processor to be supported by gcc are o A stack architecture o Enough memory (some microcontrollers can't have _any_ external RAM. o More than a couple of registers. (I could be wrong though, fill in the list if you fill like it). See ya. panto From amiga-gcc-port-owner@nic.funet.fi Thu Jul 6 01:47:14 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <89006-1>; Thu, 6 Jul 1995 01:44:48 +0300 Received: from lysita.lysator.liu.se (lysita.lysator.liu.se [130.236.254.153]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id AAA28423; Thu, 6 Jul 1995 00:43:49 +0200 Received: (nisse@localhost) by lysita.lysator.liu.se (8.6.11/8.6.11) id AAA03912; Thu, 6 Jul 1995 00:44:09 +0200 Date: Thu, 6 Jul 1995 00:44:09 +0200 Message-Id: <199507052244.AAA03912@lysita.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: l36599@alfa.ist.utl.pt CC: niklas@appli.se, hoehle@inf-wiss.uni-konstanz.de, amiga-gcc-port@nic.funet.fi In-reply-to: (message from Pedro Miguel Sequeira Teixeira on Wed, 28 Jun 1995 19:14:21 +0000 (GMT)) Subject: Re: fork() with MMU? VMMs problem... From: Pedro Miguel Sequeira Teixeira > Of course, allocations through the Unix-compatibility library (ixemul) > won't be usable for AmigaDOS IPC/IO, you have to use AmigaDOS memory > allocation routines for that. Anyway, ixemul clients are not really > supposed to be aware of Amiga-specific routines anyway. It's also > clear that MMU pages shouldn't be shared unless vfork or shared memory > (which aren't in ixemul yet, yes?) uses them. Great ! Arent you folks forgeting something? ixemul clients, up to today, are not hard to flush totaly into Virtual Memory, both code and data. If ixemul would, sudently, become to be a PMMU manager, most probably these clients would stop using VMM or, even worse, the whole system whould crash!!!!!! Is there anybody on this list that is familiar with the details of VMM? There is a library, vmm.library, that should give you an Alloc()-like interface to the virtual memory facilities. However, this is not enough here, as VMM (as far as I know) only supports global, non-protected, virtual memory. How difficult would it be to add the following to vmm.library? o Support for different VM-tables for different processes. o Library functions to allocate and manage single, protected, pages. If this was done, ixemul could test if vmm.library is installed, and if so use the gnulibc malloc() functions, just calling vmm.library to get new pages. Then the memory would look like this: To non-ixemul programs, and to the AmigaOS: All memory is transparently mapped, except for the pages that are used for VM, these pages should be protected, and are impossible both to read and write. All these programs share a common MMU page table. To ixemul clients: The memory above is also here transparently mapped, to make it compatible with the normal amiga system, messaging etc. Of course, memory allocated from exec will all be in this shared memory area. Then, in some higher, unused area of the address space, the VM for this process lives. Memory allocated by ixemul malloc() is in this area. Thus all ixemul programs have their own page table. These must be switched by the tc_launch etc stubs installed by ixemul. All page tables should be created and managed by vmm.library, not by ixemul. ixemul just requests pages, and installes the generated pagetables at taskswitch. The memory map would look as follows: --------- Non-shared, protected, virtual memory, only for ixemul programs. --------- Shared, AmigaOS memory, transparently mapped for all tasks. ---------- Protected area. These are the physical pages used for VM. ----------- More shared AmigaOS memory. ----------- First page. Protected. ----------- Is there any VMM-guru here who has any idea of how difficult this would be to implement? With some hacking, probably also code and data segments could be put into virtual, protected memory (if necessary by using a custom loader). If this is done, even fork() might possible on MMU-machines, at least for programs that does not call AmigaOS directly, only through ixemul. One good thing about letting VMM do the virtual memory stuff, and not ixemul itself, is that one can then still use VMM to do (shared) virtual memory for ordinary amiga programs, without interfering with ixemul. Just some ideas, Niels Möller From amiga-gcc-port-owner@nic.funet.fi Thu Jul 6 01:56:08 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <89304-3>; Thu, 6 Jul 1995 01:55:22 +0300 Received: from lysita.lysator.liu.se (lysita.lysator.liu.se [130.236.254.153]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id AAA28506; Thu, 6 Jul 1995 00:54:18 +0200 Received: (nisse@localhost) by lysita.lysator.liu.se (8.6.11/8.6.11) id AAA04009; Thu, 6 Jul 1995 00:54:37 +0200 Date: Thu, 6 Jul 1995 00:54:37 +0200 Message-Id: <199507052254.AAA04009@lysita.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: kyrimis@theseas.ntua.gr CC: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-reply-to: <9506221854.07iw@kriton.UUCP> (kriton!kyrimis@theseas.ntua.gr) Subject: Re: ixprefs update #1 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) Hi Fred (Fred Fish), in on Jun 22 you wrote: > As long as ixprefs verifies that the version of ixemul.library that it > is controlling is compatible, and it ignores any options in the prefs The current version of ixprefs checks to see if ixemul.library is version 41, refusing to run otherwise. It would be nice if someone could tell me from which *future* version onwards (41.1? 42.0?) the library will become incompatible, I will feel comfortable in releasing ixprefs. Meanwhile, I'll put up a warning requester if the version of ixemul.library is higher than 41.0, and upload ixprefs to aminet to get some feedback. This is just the reason why I suggested some time ago that the interpretation of the environment variable to set flags in ixemulbase should be done by ixemul itself, *not* by the GUI-frontend. The only drawback with this alternative is that the GUI (or, preferably, some other program, with a NotifyRequest on the prefs file) has to somehow tell ixemul when the settings are changed. Ixemul can't do this by itself, as it is not a process. *All* dependencies on the layout of ixemulbase are bad, except for those dependencies that are automatically resolved when recompiling ixemul. Of course, this is my personal opinion, and I won't complain any further on this subject, as it is not me who does the work. Regards, Niels Möller From amiga-gcc-port-owner@nic.funet.fi Thu Jul 6 18:33:20 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89734-2>; Thu, 6 Jul 1995 18:31:01 +0300 Received: by theseas.ntua.gr with UUCP; Thu, 6 Jul 1995 18:32:17 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07r2@kriton.UUCP>; Thu, 6 Jul 95 18:27:31 EET Date: Thu, 6 Jul 95 18:27:31 EET Message-Id: <9507061627.07r2@kriton.UUCP> In-Reply-To: <199507052254.AAA04009@lysita.lysator.liu.se> (from Niels M|ller ) (at Thu, 6 Jul 1995 00:54:37 +0200) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 2177 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: nisse@lysator.liu.se Cc: amiga-gcc-port@lists.funet.fi Subject: Re: ixprefs update #1 Hi Niels (Niels M|ller), in <199507052254.AAA04009@lysita.lysator.liu.se> on Jul 6 you wrote: > This is just the reason why I suggested some time ago that the > interpretation of the environment variable to set flags in ixemulbase > should be done by ixemul itself, *not* by the GUI-frontend. The only > drawback with this alternative is that the GUI (or, preferably, some > other program, with a NotifyRequest on the prefs file) has to somehow > tell ixemul when the settings are changed. Ixemul can't do this by > itself, as it is not a process. *All* dependencies on the layout of > ixemulbase are bad, except for those dependencies that are automatically > resolved when recompiling ixemul. So, if ixemul cannot be notified of the change, what exactly are you suggesting? As for splitting the preferences program into two, I don't see why we should make things complicated. Ixprefs was designed so that it would not have to stay permanently resident, so we don't need to split it into a resident and a non-resident part. (The one piece of missing functionality in ixprefs is having "save" have a permanent effect. To do this, ixemul will have to be modified to read the configuration file at library startup; this is certainly doable.) As for the dependencies on the layout of ixemulbase, that's not necessarily a bad thing, as we are doing something similar all the time: whenever we use a shared library, we rely on the layout of its jump table. That's why the various LVO offsets never change, and obsolete functions are not removed (e.g., OldOpenLibrary is still in exec.library, even though it has been superseded by OpenLibrary). The only bad thing is that in some older versions of ixemul, the various bits in ixemulbase had been rearranged. As long as this does not happen again (and Hans Verkuil, who'll be doing the ixemul cleanup has assured me it won't), there will not be any problem. Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "One does not wish to be devoured by alien monstrosities, even in the cause of political progress!" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Jul 6 19:53:51 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <89196-1>; Thu, 6 Jul 1995 19:49:48 +0300 Received: from lysita.lysator.liu.se (lysita.lysator.liu.se [130.236.254.153]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id SAA06204; Thu, 6 Jul 1995 18:49:05 +0200 Received: (nisse@localhost) by lysita.lysator.liu.se (8.6.11/8.6.11) id SAA12551; Thu, 6 Jul 1995 18:49:27 +0200 Date: Thu, 6 Jul 1995 18:49:27 +0200 Message-Id: <199507061649.SAA12551@lysita.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: kyrimis@theseas.ntua.gr CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9507061627.07r2@kriton.UUCP> (kriton!kyrimis@theseas.ntua.gr) Subject: Re: ixprefs update #1 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) Hi Niels (Niels M|ller), in <199507052254.AAA04009@lysita.lysator.liu.se> on Jul 6 you wrote: > This is just the reason why I suggested some time ago that the > interpretation of the environment variable to set flags in ixemulbase > should be done by ixemul itself, *not* by the GUI-frontend. The only > drawback with this alternative is that the GUI (or, preferably, some > other program, with a NotifyRequest on the prefs file) has to somehow > tell ixemul when the settings are changed. Ixemul can't do this by > itself, as it is not a process. *All* dependencies on the layout of > ixemulbase are bad, except for those dependencies that are automatically > resolved when recompiling ixemul. So, if ixemul cannot be notified of the change, what exactly are you suggesting? Well, of course ixemul can be notified, but then it needs a separate task or process, that can be communicated with, and can wait for changes of the options. Opening and initializing of ixemul happens in the context of the first task that tries to open it (is this correct ?), and that task can of course not be used for the communication of changed options. As for splitting the preferences program into two, I don't see why we should make things complicated. Ixprefs was designed so that it would not have to stay permanently resident, so we don't need to split it into a resident and a non-resident part. (The one piece of missing functionality in ixprefs is having "save" have a permanent effect. To do this, ixemul will have to be modified to read the configuration file at library startup; this is certainly doable.) That, reading of the prefs file when ixemul is loaded, is really needed, anyway. Perhaps this is a little tricky too, it's not trivial for something that is not a DOS process to get the contents of the prefs file, I guess. Also, is it possible for a simple task to create a DOS process? Or perhaps one can just require that only DOS processes ever open ixemul? Hopefully there is some simple solution; after all the library code is loded by DOS. If it is possible for ixemul itself create a process to read the prefsfile, then my suggestion is the following: When ixemul is initialized, a small process (the code of which is part of ixemul.library) is started, and ixemul initialization goes to sleep waitning for a signal (there is a signal bit reserved for such "one-time" uses). The new process then reads the prefs file and fiddles the bits in ixemul base accordingly, and then signals the waiting initializing task. After that, the process puts a NotifyRequest on the prefs file, and handles any changes. When ixemul is expunged, the created process is killed, and unloaded together with ixemul. As for the dependencies on the layout of ixemulbase, that's not necessarily a bad thing, as we are doing something similar all the time: whenever we use a shared library, we rely on the layout of its jump table. That's why the various LVO offsets never change, and obsolete functions are not removed (e.g., OldOpenLibrary is still in exec.library, even though it has been superseded by OpenLibrary). The only bad thing is that in some older versions of ixemul, the various bits in ixemulbase had been rearranged. As long as this does not happen again (and Hans Verkuil, who'll be doing the ixemul cleanup has assured me it won't), there will not be any problem. If it were that simple, I can't see why your prefs program should have to check if it is used with a ixemul.library of too high a version (this is what you said some messages ago, if i didn't misunderstand you totally). You just set the bits known in the current version, and if the prefs program is used with a future ixemul.library, new options will get the default settings, and any obsolete options will just be ignored. Well, my first idea on this subject, with one GUI-program, one resident task, and the library itself, using tasks and messages for communicating, were probably unnecessarily complicated. But the solution outlined above does not have these deficiencies, I think. There are no resident parts. There's the Prefs program, only used when changing the settings, and a small extra process that is used only when ixemul.library is actually loaded. Also, if you now change the prefs file by some other means than by the prefsprogram, for example by copying your favourite option file to s:ixprefs, ixemul would notice it. Another question: Does your program have a "use now, but don't save" alternative? With my scheme, that would probably require that env: and envarc: are used. Someone asked some time ago why C= invented the env: and envarc: directories in first place, instead of just using s: as under 1.3. Perhaps this is the answer: The preferences settings are implemented by an IPrefs process, with NotifyRequests on some files in env: , together with preferences editors that just alters these files. Now, how do you implement both the "save" and "use" alternatives in the editors? In both cases, you *have* to save the file in env: ; otherwise IPrefs wouldn't notify it, and the changes wouldn't happen. Well, if you select "use", the file is saved only in env:, but if you select "save", the file is saved both in env: and in envarc: . At boot time, envarc: is copied into env: (and there's nothing in this that requires env: to be located in RAM.) It's simple, and I think that it's rather elegant. This was a long posting, but I hope that I have been clear. Best regards, Niels From amiga-gcc-port-owner@nic.funet.fi Thu Jul 6 20:43:24 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88914-3>; Thu, 6 Jul 1995 20:42:44 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sTvvV-0004nYC; Thu, 6 Jul 95 11:45 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ixprefs update #1 To: nisse@lysator.liu.se (Niels M|ller) Date: Thu, 6 Jul 1995 11:45:28 -0700 (MST) Cc: kyrimis@theseas.ntua.gr, amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi (ixemul.library maintainers) In-Reply-To: <199507061649.SAA12551@lysita.lysator.liu.se> from "Niels M|ller" at Jul 6, 95 06:49:27 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 439 > This was a long posting, but I hope that I have been clear. Best > regards, There were some excellent ideas in here. Thanks for taking the time to post them. Unfortunately I can't contribute much to the technical discussion here, since it's outside my current knowledge of AmigaDOS details, but if everyone can agree on a technical solution and someone can implement it, I'd be most happy to merge it into ixemul and test it. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 09:17:18 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <88964-1>; Fri, 7 Jul 1995 09:13:37 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA29072 (5.65b/CWI-3.3); Fri, 7 Jul 1995 08:13:28 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sU6OM-000Fk8C; Fri, 7 Jul 95 07:55 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <08al@wyst.hobby.nl>; Thu, 6 Jul 95 20:46:40 CET Message-Id: <9507061946.08al@wyst.hobby.nl> Date: Thu, 6 Jul 1995 20:46:38 +0000 (CET) In-Reply-To: <199507061649.SAA12551@lysita.lysator.liu.se> from "Niels M|ller" at Jul 6, 95 06:49:27 pm Content-Type: text Content-Length: 3247 From: hans@wyst.hobby.nl (Hans Verkuil) To: nisse@lysator.liu.se Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ixprefs update #1 According to Niels M|ller: > That, reading of the prefs file when ixemul is loaded, is really > needed, anyway. Perhaps this is a little tricky too, it's not trivial > for something that is not a DOS process to get the contents of the > prefs file, I guess. Also, is it possible for a simple task to create > a DOS process? Or perhaps one can just require that only DOS processes > ever open ixemul? Hopefully there is some simple solution; after all > the library code is loded by DOS. When the ixemul.library is opened, it automatically opens the dos.library, so we can use DOS functions. > If it is possible for ixemul itself create a process to read the prefsfile, > then my suggestion is the following: > > When ixemul is initialized, a small process (the code of which is part > of ixemul.library) is started, and ixemul initialization goes to sleep > waitning for a signal (there is a signal bit reserved for such > "one-time" uses). The new process then reads the prefs file and > fiddles the bits in ixemul base accordingly, and then signals the > waiting initializing task. After that, the process puts a > NotifyRequest on the prefs file, and handles any changes. > > When ixemul is expunged, the created process is killed, and unloaded > together with ixemul. Way too complicated: it's much easier to read an environment setting using the DOS function GetVar() on initialization of the library. There is no need for notification stuff if ixprefs still writes the flags directly into the library base. Thus, we need the following: 1) the ixemul.library must read an environment variable on startup and set the flags to their respective values. 2) ixprefs sets the ixemul base and also writes the new environment variable. To make it easy to parse the environment variable I recommend that the first line is in an ixemul-friendly (i.e. easy to parse) format, and the other lines are in a human-friendly format. Personally, I wouldn't mind if the 'human-readable' lines are skipped, as one would use ixprefs to present everything in an understandable manner anyway. > If it were that simple, I can't see why your prefs program should have > to check if it is used with a ixemul.library of too high a version > (this is what you said some messages ago, if i didn't misunderstand > you totally). You just set the bits known in the current version, and > if the prefs program is used with a future ixemul.library, new options > will get the default settings, and any obsolete options will just be > ignored. True, but it's nice to have a matching set, otherwise the ixemul.library has settings you cannot change, or ixprefs has settings that are ignored by the library, confusing the poor users no end. > Another question: Does your program have a "use now, but don't save" > alternative? With my scheme, that would probably require that env: and > envarc: are used. I also advise moving to env: in the near future. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 10:08:49 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <89049-3>; Fri, 7 Jul 1995 10:07:47 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HSL2DOIN9C90QJRW@LEON.CTI.GR>; Fri, 7 Jul 1995 10:04:43 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA01923; Fri, 7 Jul 95 10:08:58 +0300 Date: Fri, 07 Jul 1995 10:08:57 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: ixprefs update #1 In-reply-to: <199507061649.SAA12551@lysita.lysator.liu.se> from "Niels M|ller" at Jul 6, 95 06:49:27 pm To: nisse@lysator.liu.se (Niels M|ller) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@hpcl.cti.gr Message-id: <9507070708.AA01923@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 1727 (Although for the time being I think we will stick to the current implementation, I'll keep your comments, for a possible re-implementation after the scheduled clean-up of ixemul). > If it were that simple, I can't see why your prefs program should have > to check if it is used with a ixemul.library of too high a version > (this is what you said some messages ago, if i didn't misunderstand > you totally). You just set the bits known in the current version, and > if the prefs program is used with a future ixemul.library, new options > will get the default settings, and any obsolete options will just be > ignored. I was actually wondering about this myself. The check for later versions was added when I didn't know whether the bits in ixemulbase would be rearranged or not. Now that I know that they won't be, I should remove the check completely, as you suggest. I'll probably do this when the next version of ixemul is released. > Also, if you now change the prefs file by some other means than by the > prefsprogram, for example by copying your favourite option file to > s:ixprefs, ixemul would notice it. This can also be done with the current implementation in two steps: 1. cp my_favourite_option_file S:ixprefs 2. ixprefs --last > Another question: Does your program have a "use now, but don't save" > alternative? With my scheme, that would probably require that env: and > envarc: are used. Yes and yes. However, there were some cries of protest from people in the list against using env: to store ixemul preferences in env:. Thanks for your comments, -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Killing your own clone is still murder." ----- From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 11:10:12 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89916-2>; Fri, 7 Jul 1995 11:08:19 +0300 Received: by colombo.telesys-innov.fr; Fri, 7 Jul 1995 10:10:19 +0100 From: Philippe BRAND Message-Id: <199507070910.KAA13327@colombo.telesys-innov.fr> Subject: 2.7.0 release To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Fri, 7 Jul 1995 10:10:18 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1398 Ok. Because I didn't have any feedback on latest C part (gcc270-c.lha), I have to admit that it is then bug-free, don't generate anymore 68020 opcodes, etc... So I'll now begin to build new 2.7.0 distribution. I will make at first an update distribution. At first glance I think I'll include (in separate archives): - C, ObjC C++ compilers - new essential programs like sh, ld, as, make. - only include 68000 soft-float ixemul.library. Other ixemul stuff can be then retreive from ixemul archives on aminet. This will avoid redundancy at least for upgrade distribution. - as it is an upgrade, perhaps not include libnix, because it is available on Aminet (even latest version Matthias ?) and to avoid larges archives. I think it's necessary to have a complete distribution, that will include all separate archives that may be found on Aminet, in order to simplify gnu package installation. I don't think it will be wise to let people grab pieces. We'll then have 10 more complains about installation ease. So I will need a new installer script for this upgrade. I really want to have some comments about this. Maybe I'm totally wrong, especially because I just thought about all this story 5 minutes ago ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 11:14:39 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89011-1>; Fri, 7 Jul 1995 11:14:07 +0300 Received: by colombo.telesys-innov.fr; Fri, 7 Jul 1995 10:16:12 +0100 From: Philippe BRAND Message-Id: <199507070916.KAA13362@colombo.telesys-innov.fr> Subject: Important things To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Fri, 7 Jul 1995 10:16:11 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 446 Because ealy beta or perhaps even ealier gcc releases did generate 020 opcodes even while in 680000 code generation, I need absolutly libnix recompiled using latest C release (gcc270-c.lha). I think ixemul.library 4101 is cimpiled with such release. AmI wrong Fred ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 11:27:50 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89454-4>; Fri, 7 Jul 1995 11:26:53 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sU9mO-0004nYC; Fri, 7 Jul 95 02:33 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Important things To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Fri, 7 Jul 1995 02:33:00 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199507070916.KAA13362@colombo.telesys-innov.fr> from "Philippe BRAND" at Jul 7, 95 10:16:11 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 475 > Because ealy beta or perhaps even ealier gcc releases did generate > 020 opcodes even while in 680000 code generation, I need absolutly > libnix recompiled using latest C release (gcc270-c.lha). > I think ixemul.library 4101 is cimpiled with such release. AmI wrong Fred ? The "plain 68000" version of ixemul.library V41.1 should be fine. I tested it on a 68000 based A2000 by recompiling a couple of nontrivial GNU programs (like bison), with no problems at all. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 13:02:36 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89083-2>; Fri, 7 Jul 1995 13:01:10 +0300 Received: by colombo.telesys-innov.fr; Fri, 7 Jul 1995 12:02:12 +0100 From: Philippe BRAND Message-Id: <199507071102.MAA13696@colombo.telesys-innov.fr> Subject: WARNING: bug in gcc-2.7.0 To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Fri, 7 Jul 1995 12:02:11 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2169 Ok... there's a nasty bug in AmigaDOS gcc-2.7.0 and I think also in all m68k targets. I've just sent a bug-report to gcc developper's list. This bug affects 68000 gereration code, if optimizing options are turned on. Gcc outputs 020 opcode instead of vanilla 68000 opcode. ---------------- m68k-cbm-amigados (not merged yet) produces this bug if compiled with -O or -O2. Should affect all m68k targets. int foobar(len, type) register unsigned long len, type; { register unsigned long p; if (!addchunk(p, p + len - 1)) { StdFree(p, len); p = 0; } } # amigados-gcc -O2 -v -m68000 -msoft-float -S bug.c Reading specs from /usr/local/lib/gcc-lib/amigados/2.7.0/specs gcc version 2.7.0 /usr/local/lib/gcc-lib/amigados/2.7.0/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -D__OPTIMIZE__ -Dmc68010 bug.c /usr/tmp/cca15354.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc-lib/amigados/2.7.0/include /usr/local/lib/gcc-lib/amigados/2.7.0/sys-include /usr/local/amigados/include End of search list. /usr/local/lib/gcc-lib/amigados/2.7.0/cc1 /usr/tmp/cca15354.i -mfixedstack -quiet -dumpbase bug.c -m68000 -msoft-float -O2 -version -o bug.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. #NO_APP gcc2_compiled.: ___gnu_compiled_c: .text .even .globl _foobar _foobar: movel a3,sp@- movel a2,sp@- movel sp@(12),a3 pea a3@(-1,a2:l) <---- 68020 opcode. movel a2,sp@- jbsr _addchunk addqw #8,sp tstl d0 jne L2 movel a3,sp@- movel a2,sp@- jbsr _StdFree addqw #8,sp L2: movel sp@+,a2 movel sp@+,a3 rts -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 14:09:56 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <89560-4>; Fri, 7 Jul 1995 14:08:24 +0300 Received: by ceylon.informatik.uni-rostock.de id NAA15497; Fri, 7 Jul 1995 13:08:02 +0200 Received: by honshu.informatik.uni-rostock.de id NAA23046; Fri, 7 Jul 1995 13:07:57 +0200 From: Gunther Nikl Message-Id: <199507071107.NAA23046@honshu.informatik.uni-rostock.de> Subject: Re: WARNING: bug in gcc-2.7.0 To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Fri, 7 Jul 1995 13:07:56 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199507071102.MAA13696@colombo.telesys-innov.fr> from "Philippe BRAND" at Jul 7, 95 12:02:11 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 306 > pea a3@(-1,a2:l) <---- 68020 opcode. Mhm, are you sure !? Translated to Motorola syntax it seems to be a valid 68000 instruction. pea -1(a3,a2.l) It would become a 68020 instruction if the "-1" would be assembled as word/long. As a byte (and this should it be) all is ok. Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 14:25:00 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.28]) by nic.funet.fi with SMTP id <89382-4>; Fri, 7 Jul 1995 14:23:54 +0300 Received: by ceylon.informatik.uni-rostock.de id NAA15529; Fri, 7 Jul 1995 13:20:53 +0200 Received: by honshu.informatik.uni-rostock.de id NAA23147; Fri, 7 Jul 1995 13:20:48 +0200 From: Gunther Nikl Message-Id: <199507071120.NAA23147@honshu.informatik.uni-rostock.de> Subject: Re: 2.7.0 release To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Fri, 7 Jul 1995 13:20:47 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199507070910.KAA13327@colombo.telesys-innov.fr> from "Philippe BRAND" at Jul 7, 95 10:10:18 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1067 > > Ok. Because I didn't have any feedback on latest C part (gcc270-c.lha), > I have to admit that it is then bug-free, don't generate anymore 68020 > opcodes, etc... > So I'll now begin to build new 2.7.0 distribution. No,no,no !!! Please delay it. Yesterday I tested your latest release (gcc270-c.lha). Since I have it to transfer it via disk from the university to my amiga it needs some time. Please be more patient ;) Ok, the problem: I think gcc itself has been compiled with automatic stackextension, isn't it? That does NOT work reliable on my amiga. (a4000 with 68030/68882, 2+8 MB, no fancy commodities running ;) I tested it with a shell the stack set to "20000". cc1 swaps the stack one time and even returns to the original stack but then it crashes the machine _completely_ (checked with Xoper ;). It only works with the old method - setting the stack to a very high value :-( (BTW I think the previous release was much better) > - new essential programs like sh, ld, as, make. Compiled with "-resident" please. Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 15:29:51 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89104-2>; Fri, 7 Jul 1995 15:28:29 +0300 Received: by colombo.telesys-innov.fr; Fri, 7 Jul 1995 14:28:03 +0100 From: Philippe BRAND Message-Id: <199507071328.OAA14295@colombo.telesys-innov.fr> Subject: Re: 2.7.0 release To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Fri, 7 Jul 1995 14:28:02 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199507071120.NAA23147@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Jul 7, 95 01:20:47 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1073 Gunther Nikl writes: > No,no,no !!! Please delay it. Yesterday I tested your latest release > (gcc270-c.lha). Since I have it to transfer it via disk from the > university to my amiga it needs some time. Please be more patient ;) Ok ;-) > Ok, the problem: I think gcc itself has been compiled with automatic > stackextension, isn't it? That does NOT work reliable on my amiga. Nope. It wasn't compiled using auto-stack extension. > (a4000 with 68030/68882, 2+8 MB, no fancy commodities running ;) > I tested it with a shell the stack set to "20000". cc1 swaps the stack > one time and even returns to the original stack but then it crashes > the machine _completely_ (checked with Xoper ;). It only works with the > old method - setting the stack to a very high value :-( > (BTW I think the previous release was much better) Yep, still need GCCSTACK or large stack. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 18:35:37 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89308-4>; Fri, 7 Jul 1995 18:33:19 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26483-4>; Fri, 7 Jul 1995 17:32:59 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209446-2>; Fri, 7 Jul 1995 17:32:34 +0100 Subject: Re: WARNING: bug in gcc-2.7.0 From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 7 Jul 1995 17:32:32 +0200 (MESZ) In-Reply-To: <199507071107.NAA23046@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Jul 7, 95 01:07:56 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 810 Message-Id: <95Jul7.173234+0100mesz.209446-2+997@hphalle0.informatik.tu-muenchen.de> > > pea a3@(-1,a2:l) <---- 68020 opcode. > > Mhm, are you sure !? Translated to Motorola syntax it seems to be > a valid 68000 instruction. > > pea -1(a3,a2.l) > > It would become a 68020 instruction if the "-1" would be assembled > as word/long. As a byte (and this should it be) all is ok. Hm... I might be wrong, but isn't this "a2.l" used as an index? If I remember correctly, 68000 only allows dataregisters as index. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 18:45:21 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88961-1>; Fri, 7 Jul 1995 18:44:42 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sUGbC-0004nYC; Fri, 7 Jul 95 09:49 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: WARNING: bug in gcc-2.7.0 To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Fri, 7 Jul 1995 09:49:54 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Jul7.173234+0100mesz.209446-2+997@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Jul 7, 95 05:32:32 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 671 > > > > pea a3@(-1,a2:l) <---- 68020 opcode. > > > > Mhm, are you sure !? Translated to Motorola syntax it seems to be > > a valid 68000 instruction. > > > > pea -1(a3,a2.l) > > > > It would become a 68020 instruction if the "-1" would be assembled > > as word/long. As a byte (and this should it be) all is ok. > > Hm... I might be wrong, but isn't this "a2.l" used as an index? If I > remember correctly, 68000 only allows dataregisters as index. I added enough glue code around this example to actually execute the code, and the resulting program ran fine on an m68000 based A2000, so it looks to me like it is probably good m68000 code. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 19:30:49 1995 Received: from asimov.cnam.fr ([163.173.128.6]) by nic.funet.fi with SMTP id <89049-4>; Fri, 7 Jul 1995 19:29:58 +0300 Received: from localhost (localhost [127.0.0.1]) by asimov.cnam.fr with SMTP id SAA29318 (8.6.12/ for amiga-gcc-port@nic.funet.fi); Fri, 7 Jul 1995 18:29:43 +0200 From: lauly@cnam.fr (Pascal Lauly) Message-Id: <199507071629.SAA29318@asimov.cnam.fr> To: amiga-gcc-port@nic.funet.fi Subject: Re: WARNING: bug in gcc-2.7.0 In-reply-to: Your message of "Fri, 07 Jul 95 09:49:54 PDT." Date: Fri, 07 Jul 95 18:29:42 +0200 X-Mts: smtp > > > > pea a3@(-1,a2:l) <---- 68020 opcode. > > > > Mhm, are you sure !? Translated to Motorola syntax it seems to be > > a valid 68000 instruction. > > > > pea -1(a3,a2.l) > > > > It would become a 68020 instruction if the "-1" would be assembled > > as word/long. As a byte (and this should it be) all is ok. > > Hm... I might be wrong, but isn't this "a2.l" used as an index? If I > remember correctly, 68000 only allows dataregisters as index. In new motorola syntaxe this 68000 instruction is ----- pea (-1,a3,a2.l) it will push on the stack the value (a3.l+a2.l-1).l I'v checked in my motorola 68k data book. Pascal Lauly. From amiga-gcc-port-owner@nic.funet.fi Fri Jul 7 19:42:18 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <89621-4>; Fri, 7 Jul 1995 19:41:20 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189557>; Fri, 7 Jul 1995 18:40:53 +0200 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA19757; Fri, 7 Jul 1995 18:40:41 +0200 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9507071640.AA19757@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: WARNING: bug in gcc-2.7.0 To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Fri, 7 Jul 1995 18:40:40 +0200 Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Jul7.173234+0100mesz.209446-2+997@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Jul 7, 95 05:32:32 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 678 > > > > > pea a3@(-1,a2:l) <---- 68020 opcode. > > > > Mhm, are you sure !? Translated to Motorola syntax it seems to be > > a valid 68000 instruction. > > > > pea -1(a3,a2.l) > > > > It would become a 68020 instruction if the "-1" would be assembled > > as word/long. As a byte (and this should it be) all is ok. > > Hm... I might be wrong, but isn't this "a2.l" used as an index? If I > remember correctly, 68000 only allows dataregisters as index. Type: Indexed Register Indirect With Offset The syntax for this adressing mode is d(An,Rx) , where d is a 8 Bit offset, An is a address register, Rx is any register from d0-d7,a0-a7 Thomas From amiga-gcc-port-owner@nic.funet.fi Sat Jul 8 07:08:32 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <89134-1>; Sat, 8 Jul 1995 07:02:13 +0300 Received: from cnts4p29.uwaterloo.ca ([129.97.198.29]) by math.uwaterloo.ca with SMTP id <77164-2>; Sat, 8 Jul 1995 00:01:19 -0400 Date: Fri, 7 Jul 1995 20:01:58 -0400 From: Jeff Shepherd X-Sender: jsshephe@cnts4p29.uwaterloo.ca To: ixemul maintainers cc: Amiga-Gcc List Subject: getenv() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ixemul's getenv() seems to be case-sensitive and doesn't cooperate well with AmigaDOS's program setenv. Here is a little test program that I will refer to. ---------------------- #include #include int main(void) { char *env=getenv("TESTENV"); printf("testenv is %s\n",env); } ------ compile using "gcc -o testenv testenv.c" Try the following: setenv testenv test testenv Which produces: testenv is (null) Now: setenv TESTENV test testenv which produces testenv is (null) now try echo >env:testenv test testenv which produces testenv is (null) The only thing that works is echo >env:TESTENV test testenv which produces the desired result. The difference between "echo >env:testenv test" and "setenv testenv test" is that echo puts a '\n' at the end while setenv doesn't. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/ The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Sat Jul 8 10:50:17 1995 Received: from mserv.rug.ac.be ([157.193.40.37]) by nic.funet.fi with SMTP id <89270-2>; Sat, 8 Jul 1995 10:49:01 +0300 Received: from eduserv.rug.ac.be by mserv.rug.ac.be with SMTP id AA02395 (5.67b/IDA-1.5 for ); Sat, 8 Jul 1995 09:47:30 +0200 Received: by eduserv.rug.ac.be (5.x/SMI-SVR4) id AA28813; Sat, 8 Jul 1995 09:45:36 +0200 Date: Sat, 8 Jul 1995 09:45:34 +0200 (MET DST) From: Kristof Depraetere To: amiga-gcc-port@nic.funet.fi Subject: gcc-2.7.0 stackextend is not working correctly. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello all, I compiled make-3.74 with gcc-2.7.0 and it works OK. Then I compiled it with stackextend turned on. I've put the stack to 5000 and tried to recompile make again with the new make. Make doesn't extend the stack when it should. Make just stops when it should extend the stack. This should be checked before releasing the final gcc-2.7.0 Kristof. From amiga-gcc-port-owner@nic.funet.fi Sat Jul 8 22:00:19 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <88941-4>; Sat, 8 Jul 1995 21:58:53 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA02651 (5.65c+/IDA-1.4.4 for ); Fri, 7 Jul 1995 17:09:46 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA13889; Fri, 7 Jul 1995 17:08:41 GMT Date: Fri, 7 Jul 1995 17:08:41 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Niels M|ller Cc: amiga-gcc-port@nic.funet.fi Subject: Re: fork() with MMU? VMMs problem... In-Reply-To: <199507052244.AAA03912@lysita.lysator.liu.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII OK! Maybe I have an idea that suits ixemul's need: A while ago I had one project, mearly academical, to build a distributed memory manager for the Amiga. It consisted in using Phisical (os not) RAM on another computer through some king of cable. A little like NFS but for RAM instead of HD. The project worked OK but it was very slow, as it would de expected since the tests were made through a serial cable using 1MB of RAM in a A500. Anyway, the sistem worked together with VMM with no interference. A500 RAM was 'mounted' on my 4000 in the old expansion space, $0020 0000. VMM sets the MMU tree for all the memory space BUT, after that, it only manages addresses $4000 0000 up. For instance, $20 0000 was an early termination node in MMU tree, I transformed it into a Table pointer which my DistRAM manager worked with no problem. If the problem, as you stated was to split memory areas, then it is easy to solve but, this is not the correct thing to do... The problem, in VMM is not to have one address pointing to the same phisical area, it is quite the opposite. When forking we need to alloc a new data section, copy the old one and the new process should work with it. Since relocating the code is out of the question - the father still works with the previous data section - then, the solution would be to ASK vmm to make the SAME virtual address to 2 diferent phisical areas (or HD blocks) considering the current task. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Sat Jul 8 22:11:15 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <89310-1>; Sat, 8 Jul 1995 22:09:40 +0300 Received: from cnts1p18.uwaterloo.ca ([129.97.112.18]) by math.uwaterloo.ca with SMTP id <77135-2>; Sat, 8 Jul 1995 15:09:16 -0400 Date: Sat, 8 Jul 1995 11:09:49 -0400 From: Jeff Shepherd X-Sender: jsshephe@cnts1p18.uwaterloo.ca To: ixemul maintainers cc: Amiga-Gcc List Subject: Timezone not parsed correctly Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2124320750-1582905125-805216189=:131601184" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. 2 ---2124320750-1582905125-805216189=:131601184 Content-Type: TEXT/PLAIN; charset=US-ASCII Attached is a program which is used to illustrate this example. The timezone variable TZ is not parsed correctly by ixemul. Etc:timeinfo and etc:localtime are not set. Setting TZ to "EDT-4" produces Tz = EDT-4 Sat, 8 Jul 1995 19:01:34 +0400 (EDT) which is correct. Setting TZ to EST-5EDT which is a valid timezone string by tzset(3) produces: Tz = EST-5EDT Sat, 8 Jul 1995 15:03:33 +0000 () which is definitely wrong. The reason for +0000 is that localtime() produces the same time as gmtime() which should not happen. The reason for "()" is that the timezone string is NULL. (The code was taken from the Pine 3.91 distribution) jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/ The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. ---2124320750-1582905125-805216189=:131601184 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="testenv.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: I2luY2x1ZGUgPHN0ZGxpYi5oPg0KI2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5j bHVkZSA8dGltZS5oPg0KDQp2b2lkIHJmYzgyMl90aW1lem9uZSAoY2hhciAq cyx2b2lkICp0KQ0Kew0KCQkJCS8qIGFwcGVuZCB0aW1lem9uZSBmcm9tIHRt IHN0cnVjdCAqLw0KICBzcHJpbnRmIChzICsgc3RybGVuIChzKSwiICglcyki LCgoc3RydWN0IHRtICopIHQpLT50bV96b25lKTsNCn0NCg0KY29uc3QgY2hh ciAqZGF5c1tdID0geyJTdW4iLCAiTW9uIiwgIlR1ZSIsICJXZWQiLCAiVGh1 IiwgIkZyaSIsICJTYXQifTsNCg0KY29uc3QgY2hhciAqbW9udGhzW10gPSB7 IkphbiIsICJGZWIiLCAiTWFyIiwgIkFwciIsICJNYXkiLCAiSnVuIiwNCgkJ CSJKdWwiLCAiQXVnIiwgIlNlcCIsICJPY3QiLCAiTm92IiwgIkRlYyJ9Ow0K DQpzdGF0aWMgdm9pZCBkb19kYXRlIChjaGFyICpkYXRlLGNoYXIgKnByZWZp eCxjaGFyICpmbXQsaW50IHN1ZmZpeCkNCnsNCiAgdGltZV90IHRuID0gdGlt ZSAoMCk7DQogIHN0cnVjdCB0bSAqdCA9IGdtdGltZSAoJnRuKTsNCiAgaW50 IHpvbmUgPSB0LT50bV9ob3VyICogNjAgKyB0LT50bV9taW47DQogIGludCBq dWxpYW4gPSB0LT50bV95ZGF5Ow0KICB0ID0gbG9jYWx0aW1lICgmdG4pOyAg ICAgICAgICAvKiBnZXQgbG9jYWwgdGltZSBub3cgKi8NCgkJCQkvKiBtaW51 cyBVVEMgbWludXRlcyBzaW5jZSBtaWRuaWdodCAqLw0KICB6b25lID0gdC0+ dG1faG91ciAqIDYwICsgdC0+dG1fbWluIC0gem9uZTsNCiAgLyoganVsaWFu IGNhbiBiZSBvbmUgb2Y6DQogICAqICAzNnggIGxvY2FsIHRpbWUgaXMgRGVj ZW1iZXIgMzEsIFVUQyBpcyBKYW51YXJ5IDEsIG9mZnNldCAtMjQgaG91cnMN CiAgICoJMSAgbG9jYWwgdGltZSBpcyAxIGRheSBhaGVhZCBvZiBVVEMsIG9m ZnNldCArMjQgaG91cnMNCiAgICoJMCAgbG9jYWwgdGltZSBpcyBzYW1lIGRh eSBhcyBVVEMsIG5vIG9mZnNldA0KICAgKiAgIC0xICBsb2NhbCB0aW1lIGlz IDEgZGF5IGJlaGluZCBVVEMsIG9mZnNldCAtMjQgaG91cnMNCiAgICogLTM2 eCAgbG9jYWwgdGltZSBpcyBKYW51YXJ5IDEsIFVUQyBpcyBEZWNlbWJlciAz MSwgb2Zmc2V0ICsyNCBob3Vycw0KICAgKi8NCiAgaWYgKGp1bGlhbiA9IHQt PnRtX3lkYXkgLWp1bGlhbikNCiAgICB6b25lICs9ICgoanVsaWFuIDwgMCkg PT0gKGFicyAoanVsaWFuKSA9PSAxKSkgPyAtMjQqNjAgOiAyNCo2MDsNCiAg aWYgKHByZWZpeCkgeyAgICAgICAgICAgICAgICAgLyogd2FudCBkYXkgb2Yg d2Vlaz8gKi8NCiAgICBzcHJpbnRmIChkYXRlLHByZWZpeCxkYXlzW3QtPnRt X3dkYXldKTsNCiAgICBkYXRlICs9IHN0cmxlbiAoZGF0ZSk7ICAgICAgLyog bWFrZSBuZXh0IHNwcmludGYgYXBwZW5kICovDQogIH0NCgkJCQkvKiBvdXRw dXQgdGhlIGRhdGUgKi8NCiAgc3ByaW50ZiAoZGF0ZSxmbXQsdC0+dG1fbWRh eSxtb250aHNbdC0+dG1fbW9uXSx0LT50bV95ZWFyKzE5MDAsDQoJICAgdC0+ dG1faG91cix0LT50bV9taW4sdC0+dG1fc2VjLHpvbmUvNjAsYWJzICh6b25l KSAlIDYwKTsNCgkJCQkvKiBhcHBlbmQgdGltZXpvbmUgc3VmZml4IGlmIGRl c2lyZWQgKi8NCiAgaWYgKHN1ZmZpeCkgcmZjODIyX3RpbWV6b25lIChkYXRl LCh2b2lkICopIHQpOw0KfQ0KDQppbnQgbWFpbih2b2lkKSB7DQogICAgY2hh ciAqdHogPSBnZXRlbnYoIlRaIik7DQogICAgY2hhciBkYXRlWzEwMF07DQog ICAgcHJpbnRmKCJUeiA9ICVzXG4iLHR6KTsNCiAgICB0enNldCgpOw0KICAg IGRvX2RhdGUgKGRhdGUsIiVzLCAiLCIlZCAlcyAlZCAlMDJkOiUwMmQ6JTAy ZCAlKzAzZCUwMmQiLDEpOw0KICAgIHByaW50ZigiJXNcbiIsZGF0ZSk7DQog ICAgcmV0dXJuIDA7DQp9DQoNCg== ---2124320750-1582905125-805216189=:131601184-- From amiga-gcc-port-owner@nic.funet.fi Sun Jul 9 22:47:03 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <89138-2>; Sun, 9 Jul 1995 22:39:28 +0300 Received: from lysita.lysator.liu.se (lysita.lysator.liu.se [130.236.254.153]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id VAA01670; Sun, 9 Jul 1995 21:38:37 +0200 Received: (nisse@localhost) by lysita.lysator.liu.se (8.6.11/8.6.11) id VAA03607; Sun, 9 Jul 1995 21:39:09 +0200 Date: Sun, 9 Jul 1995 21:39:09 +0200 Message-Id: <199507091939.VAA03607@lysita.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: hans@wyst.hobby.nl CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9507061946.08al@wyst.hobby.nl> (hans@wyst.hobby.nl) Subject: Re: ixprefs update #1 From: hans@wyst.hobby.nl (Hans Verkuil) According to Niels M|ller: > That, reading of the prefs file when ixemul is loaded, is really > needed, anyway. Perhaps this is a little tricky too, it's not trivial > for something that is not a DOS process to get the contents of the > prefs file, I guess. Also, is it possible for a simple task to create > a DOS process? Or perhaps one can just require that only DOS processes > ever open ixemul? Hopefully there is some simple solution; after all > the library code is loded by DOS. When the ixemul.library is opened, it automatically opens the dos.library, so we can use DOS functions. If you say so, I guess that works. But which *task* is it that opens dos.library? Opening the library doesn't automatically turn a task into a process, does it? Imagine that a task (without a DOS-process structure attached to its task structure) for some reason opens ixemul.library. Then DOS I/O is probably impossible, and at least illegal. Perhaps the proper way is to check the NT_TYPE field of tasks that tries to open ixemul, and fail if it's not a DOS process? > If it is possible for ixemul itself create a process to read the prefsfile, > then my suggestion is the following: > > When ixemul is initialized, a small process (the code of which is part > of ixemul.library) is started, and ixemul initialization goes to sleep > waitning for a signal (there is a signal bit reserved for such > "one-time" uses). The new process then reads the prefs file and > fiddles the bits in ixemul base accordingly, and then signals the > waiting initializing task. After that, the process puts a > NotifyRequest on the prefs file, and handles any changes. > > When ixemul is expunged, the created process is killed, and unloaded > together with ixemul. Way too complicated: it's much easier to read an environment setting using the DOS function GetVar() on initialization of the library. There is no need for notification stuff if ixprefs still writes the flags directly into the library base. I still think that it's a good thing to be able to change the settings without using any specific prefs program. It's good if you can change them for example by dragging an icon of your favourite option file (created earlier with ixprefs, probably) into the ENV: drawer, and have ixemul notice it. Thus, we need the following: 1) the ixemul.library must read an environment variable on startup and set the flags to their respective values. Notification should not be *that* difficult once this is done. 2) ixprefs sets the ixemul base and also writes the new environment variable. To make it easy to parse the environment variable I recommend that the first line is in an ixemul-friendly (i.e. easy to parse) format, and the other lines are in a human-friendly format. Personally, I wouldn't mind if the 'human-readable' lines are skipped, as one would use ixprefs to present everything in an understandable manner anyway. I'd prefer to fiddle the ixemul base bits in *one* place, namely in ixemul itself (it has to be able to parse them and set the bits at startup anyway, so this is not that big a deal), and save the data in *one* format, human readable and editable. If you want it easy, why not use DOS ReadArgs(), instead of inventing yet another obscure format to maintain? I guess that's the proper way to do it on an Amiga. Regards, Niels From amiga-gcc-port-owner@nic.funet.fi Sun Jul 9 23:18:02 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <88965-2>; Sun, 9 Jul 1995 23:14:05 +0300 Received: from lysita.lysator.liu.se (lysita.lysator.liu.se [130.236.254.153]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id WAA02114; Sun, 9 Jul 1995 22:13:21 +0200 Received: (nisse@localhost) by lysita.lysator.liu.se (8.6.11/8.6.11) id WAA03937; Sun, 9 Jul 1995 22:13:51 +0200 Date: Sun, 9 Jul 1995 22:13:51 +0200 Message-Id: <199507092013.WAA03937@lysita.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: l36599@alfa.ist.utl.pt CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Pedro Miguel Sequeira Teixeira on Fri, 7 Jul 1995 17:08:41 +0000 (GMT)) Subject: Re: fork() with MMU? VMMs problem... Date: Fri, 7 Jul 1995 17:08:41 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira Cc: amiga-gcc-port@nic.funet.fi Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1466 OK! Maybe I have an idea that suits ixemul's need: A while ago I had one project, mearly academical, to build a distributed memory manager for the Amiga. It consisted in using Phisical (os not) RAM on another computer through some king of cable. A little like NFS but for RAM instead of HD. The project worked OK but it was very slow, as it would de expected since the tests were made through a serial cable using 1MB of RAM in a A500. Anyway, the sistem worked together with VMM with no interference. A500 RAM was 'mounted' on my 4000 in the old expansion space, $0020 0000. VMM sets the MMU tree for all the memory space BUT, after that, it only manages addresses $4000 0000 up. For instance, $20 0000 was an early termination node in MMU tree, I transformed it into a Table pointer which my DistRAM manager worked with no problem. Sounds pretty cool, allthough not as practical as VM. If the problem, as you stated was to split memory areas, then it is easy to solve but, this is not the correct thing to do... The problem, in VMM is not to have one address pointing to the same phisical area, it is quite the opposite. When forking we need to alloc a new data section, copy the old one and the new process should work with it. Since The *proper* way to to it, is to share the code section, read only, and initially *share* the data section too, but mark it as "copy on write". When one of the processes writes to a page in the data segment, that page is copied, and the preocess gets its own read/write copy. But I'm still considering fork() as something that not will happen in the near future. Protected and virtual memory management is more implementable. From amiga-gcc-port-owner@nic.funet.fi Sun Jul 9 23:53:22 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <88964-4>; Sun, 9 Jul 1995 23:36:35 +0300 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt with SMTP id AA14684 (5.65c+/IDA-1.4.4); Sun, 9 Jul 1995 22:32:48 +0100 Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/03Jun94-0521PM) id AA10820; Sun, 9 Jul 1995 22:34:09 GMT Date: Sun, 9 Jul 1995 22:34:08 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Amiga GCC Mailling list Cc: Amiga X11 mailling list Subject: Looking for Kari Mettinen Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've read in the COPYWRIGHT file about fvwm executable that came with one of DaggeX distributions and it was signed: Kari Mettinen. I would like to find him. Is Kari Mettinen anywere on this mailing-list ? - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Mon Jul 10 22:48:55 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <89408-1>; Mon, 10 Jul 1995 22:46:49 +0300 Received: from pessoa by torga.ci.uminho.pt (5.4.1/140.2) id AA13982; Mon, 10 Jul 1995 21:47:34 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA00105; Mon, 10 Jul 1995 21:45:53 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9507101945.AA00105@pessoa.ci.uminho.pt> Subject: explain-me a thing To: amiga-gcc-port@nic.funet.fi (gcc) Date: Mon, 10 Jul 1995 21:45:53 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 515 If a start a program from double cliking in an icon, or putting it in default tool of an icon, like more in txt files, how can an see the name of file in 'C' or the parameters passed by the icon in a 'C' program. __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Tue Jul 11 20:16:11 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89215-3>; Tue, 11 Jul 1995 20:12:17 +0300 Received: by theseas.ntua.gr with UUCP; Tue, 11 Jul 1995 20:12:57 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07sw@kriton.UUCP>; Tue, 11 Jul 95 20:07:37 EET Date: Tue, 11 Jul 95 20:07:37 EET Message-Id: <9507111807.07sw@kriton.UUCP> In-Reply-To: <9507101945.AA00105@pessoa.ci.uminho.pt> (from si215603@ci.uminho.pt (Luis Antonio F.Alves)) (at Mon, 10 Jul 1995 21:45:53 +0200 (MET DST)) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 1675 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: si215603@ci.uminho.pt Cc: amiga-gcc-port@lists.funet.fi Subject: Re: explain-me a thing Hi Luis (Luis Antonio F.Alves), in <9507101945.AA00105@pessoa.ci.uminho.pt> on Jul 10 you wrote: > > If a start a program from double cliking in an icon, or putting it in default tool of an icon, like more in txt files, > > how can an see the name of file in 'C' or the parameters passed by the icon > in a 'C' program. Here's one way, that has the advantage that produces argc and argv the way you would expect them, regardless of whether you run the program from the Workbench or the CLI: -----------------------------------CUT HERE----------------------------------- #include #include #include #include int main(int arg_c, char **arg_v) { int argc; char **argv; struct WBStartup *msg; static char name[256]; /* declared static to save stack space */ int i; if (arg_c == 0) { msg = (struct WBStartup *)arg_v; argc = msg->sm_NumArgs; argv = (char **)malloc(argc * sizeof(char **)); for (i=0; ism_ArgList[i].wa_Lock, name, sizeof(name)); AddPart(name, msg->sm_ArgList[i].wa_Name, sizeof(name)); argv[i] = strdup(name); } } else { argc = arg_c; argv = arg_v; } /* From here on, you can use argc and argv in the usual manner. */ } -----------------------------------AND HERE----------------------------------- I hope this helps, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "There is an art to flying, or rather a knack. The knack lies in learning how to throw yourself at the ground and miss." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Jul 12 13:53:48 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <89438-1>; Wed, 12 Jul 1995 13:51:09 +0300 Received: from pessoa by torga.ci.uminho.pt (5.4.1/140.2) id AA09072; Wed, 12 Jul 1995 12:51:31 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA12460; Wed, 12 Jul 1995 12:49:42 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9507121049.AA12460@pessoa.ci.uminho.pt> Subject: Were can i find kickstarts To: amiga-gcc-port@nic.funet.fi (gcc) Date: Wed, 12 Jul 1995 12:49:42 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 534 were can i find kickstart images for A3000 but this one loades it's images from the disc DEVS:kickstart and how can make it work i tried before but failed i tried to copy an image off 40.XX kick and i had to install the old one. __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Wed Jul 12 14:27:45 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89398-2>; Wed, 12 Jul 1995 14:26:03 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 12 Jul 1995 13:24:58 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA26114; Wed, 12 Jul 95 13:25:00 +0200 Date: Wed, 12 Jul 95 13:25:00 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9507121125.AA26114@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA03334; Wed, 12 Jul 95 13:25:00 +0200 To: amiga-gcc-port@nic.funet.fi Subject: gripes about MIME rewrites Hi, I got a message in MIME-format twice, once directly, once through the list: the first (direct) one contained: ---------- Received: from konrad.lysator.liu.se ([130.236.253.6]) by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10061; Thu, 6 Jul 95 00:44:33 +0200 Received: from lysita.lysator.liu.se (lysita.lysator.liu.se [130.236.254.153]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id AAA28423; Thu, 6 Jul 1995 00:43:49 +0200 Received: (nisse@localhost) by lysita.lysator.liu.se (8.6.11/8.6.11) id AAA03912; Thu, 6 Jul 1995 00:44:09 +0200 Message-Id: <199507052244.AAA03912@lysita.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: (message from Pedro Miguel Sequeira Teixeira on Wed, 28 Jun 1995 19:14:21 +0000 (GMT)) Content-Length: 3352 X-Lines: 88 From: Niels M|ller To: l36599@alfa.ist.utl.pt Cc: niklas@appli.se, hoehle@inf-wiss.uni-konstanz.de, amiga-gcc-port@nic.funet.fi Subject: Re: fork() with MMU? VMMs problem... Date: Thu, 6 Jul 1995 00:44:09 +0200 [nice mail with ISO characters deleted] while the second said: ---------- Received: from nic.funet.fi ([128.214.248.6]) by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10072; Thu, 6 Jul 95 00:47:14 +0200 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <89006-1> convert rfc822-to-quoted-printable; Thu, 6 Jul 1995 01:44:48 +0300 Received: from lysita.lysator.liu.se (lysita.lysator.liu.se [130.236.254.153]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id AAA28423; Thu, 6 Jul 1995 00:43:49 +0200 Received: (nisse@localhost) by lysita.lysator.liu.se (8.6.11/8.6.11) id AAA03912; Thu, 6 Jul 1995 00:44:09 +0200 Message-Id: <199507052244.AAA03912@lysita.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE In-Reply-To: (message from Pedro Miguel Sequeira Teixeira on Wed, 28 Jun 1995 19:14:21 +0000 (GMT)) Content-Length: 3370 X-Lines: 96 [ugly mail with lots of MIME-broken lines deleted] Obviously, something along the way decided to cripple (e.g. transform a mail in clean 8bit format to stupid quoted printable). I suspect that the amiga-gcc-* list server does this and I wonder if there's a way to stop it from doing so. Don't touch others mails :-( Nobody is required to have MIME installed and the quoted printable format is lousy for non-MIME mail readers (lots of weird looking characters, lots of broken lines). Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Jul 12 14:42:42 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <88966-1>; Wed, 12 Jul 1995 14:41:10 +0300 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.6.12/8.6.9) id NAA14901; Wed, 12 Jul 1995 13:40:44 +0200 Date: Wed, 12 Jul 1995 13:40:44 +0200 From: Ignatios Souvatzis Message-Id: <199507121140.NAA14901@theory.cs.uni-bonn.de> To: hoehle@inf-wiss.uni-konstanz.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: Joerg-Cyril Hoehle's message of Wed, 12 Jul 95 13:25:00 +0200 <9507121125.AA26114@inf-wiss.uni-konstanz.de> Subject: gripes about MIME rewrites X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a; Thu, 13 Jul 1995 16:08:02 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 13 Jul 95 15:06 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 13 Jul 95 15:03 MET DST Message-Id: Subject: Gcc2.7.0-prerelase crash To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 13 Jul 1995 15:03:36 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 503 i reinstalled gcc and tried to get gcc2.7.0 working on a stock A2000. gcc,gccv,m68000... all crashed with 80000003 were as,ld,ixprefs produced atleast a version information. walter ps: 'version gcc' didnt work ? -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Jul 14 17:52:06 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <89138-4>; Fri, 14 Jul 1995 17:46:03 +0300 Received: from pessoa by torga.ci.uminho.pt (5.4.1/140.2) id AA07661; Fri, 14 Jul 1995 16:46:33 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA19026; Fri, 14 Jul 1995 16:44:44 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9507141444.AA19026@pessoa.ci.uminho.pt> Subject: subcribing problem To: amiga-gcc-port@nic.funet.fi (gcc) Date: Fri, 14 Jul 1995 16:44:44 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 586 when i subscribe to this lists i gave me porblems with my email adress now i tried to subscribe the amiga-gcc-info and it gave me the same error could anyone resolve it or tell me where to ask for the guys that can resolve it i want to subvcribe amiga-X11 amiga-gcc-info amiga-mach __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Fri Jul 14 17:55:17 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <89272-4>; Fri, 14 Jul 1995 17:54:52 +0300 Received: by math.uwaterloo.ca id <77127-4>; Fri, 14 Jul 1995 10:54:11 -0400 Date: Fri, 14 Jul 1995 10:54:10 -0400 From: Jeff Shepherd To: "Luis Antonio F.Alves" cc: gcc Subject: Re: subcribing problem In-Reply-To: <9507141444.AA19026@pessoa.ci.uminho.pt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 14 Jul 1995, Luis Antonio F.Alves wrote: > when i subscribe to this lists i gave me porblems with my email adress > now i tried to subscribe the amiga-gcc-info and it gave me the same error > could anyone resolve it or tell me where to ask for the guys that can resolve it Are you behind a firewall? jsshephe@math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Fri Jul 14 18:18:27 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <89461-1>; Fri, 14 Jul 1995 18:17:34 +0300 Received: by math.uwaterloo.ca id <77154-1>; Fri, 14 Jul 1995 11:17:09 -0400 Date: Fri, 14 Jul 1995 11:17:01 -0400 From: Jeff Shepherd To: "Luis Antonio F.Alves" cc: Amiga-Gcc List Subject: Re: subcribing problem In-Reply-To: <9507141500.AA20291@pessoa.ci.uminho.pt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 14 Jul 1995, Luis Antonio F.Alves wrote: > > > > Are you behind a firewall? > > > > > > whats a firewall? > > but i think i'm not. because e subscribe this list > but if could explain me what is it i would ask the big boss here. A firewall is a mechanism that allows machines inside the "firewall" to have full access to the internet while machine outside the "firewall" cannot access machines inside the firewall because to them, the machines inside the "firewall" don't exist. For example your machine names are not in any DNS databases outside the firewall. - "finger si215603@ci.uminho.pt" returns "unknown host: ci.uminho.pt" If anyone can give a better explanation feel free. jsshephe@math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Fri Jul 14 19:31:11 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <89963-4>; Fri, 14 Jul 1995 19:29:38 +0300 Received: from pessoa by torga.ci.uminho.pt (5.4.1/140.2) id AA09194; Fri, 14 Jul 1995 18:30:58 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA24550; Fri, 14 Jul 1995 18:29:13 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9507141629.AA24550@pessoa.ci.uminho.pt> Subject: To: amiga-gcc-port@nic.funet.fi (gcc) Date: Fri, 14 Jul 1995 18:29:13 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 353 thanks for the new adress for me how do you do it. __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Fri Jul 14 19:36:19 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <90893-3>; Fri, 14 Jul 1995 19:35:29 +0300 Received: from pessoa by torga.ci.uminho.pt (5.4.1/140.2) id AA09297; Fri, 14 Jul 1995 18:36:26 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA24761; Fri, 14 Jul 1995 18:34:45 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9507141634.AA24761@pessoa.ci.uminho.pt> Subject: help mailinglist To: amiga-gcc-port@nic.funet.fi (gcc) Date: Fri, 14 Jul 1995 18:34:45 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 361 how can i send mail but with that adress that you gave me? __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Sat Jul 15 19:02:03 1995 Received: from erlang.gbar.dtu.dk ([130.225.87.177]) by nic.funet.fi with ESMTP id <89732-2>; Sat, 15 Jul 1995 18:59:22 +0300 Received: by erlang.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Jul15.185922+0300_eet_dst.89732-2+26@nic.funet.fi> From: To: Date: Sat, 15 Jul 1995 18:59:21 +0300 Date: Sat, 15 Jul 1995 18:02:04 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: RELOC32_SHORT + status request Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I think the linker (ld) should support RELOC32_SHORT hunks. These only work from 2.0(4) and up, but since this is now a requirement already, I think the linker should support RELOC32_SHORT, as the savings in harddisk space are suprisingly big. Btw, what is the current situation with gcc 2.7.0? Does stack extension and -resident work? When will the "clear.l Dx" instructions be replaced by "moveq.l #0,Dx"? Please cc: to me as I am not on the list and haven't been so for some time. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Sun Jul 16 14:23:49 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89345-4>; Sun, 16 Jul 1995 14:23:01 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id MAA00363; Sun, 16 Jul 1995 12:21:31 +0100 From: Lars Hecking Message-Id: <199507151758.SAA16279@mostar.nmrc.ucc.ie> Subject: gcc 2.7.0 -resident To: hans@wyst.hobby.nl (Hans Verkuil) Date: Sat, 15 Jul 1995 18:58:39 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3367 Could you be so kind and check this out, please? (edited for readability) :> tar xzf sed-2.05.tar.gz :> cd sed-2.05 :sed-2.05> sh ./configure checking for gcc checking how to run the C preprocessor checking for install checking for minix/config.h checking for POSIXized ISC checking for ANSI C header files checking for string.h checking for vprintf checking for bcopy checking for memcpy checking for lack of working const checking for working alloca.h checking for alloca creating config.status creating Makefile :sed-2.05> make CC=gcc-270 "CFLAGS=-g -resident" "LDFLAGS=-g -resident" gcc-270 -c -DHAVE_STRING_H=1 -DHAVE_VPRINTF=1 -DHAVE_BCOPY=1 \ -DHAVE_MEMCPY=1 -g -resident -I. sed.c gcc-270 -c -DHAVE_STRING_H=1 -DHAVE_VPRINTF=1 -DHAVE_BCOPY=1 \ -DHAVE_MEMCPY=1 -g -resident -I. utils.c gcc-270 -c -DHAVE_STRING_H=1 -DHAVE_VPRINTF=1 -DHAVE_BCOPY=1 \ -DHAVE_MEMCPY=1 -g -resident -I. rx.c gcc-270 -c -DHAVE_STRING_H=1 -DHAVE_VPRINTF=1 -DHAVE_BCOPY=1 \ -DHAVE_MEMCPY=1 -g -resident -I. getopt.c gcc-270 -c -DHAVE_STRING_H=1 -DHAVE_VPRINTF=1 -DHAVE_BCOPY=1 \ -DHAVE_MEMCPY=1 -g -resident -I. getopt1.c gcc-270 -o sed -g -resident sed.o utils.o rx.o getopt.o getopt1.o symn = $3a4, extern = 1, addr = $21fe. ld: base relative text relocation in sed.o make: *** [sed] Error 1 :sed-2.05> gcc-270 -v -o sed -g -resident sed.o utils.o rx.o getopt.o getopt1.o Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/specs gcc version 2.7.0 ld -databss-together -datadata-reloc -fl libb -amiga-debug-hunk -o sed \ /gnu/lib/rcrt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 \ -L/local/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 -L/gnu/lib -L/local/lib \ -L/local/lib sed.o utils.o rx.o getopt.o getopt1.o \ -lgcc -lc -lamiga -lc -lgcc symn = $3a4, extern = 1, addr = $21fe. ld: base relative text relocation in sed.o Thus: :sed-2.05> gcc-270 -c -g -resident -Wa,-ahl sed.c -DHAVE_STRING_H=1 \ -DHAVE_VPRINTF=1 -DHAVE_BCOPY=1 -DHAVE_MEMCPY=1 >sed.lst Excerpt from sed.lst (386k file; didn't want to post that all ;) 1242:sed.c **** ptr = ((errno >= 0 && errno < sys_nerr) 4087 .stabd 68,0,1242 4088 21ca 47EC 0000 lea a4@(_errno:W),a3 4089 21ce 200B movel a3,d0 4090 21d0 2040 movel d0,a0 4091 21d2 4A90 tstl a0@ 4092 21d4 6D34 jlt L352 4093 21d6 47EC 0000 lea a4@(_errno:W),a3 4094 21da 200B movel a3,d0 4095 21dc 2040 movel d0,a0 4096 21de 47EC 0000 lea a4@(_sys_nerr:W),a3 4097 21e2 200B movel a3,d0 4098 21e4 2240 movel d0,a1 4099 21e6 2650 movel a0@,a3 4100 21e8 B7D1 cmpl a1@,a3 4101 21ea 6C1E jge L352 4102 21ec 47EC 0000 lea a4@(_errno:W),a3 4103 21f0 200B movel a3,d0 4104 21f2 2040 movel d0,a0 4105 21f4 2010 movel a0@,d0 4106 21f6 2200 movel d0,d1 4107 21f8 2001 movel d1,d0 4108 21fa E580 asll #2,d0 *4109 21fc 47EC 0000 lea a4@(_sys_errlist:W),a3 <<= addr=$21fe Could it be that /gnu/lib/libb/libc.a is _not base relative? I did a "objdump --disassemble-all --syms --reloc" on libc.a(errlst.o) and libb/libc.a(errlst.o), but the output was identical. Is that correct? -- "... nobody really knows what the Bourne shell's grammar is. Even examination of the source code is little help. " -Tom Duff, "Rc -- A Shell for Plan 9 and UNIX Systems" From amiga-gcc-port-owner@nic.funet.fi Sun Jul 16 18:52:46 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89681-1>; Sun, 16 Jul 1995 18:50:14 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sXVwI-0004nYC; Sun, 16 Jul 95 08:49 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: gcc 2.7.0 -resident To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Sun, 16 Jul 1995 08:49:06 -0700 (MST) Cc: hans@wyst.hobby.nl, amiga-gcc-port@nic.funet.fi In-Reply-To: <199507151758.SAA16279@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jul 15, 95 06:58:39 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1217 > Could you be so kind and check this out, please? > ... > gcc-270 -c -DHAVE_STRING_H=1 -DHAVE_VPRINTF=1 -DHAVE_BCOPY=1 \ > -DHAVE_MEMCPY=1 -g -resident -I. sed.c My "HAVE_*" args here also includes HAVE_ALLOCA, btw. > gcc-270 -o sed -g -resident sed.o utils.o rx.o getopt.o getopt1.o > symn = $3a4, extern = 1, addr = $21fe. > ld: base relative text relocation in sed.o I get the same result here. > Could it be that /gnu/lib/libb/libc.a is _not base relative? I did a > "objdump --disassemble-all --syms --reloc" on libc.a(errlst.o) and > libb/libc.a(errlst.o), but the output was identical. Is that correct? I doubt that the entire library is not base relative, since I use the exact same compiler and libraries to compile pdksh with -resident, and that works fine. There are a number of modules that are identical in both libraries, according to "cmp", which I find a bit odd but not alarming. In particular, errlst contains only data, so that is probably ok. However I do notice that it is constant data, which means it gets linked into the code section. I don't know the details of how resident works at the low level, so I'm not sure if that has any significance or not. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Jul 17 13:00:18 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <89912-2>; Mon, 17 Jul 1995 12:57:21 +0300 Received: from freenet-a.fim.uni-erlangen.de by uni-erlangen.de with SMTP; id AA01311 (5.65c-7/7.3w-FAU); Mon, 17 Jul 1995 11:55:52 +0200 Received: by fim.uni-erlangen.de; id AA25911 (4.1/7.3r-FAU); Mon, 17 Jul 95 11:53:51 +0200 Date: Mon, 17 Jul 95 11:53:51 +0200 Message-Id: <9507170953.AA25911@freenet-a.fim.uni-erlangen.de> From: cu154@fim.uni-erlangen.de (Federico Di Gregorio) To: amiga-gcc-port@lists.funet.fi Subject: unknown, I lost your address :( Reply-To: cu154@fim.uni-erlangen.de This is for a guy that asked about WBStartup, icons, etc... I promised you to send some info grabbed from autodocs, RKM and more, but I deleted your mail and I dont have your address anymore... Please, send me your address, so I can send you the stuff :) Sorry... -- *-=@<:) Federico Di Gregorio cu154@fim.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Mon Jul 17 13:07:04 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89112-4>; Mon, 17 Jul 1995 13:05:55 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA07189; Mon, 17 Jul 1995 11:04:26 +0100 From: Lars Hecking Message-Id: <199507171007.LAA17322@mostar.nmrc.ucc.ie> Subject: Re: gcc 2.7.0 -resident To: fnf@amigalib.com (Fred Fish) Date: Mon, 17 Jul 1995 11:07:04 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Fred Fish" at Jul 16, 95 08:49:06 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 757 > > gcc-270 -c -DHAVE_STRING_H=1 -DHAVE_VPRINTF=1 -DHAVE_BCOPY=1 \ > > -DHAVE_MEMCPY=1 -g -resident -I. sed.c > > My "HAVE_*" args here also includes HAVE_ALLOCA, btw. I do not always get consistent results with configure. Sometimes, the "how to call the preprocessor" yields gcc -E, but the subsequent "are we using gcc" yields no. Similarily, configure sometimes determines that I'm crosscompiling. > > "objdump --disassemble-all --syms --reloc" on libc.a(errlst.o) and > > libb/libc.a(errlst.o), but the output was identical. Is that correct? > > I doubt that the entire library is not base relative, since I use the > exact same compiler and libraries to compile pdksh with -resident, and > that works fine. Same here. From amiga-gcc-port-owner@nic.funet.fi Mon Jul 17 17:40:23 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90009-3>; Mon, 17 Jul 1995 17:34:39 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sXrF0-0004nZC; Mon, 17 Jul 95 07:33 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: gcc 2.7.0 -resident To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Mon, 17 Jul 1995 07:33:49 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <199507171007.LAA17322@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jul 17, 95 11:07:04 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 614 > > My "HAVE_*" args here also includes HAVE_ALLOCA, btw. > > I do not always get consistent results with configure. Sometimes, the > "how to call the preprocessor" yields gcc -E, but the subsequent > "are we using gcc" yields no. Similarily, configure sometimes determines > that I'm crosscompiling. The first thing I do with autoconf using programs is rebuild the configure script using the Amiga port of autoconf on my FreshFish CDs, which installs a number of workarounds in the configure script for known problems, the biggest of which is that pdksh handles args to the builtin echo incorrectly. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Jul 18 05:45:31 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <88941-2>; Tue, 18 Jul 1995 05:44:25 +0300 Received: from cnts1p18.uwaterloo.ca ([129.97.112.18]) by math.uwaterloo.ca with SMTP id <77163-2>; Mon, 17 Jul 1995 22:44:02 -0400 Date: Mon, 17 Jul 1995 18:43:55 -0400 From: Jeff Shepherd Reply-To: jsshephe@undergrad.math.uwaterloo.ca To: "Kevin D. Brierly" cc: Peter Ivimey-Cook , Amiga-Gcc List Subject: select() for AmiTCP-gcc Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2124320750-1871735711-806021035=:131205672" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. 2 ---2124320750-1871735711-806021035=:131205672 Content-Type: TEXT/PLAIN; charset=US-ASCII Good News. I finally got enough time to implement select() in the SDK. The new select() should be able to handle sockets + non-sockets at the same time. Just change WaitSelect() to select() leaving off the last argument. Attached are the files that changed. Just drop them right into the source distribution (available on aminet in comm/tcp) and recompile. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/ The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. ---2124320750-1871735711-806021035=:131205672 Content-Type: APPLICATION/octet-stream; name="tcpgcc-dropin-files.lha" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: OGItbGg1LeABAAApBAAALaDxHgAAImFtaXRjcC00LjBcc3JjXG5ldGxpYlxf dGNwc2VsZWN0LmMr+gHAY5etpuX8w/AH6KtVIKbAbiypi5WhLVVpQEALbjag 5+FasJIm2BahXxu+3Ia3Iy1S3Du28Vvh2rTTnJIMqZxD7w5cUMRuHsfsxZyg 9ER+rsihsA39btAygNQsCMJUzCDhaWJonC1bNyJnRNskEPqvxXbZ40iv5d3P +4zJJk6f7DTR/IRHW17jF0rkXQjvFnqML/mo1cY4qVO6rj4MFU4JnYDod43m FsrGYUFUbJjEAMc7EU1QweWxWwvtzotS0wOoVUw6NclXumg+uiQXzbzNxC2E pF53nLIdZYqTPAFGxkAD4VyK6wxOsdscwM2hfDfcgueRJp1ElK+fqzhfvhmh iwduE+TLDk6MsL5rChZsJqXKyK9yWI7ge4I0N5rCI1i0x248MJbM5jWK9hVY teix9Z8MPTo64LMsgfCQErDdGWzJ9QS0KBQxyWYJafjzynXQ/ebuF1C6sJ80 Od54nW/wnQcqZ37xrGkiveSU433Hoz+9+3KSwfa/lmL/oCH84PdAFq4aW82v ZCET9EI0P5VagUi+H4KuZnbWeu/P6Nxi5auKwcrNsGLRFE/UW/ymz4Mh/OiB VwDFq7swKRUnKzvqcqGtbjRzykN4r3Xw+wXQ5guP3iOOVNXFl4gPpMMTHDYy LWxoNS17CwAAFh0AACyW8R4AACBhbWl0Y3AtNC4wXHNyY1xuZXRsaWJcYXV0 b2luaXQuYzXbCO11uu6tNt0rrC+AP+FsdEUYDblm5GRvcGMbhyECcYS7l5Ze LiEvJtWISMl5Nwsz+C++IX7/7ySQNtsmluut3Nb0N092N1N2N3vvu0bbbdkS 2l9wnIoZEk50NxlX5r2Tgq/Pgd3yblTE/C+my5Y6S8lneLc83m8lq35rW75i 3d7ft+bft7pffG397ZX/foL56txi1XYKvUpGC2yyXclq9QS324H/wBzihJ6W Fw/hIT0UZZpHZInPchNmB/NG3HpBIMl3otGmN/n6El/VR/K7nfy3vXawesuW OKXRYMEqVCxIT1RR+4skUEqyrxo6UQRaM6IUlghcszBF2CAlFCQo0SIj6UOn 1WmGPmfhcgldQXnR70OWk6dCJLPRw9/Of4zNyI+PUtOn1i2rsfhTK+aK2qPj 3AOiOJMVqZgPYWF9Jl7uEnAbaSe0oH7zxIl1+LtJ44gMdyeRxw9wM3IGNp7i c3nfS5omSY2Bpb51sidQ8/CgmsGLLf5sV3C1yYMN8rVckxFzoSQSdEcLcBPP wIJQapNjbxOOekDN/DUJf9SN8nNfu8dguT+XNgy31CFKmaZLTzkKYO5YxzOA qybOYz/+6+UxGdrE/zX7WYoIuf+zqYUJH61Omp75Q2pYlMwniy473ry81bQm Nkq1bpifdKuzWX9/P5y3WWWGIIoecnnbzcEGZtz3Vg2IfawbaibVKyzcYR7z burjUs5zRFImOVxK3FVyaaDZGj+kxCZuG2Q/m00FvficTBW7BN6wUsMj/PCh 1RajR/OVEiVnt+GKWb5Nx88CIbC6LA+mgIjQV40Nu9pWlezWJqQuaV55EfcZ gS+dPRrIfVG+lH/iI5BFJsImsBkRAgdfcwTQtZF9jTmeZvb8TWeJ1AH6Hnyy RlWr1px833h5+TTJxCETb4cvQ/Jlbk923wpcayxt6ONtLZvimD8K6iJV8ioe TFC4CxezDhuMbK4OTHe9N/Liu+q/9v3AGq+FVkVp1sfa9ccXPG3nxN50XKEs WP/Xf5smDHiLeKoIMc4muzy56a0pdKI5Dm/E0YU5VT9VfwuWCLMJ5+hpUN7E 8JU33CIW7hhSv4oVoransPFX/5/MMHQoNaWKLOa7OJXiu7LOPJPZxWMZPsxY /XkwZGKmHHi5SayZcDW7bttRaEQrbTIqXoOIqKmCADxqAVQY9wEZR5PZivZQ zVipl6BZb1W4jKZNwukoaJPQjZbxJtKugPSjTLoCpgPR7wqcTyujQt11g7XG gQ5vi3Bps1OQXPm5+ydyCTQBipQgIibSWeUQSZkFA/D7hId1Pp6CXSX35nEl WBMkizoLpFshuFLNnYpjcdBCfhKKGDST/YkISAS8IhcRIfMxU51wKSac+aKA qtMY9WyGuYFjk7BnG4TSQ2ZIEqZ9Xyc2yAmCCRipsaTOlZUmnKK1YEgx5KBg BazgpIm3XQ1aRTpFOFf/BE7eFxdKYjmgo5TPr4rBzuWYqa2BQiVQqwN2Y5/1 sqXYdCC5waW+dEjNBumPzFSYuKkvDi6DoKzhdXQ+50K7lF0CEUAmIJQUpy7F SNCZYwzgO4XI9jy3xHF+TQW4JIhQ2Q57jdTPEBpkSjPRPE+CylipAhsQe738 LJYErF9EoxRJdAh8msABCpoCNjknwrcMQqeRShcgrIKwWvqjO2NMajgMymwz ZN2bJz5gYxSM78kE4kXkNheUAzHI4+8KipvsBOVQQ8tki9EXUMhSOwuR3UPz Q5KdOciocMAIVtLuLJgZFE1yLPoFfWMSjpiisjLwbz6A5V6KCCLqk3wnHtrn OAqbw1YztvwhsFf2jqbSc41b5UPxYnqBmlb8nQeIVMGWDxFFELdtnZXN6/F7 OXItlshwF/FmXVFD9CSVmKqzYQqU1RvyjPMNqCvqxU8tn6rZuRgbSGvBk+M5 0upvSuS1bcAYjwR/lnhKe5m0rSJcyy6LlJuzAhx6QWxPYCRsS6mlWcDNB1dL 9SuE3WWLE04n5wQrYZmXNqM/Ii45TqSg1iJ9+F1vOJkFThCBmh9yo2XxC7Ij Q3GbBZ6lFOfXNZNv3yu4cmP40jrXfSFFCpeot5S9gwC/okLllfGQToslueT6 lOtdGS4/AqSL8ZDf0WwIjX///MU33Thvhlz5hI2IqzppnLBQ7k6S0infqqEv xDGfFteSbF/SeAeUgwfB9KLev67DQf5MykPrXrTnesY/S9Z8A47vxOME+pMb g7gAMmXmGbAupxkTGqVM1hII/eOocWPJPSVVy2h+TmmGON3lyuz5GdvhPPc+ uapj5xUmZVAr2TaTmDGeAZ8dvDWZuzHqMQmNw6VJ0zTjzWO3GyZVQ0PIdZL4 CoYtLRj1OHbernHkLUbgK1bv69mUlcoIF6LPnEO2EZEWA9cx5twY+w02gSJ9 K+ct7fDojavYcBrtU15MpnSt4vAGL+JdnGZ5sjMLxDNHswQtKGt+gzA6bfCP w1MiZ9zM9RdbZDbNklcNVnpYLJYoupd/fwbtvzh23rvDnLvFLGU2WJ+gDRl0 TgZ8mvAEm6bSv2b2+6gbk4svqayB313CfzvNX+bmGUwFnPCCierKL7LLNgtp XyFD2fck8Bv0KHDkiOCMCMyPfqJ4cfLluzB+t1moTHe1fxcbK41Jo1t6i0Xx y6N1aq1j1G4Yqx+B4hZsbe4zc/wAjYn/YCCeTASgNeG4eiERdY/9EEi2vzzk Hp4U+Ihnwwd6a26KWs+YEq9OKQrz8cibNVRf7KEvdLtVp8NzPqjWC3vKtGDe r2jmqYE0emlDvtyaci/lMRL+SZWaPvZRI0sDyHlA8BTQC0AEzLuwQ5IBCSvV b8OvK+mAyP269uwGHgKhok5xhh8Gqov4A/K26PAX0BNW+elB45KsyjmsXMvI NuxiN02CiIaghWCXw1rpw4bWtFJ3yXjxHZ279jVmaH70VVuthj99Zv4Md8vE 7l+w1au5a7/HduM/deu4ZqtcxR028hcC+84aW80XSifXVGDJG6WC1jsDVinz bhidAldT50m58J0m3jir7xYyrQb0OquGn4gVdw36ty20+PACggtLkCacn8Q3 /dg/40gOTjvXcOHiu3vSKCNPiYbFNAaeNZemeKIB0tLBVbzcJ58cyDahvxVZ mp0u5NpTGudLr/34tNR6jRzvr0bh0O2x4aVuTPWqu21mbt7tyju3F92zxF9e u8fQs3bth9URLzpcDqpUVnoQCO7iumQZQg1iK1KJKVtw4KQzziaHksr++MtE CW0PD+WZWojNv2vO/cLqIOQ6DOS8/pX3noYTMPv8V3j5NQBt8LzR+aROizx5 fs9d9pd/RV+P5OLpaNvmpVbxusnCAbn2yXcD8VWwrx96yDOeRsYmWxy9bFSu 8uitU11eiGZmhsYDneu4g2x3jXh3d4HnQKvBAonK20bZdocs+naPkakg+TJw VCc1aOsFrbGkNCdafxiAXnCdeN2rYECKyVsZ93qT6r/qMG1tALtaBco7VeRM OpRR5FmnrPyVk/Ufzp6VeUen6lfSnrm8hvwa/Ii09q/EFcGryQlPW9NXQV5v v+i/N9XD84mZ8tLSmbxxIoCUG9OazIlXkfgN5GsHJM8icq9GrH15BEh6BRcO QRlTrPxfF2vhvei/e9O/M3jtjZ8Iw9UG00Z3eVx5HJuWBIJ/+Yvn4ekU8nZp h7Jzi0FjBiFLdVE0/NsrmYDEus/PAPFbY/bzdi6ip+W38KDTy6Awrr1n+C3c J8Z7GLGfo2R8/p+meoK9wa2EP/dcox6XqIdODth0La2j8Ogll6dyy5C/hQq7 yyL1z1JlaCmsRXJ7c7596poJ0Les7Ehc9423n3Fb4U0GlVd2ufyyVDnZj4u3 X1sfMgDDzDAqelWqkVkeDHTcH7Fd7NIXtqtNNXsuPmaw4MmVpr21bG7u2LY/ wbP/q0kaA/9K3dr7/sSuP8yVswMVMYA4di1saDUt0gEAAEwDAABUkfEeAAAi YW1pdGNwLTQuMFxzcmNcbmV0bGliXE1ha2VmaWxlLjAwMLYyAddrm62m9H+Y fwB8l+cFnASmy3DRbJYsKVAihVgEtwZJpjnpBokbib9NafHLzhoa5LXdn94a pNu3/vJXIaGVCFItF6iGcOHMIq1n/Dsmk+Hd3fINI0UBt4jZxF86Jpg+gUrW ibPqy+O0yYtgYs2vYnRr1aNfgnbuzZft4mklOXy0bpvNKTJs1ZkausjBGzv0 mBfF3o2VwKtJzGsIxJ9HsIYgeKp4811OhFCe2uvmfP8IC76kSsZGBPF3ueYI 0JM6hrdGqMcsqvaPudtgL6XutsNiph7t0shi5Knnf+hNJyjFY9jSoVbUXtRr lI0a9h6640KCmq+J4TUyBXmsvxm+cOW/J9alrGy6EEkwKdjugxpu0+Ibbg9Z YreEIsuXyEuCjgVU3Ic4VOpMFtKZnNIfUt3Rm+aIubVVx6fs9Uz3buYLFNYs xUKqqdEB5Q2OCn3ZTRAlfzcUkuyA1Cs1EI2b93nv3H28qZwVWw28ePHKpCJd u/Pn0ffw25AlWEvEDoUsESnXsiMGHsmmkA+N3gJIGJYYfmGJwYfqiWH/wSDy gMhudL9IhHUXRbv0yIwPr98VwKeD7f6r+49TTZ/0muz3kO2ltva6GI1kIv8t cgNEjRl4oDiqLWxoNS3UAQAARAMAAFqR8R4AACJhbWl0Y3AtNC4wXHNyY1xu ZXRsaWJcTWFrZWZpbGUuMDIwhpQB22OXrabj/NX4A/SxwU4JLdVllqLZLFhS oEUKsAluDJNMc/INEjcTf5rTxy+4aGtu79eGqTbt+HirgNDKhCkWi9RDOG7i EVaz/h0zYfj29vyDONFAa942bxfOiaYPsFK1omy6MfhrMkmoJMmnUnNp0ZtP enXsyY/x4GklOPxzbJvJKQkr+f06+zrNTVoyI0c5mCNXdnMC97vNsrgVaTmN YRiT5vYQxA8VTx5rqdCKE9tdfE+f6QF31IlYyMCePvc8wRoSZ1DW6NUY5ZVe sfc7bAX0vdbYbFTD37lZDFwVPO/+CaTlGKx7GlQq2ovWjXKRo17D11xoUFNV 2HhNTIFeay/Gb5w5b9n1yWsbLoQSTAp2O5DGm7T4htuDzlit3Qiy5fAS3KOB VTchxhU6kwW0pmc0h9C2cmb5oi4tVXHp+z0TPdu5gsU1izFQqqp0QHlDY4Kf eFNECV7bikl2QGoVmojVt2eW3Yfbupm5VbDalUhEuvbly5vz368QSrCXeBz0 sESnWsSOjB0zTYQPjd4AYQkWGD6hI4MH3RLD/wSDyQMRucr3hQjmLkt3Z8KO h9fviXQp4Pt9kv7Eqaa3+jV2e8V1Utt6nQkNNCL/KXEDRI0Zd6A0LC1saDUt xAMAAJIHAAAJkrEeAAAeYW1pdGNwLTQuMFxzcmNcbmV0bGliXHNlbGVjdC5o 88EDh2uXsaccuxpPAH6VwKHJ1gySdbCYTr5zuFQkiALLMIWjfweob3Wt3WHH jl/d1snRW3u64FwKs+573vatpOYPd0h7gDTQdYbT0iBf/WZTATtA/zGqymGk +xRlcg2pUDKBCOo+40LpaRNfJR91DAvSXwi7e2KBv+4gDMZW+xYZoQ8z0zlG etmup7bioRBadrOJlD3ByTYExkAoZzrYo+yxhBBgGRPgSp1BqTOfbyb5LETi 8IMFVS2jBv0+PhqDLbYfiKBUakPKzZSeZ0/lPMKFiBiMzfKugZw2cnTXe0G6 LQaHekrCZh0o7gE5e94A4CpZeMMV1wtqMAEj14zGkRQJrbMXyHPIKTEILpeH /UK9TjOB0OrNCayLlBVMjdxPTSGwQsWO2ymB1DKNDzyafl46tIR+HoHnHnzx +Gn07ijWUJL2jwF9LPVXScq0RaUZDORD11CzS55PkUnH+uTLk0+jSJ35NPhL o0B3+OcIw8o8+nJJqyx5w8tWfy8dEsIBoEblstVX/Fw5rY3DmpJKnOLDHpXz QT0J8FkKKZwoNwEn4mE/AhMYJixa/906Uo3OPRSvqrvcB9oISyAOKjligxPN 7XT33fGAMiJoYA9/59hZkrWEfAngkNVsUefcXyzRhhxRdXbAGrRHzJyxpGZk NEHAIoXfrdDevBhb/Aw9ePqw48P6AZuoAS/Ov7S7ftnHgd2MV1D9qJ60V9Gb IZEHYckSk/fQE1AzbyxA5hP6U3E6k9WCKLBh7ADFixxdePs6i1U4v2jAEDxJ eZ3tkdAs57+rsrrSpltW9hG6q4iqWCIg/iw4+r342/HnVbg+q2UfQ8HT0v4f Jx2nbApQ7cQyt1lQoYtwDejV6+7MAW+dzQXF6U01D+LdnK7Sy0UrtmyxZW18 6Up3lglvF2DmO5H9euGG2IvbYLZPXNVPAB06y4bhv/0L60rWfYVy4GpsH2Ez Za6JBpTLMd/pgCsVUGrW7zHLgRL1MPULdpJjFu04dN4/C3jc4jdrCzKbcdEu WWTTrk+Usn7PX1likNrh9yDU/lUZe9pifwPO4P/Mx2pq/g9ROeYrkt/2Zdz1 tpTUcmoMjcUs02QuH/4OZMW3iTN8NflnlLgGl6InFhT77xoFvIpckoJR61kO KUfiwNlKSyM+1PcSOjE6mrNU5kUboHcZ7VNMSxkiX3BHjly9EWH/mJtBz2G+ k9m8fhLryeHRh+vkLk9Is/35Zf4keIW2guEC1AwnSVo/lu4Grq8+OBAXi+81 95Kc7Qt975Ff1DOnJmlaA+zC386QOV8tbGg1LeABAAAtBAAAeJTvHgAAI2Ft aXRjcC00LjBcc3JjXG5ldGxpYjJcX3RjcHNlbGVjdC5jyOYBwGOXrabl/MPw B+irVSCmwG4sqYuVwO1VaUKgBbcbQN/hWrCQTbAtQr43fbgbXIy1S3Du28Vv h2rTTnIoZl0CH2PiwHlNw9kdeDIUHolR09cp6wP/WbAOpDQLgzBMucQgLW5d NAWLJuRdCZ9ahD5t8W2XeOoW/Du5/3Gcqdef+w10/yER19e4xc7VNpT3i70G F/z06OMcWMohVx8HCygF0OCEO4b9Ba7RnFJVGuYxADIQ5OqqGETXM1l9wdFi bVJChVTEJ0qq910o00qGM24z8QvhMTch5zKQ0sVLokCnW6QB8N8jfWHL0jsz Tg7YF0N1qS15EmoUSYr5+bOF26GM8t7svo7cR+3oxHjNWYLtZNS1vIt2rcnu CLgjQ3GrJzNF5jsw3zlszmNW37CqxbFLh6kXz/XL1SV5lB7lAtobcxbMo0BN SwGDmVXkm1e/nmQ2mO4/cMKF030Yz5IoidcfCdJyrojuGrZyK95JTjfcOXJ7 X7axbh9b+WYv+gD/i97IAtXDqfza9UIRPzQjw/lVqBiboZL3aj7lYMcNtRW/ j8n41guYGZOV2yTBllljqNf5VcaIFXAcXr+vIxNSg3nfQ5UNe4HjomJfxbtx h9AthzBajuEcgrauLsRAfOYYmWA6hS1saDUtOwIAAEEFAADVjO8eAAAkYW1p dGNwLTQuMFxzcmNcbmV0bGliMlxhbGxvY3NvY2tldC5j+qUCBmLX0baovzWe AP5sOJIRt2wNE0bko6UKbGU2qIipCWTul40ndHu6G2Xbxu/7uuoxsW74Hwbc wwiacl36CFMcgc8nV0ydD3lmlz9OgQcvRLmz9Ej2+Y89VtBA9iu9WJffYRWH Vy3jWTJmr3DFNUS8VdBkfwJJj07Q7EoWjEpE/YRe5WH/Ui+RIlJ2rBO5ZEnA x1g0ON64KWVc9hkTrqfF3tnWDKjCEsQWnUak5KGw6Sfe0ilxNyGOi3XimTTU Q8U+qZIQjksgj/q8kk1G1dtLpiB0nptKUib20VKlerzSu1Jlk/6XPUhW5L84 hRKiDBX6QWO0AcZLPXRr0bRLWigm1GLNVUifagQuj4dsSbulsmOad91oiY82 h2oDt/32uw4nIFCK5jHgD8vAP19RxtEbQVEQ7/CnNAKD745smumOBlm8BaII GI+Br2J1aqfp6uLj+0b2BVg8lFlfcLFvOmBtgWijkD0K+p96IXwT0JZCwDXW DZZrpZgRO4y3+PhgdTPi6jy2enlLKpAZNmsrrrHQFmCO6FXpwqW3WQY7hx48 YeAdcufN1+/3c8YYoQOgeS9XbN3qiDTavDhCHFuQFG/DEDi4/XHgGUZmQUKx 4h/6Q01dn6k7q4LVNSoBIzdUmXm8M3y6s+iS6s2eCXAy3HbWBkyBlzD4V5NE Ae0ObR8/hJKyvpNAcmvN8XZ7kVnUdiLs6qXGN6Mh5Gty3HN7xbDm5bjm9C9h zcv71zd0ByXdD3HpIu0eXRRovxeANx4tbGg1Lf8HAABrEwAADJbxHgAAIWFt aXRjcC00LjBcc3JjXG5ldGxpYjJcYXV0b2luaXQuYxcHBn5z63aNtt0r8yPg D9VrrUUE0nW5Xg25Jgomm6hVUmETLhhpQQUVybNhJ5Y9xbisF8F94hf/u4kp tttp6aDCz9m8C9ve9rG222pcK44iiTMpZRdMM5W82B71WfrxaOIoaFpjmjXd iudRei7vl93Dw+i9u8N7e4S3t/i3eHi3d4v1nh/WEsPw1F9dnjcvW3Ct2Ngw W4T1969grJccMkf7A5pmLTRNEfgotKZyzq0KTF70LuyR554Z9YJBkvAnVrnj 6OlZf6Yfyvyxv4Oe9i5y5p00arhgliwWRC+tM/vJ5MlDSryI6kSJ1SomWWKa K7SEX5JCYUFFOhSJ+pGg+q845/KOaKSjQgvSj4IivL16kKu9Pr8edqPx/LrP 4zwqR39WhKrw/6PgtEzBXs645l0RmmF6vx8AHVOlab1LHO4rt6TOfgJRBI9h PgYD+J4UvRGnvJ44gMeCrTzzJ8BqGWNcWqlEjW5cPQ1huhGmOZBQYsj+HNkv 44OXFjwletktJdCFkETRPNDIWmORBMDWJEbf6hz8QM4cdgm/tg3y5sN/kuFy /2zYn8LBDYnGtX+3XHzaYplybeaIGzzDdUM8MvmRAlvzYt3BEiejv46BDAfC b+p5jX4mDPG5VxKXPREsSgIi9gaSVt7Wo/Djcp6cbZDh0MbcwE9RZPbjxmBe M3z2XB+OF/Jf/LD/j9ADWfKVYTSNnng5509AW3JDKDZW332P5cHO/mtalzul atdSY9BW3bTff0+kt513YGNNv54cz2LLkLfKwHWyh6UtEuydAupE6jfGHj0G sIlqZQnLmkTnEBfTAxibJhDZDT7hPt3jMKZ+KZqh3qqJJW//fnHDhMNi7ldJ 5tJwsBX9tJzlqpONGHv75MvO9iecsY8uTmKB5/FBvbu7AnUiZrl1MZUGN2GM yADyMAYpBPx4ARlHl9uTA+GauWH+kUhuyoaZTKGbQTBol9KNtRwoVs6BABOu jUFTAej4BU06WdGpr3Lh049SAWRUL13bHKKtMNXZU5BZoA5YrQG4QI8tAhSz oKSOb3o0F1xr6TcED/xUuJK0CYpMqC6hUOhmW7d2qZDPWQo5iTNJrKPuSEJB pROiaJCj5nLHQ2BRWuXOmQrOyPWzdDXMTRypg0UMxpIbMkaLjOr5ObdATJIp yxtaTUlZbDS+KZwEgx5aBYt7TgxIodGgNWUx0jHCx/sipvDYumMRzyV8pn2O borcs5Y7WBTCYIrQNwUoOQYyptE0ILKDTD0IU7WbqT85YpLjJLw4us6WgP9f THF0s7mF0CCZBMQTApjl3LE6F0ThnAdw2R7K/hEcXzaDDIpIoyIi95upqiA1 qWiWueKMFlbliREIg93/6XSxLaL6qBdvo1CHydH+aEAUnqgI2uSjCtzJWMBe gLkFZBWC19c6Q0Kk1HAY+bDNs3ZsnPmBjFIzxwbDiR0ohC8oBmORyPSKoZvs BOZQQ4LpF+CesYH89xsjvYP0w5MdOciocMAKcrV/I9idFE2JMuoWL5xKOtKb ortQy6g5XSmSRPWriCce62c4DJvDViWGOYNgt+4dUKznGtfKh+7xuWAzS183 QfUKmDrh3OGELe3QHsev7PbzPNZao4C/NmXWmb7VkzFAZjGBUqajfAMfc2oM 9XLHBd+/dNyMkKw14MnynOl1w62yWtbgDEduv5Y9rHuZ9bUibMs2i5sN2cEO fWC2J7ASNqXbKVZwM1nXQX0K4TdpYuUzif9ghawzO2bUZDpFyUHUlBrET8c2 iGUTIMnCEDNb7mRsxiF1SDwRgwWqpRsyMabJuHCV/G9l86R17xpCihU3NB4C 9owTPtUXNRGMFrVdL7vR97HW6Bi/xyMki/5Ib/C2BEbf//zmy+6cN81EucSN iKs6aZywVu5Okspjv2VCY0zxrFtdSo+gUkhCcZDUMKoeldvX6aIof5SykPrb npHesc870nxDhvHFexVZlzcX0OlfzDEIbUweXOyUs1ZIIvgOoMWV6qkazlvD 5OZ6nHB3PWC3kToQb24PzpqQ+kVFnWQC900lRYynf889QvsL1ruyCDEKVDHS xMndmQJc78aJ1lCQ8jt0viKfjWBDIIiO2dbOOIWk4gVrXj1u1qq+AV+FXv46 yBgTLKIZsYyEsR58GmGIY8w0hASKsk+ot7nr1TwYMeI12sduUGZ0tfV5Axf1 Lu4zPN1cUDWsTQMGuKszA6bnrHxBSiZ9ztVQdrZDbM9REaraaJLpZE9bb8/k 3biqDtztu7nLOmicqcrT+AGvLYqAz5O2/pT03mfbIOu+f172P/lA8HfX8Z+e CDDmzDKICzng5J02mF91124X2M8hQtq1OPIb/Bg4ciRwRgRpR76CePLzP36Q /tdZ2CY74MOTkdbGpTGtv12e24MZ55JF+4/6JFNXaqVc9KXZvp1YJG/TZkFD yrKJZcuFAzTHOpd2ywv902nhIbZ2bqFWn3cLf4GowbbO8c7JGDR6rWXhVreb 5UkTC9SrNfvdQqBoG8eQR6ipc5WAO8e0Q5ZA+BunF5db8a5DI/frRbQYbIQz 0JRglerspTeQPzQ6Buf1hNnCehP/NVmlRzWLM3GUvziHQ2CiB2shXCbw2r5w D/Z2opU+TAeFJU3fuas7W/eunb+7jjdSLz1Gvi54yD1OP7jF2dzVv89xszsD U5CqUrVkiujFYXxj7EI+dRe6zBBBgfy5oMeJ5+CD3Wbm9vXN0fxQdtjGyDD9 CFyfMhdquGQ3ADdELWxoNS1HBwAAJg8AAEaU8R4AACFhbWl0Y3AtNC4wXHNy Y1xuZXRsaWIyXGl4X2ZzdGF0LmMz5QZodLrujTccu80PgD/uSZ0AxMGOSTo2 WOUbAkLwweAFdeXLhmiWoNxoWmbqQ4d0743fv+pJDkc7ud8HeW+G+a7gNG22 3bNeoVciza1NKFUSSH/tQyQlwkr5p2SxWIlaWIZvKFbCk1pK5sVqRYcbdK9u 9itWuQqvTWK1y8tp4/3kIupDO6VpdVguxUUDizrWyRS42/wa+ssiIUJiLssF hlTp0pZIDLgzNDBG0jEpJq4ZO9DE2y3rlJ9EZMTApsjFaZZA4chIjgsrY5A7 FwKh3mEljgTM4ciWbGm8Z9PjizlhnUPxTGliIi65dMSn3H+FT6Y2pJAgyYVu tMBad7jq+bG5Z2NK+sKFBvJbJKgPmYDcljQDLkoWE6ReIRRqokNxGEvaZxWD c7yiQGgoN7H8wK4PjASo3JnWvaHc1hJh7u9UURaUlK1MMsTzkGC0uzBm+WPP mK5i7S7LmTJcxZu22C2TWsDU7kzItWzbEoJoO0xEcm8N65BdV7J0/IGdzowY cGbtNxL+DNivZcpX8eQrhddzJmwdOfDcyF158nXjy3rBFlSmiNk8Vf+RwpjY dNmxYinAmRCom0wE7RPBoaiKAtaNyRPh9KtwaZBPilf/804lx6nP0DXhF22S oSjXI8XexQpQkXTO1x95TxeLBG/YeL2/j7BX41pXNwnB0o2aWKg1Dl1XC4+S 16uV4s+W5S53owQcxdyWR6IEtfYrbYfe3Fasep1i9nj9tm1yla9nNa9XN6rR MinsdK989peilCYV6vJC+hwzIncp1PxpT6pWlLealLOMK9euSdm0TwiXqLYl rUakmFnV3gkLTkhyWeP2WbXrPnzez2c3r4xbn3z364I1SKEe2TmkyDmiIqN+ ahN9cCRSMrUqNB1mQsXsLoSzuTEne84ihXFEvvUJWP0YPXITWlB3po2nVW07 o+9MUVgWVzpbWAWlIrSf1oj1JgeFjPpac3DS7kHOuYqVk45/oBdmpUmyQeGL J88WXu5Dx0e72u/eUQS1JjkpwoZ41Ou7dZmKA4lCs6NU2TS4LlHIpogo1LBV 3YpizTekcXxUeuOLeW0YrFSHBiWORUQCJLelAfWGSfGfCpjZBYurbsDEGiwu PXY9fRlu0Yqp2jFxWM8TPeo8QDPFYjJqeC08JrRiTEngBNG6RB+bQEMmx18c GT2sXuVAOB4duYqtqtQd/VNG9gvIOf81tIYtTE8JmnJFUywATYbjPO6VeSt9 0SKN4pYBQXSzJz6BHtiRv+9FqH+6NffEkXBGkuafKKG0glfknRSWmiaNKgw5 bkxDKRTnl/mZ73CjE2pVI5DvrjmaxbG+n00ZmYFvymwLsFh5M1nIUth56RZA 3hEefEa6pv95OhGoFICIAyEgtRDxcEEafBQYSFKJJRS+apE0Z6EXR5oecUE4 ptUrmgjRsT5VgRr4Dmz6Ag9H2eUMFvn00QHkrTHAAp3pG6uxYygzxwEpg1e6 e+OmgymPVGoRu1L6oRoP2sUEKeYWQXhup1bRsULN8sGUsuO/mGsW8Q59eTH/ jBdvXSuZR2EfLmK79td17/PXkPVQNU+Dq68OC9dNDz7BMF7KM4uLpw57uDF8 XqTjDg6sGa5mwY8TwWV6g58DYsd80P+2xk17/3Y1Nf35v7VfPW8c4JO+/Gxa 9pVaKZ6xe2zye6zy8dGJybw3VTVV/3TDCWXWnaJpukQg7BnXoibDVv9yZqom JFlT4mfDLG/NaoJz7AXHfHLNTP4+P8ZtsR3AzHgspQ1TqNh4vICOtoKNPeXA ss1PPPa4X9WyQKXY18/iCBX4g0sZG4mqeeBMKhjl/K9kxXsNPbRgxZgBuYdF /BhvfVG722ZN+1LfupAGhfjki/gM+El5Fo8vpGzyQg8xn9wo2O+IMRnY5vk/ MXIiIEYhSbp26lTwJhYVIuzNI3xQEwlPzS/94MAC4NpQ1P1UIwOHjFvAV0AU VfLvafC3wiFK0eTHXq1Zyo2jKvWnJ+LnPIbmQ3u4ueR/RmYjbdRIitW+zh6n 39ELRi5KrLG1WqM7vhVM9Qv3C67dNa3RsvuzViSH44qI0TZfLH12o5EjE/G4 6lPOkelqbI2jSeAFE3pHQUoiY9FeNzJ8cufKLfx2DPVP/M1U/SoVARyZrwl7 zg7Yl0LMB/ozf/YcEj8fyqfUuf3lixnTWX0+hAvHbPhw1qh3MfpUmugdOEIq 90XLt+3OEZM7vFamAfrUd/OS/Fzw6DqrNG3c3b13tGXH0/lezVqUiTvKU3IH jK0I90h2q/MGrv5cNVw+tbqUEOn80sXVbpeoIDfXwHiHLZOLnbIMMO4Ib4fD 4HEGca3S4VsPxMveWXRgvmypfQ+WTPlyTcewcbf3MpVQAx1JkSONWt+w7VSO 1TDqXREDAGOwcen1Vqh4azoONW8M6mGeCx89GXFd6M994qu5YR1et+Dn8eL8 DeqscSeOtU81Cy0xd08KvGIc8lOOeSYggGDOpHwGU11uoAedWn+tQDlWLWxo NS0pAgAAQQQAABmP8R4AACNhbWl0Y3AtNC4wXHNyY1xuZXRsaWIyXE1ha2Vm aWxlLjAwMFA0AiRjl6204/zD8AWljgLwWBstwlWyWCACtVLRa0W3BkmnHPyR qyNxN/hS+OX3HJdTZbt14aptuP4eSdwULrA9IMByRCc83A8Ethfz9EuT49fX 8z6AooPsqC2oHTmllP9T0qUaXw09njsImXWfL3IR2eWfbL5oQRNWtGfVpz6u 9Gzb3dn38T5fwmus2nBxNr7dBO6qm72SNPMtk5ekqUFokAHOY2CC4WrYuCJG 9yxCAHAmDYhVbXwQfox7/p7rLOBHU1jAVBzpAbVz4AAHMTZBwoKiWqIBWa5r uUCJne1W5tuD7AmDpgUgwpBE6QsbCultUNfKBXrbng6lzbrSUVrLlmNZL9kW pYtURUPFIxYNyZ53YCYLU8ofa5bBhD6E3VxbniEJzepxSuVZCQvSxPyK1YMn KCOCsEvCFgBe2xOptvC8qvWx9OAaHNswFjELf9xOVHepYXY9XPKHKiBk4twB GJQDf6FDxnW3+QUQpXgtC6IRumfD3jVT/fpKKWYq6FNL/eFcH1thLrqUStYI ew7YsIjww7BfVcM8cbyy848/X4GcZdjEGzClbOKZAqtxuUxtfpt8/TaWX9a5 mBvTYsl3V1dUiTGk2enh4Z/z37Mx5FHkqOThIXeOY3Nz9EsuQ5eb9BMh8qj8 /0Plafn+xpH/9iMYqqPmJbGf5DG4iim7dGQ3MXdtnJjI6XFg9+0Xu0pYVhf1 tVbyaumll3S1+UmUxsdrcx2AJIZKjDlhLWxoNS0wAgAARQQAAEaR8R4AACNh bWl0Y3AtNC4wXHNyY1xuZXRsaWIyXE1ha2VmaWxlLjAyMD0WAilrm6209H+Y fwBaX5wF4JAwssvyrZLUgUVqoUWtFtwZJp1z0kasjcTfoBfjl5xyGpst268N U23H/3eneFC6wPSDAckQnPu4HglsL+fmmyfDq6vifSFFB9lQW1A6c00x/oel SjTZ9Wbu2ESTWeSz5f/0dPQeTsQjN36Ns3ihBE8NaNHhq0eHajZt7M327jyf dNdZtWDybX16Sf1VN9GStPuWycvSVKC0SADnMbBBcLVsXBEj0csQgBwJg2IV W18EH5Me/6e6yzgR1NYwFQc6QG1c+AABzE2QcKColqiAVqua7jAiZ3tVvbbg +wJg6YFIMKQROkLGwrpbVDXxgV6254Opc260lFay5hjWS/VFqWLVEVDxSMWD emed2AmC1PGH2uWwYQ+hN1cW54hCc3qcUrlWQkL0sT0lasGTjBHBWCXhCwAv bYnU23heVXnY+nANDm2YCxiFv94nKjvMsNsernlDlRAycW4AjEoBv9Ch4zrb +4KIUrwWhdEI3bnw941U/36Sil3FXQppf7wrg+tsJddSiZrBD1HbFhEeGHYL 6rhnjjeWYntz9fgZjLuTGIN3ClbPahUCq3G5Ta/Lb4+W0svq17mB6JsWS2VJ jS7PLPn0fjt2ZTyqPLUcmyUu7cpuTl5ppshy836AZDyKPy/M8jT8v1NK//MR jFUx8pLYzzIY3sKKbr05Dchd02cWMjpcWDX6Re7SlhV//G1VvFq56WXc7XyE ymNjtTlOwBJDLUY15y1saDUtQwQAAEUOAAB5jO8eAAAfYW1pdGNwLTQuMFxz cmNcbmV0bGliMlxzZWxlY3QuY8OcA4Bql7G3Ho8ZrwB/JDpySifOSFLgvkwk jcgznzfEb4vXraIUe6m9Gmkzd1WRlJ43f/qSakjtcwJDrYFxKcFuBcu41C4d Dil8B74M3eG6NttutWHQklWEhzmOYIpUj26QdsNbiIg32mmtwx4kSHD1XOe/ cvau0F2/iEDxXoOW7euCWyY45jHD0q0qsL06Dq9GW194bRCmHP3hokRn1hZl HT3k4/Y5cmsOdKZJSBH6lnTICJFgwHZ7CTQmVcthUuPMdZFdh3xTAvt3C1mR LOG2I0/UfGxiqIHzA2622paZsawJvwdc1d8UKsxd+VEhi5t77jle0vHBiTDo twrhcccpcGgyKCgOwZDrJt2xddyy0ySnA0pcK0Y2PWK7NSQAoSLcPGo/wIXY jRoUt4Ki6QyImmi7/RCheE8Z8a50bmeCI0CjkbEZ09FSGq6LSPShs1ozn+2G MQmc7we29gv8wO5xe/Q4H3NAP7udyLQ+Gp4FZq/A48QThssKmMEIkHw+f5pw VCziQkWOUfHKLELyoSaoxQ8M/XojChGAxreSfPDoBeU9B+oIky5wR1HzzR+i NHQmFOnzqI+lDizoxcnsHrPRaEk2foOlRWIMYEbH20P79kEB6Qyy9OeGTS3y 24MNzFhu++49f5bfHdxYXLKN7epfQWZiAiS7hEmbQ8MTXCGVhex+qcQyOrEU iFr2ooCtEB98LeL6fZcgw4OT1XMTDWd156tG72Dmgt3OP28z23EYPMYMsKg5 MHr9dLg+Y31ybbyHmUhUJpUrlkXRYiZ28b1jnt1kZCZHrarFSl5Li77q9oYa jB2aQwxvyTRwpBjHMXexWI7k/PCPr8IVjS//EK/F4WUckh/5if8oV6mp/OFY 3MfKFc9tn/wsqaqmEtELuuw6V3xZzKMDOWEcLw5dkwypMiSFCT7W1TfVPDEN 3dCLR8IbNVieh+h3p3d3uCfEczMROPv4C2SWWLOXQeKaOPSOJFA4dFB0IyAe SWbJl1M2OMN8X3g7MyJIeizWl46KGHiy2z5ZaMejN3Qqw0p1SedYdMqcwNxi gVBMOYuh4Rhn77nPgbiZcR2gVMiB2gVppA06MaIhllb6CiPsywT5SgHKpsy1 f1lNowlT18G4X6teGqvg3CG0+A6YPKmzXVuysqqmktKWym0Qb0XxySjAyvau +79azIvDJFYdYqxJuS9z0k2qjzvhBPg//6EC6cXX9wgX4ZF/whAwm/GD9GDL /IQeUHlSf7B5UnjB4NcH2E+qkCrJQXVJ1zD5Sw4krLXW1T5QX5eUGLhtbPHp LB2zxn2Yotd/FOR3svkHLw+E3omglJAfUj7LPxzJ1DVSkLp84OiS7rjGhrUO sidMFBkvrPQ6FdXOPit8pCqCavwE/n7ea3+8BvLH/2wbnqPJVDBcnhVVka/R 1bDuhIsNE3t44ZC9f4nIphD0oXlqpWUylbZAifQHR/w1Xy1saDUtxAMAAJIH AAAJkrEeAAAfYW1pdGNwLTQuMFxzcmNcbmV0bGliMlxzZWxlY3QuaPPBA4dr l7GnHLsaTwB+lcChydYMknWwmE6+c7hUJIgCyzCFo38HqG91rd1hx45f3dbJ 0Vt7uuBcCrPue972raTmD3dIe4A00HWG09IgX/1mUwE7QP8xqsphpPsUZXIN qVAygQjqPuNC6WkTXyUfdQwL0l8Iu3tigb/uIAzGVvsWGaEPM9M5RnrZrqe2 4qEQWnaziZQ9wck2BMZAKGc62KPssYQQYBkT4EqdQakzn28m+SxE4vCDBVUt owb9Pj4agy22H4igVGpDys2UnmdP5TzChYgYjM3yroGcNnJ013tBui0Gh3pK wmYdKO4BOXveAOAqWXjDFdcLajABI9eMxpEUCa2zF8hzyCkxCC6Xh/1CvU4z gdDqzQmsi5QVTI3cT00hsELFjtspgdQyjQ88mn5eOrSEfh6B5x588fhp9O4o 1lCS9o8BfSz1V0nKtEWlGQzkQ9dQs0ueT5FJx/rky5NPo0id+TT4S6NAd/jn CMPKPPpySassecPLVn8vHRLCAaBG5bLVV/xcOa2Nw5qSSpziwx6V80E9CfBZ CimcKDcBJ+JhPwITGCYsWv/dOlKNzj0Ur6q73AfaCEsgDio5YoMTze10993x gDIiaGAPf+fYWZK1hHwJ4JDVbFHn3F8s0YYcUXV2wBq0R8ycsaRmZDRBwCKF 363Q3rwYW/wMPXj6sOPD+gGbqAEvzr+0u37Zx4HdjFdQ/aietFfRmyGRB2HJ EpP30BNQM28sQOYT+lNxOpPVgiiwYewAxYscXXj7OotVOL9owBA8SXmd7ZHQ LOe/q7K60qZbVvYRuquIqlgiIP4sOPq9+Nvx51W4PqtlH0PB09L+Hycdp2wK UO3EMrdZUKGLcA3o1evuzAFvnc0FxelNNQ/i3Zyu0stFK7ZssWVtfOlKd5YJ bxdg5juR/XrhhtiL22C2T1zVTwAdOsuG4b/9C+tK1n2FcuBqbB9hM2WuiQaU yzHf6YArFVBq1u8xy4ES9TD1C3aSYxbtOHTePwt43OI3awsym3HRLllk065P lLJ+z19ZYpDa4fcg1P5VGXvaYn8DzuD/zMdqav4PUTnmK5Lf9mXc9baU1HJq DI3FLNNkLh/+DmTFt4kzfDX5Z5S4BpeiJxYU++8aBbyKXJKCUetZDilH4sDZ SksjPtT3EjoxOpqzVOZFG6B3Ge1TTEsZIl9wR45cvRFh/5ibQc9hvpPZvH4S 68nh0Yfr5C5PSLP9+WX+JHiFtoLhAtQMJ0laP5buBq6vPjgQF4vvNfeSnO0L fe+RX9QzpyZpWgPswt/OkAA= ---2124320750-1871735711-806021035=:131205672-- From amiga-gcc-port-owner@nic.funet.fi Tue Jul 18 09:53:50 1995 Received: from mail.eskimo.com ([204.122.16.4]) by nic.funet.fi with SMTP id <90327-4>; Tue, 18 Jul 1995 09:52:14 +0300 Received: from amiga1.eskimo.com (tia1.eskimo.com [204.122.16.40]) by mail.eskimo.com (8.6.12/8.6.12) with SMTP id XAA11938; Mon, 17 Jul 1995 23:51:45 -0700 Date: Mon, 17 Jul 1995 23:51:34 +0000 () From: "David J. Bakeman" To: amiga-gcc-port@nic.funet.fi cc: dbakeman@eskimo.com Subject: Developer Kit Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII How does one get the developer kit now adays? Frome Escom? I'd really like to try my hand at programming the old Amiga again. David J. Bakeman dbakeman@eskimo.com Seattle, WA 98103 From amiga-gcc-port-owner@nic.funet.fi Tue Jul 18 15:24:27 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <90046-4>; Tue, 18 Jul 1995 15:23:29 +0300 Received: by math.uwaterloo.ca id <77130-2>; Tue, 18 Jul 1995 08:23:07 -0400 Date: Tue, 18 Jul 1995 08:23:00 -0400 From: Jeff Shepherd To: "Kevin D. Brierly" , Peter Ivimey-Cook , Amiga-Gcc List Subject: Re: select() for AmiTCP-gcc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Almost forgot. You can do away with having _ProgramName. The startup code automatically finds the name of the program and uses it.. jsshephe@math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Tue Jul 18 22:26:20 1995 Received: from zaz.kom.auc.dk ([130.225.51.10]) by nic.funet.fi with SMTP id <89412-2>; Tue, 18 Jul 1995 22:22:20 +0300 Received: from skoda.kom.auc.dk (jds@skoda.kom.auc.dk [130.225.51.24]) by zaz.kom.auc.dk (8.6.12/8.6.12) with ESMTP id VAA06469; Tue, 18 Jul 1995 21:21:59 +0200 Received: (from jds@localhost) by skoda.kom.auc.dk (8.6.12/8.6.12) id VAA03290; Tue, 18 Jul 1995 21:21:58 +0200 Date: Tue, 18 Jul 1995 21:21:58 +0200 Message-Id: <199507181921.VAA03290@skoda.kom.auc.dk> From: Jes Degn Soerensen To: "David J. Bakeman" Cc: amiga-gcc-port@nic.funet.fi Subject: Developer Kit In-Reply-To: References: David J. Bakeman writes: > How does one get the developer kit now adays? Frome Escom? I'd really like > to try my hand at programming the old Amiga again. > > > David J. Bakeman > dbakeman@eskimo.com > Seattle, WA 98103 > What is it you need? There is no "real" developers kit nowadays, but I guess you need the includes and autodocs, that can be found on the frozen-fish CD('s?). You need to find an ftp-site that got the CD online (sorry can't remember any right now - anyone?). You could also try mailing Dr. Peter Kittel at Escom, but I think he is very busy at the moment, so the Fish-CD is probably a better way to go. Regards Jes From amiga-gcc-port-owner@nic.funet.fi Tue Jul 18 22:30:49 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89019-4>; Tue, 18 Jul 1995 22:30:25 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26631-2>; Tue, 18 Jul 1995 21:29:59 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209631-1>; Tue, 18 Jul 1995 21:29:51 +0100 Subject: Re: Developer Kit From: Christian Stieber To: jds@kom.auc.dk (Jes Degn Soerensen) Date: Tue, 18 Jul 1995 21:29:42 +0200 (MESZ) Cc: dbakeman@eskimo.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <199507181921.VAA03290@skoda.kom.auc.dk> from "Jes Degn Soerensen" at Jul 18, 95 09:21:58 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 598 Message-Id: <95Jul18.212951+0100mesz.209631-1+1542@hphalle0.informatik.tu-muenchen.de> > > What is it you need? There is no "real" developers kit nowadays, but I > guess you need the includes and autodocs, that can be found on the > frozen-fish CD('s?). No. The autodocs cannot be distributed that way. > Regards Jes Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Ex-Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue From amiga-gcc-port-owner@nic.funet.fi Wed Jul 19 12:10:04 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89272-1>; Wed, 19 Jul 1995 12:08:47 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA13991; Wed, 19 Jul 1995 11:10:38 +0200 Date: Wed, 19 Jul 1995 11:10:37 +0200 (MET DST) From: Kamil Iskra Subject: GCC 2.7.0 Bug To: amiga-gcc-port@nic.funet.fi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've found a minor bug in GCC 2.7.0, most probably in "crt0.o" of the latest IXemul. I've installed the latest BETA-version of GCC 2.7.0, but forgot to install new version of ixemul.library - 41.1 - I had 41.0 on harddrive. When I runned GCC, it displayed a requester: ixemul.library warning: needed revision 1, current revision "current revision", instead of, the correct one, "current revision 0". / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Jul 19 12:53:25 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89238-4>; Wed, 19 Jul 1995 12:52:29 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 19 Jul 95 11:50 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 19 Jul 95 11:48 MET DST Message-Id: Subject: GCC 2.7.0 Bug To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 19 Jul 1995 11:48:49 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 670 because there was no responce to my last bug-report here is he again. I installed gcc270-prerelase from nic.funet.fi on my a2000 (68000 for now) and it crashed. ld,as etc seem to work (atleast -v) while gcc,gccv hangs the computer with 8000003. anyone else had this problem ? walter btw: is a total new installation, ixemul 41.1 is available and ixconfig works without problems. -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Jul 19 16:25:49 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89560-1>; Wed, 19 Jul 1995 16:23:27 +0300 Received: by ceylon.informatik.uni-rostock.de id PAA00216; Wed, 19 Jul 1995 15:22:57 +0200 Received: by honshu.informatik.uni-rostock.de id PAA17524; Wed, 19 Jul 1995 15:22:54 +0200 From: Gunther Nikl Message-Id: <199507191322.PAA17524@honshu.informatik.uni-rostock.de> Subject: Re: gcc 2.7.0 -resident To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Wed, 19 Jul 1995 15:22:54 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199507151758.SAA16279@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jul 15, 95 06:58:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 590 > *4109 21fc 47EC 0000 lea a4@(_sys_errlist:W),a3 <<= addr=$21fe > > Could it be that /gnu/lib/libb/libc.a is _not base relative? I did a > "objdump --disassemble-all --syms --reloc" on libc.a(errlst.o) and > libb/libc.a(errlst.o), but the output was identical. Is that correct? I think the problem are diffrent header files used to compile sed and libb/libc.a! Your headers place "_sys_errlist" in the data segment, but the "_sys_errlist" from libc.a seems to be in the code segment (means its const). Thats my guess. Maybe a newly created libc.a would help. Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Jul 19 17:06:07 1995 Received: from calvin ([193.55.128.51]) by nic.funet.fi with SMTP id <89493-3>; Wed, 19 Jul 1995 16:55:52 +0300 Received: from canardo.unicaen.fr by calvin (5.x/SMI-SVR4) id AA11246; Wed, 19 Jul 1995 15:50:08 +0200 Received: by canardo.unicaen.fr (5.x/SMI-SVR4) id AA03986; Wed, 19 Jul 1995 15:55:10 +0200 Date: Wed, 19 Jul 1995 15:55:10 +0200 From: devulder@calvin.info.unicaen.fr (Samuel Devulder) Message-Id: <9507191355.AA03986@canardo.unicaen.fr> To: amiga-gcc-port@lists.funet.fi Cc: devulder@calvin.info.unicaen.fr X-Sun-Charset: US-ASCII Hello ! Well I'm not registered on that Mailing List but I was told that you here could help me. So here is the problem I have: I'm using the gcc2.7.0 cross-compiler available on ftp://ftp.telesys-innov.fr that I've setup in my home directory (/users/doct/devulder/gcc-amiga/). I'm also using the libnix 1.0 static library. I've compiled this very short (and well known) program: ----------- hello.c ------------- |main() | | { | | printf("hello, world !"); | | return (0); | | } | --------------------------------- Here is how I get the executable (hello): ---------------------------------------------------------------------- {corto}~>36 amigcc -v -s -noixemul hello.c -o hello Reading specs from /users/doct/devulder/gcc-amiga/lib/gcc-lib/amigados/2.7.0/specs gcc version 2.7.0 /users/doct/devulder/gcc-amiga/lib/gcc-lib/amigados/2.7.0/cpp -lang-c -v -I/users/doct/devulder/gcc-amiga/amigados/include -isystem /users/doct/devulder/gcc-amiga/lib/gcc-lib/amigados/2.7.0/include -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -Dmc68010 hello.c /usr/tmp/cca10346.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /users/doct/devulder/gcc-amiga/amigados/include /users/doct/devulder/gcc-amiga/lib/gcc-lib/amigados/2.7.0/include /usr/local/lib/gcc-lib/amigados/2.7.0/include /usr/local/lib/gcc-lib/amigados/2.7.0/sys-include /usr/local/amigados/include End of search list. /users/doct/devulder/gcc-amiga/lib/gcc-lib/amigados/2.7.0/cc1 /usr/tmp/cca10346.i -quiet -dumpbase hello.c -version -o /usr/tmp/cca10346.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. as -mc68010 -o /usr/tmp/cca103461.o /usr/tmp/cca10346.s ld -shortdata -fl libnix -o hello -s /users/doct/devulder/gcc-amiga/lib/gcc-lib/amigados/2.7.0/libnix/ncrt0.o -L/users/doct/devulder/gcc-amiga/amigados/lib -L/users/doct/devulder/gcc-amiga/lib/gcc-lib/amigados/2.7.0 /usr/tmp/cca103461.o -lgcc -lnixmain -lnix -lamiga -lgcc -lstubs ------------------------------------------------------------------------ It works well and output the executable. But when I try to run it on my amiga, I get an alert-requester that is followed by a guru (#8000 0003 or #8000 0004 (I don't remind which one, sorry !)). That error occur during the loading of the program or in the very early startup of it since I was not able to intercept it with a monitoring program that is supposed to debug the 'next loaded command'. My configuration is a standard a500 with the 68000 microprocessor, 512kb chip, 512kb slow-fast ram at $c00000, and 1Mb expansion ram at $200000. It's a ks1.3 (34.40) ROM but I use ZKick to have a ks2.04 (37.175) rom in the first half of my 1Mb expansion ram. So when I'm trying to run the "hello-program" my expansion ram is like that: ks2.04 (37.175) $200000-$27ffff fast ram $280000-$2fffff So the problem is that the executable seems not to work with my computer. It could be the softkicked-rom or the 68000 (I don't think it is a memory problem, since 1.5Mb shouf be enough for that program!). I must also say that when I try to run it in ks1.3 mode, it is properly loaded and just fail because auf the missing version 37 of dos.library. So I whould like to know if anybody have already experienced such problem with gcc. Does the output of gcc2.7.0 really work with OS 37.175 or does it need a newer OS ? Could it be a parity error of the 68000 or a bug in my rom or else ? Can someone test it on a real a500+ with that rom ? It would be fine if I could be helped. Thanks. Samuel DEVULDER. PS: I've uuencoded the sourcefile and the executable in that mail. I don't think this will cause you any trouble since it is a *very* short program: 4436bytes. begin 600 hello.lha M'H(M;&@U+G1D M./#.<.)0@$1A%*##O_[^][HY#",*W?#RR6^!5\_?P2W;2V1MMR MD3[_W4[;]E^PRRC,XQ M-:B/TUG_!Q,IM1>7.R_*RO*W/#W. _X>3LDXRB_3-^MY639Y.93;]*=M]G@X M6%AR%_M8>+A8"_5$4[ZXJ"!2PIIA7T3ZWW+H7F(33\5!;3NXG;0SEN*T)L^DSEM_ S2%]UOWYNXJ;Z^J 29M"\8ZDP>R:#5&X&(DA'*E]] M^=MYWV2*;Z]S:H(&4"!Q$".P965K['\Q];1)=NP:&[9U2 MJ#MN9]+%&/^/8(QZWRBN7&1@=PE8_VF!8=R7ZV]#!_0']WZMWGU@@R#,8<'F]V4&3U9*H<#T M-?>&WS)DDJ=5T.YR8Y*'>P/=Y.@'E0TR#+1CU*-"\7E\'0(G*Y+Y?8A9=D(:YAN MV-'M1;1(%?T5U;OU=B#=DPG1"[AP[/\D67Y)FW!7^F5?E_<&/M&N1([E$$OI M7C]NIGC!'Z1J_K/$G;W7WC&-*XT&Q_(B.; _YL\0KOU;J":QUXLC#);-=3C4:9D M@TYGC=$6_QYTVE;2V;0M+A+2;0EJH-F>02S$+M*;S5HC_U%)*=6]7@ 0J3MN MTK-V9*WWA"Q/#S0[#[?/B9W$>23$;#*.QAE(=*>MYM"\C%!VHEUPL/[%OM2A M28)V^D\.A>,[\I#FN>=GLRCF[*P0Z9 Z>&S2;0W6MP,9*2=G5*<95[)IZ+R\ MP!EG)$Q/*9RA+#\S$*B4K()+,-34:6Y$LT[X2H;IUNG%"-->QN39OLR-:( <&JRRQ+L?0.4;T6G>?"[]!BES^ MOS@T&HZLMW0:AS^.7*%JJW*1+WE-Q7DC@_58.C+31)EH(Q+^R$"LE75]AOVU M0_;8=?[)042=]A1?9E/#B1=1T8H,^GF4]MS41.:'1MQ#[0U';VK$DET/)V") M(.PQBX.3APEV7IX^3P]!R2+^6IAJ8]>U%X.2W;'(KC2YO=$HZRRM=U7> MVX./!L?.=AVM;!U#Z)4.P53* W7K)IGHZD&^R(?Z.GFM/T<_;>0&;R8/N*^S M_MV5*O)MT1\ !%-=\"YL$%RF-(C$QBQT^'2PK1#@-@P6?3> 4JB!W6K!C-;<)\2F;TNJ*;^2ZR6D\:H M\'U&'2E\Q@MQ4X@Q,52B6,3MCQ*;;]X9I@4W+HICNBFPC 6NB%X9Y54LYIY_ MC.A'_X \7]P!DPEZLL^PSZ57(JGD8[L9^R+DZ%3CS?7^MJ[/#)K'&H%4_ )0 MNQ@Q"LFR4Q9G]97&14_D+J<@MH77=G[A:O<$+/5,7<]E$3'8XJ5$JX)[S(;< M!=+/\7OZ4]EI6?3QE,RG@?[(X\E&CC6GLK]/A*=_DW5(:P&X:U==#FY-KK97 M8FVJENU>M)/=).1P6-QGTN*!OQ:4KL=9SE>+)FE<3V:N-=P[?' 3M&P0J W M,-]WJY!-7&07[0O%7?@*]]5"W__^6^_;;\+1M^A@>86^>[!E'@1:XZ W0;KA;P]9[A3JT M[LI^YK?MGQ#)4[,A6][7WG3]:J6C8UI"$Z4\-3LTV^-C5,P$[D$U0QOC]+):GT.SL/ZJE1 MIB1W"\YFO;T%X67NM<;2>JS1D<#C2=<6J:XO9@2P.<)?NM';YJ_<+Y34-E)M M.]9$^/8QH'A=^=SD&X;7YNRMH? M2)I$>B[H8B[*3B>)*$OG6#2\O9L1/9#N?+G'G_+\V__,8Q;_]&)>95&+!F'3 MV2YXT2W97S8?PCP^;3O^51+A&B5T*ZJ.7T!79GBSPN"@QW&$&/U#P97^7%W+ MQ8^M)9+8M,'@Q!_:"NVEHGT!N#/RCA/LQ&R^*@NI=^KD: GKQT:FLX[,&2; MZ,FMR]?>=K2HZ'G4G6%7==N<^V9][MJ;?PL=2<2&3 /*N7;NN!&M[F<'?E$P M7XXU^"HQ/:YL67VW8\_7'UHB=RUQJ&\L848.P;AHU&:D5G1U?K'G8X9 M5XC=V#D*2^Y^A%)I.B2-(W:AQNP8[JIH=LSF?=P$V-:\)^RBS%X V6.6-QF; MJ\"3TO/U!:;L\DD:)T]Y.EE\^?+D OX?!\-M5&[/EM0J#(V&/MT4D;R>6[H2 M;OW!X0-0Y"J>5.YE3&=[[X1O?GN\"KKZ\0CT4ZPD<_)Z2H\%*Y!1KN3=KUU" M\=DEV=G9S,7!ONZ@ F=7;V8U1N)48K+VGD5F;3P2+=H\(SCF]ZG1Q!(II;V- M2D0ZQ^WMJPG-KV)V]"/69^5B)12S_Z%TM=2_'O8Q40K,_#IQ<,E;WQR5VJT7 MZ9*^3XY5_=Q!OVX W#?:+4DQMR2J3_ #3>DDHT2\/BC=/HW(\E,%?!#U*S,- MRPDIK:B;2E2W2#-R$_#+N/V8;?+Q"=\+&-)JN-"'$&7KY5F4%.6G+)=9([4BTK<%=]>TF"],. M)L/G40M MK,!#][3LIA*A'JI05YZV5/W@V,ZN%%S!QVS^"H-0C7:.R;#Q9[2>(>9LM:5? MT,V'V5!IKZ[.!\X.#@+XV#B]YM,/;+V5IUDH>+.PVQT];:]X?BU:F:'";4_& M@I[Y#+O-'@'^U8O7MJ6-:&N-E7\?'&Y5N-3,J9J][J=F2E3./1?Z?P=;[53- M-IG3Y?8>U4\X8?WYO=CF$[Q-CT63:'9,[UO?W?M7:E3@(\!;"=\9.!;O'*^+ M/'@B:O@@^T#DM_,\,.\\QV 217G=&]?;VI^1-=V",66%6^.7#L*\P5]L0(?, +"R4QY.M]VHK[HA$K"L4;XV_%.*@/JUXJ/*EJT1M9XPK]T5&P)TG MPAM;5BNQ%0VO ^^*B$3I1F]*-AG"#>T(!^%Y J WIAWZ:X%1N2M-X0J 'IO4 M$'?[ KX@8SE"O"%>(*CPML.V%=X*\,*_V8J"+T_P!7, 5K@??8D?BS! I%=J M.KP14$&D!^ER!48]/J!7D'LHA7$%<<5!?O@>;[\ 1&_%;45!CJ,BM 5W J$7 MJ #UC]WS(]8$5U@CIO[ 5!3OQ?OPF?I @]4%.K+%=L*Y0J+M4&&J#?5$:E7G M!%=N*S14(/TF8$3@OX +.!P!7DD72@1]+C"H\T7I?#%?Q!#8%ZP(-8'^L 6L M:*PP/6B-%6A&=;@"H\(/6[]'FXBAFA\-IZ<*#B HQM3"B=\*[L7G\3OG$T5& M?*$?CFQ4'N4X]N>*]N*A<9 _R"=R!#I#%B-@-%V*ZX5!QI!(:02&E[PJ& TQ MX8A,*33#*Z826F%QI@OTPO=,'6F%EI\L_.;A.88#?'N&PP&^!]O@5[X7[[TP MF\!-3^X)GCBOOA+],%4!VJ"?5&/5\45]@(_#@^D&;TG%%0>< -QP/PBH;_6# M7:PR];$"!PDN)+>] L%5OO8=] >D%1Z<)7*"7S?:V\G7$D_M9]?87DG6W=Y> M]?5NK=[G;/QE=6OJ9766O6VW7:KZEO]6^O]E@8+>CWZR9K; MKK]L-8CY+Z/G;^8CY/Z/CO5__/E5O^_DOW? M5;=/_KY:KT.H[W0JX\HO:&H(5#6Y#8^ECO1Z_P>C;>;'_P>YGZ M;_ZPJ?IT>F%?\A73BOYS\R:]Z@,0!RX[T4/_-['AT\:!LB_2*].*_Z'O217D MG,5%?5>Y\I[G_J*WCT7L\O[+K Z76/7_[_D]V]S^]@8?>6F%M+_%OL7O2V]' M:86TH][S^\CWWQ_:8JSYP$_J^KGB4#X[3;4=OM*(F@='.H0VGD'IZ]%K,V^R M&3K->ZF=4X ]^\X?=/8CGJO.SW+SK>O/?T@#@AT]T#55 M!0!0@($' %$R /("!P!4;+L#, ;6%I;B@I"GL*<')I;G1F*")H96QL;RP@ :=V]R;&0@(2(I.PIR971U; Wed, 19 Jul 1995 17:39:11 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id QAA20912; Wed, 19 Jul 1995 16:36:48 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id PAA07580; Wed, 19 Jul 1995 15:27:41 +0200 Date: Wed, 19 Jul 1995 15:27:41 +0200 From: Niklas Hallqvist Message-Id: <199507191327.PAA07580@linda.appli.se> To: gnikl@informatik.uni-rostock.de CC: lhecking@nmrc.ucc.ie, amiga-gcc-port@nic.funet.fi In-reply-to: <199507191322.PAA17524@honshu.informatik.uni-rostock.de> (message from Gunther Nikl on Wed, 19 Jul 1995 15:22:54 +0200 (MET DST)) Subject: Re: gcc 2.7.0 -resident >>>>> "Gunther" == Gunther Nikl writes: >> *4109 21fc 47EC 0000 lea a4@(_sys_errlist:W),a3 <<= addr=$21fe >> >> Could it be that /gnu/lib/libb/libc.a is _not base relative? I did >> a "objdump --disassemble-all --syms --reloc" on libc.a(errlst.o) >> and libb/libc.a(errlst.o), but the output was identical. Is that >> correct? Gunther> I think the problem are diffrent header files used to Gunther> compile sed and libb/libc.a! Your headers place Gunther> "_sys_errlist" in the data segment, but the "_sys_errlist" Gunther> from libc.a seems to be in the code segment (means its Gunther> const). Thats my guess. Maybe a newly created libc.a would Gunther> help. Rather changing the headers, no? The modern way is to have sys_errlist const! Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Wed Jul 19 17:45:13 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <89489-2>; Wed, 19 Jul 1995 17:41:19 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 19 Jul 95 16:34:44 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2100f522.u7t157e.7452-robert@plukwa.pdi.lodz.pl> Subject: Lookin for autoconf Reply-To: robert@pdi.lodz.pl Content-Length: 663 To: amiga-gcc-port@nic.funet.fi Date: Wed, 19 Jul 95 16:34:44 Hi! Sometime ago Fred Fish said about autoconf port for Amiga that is available on one of his CD's. I wonder if it is available online anywhere. If so please let me know about it. Thanks regards Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Jul 19 17:59:32 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89376-1>; Wed, 19 Jul 1995 17:55:16 +0300 Received: by colombo.telesys-innov.fr; Wed, 19 Jul 1995 16:56:23 +0100 From: Philippe BRAND Message-Id: <199507191556.QAA28392@colombo.telesys-innov.fr> Subject: Re: Lookin for autoconf To: robert@pdi.lodz.pl Date: Wed, 19 Jul 1995 16:56:23 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <2100f522.u7t157e.7452-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Jul 19, 95 04:34:44 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 490 Robert Ramiega writes: > Sometime ago Fred Fish said about autoconf port for Amiga that is available > on one of his CD's. I wonder if it is available online anywhere. > If so please let me know about it. I've just put it on-line on my ftp site. ftp.telesys-innov.fr:/pub/amigados-gnu/autoconf-2.1-bin.lha -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Jul 19 18:18:08 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <89726-3>; Wed, 19 Jul 1995 18:13:37 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 19 Jul 95 17:06:47 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2100fca4.u7t157e.2ca38-robert@plukwa.pdi.lodz.pl> Subject: Re: Lookin for autoconf In-Reply-To: <199507191556.QAA28392@colombo.telesys-innov.fr> (from Philippe BRAND ) (at Wed, 19 Jul 1995 16:56:23 +0100 (BST)) Reply-To: robert@pdi.lodz.pl Content-Length: 531 To: amiga-gcc-port@nic.funet.fi Date: Wed, 19 Jul 95 17:06:47 Wow! Thats called quick response!! :) Thanks Phillippe and Lars Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Jul 19 18:21:35 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89039-1>; Wed, 19 Jul 1995 18:17:11 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 19 Jul 95 17:11 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 19 Jul 95 17:08 MET DST Message-Id: Subject: Re: your mail To: devulder@calvin.info.unicaen.fr (Samuel Devulder) Date: Wed, 19 Jul 1995 17:08:50 +0200 (MET DST) From: Walter Harms Cc: amiga-gcc-port@lists.funet.fi (amiga gcc-list) In-Reply-To: <9507191355.AA03986@canardo.unicaen.fr> from "Samuel Devulder" at Jul 19, 95 03:55:10 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 416 what does as,ld and ixconfig make ? ls -v should work at least. i had the same problems with gcc,gccv on my a2000 with 68k walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Jul 19 20:15:56 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89196-3>; Wed, 19 Jul 1995 20:11:35 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id SAA07960; Wed, 19 Jul 1995 18:05:17 +0100 From: Lars Hecking Message-Id: <199507191707.SAA20532@mostar.nmrc.ucc.ie> Subject: Re: your mail To: devulder@calvin.info.unicaen.fr (Samuel Devulder) Date: Wed, 19 Jul 1995 18:07:58 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9507191355.AA03986@canardo.unicaen.fr> from "Samuel Devulder" at Jul 19, 95 03:55:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 951 [cross-compile] > I've compiled this very short (and well known) program: > > ----------- hello.c ------------- > |main() | > | { | > | printf("hello, world !"); | > | return (0); | > | } | > --------------------------------- > > Here is how I get the executable (hello): > But when I try to run it on my amiga, I get an alert-requester that is > followed by a guru (#8000 0003 or #8000 0004 (I don't remind which one, > sorry !)). > My configuration is a standard a500 with the 68000 microprocessor, > 512kb chip, 512kb slow-fast ram at $c00000, and 1Mb expansion ram at > $200000. Your executable runs ok on my A3000, no enforcer hits or such. I guess that the cross compiler creates 68020+ code (by accident; your gcc -v output seems perfectly normal for 68000). Philippe has no 68000 machine to test that stuff, I suppose? From amiga-gcc-port-owner@nic.funet.fi Thu Jul 20 12:07:22 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89252-1>; Thu, 20 Jul 1995 12:05:30 +0300 Received: by ceylon.informatik.uni-rostock.de id LAA03930; Thu, 20 Jul 1995 11:05:08 +0200 Received: by honshu.informatik.uni-rostock.de id LAA01319; Thu, 20 Jul 1995 11:05:08 +0200 From: Gunther Nikl Message-Id: <199507200905.LAA01319@honshu.informatik.uni-rostock.de> Subject: your gcc problem To: devulder@calvin.info.unicaen.fr (Samuel Devulder) Date: Thu, 20 Jul 1995 11:05:07 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9507191355.AA03986@canardo.unicaen.fr> from "Samuel Devulder" at Jul 19, 95 03:55:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1760 > I'm using the gcc2.7.0 cross-compiler available on > ftp://ftp.telesys-innov.fr that I've setup in my home directory > (/users/doct/devulder/gcc-amiga/). I'm also using the libnix 1.0 static > library. I checked the executable: you do _not_ use libnix 1.0 (believe me, I know what I am taking of), but this is *not* the problem > I've compiled this very short (and well known) program: > > ----------- hello.c ------------- > |main() | > | { | > | printf("hello, world !"); | > | return (0); | > | } | > --------------------------------- > > But when I try to run it on my amiga, I get an alert-requester that is > followed by a guru (#8000 0003 or #8000 0004 (I don't remind which one, > sorry !)). The program crashs because it contains ONE 68020 instruction ("bsr.l atexit"), thus the program has to crash ... The reason for this is a broken libgcc.a. That library had been assembled with a broken gas generating 68020 instructions even in 68000 mode. What you can do: 1.) use newer versions of libgcc.a 2.) place a dummy libgcc.a in the libnix directories 3.) add "__main(){}" to your program. What it means: To support C++ constructors, gcc calls in main before every other action takes place a function called "__main()". This one initializes all constructors (if any) and then adds an exit-function with atexit(). "__main()" is only used by C++ and with normal C from libauto.a for auto-opening of system libraries with ixemul. libauto is of *NO* use for libnix! As long as you only use the c-compiler together with libnix you should use 2.) The compiler and assembler you used were ok. Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Jul 20 12:07:57 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89412-1>; Thu, 20 Jul 1995 12:07:18 +0300 Received: by ceylon.informatik.uni-rostock.de id LAA03944; Thu, 20 Jul 1995 11:06:58 +0200 Received: by honshu.informatik.uni-rostock.de id LAA01330; Thu, 20 Jul 1995 11:06:58 +0200 From: Gunther Nikl Message-Id: <199507200906.LAA01330@honshu.informatik.uni-rostock.de> Subject: Re: your mail To: amiga-gcc-port@nic.funet.fi Date: Thu, 20 Jul 1995 11:06:57 +0200 (MET DST) In-Reply-To: <199507191707.SAA20532@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jul 19, 95 06:07:58 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 353 > Your executable runs ok on my A3000, no enforcer hits or such. I guess that > the cross compiler creates 68020+ code (by accident; your gcc -v output > seems perfectly normal for 68000). Philippe has no 68000 machine to test > that stuff, I suppose? The compiler works, only the assembler used to create libgcc.a was broken :-( Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Jul 21 11:21:58 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90157-2>; Fri, 21 Jul 1995 11:16:05 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA26666; Fri, 21 Jul 1995 10:17:48 +0200 Date: Fri, 21 Jul 1995 10:17:47 +0200 (MET DST) From: Kamil Iskra Subject: GCC 2.7.0 Bugs To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've found two bugs in "gcc" driver, in recognition of CPU-specific options. 1. When "-m68020-40" is used, assembler is not called with "-mc68020" option, but with "-mc68010" - this causes errors. 2. When "-mc68020" is used, linker is not called with "-fl libm020" option. PHILIPPE, if I soon die because of a heart attack, YOU will be responsible! I already reported this bug TWICE, this is THIRD time. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Jul 21 11:26:33 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <90132-1>; Fri, 21 Jul 1995 11:26:03 +0300 Received: from faui80.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA15753 (5.65c-7/7.3w-FAU); Fri, 21 Jul 1995 10:25:12 +0200 Received: from faui8s4 by immd8.informatik.uni-erlangen.de; id AA07726 (5.x/7.3w-FAU); Fri, 21 Jul 1995 10:25:11 +0200 From: Tobias Ruland Message-Id: <9507210825.AA07726@immd8.informatik.uni-erlangen.de> Date: Fri, 21 Jul 1995 10:25:10 +0200 To: Kamil Iskra Cc: Amiga GCC List Subject: Re: GCC 2.7.0 Bugs In-Reply-To: References: Kamil Iskra writes: > 2. When "-mc68020" is used, linker is not called with "-fl libm020" > option. PHILIPPE, if I soon die because of a heart attack, YOU will be > responsible! I already reported this bug TWICE, this is THIRD time. i'm sure you're young and dynamic like we are all :-) you'll not die of a heart attack that soon :-) kind regards tobias --------------------------------------------------------------------------- Tobias Ruland (student at Dept. of Artificial Intelligence, Univ. Erlangen) MAIL: tsruland@immd8.informatik.uni-erlangen.de (Please write in ENGLISH, GERMAN or FINNISH) WWW: http://www8.informatik.uni-erlangen.de/~tsruland From amiga-gcc-port-owner@nic.funet.fi Fri Jul 21 11:46:13 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90114-4>; Fri, 21 Jul 1995 11:45:09 +0300 Received: by colombo.telesys-innov.fr; Fri, 21 Jul 1995 10:45:25 +0100 From: Philippe BRAND Message-Id: <199507210945.KAA05620@colombo.telesys-innov.fr> Subject: Re: GCC 2.7.0 Bugs To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Fri, 21 Jul 1995 10:45:24 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Kamil Iskra" at Jul 21, 95 10:17:47 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 826 Kamil Iskra writes: > 1. When "-m68020-40" is used, assembler is not called with "-mc68020" > option, but with "-mc68010" - this causes errors. Ok I'll fix it... > 2. When "-mc68020" is used, linker is not called with "-fl libm020" > option. PHILIPPE, if I soon die because of a heart attack, YOU will be > responsible! I already reported this bug TWICE, this is THIRD time. Ok this time I'll fix it ;-) Hold your breath ;-) You can also, now, edit 'specs' file to correct this. This what I'll do (well in fact change amigados.h file in gcc). This time this email has been save in my todo directory, exported each night to my amiga at home. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Jul 21 12:42:36 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90236-4>; Fri, 21 Jul 1995 12:41:53 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Fri, 21 Jul 95 11:39 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Fri, 21 Jul 95 11:38 MET DST Message-Id: Subject: GCC 2.7.0 Bugs (fwd) To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Fri, 21 Jul 1995 11:38:53 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 869 Forwarded message: > 2. When "-mc68020" is used, linker is not called with "-fl libm020" > option. PHILIPPE, if I soon die because of a heart attack, YOU will be > responsible! I already reported this bug TWICE, this is THIRD time. > hi kamil, take it easy i didnt get the 68k version on gcc running yet ! and 2. i submitted a patch to gcc2.5.8 to correct errors in the math-68881.h i hope its now with 2.7. (couldnt check it because 1.). on the other hand why does the gcc version crash with 80000003 ? my gcc2.6.3 for 68k20 produces a bus error when called, no guru. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Jul 21 22:02:18 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90440-1>; Fri, 21 Jul 1995 21:53:40 +0300 Received: from theseas.ntua.gr by FIPORT.FUNET.FI (PMDF V5.0-3 #2494) id <01HT5B7AVTSW00069K@FIPORT.FUNET.FI> for amiga-gcc-port@lists.funet.fi; Fri, 21 Jul 1995 21:54:05 +0200 (EET) Received: by theseas.ntua.gr with UUCP; Fri, 21 Jul 1995 21:55:00 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07ul@kriton.UUCP>; Fri, 21 Jul 1995 21:49:16 +0200 (EET) Date: Fri, 21 Jul 1995 21:49:16 +0200 (EET) From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) Subject: Bug in fflush (ixemul 41.1) To: amiga-gcc-port@lists.funet.fi Reply-to: kyrimis@theseas.ntua.gr Message-id: <9507211949.07ul@kriton.UUCP> Organization: My Home Content-transfer-encoding: 7BIT Ixemul.library's fflush() subroutine returns an error code (Bad file descriptor) when asked to flush stderr. This happens in version 41.1, and I'm fairly certain it also used to happen in version 41.0. The problem can be reproduced by the following program: #include main() { if (fflush(stderr)) { perror(""); } return 0; } -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I've discovered we can't afford to die here--not even once!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Jul 24 08:14:06 1995 Received: from baurz32.urz.uni-bamberg.de ([141.13.250.32]) by nic.funet.fi with SMTP id <89677-4>; Mon, 24 Jul 1995 08:11:55 +0300 Received: from urzmail.stud.uni-bamberg.de by baurz32.urz.uni-bamberg.de with SMTP (1.37.109.4/16.2) id AA02955; Mon, 24 Jul 95 07:06:55 +0200 Received: from URZMAIL/SpoolDir by urzmail.stud.uni-bamberg.de (Mercury 1.13); Mon, 24 Jul 95 7:13:38 GMT+1 Received: from SpoolDir by URZMAIL (Mercury 1.13); Mon, 24 Jul 95 7:13:20 GMT+1 From: "Stefan Westner" Organization: UNI-BAMBERG To: amiga-gcc-port@nic.funet.fi Date: Fri, 21 Jul 1995 14:50:04 GMT+0100 Subject: GhostView 2.6.1 form the Fish-Disk X-Confirm-Reading-To: "Stefan Westner" X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <4453800EF8@urzmail.stud.uni-bamberg.de> Hello, I have to questions, one to LIBNIX 1.0 and one to GhostScript 2.6.1 form the Fish-Disc: a) When installing LIBNIX 1.0 over my GCC 2.6.3 using the INSTALL-Script provided in the packet the installer crashes after the "Please check the right path for your spec file". Is there a bug in the install-script? If so, where (I didn't find one)? Is there an other way to install LIBNIX 1.0 (i. e. extract the files (and copy it manually...))? b) After installing GhostScript 2.6.1 I want to use my original PS-Fonts from Adobe (copied from my PC-TypeManager) rather then the bad X-Fonts. On the PC I can set the GS_LIB-Environmentvariable with the path to the PS- Fonts. On the Amiga this didn't seem to work. Tracing with Snoopdos showed that the gs looked for a GS_LIB and find one but didn't interpret it (gs didn't find the fonts). Any ideas? Bye Bye Stefan -------------------------------------------------------------------------- Stefan Westner Tel: 0951/74375 Grabenstrasse 41 Stefan.Westner@stud.uni-bamberg.de 96103 Hallstadt PGP-Public-Key auf Anfrage verfuegbar PGP-Public-Key available on request -------------------------------------------------------------------------- ... So muessen Mails aussehen, dann klappts auch mit dem Nachbarn ... From amiga-gcc-port-owner@nic.funet.fi Mon Jul 24 13:39:31 1995 Received: from dfunms.rus.uni-stuttgart.de ([129.69.1.162]) by nic.funet.fi with SMTP id <89223-3>; Mon, 24 Jul 1995 13:35:40 +0300 Received: from ifr1.luftfahrt.uni-stuttgart.de by dfunms.rus.uni-stuttgart.de with SMTP id AA06987 (5.65c8/DFUE-M1.0 for ); Mon, 24 Jul 1995 12:35:16 +0200 Received: from ifr3 by ifr1.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-1.0NeXT+) id AA00229; Mon, 24 Jul 95 12:35:12 +0200 Message-Id: <9507241035.AA00229@ifr1.Luftfahrt.Uni-Stuttgart.DE> Received: by ifr3.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-S1.0NeXT+) id AA02676; Mon, 24 Jul 95 12:35:07 +0200 Date: Mon, 24 Jul 95 12:35:07 +0200 From: raimund@ifr.luftfahrt.uni-stuttgart.de Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: amiga-gcc-port@nic.funet.fi Subject: Plotting with ocatve 1.1.1? Hi, perhaps I am a little off topic, but I think this is a good place to ask. I installed octave 1.1.1 from FreshFishCD Vol. 9 and tried to plot something with octave. Since octave uses gnuplot to plot I edited the .octaverc file to set the environment for the gnuplot_binary. But if I try to plot something octave calls gnuplot but I get no output. The gnuplot process is in ready state and takes cpu time, but nothing happens. What should I do? Thanks Raimund From amiga-gcc-port-owner@nic.funet.fi Mon Jul 24 14:28:54 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89326-3>; Mon, 24 Jul 1995 14:25:34 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id MAA09252; Mon, 24 Jul 1995 12:22:39 +0100 From: Lars Hecking Message-Id: <199507241125.MAA24558@mostar.nmrc.ucc.ie> Subject: Re: Bug in fflush (ixemul 41.1) To: kyrimis@theseas.ntua.gr Date: Mon, 24 Jul 1995 12:25:25 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9507211949.07ul@kriton.UUCP> from "Kriton Kyrimis" at Jul 21, 95 09:49:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 316 > Ixemul.library's fflush() subroutine returns an error code (Bad file > descriptor) when asked to flush stderr. This happens in version 41.1, and I'm > fairly certain it also used to happen in version 41.0. Yep. This bug has been here for a while and makes some ugly klugdes necessary for programs like gawk. From amiga-gcc-port-owner@nic.funet.fi Mon Jul 24 14:37:01 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <89227-1>; Mon, 24 Jul 1995 14:33:24 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HT92IAWKBK90S4PR@LEON.CTI.GR>; Mon, 24 Jul 1995 14:27:27 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA00705; Mon, 24 Jul 95 14:32:52 +0300 Date: Mon, 24 Jul 1995 14:32:51 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: Bug in fflush (ixemul 41.1) In-reply-to: <199507241125.MAA24558@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jul 24, 95 12:25:25 pm To: lhecking@nmrc.ucc.ie (Lars Hecking) Cc: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9507241132.AA00705@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 361 > Yep. This bug has been here for a while and makes some ugly klugdes > necessary for programs like gawk. Which is exactly where I discovered the bug! -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "That's a bit of a mystery; no one's been able to decipher the carving." "It says `dig hole here'." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Jul 24 17:14:07 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89376-3>; Mon, 24 Jul 1995 17:07:11 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id OAA10971; Mon, 24 Jul 1995 14:38:46 +0100 From: Lars Hecking Message-Id: <199507241341.OAA24683@mostar.nmrc.ucc.ie> Subject: Re: Bug in fflush (ixemul 41.1) To: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Date: Mon, 24 Jul 1995 14:41:33 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9507241132.AA00705@hpcl.cti.gr> from "Kriton Kyrimis" at Jul 24, 95 02:32:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 358 > > Yep. This bug has been here for a while and makes some ugly klugdes > > necessary for programs like gawk. > > Which is exactly where I discovered the bug! So did I ;-) > "That's a bit of a mystery; no one's been able to decipher the carving." > "It says `dig hole here'." -- 'We need a Best Man.' 'Ook.' 'Well, at least put some clothes on.' From amiga-gcc-port-owner@nic.funet.fi Mon Jul 24 17:38:16 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89584-4>; Mon, 24 Jul 1995 17:34:56 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26490-3>; Mon, 24 Jul 1995 16:34:22 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209171-1>; Mon, 24 Jul 1995 16:34:10 +0100 Subject: Re: Bug in fflush (ixemul 41.1) From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Mon, 24 Jul 1995 16:34:02 +0200 (MESZ) In-Reply-To: <199507241341.OAA24683@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jul 24, 95 02:41:33 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 583 Message-Id: <95Jul24.163410+0100mesz.209171-1+1212@hphalle0.informatik.tu-muenchen.de> > > > Yep. This bug has been here for a while and makes some ugly klugdes > > > necessary for programs like gawk. > > > > Which is exactly where I discovered the bug! > > So did I ;-) Seems gawk is the only program where it shows up (I found it while compiling gawk, too). Anybody found the bug with another program? Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Ex-Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Mon Jul 24 17:41:36 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89118-4>; Mon, 24 Jul 1995 17:38:11 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0saOfI-0004nYC; Mon, 24 Jul 95 07:39 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Plotting with ocatve 1.1.1? To: raimund@ifr.luftfahrt.uni-stuttgart.de Date: Mon, 24 Jul 1995 07:39:28 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9507241035.AA00229@ifr1.Luftfahrt.Uni-Stuttgart.DE> from "raimund@ifr.luftfahrt.uni-stuttgart.de" at Jul 24, 95 12:35:07 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1180 > I installed octave 1.1.1 from FreshFishCD Vol. 9 and tried to plot > something with octave. Since octave uses gnuplot to plot I edited the > .octaverc file to set the environment for the gnuplot_binary. But if > I try to plot something octave calls gnuplot but I get no output. The > gnuplot process is in ready state and takes cpu time, but nothing > happens. I don't have gnuplot installed here, apparently, so when octave is configured it does not find a default gnuplot. This is the output of configure on my system: checking for gnuplot... no configure: warning: I didn't find gnuplot. It isn't necessary to have gnuplot configure: warning: installed, but you won't be able to use any of Octave's configure: warning: plotting commands without it. configure: warning: configure: warning: If gnuplot is installed but it isn't in your path, you can configure: warning: tell Octave where to find it by typing the command configure: warning: configure: warning: gnuplot_binary = /full/path/to/gnuplot/binary configure: warning: configure: warning: at the Octave prompt. I guess I need to try configuring and installing gnuplot... -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Jul 24 19:37:55 1995 Received: from theseas.ntua.gr ([147.102.1.1]) by nic.funet.fi with SMTP id <89668-1>; Mon, 24 Jul 1995 19:33:36 +0300 Received: by theseas.ntua.gr with UUCP; Mon, 24 Jul 1995 19:35:22 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <07v0@kriton.UUCP>; Mon, 24 Jul 95 19:29:45 EET Date: Mon, 24 Jul 95 19:29:45 EET Message-Id: <9507241729.07v0@kriton.UUCP> In-Reply-To: <95Jul24.163410+0100mesz.209171-1+1212@hphalle0.informatik.tu-muenchen.de> (from Christian Stieber ) (at Mon, 24 Jul 1995 16:34:02 +0200 (MESZ)) Organization: My Home Reply-To: kyrimis@theseas.ntua.gr Content-Length: 704 From: kriton!kyrimis@theseas.ntua.gr (Kriton Kyrimis) To: stieber@informatik.tu-muenchen.de Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Bug in fflush (ixemul 41.1) Hi Christian (Christian Stieber), in <95Jul24.163410+0100mesz.209171-1+1212@hphalle0.informatik.tu-muenchen.de> on Jul 24 you wrote: > Seems gawk is the only program where it shows up (I found it while compiling > gawk, too). Anybody found the bug with another program? More to the point, does anyone ever check the return value of all those functions that "never" fail, like fflush? It could turn out that the return code part of these function is poorly debugged, given that almost nobody ever uses it! -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Oh, it's just the unknown, then!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jul 25 10:15:55 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <89319-4>; Tue, 25 Jul 1995 10:12:34 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA08899 (5.65b/CWI-3.3); Tue, 25 Jul 1995 09:12:14 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sadHu-000FikC; Tue, 25 Jul 95 08:16 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <08gx@wyst.hobby.nl>; Tue, 25 Jul 95 08:15:12 CET Message-Id: <9507250715.08gx@wyst.hobby.nl> Date: Tue, 25 Jul 1995 08:15:10 +0000 (CET) Content-Type: text Content-Length: 1079 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Cc: fnf@amigalib.com Subject: Re: Bug in fflush (ixemul 41.1) Hi, To squash the bug, just apply the patch included below to fflush.c in the stdio_2 directory of ixemul.library. In general, the library is quite good at handling return codes, but it is rarely tested, so bugs may still remain. --------------- cut here ---------------- *** f.c Mon Jul 24 21:19:15 1995 --- fflush.c Mon Jul 24 21:19:40 1995 *************** *** 52,56 **** return (_fwalk(__sflush)); ! if ((fp->_flags & __SWR) == 0) { errno = EBADF; KPRINTF (("&errno = %lx, errno = %ld\n", &errno, errno)); --- 52,56 ---- return (_fwalk(__sflush)); ! if ((fp->_flags & (__SWR|__SRW)) == 0) { errno = EBADF; KPRINTF (("&errno = %lx, errno = %ld\n", &errno, errno)); --------------- cut here ---------------- Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Jul 25 16:36:20 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89054-4>; Tue, 25 Jul 1995 16:30:36 +0300 Received: by ceylon.informatik.uni-rostock.de id PAA18726; Tue, 25 Jul 1995 15:30:15 +0200 Received: by honshu.informatik.uni-rostock.de id PAA19138; Tue, 25 Jul 1995 15:30:12 +0200 From: Gunther Nikl Message-Id: <199507251330.PAA19138@honshu.informatik.uni-rostock.de> Subject: include / lib search path To: amiga-gcc-port@nic.funet.fi Date: Tue, 25 Jul 1995 15:30:12 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 369 Hi! Does make amiga-gcc use of a local directory? I mean will it search for libs,includes in /local ? I know that at least cpp of 2.7.0 looks for /local/include but I am more interested in /local/os-include. I would be nice in the following way: /local/include /include /local/os-include /os-include (I may have forgotten some directories ;) Gunther From amiga-gcc-port-owner@nic.funet.fi Tue Jul 25 17:28:27 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <89118-1>; Tue, 25 Jul 1995 17:26:23 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id QAA26146 (8.6.10/2.4); Tue, 25 Jul 1995 16:26:30 +0200 Date: Tue, 25 Jul 1995 16:26:30 +0200 From: Olaf Seibert Message-Id: <199507251426.QAA26146@septimius.mbfys.kun.nl> To: amiga-gcc-port@nic.funet.fi, gnikl@informatik.uni-rostock.de Subject: Re: include / lib search path > Does make amiga-gcc use of a local directory? I mean will On the Unix system I administer, I have the following: export C_INCLUDE_PATH=/usr/local/include export CPLUS_INCLUDE_PATH=/usr/local/g++-include export LIBRARY_PATH=/usr/local/lib These paths are colon-separated directories, just like PATH. They add to the places gcc normally searches. I assume ENV: or local variables on AmigaDOS will work the same. -Olaf. -- Have you indecently fucked this Exon idiot and his allies today? ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Tue Jul 25 19:05:25 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89489-4>; Tue, 25 Jul 1995 19:03:30 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Tue, 25 Jul 1995 18:02:04 +0200 Received: from hoechst.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA11606; Tue, 25 Jul 95 18:02:10 +0200 Date: Tue, 25 Jul 95 18:02:10 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9507251602.AA11606@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@nic.funet.fi Subject: Re: include / lib search path Hi, Gunther Nikl wrote: > Does make amiga-gcc use of a local directory? I mean will > /local/include > /include > /local/os-include > /os-include I hope that this will only be found in the specs file, so that I can comment it out, because I always have to cancel the "Please insert local..." requester. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Tue Jul 25 19:17:21 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88970-1>; Tue, 25 Jul 1995 19:15:32 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0samfN-0004nYC; Tue, 25 Jul 95 09:17 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: include / lib search path To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Tue, 25 Jul 1995 09:17:09 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9507251602.AA11606@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Jul 25, 95 06:02:10 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 638 > > Does make amiga-gcc use of a local directory? I mean will > > > /local/include > > /include > > /local/os-include > > /os-include > I hope that this will only be found in the specs file, so that I can > comment it out, because I always have to cancel the "Please insert local..." > requester. Many of the other GNU tools that I've built and installed on the FreshFish CD also allow searching /local before some directory on the CD (so you can make local changes to things that are on the CD and still run from the CD). The GNU startup script assigns local: to ram:t as the default. I'd suggest doing something similar. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Jul 26 15:46:55 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90369-3>; Wed, 26 Jul 1995 15:43:18 +0300 Received: by colombo.telesys-innov.fr; Wed, 26 Jul 1995 14:44:02 +0100 From: Philippe BRAND Message-Id: <199507261344.OAA27831@colombo.telesys-innov.fr> Subject: Preliminary 2.7.0 distribution To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Wed, 26 Jul 1995 14:44:01 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 385 I've put 2.7.0 preliminary distribution on my FTP site. Still needed: libg++-2.7.0, Installer script both both upgrade and fresh installation (I've modified README so all steps are described), Latest FAQ. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Jul 26 23:16:54 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <89227-2>; Wed, 26 Jul 1995 23:11:11 +0300 Received: from pessoa by torga.ci.uminho.pt (5.4.1/140.2) id AA17720; Wed, 26 Jul 1995 22:12:49 GMT Received: by pessoa.ci.uminho.pt (5.4R2.10/140.2) id AA19768; Wed, 26 Jul 1995 22:10:25 +0200 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9507262010.AA19768@pessoa.ci.uminho.pt> Subject: HP48G answer me for sites To: amiga-gcc-port@nic.funet.fi (gcc) Date: Wed, 26 Jul 1995 22:10:25 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 391 can anybody tell about about sites wiyh programs for HPi48G. please answer me, please. __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Thu Jul 27 02:03:54 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89461-2>; Thu, 27 Jul 1995 02:03:02 +0300 Received: by colombo.telesys-innov.fr; Thu, 27 Jul 1995 01:05:23 +0100 From: Philippe BRAND Message-Id: <199507270005.BAA29412@colombo.telesys-innov.fr> Subject: gcc270-inclib is now correct To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Thu, 27 Jul 1995 01:05:23 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 278 Thanks to Lars who realized that gcc270-inclib.lha was corrupted. I've just stored correct version. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Jul 27 12:46:50 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <88934-1>; Thu, 27 Jul 1995 12:45:29 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 27 Jul 95 11:44 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 27 Jul 95 11:39 MET DST Message-Id: Subject: gcc and 68k To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 27 Jul 1995 11:39:06 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 367 good news for all who still use a m68k. the new gcc270 starts without guru. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Thu Jul 27 15:05:50 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89039-1>; Thu, 27 Jul 1995 15:04:30 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id NAA16883; Thu, 27 Jul 1995 13:03:01 +0100 From: Lars Hecking Message-Id: <199507271205.NAA28478@mostar.nmrc.ucc.ie> Subject: GNU ld To: phb@colombo.telesys-innov.fr (Philippe Brand) Date: Thu, 27 Jul 1995 13:05:50 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 200 GNU ld also needs to use stack extension or GCCSTACK. For some compile jobs, ld needs around 100k of stack, which usually exceeds my shell's default (not that I care with 14MB of RAM, but YMMV). From amiga-gcc-port-owner@nic.funet.fi Thu Jul 27 15:50:00 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89244-2>; Thu, 27 Jul 1995 15:49:18 +0300 Received: by colombo.telesys-innov.fr; Thu, 27 Jul 1995 14:51:34 +0100 From: Philippe BRAND Message-Id: <199507271351.OAA01508@colombo.telesys-innov.fr> Subject: Re: GNU ld To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 27 Jul 1995 14:51:33 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199507271205.NAA28478@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jul 27, 95 01:05:50 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 448 Lars Hecking writes: > GNU ld also needs to use stack extension or GCCSTACK. For some compile > jobs, ld needs around 100k of stack, which usually exceeds my shell's > default (not that I care with 14MB of RAM, but YMMV). Ok I'll rebuild ld with GCCSTACK support. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Jul 27 17:41:11 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89057-1>; Thu, 27 Jul 1995 17:33:33 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sbU2R-0004nYC; Thu, 27 Jul 95 07:35 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: GNU ld To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Thu, 27 Jul 1995 07:35:51 -0700 (MST) Cc: lhecking@nmrc.ucc.ie, amiga-gcc-port@nic.funet.fi In-Reply-To: <199507271351.OAA01508@colombo.telesys-innov.fr> from "Philippe BRAND" at Jul 27, 95 02:51:33 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 633 > > GNU ld also needs to use stack extension or GCCSTACK. For some compile > > jobs, ld needs around 100k of stack, which usually exceeds my shell's > > default (not that I care with 14MB of RAM, but YMMV). > > Ok I'll rebuild ld with GCCSTACK support. Hmm, when ixemul starts a child (as would normally be the case with ld started by gcc, "make", or "sh"), then the child automatically gets a stack of 250,000 unless IXSTACK is set to some other value or the stack is already larger than that. So the only time ld could end up with less stack is if it is run directly from a CLI. Is this not working for some reason? -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Jul 27 17:42:08 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89172-4>; Thu, 27 Jul 1995 17:40:35 +0300 Received: by colombo.telesys-innov.fr; Thu, 27 Jul 1995 16:42:47 +0100 From: Philippe BRAND Message-Id: <199507271542.QAA02099@colombo.telesys-innov.fr> Subject: Re: GNU ld To: fnf@amigalib.com (Fred Fish) Date: Thu, 27 Jul 1995 16:42:46 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Fred Fish" at Jul 27, 95 07:35:51 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 523 Fred Fish writes: > Hmm, when ixemul starts a child (as would normally be the case with ld > started by gcc, "make", or "sh"), then the child automatically gets a > stack of 250,000 unless IXSTACK is set to some other value or the > stack is already larger than that. Ahem... well I forgot this option... Let's keep things like it is now ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Jul 27 22:31:12 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <89744-2>; Thu, 27 Jul 1995 22:27:56 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id VAA01123 (8.6.10/2.4); Thu, 27 Jul 1995 21:28:02 +0200 Date: Thu, 27 Jul 1995 21:28:02 +0200 From: Olaf Seibert Message-Id: <199507271928.VAA01123@septimius.mbfys.kun.nl> To: amiga-gcc-port@nic.funet.fi, rhialto@mbfys.kun.nl Subject: cp crashes with ixemul 41.x Yesterday I was running a script to compile all versions of prlink (which is irrelevant to the discussion :). The script used the cp command from the gcc 2.6.3 package, and it crashed every time (leaving the distination disk unvalidated). Since I had ixemul 41.0, I installed 41.1 and retried, but no improvement. So I went back to 40.4, which worked fine. Anybody got an idea what's going on? (I just think of stack size; perhaps 41.x uses more stack? I haven't tested this yet...) -Olaf. -- Have you indecently fucked this Exon idiot and his allies today? ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Thu Jul 27 23:13:18 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <88939-1>; Thu, 27 Jul 1995 23:12:40 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id VAA24261; Thu, 27 Jul 1995 21:06:14 +0100 From: Lars Hecking Message-Id: <199507272009.VAA28838@mostar.nmrc.ucc.ie> Subject: Re: GNU ld To: fnf@amigalib.com (Fred Fish) Date: Thu, 27 Jul 1995 21:09:03 +0100 (BST) Cc: phb@colombo.telesys-innov.fr (Philippe Brand), amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Fred Fish" at Jul 27, 95 07:35:51 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1071 > > > GNU ld also needs to use stack extension or GCCSTACK. For some compile > > > jobs, ld needs around 100k of stack, which usually exceeds my shell's > > > default (not that I care with 14MB of RAM, but YMMV). > > > > Ok I'll rebuild ld with GCCSTACK support. > > Hmm, when ixemul starts a child (as would normally be the case with ld > started by gcc, "make", or "sh"), then the child automatically gets a > stack of 250,000 unless IXSTACK is set to some other value or the > stack is already larger than that. So the only time ld could end up > with less stack is if it is run directly from a CLI. Is this not > working for some reason? IXSTACK (or 250,000) is only used by system(3), but gcc in turn runs ld via vfork()+execvp() (-->execve). See gcc source (collect2.c) and ixemul source (stdlib/exec.c). Another issue: could you, Philippe, synchronize GNU:include and GNU:lib/gcc-lib///include, INCLUDE THE PATCHES THAT HAVE BEEN POSTED HERE (sorry for shouting ;-) and feed this back to Fred for the ixemul release? Thanks :) From amiga-gcc-port-owner@nic.funet.fi Thu Jul 27 23:25:16 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <88989-2>; Thu, 27 Jul 1995 23:24:55 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 27 Jul 95 22:24 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 27 Jul 95 22:19 MET DST Message-Id: Subject: debug.lib alpha testers To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 27 Jul 1995 22:19:48 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 606 i am preparing to release a gcc-clone of comos-debug.lib. i cant do extensive test my 68k based is a bit slow. this time its a -ready-to-link- library ;). but it will take some time before the ext version is released. i plan my final exams in the next time, so there is a lot of non-amiga related work for me. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 00:16:53 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89560-2>; Fri, 28 Jul 1995 00:16:00 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id WAA24738; Thu, 27 Jul 1995 22:14:35 +0100 From: Lars Hecking Message-Id: <199507272117.WAA28941@mostar.nmrc.ucc.ie> Subject: Re: cp crashes with ixemul 41.x To: rhialto@mbfys.kun.nl (Olaf Seibert) Date: Thu, 27 Jul 1995 22:17:25 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199507271928.VAA01123@septimius.mbfys.kun.nl> from "Olaf Seibert" at Jul 27, 95 09:28:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 663 > Yesterday I was running a script to compile all versions of prlink > (which is irrelevant to the discussion :). The script used the cp > command from the gcc 2.6.3 package, and it crashed every time (leaving > the distination disk unvalidated). Since I had ixemul 41.0, I > installed 41.1 and retried, but no improvement. So I went back to 40.4, > which worked fine. > > Anybody got an idea what's going on? (I just think of stack size; > perhaps 41.x uses more stack? I haven't tested this yet...) I also had this problem with cp before ixemul 41.x, and I think it's a stack problem. Usually, 32k did the job, but now cp seems to need more than 64k :( From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 00:19:58 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89314-4>; Fri, 28 Jul 1995 00:19:36 +0300 Received: by ceylon.informatik.uni-rostock.de id XAA28653; Thu, 27 Jul 1995 23:19:12 +0200 Received: by honshu.informatik.uni-rostock.de id XAA25371; Thu, 27 Jul 1995 23:19:11 +0200 From: Gunther Nikl Message-Id: <199507272119.XAA25371@honshu.informatik.uni-rostock.de> Subject: Re: include / lib search path To: amiga-gcc-port@nic.funet.fi Date: Thu, 27 Jul 1995 23:19:10 +0200 (MET DST) In-Reply-To: <9507251602.AA11606@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Jul 25, 95 06:02:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 678 > Joerg Hoehle wrote: > > > > /local/include > > /include > > /local/os-include > > /os-include > I hope that this will only be found in the specs file, so that I can > comment it out, because I always have to cancel the "Please insert local..." > requester. Don't you use "ixconfig -v" ? :-) But wouldn't it be easier to make the assign rather than to get such annouying requesters? Anyway, the reason I asked for some special default include directories is the fact, that I finally realized, its much better to have os-haeders seperated from third party ones. And this could be easily done via /local/os-include (searched before /os-include) Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 00:22:50 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89677-3>; Fri, 28 Jul 1995 00:22:21 +0300 Received: by ceylon.informatik.uni-rostock.de id XAA28665; Thu, 27 Jul 1995 23:22:02 +0200 Received: by honshu.informatik.uni-rostock.de id XAA25396; Thu, 27 Jul 1995 23:22:01 +0200 From: Gunther Nikl Message-Id: <199507272122.XAA25396@honshu.informatik.uni-rostock.de> Subject: Re: cp crashes with ixemul 41.x To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Thu, 27 Jul 1995 23:22:01 +0200 (MET DST) In-Reply-To: <199507272117.WAA28941@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jul 27, 95 10:17:25 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 437 > > Anybody got an idea what's going on? (I just think of stack size; > > perhaps 41.x uses more stack? I haven't tested this yet...) > > I also had this problem with cp before ixemul 41.x, and I think it's > a stack problem. Usually, 32k did the job, but now cp seems to need > more than 64k :( I can only confirm this. cp used by the libnix-installation makefile uses ca. 75k stack max. (check with a stackmon) Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 00:25:45 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89929-2>; Fri, 28 Jul 1995 00:25:25 +0300 Received: by ceylon.informatik.uni-rostock.de id XAA28689; Thu, 27 Jul 1995 23:25:06 +0200 Received: by honshu.informatik.uni-rostock.de id XAA25420; Thu, 27 Jul 1995 23:25:05 +0200 From: Gunther Nikl Message-Id: <199507272125.XAA25420@honshu.informatik.uni-rostock.de> Subject: Re: GNU ld To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Thu, 27 Jul 1995 23:25:04 +0200 (MET DST) In-Reply-To: from "Fred Fish" at Jul 27, 95 07:35:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 631 > > Ok I'll rebuild ld with GCCSTACK support. > > Hmm, when ixemul starts a child (as would normally be the case with ld > started by gcc, "make", or "sh"), then the child automatically gets a > stack of 250,000 unless IXSTACK is set to some other value or the > stack is already larger than that. So the only time ld could end up > with less stack is if it is run directly from a CLI. Is this not > working for some reason? Nope, not true. I had my shell stacksize set to 20.000 bytes and used GCCSTACK. make crashed in the final link stage and a stackmon showed, that ld did have the default shell stack. Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 00:28:21 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89071-3>; Fri, 28 Jul 1995 00:27:50 +0300 Received: by ceylon.informatik.uni-rostock.de id XAA28698; Thu, 27 Jul 1995 23:27:28 +0200 Received: by honshu.informatik.uni-rostock.de id XAA25437; Thu, 27 Jul 1995 23:27:27 +0200 From: Gunther Nikl Message-Id: <199507272127.XAA25437@honshu.informatik.uni-rostock.de> Subject: Re: GNU ld To: amiga-gcc-port@nic.funet.fi Date: Thu, 27 Jul 1995 23:27:27 +0200 (MET DST) In-Reply-To: <199507272009.VAA28838@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jul 27, 95 09:09:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 453 > Another issue: could you, Philippe, synchronize GNU:include and > GNU:lib/gcc-lib///include, INCLUDE THE PATCHES THAT > HAVE BEEN POSTED HERE (sorry for shouting ;-) and feed this back to > Fred for the ixemul release? Thanks :) I support this! My solution so far is to disable the include directory found in the place cc1 resides, but this is not so well, I suppose... (but didn't had any problems so far) Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 00:31:59 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <89726-3>; Fri, 28 Jul 1995 00:31:44 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id XAA01241 (8.6.10/2.4); Thu, 27 Jul 1995 23:31:53 +0200 Date: Thu, 27 Jul 1995 23:31:53 +0200 From: Olaf Seibert Message-Id: <199507272131.XAA01241@septimius.mbfys.kun.nl> To: amiga-gcc-port@nic.funet.fi, gnikl@informatik.uni-rostock.de Subject: Re: cp crashes with ixemul 41.x Remains the question, *why* would a change in ixemul.library cause an application to use significantly more stack? Could it be alloca()? (just wild speculation here, I don't have the source of this particular cp. The NetBSD cp uses a static buffer of MAXBSIZE (16384) bytes or mmap() to map the file in memory.) -Olaf. -- Have you indecently fucked this Exon idiot and his allies today? ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 00:41:39 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89528-2>; Fri, 28 Jul 1995 00:41:10 +0300 Received: by colombo.telesys-innov.fr; Thu, 27 Jul 1995 23:43:30 +0100 From: Philippe BRAND Message-Id: <199507272243.XAA03416@colombo.telesys-innov.fr> Subject: Re: GNU ld To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 27 Jul 1995 23:43:30 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199507272009.VAA28838@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jul 27, 95 09:09:03 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 710 Lars Hecking writes: > Another issue: could you, Philippe, synchronize GNU:include and > GNU:lib/gcc-lib///include, INCLUDE THE PATCHES THAT > HAVE BEEN POSTED HERE (sorry for shouting ;-) and feed this back to > Fred for the ixemul release? Thanks :) I've already synched with Fred a few weeks ago. I suggest now everyone send their patches on amiga-gcc-port so that: everyone will see them, and I'll integrate them for 2.7.0. I prefer to wait for everything to be clean before releasing 2.7.0 on Aminet. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 01:13:01 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89202-4>; Fri, 28 Jul 1995 01:12:35 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sbbCW-0004nYC; Thu, 27 Jul 95 15:14 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: GNU ld To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Thu, 27 Jul 1995 15:14:43 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199507272127.XAA25437@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Jul 27, 95 11:27:27 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1436 > > Another issue: could you, Philippe, synchronize GNU:include and > > GNU:lib/gcc-lib///include, INCLUDE THE PATCHES THAT > > HAVE BEEN POSTED HERE (sorry for shouting ;-) and feed this back to > > Fred for the ixemul release? Thanks :) > > I support this! My solution so far is to disable the include directory > found in the place cc1 resides, but this is not so well, I suppose... > (but didn't had any problems so far) The way it should work (in theory) is: (1) Changes get made first in the include tree in ixemul source and ixemul.library gets rebuilt. (2) When ixemul.library is installed, part of the installation is to copy the include tree in the ixemul source tree to the gnu:include tree. (3) When gcc gets built, it runs fixincludes, which fixes things in gnu:include that it thinks needs fixing, and writes the fixed include files in gnu:lib/gcc-lib///include. Normally fixincludes is necessary because it is hard to get system vendors to change their system header files in /usr/include (gnu:include in our case). This is obviously not a problem here and we should work first to fold back whatever changes gcc wants into the ixemul headers, assuming they don't make the headers incompatible with other compilers for no good reason. We may someday have another compile that uses the headers and ixemul.library, that is not the GNU compiler. :-) -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 01:41:16 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89493-2>; Fri, 28 Jul 1995 01:40:45 +0300 Received: by colombo.telesys-innov.fr; Fri, 28 Jul 1995 00:43:09 +0100 From: Philippe BRAND Message-Id: <199507272343.AAA03754@colombo.telesys-innov.fr> Subject: libg++ 2.7.0 To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Fri, 28 Jul 1995 00:43:09 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 324 I've put a libg++ v2.7.0 on my FTP site: /pub/amigados-gnu/beta/libg270.lha This was built using cross-compiler running on sunos. Please test it. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 05:08:10 1995 Received: from io.org ([142.77.70.2]) by nic.funet.fi with SMTP id <90353-2>; Fri, 28 Jul 1995 05:07:31 +0300 Received: from "io.org" (timper.net5b.io.org [199.166.191.38]) by io.org (8.6.12/8.6.12) with SMTP id WAA02989 for ; Thu, 27 Jul 1995 22:07:05 -0400 Received: by "io.org" (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Thu, 27 Jul 95 22:07:00 From: tjhayko@timper (Tom Hayko) Message-Id: <210bcf02.u7t157e.b1d2a-tjhayko@timper> Subject: Re: cp crashes with ixemul 41.x In-Reply-To: <199507271928.VAA01123@septimius.mbfys.kun.nl> (from Olaf Seibert ) (at Thu, 27 Jul 1995 21:28:02 +0200) Reply-To: tjhayko@io.org To: rhialto@mbfys.kun.nl Cc: amiga-gcc-port@nic.funet.fi, rhialto@mbfys.kun.nl Date: Thu, 27 Jul 95 22:07:00 Hi Olaf (Olaf Seibert), in <199507271928.VAA01123@septimius.mbfys.kun.nl> on Jul 27 you wrote: > Yesterday I was running a script to compile all versions of prlink > (which is irrelevant to the discussion :). The script used the cp > command from the gcc 2.6.3 package, and it crashed every time (leaving > the distination disk unvalidated). Since I had ixemul 41.0, I > installed 41.1 and retried, but no improvement. So I went back to 40.4, > which worked fine. > > Anybody got an idea what's going on? (I just think of stack size; > perhaps 41.x uses more stack? I haven't tested this yet...) > > -Olaf. I seem to recall that I had this problem with 40.4 when copying large files too. I don't use the cp command from the GCC package so I figured I was using too small a stack. -- Tom Hayko tjhayko@io.org http://www.io.org/~tjhayko From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 09:20:40 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90100-3>; Fri, 28 Jul 1995 09:19:31 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA14931 (5.65b/CWI-3.3); Fri, 28 Jul 1995 08:11:24 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sbiLb-000FhQC; Fri, 28 Jul 95 07:52 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <08i0@wyst.hobby.nl>; Thu, 27 Jul 95 22:39:05 CET Message-Id: <9507272139.08i0@wyst.hobby.nl> Date: Thu, 27 Jul 1995 22:39:03 +0000 (CET) In-Reply-To: <199507271928.VAA01123@septimius.mbfys.kun.nl> from "Olaf Seibert" at Jul 27, 95 09:28:02 pm Content-Type: text Content-Length: 1154 From: hans@wyst.hobby.nl (Hans Verkuil) To: rhialto@mbfys.kun.nl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: cp crashes with ixemul 41.x According to Olaf Seibert: > > Yesterday I was running a script to compile all versions of prlink > (which is irrelevant to the discussion :). The script used the cp > command from the gcc 2.6.3 package, and it crashed every time (leaving > the distination disk unvalidated). Since I had ixemul 41.0, I > installed 41.1 and retried, but no improvement. So I went back to 40.4, > which worked fine. > > Anybody got an idea what's going on? (I just think of stack size; > perhaps 41.x uses more stack? I haven't tested this yet...) Unlikely that it has anything to do with the stack. Can you provide me with a small testcase? Some changes have been made to filehandling, most notably the handling of softlinks. Which ixconfig options (if any) do you use? This seems serious enough to spend some time on, but I need more detailed information. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 12:13:08 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89717-1>; Fri, 28 Jul 1995 12:11:22 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA22314; Fri, 28 Jul 1995 11:13:01 +0200 Date: Fri, 28 Jul 1995 11:13:00 +0200 (MET DST) From: Kamil Iskra Subject: Re: Preliminary 2.7.0 distribution To: Philippe BRAND cc: Amiga-Gcc Liste In-Reply-To: <199507261344.OAA27831@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 26 Jul 1995, Philippe BRAND wrote: > I've put 2.7.0 preliminary distribution on my FTP site. Philippe, I BEG you, transfer it to FUNET!!! I'm trying to download it from your side, but it's sOOOOO slOOOOOw that I most probably won't finish by Monday :-) BTW: What's file "gcc290-c.readme" doing on your FTP site? Is it a typo or what? There is no gcc 2.8.0, I believe, not to mention 2.9.0 :-) / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 12:17:10 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89933-2>; Fri, 28 Jul 1995 12:16:54 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA22347; Fri, 28 Jul 1995 11:18:39 +0200 Date: Fri, 28 Jul 1995 11:18:39 +0200 (MET DST) From: Kamil Iskra Subject: Re: HP48G answer me for sites To: "Luis Antonio F.Alves" cc: gcc In-Reply-To: <9507262010.AA19768@pessoa.ci.uminho.pt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 26 Jul 1995, Luis Antonio F.Alves wrote: > can anybody tell about about sites wiyh programs for HPi48G. > > please answer me, please. I don't know if this is what you are looking for, but I think you will find something here: ftp://nyquist.ee.ualberta.ca/pub/HP48 / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 12:25:05 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90352-4>; Fri, 28 Jul 1995 12:24:10 +0300 Received: by colombo.telesys-innov.fr; Fri, 28 Jul 1995 11:24:42 +0100 From: Philippe BRAND Message-Id: <199507281024.LAA04892@colombo.telesys-innov.fr> Subject: Re: Preliminary 2.7.0 distribution To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Fri, 28 Jul 1995 11:24:41 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Kamil Iskra" at Jul 28, 95 11:13:00 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 616 Kamil Iskra writes: > Philippe, I BEG you, transfer it to FUNET!!! I'm trying to download it > from your side, but it's sOOOOO slOOOOOw that I most probably won't > finish by Monday :-) Now transfering gcc270* and libg270.lha to nic.funet.fi:/pub/amiga/gnu/beta Sorry for this. > BTW: What's file "gcc290-c.readme" doing on your FTP site? Is it a typo or > what? There is no gcc 2.8.0, I believe, not to mention 2.9.0 :-) Typo :-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 15:01:02 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <90029-3>; Fri, 28 Jul 1995 14:59:09 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id NAA17228; Fri, 28 Jul 1995 13:56:41 +0200 From: Jochen Wiedmann Message-Id: <199507281156.NAA17228@iss1.neckar-alb.de> Subject: Re: GCC Install script To: iskra@student.uci.agh.edu.pl (Kamil Iskra) Date: Fri, 28 Jul 1995 13:56:40 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Jul 28, 95 12:30:47 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 787 Hello, Kamil, > Some time ago I posted an article to amiga-gcc-port@list.funet.fi > concerning incompatibilities between AmigaGuide v34-39 and v40 and their > influence on GCC guides. Just to remind you: AG v40 needs '\\n' in > ".guide" to display "\n" on the screen. I suggested running a special > correcting program during the installation that would convert all > occurences of "\" with "\\" in guides when "amigaguide.library" v40+ was > found. No one answered. I think you should have something to say on this > subject. As all .guide files in the gcc distribution are built from texinfo, it would be a much better idea, to modify the "makeinfo" sources (Aminet, mkguide1.55.lha or something like that) appropriately. And, without doubt, it would be much easier. :-) Jochen From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 16:51:26 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <90730-1>; Fri, 28 Jul 1995 16:44:59 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id PAA02673 (8.6.10/2.4); Fri, 28 Jul 1995 15:45:10 +0200 Date: Fri, 28 Jul 1995 15:45:10 +0200 From: Olaf Seibert Message-Id: <199507281345.PAA02673@septimius.mbfys.kun.nl> To: hans@wyst.hobby.nl, rhialto@mbfys.kun.nl Subject: Re: cp crashes with ixemul 41.x Cc: amiga-gcc-port@nic.funet.fi hans@wyst.hobby.nl (Hans Verkuil) wrote: > Unlikely that it has anything to do with the stack. > > Can you provide me with a small testcase? Some changes have been made to > filehandling, most notably the handling of softlinks. Which ixconfig > options (if any) do you use? This seems serious enough to spend some time > on, but I need more detailed information. I have done some testing now. I was in my local:libs directory, containing about 15 files, with largest file ixemul.library. I did cp * /t, using 40.4 and 41.1. With xoper I determined that 41.1 needed some 67000 bytes of stack. With 40.4, my default stack size of 16000 bytes was sufficient (or at least it didn't crash). (I haven't checked how much it actually used in this case.) In case it matters, this is on an A4000/040 with 12M ram, using the 040fpu version of ixemul. -Olaf. -- Have you indecently fucked this Exon idiot and his allies today? ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Fri Jul 28 20:12:03 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90299-3>; Fri, 28 Jul 1995 20:08:48 +0300 Received: by ceylon.informatik.uni-rostock.de id TAA02653; Fri, 28 Jul 1995 19:08:14 +0200 Received: by honshu.informatik.uni-rostock.de id TAA00480; Fri, 28 Jul 1995 19:08:12 +0200 From: Gunther Nikl Message-Id: <199507281708.TAA00480@honshu.informatik.uni-rostock.de> Subject: Re: Preliminary 2.7.0 distribution To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Fri, 28 Jul 1995 19:08:11 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199507281024.LAA04892@colombo.telesys-innov.fr> from "Philippe BRAND" at Jul 28, 95 11:24:41 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 421 > Kamil Iskra writes: > > > Philippe, I BEG you, transfer it to FUNET!!! I'm trying to download it > > from your side, but it's sOOOOO slOOOOOw that I most probably won't > > finish by Monday :-) Mhm, when did you try? I downloaded from colombo and it was everything else but slow (about 1 am) It would be a good thing, if all utilities in /bin would become pure (if possible - eg. gzip cannot) Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 10:38:56 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <89946-3>; Mon, 31 Jul 1995 10:36:01 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id JAA19057 for amiga-gcc-port@lists.funet.fi; Mon, 31 Jul 1995 09:34:03 +0200 From: Jochen Wiedmann Message-Id: <199507310734.JAA19057@iss1.neckar-alb.de> Subject: -fhandle-exceptions To: amiga-gcc-port@nic.funet.fi Date: Mon, 31 Jul 1995 09:34:03 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2249 Hello, Philippe and list, here are two problems, I encountered with the new libg270.lha: 1.) The libraries (libg++, libstdc++, libiostream.amust be passed to ranlib, before using them. No real problem. 2.) I tried to compile a program using exceptions. But the linker wasn't able to resolv anything: A function __unwind_function seems to be missing in libstdc++.a. (Not sure about the library, but I have noticed, that a similar function called terminate__Fv was resolved by libstdc++.) I do not have access to the libg++ sources, so I wasn't able to figure out, if this function is just missing in the distribution or if exceptions still aren't supported. (I would really like to know, how they are realized. :-) Regards, Jochen 6> gcc -v test.cc -liostream -lstdc++ -fhandle-exceptions >work:spool/gcc-bug Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -IGNUINCLUDE: -Dmc68010 test.cc /t/cc601904.ii GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: GNUINCLUDE: /gnu/lib/g++-include /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cc1plus /t/cc601904.ii -mfixedstack -mfixedstack -quiet -dumpbase test.cc -version -fhandle-exceptions -o /t/cc601904.s GNU C++ version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. as -mc68010 -o /t/cc6019041.o /t/cc601904.s ld /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 -L/local/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 -L/gnu/lib -L/local/lib -L/local/lib /t/cc6019041.o -liostream -lstdc++ -lgcc -lc -lamiga -lc -lgcc /t/cc6019041.o: Undefined symbol ___unwind_function referenced from text segment From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 11:04:33 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90590-3>; Mon, 31 Jul 1995 11:03:56 +0300 Received: by colombo.telesys-innov.fr; Sun, 30 Jul 1995 21:24:56 +0100 From: Philippe BRAND Message-Id: <199507302024.VAA10407@colombo.telesys-innov.fr> Subject: Ld with auto-stack extention is available To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Sun, 30 Jul 1995 21:24:55 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 479 I've just compiled ld using -mstackextend. It is available on both my site and on nic.funet.fi for you speedy gonzales guys :-) ftp.telesys-innov.fr:/pub/amigados-gnu/beta/ld-stack.lha and ftp.funet.fi:/pub/amiga/gnu/beta/ld-stack.lha PLEASE test it. I've just compiled it and relinked ld with it. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 11:15:14 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90194-3>; Mon, 31 Jul 1995 11:14:40 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA00271; Mon, 31 Jul 1995 10:16:27 +0200 Date: Mon, 31 Jul 1995 10:16:27 +0200 (MET DST) From: Kamil Iskra Subject: Re: GCC Install script To: Jochen Wiedmann cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199507281156.NAA17228@iss1.neckar-alb.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 28 Jul 1995, Jochen Wiedmann wrote: > > Hello, Kamil, > > > Some time ago I posted an article to amiga-gcc-port@list.funet.fi > > concerning incompatibilities between AmigaGuide v34-39 and v40 and their > > influence on GCC guides. Just to remind you: AG v40 needs '\\n' in > > ".guide" to display "\n" on the screen. I suggested running a special > > correcting program during the installation that would convert all > > occurences of "\" with "\\" in guides when "amigaguide.library" v40+ was > > found. No one answered. I think you should have something to say on this > > subject. > > As all .guide files in the gcc distribution are built from texinfo, it > would be a much better idea, to modify the "makeinfo" sources (Aminet, > mkguide1.55.lha or something like that) appropriately. And, without > doubt, it would be much easier. :-) Of course it would be, but keep in your mind that there is an incompatibility between various AmigaGuide versions. If makeinfo always outputted backslashes as "\\", v40 users would see everything correctly ('\\n' -> '\n'), but v39- users would see it incorrectly ('\\n' -> '\\n')! This is the problem, and IMHO the only way to fix it is a converter! / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 11:19:55 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90159-2>; Mon, 31 Jul 1995 11:19:31 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA00297; Mon, 31 Jul 1995 10:21:20 +0200 Date: Mon, 31 Jul 1995 10:21:20 +0200 (MET DST) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: Preliminary 2.7.0 distribution To: Gunther Nikl cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199507281708.TAA00480@honshu.informatik.uni-rostock.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Fri, 28 Jul 1995, Gunther Nikl wrote: > > > Kamil Iskra writes: > > > > > Philippe, I BEG you, transfer it to FUNET!!! I'm trying to download it > > > from your side, but it's sOOOOO slOOOOOw that I most probably won't > > > finish by Monday :-) > > Mhm, when did you try? I downloaded from colombo and it was everything > else but slow (about 1 am) I tried about 11 am. Everything NcFTP 2.0.2 could do was read a directory or small files. Keep in your mind that Germany is slightly closer to France than Poland :-). > It would be a good thing, if all utilities in /bin would become pure > (if possible - eg. gzip cannot) I agree with you. And those of them that require more stack than standard 4 KB should either increase it on startup or be compiled with stack-extension. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 11:30:04 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90332-2>; Mon, 31 Jul 1995 11:29:32 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA00367; Mon, 31 Jul 1995 10:31:15 +0200 Date: Mon, 31 Jul 1995 10:31:15 +0200 (MET DST) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: -fhandle-exceptions To: Jochen Wiedmann cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199507310734.JAA19057@iss1.neckar-alb.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Mon, 31 Jul 1995, Jochen Wiedmann wrote: > 1.) The libraries (libg++, libstdc++, libiostream.amust be passed > to ranlib, before using them. No real problem. Thanks for the information. Maybe this was not a real problem for you, but I couldn't compile anything with g++ - I don't even know what this "ranlib" is (I guess it's some kind of program to maintain linker libraries). > 2.) I tried to compile a program using exceptions. But the linker > wasn't able to resolv anything: A function __unwind_function > seems to be missing in libstdc++.a. (Not sure about the > library, but I have noticed, that a similar function called > terminate__Fv was resolved by libstdc++.) So exceptions don't work?! I was so happy when "cc1plus" accepted all those "throws" and "catches" and generated asm code for them :-) I thought that the problem was caused by the fact that I didn't have new g++ libraries. What a pity :-((((( > ld /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 > -L/local/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 -L/gnu/lib > -L/local/lib -L/local/lib /t/cc6019041.o -liostream -lstdc++ > -lgcc -lc -lamiga -lc -lgcc > /t/cc6019041.o: Undefined symbol ___unwind_function referenced from text segment Why haven't you linked with libg++.a? Maybe this function is there? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 11:39:30 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90179-1>; Mon, 31 Jul 1995 11:39:04 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA00399; Mon, 31 Jul 1995 10:40:35 +0200 Date: Mon, 31 Jul 1995 10:40:34 +0200 (MET DST) From: Kamil Iskra Subject: GCC 2.7.0 BETA To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: GCC 2.7.0 Bugs I have the following comments on the latest GCC 2.7.0 BETA release: 1. Too bad that GCC distribution is not compiled with automatic stack extension [From the last minute: thanks for new "ld", Philippe]. I thought that with 2.7.0 I won't have to remember about increasing stack in shell to something above 4KB. "GCCSTACK" env-variable does not really satisfy me. First of all, it works only with main compilers (cc1/cc1plus), while in C++ mode "cpp" needs more than 4 KB of stack and hangs the machine. Second, I am always afraid when compiling larger programs that GCC can run out of stack. 2. g++ libraries are corrupted [From the last minute: now I know why, thanks Jochen]. I tried to use earlier ones, from 2.6.3, but there was no "libstdc++.a" so linker aborted execution. I tried to compile g++ programs using directly "gcc" driver: gcc -o test test.cxx -lg++ But something strange happens. "bin/gcc" loads and nothing more - like it hanged! I have to enter something from the keyboard - only then "gcc" starts executing preprocessor, compiler and so on. But linker is called with "-lg+" option, not "-lg++" - I have to call "gcc" with "-lg+++" to get correct results. 3. "-m68020-40" still doesn't work correctly. "as" is called with "-mc68020-mc68010" option and aborts immediately. 4. README-2.7.0 contains some informations which are not really true. Main "problem" is that, according to different parts of the readme, Libnix was added either in 2.6.0 ("What was new in previous releases") or 2.6.1 ("Ixemul vs Libnix") or 2.6.3 ("Your first C program with gcc"). I corrected all references to be "2.6.1", but since I personally don't know exactly when Libnix was added, this may require farther corrections. Another problem is that README states that "020" archives need 68881, what, according to Philippe's statement made on this list, is not true. There are also some references to "Commodore-Amiga", which, as we all know, are no longer true. I removed one of them, but one still remains in "Inline-Headers" chapter. There was also a bug in "os-include/proto/exec.h". Gunther Nikl corrected in recently, but README still corresponds to old, uncorrected one. BTW: Is "stderrfix" still needed? I seem to remember that somebody said it was no longer needed in 2.7.0, and it is not included in the new archive - so maybe it shouldn't be mentioned in README? I include a patch below. It is by no means complete: I would suggest you, Philippe, to read whole README and reformat it in certain places, fix some typos etc. diff -c README-2.7.0.old README-2.7.0 *** README-2.7.0.old Fri Jul 28 15:16:09 1995 --- README-2.7.0 Sun Jul 30 16:34:34 1995 *************** *** 53,67 **** VMM40 (Public Domain Virtual memory manager) is also known to work with GCC. - OS: ! Starting from this release, 1.3 systems are not longer supported. Gcc runs fine on all other systems, starting from 2.04 up to 3.1 (40.68). - Disk Space; An installation of gcc requires the use of a hard disk. Approximately 10MB is required at present to install the compiler and utilities required to use it. In addition 3MB is required for the Commodore Developer Kit, which is required ! to be able to compile AmigaDOS specific programs. This kit is available direct ! from Commodore-Amiga. ========================== What's new in this release --- 53,66 ---- VMM40 (Public Domain Virtual memory manager) is also known to work with GCC. - OS: ! Starting from version 2.5.x, 1.3 systems are not longer supported. Gcc runs fine on all other systems, starting from 2.04 up to 3.1 (40.68). - Disk Space; An installation of gcc requires the use of a hard disk. Approximately 10MB is required at present to install the compiler and utilities required to use it. In addition 3MB is required for the Commodore Developer Kit, which is required ! to be able to compile AmigaDOS specific programs. ========================== What's new in this release *************** *** 201,207 **** details of what is required)." If you're interested in the sources required to rebuild gcc, get the ! gcc263-src.lha, which hold sources for gcc. Those archives should be stored either the same ftp site you got this binary distribution from (if they're not, tell the manager of that ftp site, as this is a requirement of the GNU Copyright LICENSE), either at ftp.gnu.ai.mit.edu:/pub/gnu, either on --- 200,206 ---- details of what is required)." If you're interested in the sources required to rebuild gcc, get the ! gcc270-src.lha, which hold sources for gcc. Those archives should be stored either the same ftp site you got this binary distribution from (if they're not, tell the manager of that ftp site, as this is a requirement of the GNU Copyright LICENSE), either at ftp.gnu.ai.mit.edu:/pub/gnu, either on *************** *** 301,311 **** gcc270-base.lha basic gcc distribution, hold necessary files. gcc270-inclib.lha headers and libraries. gcc270-c.lha C compiler. ! gcc270-c-020.lha 68020+68881 version of C compiler. gcc270-c++.lha C++ compiler, headers and libraries. ! gcc270-c++-020.lha 68020+68881 versions of C++ compiler. gcc270-objc.lha Objective-C compiler, header and libraries. ! gcc270-objc-020.lha 68020+68881 versions of Objective-C compiler. gcc270-doc.lha Gcc AmigaGuide(tm) documents & manpages. gcc270-utils.lha Useful utilities needed for development. gcc270-utilsdoc.lha Utilities documentation (guide & manpages). --- 300,310 ---- gcc270-base.lha basic gcc distribution, hold necessary files. gcc270-inclib.lha headers and libraries. gcc270-c.lha C compiler. ! gcc270-c-020.lha 68020 version of C compiler. gcc270-c++.lha C++ compiler, headers and libraries. ! gcc270-c++-020.lha 68020 versions of C++ compiler. gcc270-objc.lha Objective-C compiler, header and libraries. ! gcc270-objc-020.lha 68020 versions of Objective-C compiler. gcc270-doc.lha Gcc AmigaGuide(tm) documents & manpages. gcc270-utils.lha Useful utilities needed for development. gcc270-utilsdoc.lha Utilities documentation (guide & manpages). *************** *** 319,325 **** COPYING GNU LICENSE, read!! All archives COPYING.LIB GNU LIBRARY LICENSE, read!! All archives README-2.7.0 this file All archives ! NEWS-2.7.0 What's new in gcc-2.6.3 gcc270-base Installer Commodore installer utility gcc270-base GCC-Install Installer script to configure gcc All archives envarc/ global environment variables you should --- 318,324 ---- COPYING GNU LICENSE, read!! All archives COPYING.LIB GNU LIBRARY LICENSE, read!! All archives README-2.7.0 this file All archives ! NEWS-2.7.0 What's new in gcc-2.7.0 gcc270-base Installer Commodore installer utility gcc270-base GCC-Install Installer script to configure gcc All archives envarc/ global environment variables you should *************** *** 390,396 **** Amiga Libraries =============== ! Starting from 2.6.3 an AmigaDOS compliant library is provided, thanks to libnix authors (Matthias Fleischer and Gunther Nikl). Anyway if you want to rebuild one, there are two methods: --- 389,395 ---- Amiga Libraries =============== ! Starting from 2.6.1 an AmigaDOS compliant library is provided, thanks to libnix authors (Matthias Fleischer and Gunther Nikl). Anyway if you want to rebuild one, there are two methods: *************** *** 497,503 **** CLI> lha x gcc270-c++.lha (or gcc270-c++-020) ! Please not that 68020+68881 versions have '.020' extension in GNU:bin. - If you want to do Objective-C, unarchive Objective-C part (Users with accelerated amigas can --- 496,502 ---- CLI> lha x gcc270-c++.lha (or gcc270-c++-020) ! Please note that 68020 versions have '.020' extension in GNU:bin. - If you want to do Objective-C, unarchive Objective-C part (Users with accelerated amigas can *************** *** 600,606 **** CLI> gcc -noixemul -o foobar foobar.c ! provided you have libnix distribution (included with 2.6.3 distribution). ================ Ixemul vs Libnix --- 599,605 ---- CLI> gcc -noixemul -o foobar foobar.c ! provided you have libnix distribution (included with 2.6.1 distribution). ================ Ixemul vs Libnix *************** *** 934,944 **** (3) internal compiler specific requirements are hidden from the user For the exec.library the proto header has one additional goodie: it "implements" ! SAS/C "__USE_SYSBASE". Defining this forces to evaluate the absolute address 4 every time the library base for the exec.library is required. In this case no global library base is necessary but it must be noted that programs compiled with this option enabled can have performance problems because AbsExecBase is located ! in Chip-Memory. Be aware: if using __USE_SYSBASE its *NOT* legal to declare or define SysBase! If you do so strange things may happen ... Please note that some function in libamiga.a require a global "SysBase" so that those functions cannot be used. --- 933,943 ---- (3) internal compiler specific requirements are hidden from the user For the exec.library the proto header has one additional goodie: it "implements" ! SAS/C "_USEOLDEXEC_". Defining this forces to evaluate the absolute address 4 every time the library base for the exec.library is required. In this case no global library base is necessary but it must be noted that programs compiled with this option enabled can have performance problems because AbsExecBase is located ! in Chip-Memory. Be aware: if using _USEOLDEXEC_ its *NOT* legal to declare or define SysBase! If you do so strange things may happen ... Please note that some function in libamiga.a require a global "SysBase" so that those functions cannot be used. 5. From tools included in "bin" directory, "ixprefs" is not the latest release available - it is version 1.1, while the latest one is 1.2. I would also suggest to remove "fd2inline" from the archive, since it is so buggy that it is practically unusable - new version is being prepared by Rainer Trunz (with small help from me :-) and should be available in a few months. 6. "lib/libauto.a" and "libauto" directory are no longer included. Why? 7. There are still some bugs in includes - all of them have been reported before by various people. Particularly dangerous seems to be a bug in "math-68881.h" in pow() function, as reported by Lars Hecking on 15th June and by many other people. I reported some problems with "sys/cdefs.h", which causes warnings to be generated by g++. Here's a patch: diff -c include/sys/cdefs.h.old include/sys/cdefs.h *** include/sys/cdefs.h.old Sun Jul 30 16:18:09 1995 --- include/sys/cdefs.h Sun Jul 30 16:18:42 1995 *************** *** 52,58 **** --- 52,60 ---- * strings produced by the __STRING macro, but this only works with ANSI C. */ #if defined(__STDC__) || defined(__cplusplus) + #ifndef __P #define __P(protos) protos /* full-blown ANSI C */ + #endif /* __P */ #define __CONCAT(x,y) x ## y #define __STRING(x) #x Now I am waiting for 68020 g++ libraries, since in GCC 2.6.3 there were problems with them when displaying floats on Amiga without FPU - I would like to check if this has been fixed in 2.7.0. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 12:25:14 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90252-1>; Mon, 31 Jul 1995 12:24:50 +0300 Received: by colombo.telesys-innov.fr; Mon, 31 Jul 1995 11:25:11 +0100 From: Philippe BRAND Message-Id: <199507311025.LAA01154@colombo.telesys-innov.fr> Subject: Re: GCC 2.7.0 BETA To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Mon, 31 Jul 1995 11:25:10 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Kamil Iskra" at Jul 31, 95 10:40:34 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4108 Kamil Iskra writes: > I have the following comments on the latest GCC 2.7.0 BETA release: Thanks for this report... If I'd receive tons of them, gcc dist would only be better :-) I've saved this email into my todo dir for tonight gcc work. BTW my friend Samuel Devulder has complete port of his tool APurify to gcc. I'll integrate it tommorrow and send new 'specs' file and new gcc frontend. Goal is to add a new compiler parameter which is going to result in a new compiler pass, between cc1 and as. You can already download APurify from Aminet (Dice and SAS version), to have an idea about functionnalities... > 1. Too bad that GCC distribution is not compiled with automatic stack > extension [From the last minute: thanks for new "ld", Philippe]. I couldn't make gcc to work with -mstackextend. Seems there's yet a small work to do on this. > 2. g++ libraries are corrupted [From the last minute: now I know why, > thanks Jochen]. I tried to use earlier ones, from 2.6.3, but there was no > "libstdc++.a" so linker aborted execution. I tried to compile g++ programs > using directly "gcc" driver: I generated libg++ on my sparc system using gcc cross-compiler. Seems ranlib wasn't call, if that was your problem. I'll fix it for ditribution. > gcc -o test test.cxx -lg++ > > But something strange happens. "bin/gcc" loads and nothing more - like > it hanged! I have to enter something from the keyboard - only then > "gcc" starts executing preprocessor, compiler and so on. But linker is > called with "-lg+" option, not "-lg++" - I have to call "gcc" with > "-lg+++" to get correct results. I guess you're using standard AmigaDOs shell instead of sh, that's the reason why. AmigaDOS does interpret second '+'. > 3. "-m68020-40" still doesn't work correctly. "as" is called with > "-mc68020-mc68010" option and aborts immediately. Only a minor typo problem. I'll fix it tonight. You can always as for now edit 'specs' file. > 4. README-2.7.0 contains some informations which are not really true. Well I used mainly search-and-replace function :-) And I wrote additional stuff pretty quickly, being sure that somebody would report about problems :) > Main "problem" is that, according to different parts of the readme, Libnix > was added either in 2.6.0 ("What was new in previous releases") or 2.6.1 > ("Ixemul vs Libnix") or 2.6.3 ("Your first C program with gcc"). I > corrected all references to be "2.6.1", but since I personally don't know > exactly when Libnix was added, this may require farther corrections. Was in 2.6.0 first. I'll fix it. > Another problem is that README states that "020" archives need 68881, > what, according to Philippe's statement made on this list, is not true. Correct. I didn't generate them yet BTW :) > There are also some references to "Commodore-Amiga", which, as we all > know, are no longer true. I removed one of them, but one still remains in > "Inline-Headers" chapter. Oops :-) My friend G.Bourdin (Marketing) would surely don't like it :-) > There was also a bug in "os-include/proto/exec.h". Gunther Nikl corrected > in recently, but README still corresponds to old, uncorrected one. Ok. > BTW: Is "stderrfix" still needed? I seem to remember that somebody said it > was no longer needed in 2.7.0, and it is not included in the new archive - > so maybe it shouldn't be mentioned in README? If I recall correctly it was fixed. I'll delete paragraph. > I include a patch below. It is by no means complete: I would suggest you, > Philippe, to read whole README and reformat it in certain places, fix some > typos etc. Ok. Many thanks. > Now I am waiting for 68020 g++ libraries, since in GCC 2.6.3 there were > problems with them when displaying floats on Amiga without FPU - I would > like to check if this has been fixed in 2.7.0. I'll generate them in a few minutes and upload them on both my site and funet. Thanks for reporting. Others ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 13:08:51 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90201-1>; Mon, 31 Jul 1995 13:07:53 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 31 Jul 95 12:05 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 31 Jul 95 12:00 MET DST Message-Id: Subject: Re: Preliminary 2.7.0 distribution To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 31 Jul 1995 12:00:50 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 955 > > > > > > > Philippe, I BEG you, transfer it to FUNET!!! I'm trying to download it > > > > from your side, but it's sOOOOO slOOOOOw that I most probably won't > > > > finish by Monday :-) > > > > Mhm, when did you try? I downloaded from colombo and it was everything > > else but slow (about 1 am) > > I tried about 11 am. Everything NcFTP 2.0.2 could do was read a directory > or small files. Keep in your mind that Germany is slightly closer to > France than Poland :-). > depend where your packet goes, from here funet and tele are ~ equal. but that doesnt mean anything a simple calculation shows that hamburg is on the darkside of the moon ;(. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 13:34:34 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90057-2>; Mon, 31 Jul 1995 13:33:53 +0300 Received: by colombo.telesys-innov.fr; Mon, 31 Jul 1995 12:35:39 +0100 From: Philippe BRAND Message-Id: <199507311135.MAA01915@colombo.telesys-innov.fr> Subject: libg++ 020 soft-float version To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 31 Jul 1995 12:35:38 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 471 File libg020.lha is available on both ftp.telesys-innov.fr and nic.funet.fi As I've used cross-compiler, be sure to 'ranlib' libraries. I used "-m68020 -msoft-float' to generate them. 020 libraries won't overwrite existing one, as they'll go into gnu/lib/libm020. Please test and report asap. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 14:37:58 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90334-4>; Mon, 31 Jul 1995 14:36:44 +0300 Received: by colombo.telesys-innov.fr; Mon, 31 Jul 1995 13:34:28 +0100 From: Philippe BRAND Message-Id: <199507311234.NAA02146@colombo.telesys-innov.fr> Subject: Re: -fhandle-exceptions To: wiedmann@iss1.neckar-alb.de (Jochen Wiedmann) Date: Mon, 31 Jul 1995 13:34:27 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199507310734.JAA19057@iss1.neckar-alb.de> from "Jochen Wiedmann" at Jul 31, 95 09:34:03 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 503 Jochen Wiedmann writes: > 1.) The libraries (libg++, libstdc++, libiostream.amust be passed > to ranlib, before using them. No real problem. Yep... sorry about this. > 2.) I tried to compile a program using exceptions. But the linker Try using g++ instead of gcc. BTW do you have time to work on installer script ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 15:12:18 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <90284-4>; Mon, 31 Jul 1995 15:11:34 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id OAA04397; Mon, 31 Jul 1995 14:08:45 +0200 From: Jochen Wiedmann Message-Id: <199507311208.OAA04397@iss1.neckar-alb.de> Subject: Re: -fhandle-exceptions To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Mon, 31 Jul 1995 14:08:45 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199507311234.NAA02146@colombo.telesys-innov.fr> from "Philippe BRAND" at Jul 31, 95 01:34:27 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 603 Hello, Philippe, > > 2.) I tried to compile a program using exceptions. But the linker > > Try using g++ instead of gcc. Will this help? Sounds funny. :-) I'll give it a try this evening. > BTW do you have time to work on installer script ? What do you think is missing? (I already argued in the list, that I don't like to create a special "update" script.) There's just one thing, I currently don't know: How stack will be handled finally. (Read: If GCCSTACK will be needed or not.) Besides, the script I sent you this week does a good job. (At least noone told me the contrary. :-) Jochen From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 16:25:08 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90291-3>; Mon, 31 Jul 1995 16:24:21 +0300 Received: from bastion.nmrc.ucc.ie (actually host nmrc.ucc.ie) by funet.fi with SMTP (PP); Mon, 31 Jul 1995 16:24:16 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id OAA06906; Mon, 31 Jul 1995 14:21:08 +0100 From: Lars Hecking Message-Id: <199507311324.OAA02100@mostar.nmrc.ucc.ie> Subject: Re: Ld with auto-stack extention is available To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Mon, 31 Jul 1995 14:23:59 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199507302024.VAA10407@colombo.telesys-innov.fr> from "Philippe BRAND" at Jul 30, 95 09:24:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 528 > I've just compiled ld using -mstackextend. It is available on both > my site and on nic.funet.fi for you speedy gonzales guys :-) > > ftp.telesys-innov.fr:/pub/amigados-gnu/beta/ld-stack.lha and > ftp.funet.fi:/pub/amiga/gnu/beta/ld-stack.lha > > PLEASE test it. I've just compiled it and relinked ld with it. Seems to work fine. I managed to make miniperl (no, it doesn't work, but I'll be happy to supply config.sh ;) with 8192 bytes of stack. This crashed with the old ld. StackMon reports a stack usage of 49k. From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 16:43:24 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <90486-1>; Mon, 31 Jul 1995 16:39:33 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id PAA05969; Mon, 31 Jul 1995 15:36:28 +0200 From: Jochen Wiedmann Message-Id: <199507311336.PAA05969@iss1.neckar-alb.de> Subject: Re: -fhandle-exceptions To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Mon, 31 Jul 1995 15:36:27 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199507311316.OAA02327@colombo.telesys-innov.fr> from "Philippe BRAND" at Jul 31, 95 02:16:13 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1311 Hello, Philippe, > > Will this help? Sounds funny. :-) I'll give it a try this evening. > > g++ calls automagically -lg++ at link time :-) Be sure, that I have linked against libg++. :-) (Ok, I should have noted that.) IMO, the symbol is missing in libstdc++.a, as similar exception-related symbols were satisfied from this library. > Well I think you should have a look at instructions I put in > README-2.7.0 in case of "upgrade". > In fact upgrade is just part of global installation. But libraries > have to be move or deleted, whether user wants or not to keep previous > version. I examined it. And, in fact, I did this manually, when upgrading from 2.6.3 to the first 2.7.0 beta. However, as I already said in a previous mail, I think that a special "upgrade" option would be wasted time, because - the "upgrade" option would *only* be needed when upgrading from 2.6.3 to 2.7.0. Future releases would work fine with the existing script, so did previous releases. - People with basic gcc knowledge could well do the upgrade manually, others could be recommended to do a complete new installation anyways If you insist in an upgrade script, I'll do it. But I think it isn't important, that people without basic knowledge have two different versions available. Regards, Jochen From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 17:36:24 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90854-2>; Mon, 31 Jul 1995 17:35:19 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id PAA08346; Mon, 31 Jul 1995 15:33:17 +0100 From: Lars Hecking Message-Id: <199507311436.PAA02290@mostar.nmrc.ucc.ie> Subject: Re: -fhandle-exceptions To: wiedmann@iss1.neckar-alb.de (Jochen Wiedmann) Date: Mon, 31 Jul 1995 15:36:08 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199507311336.PAA05969@iss1.neckar-alb.de> from "Jochen Wiedmann" at Jul 31, 95 03:36:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 477 > > > Will this help? Sounds funny. :-) I'll give it a try this evening. > > > > g++ calls automagically -lg++ at link time :-) > > Be sure, that I have linked against libg++. :-) (Ok, I should have > noted that.) IMO, the symbol is missing in libstdc++.a, as similar > exception-related symbols were satisfied from this library. I found no reference to __unwind_function at all in the whole libg++ distribution or libgcc.a. Maybe you post a minimum example file? From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 19:36:34 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90191-2>; Mon, 31 Jul 1995 19:35:38 +0300 Received: by colombo.telesys-innov.fr; Mon, 31 Jul 1995 18:35:26 +0100 From: Philippe BRAND Message-Id: <199507311735.SAA02972@colombo.telesys-innov.fr> Subject: Re: -fhandle-exceptions To: wiedmann@iss1.neckar-alb.de (Jochen Wiedmann) Date: Mon, 31 Jul 1995 18:35:15 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199507311336.PAA05969@iss1.neckar-alb.de> from "Jochen Wiedmann" at Jul 31, 95 03:36:27 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 803 Jochen Wiedmann writes: > - the "upgrade" option would *only* be needed when upgrading > from 2.6.3 to 2.7.0. Future releases would work fine with > the existing script, so did previous releases. Nope. Previous libraries e.g: /gnu/lib/libgcc.a etc... as mentionned in my README MUST be either moved to previous version or deleted. > - People with basic gcc knowledge could well do the upgrade > manually, others could be recommended to do a complete > new installation anyways There gonna be a LOt of people complaining... people really like complaining so let's just not give them a reason to do it :-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 19:38:31 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90451-4>; Mon, 31 Jul 1995 19:38:00 +0300 Received: by colombo.telesys-innov.fr; Mon, 31 Jul 1995 18:39:19 +0100 From: Philippe BRAND Message-Id: <199507311739.SAA03004@colombo.telesys-innov.fr> Subject: apurify (fwd) To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 31 Jul 1995 18:39:08 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 15680 Here's a preliminary draft for Apurify. If you find bad english sentence here, feel free to report to author... :-) APurify v1.2 ------------ GCC version. (c) by Samuel DEVULDER July 1995 Samuel.Devulder@info.unicaen.fr DESCRIPTION (SHORT): -------------------- APurify is a program that allows you to detect bad accesses to memory of your programs without any kind of specific external devices (MMU). It avoids bugs due to accessing memory not owned by your program. This is a port for APurify v1.1 on Aminet/dev/debug for GCC. It may be full of bugs, so be carefull. SYNOPSIS: -------- Usage: APurify [-revinfo] [flags] [-o ] Where flags can be: -br To set the base register -tb To test memory referenced through base register -ts To test memory referenced through stack register -tl To test memory referenced through local stack frame -tp To test pea instructions -?,?,-h To display this usage Flags can be anywhere on the command line and may be concatenated together. Here is a short description of arguments and flags: -revinfo: This displays informations about APurify (name, size and date of modules and number of compilation done for that version). -br: This sets the base register used to reference memory in SMALL_DATA model. Usually A4 is used for that perpose and that's the default. -tb: This enable APurify to check all referenced memory through the base register (see -br). If you are using a SMALL_DATA model, add this flag on your command line. By default, APurify won't check memory referenced through the base register. NOTE: for safest check, you should always use that option, even if you're not in smalldata model (A4 may be used as a temporary register in that case). -ts: This enable APurify to check memory referenced by stack pointer (SP or A7). By default APurify won't check such memory accesses (to reduce the code size and increase the runtime speed). That option will detect when you have to room on your stack (stack overflow). -tl: This enable APurify to check memory referenced by local stack pointer (the one that is link'ed and unlink'ed when enterring and exiting a C-function). By default, this is switch off. This option allow APurify to detect stack overflow. -tp: This enable APurify to check indirect adresses pushed onto the stack by using a pea. By default this is off. When used, that option will check things like pea a2@(10) or the like. This can help you with memory accessed by a pointer in a code that has not been APurify'ed. For example this is usefull for things like fread(&ptr[10],10,1,fp) because in that case the pea a2@(10) used to put on the stack &ptr[10] will be checked and if ptr[10] is not owned by your program, you'll get an APurify error. Please note that this may no work all the time since &ptr[0] can be transcripted into "pea a0@" or "movel a0,sp@-" which won't be checked. -o This specifies the name of the outputfile. If ommited the outputfile will be the same as the inputfile (source file). -? -h ?: Obvious option. DESCRIPTION (A BIT LONGER): -------------------------- As a general rule, at the microprocessor level, there is two kind of ways to access memory. There is direct access and indirect access to memory. For example, in C, direct access can be viewed as accessing to global variables. Indirect access corresponds to accessing an array value. More precisely, direct access corresponds to reading or writing a variable whose address is known at compilation time (or since the loading of the program into the memory). Indirect access is used for variables whose adress is dynamicaly determined by the program. For example, if p is a pointer to an array allocated by malloc(), *p is an indirect access. Such an access occur also in case of instruction like T[i] where T is a global array, because the address of T[i] is not known at compilation time, since it depends on the index value i. Using indirect access to memory is called indirection. A regular program must not access memory not owned by it. That kind of access can be qualified as illegal. Illegal direct access to memory is not possible, because by definition, only global variables can be accessed that way and those variables belongs obviously to the program (except for code written in assembly language that references absolute values, for example: btst #6,$bfe001; but that kind of code can't be produced in C directly). So direct access to memory is always right. On the other hand, it is sure that indirect access to memory can be illegal. Many bugs are made by overstepping array boundaries. If that oversteppings are in reading a value, there is not much trouble; but if it is in writing, big mess can happen. APurify works on that kind of access by verifying the validity of indirect access to memory. It remebers the memory that was allocated by the program and check the integrity of each access. One can think that makes a lot of tests ! Well, yes, but APurify is not designed to be used in the general use of programs; just in test phases. Moreover, indirections do no occur very often actually. Only array-linked variables produces indirections. Thus, the variables on the stack ---although being accessed by indirection--- are not checked because their access is always safe (at least if there is no stack overflow !). Also, in SMALL_DATA model, global variables access is done through indirection, but they are not checked. If an illegal access is found, APurify displays an error message on the error stream of the program (have a look at the full justification of the output :^). There is two kind of illegal accesses. Some are accesses to memory that doesn't belong to the program (it is called an access between blocks), some others are accesses to a part of memory owned by a program and an other part not owned by it (it is an overstepping of a block). The memory is represented by a block. Each block is displayed according to the following pattern: [0x() ()] where is the hexadecimal address of the beginning of the block, its length, 3 status characters RWS where R means: read-enable block W means: write-enable block S means: system block (block not controlled by the program). If one access is forbidden, the letter '-' replaces the corresponding character. is actually the name of the procedure that has allocated the block. If it ends with "*" that block was allocated by a call within the one indicated to a procedure not parsed by APurify (a library call, maybe). In case of an error, APurify displays the blocks that surrounds the illegal access and the number of bytes to those blocks. It also displays a block for the accessed address. In that block, the beginning address is the faultly address, the length is the size of the access (1 for a byte access, 2 for a short, 4 for a int/long and >4 for movem instruction). Attributes are R or W wether it's a read or write access. The text-field contains the name of the procedure in which the illegal access had happened. APurify checks the memory allocated but not freed by the program. (in fact, it detects non deallocated-blocks on library-closing time). It knows about memory location independant of the program execution. That is to say, the first kilobyte of memory that contains interrupt vectors of the 680x0 processor, the program segments and the stack. Accessing to those blocks will not be illegal. They got the S attribute (for SYSTEM blocks). It takes into account memory block allocated by malloc() and AllocMem(), and indirect allocated block (by OpenScreen() for example). But I did not test the last kind of allocation. Anyway, it should be ok, because APurify patches AllocMem() & FreeMem() entries. Thus a program can access to the bitplanes of one of its screen without error. If the program makes a legal access, but attributes are incompatible with the access-kind, a protection-error message is displayed. Actually only the first kilobyte is read-write-protected. But it may change in the future. In order to speed up block searching, APurify uses a cache of recently accessed blocks. Thus, even if there is a large amount of memory blocks, execution should not be slowed down too much. (but I must say I doubt it is efficient enough). HOW TO USE APURIFY: ------------------ One can see APurify as a pre-assembler. It must be used on assembly language sourcefile just before the assembler takes place. It scan the file and change it a bit so that APur.a can be used. Normal way to use it for a C program is to: - compile C sourcefiles and leave assembly language source (.s). - use APurify on each .s file. - link all .o files together with APur.a. For example, using gcc on prog.c it gives CLI> gcc -g prog.c -o prog.s -S CLI> APurify -tb prog.s CLI> gcc -g prog.s -o prog -lAPur As you can see, APurify needs no change to your C files to be used. However, the library must be opened by calling AP_Init() in the main() function and, *VERY IMPORTANT*, closed before exiting the program by calling AP_Close() (just before every exit() func-call, for example). As a matter of fact, since some system functions are patched, if a program exits without closing the library, you'll meet the guru (ie: the computer will crash)... (You've been warned :-). The easiest way to do this is to use atexit() (for example, by calling atexit(AP_Close) just after calling AP_Init()). If you forget to open the library, a warning message will tell you about that and the program will go on without APurify. You can disable/enable printing of messages by making a call to AP_Report(flag). If flag is true then printing is enabled, if it is false, no output will be done. This is usefull for startup-codes. For example, if you are using the argv[] array in C, APurify will make a lot of false-error printing. This is because the values pointed by this array is allocated before the library is opened. You can avoid this by calling AP_Report(0) before, and AP_Report(1) after, the code that uses argv[]. When debugging an APurify'ed program, you can put a breakpoint on a function called AP_Err(). That function AP_Err() is called each time APurify detects an error. With that, you'll have the occasion to look at your program just before a faultly memory-access occur. You can use APurify on any language that generates a temporary assembly language sourcefile (included assembly itself :-) ). You must notice too, that you can use it on programs for which no source-code is available (or .o files without .asm files). For that, use a program that makes reverse engineering on your executable (ie: that disassembles the executable and produces a .asm file ready to be assembled). Then, with minor changes (prepend '_' to every label, put calls AP_Init & AP_Close to right places), you get a file ready to be processed by APurify. LEGAL PART: ---------- That program is provided 'AS IS'. I am not responsible for any dammage it can cause (but I am responsible for the benefits it can give to you :-). Use that software at you own risks. That program is FREEWARE. You can use and distribute it as long as you keep the archive intact (no adulteration of files except for compression). It can't be sold without my agreement (except a minimal amount for media support). You must ask me for commercial use of (any part of) that product. I keep all my rights on that program and its future releases. I can modify that software without telling it to the users. If you wish, you can send me a postcard or anything else you want (money, documentation, amiga, hardware stuff, ...) in exchange for using APurify. But there is no obligation :-). My postal address is: M. DEVULDER Samuel 1, Rue du chateau 59380 STEENE FRANCE (yes I'm french !). You can send suggestions or bugs to my email address: devulder@info.unicaen.fr DISTRIBUTION: ------------ That archive contains the english version of APurify: - doc/APurify.doc: The file you are currently reading. - bin/APurify: The parser. - lib/APur.a: The link-time library. - test/test.c: Source of a stupid test file - test/test: Test file Apurify'ed. NOTES: ----- My configuration is: one old A500 (1989), 1Mo RAM, 1 diskdrive, KS1.3 and a lot of patience (ah, I wish I had an A4000/040/33Mhz !). It has been compiled with cross-gcc 2.7.0 with libnix on a Sun sparc. I had the idea of that program after a chat with Cedric BEUST (AMIGA NEWS) on IRC (Internet Relay Chat). Thanks Cedric ! I wish to thank Philippe Brand for his help in my port. He was really patient, even when I was really annoying (:-)). Thank you PHB ! All marks are proprietary of their respective owners. There are some programs like APurify. For example, FORTIFY (Simon P. Bullen), but it only detects illegal writes to boundaries of allocated blocks. Thus it can't detect big oversteps and oversteps in reading and the detection is not real-time. Enforcer can detect illegal access to memory (I think), but it needs a special device (MMU). HINTS & TIPS: ------------ You can see some memory leaks with that version of APurify. It is not really good but it can help. Memory leak occur when a block of memory is nomore pointed by your program. Those memory blocks will necessary be displayed when your program exit()s. So with all the messages printed on that occasion, you can find such blocks. I known this is not so great, but I think it can help you a little bit (maybe in a future version I'll build some code to really check memory leaks). BUGS: ---- APurify don't known public memory where a program can read or write without having allocated it. Thus, it will report an error when a program reads or writes values in a message obtained through GetMsg() calls. It can display messages about closing the library without freeing some memory blocks. This is due to printf() that allocates memory that is free'd on exit. This is not a real bug, but you can avoid this by doing a AP_Report(0) just before exiting. But you must notice that it is better to display false bugs than to not display real ones. I've re-wrote malloc()/realloc()/free(). I hope this will not produce any bugs. Certainly more bugs, but I'm waiting for your bug-reports. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 20:08:37 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90361-2>; Mon, 31 Jul 1995 20:08:04 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id SAA11922 for ; Mon, 31 Jul 1995 18:06:43 +0100 From: Lars Hecking Message-Id: <199507311709.SAA02562@mostar.nmrc.ucc.ie> Subject: gcc-2.7.0 -resident bug To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Mon, 31 Jul 1995 18:09:35 +0100 (BST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 918 Compiling m4-1.4 with gccv -pipe -O2 -m68020 -resident. The resulting executable is 65356 bytes. m4 --version (--help, any other option) does not produce any output! Omitting the -resident option: executable size 69116 bytes, works as expected. For invalid options, the output is the same for the resident and non- resident executable. The same behaviour can be observed for text- and fileutils, but _not for findutils, diffutils, grep, flex, gawk, gzip. It is independent of gcc/gccv and -m68020. Ixemul version is 41.1. It does not happen for a simple hello world program either. Can anybody give me a hint how to track this down? Why is the -resident executable so much smaller? Is the involved incarnation of libc.a the culprit (I have no lib/libb/libm020/libc.a; I assume lib/libb/libc.a is being used in this case)? Why are only some GNU programs affected? Why do I ask so many questions? ;)) From amiga-gcc-port-owner@nic.funet.fi Mon Jul 31 22:57:43 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90372-3>; Mon, 31 Jul 1995 22:56:35 +0300 Received: from iss1.neckar-alb.de by funet.fi with SMTP (PP); Mon, 31 Jul 1995 22:55:50 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id VAA12048 for amiga-gcc-port@lists.funet.fi; Mon, 31 Jul 1995 21:48:32 +0200 From: Jochen Wiedmann Message-Id: <199507311948.VAA12048@iss1.neckar-alb.de> Subject: Re: -fhandle-exceptions To: amiga-gcc-port@nic.funet.fi Date: Mon, 31 Jul 1995 21:48:32 +0200 (MET DST) In-Reply-To: <199507311735.SAA02972@colombo.telesys-innov.fr> from "Philippe BRAND" at Jul 31, 95 06:35:15 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6222 Here's a test program, that shows the problem. You'll notice, that the missing function (__unwind_function) is needed in the exception code itself. That's why Lars didn't find a reference. #!/bin/sh # This is a shell archive (produced by GNU sharutils 4.1). # To extract the files from this archive, save it to some FILE, remove # everything before the `!/bin/sh' line above, then type `sh FILE'. # # Made on 1995-07-31 21:37 MET DST by . # Source directory was `/export/home/user/wiedmann'. # # Existing files will *not* be overwritten unless `-c' is specified. # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 598 -rw-rw-r-- test.cc # 3399 -rw-rw-r-- test.a # touch -am 1231235999 $$.touch >/dev/null 2>&1 if test ! -f 1231235999 && test -f $$.touch; then shar_touch=touch else shar_touch=: echo echo 'WARNING: not restoring timestamps. Consider getting and' echo "installing GNU \`touch', distributed in GNU File Utilities..." echo fi rm -f 1231235999 $$.touch # # ============= test.cc ============== if test -f 'test.cc' && test X"$1" != X"-c"; then echo 'x - skipping test.cc (file already exists)' else echo 'x - extracting test.cc (text)' sed 's/^X//' << 'SHAR_EOF' > 'test.cc' && extern "C" { #include #include } X #include #include X X typedef const char* const Error; X struct Buffer { X char buf[4096]; }; X const Error MemoryError = "Out of memory"; X X void* operator new(size_t s) { X void* m; X X if (!(m = malloc(s))) { X throw MemoryError; X } X return m; } X X X int main(int argc, char* argv[]) X { X int i = 0; X char buffer[20]; X X for (;;) { X ++i; X cout << "Creating string node " << i << '\n'; X X sprintf(buffer, "%d", i); X X try { X Buffer* b = new Buffer(); X } X catch (Error e) { X cout << e << '\n'; X } X } } SHAR_EOF $shar_touch -am 0731213795 'test.cc' && chmod 0664 'test.cc' || echo 'restore of test.cc failed' shar_count="`wc -c < 'test.cc'`" test 598 -eq "$shar_count" || echo "test.cc: original size 598, current size $shar_count" fi # ============= test.a ============== if test -f 'test.a' && test X"$1" != X"-c"; then echo 'x - skipping test.a (file already exists)' else echo 'x - extracting test.a (text)' sed 's/^X//' << 'SHAR_EOF' > 'test.a' && X far code X far data ;#NO_APP gcc2_compiled.: ___gnu_compiled_cplusplus: X cseg LC0: X dc.b 80,67,99,0 LC1: X dc.b 79,117,116,32,111,102,32,109,101,109,111,114,121 X dc.b 0 X even X xdef ___builtin_new ___builtin_new: X link a5,#-4 X movem.l a2-a4,-(sp) X move.l (8,a5),-(sp) X jsr _malloc X addq.w #4,sp X move.l d0,(-4,a5) X move.l (-4,a5),d0 X tst.l d0 X bne L385 L386: X pea (4).w X jsr ___builtin_new X addq.w #4,sp X move.l d0,a0 X move.l #LC1,(a0) X move.l a0,a4 X lea LC0,a3 X move.l #L386,a2 X bra L1 L385: X move.l (-4,a5),d0 X bra L384 X bra L384 L384: X bra L387 L1: X move.l a2,-(sp) X jsr ___find_first_exception_table_match X addq.w #4,sp X move.l d0,d1 X tst.l d0 X beq L388 X move.l d0,a0 X jmp (a0) L388: X move.l (4,a5),a0 X cmp.w #0,a0 X beq L389 X lea (-1,a0),a2 X move.l (4,a5),d0 X move.l #L1,-(sp) X jsr ___unwind_function X addq.w #4,sp X bra L1 L389: X jsr _terminate__Fv L387: X movem.l (-16,a5),a2-a4 X unlk a5 X rts LC2: X dc.b 67,114,101,97,116,105,110,103,32,115,116,114,105 X dc.b 110,103,32,110,111,100,101,32,0 LC3: X dc.b 37,100,0 LC4: X dc.b 67,80,67,99,0 X even X xdef _main _main: X link a5,#-32 X movem.l d2-d5/a2-a4,-(sp) X jsr ___main X clr.l (-4,a5) L393: X addq.l #1,(-4,a5) X pea (10).w X move.l (-4,a5),-(sp) X pea LC2 X pea _cout X jsr ___ls__7ostreamPCc X addq.w #8,sp X move.l d0,d5 X move.l d5,-(sp) X jsr ___ls__7ostreami X addq.w #8,sp X move.l d0,d4 X move.l d4,-(sp) X jsr ___ls__7ostreamc X addq.w #8,sp X move.l (-4,a5),-(sp) X pea LC3 X lea (-24,a5),a0 X move.l a0,-(sp) X jsr _sprintf X add.w #12,sp L396: X pea (4096).w X jsr ___builtin_new X addq.w #4,sp X move.l d0,(-28,a5) L397: L399: L395: X bra L393 L394: X moveq #0,d0 X bra L392 X bra L392 L392: X bra L406 X nop L398: X bra L400 L401: X move.l #L401,a2 X bra L1 L402: X jsr _terminate__Fv L400: X move.l a4,-(sp) X move.l a3,-(sp) X pea LC4 X jsr ___throw_type_match X add.w #12,sp X move.l d0,d1 X tst.l d0 X beq L403 X move.l d1,a0 X move.l (a0),d3 X move.l d3,(-32,a5) L404: X pea (10).w X move.l (-32,a5),-(sp) X pea _cout X jsr ___ls__7ostreamPCc X addq.w #8,sp X move.l d0,d2 X move.l d2,-(sp) X jsr ___ls__7ostreamc X addq.w #8,sp X bra L399 L405: X move.l #L399,a2 X bra L1 L403: X move.l #L399,a2 X bra L1 L406: X movem.l (-60,a5),d2-d5/a2-a4 X unlk a5 X rts X even X xdef __GLOBAL_$I$__builtin_new __GLOBAL_$I$__builtin_new: X link a5,#0 X move.l a4,-(sp) X move.l a3,-(sp) X pea ___EXCEPTION_TABLE__ X jsr ___register_exceptions X addq.w #4,sp L407: X bra L408 L408: X move.l (-8,a5),a3 X move.l (-4,a5),a4 X unlk a5 X rts X ;ERROR: parse error parse error, can't convert -> "___CTOR_LIST__",22,0,0,__GLOBAL_$I$__builtin_new <- X even ___EXCEPTION_TABLE__: X dc.l 0 X dc.l 0 X dc.l 0 X X dc.l L396 X dc.l L397 X dc.l L398 X X dc.l L398 X dc.l L401 X dc.l L402 X X dc.l L404 X dc.l L403 X dc.l L405 X ___EXCEPTION_END__: X dc.l -1 X dc.l -1 X dc.l -1 X X even _MemoryError: X dc.l LC1 X ;Global: X xref ___CTOR_LIST__ X xref ___find_first_exception_table_match X xref ___ls__7ostreamPCc X xref ___ls__7ostreamc X xref ___ls__7ostreami X xref ___main X xref ___register_exceptions X xref ___throw_type_match X xref ___unwind_function X xref _cout X xref _malloc X xref _sprintf X xref _terminate__Fv ;Local L1 L384 L385 L386 L387 L388 ;Local L389 L392 L393 L394 L395 L396 ;Local L397 L398 L399 L400 L401 L402 ;Local L403 L404 L405 L406 L407 L408 ;Local LC0 LC1 LC2 LC3 LC4 _MemoryError ;Local __GLOBAL_$I$__builtin_new ___EXCEPTION_END__ ___EXCEPTION_TABLE__ ___builtin_new ___gnu_compiled_cplusplus _main ;Local gcc2_compiled. ;ERRORS: 1 SHAR_EOF $shar_touch -am 0731213795 'test.a' && chmod 0664 'test.a' || echo 'restore of test.a failed' shar_count="`wc -c < 'test.a'`" test 3399 -eq "$shar_count" || echo "test.a: original size 3399, current size $shar_count" fi exit 0 From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 00:06:09 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90884-1>; Tue, 1 Aug 1995 00:05:46 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id WAA14405; Mon, 31 Jul 1995 22:04:07 +0100 From: Lars Hecking Message-Id: <199507312106.WAA02928@mostar.nmrc.ucc.ie> Subject: Re: -fhandle-exceptions To: wiedmann@iss1.neckar-alb.de (Jochen Wiedmann), phb@colombo.telesys-innov.fr (Philippe Brand) Date: Mon, 31 Jul 1995 22:06:58 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199507311948.VAA12048@iss1.neckar-alb.de> from "Jochen Wiedmann" at Jul 31, 95 09:48:32 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 685 > Here's a test program, that shows the problem. You'll notice, that the > missing function (__unwind_function) is needed in the exception code > itself. That's why Lars didn't find a reference. Compiles fine on the SPARC. Trouble is, I couldn't find any documentation about gcc's exception handling. I only recall that before 2.7.0, exception handling was quite incomplete. I'll have a look into the sources ... Philippe: there's a "feature" in the argument line passed to cc1plus: /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cc1plus /t/cc601904.ii -mfixedstack -mfixedstack -quiet -dumpbase test.cc -version Do you think think this will fix the stack even more? ;)) From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 01:56:48 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89493-1>; Tue, 1 Aug 1995 01:56:07 +0300 Received: by colombo.telesys-innov.fr; Tue, 1 Aug 1995 00:56:59 +0100 From: Philippe BRAND Message-Id: <199507312356.AAA00569@colombo.telesys-innov.fr> Subject: Re: GCC 2.7.0 BETA To: kiskra@ernie.icslab.agh.edu.pl Date: Tue, 1 Aug 1995 00:56:58 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 528 Sorry, didn't saw at first glance points 5, 6 and 7 in your email... > 5. Wrong ixpref 1.2 is now in gnu:bin > 6. libauto I've just generated 68000 and 020+soft-float versions. > 7. bugs in includes I'd still need a complete math-6881.h with EVERY changes that were made. I just patched cdefs.h. Change should be also made in ixemul headers. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 02:07:17 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <88966-2>; Tue, 1 Aug 1995 02:06:01 +0300 Received: by colombo.telesys-innov.fr; Tue, 1 Aug 1995 01:07:25 +0100 From: Philippe BRAND Message-Id: <199508010007.BAA00602@colombo.telesys-innov.fr> Subject: Include patches To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Tue, 1 Aug 1995 01:07:24 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 368 Just found Lars email from 15 JHun 1995 13:42:30 about headers. Still don't know why this one was in my SYS: partition :-) I patched includes (dirent.h, math-68881.h, paths.h and unistd.h). -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 10:12:06 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90505-4>; Tue, 1 Aug 1995 10:10:53 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA19801 (5.65b/CWI-3.3); Tue, 1 Aug 1995 09:10:25 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sdAXw-000Fc2C; Tue, 1 Aug 95 08:11 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <08k9@wyst.hobby.nl>; Tue, 1 Aug 95 08:10:14 CET Message-Id: <9508010710.08k9@wyst.hobby.nl> Date: Tue, 1 Aug 1995 08:10:12 +0000 (CET) In-Reply-To: <199507311709.SAA02562@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jul 31, 95 06:09:35 pm Content-Type: text Content-Length: 2206 From: hans@wyst.hobby.nl (Hans Verkuil) To: lhecking@nmrc.ucc.ie Cc: amiga-gcc-port@nic.funet.fi Subject: Re: gcc-2.7.0 -resident bug According to Lars Hecking: > Compiling m4-1.4 with gccv -pipe -O2 -m68020 -resident. The resulting > executable is 65356 bytes. m4 --version (--help, any other option) does > not produce any output! > Omitting the -resident option: executable size 69116 bytes, works as > expected. > For invalid options, the output is the same for the resident and non- > resident executable. > The same behaviour can be observed for text- and fileutils, but _not > for findutils, diffutils, grep, flex, gawk, gzip. It is independent > of gcc/gccv and -m68020. Ixemul version is 41.1. > It does not happen for a simple hello world program either. > > Can anybody give me a hint how to track this down? const. Don't use const: try compiling with '-resident -Dconst='. I had stumbled across other problems with const earlier (your sed problem), but I've found out that the problem is much more basic than I thought and to really fix it will require a change to gcc :-(. Currently pointers to variables in the data hunk are placed in the text hunk if they are declared const. But in that case they are relocated only once, while the data hunk is copied and relocated every time you use the program, so the pointer points to an old data hunk. gcc needs to be changed so that, when compiling with -resident, all variables are placed in the data hunk, regardless of their 'const'-ness. > Why is the -resident executable so much smaller? No idea. I get (-O -resident -Dconst=) 78972 bytes. > Is the involved incarnation of libc.a the > culprit (I have no lib/libb/libm020/libc.a; I assume lib/libb/libc.a is > being used in this case)? Did you recompile the libraries with ixemul-41.1? Nevertheless, it is unlikely that they are the problem. > Why are only some GNU programs affected? Not all programs use const in this particular way. > Why do I ask so many questions? ;)) Beats me! :-) Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 10:32:04 1995 Received: from beta.mdy.univie.ac.at ([131.130.40.4]) by nic.funet.fi with SMTP id <90341-2>; Tue, 1 Aug 1995 10:31:33 +0300 Received: by beta.mdy.univie.ac.at (1.38.193.4/16.2) id AA27946; Tue, 1 Aug 1995 09:30:50 +0200 From: Alfred Minarik Subject: Re: -fhandle-exceptions To: amiga-gcc-port@nic.funet.fi Date: Tue, 1 Aug 95 9:30:49 MESZ Mailer: Elm [revision: 70.85] Message-Id: <95Aug1.103133+0300_eet_dst.90341-2+47@nic.funet.fi> > 2.) I tried to compile a program using exceptions. But the linker > wasn't able to resolv anything: A function __unwind_function > seems to be missing in libstdc++.a. As far as I know, this function has to be written new for every system. Some assembler lines to unwind the stack. (Function: setting back the stack frame to calling functions while calling the destructors of the so removed (automatic storage type) classes until a exeption handler is found). No idea how to programm this. e.g. you have to monitor the new stack extension option. From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 13:43:38 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89624-1>; Tue, 1 Aug 1995 13:39:53 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug1.133953+0300_eet_dst.89624-1+47@nic.funet.fi> From: To: Date: Tue, 1 Aug 1995 13:39:45 +0300 Date: Tue, 1 Aug 1995 12:38:45 +0200 (METDST) From: Rask Lambertsen To: Philippe BRAND Cc: Kamil Iskra , Amiga-Gcc Liste Subject: Re: GCC 2.7.0 BETA In-Reply-To: <199507311025.LAA01154@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 31 Jul 1995, Philippe BRAND wrote: > Kamil Iskra writes: > > > gcc -o test test.cxx -lg++ > > > > But something strange happens. "bin/gcc" loads and nothing more - like > > it hanged! I have to enter something from the keyboard - only then > > "gcc" starts executing preprocessor, compiler and so on. But linker is > > called with "-lg+" option, not "-lg++" - I have to call "gcc" with > > "-lg+++" to get correct results. > > I guess you're using standard AmigaDOs shell instead of sh, that's the > reason why. AmigaDOS does interpret second '+'. Actually, it expects you to continue the command line on the next line - putting a space behind the '+' seems to help. > > There are also some references to "Commodore-Amiga", which, as we all > > know, are no longer true. I removed one of them, but one still remains in > > "Inline-Headers" chapter. > > Oops :-) My friend G.Bourdin (Marketing) would surely don't like it :-) We should also consider changing some directory names, like mc680x0-cbm-amigados to mc680x0-amiga-amigados or mc680x0-escom-amigados And maybe change 'amigados' to 'amigaos'? On my machine, 'cc1' sometimes fail to load because of memory fragmentation, but 'gcc' gives no error message - this means that I have to watch the hard disk LED to see if it loads. Couldn't something be done about this? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 13:51:59 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89049-1>; Tue, 1 Aug 1995 13:48:54 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug1.134854+0300_eet_dst.89049-1+49@nic.funet.fi> From: To: Date: Tue, 1 Aug 1995 13:48:48 +0300 Date: Tue, 1 Aug 1995 12:47:47 +0200 (METDST) From: Rask Lambertsen To: Lars Hecking Cc: Amiga GCC List Subject: Re: gcc-2.7.0 -resident bug In-Reply-To: <199507311709.SAA02562@mostar.nmrc.ucc.ie> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 31 Jul 1995, Lars Hecking wrote: > > Compiling m4-1.4 with gccv -pipe -O2 -m68020 -resident. The resulting > executable is 65356 bytes. m4 --version (--help, any other option) does > not produce any output! > Omitting the -resident option: executable size 69116 bytes, works as > expected. (snip) > Can anybody give me a hint how to track this down? Why is the -resident > executable so much smaller? Is the involved incarnation of libc.a the There could be two reasons: 1) Something is missing in the -resident version - mayby that is why i doesn't work? 2) -resident also turns on -baserel, so all memory references that used to be 32-bit absolute will be 16-bit relative, thus saving 12 bytes for each reference (2 bytes for shorter instruction + 10 bytes for missing RELOC_32 hunk entry). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 14:03:07 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89036-3>; Tue, 1 Aug 1995 14:00:04 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA22761; Tue, 1 Aug 1995 11:57:59 +0100 From: Lars Hecking Message-Id: <199508011100.MAA03416@mostar.nmrc.ucc.ie> Subject: Re: Include patches To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Tue, 1 Aug 1995 12:00:51 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199508010007.BAA00602@colombo.telesys-innov.fr> from "Philippe BRAND" at Aug 1, 95 01:07:24 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 387 > Just found Lars email from 15 JHun 1995 13:42:30 about headers. Still don't > know why this one was in my SYS: partition :-) Watch out! If your SYS: holds also playing cards, fishbones, champagne glasses and dice, you're in serious trouble ... > I patched includes (dirent.h, math-68881.h, paths.h and unistd.h). Please consider also Peter Ivimey-Cook's response to that post. From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 15:49:21 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <89114-3>; Tue, 1 Aug 1995 15:48:27 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id OAA09646 (8.6.10/2.4); Tue, 1 Aug 1995 14:48:24 +0200 Date: Tue, 1 Aug 1995 14:48:24 +0200 From: Olaf Seibert Message-Id: <199508011248.OAA09646@septimius.mbfys.kun.nl> To: hans@wyst.hobby.nl, lhecking@nmrc.ucc.ie Subject: Re: gcc-2.7.0 -resident bug Cc: amiga-gcc-port@nic.funet.fi hans@wyst.hobby.nl (Hans Verkuil) wrote: > const. Don't use const: try compiling with '-resident -Dconst='. I had > stumbled across other problems with const earlier (your sed problem), but > I've found out that the problem is much more basic than I thought and to > really fix it will require a change to gcc :-(. Currently pointers to > variables in the data hunk are placed in the text hunk if they are declared > const. But in that case they are relocated only once, while the data hunk > is copied and relocated every time you use the program, so the pointer > points to an old data hunk. gcc needs to be changed so that, when compiling > with -resident, all variables are placed in the data hunk, regardless of > their 'const'-ness. This is neeed only if they are pointers, I think. And why one would use constant pointers... I guess that doesn't happen very often. char *const constant_pointer_to_char; Pointer to constant data is used more, I guess: const char *pointer_to_constant_char; -Olaf. -- Have you indecently fucked this Exon idiot and his allies today? ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 16:00:46 1995 Received: by nic.funet.fi id <89149-1>; Tue, 1 Aug 1995 16:00:08 +0300 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <95Aug1.160008+0300_eet_dst.89149-1+55@nic.funet.fi> Date: Tue, 1 Aug 1995 16:00:02 +0300 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 16:04:40 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <89039-2>; Tue, 1 Aug 1995 16:04:24 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id PAA09690 (8.6.10/2.4); Tue, 1 Aug 1995 15:04:29 +0200 Date: Tue, 1 Aug 1995 15:04:29 +0200 From: Olaf Seibert Message-Id: <199508011304.PAA09690@septimius.mbfys.kun.nl> To: hoehle@inf-wiss.uni-konstanz.de, rhialto@mbfys.kun.nl Subject: Re: cp crashes with ixemul 41.x Cc: amiga-gcc-port@nic.funet.fi Joerg Hoehle wrote: > you wrote: > > was sufficient (or at least it didn't crash). (I haven't checked how > > much it actually used in this case.) > That's not a good enough test, maybe the other library didn't allocate > sensible memory in an area that got overwritten. You should really have > looked at the stack size. Now that I've done that, it seems both versions use about the same amount of stack. So I'm looking like the boy who cried WOLF now... I guess it was the first time I used cp since I installed gcc 2.6.3 (I normally use the AmigaDOS commands) and the 2.6.3 initialisation script does not increase the stack as my 2.5.7 initialisation script used to do. And since I just installed ixemul 41.x I blamed it on that. -Olaf. -- Have you indecently fucked this Exon idiot and his allies today? ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 16:32:07 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89824-1>; Tue, 1 Aug 1995 16:31:08 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug1.163108+0300_eet_dst.89824-1+58@nic.funet.fi> From: To: Date: Tue, 1 Aug 1995 16:31:03 +0300 Date: Tue, 1 Aug 1995 15:30:07 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Buggy startup/exit code Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/REPORT; REPORT-TYPE=delivery-status; BOUNDARY="A4842.807283431=_/nic.funet.fi" Content-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --A4842.807283431=_/nic.funet.fi Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: I have some problems with gcc 2.6.3. Recently, I installed the new ixemul and since then, I have not been able to make a working program using ixemul. The problem seems to be the first instruction in the startup code, either it is junk or it is a 68020+ instruction (of cource, i forgot my disassembly at home). My second problem seems to be with libnix. I have ported/compiled wusage 3.2 using -noixemul, which works fine, but the program crashed after the final return() from main(), so it seems to be the exit code of libnix that is the cause. Is there some startup/exit code that is known to work with a 68000? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ --A4842.807283431=_/nic.funet.fi-- From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 16:48:26 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89039-2>; Tue, 1 Aug 1995 16:46:52 +0300 Received: by ceylon.informatik.uni-rostock.de id PAA17748; Tue, 1 Aug 1995 15:46:31 +0200 Received: by honshu.informatik.uni-rostock.de id PAA07683; Tue, 1 Aug 1995 15:46:31 +0200 From: Gunther Nikl Message-Id: <199508011346.PAA07683@honshu.informatik.uni-rostock.de> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Tue, 1 Aug 1995 15:46:30 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95Aug1.163108+0300_eet_dst.89824-1+58@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 1, 95 04:31:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 878 > From: Rask Lambertsen > > I have some problems with gcc 2.6.3. Recently, I installed the new ixemul > and since then, I have not been able to make a working program using > ixemul. The problem seems to be the first instruction in the startup > code, either it is junk or it is a 68020+ instruction (of cource, i > forgot my disassembly at home). Yep, the first instruction is a 020+ instruction by accident (broken assembler). Get the newest ixemul release, it has fixed *crt0.o. > My second problem seems to be with libnix. I have ported/compiled wusage 3.2 > using -noixemul, which works fine, but the program crashed after the > final return() from main(), so it seems to be the exit code of libnix > that is the cause. I had no trouble with this startup-code so far. Did you use a debugger? Maybe you trashed memory? Gunther From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 16:51:55 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89773-4>; Tue, 1 Aug 1995 16:50:46 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug1.165046+0300_eet_dst.89773-4+58@nic.funet.fi> From: To: Date: Tue, 1 Aug 1995 16:50:45 +0300 Date: Tue, 1 Aug 1995 15:49:38 +0200 (METDST) From: Rask Lambertsen To: Gunther Nikl Cc: Amiga-Gcc Liste Subject: Re: Buggy startup/exit code In-Reply-To: <199508011346.PAA07683@honshu.informatik.uni-rostock.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Aug 1995, Gunther Nikl wrote: > > > From: Rask Lambertsen (snip) > > My second problem seems to be with libnix. I have ported/compiled wusage 3.2 > > using -noixemul, which works fine, but the program crashed after the > > final return() from main(), so it seems to be the exit code of libnix > > that is the cause. > > I had no trouble with this startup-code so far. Did you use a debugger? No. > Maybe you trashed memory? I don't know. I just tried to port the thing. What is most likely to cause the problem (guru 8000 0003)? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 17:02:40 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89149-1>; Tue, 1 Aug 1995 17:01:01 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug1.170101+0300_eet_dst.89149-1+59@nic.funet.fi> From: To: Date: Tue, 1 Aug 1995 17:00:57 +0300 Date: Tue, 1 Aug 1995 15:59:52 +0200 (METDST) From: Rask Lambertsen To: Gunther Nikl Cc: Amiga-Gcc Liste Subject: Re: your mail In-Reply-To: <199508011346.PAA07683@honshu.informatik.uni-rostock.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Aug 1995, Gunther Nikl wrote: > assembler). Get the newest ixemul release, it has fixed *crt0.o. Where? A URL would be nice. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 19:11:20 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88934-2>; Tue, 1 Aug 1995 19:10:15 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sdJt0-0004nZC; Tue, 1 Aug 95 09:09 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Tue, 1 Aug 1995 09:09:41 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Aug1.133953+0300_eet_dst.89624-1+47@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 1, 95 01:39:45 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 865 > We should also consider changing some directory names, like > > mc680x0-cbm-amigados > > to > > mc680x0-amiga-amigados or mc680x0-escom-amigados A more standard configuration name would be "m680x0-unknown-amigados" since we really don't care much at all about the manufacturer of the machine that the Amiga operating system is running on. If we did, then something like "escom", "draco", or "cei" would be appropriate for the middle field. > And maybe change 'amigados' to 'amigaos'? I see no particular advantage to changing at this point. > On my machine, 'cc1' sometimes fail to load because of memory > fragmentation, but 'gcc' gives no error message - this means that I have > to watch the hard disk LED to see if it loads. Couldn't something be done > about this? Agreed, this should eventually be fixed. It bites people too many times. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 19:17:49 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89190-4>; Tue, 1 Aug 1995 19:17:17 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26622-1>; Tue, 1 Aug 1995 18:16:52 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209167-2>; Tue, 1 Aug 1995 18:16:38 +0100 Subject: Re: your mail From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Tue, 1 Aug 1995 18:16:32 +0200 (MESZ) In-Reply-To: from "Fred Fish" at Aug 1, 95 09:09:41 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 987 Message-Id: <95Aug1.181638+0100mesz.209167-2+1001@hphalle0.informatik.tu-muenchen.de> > > And maybe change 'amigados' to 'amigaos'? > > I see no particular advantage to changing at this point. Well, "DOS" is short for "disk operating system", "OS" is short for "operating system". Since AmigaOS is more than just "DOS", it seems reasonable to call it "AmigaOS". Short: AmigaDOS is just one part of AmigaOS. > > On my machine, 'cc1' sometimes fail to load because of memory > > fragmentation, but 'gcc' gives no error message - this means that I have > > to watch the hard disk LED to see if it loads. Couldn't something be done > > about this? > > Agreed, this should eventually be fixed. It bites people too many times. Well, it fails with a returncode of 1, so the error indication _is_ there. > -Fred Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 19:18:08 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <89668-1>; Tue, 1 Aug 1995 19:17:25 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189779>; Tue, 1 Aug 1995 18:16:05 +0200 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA25205; Tue, 1 Aug 1995 18:14:09 +0200 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9508011614.AA25205@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: gcc-2.7.0 -resident bug To: hans@wyst.hobby.nl (Hans Verkuil) Date: Tue, 1 Aug 1995 18:14:09 +0200 Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9508010710.08k9@wyst.hobby.nl> from "Hans Verkuil" at Aug 1, 95 08:10:12 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 310 > > Why is the -resident executable so much smaller? > > No idea. I get (-O -resident -Dconst=) 78972 bytes. > Because absolute addressing needs four bytes, the relative counterparts only two. Am I wrong ? BTW., rel. addr. is much quicker. One should use this as default. Just an Idea..:) Thomas From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 19:31:53 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89346-1>; Tue, 1 Aug 1995 19:31:14 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26607-2>; Tue, 1 Aug 1995 18:30:47 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209198-2>; Tue, 1 Aug 1995 18:30:27 +0100 Subject: Re: gcc-2.7.0 -resident bug From: Christian Stieber To: thradtke@nereid.rz.uni-osnabrueck.de (Thomas Radtke) Date: Tue, 1 Aug 1995 18:30:25 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9508011614.AA25205@nereid.rz.Uni-Osnabrueck.DE> from "Thomas Radtke" at Aug 1, 95 06:14:09 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 885 Message-Id: <95Aug1.183027+0100mesz.209198-2+1004@hphalle0.informatik.tu-muenchen.de> > > > > Why is the -resident executable so much smaller? > > > > No idea. I get (-O -resident -Dconst=) 78972 bytes. > > > Because absolute addressing needs four bytes, the relative > counterparts only two. Am I wrong ? BTW., rel. addr. is much > quicker. One should use this as default. Just an Idea..:) However, there are some more points: - relative needs _4_ bytes if you have >64K to address - relative needs an address register, which is not available for the code generator anymore. - relative requires all data in one chunk - relative requires special consideration for interrupt/thread code > Thomas Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 19:33:04 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <89039-1>; Tue, 1 Aug 1995 19:32:50 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id SAA10115 (8.6.10/2.4); Tue, 1 Aug 1995 18:33:07 +0200 Date: Tue, 1 Aug 1995 18:33:07 +0200 From: Olaf Seibert Message-Id: <199508011633.SAA10115@septimius.mbfys.kun.nl> To: amiga-gcc-port@nic.funet.fi Subject: ^C-ing gcc After my unnecessary complaint about cp, I thought I'd throw in another vague complaint. In my experience, aborting gcc is not 100% reliable. If I hit ^C, cc1 usually aborts with a message like "gcc: Internal compiler error: program cc1 got fatal signal 2". I can live with that, since SIGINT is 2. However, sometimes it complains about "illegal instruction" and/or crashes or hangs the machine. Of course this is not reproducable at will, and it seems to have considerably improved over time. I used never to interrupt gcc because of this, but now it seems I can take the risk. Anybody have an idea where this is coming from (even if it's not easy to fix). Oh, an unrelated thing: the "trace" command, going with ixemul.trace, seems to be missing from both the gcc 2.6.3 binary dist and the ixemul 41.x source dist. -Olaf. -- Have you indecently fucked this Exon idiot and his allies today? ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 20:06:10 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <88986-4>; Tue, 1 Aug 1995 20:04:59 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id SAA00919; Tue, 1 Aug 1995 18:03:19 +0100 From: Lars Hecking Message-Id: <199508011706.SAA03956@mostar.nmrc.ucc.ie> Subject: Re: ^C-ing gcc To: rhialto@mbfys.kun.nl (Olaf Seibert) Date: Tue, 1 Aug 1995 18:06:12 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199508011633.SAA10115@septimius.mbfys.kun.nl> from "Olaf Seibert" at Aug 1, 95 06:33:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 620 > After my unnecessary complaint about cp, I thought I'd throw in another > vague complaint. It wasn't unnecessary, but merely pointed out undesired bahaviour. For the next release, cp should come compiled with -mstackextend. > In my experience, aborting gcc is not 100% reliable. If I hit ^C, cc1 > usually aborts with a message like "gcc: Internal compiler error: > program cc1 got fatal signal 2". I can live with that, since SIGINT is > 2. However, sometimes it complains about "illegal instruction" and/or > crashes or hangs the machine. I am using PriMan to 'break' cc1. Has worked reliably ever since. From amiga-gcc-port-owner@nic.funet.fi Tue Aug 1 20:32:56 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <89103-2>; Tue, 1 Aug 1995 20:30:52 +0300 Received: from lysita.lysator.liu.se (lysita.lysator.liu.se [130.236.254.153]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id TAA09941; Tue, 1 Aug 1995 19:30:12 +0200 Received: (nisse@localhost) by lysita.lysator.liu.se (8.6.11/8.6.11) id TAA01451; Tue, 1 Aug 1995 19:30:09 +0200 Date: Tue, 1 Aug 1995 19:30:09 +0200 Message-Id: <199508011730.TAA01451@lysita.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: rhialto@mbfys.kun.nl CC: hans@wyst.hobby.nl, lhecking@nmrc.ucc.ie, amiga-gcc-port@nic.funet.fi In-reply-to: <199508011248.OAA09646@septimius.mbfys.kun.nl> (message from Olaf Seibert on Tue, 1 Aug 1995 14:48:24 +0200) Subject: Re: gcc-2.7.0 -resident bug Date: Tue, 1 Aug 1995 14:48:24 +0200 From: Olaf Seibert Cc: amiga-gcc-port@nic.funet.fi Content-Type: text Content-Length: 1237 hans@wyst.hobby.nl (Hans Verkuil) wrote: > const. Don't use const: try compiling with '-resident -Dconst='. I had > stumbled across other problems with const earlier (your sed problem), but > I've found out that the problem is much more basic than I thought and to > really fix it will require a change to gcc :-(. Currently pointers to > variables in the data hunk are placed in the text hunk if they are declared > const. But in that case they are relocated only once, while the data hunk > is copied and relocated every time you use the program, so the pointer > points to an old data hunk. gcc needs to be changed so that, when compiling > with -resident, all variables are placed in the data hunk, regardless of > their 'const'-ness. This is neeed only if they are pointers, I think. And why one would use constant pointers... I guess that doesn't happen very often. Unfortunately, ignoring the const keyword will not solve the problem, always. Consider this (of course not tested) --- struct some_struct { char * string; struct other_struct *data; }; struct other_struct { int a,b; }; char message[] = "Hey you"; struct other_struct os = {7, 17}; struct some_struct ss = { &os, message }; /* Note this initializer!!! */ ... main() { os.a = 19; printf("19 = %d", ss->data.a); /* This might result in "19 = 7" * second time this program is * invoked, if resident! */ } --- All the variables here are non-consts, and are placed in the data segment. Nevertheless, I think that the initializer migth be in the text segment, and as a result you may end up with the data field pointing at the wrong other_struct, with *strange* errors. (I hope this description is clear enough, at least I think I understand it myself...) From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 00:17:55 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89012-3>; Wed, 2 Aug 1995 00:16:50 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 1 Aug 95 23:16 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 1 Aug 95 23:09 MET DST Message-Id: Subject: when we get __chip__ ? To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 1 Aug 1995 23:09:01 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 580 i have successfull compiled simpletask with gcc270 what was the last thing that didnt work with 263. the only thing whats missing now is __chip__ for use in gfx related structures usw ... when can we see it ? walter ps: who is ptrace() going ? i would like to debug my prg's with gdb. :) -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 09:12:17 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <89492-1>; Wed, 2 Aug 1995 09:10:46 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA16487 (5.65b/CWI-3.3); Wed, 2 Aug 1995 08:10:25 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sdWpD-000FjBC; Wed, 2 Aug 95 07:58 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <08lg@wyst.hobby.nl>; Tue, 1 Aug 95 21:08:30 CET Message-Id: <9508012008.08lg@wyst.hobby.nl> Date: Tue, 1 Aug 1995 21:08:22 +0000 (CET) In-Reply-To: <199508011730.TAA01451@lysita.lysator.liu.se> from "Niels M|ller" at Aug 1, 95 07:30:09 pm Content-Type: text Content-Length: 1729 From: hans@wyst.hobby.nl (Hans Verkuil) To: nisse@lysator.liu.se Cc: amiga-gcc-port@nic.funet.fi Subject: Re: gcc-2.7.0 -resident bug According to Niels M|ller: > > Unfortunately, ignoring the const keyword will not solve the problem, > always. Consider this (of course not tested) Well, I tested it, and after debugging it (:-) it worked perfectly, just as I expected. Here is my slightly revised program: struct some_struct { struct other_struct *data; char * string; }; struct other_struct { int a,b; }; char message[] = "Hey you"; struct other_struct os = { 7, 17 }; const struct some_struct ss1 = { &os, message }; /* Note this initializer!!! */ struct some_struct ss2 = { &os, message }; /* Note this initializer!!! */ main() { os.a = 19; printf("19 = %d\n", ss1.data->a); /* This results in "19 = 7" * whenever this program is * invoked, if resident! */ printf("19 = %d\n", ss2.data->a); /* This should be "19 = 19"! */ } This will produce: 19 = 7 19 = 19 struct ss1 is declared constant and ends up in the text hunk, ss2 is not constant and will end up in the data hunk. The compiler will only put data in the text hunk if declared constant or if they are strings (which are assumed to be constant). The program will always produce a wrong result for ss1 and not only the second time it is started, because the data hunk is always copied for every invocation. The original data hunk is never used, except as the original for the duplication. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 09:33:43 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90385-1>; Wed, 2 Aug 1995 09:33:05 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA16477 (5.65b/CWI-3.3); Wed, 2 Aug 1995 08:10:24 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sdWp6-000FjBC; Wed, 2 Aug 95 07:58 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <08lb@wyst.hobby.nl>; Tue, 1 Aug 95 20:51:12 CET Message-Id: <9508011951.08lb@wyst.hobby.nl> Date: Tue, 1 Aug 1995 20:51:10 +0000 (CET) In-Reply-To: <199508011633.SAA10115@septimius.mbfys.kun.nl> from "Olaf Seibert" at Aug 1, 95 06:33:07 pm Content-Type: text Content-Length: 796 From: hans@wyst.hobby.nl (Hans Verkuil) To: rhialto@mbfys.kun.nl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ^C-ing gcc According to Olaf Seibert: > Oh, an unrelated thing: the "trace" command, going with ixemul.trace, > seems to be missing from both the gcc 2.6.3 binary dist and the ixemul > 41.x source dist. When Fred has finished merging I'll get the ixemul sources so that I can clean them up. While doing that I'll also integrate ixtrace. The current ixtrace is quite out of date (most of the new functions are not traced at the moment), so it needs work anyway. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 09:34:26 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90401-4>; Wed, 2 Aug 1995 09:33:29 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HTLCPT62Q890RR2S@LEON.CTI.GR>; Wed, 2 Aug 1995 09:29:20 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA20230; Wed, 2 Aug 95 09:35:17 +0300 Date: Wed, 02 Aug 1995 09:35:16 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: ^C-ing gcc In-reply-to: <199508011706.SAA03956@mostar.nmrc.ucc.ie> from "Lars Hecking" at Aug 1, 95 06:06:12 pm To: lhecking@nmrc.ucc.ie (Lars Hecking) Cc: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9508020635.AA20230@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 568 > I am using PriMan to 'break' cc1. Has worked reliably ever since. Ditto for the DOS "break" command. The problem does not appear when setting the signal bit using an external program such as priman or break, but when actualli hitting ^C in the CLI window. It probably has something to do with the handler that ixemul.library installs to emulate UNIX ^C handling. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "The thing is, Doctor, is there anything *I* can do?" "Yes, pass me a silicon rod, will you?" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 11:46:50 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <89748-1>; Wed, 2 Aug 1995 11:45:52 +0300 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id KAA25948 (8.6.12/IDA-1.6); Wed, 2 Aug 1995 10:45:26 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA24762; Wed, 2 Aug 95 10:45:25 +0200 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9508020845.AA24762@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: gcc-2.7.0 -resident bug To: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Date: Wed, 2 Aug 1995 10:45:25 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9508011614.AA25205@nereid.rz.Uni-Osnabrueck.DE> from "Thomas Radtke" at Aug 1, 95 06:14:09 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 336 > > > No idea. I get (-O -resident -Dconst=) 78972 bytes. > > > Because absolute addressing needs four bytes, the relative > counterparts only two. Am I wrong ? > You're right. But don't forget the relocation needed for absolute addressing which increases the executables size by another 4 bytes and slows down loading. Matthias From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 12:18:55 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89381-4>; Wed, 2 Aug 1995 12:18:02 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA08907; Wed, 2 Aug 1995 11:19:39 +0200 Date: Wed, 2 Aug 1995 11:19:38 +0200 (MET DST) From: Kamil Iskra Subject: Re: gcc-2.7.0 -resident bug To: Christian Stieber cc: Thomas Radtke , amiga-gcc-port@nic.funet.fi In-Reply-To: <95Aug1.183027+0100mesz.209198-2+1004@hphalle0.informatik.tu-muenchen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Aug 1995, Christian Stieber wrote: > - relative needs an address register, which is not available for > the code generator anymore. Could you clear this up, please? What does it mean: not available anymore? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 12:22:52 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90046-4>; Wed, 2 Aug 1995 12:22:29 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA08934; Wed, 2 Aug 1995 11:23:55 +0200 Date: Wed, 2 Aug 1995 11:23:54 +0200 (MET DST) From: Kamil Iskra Subject: Re: -fhandle-exceptions To: Alfred Minarik cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Aug1.103133+0300_eet_dst.90341-2+47@nic.funet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Aug 1995, Alfred Minarik wrote: > > 2.) I tried to compile a program using exceptions. But the linker > > wasn't able to resolv anything: A function __unwind_function > > seems to be missing in libstdc++.a. > > As far as I know, this function has to be written new for every system. > Some assembler lines to unwind the stack. > (Function: setting back the stack frame to calling functions while > calling the destructors of the so removed (automatic storage type) > classes until a exeption handler is found). > No idea how to programm this. > e.g. you have to monitor the new stack extension option. > Seems you are right. What a pity :-(. Could somebody with good knowledge of GCC internals and this awful 680x0 GNU syntax (:-) write such a function, please? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 12:34:59 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <89575-4>; Wed, 2 Aug 1995 12:34:26 +0300 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.6.12/8.6.9) id LAA03677; Wed, 2 Aug 1995 11:33:25 +0200 Date: Wed, 2 Aug 1995 11:33:25 +0200 From: Ignatios Souvatzis Message-Id: <199508020933.LAA03677@theory.cs.uni-bonn.de> To: kiskra@ernie.icslab.agh.edu.pl CC: stieber@informatik.tu-muenchen.de, thradtke@nereid.rz.Uni-Osnabrueck.DE, amiga-gcc-port@nic.funet.fi In-reply-to: Kamil Iskra's message of Wed, 2 Aug 1995 11:19:38 +0200 (MET DST) Subject: gcc-2.7.0 -resident bug X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a On Tue, 1 Aug 1995, Christian Stieber wrote: > - relative needs an address register, which is not available for > the code generator anymore. Could you clear this up, please? What does it mean: not available anymore? Nothing. Modern compilers, like gcc, use registers in an optimized way. There is no single register blocked for such purposes, normally. And relative branches use the PC, which can't be used for anything else :-) Ignatios Souvatzis From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 13:11:36 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89309-2>; Wed, 2 Aug 1995 13:10:39 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 2 Aug 1995 12:07:03 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA07091; Wed, 2 Aug 95 12:07:11 +0200 Date: Wed, 2 Aug 95 12:07:11 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508021007.AA07091@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@nic.funet.fi Subject: Re: ^C-ing gcc Hi, > From: Lars Hecking > I am using PriMan to 'break' cc1. Has worked reliably ever since. To make yet another vague statement: I'm also under the impression that sending a break signal from another shell is much more reliable (if not 100%) than typing ^C in the shell where gcc runs. Sorry for the lack of precision, Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 13:46:00 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90602-2>; Wed, 2 Aug 1995 13:44:59 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA09534; Wed, 2 Aug 1995 12:46:07 +0200 Date: Wed, 2 Aug 1995 12:46:06 +0200 (MET DST) From: Kamil Iskra Subject: Re: libg++ 020 soft-float version To: Philippe BRAND cc: Amiga-Gcc Liste In-Reply-To: <199507311135.MAA01915@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 31 Jul 1995, Philippe BRAND wrote: > File libg020.lha is available on both ftp.telesys-innov.fr and nic.funet.fi > As I've used cross-compiler, be sure to 'ranlib' libraries. > I used "-m68020 -msoft-float' to generate them. 020 libraries won't > overwrite existing one, as they'll go into gnu/lib/libm020. > Please test and report asap. Thanks for these. I tested outputting floats using "cout <<" with -m68020 and without FPU and it seems that this works fine now (contrary to 2.6.3). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 15:27:06 1995 Received: from gate1.informatik.fh-wiesbaden.de ([193.175.36.254]) by nic.funet.fi with SMTP id <90094-2>; Wed, 2 Aug 1995 15:25:36 +0300 Received: from sun.informatik.fh-wiesbaden.de (sun15.informatik.fh-wiesbaden.de) by gate1.informatik.fh-wiesbaden.de with SMTP id AA00600 (5.65c/IDA-1.4.4 for ); Wed, 2 Aug 1995 14:25:02 +0200 Received: from sun01.informatik.fh-wiesbaden.de by sun.informatik.fh-wiesbaden.de (4.1/fhw-FBI_sun-Nl) id AA18415; Wed, 2 Aug 95 14:24:58 +0200 From: i511@informatik.fh-wiesbaden.de (ruppert) Message-Id: <9508021224.AA18415@sun.informatik.fh-wiesbaden.de> Subject: gcc2.7.0 preliminary problem with -dxxx ! To: amiga-gcc-port@nic.funet.fi Date: Wed, 2 Aug 1995 14:24:57 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 499 Hi, I have a problem with the gcc2.7.0 preliminary version. I just want to recompile gmake, to make it residentable. But the compiler generates all dump files, which are normally only created with the -dxxx switch. But I can't find any -dxxx switches in my environment (specs or in the gcc driver program). Can anyone give me a hint ? Ciao Stefan -- Home: Stefan Ruppert Windthorststrasse 5 65439 Floersheim am Main GERMANY EMail: ruppert@vs3.informatik.fh-wiesbaden.de From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 16:01:54 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90693-2>; Wed, 2 Aug 1995 16:00:01 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id NAA14048; Wed, 2 Aug 1995 13:58:18 +0100 From: Lars Hecking Message-Id: <199508021301.OAA05161@mostar.nmrc.ucc.ie> Subject: Re: gcc2.7.0 preliminary problem with -dxxx ! To: i511@informatik.fh-wiesbaden.de (ruppert) Date: Wed, 2 Aug 1995 14:01:08 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9508021224.AA18415@sun.informatik.fh-wiesbaden.de> from "ruppert" at Aug 2, 95 02:24:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 652 > I have a problem with the gcc2.7.0 preliminary version. > I just want to recompile gmake, to make it residentable. But the GNU make cannot be made resident. It compiles ok, but doesn't work properly. This has been so ever since I started working with gcc and gmake (v3.5x). > compiler generates all dump files, which are normally only created > with the -dxxx switch. But I can't find any -dxxx switches in my > environment (specs or in the gcc driver program). > Can anyone give me a hint ? Leaves me clueless. Do you use the compiler from 22/7/95 (archives from 26/7/95)? Posting an example commandline with gcc -v output might help. From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 16:26:57 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90544-2>; Wed, 2 Aug 1995 16:26:09 +0300 Received: by ceylon.informatik.uni-rostock.de id PAA21887; Wed, 2 Aug 1995 15:25:48 +0200 Received: by honshu.informatik.uni-rostock.de id PAA01053; Wed, 2 Aug 1995 15:25:47 +0200 From: Gunther Nikl Message-Id: <199508021325.PAA01053@honshu.informatik.uni-rostock.de> Subject: Re: gcc2.7.0 preliminary problem with -dxxx ! To: amiga-gcc-port@nic.funet.fi Date: Wed, 2 Aug 1995 15:25:46 +0200 (MET DST) In-Reply-To: <199508021301.OAA05161@mostar.nmrc.ucc.ie> from "Lars Hecking" at Aug 2, 95 02:01:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 411 > > I have a problem with the gcc2.7.0 preliminary version. > > I just want to recompile gmake, to make it residentable. But the > > GNU make cannot be made resident. It compiles ok, but doesn't work > properly. This has been so ever since I started working with gcc > and gmake (v3.5x). No true. I managed to create a residentable gmake v3.74 (but only compiled with -O, -O2 didn't work) Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 16:35:22 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90591-3>; Wed, 2 Aug 1995 16:30:45 +0300 Received: by ceylon.informatik.uni-rostock.de id PAA21942; Wed, 2 Aug 1995 15:30:22 +0200 Received: by honshu.informatik.uni-rostock.de id PAA01091; Wed, 2 Aug 1995 15:30:22 +0200 From: Gunther Nikl Message-Id: <199508021330.PAA01091@honshu.informatik.uni-rostock.de> Subject: Re: gcc-2.7.0 -resident bug To: amiga-gcc-port@nic.funet.fi Date: Wed, 2 Aug 1995 15:30:22 +0200 (MET DST) In-Reply-To: <199508020933.LAA03677@theory.cs.uni-bonn.de> from "Ignatios Souvatzis" at Aug 2, 95 11:33:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 878 > > From: Kamil Iskra > > On Tue, 1 Aug 1995, Christian Stieber wrote: > > - relative needs an address register, which is not available for > > the code generator anymore. > > Could you clear this up, please? What does it mean: not available anymore? > > Nothing. Modern compilers, like gcc, use registers in an optimized > way. There is no single register blocked for such purposes, normally. Wrong. Christian refered to "small-data" as relative addressing. This has nothing to do "small-code". The "small-data" model requires an address register to access *all* data through this register. Usually its "a4", if you compile with "-fbaserel". But gcc allows you to use any other register as well (but you should use a non-scratch address register :-). Unfortunately this limits you to 32k of data) Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 16:45:11 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <88597-2>; Wed, 2 Aug 1995 16:43:52 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 2 Aug 1995 15:43:30 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA07636; Wed, 2 Aug 95 15:43:39 +0200 Date: Wed, 2 Aug 95 15:43:39 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508021343.AA07636@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@nic.funet.fi Subject: Re: gcc-2.7.0 -resident bug Gunther Nikl wrote: > > From: Kamil Iskra > > Nothing. Modern compilers, like gcc, use registers in an optimized > > way. There is no single register blocked for such purposes, normally. > > Wrong. Christian refered to "small-data" as relative addressing. This > has nothing to do "small-code". The "small-data" model requires an > address register to access *all* data through this register. Usually > its "a4", if you compile with "-fbaserel". But gcc allows you to use > any other register as well (but you should use a non-scratch address > register :-). Unfortunately this limits you to 32k of data) Maybe the question is whether GCC is able to use the baserel register for something else in say tight loops with many registers. I was once surprised to see that A6 was used in such a loop and wondered if something was wrong with register allocation, I thought it was somewhat reserved. Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 16:50:30 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90914-2>; Wed, 2 Aug 1995 16:49:53 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 2 Aug 1995 15:49:17 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA07666; Wed, 2 Aug 95 15:49:25 +0200 Date: Wed, 2 Aug 95 15:49:25 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508021349.AA07666@inf-wiss.uni-konstanz.de> To: am@beta.mdy.univie.ac.at, amiga-gcc-port@nic.funet.fi Subject: Re: -fhandle-exceptions Kamil Iskra wrote: > On Tue, 1 Aug 1995, Alfred Minarik wrote: > > e.g. you have to monitor the new stack extension option. BTW, last time I checked the stack/ directory of the ixemul 41.x source code, I found no reference to setjmp/longjmp. To me it seems that one cannot claim to implement stackextension properly without having a look at (read modify) these functions :-( > Seems you are right. What a pity :-(. Could somebody with good knowledge > of GCC internals and this awful 680x0 GNU syntax (:-) write such a > function, please? New GAS' accept the (beautiful? :-) Motorola syntax too. Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 16:53:50 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <88668-3>; Wed, 2 Aug 1995 16:53:12 +0300 Received: by ceylon.informatik.uni-rostock.de id PAA22012; Wed, 2 Aug 1995 15:52:52 +0200 Received: by honshu.informatik.uni-rostock.de id PAA01244; Wed, 2 Aug 1995 15:52:52 +0200 From: Gunther Nikl Message-Id: <199508021352.PAA01244@honshu.informatik.uni-rostock.de> Subject: Re: gcc-2.7.0 -resident bug To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Wed, 2 Aug 1995 15:52:51 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9508021343.AA07636@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 2, 95 03:43:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 686 > Joerg Hoehle wrote: > > Maybe the question is whether GCC is able to use the baserel register > for something else in say tight loops with many registers. I was once > surprised to see that A6 was used in such a loop and wondered if > something was wrong with register allocation, I thought it was somewhat > reserved. Nope. The baserel register is fixed in the whole program. It cannot be used for everything, since its really taken away from the list of available registers. A6 however is no special register for amiga-gcc. (Normally a6 is the frame-pointer, but this had to be changed for the amiga, because the amiga required a6 for the library bases.) Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 17:31:45 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <88772-1>; Wed, 2 Aug 1995 17:30:26 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id PAA15622; Wed, 2 Aug 1995 15:28:48 +0100 From: Lars Hecking Message-Id: <199508021431.PAA05254@mostar.nmrc.ucc.ie> Subject: Re: gcc2.7.0 preliminary problem with -dxxx ! To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Wed, 2 Aug 1995 15:31:41 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199508021325.PAA01053@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Aug 2, 95 03:25:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 940 > > GNU make cannot be made resident. It compiles ok, but doesn't work > > properly. This has been so ever since I started working with gcc > > and gmake (v3.5x). > > No true. I managed to create a residentable gmake v3.74 (but only > compiled with -O, -O2 didn't work) I used -O2 -m68020 -resident -Dconst= and got weird errors configure'ing various packages whenever configure was testing ${MFLAGS} or ${MAKE}. Ok. I'll try -O ... [make and install GNU make 3.74; CFLAGS= -O -m68020 -resident -Dconst=] :sh-utils-1.12> resident bin:make :sh-utils-1.12> sh ./configure creating cache ./config.cache checking whether make sets $MAKE... %1 125931080 Illegal instruction [ ^^ = 0x7818e48; task address] ${MAKE-make} -f conftestmake 2> /dev/null | no checking for gcc... gcc ... and so on. :sed-2.05> make Bus error. :sed-2.05> stack Current stack size is 98304 bytes So? From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 17:36:57 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89059-3>; Wed, 2 Aug 1995 17:36:01 +0300 Received: by ceylon.informatik.uni-rostock.de id QAA22171; Wed, 2 Aug 1995 16:35:42 +0200 Received: by honshu.informatik.uni-rostock.de id QAA01333; Wed, 2 Aug 1995 16:35:42 +0200 From: Gunther Nikl Message-Id: <199508021435.QAA01333@honshu.informatik.uni-rostock.de> Subject: Re: gcc2.7.0 preliminary problem with -dxxx ! To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Wed, 2 Aug 1995 16:35:41 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508021431.PAA05254@mostar.nmrc.ucc.ie> from "Lars Hecking" at Aug 2, 95 03:31:41 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1264 > > > GNU make cannot be made resident. It compiles ok, but doesn't work > > > properly. This has been so ever since I started working with gcc > > > and gmake (v3.5x). > > > > No true. I managed to create a residentable gmake v3.74 (but only > > compiled with -O, -O2 didn't work) > > I used -O2 -m68020 -resident -Dconst= and got weird errors configure'ing > various packages whenever configure was testing ${MFLAGS} or ${MAKE}. I also had several problems with make, but this was not a problem of "resident", "fbasrel" failed as well together with "-O2". And if I remember correctly "-O" worked. > [make and install GNU make 3.74; CFLAGS= -O -m68020 -resident -Dconst=] > > :sh-utils-1.12> resident bin:make > :sh-utils-1.12> sh ./configure > creating cache ./config.cache > checking whether make sets $MAKE... %1 125931080 Illegal instruction > [ ^^ = 0x7818e48; task address] > ${MAKE-make} -f conftestmake 2> /dev/null | > no > checking for gcc... gcc > ... and so on. > > :sed-2.05> make > Bus error. > :sed-2.05> stack > Current stack size is 98304 bytes > > So? I know this behavior of make. I really have no clue, whats the problem with "-O2 -fbaserel", sorry. Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 17:39:44 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90496-4>; Wed, 2 Aug 1995 17:38:43 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id PAA15805; Wed, 2 Aug 1995 15:37:03 +0100 From: Lars Hecking Message-Id: <199508021439.PAA05314@mostar.nmrc.ucc.ie> Subject: Re: gcc2.7.0 preliminary problem with -dxxx ! To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Wed, 2 Aug 1995 15:39:57 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199508021435.QAA01333@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Aug 2, 95 04:35:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 265 > > [make and install GNU make 3.74; CFLAGS= -O -m68020 -resident -Dconst=] [ex del'd] > > So? > > I know this behavior of make. I really have no clue, whats the problem > with "-O2 -fbaserel", sorry. The make used in above example was compiled with -O. From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 17:43:05 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88855-4>; Wed, 2 Aug 1995 17:41:25 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sdewR-0004nYC; Wed, 2 Aug 95 07:38 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: gcc2.7.0 preliminary problem with -dxxx ! To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Wed, 2 Aug 1995 07:38:38 -0700 (MST) Cc: i511@informatik.fh-wiesbaden.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <199508021301.OAA05161@mostar.nmrc.ucc.ie> from "Lars Hecking" at Aug 2, 95 02:01:08 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 732 > > compiler generates all dump files, which are normally only created > > with the -dxxx switch. But I can't find any -dxxx switches in my > > environment (specs or in the gcc driver program). > > Can anyone give me a hint ? > > Leaves me clueless. Do you use the compiler from 22/7/95 (archives > from 26/7/95)? Posting an example commandline with gcc -v output > might help. Some versions of "make" have been buggy and would randomly dump their internal state to the console when run. I attribute this to the flag that controls this option being toggled true by random internal corruption. I saw this mostly in the early 3.7.X makes (3.7.1?), however have not had any trouble with make since upgrading to 3.7.4. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 17:43:43 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <88410-4>; Wed, 2 Aug 1995 17:43:23 +0300 Received: by colombo.telesys-innov.fr; Wed, 2 Aug 1995 16:44:10 +0100 From: Philippe BRAND Message-Id: <199508021544.QAA05441@colombo.telesys-innov.fr> Subject: Apurify 1.2 for gcc available (preliminary) To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Wed, 2 Aug 1995 16:44:09 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 520 File gcc-apurify_v1.2.lha is available on both my site and ftp.funet.fi. Please test it, as I may be able to integrate it into gcc-2.7.0 distribution, creating an extra pass if a special compiler flag is given (-apurify something like that). As for now you have to compile with -S then assemble and link. Grab Apurify from Aminet for docs. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 17:54:17 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <88496-2>; Wed, 2 Aug 1995 17:53:44 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26712-1>; Wed, 2 Aug 1995 16:53:02 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209167-2>; Wed, 2 Aug 1995 16:52:54 +0100 Subject: Re: gcc-2.7.0 -resident bug From: Christian Stieber To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Wed, 2 Aug 1995 16:52:40 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508021330.PAA01091@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Aug 2, 95 03:30:22 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 495 Message-Id: <95Aug2.165254+0100mesz.209167-2+1579@hphalle0.informatik.tu-muenchen.de> [ baserelative addressing ] > register :-). Unfortunately this limits you to 32k of data) Well, what happens if you use -mc68020? We have 32 bit offsets since the 68020; can GNU-C use them for baserelative addressing? > Gunther Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 18:45:36 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90612-3>; Wed, 2 Aug 1995 18:44:17 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 2 Aug 1995 17:43:47 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA08066; Wed, 2 Aug 95 17:43:55 +0200 Date: Wed, 2 Aug 95 17:43:55 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508021543.AA08066@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@nic.funet.fi Subject: Re: -fhandle-exceptions [This is a forward.] I wrote: > New GAS' accept the (beautiful? :-) Motorola syntax too. Walter Harms replied: ever tried jsr hallo(pc) ? dont work in any gas version i know everytime i found this and changed it to jsr hallo that works without problems. walter From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 19:03:13 1995 Received: from gate1.informatik.fh-wiesbaden.de ([193.175.36.254]) by nic.funet.fi with SMTP id <90738-4>; Wed, 2 Aug 1995 19:01:51 +0300 Received: from sun.informatik.fh-wiesbaden.de (sun15.informatik.fh-wiesbaden.de) by gate1.informatik.fh-wiesbaden.de with SMTP id AA00761 (5.65c/IDA-1.4.4 for ); Wed, 2 Aug 1995 18:01:26 +0200 Received: from sun06.informatik.fh-wiesbaden.de by sun.informatik.fh-wiesbaden.de (4.1/fhw-FBI_sun-Nl) id AA18557; Wed, 2 Aug 95 18:01:21 +0200 From: i511@informatik.fh-wiesbaden.de (Stefan Ruppert) Message-Id: <9508021601.AA18557@sun.informatik.fh-wiesbaden.de> Subject: Re: gcc2.7.0 preliminary problem with -dxxx ! To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Wed, 2 Aug 1995 18:01:19 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508021301.OAA05161@mostar.nmrc.ucc.ie> from "Lars Hecking" at Aug 2, 95 02:01:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2032 Hi, > > compiler generates all dump files, which are normally only created > > with the -dxxx switch. But I can't find any -dxxx switches in my > > environment (specs or in the gcc driver program). > > Can anyone give me a hint ? > > Leaves me clueless. Do you use the compiler from 22/7/95 (archives > from 26/7/95)? Posting an example commandline with gcc -v output > might help. Yes, the compiler is from 26/7/95 (archive). And gcc -v gives the following output : 0> gcc270 -v -DHAVE_CONFIG_H -DLIBDIR=\"/usr/local/lib\" -DINCLUDEDIR=\"/usr/local/include\" -c -I. -I. -I./glob -O -m68000 -resident -databss-together job.c Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cpp -lang-c -v -I. -I. -I./glob-O -undef -D__GNUC__=2 -D__GNUC_MINO __=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ - __AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m6 k) -databss-together -Dmc68010 -DHAVE_CONFIG_H -DLIBDIR="/usr/local/lib" -DINCLUDEDIR="/usr/local/include" job.c /t/cc173464.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: . . ./glob-O /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cc1 /t/cc173464.i -fbaserel -mfixedstack -quiet -dumpbase job.c -databss-together -m68000 -version -o /t/cc173464.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. I don't know, why the -dumpbase is in the commandline ? I tried this also the the gcc2.6.3 driver with -V 2.7.0 -b mc68000-cbm-amigados switch and the same happens. Ciao Stefan -- Home: Stefan Ruppert Windthorststrasse 5 65439 Floersheim am Main GERMANY EMail: ruppert@vs3.informatik.fh-wiesbaden.de From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 20:11:17 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90235-2>; Wed, 2 Aug 1995 20:07:33 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id SAA18590; Wed, 2 Aug 1995 18:05:37 +0100 From: Lars Hecking Message-Id: <199508021708.SAA05632@mostar.nmrc.ucc.ie> Subject: Re: gcc2.7.0 preliminary problem with -dxxx ! To: i511@informatik.fh-wiesbaden.de (Stefan Ruppert) Date: Wed, 2 Aug 1995 18:08:31 +0100 (BST) Cc: phb@colombo.telesys-innov.fr (Philippe Brand), amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9508021601.AA18557@sun.informatik.fh-wiesbaden.de> from "Stefan Ruppert" at Aug 2, 95 06:01:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1122 > 0> gcc270 -v -DHAVE_CONFIG_H -DLIBDIR=\"/usr/local/lib\" -DINCLUDEDIR=\"/usr/local/include\" -c -I. -I. -I./glob -O -m68000 -resident -databss-together job.c ^^^^^^^^^^^^^^^^^ This is not necessary for resident executables! -resident should be sufficient (someone correct me if I'm wrong). > /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cc1 /t/cc173464.i -fbaserel -mfixedstack -quiet -dumpbase job.c -databss-together -m68000 -version -o /t/c.... ^^^^^^^^^^^^^^^^^ This is a bug in the frontend: -databss-together is a linker option and must not be passed to cc1. In your case, it causes all the dump files to be created, because cc1 interprets -databss-together as -dxxx option. Philippe? ;)) > I don't know, why the -dumpbase is in the commandline ? Just scanned the source code. -dumpbase job.c simply tells cc1 the filenamebase for the dump files. If you run cc1 from the commandline with -dxxx and without -dumpbase job.c, you'll find that the dumpfiles will default to gccdump.combine, gccdump.cse and so on. From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 20:30:50 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90273-4>; Wed, 2 Aug 1995 20:27:26 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sdhZE-0004nYC; Wed, 2 Aug 95 10:26 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: gcc2.7.0 preliminary problem with -dxxx ! To: fnf@amigalib.com (Fred Fish) Date: Wed, 2 Aug 1995 10:26:52 -0700 (MST) Cc: lhecking@nmrc.ucc.ie, i511@informatik.fh-wiesbaden.de, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Fred Fish" at Aug 2, 95 07:38:38 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 368 > > > compiler generates all dump files, which are normally only created > > Some versions of "make" have been buggy and would randomly dump their > internal state to the console when run. I attribute this to the flag Arg! Ignore my ramblings about "make". I didn't read the original mail closely enough, or else was severely sleep-deprived at the time... -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 22:48:36 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89221-4>; Wed, 2 Aug 1995 22:45:17 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id UAA20361; Wed, 2 Aug 1995 20:43:52 +0100 From: Lars Hecking Message-Id: <199508021946.UAA05925@mostar.nmrc.ucc.ie> Subject: Exception handling To: am@beta.mdy.univie.ac.at (Alfred Minarik) Date: Wed, 2 Aug 1995 20:46:46 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <95Aug1.103133+0300_eet_dst.90341-2+47@nic.funet.fi> from "Alfred Minarik" at Aug 1, 95 09:30:49 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2012 > > 2.) I tried to compile a program using exceptions. But the linker > > wasn't able to resolv anything: A function __unwind_function > > seems to be missing in libstdc++.a. It belongs into libgcc2.a, unless compiled into cc1plus. > As far as I know, this function has to be written new for every system. > Some assembler lines to unwind the stack. > (Function: setting back the stack frame to calling functions while > calling the destructors of the so removed (automatic storage type) > classes until a exeption handler is found). > No idea how to programm this. > e.g. you have to monitor the new stack extension option. [gxxint.info] The __unwind_function takes a pointer to the throw handler, and is expected to pop the stack frame that was built to call it, as well as the frame underneath and then jump to the throw handler. It must not change the three registers allocated for the pointer to the exception object, the pointer to the type descriptor that identifies the type of the exception object, and the pointer to the code that threw. On hppa, these are %r5, %r6, %r7. On m68k these are a2, a3, a4. On mips they are s0, s1, s2. On Alpha these are $9, $10, $11. It takes about a day to write this routine, if someone wants to volunteer to write this routine for any architecture, exception support for that architecture will be added to g++. Please send in those code donations. Mike Stump, current maintainer of EH code in g++, pointed out: "The above should be enough to get started. You can get the compiler to tell you most of what you have to write by compiling: foo() { } Although to work well, one should understand the calling conventions of the machine. Hint, use the frame pointer (gcc speak) (on the m68k, this would be a6), and assume it is always present." [This is a5 on the Amiga, as we know] On the SPARC, it's only 5 lines of assembly code (I don't understand it, though :(, but -mstackextend might introduce some difficulties. Any takers? From amiga-gcc-port-owner@nic.funet.fi Wed Aug 2 23:13:06 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89114-4>; Wed, 2 Aug 1995 23:10:02 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 2 Aug 95 22:09 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 2 Aug 95 22:05 MET DST Message-Id: Subject: Exception handling To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 2 Aug 1995 22:05:33 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3224 Forwarded message: > From arbi.informatik.uni-oldenburg.de!nic.funet.fi!amiga-gcc-port-owner Wed Aug 2 21:51:22 1995 > From: Lars Hecking > Message-Id: <199508021946.UAA05925@mostar.nmrc.ucc.ie> > Subject: Exception handling > To: am@beta.mdy.univie.ac.at (Alfred Minarik) > Date: Wed, 2 Aug 1995 20:46:46 +0100 (BST) > Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) > In-Reply-To: <95Aug1.103133+0300_eet_dst.90341-2+47@nic.funet.fi> from "Alfred Minarik" at Aug 1, 95 09:30:49 am > X-Mailer: ELM [version 2.4 PL24] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7BIT > Content-Length: 2012 > > > > > 2.) I tried to compile a program using exceptions. But the linker > > > wasn't able to resolv anything: A function __unwind_function > > > seems to be missing in libstdc++.a. > > It belongs into libgcc2.a, unless compiled into cc1plus. > > > As far as I know, this function has to be written new for every system. > > Some assembler lines to unwind the stack. > > (Function: setting back the stack frame to calling functions while > > calling the destructors of the so removed (automatic storage type) > > classes until a exeption handler is found). > > No idea how to programm this. > > e.g. you have to monitor the new stack extension option. > > [gxxint.info] > The __unwind_function takes a pointer to the throw handler, and is > expected to pop the stack frame that was built to call it, as well as > the frame underneath and then jump to the throw handler. It must not > change the three registers allocated for the pointer to the exception > object, the pointer to the type descriptor that identifies the type of > the exception object, and the pointer to the code that threw. On hppa, > these are %r5, %r6, %r7. On m68k these are a2, a3, a4. On mips they > are s0, s1, s2. On Alpha these are $9, $10, $11. It takes about a day > to write this routine, if someone wants to volunteer to write this > routine for any architecture, exception support for that architecture > will be added to g++. Please send in those code donations. > > Mike Stump, current maintainer of EH code in g++, pointed out: > > "The above should be enough to get started. You can get the compiler > to tell you most of what you have to write by compiling: > > foo() { > } > > Although to work well, one should understand the calling conventions > of the machine. Hint, use the frame pointer (gcc speak) (on the m68k, > this would be a6), and assume it is always present." > > [This is a5 on the Amiga, as we know] > > On the SPARC, it's only 5 lines of assembly code (I don't understand > it, though :(, but -mstackextend might introduce some difficulties. > Any takers? > > if you use amigaos-based exeptions i dont say major trouble but its a bit more tricky for m68k in general because there are (atleast) 2 differend stackframes. -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 00:08:01 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <89190-2>; Thu, 3 Aug 1995 00:02:44 +0300 Received: from lysita.lysator.liu.se (lysita.lysator.liu.se [130.236.254.153]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id XAA27070; Wed, 2 Aug 1995 23:02:15 +0200 Received: (nisse@localhost) by lysita.lysator.liu.se (8.6.11/8.6.11) id XAA00794; Wed, 2 Aug 1995 23:02:11 +0200 Date: Wed, 2 Aug 1995 23:02:11 +0200 Message-Id: <199508022102.XAA00794@lysita.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: hans@wyst.hobby.nl CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9508012008.08lg@wyst.hobby.nl> (hans@wyst.hobby.nl) Subject: Re: gcc-2.7.0 -resident bug According to Niels M|ller: > > Unfortunately, ignoring the const keyword will not solve the problem, > always. Consider this (of course not tested) Well, I tested it, and after debugging it (:-) it worked perfectly, just as I expected. [...] const struct some_struct ss1 = { &os, message }; /* Note this initializer!!! */ struct some_struct ss2 = { &os, message }; /* Note this initializer!!! */ main() { os.a = 19; printf("19 = %d\n", ss1.data->a); /* This results in "19 = 7" * whenever this program is * invoked, if resident! */ printf("19 = %d\n", ss2.data->a); /* This should be "19 = 19"! */ } This will produce: 19 = 7 19 = 19 struct ss1 is declared constant and ends up in the text hunk, ss2 is not constant and will end up in the data hunk. The compiler will only put data in the text hunk if declared constant or if they are strings (which are assumed to be constant). The program will always produce a wrong result for ss1 and not only the second time it is started, because the data hunk is always copied for every invocation. The original data hunk is never used, except as the original for the duplication. What I was thinking of is if the *initializer* is put in the text segment, that is, if struct some_struct ss2 = { &os, message }; /* Note this initializer!!! */ might be equivalent to struct some_struct ss2; /* in data segment */ const struct some_struct temp = { &os, message }; /* in text segment */ followed by memcpy(&ss2, &temp, sizeof(struct some_struct)); called from (or before) main(); I suppose gcc can generate this kind of initializing if 1) the initializer is constant (as it is above), and 2) the struct is fairly large, which my example perhaps is not. If you want to test this further, try instead struct some_struct { char *message; char text[1000]; struct other_struct *os; }; struct some_struct ss = { message, "insert 1000 random characters here, m,egnjkmgn sm, mfawek ...", &os }; and look at the code gcc generates. I'm sorry that I don't know much about what strategies gcc actually uses for initializers, I neither do I have access to my Amiga right now, so that I can find out myself. Regards, Niels From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 11:29:31 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <89511-3>; Thu, 3 Aug 1995 11:26:23 +0300 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id KAA23655 (8.6.12/IDA-1.6 for ); Thu, 3 Aug 1995 10:25:41 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA26678; Thu, 3 Aug 95 10:25:40 +0200 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9508030825.AA26678@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: gcc-2.7.0 -resident bug To: amiga-gcc-port@nic.funet.fi Date: Thu, 3 Aug 1995 10:25:40 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 669 > > [ baserelative addressing ] > > > register :-). Unfortunately this limits you to 32k of data) > Since ld adds -0x7ffe to all 16bit offsets the limit should actually be somewhere about 64k of data. But I never checked this. > Well, what happens if you use -mc68020? We have 32 bit offsets since > the 68020; can GNU-C use them for baserelative addressing? > I guess not. If you put 50k of data in each of 2 object files neither the compiler nor the assembler knows that you have too much data for 16 bit offsets. And the linker cannot change the offsets to 32bit. OTOH it'll be possible to add a large-baserel switch to gcc itself - theoretically. Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 11:34:21 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89290-2>; Thu, 3 Aug 1995 11:31:32 +0300 Received: by colombo.telesys-innov.fr; Thu, 3 Aug 1995 10:31:57 +0100 From: Philippe BRAND Message-Id: <199508030931.KAA07865@colombo.telesys-innov.fr> Subject: New pre-release available To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Thu, 3 Aug 1995 10:31:56 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 812 New pre-release distribution is available on both my site and nic.funet.fi. As for now you'll find readme, base, c, c++, objc and inclib parts. I've integrated latest Install script, Apurify v1.2 (although not integrated as a compiler pass yet), ld with GCCSTACK support, libg++ 68000 and 020 versions, patches applied to headers, libauto, GccFindHit, etc... Please have a look at those archives, try to install it (Install script has now an upgrade option with preservation of previous compiler version support), Report for missing files/programs (remember that gcc270-utils is not done yet), and possibly header patches missing. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 13:37:23 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89024-1>; Thu, 3 Aug 1995 13:35:36 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA28794; Thu, 3 Aug 1995 11:34:14 +0100 From: Lars Hecking Message-Id: <199508031037.LAA06798@mostar.nmrc.ucc.ie> Subject: Re: New pre-release available To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Thu, 3 Aug 1995 11:37:08 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199508030931.KAA07865@colombo.telesys-innov.fr> from "Philippe BRAND" at Aug 3, 95 10:31:56 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 114 > and possibly header patches missing. None of the header patches are there ... I'll mail them again. From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 15:02:52 1995 Received: from mailserv.uni-tuebingen.de ([134.2.250.102]) by nic.funet.fi with SMTP id <89509-2>; Thu, 3 Aug 1995 15:01:25 +0300 Received: from commlink.zdv.uni-tuebingen.de by mailserv.uni-tuebingen.de with SMTP (PP); Thu, 3 Aug 1995 14:01:00 +0200 Received: (from tkibo01@localhost) by commlink.zdv.uni-tuebingen.de (8.6.12/8.6.12) id OAA01235; Thu, 3 Aug 1995 14:00:58 +0200 From: Karl Walter Bock Message-Id: <199508031200.OAA01235@commlink.zdv.uni-tuebingen.de> Subject: Re: exit code 1 (was Re: your mail) To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Thu, 3 Aug 1995 14:00:58 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Aug1.181638+0100mesz.209167-2+1001@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Aug 1, 95 06:16:32 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 542 > > > On my machine, 'cc1' sometimes fail to load because of memory > > > fragmentation, but 'gcc' gives no error message - this means that I have > > > to watch the hard disk LED to see if it loads. Couldn't something be done > > > about this? > > > > Agreed, this should eventually be fixed. It bites people too many times. > > Well, it fails with a returncode of 1, so the error indication _is_ there. > > > -Fred > > Christian Well, but what do you do with error code 1 on the Amiga ? FAIL (10) would IMHO be much nicer. Simon From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 16:22:19 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90047-3>; Thu, 3 Aug 1995 16:21:00 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id OAA02788; Thu, 3 Aug 1995 14:19:20 +0100 From: Lars Hecking Message-Id: <199508031322.OAA06971@mostar.nmrc.ucc.ie> Subject: Re: exit code 1 (was Re: your mail) To: karl-walter.bock@uni-tuebingen.de (Karl Walter Bock) Date: Thu, 3 Aug 1995 14:22:12 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199508031200.OAA01235@commlink.zdv.uni-tuebingen.de> from "Karl Walter Bock" at Aug 3, 95 02:00:58 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 589 > > > Agreed, this should eventually be fixed. It bites people too many times. > > > > Well, it fails with a returncode of 1, so the error indication _is_ there. > > > > > -Fred > > > > Christian > > Well, but what do you do with error code 1 on the Amiga ? FAIL (10) would > IMHO be much nicer. What for? Cc1 is rarely run directly from commandline or AmigaDOS script, and those programs receiving cc1's exit code (gcc driver; make?) know how to deal with it. ixemul.library was designed for Unix, more specific BSD, compatibility, and not to be conformant to Amiga habits. From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 16:59:14 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90252-2>; Thu, 3 Aug 1995 16:54:54 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 3 Aug 95 15:54 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 3 Aug 95 15:50 MET DST Message-Id: Subject: gas bug To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 3 Aug 1995 15:50:17 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 882 there is a ugly bug in AS ! this simple prg shows that pc-relative addressing is not working in gas ! this adressing mode is often used by resident programms and may cause some serious crashes if used. i hope i have somewhere a prg that make use of ALL valid modes of the 68k. is someone interessed ?? assemble with: as -mc68010 -o bug.o bug.s _testprg: move.w test(pc),d0 | 303a000a jsr test(pc) sub.l test(pc),d0 nop nop nop nop test: .word 0xffff you can disasemble bug.o and see that the resulting code isnt anything. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 18:16:48 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89668-3>; Thu, 3 Aug 1995 18:07:18 +0300 Received: by ceylon.informatik.uni-rostock.de id RAA00845; Thu, 3 Aug 1995 17:06:48 +0200 Received: by honshu.informatik.uni-rostock.de id OAA00607; Thu, 3 Aug 1995 14:46:30 +0200 From: Gunther Nikl Message-Id: <199508031246.OAA00607@honshu.informatik.uni-rostock.de> Subject: Re: gcc2.7.0 preliminary problem with -dxxx ! To: amiga-gcc-port@nic.funet.fi Date: Thu, 3 Aug 1995 14:46:29 +0200 (MET DST) In-Reply-To: <199508021708.SAA05632@mostar.nmrc.ucc.ie> from "Lars Hecking" at Aug 2, 95 06:08:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 442 > > 0> gcc270 -v -DHAVE_CONFIG_H -DLIBDIR=\"/usr/local/lib\" > > 0> -DINCLUDEDIR=\"/usr/local/include\" -c -I. -I. -I./glob -O -m68000 -resident -databss-together job.c Is this line already the output of "gcc -v" or the way its called? For compiling "-fbaserel" is sufficient, "-resident" is only required when linking. (And "-databss-together" should never supplied by on the commandline unless ld is called directly) Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 18:17:27 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89824-1>; Thu, 3 Aug 1995 18:07:21 +0300 Received: by ceylon.informatik.uni-rostock.de id RAA00848; Thu, 3 Aug 1995 17:06:50 +0200 Received: by honshu.informatik.uni-rostock.de id OAA00639; Thu, 3 Aug 1995 14:51:09 +0200 From: Gunther Nikl Message-Id: <199508031251.OAA00639@honshu.informatik.uni-rostock.de> Subject: Re: gcc-2.7.0 -resident bug To: amiga-gcc-port@nic.funet.fi Date: Thu, 3 Aug 1995 14:51:08 +0200 (MET DST) In-Reply-To: from "gnikl" at Aug 3, 95 02:50:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 577 > [ baserelative addressing ] > > > register :-). Unfortunately this limits you to 32k of data) > > Well, what happens if you use -mc68020? We have 32 bit offsets since > the 68020; can GNU-C use them for baserelative addressing? This could work I guess, but I haven't tried it yet. The technique I described is a bit different from the normal "baserel" since all globals go into a structure. This structure will be accessed via a register taken away from the compiler. The memory for the structure instance however can be allocated on the stack. Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 18:32:19 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89882-2>; Thu, 3 Aug 1995 18:23:47 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26736-3>; Thu, 3 Aug 1995 17:23:06 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209167-1>; Thu, 3 Aug 1995 17:22:52 +0100 Subject: Re: Exception handling From: Christian Stieber To: walter.harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Thu, 3 Aug 1995 17:22:46 +0200 (MESZ) Cc: amiga-gcc-port@lists.funet.fi In-Reply-To: from "Walter Harms" at Aug 2, 95 10:05:33 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 555 Message-Id: <95Aug3.172252+0100mesz.209167-1+2145@hphalle0.informatik.tu-muenchen.de> [ support for exceptions ] > if you use amigaos-based exeptions i dont say major trouble > but its a bit more tricky for m68k in general because there > are (atleast) 2 differend stackframes. Walter: m68k exception != AmigaOS exception != C++ exception. One name, three different things :( Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 18:36:36 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90952-4>; Thu, 3 Aug 1995 18:28:27 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id QAA06180; Thu, 3 Aug 1995 16:26:16 +0100 From: Lars Hecking Message-Id: <199508031532.QAA29525@verona.nmrc.ucc.ie> Subject: Re: Exception handling To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Thu, 3 Aug 1995 16:32:08 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Walter Harms" at Aug 2, 95 10:05:33 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 324 > if you use amigaos-based exeptions i dont say major trouble > but its a bit more tricky for m68k in general because there > are (atleast) 2 differend stackframes. Could you point that out further? What are amigaos-based exceptions? Btw, we are talking language-level EH here, as defined in Stroustrup or Lippman. From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 21:18:16 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <89245-3>; Thu, 3 Aug 1995 21:17:29 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189467>; Thu, 3 Aug 1995 20:16:46 +0200 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA13625; Thu, 3 Aug 1995 20:16:42 +0200 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9508031816.AA13625@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: New pre-release available To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Thu, 3 Aug 1995 20:16:41 +0200 Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508030931.KAA07865@colombo.telesys-innov.fr> from "Philippe BRAND" at Aug 3, 95 10:31:56 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 641 Hi Philippe, > I've integrated latest Install script, Apurify v1.2 (although not integrated I have apurified two bigger sources (Fudgit and an example to readline & history libs) and it was a desaster. I never had problems with it, but apurify outputs lots off errors and I met in both cases the guru. Sorry, I know I am not of big help, I will try to analyse the problems, maybe I made a mistake. I would recommend others to try this tool. BTW., in your example you miss the AP_Close(). AFAIK apurify patches at least the mem allocation functions. It seems to be necessary to cleanup everything on exit. Thomas From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 22:39:07 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89057-1>; Thu, 3 Aug 1995 22:35:10 +0300 Received: by ceylon.informatik.uni-rostock.de id VAA01896; Thu, 3 Aug 1995 21:34:53 +0200 Received: by honshu.informatik.uni-rostock.de id VAA01760; Thu, 3 Aug 1995 21:34:52 +0200 From: Gunther Nikl Message-Id: <199508031934.VAA01760@honshu.informatik.uni-rostock.de> Subject: Re: gas bug To: amiga-gcc-port@nic.funet.fi Date: Thu, 3 Aug 1995 21:34:51 +0200 (MET DST) In-Reply-To: from "Walter Harms" at Aug 3, 95 03:50:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 689 > there is a ugly bug in AS ! > > this simple prg shows that pc-relative addressing is not > working in gas ! this adressing mode is often used by > resident programms and may cause some serious crashes > if used. Who cares that pc-relative addressing does not work in YOUR example? Please consider, that gas is designed to assemble *gcc output*, its not thought to replace a a native assembler! And gcc itself will NEVER output any pc-relative instructions. The deciscion to use a pc-relative addressing mode is upto the assembler (and gas will only generate pc-relative addressing in 020+ mode and only if the object accessed is located prior the use) Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Aug 3 23:20:21 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <88914-1>; Thu, 3 Aug 1995 23:19:46 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 3 Aug 95 22:19 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 3 Aug 95 22:15 MET DST Message-Id: Subject: Re: gas bug To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 3 Aug 1995 22:15:05 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1645 > > > there is a ugly bug in AS ! > > > > this simple prg shows that pc-relative addressing is not > > working in gas ! this adressing mode is often used by > > resident programms and may cause some serious crashes > > if used. > > Who cares that pc-relative addressing does not work in > YOUR example? Please consider, that gas is designed to > assemble *gcc output*, its not thought to replace a > a native assembler! And gcc itself will NEVER output > any pc-relative instructions. The deciscion to use > a pc-relative addressing mode is upto the assembler > (and gas will only generate pc-relative addressing > in 020+ mode and only if the object accessed is > located prior the use) > > Gunther > 1. pc-relative is a very important mode in resident programming. it allows code to be move without changes 2. the example should only show that pc relative as whole isnt working, the main problem is in my eyes that as dont produce any warning or error, it produces simply rubbish. 3. with asm() you can force gcc to produce any code you want, and its very unpleasent to have a so good asembler and then to see that one of the basic modes are lacking. 4. I have no idea how to implement this mode in gcc, but its already detected and should be made workabel as soon as possible. walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 11:12:20 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89149-2>; Fri, 4 Aug 1995 11:11:40 +0300 Received: by colombo.telesys-innov.fr; Fri, 4 Aug 1995 10:12:24 +0100 From: Philippe BRAND Message-Id: <199508040912.KAA00635@colombo.telesys-innov.fr> Subject: Re: New pre-release available (fwd) To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Fri, 4 Aug 1995 10:12:24 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1090 Lars Hecking writes: >From lhecking@nmrc.ucc.ie Thu Aug 3 20:22:04 1995 From: Lars Hecking Message-Id: <199508031822.TAA07448@mostar.nmrc.ucc.ie> Subject: Re: New pre-release available To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Thu, 3 Aug 1995 19:22:06 +0100 (BST) In-Reply-To: <199508030931.KAA07865@colombo.telesys-innov.fr> from "Philippe BRAND" at Aug 3, 95 10:31:56 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 344 > Please have a look at those archives, try to install it (Install script has No Icon for GCC-Install -> crashes if started from WB, probably stack problem (default stack=4096 to small); stack usage reported during install ~6k Missing " in line 489 Asks for gcc version (default 2.7.0) and then for gcc-263 version of 020 binaries. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 11:31:14 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89059-4>; Fri, 4 Aug 1995 11:30:51 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA17376; Fri, 4 Aug 1995 10:32:17 +0200 Date: Fri, 4 Aug 1995 10:32:17 +0200 (MET DST) From: Kamil Iskra Subject: Re: New pre-release available (fwd) To: Philippe BRAND cc: Amiga-Gcc Liste In-Reply-To: <199508040912.KAA00635@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 4 Aug 1995, Philippe BRAND wrote: > No Icon for GCC-Install -> crashes if started from WB, probably > stack problem (default stack=4096 to small); stack usage reported > during install ~6k I seem to remember that in Commodore Installer documenation there is written that Installer should have stack of at least 10 KB and that even more can be required for large scripts. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 12:15:30 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89624-4>; Fri, 4 Aug 1995 12:14:36 +0300 Received: by ceylon.informatik.uni-rostock.de id LAA03610; Fri, 4 Aug 1995 11:14:08 +0200 Received: by honshu.informatik.uni-rostock.de id LAA03482; Fri, 4 Aug 1995 11:14:07 +0200 From: Gunther Nikl Message-Id: <199508040914.LAA03482@honshu.informatik.uni-rostock.de> Subject: Re: gas bug To: amiga-gcc-port@nic.funet.fi Date: Fri, 4 Aug 1995 11:14:07 +0200 (MET DST) In-Reply-To: from "Walter Harms" at Aug 3, 95 10:15:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 760 > 1. pc-relative is a very important mode in > resident programming. it allows code to be > move without changes Are we talking about the same thing? Who uses gas to program the amiga in assembler? As I am already stated gas is designed to assemble *gcc output*. > 3. with asm() you can force gcc to produce any > code you want, and its very unpleasent to have > a so good asembler and then to see that one of > the basic modes are lacking. Bad programming habit. If you want program in assembler, go and use a native assembler and use hunk2gcc. BTW, value: .long 0 func: movel value,sp@(8) The above example will be converted to "move.l value(pc),8(sp)" by gas 1.38, but only that case nothing else. Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 12:19:49 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89345-3>; Fri, 4 Aug 1995 12:19:23 +0300 Received: by ceylon.informatik.uni-rostock.de id LAA03624; Fri, 4 Aug 1995 11:18:54 +0200 Received: by honshu.informatik.uni-rostock.de id LAA03515; Fri, 4 Aug 1995 11:18:53 +0200 From: Gunther Nikl Message-Id: <199508040918.LAA03515@honshu.informatik.uni-rostock.de> Subject: pure make To: amiga-gcc-port@nic.funet.fi Date: Fri, 4 Aug 1995 11:18:52 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 497 Hi! Recently there was a message on this list, stating that its impossible to create a pure make since 3.5x. I thought I managed to create one, but unfortunately this was only my weak memory :-( Sorry for that! The some mentioned, the problem might be pointers from the text section into the data/bss section. Indeed, such pointer really exists and I am almost sure, they cause all the trouble, when creating the resident make-version (nevertheless "-fbaserel" should work) Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 13:07:05 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <89263-4>; Fri, 4 Aug 1995 13:06:41 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 4 Aug 95 11:59:32 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2115cca1.u7t157e.ebbd9-robert@plukwa.pdi.lodz.pl> Subject: Lookin' for curses library Reply-To: robert@pdi.lodz.pl Content-Length: 712 To: amiga-gcc-port@nic.funet.fi Date: Fri, 4 Aug 95 11:59:32 Hi all! I'm looking for curses library that has the function wnoutrefresh() defined. Aparently curses210.lha from aminet and libcurses 8.3 from FreshFish doesn't have one. Or maybe someone ported ncurses library and would care to share it? Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 13:22:17 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90130-1>; Fri, 4 Aug 1995 13:21:36 +0300 Received: by ceylon.informatik.uni-rostock.de id MAA03786; Fri, 4 Aug 1995 12:21:11 +0200 Received: by honshu.informatik.uni-rostock.de id MAA04110; Fri, 4 Aug 1995 12:21:10 +0200 From: Gunther Nikl Message-Id: <199508041021.MAA04110@honshu.informatik.uni-rostock.de> Subject: 270-prerelease To: amiga-gcc-port@nic.funet.fi Date: Fri, 4 Aug 1995 12:21:09 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 224 Hello! I would suggest to ship some things in a seperate archive. This includes: - apurify - gcc-findhit - manual-browser Wouldn't it be better the manpages supplied to be already in the cat format? Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 13:35:31 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90099-4>; Fri, 4 Aug 1995 13:34:44 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 4 Aug 95 12:27:19 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2115d313.u7t157e.bb772-robert@plukwa.pdi.lodz.pl> Subject: Re: 270-prerelease Reply-To: robert@pdi.lodz.pl In-Reply-To: <199508041021.MAA04110@honshu.informatik.uni-rostock.de> (from Gunther Nikl ) (at Fri, 4 Aug 1995 12:21:09 +0200 (MET DST)) Reply-To: robert@pdi.lodz.pl Content-Length: 1403 To: amiga-gcc-port@nic.funet.fi Date: Fri, 4 Aug 95 12:27:19 On Aug 4 Gunther Nikl wrote: > > Hello! > > I would suggest to ship some things in a seperate archive. This includes: > > - apurify > - gcc-findhit > - manual-browser > > Wouldn't it be better the manpages supplied to be already in the cat > format? It would be better =o). In fact they should be in cat format and also in normal (ie without ^H) ASCII. If someone wnats i can try to dig up my old progrma that removed those annoying chars.... > > Gunther > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 13:37:40 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89946-1>; Fri, 4 Aug 1995 13:37:21 +0300 Received: by ceylon.informatik.uni-rostock.de id MAA03844; Fri, 4 Aug 1995 12:36:46 +0200 Received: by honshu.informatik.uni-rostock.de id MAA04199; Fri, 4 Aug 1995 12:36:46 +0200 From: Gunther Nikl Message-Id: <199508041036.MAA04199@honshu.informatik.uni-rostock.de> Subject: Re: 270-prerelease To: amiga-gcc-port@nic.funet.fi Date: Fri, 4 Aug 1995 12:36:46 +0200 (MET DST) In-Reply-To: <2115d278.u7t157e.2e9f6-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Aug 4, 95 12:24:26 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 511 > > Wouldn't it be better the manpages supplied to be already in the cat > > format? > It would be better =o). In fact they should be in cat format and also in > normal (ie without ^H) ASCII. If someone wnats i can try to dig up my old > progrma that removed those annoying chars.... Using the man-command from gcc 2.3.3 ^H makes no problem at all. Another question: Why is the termcap file found the base archive so awful big? Previous versions were _much_ smaller (eg. from 2.3.3 :) Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 14:09:03 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90326-2>; Fri, 4 Aug 1995 14:08:25 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 4 Aug 95 13:00:21 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2115dae2.u7t157e.56944-robert@plukwa.pdi.lodz.pl> Subject: Re: 270-prerelease In-Reply-To: <199508041036.MAA04199@honshu.informatik.uni-rostock.de> (from Gunther Nikl ) (at Fri, 4 Aug 1995 12:36:46 +0200 (MET DST)) Reply-To: robert@pdi.lodz.pl Content-Length: 659 To: gnikl%informatik.uni-rostock.de@plearn.edu.pl Cc: amiga-gcc-port@nic.funet.fi Date: Fri, 4 Aug 95 13:00:21 On Aug 4 Gunther Nikl wrote: > > > Using the man-command from gcc 2.3.3 ^H makes no problem at all. Yes in case someone has gcc 2.3.3. I dont have gcc 2.3.3 so... > > > Gunther > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 14:14:46 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90185-4>; Fri, 4 Aug 1995 14:14:29 +0300 Received: by ceylon.informatik.uni-rostock.de id NAA04023; Fri, 4 Aug 1995 13:14:05 +0200 Received: by honshu.informatik.uni-rostock.de id NAA04404; Fri, 4 Aug 1995 13:14:05 +0200 From: Gunther Nikl Message-Id: <199508041114.NAA04404@honshu.informatik.uni-rostock.de> Subject: Re: 270-prerelease To: amiga-gcc-port@nic.funet.fi Date: Fri, 4 Aug 1995 13:14:05 +0200 (MET DST) In-Reply-To: <2115dae2.u7t157e.56944-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Aug 4, 95 01:00:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 386 > > Using the man-command from gcc 2.3.3 ^H makes no problem at all. > > Yes in case someone has gcc 2.3.3. I dont have gcc 2.3.3 so... its a very small program, it shouldn't be to hard to include the original "man"-program in the 2.7.0 distribution (together with the man-pages). Funny to mention, that the man-configuration file _is_ distributed in /gnu/etc. Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 14:46:02 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <89114-1>; Fri, 4 Aug 1995 14:45:11 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id NAA06556; Fri, 4 Aug 1995 13:39:59 +0200 From: Jochen Wiedmann Message-Id: <199508041139.NAA06556@iss1.neckar-alb.de> Subject: Re: New pre-release available To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Fri, 4 Aug 1995 13:39:59 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508040912.KAA00635@colombo.telesys-innov.fr> from "Philippe BRAND" at Aug 4, 95 10:12:24 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 23187 Hello, Lars, > Lars Hecking writes: > No Icon for GCC-Install -> crashes if started from WB, probably > stack problem (default stack=4096 to small); stack usage reported > during install ~6k Yes, this is insufficient stack. The old GCC-Install icon (which can still be used, of course) has a setting of 20000 bytes. I add it again below. > Missing " in line 489 Ooops. :-) Wonder why this wasn't shown. > Asks for gcc version (default 2.7.0) and then for gcc-263 version of > 020 binaries. Fixed. I add the new version below. Regards, Jochen begin 644 GCC-Install.lha M(<\M;&@U+4\M``"!JP``.VL$'P(`"T=#0RU);G-T86QLD8P='(.Z[K(VW7>>] M,5\`>S!96=B)TDE)-ME7WF]6DEK8TB3#I+50J`]SO<=<XEX5MX%`]1;!)9)ZV.`7UH%S MMX-`O`O>'NUDC;:[_?[Z-7[FJCQ0RXM6U%,F1^":&.(O)VB]GQIDE'WVD?WO@ MCW.':1\-FR,-+,_@P(V:^QKHT]?NU]?W:_O=ZL6._V_W:7_T(^'>XT64+W-\B M^-RP20XID7HY$6,,/(_M[]MN/XK\,J,4D?)(_A0/E>D2E$L=Z;G?D3WT=$>-I M$#\2)$W899I(;F.9*(9D/Q7=8:?ACNPWNA6DCRXXKJ9$37TH"&<,J([Q_0N)= M_"F((LP(X,=S!#`$@0)BE2A\;X7AEOINHN+TDLGNEP>VO@Z-V,:T?3>^A,(]; M\B.92:4;+-E7J6HB.16C:;\Q<_D1'B+,UAS3H0$)MSE?TH';VZZB&(]@OQXAX MUB^-5':N>$+2N)1CE3>QX-16B#'(\EKB\._Q\2+&]Y4>2QP\-C>XO+WQCIK\D M8]J>9*M,APXL$(UL=>D?BFZ!T56A^/"UXK7%Y1TU&[:XM[Y70BVDN-):P'V)OO&K0)1NIF?AP2N0#Y4 M0NJ4"OJ(]OW.\CQORRHL$OD2E++#R1%- MGK6]9\7'M[FT.+\ZT4/X*_LX:22487^A$H=I#6UQ,W.D-QJC(!JCV:3+B3`(U M^T.!)K?QR_JSEGY%]'^3@L<7A]""^ZIE[N:OC?Z&H+W8?.4?/'R,BOMX3[-_R M/MT,!P+:ZVL)U4>S11`=@Y3:FX4Q/X4Z^SK^"&)^2%,OHZEWF+>IZEPIPQE$9 MQ$_:WQ6+/Q(#$,+]P):T]Z/V<.6U-$E-TYBB.2"`;E[E?7K=G#?;9PW[N.+*I MF";HQ1]]S?LJ9IOU+BW-[X['#9VN"Q\.YPEPRZF\_CP3=\*H&O>S1N>0I"V)$ M\2%I"1*(2<,7LSO7`^T()]Q7[]X()P?M9JVD;ET4`S0KF!^+E*EBCPG# MP4X0MX37\$,2AEKWE25MY MG5L8^3+O3W'B$]JZEYT>GV;MMIA552%0H7L<1UH_9P38.6YK]VK@BEJX88A1D MIA;5-UR:]=:) M[8(XKT/);QW&>1M-UE4_VNT<(H6$>GO;_%EU&LKVKP-&K=K2/RN9[+:]-/GQ2 M"C,.3;IC2[I8C2+?L(O"'N#`E^5+%V$JAJ)@P(K7QR6N@-;C+WTX,2'E7K,,X MK-H4N85[[<[J(\D$)Z6/"D6AHF`RPX8<#\E=&7@@UAV3=J4P ML:KG2TN^(GX\+H:OYHO-$66/DZYS3D$GYHD\YM8=H]9 MTRQ<<6#HHT89NMU)J9E/ZDX=;4EA,NZ%-)\[XOBA/L%3#"@\$#K`_`J^&+*ES=K#>"'E31LOWV,F[ M^TCK9#M19F.%].,&X7?F]3<^;9O:R>AY<`PN_+7B)/=&HO5<_>97@SL?GD,^[H>"XC?G5EUKLI7#UY<8! M*G+WTOD%_%4J^K*PQ08,8I,VYDFT31:'9"=E)%7P+35JW4RY'T-.S&2X9DVY4 MDXB11U1@]A43,:A_UFR,GG?TS89P[^:-G7J_V2GF6YVN&]93(`ZB);*I08&/ADTV)!9^V$ MC5%.!/3ZVOW$\MJ#XXY1))*Y;+=.4@'T>W"R(LR-4F?E:M$9KB],$+_"O(Y:9 M@]SPWP3H)7!%6W*?7LDJR=+6E6G;3Z:DW3%L"R"ECN#7?_ M\7L\KR]"`5O.$I:[0AB>ATG=MM],O7G!!R8SW/G%=2-W5;N-J\H@UR-\9*&!) MDYK4.>6N."V;_J,4(W#Y:<<@#MU.%TS=2XHQR>E3\[/IH-JD(?M:0LD&3[]R6 M6,ML]#1TO*YHP11!\N<$GK([U12W\&,4.CV9R6F: MUL/A8<55F26M\VC=O31JSK8.C!+9/\'\Y6"V MH%BI=&AUD;++$_"^-TADZ5@NL0;),0%3^40U'NGCKQRUTIQ+L2RO3L4B;TKI0 MH4(F;RY;$C?P73:TU1PZ9\,NJQY#L@^@T+F*8I=4'?46U0?H-?(%'"+*"Y*4B MU(N#O=?5EYFN9;F8^+RPXEEEP$W=0F_BKP+L<7M3&Y\?LRUT*T=4UT1W#HG.F M;)_6&*]'+6JF\?6ISZ&!7GIZ^1U5OZ6G?Y3,:6\]TB-+1"A4^1!EQ1A=#GU#> M)$53-C6J<&=1EK^81=8XC0$>2)*!(4&/\XI/17[NQ^A1JOYG.RAA=,6O1HC<3 MXC1HG_B&SV0MR4PZ%PMK+J5VZ%OEA]'3DPWNIXL\@2X#?M=!RTWN"1(@'N]V<"=!-*57/EW'(0F>]00M,J]QY2NDY4?%"#8HB^+6*LYN`W'O@H`U^Z08#?!5R M0F0JZO^-KW?CY[(<1D&Y3>-84)F83_YV>FC>NU4&&'9-;1>/B7?0\$D?RE8W3 M63HW[/;[:"L%`]1(M^9[XWLU]4:>/\:-CW@6I;LB1O4=Z;G`<.C=CQQ751]4, M,T#B."C)&"_+"3>N[P[FXBWO[O%Y+'#N=\X,2K-B["5_I0:ZL!>`#-AE9)N+I/PIB3((#?!CN8(8$>*$7/`KL'S$Y7L1>66^H\7+R M)>CF_?0F$J^V=Z?9//CA+\70@2T6^JOZ.PMZ1.3HWX\256*(Z*RR&$*T%"VH` M>P#&H\EKB\._Q\2+&]Y4!#G#8WN+R_:#_2?H[(6@:;`6(I'%G?X/+:WOAK'<_ MR74@'KP%5;JB+?VQ"QR?LMXS]RHA!C8A#9ED-'ORRP\D2%3I>^JV=E7:EL/[S M'4.TI1"[D8D9/MB$NNYS6.$:Q?9$=5VQP"[0`MB(ROK1C3J'N9]ZB(%_-3:%. M/==J#FTFS9ITD@F^BN?_1J3B7FH>,5'BSI-,+=R>S;;;`+&9)I'XI8)(3$N", M6A0.\NJ%,@\,NA/>)JP0CR)KE]>^;H+UORV]HQ_7U\RFWHL!1I='F_8[(U`.>O.=QJHWH,"H9A6E.;N9UJV4!&[,,NZBD2, MJS=;N-.&_C0KSB99-6:&"]LZPR5"S%+6Y((-4?M##"_3AGF4[1CZ0KT"M$'XG MN0YB:M%8&_ULK`M(IF7]M_2*-?O87H0?TB[?Q0BC.(7<@OQB9(X7?\E^$5#74 M*7O#B\^07=51G1'E9V>^X7:4,)DZQYGF"FBA8E_!YA;("41*K[E@VBZAB03,A M?0$_TI/>(2A4\(W-8Y<8]W0L8.3=GMCE6Q$;!@A4+RD9*9@6*.?-_EQ,2_$83 MF@X\_I&2UC9*/EQRS.VY1T"74DLCKLU/G%)D[@"MPCB2RC]E)S"?;=0J0-9S2 M'<2[+RX[UZ&"%*MQ6.$>9X&\)QIYTX;2D7N[B5*@;WBT*M-0JDTN<:9<3&;!S M!PM2$E!W;*:`:5)SR0S3"22&YYQ+K.N5R8R&NO"Q\Y3L)BWLNUQD+T6U9> MS*:Y>4B?W,;1'1T4<44:7L9BBC$Y,1A)!%X._11:.-2(<963!V.D,1$<4YM", M93+;IX41NA`F2*?EY&V*>ACLJ\P.M7!L9A'JG*+M!KJM"=1KGZRC%D79S0@PEZ[<_N80!_4LQD[]EVW:.6B(;*#L#FQ(:J0N<*YJ@,&[Q+L M&LF7%!L#>)QYAJ-RX"9G*?$0L[EVO.[FX+`J2>NK6Y[Y4^Q^&\OXFHF*J'.1&:6GGY!_QYZ[^;R^KU8=?G M9U_R9CLP4\#Q$]+?H8/ZHU1=1K,=?I8A0U`VGVT%9+?,BB?4?!#$^0Z1U2%+] MD,1(L>GL_,F6W^52;W5/63`LZY)C'$Q6P"64.7Q4/(U>;[[S22='9U%@CD1*[Q\_,%#Q;4.Z7^A#1[3]2'O;"'=:7$F"5Y6\]*%=)7J_2@_2^E!F7 ME]'&]=:"\[/4XOX3T9TNOJX3D9L;]UVI9@*M+0?3#/8]$MUU?VU7LW%#3[I3, MC#B\1S9,QS?3F:8EBL[V(H>;A^O0_\ND7/HTVJ+5].H58_U MA36"%OK+7V<$3(P?],A%13"YREM\1]&8/@;0%)6F*TVAI(P#]?T=[J7DD4]7$ MZY&NPQ[M@=.H!,8!0YLAFHT[+\14:%XJNKLJ32N/;#J)W%&*(LJ0`!!4JBF9O M\$KX\A&1TB.>2-51'M4T:147YU9];UT^'[@-_UGO3`-U073G`G,A\6P^"5Z/Y M[0(?(18P^*^S3?^ MX&"63N+@RG`4)UTW;!4TT[FI!HIN[5,U<`)?@4]+1$=TF755E@V6\;XP?I"YY M2(R?BB[F-&`X@3.TI!D^.5%HQJLGX.6*/G/3%Y*<-K* M8F?-Q9UWG-P9^($V0J'S+F&#\0`^IPQQO?IPR90P;.%W>`F^IS>906`O M`MJU%!@Q@H?1_?!LUHTX0`>I>^5Z@.`]S8:-^&G M(79CM1HBT3KS&/J[A$*TH3AG9!#$T1/H$P*(:!MRY&#ZKW*_>1X_`( M3&%]^0*ZEY42X@./UT>&/G2!`34$*83)(\(308K(42Z:C1QE5EU,:U>7:%+F" M+N$@@7ZYTX0[OCPEN+=#V-<<$SBTRVY)Q:?_["0L2\HL&CJV8>R$A+RMA'&1, MO#YD0W*\OM^Z,^J9)"3+"X/$\'59F`I@8L5^Z#>4%`)83=HZF(]SH1%7<'&5! MI5]67-]9VJ717GJ+"+3W^%&G_,)2+\SYMMO08L;P`,PAW7UWJTX&KV8/8UWG) M`JLYH^.'7(X\#++V>H]4SA@AY3K/C(3,ZBD,MUD/-B/,FKJ\^_>`TACD'"RTJ M]DZWZ=/`OPN6`WQG?[57U5N^*$M#VK!JC1ZXG&ZGUX_M]MF1-_?\V4CN?+!HT MV80;<2HX.#HK(?YGX-T51>T/*J))I MR;XR!TZ-3"^(JD2?:E19X.-5O*S)J2\+>L0JN9)D!,2HJ2I:[#!=E)PW)SJ2U M,<-86_^5,OF891\\<7M-XZ^.7+H0)\U`+GB8SE,MS',)E%S+,G#$6!E2I^4J? M;$4P@[^$G.(CBQ.^0[-SPK9%7SR?BN]&.*.QWP+;47#UJ4`R6NJ^1R"&%#OI# M,/T.9&YMD(]=+K@';'V687'$3D-A:&% M9!"2ZR=:R]I6#F%5Z!`^$F&6_T"_"'W4^=,`H'$$9074JT42X/UQC%K07T+@M M*ON*)RZ,?QQ<#45=K]-GS4AS\]GZZM!4`^3@K6A-3QHBQFJ@(@KO56/BH%?T? M:_U:Q79:#STO1;&,Z4!YE,)52\(>_IM$FAL&9/^?B,[H'8K$B^>^VE1!HRA_>[TKG(%OC2HSF-#C;V?0UV]4'H?MA+68\71N@ M1*" M-7,^!;^2P+`F*>KHA6BOF>W-[X['#9VO,2>^K3O";K:@Q^V1SAUZ81RXNS6N: ME/+3$5*B&&;M-?>\"^,%]UGXA@)1VV745:@E;:*G5DXF5EB([4I/>-MHBS?!U MPVM_AM<7E*A!*#+BDA!WA-T+O"A0O!DH3=C2=*)'M=V]^+V:*O219%+ M"FAM;UGQ<>WN.@SPJN.E29]9N"><]SEP]'#%/#KB$T,&U`2E$)W.T%3(ASLI4 M%'XL_(OC'R<%CB\.H*AOQ<=O)X]_P?=JPS)&I*[+V49,_>`[/`3!NHCG%,B<$ MD,R))P;SOVQ;>GVW))/JNBZ)*4X*8YH9I$DQM=OAU^XZ+W50P_\E_YDV?8F;I[QL]RF3FZ*F9P!/];D,V6 M2F'/S`AKNT&_%'-'5.XKJ-B>V+IZ.BK^>[G>URO*:,71V&G%D$FQ4XI7=T9O' MY[6QRR:Q')N$`1U.2-#:-&2?PP\C].*R,T3XIT$6G'9V?/7CL[9*/HQW3L'9A MCE+^K5J8GVGX+7$48N([6C+Y27E0UMEMAX+Z8.7?N2QTE$[*G%DUEXM#94NBN MV;RY0_+,GSS*KM:J[8]X]$\%#=:ION/@9IK'5V-XRS?DXZ>'?Q8B$`B;9K54T M^=+AFG+?AO38$WF.-Y)+2]79H\]:NXZ58[GWYYC"ZT!G'9W):R\'E"$._E:U0 MG1R0%YU(TGH@(2JED8`SZ5.X0J@+%Z`P=OV:_N5]=)'3)(EQWKT,$*@=;T:8NF;,%DGTRE*3*4((W+E_JXOYY@S@*H^:55/DB[T9 M"_=A@.F0!9E\Z:GK=(/Q/319$\'AS:?+M/_7>FLOYSU+?]P[EXXP(?]`!XI+! M+IMASPA!5TNT6)U68HJ?R!=M&*M_:EUJ/=V!()5LR*B8JZ++"`#T?10$=TUR0 M[#9MM1E^RWZS(1^FW\6@YXA:B68/TRMI^?BQ8#U\-7@K=\AA.T`%- M]3[0@3^^\J4$TP'*$&0S40WW""X5T0(BJ\.9OGPJ4WL4^=\F^:#!0Y(S\L)3J M.^=_H+K)%;Y[C1%/A,PBPI-8"N^-T2EK@IS!EE9W>\)YI@T&_CFCPAI=4/GG] M(<';HM`Z,@2_9IH+`LE_13(%/(6P30!X][L M5M-P^T]6JL].G(J[3JVGJ@`!M/LZGWZZO%O,%XKIJXS]#JN;/5Q7'YH+ZABX1 MGC%(:,0O8^C85@SP7/"(RJX7LKL@C#C#U5QPVD#%]3KU=OBJK(E5F8 MVI^H3J<96*/<7#VUDX+VZCP:WW(,6+:UF>'>9\-OB\"-;[?XL/M^[[ON[$_N0 M\&HSQ#X?:BCEF!ZC`*X*E8"/QZC,A]Y7PR+$,8T-6B^XO.;1>1Y+1`@-70T;Y M_!Q(\G=U_>]MZFO'RT'^CO6:@WRB_)1BU\((,!+/L'\Y],+!D,!7H\<5VNCR8 MBE+-4R2RI`RM&6+&!:JPXX)T$E,4Q.1$P#<#IB1C#+E\6(1CYI.@JI))REF2' ME<$'/%;2TM(`V/K3^I>*,H-#X;)BX!<("?MBF?&Y,#PR7N3&4I MJII1(R67J!C.9#*1HDIK?Z^!?0*@]W(ACZ;]JGNU-$Z\R95HB!(ZHY727EYHJ M])OVT5Y+:4!D>HV;:I[/F73R-*T?S:_HUOAW/'O_'N(_GBAP;3-3T,YYM>7/+ MX[-\SM)MD/YV1"7:JKD;2CKJ'\9*!7YS9<6RQQ+8@T8:>1-.QC<3>6[(N1JI\ MWXQD9A`Y>'%,E6I774YT@KOSL0-DFU^5/0C?WM:WJ;^[NC\@/A'YL^'TLKD5&%_JT`(M9O89A-B0K:L`D) M(-HJ]2)+6Z'(/Q#EOXQ&$W/O#Z>9YT?97N/B/7@&X0;KZ<%4Y_M(W/\-JWQ67 MYW.,N*&H^2QP[VCTY=()]VFTGZ=YW-[;M;OIXCX+6]M,\1:H!@[TXS*&Y*BQM[?JR._9L>+:;R MD58G1#TZ\[M-\19V'SXH<2=&X]*9K8>7W+?AW/%X@JI:7-:6_F5,9;2OWE02_ M.]VYXK>YDQOULE>ED;R]TS\=IV!NPJ$ MH4,^M94;4??)KOY>[CN>]O\73W>E,625S1A^.)JM.M.X81`-Y'UX`WW_7@#@6^O`&IW-@*5JS_.F@N$]J8A;#Z& MIEJ'NV52Q_[$F%$]WBABY>D21LK$=8XCL9^7*(UBAF+-2SN1[!RUA:2>,5/IE M>IYP9@,:!R/75,&CQ4B0Q:[MBA7.W9.747P%B$ZL:TWRJ9"#*RE]ULN>MBQL- M@2O0*,]'BAZ\[^P3<:E5UD"NQ]JY5D+I'8-B#:`<[)=B9,-HNOUA4;%3KTJBA M]68J@YNU*A2MPV>1W,'7BQ+$.R5H`Y-U_E6*6\JJD3+H*)[L[2JV^N\P"=E/& M&9D5,`M],E@E1\U(!/`1)YXCLP"XQV8-1\6!2-X%KA5E3R'@TI`EZMFN:OXN: M^;QE'BG1_4\&LKV+ILM?TC^C?2(^3GHOL;O=TAUR_/`C(S)$T*&"BSS(!;MD. M-.*NW<(&=P]DOIP[C,LXZ!;307Z]9HW&LWXG&XP1Z M@FCTA4LN`#9,("-.@#U9W^1#O:#35/;3J+7M?1?ZQ,\I_4SMIG@`$"0Q>7GO& M+^)F.@%["IZ>3\,.*BD75Y,<1>;M:3!'7U8O\(@\YL3^$$)EY[-B<.C4Y$Y]) M3O'Y?S8I/5B@"4TT]BO)^?#;IK5,HK1377ER/54SL\]_(2WY)=/JT>L> MP(M-WO3*O@+XS^83H>V/QL5LCWG]U0QPI*:,XKNZ93:L)*01SJC%:B.3M]M7O MP`QL9B`02D/(?@U`";D,230\R<'1V2PB+0T$!R'4DF6#HN,X$JG0GD._OEIYD MD`+4!E,!*1F+(8$4T[:XY]%)64C/;5*\YWP:M83JLY#WDY),_>5$DOZ$SJQM< M";??GI6U3%SFYE1]2E,,(UD$P$R_4R(?(G=Q3`_S/PX'[A''7$1PS(G\&,#:9 M4NHH:9@3(0UQU9K!#RIGY2?.3WHNS@0B*C<#$0%$-0Q0=")#LY. M$HO"^,$9*INXGFQE?ZMG7#LQ[).U7J4:^U&M^/G2)Q-=%J\:DKL8.O%2^_,]& MY4R^9ZG,$B>TH>_:K'#J*X*9)*O..R?F>WH_,\?/'>;)/J870JG>[#:I/3IG) M>Z7YIUL$#S#>B>-E`N2Y5,LZO)!!S9_*5VK'#^%.?TXXNOUK[76RFSHKK?60[ MY7IZ[(R>?!=;C"LOJ,Z;'+RL8ZU)=DS]79:DNTFLM2U5J2LR/4N>CA&3,MY:V MZ.`PY>=8J?^HY=LV$M^VXDQT1S+!F&9N4E`8)SE;);[BK4ZRH5I:BYQ=8+EL6 M=*29POXK;!;X'S:6W1O]\<^DP?'#5(*$$T.@.CV9T0NCKE.;Z=#]!D,8.[.4C M&T>;;6^GI\B9E#_:'FAJ`A[/O3T`%)9V;]ZFN"!BS^JW^2XZ7D9`?[)-2Y,T@ M\7%IK6U0#9K/OO.D5\"AC=A;: MD(AZT_U1*5Q<8;V68^H(/'$!)^5J&IGBQMC#9)%6:+9EA)TK'))2BZ:HWPX,C M"7VQX=#:Q>*>J$>Z4<5V<3G@O?UINTOT)KU%G,+,H/YL8J%[.XS0Y!.@GRD\F=+0&C"J#R8_YY(0MK M4+;P(,%T0*;S!")U0#;G5!3Q,LQXYOF0I4]D>UDQJ(FJZ6,AD)/G?*9\*7!22 M7=V&6^BSM^T)^DCMKN8U@E6G#%!@QW<[KEC'-'MQP2UIVRVYV0W&1CE=/W;'7 MWCWNZ(W\."5PEC0QPZ?[2HO]N;H*.RX,O;''\,?.P=2M,C7' MGR!J/5QO)PBWQQB\GZ$%8&2G.P4RT\J[%%;WS0R1Q84B+!S"NT)9DJ\%O%U*L M.\>P/W(^9--B,0<7Q4[T:IJ0\`-]%?2ID+7@%52Y:[DM`.&80NR5:G*_>+Y0[ MRSAM1J^6,9HI<2H)3XY=52X4D2EY=FL1*#E<48@W7(<$,PAP,(F3HZB/9V67Q MSLQU(>;#7%9"JP#?P%UVFSOCCY1R$N<9%^\]],0W%^2"^31RZ4MV:52K=**22 MJRY+Z(3W@<>E1S0A)0:I)Q%E1MHFVJ:(ZK-S7:Y:N#(;EO8XCL8 MT0B:J.?-1T'07MH+'Z9@XH'E2=5.5,HZ/&!4U&),8:+0=U8,^=)@V::X)7>RI M366S+V2(2N_PNJ0[O6G-+?!6QF;%!)$IK5&4BGF>Z#I":,_"RZAHF;'Z=]5X* M'=.,TQ`A]$(9?7T:4W:%WD-&=R7EN>7#"&(KL(2C@Z,N]9:5C24EJA=4\J/3N M<0.NJY=A)OU^>;2 MN`*PH?)Z,4(-;J4\(;2_5""&G>`/="QH6"2J5V2H1%2DDANJ8A=`'TEP`T+H" M.L#\TP]4`E.CL)/APC=.AU3,\=[RZB=41:B&Z6QE.9F3$R5@Z5#I9+H;19;3/ MVFFQ_(L4=PWINIK=\KJ4?A3:"Y3G/')RE"7@7G;N8LB9Z?$`>/`P;!X$@6J#+ MD8T4]!?P%/PZ#GE4'+[,Y:B$$\Y!3LX$ZAF)<04RF-.+^!;-MQ MF(.ZC9"A"JAAPW2AB+N:3`F+-ZZQ!TR'MJFN5SZ* M`0CGF\KVL]43GWW[*Y)1Y`?=?:!)P\Z-7\`E$">G]N4AN;/PF?M430?.Y"I(Q ME`O8O,+0.H43<+]!4*A8$I#)2DX;D_W/BST#SB*VMD]8&"_3[8[GRC.9$SD00 M7F)UKW/&)S\K>!78X'J?73X":U=C)A?=-^LY=[F4U3WQRG#\"_FMYX.QR#G6C MJO5NG07JX54].$'$R=X+7%8WMM')%C8TS9.K+)2-%$[3`>=->T"\K;W$EJZ<[ MM^&],9@$IM8@(`$77G&`(=,?;_ M<`&H(94K9Z:@JT0>\<4/X,:K&M:O#"YR'@$8E*=VJ)+K(:JX@YR-S'OR]%!6D M[_"1SG[O3(]M3O_K6U5)I804'9B;R4BV<(YU9Y\QE'_%8.VF'\BP\29`J3"+_ M&,20"I"Q(W/G*P3FA7L2##I2^:UA_R4;5T.E1\_J:I&?Q";G_%+]F.*]#R8Y3 M/]*7H%Y[_^EVGH/SMV61:L[C05^M1C*"8Q?H4%D"O.DMS/R`&O_^%HX'>X8FR M4DW]B2>UIV;Z8.7?EGJ4M,K.PD22%;E^-5X'69B`T>:&^T4JL&2=$&2VE,7:` MTZ:]W7K.L*Y$XA!2M3,MTEFBATKBYFMD=8KPN>MYL[J[<5Z48-P8N=,PW8KTEUKLLW:7-)Q_2JQ`%PJHYR5W MZ'R^SIVN3TVJ:KEOL]!V.?N\MQMX[A!\6Q]?#:06*>T6MBDK!3K#@?GBOJR?D$J M`J_Q;NH@6#2]1NXL*%5'TCK1\7KNWRQ.0SC5MI&0^;H> M/6$'(:U)[,1O`CRAEP1Z(,!J`C,BY1^+DBL6OU#P*+<(T-CHKBL*CA+(_.@JA M/,$]`J=%D<9%&U%@-+!)#BF!8JE0Z"LH[!I&.=.U?Y8X`5]5^>%-T`D,7P1"+ MC&?DU7\%RN!S-=W%VOF:W]+6V1CVU%#,!R"KDA"ZE=!$(&%_H#8$F.)`O]WYO MC[%-#A2WG3:)QMEB>BZE%SZZ32PYU8<;43T*:"[)1&*Q^\`UB=.!T8@$*U#+& M([;S$5@EM;C(NAC:TL.2#1P(38R)!)U8#BO.&D0\&&+<2J8@<;!%Y,Y5!(%V= MJ>(I)7FTC%?N?!!'@CPW(ZX>#3+T$1Q11\U>]([&WH22Y-M(V=KN;.OK;&OWE M:^SL(X7\('>B$?V'GV`R4CP>"VQ=8@9`)L4M;&@U+0("``"^!```78"+'@``H M$$=#0RU);G-T86QL+FEN9F^;P`&L8F+:QM23[MWFVB+NZ&@JO=`8&!$;!T3%< M.&W98&IC)S$7D1@(X7&VA81O@M$06&L-1D6]# M(\>YP#A<)UED.E\VGAT?.T-^X0NZ-@G0UPL#=)U(I:.`4+\AS@(Z#QQ%2_?^E M%`@4,4\_;H@)0YX'1_(PO$5W"BO>8.R>4:QL%2T9"P-%FI.(EZJ+SQLM$\_16 M$D>5H^W_"R1,4+HIBN[KF\UCX]#;,HQR"+ZKR9'+,?0?C'06/R_@KA^`4O$?$ M\5W=6!7/9=Y"5Y*NBR)5K=8-PO>O0.).\\?#^APN%=W7#I?-\.AOD^#Q;>YWF M=C8[^T:\I7W/FUM:W-JVM+4MSR]8^K'J]BW/V;6OI3=JUKS:EH`BU2UL:#4MC MR@<``)H3``#,8;,>`@`,9V-C7V=E=&5N=BYCX6$&4G.[T;3DGGFC^`/X56C8C M.!`WMWE:PJ3LL)8E"`I)#4*E43&\]&]A[K&VVW[@W5@`,CKN/(:0T.C?=]@%P)]%V`0;/`XZ;,:&0'XD$$B MK5JQ`5F+/I0?)ED7LL!P^OU_B'*@Q@P1/R=SB#!RQ2PO.2'BA9"Y"[OK+8=Q$@1/A;O8@LV1[5>!=3Y$>.8CM!IBE!UR$4*>/'(@_9+()!D!R% M%[@%$#LTK$'?916@,<>]`:#(C'W#B9`3\NY(20H"+.0*PLY#I"!R2D(\%;I46 M)X#PI1_+%G%,M8,`<& MO/?!L.AN_AN6<5UN^'1BO]'/@M;X!@,2(&6_RSE]+>19`\:1P\$8K)U"Z>,4- M2@>#*YH,+KW3'T"B#@.C!7]W'+.010Y$JQ-`LT$:D*5!M9Y^CJN7K8I#Q7;HH)N\"RWH/"[!*\8...1Z`_9OY?;KX3 MSQ>7$@\.37QNR:1`1&/83'FM0W#+FZ5=5AJE8K=FSCL\][EN0 M6\=YOFI4CQYPVQAC]@M:X!?GOJ=KMT,)F$[EZYAQW;EZUCNVKUO#\`_I8]?Y4 M:^V]BYL?2W?P!^'$39YNI*I-C,1I7*8[2R`PB2N06H1=.3_QG@>H](3"TMYD` M(S_V,P3.`ZTL_&"1?:40!YOT_0!HW:B,P%<%ZB2P'&"ZB8PP'TF)-;P$Q9;KE M]^/C#A:#_7Q$(D#$:09R"")U>9%&?)$&&O\$+4IDZ.?]^$A%^LYD(B0OMYDH, M1ML-?_(1OF>1?BL?^&JB%WA_/RGM]ZRRI'JJ.0QT7AD\86\)/4\;2VJ6)!HY@ M8)%2R%(2=I0EP;HWF!8Q52G51<&P[F&Y^-I>#2FCY'*ZZ:.,;,@U3AHXSPW+A MJ+0OJ\43)V:U91-F!&&IU)G/>`KU%50%)J&M2#D`PBA-K.&U50!28N6% MY=M!NOYVEJVN@X5(D5G3"0N_G'A?&YU"OXSL,AMHVYDNG8^J*2Z,S-TT.0;+; M_)LG:X.)JD/@U!-AKR)%ZBCQX4`J"$ITA$2BELKH&P@NTTE&JU#R6J/0JG+*Y M:F!"%8FHVS#9:SCC!#;E*7UX:%GS4D&^($+2*U:JC87.SL6YFI4&1$"0OZK^Y MJC_$^N2&#.3.@5_]CJA-$M\8)HTG8-[]3+]6\U_,%?SL$P5,!Z"IC_2;)E[!@ M7+M:5"Y[U0=@D^]X_WP=*-HB`8#"XZ"67I\:06OP_(-KD#I1XE(CU]>Q MY2X"A2YRH\$2LF^F!$`_9,:_(!2(TY%/>*Y84+?V`4;C%*Q>8)X(Y7KT]K7G#W859)_AS@BI3P"'EQM4K(>-,W M\*Z9_ZD8WMY6*4HXC05$:GX9AHJ%:GF)\2C=Y-Q7!M4%8>GP*J:+],#2D4Y`S M(&*(HE&YA'"COGRL052:/DA+/T\X:YG*$.2%KT40,_7ZB<#8HG[IENJ7O4Y.` MI19E&J8!L48>.A/-2._\G#Z7(#O4L"3CM'+11G4/4BX5,`YG.U3,1T^]"2)9' M";.@I8!0H*6"_=@FM<:J^97)6==IEF?,;9#AGJR55W`W:J[S>B(4@E2R<4D>' MESKCB,XH!2_YC>O-'#N2*UT2IAA33%VDGGXS&GY;\T;BL9A>:L>F-+>X6&)IF MDB4GR&$Z$&P9)?2&*6`[,?J;GHQSYH5A(#N?3^J.LIN]O*8'L+/I*\#Z8Q(S*=4CXGG6>?U2J+%"X M?CE=F@'>^^G[I5/)?JVQ/3'OI,'CBS$O:M2P6YU9`U"D3*!7X4JA[9E9KUYLV M_M5]&54K#L#BF/1[4\CY0PDZ3-G7V*TG*0*EE8HQY9LIC8N_@C35MR%W1 M?'Y:\Z44,+-'ISW]O#\+F`LBJXW[KMK&/G>M=-J_C]]KE'&(]^VE%)FJ@!P5] M+6QH-2U3!P``21$``-EK!!\"``9214%$344,U07+Y%)%;S/-NT\R[SLO,UZ_CE_[UW;;>]W3A(%"E$489 MD;P':QMIOPVPPQTELKK)SXXMMM/`HUX.OQ9[>%YZ2L/QZQ[F=N6(Y>DM[CLN= M:]_\GG7N;AH;;JJL-GNOM@VP_]\!C.W5#+$OM[N[1WR53/X?+\1$QGMVNB3

$70>7"&1;VCTXPHH"A@RPY_2J;(:PFBCMAE;86!WVMK-4.?DN MZ.+G[/S9W.6_:ZO:0[>Y\-[V!0!D=66S9P+JC###AF#JV$$5NB487&6LVXY8$ M'&?:B9W(RX]*]QF#0LL"==>);!M,Z0?BX1W1@4;H2DB9>_(PR@]4T1O5MGF'U MT8&#;'<=F7O$+!WPU\G`JZ2K^F([V_BT#&X":0E<6@K(!L'PQ*E M492$5#\L3P>VU8:QSEB/`OR"?;C.(R]XD@G7@$L)4!*4G@LMEC!-C)JRL`'N> M;N-19""DFS,NZ%UT+(!`?V\"VF@B@_CA`X!SKA?P$()K`!(@0PR11/RO.O$>^4_RN1X!$)Y-'VQ;0P M8NR9=*B]AXH'1!;J"9U M"2:P49'@*_"&JT[HI`RR#_IQ*UVXV(,`.V_947W\".YKK2;98`61!`Y`L_2@# MVSF&H-KM;X@%=&;$$[':]9I!_/,,J-^(^;]IJ1%((QB[8]B35D92(H$:T@4@< MH,_,)90"!%%$,<\261#A<88Y7S-FP,+#?%(Z1`0P4`1LWF0^=`A&I5>G(].8#+I[.*0Z<']F8NU*4FM6-;JAG MXR%Y^W,7K\G8@1>L&.G`\N<#\\@]S?5#SY7WI)]"](RBNPC5"5X[V5P]$0*E6 M!+"H.SH]B,K_I[]'_?R55U+1@25K(G:@ZFB=0+#C`$60WWG6K0HW&-G58>MN0 M5N*SQS5/EE]LX544I9BB,*BR>P++ ME$"%<.-4W.GQU=?G]KNST=G'PHD64X?P]*WO-C\M(\(85D_E1SNNZO[/W=G9X MV:*]5V@-OL;9"/6K+U%U>N4,\P&/R,8MS93!__&%_P7LKO,ZPR3V$FDP@K,&, M[QUH:U%S47:##ZI^3Z`Z7T<>I.XOGD_#Y4JM1HVF!BH?@=@-.4D-U>"8*4\1Q M-,`2$JV\F'2JCSL?(1*D\Y,0'\IA@V+9.5LA/XYLHMK7RY7E_9M[:8TL:A%7B MOZ%]%PQ,;13@Y/O&'#0EO'I%_B(#.G!%\9<9F,[?DD.&`G>[6N\G0N:.@AZHW ML/WY.OO'#5*T&UD^A8XPUXS07U60^J6*M2^Y5FT M2&J8G"NU)H5LM?*"T@M:DN.\P@)Q?.L>+V<@'A_^(#$>W/\GE6CHN$AH13RH` MVYRV?7]<_NP?):.\1$!]1?S#$H_?-9\M"-,D]S\CF(R.)WEZ4G%RO!*.CC0"1 MZ-JEO3G>0E0M_]0I2PATR+%P9YL5\8#RKL/\780?>2L5H9U9B?&)%,.?H ME(Y;G,]F:)>;L4HVTP`UR`!/:A!8Z>BZ29UR1$<@!Z0T&8I)S8_+,Y1;GY'7S MDGK^;DI-NFE]\;4I=0R>W1^>N!\]QAOQV(4:096-L'[%VH$G>FL"EE;UTR8YF M3\1G_FRW.LG3<0"_AJC!,6:IG;SC:NOM/THN.-V3B,_IB(Q5YDW-`7ARV?$HS .*?J_I"O:*>/]YZ:#``#!E end size 16124 From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 15:07:43 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90464-3>; Fri, 4 Aug 1995 15:07:12 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id NAA20418; Fri, 4 Aug 1995 13:04:56 +0100 From: Lars Hecking Message-Id: <199508041207.NAA00629@mostar.nmrc.ucc.ie> Subject: Re: Lookin' for curses library To: robert@pdi.lodz.pl Date: Fri, 4 Aug 1995 13:07:52 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <2115cca1.u7t157e.ebbd9-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Aug 4, 95 11:59:32 am Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 414 > Hi all! > I'm looking for curses library that has the function wnoutrefresh() defined. > Aparently curses210.lha from aminet and libcurses 8.3 from FreshFish doesn't > have one. > Or maybe someone ported ncurses library and would care to share it? I am indeed working on ncurses. make goes ok, but make install.data fails on installing the terminfo database. I have no idea why, but I'm working on it ;) From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 15:15:56 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90870-3>; Fri, 4 Aug 1995 15:13:23 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 4 Aug 95 14:05:25 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2115ea22.u7t157e.c5469-robert@plukwa.pdi.lodz.pl> Subject: Re: Lookin' for curses library In-Reply-To: <199508041207.NAA00629@mostar.nmrc.ucc.ie> (from Lars Hecking ) (at Fri, 4 Aug 1995 13:07:52 +0100 (BST)) Reply-To: robert@pdi.lodz.pl Content-Length: 863 To: lhecking@nmrc.ucc.ie Cc: amiga-gcc-port@nic.funet.fi Date: Fri, 4 Aug 95 14:05:25 On Aug 4 Lars Hecking wrote: > > > I am indeed working on ncurses. make goes ok, but make install.data > fails on installing the terminfo database. I have no idea why, but > I'm working on it ;) Well it's nice to know =o). If You finish it let me know, it might help me to create better port of ncftp2.0.7 (if i ever manage to get it to connect to anywhere) > regards, Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 15:18:52 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90583-3>; Fri, 4 Aug 1995 15:18:29 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 4 Aug 95 14:11:04 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2115eb75.u7t157e.6dc4f-robert@plukwa.pdi.lodz.pl> Subject: Re: New pre-release available In-Reply-To: <199508041139.NAA06556@iss1.neckar-alb.de> (from Jochen Wiedmann ) (at Fri, 4 Aug 1995 13:39:59 +0200 (MET DST)) Reply-To: robert@pdi.lodz.pl Content-Length: 696 To: wiedmann%iss1.neckar-alb.de@plearn.edu.pl Cc: amiga-gcc-port@nic.funet.fi Date: Fri, 4 Aug 95 14:11:04 On Aug 4 Jochen Wiedmann wrote: > > I add the new version below. Somehow it is corupted. UUdecode says short file and extracted lha is corupted too. Could You correct it and post again? > > > Regards, Jochen regards, Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 17:06:23 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <90534-2>; Fri, 4 Aug 1995 17:02:30 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id QAA17015 (8.6.10/2.4); Fri, 4 Aug 1995 16:02:36 +0200 Date: Fri, 4 Aug 1995 16:02:36 +0200 From: Olaf Seibert Message-Id: <199508041402.QAA17015@septimius.mbfys.kun.nl> To: amiga-gcc-port@nic.funet.fi, gnikl@informatik.uni-rostock.de Subject: Re: 270-prerelease > Another question: Why is the termcap file found the base archive so > awful big? Previous versions were _much_ smaller (eg. from 2.3.3 :) Be glad it is big! It contains many terminals. The current NetBSD termcap file is 178902 bytes long. Some people actually have terminals hanging off their Amigas. I for example like to read news (with nn) with my terminal (ADM-12 and Wyse 85 (vt200 clone)) in bed... -Olaf. -- Have you indecently fucked this Exon idiot and his allies today? ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 17:25:56 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <89239-3>; Fri, 4 Aug 1995 17:25:33 +0300 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id QAA19890 (8.6.12/7.4b-FAU);; Fri, 4 Aug 1995 16:25:07 +0200 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA14906; Fri, 4 Aug 1995 16:25:05 +0200 Date: Fri, 4 Aug 1995 16:25:05 +0200 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9508041425.AA14906@pctc.chemie.uni-erlangen.de> To: rhialto@mbfys.kun.nl Cc: amiga-gcc-port@nic.funet.fi, gnikl@informatik.uni-rostock.de In-Reply-To: <199508041402.QAA17015@septimius.mbfys.kun.nl> (message from Olaf Seibert on Fri, 4 Aug 1995 16:02:36 +0200) Subject: size of termcap Hello, if you think the termcap is too large make a safty copy and delete all stuff not used/needed by the amiga. Then you get a small quick loadable file and your programm may use less memory because its termcap table may be smaller. Servus Thomas -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 18:54:31 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <89933-4>; Fri, 4 Aug 1995 18:53:37 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id RAA10819; Fri, 4 Aug 1995 17:49:01 +0200 From: Jochen Wiedmann Message-Id: <199508041549.RAA10819@iss1.neckar-alb.de> Subject: Re: New pre-release available To: robert@pdi.lodz.pl Date: Fri, 4 Aug 1995 17:49:01 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <2115eb75.u7t157e.6dc4f-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Aug 4, 95 02:11:04 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 22501 > > I add the new version below. > Somehow it is corupted. UUdecode says short file and extracted lha is > corupted too. Could You correct it and post again? Damn. :-) Here it is. begin 664 GCC-Install.lha M+0@M;&@U+4\M "!JP .VL$'P( %T=#0RU);G-T86QL7$=#0RU);G-T86QL MD8P='(.Z[K(VW7>>,5\ >S!96=B)TDE)-ME7WF]6DEK8TB3#I+50J ]SO<=<XEX5MX% M ]1;!)9)ZV. 7UH%MX- O O>'NUDC;:[_?[Z-7[FJCQ0RXM6U%,F1^":&.(O M)VB]GQIDE'WVD?WOCW.':1\-FR,-+,_@P(V:^QKHT]?NU]?W:_O=ZL6._V_W M:7_T(^'>XT64+W-\^-RP20XID7HY$6,,/(_M[]MN/XK\,J,4D?)(_A0/E>D2 ME$L=Z;G?D3WT=$>-$#\2)$W899I(;F.9*(9D/Q7=8:?ACNPWNA6DCRXXKJ9$ M37TH"&<,J([Q_0N)_"F((LP(X,=S!# $@0)BE2A\;X7AEOINHN+TDLGNEP>V MO@Z-V,:T?3>^A,(]\B.92:4;+-E7J6HB.16C:;\Q<_D1'B+,UAS3H0$)MSE? MTH';VZZB&(]@OQXAUB^-5':N>$+2N)1CE3>QX-16B#'(\EKB\._Q\2+&]Y4> M2QP\-C>XO+WQCIK\8]J>9*M,APXL$(UL=>D?BFZ!T56A^/"UXK7 M%Y1TU&[:XM[Y70BVDN-):P'V)OO M&K0)1NIF?AP2N0#Y0NJ4"OJ(]OW.\CQORRHL$OD2E++#R1%GK6]9\7'M[FT.+\ZT4/X*_LX:22487^A$H=I#6UQ,W.D M-QJC(!JCV:3+B3 (^T.!)K?QR_JSEGY%]'^3@L<7A]""^ZIE[N:OC?Z&H+W8 M?.4?/'R,BOMX3[-_/MT,!P+:ZVL)U4>S11 =@Y3:FX4Q/X4Z^SK^"&)^2%,O MHZEWF+>IZEPIPQE$Q$_:WQ6+/Q(#$,+]P):T]Z/V<.6U-$E-TYBB.2" ;E[E M?7K=G#?;9PW[N.+*F";HQ1]]S?LJ9IOU+BW-[X['#9VN"Q\.YPEPRZF\_CP3 M=\*H&O>S1N>0I"V)\2%I"1*(2<,7LSO7 ^T()]Q7[]X()P?M9JVD;ET4 S0KF!^+E*EBCPGP4X0MX37\$,2AEKWE25MG5L8^3+O3W'B$]JZEYT>GV;MMIA552%0H7L<1UH_9P38 M.6YK]VK@BEJX88A1IA;5-UR:]=:[8(XKT/);QW&>1M-UE4_VNT<(H6$>GO;_%EU&LKVKP-& MK=K2/RN9[+:]-/GQ"C,.3;IC2[I8C2+?L(O"'N# E^5+%V$JAJ)@P(K7QR6N M@-;C+WTX,2'E7K,,K-H4N85[[<[J(\D$)Z6/"D6AHF RPX8 M<#\E=&7@@UAV3=J4L:KG2TN^(GX\+H:OYHO-$66/DZYS3D$GYHD\YM8=H]TRQ<<6#HHT89NMU)J9E/ZDX=;4EA,NZ%-)\[XOBA/L%3#"@\$#K _ J^&+*E MS=K#>"'E31LOWV,F^TCK9#M19F.%].,&X7?F]3<^;9O:R>AY< PN_+7B)/=&HO5<_>97@SL?GD,^[H>" MXC?G5EUKLI7#UY<8*G+WTOD%_%4J^K*PQ08,8I,VYDFT31:'9"=E)%7P+35J MW4RY'T-.S&2X9DVYDXB11U1@]A43,:A_UFR,GG?TS89P[^:-G7J_V2GF6YVN&]93( ZB) M;*I08&/ADTV)!9^VC5%.!/3ZVOW$\MJ#XXY1))*Y;+=.4@'T>W"R(LR-4F?E M:M$9KB],$+_"O(Y:@]SPWP3H)7!%6W*?7LDJR=+6E6G;3Z:DW3%L"R"ECN#7 M?\7L\KR]" 5O.$I:[0AB>ATG=MM],O7G!!R8SW/G%=2-W M5;N-J\H@UR-\9*&!DYK4.>6N."V;_J,4(W#Y:<<@#MU.%TS=2XHQR>E3\[/I MH-JD(?M:0LD&3[]R6,ML]#1TO*YHP11!\N<$GK( M[U12W\&,4.CV9R6FUL/A8<55F26M\VC=O31 MJSK8.C!+9/\'\Y6"H%BI=&AUD;++$_"^-TADZ5@NL0;),0%3^40U'NGCKQRU MTIQ+L2RO3L4B;TKIH4(F;RY;$C?P73:TU1PZ9\,NJQY#L@^@T+F*8I=4'?46 MU0?H-?(%'"+*"Y*4U(N#O=?5EYFN9;F8^+RPXEEEP$W=0F_BKP+L<7M3&Y\? MLRUT*T=4UT1W#HG.;)_6&*]'+6JF\?6ISZ&!7GIZ^1U5OZ6G?Y3,:6\]TB-+ M1"A4^1!EQ1A=#GU#)$53-C6J<&=1EK^81=8XC0$>2)*!(4&/\XI/17[NQ^A1 MJOYG.RAA=,6O1HCN]V<"=!-*57/EW'(0F>]00M,J]QY2NDY4?%"#8HB^+6*LYN M W'O@H U^Z08#?!50F0JZO^-KW?CY[(<1D&Y3>-84)F83_YV>FC>NU4&&'9- M;1>/B7?0\$D?RE8W63HW[/;[:"L% ]1(M^9[XWLU]4:>/\:-CW@6I;LB1O4= MZ;G <.C=CQQ751]4,T#B."C)&"_+"3>N[P[FXBWO[O%Y+'#N=\X,2K-B["5_ MI0:ZL!> #-AE9)N+I/PIB3((#?!CN8(8$>*$7/ K ML'S$Y7L1>66^H\7+)>CF_?0F$J^V=Z?9//CA+\70@2T6^JOZ.PMZ1.3HWX\2 M56*(Z*RR&$*T%"VH>P#&H\EKB\._Q\2+&]Y4!#G#8WN+R_:#_2?H[(6@:; 6 M(I'%G?X/+:WOAK'^JV=E7:EL/['4.TI1"[D8D9/MB$NNYS6.$:Q?9$=5VQP"[0 MB(ROK1 MC3J'N9]ZB(%_-3:%/==J#FTFS9ITD@F^BN?_1J3B7FH>,5'BSI-,+=R>S;;; M +&9)I'XI8)(3$N"6A0.\NJ%,@\,NA/>)JP0CR)KE]>^;H+UORV]HQ_7U\RFWHL!1I='F_8[(U .>O.=QJHWH,"H9A6E.; MN9UJV4!&[,,NZBD2JS=;N-.&_C0KSB99-6:&"]LZPR5"S%+6Y((-4?M##"_3 MAGF4[1CZ0KT"M$'XN0YB:M%8&_ULK M(IF7]M_2*-?O87H0?TB[?Q0BC.(7< M@OQB9(X7?\E^$5#7*7O#B\^07=51G1'E9V>^X7:4,)DZQYGF"FBA8E_!YA;( M"41*K[E@VBZAB03,?0$_TI/>(2A4\(W-8Y<8]W0L8.3=GMCE6Q$;!@A4+RD9 M*9@6*.?-_EQ,2_$8F@X\_I&2UC9*/EQRS.VY1T"74DLCKLU/G%)D[@"MPCB2 MRC]E)S"?;=0J0-9S'<2[+RX[UZ&"%*MQ6.$>9X&\)QIYTX;2D7N[B5*@;WBT M*M-0JDTN<:9<3&;!!PM2$E!W;*: :5)SR0S3"22&YYQ+K.N5R8R&NO"Q\ MY3L)BWLNUQD+T6U9S*:Y>4B?W,;1'1T4<44:7L9BBC$Y,1A)!%X._11:.-2( M<963!V.D,1$<4YM"93+;IX41NA F2*?EY&V*>ACLJ\P.M7!L9A'JG*+M!KJM M"=1KGZRC%D79S0@PEZ[<_N80!_4LQD[]EVW:.6B(;*#L#F MQ(:J0N<*YJ@,&[Q+&LF7%!L#>)QYAJ-RX"9G*?$0L[EVO.[FX+ J2>NK6Y[Y4^Q^&\OXFHF*J'.1&:6GG MY!_QYZ[^;R^KU8=?9U_R9CLP4\#Q$]+?H8/ZHU1=1K,=?I8A0U VGVT%9+?, MBB?4?!#$^0Z1U2%+D,1(L>GL_,F6W^52;W5/63 LZY)C'$Q6P"64.7Q4/(U>;[[S22='9U%@< MT-'*XC+CD1*[Q\_,%#Q;4.Z7^A#1[3]2'O;"'=:7$F"5Y6\ M]*%=)7J_2@_2^E!FE]'&]=:"\[/4XOX3T9TNOJX3D9L;]UVI9@*M+0?3#/8] M$MUU?VU7LW%#3[I3C#B\1S9,QS?3F:8EBL[V(H>;A^O0_\ND7/HTVJ+5].H5 M8_U2-51'M4T:147YU9];UT^'[@-_UGO3 -U M073G G,A\6P^"5Z/[0(?(18P^*^S3?X&"63N+@RG 4)UTW;!4TT[FI!HIN[5,U< )?@4]+1$=T MF755E@V6\;XP?I"Y2(R?BB[F-& X@3.TI!D^.5%HQJ MLGX.6*/G/3%Y*<-K8F?-Q9UWG-P9^($V0J'S+F&#\0 ^IPQQO?IPR90 MP;.%W> F^IS>906 MJU%!@Q@H?1_?!LUHTX0 M>I>^5Z@. ]S8:-^&(79CM1HBT3KS&/J[A$*TH3AG9!#$T1/H$P*(: M!MRY&#ZKW*_>1X_ 3&%]^0*ZEY42X@./UT>&/G2! 34$*83)(\(308K(42Z: MC1QE5EU,:U>7:%+F+N$@@7ZYTX0[OCPEN+=#V-<<$SBTRVY)Q:?_["0L2\HL M&CJV8>R$A+RMA'&1O#YD0W*\OM^Z,^J9)"3+"X/$\'59F I@8L5^Z#>4% )8 M3=HZF(]SH1%7<'&5I5]67-]9VJ717GJ+"+3W^%&G_,)2+\SYMMO08L;P ,PA MW7UWJTX&KV8/8UWG JLYH^.'7(X\#++V>H]4SA@AY3K/C(3,ZBD,MUD/-B/, MFKJ\^_> TACD'"RT]DZWZ=/ OPN6 WQG?[57U5N^*$M#VK!JC1ZXG&ZGUX_M M]MF1-_?\V4CN?+!HV80;<2HX.#HK(?YGX-T51>T/*J))R;XR!TZ-3"^(JD2?:E19X.-5O*S)J2\+>L0JN9)D!,2H MJ2I:[#!=E)PW)SJ2,<-86_^5,OF891\\<7M-XZ^.7+H0)\U +GB8SE,MS',) ME%S+,G#$6!E2I^4J;$4P@[^$G.(CBQ.^0[-SPK9%7SR?BN]&.*.QWP+;47#U MJ4 R6NJ^1R"&%#OI,/T.9&YMD(]=+K@';'V687'$3D-A:&9!"2ZR=:R]I6#F%5Z! ^$F&6_T"_"'W4^=, H'$$9074 MJT42X/UQC%K07T+@*ON*)RZ,?QQ<#45=K]-GS4AS\]GZZM!4 ^3@K6A-3QHB MQFJ@(@KO56/BH%?T:_U:Q79:#STO1;&,Z4!YE,)52\(>_IM$FAL&9/^?B,[H M'8K$B^>^VE1!HRA_>[TKG(%OC2HSF-#C;V?0 MUV]4'H?MA+68\71N1*-7,^!;^2P+ F*>KHA6BOF>W-[X['#9VO,2>^K3O";K:@ MQ^V1SAUZ81RXNS6NE/+3$5*B&&;M-?>\"^,%]UGXA@)1VV745:@E;:*G5DXF M5EB([4I/>-MHBS?!PVM_AM<7E*A!*#+BDA!WA-T+O"A0O!DH3=C2=*)'M=V] M^+V:*O219%"FAM;UGQ<>WN.@SPJN.E29]9N"><]SEP]'#%/#KB$T,& MU 2E$)W.T%3(ASLI%'XL_(OC'R<%CB\.H*AOQ<=O)X]_P?=JPS)&I*[+V49, M_> [/ 3!NHCG%,BGVW))/JNBZ)*4X*8YH9I$DQM=OAU^XZ+W50P_\E_YDV?8F;I[QL] MRF3FZ*F9P!/];D,V2F'/S AKNT&_%'-'5.XKJ-B>V+IZ.BK^>[G>URO*:,71 MV&G%D$FQ4XI7=T9OY[6QRR:Q')N$ 1U.2-#:-&2?PP\C].*R,T3XIT$6G'9V M?/7CL[9*/HQW3L'9CE+^K5J8GVGX+7$48N([6C+Y27E0UMEMAX+Z8.7?N2QT ME$[*G%DUEXM#94NBV;RY0_+,GSS*KM:J[8]X]$\%#=:ION/@9IK'5V-XRS?D MXZ>'?Q8B$ B;9K54^=+AFG+?AO38$WF.-Y)+2]79H\]:NXZ58[GWYYC"ZT!G M'9W):R\'E"$._E:UG1R0%YU(TGH@(2JED8 SZ5.X0J@+%Z P=OV:_N M5]=)'3)(EQWKT,$*@=;T:8NF;,%DGTRE*3*4((W+E_JXO MYY@S@*H^:55/DB[T"_=A@.F0!9E\Z:GK=(/Q/319$\'AS:?+M/_7>FLOYSU+?]P[EX MXP(?] !XI++IMASPA!5TNT6)U68HJ?R!=M&*M_:EUJ/=V!()5LR*B8 MJZ++" #T?10$=TUR[#9MM1E^RWZS(1^FW\6@YXA:B68/TRMI^?BQ M8#U\-7@K=\AA.T %]3[0@3^^\J4$TP'*$&0S40WW""X5T0(BJ\.9OGPJ4WL4 M^=\F^:#!0Y(S\L)3.^=_H+K)%;Y[C1%/A,PBPI-8"N^-T2EK@IS!EE9W>\)Y MI@T&_CFCPAI=4/GG(<';HM Z,@2_9IH+ L ME_13(%/(6P30!X][5M-P^T]6JL].G(J[3JVGJ@ !M/LZGWZZO%O,%XKIJXS] M#JN;/5Q7'YH+ZABXGC%(:,0O8^C85@SP7/"(RJX7LKL@C#C#U5QPVD#%]3KU M=OBJK(E5FVI^H3J<96*/<7#VUDX+VZCP:WW(,6+:UF>'>9\-OB\"- M;[?XL/M^[[ON[$_N\&HSQ#X?:BCEF!ZC *X*E8"/QZC,A]Y7PR+$,8T-6B^X MO.;1>1Y+1 @-70T;_!Q(\G=U_>]MZFO'RT'^CO6:@WRB_)1BU\((,!+/L'\Y M],+!D,!7H\<5VNCRBE+-4R2RI RM&6+&!:JPXX)T$E,4Q.1$P#<#IB1C#+E\ M6(1CYI.@JI))REF2E<$'/%;2TM( V/K3^I>*,H-#X;)BX!<(" M?MBF?&Y,#PR7N3&4JII1(R67J!C.9#*1HDIK?Z^!?0*@]W(ACZ;]JGNU-$Z\ MR95HB!(ZHY727EYH])OVT5Y+:4!D>HV;:I[/F73R-*T?S:_HUOAW/'O_'N(_ MGBAP;3-3T,YYM>7/X[-\SM)MD/YV1"7:JKD;2CKJ'\9*!7YS9<6RQQ+8@T8: M>1-.QC<3>6[(N1JIWXQD9A Y>'%,E6I774YT@KOSL0-DFU^5/0C?WM:WJ;^[ MNC\@/A'YL^'TLKD5&%_JT M (M9O89A-B0K:L D(-HJ]2)+6Z'(/Q#EOXQ&$W/O#Z>9YT?97N/B/7@&X0;K MZ<%4Y_M(W/\-JWQ6YW.,N*&H^2QP[VCTY=()]VFTGZ=YW-[;M;OIXCX+6]M, M\1:H!@[TXS*&Y M*BQM[?JR._9L>+:;D58G1#TZ\[M-\19V'SXH<2=&X]*9K8>7W+?AW/%X@JI: M7-:6_F5,9;2OWE02.]VYXK>YDQOULE>ED;R]TS\=IV!NPJH4,^M94;4??)KOY>[CN>]O\73W>E,625S1A^.)JM.M.X M81 -Y'UX WW_7@#@6^O &IW-@* M5JS_.F@N$]J8A;#ZIEJ'NV52Q_[$F%$]WBABY>D21LK$=8XCL9^7*(UBAF+- M2SN1[!RUA:2>,5/I>IYP9@,:!R/75,&CQ4B0Q:[MBA7.W9.747P%B$ZL:TWR MJ9"#*RE]ULN>MBQL@2O0*,]'BAZ\[^P3<:E5UD"NQ]JY5D+I'8-B#: <[)=B M9,-HNOUA4;%3KTJB]68J@YNU*A2MPV>1W,'7BQ+$.R5H Y-U_E6*6\JJD3+H M*)[L[2JV^N\P"=E/&9D5, M],E@E1\U(!/ 1)YXCLP"XQV8-1\6!2-X%KA5E M3R'@TI EZMFN:OXN^;QE'BG1_4\&LKV+ILM?TC^C?2(^3GHOL;O=TAUR_/ C M(S)$T*&"BSS(!;MD-.*NW<(&=P]DOIP[C,LXZ!;3 M07Z]9HW&LWXG&XP1@FCTA4LN #9,("-.@#U9W^1#O:#35/;3J+7M?1?ZQ,\I M_4SMIG@ $"0Q>7GO+^)F.@%["IZ>3\,.*BD75Y,<1>;M:3!'7U8O\(@\YL3^ M$$)EY[-B<.C4Y$Y]3O'Y?S8I/5B@"4TT]BO)^?#;IK5,HK1377ER/54 MSL\]_(2WY)=/JT>LP(M-WO3*O@+XS^83H>V/QL5LCWG]U0QPI*:,XKNZ93:L M)*01SJC%:B.3M]M7P QL9B 02D/(?@U ";D,230\R<'1V2PB+0T$!R'4DF6# MHN,X$JG0GD._OEIYD +4!E,!*1F+(8$4T[:XY]%)64C/;5*\YWP:M83JLY#W MDY),_>5$DOZ$SJQM";??GI6U3%SFYE1]2E,,(UD$P$R_4R(?(G=Q3 _S/PX' M[A''7$1PS(G\&,#:4NHH:9@3(0UQU9K!#RIGY2?.3WHNS@0B*C M<#$0%$-0Q0=")#LY$HO"^,$9*INXGFQE?ZMG7#LQ[).U7J4:^U&M^/G2)Q-= M%J\:DKL8.O%2^_,]Y4R^9ZG,$B>TH>_:K'#J*X*9)*O..R?F>WH_,\?/'>;) M/J870JG>[#:I/3IG>Z7YIUL$#S#>B>-E N2Y5,LZO)!!S9_*5VK'#^%.?TXX MNOUK[76RFSHKK?60Y7IZ[(R>?!=;C"LOJ,Z;'+RL8ZU)=DS]79:DNTFLM2U5 MJ2LR/4N>CA&3,MY:Z. PY>=8J?^HY=LV$M^VXDQT1S+!F&9N4E 8)SE;);[B MK4ZRH5I:BYQ=8+EL=*29POXK;!;X'S:6W1O]\<^DP?'#5(*$$T.@.CV9T0NC MKE.;Z=#]!D,8.[.4&T>;;6^GI\B9E#_:'FAJ A[/O3T %)9V;]ZFN"!BS^JW M^2XZ7D9 ?[)-2Y,T\7%IK6U0#9K/OO.D5\"AC=A;D(AZT_U1*5Q<8;V68^H(/'$!)^5J&IGBQMC#9)%6:+9E MA)TK'))2BZ:HWPX,"7VQX=#:Q>*>J$>Z4<5V<3G@O?UINTOT)KU%G,+,H/YL8J%[.XS0Y!.@GRD\F M=+0&C"J#R8_YY(0M4+;P(,%T0*;S!")U0#;G5!3Q,LQXYOF0I4]D>UDQJ(FJ MZ6,AD)/G?*9\*7!27=V&6^BSM^T)^DCMKN8U@E6G#%!@QW<[KEC'-'MQP2UI MVRVYV0W&1CE=/W;'WCWNZ(W\."5PEC0QPZ?[2HO]N;H*.RX M,O;''\,?.P=2M,C7GR!J/5QO)PBWQQB\GZ$%8&2G.P4RT\J[%%;WS0R1Q84B M+!S"NT)9DJ\%O%U*.\>P/W(^9--B,0<7Q4[T:IJ0\ -]%?2ID+7@%52Y:[DM M .&80NR5:G*_>+Y0RSAM1J^6,9HI<2H)3XY=52X4D2EY=FL1*#E<48@W7(<$ M,PAP,(F3HZB/9V67SLQU(>;#7%9"JP#?P%UVFSOCCY1R$N<9%^\]],0W%^2" M^31RZ4MV:52K=**2JRY+Z(3W@<>E1S0A)0:I)Q%E1MHFVJ:(ZK M-S7:Y:N#(;EO8XCLT0B:J.?-1T'07MH+'Z9@XH'E2=5.5,HZ/&!4U&),8:+0 M=U8,^=)@V::X)7>R366S+V2(2N_PNJ0[O6G-+?!6QF;%!)$IK5&4BGF>Z#I" M:,_"RZAHF;'Z=]5X'=.,TQ A]$(9?7T:4W:%WD-&=R7EN>7#"&(KL(2C@Z,N M]9:5C24EJA=4\J/3<0.NJY=A)OU^>;N *PH?)Z,4(-;J4\(;2_5""&G> /="QH6"2J5V2H1%2D MDANJ8A= 'TEP T+H.L#\TP]4 E.CL)/APC=.AU3,\=[RZB=41:B&Z6QE.9F3 M$R5@Z5#I9+H;19;3VFFQ_(L4=PWINIK=\KJ4?A3:"Y3G/')RE"7@7G;N8LB9 MZ?$ >/ P;!X$@6J#D8T4]!?P%/PZ#GE4'+[,Y:B$$\Y!3LX$ZAF)<04RF-.+ M^!;-MF(.ZC9"A"JAAPW2AB+N:3 F M+-ZZQ!TR'MJFN5SZ 0CGF\KVL]43GWW[*Y)1Y ?=?:!)P\Z-7\ E$">G]N4A MN;/PF?M430?.Y"I(E O8O,+0.H43<+]!4*A8$I#)2DX;D_W/BST#SB*VMD]8 M&"_3[8[GRC.9$SD07F)UKW/&)S\K>!78X'J?73X":U=C)A?=-^LY=[F4U3WQ MRG#\"_FMYX.QR#G6JO5NG07JX54].$'$R=X+7%8WMM')%C8TS9.K+)2-%$[3 M >=->T"\K;W$EJZ MM8@( $77G& (=,?;< &H(94K9Z:@JT0>\<4/X,:K&M:O#"YR'@$8E*=VJ)+K M(:JX@YR-S'OR]%!6[_"1SG[O3(]M3O_K6U5)I804'9B;R4BV<(YU9Y\QE'_% M8.VF'\BP\29 J3"+&,20"I"Q(W/G*P3FA7L2##I2^:UA_R4;5T.E1\_J:I&? MQ";G_%+]F.*]#R8Y/]*7H%Y[_^EVGH/SMV61:L[C05^M1C*"8Q?H4%D"O.DM MS/R &O_^%HX'>X8F4DW]B2>UIV;Z8.7?EGJ4M,K.PD22%;E^-5X'69B T>:& M^T4JL&2=$&2VE,7:TZ:]W7K.L*Y$XA!2M3,MTEFBATKBYFMD=8KPN>MYL[J[<5Z48-P8N=,PW8KTEUKLLW: M7-)Q_2JQ %PJHYR5Z'R^SIVN3TVJ:KEOL]!V.?N\MQMX[A M!\6Q]?#:06*>T6MBDK!3K#@?GBOJR M?D$JTCK1\7K MNWRQ.0SC5MI&0^;H/6$'(:U)[,1O CRAEP1Z(,!J C,BY1^+DBL6OU#P*+<( MT-CHKBL*CA+(_.@J/,$] J=%D<9%&U%@-+!)#BF!8JE0Z"LH[!I&.=.U?Y8X M 5]5^>%-T D,7P1"C&?DU7\%RN!S-=W%VOF:W]+6V1CVU%#,!R"KDA"ZE=!$ M(&%_H#8$F.) O]WYC[%-#A2WG3:)QMEB>BZE%SZZ32PYU8<;43T*:"[)1&*Q M^\ UB=.!T8@$*U#+([;S$5@EM;C(NAC:TL.2#1P(38R)!)U8#BO.&D0\&&+< M2J8@<;!%Y,Y5!(%VJ>(I)7FTC%?N?!!'@CPW(ZX>#3+T$1Q11\U>]([&WH22 MY-M(V=KN;.OK;&OW:^SL(X7\('>B$?V'GV R4CP>"VQ=8@9 ,OXM;&@U+0(" M "^! 78"+'@ '$=#0RU);G-T86QL7$=#0RU);G-T86QL+FEN9F^;P &L M8F+:QM23[MWFVB+NZ&@JO= 8&!$;!T3%.&W98&IC)S$7D1@(X7&VA81O@M$0 M6&L-1D6](\>YP#A<)UED.E\VGAT?.T-^X0NZ M-@G0UPL#=)U(I:. 4+\AS@(Z#QQ%2_?^% @4,4\_;H@)0YX'1_(PO$5W"BO> M8.R>4:QL%2T9"P-%FI.(EZJ+SQLM$\_1$D>5H^W_"R1,4+HIBN[KF\UCX]#; M,HQR"+ZKR9'+,?0?C'06/R_@KA^ 4O$?\5W=6!7/9=Y"5Y*NBR)5K=8-PO>O M0.).\\?#^APN%=W7#I?-\.AOD^#Q;>YW=C8[^T:\I7W/FUM:W-JVM+4MSR]8 M^K'J]BW/V;6OI3=JUKS:EH N#BUL:#4MR@< )H3 #,8;,> @ 81T-#+4EN M]&]A[K M&VVW[@W5@ ,CKN/(:0T.C?=]@%P)]%V 0;/ XZ;,:&0'XD$$K5JQ 5F+/I0? M)ED7LL!P^OU_B'*@Q@P1/R=SB#!RQ2PO.2'BA9"Y"[OK+8=Q$ M@1/A;O8@LV1[5>!=3Y$>.8CM!IBE!UR$4*>/'(@_9+()!D!R%[@%$#LTK$'? M916@,<>] :#(C'W#B9 3\NY(20H"+.0*PLY#I"!R2D(\%;I4)X#PI1_+%G%, MM8, 19 \:1P\$8K)U"Z>,42@>#*YH,+KW3 M'T"B#@.C!7]W'+.010Y$JQ- LT$:D*5!M9Y^CJN7K8I#Q7;HH)N\"RWH/"[!*\8...1Z _9OY?;KXSQ>7$@\.37QN MR:1 1&/83'FM0W#+FZ5=5AJE8K=FSCL\][EN6\=YOFI4CQYP MVQAC]@M:X!?GOJ=KMT,)F$[EZYAQW;EZUCNVKUO#\ _I8]?Y:^V]BYL?2W?P M!^'$39YNI*I-C,1I7*8[2R PB2N06H1=.3_QG@>H](3"TMYD(S_V,P3. ZTL M_&"1?:40!YOT_0!HW:B,P%<%ZB2P'&"ZB8PP'TF)-;P$Q9;K]^/C#A:#_7Q$ M(D#$:09R"")U>9%&?)$&&O\$+4IDZ.?]^$A%^LYD(B0OMYDH1ML-?_(1OF>1 M?BL?^&JB%WA_/RGM]ZRRI'JJ.0QT7AD\86\)/4\;2VJ6)!HY8)%2R%(2=I0E MP;HWF!8Q52G51<&P[F&Y^-I>#2FCY'*ZZ:.,;,@U3AHXSPW+J+0OJ\43)V:U M91-F!&&IU)G/> KU%50%)J&M2#D PBA-K.&U50!28N6Y=M!NOYVEJVN M@X5(D5G3"0N_G'A?&YU"OXSL,AMHVYDNG8^J*2Z,S-TT.0;+_)LG:X.)JD/@ MU!-AKR)%ZBCQX4 J"$ITA$2BELKH&P@NTTE&JU#R6J/0JG+*:F!"%8FHVS#9 M:SCC!#;E*7UX:%GS4D&^($+2*U:JC87.SL6YFI4&1$"0OZK^JC_$^N2&#.3. M@5_]CJA-$M\8)HTG8-[]3+]6\U_,%?SL$P5,!Z"IC_2;)E[!7+M:5"Y[U0=@ MD^]X_WP=*-HB 8#"XZ"67I\:06OP_(-KD#I1XE(CU]>Y2X"A2YRH\$2 MLF^F!$ _9,:_(!2(TY%/>*Y84 M+?V 4;C%*Q>8)X(Y7KT]K7G#W859)_AS@BI3P"'EQM4K(>-,\*Z9_ZD8WMY6 M*4HXC05$:GX9AHJ%:GF)\2C=Y-Q7!M4%8>GP*J:+],#2D4Y (&*(HE&YA'"C MOGRL052:/DA+/T\X:YG*$.2%KT40,_7ZB<#8HG[IENJ7O4Y.I19E&J8!L48> M.A/-2._\G#Z7(#O4L"3CM'+11G4/4BX5, YG.U3,1T^]"2)9";.@I8!0H*6" M_=@FM<:J^97)6==IEF?,;9#AGJR55W W:J[S>B(4@E2R<4D>ESKCB,XH!2_Y MC>O-'#N2*UT2IAA33%VDGGXS&GY;\T;BL9A>:L>F-+>X6&)IDB4GR&$Z$&P9 M)?2&*6 [,?J;GHQSYH5A(#N?3^J.LIN]O*8'L+/I*\#Z8Q(S*=4CXGG6>?U2J+%"?CE=F@'>^^G[ MI5/)?JVQ/3'OI,'CBS$O:M2P6YU9 U"D3*!7X4JA[9E9KUYL_M5]&54K#L#B MF/1[4\CY0PDZ3-G7V*TG*0*EE8HQY9LIC8N_@C35MR%W?'Y:\Z44,+-' MISW]O#\+F LBJXW[KMK&/G>M=-J_C]]KE'&(]^VE%)FJ@"A.+6QH-2U3!P M21$ -EK!!\" !)'0T,M26YS=&%L;%Q214%$344,U07+Y%)%;S/-NT\R[SLO,UZ_CE_[UW;;>]W3A(%" ME$48D;P':QMIOPVPPQTELKK)SXXMMM/ HUX.OQ9[>%YZ2L/QZQ[F=N6(Y>DM M[CLN:]_\GG7N;AH;;JJL-GNOM@VP_]\!C.W5#+$OM[N[1WR53/X?+\1$QGMV MNB3<*]KO$RK@_%H9HFO_-H2UPP+':9?;^'N+N'*NO$70>7"&1;VCTXPHH"A@RPY_2J;(:PFBCMAE;86!WVMK- M4.?DZ.+G[/S9W.6_:ZO:0[>Y\-[V!0!D=66S9P+JC###AF#JV$$5NB487&6L MVXY8'&?:B9W(RX]*]QF#0LL"==>);!M,Z0?BX1W1@4;H2DB9>_(PR@]4T1O5 MMGF'T8&#;'<=F7O$+!WPU\G JZ2K^F([V_BT#&X":0E<6@K(!L M'PQ*492$5#\L3P>VU8:QSEB/ OR"?;C.(R]XD@G7@$L)4!*4G@LMEC!-C)JR ML 'N;N-19""DFS,NZ%UT+(! ?V\"VF@B@_CA X!SKA?P$()K !(@0PR11/RO.O$>^4_RN1X!$)Y-' MVQ;08NR9=*B]AXH'1! M;J"9"2:P49'@*_"&JT[HI RR#_IQ*UVXV(, .V_947W\".YKK2;98 61! Y ML_2@VSF&H-KM;X@%=&;$$[':]9I!_/,,J-^(^;]IJ1%((QB[8]B35D92(H$: MT@4@H,_,)90"!%%$,<\261#A<88Y7S-FP,+#?%(Z1 0P4 1LWF0^= A&I5>G(].8#+I[.*0Z<']F8NU*4FM6 M-;JAXR%Y^W,7K\G8@1>L&.G \N<#\\@]S?5#SY7WI)]"](RBNPC5"5X[V5P] M$0*E!+"H.SH]B,K_I[]'_?R55U+1@25K(G:@ZFB=0+#C $60WWG6K0HW&-G5 M8>MN5N*SQS5/EE]LX544I9BB,*B MR>P+E$"%<.-4W.GQU=?G]KNST=G'PHD64X?P]*WO-C\M(\(85D_E1SNNZO[/ MW=G9V:*]5V@-OL;9"/6K+U%U>N4,\P&/R,8MS93!__&%_P7LKO,ZPR3V$FDP M@K,&[QUH:U%S47:##ZI^3Z Z7T<>I.XOGD_#Y4JM1HVF!BH?@=@-.4D-U>"8 M*4\1-, 2$JV\F'2JCSL?(1*D\Y,0'\IA@V+9.5LA/XYLHMK7RY7E_9M[:8TL M:A%7OZ%]%PQ,;13@Y/O&'#0EO'I%_B(#.G!%\9<9F,[?DD.& G>[6N\G0N:. M@AZHL/WY.OO'#5*T&UD^A8XPUXS07U60^J6*M2 M^Y5F2&J8G"NU)H5LM?*"T@M:DN.\P@)Q?.L>+V<@'A_^(#$>W/\GE6CHN$AH M13RHVYRV?7]<_NP?):.\1$!]1?S#$H_?-9\M"-,D]S\CF(R.)WEZ4G%RO!*. MCC0"Z-JEO3G>0E0M_]0I2PATR+%P9YL5\8#RKL/\780?>2L5H9U9B?&) M%,.?E(Y;G,]F:)>;L4HVTP UR !/:A!8Z>BZ29UR1$<@!Z0T&8I)S8_+,Y1; MGY'7DGK^;DI-NFE]\;4I=0R>W1^>N!\]QAOQV(4:096-L'[%VH$G>FL"EE;U MTR8Y3\1G_FRW.LG3<0"_AJC!,6:IG;SC:NOM/THN.-V3B,_IB(Q5YDW- 7AR 1V?$H*?J_I"O:*>/]YZ:# #! end From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 18:58:14 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90235-4>; Fri, 4 Aug 1995 18:57:53 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 4 Aug 95 17:50:30 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <21161ee3.u7t157e.78934-robert@plukwa.pdi.lodz.pl> Subject: Re: New pre-release available In-Reply-To: <199508041549.RAA10819@iss1.neckar-alb.de> (from Jochen Wiedmann ) (at Fri, 4 Aug 1995 17:49:01 +0200 (MET DST)) Reply-To: robert@pdi.lodz.pl Content-Length: 283 To: wiedmann%iss1.neckar-alb.de@plearn.edu.pl Cc: amiga-gcc-port@nic.funet.fi Date: Fri, 4 Aug 95 17:50:30 On Aug 4 Jochen Wiedmann wrote: > > > > I add the new version below. > > Somehow it is corupted. UUdecode says short file and extracted lha is > > corupted too. Could You correct it and post again? > > Damn. :-) Here it is. This time it's prefectly ok!!! Thanks! Robert From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 19:39:14 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90212-3>; Fri, 4 Aug 1995 19:38:42 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26776-3>; Fri, 4 Aug 1995 18:38:12 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209167-2>; Fri, 4 Aug 1995 18:38:06 +0100 Subject: Re: gas bug From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 4 Aug 1995 18:37:53 +0200 (MESZ) In-Reply-To: <199508040914.LAA03482@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Aug 4, 95 11:14:07 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1093 Message-Id: <95Aug4.183806+0100mesz.209167-2+2908@hphalle0.informatik.tu-muenchen.de> > > 1. pc-relative is a very important mode in > > resident programming. it allows code to be > > move without changes > > Are we talking about the same thing? Probably not. Resident doesn't require PC-relative at all. > Who uses gas to program the amiga in assembler? I do. Generally I use the assembler that comes with the compiler, so I use lattice-asm for the SAS/C stuff and gas for GNU-C. It even means that I have to versions for most assembler files :( > Bad programming habit. If you want program in assembler, go > and use a native assembler and use hunk2gcc. That's bad... what assembler do you put into the makefile? Can you trust hunk2gcc? Besides that, I actually managed to use PC-relative addressing modes with gas some time ago... but that might be an older gas, don't remember :( > Gunther Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 20:38:30 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89691-2>; Fri, 4 Aug 1995 20:37:38 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 4 Aug 1995 19:37:16 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA13615; Fri, 4 Aug 95 19:37:25 +0200 Date: Fri, 4 Aug 95 19:37:25 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508041737.AA13615@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA01759; Fri, 4 Aug 95 19:37:25 +0200 To: amiga-gcc-port@nic.funet.fi Subject: Apurify only works with CPU noinstcache Hi, I found out that the above is necessary: APurify uses self-modifying code, thus failing on good machines. The address of the original AllocMem() and FreeMem() is poked into the code section. The caches must be cleared (not too expensive here, SetFunction() did it shortly before anyway), unless somebody comes up with a better scheme. I wrote a longer mail to the author. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 20:42:05 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90100-4>; Fri, 4 Aug 1995 20:41:42 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 4 Aug 1995 19:41:08 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA13633; Fri, 4 Aug 95 19:41:16 +0200 Date: Fri, 4 Aug 95 19:41:16 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508041741.AA13633@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA01760; Fri, 4 Aug 95 19:41:16 +0200 To: robert@pdi.lodz.pl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: 270-prerelease In-Reply-To: <2115d313.u7t157e.bb772-robert@plukwa.pdi.lodz.pl> References: <199508041021.MAA04110@honshu.informatik.uni-rostock.de> <2115d313.u7t157e.bb772-robert@plukwa.pdi.lodz.pl> Robert Ramiega writes: > It would be better =o). In fact they should be in cat format and also in > normal (ie without ^H) ASCII. If someone wnats i can try to dig up my old > progrma that removed those annoying chars.... I can recommend Less-1.6Z which displays them wonderfully. pure text + cat would be a waste of resources. I vote for cat because it offers highlighting and such. Of course, a translation into CSI codes would be even better. Joerg. From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 20:56:07 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90179-2>; Fri, 4 Aug 1995 20:55:33 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 4 Aug 1995 19:54:59 +0200 Received: from psycho.inf-wiss.uni-konstanz.de ([134.34.53.49]) by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA13658; Fri, 4 Aug 95 19:55:04 +0200 Date: Fri, 4 Aug 95 19:55:03 +0200 Message-Id: <9508041755.AA13658@inf-wiss.uni-konstanz.de> From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: gcc270 prerelease bugs and notes Hi, o GCC270 still uses the brain-damaged static struct return convention. I wrote about this in April and thought that this was going to change back to the good old GCC 1.38 and 2.3.3 behaviour. o GCC still (I reported this for the first time in February 94) doesn't work without ixconfig's "/" translation. I believe that this it not necessary (GCC-2.3.3 worked fine without), it only shows that there are still paths like /gnu/... instead of GNU:... built into the binaries. Why? GNU: always works fine, whereas /gnu/ doesn't half of the time. PhB told many moons ago that this would be changed. We shouldn't and mustn't depend on the "/" translation! o The workings of stack* should be documented, i.e. the libstack.guide file from the libnix distribution included. We should stress that the registers a0/a1/d0/d1 are _not_ preserved, thus neither stackextension nor stackcheck will work with functions passing variables in registers (for example ixemul/library/ix_sigwinch.c, not that one would want to compile a .library with stack extension though :-). Be careful! It should also be stressed that a Forbid() can be broken by simple function calls now because AllocMem() maybe called and only God knows what all programmers do in their lib_Expunge() routines or AllocMem() patches. o What about including my stdlib patch? (see README-2.7.0) *** include/stdlib.h.orig Mon Aug 10 15:28:54 1992 --- include/stdlib.h Fri Dec 09 17:12:38 1993 *************** *** 72,76 **** --- 72,80 ---- void *calloc __P((size_t, size_t)); div_t div __P((int, int)); + #if 0 void volatile exit __P((int)); + #else /* new ANSI-C interpretation */ + typedef void exit_t __P((int)); volatile exit_t exit; + #endif void free __P((void *)); char *getenv __P((const char *)); Or at least make it dependent on some ANSI define? o Ixconfig's stack watcher doesn't like VMM2.1. I guess the reason is the same that makes StackMon show stack overflows: VMM switches SP to a location which it's sure is in physical memory. [This has nothing to do with gcc270 in particular] o About the Stack code: maybe I'm confused, but why is __stackborders initialized from tc_SPLower instead of Upper in init_stk.c? It seems like it should tell the upper bound of the stack in stkext.c? o A note should be dropped to users saying that the stackextension can happen at any function call, dynamic array or alloca(), thus it has the potential to break any Forbid() or Disable(). Software will work most of the time, but crash randomly. The kind if SW we like. Regards, Joerg Hoehle [writing on my Amiga, lot's of fun :)] From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 21:09:10 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90046-1>; Fri, 4 Aug 1995 21:08:22 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 4 Aug 1995 20:08:01 +0200 Received: from psycho.inf-wiss.uni-konstanz.de ([134.34.53.49]) by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA13702; Fri, 4 Aug 95 20:08:07 +0200 Date: Fri, 4 Aug 95 20:08:06 +0200 Message-Id: <9508041808.AA13702@inf-wiss.uni-konstanz.de> From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: gcc270 distribution s/user-startup Hi, I think that the ESHELL variable should not be set to gnu:bin/sh but stay pointing to gnuemacs:etc/sh. Although it works, using gnu:bin/sh is a _huge_ waste of resources, as what this shell usually does is just to sit around, running another command or sometimes even worse a succession of commands (sh -c env TERM=emacs - command). Thus keep it as small as possible. GNUEmacs will be happy with more free memory. BTW, I recommend using cmushell.el and cmulisp.el instead of the original shell.el or inf-lisp.el Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 21:14:43 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90426-2>; Fri, 4 Aug 1995 21:14:10 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 4 Aug 1995 20:13:49 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA13716; Fri, 4 Aug 95 20:13:57 +0200 Date: Fri, 4 Aug 95 20:13:57 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508041813.AA13716@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA01779; Fri, 4 Aug 95 20:13:57 +0200 To: Gunther Nikl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: gas bug In-Reply-To: <199508040914.LAA03482@honshu.informatik.uni-rostock.de> References: <199508040914.LAA03482@honshu.informatik.uni-rostock.de> Gunther Nikl writes: > Are we talking about the same thing? Who uses gas to > program the amiga in assembler? As I am already stated > gas is designed to assemble *gcc output*. The asm() thing is a documented option of GCC, including examples in the manual. As such, we must expect it to work. If it doesn't, it ought to be be fixed. Simple. Dasm (from DICE) is explicitly stated as being an incomplete assembler just there to postparse compiler output. Gas is not. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Fri Aug 4 21:57:53 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90291-4>; Fri, 4 Aug 1995 21:56:59 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0seRvq-0004nYC; Fri, 4 Aug 95 11:57 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: gcc270 prerelease bugs and notes To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Fri, 4 Aug 1995 11:57:17 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9508041755.AA13658@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 4, 95 07:55:03 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2376 > o GCC270 still uses the brain-damaged static struct return convention. > I wrote about this in April and thought that this was going to change > back to the good old GCC 1.38 and 2.3.3 behaviour. Fixing this is probably as simple as changing a configuration define or two, and then rebuilding "the world" to find out what breaks. Fixing what breaks (if anything) is probably the hardest part of the conversion. Perhaps I'll give it a try once FreshFish 10 is done and I can risk destabilizing my gnu environment. > o GCC still (I reported this for the first time in February 94) > doesn't work without ixconfig's "/" translation. I believe that this > it not necessary (GCC-2.3.3 worked fine without), it only shows that > there are still paths like /gnu/... instead of GNU:... built into the > binaries. Why? GNU: always works fine, whereas /gnu/ doesn't half of > the time. PhB told many moons ago that this would be changed. We > shouldn't and mustn't depend on the "/" translation! In principle there is no problem to change this. There may be some hacking required at the infrastructure (configure, Makefile, etc) since sometimes names that are embedded in binaries are dynamically generated by the infrastructure, which currently expects standard Unix style notation. This applies to all the gnu tools, not just gcc. The amount of work to eliminate unix style names in all the gnu tools could be unpleasantly large, and also increase the amount of differences between the reference FSF source and the Amiga source base. This doesn't mean it shouldn't be done, just that it is not a high priority if you are working on a limited time budget. > o The workings of stack* should be documented, i.e. the libstack.guide > file from the libnix distribution included. We should stress that the > registers a0/a1/d0/d1 are _not_ preserved, thus neither stackextension > nor stackcheck will work with functions passing variables in registers > (for example ixemul/library/ix_sigwinch.c, not that one would want to > compile a .library with stack extension though :-). Be careful! It would be helpful if someone would compare the current ixemul stack code (taken from an earlier version of libnix) with the current libnix 1.0 code, and send me patches to update the copies in ixemul (as well as add any other files like libstack.guide that seem appropriate). -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Aug 5 12:07:21 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89528-4>; Sat, 5 Aug 1995 12:06:06 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug5.120606+0300_eet_dst.89528-4+16@nic.funet.fi> From: To: Date: Sat, 5 Aug 1995 12:06:02 +0300 Date: Sat, 5 Aug 1995 11:05:11 +0200 (METDST) From: Rask Lambertsen To: Lars Hecking Cc: Karl Walter Bock , Amiga GCC List Subject: Re: exit code 1 (was Re: your mail) In-Reply-To: <199508031322.OAA06971@mostar.nmrc.ucc.ie> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 3 Aug 1995, Lars Hecking wrote: > > > > > Agreed, this should eventually be fixed. It bites people too many times. > > > > > > Well, it fails with a returncode of 1, so the error indication _is_ there. No. See below. > > > > > > > -Fred > > > > > > Christian > > > > Well, but what do you do with error code 1 on the Amiga ? FAIL (10) would > > IMHO be much nicer. > > What for? Cc1 is rarely run directly from commandline or AmigaDOS script, > and those programs receiving cc1's exit code (gcc driver; make?) know how > to deal with it. ixemul.library was designed for Unix, more specific > BSD, compatibility, and not to be conformant to Amiga habits. > And changing the error code wouldn't make any difference what so ever. You simply get no error message, no matter what error code is returned. This only happens if it failes in a script. If you start it from the command line, you never see the error code. An error message is what we need. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Sat Aug 5 12:28:54 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90507-1>; Sat, 5 Aug 1995 12:27:15 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug5.122715+0300_eet_dst.90507-1+13@nic.funet.fi> From: To: Date: Sat, 5 Aug 1995 12:27:14 +0300 Date: Sat, 5 Aug 1995 11:26:21 +0200 (METDST) From: Rask Lambertsen To: Matthias Fleischer Cc: Thomas Radtke , amiga-gcc-port@nic.funet.fi Subject: Re: gcc-2.7.0 -resident bug In-Reply-To: <9508020845.AA24762@sunserv.IZFM.Uni-Stuttgart.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 2 Aug 1995, Matthias Fleischer wrote: > > > > > No idea. I get (-O -resident -Dconst=) 78972 bytes. > > > > > Because absolute addressing needs four bytes, the relative > > counterparts only two. Am I wrong ? > > > You're right. But don't forget the relocation needed for absolute > addressing which increases the executables size by another 4 bytes and ^^^ > slows down loading. Actually, that is 8 bytes (for a RELOC32 hunk entry). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Sat Aug 5 12:40:16 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <88447-4>; Sat, 5 Aug 1995 12:39:54 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug5.123954+0300_eet_dst.88447-4+17@nic.funet.fi> From: To: Date: Sat, 5 Aug 1995 12:39:52 +0300 Date: Sat, 5 Aug 1995 11:39:06 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Suggestion for gcc Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have a few things I would like to see in gcc: 1. 'ld' should output RELOC32_SHORT hunks instead of RELOC32 hunks. These new (OS 2.0+) hunks do give some nice executalbe size reductions. Since gcc now requires OS 2.0+ anyway, why no make it the default? 2. An option for generating PC-relative code. 3. An option for generating functions and function calls that use registers for argument passing. Using the stack to pass arguments is slower and increases the code size a lot. In comparison with DICE, GCC really looses out on points 2 and 3. This means that in spite of the optimizasions done by GCC, the code doesn't end up much better (speedwise as well as sizewise). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Sat Aug 5 12:41:51 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <88791-2>; Sat, 5 Aug 1995 12:41:33 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug5.124133+0300_eet_dst.88791-2+12@nic.funet.fi> From: To: Date: Sat, 5 Aug 1995 12:41:26 +0300 Date: Sat, 5 Aug 1995 11:40:40 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: How to call functions starting with @ in inline asm Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII How do I call a function which has a name that begins with '@' from inline asm? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Sat Aug 5 13:31:55 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <90278-4>; Sat, 5 Aug 1995 13:31:31 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id MAA27032; Sat, 5 Aug 1995 12:29:02 +0200 From: Jochen Wiedmann Message-Id: <199508051029.MAA27032@iss1.neckar-alb.de> Subject: Re: Code suggestions To: gc948374@gbar.dtu.dk Date: Sat, 5 Aug 1995 12:29:02 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Aug5.123954+0300_eet_dst.88447-4+17@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 5, 95 12:39:52 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1158 Hello, Rask, > 1. 'ld' should output RELOC32_SHORT hunks instead of RELOC32 hunks. These > new (OS 2.0+) hunks do give some nice executalbe size reductions. Since > gcc now requires OS 2.0+ anyway, why no make it the default? You mismatch two things: gcc itself requires OS 2.0+, but *not* the binaries created by gcc. Of course I'd like this possibility, if an option would allow to choose between different hunks. Most of *my* programs require 2.0 anyways. :-) > 2. An option for generating PC-relative code. Probably possible. > 3. An option for generating functions and function calls that use > registers for argument passing. Using the stack to pass arguments is > slower and increases the code size a lot. > > In comparison with DICE, GCC really looses out on points 2 and 3. This > means that in spite of the optimizasions done by GCC, the code doesn't > end up much better (speedwise as well as sizewise). This would be a hard thing. Of course we all would be happy, if it would work, but a new machine description would be required for this kind of things, which is much work. I doubt, that anyone will do it sometimes. Jochen From amiga-gcc-port-owner@nic.funet.fi Sun Aug 6 00:21:42 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90286-3>; Sun, 6 Aug 1995 00:18:52 +0300 Received: by ceylon.informatik.uni-rostock.de id XAA07874; Sat, 5 Aug 1995 23:18:32 +0200 Received: by honshu.informatik.uni-rostock.de id XAA06062; Sat, 5 Aug 1995 23:18:31 +0200 From: Gunther Nikl Message-Id: <199508052118.XAA06062@honshu.informatik.uni-rostock.de> Subject: Re: Code suggestions To: amiga-gcc-port@nic.funet.fi Date: Sat, 5 Aug 1995 23:18:30 +0200 (MET DST) In-Reply-To: <199508051029.MAA27032@iss1.neckar-alb.de> from "Jochen Wiedmann" at Aug 5, 95 12:29:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1080 Hi! > > 1. 'ld' should output RELOC32_SHORT hunks instead of RELOC32 hunks. These > > new (OS 2.0+) hunks do give some nice executalbe size reductions. Since > > gcc now requires OS 2.0+ anyway, why no make it the default? > > You mismatch two things: gcc itself requires OS 2.0+, but *not* the > binaries created by gcc. I would say that depends whether ixemul, libnix or nostdlib is requested (eg. binaries requiring ixemul v39 will still run with 1.2 ;) > > 2. An option for generating PC-relative code. > > Probably possible. To achieve (almost) this, only gas has to be modified. gas refuses to use pc-relative addressing modes when assembling for a 68000/68010. However, in 68020 mode it *does* use pc-relative addressing modes! Because it didn't like the 68000 behavior of gas I changed gas 1.38.1 so that it uses pc-relative addressing modes even for a 68000 (in the sources of gas was statemnet about this: pc-relative addressing modes shall be slower than absolute addressing on a 68000. I don't know whether its true or not) Gunther From amiga-gcc-port-owner@nic.funet.fi Sun Aug 6 00:31:16 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90352-1>; Sun, 6 Aug 1995 00:30:46 +0300 Received: by ceylon.informatik.uni-rostock.de id XAA07893; Sat, 5 Aug 1995 23:30:18 +0200 Received: by honshu.informatik.uni-rostock.de id XAA06076; Sat, 5 Aug 1995 23:30:17 +0200 From: Gunther Nikl Message-Id: <199508052130.XAA06076@honshu.informatik.uni-rostock.de> Subject: Re: gas bug To: amiga-gcc-port@nic.funet.fi Date: Sat, 5 Aug 1995 23:30:16 +0200 (MET DST) In-Reply-To: <95Aug4.183806+0100mesz.209167-2+2908@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Aug 4, 95 06:37:53 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1498 > > Who uses gas to program the amiga in assembler? > > I do. Generally I use the assembler that comes with the compiler, > so I use lattice-asm for the SAS/C stuff and gas for GNU-C. > It even means that I have to versions for most assembler files :( > > > Bad programming habit. If you want program in assembler, go > > and use a native assembler and use hunk2gcc. > > That's bad... what assembler do you put into the makefile? Can you > trust hunk2gcc? I would use 'snma' and I would supply an object-file for those cases. If some likes to change the asm-code, then he must know about hunk2gcc ;) Can one trust hunk2gcc? Good question, but the answer is: not always. 1) for branches to external references, never use "b", only jmp/jsr! or the distances will be wrong ... 2) if the asm part contains more than one section, give every section its own file and import/export all symbols. If you don't do this, hunk2gcc will mess up the sections (it always uses the first section for relocations...) The above things have been gained by unpleasant expiriences with hunk2gcc (The version that comes with 2.7.0 is still broken) > Besides that, I actually managed to use PC-relative addressing modes > with gas some time ago... but that might be an older gas, don't remember :( gas 1.38? :-) It had the (in)famous "+2" style for this. Don't know if its a bug, but since its widely used including crt.c), i would call it a feature ;-) Gunther From amiga-gcc-port-owner@nic.funet.fi Sun Aug 6 01:07:08 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90455-1>; Sun, 6 Aug 1995 01:06:32 +0300 Received: by ceylon.informatik.uni-rostock.de id AAA07952; Sun, 6 Aug 1995 00:06:11 +0200 Received: by honshu.informatik.uni-rostock.de id AAA06326; Sun, 6 Aug 1995 00:06:10 +0200 From: Gunther Nikl Message-Id: <199508052206.AAA06326@honshu.informatik.uni-rostock.de> Subject: 2.7.0 prerelease To: amiga-gcc-port@nic.funet.fi Date: Sun, 6 Aug 1995 00:06:09 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 188 Hi! I just noticed that all the libauto.a libraries are incomplete. (all the alias definition for the library versions are missing) or has something changed I overlooked? Gunther From amiga-gcc-port-owner@nic.funet.fi Sun Aug 6 02:11:43 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <90724-4>; Sun, 6 Aug 1995 02:10:29 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189880>; Sun, 6 Aug 1995 01:09:27 +0200 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA22641; Sun, 6 Aug 1995 01:09:12 +0200 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9508052309.AA22641@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: Code suggestions To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Sun, 6 Aug 1995 01:09:11 +0200 Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508052118.XAA06062@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Aug 5, 95 11:18:30 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 319 > sources of gas was statemnet about this: pc-relative addressing modes > shall be slower than absolute addressing on a 68000. I don't know > whether its true or not) not true. absolute addressing uses 4 cycles more than pc-relative addr. (32bit absolute, thats what we are talking about, right?) Thomas From amiga-gcc-port-owner@nic.funet.fi Sun Aug 6 03:05:00 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90210-2>; Sun, 6 Aug 1995 03:04:24 +0300 Received: by colombo.telesys-innov.fr; Sun, 6 Aug 1995 02:04:52 +0100 From: Philippe BRAND Message-Id: <199508060104.CAA08413@colombo.telesys-innov.fr> Subject: Re: 2.7.0 prerelease To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Sun, 6 Aug 1995 02:04:51 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199508052206.AAA06326@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Aug 6, 95 00:06:09 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 457 Gunther Nikl writes: > I just noticed that all the libauto.a libraries are incomplete. > (all the alias definition for the library versions are missing) > or has something changed I overlooked? In fact I didn't change a line. To which version of libauto are you refering ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sun Aug 6 12:33:25 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90201-4>; Sun, 6 Aug 1995 12:32:54 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sun, 6 Aug 95 11:25:39 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <211867b1.u7t157e.5fc5e-robert@plukwa.pdi.lodz.pl> Subject: Re: your mail In-Reply-To: <199508041742.TAA32707@gryzmak.pdi.lodz.pl> (from <@plearn.edu.pl:AMIGA-GCC-PORT-OWNER@NIC.FUNET.FI>) (at Fri, 4 Aug 1995 19:42:13 +0200) Reply-To: robert@pdi.lodz.pl Content-Length: 549 To: amiga-gcc-port@nic.funet.fi Date: Sun, 6 Aug 95 11:25:39 On Aug 4 Joerg-Cyril Hoehle wrote: > I can recommend Less-1.6Z which displays them wonderfully. I know there are ways to see them. But im most often than not use DOpus and it's not shwoing them correctly. I use standard DOpus viewer cause it fast > > pure text + cat would be a waste of resources. I vote for cat because > it offers highlighting and such. Of course, a translation into CSI > codes would be even better. Agreed. Anyway if esomeone wants to have it in pure ascii than he can change them with ease =o) > > Joerg. > Robert From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 12:10:10 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <89376-2>; Mon, 7 Aug 1995 12:07:11 +0300 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id LAA12149 (8.6.12/IDA-1.6 for ); Mon, 7 Aug 1995 11:06:44 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA00781; Mon, 7 Aug 95 11:06:44 +0200 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9508070906.AA00781@sunserv.IZFM.Uni-Stuttgart.DE> Subject: gcc270 prerelease bugs and notes (fwd) To: amiga-gcc-port@nic.funet.fi Date: Mon, 7 Aug 1995 11:06:44 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 2186 > > o The workings of stack* should be documented, i.e. the libstack.guide > file from the libnix distribution included. > Yes. > > It should also be stressed that a Forbid() can be broken by simple > function calls now because AllocMem() maybe called and only God knows > what all programmers do in their lib_Expunge() routines or AllocMem() > patches. > I think we can trust programmers to not break Forbid() in their lib_Expunge() routines. They explicitly must not do it because of a race condition: lib1 relies on exec to have a single-threaded lib_Open() routine (a documented exec feature) and crashes otherwise. It needs some more memory for each new opener and calls AllocMem() which expunges lib2 because all memory is used. Now this expunge of lib2 breaks Forbid() and a second task manages to open lib1 at the same time... OTOH I don't know what VM systems do with AllocMem(). As soon as they use something else to single-thread lib_Open() they are free to break Forbid(). > > o About the Stack code: maybe I'm confused, but why is __stackborders > initialized from tc_SPLower instead of Upper in init_stk.c? It seems > like it should tell the upper bound of the stack in stkext.c? > __stackborder is a pointer into the task structure for easier access: __stackborders=&FindTask(NULL)->tc_SPLower; ^^^^^^^^^^^^^^ Note the expensive function call To get the upper stack bound you do a movel ___stackborders,a1 movel a1@(4:W),a1 Of course a pointer to the task structure itself would work, too. > o A note should be dropped to users saying that the stackextension can > happen at any function call, dynamic array or alloca(), thus it has > the potential to break any Forbid() or Disable(). Software will work > most of the time, but crash randomly. The kind if SW we like. I hope people use Forbid() very rarely ;-). Therefore I think the bigger problem is that a _failing_ stackextend will exit the program with the potential of leaving a lot of ressources allocated. Software that works if there is enough memory left but fails randomly otherwise. Maybe it's a good idea to limit the use of stackextend to pure ANSI programs? So long. Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 12:36:28 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89414-2>; Mon, 7 Aug 1995 12:35:38 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA24513; Mon, 7 Aug 1995 11:37:04 +0200 Date: Mon, 7 Aug 1995 11:37:03 +0200 (MET DST) From: Kamil Iskra Subject: Re: 2.7.0 prerelease To: Philippe BRAND cc: Gunther Nikl , Amiga-Gcc Liste In-Reply-To: <199508060104.CAA08413@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 6 Aug 1995, Philippe BRAND wrote: > Gunther Nikl writes: > > > I just noticed that all the libauto.a libraries are incomplete. > > (all the alias definition for the library versions are missing) > > or has something changed I overlooked? > > In fact I didn't change a line. To which version of libauto are you refering ? I guess Gunther is referring to the one included in the latest prerelease. I found this bug too, I'll post more about it in a few minutes. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 12:38:25 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90249-1>; Mon, 7 Aug 1995 12:37:56 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA24547; Mon, 7 Aug 1995 11:39:40 +0200 Date: Mon, 7 Aug 1995 11:39:40 +0200 (MET DST) From: Kamil Iskra Subject: GCC 2.7.0 Prerelease To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 1. I think that the following patch should be applied to "README.2.7.0". *** README-2.7.0.orig Sun Aug 6 20:08:36 1995 --- README-2.7.0 Sun Aug 6 20:47:16 1995 *************** *** 310,316 **** gcc270-utilsdoc.lha Utilities documentation (guide & manpages). gcc270-texi.lha All Texinfo documents. gcc270-diffs.lha Diff files for all binaries. ! gcc270-src.lha Source for gcc-2.6.3 plus diff file. Name What Where ---- ---- ----- --- 310,316 ---- gcc270-utilsdoc.lha Utilities documentation (guide & manpages). gcc270-texi.lha All Texinfo documents. gcc270-diffs.lha Diff files for all binaries. ! gcc270-src.lha Source for gcc-2.7.0 plus diff file. Name What Where ---- ---- ----- *************** *** 360,367 **** ============== Since I'm not able to redistribute amiga header files, you will have to get ! them directly from Commodore, unless you're an official registrated Amiga ! developer. You can also find Development Kit on FreshFish CD-Roms. In order to generate inline-headers, follow these steps (provided amiga headers and fd files are in os-include). If you are running under Kickstart 3.1, you don't have to generate them, inlines are provided with distribution. --- 360,367 ---- ============== Since I'm not able to redistribute amiga header files, you will have to get ! them from other source, unless you're an official registrated Amiga developer. ! You can also find Development Kit on FreshFish CD-Roms. In order to generate inline-headers, follow these steps (provided amiga headers and fd files are in os-include). If you are running under Kickstart 3.1, you don't have to generate them, inlines are provided with distribution. *************** *** 605,611 **** Ixemul vs Libnix ================ ! Starting with 2.6.1 version of amigados-gcc, two C libraries are provided. First one is using ixemul.library Amiga shared-library at run-time. This library makes it possible to easily convert Unix(tm) programs to AmigaDOS, --- 605,611 ---- Ixemul vs Libnix ================ ! Starting with 2.6.0 version of amigados-gcc, two C libraries are provided. First one is using ixemul.library Amiga shared-library at run-time. This library makes it possible to easily convert Unix(tm) programs to AmigaDOS, *************** *** 642,673 **** Use ixemul.library for porting Un*x programs, libnix for compiling amiga-only programs and gcc becomes one of the best Amiga compilers. - - =============================== - Redirection with ixemul.library - =============================== - - A common problem seen with amigados-gcc is bad redirection to sderr. - - The fact is that ixemul.library takes stderr from the pr_CES field - in the process structure. The field was added in 2.0. If the field - is not set, then ixemul uses stdout, instead. The trouble is that this - field must be set by the shell, and the only shell that does so is - WShell! - - The rationale behind ixemul.library working this way is that - "run NIL: cmd" will detach your process from the terminal, so - that you can close the initial CLI window after startup. - - In any case, there is a workaround for the problem that was posted to the - list a while back: compile your main program using the -Dmain=mymain - option, then link with stderrfix.o to provide the actual main that will - do the magic that creates an stderr stream that is different from - stdout. Along with the C version a C++ version is included and was used to - compile groff. - - Thanks to Kriton Kyrimis for this explanation and patch. - stderr fixes can be found in GNU:stderrfix (srcs-) and GNU:lib (.o files). ===== ARexx --- 642,647 ---- 2. As Lars Hecking pointed out a few days ago, no patches have been applied to "include". Below is a repost of my "sys/cdefs.h" patch: diff -c include/sys/cdefs.h.orig include/sys/cdefs.h *** include/sys/cdefs.h.orig Sun Jul 30 16:18:09 1995 --- include/sys/cdefs.h Sun Jul 30 16:18:42 1995 *************** *** 52,58 **** --- 52,60 ---- * strings produced by the __STRING macro, but this only works with ANSI C. */ #if defined(__STDC__) || defined(__cplusplus) + #ifndef __P #define __P(protos) protos /* full-blown ANSI C */ + #endif /* __P */ #define __CONCAT(x,y) x ## y #define __STRING(x) #x 3. I was surprised to see that new "libauto.a" is so much smaller than the old one. I think it is incomplete, it lacks the libraries added in "libauto/MakefileAJGG". It doesn't also seem to work well. I tried to compile this simple source: #include int main(void) { long secs, mics; CurrentTime(&secs, &mics); return 0; } using: gcc -v -O2 test.c -o test -lauto That's the produced output: Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -D__OPTIMIZE__ -Dmc68010 test.c /t/cc817776.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cc1 /t/cc817776.i -mfixedstack -quiet -dumpbase test.c -O2 -version -o /t/cc817776.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. as -mc68010 -o /t/cc8177761.o /t/cc817776.s ld -o test /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 -L/local/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 -L/gnu/lib -L/local/lib -L/local/lib /t/cc8177761.o -lauto -lgcc -lc -lamiga -lc -lgcc /gnu/lib/libauto.a(intuition.o): Undefined symbol ___auto_intuition_vers referenced from text segment / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 12:47:46 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90409-4>; Mon, 7 Aug 1995 12:47:16 +0300 Received: by colombo.telesys-innov.fr; Mon, 7 Aug 1995 11:47:45 +0100 From: Philippe BRAND Message-Id: <199508071047.LAA11830@colombo.telesys-innov.fr> Subject: Re: GCC 2.7.0 Prerelease To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Mon, 7 Aug 1995 11:47:44 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Kamil Iskra" at Aug 7, 95 11:39:40 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 822 Kamil Iskra writes: > 1. I think that the following patch should be applied to ok. > 2. As Lars Hecking pointed out a few days ago, no patches have been > applied to "include". Below is a repost of my "sys/cdefs.h" patch: I applied diffs, but I must have lhaed wron include dir (I have several distributions on my hard drives). > 3. I was surprised to see that new "libauto.a" is so much smaller than > the old one. I think it is incomplete, it lacks the libraries added in > "libauto/MakefileAJGG". It doesn't also seem to work well. I tried to > compile this simple source: I didn't use this Makefile. I will regenerate them tonight. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 14:38:33 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <89560-1>; Mon, 7 Aug 1995 14:35:07 +0300 Received: by ceylon.informatik.uni-rostock.de id NAA00295; Mon, 7 Aug 1995 13:34:45 +0200 Received: by honshu.informatik.uni-rostock.de id NAA09004; Mon, 7 Aug 1995 13:34:44 +0200 From: Gunther Nikl Message-Id: <199508071134.NAA09004@honshu.informatik.uni-rostock.de> Subject: Re: 2.7.0 prerelease To: amiga-gcc-port@nic.funet.fi Date: Mon, 7 Aug 1995 13:34:43 +0200 (MET DST) In-Reply-To: <199508060104.CAA08413@colombo.telesys-innov.fr> from "Philippe BRAND" at Aug 6, 95 02:04:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 376 Philippe Brand writes: > Gunther Nikl writes: > > > I just noticed that all the libauto.a libraries are incomplete. > > (all the alias definition for the library versions are missing) > > or has something changed I overlooked? > > In fact I didn't change a line. To which version of libauto are you refering ? The ones that are in the latest pre-release. Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 14:47:49 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90683-2>; Mon, 7 Aug 1995 14:44:52 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Mon, 7 Aug 95 13:36:53 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2119d7f2.u7t157e.4aabd-robert@plukwa.pdi.lodz.pl> Subject: Re: 2.7.0 prerelease In-Reply-To: <199508071134.NAA09004@honshu.informatik.uni-rostock.de> (from Gunther Nikl ) (at Mon, 7 Aug 1995 13:34:43 +0200 (MET DST)) Reply-To: robert@pdi.lodz.pl Content-Length: 996 To: amiga-gcc-port@nic.funet.fi Date: Mon, 7 Aug 95 13:36:53 On Aug 7 Gunther Nikl wrote: > > Philippe Brand writes: > > Gunther Nikl writes: > > > > > I just noticed that all the libauto.a libraries are incomplete. > > > (all the alias definition for the library versions are missing) > > > or has something changed I overlooked? > > > > In fact I didn't change a line. To which version of libauto are you refering ? > > The ones that are in the latest pre-release. The ones from previous pre-release worked just fine. Latest pre-release is screwed =o( > > Gunther > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 15:01:27 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89879-1>; Mon, 7 Aug 1995 14:58:30 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA24928; Mon, 7 Aug 1995 13:59:53 +0200 Date: Mon, 7 Aug 1995 13:59:52 +0200 (MET DST) From: Kamil Iskra Subject: Re: 2.7.0 prerelease To: robert@pdi.lodz.pl cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <2119d7f2.u7t157e.4aabd-robert@plukwa.pdi.lodz.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 7 Aug 1995, Robert Ramiega wrote: > On Aug 7 Gunther Nikl wrote: > > > > > Philippe Brand writes: > > > Gunther Nikl writes: > > > > > > > I just noticed that all the libauto.a libraries are incomplete. > > > > (all the alias definition for the library versions are missing) > > > > or has something changed I overlooked? > > > > > > In fact I didn't change a line. To which version of libauto are you refering > ? > > > > The ones that are in the latest pre-release. > The ones from previous pre-release worked just fine. Latest pre-release is > screwed =o( I think there was no "libauto.a" in previous pre-release. So the "previous" version you are referring to is most probably 2.6.3. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 15:10:12 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90907-2>; Mon, 7 Aug 1995 15:07:26 +0300 Received: by ceylon.informatik.uni-rostock.de id OAA00473; Mon, 7 Aug 1995 14:06:57 +0200 Received: by honshu.informatik.uni-rostock.de id OAA10301; Mon, 7 Aug 1995 14:06:57 +0200 From: Gunther Nikl Message-Id: <199508071206.OAA10301@honshu.informatik.uni-rostock.de> Subject: Re: gcc270 prerelease bugs and notes (fwd) To: amiga-gcc-port@nic.funet.fi Date: Mon, 7 Aug 1995 14:06:56 +0200 (MET DST) In-Reply-To: <9508070906.AA00781@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Aug 7, 95 11:06:44 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1035 > I think we can trust programmers to not break Forbid() in their > lib_Expunge() routines. They explicitly must not do it because > of a race condition: > lib1 relies on exec to have a single-threaded lib_Open() > routine (a documented exec feature) and crashes otherwise. > It needs some more memory for each new opener and calls AllocMem() > which expunges lib2 because all memory is used. Now this expunge of > lib2 breaks Forbid() and a second task manages to open lib1 at > the same time... Thats why the correct way to protect a LibOpen() is the following: struct Library *LibOpen(register __a6 struct Library *Lib) { /* any memory allocation can cause a call of THIS library expunge vector. if OpenCnt is zero the library might go away ... So fake a user :-) */ Lib->lib_OpenCnt++; /* open stuff comes here */ --Lib->lib_OpenCnt; return result: } Every library that does it not this way (and calls functions that might break the forbid) has to be considered *broken*. Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 15:14:16 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90322-2>; Mon, 7 Aug 1995 15:10:41 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Mon, 7 Aug 95 14:03:10 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2119de1a.u7t157e.c0bb7-robert@plukwa.pdi.lodz.pl> Subject: Re: 2.7.0 prerelease In-Reply-To: (from Kamil Iskra ) (at Mon, 7 Aug 1995 13:59:52 +0200 (MET DST)) Reply-To: robert@pdi.lodz.pl Content-Length: 589 To: kiskra@ernie.icslab.agh.edu.pl Cc: amiga-gcc-port@nic.funet.fi Date: Mon, 7 Aug 95 14:03:10 On Aug 7 Kamil Iskra wrote: > > > I think there was no "libauto.a" in previous pre-release. So the > "previous" version you are referring to is most probably 2.6.3. Ooops! You might be right. I've installed 2.7.0 over 2.6.3 and i didnt check what's in archive > > / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ > | iskra@student.uci.agh.edu.pl | > | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | > \ PGP public key available via Finger or WWW / > Robert From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 17:04:05 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90481-1>; Mon, 7 Aug 1995 17:00:31 +0300 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id QAA16914 (8.6.12/IDA-1.6 for ); Mon, 7 Aug 1995 16:00:02 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA01444; Mon, 7 Aug 95 16:00:02 +0200 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9508071400.AA01444@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: gcc270 prerelease bugs and notes To: amiga-gcc-port@nic.funet.fi Date: Mon, 7 Aug 1995 16:00:01 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 817 > > Thats why the correct way to protect a LibOpen() is the following: > > Lib->lib_OpenCnt++; > /* open stuff comes here */ > --Lib->lib_OpenCnt; > I guess you misunderstood me. The above protects the library against being _expunged_ by itself while opening at the same time (by faking an opener). But the problem is that breaking Forbid() in the expunge routine of any library allows multiple tasks to enter the open routine (of any lib) simultaneously. > > Every library that does it not this way (and calls functions that might > break the forbid) has to be considered *broken*. > Breaking the Forbid() is explicitly forbidden for expunge(). AFAIK it's allowed for init(), open(), close() (OpenLibrary() might break the Forbid() and is allowed) as long as your code is reentrant. Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 17:10:01 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90391-3>; Mon, 7 Aug 1995 17:09:42 +0300 Received: by ceylon.informatik.uni-rostock.de id QAA01047; Mon, 7 Aug 1995 16:09:17 +0200 Received: by honshu.informatik.uni-rostock.de id QAA11503; Mon, 7 Aug 1995 16:09:15 +0200 From: Gunther Nikl Message-Id: <199508071409.QAA11503@honshu.informatik.uni-rostock.de> Subject: Re: gcc270 prerelease bugs and notes To: amiga-gcc-port@nic.funet.fi Date: Mon, 7 Aug 1995 16:09:14 +0200 (MET DST) In-Reply-To: <9508071400.AA01444@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Aug 7, 95 04:00:01 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 591 > > Thats why the correct way to protect a LibOpen() is the following: > > > > Lib->lib_OpenCnt++; > > /* open stuff comes here */ > > --Lib->lib_OpenCnt; > > > I guess you misunderstood me. The above protects the library > against being _expunged_ by itself while opening at the same time > (by faking an opener). > But the problem is that breaking Forbid() in the expunge routine > of any library allows multiple tasks to enter the open routine > (of any lib) simultaneously. Oops, seems that I really didn't catch the point that you refered to Expunge(). Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 17:10:55 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90855-2>; Mon, 7 Aug 1995 17:10:31 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 7 Aug 1995 16:09:58 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA18723; Mon, 7 Aug 95 16:10:07 +0200 Date: Mon, 7 Aug 95 16:10:07 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508071410.AA18723@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02205; Mon, 7 Aug 95 16:10:07 +0200 To: amiga-gcc-port@nic.funet.fi Subject: two questions: gcc270 -m68020-40 and MungWall/Owner Hi, does anyone have a proof that the (finally implemented) -m68020-40 switch really makes a difference agains -mc68020? I diffed huge assembly files and found nothing at all. Does anyone know of a tool that works better than Owner in the way that it scans the current memlist and uses MungWall's Nametag? I don't find "pipe munglist | less-1.6Z -[cli]" very easy to use. Owner simply replies "nothing known" for many addresses. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon Aug 7 17:32:22 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90422-3>; Mon, 7 Aug 1995 17:31:41 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sfTEK-0004nYC; Mon, 7 Aug 95 07:32 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: GCC 2.7.0 Prerelease To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Mon, 7 Aug 1995 07:32:36 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Aug 7, 95 11:39:40 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 944 > 2. As Lars Hecking pointed out a few days ago, no patches have been > applied to "include". Below is a repost of my "sys/cdefs.h" patch: > > diff -c include/sys/cdefs.h.orig include/sys/cdefs.h > *** include/sys/cdefs.h.orig Sun Jul 30 16:18:09 1995 > --- include/sys/cdefs.h Sun Jul 30 16:18:42 1995 > *************** > *** 52,58 **** > --- 52,60 ---- > * strings produced by the __STRING macro, but this only works with ANSI C. > */ > #if defined(__STDC__) || defined(__cplusplus) > + #ifndef __P > #define __P(protos) protos /* full-blown ANSI C */ > + #endif /* __P */ > #define __CONCAT(x,y) x ## y Names beginning with "__" are reserved and must not be used by applications. So in ANSI C the original definition is safe from colliding with definitions in user applications. If an application uses __P it should be fixed to use something like "#define PROTO(proto) proto". What is the motivation for this change? -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Aug 8 23:59:47 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90287-1>; Tue, 8 Aug 1995 23:55:53 +0300 Received: by colombo.telesys-innov.fr; Tue, 8 Aug 1995 22:56:34 +0100 From: Philippe BRAND Message-Id: <199508082156.WAA16610@colombo.telesys-innov.fr> Subject: minor update to distribution To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Tue, 8 Aug 1995 22:56:34 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 494 I've just uploaded a minor update to gcc270 distribution on both my site and funet. gcc270-upd950808.lha which contains new frontends (gcc, gccv, gcc020, gccv020) that fix essentially a 'specs' file problem. Thanks Gunther. It also includes new libauto libraries, on both 68000, 68020-soft-float, and base-relative. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 12:05:32 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90536-1>; Wed, 9 Aug 1995 12:04:26 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 9 Aug 95 10:54:20 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <211c54d8.u7t157e.b12e3-robert@plukwa.pdi.lodz.pl> Subject: Re: minor update to distribution In-Reply-To: <199508082156.WAA16610@colombo.telesys-innov.fr> (from Philippe BRAND ) (at Tue, 8 Aug 1995 22:56:34 +0100 (BST)) Reply-To: robert@pdi.lodz.pl Content-Length: 2197 To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@nic.funet.fi Date: Wed, 9 Aug 95 10:54:20 On Aug 8 Philippe BRAND wrote: > I've just uploaded a minor update to gcc270 distribution on both > my site and funet. > gcc270-upd950808.lha > which contains new frontends (gcc, gccv, gcc020, gccv020) that fix essentially > a 'specs' file problem. Thanks Gunther. What have You done to gcc?? Now during configure i got this: cpp: "***NULL POINTER***", line 0: Warning: Unknown option "-Asystem(amigados)" The following options are valid: -C Write source file comments to output -Dsymbol=value Define a symbol with the given (optional) value -Idirectory Add a directory to the #include search list -N Don't predefine target-specific names -P Don't insert #line directives -Stext Specify sizes for #if sizeof -Usymbol Undefine symbol cpp: "***NULL POINTER***", line 0: Warning: Unknown option "-Acpu(m68k)" The following options are valid: [snip] cpp: "***NULL POINTER***", line 0: Warning: Unknown option "-Amachine(m68k)" The following options are valid: [snip] /t/cc985504.i: No such file or directory cpp: "***NULL POINTER***", line 0: Error: Can't open output file "/t/cc985504.i" no checking for fcntl... cpp: "***NULL POINTER***", line 0: Warning: Unknown option "-lang-c" The following options are valid: ... and so on. >From whole configure process not one compilation succeded Before I installed the update it was all ok! To clear things: I have installed gcc-270 base, inclib, c as well as AmiTCP-gcc-sdk > -- > Philippe BRAND > phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB > AmigaDOS GNU Project, AmigOS Net/WWW coordinator. > http://www.telesys-innov.fr/about/PhB.html > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 12:06:12 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90838-1>; Wed, 9 Aug 1995 12:05:35 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA06010; Wed, 9 Aug 1995 11:07:06 +0200 Date: Wed, 9 Aug 1995 11:07:06 +0200 (MET DST) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: GCC 2.7.0 Prerelease To: Fred Fish cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Mon, 7 Aug 1995, Fred Fish wrote: > > 2. As Lars Hecking pointed out a few days ago, no patches have been > > applied to "include". Below is a repost of my "sys/cdefs.h" patch: > > > > diff -c include/sys/cdefs.h.orig include/sys/cdefs.h > > *** include/sys/cdefs.h.orig Sun Jul 30 16:18:09 1995 > > --- include/sys/cdefs.h Sun Jul 30 16:18:42 1995 > > *************** > > *** 52,58 **** > > --- 52,60 ---- > > * strings produced by the __STRING macro, but this only works with ANSI C. > > */ > > #if defined(__STDC__) || defined(__cplusplus) > > + #ifndef __P > > #define __P(protos) protos /* full-blown ANSI C */ > > + #endif /* __P */ > > #define __CONCAT(x,y) x ## y > > Names beginning with "__" are reserved and must not be used by applications. > So in ANSI C the original definition is safe from colliding with definitions > in user applications. If an application uses __P it should be fixed to use > something like "#define PROTO(proto) proto". > > What is the motivation for this change? In g++, it causes warnings about redefinition of "__P" macro. Here's an example source: #include #include CPP produces the following warning: In file included from /gnu/include/stdlib.h:67, from bug.cxx:2: /gnu/include/sys/cdefs.h:55: warning: `__P' redefined /gnu/lib/g++-include/libio.h:62: warning: this is the location of the previous definition When I swap the lines in source, ie. first include , then , everything works well. > > -Fred > Kamil From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 12:36:34 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90891-3>; Wed, 9 Aug 1995 12:35:21 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug9.123521+0300_eet_dst.90891-3+18@nic.funet.fi> From: To: Date: Wed, 9 Aug 1995 12:35:18 +0300 Date: Wed, 9 Aug 1995 11:34:45 +0200 (METDST) From: Rask Lambertsen To: Matthias Fleischer Cc: amiga-gcc-port@nic.funet.fi Subject: Re: gcc270 prerelease bugs and notes (fwd) In-Reply-To: <9508070906.AA00781@sunserv.IZFM.Uni-Stuttgart.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 7 Aug 1995, Matthias Fleischer wrote: > > __stackborders=&FindTask(NULL)->tc_SPLower; > ^^^^^^^^^^^^^^ Note the expensive function call According to the RKRM Autodocs (third edition), FindTask(NULL) is not expensive, only FindTask(name), where name != NULL, is expensive. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 12:49:56 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90701-4>; Wed, 9 Aug 1995 12:49:30 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug9.124930+0300_eet_dst.90701-4+18@nic.funet.fi> From: To: Date: Wed, 9 Aug 1995 12:49:29 +0300 Date: Wed, 9 Aug 1995 11:48:55 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Diffs for README.libnix and README-2.7.0 (long, 13 k) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII While reading the README.libnix and README-2.7.0 files from the last gcc 2.7.0 distribution (Aug 3) I saw a few errors (speeling, grammar, etc) so I decided to correct them and make diff files (my first!). I suggest that the people involved in writing those files have a look at the diffs. I'm sure some people will think that I had '-pedantic' turned on while I was looking at those README files ;-). The first diff file is for README.libnix (24 lines): 10c10 < * starting with this release there is no installer script anymore: --- > * starting with this release there is no installer script any more: 14c14 < Short: A library for amiga specific development on gcc --- > Short: A library for Amiga specific development on gcc 22c22 < for amiga specific development on gcc: --- > for Amiga specific development on gcc: 29c29 < * It doesn't need any shared libraries than normal Amiga OS ones. --- > * It doesn't need any shared libraries other than normal Amiga OS ones. 38c38 < * It uses OS20 features whenever necessary. --- > * It uses OS 2.0 features whenever necessary. 43c43 < amiga-only programs and gcc becomes one of the best Amiga compilers. --- > Amiga-only programs and gcc becomes one of the best Amiga compilers. The second one is for README-2.7.0 (962 lines): 16c16 < There's an amiga-gcc mailing list running in Finland, read README-LIST file. --- > There's an Amiga-gcc mailing list running in Finland, read README-LIST file. 22a23,24 > (insert your own first name and your own last name above) > 35c37 < Note2: ftp.funet.fi mirrors my amigados-gnu tree. Using ftp.funet.fi is --- > Note 2: ftp.funet.fi mirrors my amigados-gnu tree. Using ftp.funet.fi is 47c49 < A minimum of 4MB free memory is needed in order to compile small/medium --- > A minimum of 4 Mb of free memory is needed in order to compile small/medium 52c54 < case, you'll need an MMU equiped amiga (A3000,A4000/40, etc...). --- > case, you'll need an MMU equipped Amiga (A3000,A4000/40, etc...). 60c62 < An installation of gcc requires the use of a hard disk. Approximately 10MB is --- > An installation of gcc requires the use of a hard disk. Approximately 10 Mb is 62c64 < In addition 3MB is required for the Commodore Developer Kit, which is required --- > In addition 3 Mb is required for the Commodore Developer Kit, which is required 96c98 < - new environnement variables GCCPRIORITY and GCCSTACK, see below. --- > - new environent variables GCCPRIORITY and GCCSTACK, see below. 98c100 < - mit2mot & mot2mit, convert asm syntax between Motorala and MIT syntaxes. --- > - mit2mot & mot2mit, convert asm syntax between Motorola and MIT syntaxes. 116c118 < - q_anote, anotate assembly files mixing C source code, submitted by Walter --- > - q_anote, annotate assembly files mixing C source code, submitted by Walter 143,144c145,146 < - ld behavior over symbols changed (see note below). < - added flavors so that linker will take appropriate libraries according to --- > - ld behaviour over symbols changed (see note below). > - added flavours so that linker will take appropriate libraries according to 151c153 < - GCC-Install script fixed by Claus Deckhut (to be used with full distrib). --- > - GCC-Install script fixed by Claus Deckhut (to be used with full distribution). 180c182 < Raphel Luebbert, --- > Raphael Luebbert, 211,212c213,214 < and configure for `amigados'. Please note that you should have at least 40MB < left or your HD and 8MB of memory minimum in order to rebuild gcc up to stage3. --- > and configure for `amigados'. Please note that you should have at least 40 Mb > left or your HD and 8 Mb of memory minimum in order to rebuild gcc up to stage 3. 249c251 < All sources archives are amiga ready, and amiga specific diff file located --- > All sources archives are Amiga ready, and Amiga specific diff file located 252c254 < Exceptions are libnix, ixemul which have their own archives, both binary & --- > Exceptions are libnix and ixemul which have their own archives, both binary & 327,329c329,331 < include/ non-amiga specific C/C++ headers gcc270-inclib < os-include/proto amiga specific protos headers. gcc270-inclib < os-include/inline amiga specific inline C headers. Add gcc270-inclib --- > include/ non-Amiga specific C/C++ headers gcc270-inclib > os-include/proto Amiga specific protos headers. gcc270-inclib > os-include/inline Amiga specific inline C headers. Add gcc270-inclib 331c333 < os-lib/ amiga specific libraries gcc270-base --- > os-lib/ Amiga specific libraries gcc270-base 362,363c364,365 < Since I'm not able to redistribute amiga header files, you will have to get < them directly from Commodore, unless you're an official registrated Amiga --- > Since I'm not able to redistribute Amiga header files, you will have to get > them directly from Commodore, unless you're an official registered Amiga 365c367 < In order to generate inline-headers, follow these steps (provided amiga headers and fd files --- > In order to generate inline-headers, follow these steps (provided Amiga headers and fd files 417c419 < time. Just uncompress sources.lha from libnix distribution and run a --- > time. Just decompress sources.lha from libnix distribution and run a 422c424 < As long as you make no AmigaDOs specific calls, you can create a dummy library --- > As long as you make no AmigaDOS specific calls, you can create a dummy library 486c488 < accelerated amigas can unarchive gcc270-c-020 part instead) : --- > accelerated Amigas can unarchive gcc270-c-020 part instead) : 495c497 < accelerated amigas can unarchive gcc270-c++-020 part instead) : --- > accelerated Amigas can unarchive gcc270-c++-020 part instead) : 502,503c504 < accelerated amigas can < unarchive gcc270-objc-020 part instead) : --- > accelerated Amigas can unarchive gcc270-objc-020 part instead) : 512c513 < - If you want all utilities documentation no-line, unarchive utils-doc --- > - If you want all utilities documentation on-line, unarchive utils-doc 517c518 < - Because some programs are normally link to others, please run script: --- > - Because some programs are normally links to others, please run script: 530c531 < - If you want to build Postscipt files for Gcc documention, unarchive --- > - If you want to build Postscript files for Gcc documentation, unarchive 553,554c554,555 < This was pretty simple ;-) Now we have to compile it. < There's a lot of options in gcc but simplest way to compile this would be: --- > This was pretty simple ;-) Now we have to compile it. > There's a lot of options in gcc but the simplest way to compile this would be: 558c559 < Simple ? --- > Simple? 620c621 < for amiga specific development on gcc: --- > for Amiga specific development on gcc: 627c628 < * It doesn't need any shared libraries than normal Amiga OS ones. --- > * It doesn't need any shared libraries other than normal Amiga OS ones. 636c637 < * It uses OS20 features whenever necessary. --- > * It uses OS 2.0 features whenever necessary. 639c640 < but at the cost of an extra 200KB memory taken by shared library. --- > but at the cost of an extra 200 kb of memory taken by shared library. 644c645 < amiga-only programs and gcc becomes one of the best Amiga compilers. --- > Amiga-only programs and gcc becomes one of the best Amiga compilers. 650c651 < A common problem seen with amigados-gcc is bad redirection to sderr. --- > A common problem seen with amigados-gcc is bad redirection to stderr. 697c698 < to run at the same time, passing intermediate files thru internal pipes --- > to run at the same time, passing intermediate files through internal pipes 700c701 < As long as you don't want that feature (ok, playing with certain make tools --- > As long as you don't want that feature (OK, playing with certain make tools 707c708 < You need to have a 50.000 stack size in order to compile with GCC. This should --- > You need to have a stack size of 50000 in order to compile with GCC. This should 709c710 < has taken more than 300KB stack. Stack can grow due to source complexity. --- > has taken more than 300 kb of stack. Stack usage can grow due to source complexity. 714c715 < To use ar and/or ranlib, 50KB is the minimum acceptable. You should have a --- > To use ar and/or ranlib, 50 kb is the minimum acceptable stack. You should have a 717c718 < Starting with 2.6.3 a new environnement variable, GCCSTACK, enables gcc to --- > Starting with 2.6.3 a new environment variable, GCCSTACK, enables gcc to 726c727 < Benefits: huge memory savings. --- > Benefits: Huge memory savings. 732c733 < Starting also with 2.6.3 a new environnement variable, GCCPRIORITY, let you --- > Starting also with 2.6.3 a new environment variable, GCCPRIORITY, let you 743,745c744,746 < string.h. My suggestion for now is to add to C++ "faulty" header filename an < "_" in front of it, thus String.h would become _String.h. Sorry for < inconvenience. (thanks to Dirk Nehring for reminding me this anoying --- > string.h. My suggestion for now is to add to C++ "faulty" header file name an > "_" in front of it, thus String.h would become _String.h. Sorry for the > inconvenience. (thanks to Dirk Nehring for reminding me about this annoying 813c814 < Starting from 2.5.8 release, ld behavior over symbols has changed. Default is --- > Starting from 2.5.8 release, ld behaviour over symbols has changed. Default is 821c822 < Ld is using now flavors, which are generated depending on gcc flags: --- > Ld is using now flavours, which are generated depending on gcc flags: 828c829 < Thus ld when searching for libraries, add to search library path those flavors, --- > Thus ld when searching for libraries, adds those flavours to the library search path, 832,833c833,834 < first, then will reduce flavors, one by one, if it can't find required library < in flavor's expanded path. This means that it will try to find libgcc.a in: --- > first, then it will reduce flavours, one by one, if it can't find required library > in flavour's expanded path. This means that it will try to find libgcc.a in: 835c836 < and in /gnu/lib/. because libgcc.a exists in /gnu/lib/libm020, ld will take --- > and in /gnu/lib/. Because libgcc.a exists in /gnu/lib/libm020, ld will take 851,854c852,855 < Using this approach makes adding flavors pretty easily, if someone wants for < example to add 68881 libraries, a new flavor will hve to be created, libm881, < and thus maximum level flavor search path would be: < /gnu/lib/libb/libm020/libm881/libnix, which can be translated in english as: --- > Using this approach makes adding flavours pretty easy, if someone wants for > example to add 68881 libraries, a new flavour will have to be created, libm881, > and thus the maximum flavour search path level would be: > /gnu/lib/libb/libm020/libm881/libnix, which can be translated to English as: 864c865 < Accessing operating-system functions on the amiga requires to pass arguments --- > Accessing operating-system functions on the Amiga requires to pass arguments 870c871 < os-function convention. These glue routines are located for all system libraries --- > OS-function convention. These glue routines are located for all system libraries 872,873c873,874 < amiga c-compilers have the capability of in-line calls to os functions using < a c language extension "#pragma". The format of a pragma statement and file names --- > Amiga C-compilers have the capability of in-line calls to OS functions using > a C language extension "#pragma". The format of a pragma statement and file names 876,877c877,878 < functions into the caller. This method is known from c++ as "inlining". Thus < functions that are declared "inline" (peferable in conjunction with the keyword --- > functions into the caller. This method is known from C++ as "inlining". Thus > functions that are declared "inline" (preferable in conjunction with the keyword 882,884c883,885 < To get programs more portable between amiga c-compilers a new set of include files < would be helpful that hide the diffrent methods for in-line calls from the user. < These files are located in a drawer called proto eg. "proto/exec.h". Instead of --- > To get programs more portable between Amiga C-compilers a new set of include files > would be helpful that hide the different methods for in-line calls from the user. > These files are located in a drawer called proto e.g. "proto/exec.h". Instead of 900c901 < with "xxx" replaced with the first part of a clib proto-headers name eg. --- > with "xxx" replaced with the first part of a clib proto-headers name e.g. 917c918 < - a define on the commandline "-D__NOINLINES__" --- > - a define on the command line "-D__NOINLINES__" 949a951 > ============== 950a953 > ============== Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 12:52:24 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90046-2>; Wed, 9 Aug 1995 12:52:03 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug9.125203+0300_eet_dst.90046-2+26@nic.funet.fi> From: To: Date: Wed, 9 Aug 1995 12:52:02 +0300 Date: Wed, 9 Aug 1995 11:51:35 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Misc. questions Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Could anybody explaing to me what the '-SHORTDATA' option of 'ld' does? Is there any man pages or other documentation for 'mit2mot' and 'mot2mit'? How do I set the ixprefs settings so '/' means 'parent directory'? Setting or clearing "translate /" in ixprefs doesn't help. IMO, GCC should support the '060, does anybody want to do that? People with knowledge of '060 assembler and machine description files will be a great help. I remember that someone had the idea of making the branch predictor always guess right, that would be worth trying. Also, if anybody on the lists has an '060 equipped machine, that would help too. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 12:53:48 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90132-2>; Wed, 9 Aug 1995 12:53:28 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug9.125328+0300_eet_dst.90132-2+27@nic.funet.fi> From: To: Date: Wed, 9 Aug 1995 12:53:28 +0300 Date: Wed, 9 Aug 1995 11:53:00 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: diffs for inline/graphics.h and inline/exec.h Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have made diff files for inline/graphics.h and inline/exec.h so these files correspond better to the information in the Autodocs. Mostly, this tells the compiler that some registers aren't clobbered by a function call. In the case of the Supervisor() function, though, none of the registers are saved, so there was a potential danger in calling that function when compiling with gcc. I do believe that "cc" should be added to the list of clobbered registers for all function calls that are not documented to preserve the condition codes. Here is a quote from the "Amiga ROM Kernal Reference Manual Includes and Autodocs" third edition, page 9: "Never depend on processor condition codes after a system call. The caller must test the returned value before acting on a condition code." Btw, I only have Autodocs for calls upto OS 2.04, so there may be more calls that should be corrected. Here are the diffs. The first one is for inline/graphics.h: 2128c2128 < : "a0","a1","d0","d1", "memory"); --- > : "cc", "memory"); The second one is for inline/exec.h: 622c622 < : "a0","a1","d0","d1", "memory"); --- > : "memory"); 645c645 < : "a0","a1","d0","d1", "memory"); --- > : "memory"); 733c733 < : "a0","a1","d0","d1", "memory"); --- > : "memory"); 813c813 < : "a0","a1","d0","d1", "memory"); --- > : /* Nothing is clobbered */ ); 944c944 < : "a0","a1","d0","d1", "memory"); --- > : "memory"); 966c966 < : "a0","a1","d0","d1", "memory"); --- > : "memory"); 1032c1032 < : "a0","a1","d0","d1", "memory"); --- > : "memory"); 1085c1085 < : "a0","a1","d0","d1", "memory"); --- > : "memory"); 1399c1399 < : "a0","a1","a2","d0","d1", "memory"); --- > : "a0","a1","a2","a3","a4","a5","a6","a7","d0","d1","d2","d3","d4","d5","d6","d7","cc", "memory"); Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 12:55:21 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90307-1>; Wed, 9 Aug 1995 12:55:03 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug9.125503+0300_eet_dst.90307-1+26@nic.funet.fi> From: To: Date: Wed, 9 Aug 1995 12:55:00 +0300 Date: Wed, 9 Aug 1995 11:54:32 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: -resident is seriously buggy! Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII That's right, -resident is seriously buggy in the latest gcc 2.7.0 release. Try that nice example program from Hans Verkiul (I think): #include struct some_struct { struct other_struct *data; char *string; }; struct other_struct { int a,b; }; char message[] = "Hey you"; struct other_struct os = {7, 17 }; const struct some_struct ss1 = { &os, message }; struct some_struct ss2 = { &os, message }; int main (int argc, char *argv[]) { os.a = 19; printf ("19 = %d\n", ss1.data->a); /* This results in "19 = 7" * whenever this program is * invoked, if resident! */ printf ("19 = %d\n", ss2.data->a); /* This should be "19 = 19"! */ return (0); } Save it as "resident-test.c" and compile: 5. HD1:gnu> gcc resident-test.c -resident -o resident-test_GCC 5. HD1:gnu> resident resident-test_GCC PURE 5. HD1:gnu> ;gcc forgets to set the ^^^^ 'p' attribute Now open a second shell. Start 'resident-test_GCC' and immediately press to stop output, wait a few seconds, then quickly press and so that only the first line is output (this might be difficult on a fast machine). Then go back to the first shell and start the program as normal. It won't work. Now arrange the shell windows so that you can see both of them at the same time. Go back to the second shell and press to let the program output text again. *Now* the other program (in the first shell) will output it's two lines of text and exit. Obviously, something doesn't work quite the way it was intended. As a comparison, DICE refuses to compile the example: HD1:gnu> dcc resident-test.c -r -o resident-test_DICE DC1: Error Line 18: "resident-test.c" unrelocatable data reference in const storage DC1: Error Line 18: "resident-test.c" unrelocatable data reference in const storage Exit code 1 Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 13:12:06 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90937-2>; Wed, 9 Aug 1995 13:11:40 +0300 Received: by colombo.telesys-innov.fr; Wed, 9 Aug 1995 12:11:49 +0100 From: Philippe BRAND Message-Id: <199508091111.MAA18131@colombo.telesys-innov.fr> Subject: Re: minor update to distribution To: robert@pdi.lodz.pl Date: Wed, 9 Aug 1995 12:11:48 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <211c54d8.u7t157e.b12e3-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Aug 9, 95 10:54:20 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 437 Robert Ramiega writes: > cpp: "***NULL POINTER***", line 0: Warning: Unknown option "-Asystem(amigados)" I'm currently working on a fix for resident sent to me a few days ago. I must have done something weird to amigados.h, I'll have a deep look tonight. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 13:15:55 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90724-2>; Wed, 9 Aug 1995 13:15:31 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA06134; Wed, 9 Aug 1995 12:17:11 +0200 Date: Wed, 9 Aug 1995 12:17:10 +0200 (MET DST) From: Kamil Iskra Subject: Re: Diffs for README.libnix and README-2.7.0 (long, 13 k) To: gc948374@gbar.dtu.dk cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Aug9.124930+0300_eet_dst.90701-4+18@nic.funet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 9 Aug 1995 gc948374@gbar.dtu.dk wrote: > While reading the README.libnix and README-2.7.0 files from > the last gcc 2.7.0 distribution (Aug 3) I saw a few errors > (speeling, grammar, etc) so I decided to correct them and make > diff files (my first!). > > I suggest that the people involved in writing those files have a > look at the diffs. > > I'm sure some people will think that I had '-pedantic' turned on > while I was looking at those README files ;-). > > [diffs removed] It think you are generally right about this changes, but one think is definitely wrong: megabytes==MB!=Mb && kilobytes==KB!=kb. > _________________________________________________________________________ > / \ > | Rask Ingemann Lambertsen , | > | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | > | Keyboard error: and are stuck - press to continue | > \_________________________________________________________________________/ / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 13:24:24 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90873-4>; Wed, 9 Aug 1995 13:23:34 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id MAA04701; Wed, 9 Aug 1995 12:21:05 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id LAA17401; Wed, 9 Aug 1995 11:13:22 +0200 Date: Wed, 9 Aug 1995 11:13:22 +0200 From: Niklas Hallqvist Message-Id: <199508090913.LAA17401@linda.appli.se> To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95Aug9.124930+0300_eet_dst.90701-4+18@nic.funet.fi> (gc948374@gbar.dtu.dk) Subject: Readme diffs >>>>> "Rask" == gc948374 writes: FYI Your mail is still getting the Subject header into the body. Rask> While reading the README.libnix and README-2.7.0 files from Rask> the last gcc 2.7.0 distribution (Aug 3) I saw a few errors Rask> (speeling, grammar, etc) so I decided to correct them and make ^^^^^^^^ <- A joke, right :-) Rask> diff files (my first!). I only read the first few lines, and gave up when I saw the extent of the diffs. However: Rask> 10c10 Rask> < * starting with this release there is no installer script anymore: Rask> --- Rask> > * starting with this release there is no installer script any more: What? Do you mean to say that the latter is more correct? Rask> 14c14 Rask> < Short: A library for amiga specific development on gcc Rask> --- Rask> > Short: A library for Amiga specific development on gcc Perhaps we should upcase GCC as well, wherever the product is referred to, as opposed to referring to the command itself. It is an acronym and it's in capitals in the GCC manual, if I remember correctly. Anyway, I do this regularily in private mail and such, as I've always had the impression that it is the correct way to write it. Here, I stopped looking through the patches... Niklas From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 13:25:04 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90315-3>; Wed, 9 Aug 1995 13:23:30 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id MAA04710; Wed, 9 Aug 1995 12:21:07 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id LAA17436; Wed, 9 Aug 1995 11:16:30 +0200 Date: Wed, 9 Aug 1995 11:16:30 +0200 From: Niklas Hallqvist Message-Id: <199508090916.LAA17436@linda.appli.se> To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95Aug9.125203+0300_eet_dst.90046-2+26@nic.funet.fi> (gc948374@gbar.dtu.dk) >>>>> "Rask" == gc948374 writes: Rask> IMO, GCC should support the '060, does anybody want to do that? Doesn't it? Or do you mean that the optimizer should have a flag telling it optimize for 060? Otherwise I cannot imagine GCC wouldn't support it already, as it brings no new usermode instructions, right? Niklas From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 13:35:46 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90952-2>; Wed, 9 Aug 1995 13:35:23 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug9.133523+0300_eet_dst.90952-2+31@nic.funet.fi> From: To: Date: Wed, 9 Aug 1995 13:35:17 +0300 Date: Wed, 9 Aug 1995 12:34:21 +0200 (METDST) From: Rask Lambertsen To: Niklas Hallqvist Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Readme diffs In-Reply-To: <199508090913.LAA17401@linda.appli.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 9 Aug 1995, Niklas Hallqvist wrote: > >>>>> "Rask" == gc948374 writes: > > FYI Your mail is still getting the Subject header into the body. I know (I get a copy of my letters from the mailserver too), there is not much I can do, whereever the mailserver gets my mail from, something f...s up my mail headers. I think there is a broken gateway somewhere in Sweden (or Finland), as some people *do* get intact headers. > Rask> While reading the README.libnix and README-2.7.0 files from > Rask> the last gcc 2.7.0 distribution (Aug 3) I saw a few errors > Rask> (speeling, grammar, etc) so I decided to correct them and make > ^^^^^^^^ <- A joke, right :-) Yep. > Rask> diff files (my first!). > > I only read the first few lines, and gave up when I saw the extent of > the diffs. However: > > Rask> 10c10 > Rask> < * starting with this release there is no installer script anymore: > Rask> --- > Rask> > * starting with this release there is no installer script any more: > > What? Do you mean to say that the latter is more correct? That is what the Wordworth 2 spell checker tells me. > Rask> 14c14 > Rask> < Short: A library for amiga specific development on gcc > Rask> --- > Rask> > Short: A library for Amiga specific development on gcc > > Perhaps we should upcase GCC as well, wherever the product is referred > to, as opposed to referring to the command itself. It is an acronym > and it's in capitals in the GCC manual, if I remember correctly. You're right, I'll make some new diffs. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 13:38:11 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90746-4>; Wed, 9 Aug 1995 13:37:54 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug9.133754+0300_eet_dst.90746-4+19@nic.funet.fi> From: To: Date: Wed, 9 Aug 1995 13:37:49 +0300 Date: Wed, 9 Aug 1995 12:37:16 +0200 (METDST) From: Rask Lambertsen To: Niklas Hallqvist Cc: amiga-gcc-port@nic.funet.fi Subject: Re: 68060 support In-Reply-To: <199508090916.LAA17436@linda.appli.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 9 Aug 1995, Niklas Hallqvist wrote: > >>>>> "Rask" == gc948374 writes: > > Rask> IMO, GCC should support the '060, does anybody want to do that? > > Doesn't it? Or do you mean that the optimizer should have a flag > telling it optimize for 060? Otherwise I cannot imagine GCC wouldn't > support it already, as it brings no new usermode instructions, right? AFAIK, at least some of the floating point instructions have changed. Some '040 ones are gone and some '882 ones have been added. And yes, I do mean a flag like '-m68060'. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 14:09:51 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90369-4>; Wed, 9 Aug 1995 14:08:18 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id NAA17141; Wed, 9 Aug 1995 13:06:00 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id LAA17649; Wed, 9 Aug 1995 11:58:40 +0200 Date: Wed, 9 Aug 1995 11:58:40 +0200 From: Niklas Hallqvist Message-Id: <199508090958.LAA17649@linda.appli.se> To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Rask Lambertsen on Wed, 9 Aug 1995 12:34:21 +0200 (METDST)) Subject: Re: Readme diffs >>>>> "Rask" == Rask Lambertsen writes: >> What? Do you mean to say that the latter is more correct? Rask> That is what the Wordworth 2 spell checker tells me. Well, "spell" on Unix accepts it. I may even think "any more" would be a grammatical error in that sentence. I would use the language like below. What do you say, English natives? I'm not happy anymore. I'm not happy, not any more than you are. But I may well be wrong, esp. on the last one. Niklas From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 14:10:57 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90211-2>; Wed, 9 Aug 1995 14:09:30 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id MAA21588; Wed, 9 Aug 1995 12:07:38 +0100 From: Lars Hecking Message-Id: <199508091110.MAA05189@mostar.nmrc.ucc.ie> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Wed, 9 Aug 1995 12:10:37 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <95Aug9.125203+0300_eet_dst.90046-2+26@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 9, 95 12:52:02 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 904 > Could anybody explaing to me what the '-SHORTDATA' option of 'ld' does? Not offhand, but this brings up another issue: there is no comprehensive documentation of all amiga-specific gcc/ld options, neither in README nor the FAQ. > IMO, GCC should support the '060, does anybody want to do that? People > with knowledge of '060 assembler and machine description files will > be a great help. I remember that someone had the idea of making the > branch predictor always guess right, that would be worth trying. > Also, if anybody on the lists has an '060 equipped machine, that would > help too. The 040 and 060 are pretty much alike, with only minor difference. Ralph Schmidt's 68060Guide on Aminet lists some asm instructions that should/should not be used on 68040 and 68060. IMHO, most of the benefits for 060 users could be achieved by modification of gas (eg. instruction reordering). From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 14:12:06 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90718-3>; Wed, 9 Aug 1995 14:11:01 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id MAA21605; Wed, 9 Aug 1995 12:09:28 +0100 From: Lars Hecking Message-Id: <199508091112.MAA05200@mostar.nmrc.ucc.ie> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Wed, 9 Aug 1995 12:12:28 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <95Aug9.125328+0300_eet_dst.90132-2+27@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 9, 95 12:53:28 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 246 > Here are the diffs. The first one is for inline/graphics.h: > > 2128c2128 > < : "a0","a1","d0","d1", "memory"); > --- > > : "cc", "memory"); PLEASE PLEASE PLEASE use context diffs only! They are much easier to read and understand! From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 14:36:52 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90687-3>; Wed, 9 Aug 1995 14:36:26 +0300 Received: from mailhub.uni-konstanz.de (actually host pan.rz.uni-konstanz.de) by funet.fi with SMTP (PP); Wed, 9 Aug 1995 14:36:21 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 9 Aug 1995 13:33:10 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA23753; Wed, 9 Aug 95 13:33:21 +0200 Date: Wed, 9 Aug 95 13:33:20 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508091133.AA23753@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02750; Wed, 9 Aug 95 13:33:21 +0200 To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Subject: gas and 68040 (Re: your mail) In-Reply-To: <199508091110.MAA05189@mostar.nmrc.ucc.ie> References: <95Aug9.125203+0300_eet_dst.90046-2+26@nic.funet.fi> <199508091110.MAA05189@mostar.nmrc.ucc.ie> Lars Hecking writes: > should/should not be used on 68040 and 68060. IMHO, most of the benefits > for 060 users could be achieved by modification of gas (eg. instruction > reordering). I thought that the 68040 would benefit from it too. I tried -mc68020-40 but found no differences to -mc68020. Is it a no-op? Are you sure that the assembler is the one that must do instruction reordering, not the compiler? Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 14:46:09 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90398-1>; Wed, 9 Aug 1995 14:45:33 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 9 Aug 1995 13:44:45 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA23786; Wed, 9 Aug 95 13:44:55 +0200 Date: Wed, 9 Aug 95 13:44:55 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508091144.AA23786@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02752; Wed, 9 Aug 95 13:44:55 +0200 To: amiga-gcc-port Subject: Re: gcc270 prerelease bugs and notes (fwd) In-Reply-To: <95Aug9.123521+0300_eet_dst.90891-3+18@nic.funet.fi> References: <95Aug9.123521+0300_eet_dst.90891-3+18@nic.funet.fi> gc948374@gbar.dtu.dk writes: > > __stackborders=&FindTask(NULL)->tc_SPLower; > > ^^^^^^^^^^^^^^ Note the expensive function call > > According to the RKRM Autodocs (third edition), FindTask(NULL) is not > expensive, only FindTask(name), where name != NULL, is expensive. One would argue that it's certainly more expensive than SysBase->thistask, but then this is not an object-oriented approach. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 14:48:04 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90765-2>; Wed, 9 Aug 1995 14:47:34 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug9.144734+0300_eet_dst.90765-2+35@nic.funet.fi> From: To: Date: Wed, 9 Aug 1995 14:47:29 +0300 Date: Wed, 9 Aug 1995 13:46:54 +0200 (METDST) From: Rask Lambertsen To: Lars Hecking Cc: Amiga GCC List Subject: Re: your mail In-Reply-To: <199508091112.MAA05200@mostar.nmrc.ucc.ie> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 9 Aug 1995, Lars Hecking wrote: > > > Here are the diffs. The first one is for inline/graphics.h: > > > > 2128c2128 > > < : "a0","a1","d0","d1", "memory"); > > --- > > > : "cc", "memory"); > > PLEASE PLEASE PLEASE use context diffs only! They are much easier > to read and understand! graphics.library/WaitBlit() Unfortunately, context diffs are so much larger, but OK, I'll see which options are needed (and apply them the next time I 'diff'). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 14:49:49 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90210-2>; Wed, 9 Aug 1995 14:49:21 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id MAA22213; Wed, 9 Aug 1995 12:47:35 +0100 From: Lars Hecking Message-Id: <199508091150.MAA05323@mostar.nmrc.ucc.ie> Subject: Re: gas and 68040 (Re: your mail) To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Wed, 9 Aug 1995 12:50:35 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9508091133.AA23753@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 9, 95 01:33:20 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 692 > Lars Hecking writes: > > should/should not be used on 68040 and 68060. IMHO, most of the benefits > > for 060 users could be achieved by modification of gas (eg. instruction > > reordering). > I thought that the 68040 would benefit from it too. I tried > -mc68020-40 but found no differences to -mc68020. Is it a no-op? Dunno. As a side note, I found that -m68030 compiled code was bigger and ran slower on my A3k than -m68020 compiled code. Why? > Are you sure that the assembler is the one that must do instruction > reordering, not the compiler? No, but I thought this would be easier to implement. Otherwise, we'd indeed need a new machine description for every new cpu. From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 14:50:40 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90926-1>; Wed, 9 Aug 1995 14:50:23 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id MAA22221; Wed, 9 Aug 1995 12:48:46 +0100 From: Lars Hecking Message-Id: <199508091151.MAA05341@mostar.nmrc.ucc.ie> Subject: Re: your mail To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Wed, 9 Aug 1995 12:51:46 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Rask Lambertsen" at Aug 9, 95 01:46:54 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 316 > > PLEASE PLEASE PLEASE use context diffs only! They are much easier > > to read and understand! > > graphics.library/WaitBlit() > > Unfortunately, context diffs are so much larger, but OK, I'll see > which options are needed (and apply them the next time I 'diff'). In general, diff -2cw is not too bad ;) From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 14:51:51 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90602-2>; Wed, 9 Aug 1995 14:51:29 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug9.145129+0300_eet_dst.90602-2+36@nic.funet.fi> From: To: Date: Wed, 9 Aug 1995 14:51:23 +0300 Date: Wed, 9 Aug 1995 13:49:57 +0200 (METDST) From: Rask Lambertsen To: Joerg-Cyril Hoehle Cc: amiga-gcc-port Subject: Re: gcc270 prerelease bugs and notes (fwd) In-Reply-To: <9508091144.AA23786@inf-wiss.uni-konstanz.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 9 Aug 1995, Joerg-Cyril Hoehle wrote: > gc948374@gbar.dtu.dk writes: > > > __stackborders=&FindTask(NULL)->tc_SPLower; > > > ^^^^^^^^^^^^^^ Note the expensive function call > > > > According to the RKRM Autodocs (third edition), FindTask(NULL) is not > > expensive, only FindTask(name), where name != NULL, is expensive. > One would argue that it's certainly more expensive than > SysBase->thistask, but then this is not an object-oriented approach. Are jou sure 'SysBase->thistask' can be trusted? I don't have the docs handy right now, so I can't check it, but I don't think we are allowed to depend on 'SysBase->thistask'. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 15:06:29 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90526-2>; Wed, 9 Aug 1995 15:05:26 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 9 Aug 95 13:58:37 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <211c800b.u7t157e.9b7cd-robert@plukwa.pdi.lodz.pl> Subject: What's going on? Reply-To: robert@pdi.lodz.pl Content-Length: 889 To: amiga-gcc-port@nic.funet.fi Date: Wed, 9 Aug 95 13:58:37 Hi all! Today i tried to recompile ncftp 2.1.0 to look where it brokes but i got this error during recompiling of one file: gcc -O2 -DHAVE_CONFIG_H -D__AMITCP__ -DNO_INLINE_STDARG -I. Cmdlist.c -c Illegal instruction - /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cpp -lang-c gcc: Internal compiler error: program cpp got fatal signal 4 make: *** [Cmdlist.o] Error 1 Can someone explain me what's going on with it? Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 15:38:58 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90520-4>; Wed, 9 Aug 1995 15:38:23 +0300 Received: by ceylon.informatik.uni-rostock.de id OAA08385; Wed, 9 Aug 1995 14:37:55 +0200 Received: by honshu.informatik.uni-rostock.de id OAA01766; Wed, 9 Aug 1995 14:37:54 +0200 From: Gunther Nikl Message-Id: <199508091237.OAA01766@honshu.informatik.uni-rostock.de> Subject: -shortdata To: amiga-gcc-port@nic.funet.fi Date: Wed, 9 Aug 1995 14:37:54 +0200 (MET DST) In-Reply-To: <95Aug9.125203+0300_eet_dst.90046-2+26@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 9, 95 12:52:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 518 > Could anybody explaing to me what the '-SHORTDATA' option of 'ld' does? This instructs ld not to output the bss-part as zeros, but to allocate the bss space through the hunkheader. This is only useful for "-fbaserel" and "-resident", although for "-resident" ld only outputs the data part and does *not* allocate any bss space since this would be a waste of memory. Lastly, "-shortdata" is only supported by libnix since it requires some support in the startup-code for "baserel" and "resident". Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 16:18:56 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90236-3>; Wed, 9 Aug 1995 16:17:50 +0300 Received: by ceylon.informatik.uni-rostock.de id PAA08485; Wed, 9 Aug 1995 15:17:18 +0200 Received: by honshu.informatik.uni-rostock.de id PAA02186; Wed, 9 Aug 1995 15:17:18 +0200 From: Gunther Nikl Message-Id: <199508091317.PAA02186@honshu.informatik.uni-rostock.de> Subject: incorrect ReadMe-section for Inline-Headers To: amiga-gcc-port@nic.funet.fi Date: Wed, 9 Aug 1995 15:17:18 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 680 Hi! The section "Inline-Header" in the ReadMe of 2.7.0 (and previous releases) gives a wrong information. > In order to generate inline-headers, follow these steps (provided > amiga headers and fd files are in os-include). If you are running > under Kickstart 3.1, you don't have to generate them, inlines are > provided with distribution. The last sentence is *totally* wrong and causes much trouble since now often people go and try to create new inlines, only because they "only" have V37 of the OS. The point is, that the inlines are *useable* with *every* OS, since they cover all *previous* OS versions. This should really corrected. Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 18:09:23 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90884-1>; Wed, 9 Aug 1995 18:06:07 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 9 Aug 1995 17:05:28 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA24285; Wed, 9 Aug 95 17:05:38 +0200 Date: Wed, 9 Aug 95 17:05:38 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508091505.AA24285@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02800; Wed, 9 Aug 95 17:05:38 +0200 To: amiga-gcc-port@nic.funet.fi Subject: -shortdata In-Reply-To: <199508091237.OAA01766@honshu.informatik.uni-rostock.de> References: <95Aug9.125203+0300_eet_dst.90046-2+26@nic.funet.fi> <199508091237.OAA01766@honshu.informatik.uni-rostock.de> Gunther Nikl writes: > This instructs ld not to output the bss-part as zeros, but to allocate > the bss space through the hunkheader. This is only useful for "-fbaserel" > and "-resident", although for "-resident" ld only outputs the data part > and does *not* allocate any bss space since this would be a waste of > memory. > Lastly, "-shortdata" is only supported by libnix since it requires some > support in the startup-code for "baserel" and "resident". Could all these dependencies be documented somewhere? Not everybody is using ixemul or libnix startup code and I'd like to know if there are some useful options to pass to cpp, cc1, gas or ld. Why should ld output BSS as zeroes (unnecessarily growing the executable size?)? The DOS hunks allow an actual hunk size smaller than what the header says. Some compilers (actually linkers?) use this for their BSS. Did I miss something? Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 18:11:50 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90735-2>; Wed, 9 Aug 1995 18:11:08 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26482-1>; Wed, 9 Aug 1995 17:10:35 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209168-1>; Wed, 9 Aug 1995 17:10:22 +0100 Subject: Re: your mail From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Wed, 9 Aug 1995 17:10:20 +0200 (MESZ) In-Reply-To: <199508091110.MAA05189@mostar.nmrc.ucc.ie> from "Lars Hecking" at Aug 9, 95 12:10:37 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 604 Message-Id: <95Aug9.171022+0100mesz.209168-1+1186@hphalle0.informatik.tu-muenchen.de> > should/should not be used on 68040 and 68060. IMHO, most of the benefits > for 060 users could be achieved by modification of gas (eg. instruction > reordering). Hm.. I believe that instruction reordering is the task of the compiler. No assembler I have seen actually understands what it is assembling, so how can it reorder instructions? Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 18:15:30 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90338-1>; Wed, 9 Aug 1995 18:14:44 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26481-3>; Wed, 9 Aug 1995 17:14:03 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209167-1>; Wed, 9 Aug 1995 17:13:55 +0100 Subject: Re: your mail From: Christian Stieber To: gc948374@gbar.dtu.dk Date: Wed, 9 Aug 1995 17:13:51 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Aug9.145129+0300_eet_dst.90602-2+36@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 9, 95 02:51:23 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 834 Message-Id: <95Aug9.171355+0100mesz.209167-1+1189@hphalle0.informatik.tu-muenchen.de> > Are jou sure 'SysBase->thistask' can be trusted? I don't have the docs > handy right now, so I can't check it, but I don't think we are allowed > to depend on 'SysBase->thistask'. I don't have the RKMs handy, but this is from exec/execbase.h: struct Task *ThisTask; /* pointer to current task (readable) */ Well, it says "readable". Since AmigaOS can't support SMP anyway without additional changes, it seems safe enough to use ThisTask (although I personally use FindTask(NULL)). > | Rask Ingemann Lambertsen , | Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 18:32:27 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <87913-1>; Wed, 9 Aug 1995 18:31:39 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id QAA25736; Wed, 9 Aug 1995 16:29:38 +0100 From: Lars Hecking Message-Id: <199508091532.QAA05603@mostar.nmrc.ucc.ie> Subject: Re: your mail To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Wed, 9 Aug 1995 16:32:38 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Christian Stieber" at Aug 9, 95 05:10:20 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 438 > > should/should not be used on 68040 and 68060. IMHO, most of the benefits > > for 060 users could be achieved by modification of gas (eg. instruction > > reordering). > > Hm.. I believe that instruction reordering is the task of the compiler. > No assembler I have seen actually understands what it is assembling, > so how can it reorder instructions? Sounds logical to me. But, then again, I'm not into compiler internals :-) From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 19:33:38 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <90591-4>; Wed, 9 Aug 1995 19:32:44 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id SAA26427 (8.6.10/2.4); Wed, 9 Aug 1995 18:32:48 +0200 Date: Wed, 9 Aug 1995 18:32:48 +0200 From: Olaf Seibert Message-Id: <199508091632.SAA26427@septimius.mbfys.kun.nl> To: amiga-gcc-port@nic.funet.fi, hoehle@inf-wiss.uni-konstanz.de Subject: Re: -shortdata hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) > Why should ld output BSS as zeroes (unnecessarily growing the > executable size?)? The DOS hunks allow an actual hunk size smaller > than what the header says. Some compilers (actually linkers?) use this > for their BSS. Did I miss something? If the BBS is appended to the DATA hunk, and does not explicitly contain zeros, (i.e. the contents of the hunk are shorter than its size) it is left uninitialised. The startup code *must* clear it then. This requires the startup code to know that, so requiring a special option for this behaviour seems the correct thing to do. -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 22:05:28 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90372-1>; Wed, 9 Aug 1995 22:04:13 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sgGSN-0004nYC; Wed, 9 Aug 95 12:06 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: GCC 2.7.0 Prerelease To: kiskra@ernie.icslab.agh.edu.pl Date: Wed, 9 Aug 1995 12:06:22 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Aug 9, 95 11:07:06 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 914 > > > #if defined(__STDC__) || defined(__cplusplus) > > > + #ifndef __P > > > #define __P(protos) protos /* full-blown ANSI C */ > > > + #endif /* __P */ > > > #define __CONCAT(x,y) x ## y > > What is the motivation for this change? > In g++, it causes warnings about redefinition of "__P" macro. Here's an > example source: > > #include > #include > > CPP produces the following warning: > > In file included from /gnu/include/stdlib.h:67, > from bug.cxx:2: > /gnu/include/sys/cdefs.h:55: warning: `__P' redefined > /gnu/lib/g++-include/libio.h:62: warning: this is the location of the > previous definition This is due to libio.h from libg++. I asked the libg++ author about this and got back email which indicates that the conflict has been resolved in libg++, so there is no need to change the header. The fix will be in the next libg++ release. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 09:13:23 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <87938-2>; Thu, 10 Aug 1995 09:11:48 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA08473 (5.65b/CWI-3.3); Thu, 10 Aug 1995 08:11:17 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sgQZK-000FbbC; Thu, 10 Aug 95 07:54 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <08pz@wyst.hobby.nl>; Wed, 9 Aug 95 20:37:52 CET Message-Id: <9508091937.08pz@wyst.hobby.nl> Date: Wed, 9 Aug 1995 20:37:50 +0000 (CET) In-Reply-To: <95Aug9.125503+0300_eet_dst.90307-1+26@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 9, 95 12:55:00 pm Content-Type: text Content-Length: 1530 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: > Now open a second shell. Start 'resident-test_GCC' and immediately press > to stop output, wait a few seconds, then quickly press > and so that only the first line is output (this might be difficult > on a fast machine). > > Then go back to the first shell and start the program as normal. > It won't work. Now arrange the shell windows so that you can see both > of them at the same time. Go back to the second shell and press > to let the program output text again. *Now* the other > program (in the first shell) will output it's two lines of text and > exit. > > Obviously, something doesn't work quite the way it was intended. Which ixemul version do you use? I've tried it here and it worked OK. However, a similar bug has been fixed in ixemul.library. You can test if this is the culprit by compiling the test program without -resident and running the test again. The same problem should arise. Note that even after applying the patches to gcc (I've mailed these to both Philippe and Fred) 'make' still misbehaves when compiled resident. I suspect that it is something tricky in ixemul.library or the startup code. I've been trying to find the bug but no luck so far. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 10:28:49 1995 Received: from elixir.e.kth.se ([130.237.48.5]) by nic.funet.fi with SMTP id <88016-1>; Thu, 10 Aug 1995 10:27:27 +0300 Received: from brahms.e.kth.se (brahms.e.kth.se [130.237.48.133]) by elixir.e.kth.se (8.6.8.1/8.6.6) with ESMTP id JAA03695 for ; Thu, 10 Aug 1995 09:27:08 +0200 Received: (e90_dny@localhost) by brahms.e.kth.se (8.6.8.1/8.6.6) id JAA08161; Thu, 10 Aug 1995 09:27:07 +0200 Message-Id: <199508100727.JAA08161@brahms.e.kth.se> From: To: amiga-gcc-port@nic.funet.fi Subject: How do I get 'String' to work? Date: Thu, 10 Aug 1995 09:27:06 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: DennyĊ berg ^-illegal control character Hello. I cannot get the 'String'-class to work. I have Gcc version 2.6.3. and ixemul library 41.1. If I compile a program like the one following "#include #include <_String.h> int main(void) { String str; return 0; }" I get linkage(?Is that the english word?) problem. The linker cannot find the code for the header file. It doesn't help to type '-lg++' when linking. It shouldn't either, since if I understand it correctly libg++.a is always included if I use g++. What should I do? My hardware setup is an A1200 with blizzard 030 50MHz, but I suspect that is of no importance. From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 11:05:59 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <88022-4>; Thu, 10 Aug 1995 11:04:27 +0300 Received: by colombo.telesys-innov.fr; Thu, 10 Aug 1995 10:04:56 +0100 From: Philippe BRAND Message-Id: <199508100904.KAA20829@colombo.telesys-innov.fr> Subject: Re: To: hans@wyst.hobby.nl (Hans Verkuil) Date: Thu, 10 Aug 1995 10:04:56 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9508091937.08pz@wyst.hobby.nl> from "Hans Verkuil" at Aug 9, 95 08:37:50 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 680 Hans Verkuil writes: > Which ixemul version do you use? I've tried it here and it worked OK. I even recompiled the whole ixemul package, but I couldn't build resident version of gcc (with your patches applied), although your test program does work correctly.Anyway I'll make another distribution as your patch does fix const problem. For those willing to test gcc on Sparc sunos, I've already built a cross compiler with latest patches applied. It succeded in recompiling while ixemul for example. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 11:10:25 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <88017-2>; Thu, 10 Aug 1995 11:09:21 +0300 Received: by colombo.telesys-innov.fr; Thu, 10 Aug 1995 10:09:57 +0100 From: Philippe BRAND Message-Id: <199508100909.KAA20846@colombo.telesys-innov.fr> Subject: Code freeze in gcc To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Thu, 10 Aug 1995 10:09:56 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 428 I'm now freezing Amiga gcc-2.7.0 code, and will built definitive distribution, unless magical code fixing either gcc or ixemul comes before Saturday. This time I'll build also source code archive for gcc, so that people can work on compiler itself. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 13:55:56 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <88070-4>; Thu, 10 Aug 1995 13:54:25 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 10 Aug 1995 12:27:47 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA25839; Thu, 10 Aug 95 12:26:33 +0200 Date: Thu, 10 Aug 95 12:26:33 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508101026.AA25839@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02919; Thu, 10 Aug 95 12:25:42 +0200 To: amiga-gcc-port@nic.funet.fi Subject: comments and questions about gcc270 Hi, o Where should gcc -c misc/strlen.c put strlen.o? I found that GCC258 created misc/strlen.o while GCC270 put strlen.o in the current directory. This different behaviour broke a Makefile of mine. o Can anybody comment on this assembly code? int strlen(const char* str) { register const char* ptr = str; while (*ptr++) ; return (ptr - str) -1; } GCC270 generates _strlen: movel sp@(4),d0 movel d0,a0 L6: tstb a0@+ jne L6 subl d0,a0 | 2 movel a0,d0 | 2 subql #1,d0 rts nop while GCC258 uses this instead subl a0,d0 | 2 negl d0 | 2 I verified that the instructions have the same length, but what's about speed? o BTW, ixem41.1-src contains the following strlen.s: moveq #-1,d0 movl sp@(4),a0 /* string */ slloop: addql #1,d0 /* increment count */ tstb a0@+ /* null? */ jne slloop /* no, keep going */ rts Isn't this slower because of more instructions in the loop? (Let's start the strlen assembly contest :-) Or does it make no difference because RAM can't be accessed fast enough? o Why doesn't ar show the __.SYMDEF entry anymore? How do I know if it's there? Is ar always running ranlib itself now? o I'm trying hard to prevent GCC from reloading A6 for several OS calls in a row, unsuccessfully so far: The idea is that the library base be declared const, but it doesn't seem to work because of the "memory" clobber in the __asm() -------- a-usage.c #include /* from inline/exec.h*/ #include #include __BEGIN_DECLS #ifndef BASE_EXT_DECL #define BASE_EXT_DECL extern struct ExecBase * const SysBase; #endif #define BASE_PAR_DECL #define BASE_PAR_DECL0 void #define BASE_NAME SysBase static __inline void CloseLibrary (BASE_PAR_DECL struct Library *library) { BASE_EXT_DECL register struct ExecBase *a3 __asm("a3") = BASE_NAME; register struct Library *a1 __asm("a1") = library; __asm __volatile ("jsr a3@(-0x19e)" : /* no output */ : "r" (a3), "r" (a1) : "a0","a1","d0","d1"); /* ,"memory" gestrichen */ } static __inline struct Library * OpenLibrary (BASE_PAR_DECL UBYTE *libName,unsigned long version) { BASE_EXT_DECL register struct Library * _res __asm("d0"); register struct ExecBase *a3 __asm("a3") = BASE_NAME; register UBYTE *a1 __asm("a1") = libName; register unsigned long d0 __asm("d0") = version; __asm __volatile ("jsr a3@(-0x228)" : "=r" (_res) : "r" (a3), "r" (a1), "r" (d0) : "a0","a1","d0","d1" ,"memory"); return _res; } /* end inline/exec.h*/ BOOL existsLibrary_m(char *name) { struct Library * temp; temp = OpenLibrary(name,0L); if (NULL == temp) CloseLibrary(temp); return (BOOL)temp; } -------- #NO_APP gcc2_compiled.: ___gnu_compiled_c: .text .even .globl _existsLibrary_m _existsLibrary_m: movel a3,sp@- movel d2,sp@- movel _SysBase,a3 movel sp@(12),a1 moveq #0,d0 #APP jsr a3@(-0x228) #NO_APP movel d0,d2 jne L5 movel _SysBase,a3 movel d0,a1 #APP jsr a3@(-0x19e) #NO_APP L5: movew d2,d0 extl d0 movel sp@+,d2 movel sp@+,a3 rts -------- With "memory" in the clobber list in the __asm() of OpenLibrary, GCC reloads SysBase even when there's the const declaration. o Can't the ___gnu_compiled_c labels be removed from the executable (e.g. ignored by the linker)? They confuse (at least) Dobj, ADis, Barfly and PowerVisor which disassemble instructions that seem to access ___gnu... where in fact they access the first real label of the object file :-( Very annoying when you've many object files, you don't know what's going on. o libstack.guide should mention that a program compiled with -mstackextend must not be compiled with the standard alloca() replacements (using malloc()) that are found in some archives. These work by comparing stack pointers. Dynamically AllocMem()'ed stack pointers can be everywhere. Programs must use the builtin_alloca()! To answer a few recent questions in this list: o According to the GURU book (chapter 22.3.8ff), PC-relative 32-bit-relocs cannot currently be used, because there's no hunk support for them. Thus if -mc68020 would know about 32-bit-relocs, it would only be possible in one hunk. The book also says (chapter 22.2.1) that LoadSeg() et al. since OS >= 2.0 are documented as clearing the unused (usually BSS) region after a short hunk. Thus 2.0 startup code (libnix) needn't do it again (but must check very early that it's running 2.0). o Mikael Karlsson's excellent Dump Amiga Load File (dalf) ARexx script choked on the cc1 executable because it has more than 16384 relocs in one hunk. If somebody is interested, I can email another version (that's also slightly faster thanks to seek()). Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 14:18:15 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <88084-3>; Thu, 10 Aug 1995 14:16:24 +0300 Received: by ceylon.informatik.uni-rostock.de id NAA12427; Thu, 10 Aug 1995 13:16:00 +0200 Received: by honshu.informatik.uni-rostock.de id NAA05262; Thu, 10 Aug 1995 13:15:58 +0200 From: Gunther Nikl Message-Id: <199508101115.NAA05262@honshu.informatik.uni-rostock.de> Subject: Re: -shortdata To: amiga-gcc-port@nic.funet.fi Date: Thu, 10 Aug 1995 13:15:58 +0200 (MET DST) In-Reply-To: <9508091505.AA24285@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 9, 95 05:05:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1530 Joerg Hoehle writes: > Gunther Nikl writes: > > This instructs ld not to output the bss-part as zeros, but to allocate > > the bss space through the hunkheader. This is only useful for "-fbaserel" > > and "-resident", although for "-resident" ld only outputs the data part > > and does *not* allocate any bss space since this would be a waste of > > memory. > > Lastly, "-shortdata" is only supported by libnix since it requires some > > support in the startup-code for "baserel" and "resident". > > Could all these dependencies be documented somewhere? Not everybody is > using ixemul or libnix startup code and I'd like to know if there are > some useful options to pass to cpp, cc1, gas or ld. Is "-shortdata" useful in any other case than "noixemul"? > Why should ld output BSS as zeroes (unnecessarily growing the > executable size?)? The DOS hunks allow an actual hunk size smaller > than what the header says. Some compilers (actually linkers?) use this > for their BSS. Did I miss something? The original ld-version (from M.Wild) always dumped the BSS part as real zeros for baserel/resident. Because this increases the executable size, I tried to add the shortdata option and succeeded. The amigados loader supported an actual hunk size smaller than what the header said, but this was not documented until OS 2.0. Thats the reason why any additional space in a data-hunk has to be cleared before the use. Since OS 2.0 the system clears the space by itself (MEMF_CLEAR :-) Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 14:30:06 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <88086-2>; Thu, 10 Aug 1995 14:28:30 +0300 Received: by ceylon.informatik.uni-rostock.de id NAA12462; Thu, 10 Aug 1995 13:27:53 +0200 Received: by honshu.informatik.uni-rostock.de id NAA05370; Thu, 10 Aug 1995 13:27:52 +0200 From: Gunther Nikl Message-Id: <199508101127.NAA05370@honshu.informatik.uni-rostock.de> Subject: Re: -shortdata To: amiga-gcc-port@nic.funet.fi Date: Thu, 10 Aug 1995 13:27:51 +0200 (MET DST) In-Reply-To: <199508091632.SAA26427@septimius.mbfys.kun.nl> from "Olaf Seibert" at Aug 9, 95 06:32:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1437 > If the BBS is appended to the DATA hunk, and does not explicitly > contain zeros, (i.e. the contents of the hunk are shorter than its > size) it is left uninitialised. The startup code *must* clear it then. > This requires the startup code to know that, so requiring a special > option for this behaviour seems the correct thing to do. Starting with OS 2.0 a bss part of a data-hunk is initialized with zeros. Although libnix requires OS2.0, the startup code of libnix does not! So its possible to write programs for < 2.0 or trying to run 2.0 only programs under < 2.0. If the bss part wouldn't be cleared the program might crash. So to use the "shortdata" option of gnu-ld, the startup code *must* support it. Thats no real problem though, I tried to convince R.Luebbert last year to do so, but I had some problems to explain to him, what I am suggested. The problem with ixemul is, that not all work is done in the startup code, but also in the library itself. The library creates a new data+bss area for resident programs, copying the old segment, BUT it always copies data+bss together (for resident there wouldn't be a bss part with "-shortdata". And in the case of "baserel" it had to clear the bss part. Gunther > > -Olaf. > -- > ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. > \X/ You are not allowed to read this using any kind of Micro$oft product. > From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 15:41:48 1995 Received: by nic.funet.fi id <88415-3>; Thu, 10 Aug 1995 15:36:03 +0300 From: Leonard Norrgard To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95Aug9.123521+0300_eet_dst.90891-3+18@nic.funet.fi> (gc948374@gbar.dtu.dk) Subject: FindTask(0) Message-Id: <95Aug10.153603+0300_eet_dst.88415-3+43@nic.funet.fi> Date: Thu, 10 Aug 1995 15:35:57 +0300 FindTask(0) should be equivalent to SysBase->ThisTask, so it's hard to see a way to make it expensive... Using SysBase->ThisTask directly is even cheaper, of course. From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 15:46:30 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <88093-3>; Thu, 10 Aug 1995 15:41:50 +0300 Received: by colombo.telesys-innov.fr; Thu, 10 Aug 1995 14:42:17 +0100 From: Philippe BRAND Message-Id: <199508101342.OAA21569@colombo.telesys-innov.fr> Subject: Re: (fwd) To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Thu, 10 Aug 1995 14:42:16 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 435 Gunther Nikl writes: > Just checked the update archive on funet.fi and the libauto.a > libs are still incomplete. This means I don't have a complete libauto.a source package. I had two Makefiles, but it seems something more exist somewhere. Somebody ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 15:48:32 1995 Received: by nic.funet.fi id <88102-1>; Thu, 10 Aug 1995 15:43:53 +0300 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi In-reply-to: <199508090916.LAA17436@linda.appli.se> (message from Niklas Hallqvist on Wed, 9 Aug 1995 11:16:30 +0200) Subject: '060 Message-Id: <95Aug10.154353+0300_eet_dst.88102-1+29@nic.funet.fi> Date: Thu, 10 Aug 1995 15:43:49 +0300 Niklas Hallqvist writes: > >>>>> "Rask" == gc948374 writes: > > Rask> IMO, GCC should support the '060, does anybody want to do that? > > Doesn't it? Or do you mean that the optimizer should have a flag > telling it optimize for 060? Otherwise I cannot imagine GCC wouldn't > support it already, as it brings no new usermode instructions, right? > > Niklas There might be a problem not with gcc but with ixemul.library. Not having an '060 myself it's hard to test... (The problem would be in exception processing). From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 16:41:17 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <88100-4>; Thu, 10 Aug 1995 16:36:38 +0300 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA18948; Thu, 10 Aug 1995 15:36:00 +0200 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA01223; Thu, 10 Aug 95 15:35:59 +0200 From: isthesin@TechFak.Uni-Bielefeld.DE (Stephan Thesing) Message-Id: <9508101535.ZM1221@moos.TechFak.Uni-Bielefeld.DE> Date: Thu, 10 Aug 1995 15:35:58 +0200 In-Reply-To: Olaf Seibert "Re: -shortdata" (Aug 9, 18:32) References: <199508091632.SAA26427@septimius.mbfys.kun.nl> X-Mailer: Z-Mail (2.1.5 09aug93) To: Olaf Seibert Subject: Re: -shortdata Cc: amiga-gcc-port@nic.funet.fi On Aug 9, 18:32, Olaf Seibert wrote: > Subject: Re: -shortdata > hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) > > Why should ld output BSS as zeroes (unnecessarily growing the > > executable size?)? The DOS hunks allow an actual hunk size smaller > > than what the header says. Some compilers (actually linkers?) use this > > for their BSS. Did I miss something? > > If the BBS is appended to the DATA hunk, and does not explicitly > contain zeros, (i.e. the contents of the hunk are shorter than its > size) it is left uninitialised. The startup code *must* clear it then. > This requires the startup code to know that, so requiring a special > option for this behaviour seems the correct thing to do. > > -Olaf. Hi! Since AmigaDos 2.0 LoadSeg is documented to init the hunk space after the size specified in the header to zero. So this IS legal. Bye... Stephan -- =============================================== = Stephan Thesing = = AG Praktische Informatik = = Technische Fakult"at = = Universit"at Bielefeld = = EMail: isthesin@techfak.uni-bielefeld.de = =---------------------------------------------= = Wer den Spruch erfunden hat : = = "So einfach, wie einem Kind den Lolly = = wegzunehmen", hat noch nie versucht, = = seinem Neffen ein Bonbon zu stibitzen. = =============================================== From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 16:55:38 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <88121-3>; Thu, 10 Aug 1995 16:53:12 +0300 Received: by ceylon.informatik.uni-rostock.de id NAA12587; Thu, 10 Aug 1995 13:50:14 +0200 Received: by honshu.informatik.uni-rostock.de id NAA05550; Thu, 10 Aug 1995 13:50:14 +0200 From: Gunther Nikl Message-Id: <199508101150.NAA05550@honshu.informatik.uni-rostock.de> Subject: Re: comments and questions about gcc270 To: amiga-gcc-port@nic.funet.fi Date: Thu, 10 Aug 1995 13:50:13 +0200 (MET DST) In-Reply-To: <9508101026.AA25839@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 10, 95 12:26:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2629 Hello! > o Can anybody comment on this assembly code? > int strlen(const char* str) > { > register const char* ptr = str; > while (*ptr++) ; > return (ptr - str) -1; ^^^^^^^^^^^^^^ Try "~(str-ptr)" instead > o BTW, ixem41.1-src contains the following strlen.s: > moveq #-1,d0 > movl sp@(4),a0 /* string */ > slloop: > addql #1,d0 /* increment count */ > tstb a0@+ /* null? */ > jne slloop /* no, keep going */ > rts > Isn't this slower because of more instructions in the loop? > (Let's start the strlen assembly contest :-) Or does it make no > difference because RAM can't be accessed fast enough? Thats really a bad one... > o Why doesn't ar show the __.SYMDEF entry anymore? How do I know if > it's there? Is ar always running ranlib itself now? The gnu-ar (the one that comes with gcc) is supposed to run 'ranlinb' itself (and has the location, where to find ranlib compiled into it...) > o I'm trying hard to prevent GCC from reloading A6 for several OS > calls in a row, unsuccessfully so far: Thats what I am told Philippe some time ago, too. Maybe, its annoying to hear, that with 2.3.3 it worked... (but I think that was an optimizer bug) But the current gcc 2.7.0 is much better than 2.3.3. Even if its reloads a6 every time, the executable size is smaller (but could be even smaller by eleminating a6-reloading). Another thing i just noticed, is the following: AllocMem(100,MEMF_CLEAR) becomes moveq #100,d0 moveq #1,d1 | was "movel #0x10000,d1" in swao d1 | previous versions jsr a6@(198:W) > o Can't the ___gnu_compiled_c labels be removed from the executable > (e.g. ignored by the linker)? They confuse (at least) Dobj, ADis, > Barfly and PowerVisor which disassemble instructions that seem to > access ___gnu... where in fact they access the first real label of the > object file :-( Very annoying when you've many object files, you don't > know what's going on. Nothing gets confused, but all dissambler choose the first symbol name to show they find for an address. Since the first address in an object file has to some lables (gcc2_compiled,___gnu_compiled_c,) the correct label name is hidden and yes, it disturbs me :) > would only be possible in one hunk. The book also says (chapter > 22.2.1) that LoadSeg() et al. since OS >= 2.0 are documented as > clearing the unused (usually BSS) region after a short hunk. Thus 2.0 > startup code (libnix) needn't do it again (but must check very early > that it's running 2.0). Since the startup-code of libnix does not require 2.0, the bss-clearing has to stay in. Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 17:06:28 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88122-2>; Thu, 10 Aug 1995 17:04:11 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sgYFP-0004nYC; Thu, 10 Aug 95 07:06 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: comments and questions about gcc270 To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Thu, 10 Aug 1995 07:06:11 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9508101026.AA25839@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 10, 95 12:26:33 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 288 > o Where should gcc -c misc/strlen.c put strlen.o? I found that GCC258 > created misc/strlen.o while GCC270 put strlen.o in the current > directory. This different behaviour broke a Makefile of mine. It should go in the current directory unless a -o option specifies otherwise. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 17:20:37 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <88159-4>; Thu, 10 Aug 1995 17:18:00 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 10 Aug 1995 16:17:21 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA26415; Thu, 10 Aug 95 16:17:29 +0200 Date: Thu, 10 Aug 95 16:17:29 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508101417.AA26415@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA02966; Thu, 10 Aug 95 16:17:28 +0200 To: amiga-gcc-port@nic.funet.fi Subject: Re: comments and questions about gcc270 In-Reply-To: <199508101150.NAA05550@honshu.informatik.uni-rostock.de> References: <9508101026.AA25839@inf-wiss.uni-konstanz.de> <199508101150.NAA05550@honshu.informatik.uni-rostock.de> Gunther Nikl writes: > Try "~(str-ptr)" instead Nice! 1-complement, why didn't I think of it :-) > The gnu-ar (the one that comes with gcc) is supposed to run > 'ranlib' itself (and has the location, where to find ranlib > compiled into it...) Probably as /gnu/bin and not gnu:bin :-( > > o I'm trying hard to prevent GCC from reloading A6 for several OS > > calls in a row, unsuccessfully so far: > > Thats what I am told Philippe some time ago, too. Maybe, its > annoying to hear, that with 2.3.3 it worked... (but I think > that was an optimizer bug) I too think that it was more a bug than a feature that it worked in 2.3.3. With "memory", it would have had to reload. > Since the startup-code of libnix does not require 2.0, the bss-clearing > has to stay in. With a proper check for OS<2.0 before calling an unnecessary MemClear() :-) Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 18:49:56 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <88390-3>; Thu, 10 Aug 1995 18:48:06 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26483-2>; Thu, 10 Aug 1995 17:47:41 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209196-2>; Thu, 10 Aug 1995 17:47:28 +0100 Subject: Re: comments and questions about gcc270 From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Thu, 10 Aug 1995 17:47:26 +0200 (MESZ) In-Reply-To: <9508101417.AA26415@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 10, 95 04:17:29 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 559 Message-Id: <95Aug10.174728+0100mesz.209196-2+1728@hphalle0.informatik.tu-muenchen.de> > > Since the startup-code of libnix does not require 2.0, the bss-clearing > > has to stay in. > With a proper check for OS<2.0 before calling an unnecessary MemClear() :-) Do people use GNU-C to write programs for Joerg Hoehle. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 19:45:19 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <88187-4>; Thu, 10 Aug 1995 19:43:37 +0300 Received: by ceylon.informatik.uni-rostock.de id SAA13601; Thu, 10 Aug 1995 18:43:13 +0200 Received: by honshu.informatik.uni-rostock.de id SAA06642; Thu, 10 Aug 1995 18:43:11 +0200 From: Gunther Nikl Message-Id: <199508101643.SAA06642@honshu.informatik.uni-rostock.de> Subject: incomplete libauto To: amiga-gcc-port@nic.funet.fi Date: Thu, 10 Aug 1995 18:43:11 +0200 (MET DST) In-Reply-To: <199508101342.OAA21569@colombo.telesys-innov.fr> from "Philippe BRAND" at Aug 10, 95 02:42:16 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 597 > Gunther Nikl writes: > > > Just checked the update archive on funet.fi and the libauto.a > > libs are still incomplete. > > This means I don't have a complete libauto.a source package. I had two > Makefiles, but it seems something more exist somewhere. Somebody ? No, that means you do not have a proper make for the 'Makefile'... I do not know what 'make' was used to create libauto.a but it does not work with 'gmake'. (BTW, the correct makefile is called MakefileAJGG) Anyway I created the libraries. These will directly be send to "phb@colombo.telesys-innov.fr" Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 19:52:49 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <88108-2>; Thu, 10 Aug 1995 19:51:10 +0300 Received: by ceylon.informatik.uni-rostock.de id SAA13620; Thu, 10 Aug 1995 18:50:41 +0200 Received: by honshu.informatik.uni-rostock.de id SAA06660; Thu, 10 Aug 1995 18:50:40 +0200 From: Gunther Nikl Message-Id: <199508101650.SAA06660@honshu.informatik.uni-rostock.de> Subject: Re: -shortdata To: amiga-gcc-port@nic.funet.fi Date: Thu, 10 Aug 1995 18:50:39 +0200 (MET DST) In-Reply-To: <9508101231.AA26178@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 10, 95 02:31:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 561 > Gunther Nikl writes: > > Starting with OS 2.0 a bss part of a data-hunk is initialized with > > zeros. Although libnix requires OS2.0, the startup code of libnix > > does not! So its possible to write programs for < 2.0 or trying to > Does the startup-code check for 2.0 and not call MemClear() then? > Would be a simple, but nice addition. There is no additional function call, the clear loop is handled as its the case with SAS/C. The overhead clearing the bss part (although its already cleared) is not worth mentioning (IMHO) Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 19:58:30 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <88236-3>; Thu, 10 Aug 1995 19:56:44 +0300 Received: by ceylon.informatik.uni-rostock.de id SAA13658; Thu, 10 Aug 1995 18:56:22 +0200 Received: by honshu.informatik.uni-rostock.de id SAA06677; Thu, 10 Aug 1995 18:56:21 +0200 From: Gunther Nikl Message-Id: <199508101656.SAA06677@honshu.informatik.uni-rostock.de> Subject: Re: comments and questions about gcc270 To: amiga-gcc-port@nic.funet.fi Date: Thu, 10 Aug 1995 18:56:21 +0200 (MET DST) In-Reply-To: <95Aug10.174728+0100mesz.209196-2+1728@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Aug 10, 95 05:47:26 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 620 > > > Since the startup-code of libnix does not require 2.0, the bss-clearing > > > has to stay in. > > With a proper check for OS<2.0 before calling an unnecessary MemClear() :-) > > Do people use GNU-C to write programs for stupid to me to support 1.3. > > Christian A program written for OS 2.0 could easily be started under 1.3. it would fail, but could crash the machine only because there was crap in the bss area. BTW, its very easy to create programs with gcc that will run fine < 2.0 simply link with a startup-code that only requites ixemul 39... Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 19:59:11 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <88308-4>; Thu, 10 Aug 1995 19:57:27 +0300 Received: by ceylon.informatik.uni-rostock.de id SAA13667; Thu, 10 Aug 1995 18:57:02 +0200 Received: by honshu.informatik.uni-rostock.de id SAA06687; Thu, 10 Aug 1995 18:57:01 +0200 From: Gunther Nikl Message-Id: <199508101657.SAA06687@honshu.informatik.uni-rostock.de> Subject: Re: comments and questions about gcc270 To: amiga-gcc-port@nic.funet.fi Date: Thu, 10 Aug 1995 18:57:00 +0200 (MET DST) In-Reply-To: from "gnikl" at Aug 10, 95 06:52:25 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 491 > > > > Gunther Nikl writes: > > > Try "~(str-ptr)" instead > > Nice! 1-complement, why didn't I think of it :-) > > Thats the way libnix does it :-) > > > > The gnu-ar (the one that comes with gcc) is supposed to run > > > 'ranlib' itself (and has the location, where to find ranlib > > > compiled into it...) > > Probably as /gnu/bin and not gnu:bin :-( > > Yes, if I remember correctly, but since I use the old bsd-ar from > 2.3.3 I don't care. > > Gunther > From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 20:15:13 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <88179-3>; Thu, 10 Aug 1995 20:13:30 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189618>; Thu, 10 Aug 1995 19:12:42 +0200 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA16614; Thu, 10 Aug 1995 19:12:30 +0200 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9508101712.AA16614@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: comments and questions about gcc270 To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Thu, 10 Aug 1995 19:12:29 +0200 Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9508101026.AA25839@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 10, 95 12:26:33 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 710 > o Where should gcc -c misc/strlen.c put strlen.o? I found that GCC258 > created misc/strlen.o while GCC270 put strlen.o in the current > directory. This different behaviour broke a Makefile of mine. I would expect outputs to be going in the current dir... > GCC270 generates > _strlen: > movel sp@(4),d0 > movel d0,a0 > L6: > tstb a0@+ > jne L6 > subl d0,a0 | 2 > movel a0,d0 | 2 > subql #1,d0 > rts > nop > while GCC258 uses this instead > subl a0,d0 | 2 > negl d0 | 2 > I verified that the instructions have the same length, but what's > about speed? the move reg,reg is two cycles faster than the neg. -and it doesnt use the ALU, maybe this is even faster an 68060 ? Thomas From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 20:17:18 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <88222-3>; Thu, 10 Aug 1995 20:15:15 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 10 Aug 1995 19:14:49 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA26971; Thu, 10 Aug 95 19:14:59 +0200 Date: Thu, 10 Aug 95 19:14:59 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508101714.AA26971@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA03067; Thu, 10 Aug 95 19:15:00 +0200 To: amiga-gcc-port@nic.funet.fi Subject: Re: comments and questions about gcc270 In-Reply-To: <95Aug10.174728+0100mesz.209196-2+1728@hphalle0.informatik.tu-muenchen.de> References: <9508101417.AA26415@inf-wiss.uni-konstanz.de> <95Aug10.174728+0100mesz.209196-2+1728@hphalle0.informatik.tu-muenchen.de> Christian Stieber writes: > Do people use GNU-C to write programs for stupid to me to support 1.3. Here I am and I'd by condamned to use an old GCC if newer ones wouldn't support 1.3 any more. CLISP works fine even with 1.2. And from time to time, I even get mail from an 1.3 user. I wish everybody would have OS>=2.x too, but then many games break... Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Thu Aug 10 20:23:40 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <88127-1>; Thu, 10 Aug 1995 20:21:53 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189599>; Thu, 10 Aug 1995 19:21:17 +0200 Received: by nereid.rz.Uni-Osnabrueck.DE (AIX 3.2/UCB 5.64/2.10) id AA25080; Thu, 10 Aug 1995 19:21:11 +0200 From: thradtke@nereid.rz.Uni-Osnabrueck.DE (Thomas Radtke) Message-Id: <9508101721.AA25080@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: comments and questions about gcc270 To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Thu, 10 Aug 1995 19:21:10 +0200 Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508101150.NAA05550@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Aug 10, 95 01:50:13 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 281 > AllocMem(100,MEMF_CLEAR) > > becomes > > moveq #100,d0 > moveq #1,d1 | was "movel #0x10000,d1" in > swao d1 | previous versions > jsr a6@(198:W) It seems the code is much more optimized now. moveq+swap is only 8 cycles instead of 20 for the long move. Thomas From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 00:12:09 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89085-3>; Fri, 11 Aug 1995 00:11:16 +0300 Received: by colombo.telesys-innov.fr; Thu, 10 Aug 1995 23:11:52 +0100 From: Philippe BRAND Message-Id: <199508102211.XAA23370@colombo.telesys-innov.fr> Subject: Re: incomplete libauto To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Thu, 10 Aug 1995 23:11:51 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199508101643.SAA06642@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Aug 10, 95 06:43:11 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 532 Gunther Nikl writes: > No, that means you do not have a proper make for the 'Makefile'... > I do not know what 'make' was used to create libauto.a but it > does not work with 'gmake'. (BTW, the correct makefile is called > MakefileAJGG) > Anyway I created the libraries. These will directly be send to That's the Makefile I used... funny :) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 11:59:12 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90734-1>; Fri, 11 Aug 1995 11:55:48 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA12439; Fri, 11 Aug 1995 10:57:33 +0200 Date: Fri, 11 Aug 1995 10:57:33 +0200 (MET DST) From: Kamil Iskra Subject: libiostream.a To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please read the following extract from g++ FAQ: "In version 2.7.0 `-liostream' is gone and all the standard classes are in `-lstdc++'." So why in Amiga-GCC distribution "libiostream.a" is still included? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 12:11:24 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90474-4>; Fri, 11 Aug 1995 12:10:18 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA12470; Fri, 11 Aug 1995 11:11:29 +0200 Date: Fri, 11 Aug 1995 11:11:28 +0200 (MET DST) From: Kamil Iskra Subject: Re: GCC 2.7.0 Prerelease To: Fred Fish cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 9 Aug 1995, Fred Fish wrote: > > In g++, it causes warnings about redefinition of "__P" macro. Here's an > > example source: > > > > #include > > #include > > > > CPP produces the following warning: > > > > In file included from /gnu/include/stdlib.h:67, > > from bug.cxx:2: > > /gnu/include/sys/cdefs.h:55: warning: `__P' redefined > > /gnu/lib/g++-include/libio.h:62: warning: this is the location of the > > previous definition > > This is due to libio.h from libg++. I asked the libg++ author about > this and got back email which indicates that the conflict has been > resolved in libg++, so there is no need to change the header. The fix > will be in the next libg++ release. Fine. But, frankly speaking, this explanation sounds rather suspicious to me. "libio.h" has a protection against redefining of "__P", "cdefs.h" doesn't have. I wonder what the "correct" patch should be like... / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 12:56:02 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89959-1>; Fri, 11 Aug 1995 12:55:24 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA12583; Fri, 11 Aug 1995 11:56:42 +0200 Date: Fri, 11 Aug 1995 11:56:41 +0200 (MET DST) From: Kamil Iskra Subject: Re: comments and questions about gcc270 To: hoehle@inf-wiss.uni-konstanz.de cc: Amiga GCC List In-Reply-To: <199508101058.MAA10372@ernie.icslab.agh.edu.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 10 Aug 1995 Joerg-Cyril Hoehle wrote: > o I'm trying hard to prevent GCC from reloading A6 for several OS > calls in a row, unsuccessfully so far: > > The idea is that the library base be declared const, but it doesn't > seem to work because of the "memory" clobber in the __asm() > > -------- a-usage.c [stuff deleted] > static __inline void > CloseLibrary (BASE_PAR_DECL struct Library *library) > { > BASE_EXT_DECL > register struct ExecBase *a3 __asm("a3") = BASE_NAME; > register struct Library *a1 __asm("a1") = library; > __asm __volatile ("jsr a3@(-0x19e)" > : /* no output */ > : "r" (a3), "r" (a1) > : "a0","a1","d0","d1"); /* ,"memory" gestrichen */ > } > static __inline struct Library * > OpenLibrary (BASE_PAR_DECL UBYTE *libName,unsigned long version) > { > BASE_EXT_DECL > register struct Library * _res __asm("d0"); > register struct ExecBase *a3 __asm("a3") = BASE_NAME; > register UBYTE *a1 __asm("a1") = libName; > register unsigned long d0 __asm("d0") = version; > __asm __volatile ("jsr a3@(-0x228)" > : "=r" (_res) > : "r" (a3), "r" (a1), "r" (d0) > : "a0","a1","d0","d1" ,"memory"); > return _res; > } [stuff deleted] > With "memory" in the clobber list in the __asm() of OpenLibrary, GCC > reloads SysBase even when there's the const declaration. It is ILLEGAL to put library base in A3 - RKM says that it HAS TO be in A6. Why didn't you put it there?! As far as I understand the role of "memory", OpenLibrary() does not need "memory" in the list of clobbered "registers" - "memory" is only necessary if assembler part modifies a variable, for example it would be needed if OpenLibrary() modified something in "LibName" parameter. Maybe one day inlines will have "memory" only in calls that really need it. But this requires a lot of work. I once volunteered (sp?) to do it, but first thing that has to be done is reliable inlines generator. This work is in progress, Rainer Trunz is working on it and "fd2inline.c" is nearly correct. Once it is done, there will be time to add all this nice features like "memory" only in calls that really need it, wider/narrower list of clobbered registers for certain calls such as Forbid() etc. Just be patient :-). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 13:30:07 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90047-4>; Fri, 11 Aug 1995 13:28:59 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA12768; Fri, 11 Aug 1995 12:30:37 +0200 Date: Fri, 11 Aug 1995 12:30:36 +0200 (MET DST) From: Kamil Iskra Subject: Re: How do I get 'String' to work? To: e90_dny@elixir.e.kth.se cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508100727.JAA08161@brahms.e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 10 Aug 1995 e90_dny@elixir.e.kth.se wrote: > Hello. I cannot get the 'String'-class to work. I have Gcc version 2.6.3. > and ixemul library 41.1. If I compile a program like the one following > "#include > #include <_String.h> > > int main(void) > { > String str; > return 0; > }" > I get linkage(?Is that the english word?) problem. The linker cannot find > the code for the header file. It doesn't help to type '-lg++' when linking. > It shouldn't either, since if I understand it correctly libg++.a is always > included if I use g++. What should I do? My hardware setup is an A1200 with > blizzard 030 50MHz, but I suspect that is of no importance. It would be really helpful if you included messages produced by linker, preferably together with verbose-output ("g++ -v"). I tried to compile your source on Sparc SunOS and it compiled and linked without any problems. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 13:38:53 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90348-4>; Fri, 11 Aug 1995 13:38:25 +0300 Received: by ceylon.informatik.uni-rostock.de id MAA16061; Fri, 11 Aug 1995 12:37:59 +0200 Received: by honshu.informatik.uni-rostock.de id MAA08854; Fri, 11 Aug 1995 12:37:57 +0200 From: Gunther Nikl Message-Id: <199508111037.MAA08854@honshu.informatik.uni-rostock.de> Subject: inline patches To: amiga-gcc-port@nic.funet.fi Date: Fri, 11 Aug 1995 12:37:57 +0200 (MET DST) In-Reply-To: from "Kamil Iskra" at Aug 11, 95 11:56:41 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1110 > Maybe one day inlines will have "memory" only in calls that really need > it. But this requires a lot of work. I once volunteered (sp?) to do it, > but first thing that has to be done is reliable inlines generator. This > work is in progress, Rainer Trunz is working on it and "fd2inline.c" is > nearly correct. Once it is done, there will be time to add all this nice > features like "memory" only in calls that really need it, wider/narrower > list of clobbered registers for certain calls such as Forbid() etc. Just > be patient :-). Bad idea, since now all inlines had been created with a perl-script that worked _very_ reliable and so do the generated inlines. The generated code won't be much better only because the compiler now knows that eg. ObtainSemaphore() does not trash a0. All these things are special information (from the autodocs mainly for asm programmers, but nothing a C compiler really should care) and you have to add this knowledge to a database as "exeception" to the rule. This doesn't sound very exciting to me. Add yes, I am a bit conservative ;-) Gunther From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 13:52:17 1995 Received: from cardhu.cs.hut.fi ([130.233.192.95]) by nic.funet.fi with SMTP id <90100-2>; Fri, 11 Aug 1995 13:51:18 +0300 Received: by cardhu.cs.hut.fi id AA00491 (5.65c8/HUTCS-C 1.3 for Amiga GCC List ); Fri, 11 Aug 1995 13:50:54 +0300 Date: Fri, 11 Aug 1995 13:50:54 +0300 Message-Id: <199508111050.AA00491@cardhu.cs.hut.fi> From: Tomi Ollila Reply-To: Cc: Amiga GCC List To: Subject: Re: comments and questions about gcc270 In-Reply-To: References: <199508101058.MAA10372@ernie.icslab.agh.edu.pl> Kamil Iskra writes: > > > On Thu, 10 Aug 1995 Joerg-Cyril Hoehle wrote: > > > o I'm trying hard to prevent GCC from reloading A6 for several OS > > calls in a row, unsuccessfully so far: > > > > The idea is that the library base be declared const, but it doesn't > > seem to work because of the "memory" clobber in the __asm() > > > > -------- a-usage.c > [stuff deleted] > > static __inline void > > CloseLibrary (BASE_PAR_DECL struct Library *library) > > { > > BASE_EXT_DECL > > register struct ExecBase *a3 __asm("a3") = BASE_NAME; > > register struct Library *a1 __asm("a1") = library; > > __asm __volatile ("jsr a3@(-0x19e)" > > : /* no output */ > > : "r" (a3), "r" (a1) > > : "a0","a1","d0","d1"); /* ,"memory" gestrichen */ > > } > > static __inline struct Library * > > OpenLibrary (BASE_PAR_DECL UBYTE *libName,unsigned long version) > > { > > BASE_EXT_DECL > > register struct Library * _res __asm("d0"); > > register struct ExecBase *a3 __asm("a3") = BASE_NAME; > > register UBYTE *a1 __asm("a1") = libName; > > register unsigned long d0 __asm("d0") = version; > > __asm __volatile ("jsr a3@(-0x228)" > > : "=r" (_res) > > : "r" (a3), "r" (a1), "r" (d0) > > : "a0","a1","d0","d1" ,"memory"); > > return _res; > > } > [stuff deleted] > > With "memory" in the clobber list in the __asm() of OpenLibrary, GCC > > reloads SysBase even when there's the const declaration. > > It is ILLEGAL to put library base in A3 - RKM says that it HAS TO be in > A6. Why didn't you put it there?! > To explain why library base *must* be in A6 the library functions called may (and usually does) access the data section of library base which is stored in A6. ...and A6 has some random value if it is not set prior calling the function that is in that base (or it already have that value). If this random value is used to access the data section of the library base, everyone may quess what happens. Tomi From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 14:51:13 1995 Received: by nic.funet.fi id <89707-4>; Fri, 11 Aug 1995 14:50:00 +0300 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Kamil Iskra on Fri, 11 Aug 1995 11:56:41 +0200 (MET DST)) Subject: illegal/invalid Message-Id: <95Aug11.145000+0300_eet_dst.89707-4+35@nic.funet.fi> Date: Fri, 11 Aug 1995 14:49:58 +0300 When referring to programming standards (like in what register the library base should be) and the correct use of them please talk about valid or invalid programming. Legal/illegal programming is something completely different, and out of the scope for this mailing list. From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 16:59:19 1995 Received: from elixir.e.kth.se ([130.237.48.5]) by nic.funet.fi with SMTP id <89175-2>; Fri, 11 Aug 1995 16:56:23 +0300 Received: from zafir.e.kth.se (zafir.e.kth.se [130.237.48.6]) by elixir.e.kth.se (8.6.8.1/8.6.6) with ESMTP id PAA17452; Fri, 11 Aug 1995 15:55:53 +0200 Received: (e90_dny@localhost) by zafir.e.kth.se (8.6.8.1/8.6.6) id PAA10898; Fri, 11 Aug 1995 15:55:52 +0200 Message-Id: <199508111355.PAA10898@zafir.e.kth.se> From: To: amiga-gcc-port@nic.funet.fi cc: kiskra@ernie.icslab.agh.edu.pl Subject: String problem. Here is what I get with -v option. Date: Fri, 11 Aug 1995 15:55:52 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: DennyĊ berg ^-illegal control character Hello again. I apologize for not putting this in my first mail. Here is the response I get when testing String. The program TestString.cc looks like: #include #include <_String.h> int main(void) { String str; return 0; } This is the output: > g++ -v TestString.cc gcc -v TestString.cc -lg++ Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Dmc68010 teststring.cc t:cc366520.ii GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/lib/g++-include /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/cc1plus t:cc366520.ii -quiet -dumpbase teststring.cc -version -o t:cc366520.s GNU C++ version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3. as -mc68010 -o t:cc3665201.o t:cc366520.s ld /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3 -L/local/lib/gcc-lib/mc68000-cbm-amigados/2.6.3 -L/gnu/lib -L/local/lib -L/local/lib t:cc3665201.o -lg++ -lgcc -lc -lgcc t:cc3665201.o: Undefined symbol String::String() referenced from text segment t:cc3665201.o: Undefined symbol 6String::~6String() referenced from text segment >g++ -v -c TestString.cc gcc -v -c TestString.cc Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Dmc68010 teststring.cc t:cc366520.ii GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/lib/g++-include /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/cc1plus t:cc366520.ii -quiet -dumpbase teststring.cc -version -o t:cc366520.s GNU C++ version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3. as -mc68010 -o teststring.o t:cc366520.s >g++ -v -lg++ TestString.o gcc -v -lg++ testString.o -lg++ Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/specs gcc version 2.6.3 ld /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3 -L/local/lib/gcc-lib/mc68000-cbm-amigados/2.6.3 -L/gnu/lib -L/local/lib -L/local/lib -lg++ testString.o -lg++ -lgcc -lc -lgcc testString.o: Undefined symbol String::String() referenced from text segment testString.o: Undefined symbol 6String::~6String() referenced from text segment That's it. Anybody knows what I should do? Denny AAberg From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 17:31:46 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89507-4>; Fri, 11 Aug 1995 17:31:08 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id PAA29906; Fri, 11 Aug 1995 15:29:05 +0100 From: Lars Hecking Message-Id: <199508111432.PAA10235@mostar.nmrc.ucc.ie> Subject: Re: String problem. Here is what I get with -v option. To: e90_dny@elixir.e.kth.se Date: Fri, 11 Aug 1995 15:32:06 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199508111355.PAA10898@zafir.e.kth.se> from "e90_dny@elixir.e.kth.se" at Aug 11, 95 03:55:52 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 455 > ld /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3 -L/local/lib/gcc-lib/mc68000-cbm-amigados/2.6.3 -L/gnu/lib -L/local/lib -L/local/lib t:cc3665201.o -lg++ -lgcc -lc -lgcc > t:cc3665201.o: Undefined symbol String::String() referenced from text segment > t:cc3665201.o: Undefined symbol 6String::~6String() referenced from text segment > That's it. Anybody knows what I should do? Link against libiostream.a or (better) libstdc++.a From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 17:40:58 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89136-1>; Fri, 11 Aug 1995 17:40:12 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26496-4>; Fri, 11 Aug 1995 16:37:58 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209170-2>; Fri, 11 Aug 1995 16:37:52 +0100 Subject: Re: inline patches From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 11 Aug 1995 16:37:40 +0200 (MESZ) In-Reply-To: <199508111037.MAA08854@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Aug 11, 95 12:37:57 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1637 Message-Id: <95Aug11.163752+0100mesz.209170-2+2138@hphalle0.informatik.tu-muenchen.de> [ better inlines ] > Bad idea, since now all inlines had been created with a perl-script > that worked _very_ reliable and so do the generated inlines. The > generated code won't be much better only because the compiler now > knows that eg. ObtainSemaphore() does not trash a0. Why not? If the compiler knows that a register is not trashed, it might be able to save a variable load. It might indeed be able to save stack space since more registers are available. This is especially true for calls like ObtainSemaphore(), since this is generally used like ... prepare some action ... ObtainSemaphore() ... do something which usually is only a few lines... ReleaseSemaphore() And even you think that it won't help: it won't hurt either. > All these things > are special information (from the autodocs mainly for asm programmers, > but nothing a C compiler really should care) A C compiler should try to output the best code it can create. If the compiler knows that a register isn't trashed, it will help with that goal. Why is this information for asm programmers only? Just because none of the existing compilers can handle such details? > and you have to add this > knowledge to a database as "exeception" to the rule. This doesn't sound > very exciting to me. Well, there are people that will be happy to create such a database for you. > Gunther Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 17:51:43 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90566-3>; Fri, 11 Aug 1995 17:51:00 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 11 Aug 95 16:43:59 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <211f49cc.u7t157e.6f208-robert@plukwa.pdi.lodz.pl> Subject: a bit off topic but not that much Reply-To: robert@pdi.lodz.pl Content-Length: 1296 To: amiga-gcc-port@nic.funet.fi Date: Fri, 11 Aug 95 16:43:59 Hi all! Walter Harms made me :) to create AmigaGuide version of man pages suplied with GCC. I've already made section3 in to kindda AutoDoc format (this was rather easy but involved some manual editing) now i would like to convert it to AmigaGuide format. Problem is that the only program i found on Aminet screws this thing (it's name is AutoGuide.lha) the other i could find AGtoHT stops in the middle of the road doing literaly nothing. Can someone send me working copy of Ad2Ag? or better yet upload it to plukwa.pdi.lodz.pl? If all will be good I could give the files to Philippe to include them in gcc2.7.0 distrib Robert ps. Walter said that he has such a program of this own but unfrotunately his amiga is unreacheble. If someone wants to look at the kindda AutoDoc file then ftp://plukwa.pdi.lodz.pl/amiga/gnu/private +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 18:03:39 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <89590-4>; Fri, 11 Aug 1995 18:02:41 +0300 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id RAA23875 (8.6.12/7.4b-FAU);; Fri, 11 Aug 1995 17:02:04 +0200 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA16100; Fri, 11 Aug 1995 17:02:00 +0200 Date: Fri, 11 Aug 1995 17:02:00 +0200 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9508111502.AA16100@pctc.chemie.uni-erlangen.de> To: e90_dny@elixir.e.kth.se Cc: amiga-gcc-port@nic.funet.fi, kiskra@ernie.icslab.agh.edu.pl In-Reply-To: <199508111355.PAA10898@zafir.e.kth.se> (e90_dny@elixir.e.kth.se) Subject: Re: String problem. Here is what I get with -v option. Hello, try the same with the optimize switch -O and look, if the same happens. Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 18:09:43 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89662-1>; Fri, 11 Aug 1995 18:09:06 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26497-4>; Fri, 11 Aug 1995 17:08:28 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209163-2>; Fri, 11 Aug 1995 17:08:11 +0100 Subject: Re: a bit off topic but not that much From: Christian Stieber To: robert@pdi.lodz.pl Date: Fri, 11 Aug 1995 17:08:01 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <211f49cc.u7t157e.6f208-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Aug 11, 95 04:43:59 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1167 Message-Id: <95Aug11.170811+0100mesz.209163-2+2148@hphalle0.informatik.tu-muenchen.de> > to AmigaGuide format. Problem is that the only program i found on Aminet > screws this thing (it's name is AutoGuide.lha) the other i could find AGtoHT > stops in the middle of the road doing literaly nothing. I'm the author of ADtoHT (not the AD2HT that comes with the amigaguide package). ADtoHT is rather picky about the autodoc format. I just checked your autodocs and found a couple of problems: - there is no CTRL-L after the table of contents - the indendation is completely wrong - "BSD Experimental" is not a valid header - the "SYNOPSIS" section is wrong There may be other problemsl these are just the obvious ones. I don't know which of them makes ADtoHT hang. I might try to find out some time, to make ADtoHT output an error instead of hanging :( Seems the internal state machine is somehow getting confused :( > | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 18:18:23 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88952-1>; Fri, 11 Aug 1995 18:17:41 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sgvsf-0004nYC; Fri, 11 Aug 95 08:20 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: GCC 2.7.0 Prerelease To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Fri, 11 Aug 1995 08:20:17 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Aug 11, 95 11:11:28 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 649 > > This is due to libio.h from libg++. I asked the libg++ author about > > this and got back email which indicates that the conflict has been > > resolved in libg++, so there is no need to change the header. The fix > > will be in the next libg++ release. > > Fine. But, frankly speaking, this explanation sounds rather suspicious to > me. "libio.h" has a protection against redefining of "__P", "cdefs.h" > doesn't have. I wonder what the "correct" patch should be like... I believe it involves having configure check to see if cdefs.h is available, and if so, libio.h includes it rather than duplicating the defines that cdefs.h has. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 18:19:39 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <88974-2>; Fri, 11 Aug 1995 18:19:02 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 11 Aug 95 17:11:31 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <211f5040.u7t157e.c16a8-robert@plukwa.pdi.lodz.pl> Subject: Re: a bit off topic but not that much In-Reply-To: <95Aug11.170811+0100mesz.209163-2+2148@hphalle0.informatik.tu-muenchen.de> (from Christian Stieber ) (at Fri, 11 Aug 1995 17:08:01 +0200 (MESZ)) Reply-To: robert@pdi.lodz.pl Content-Length: 1557 To: stieber%informatik.tu-muenchen.de@plearn.edu.pl Cc: amiga-gcc-port@nic.funet.fi Date: Fri, 11 Aug 95 17:11:31 On Aug 11 Christian Stieber wrote: > > I'm the author of ADtoHT (not the AD2HT that comes with the amigaguide oooooops!!! :) > package). ADtoHT is rather picky about the autodoc format. I just checked > your autodocs and found a couple of problems: > - there is no CTRL-L after the table of contents > - the indendation is completely wrong > - "BSD Experimental" is not a valid header > - the "SYNOPSIS" section is wrong Can You give me the correct specification of how should look AutoDoc? (I have them only in AutoGuide format) Thanks in advance. > > There may be other problemsl these are just the obvious ones. I > don't know which of them makes ADtoHT hang. I might try to find > out some time, to make ADtoHT output an error instead of hanging :( > Seems the internal state machine is somehow getting confused :( Well it could be that I screwed something wit command line options. It appears that AGtoHT needs path to include files, dir where to put parsed include files, path to AutoDocs and place to put the output. I told it to look in GNU:include instead of GNU:os-include. Could thie cause any probs? (AGtoHT frozen somwhere during first pass on include files) > > > | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | > > Christian > > > -- > // Christian Stieber Stieber@Informatik.TU-Muenchen.de > \// Certified Amiga Developer http://www.leo.org/~stieber/ > -------------------------------------------------------------------------- > Nobody, just nobody > Robert From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 18:20:33 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <89168-4>; Fri, 11 Aug 1995 18:20:07 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id RAA01265 (8.6.10/2.4); Fri, 11 Aug 1995 17:02:05 +0200 Date: Fri, 11 Aug 1995 17:02:05 +0200 From: Olaf Seibert Message-Id: <199508111502.RAA01265@septimius.mbfys.kun.nl> To: hoehle@inf-wiss.uni-konstanz.de, kiskra@ernie.icslab.agh.edu.pl Subject: Re: comments and questions about gcc270 Cc: amiga-gcc-port@nic.funet.fi, rhialto@mbfys.kun.nl > Maybe one day inlines will have "memory" only in calls that really need > it. But this requires a lot of work. I once volunteered (sp?) to do it, > but first thing that has to be done is reliable inlines generator. This > work is in progress, Rainer Trunz is working on it and "fd2inline.c" is > nearly correct. Once it is done, there will be time to add all this nice > features like "memory" only in calls that really need it, wider/narrower > list of clobbered registers for certain calls such as Forbid() etc. Just > be patient :-). At one point I had devised a method to avoid defining an inline function per library function. (This takes a lot of memory, most of which is not needed, since most of them will not be used in any given translation unit). Instead, I had inline functions for each mapping (argument position) -> (register), and #defines to map each library function to one appropriate call function. Unfortunately this lost the type information (all parameters being LONG)... Anybody interested in me digging this up? -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 18:23:07 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <89875-3>; Fri, 11 Aug 1995 18:22:39 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 11 Aug 95 17:15:37 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <211f5137.u7t157e.1d3b2-robert@plukwa.pdi.lodz.pl> Subject: AmiTCP-4.0-gcc-sdk Reply-To: robert@pdi.lodz.pl Content-Length: 582 To: amiga-gcc-port@nic.funet.fi Date: Fri, 11 Aug 95 17:15:37 Hi again! Who is resposible for bringing us that SDK for AmiTCP4.0? Somehow i managed to loose his addres :( Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 18:23:59 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89908-2>; Fri, 11 Aug 1995 18:23:16 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sgvyC-0004nYC; Fri, 11 Aug 95 08:26 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: libiostream.a To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Fri, 11 Aug 1995 08:26:00 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Aug 11, 95 10:57:33 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 384 > Please read the following extract from g++ FAQ: > > "In version 2.7.0 `-liostream' is gone and all the standard classes are in > `-lstdc++'." > > So why in Amiga-GCC distribution "libiostream.a" is still included? libg++-2.7.0 still builds and installs libiostream.a. Perhaps this is for backwards compatibility. The libg++ author should be able to provide more info. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 18:26:15 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <89320-2>; Fri, 11 Aug 1995 18:25:56 +0300 Received: by math.uwaterloo.ca id <77162-1>; Fri, 11 Aug 1995 11:25:07 -0400 Date: Fri, 11 Aug 1995 11:24:59 -0400 From: Jeff Shepherd To: robert@pdi.lodz.pl cc: amiga-gcc-port@nic.funet.fi Subject: Re: AmiTCP-4.0-gcc-sdk In-Reply-To: <211f5137.u7t157e.1d3b2-robert@plukwa.pdi.lodz.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 11 Aug 1995, Robert Ramiega wrote: > Hi again! > Who is resposible for bringing us that SDK for AmiTCP4.0? > Somehow i managed to loose his addres :( > > Robert jsshephe@undergrad.math.uwaterloo.ca (don't use the address in my sig since its temporary.) jsshephe@math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 19:19:18 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89856-4>; Fri, 11 Aug 1995 19:18:45 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26471-4>; Fri, 11 Aug 1995 18:18:21 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209168-2>; Fri, 11 Aug 1995 18:18:12 +0100 Subject: Re: a bit off topic but not that much From: Christian Stieber To: robert@pdi.lodz.pl Date: Fri, 11 Aug 1995 18:17:59 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <211f5040.u7t157e.c16a8-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Aug 11, 95 05:11:31 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 2126 Message-Id: <95Aug11.181812+0100mesz.209168-2+2160@hphalle0.informatik.tu-muenchen.de> > Can You give me the correct specification of how should look AutoDoc? (I > have them only in AutoGuide format) Thanks in advance. If you have the NDK, just check out the autodoc.style files. Then create a couple of autodocs and run them through the autodoc program. Or look at exec.doc. Bascially, there are 4 spaces before a header, e.g. SYNOPSIS There is one tab before any other line, e.g. This is some text line I know that ADtoHT had problems with wrong indentation, and I think I fixed some of the problems. Probably not all of them :( > Well it could be that I screwed something wit command line options. It > appears that AGtoHT needs path to include files, dir where to put parsed > include files, path to AutoDocs and place to put the output. I told it to > look in GNU:include instead of GNU:os-include. Could thie cause any probs? Definitely. GNU:include is _much_ to complicated for ADtoHT to parse. It doesn't have a C compiler, or even a C preprocessor built in --- it knows how to parse the Commodore includes, but it definitely doesn't know how to parse "ISO-C" headers. GNU:include tends to have lots of "fancy" stuff, so chances are that ADtoHT breaks. As a side note: ADtoHT was _never_ meant to convert "everything" to .guide. It was written to convert the AmigaOS includes/autodocs, and if it does convert some other autodocs it's just luck. Of course, I'll try to make it more general (if I find the time (which I have more than enough of), and feel like doing it (which currently isn't the case)), but it is unlikely that ADtoHT will ever be able to parse all of ISO-C. > (AGtoHT frozen somwhere during first pass on include files) That seems to be a common problem. It has always had more problems with the includes than with the autodocs :( > > > | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Fri Aug 11 21:55:35 1995 Received: from elixir.e.kth.se ([130.237.48.5]) by nic.funet.fi with SMTP id <88024-2>; Fri, 11 Aug 1995 21:54:49 +0300 Received: from zafir.e.kth.se (zafir.e.kth.se [130.237.48.6]) by elixir.e.kth.se (8.6.8.1/8.6.6) with ESMTP id UAA19410 for ; Fri, 11 Aug 1995 20:54:43 +0200 Received: (e90_dny@localhost) by zafir.e.kth.se (8.6.8.1/8.6.6) id UAA13846; Fri, 11 Aug 1995 20:54:43 +0200 Message-Id: <199508111854.UAA13846@zafir.e.kth.se> From: To: amiga-gcc-port@nic.funet.fi Subject: String.h. Help! Date: Fri, 11 Aug 1995 20:54:42 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: DennyĊ berg ^-illegal control character It still doen't work.I don't have libstdc++.a, where is it? Here is my output: > g++ -v -liostream TestString.cc gcc -v -liostream TestString.cc -lg++ Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Dmc68010 teststring.cc t:cc545240.ii GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/lib/g++-include /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/cc1plus t:cc545240.ii -quiet -dumpbase teststring.cc -version -o t:cc545240.s GNU C++ version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3. as -mc68010 -o t:cc5452401.o t:cc545240.s ld /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3 -L/local/lib/gcc-lib/mc68000-cbm-amigados/2.6.3 -L/gnu/lib -L/local/lib -L/local/lib -liostream t:cc5452401.o -lg++ -lgcc -lc -lgcc t:cc5452401.o: Undefined symbol String::String() referenced from text segment t:cc5452401.o: Undefined symbol 6String::~6String() referenced from text segment > g++ -v -O TestString.cc gcc -v -O TestString.cc -lg++ Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=6 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados_ _ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -D__OPTIMIZE__ -Dmc 68010 teststring.cc t:cc545240.ii GNU CPP version 2.6.3 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/lib/g++-include /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3/cc1plus t:cc545240.ii -quiet -dumpbase teststring.cc -O -versio n -o t:cc545240.s GNU C++ version 2.6.3 (68k, MIT syntax) compiled by GNU C version 2.6.3. as -mc68010 -o t:cc5452401.o t:cc545240.s ld /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.3 -L/local/lib/gcc-lib/mc68000-cbm-amigados/ 2.6.3 -L/gnu/lib -L/local/lib -L/local/lib t:cc5452401.o -lg++ -lgcc -lc -lgcc /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): Undefined symbol String::_substr(int, int) referenced from text segment /gnu/lib/libg++.a(String.o): More undefined symbol String::_substr(int, int) refs follow 7.Rymden:Source/C++/TestDepartment> --------------------------------------------------------------- // Denny AAberg email:e90_dny@elixir.e.kth.se // \\// Amiga makes it possible. From amiga-gcc-port-owner@nic.funet.fi Sat Aug 12 15:23:43 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <88327-4>; Sat, 12 Aug 1995 15:22:50 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sat, 12 Aug 95 14:22:26 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <21207a1f.u7t157e.7ea4c-robert@plukwa.pdi.lodz.pl> Subject: Help! I need fully working libauto.a Reply-To: robert@pdi.lodz.pl Content-Length: 748 To: amiga-gcc-port@nic.funet.fi Date: Sat, 12 Aug 95 14:22:26 Hi all! Sorry for disturbing You all. Can someone send me working libauto.a (via e-mail or directly on plukwa.pdi.lodz.pl via ftp)? I really need it. I tried to compile one on my own (I used both MakefileAJGG and Makefile suplied with gcc) but still cant get working libauto. Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Sat Aug 12 19:38:04 1995 Received: from asimov.cnam.fr ([163.173.128.6]) by nic.funet.fi with SMTP id <88578-4>; Sat, 12 Aug 1995 19:35:48 +0300 Received: from brunner.cnam.fr (brunner.cnam.fr [163.173.128.15]) by asimov.cnam.fr with ESMTP id SAA06414 (8.6.12/ for ); Sat, 12 Aug 1995 18:35:45 +0200 Received: by brunner.cnam.fr id SAA02608 (8.6.12/ for amiga-gcc-port@nic.funet.fi); Sat, 12 Aug 1995 18:35:44 +0200 Received: (from daniel@localhost) by brasil.frmug.fr.net (8.6.12/8.6.12) id SAA03025 for amiga-gcc-port@nic.funet.fi; Sat, 12 Aug 1995 18:10:41 +0200 From: Daniel Verite Message-Id: <199508121610.SAA03025@brasil.frmug.fr.net> Subject: Re: inline patches To: amiga-gcc-port@nic.funet.fi Date: Sat, 12 Aug 1995 18:10:40 +0200 (MET DST) In-Reply-To: <95Aug11.163752+0100mesz.209170-2+2138@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Aug 11, 95 04:37:40 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1222 > > [ better inlines ] > > > Bad idea, since now all inlines had been created with a perl-script > > that worked _very_ reliable and so do the generated inlines. The > > generated code won't be much better only because the compiler now > > knows that eg. ObtainSemaphore() does not trash a0. > > Why not? If the compiler knows that a register is not trashed, it might > be able to save a variable load. It might indeed be able to save stack > space since more registers are available. > This is especially true for calls like ObtainSemaphore(), since this > is generally used like > ... prepare some action ... > ObtainSemaphore() > ... do something which usually is only a few lines... > ReleaseSemaphore() > > And even you think that it won't help: it won't hurt either. > I think RKM says every library call (at least those shipped with the OS) might trash d0-d1/a0-a1. Perhaps I miss the point, but if you plan to look at every function and try to determine which of those registers aren't actually trashed, it sounds quite nasty to me. Indeed, these things could change from any revision of the OS to the other, let alone the possible future (?) versions. Daniel Verite -- daniel@brainstorm.cnam.fr From amiga-gcc-port-owner@nic.funet.fi Sat Aug 12 22:29:16 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <88464-1>; Sat, 12 Aug 1995 22:28:53 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id VAA02885 (8.6.10/2.4); Sat, 12 Aug 1995 21:29:16 +0200 Date: Sat, 12 Aug 1995 21:29:16 +0200 From: Olaf Seibert Message-Id: <199508121929.VAA02885@septimius.mbfys.kun.nl> To: amiga-gcc-port@nic.funet.fi, hoehle@inf-wiss.uni-konstanz.de Subject: Re: comments and questions about gcc270 Cc: rhialto@mbfys.kun.nl hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) wrote:: > o Can't the ___gnu_compiled_c labels be removed from the executable > (e.g. ignored by the linker)? They confuse (at least) Dobj, ADis, Try "ld -x -r some.o". This works with NetBSD, I don't have the amiga's ld manpage here to check. -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Sun Aug 13 00:06:55 1995 Received: from zorn.mn.medstroms.se ([193.44.236.3]) by nic.funet.fi with SMTP id <88179-4>; Sun, 13 Aug 1995 00:06:09 +0300 Received: from maxinet (4.ts1.mnet.medstroms.se [193.44.236.24]) by zorn.mn.medstroms.se (8.6.12/8.6.12) with SMTP id XAA04441 for ; Sat, 12 Aug 1995 23:06:41 +0200 Received: by maxinet.medstroms.se (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sat, 12 Aug 95 23:07:24 Received: by maxinet.medstroms.se (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sat, 12 Aug 95 23:05:33 From: erik.rissanen@mn.medstroms.se (Erik Rissanen) Message-Id: <2120f4b4.u7t150e.1069a-erik.rissanen@mn.medstroms.se> Subject: amitcp and gcc Date: Sat, 12 Aug 95 23:05:33 To: amiga-gcc-port@nic.funet.fi I read in the FAQ about the problems associated with using amitcp with gcc, but despite of that, many of you on the list seem to compile programs for amitcp with gcc, so I am wondering how do you do it? I am interested in compiling an BSDEmpire client on my Amiga. It is going well except for the internet part, so if there is someone who has the time to spare, maybe (s)he would answer these questions. If you do not have the time, do not bother, since propably I will not be able to make it work anyway since I am not any good at programming and have no education on the subject, but I would like to try it anyway. I am really sorry if this mail has taken up too much of your valuable time. I considered for several days before I sent this. 1. Are the includes in the gcc2.6.3 archives for the internet package by Commodore? 2. seems to be incompatible with the other includes in the package. Is that TRUE or am I doing something wrong? (Sorry for 'TRUE' beeing capitalized, but this editor does that and I do not know how to turn it off.) 3. Would it be easier to use Commodore's package instead of Amitcp (actually the socket.library emulation that is available for AmiTCP)? (Though I do not have the package so probably not.) 4. I tried to use the includes supplied in AmiTCP-sdk, but they did not work either. Am I doing something wrong? (Probably not if I understood the FAQ correctly.) 5. Has anyone done the work needed to make the AmiTCP sdk package working with gcc? These two questions are perhaps bit out of topic on this list, but fit well with the questions above, so please don't flame me. 6. Is AmiTCP laid out in a similar way as TCP/IP networking on UNIX, so that it will be reasonably simple to port programs? 7. Should I really bother to try? Will it be almost impossible? --------------------------------------------------------------------- Erik Rissanen erik.rissanen@mn.medstroms.se I am sorry for my bad English. --------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Sun Aug 13 22:23:20 1995 Received: from sunmbx.netmbx.de ([192.76.152.9]) by nic.funet.fi with SMTP id <88544-1>; Sun, 13 Aug 1995 22:09:09 +0300 Received: by sunmbx.netmbx.de (/\==/\ Smail3.1.28.1) from tmpmbx.netmbx.de with smtp id ; Sun, 13 Aug 95 21:14 MET DST Received: by tmpmbx.netmbx.de (/\==/\ Smail3.1.28.1 #28.6) id ; Sun, 13 Aug 95 20:56 MES Received: from tbx by zelator.BerliNet.DE with bsmtp (Smail3.1.28.1 #11) id m0shQ5n-0003LJC; Sat, 12 Aug 95 23:35 MESZ To: amiga-gcc-port@nic.funet.fi Message-Id: <50187275@bw01.bbrandes.berlinet.de> From: B.WINKELMANN@BBrandes.berlinet.de (Bert Winkelmann) Path: tbx.berlinet.de!bbrandes.berlinet.de!B.WINKELMANN Subject: How do I get 'String' to work? Date: Sat, 12 Aug 1995 22:23:03 +0200 X-Mailer: UMSZer V2.22 public References: <199508100727.JAA08161@brahms.e.kth.se> X-Gateway: ZCONNECT U2 zelator.BerliNet.DE [UNIX/Connect v0.71] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-VIA: 19950812000000S+2@BBrandes.berlinet.de Lines: 56 Hi e90_dny.? > Hello. I cannot get the 'String'-class to work. I have Gcc version > 2.6.3. > and ixemul library 41.1. If I compile a program like the one following > "#include > #include <_String.h> > > int main(void) > { > String str; > return 0; > }" > I get linkage(?Is that the english word?) problem. The linker cannot > find > the code for the header file. I resend a message by me. Maybe it's nonsense: =========================================================================== From: Bert Winkelmann <> To: amiga-gcc-port Subject: Is g++ stable? Message ID: 43272130B.Winkelmann@bbrandes.berlinet.de Refer ID: 199505111239.OAA05365@vann.alkymi.unit.no Creation Date: Donnerstag 18-Mai-95 11:20:16 Newsreader: IntuiNews 1.2b (31.7.94) Chain: -0 +0 <0 >1312 [problems with linker errors when using the libg++ Stringclass deleted] I had the same problem and have reinstalled libg++ today and the problem is completely vanished. I have using the 'libg++-2.6.2-bin.lha'-archive from the Fresh-Fish-8-CD. Originally I had installed the libg++ from the gcc-2.6.?-archive: The inline String() ctor will not work, because the #pragma interface keyword avoid inlining (why?). After remove this #pragma ld missed the func String::_substr(int,int) referenced by libg++(String.o) (the func is declared and defined as inline in String.h). Can it be, libg++(String.o) in the gcc-archive is defect? Maybe because '#pragma interface' works not correct with changed filenames like _String.h/String.cc instead String.h/String.cc MfG, Bert. =========================================================================== From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 02:31:15 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <88618-3>; Mon, 14 Aug 1995 02:29:10 +0300 Received: by colombo.telesys-innov.fr; Mon, 14 Aug 1995 01:30:15 +0100 From: Philippe BRAND Message-Id: <199508140030.BAA02459@colombo.telesys-innov.fr> Subject: Re: gcc 2.7.0 - when and where? (fwd) To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 14 Aug 1995 01:30:14 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2065 Joop van de Wege writes: >From joop.vandeWege@MEDEW.ENTO.WAU.NL Sun Aug 13 16:13:41 1995 Date: Sun, 13 Aug 1995 16:18:12 LOCAL From: joop.vandeWege@MEDEW.ENTO.WAU.NL (Joop van de Wege) Subject: Re: gcc 2.7.0 - when and where? To: Philippe Brand Message-id: X-Envelope-to: phb@colombo.telesys-innov.fr Content-transfer-encoding: 7BIT In article <40fmco$s9b@sol.telesys-innov.fr> Philippe Brand writes: >From: Philippe Brand >Subject: Re: gcc 2.7.0 - when and where? >Date: 11 Aug 1995 13:36:24 GMT >walko@cadence.fb12.tu-berlin.de (Tobias Walkowiak) wrote: >>Is anybody busy with porting V 2.7.0 of the gcc to the AMIGA and/or can tell >>me when it will be done? >Yes I am, and it will be available shortly. Beta testers have already tested >it for some time now. Hello Philippe, I'm trying to get Ghostscript3.33 to compile which works nicely with gcc270, *but* not when using -m68000 only when compiled for cpu's higher then mc68010. It seems there is some problem with pointers as I get a lot of garbage printed to the console. Would you please forward this to the gcc mailing list since this is really weird. Ghostscript uses a define (FPU_TYPE) with a value of -1 when integer calculations are faster than FPU ones or 0/1/2 with 2 being FPU ones faster than integer ones, and the rest (0/1) in the middle. This flag is only used in 2/3 places and I don't see any possible problems with it. Varying this flag when compiling for -m68020 doesn't make a difference. Introducing -m68000 does with any FPU_TYPE Done sofar: Mailed Olaf Barthel, which is also working on it, telling my findings. Mailed to the ghostscript newsgroup asking for help on this. Mailed you for help ;) I'm willing to try almost anything. Thanks Joop -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 12:16:59 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <87939-1>; Mon, 14 Aug 1995 12:15:38 +0300 Received: by ceylon.informatik.uni-rostock.de id LAA05484; Mon, 14 Aug 1995 11:15:32 +0200 Received: by honshu.informatik.uni-rostock.de id LAA04500; Mon, 14 Aug 1995 11:15:31 +0200 From: Gunther Nikl Message-Id: <199508140915.LAA04500@honshu.informatik.uni-rostock.de> Subject: Re: inline patches To: amiga-gcc-port@nic.funet.fi Date: Mon, 14 Aug 1995 11:15:30 +0200 (MET DST) In-Reply-To: <95Aug11.163752+0100mesz.209170-2+2138@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Aug 11, 95 04:37:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 313 > > and you have to add this > > knowledge to a database as "exeception" to the rule. This doesn't sound > > very exciting to me. > > Well, there are people that will be happy to create such a database for you. > Fine, if anybody could update the perl-script. I am only able to run it :) Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 12:41:59 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <88656-1>; Mon, 14 Aug 1995 12:18:23 +0300 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id LAA24045 (8.6.12/IDA-1.6); Mon, 14 Aug 1995 11:17:57 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA06371; Mon, 14 Aug 95 11:17:56 +0200 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9508140917.AA06371@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: inline patches To: daniel@brasil.brainstorm.cnam.fr (Daniel Verite) Date: Mon, 14 Aug 1995 11:17:56 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508121610.SAA03025@brasil.frmug.fr.net> from "Daniel Verite" at Aug 12, 95 06:10:40 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 2801 > > > [ better inlines ] > > I think RKM says every library call (at least those shipped with the OS) > might trash d0-d1/a0-a1. Perhaps I miss the point, but if you plan to > look at every function and try to determine which of those registers > aren't actually trashed, it sounds quite nasty to me. > Yes, this would be very nasty. But some of execs functions (Forbid(), Permit(), ...) are documented (in the autodocs) to not trash any registers. Some of utility.library's functions are documented to not use a6 and not trash a0, a1. Since it's documented you can rely on it. Btw: I like the idea to lay the burden to memorize all the inlines onto the preprocessor instead of the main compiler pass. And you don't necessarily need to lose typechecking: For each function you build a macro that declares the assembler inline as a nested function which is called immediately (see below). One header file contains the magic LPx()-Macros - making it easier to write inline header files - and as a side effect you're able to use local variables or even preprocessor macros as library base variables. What do you say? Matthias -----newinline.c----- #include struct ExecBase; #define LP2(num,rt,name,t1,v1,r1,t2,v2,r2,bt,bn,br) \ ({ \ __inline rt name(t1 __n1,t2 __n2) \ { \ register rt _re __asm(D0); \ register bt _bn __asm(br) = (bn); \ register t1 _n1 __asm(r1) = __n1; \ register t2 _n2 __asm(r2) = __n2; \ __asm __volatile ("jsr a6@(-6*"#num":W)" \ :"=r"(_re) \ :"r"(_n1),"r"(_n2),"r"(_bn) \ :D0,D1,A0,A1,"cc","memory"); \ return _re; \ } \ name(v1,v2); \ }) #define D0 "d0" #define D1 "d1" #define A0 "a0" #define A1 "a1" #define A6 "a6" #define AllocMem(byteSize,attributes) \ LP2(33,APTR,AllocMem,ULONG,byteSize,D0,ULONG,attributes,D1, \ struct ExecBase *,SysBase,A6) extern struct ExecBase *SysBase; APTR testfunc1(ULONG a,ULONG b) { return AllocMem(a,b); } APTR testfunc2(ULONG a,ULONG b) { struct ExecBase *SysBase=*(struct ExecBase **)4; return AllocMem(a,b); } #define SysBase *(struct ExecBase **)4 APTR testfunc3(ULONG a,ULONG b) { return AllocMem(a,b); } -----newinline.S----- #NO_APP gcc2_compiled.: ___gnu_compiled_c: .text .even .globl _testfunc1 _testfunc1: movel a6,sp@- movel _SysBase,a6 movel sp@(8),d0 movel sp@(12),d1 #APP jsr a6@(-6*33:W) #NO_APP movel sp@+,a6 rts .even .globl _testfunc2 _testfunc2: addw #-8,sp movel a6,sp@- movel 4:w,a6 movel a6,sp@(4) movel sp@(16),d0 movel sp@(20),d1 #APP jsr a6@(-6*33:W) #NO_APP movel sp@+,a6 addw #8,sp rts .even .globl _testfunc3 _testfunc3: movel a6,sp@- movel 4:w,a6 movel sp@(8),d0 movel sp@(12),d1 #APP jsr a6@(-6*33:W) #NO_APP movel sp@+,a6 rts -----end----- From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 14:30:05 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90474-1>; Mon, 14 Aug 1995 14:29:32 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug14.142932+0300_eet_dst.90474-1+45@nic.funet.fi> From: To: Date: Mon, 14 Aug 1995 14:29:32 +0300 Date: Mon, 14 Aug 1995 13:26:17 +0200 (METDST) From: Rask Lambertsen To: Gunther Nikl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: comments and questions about gcc270 In-Reply-To: <199508101150.NAA05550@honshu.informatik.uni-rostock.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 10 Aug 1995, Gunther Nikl wrote: > Hello! > > > o Can anybody comment on this assembly code? > > int strlen(const char* str) > > { > > register const char* ptr = str; > > while (*ptr++) ; > > return (ptr - str) -1; > ^^^^^^^^^^^^^^ > Try "~(str-ptr)" instead Or try "return (str + ~ptr);" - This is faster if addition is faster than subtraction. > > > o BTW, ixem41.1-src contains the following strlen.s: > > moveq #-1,d0 > > movl sp@(4),a0 /* string */ > > slloop: > > addql #1,d0 /* increment count */ > > tstb a0@+ /* null? */ > > jne slloop /* no, keep going */ > > rts > > Isn't this slower because of more instructions in the loop? > > (Let's start the strlen assembly contest :-) Or does it make no > > difference because RAM can't be accessed fast enough? Ofcourse RAM can be accessed fast enough. Some people actually have real FAST RAM. > Thats really a bad one... Horrors! This is how is should be done (Motorola syntax): move.l (sp)+,a0 move.l a0,d0 slloop: tst.l (a0)+ ; Test for null-terminator and increment A0 bne.b slloop ; Repeat if we didn't find the terminator not.l d0 ; D0 = -D0 - 1 add.l a0,d0 ; D0 = A0 - D0 - 1 rts If only 16-bit returns were needed, this could be done ever faster, I think (using 'dbeq.w' maybe). > > o I'm trying hard to prevent GCC from reloading A6 for several OS > > calls in a row, unsuccessfully so far: > > Thats what I am told Philippe some time ago, too. Maybe, its > annoying to hear, that with 2.3.3 it worked... (but I think > that was an optimizer bug) > But the current gcc 2.7.0 is much better than 2.3.3. Even if its > reloads a6 every time, the executable size is smaller (but could > be even smaller by eleminating a6-reloading). Doesn't the inline headers force the compiler to reload a6 every time? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 14:43:37 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90047-2>; Mon, 14 Aug 1995 14:43:04 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug14.144304+0300_eet_dst.90047-2+48@nic.funet.fi> From: To: Date: Mon, 14 Aug 1995 14:43:02 +0300 Date: Mon, 14 Aug 1995 13:40:02 +0200 (METDST) From: Rask Lambertsen To: Kamil Iskra Cc: hoehle@inf-wiss.uni-konstanz.de, Amiga GCC List Subject: Re: comments and questions about gcc270 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 11 Aug 1995, Kamil Iskra wrote: > As far as I understand the role of "memory", OpenLibrary() does not need > "memory" in the list of clobbered "registers" - "memory" is only necessary > if assembler part modifies a variable, for example it would be needed if > OpenLibrary() modified something in "LibName" parameter. > > Maybe one day inlines will have "memory" only in calls that really need > it. But this requires a lot of work. I once volunteered (sp?) to do it, > but first thing that has to be done is reliable inlines generator. This > work is in progress, Rainer Trunz is working on it and "fd2inline.c" is > nearly correct. Once it is done, there will be time to add all this nice > features like "memory" only in calls that really need it, wider/narrower > list of clobbered registers for certain calls such as Forbid() etc. Just > be patient :-). There is also the quiestion about putting "cc" in the clobber-list. I will also wolunteer to try to optimize those inline files. And also fix the Supervisor() inline definition - anything can be clobbered (d0-d7, a0-a7, cc, memory) Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 14:51:25 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90464-2>; Mon, 14 Aug 1995 14:51:06 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug14.145106+0300_eet_dst.90464-2+49@nic.funet.fi> From: To: Date: Mon, 14 Aug 1995 14:51:01 +0300 Date: Mon, 14 Aug 1995 13:47:56 +0200 (METDST) From: Rask Lambertsen To: Olaf Seibert Cc: hoehle@inf-wiss.uni-konstanz.de, kiskra@ernie.icslab.agh.edu.pl, amiga-gcc-port@nic.funet.fi, rhialto@mbfys.kun.nl Subject: Re: comments and questions about gcc270 In-Reply-To: <199508111502.RAA01265@septimius.mbfys.kun.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 11 Aug 1995, Olaf Seibert wrote: > At one point I had devised a method to avoid defining an inline function > per library function. (This takes a lot of memory, most of which is > not needed, since most of them will not be used in any given translation > unit). Instead, I had inline functions for each mapping (argument > position) -> (register), and #defines to map each library function > to one appropriate call function. Unfortunately this lost the type > information (all parameters being LONG)... > > Anybody interested in me digging this up? I am! Btw, would this allow you to use local variables for library bases? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 14:56:30 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89707-1>; Mon, 14 Aug 1995 14:55:54 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug14.145554+0300_eet_dst.89707-1+46@nic.funet.fi> From: To: Date: Mon, 14 Aug 1995 14:55:46 +0300 Date: Mon, 14 Aug 1995 13:52:57 +0200 (METDST) From: Rask Lambertsen To: Daniel Verite Cc: amiga-gcc-port@nic.funet.fi Subject: Re: inline patches In-Reply-To: <199508121610.SAA03025@brasil.frmug.fr.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 12 Aug 1995, Daniel Verite wrote: > > > > [ better inlines ] > > > > > Bad idea, since now all inlines had been created with a perl-script > > > that worked _very_ reliable and so do the generated inlines. The > > > generated code won't be much better only because the compiler now > > > knows that eg. ObtainSemaphore() does not trash a0. > > > > Why not? If the compiler knows that a register is not trashed, it might > > be able to save a variable load. It might indeed be able to save stack > > space since more registers are available. > > This is especially true for calls like ObtainSemaphore(), since this > > is generally used like > > ... prepare some action ... > > ObtainSemaphore() > > ... do something which usually is only a few lines... > > ReleaseSemaphore() > > > > And even you think that it won't help: it won't hurt either. > > > > I think RKM says every library call (at least those shipped with the OS) > might trash d0-d1/a0-a1. Perhaps I miss the point, but if you plan to > look at every function and try to determine which of those registers > aren't actually trashed, it sounds quite nasty to me. > Indeed, these things could change from any revision of the OS to the > other, let alone the possible future (?) versions. Yes, you did miss the point :-(. Some functions are *documented* *and* *guaranteed* not to trash specific registers. In these cases, the inlines can be patched so that the compiler isn't forced to reload registers unnecessarily. There is nothing nasty in this. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 14:58:36 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90411-3>; Mon, 14 Aug 1995 14:57:58 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug14.145758+0300_eet_dst.90411-3+28@nic.funet.fi> From: To: Date: Mon, 14 Aug 1995 14:57:57 +0300 Date: Mon, 14 Aug 1995 13:55:08 +0200 (METDST) From: Rask Lambertsen To: Erik Rissanen Cc: amiga-gcc-port@nic.funet.fi Subject: Re: amitcp and gcc In-Reply-To: <2120f4b4.u7t150e.1069a-erik.rissanen@mn.medstroms.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 12 Aug 1995, Erik Rissanen wrote: > 6. Is AmiTCP laid out in a similar way as TCP/IP networking on UNIX, so that > it will be reasonably simple to port programs? Yes. The functions should be BSD compatible. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 15:03:38 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90559-1>; Mon, 14 Aug 1995 15:03:14 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug14.150314+0300_eet_dst.90559-1+47@nic.funet.fi> From: To: Date: Mon, 14 Aug 1995 15:03:07 +0300 Date: Mon, 14 Aug 1995 14:00:09 +0200 (METDST) From: Rask Lambertsen To: Matthias Fleischer Cc: Daniel Verite , amiga-gcc-port@nic.funet.fi Subject: Re: inline patches In-Reply-To: <9508140917.AA06371@sunserv.IZFM.Uni-Stuttgart.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 14 Aug 1995, Matthias Fleischer wrote: > Btw: > I like the idea to lay the burden to memorize all the inlines onto > the preprocessor instead of the main compiler pass. And you don't To save memory, right? > necessarily need to lose typechecking: > For each function you build a macro that declares the assembler > inline as a nested function which is called immediately > (see below). One header file contains the magic LPx()-Macros - > making it easier to write inline header files - and as a side > effect you're able to use local variables or even preprocessor > macros as library base variables. > > What do you say? Great! This is the sort of thing I have been missing with GCC. [big snip] Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 15:04:18 1995 Received: by nic.funet.fi id <87922-1>; Mon, 14 Aug 1995 15:03:41 +0300 From: Leonard Norrgard To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95Aug14.144304+0300_eet_dst.90047-2+48@nic.funet.fi> (gc948374@gbar.dtu.dk) Message-Id: <95Aug14.150341+0300_eet_dst.87922-1+48@nic.funet.fi> Date: Mon, 14 Aug 1995 15:03:34 +0300 > There is also the quiestion about putting "cc" in the clobber-list. > I will also wolunteer to try to optimize those inline files. And also fix > the Supervisor() inline definition - anything can be clobbered (d0-d7, > a0-a7, cc, memory) Supervisor() doesn't clobber anything. Per definition of Supervisor(), the executed routine has full access to the register set (ie, it's free to clobber registers if it wants to). If we force the compiler to reload all registers after a Supervisor call, we break Supervisor. -- vinsci From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 15:10:37 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <88586-2>; Mon, 14 Aug 1995 15:10:04 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug14.151004+0300_eet_dst.88586-2+50@nic.funet.fi> From: To: Date: Mon, 14 Aug 1995 15:09:56 +0300 Date: Mon, 14 Aug 1995 14:07:07 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: My e-mail headers (Was: Re: (090895-1502) Problemer med headers i e-mail (Was: E-Mails from Rask) (fwd)) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I asked the system administration about the TAB's in the headers and they believe that this is normal and that the recipient (which is lists.funet.fi) should fix the problem, so I will try to get the administrators of lists.fune.fi to fix it. For those interested, I have included the reply from DTU Databar Support below. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ ---------- Forwarded message ---------- Date: Thu, 10 Aug 1995 08:53:10 +0200 (METDST) From: DTU Databar Support To: gc948374@gbar.dtu.dk Cc: DTU Databar Support Subject: Re: (090895-1502) Problemer med headers i e-mail (Was: E-Mails from Rask) --------------------------------------------------------------- Databar Support Problem nr.: 090895-1502 --------------------------------------------------------------- > From gc948374@gbar.dtu.dk Wed Aug 9 15:00:59 1995 > Date: Wed, 9 Aug 1995 14:59:52 +0200 (METDST) > From: Rask Lambertsen > To: Databar Support > Subject: Problemer med headers i e-mail (Was: E-Mails from Rask (fwd)) > Message-Id: > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Kaere Databar Support, > > Der er nogle problemer med udgaaende e-mail fra g-databaren. Problemet > ser ud til at vaere at der bliver indsat TAB-tegn i headeren, hvilket > forvirrer en masse mail-gateways og mailers. Jeg har vedlagt et brev der > maaske kan kaste lys over problemet. > > Med venlig hilsen, > _________________________________________________________________________ > / \ > | Rask Ingemann Lambertsen , | > | Keyboard error: and are stuck - press to continue | > \_________________________________________________________________________/ > > ---------- Forwarded message ---------- > Date: Wed, 9 Aug 95 14:24:27 +0200 > From: Joerg-Cyril Hoehle > To: Rask Lambertsen > Cc: postmaster@gbar.dtu.dk > Subject: E-Mails from Rask > > Hi, > > sorry to take this into the mailing list, but as Rask pointed out, > some people do get correct mails from him so sending this mail to all > of us will perhaps help clear things out. > > Here is a mail that I go directly from Rask. > -------- > >From gc948374@gbar.dtu.dk Wed Aug 9 13:51:04 1995 > Return-Path: > Received: from lorenz.gbar.dtu.dk by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) > id AA23820; Wed, 9 Aug 95 13:50:35 +0200 > Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) > > In-Reply-To: <9508091144.AA23786@inf-wiss.uni-konstanz.de> > Message-Id: > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > From: Rask Lambertsen > To: Joerg-Cyril Hoehle > Cc: amiga-gcc-port > Subject: Re: gcc270 prerelease bugs and notes (fwd) > Date: Wed, 9 Aug 1995 13:49:57 +0200 (METDST) > > On Wed, 9 Aug 1995, Joerg-Cyril Hoehle wrote: > -------- > Notice the _non-empty_(but almost invisible) line following > Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) > It contains a single TAB. I don't know what to think of that, but to > me it seems that some gateways see the non-empty line as continuing > the Received: line where other must interpret it as a blank line that > separates the headers from the message content. > > Here's Rask's mail received through amiga-gcc-port > -------- > >From amiga-gcc-port-owner@nic.funet.fi Wed Aug 9 13:51:56 1995 > Return-Path: > Received: from nic.funet.fi by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) > id AA23841; Wed, 9 Aug 95 13:51:53 +0200 > Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90602-2>; Wed, 9 Aug 1995 14:51:29 +0300 > Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) > Message-Id: <95Aug9.145129+0300_eet_dst.90602-2+36@nic.funet.fi> > From: > To: > Date: Wed, 9 Aug 1995 14:51:23 +0300 > > Date: Wed, 9 Aug 1995 13:49:57 +0200 (METDST) > From: Rask Lambertsen > To: Joerg-Cyril Hoehle > Cc: amiga-gcc-port > Subject: Re: gcc270 prerelease bugs and notes (fwd) > In-Reply-To: <9508091144.AA23786@inf-wiss.uni-konstanz.de> > Message-Id: > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Wed, 9 Aug 1995, Joerg-Cyril Hoehle wrote: > -------- > It looks like it got cut at the TAB line above. > > It looks like the host lorenz.gbar.dtu.dk(1.37.109.15/16.2) should > stop sending the trailing blank line and everything could work fine. > Could somebody on this list get postmaster@lorenz.gbar.dtu.dk or > whomever to correct the SMTP configuration of this host and remove that > TAB-only line? > > Or should nic.funet.fi be fixed to accept it? > > Thanks, > Joerg Hoehle. > hoehle@inf-wiss.uni-konstanz.de ------------------------------------------------------------------ Svar fra Databar Support: There is - as you have found out - a TAB on the lines after Received:... This is something that I can see in all my mail from machines all over the world, so I would say, that the problem is to be solved at the receipient instead. We are not planning to make any changes. The lines can look as follows: Received: from srv2.gbar.dtu.dk by unidhp1.uni-c.dk with SMTP (TAB) (1.37.109.8/16.2) id AA19295; Wed, 9 Aug 1995 15:59:47 +0200 Received: by srv2.gbar.dtu.dk(1.38.193.4/16.2) (TAB) for uniok@unidhp1.uni-c.dk id AA00360; Wed, 9 Aug 1995 16:03:04 +0200 /UNI-C -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Databar Support Databar problems: dbsupport@dtu.dk + + UNI-C DTU-net problems: netsupport@dtu.dk + + DTU, build. 304 Both phone : DTU local 1256 + + DK 2800 Lyngby + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 15:18:20 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90194-3>; Mon, 14 Aug 1995 15:17:59 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug14.151759+0300_eet_dst.90194-3+29@nic.funet.fi> From: To: To: Date: Mon, 14 Aug 1995 15:17:57 +0300 Date: Mon, 14 Aug 1995 14:15:14 +0200 (METDST) From: Rask Lambertsen To: Leonard Norrgard Cc: amiga-gcc-port@nic.funet.fi Subject: Re: your mail In-Reply-To: <95Aug14.150341+0300_eet_dst.87922-1+48@nic.funet.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 14 Aug 1995, Leonard Norrgard wrote: > > There is also the quiestion about putting "cc" in the clobber-list. > > I will also wolunteer to try to optimize those inline files. And also fix > > the Supervisor() inline definition - anything can be clobbered (d0-d7, > > a0-a7, cc, memory) > > Supervisor() doesn't clobber anything. Per definition of > Supervisor(), the executed routine has full access to the register set > (ie, it's free to clobber registers if it wants to). If we force the > compiler to reload all registers after a Supervisor call, we break > Supervisor. Maybe all registers should be defined as returning a result then? Otherwise, how is it possible to use Supervisor() from GCC at all? If we don't put all registers into the clobber list, GCC won't know that it can't trust the contents of the registers. As a result, buggy code could be generated. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 15:20:02 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <88472-1>; Mon, 14 Aug 1995 15:19:32 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id OAA23747 for amiga-gcc-port@lists.funet.fi; Mon, 14 Aug 1995 14:17:19 +0200 From: Jochen Wiedmann Message-Id: <199508141217.OAA23747@iss1.neckar-alb.de> Subject: Re: Inline headers To: amiga-gcc-port@nic.funet.fi Date: Mon, 14 Aug 1995 14:17:19 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 468 Hey, guys, don't you think its much more important to get a stable version of gcc-2.7.0 than to win a few microseconds at the risk of serious problems because of probably just one wrong inline? Philippe, please don't add new inlines to the forthcoming release. If anyone is really interested in these things, he may do it and integrate it into a release, where we have much time for testing, but not as a last minutes fix. This really isn't that important. Jochen From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 15:24:58 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <88310-3>; Mon, 14 Aug 1995 15:24:25 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug14.152425+0300_eet_dst.88310-3+30@nic.funet.fi> From: To: Date: Mon, 14 Aug 1995 15:24:18 +0300 Date: Mon, 14 Aug 1995 14:20:20 +0200 (METDST) From: Rask Lambertsen To: Hans Verkuil Cc: amiga-gcc-port@nic.funet.fi Subject: Re: In-Reply-To: <9508091937.08pz@wyst.hobby.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 9 Aug 1995, Hans Verkuil wrote: > > Now open a second shell. Start 'resident-test_GCC' and immediately press > > to stop output, wait a few seconds, then quickly press > > and so that only the first line is output (this might be difficult > > on a fast machine). > > > > Then go back to the first shell and start the program as normal. > > It won't work. Now arrange the shell windows so that you can see both > > of them at the same time. Go back to the second shell and press > > to let the program output text again. *Now* the other > > program (in the first shell) will output it's two lines of text and > > exit. > > > > Obviously, something doesn't work quite the way it was intended. > > Which ixemul version do you use? I've tried it here and it worked OK. I use ixemul 41.1. And it hasn't failed on my machine (7 MHz '000) yet. > However, a similar bug has been fixed in ixemul.library. You can test if > this is the culprit by compiling the test program without -resident and > running the test again. The same problem should arise. You're right, it does. I'm sorry, I really should have checked that. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 15:33:00 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <87897-1>; Mon, 14 Aug 1995 15:32:22 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug14.153222+0300_eet_dst.87897-1+52@nic.funet.fi> From: To: Date: Mon, 14 Aug 1995 15:32:15 +0300 Date: Mon, 14 Aug 1995 14:28:14 +0200 (METDST) From: Rask Lambertsen To: Jochen Wiedmann Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Inline headers In-Reply-To: <199508141217.OAA23747@iss1.neckar-alb.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 14 Aug 1995, Jochen Wiedmann wrote: > Hey, guys, > > don't you think its much more important to get a stable version of > gcc-2.7.0 than to win a few microseconds at the risk of serious > problems because of probably just one wrong inline? Yes, fortunately both things can be worked on by different people. I can't work on gcc itself due to a lack of resources (RAM and CPU), but I can work on the inline headers so that those people who are dying to get optimized versions can get them. > Philippe, please don't add new inlines to the forthcoming release. If > anyone is really interested in these things, he may do it and > integrate it into a release, where we have much time for testing, but > not as a last minutes fix. This really isn't that important. No, but it should be done at some point anyway, so why not begin now and have new inlines ready for 2.7.1? That can't hurt 2.7.0 IMO. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 16:43:25 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90534-2>; Mon, 14 Aug 1995 16:36:37 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug14.163637+0300_eet_dst.90534-2+52@nic.funet.fi> From: To: Date: Mon, 14 Aug 1995 16:36:29 +0300 Date: Mon, 14 Aug 1995 15:33:02 +0200 (METDST) From: Rask Lambertsen To: Kamil Iskra Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Diffs for README.libnix and README-2.7.0 (long, 13 k) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 9 Aug 1995, Kamil Iskra wrote: > It think you are generally right about this changes, but one think is > definitely wrong: megabytes==MB!=Mb && kilobytes==KB!=kb. ^^^^^^^^^^^^^^^^^ No, kilo is definitely a small 'k'. So kilobytes is kB. As for bytes, I have never seen any specification as to whether it should be 'B' or 'b', but I'll use 'B' in the patches. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 16:43:37 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <88246-4>; Mon, 14 Aug 1995 16:39:07 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id PAA03924; Mon, 14 Aug 1995 15:36:51 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id OAA04197; Mon, 14 Aug 1995 14:26:35 +0200 Date: Mon, 14 Aug 1995 14:26:35 +0200 From: Niklas Hallqvist Message-Id: <199508141226.OAA04197@linda.appli.se> To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95Aug14.151004+0300_eet_dst.88586-2+50@nic.funet.fi> (gc948374@gbar.dtu.dk) >>>>> "Rask" == gc948374 writes: Rask> I asked the system administration about the TAB's in the headers Rask> and they believe that this is normal and that the recipient Rask> (which is lists.funet.fi) should fix the problem, so I will try Rask> to get the administrators of lists.fune.fi to fix it. Actually they seem to be correct, I just read RFC822 and a CRLF + white-space should just drop the CRLF. So funet seems to be in error. NH Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 17:09:33 1995 Received: from dira.bris.ac.uk ([137.222.10.41]) by nic.funet.fi with ESMTP id <90956-3>; Mon, 14 Aug 1995 17:08:55 +0300 Received: from zeus.bris.ac.uk by dira.bris.ac.uk with SMTP (PP); Mon, 14 Aug 1995 15:08:35 +0100 Received: by zeus.bris.ac.uk (950215.SGI.8.6.10/940406.SGI) for amiga-gcc-port@lists.funet.fi id PAA21559; Mon, 14 Aug 1995 15:08:34 +0100 From: Pierre.Scotney@bristol.ac.uk (PD. Scotney) Message-Id: <199508141408.PAA21559@zeus.bris.ac.uk> Subject: Workbench Startup Message - Help! To: amiga-gcc-port@nic.funet.fi Date: Mon, 14 Aug 1995 15:08:34 +0100 (BST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 713 Could somebody please help! I am trying out a few experimental C programs to get me back in the programming mode but I'm having difficulty getting the Workbench startup message with gcc2.6.3. I've looked through all the GCC documentation and cannot find any notes on the linked startup code. I've tried using: #include extern struct WBStartup *WBenchMsg in my source before my main() but I get an error message saying that _WBenchMsg is undefined. Could someone please tell me if GCC produces code for Workbench launchable programs and if so how to I access the subsequent Workbench startup message that it produces. Thanks! Pierre. Amiga1200, ZXSpectrum+ and a wasted youth! From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 17:10:39 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90954-1>; Mon, 14 Aug 1995 17:10:00 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 14 Aug 95 16:06 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 14 Aug 95 15:59 MET DST Message-Id: Subject: Size names To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 14 Aug 1995 15:59:38 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1004 > > > It think you are generally right about this changes, but one think is > > definitely wrong: megabytes==MB!=Mb && kilobytes==KB!=kb. > ^^^^^^^^^^^^^^^^^ > No, kilo is definitely a small 'k'. So kilobytes is kB. > As for bytes, I have never seen any specification as to whether it should > be 'B' or 'b', but I'll use 'B' in the patches. > actualy K for kilo is right, because all for positive exponents the shortcut is capitel (T,G,M,...) while for negative its small. because K is used so often its allowed to use smallcaps too. I dont know if B,b is defined somewhere but there seems to be an agreement that b means Bit (0/1) while B means Byte (0..255). walter -- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 17:22:22 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90949-2>; Mon, 14 Aug 1995 17:21:44 +0300 Received: by oersted.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug14.172144+0300_eet_dst.90949-2+2@nic.funet.fi> From: To: Date: Mon, 14 Aug 1995 17:21:41 +0300 Date: Mon, 14 Aug 1995 16:17:47 +0200 (METDST) From: Rask Lambertsen To: Walter Harms Cc: amiga gcc-list Subject: Re: Size names (way off topic) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 14 Aug 1995, Walter Harms wrote: > > > It think you are generally right about this changes, but one think is > > > definitely wrong: megabytes==MB!=Mb && kilobytes==KB!=kb. > > ^^^^^^^^^^^^^^^^^ > > No, kilo is definitely a small 'k'. So kilobytes is kB. > > As for bytes, I have never seen any specification as to whether it should > > be 'B' or 'b', but I'll use 'B' in the patches. > > > > actualy K for kilo is right, because all for positive exponents > the shortcut is capitel (T,G,M,...) while for negative its small. > because K is used so often its allowed to use smallcaps too. Aargh - so far I have never seen a capital 'k' used for 'kilo' - this includes math books. I think I have even seen several official lists stating small 'k' for 'kilo'. > I dont know if B,b is defined somewhere but there seems to > be an agreement that b means Bit (0/1) while B means Byte (0..255). I'm pretty sure that a letter for 'bit' has not been defined. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 17:42:12 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90943-1>; Mon, 14 Aug 1995 17:41:07 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26462-1>; Mon, 14 Aug 1995 16:40:12 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209195-1>; Mon, 14 Aug 1995 16:40:00 +0100 Subject: Re: inline patches From: Christian Stieber To: daniel@brasil.brainstorm.cnam.fr (Daniel Verite) Date: Mon, 14 Aug 1995 16:39:48 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508121610.SAA03025@brasil.frmug.fr.net> from "Daniel Verite" at Aug 12, 95 06:10:40 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1181 Message-Id: <95Aug14.164000+0100mesz.209195-1+294@hphalle0.informatik.tu-muenchen.de> [ Some lib calls don't trash all registers ] > I think RKM says every library call (at least those shipped with the OS) > might trash d0-d1/a0-a1. Perhaps I miss the point, but if you plan to > look at every function and try to determine which of those registers > aren't actually trashed, it sounds quite nasty to me. We are not planning to do that. Some functions are _documented_ to not trash all of d0/d1/a0/a1. We only want to tell the compiler about these functions. Also, some functions do not need the library base in a6 --- again, looking at the autodocs is enough to find these functions, since they are documented to not require the library base. > Indeed, these things could change from any revision of the OS to the > other, let alone the possible future (?) versions. No. Anything that's documented will stay this way. We don't plan to disassemble AmigaOS. > Daniel Verite -- daniel@brainstorm.cnam.fr Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 17:58:12 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90955-3>; Mon, 14 Aug 1995 17:57:21 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id PAA08256; Mon, 14 Aug 1995 15:54:34 +0100 From: Lars Hecking Message-Id: <199508141457.PAA12910@mostar.nmrc.ucc.ie> Subject: Re: Workbench Startup Message - Help! To: Pierre.Scotney@Bristol.ac.uk (PD. Scotney) Date: Mon, 14 Aug 1995 15:57:38 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199508141408.PAA21559@zeus.bris.ac.uk> from "PD. Scotney" at Aug 14, 95 03:08:34 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1699 > I am trying out a few experimental C programs to get me back in the > programming mode but I'm having difficulty getting the Workbench startup > message with gcc2.6.3. I've looked through all the GCC documentation and > cannot find any notes on the linked startup code. I've tried using: > > #include > extern struct WBStartup *WBenchMsg > > in my source before my main() but I get an error message saying > that _WBenchMsg is undefined. GCC's C library doesn't have it, but SAS' does. > Could someone please tell me if GCC produces code for Workbench launchable > programs and if so how to I access the subsequent Workbench startup > message that it produces. $ cat wbmsg.c #include struct WBStartup *WBenchMsg; $ cat main.c ... #include extern struct WBStartup *WBenchMsg; ... int main (int argc, char **argv) { ... if (argc == 0) /* Started from wb */ { WBenchMsg = (struct WBStartup *)argv; ... Then, link wbmsg.o into your program (of course, you could omit wbmsg.c and remove the "extern" declaration in main.c). I haven't actually tried this out, but it should work, as argv is properly filled by ixemul.library (library/ix_startup.c and library/_main.c, for source hackers ;) A neat way to deal with CLI/WB startup is used in Ralph Babel's Guru Book (ArgsEcho.c -- (C) by Ralph Babel): union argv { const char *const *cliArg; const struct WBStartup *wbArg; }; ... int main (ULONG argc, union argv argv) { ... if (argc != 0) /* CLI */ { /* argv[0], argv[1], ... etc */ } ... else /* WB */ { /* wbArg->sm_Process, wbArg->sm_Segment ... etc */ ... Hope this helps. Lars From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 18:05:20 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90933-4>; Mon, 14 Aug 1995 18:04:52 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26474-2>; Mon, 14 Aug 1995 17:04:29 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209198-2>; Mon, 14 Aug 1995 17:04:09 +0100 Subject: Re: your mail From: Christian Stieber To: gc948374@gbar.dtu.dk Date: Mon, 14 Aug 1995 17:04:08 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Aug14.172144+0300_eet_dst.90949-2+2@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 14, 95 05:21:41 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1066 Message-Id: <95Aug14.170409+0100mesz.209198-2+325@hphalle0.informatik.tu-muenchen.de> > > actualy K for kilo is right, because all for positive exponents > > the shortcut is capitel (T,G,M,...) while for negative its small. > > because K is used so often its allowed to use smallcaps too. > > Aargh - so far I have never seen a capital 'k' used for 'kilo' - this > includes math books. I think I have even seen several official lists > stating small 'k' for 'kilo'. Well, the correct thing for the _decimal_ is "k" -- think about kg, km and other units. However, a "Kilobyte" is not 1000 Bytes, it is 1024 Bytes. As a general convention, people use "K" for the binary "kilo", i.e. 1 kB would be 1000 Bytes, while 1KB is 1024 Bytes. Of course, this doesn't work for "Mega" since 1 mB would be 1/1000 Byte :) > | Rask Ingemann Lambertsen , | Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 20:46:24 1995 Received: from INVALID ([193.212.103.101]) by nic.funet.fi with SMTP id <90896-4>; Mon, 14 Aug 1995 20:45:30 +0300 Received: by INVALID.telepost.no (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Mon, 14 Aug 95 19:45:18 Received: by INVALID.telepost.no (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Mon, 14 Aug 95 11:01:14 Date: Mon, 14 Aug 1995 11:01:14 +0000 () From: Erik Johannessen X-Sender: erij@localhost Subject: Re: amitcp and gcc In-Reply-To: <2120f4b4.u7t150e.1069a-erik.rissanen@mn.medstroms.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: amiga-gcc-port@nic.funet.fi On Sat, 12 Aug 1995, Erik Rissanen wrote: > I read in the FAQ about the problems associated with using amitcp with gcc, > but despite of that, many of you on the list seem to compile programs for > amitcp with gcc, so I am wondering how do you do it? The FAQ is a bit out of date. There is a port of the AmiTCP sdk kit for gcc on Aminet. You can find it in comm/tcp or comm/net its called ATCP-sdk-40-gc.lha > 2. seems to be incompatible with the other includes in the > package. Is that TRUE or am I doing something wrong? (Sorry for 'TRUE' beeing > capitalized, but this editor does that and I do not know how to turn it off.) There is a new set of includes in the archive mentioned above. > 6. Is AmiTCP laid out in a similar way as TCP/IP networking on UNIX, so that > it will be reasonably simple to port programs? Yes, just be sure to read the README.gcc in the archive. > 7. Should I really bother to try? Will it be almost impossible? If it is the Empire client you are trying to port, you shouldn't have to many problems getting the networking code to work. I've been having some problems with code that select() between sockets and other fildescriptors. The libnewamitcp.a WaitSelect() only work on sockets I suppose. This is a problem for programs waiting for input on both sockets and the terminal. Is there a (easy) solution? -Erik From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 21:27:50 1995 Received: from INVALID ([193.212.103.101]) by nic.funet.fi with SMTP id <90860-2>; Mon, 14 Aug 1995 21:27:07 +0300 Received: by INVALID.telepost.no (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Mon, 14 Aug 95 20:26:58 Received: by INVALID.telepost.no (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Mon, 14 Aug 95 20:19:32 Date: Mon, 14 Aug 1995 20:19:32 +0000 () From: Erik Johannessen X-Sender: erij@localhost Subject: Re: Workbench Startup Message - Help! In-Reply-To: <199508141408.PAA21559@zeus.bris.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: amiga-gcc-port@nic.funet.fi On Mon, 14 Aug 1995, PD. Scotney wrote: > Could somebody please help! > > I am trying out a few experimental C programs to get me back in the > programming mode but I'm having difficulty getting the Workbench startup > message with gcc2.6.3. I've looked through all the GCC documentation and > cannot find any notes on the linked startup code. I've tried using: > > #include > extern struct WBStartup *WBenchMsg > > in my source before my main() but I get an error message saying > that _WBenchMsg is undefined. If you don't need "Unix" functions you can use libnix instead. Give the -noixemul option to gcc. See the libnix documentation(gnu:guide/libnix.guide) for more details. -Erik From amiga-gcc-port-owner@nic.funet.fi Mon Aug 14 22:41:39 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90853-2>; Mon, 14 Aug 1995 22:38:54 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id VAA12719; Mon, 14 Aug 1995 21:36:44 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id UAA06536; Mon, 14 Aug 1995 20:36:20 +0200 Date: Mon, 14 Aug 1995 20:36:20 +0200 From: Niklas Hallqvist Message-Id: <199508141836.UAA06536@linda.appli.se> To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95Aug14.172144+0300_eet_dst.90949-2+2@nic.funet.fi> (gc948374@gbar.dtu.dk) >>>>> "Rask" == gc948374 writes: >> > > It think you are generally right about this changes, but one >> think is > > definitely wrong: megabytes==MB!=Mb && >> kilobytes==KB!=kb. > ^^^^^^^^^^^^^^^^^ > No, kilo is definitely a >> small 'k'. So kilobytes is kB. > As for bytes, I have never seen >> any specification as to whether it should > be 'B' or 'b', but I'll >> use 'B' in the patches. > >> >> actualy K for kilo is right, because all for positive exponents the >> shortcut is capitel (T,G,M,...) while for negative its small. >> because K is used so often its allowed to use smallcaps too. Rask> Aargh - so far I have never seen a capital 'k' used for 'kilo' - Rask> this includes math books. I think I have even seen several Rask> official lists stating small 'k' for 'kilo'. Correct! The mathematical k prefix stands for kilo and is 10^3. It is the exception for the rule stated above as it was used widely long before that rule got invented. However, as someone else has pointed out, in order to differentiate between the "Kilo" in binary sense 2^10 and "kilo" in the decimal, capital K has been used widely for that purpose. I don't think this has been standardized by *any* standardization organization, though. I also think the importance to differentiate between the two prefixes is nil. It would seldom be of use, talking about 2^10 metres, or 10^3 bytes... In anyway this way to differentiate the two systems doesn't even scale to "mega""! I would use KB and MB, but just out of habit, not because I think this is in any way better than the other way. >> I dont know if B,b is defined somewhere but there seems to be an >> agreement that b means Bit (0/1) while B means Byte (0..255). Rask> I'm pretty sure that a letter for 'bit' has not been defined. bps is the common "bit per second" acronym, cps is character per second and usually used instead of Bps (for byte per second) as it is so easy to intermix the acronyms then. Anyway, use whatever you think is best, but be consistent, and define the acronyms in a glossary, if you think there might be a risk for misunderstandings. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Tue Aug 15 02:23:29 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90772-1>; Tue, 15 Aug 1995 02:19:37 +0300 Received: by colombo.telesys-innov.fr; Tue, 15 Aug 1995 01:20:27 +0100 From: Philippe BRAND Message-Id: <199508150020.BAA05493@colombo.telesys-innov.fr> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Tue, 15 Aug 1995 01:20:26 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95Aug14.153222+0300_eet_dst.87897-1+52@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 14, 95 03:32:15 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 702 gc948374@gbar.dtu.dk writes: > > Philippe, please don't add new inlines to the forthcoming release. If > > anyone is really interested in these things, he may do it and > > integrate it into a release, where we have much time for testing, but > > not as a last minutes fix. This really isn't that important. > > No, but it should be done at some point anyway, so why not begin now and > have new inlines ready for 2.7.1? That can't hurt 2.7.0 IMO. I freezed gcc source code last week. So next changes will be for 2.7.1 -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Aug 15 08:47:37 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90593-1>; Tue, 15 Aug 1995 08:46:49 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0siEuZ-0004nYC; Mon, 14 Aug 95 22:51 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: possible libnix 1.0 gets() bug To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Mon, 14 Aug 1995 22:51:38 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 927 I think that the following patch may be necessary for gets() in libnix 1.0: *** gets.c.orig Sun Jan 22 18:12:08 1995 --- gets.c Mon Aug 14 21:50:21 1995 *************** *** 6,12 **** char *s2=s; for(;;) { c=fgetc(stdin); ! if(ferror(stdin)) return NULL; if(c==EOF||c=='\n') break; --- 6,12 ---- char *s2=s; for(;;) { c=fgetc(stdin); ! if(ferror(stdin) || (c==EOF && s==s2)) return NULL; if(c==EOF||c=='\n') break; The problem is that gets() is documented to return NULL if EOF is seen and no characters have been transfered to the buffer. My program was looping continuously on gets() since it was looking for NULL as the termination condition. I.E.: while (gets (buf) != NULL) { do stuff with buf } Perhaps ferror(stdin) should be generating a NULL return for this case, I don't know for sure and didn't chase it back any further. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Aug 15 15:58:59 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <90753-1>; Tue, 15 Aug 1995 15:57:19 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id OAA08272 (8.6.10/2.4); Tue, 15 Aug 1995 14:57:32 +0200 Date: Tue, 15 Aug 1995 14:57:32 +0200 From: Olaf Seibert Message-Id: <199508151257.OAA08272@septimius.mbfys.kun.nl> To: Walter.Harms@arbi.informatik.uni-oldenburg.de, amiga-gcc-port@lists.funet.fi Subject: Re: Size names > actualy K for kilo is right, because all for positive exponents > the shortcut is capitel (T,G,M,...) while for negative its small. > because K is used so often its allowed to use smallcaps too. No, the SI one-letter suffix for "kilo" is "k". Note that this means 1000. For 1024, "K" is often used but this is not official in any way that I know of. -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Tue Aug 15 16:35:17 1995 Received: from sunic.sunet.se ([192.36.125.2]) by nic.funet.fi with SMTP id <90459-4>; Tue, 15 Aug 1995 16:30:39 +0300 Received: from Minsk.DoCS.UU.SE by sunic.sunet.se (8.6.8/2.03) id PAA29648; Tue, 15 Aug 1995 15:30:27 +0200 Received: by Minsk.DoCS.UU.SE (Sun-4/630, SunOS 4.1.2) with sendmail 5.61-bind 1.5+ida/ICU/DoCS id AA01158; Tue, 15 Aug 95 15:29:43 +0200 From: Erik Trulsson Message-Id: <9508151329.AA01158@Minsk.DoCS.UU.SE> Subject: DBL_MAX wrong in To: amiga-gcc-port@nic.funet.fi Date: Tue, 15 Aug 1995 15:29:43 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 436 As the subject line implies there is a bug in (well, there might be more but this is the only one that I have found) The bug is DBL_MAX which is defined as a too large value. I think that results in a NaN when you try to use it. I know it made one of my programs crash at least. Anyway the correct value of DBL_MAX hould be 1.7976931348623157E+308. After I had changed it in my include files my program worked fine anyway. From amiga-gcc-port-owner@nic.funet.fi Tue Aug 15 17:10:29 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90401-1>; Tue, 15 Aug 1995 17:09:52 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id PAA01624; Tue, 15 Aug 1995 15:07:56 +0100 From: Lars Hecking Message-Id: <199508151411.PAA00398@mostar.nmrc.ucc.ie> Subject: Re: DBL_MAX wrong in To: trulsson@Minsk.DoCS.UU.SE (Erik Trulsson) Date: Tue, 15 Aug 1995 15:11:00 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9508151329.AA01158@Minsk.DoCS.UU.SE> from "Erik Trulsson" at Aug 15, 95 03:29:43 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 594 > As the subject line implies there is a bug in (well, there > might be more but this is the only one that I have found) > The bug is DBL_MAX which is defined as a too large value. I think that > results in a NaN when you try to use it. I know it made one of my > programs crash at least. Anyway the correct value of DBL_MAX > hould be 1.7976931348623157E+308. After I had changed it in my include files > my program worked fine anyway. ?? does nothing but include and this one defines DBL_MAX correctly. Any chance you're using pre-2.7.0 headers? From amiga-gcc-port-owner@nic.funet.fi Tue Aug 15 17:27:33 1995 Received: from dira.bris.ac.uk ([137.222.10.41]) by nic.funet.fi with ESMTP id <90366-1>; Tue, 15 Aug 1995 17:26:54 +0300 Received: from zeus.bris.ac.uk by dira.bris.ac.uk with SMTP (PP); Tue, 15 Aug 1995 15:26:37 +0100 Received: by zeus.bris.ac.uk (950215.SGI.8.6.10/940406.SGI) for amiga-gcc-port@nic.funet.fi id PAA27653; Tue, 15 Aug 1995 15:26:36 +0100 From: Pierre.Scotney@bristol.ac.uk (PD. Scotney) Message-Id: <199508151426.PAA27653@zeus.bris.ac.uk> Subject: Re: Workbench Startup Message - Help! To: amiga-gcc-port@nic.funet.fi Date: Tue, 15 Aug 1995 15:26:36 +0100 (BST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 93 Thanks for all the help and advice on the subject. I shall give it a go! See ya! Pierre. From amiga-gcc-port-owner@nic.funet.fi Tue Aug 15 19:00:00 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90153-3>; Tue, 15 Aug 1995 18:58:53 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0siOSg-0004nYC; Tue, 15 Aug 95 09:03 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: DBL_MAX wrong in To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Tue, 15 Aug 1995 09:03:30 -0700 (MST) Cc: trulsson@Minsk.DoCS.UU.SE, amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi (ixemul.library maintainers) In-Reply-To: <199508151411.PAA00398@mostar.nmrc.ucc.ie> from "Lars Hecking" at Aug 15, 95 03:11:00 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1299 > > As the subject line implies there is a bug in (well, there > > might be more but this is the only one that I have found) > > The bug is DBL_MAX which is defined as a too large value. I think that > > results in a NaN when you try to use it. I know it made one of my > > programs crash at least. Anyway the correct value of DBL_MAX > > hould be 1.7976931348623157E+308. After I had changed it in my include files > > my program worked fine anyway. > > ?? does nothing but include and this one > defines DBL_MAX correctly. Any chance you're using pre-2.7.0 headers? Neither gnu:include/float.h nor gnu:include/machine/float.h will ever be used by gcc, since it will find its own float.h in the include tree under gnu:lib/gcc-lib/*/2.7.0 (for example). There are known problems with floating point. If I use the non-FPU version on my A4000, I get different floating point results than with the FPU version. With the non-FPU version gcc's "enquire" program, which is used to generate gcc's float.h, dies with an EMT trap. I hope to get some time to look at these problems after the release of FreshFish 10 and after I return from vacation in early September. Perhaps someone else would like to review the floating point support before then. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Aug 15 19:13:41 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90146-3>; Tue, 15 Aug 1995 19:13:13 +0300 Received: from septimius.mbfys.kun.nl by funet.fi with SMTP (PP); Tue, 15 Aug 1995 19:13:00 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id SAA08749 (8.6.10/2.4); Tue, 15 Aug 1995 18:11:05 +0200 Date: Tue, 15 Aug 1995 18:11:05 +0200 From: Olaf Seibert Message-Id: <199508151611.SAA08749@septimius.mbfys.kun.nl> To: gc948374@gbar.dtu.dk, rhialto@mbfys.kun.nl Subject: Re: comments and questions about gcc270 Cc: amiga-gcc-port@nic.funet.fi, gnikl@informatik.uni-rostock.de, hoehle@inf-wiss.uni-konstanz.de, kiskra@ernie.icslab.agh.edu.pl # This is a shell archive. # Remove everything above and including the cut line. # Then run the rest of the file through sh. #----cut here-----cut here-----cut here-----cut here----# #!/bin/sh # shar: Shell Archiver # Run the following text with /bin/sh to create: # fdtoinline.doc # fdtoinline.c # c.c # stubs.h # dos.h # This archive created: Mon Aug 14 22:39:27 1995 cat << \SHAR_EOF > fdtoinline.doc Just an impression of how old this is: fdtoinline.doc 3010 ----rwed 02-Jul-93 23:16:52 c.c 2050 ----rwed 19-Dec-92 05:34:45 inline Dir ----rwed 03-Dec-92 00:54:16 exec.h 6992 ----rwed 19-Dec-92 05:09:47 c.i 878 ----rwed 19-Dec-92 04:58:01 fdtoinline.c 15260 -s--rwed 19-Dec-92 04:48:35 exec_lib.fd 5382 ----rwed 14-Mar-91 21:11:38 graphics_lib.fd 5152 ----rwed 14-Mar-91 21:11:38 c.s 752 ----rwed 19-Dec-92 05:34:56 dos.h 10056 ----rwed 19-Dec-92 04:47:56 a.out 2276 ----rwed 03-Dec-92 06:38:01 fdtoinline 9608 ----rwed 19-Dec-92 04:47:05 stubs.h 20905 ----rwed Today 20:41:01 dos_lib.fd 5627 ----rwed 14-Mar-91 21:11:38 graphics.h 9474 ----rwed 02-Dec-92 02:02:19 Here is my idea for inline Amiga library calls. I think this is much more memory-friendly than the existing method, because here most of the work is being done by cpp; there is no need for cc1 to keep inline versions of all Amiga library calls in core. The supplied program can generate inline calling stuff in several versions, but there are drawbacks to all of them. I like version #2 best, if the (apparent) code generation bug in gcc wasn't present (tested with gcc 2.2.2). As you see it is rather old already, so many code generation issues are changed and should be looked at again. An unfortunate general problem with this method is the loss of type information. Perhaps some post-processor can be made to modify all #defines to include proper casts for all arguments and (especially) the return values. I must say that the already posted idea of locally defined functions sounds good. Especially that the type information isn't lost there makes it an excellent approach. If only we could specify that an input expression for an __asm() statement should go into a specific register... that would save so much messing about with either moves to get them in place or excessively complex declarations of registers and places to save them... -Olaf. VERSION 1: #defines for expression statements ({...}). #define _LibCalld1a1d0(base, offset, pd1, pa1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved1; register long d1 __asm("d1");\ void savea1; register void *a1 __asm("a1");\ saved1 = d1; d1 = pd1;\ savea1 = a1; a1 = pa1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d1), "g" (a1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a1 = savea1;\ d1 = saved1;\ _res; }) and glue #defines like this: #define InitResident(p0, p1) _LibCalld1a1d0(SysBase, "102", p1, p0) Problem: expression does not save the explicitly indicated registers (this fact is documented in node "Explicit Reg Vars"). Solution: declare some extra variables to do the save/restore manually. Result: bad code when not optimised. Very long macros. Question: Does this still work when the registers really need to be saved and restored? VERSION 2: This changes version 1 to use a single asm statement to load the arguments and indicate them as clobbered. No temporary storage. Works with 2.2.2, but only if the asm statement is marked volatile, even though "memory" is indicated as being clobbered (bug?!). Therefore not subject to optimisation. Note: gcc 2.6.3 apparently always wants to do common subexpression elimination, or something like that, and especially on nested calls makes a mess of it. This makes it quite unusable. VERSION 3: Inline functions like this: static __inline long _LibCalld1a1d0(void *base, long offset, long pd1, void *pa1) { register long _res __asm("d0"); register void *a6 __asm("a6") = base; register long d1 __asm("d1") = pd1; register void *a1 __asm("a1") = pa1; __asm __volatile ("jsr a6@(%c2)" : "=r" (_res) : "a" (a6), "ir" (offset), "d" (d1), "a" (a1) : "a0","a1","d0","d1", "memory"); return _res; } and glue #defines like this: #define InitResident(p0, p1) _LibCalld1a1d0(SysBase, -102, p1, p0) Works, but only useful if you specify optimisation. The inlining and constant propagation is needed to make the offset work. Otherwise, when not inlined, it is put in a spare register (for some reason not directly but with an extra move in between...) SHAR_EOF cat << \SHAR_EOF > fdtoinline.c ; /* gcc fdtoinline.c -o fdtoinline quit */ /* * FDTOINLINE.C * * FDTOINLINE fdfile[s] -o hdrname -s * * Generates an inline #define file for any set of FD files. */ #include #include #include /*#include */ /*#include */ /*#include */ /*#include */ #include #include #include #include #define D0 0x0001 #define D1 0x0002 #define D2 0x0004 #define D3 0x0008 #define D4 0x0010 #define D5 0x0020 #define D6 0x0040 #define D7 0x0080 #define A0 0x0100 #define A1 0x0200 #define A2 0x0400 #define A3 0x0800 #define A4 0x1000 #define A5 0x2000 #define A6 0x4000 #define A7 0x8000 #define VERSION 1 #define STRINGIZE(x) REALLY_STRINGIZE(x) #define REALLY_STRINGIZE(x) # x char banner[] = "/* Generated by FDTOINLINE version " STRINGIZE(VERSION) " by Olaf 'Rhialto' Seibert */\n\n"; #define NAME "_LibCall" void generate(FILE *fo, int mask, int ret) { int i, m; int cnt; #if VERSION < 3 /* #define of elaborate statement expression ({...}) */ /* generate name */ fprintf(fo, "#define " NAME "d"); m = mask; for (i = 0; i <= 7; i++) { if (m & (D0 << i)) putc('0' + i, fo); } fprintf(fo, "a"); for (i = 0; i <= 7; i++) { if (m & (A0 << i)) putc('0' + i, fo); } if (ret >= 0) { fprintf(fo, "d%c", '0' + ret); } /* generate parmlist */ fprintf(fo, "(base, offset"); for (i = 0; i <= 7; i++) { if (m & (D0 << i)) fprintf(fo, ", pd%c", '0' + i); } for (i = 0; i <= 7; i++) { if (m & (A0 << i)) fprintf(fo, ", pa%c", '0' + i); } fprintf(fo, ") ({\\\n"); /* generate vars: result */ if (ret >= 0) { fprintf(fo, "register unsigned long _res __asm(\"d%c\");\\\n", '0'+ret); } #if VERSION == 1 /* assignments in C + call in asm() */ /* generate vars: base */ fprintf(fo, "void *savea6; register void *a6 __asm(\"a6\");\\\n"); /* generate vars: arguments */ for (i = 0; i <= 7; i++) { if (m & (D0 << i)) fprintf(fo, "long saved%d; register long d%d __asm(\"d%d\");\\\n", i, i, i); } for (i = 0; i <= 7; i++) { if (m & (A0 << i)) fprintf(fo, "void *savea%d; register void *a%d __asm(\"a%d\");\\\n", i, i, i); } /* generate save of registers and load of arguments */ for (i = 0; i <= 7; i++) { if (m & (D0 << i)) fprintf(fo, "saved%d = d%d; d%d = pd%d;\\\n", i, i, i, i); } for (i = 0; i <= 7; i++) { if (m & (A0 << i)) fprintf(fo, "savea%d = a%d; a%d = pa%d;\\\n", i, i, i, i); } fprintf(fo, "savea6 = a6; a6 = base;\\\n"); /* generate actual call */ fprintf(fo, "__asm volatile (\"jsr a6@(-\" offset \")\"\\\n" ); fprintf(fo, " : \"=r\" (_res) : \"g\" (a6)" ); /* generate args in asm */ for (i = 0; i <= 7; i++) { if (m & (D0 << i)) fprintf(fo, ", \"g\" (d%c)", '0'+i); } for (i = 0; i <= 7; i++) { if (m & (A0 << i)) fprintf(fo, ", \"g\" (a%c)", '0'+i); } /* generate clobbered registers */ fprintf(fo, "\\\n : \"a0\",\"a1\",\"d0\",\"d1\", \"memory\");\\\n" ); /* generate restore of registers */ fprintf(fo, "a6 = savea6;\\\n"); for (i = 7; i >= 0; i--) { if (m & (A0 << i)) fprintf(fo, "a%d = savea%d;\\\n", i, i, i, i); } for (i = 7; i >= 0; i--) { if (m & (D0 << i)) fprintf(fo, "d%d = saved%d;\\\n", i, i, i, i); } #endif /* VERSION == 1 */ #if VERSION == 2 /* assignments + call all in 1 asm() */ fprintf(fo, "__asm volatile (\""); /* generate loads of arguments */ cnt = 2; for (i = 0; i <= 7; i++) { if (m & (D0 << i)) { fprintf(fo, " movel %%%d,d%c\n", cnt, '0'+i); cnt++; } } for (i = 0; i <= 7; i++) { if (m & (A0 << i)) { fprintf(fo, " movea %%%d,a%c\n", cnt, '0'+i); cnt++; } } /* generate load of base */ fprintf(fo, " movea %%1,a6\n"); /* generate actual call */ fprintf(fo, " jsr a6@(-\" offset \")\"\\\n" ); fprintf(fo, " : \"=r\" (_res) : \"g\" (base)" ); /* generate args in asm */ for (i = 0; i <= 7; i++) { if (m & (D0 << i)) fprintf(fo, ", \"g\" (pd%c)", '0'+i); } for (i = 0; i <= 7; i++) { if (m & (A0 << i)) fprintf(fo, ", \"g\" (pa%c)", '0'+i); } m |= D0 | D1 | A0 | A1 | A6; /* generate clobbered registers */ fprintf(fo, "\\\n : \"memory\"" ); for (i = 0; i <= 7; i++) { if (m & (D0 << i)) fprintf(fo, ", \"d%c\"", '0'+i); } for (i = 0; i <= 7; i++) { if (m & (A0 << i)) fprintf(fo, ", \"a%c\"", '0'+i); } /* finish off */ fprintf(fo, ");\\\n" ); #endif /* VERSION == 2 */ /* deliver result. */ if (ret >= 0) fprintf(fo, "_res; " ); /* finish off */ fprintf(fo, "})\n\n" ); #endif /* VERSION < 3 */ #if VERSION == 3 /* inline function; only works when code is optimised */ /* generate name */ fprintf(fo, "static __inline__ long " NAME "d"); m = mask; for (i = 0; i <= 7; i++) { if (m & (D0 << i)) putc('0' + i, fo); } fprintf(fo, "a"); for (i = 0; i <= 7; i++) { if (m & (A0 << i)) putc('0' + i, fo); } if (ret >= 0) { fprintf(fo, "d%c", '0' + ret); } /* generate parmlist */ fprintf(fo, "(void *base, long offset"); for (i = 0; i <= 7; i++) { if (m & (D0 << i)) fprintf(fo, ", long pd%c", '0' + i); } for (i = 0; i <= 7; i++) { if (m & (A0 << i)) fprintf(fo, ", void *pa%c", '0' + i); } fprintf(fo, ") {\n"); /* generate vars: result */ if (ret >= 0) { fprintf(fo, "register long _res __asm(\"d%c\");\n", '0'+ret); } /* generate vars: base */ fprintf(fo, "register void *a6 __asm(\"a6\") = base;\n"); /* generate vars: arguments */ for (i = 0; i <= 7; i++) { if (m & (D0 << i)) fprintf(fo, "register long d%c __asm(\"d%c\") = pd%c;\n", '0'+i, '0'+i, '0'+i); } for (i = 0; i <= 7; i++) { if (m & (A0 << i)) fprintf(fo, "register void *a%c __asm(\"a%c\") = pa%c;\n", '0'+i, '0'+i, '0'+i); } /* generate actual call */ fprintf(fo, "__asm volatile (\"jsr a6@(%%c2)\"\n" ); fprintf(fo, " : \"=r\" (_res) : \"g\" (a6), \"ir\" (offset)" ); /* generate args in asm */ for (i = 0; i <= 7; i++) { if (m & (D0 << i)) fprintf(fo, ", \"g\" (d%c)", '0'+i); } for (i = 0; i <= 7; i++) { if (m & (A0 << i)) fprintf(fo, ", \"g\" (a%c)", '0'+i); } /* generate clobbered registers */ fprintf(fo, "\n : \"a0\",\"a1\",\"d0\",\"d1\", \"memory\");\n" ); /* finish off */ fprintf(fo, "return _res;\n}\n" ); #endif /* VERSION == 3 */ } void genstubs(FILE *fo) { fprintf(fo, "#ifndef INLINE_STUBS_H\n#define INLINE_STUBS_H\n\n"); fprintf(fo, banner); generate(fo, 0, 0); generate(fo, A5, 0); generate(fo, A1 , 0); generate(fo, A0 , 0); generate(fo, A0|A1 , 0); generate(fo, A0|A1|A2 , 0); generate(fo, A0|A1|A2|A3 , 0); generate(fo, D7 , 0); generate(fo, D1 , 0); generate(fo, D1 | A1 , 0); generate(fo, D1|D2 , 0); generate(fo, D1|D2|D3 , 0); generate(fo, D1|D2|D3|D4 , 0); generate(fo, D1|D2|D3|D4|D5 , 0); generate(fo, D0 , 0); generate(fo, D0 | A1 , 0); generate(fo, D0 | A0 , 0); generate(fo, D0 | A0|A1 , 0); generate(fo, D0 | A0|A1|A2 , 0); generate(fo, D0|D1 , 0); generate(fo, D0|D1 | A0 , 0); generate(fo, D0|D1 | A0|A1 , 0); generate(fo, D0|D1|D2 , 0); generate(fo, D0|D1|D2|D3 | A1 , 0); generate(fo, D0|D1|D2|D3 | A0|A1 , 0); generate(fo, D0|D1|D2|D3|D4 | A0|A1|A2 , 0); generate(fo, D0|D1|D2|D3|D4 | A0|A1|A2|A3 , 0); generate(fo, D0|D1|D2|D3|D4|D5 | A0|A1 , 0); generate(fo, D0|D1|D2|D3|D4|D5|D6 | A0|A1 , 0); generate(fo, D0|D1|D2|D3|D4|D5|D6|D7 | A0|A1|A2 , 0); fprintf(fo, "/* This one is only for educational purposes: */\n\n"); generate(fo, D0|D1|D2|D3|D4|D5 | A0|A1|A2|A3|A4|A5, 0); fprintf(fo, "#endif\n"); } inline void NewList(struct List *l) { l->lh_Head = (struct Node *)&l->lh_Tail; l->lh_Tail = NULL; l->lh_TailPred = (struct Node *)&l->lh_Head; } typedef struct MinList List; typedef struct Node Node; void help(int); void ScanFD(FILE *, FILE *); void GenerateFunction(FILE *, char *, char *, int); List FDList; /* list of FD files */ char *OutFile; char Buf[256]; short Verbose; main(ac, av) int ac; char **av; { int i; int DoStubs = 0; NewList((struct List *)&FDList); for (i = 1; i < ac; ++i) { char *ptr = av[i]; if (*ptr != '-') { Node *node = malloc(sizeof(Node)); node->ln_Name = ptr; AddTail(&FDList, node); continue; } ptr += 2; switch(ptr[-1]) { case 'o': OutFile = (*ptr) ? ptr : av[++i]; break; case 'v': ++Verbose; break; case 's': ++DoStubs; break; default: help(1); } } if (OutFile == NULL && DoStubs == 0) help(ac != 1); /* * step 1: make generic stubs */ if (DoStubs) { FILE *fo = fopen("stubs.h", "w"); if (fo) { genstubs(fo); fclose(fo); } } /* * step 2 */ if (OutFile) { FILE *fi; FILE *fo = fopen(OutFile, "w"); Node *node; Node *RemHead(List *); if (fo == NULL) { printf("Error, Unable to create %s\n", OutFile); exit(20); } while (node = RemHead(&FDList)) { printf("generate %s", node->ln_Name); fi = fopen(node->ln_Name, "r"); if (fi) { puts(""); ScanFD(fi, fo); fclose(fi); } else { puts(" (open failed)"); } } } return(0); } void help(code) { puts("FDTOINLINE fdfiles/wildcard -o hdrname -s"); puts(" -s to generate 'stubs.h' file"); exit(code); } void ScanFD(fi, fo) FILE *fi; FILE *fo; { char *base = NULL; long bias = -1; short end = 0; short public = 1; char *key; char *protect; protect = strdup(OutFile); { char *p = protect; while (*p && *p != '_' && *p != '.') { if (islower(*p)) *p = toupper(*p); p++; } *p = 0; } fprintf(fo, "#ifndef INLINE_%s_H\n#define INLINE_%s_H\n\n", protect, protect); free(protect); fprintf(fo, banner); fprintf(fo, "#ifndef INLINE_STUBS_H\n#include \"inline/stubs.h\"\n#endif\n\n"); while (fgets(Buf, sizeof(Buf), fi)) { if (Buf[0] == '\n' || Buf[0] == '*') continue; if (strncmp(Buf, "##", 2) != 0) { if (bias < 0 || base == NULL) { printf("Error, No ##base/##bias before function: %s\n", Buf); continue; } if (public) GenerateFunction(fo, Buf, base, bias); bias += 6; continue; } if ((key = strtok(Buf + 2, " \t\n")) == NULL) { printf("\tError, Illegal null directive\n"); continue; } if (stricmp(key, "base") == 0) { if (key = strtok(NULL, " \t\n")) { if (key[0] == '_') key++; if (base) free(base); base = strdup(key); } else { printf("\tError, Illegal ##base directive\n"); } continue; } if (stricmp(key, "bias") == 0) { if (key = strtok(NULL, " \t\n")) { char *dummy; bias = strtol(key, &dummy, 0); if (bias <= 0) printf("\tError, Illegal ##bias: %d\n", bias); } else { printf("\tError, Illegal ##bias directive\n"); } continue; } if (stricmp(key, "public") == 0) { public = 1; continue; } if (stricmp(key, "private") == 0) { public = 0; continue; } if (stricmp(key, "end") == 0) { end = 1; break; } printf("\tError, Unrecognized directive: %s\n", key); } if (bias < 0) puts("\tUnexpected EOF, no ##bias"); if (base == NULL) puts("\tUnexpected EOF, no ##base"); if (end == 0) puts("\tUnexpected EOF, no ##end directive"); fprintf(fo, "\n#endif\n"); } /* * funcname(var,var,var)(reg,reg,reg) (or reg/reg) */ static short FRegs[16]; static char hex[] = "0123456789abcdefgh"; void GenerateFunction(fo, buf, base, bias) FILE *fo; char *buf; char *base; int bias; { char *funcName; short argCnt; short noArgs = 0; short i; funcName = buf; while (*funcName && *funcName != '\t' && *funcName != ' ' && *funcName != '(') ++funcName; if (*funcName == ' ' || *funcName == '\t') { while (*funcName && *funcName != '(') *funcName++ = 0; } if (*funcName == '(') { *funcName++ = 0; if (*funcName == ')') noArgs = 1; } while (*funcName && *funcName != ')') /* skip text args */ ++funcName; while (*funcName && *funcName != '(') ++funcName; if (noArgs == 0 && *funcName == 0) { printf("\tError in line: %s\n", buf); return; } /* * get register description */ for (i = 0;i <= 15; i++) { FRegs[i] = -1; } if (*funcName) ++funcName; for (argCnt = 0; *funcName && *funcName != '\n' && *funcName != ')'; ++argCnt) { switch(*funcName) { case 'd': case 'D': FRegs[*++funcName - '0'] = argCnt; ++funcName; break; case 'a': case 'A': FRegs[*++funcName - '0' + 8] = argCnt; ++funcName; break; default: printf("\tError in register spec: %s\n", funcName); return; } if (*funcName == ',' || *funcName == '/') ++funcName; } if (noArgs == 0 && *funcName != ')') { printf("\tError in register spec: %s\n", funcName); return; } /* * generate */ funcName = strdup(buf); { int cnt; if (Verbose) printf(" %-15s %d %d\n", funcName, -bias, argCnt); /* generate #define */ fprintf(fo, "#define %s(", funcName); /* generate parameters */ for (cnt = 0, i = 0; i <= 15; i++) { if (FRegs[i] >= 0) { if (cnt) fprintf(fo, ", "); fprintf(fo, "p%c", hex[cnt]); cnt++; } } /* generate calling macro name */ fprintf(fo, ")\t" NAME "d"); for (i = 0; i <= 7; i++) { if (FRegs[i] >= 0) { fprintf(fo, "%c", '0'+i); } } fprintf(fo, "a"); for (i = 8; i <= 15; i++) { if (FRegs[i] >= 0) { fprintf(fo, "%c", '0'+i-8); } } #if VERSION == 3 fprintf(fo, "d0(%s, %d", base, -bias); #else fprintf(fo, "d0(%s, \"%d\"", base, bias); #endif /* permute parameters to arguments */ for (i = 0; i <= 15; i++) { if (FRegs[i] >= 0) { fprintf(fo, ", p%c", hex[FRegs[i]]); cnt++; } } /* finish off */ fprintf(fo, ")\n"); if (Verbose) fflush(stdout); } } SHAR_EOF cat << \SHAR_EOF > c.c extern void *const DOSBase; extern void *const SysBase; #include "exec.h" #include "dos.h" main(int i) { return LockRecord(LockRecord(21,22,23,24,25), LockRecord(31,32,33,34,35), LockRecord(LockRecord(1,2,3,4,5), 12,13,14,15), 54, 55); } SHAR_EOF cat << \SHAR_EOF > stubs.h #ifndef INLINE_STUBS_H #define INLINE_STUBS_H /* Generated by FDTOINLINE version 1 by Olaf 'Rhialto' Seibert */ #define _LibCalldad0(base, offset) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ _res; }) #define _LibCallda5d0(base, offset, pa5) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ void *savea5; register void *a5 __asm("a5");\ savea5 = a5; a5 = pa5;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (a5)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a5 = savea5;\ _res; }) #define _LibCallda1d0(base, offset, pa1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ void *savea1; register void *a1 __asm("a1");\ savea1 = a1; a1 = pa1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (a1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a1 = savea1;\ _res; }) #define _LibCallda0d0(base, offset, pa0) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ void *savea0; register void *a0 __asm("a0");\ savea0 = a0; a0 = pa0;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (a0)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a0 = savea0;\ _res; }) #define _LibCallda01d0(base, offset, pa0, pa1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (a0), "g" (a1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a1 = savea1;\ a0 = savea0;\ _res; }) #define _LibCallda012d0(base, offset, pa0, pa1, pa2) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ void *savea2; register void *a2 __asm("a2");\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea2 = a2; a2 = pa2;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (a0), "g" (a1), "g" (a2)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a2 = savea2;\ a1 = savea1;\ a0 = savea0;\ _res; }) #define _LibCallda0123d0(base, offset, pa0, pa1, pa2, pa3) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ void *savea2; register void *a2 __asm("a2");\ void *savea3; register void *a3 __asm("a3");\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea2 = a2; a2 = pa2;\ savea3 = a3; a3 = pa3;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (a0), "g" (a1), "g" (a2), "g" (a3)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a3 = savea3;\ a2 = savea2;\ a1 = savea1;\ a0 = savea0;\ _res; }) #define _LibCalld7ad0(base, offset, pd7) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved7; register long d7 __asm("d7");\ saved7 = d7; d7 = pd7;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d7)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ d7 = saved7;\ _res; }) #define _LibCalld1ad0(base, offset, pd1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved1; register long d1 __asm("d1");\ saved1 = d1; d1 = pd1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ d1 = saved1;\ _res; }) #define _LibCalld1a1d0(base, offset, pd1, pa1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved1; register long d1 __asm("d1");\ void *savea1; register void *a1 __asm("a1");\ saved1 = d1; d1 = pd1;\ savea1 = a1; a1 = pa1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d1), "g" (a1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a1 = savea1;\ d1 = saved1;\ _res; }) #define _LibCalld12ad0(base, offset, pd1, pd2) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d1), "g" (d2)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ d2 = saved2;\ d1 = saved1;\ _res; }) #define _LibCalld123ad0(base, offset, pd1, pd2, pd3) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ long saved3; register long d3 __asm("d3");\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ saved3 = d3; d3 = pd3;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d1), "g" (d2), "g" (d3)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ d3 = saved3;\ d2 = saved2;\ d1 = saved1;\ _res; }) #define _LibCalld1234ad0(base, offset, pd1, pd2, pd3, pd4) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ long saved3; register long d3 __asm("d3");\ long saved4; register long d4 __asm("d4");\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ saved3 = d3; d3 = pd3;\ saved4 = d4; d4 = pd4;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d1), "g" (d2), "g" (d3), "g" (d4)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ d4 = saved4;\ d3 = saved3;\ d2 = saved2;\ d1 = saved1;\ _res; }) #define _LibCalld12345ad0(base, offset, pd1, pd2, pd3, pd4, pd5) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ long saved3; register long d3 __asm("d3");\ long saved4; register long d4 __asm("d4");\ long saved5; register long d5 __asm("d5");\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ saved3 = d3; d3 = pd3;\ saved4 = d4; d4 = pd4;\ saved5 = d5; d5 = pd5;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d1), "g" (d2), "g" (d3), "g" (d4), "g" (d5)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ d5 = saved5;\ d4 = saved4;\ d3 = saved3;\ d2 = saved2;\ d1 = saved1;\ _res; }) #define _LibCalld0ad0(base, offset, pd0) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ saved0 = d0; d0 = pd0;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ d0 = saved0;\ _res; }) #define _LibCalld0a1d0(base, offset, pd0, pa1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ void *savea1; register void *a1 __asm("a1");\ saved0 = d0; d0 = pd0;\ savea1 = a1; a1 = pa1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (a1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a1 = savea1;\ d0 = saved0;\ _res; }) #define _LibCalld0a0d0(base, offset, pd0, pa0) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ void *savea0; register void *a0 __asm("a0");\ saved0 = d0; d0 = pd0;\ savea0 = a0; a0 = pa0;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (a0)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a0 = savea0;\ d0 = saved0;\ _res; }) #define _LibCalld0a01d0(base, offset, pd0, pa0, pa1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ saved0 = d0; d0 = pd0;\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (a0), "g" (a1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a1 = savea1;\ a0 = savea0;\ d0 = saved0;\ _res; }) #define _LibCalld0a012d0(base, offset, pd0, pa0, pa1, pa2) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ void *savea2; register void *a2 __asm("a2");\ saved0 = d0; d0 = pd0;\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea2 = a2; a2 = pa2;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (a0), "g" (a1), "g" (a2)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a2 = savea2;\ a1 = savea1;\ a0 = savea0;\ d0 = saved0;\ _res; }) #define _LibCalld01ad0(base, offset, pd0, pd1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ long saved1; register long d1 __asm("d1");\ saved0 = d0; d0 = pd0;\ saved1 = d1; d1 = pd1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (d1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ d1 = saved1;\ d0 = saved0;\ _res; }) #define _LibCalld01a0d0(base, offset, pd0, pd1, pa0) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ long saved1; register long d1 __asm("d1");\ void *savea0; register void *a0 __asm("a0");\ saved0 = d0; d0 = pd0;\ saved1 = d1; d1 = pd1;\ savea0 = a0; a0 = pa0;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (d1), "g" (a0)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a0 = savea0;\ d1 = saved1;\ d0 = saved0;\ _res; }) #define _LibCalld01a01d0(base, offset, pd0, pd1, pa0, pa1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ long saved1; register long d1 __asm("d1");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ saved0 = d0; d0 = pd0;\ saved1 = d1; d1 = pd1;\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (d1), "g" (a0), "g" (a1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a1 = savea1;\ a0 = savea0;\ d1 = saved1;\ d0 = saved0;\ _res; }) #define _LibCalld012ad0(base, offset, pd0, pd1, pd2) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ saved0 = d0; d0 = pd0;\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (d1), "g" (d2)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ d2 = saved2;\ d1 = saved1;\ d0 = saved0;\ _res; }) #define _LibCalld0123a1d0(base, offset, pd0, pd1, pd2, pd3, pa1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ long saved3; register long d3 __asm("d3");\ void *savea1; register void *a1 __asm("a1");\ saved0 = d0; d0 = pd0;\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ saved3 = d3; d3 = pd3;\ savea1 = a1; a1 = pa1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (d1), "g" (d2), "g" (d3), "g" (a1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a1 = savea1;\ d3 = saved3;\ d2 = saved2;\ d1 = saved1;\ d0 = saved0;\ _res; }) #define _LibCalld0123a01d0(base, offset, pd0, pd1, pd2, pd3, pa0, pa1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ long saved3; register long d3 __asm("d3");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ saved0 = d0; d0 = pd0;\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ saved3 = d3; d3 = pd3;\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (d1), "g" (d2), "g" (d3), "g" (a0), "g" (a1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a1 = savea1;\ a0 = savea0;\ d3 = saved3;\ d2 = saved2;\ d1 = saved1;\ d0 = saved0;\ _res; }) #define _LibCalld01234a012d0(base, offset, pd0, pd1, pd2, pd3, pd4, pa0, pa1, pa2) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ long saved3; register long d3 __asm("d3");\ long saved4; register long d4 __asm("d4");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ void *savea2; register void *a2 __asm("a2");\ saved0 = d0; d0 = pd0;\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ saved3 = d3; d3 = pd3;\ saved4 = d4; d4 = pd4;\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea2 = a2; a2 = pa2;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (d1), "g" (d2), "g" (d3), "g" (d4), "g" (a0), "g" (a1), "g" (a2)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a2 = savea2;\ a1 = savea1;\ a0 = savea0;\ d4 = saved4;\ d3 = saved3;\ d2 = saved2;\ d1 = saved1;\ d0 = saved0;\ _res; }) #define _LibCalld01234a0123d0(base, offset, pd0, pd1, pd2, pd3, pd4, pa0, pa1, pa2, pa3) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ long saved3; register long d3 __asm("d3");\ long saved4; register long d4 __asm("d4");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ void *savea2; register void *a2 __asm("a2");\ void *savea3; register void *a3 __asm("a3");\ saved0 = d0; d0 = pd0;\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ saved3 = d3; d3 = pd3;\ saved4 = d4; d4 = pd4;\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea2 = a2; a2 = pa2;\ savea3 = a3; a3 = pa3;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (d1), "g" (d2), "g" (d3), "g" (d4), "g" (a0), "g" (a1), "g" (a2), "g" (a3)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a3 = savea3;\ a2 = savea2;\ a1 = savea1;\ a0 = savea0;\ d4 = saved4;\ d3 = saved3;\ d2 = saved2;\ d1 = saved1;\ d0 = saved0;\ _res; }) #define _LibCalld012345a01d0(base, offset, pd0, pd1, pd2, pd3, pd4, pd5, pa0, pa1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ long saved3; register long d3 __asm("d3");\ long saved4; register long d4 __asm("d4");\ long saved5; register long d5 __asm("d5");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ saved0 = d0; d0 = pd0;\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ saved3 = d3; d3 = pd3;\ saved4 = d4; d4 = pd4;\ saved5 = d5; d5 = pd5;\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (d1), "g" (d2), "g" (d3), "g" (d4), "g" (d5), "g" (a0), "g" (a1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a1 = savea1;\ a0 = savea0;\ d5 = saved5;\ d4 = saved4;\ d3 = saved3;\ d2 = saved2;\ d1 = saved1;\ d0 = saved0;\ _res; }) #define _LibCalld0123456a01d0(base, offset, pd0, pd1, pd2, pd3, pd4, pd5, pd6, pa0, pa1) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ long saved3; register long d3 __asm("d3");\ long saved4; register long d4 __asm("d4");\ long saved5; register long d5 __asm("d5");\ long saved6; register long d6 __asm("d6");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ saved0 = d0; d0 = pd0;\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ saved3 = d3; d3 = pd3;\ saved4 = d4; d4 = pd4;\ saved5 = d5; d5 = pd5;\ saved6 = d6; d6 = pd6;\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (d1), "g" (d2), "g" (d3), "g" (d4), "g" (d5), "g" (d6), "g" (a0), "g" (a1)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a1 = savea1;\ a0 = savea0;\ d6 = saved6;\ d5 = saved5;\ d4 = saved4;\ d3 = saved3;\ d2 = saved2;\ d1 = saved1;\ d0 = saved0;\ _res; }) #define _LibCalld01234567a012d0(base, offset, pd0, pd1, pd2, pd3, pd4, pd5, pd6, pd7, pa0, pa1, pa2) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ long saved3; register long d3 __asm("d3");\ long saved4; register long d4 __asm("d4");\ long saved5; register long d5 __asm("d5");\ long saved6; register long d6 __asm("d6");\ long saved7; register long d7 __asm("d7");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ void *savea2; register void *a2 __asm("a2");\ saved0 = d0; d0 = pd0;\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ saved3 = d3; d3 = pd3;\ saved4 = d4; d4 = pd4;\ saved5 = d5; d5 = pd5;\ saved6 = d6; d6 = pd6;\ saved7 = d7; d7 = pd7;\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea2 = a2; a2 = pa2;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (d1), "g" (d2), "g" (d3), "g" (d4), "g" (d5), "g" (d6), "g" (d7), "g" (a0), "g" (a1), "g" (a2)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a2 = savea2;\ a1 = savea1;\ a0 = savea0;\ d7 = saved7;\ d6 = saved6;\ d5 = saved5;\ d4 = saved4;\ d3 = saved3;\ d2 = saved2;\ d1 = saved1;\ d0 = saved0;\ _res; }) /* This one is only for educational purposes: */ #define _LibCalld012345a012345d0(base, offset, pd0, pd1, pd2, pd3, pd4, pd5, pa0, pa1, pa2, pa3, pa4, pa5) ({\ register unsigned long _res __asm("d0");\ void *savea6; register void *a6 __asm("a6");\ long saved0; register long d0 __asm("d0");\ long saved1; register long d1 __asm("d1");\ long saved2; register long d2 __asm("d2");\ long saved3; register long d3 __asm("d3");\ long saved4; register long d4 __asm("d4");\ long saved5; register long d5 __asm("d5");\ void *savea0; register void *a0 __asm("a0");\ void *savea1; register void *a1 __asm("a1");\ void *savea2; register void *a2 __asm("a2");\ void *savea3; register void *a3 __asm("a3");\ void *savea4; register void *a4 __asm("a4");\ void *savea5; register void *a5 __asm("a5");\ saved0 = d0; d0 = pd0;\ saved1 = d1; d1 = pd1;\ saved2 = d2; d2 = pd2;\ saved3 = d3; d3 = pd3;\ saved4 = d4; d4 = pd4;\ saved5 = d5; d5 = pd5;\ savea0 = a0; a0 = pa0;\ savea1 = a1; a1 = pa1;\ savea2 = a2; a2 = pa2;\ savea3 = a3; a3 = pa3;\ savea4 = a4; a4 = pa4;\ savea5 = a5; a5 = pa5;\ savea6 = a6; a6 = base;\ __asm volatile ("jsr a6@(-" offset ")"\ : "=r" (_res) : "g" (a6), "g" (d0), "g" (d1), "g" (d2), "g" (d3), "g" (d4), "g" (d5), "g" (a0), "g" (a1), "g" (a2), "g" (a3), "g" (a4), "g" (a5)\ : "a0","a1","d0","d1", "memory");\ a6 = savea6;\ a5 = savea5;\ a4 = savea4;\ a3 = savea3;\ a2 = savea2;\ a1 = savea1;\ a0 = savea0;\ d5 = saved5;\ d4 = saved4;\ d3 = saved3;\ d2 = saved2;\ d1 = saved1;\ d0 = saved0;\ _res; }) #endif SHAR_EOF cat << \SHAR_EOF > dos.h #ifndef INLINE_DOS_H #define INLINE_DOS_H /* Generated by FDTOINLINE version 1 by Olaf 'Rhialto' Seibert */ #ifndef INLINE_STUBS_H #include "inline/stubs.h" #endif #define Open(p0, p1) _LibCalld12ad0(DOSBase, "30", p0, p1) #define Close(p0) _LibCalld1ad0(DOSBase, "36", p0) #define Read(p0, p1, p2) _LibCalld123ad0(DOSBase, "42", p0, p1, p2) #define Write(p0, p1, p2) _LibCalld123ad0(DOSBase, "48", p0, p1, p2) #define Input() _LibCalldad0(DOSBase, "54") #define Output() _LibCalldad0(DOSBase, "60") #define Seek(p0, p1, p2) _LibCalld123ad0(DOSBase, "66", p0, p1, p2) #define DeleteFile(p0) _LibCalld1ad0(DOSBase, "72", p0) #define Rename(p0, p1) _LibCalld12ad0(DOSBase, "78", p0, p1) #define Lock(p0, p1) _LibCalld12ad0(DOSBase, "84", p0, p1) #define UnLock(p0) _LibCalld1ad0(DOSBase, "90", p0) #define DupLock(p0) _LibCalld1ad0(DOSBase, "96", p0) #define Examine(p0, p1) _LibCalld12ad0(DOSBase, "102", p0, p1) #define ExNext(p0, p1) _LibCalld12ad0(DOSBase, "108", p0, p1) #define Info(p0, p1) _LibCalld12ad0(DOSBase, "114", p0, p1) #define CreateDir(p0) _LibCalld1ad0(DOSBase, "120", p0) #define CurrentDir(p0) _LibCalld1ad0(DOSBase, "126", p0) #define IoErr() _LibCalldad0(DOSBase, "132") #define CreateProc(p0, p1, p2, p3) _LibCalld1234ad0(DOSBase, "138", p0, p1, p2, p3) #define Exit(p0) _LibCalld1ad0(DOSBase, "144", p0) #define LoadSeg(p0) _LibCalld1ad0(DOSBase, "150", p0) #define UnLoadSeg(p0) _LibCalld1ad0(DOSBase, "156", p0) #define DeviceProc(p0) _LibCalld1ad0(DOSBase, "174", p0) #define SetComment(p0, p1) _LibCalld12ad0(DOSBase, "180", p0, p1) #define SetProtection(p0, p1) _LibCalld12ad0(DOSBase, "186", p0, p1) #define DateStamp(p0) _LibCalld1ad0(DOSBase, "192", p0) #define Delay(p0) _LibCalld1ad0(DOSBase, "198", p0) #define WaitForChar(p0, p1) _LibCalld12ad0(DOSBase, "204", p0, p1) #define ParentDir(p0) _LibCalld1ad0(DOSBase, "210", p0) #define IsInteractive(p0) _LibCalld1ad0(DOSBase, "216", p0) #define Execute(p0, p1, p2) _LibCalld123ad0(DOSBase, "222", p0, p1, p2) #define AllocDosObject(p0, p1) _LibCalld12ad0(DOSBase, "228", p0, p1) #define FreeDosObject(p0, p1) _LibCalld12ad0(DOSBase, "234", p0, p1) #define DoPkt(p0, p1, p2, p3, p4, p5, p6) _LibCalld1234567ad0(DOSBase, "240", p0, p1, p2, p3, p4, p5, p6) #define SendPkt(p0, p1, p2) _LibCalld123ad0(DOSBase, "246", p0, p1, p2) #define WaitPkt() _LibCalldad0(DOSBase, "252") #define ReplyPkt(p0, p1, p2) _LibCalld123ad0(DOSBase, "258", p0, p1, p2) #define AbortPkt(p0, p1) _LibCalld12ad0(DOSBase, "264", p0, p1) #define LockRecord(p0, p1, p2, p3, p4) _LibCalld12345ad0(DOSBase, "270", p0, p1, p2, p3, p4) #define LockRecords(p0, p1) _LibCalld12ad0(DOSBase, "276", p0, p1) #define UnLockRecord(p0, p1, p2) _LibCalld123ad0(DOSBase, "282", p0, p1, p2) #define UnLockRecords(p0) _LibCalld1ad0(DOSBase, "288", p0) #define SelectInput(p0) _LibCalld1ad0(DOSBase, "294", p0) #define SelectOutput(p0) _LibCalld1ad0(DOSBase, "300", p0) #define FGetC(p0) _LibCalld1ad0(DOSBase, "306", p0) #define FPutC(p0, p1) _LibCalld12ad0(DOSBase, "312", p0, p1) #define UnGetC(p0, p1) _LibCalld12ad0(DOSBase, "318", p0, p1) #define FRead(p0, p1, p2, p3) _LibCalld1234ad0(DOSBase, "324", p0, p1, p2, p3) #define FWrite(p0, p1, p2, p3) _LibCalld1234ad0(DOSBase, "330", p0, p1, p2, p3) #define FGets(p0, p1, p2) _LibCalld123ad0(DOSBase, "336", p0, p1, p2) #define FPuts(p0, p1) _LibCalld12ad0(DOSBase, "342", p0, p1) #define VFWritef(p0, p1, p2) _LibCalld123ad0(DOSBase, "348", p0, p1, p2) #define VFPrintf(p0, p1, p2) _LibCalld123ad0(DOSBase, "354", p0, p1, p2) #define Flush(p0) _LibCalld1ad0(DOSBase, "360", p0) #define SetVBuf(p0, p1, p2, p3) _LibCalld1234ad0(DOSBase, "366", p0, p1, p2, p3) #define DupLockFromFH(p0) _LibCalld1ad0(DOSBase, "372", p0) #define OpenFromLock(p0) _LibCalld1ad0(DOSBase, "378", p0) #define ParentOfFH(p0) _LibCalld1ad0(DOSBase, "384", p0) #define ExamineFH(p0, p1) _LibCalld12ad0(DOSBase, "390", p0, p1) #define SetFileDate(p0, p1) _LibCalld12ad0(DOSBase, "396", p0, p1) #define NameFromLock(p0, p1, p2) _LibCalld123ad0(DOSBase, "402", p0, p1, p2) #define NameFromFH(p0, p1, p2) _LibCalld123ad0(DOSBase, "408", p0, p1, p2) #define SplitName(p0, p1, p2, p3, p4) _LibCalld12345ad0(DOSBase, "414", p0, p1, p2, p3, p4) #define SameLock(p0, p1) _LibCalld12ad0(DOSBase, "420", p0, p1) #define SetMode(p0, p1) _LibCalld12ad0(DOSBase, "426", p0, p1) #define ExAll(p0, p1, p2, p3, p4) _LibCalld12345ad0(DOSBase, "432", p0, p1, p2, p3, p4) #define ReadLink(p0, p1, p2, p3, p4) _LibCalld12345ad0(DOSBase, "438", p0, p1, p2, p3, p4) #define MakeLink(p0, p1, p2) _LibCalld123ad0(DOSBase, "444", p0, p1, p2) #define ChangeMode(p0, p1, p2) _LibCalld123ad0(DOSBase, "450", p0, p1, p2) #define SetFileSize(p0, p1, p2) _LibCalld123ad0(DOSBase, "456", p0, p1, p2) #define SetIoErr(p0) _LibCalld1ad0(DOSBase, "462", p0) #define Fault(p0, p1, p2, p3) _LibCalld1234ad0(DOSBase, "468", p0, p1, p2, p3) #define PrintFault(p0, p1) _LibCalld12ad0(DOSBase, "474", p0, p1) #define ErrorReport(p0, p1, p2, p3) _LibCalld1234ad0(DOSBase, "480", p0, p1, p2, p3) #define Cli() _LibCalldad0(DOSBase, "492") #define CreateNewProc(p0) _LibCalld1ad0(DOSBase, "498", p0) #define RunCommand(p0, p1, p2, p3) _LibCalld1234ad0(DOSBase, "504", p0, p1, p2, p3) #define GetConsoleTask() _LibCalldad0(DOSBase, "510") #define SetConsoleTask(p0) _LibCalld1ad0(DOSBase, "516", p0) #define GetFileSysTask() _LibCalldad0(DOSBase, "522") #define SetFileSysTask(p0) _LibCalld1ad0(DOSBase, "528", p0) #define GetArgStr() _LibCalldad0(DOSBase, "534") #define SetArgStr(p0) _LibCalld1ad0(DOSBase, "540", p0) #define FindCliProc(p0) _LibCalld1ad0(DOSBase, "546", p0) #define MaxCli() _LibCalldad0(DOSBase, "552") #define SetCurrentDirName(p0) _LibCalld1ad0(DOSBase, "558", p0) #define GetCurrentDirName(p0, p1) _LibCalld12ad0(DOSBase, "564", p0, p1) #define SetProgramName(p0) _LibCalld1ad0(DOSBase, "570", p0) #define GetProgramName(p0, p1) _LibCalld12ad0(DOSBase, "576", p0, p1) #define SetPrompt(p0) _LibCalld1ad0(DOSBase, "582", p0) #define GetPrompt(p0, p1) _LibCalld12ad0(DOSBase, "588", p0, p1) #define SetProgramDir(p0) _LibCalld1ad0(DOSBase, "594", p0) #define GetProgramDir() _LibCalldad0(DOSBase, "600") #define SystemTagList(p0, p1) _LibCalld12ad0(DOSBase, "606", p0, p1) #define AssignLock(p0, p1) _LibCalld12ad0(DOSBase, "612", p0, p1) #define AssignLate(p0, p1) _LibCalld12ad0(DOSBase, "618", p0, p1) #define AssignPath(p0, p1) _LibCalld12ad0(DOSBase, "624", p0, p1) #define AssignAdd(p0, p1) _LibCalld12ad0(DOSBase, "630", p0, p1) #define RemAssignList(p0, p1) _LibCalld12ad0(DOSBase, "636", p0, p1) #define GetDeviceProc(p0, p1) _LibCalld12ad0(DOSBase, "642", p0, p1) #define FreeDeviceProc(p0) _LibCalld1ad0(DOSBase, "648", p0) #define LockDosList(p0) _LibCalld1ad0(DOSBase, "654", p0) #define UnLockDosList(p0) _LibCalld1ad0(DOSBase, "660", p0) #define AttemptLockDosList(p0) _LibCalld1ad0(DOSBase, "666", p0) #define RemDosEntry(p0) _LibCalld1ad0(DOSBase, "672", p0) #define AddDosEntry(p0) _LibCalld1ad0(DOSBase, "678", p0) #define FindDosEntry(p0, p1, p2) _LibCalld123ad0(DOSBase, "684", p0, p1, p2) #define NextDosEntry(p0, p1) _LibCalld12ad0(DOSBase, "690", p0, p1) #define MakeDosEntry(p0, p1) _LibCalld12ad0(DOSBase, "696", p0, p1) #define FreeDosEntry(p0) _LibCalld1ad0(DOSBase, "702", p0) #define IsFileSystem(p0) _LibCalld1ad0(DOSBase, "708", p0) #define Format(p0, p1, p2) _LibCalld123ad0(DOSBase, "714", p0, p1, p2) #define Relabel(p0, p1) _LibCalld12ad0(DOSBase, "720", p0, p1) #define Inhibit(p0, p1) _LibCalld12ad0(DOSBase, "726", p0, p1) #define AddBuffers(p0, p1) _LibCalld12ad0(DOSBase, "732", p0, p1) #define CompareDates(p0, p1) _LibCalld12ad0(DOSBase, "738", p0, p1) #define DateToStr(p0) _LibCalld1ad0(DOSBase, "744", p0) #define StrToDate(p0) _LibCalld1ad0(DOSBase, "750", p0) #define InternalLoadSeg(p0, p1, p2, p3) _LibCalld0a012d0(DOSBase, "756", p0, p1, p2, p3) #define InternalUnLoadSeg(p0, p1) _LibCalld1a1d0(DOSBase, "762", p0, p1) #define NewLoadSeg(p0, p1) _LibCalld12ad0(DOSBase, "768", p0, p1) #define AddSegment(p0, p1, p2) _LibCalld123ad0(DOSBase, "774", p0, p1, p2) #define FindSegment(p0, p1, p2) _LibCalld123ad0(DOSBase, "780", p0, p1, p2) #define RemSegment(p0) _LibCalld1ad0(DOSBase, "786", p0) #define CheckSignal(p0) _LibCalld1ad0(DOSBase, "792", p0) #define ReadArgs(p0, p1, p2) _LibCalld123ad0(DOSBase, "798", p0, p1, p2) #define FindArg(p0, p1) _LibCalld12ad0(DOSBase, "804", p0, p1) #define ReadItem(p0, p1, p2) _LibCalld123ad0(DOSBase, "810", p0, p1, p2) #define StrToLong(p0, p1) _LibCalld12ad0(DOSBase, "816", p0, p1) #define MatchFirst(p0, p1) _LibCalld12ad0(DOSBase, "822", p0, p1) #define MatchNext(p0) _LibCalld1ad0(DOSBase, "828", p0) #define MatchEnd(p0) _LibCalld1ad0(DOSBase, "834", p0) #define ParsePattern(p0, p1, p2) _LibCalld123ad0(DOSBase, "840", p0, p1, p2) #define MatchPattern(p0, p1) _LibCalld12ad0(DOSBase, "846", p0, p1) #define FreeArgs(p0) _LibCalld1ad0(DOSBase, "858", p0) #define FilePart(p0) _LibCalld1ad0(DOSBase, "870", p0) #define PathPart(p0) _LibCalld1ad0(DOSBase, "876", p0) #define AddPart(p0, p1, p2) _LibCalld123ad0(DOSBase, "882", p0, p1, p2) #define StartNotify(p0) _LibCalld1ad0(DOSBase, "888", p0) #define EndNotify(p0) _LibCalld1ad0(DOSBase, "894", p0) #define SetVar(p0, p1, p2, p3) _LibCalld1234ad0(DOSBase, "900", p0, p1, p2, p3) #define GetVar(p0, p1, p2, p3) _LibCalld1234ad0(DOSBase, "906", p0, p1, p2, p3) #define DeleteVar(p0, p1) _LibCalld12ad0(DOSBase, "912", p0, p1) #define FindVar(p0, p1) _LibCalld12ad0(DOSBase, "918", p0, p1) #define CliInit(p0) _LibCallda0d0(DOSBase, "924", p0) #define CliInitNewcli(p0) _LibCallda0d0(DOSBase, "930", p0) #define CliInitRun(p0) _LibCallda0d0(DOSBase, "936", p0) #define WriteChars(p0, p1) _LibCalld12ad0(DOSBase, "942", p0, p1) #define PutStr(p0) _LibCalld1ad0(DOSBase, "948", p0) #define VPrintf(p0, p1) _LibCalld12ad0(DOSBase, "954", p0, p1) #define ParsePatternNoCase(p0, p1, p2) _LibCalld123ad0(DOSBase, "966", p0, p1, p2) #define MatchPatternNoCase(p0, p1) _LibCalld12ad0(DOSBase, "972", p0, p1) #define SameDevice(p0, p1) _LibCalld12ad0(DOSBase, "984", p0, p1) #endif SHAR_EOF # End of shell archive exit 0 From amiga-gcc-port-owner@nic.funet.fi Wed Aug 16 12:19:52 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90013-1>; Wed, 16 Aug 1995 12:18:15 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 16 Aug 1995 09:53:16 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA08062; Wed, 16 Aug 95 09:50:34 +0200 Date: Wed, 16 Aug 95 09:50:34 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508160750.AA08062@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@nic.funet.fi Subject: Re: comments and questions about gcc270 Kamil wrote: > It is ILLEGAL to put library base in A3 - RKM says that it HAS TO be in > A6. Why didn't you put it there?! Of course it it illegal. The code was not meant to be run and I should have pointed it out. By using A3 instead of A6, I wanted to make sure that there was no compiler magic about A6 that would come in. But you get exactly the same code with A6. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Aug 16 12:20:36 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90840-4>; Wed, 16 Aug 1995 12:18:15 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Wed, 16 Aug 1995 10:22:28 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA08112; Wed, 16 Aug 95 10:19:47 +0200 Date: Wed, 16 Aug 95 10:19:47 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508160819.AA08112@inf-wiss.uni-konstanz.de> To: amiga-gcc-port@nic.funet.fi Subject: Re: comments and questions about gcc270 Rask Ingemann Lambertsen wrote: > I am! Btw, would this allow you to use local variables for library bases? ?? You can do this today with the current inlines. Just notice that the library base is a define: #define BASE_EXT_DECL extern struct ExecBase * SysBase; define it to suit your needs (mydata->SysBase) just before including the corresponding inline header file. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Wed Aug 16 14:45:03 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90106-1>; Wed, 16 Aug 1995 14:43:22 +0300 Received: by ceylon.informatik.uni-rostock.de id NAA14039; Wed, 16 Aug 1995 13:43:14 +0200 Received: by honshu.informatik.uni-rostock.de id NAA12380; Wed, 16 Aug 1995 13:43:13 +0200 From: Gunther Nikl Message-Id: <199508161143.NAA12380@honshu.informatik.uni-rostock.de> Subject: Re: comments and questions about gcc270 To: amiga-gcc-port@nic.funet.fi Date: Wed, 16 Aug 1995 13:43:12 +0200 (MET DST) In-Reply-To: <9508160819.AA08112@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 16, 95 10:19:47 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1248 > > Rask Ingemann Lambertsen wrote: > > I am! Btw, would this allow you to use local variables for library bases? > ?? You can do this today with the current inlines. Just notice that the > library base is a define: > > #define BASE_EXT_DECL extern struct ExecBase * SysBase; > > define it to suit your needs (mydata->SysBase) just before including > the corresponding inline header file. That doesn't help to use _local_ variables as library base. In your example mydata has to be _global_. The current inlines can use locals but in an ugly way: The library-base has to be suppliedd as the first argument of every OS function (for this a define for BASE_PAR_DECL is needed before every inline) if one writes a program from scratch for AmigaOS there is a better solution: "system includes" struct Globals { struct ExecBase *SysBase; ... }; register struct Globals *gb asm("a4"); #define BASE_NAME gb->SysBase #include #undef BASE_NAME "other proto includes" Main() { struct Globals globals; memset(&globals,0,sizeof(struct Globals)); gb = &globals; } This works only with gcc and *requires* compiling with at least "-O" Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Aug 16 14:55:48 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90920-4>; Wed, 16 Aug 1995 14:54:34 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA25435; Wed, 16 Aug 1995 13:56:06 +0200 Date: Wed, 16 Aug 1995 13:56:05 +0200 (MET DST) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: comments and questions about gcc270 To: hoehle@inf-wiss.uni-konstanz.de cc: Amiga GCC List In-Reply-To: <199508160922.LAA24719@ernie.icslab.agh.edu.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Wed, 16 Aug 1995 Joerg-Cyril Hoehle wrote: > Rask Ingemann Lambertsen wrote: > > I am! Btw, would this allow you to use local variables for library bases? > ?? You can do this today with the current inlines. Just notice that the > library base is a define: > > #define BASE_EXT_DECL extern struct ExecBase * SysBase; > > define it to suit your needs (mydata->SysBase) just before including > the corresponding inline header file. I think you're wrong. This definition doesn't solve anything. The problem is that "inlines" are separate functions. In inline-glue, there is a line like this: register struct ExecBase *a6 __asm("a6") = BASE_NAME; BASE_NAME cannot be a local variable, cause it simply won't be "seen" by GCC. Inlines are not preprocessor macros :-(. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Aug 16 16:58:31 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90694-3>; Wed, 16 Aug 1995 16:51:02 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HU5A6XH5KW008QSR@NET2.WAU.NL>; Wed, 16 Aug 1995 15:52:41 +0000 (GMT) Received: by vines2.wau.nl; Wed, 16 Aug 95 15:56:29 +0100 Date: Wed, 16 Aug 1995 15:40:11 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Continuing story of GS3.33 & GCC To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hello all, First of all a big thanks to Phillipe for forwarding my mail to this list. This is a followup because I got mail from the GhostScript maintainer asking if I could recompile with GCC 2.6.3 I did and the results are :( Options used beside the ones in the makefile: in all situations -O2 and FPU_TYPE either -1 or 2. GCC 2.6.3: -m68000 doesn't work correctly -m68020 doesn't work correctly -m68020 -m68881 *does* work correctly GCC 2.7.0 (beta 3-Aug) -m68000 doesn't work correctly -m68020 *does* work -m68020 -m68881 *does* work So gcc263 is even worse than 270 because now I need to include FPU instructions to get things working correctly. Working correctly means that I can specify -sDEVICE=pcx with out GS printing lots of garbage to my console and quitting. Strange thing is that certain drivers are affected by the compiler options but not all. Not affected (meaning they work with -m68000): deskjet/laserjet/tiffpack Affected: tifflzw/tiffcrle/bmp/pcx The suggestion that gcc might be faulty is still there. What I don't get is why -m68000 is the one causing problems. There is no inline asm, GS should be only ANSI-C, and the FPU_TYPE define does not have an impact on GS behaving itself. Only thing that changes is the precision of floats and rounding, which can be seen by generating pictures and compare them. They differ in size and in dither patterns. Could someone please suggest what is going on. I'm willing to try any suggestion which makes a little sense. Thanks alot, Joop From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 17:56:31 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <89937-1>; Thu, 17 Aug 1995 17:53:18 +0300 Received: from ernie.icslab.agh.edu.pl by FIPORT.FUNET.FI (PMDF V5.0-3 #2494) id <01HU6F0GFD34000A8M@FIPORT.FUNET.FI> for amiga-gcc-port@nic.funet.fi; Thu, 17 Aug 1995 11:22:10 +0200 (EET) Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA00242; Thu, 17 Aug 1995 10:18:32 +0200 Date: Thu, 17 Aug 1995 10:18:32 +0200 (MET DST) From: Kamil Iskra Subject: Re: inline patches In-reply-to: <199508140915.LAA04500@honshu.informatik.uni-rostock.de> Sender: Kamil Iskra To: Gunther Nikl Cc: amiga-gcc-port@nic.funet.fi Reply-to: Kamil Iskra Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Mon, 14 Aug 1995, Gunther Nikl wrote: > > Well, there are people that will be happy to create such a database for you. > Fine, if anybody could update the perl-script. I am only able to run it :) If you are only able to run it, why do you like it so much? I am not even able to run it, cause I don't have perl. Not to mention modifying it. That's why I would like to have "fd2inline.c" fully working and reliable. IMHO "C" gererator has a lot of advantages: it's faster and easier to read and modify. Frankly speaking, all I can see in perl-script are DISadvantages. The fact that Markus Wild, first GCC porter, great UN*X fan, made inlines generator in perl, doesn't mean that we still have to use it. > Gunther Kamil From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 17:56:51 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90576-2>; Thu, 17 Aug 1995 17:53:26 +0300 Received: from ernie.icslab.agh.edu.pl by FIPORT.FUNET.FI (PMDF V5.0-3 #2494) id <01HU6EWT5WGW000A8F@FIPORT.FUNET.FI>; Thu, 17 Aug 1995 11:19:36 +0200 (EET) Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA00269; Thu, 17 Aug 1995 10:19:29 +0200 Date: Thu, 17 Aug 1995 10:19:28 +0200 (MET DST) From: Kamil Iskra Subject: Re: your mail In-reply-to: <95Aug14.151759+0300_eet_dst.90194-3+29@nic.funet.fi> Sender: Kamil Iskra To: gc948374@gbar.dtu.dk Cc: vinsci@nic.funet.fi, amiga-gcc-port@nic.funet.fi Reply-to: Kamil Iskra Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Mon, 14 Aug 1995 gc948374@gbar.dtu.dk wrote: > Maybe all registers should be defined as returning a result then? > Otherwise, how is it possible to use Supervisor() from GCC at all? IMHO using such a function as Supervisor() from programming language other than assembler is rather problematic. Have anyone used it in "C"? And what for? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 17:57:34 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90757-4>; Thu, 17 Aug 1995 17:56:38 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Thu, 17 Aug 95 12:12:23 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2126f324.u7t157e.54c3b-robert@plukwa.pdi.lodz.pl> Subject: Help! I need fully working libauto.a (fwd) Reply-To: robert@pdi.lodz.pl Content-Length: 527 To: amiga-gcc-port@nic.funet.fi Date: Thu, 17 Aug 95 12:12:23 So noone has a working libauto.a ????? On Aug 12, Robert Ramiega wrote: |-------------------- text of forwarded message follows --------------------| Hi all! Sorry for disturbing You all. Can someone send me working libauto.a (via e-mail or directly on plukwa.pdi.lodz.pl via ftp)? I really need it. I tried to compile one on my own (I used both MakefileAJGG and Makefile suplied with gcc) but still cant get working libauto. Robert |------------------------- end of forwarded message ------------------------| From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 17:57:56 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90325-2>; Thu, 17 Aug 1995 17:56:37 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug17.175637+0300_eet_dst.90325-2+20@nic.funet.fi> From: To: Date: Thu, 17 Aug 1995 13:09:17 +0300 Date: Thu, 17 Aug 1995 12:08:42 +0200 (METDST) From: Rask Lambertsen To: Joerg-Cyril Hoehle Cc: amiga-gcc-port@nic.funet.fi Subject: Re: comments and questions about gcc270 In-Reply-To: <9508160819.AA08112@inf-wiss.uni-konstanz.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 16 Aug 1995, Joerg-Cyril Hoehle wrote: > Rask Ingemann Lambertsen wrote: > > I am! Btw, would this allow you to use local variables for library bases? > ?? You can do this today with the current inlines. Just notice that the > library base is a define: > > #define BASE_EXT_DECL extern struct ExecBase * SysBase; > > define it to suit your needs (mydata->SysBase) just before including > the corresponding inline header file. Thanks! I had totally overlooked that. Btw, is it documented anywhere? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 17:58:42 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90780-1>; Thu, 17 Aug 1995 17:57:25 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HU6HA7KLSW008YJ5@NET2.WAU.NL>; Thu, 17 Aug 1995 12:26:57 +0000 (GMT) Received: by vines2.wau.nl; Thu, 17 Aug 95 12:30:45 +0100 Date: Thu, 17 Aug 1995 12:23:58 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: GCC270 & GS3.33 problems To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hello Rask, You're the guy with SUBJECT: problems aren't you The lines below appeared in my message body, and there was no subject line. >Date: Thu, 17 Aug 1995 12:14:41 +0200 (METDST) >From: Rask Lambertsen >To: joop van de wege >Cc: amiga-gcc-port@nic.funet.fi >Subject: Re: Continuing story of GS3.33 & GCC >In-Reply-To: >Message-Id: >Mime-Version: 1.0 >Content-Type: TEXT/PLAIN; charset=US-ASCII >Could it be a broken machine description file? Maybe that would explain why >only the '000 is affected. Maybe but then they atleast updated the md file to generate correct code for the mc68020 and up for gcc2.7.0 With gcc2.6.3 there is incorrect code for -m68020 too. >Btw, when were 680x0 machine descriptions files last updated? No idea :) I'm currently trying Lars' idea to compile with -O0 and -O1. -O1 doesn't produce a correctly working executable. -O0 is probably ready by now but I'm at work so I can't check but will mail the results soon. Joop From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 17:59:09 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90451-2>; Thu, 17 Aug 1995 17:57:23 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 17 Aug 1995 12:24:02 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10838; Thu, 17 Aug 95 12:24:02 +0200 Date: Thu, 17 Aug 95 12:24:02 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508171024.AA10838@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA04437; Thu, 17 Aug 95 12:24:01 +0200 To: amiga-gcc-port@nic.funet.fi Subject: Re: comments and questions about gcc270 In-Reply-To: References: <9508160819.AA08112@inf-wiss.uni-konstanz.de> Oops, sorry for the almost empty mail :( Rask Lambertsen writes: > > #define BASE_EXT_DECL extern struct ExecBase * SysBase; > > > > define it to suit your needs (mydata->SysBase) just before including > > the corresponding inline header file. > Thanks! I had totally overlooked that. Btw, is it documented anywhere? As was pointed out, it's not that easy as MYDATA is not local to the inline function. However it works if you reserve a register variable, say reserve A4 to point to your data. Still not strictly local. Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 17:59:59 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90727-3>; Thu, 17 Aug 1995 17:58:26 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug17.175826+0300_eet_dst.90727-3+42@nic.funet.fi> From: To: Date: Thu, 17 Aug 1995 14:23:18 +0300 Date: Thu, 17 Aug 1995 13:23:08 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Diff -2cp for inline/graphics.h Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is a diff for inline/graphics.h. I added '-p' to diff so that you can easily see the name of the function (look at the end of the third line). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ *** inline/graphics.h Thu Sep 22 11:31:14 1994 --- new-inline/graphics.h Tue Aug 8 13:06:57 1995 *************** WaitBlit (BASE_PAR_DECL0) *** 2126,2130 **** : /* no output */ : "r" (a6) ! : "a0","a1","d0","d1", "memory"); } extern __inline void --- 2126,2130 ---- : /* no output */ : "r" (a6) ! : "cc", "memory"); } extern __inline void From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 18:00:32 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90695-3>; Thu, 17 Aug 1995 17:57:06 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Thu, 17 Aug 1995 12:19:21 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA10815; Thu, 17 Aug 95 12:19:20 +0200 Date: Thu, 17 Aug 95 12:19:20 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508171019.AA10815@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA04436; Thu, 17 Aug 95 12:19:20 +0200 To: amiga-gcc-port@nic.funet.fi Subject: Re: comments and questions about gcc270 In-Reply-To: References: <9508160819.AA08112@inf-wiss.uni-konstanz.de> Rask Lambertsen writes: > > #define BASE_EXT_DECL extern struct ExecBase * SysBase; > Thanks! I had totally overlooked that. Btw, is it documented anywhere? dboyAs somebody pointed out From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 18:01:25 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90924-4>; Thu, 17 Aug 1995 17:53:25 +0300 Received: from funet.fi (funet.fi) by FIPORT.FUNET.FI (PMDF V5.0-3 #2494) id <01HU6EY47DN4000A8H@FIPORT.FUNET.FI>; Thu, 17 Aug 1995 11:20:01 +0200 (EET) Received: from ernie.icslab.agh.edu.pl by funet.fi with SMTP (PP); Thu, 17 Aug 1995 11:19:15 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA00232; Thu, 17 Aug 1995 10:17:31 +0200 Date: Thu, 17 Aug 1995 10:17:31 +0200 (MET DST) From: Kamil Iskra Subject: Re: illegal/invalid In-reply-to: <95Aug11.145000+0300_eet_dst.89707-4+35@nic.funet.fi> Sender: Kamil Iskra To: Leonard Norrgard Cc: amiga-gcc-port@nic.funet.fi Reply-to: Kamil Iskra Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Fri, 11 Aug 1995, Leonard Norrgard wrote: > When referring to programming standards (like in what register the > library base should be) and the correct use of them please talk about > valid or invalid programming. > > Legal/illegal programming is something completely different, and out > of the scope for this mailing list. I appologise. I am not English native speaker and I didn't see any semantic difference between this two adjectives. IMHO this discussion is out of the scope for this mailing list, but anyway I'll try to remember and use "invalid" where appropriate :-). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 18:01:41 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90752-1>; Thu, 17 Aug 1995 17:56:39 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug17.175639+0300_eet_dst.90752-1+17@nic.funet.fi> From: To: Date: Thu, 17 Aug 1995 13:15:09 +0300 Date: Thu, 17 Aug 1995 12:14:41 +0200 (METDST) From: Rask Lambertsen To: joop van de wege Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Continuing story of GS3.33 & GCC In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 16 Aug 1995, joop van de wege wrote: > Hello all, > > First of all a big thanks to Phillipe for forwarding my mail to this list. [snip] > The suggestion that gcc might be faulty is still there. What I don't get is > why -m68000 is the one causing problems. There is no inline asm, GS should be > only ANSI-C, and the FPU_TYPE define does not have an impact on GS behaving > itself. Only thing that changes is the precision of floats and rounding, > which can be seen by generating pictures and compare them. They differ in > size and in dither patterns. > > Could someone please suggest what is going on. > > I'm willing to try any suggestion which makes a little sense. Could it be a broken machine description file? Maybe that would explain why only the '000 is affected. Btw, when were 680x0 machine descriptions files last updated? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 18:03:01 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90353-3>; Thu, 17 Aug 1995 17:55:53 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug17.175553+0300_eet_dst.90353-3+38@nic.funet.fi> From: To: Date: Thu, 17 Aug 1995 12:56:17 +0300 Date: Thu, 17 Aug 1995 11:56:03 +0200 (METDST) From: Rask Lambertsen To: Niklas Hallqvist Cc: amiga-gcc-port@nic.funet.fi Subject: Re: your mail In-Reply-To: <199508141836.UAA06536@linda.appli.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 14 Aug 1995, Niklas Hallqvist wrote: > >>>>> "Rask" == gc948374 writes: > > >> actualy K for kilo is right, because all for positive exponents the > >> shortcut is capitel (T,G,M,...) while for negative its small. > >> because K is used so often its allowed to use smallcaps too. > > Rask> Aargh - so far I have never seen a capital 'k' used for 'kilo' - > Rask> this includes math books. I think I have even seen several > Rask> official lists stating small 'k' for 'kilo'. > > Correct! The mathematical k prefix stands for kilo and is 10^3. It > is the exception for the rule stated above as it was used widely long > before that rule got invented. However, as someone else has pointed Two more exceptions: 'h' for 'hekto' (10^2) and 'da' for 'deca' (10^1). > >> I dont know if B,b is defined somewhere but there seems to be an > >> agreement that b means Bit (0/1) while B means Byte (0..255). > > Rask> I'm pretty sure that a letter for 'bit' has not been defined. > > bps is the common "bit per second" acronym, cps is character per > second and usually used instead of Bps (for byte per second) as it is > so easy to intermix the acronyms then. > > Anyway, use whatever you think is best, but be consistent, and define > the acronyms in a glossary, if you think there might be a risk for > misunderstandings. OK, how about 'kB' for 'kilobyte' and 'MB' for megabyte? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 18:04:28 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90231-2>; Thu, 17 Aug 1995 17:58:26 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug17.175826+0300_eet_dst.90231-2+22@nic.funet.fi> From: To: Date: Thu, 17 Aug 1995 14:22:09 +0300 Date: Thu, 17 Aug 1995 13:22:06 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Diff -2cp for inline/exec.h Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is a diff for inline/exec.h. I added '-p' to diff so that you can easily see the name of the function (look at the end of the third line). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ *** inline/exec.h Thu Sep 22 12:05:54 1994 --- new-inline/exec.h Tue Aug 8 12:48:51 1995 *************** Disable (BASE_PAR_DECL0) *** 620,624 **** : /* no output */ : "r" (a6) ! : "a0","a1","d0","d1", "memory"); } extern __inline BYTE --- 620,624 ---- : /* no output */ : "r" (a6) ! : "memory"); } extern __inline BYTE *************** Enable (BASE_PAR_DECL0) *** 643,647 **** : /* no output */ : "r" (a6) ! : "a0","a1","d0","d1", "memory"); } extern __inline void --- 643,647 ---- : /* no output */ : "r" (a6) ! : "memory"); } extern __inline void *************** Forbid (BASE_PAR_DECL0) *** 731,735 **** : /* no output */ : "r" (a6) ! : "a0","a1","d0","d1", "memory"); } extern __inline void --- 731,735 ---- : /* no output */ : "r" (a6) ! : "memory"); } extern __inline void *************** GetCC (BASE_PAR_DECL0) *** 811,815 **** : "=r" (_res) : "r" (a6) ! : "a0","a1","d0","d1", "memory"); return _res; } --- 811,815 ---- : "=r" (_res) : "r" (a6) ! : /* Nothing is clobbered */ ); return _res; } *************** ObtainSemaphore (BASE_PAR_DECL struct Si *** 942,946 **** : /* no output */ : "r" (a6), "r" (a0) ! : "a0","a1","d0","d1", "memory"); } extern __inline void --- 942,946 ---- : /* no output */ : "r" (a6), "r" (a0) ! : "memory"); } extern __inline void *************** ObtainSemaphoreShared (BASE_PAR_DECL str *** 964,968 **** : /* no output */ : "r" (a6), "r" (a0) ! : "a0","a1","d0","d1", "memory"); } extern __inline struct Library * --- 964,968 ---- : /* no output */ : "r" (a6), "r" (a0) ! : "memory"); } extern __inline struct Library * *************** Permit (BASE_PAR_DECL0) *** 1030,1034 **** : /* no output */ : "r" (a6) ! : "a0","a1","d0","d1", "memory"); } extern __inline ULONG --- 1030,1034 ---- : /* no output */ : "r" (a6) ! : "memory"); } extern __inline ULONG *************** ReleaseSemaphore (BASE_PAR_DECL struct S *** 1083,1087 **** : /* no output */ : "r" (a6), "r" (a0) ! : "a0","a1","d0","d1", "memory"); } extern __inline void --- 1083,1087 ---- : /* no output */ : "r" (a6), "r" (a0) ! : "memory"); } extern __inline void *************** Supervisor (BASE_PAR_DECL unsigned long *** 1397,1401 **** : "=r" (_res) : "r" (a6), "r" (a2) ! : "a0","a1","a2","d0","d1", "memory"); return _res; } --- 1397,1401 ---- : "=r" (_res) : "r" (a6), "r" (a2) ! : "a0","a1","a2","a3","a4","a5","a6","a7","d0","d1","d2","d3","d4","d5","d6","d7","cc", "memory"); return _res; } From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 18:16:27 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90245-4>; Thu, 17 Aug 1995 17:58:19 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug17.175819+0300_eet_dst.90245-4+34@nic.funet.fi> From: To: Date: Thu, 17 Aug 1995 14:16:31 +0300 Date: Thu, 17 Aug 1995 13:16:24 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: New README for GCC 2.7.0 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, Here is a new readme file for GCC 2.7.0 with (hopefully) all errors corrected. I know that it won't make it into the 2.7.0 release, but maybe it can be used as a base for GCC 2.7.1? I am posting the complete new readme instead of diffs as a normal context diff (diff -2w) would be much larger and even a unified context diff (diff -2u) wouldn't be much smaller. If you wan't to see what I have changed, you can now use your favourite diff output format :-) Mainly, spelling and grammar has been correct + the incorrect inline section. It should now be clear that you can use the supplied inlines on OS 2.x systems. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ Readme for GCC 2.7.0 ---------------------------------------------------------------- Short: gcc v2.7.0 - C/C++/ObjC Compiler set for AmigaDOS Type: dev/gcc Uploader: phb@colombo.telesys-innov.fr Author: phb@colombo.telesys-innov.fr This is the AmigaDOS 2.7.0 GNU C/C++/Objc compiler. The GNU C compiler is free software. See the file COPYING for copying permission. PLEASE be sure to read README file enclosed in gcc270-readme.lh= a FIRST. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D How to get help =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There's an Amiga-GCC mailing list running in Finland, read README-LIST file= . This is the preferred place to ask for help since I'm on this list and every GCC developers also, libnix & ixemul authors, etc... Short: send an email to listserv@lists.funet.fi, and put in body: =09subscribe amiga-gcc-port your_first_name your_last_name (insert your own first name and your own last name above) Otherwise you can contact me at: =09Philippe BRAND =09Fidonet: Ramses The Amiga Flying BBS 2:320/104.0 =09Email: phb@colombo.telesys-innov.fr (ONLY for personal email). =09WWW: www.telesys-innov.fr=20 =09Ftp: ftp.telesys-innov.fr:/pub/amigados-gnu =09 or /pub/incoming/uploads for uploads. Note: I'll forward any question to this mailing-list, but please use it directly, except when you send files, in this case send them to my ftp site= . Note 2: ftp.funet.fi mirrors my amigados-gnu tree. Using ftp.funet.fi is preferable as they have much more bandwidth (/pub/amiga/gnu). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Requirements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Systems: Any Amiga (ranging from A1000 up to A4000/40, including CD-32 & SX-1) will run AmigaDOS-GNU utilities. - Memory: A minimum of 4 MB of free memory is needed in order to compile small/medium projects. More memory will be needed for large projects, such as recompiling GCC itself. Gigamem is known to work with GCC so *maybe* less memory will work. But in = this case, you'll need an MMU equipped Amiga (A3000,A4000/40, etc...). VMM40 (Public Domain Virtual memory manager) is also known to work with GCC= . - OS: Starting from version 2.5.x, 1.3 systems are not longer supported. GCC runs fine on all other systems, starting from 2.04 up to 3.1 (40.68). - Disk Space; An installation of GCC requires the use of a hard disk. Approximately 10 MB= is required at present to install the compiler and utilities required to use i= t. In addition 3 MB is required for the Commodore Developer Kit, which is requ= ired to be able to compile AmigaDOS specific programs. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D What's new in this release =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D 2.7.0 - Read FSF NEWS-2.7.0 file included. - As always, generic bugs fixed (see Changelog in GCC sources for details). - FSF listing shell script suppressed. - new as/ld/size/nm/ranlib using BFD, made by Raphael Luebbert - as fixed, used to generate some 020 instructions while in 68000 mode. - all programs recompiled using 2.7.0 compiler. - new inlines headers. - new compiler options: -mstackcheck and -mstackextend, to respectively implement stack checking and auto-stack growing into GCC compiled program= s. - resident option is now fixed. - new ixemul library, v41.1 (complete distribution can be found on Aminet s= ite). - new libnix, v1.0 (sources can be found also on Aminet sites, in libnix ar= chive). This release is dedicated in memory of Pierre Carette. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D What was new in previous releases =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 2.6.3 - Read FSF NEWS-2.6.1 file included. - As always, generic bugs fixed (see Changelog in GCC sources for details). - q_anote package replaced by FSF listing shell script, need awk. - new as/ld/size/nm/ranlib, made by Raphael Luebbert - new environent variables GCCPRIORITY and GCCSTACK, see below. - all programs recompiled using 2.6.3 compiler. - mit2mot & mot2mit, convert asm syntax between Motorola and MIT syntaxes. - all programs hold AmigaDOS compatible $VER string. 2.6.2 - internal release only. 2.6.1 - Read FSF NEWS-2.6.1 file included. - As always, generic bugs fixed (see Changelog in GCC sources for details). - new option -priority in gcc allowing process priority setting. - new specs file, inlines/protos and libamiga done by Gunther Nikl. See not= e below. - new libnix version by Matthias Fleischer & Gunther Nikl. - new ixemul version by Raphael Luebbert. - stripc program to strip all uneccessary stuff from headers by Chris Metca= lf, submitted by Lars Hecking. - q_anote, annotate assembly files mixing C source code, submitted by Walte= r Harms (Walter.Harms@arbi.informatik.uni-oldenburg.de), written by=20 Mike Albaugh (albaugh@agames.com). See note below. - new assembler, as-2.5, using new BFD (Binary File Descriptor), made by Raphael Luebbert. 2.6.0 - Read FSF NEWS-2.6.0 file included. - Extensive internal compiler bugs fixed (see ChangeLog in GCC sources for details), tons of bugs fixed for C++ support. - ld changed (see note for ld below). - new ixemul.library, with optimized versions for accelerated Amigas, see README-ixemul & ixemul.guide for more informations. - new C library (libnix) disabling use of ixemul.library for generated programs (best use for AmigaDOS specific programs). Full ANSI compliant, = see README-libnix & libnix.guide for more informations. - revised inline headers in accordance with new ixemul.library. - libamiga.a is now distributed with GCC-2.6.1. - as v2.3 is included, along with a macro-assembler (gasp). - stderrfix.o (see below) patch applied. - Upgrade to libg++-2.6. - GCC now supports $VER string for AmigaDOS version compatibility. 2.5.8 - Read FSF NEWS-2.5.8 file included. - ld behaviour over symbols changed (see note below). - added flavours so that linker will take appropriate libraries according t= o gcc options (m68020 libraries/baserel libraries, etc...). - gpc (GNU-Pascal) v1.03 added. - all utilities recompiled with GCC-2.5.8. - plain 68000 and 68020+68881 versions of all binaries available. - More internal compiler bugs fixed (see ChangeLog in GCC sources for detai= ls), some for C++ support. - GCC-Install script fixed by Claus Deckhut (to be used with full distribut= ion). - Upgrade to libg++-2.5.3. - trace.c updated by J. Hoehle to avoid buffer overflows. 2.5.7: - Read FSF NEWS file included. - More internal compiler bugs fixed (see ChangeLog in GCC sources for detai= ls), a lot for C++ support. - Fred Fish seems to have finally found an annoying bug which prevented to compile a resident version of GCC, or to compile resident programs. Bu= t don't try it anyway 'cause there's still lack of library support as for n= ow. - Man command now works, this one was my fault (well in fact like others ;-= ), fix done by Tom Haiko. - Infoview works also, it was an internal path problem. - libamy.a HAS TO BE RENAMED to libamiga.a because new ld won't find libamy= .a - upgrade to new C++ library v2.5.1. =3D=3D=3D=3D=3D=3D=3D Authors =3D=3D=3D=3D=3D=3D=3D GCC v2.2.2 port: Markus Wild GCC v2.3.3 port: Markus Wild GCC v2.4.5 port: Philippe Brand, Lars Hecking, Fred Fish GCC v2.5.0 and up: Philippe Brand, Fred Fish, Leonard Norrgard=20 Ixemul.library: Markus Wild (original programming), =09=09 Leonard Norrgard (vinsci@nic.funet.fi), =09=09 Raphael Luebbert, Stephan Isthesin. Libnix: Matthias Fleischer (fleischr@izfm.uni-stuttgart.de) and =09=09 Gunther Nikl (gnikl@informatik.uni-rostock.de) Installer Prog: Jochen Wiedmann (jochen.wiedmann@zdv.uni-tuebingen.de) Thanks to all amiga-gcc-port mailing-list users for their reports and suppo= rt for a better AmigaDOS-GCC and documentation. =3D=3D=3D=3D=3D=3D=3D Sources =3D=3D=3D=3D=3D=3D=3D These archives should contain everything necessary to get you going, they don't include sources for all tools (have a look at end of paragraph). As stated by Richard Stallman of the FSF: "The GPL says that any distribution of binaries must contain either the source code or a written offer to supply source code (see the GPL for details of what is required)." If you're interested in the sources required to rebuild GCC, get the gcc270-src.lha, which hold sources for GCC. Those archives should be stored either the same ftp site you got this binary distribution from (if they're not, tell the manager of that ftp site, as this is a requirement of the GNU Copyright LICENSE), either at ftp.gnu.ai.mit.edu:/pub/gnu, either on Ramses BBS (phone numbers listed below). If you have those archives, you can skip to next paragraph. If you have original FSF sources, you'll have to apply the GCC patch-file in src-patche= s/, and configure for `amigados'. Please note that you should have at least 40 = MB left or your HD and 8 MB of memory minimum in order to rebuild GCC up to st= age 3. An accelerated Amiga is welcome, as it took me 4,5 hours to generate a sing= le pass. So 3 passes makes 4,5 x 3 =3D 13,5 hours. Sources for other tools only included as binaries are available separately in self-contained archives, usually having their name into the archive-name= . File=09=09=09=09What gcc270-src.lha=09=09=09C/C++/ObjC compiler sources & diff file libnix-1.0.lha=09=09=09libnix sources and binaries ixemul-41.1-src.lha=09=09ixemul sources and libraries binutils-1.8.x-src.lha=09=09Sources for ld binutils-2.5.2-src.lha=09=09Sources for ar/ranlib & diff file make-3.74-src.lha=09=09make sources & diff file gdbm-1.7.3-src.lha=09=09Sources for gdbm & diff file patch-2.1-src.lha=09=09patch sources, needed to apply diff files sed-2.05-src.lha=09=09sed sources & diff file gawk-2.15.5-src.lha=09=09GNU awk sources & diff file diffutils-2.7-src.lha=09=09diff utility sources & diff file fileutils-3.11-src.lha=09=09file utilities sources & diff file sh-utils-1.12-src.lha=09=09shell utilities sources & diff file textutils-1.11-src.lha=09=09text utilities sources & diff file findutils-4.1-src.lha=09=09find sources & diff file grep-2.0-src.lha=09=09grep sources & diff file bison-1.22-src.lha=09=09bison (yacc replacement) sources & diff file flex-2.4.7-src.lha=09=09flex (lex replacement) sources & diff file texinfo-3.1-src.lha=09=09texinfo (includes makeinfo) sources & diff file gzip-1.2.4-src.lha=09=09gzip sources & diff file tar-1.11.2-src.lha=09=09gtar sources & diff file cpio-2.3-src.lha=09=09cpio sources & diff file gdbm-1.7.3-src.lha=09=09database manip. library sources & diff file termcap-1.2-src.lha=09=09termcap library sources & diff file libm-5.6-src.lha=09=09BSD mathematic library sources & diff file NOTE: All sources archives are Amiga ready, and Amiga specific diff file located in 'amiga' directory. To recompile a tool, just run a 'configure amigados' then a 'make'. Exceptions are libnix and ixemul which have their own archives, both binary= & sources. On Aminet sites, libnix & ixemul in /pub/amiga/dev/gcc. =3D=3D=3D=3D=3D Where =3D=3D=3D=3D=3D **** All GNU sources & binaries are available on: - ftp.telesys-innov.fr, primary Amiga-GNU FTP site, and its mirror ftp.fune= t.fi which is MUCH faster than my own site. Please use it at first choice. in /pub/amigados-gnu - Aminet sites (wuarchive.wustl.edu and mirrors such as ftp.luth.se) in /pub/amiga/dev/gcc - Ramses The Amiga Flying BBS +33-1-45845623 USR V.everything 2400-3360= 0 +33-1-53791199 USR V.everything 2400-3360= 0 +33-1-53791200 USR Sportster V32b 2400-1440= 0 in Topic "Development", Area "Gcc" (File Area 156). - FreshFish CDs from Fred Fish=09=09 Amiga Library Services in :GNU/bin, :GNU/src, :GNU/lib dirs. 610 N. Alma School Road, Suite 1= 8 =09=09=09=09=09 Chandler, AZ 85224-3687 =09=09=09=09=09 USA =09=09=09=09=09 FAX: (602) 491-0048 =09=09=09=09=09 VOICE: (602) 491-0442 **** GNU source code is available on: - same FTP site you've taken these archives - gnu.prep.ai.mit.edu 18.71.0.38 in /pub/gnu - Ramses The Amiga Flying BBS in Topic "AmigaUnix/Unix/Linux/NetBSD", Area "Gnu Source Code" - FreshFish from Fred Fish in :GNU/src =3D=3D=3D=3D=3D=3D Layout =3D=3D=3D=3D=3D=3D GCC-2.7.0 is split up into 15 archives: gcc270-readme.lha=09holds readmes files (include installation notes). gcc270-base.lha basic GCC distribution, hold necessary files. gcc270-inclib.lha=09headers and libraries. gcc270-c.lha=09=09C compiler. gcc270-c-020.lha=0968020 version of C compiler. gcc270-c++.lha=09=09C++ compiler, headers and libraries. gcc270-c++-020.lha=0968020 versions of C++ compiler. gcc270-objc.lha=09=09Objective-C compiler, header and libraries. gcc270-objc-020.lha=0968020 versions of Objective-C compiler. gcc270-doc.lha=09=09GCC AmigaGuide(tm) documents & manpages. gcc270-utils.lha=09Useful utilities needed for development. gcc270-utilsdoc.lha=09Utilities documentation (guide & manpages). gcc270-texi.lha=09=09All Texinfo documents. gcc270-diffs.lha=09Diff files for all binaries. gcc270-src.lha=09=09Source for GCC-2.7.0 plus diff file. Name=09=09=09What=09=09=09=09=09Where=09 ----=09=09=09----=09=09=09=09=09----- COPYING=09=09=09GNU LICENSE, read!!=09=09=09All archives COPYING.LIB=09=09GNU LIBRARY LICENSE, read!!=09=09All archives README-2.7.0=09=09this file=09=09=09=09All archives NEWS-2.7.0=09=09What's new in GCC-2.7.0=09=09=09gcc270-base Installer=09=09Commodore installer utility=09=09gcc270-base GCC-Install=09=09Installer script to configure GCC=09All archives envarc/=09=09=09global environment variables you should =09=09=09have set when using this programming=09gcc270-base =09=09=09environment include/=09=09non-Amiga specific C/C++ headers=09gcc270-inclib os-include/proto=09Amiga specific protos headers.=09=09gcc270-inclib os-include/inline=09Amiga specific inline C headers. Add=09gcc270-inclib =09=09=09Commodore headers!!=09=09 os-lib/=09=09=09Amiga specific libraries=09=09gcc270-base guide/=09=09=09Docs in AmigaGuide(tm) format=09=09gcc270-doc man/=09=09=09this is the root for tons of man pages=09gcc270-doc bin/=09=09=09this is /bin, and contains all =09=09gcc270-c =09=09=09binaries of this distribution that=09gcc270-c++ =09=09=09are meant to be directly invoked by=09gcc270-utils =09=09=09the user (contrary to the executables =09=09=09in lib/gcc-lib/, that are meant to be =09=09=09invoked by a driver program like gcc) lib/=09=09=09normal (not base relatives) libraries=09gcc270-inclib lib/libm020/=09=09normal 68020 libraries=09=09=09gcc270-inclib lib/libb/=09=09base relatives libraries=09=09gcc270-inclib lib/libb/libm020/=09base relatives using 68020 libraries=09gcc270-inclib lib/libnix/=09=09Non-ixemul libraries=09=09=09gcc270-inclib lib/libm020/libnix/=09Non-ixemul 68020 libraries=09=09gcc270-inclib lib/libb/libnix/=09Non-ixemul base relatives libraries=09gcc270-inclib lib/libb/libm020/libnix=09Non-ixemul base relatives 68020 libs=09gcc270-inc= lib lib/gcc-lib/=09=09home of compilers called by gcc=09=09gcc270-c =09=09=09=09=09=09=09=09gcc270-c++ =09=09=09=09=09=09=09=09gcc270-objc ixpipe/=09=09=09a pipe handler needed by the library=09gcc270-base libs/=09=09=09ixemul.library=09=09=09=09gcc270-base rexx/=09=09=09ARexx wrappers for gcc and g++=09=09gcc270-base src-patches/=09=09source patches=09=09=09=09gcc270-diffs geninline/=09=09Perl scripts to generate inline headers=09gcc270-inclib =09=09=09and -lamy glue =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Inline-Headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Since I'm not able to redistribute Amiga header files, you will have to get them directly from Commodore, unless you're an official registered Amiga developer. You can also find Development Kit on FreshFish CD-Roms. In order to generate inline-headers, follow these steps (provided Amiga hea= ders and fd files are in os-include). If you are compiling for Kickstart 3.1 or less, you don't have to generate them, inlines are provided with the distribution. 1) First method: CLI> stack 100000 CLI> Assign INCLUDE: GCC:os-include CLI> Assign FD: INCLUDE:fd CLI> Makedir INCLUDE:inline CLI> cd USR:bin/geninline CLI> gen31 This will create all inline-headers. If you have 2.0 headers, use gen20 instead, if you have 3.0, use gen30, if you have 6.4, send it to me ;-) NOTE: perl scripts do not handle correctly AmigaDOS include files, which seems to mean they are somewhat broken. If someone could work on this... 2) Second method: Use fd2inline, which you can find on Aminet in dev/gcc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Amiga Libraries =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Starting from 2.6.0 an AmigaDOS compliant library is provided, thanks to libnix authors (Matthias Fleischer and Gunther Nikl). Anyway if you want to rebuild one, there are two methods: 1) Using hunk2gcc; the AmigaDOS object converter made by Markus Wild. To achieve this, simply grab a copy of latest amiga.lib (from Commodore Development Kit) and make a new directory where you want your converted object files to go, cd into it, and enter hunk2gcc amiga.lib [..further libs if you like..] This generates an a.out object file for every program unit present in the hunk file (in this case, from amiga.lib). As the final step convert all those files into an a.out style library by issuing: ar qc libamiga.a obj.* ranlib libamiga.a The ranlib run builds a symbol table in the archive, and makes accesses to the library much faster. 2) Creating a libamiga.a library with libnix is fairly easy, but takes some time. Just decompress sources.lha from libnix distribution and run a 'make libamiga.a'. NOTE: As long as you make no AmigaDOS specific calls, you can create a dummy libr= ary using: cat "int dummy;" >dummy.c gcc -c dummy.c ar crv libamiga.a dummy.o mv libamiga.a gcc:lib A small libamiga.a (dummy) is also provided with libnix. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Upgrade Installation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - You will at first have to decide if you want to keep your existing GCC compiler or not. This might sound silly, but it is in fact possible. - I want to keep older GCC compiler CLI> cd GNU:lib CLI> rename libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3 (note: replace 2.6.3 with your GCC version) CLI> rename libb/libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3/libb CLI> rename libm020/libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3/lib= m020 CLI> cd GNU:bin CLI> rename gcc gcc-2.6.3 CLI> rename gccv gccv-2.6.3 - I don't care about previous versions CLI> delete GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3 all quiet Proceed then to "Distribution Installation" below, for mandatory archives only. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Distribution Installation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NOTE: you MUST at least unpack gcc270 base, inclib and c parts. Other archives are optional. - You need first to create a directory gnu on your hard-disk and unarchive first part: CLI> cd place_with_lot_of_space CLI> makedir gnu CLI> lha x gcc270-base.lha - Now you have to append gnu/s/user-startup to your s:user-startup file (replace Devel:GNU by your own gnu path). Execute it in order to get new assigns: CLI> execute gnu/s/user-startup - Copy gnu/envarc to ENVARC: CLI> copy gnu/envarc/#? ENVARC: - GCC libraries and headers: CLI> lha x gcc270-inclib.lha - C-compiler is needed so unarchive C compiler part (Users with accelerated Amigas can unarchive gcc270-c-020 part instead) : CLI> lha x gcc270-c.lha (or gcc270-c-020) - If you want to have GCC documentation on-line, unarchive doc part: CLI> lha x gcc270-doc.lha - If you want to do C++, unarchive C++ part (Users with accelerated Amigas can unarchive gcc270-c++-020 part instead) : CLI> lha x gcc270-c++.lha (or gcc270-c++-020) Please note that 68020 versions have '.020' extension in GNU:bin. - If you want to do Objective-C, unarchive Objective-C part (Users with accelerated Amigas can unarchive gcc270-objc-020 part instead) : CLI> lha x gcc270-objc.lha (or gcc270-objc-020) - If you want additional utilities (recommended for Unix compatibility), unarchive utils part: CLI> lha x gcc270-utils.lha - If you want all utilities documentation on-line, unarchive utils-doc part: CLI> lha x gcc270-utilsdoc.lha - Because some programs are normally links to others, please run script: CLI> sh /gnu/s/restorelinks Or if you don't want to use makelink but rather copy file, run script: CLI> sh /gnu/s/restorelinks copy - If you want to rebuild all distribution, you'll have to unarchive diff part: CLI> lha x gcc270-diffs.lha - If you want to build Postscript files for GCC documentation, unarchive texinfo part: CLI> lha x gcc270-texi.lha - Now skip to next paragraph and happy compiling! NOTE: new version of ixemul.library is provided, make sure you don't have another copy somewhere which may conflict with GCC. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Your first C program with GCC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D What about a nice Hello World ? =09#include =09main() =09{ =09 printf("Hello World!\n"); =09} =20 This was pretty simple ;-) Now we have to compile it. There's a lot of options in GCC but the simplest way to compile this would = be: CLI> gcc -o hello hello.c Simple? Here's more options. Target processor for Motorola family: You can compile plain 68000 code, 68020, 68030, 68040, 68881 (have a look a= t GCC documentation, either in info or AmigaGuide format, chapter Invoking GC= C/ SubModel Options/M680X0 Options for Motorola specific compilation flags). CLI> gcc -m68020 -m68881 -o hello hello.c This will compile your programs using 68020 code and direct calls to math-processor, and will link with accelerated libraries, located in GCC:lib/lib020. Optimization: Either you don't want optimization, or you can provide -O, which will=20 optimize your code, or if you really want top optimization, use -O2 flag (f= or more discussion about optimization, read info or AmigaGuide doc chapter Invoking GCC/Optimize Options). There's now even a -O3 optimization option, which will go even further. CLI> gcc -O2 -o hello hello.c You'll never have a "Hello World" program running so fast ;-) Code generation: Perhaps you want to generate resident programs. Flag is -resident, at compile and link stage. CLI> gcc -resident -o hello hello.c Of course you can mix all options, resulting in: CLI> gcc -O2 -m68020 -m68881 -resident -o hello hello.c This will make a 68020+68881 executable highly optimized and resident. IMPORTANT: If you only use AmigaDOS functions or you don't want to use ixemul for philosophical reasons, you can get rid of ixemul.library with: CLI> gcc -noixemul -o foobar foobar.c provided you have libnix distribution (included with 2.6.0 and up distribut= ions). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ixemul vs Libnix =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Starting with 2.6.1 version of AmigaDOS-GCC, two C libraries are provided. First one is using ixemul.library Amiga shared-library at run-time. This library makes it possible to easily convert Unix(tm) programs to AmigaDOS, and made for example possible GCC on AmigaDOS. Have a look at ixemul.guide for further informations. Second one is an ANSI-C compliant library which is better suited for AmigaDOS specific development, thus not using any Unix specific routines. Libnix is a static (i.e. link) library for GCC 2.3.3 or above. It's not a replacement for ixemul.library (though it's possible to recompile most of the GCC environment with libnix) but a good thing for Amiga specific development on GCC: * It's mostly compatible to SAS's way of handling things, i.e. you get even an automatic shared library opening feature and some other things you may miss in ixemul.library. This also means it's ANSI compliant. * It doesn't need any shared libraries other than normal Amiga OS ones. * It is not copyrighted by the FSF. Therefore you neither need to include sources nor objects together with your executable. (read the GLGPL _before_ flaming on this statement) * And it's short! I was able to compile a 492 byte 'hello, world' using normal main. * It uses OS 2.0 features whenever necessary. Note that you can develop AmigaDOS specific programs with ixemul.library, but at the cost of an extra 200 kB of memory taken by shared library. To cut it short: Use ixemul.library for porting Un*x programs, libnix for compiling Amiga-only programs and GCC becomes one of the best Amiga compilers. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Redirection with ixemul.library =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D A common problem seen with AmigaDOS-GCC is bad redirection to stderr. The fact is that ixemul.library takes stderr from the pr_CES field in the process structure. The field was added in 2.0. If the field is not set, then ixemul uses stdout, instead. The trouble is that this field must be set by the shell, and the only shell that does so is WShell! The rationale behind ixemul.library working this way is that "run NIL: cmd" will detach your process from the terminal, so that you can close the initial CLI window after startup. In any case, there is a workaround for the problem that was posted to the list a while back: compile your main program using the -Dmain=3Dmymain option, then link with stderrfix.o to provide the actual main that will do the magic that creates an stderr stream that is different from stdout. Along with the C version a C++ version is included and was used to compile groff. Thanks to Kriton Kyrimis for this explanation and patch. stderr fixes can be found in GNU:stderrfix (srcs-) and GNU:lib (.o files). =3D=3D=3D=3D=3D ARexx =3D=3D=3D=3D=3D The provided ARexx scripts have been contributed by Loren J. Rittle. If you like ARexx, they're an alternate way of calling GCC. They=20 automatically make sure you're using a large enough stack setting, and=20 enable you to compile C++ programs with less obscure options. This=20 approach is furthermore useful if you're not able to use the g++ /bin/sh script. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D gcc versus gccv =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D gccv stands for a gcc using vfork() to spawn a new process, and then callin= g the new execve() function in ixemul.library to call its subcompilers. Gcc continues to using the more system friendly RunCommand() function in dos.library to start subcompilers. Gccv has the advantage of being able to work with interprocess pipes, thus (provided you have the memory ;-)), you'= re able to do gccv -pipe your_program.c causing the preprocessor (cpp), the C-compiler (cc1) and the assembler (as) to run at the same time, passing intermediate files through internal pipes= =20 instead of using temporary files. As long as you don't want that feature (OK, playing with certain make tools also requires gccv) you're safe using gcc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D stack size =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D You need to have a stack size of 50000 in order to compile with GCC. This s= hould be enough for most projects. Note than while recompiling GCC with itself it has taken more than 300 kB of stack. Stack usage can grow due to source com= plexity. Don't be afraid of it. To set the stack size, see the AmigaDOS Command 'stack'.=20 To use ar and/or ranlib, 50 kB is the minimum acceptable stack. You should = have a much larger stack, if you use larger libraries. Starting with 2.6.3 a new environment variable, GCCSTACK, enables gcc to read this variable and set stack upon startup. Thus now no need to set stac= k to huge values, only gcc/ld/cpp/cc1#? will automatically set new stack, according to GCCSTACK variable. Simply commit a:=20 =09setenv GCCSTACK value to set gcc stack to value. Benefits: Huge memory savings. =3D=3D=3D=3D=3D=3D=3D=3D priority =3D=3D=3D=3D=3D=3D=3D=3D Starting also with 2.6.3 a new environment variable, GCCPRIORITY, let you specify a default process priority for GNU compiler. Setting it to -1 enabl= e your Amiga to do something else while compiling :-) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D C++ headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D With AmigaDOS it makes no difference whether a name has capital or lower-ca= se letters in names when finding files (i.e. it is case insensitive), you'll= =20 certainly run into problems with some headers, including String.h and norma= l string.h. My suggestion for now is to add to C++ "faulty" header file name = an "_" in front of it, thus String.h would become _String.h. Sorry for the inconvenience. (thanks to Dirk Nehring for reminding me about this annoying "feature"). =3D=3D=3D=3D=3D=3D=3D Patches =3D=3D=3D=3D=3D=3D=3D Includes: =09J=F6rg H=F6hle hoehle@inf-wiss.uni-konstanz.de There is a conflict between the Amiga and the UNIX definition of the timeval structure. Markus Wild proposed in GCC233 to patch the Amiga devices/timer.h file so that it loads the UNIX sys/time.h file (and thus tons of other files) (see os-include/devices/timer.mwild.path). I suggest that sys/time.h and devices/timer.h be modified to detect each other and use whichever structure was declared first (see os-include/devices/timer.jch.patch). The supplied include/sys/time.h file works this way. You can apply the patches with the program patch or by hand. The original devices/timer.h file is copyrighted by Commodore-Amiga and not included, but here is the patch: + #ifndef _SYS_TIME_H_ + /* Use whatever was included first, standard (sys/time.h) or Amiga + * includes (jch). */ struct timeval { ULONG tv_secs; ULONG tv_micro; }; + #else + #define tv_secs tv_sec + #define tv_micro tv_usec + #endif The sys/types.h defined BPTR causing conflicts with Amiga includes. I removed the BPTR definition from sys/types.h and sys/proc.h. In GCC233, there was no such definition either. I moved the ixemul.h file from include/ to the ixemlib/library/ directory. The ixemlib/ directory could contain the ixemul.library sources. In the ixemul source tree, ixemul.h is found in the library/ directory. Furthermore I patched it so that it is now able to compile a working ixconfig. It was broken (because of the broken ixemul.h) in GCC252/3/4. It previously worked in GCC233 but didn't provide the -e option. The ixemlib/library/version.h is an empty fake. I don't have a newer ixemul.h file. There's yet another minor patch I'd like to suggest: *** include/stdlib.h.orig=09Mon Aug 10 15:28:54 1992 --- include/stdlib.h=09Fri Dec 09 17:12:38 1993 *************** *** 72,76 **** --- 72,80 ---- void=09*calloc __P((size_t, size_t)); div_t=09 div __P((int, int)); + #if 0 void volatile exit __P((int)); + #else /* new ANSI-C interpretation */ + typedef void exit_t __P((int)); volatile exit_t exit; + #endif void=09 free __P((void *)); char=09*getenv __P((const char *)); =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ld (GNU linker) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Starting from 2.5.8 release, ld behaviour over symbols has changed. Default= is now to strip all symbols from generated executable ONLY if environment vari= able LDSTRIP is set (to whatever you want). Otherwise, '-s' flag will strip symb= ols, as usual. Also packing of uninitialized data will be done automatically if LDSHORTDAT= A is set (to whatever you want). Ld also knows about -chip and -fast keywords, gcc will soon handle them directly. Ld is using now flavours, which are generated depending on gcc flags: Gcc option=09Flavor passed to ld -m68020=09=09-fl libm020 -noixemul=09-fl libnix -resident=09-fl libb Thus ld when searching for libraries, adds those flavours to the library se= arch path, in alphabetical order. Normal search path is /gnu/lib, and if for example y= ou want to compile using -m68020 -noixemul ld will look for libgcc.a in: =09/gnu/lib/libm020/libnix first, then it will reduce flavours, one by one, if it can't find required = library in flavour's expanded path. This means that it will try to find libgcc.a in= : =09/gnu/lib/libm020 and in /gnu/lib/. Because libgcc.a exists in /gnu/lib/libm020, ld will tak= e this one. There is as for now 8 possibilities: Flavors=09=09Search path libb libm020 libnix 0 0 0=09/gnu/lib/=09=09=09normal 0 0 1=09/gnu/lib/libnix/=09=09non-ixemul 0 1 0=09/gnu/lib/libm020/=09=09normal 68020 0 1 1=09/gnu/lib/libm020/libnix/=09non-ixemul 68020 1 0 0=09/gnu/lib/libb/=09=09=09baserel 1 0 1=09/gnu/lib/libb/libnix/=09=09baserel non-ixemul 1 1 0=09/gnu/lib/libb/libm020/=09=09baserel 68020 1 1 1=09/gnu/lib/libb/libm020/libnix/=09baserel 68020 non-ix Using this approach makes adding flavours pretty easy, if someone wants for example to add 68881 libraries, a new flavour will have to be created, libm= 881, and thus the maximum flavour search path level would be: /gnu/lib/libb/libm020/libm881/libnix, which can be translated to English as= : "I want a base-relative library compiled using Motorola 68020 and coprocess= or 68881, not using ixemul.library". =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D GCC and its "pragmas" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From=20Gunther Nikl: Accessing operating-system functions on the Amiga requires to pass argument= s in specific processor registers. C, however, uses a different calling conve= ntion: it pushes all arguments in reverse order onto the stack, calls the function= and finally removes the arguments from the stack by simply correcting the stack= pointer. One solution to interface C and the calling convention for the system-funct= ions are so called "glue"-functions that convert arguments passed on the stack into = the OS-function convention. These glue routines are located for all system libr= aries in a link library named libamiga.a. Obviously this method is inefficient. M= ost Amiga C-compilers have the capability of in-line calls to OS functions usin= g a C language extension "#pragma". The format of a pragma statement and file= names differ from compiler to compiler. GCC supports in-line calls too but not wi= th pragmas. the GCC solution is based on the fact that GCC is able to integrat= e small functions into the caller. This method is known from C++ as "inlining". Thu= s functions that are declared "inline" (preferable in conjunction with the ke= yword static or extern but see the next chapter) get integrated. As you can see w= riting programs that compile with several compilers and use its capability of maki= ng in-line calls to libraries is a tricky thing. To get programs more portable between Amiga C-compilers a new set of includ= e files would be helpful that hide the different methods for in-line calls from the= user. These files are located in a drawer called proto e.g. "proto/exec.h". Inste= ad of writing (only an example!): =09#include =09#ifdef __GNUC__ =09#include =09#endif now the following should be used: =09#include to achieve the same result! Nice, isn't it? The general rule for the all fi= les is: =09#include with "xxx" replaced with the first part of a clib proto-headers name e.g. "exec_protos.h" becomes "exec.h" In general each file first includes its function prototype header then the = compiler specific "pragma" header and finally declares the library base extern. The = GCC files are in the following format: =09(1) include some C=3D headers to prevent errors with GCC =09(2) include the function prototypes from the clib drawer =09(3) include the inline header if this is not disabled and if optimizing =09(4) declare the library base extern if its not disabled Step 3 will only be executed if GCC is optimizing. Otherwise the compiler w= on't integrate any function. Even when optimizing it could be not desired to inc= lude the inline header because it requires some amount of memory and the compile= time enlarges significantly. Therefore step 3 can be disabled with: =09- a define on the command line "-D__NOINLINES__" =09=09=09or =09- a define before the proto headers are included "#define __NOINLINES__" Declaring the library base as an external variable can disabled with a defi= ne in the same way. The define is called "__NOLIBBASE__". This define can be usef= ul if its not desired to have the library base declared extern. Using the new proto headers has some advantages then using the clib and inl= ine files by itself: =09(1) better compatibility with SAS/C. It should be much easier to compile =09 programs developed for SAS/C with GCC - almost ;) no need to adjust =09 includes =09(2) almost ;) optimal code because depending on the optimization level =09 the best suited include set will be used =09(3) internal compiler specific requirements are hidden from the user For the exec.library the proto header has one additional goodie: it "implem= ents" SAS/C "_USEOLDEXEC_". Defining this forces to evaluate the absolute address= 4 every time the library base for the exec.library is required. In this case = no global library base is necessary but it must be noted that programs compile= d with this option enabled can have performance problems because AbsExecBase is lo= cated in Chip-Memory. Be aware: if using _USEOLDEXEC_ its *NOT* legal to declare = or define SysBase! If you do so strange things may happen ... Please note that= some function in libamiga.a require a global "SysBase" so that those functions c= annot be used. Some problems still remain but these restrictions come from the inline tech= nique. Library bases have to be global due to the nature of the inlines. SAS/C, ho= wever, is able to use local variables or structure elements as library bases. In t= his case the library bases has to be made global for GCC. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D inline headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D One major advantage of GCC is its ability to integrate simple functions int= o the caller. To direct the compiler to inline a function the keyword "inline" in combination with "static" or "extern" can be used. Previous version of the = inlines used static in the definition. This had the effect that functions compiled = to assembler if optimization is disabled. The new inline headers use extern de= finitions. Functions defined inline and extern can be considered as macros. That means= the definition is only used for inlining thus requiring linking with a library = containing stubs. From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 18:19:05 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90632-1>; Thu, 17 Aug 1995 17:58:27 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug17.175827+0300_eet_dst.90632-1+21@nic.funet.fi> From: To: Date: Thu, 17 Aug 1995 14:25:04 +0300 Date: Thu, 17 Aug 1995 13:24:59 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: New README-file for LIBNIX Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, This is a README for libnix where 'GCC', 'C', 'OS' and 'Amiga' is capitalized as appropiate (I hope). That sort of things. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ Readme for libnix ---------------------------------------------------------------- This is V1.0 of libnix. There are only a few changes worth mentioning from previous releases: * The long standing bug with floating point output is fixed. Please read the documentation of the SetMathPatch program by Andreas Wolff for more details. * There's now an auto stack extend feature. * starting with this release there is no installer script any more: GCC 2.7.0 has support for -fbaserel again, which makes GCC 2.3.3 obsolete. And since GCC 2.7.0 is prepared for libnix another installer script really isn't necessary. Short: A library for Amiga specific development on GCC Type: dev/gcc Uploader: fleischr@izfm.uni-stuttgart.de Author: fleischr@izfm.uni-stuttgart.de, gnikl@informatik.uni-rostock.de This is libnix, a static (i.e. link) library for GCC 2.3.3 or above. It's not a replacement for ixemul.library (though it's possible to recompile most of the GCC environment with libnix) but a good thing for Amiga specific development on GCC: * It's mostly compatible to SAS's way of handling things, i.e. you get even an automatic shared library opening feature and some other things you may miss in ixemul.library. This also means it's ANSI compliant. * It doesn't need any shared libraries other than normal Amiga OS ones. * It is not copyrighted by the FSF. Therefore you neither need to include sources nor objects together with your executable. (read the GLGPL _before_ flaming on this statement) * And it's short! I was able to compile a 492 byte 'hello, world' using normal main. * It uses OS 2.0 features whenever necessary. To cut it short: Use ixemul.library for porting Un*x programs, libnix for compiling Amiga-only programs and GCC becomes one of the best Amiga compilers. There is no need to download this archive if you use GCC 2.6.0 or above since the libraries itself are included with the normal GCC distribution. But if you use an older GCC version or if you want to get the sources you can take this package. But be warned: The ld that comes with earlier versions of GCC has some serious trouble with set elements. You cannot use libnix without the fixed linker that comes with GCC 2.6.0. From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 19:51:04 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90724-2>; Thu, 17 Aug 1995 18:58:34 +0300 Received: by ceylon.informatik.uni-rostock.de id RAA20192; Thu, 17 Aug 1995 17:58:22 +0200 Received: by honshu.informatik.uni-rostock.de id RAA27740; Thu, 17 Aug 1995 17:58:21 +0200 From: Gunther Nikl Message-Id: <199508171558.RAA27740@honshu.informatik.uni-rostock.de> Subject: Re: GCC270 & GS3.33 problems To: amiga-gcc-port@nic.funet.fi Date: Thu, 17 Aug 1995 17:58:21 +0200 (MET DST) In-Reply-To: from "joop van de wege" at Aug 17, 95 12:23:58 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 394 > I'm currently trying Lars' idea to compile with -O0 and -O1. > -O1 doesn't produce a correctly working executable. > -O0 is probably ready by now but I'm at work so I can't check but will mail > the results soon. Maybe you use a broken gas in your setup? Some version of gas > 1.x are known to poduce 68020 only instructions even if they should output 68000 instructions. Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Aug 17 19:51:20 1995 Received: from fiport.funet.fi ([128.214.109.150]) by nic.funet.fi with ESMTP id <90866-4>; Thu, 17 Aug 1995 18:59:35 +0300 Received: from zaz.kom.auc.dk by FIPORT.FUNET.FI (PMDF V5.0-3 #2494) id <01HU6TABMR5C00084N@FIPORT.FUNET.FI> for amiga-gcc-port@nic.funet.fi; Thu, 17 Aug 1995 18:10:38 +0200 (EET) Received: from skoda.kom.auc.dk (jds@skoda.kom.auc.dk [130.225.51.24]) by zaz.kom.auc.dk (8.6.12/8.6.12) with ESMTP id RAA11956; Thu, 17 Aug 1995 17:09:29 +0200 Received: (from jds@localhost) by skoda.kom.auc.dk (8.6.12/8.6.12) id RAA09760; Thu, 17 Aug 1995 17:09:27 +0200 Date: Thu, 17 Aug 1995 17:09:27 +0200 From: Jes Degn Soerensen Subject: Re: inline patches In-reply-to: To: Kamil Iskra Cc: Gunther Nikl , amiga-gcc-port@nic.funet.fi Message-id: <199508171509.RAA09760@skoda.kom.auc.dk> Content-transfer-encoding: 7BIT References: <199508140915.LAA04500@honshu.informatik.uni-rostock.de> Kamil Iskra writes: > > On Mon, 14 Aug 1995, Gunther Nikl wrote: > > > > Well, there are people that will be happy to create such a database for you. > > Fine, if anybody could update the perl-script. I am only able to run it :) > > If you are only able to run it, why do you like it so much? I am not even > able to run it, cause I don't have perl. Not to mention modifying it. Well perl is available for the Amiga aswell, so you can just dl it if you want to run the scripts. > That's why I would like to have "fd2inline.c" fully working and reliable. > IMHO "C" gererator has a lot of advantages: it's faster and easier to read > and modify. Frankly speaking, all I can see in perl-script are > DISadvantages. The fact that Markus Wild, first GCC porter, great UN*X fan, > made inlines generator in perl, doesn't mean that we still have to use it. The point is that it is a _lot_ easier to modify the perl-scripts than rewriting anything in C. Of course its not as fast as C, but does it matter that it takes a few minuttes more than a C-program when you run it very rarely? Actually its got a lot of advantages to keep that kind of scripts in perl, as they are easy to update, debug etc. as you don't need worry about all the things you do when you program C. Try looking a little more at it - its extreamly easy to work with. Everybody who understands C and knows about regular expressions can program/understand perl. Jes From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 16:29:18 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90760-2>; Fri, 18 Aug 1995 16:23:57 +0300 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id WAA19979; Thu, 17 Aug 1995 22:51:16 +0200 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id VAA02107; Thu, 17 Aug 1995 21:40:09 +0200 Date: Thu, 17 Aug 1995 21:40:09 +0200 From: Niklas Hallqvist Message-Id: <199508171940.VAA02107@linda.appli.se> To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95Aug17.175827+0300_eet_dst.90632-1+21@nic.funet.fi> (gc948374@gbar.dtu.dk) s/GLGPL/GNU LGPL/ IMHO. I've never seen it abbreviated as GLGPL.. It's been a while since I payed attentionto these issues however. NH Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 16:31:48 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90922-1>; Fri, 18 Aug 1995 16:25:44 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 17 Aug 95 23:19 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 17 Aug 95 23:15 MET DST Message-Id: Subject: Re: inline patches To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 17 Aug 1995 23:15:41 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 702 > Actually its got a lot of advantages to keep that kind of scripts in > perl, as they are easy to update, debug etc. as you don't need worry > about all the things you do when you program C. Try looking a little > more at it - its extreamly easy to work with. Everybody who understands > C and knows about regular expressions can program/understand perl. i have no idea about perl, but could we compromise at awk ? from the description above it seems it should work. awk because its coming as gawk from GNU and its not so long (in bytes) and more ready available than PERL. walter -- ----- "You know, I think it's just a matter of putting two and two together to make three..." ----- From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 16:32:20 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90285-4>; Fri, 18 Aug 1995 16:27:14 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sjDrw-0004nYC; Thu, 17 Aug 95 15:57 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: CLI scripts from pdksh To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Thu, 17 Aug 1995 15:56:59 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 490 I have just discovered that I'm unable to figure out how run amigados scripts from pdksh. I'm not sure if I just haven't found the right incantation yet, or if the environment set up when pdksh forks and runs something is somehow not acceptable to c:execute or a cli. I'm not up on the finer points of CLI and how c:execute fits into this picture. Can anyone provide a working example of how to run a cli and get it to execute a prefined script, that works from pdksh? Thanks. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 16:32:58 1995 Received: from zorn.mn.medstroms.se ([193.44.236.3]) by nic.funet.fi with SMTP id <90284-3>; Fri, 18 Aug 1995 16:26:57 +0300 Received: from maxinet (port3 [193.44.236.43]) by zorn.mn.medstroms.se (8.6.12/8.6.12) with SMTP id AAA26731 for ; Fri, 18 Aug 1995 00:54:37 +0200 Received: by maxinet.medstroms.se (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 18 Aug 95 00:55:08 Received: by maxinet.medstroms.se (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 18 Aug 95 00:53:48 From: erik.rissanen@mn.medstroms.se (Erik Rissanen) Message-Id: <2127a596.u7t150e.67297-erik.rissanen@mn.medstroms.se> Subject: termio.h Date: Fri, 18 Aug 95 00:53:48 To: amiga-gcc-port@nic.funet.fi Is there any for gcc and amiga? (I do not know what it is, but I was compiling an UNIX program which needs it.) --------------------------------------------------------------------- Erik Rissanen erik.rissanen@mn.medstroms.se I am sorry for my bad English. --------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 16:36:41 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <89881-3>; Fri, 18 Aug 1995 16:33:58 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Thu, 17 Aug 95 17:01:11 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <212736d4.u7t157e.89047-robert@plukwa.pdi.lodz.pl> Subject: Re: inline patches In-Reply-To: (from Kamil Iskra ) (at Thu, 17 Aug 1995 10:18:32 +0200 (MET DST)) Reply-To: robert@pdi.lodz.pl Content-Length: 1408 To: amiga-gcc-port@nic.funet.fi Date: Thu, 17 Aug 95 17:01:11 On Aug 17 Kamil Iskra wrote: > > > On Mon, 14 Aug 1995, Gunther Nikl wrote: > > > > Well, there are people that will be happy to create such a database for you. > > Fine, if anybody could update the perl-script. I am only able to run it :) > > If you are only able to run it, why do you like it so much? I am not even > able to run it, cause I don't have perl. Not to mention modifying it. > That's why I would like to have "fd2inline.c" fully working and reliable. > IMHO "C" gererator has a lot of advantages: it's faster and easier to read > and modify. Frankly speaking, all I can see in perl-script are > DISadvantages. The fact that Markus Wild, first GCC porter, great UN*X fan, > made inlines generator in perl, doesn't mean that we still have to use it. Kamil You CAN run perl scripts (although i didnt test that) there is perl version for Amiga. It is also great language. Just try it. > > > Gunther > > Kamil > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 18:38:04 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90251-3>; Fri, 18 Aug 1995 18:35:59 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 18 Aug 95 10:35:05 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <21282dd7.u7t157e.1461-robert@plukwa.pdi.lodz.pl> Subject: Re: your mail In-Reply-To: <95Aug17.175819+0300_eet_dst.90245-4+34@nic.funet.fi> (from ) (at Thu, 17 Aug 1995 14:16:31 +0300) Reply-To: robert@pdi.lodz.pl Content-Length: 1906 To: gc948374%gbar.dtu.dk@plearn.edu.pl Cc: amiga-gcc-port@nic.funet.fi Date: Fri, 18 Aug 95 10:35:05 On Aug 17 gc948374 wrote: > Hi, > > Here is a new readme file for GCC 2.7.0 with (hopefully) all errors > corrected. I know that it won't make it into the 2.7.0 release, but > maybe it can be used as a base for GCC 2.7.1? Why it won't make it into 2.7.0 release? I thought Philippe frozen only code... =o) I also foundone more bug(?) in GCC 2.7.0 readme. It mentions VMM40 and this way some misunderstanding may come up. It would be better to state that VMM is known to work with GCC (or vice-versa) > > > Regards, > _________________________________________________________________________ > / \ > | Rask Ingemann Lambertsen , | > | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | > | Keyboard error: and are stuck - press to continue | > \_________________________________________________________________________/ > > > Readme for GCC 2.7.0 > ---------------------------------------------------------------- > Short: gcc v2.7.0 - C/C++/ObjC Compiler set for AmigaDOS [snip.....snip] > VMM40 (Public Domain Virtual memory manager) is also known to work with GCC= VMM (Public Domain Virtual memory manager) is also known to work with GCC. [snip.....snip] regards, Robert Ps. I know that You guys love diff output, so sorry for not posting it this way =o) +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 18:38:52 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90075-2>; Fri, 18 Aug 1995 18:36:30 +0300 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id KAA02314 (8.6.12/IDA-1.6); Fri, 18 Aug 1995 10:49:20 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA01305; Fri, 18 Aug 95 10:49:20 +0200 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9508180849.AA01305@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: your mail To: kiskra@ernie.icslab.agh.edu.pl Date: Fri, 18 Aug 1995 10:49:19 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Aug 17, 95 10:19:28 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 497 > > IMHO using such a function as Supervisor() from programming language other > than assembler is rather problematic. Have anyone used it in "C"? And > what for? > Since the function you call with Supervisor() has to end with an rte (instead of the normal rts) it's not easy to write one in C :-). And if you write one in assembler it's (IMO) just as with any other subroutine. And the general rule is to not clobber d2-d7,a2-a6 unless you know what you're doing and really need it. Matthias From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 18:39:31 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89834-2>; Fri, 18 Aug 1995 18:37:48 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 18 Aug 1995 12:16:57 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA13314; Fri, 18 Aug 95 12:16:56 +0200 Date: Fri, 18 Aug 95 12:16:56 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508181016.AA13314@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA04550; Fri, 18 Aug 95 12:16:57 +0200 To: amiga-gcc-port@nic.funet.fi Subject: questions about cpp and gccv Hi, does anybody have a clue why cpp tries to allocate a huge memory block (it certainly depends on the size of the thing compiled) towards the end of it's run? For example, with CLISP, it wants nearly 2MB which I haven't left at that time. The allocation fails, but everything works fine. However this causes an Exec Flush everytime cpp is run. Has anybody tested the usefullness of gccv? I found it to be much slower than gcc, it takes much more RAM (instead of temporary HD space), so what's the point in using it? (I didn't test with gccv-270, my results are based on 258). Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 18:41:31 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <89513-4>; Fri, 18 Aug 1995 18:39:43 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HU7YRMLAM8009D7N@NET2.WAU.NL>; Fri, 18 Aug 1995 13:58:08 +0000 (GMT) Received: by vines2.wau.nl; Fri, 18 Aug 95 14:02:09 +0100 Resent-date: Fri, 18 Aug 1995 00:43:00 +0000 (GMT) Date: Fri, 18 Aug 1995 13:58:08 +0000 (GMT) Date-warning: Date header was inserted by NET2.WAU.NL Resent-from: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) From: ghost@aladdin.com (L. Peter Deutsch) Resent-To: Subject: Re: Ghostscript3.33 error on Amiga's: Peter Help ; ) To: amiga-gcc-port@lists.funet.fi Resent-message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Forwarded to: in%[amiga-gcc-port@lists.funet.fi] cc: Comments by: Joop van de Wege@Medew@ENTO.WAU Comments: I got the following message from the Alladin maintainer. As a side note. I read the message from Gunther about the broken gas. I'm using 2.7.0 (beta 3-aug) so thats quite unlikely, not to mention that I'm compiling for -m68000 but *running* it on a A3000 with an mc68030 So even when using a broken gas which inserts 020 code at the beginning it should still work. GS doesn't crash at startup, it prints a lot of garbage to CON: while initializing. See my previous post which includes my capture of CON: (Thanks to KingCON) A couple of people are using my -m68020-40 version on: A1200 +030 A3000 030 A4000 040 A4000 030 No problems reported sofar. Thanks, Joop -------------------------- [Original Message] ------------------------- > What I don't understand is why some device drivers > (deskjet/laserjet/epson/tiffpack) work and some don't (tifflzw/ppm) when > compiled for mc68000. > What kind of black magic do they perform that only breaks on mc68000? I don't understand this either. The only thing that I can think of is that the tifflzw and the ppm drivers make much heavier use of shifting operations. But this shouldn't have any connection with the use of the 68020 or 68881 instructions. L. Peter Deutsch | Aladdin Enterprises :::: ghost@aladdin.com 203 Santa Margarita Ave. | Artifex Software Inc. :: tech@arsoft.com Menlo Park, CA 94025 | tel. +1-415-322-0103 (AM only) fax +1-415-322-1734 "Implementation is the sincerest form of flattery." From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 18:43:35 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90268-2>; Fri, 18 Aug 1995 18:42:15 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id PAA05304; Fri, 18 Aug 1995 15:38:00 +0200 Date: Fri, 18 Aug 1995 15:37:59 +0200 (MET DST) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: inline patches To: Matthias Fleischer cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9508140917.AA06371@sunserv.IZFM.Uni-Stuttgart.DE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Mon, 14 Aug 1995, Matthias Fleischer wrote: > -----newinline.c----- > #include > > struct ExecBase; > > #define LP2(num,rt,name,t1,v1,r1,t2,v2,r2,bt,bn,br) \ > ({ \ > __inline rt name(t1 __n1,t2 __n2) \ > { \ > register rt _re __asm(D0); \ > register bt _bn __asm(br) = (bn); \ > register t1 _n1 __asm(r1) = __n1; \ > register t2 _n2 __asm(r2) = __n2; \ > __asm __volatile ("jsr a6@(-6*"#num":W)" \ > :"=r"(_re) \ > :"r"(_n1),"r"(_n2),"r"(_bn) \ > :D0,D1,A0,A1,"cc","memory"); \ > return _re; \ > } \ > name(v1,v2); \ > }) > > #define D0 "d0" > #define D1 "d1" > #define A0 "a0" > #define A1 "a1" > #define A6 "a6" > > #define AllocMem(byteSize,attributes) \ > LP2(33,APTR,AllocMem,ULONG,byteSize,D0,ULONG,attributes,D1, \ > struct ExecBase *,SysBase,A6) Seems it is an EXCELENT idea. But could you please tell me why there is inline-function needed? Wouldn't it be easier if the macro looked like this: #define LP2(num,rt,name,t1,v1,r1,t2,v2,r2,bt,bn,br) \ ({ \ register rt _re __asm(D0); \ register bt _bn __asm(br) = (bn); \ register t1 _n1 __asm(r1) = v1; \ register t2 _n2 __asm(r2) = v2; \ __asm __volatile ("jsr a6@(-6*"#num":W)" \ :"=r"(_re) \ :"r"(_n1),"r"(_n2),"r"(_bn) \ :D0,D1,A0,A1,"cc","memory"); \ _re; \ }) This way it would also work without optimisation turned on. I haven't tried it, though. BTW: Does anyone have an idea how to improve vararg-stub calls, such as intuition.library/OpenWindowTags() or dos.library/Printf()? When optimisation is turned on, GCC produces incorrectly warnings about implicit conversion from pointer to scalar in the following code: win=OpenWindowTags(0, WA_Title, "Title", TAG_DONE); Printf("abc: %s\n", "def"); This is because inline vararg-stub calls are implemented as preprocessor macros, so the above calls are actually: win=({ struct TagItem _tags[]= { WA_Title, "Title" /* Here's the problem */, TAG_DONE }; OpenWindowTagList(0, _tags); }); ({ struct TagItem _tags[]={"def" /* Here's the problem */}; VPrintf("abc: %s\n", _tags); }); I have no idea how to fix it. But maybe someone with better knowledge of GCC will have something to say... / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 18:44:51 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90054-1>; Fri, 18 Aug 1995 18:43:23 +0300 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id QAA06227 (8.6.12/IDA-1.6); Fri, 18 Aug 1995 16:12:54 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA01828; Fri, 18 Aug 95 16:12:54 +0200 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9508181412.AA01828@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: inline patches To: kiskra@ernie.icslab.agh.edu.pl Date: Fri, 18 Aug 1995 16:12:53 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Aug 18, 95 03:37:59 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 921 > Seems it is an EXCELENT idea. But could you please tell me why there is > inline-function needed? It's not really needed :-). It's there to get the right error messages in case you used the wrong argument types. > Wouldn't it be easier if the macro looked like > this: > [...] > This way it would also work without optimisation turned on. I haven't > tried it, though. The inline version also works without optimization. I tried it. Only the code is worse. > BTW: Does anyone have an idea how to improve vararg-stub calls, such as > intuition.library/OpenWindowTags() or dos.library/Printf()? #define OpenWindowTags(newWindow,tagItem,args...) \ ({ \ inline struct Window *OpenWindowTags \ (struct NewWindow *_1,struct TagItem *_2,...) \ { return OpenWindowTagList(_1,&_2); } \ OpenWindowTags(newWindow,tagItem,##args); \ }) It's just an idea. I didn't test it yet. So long. Matthias From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 18:46:01 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90751-2>; Fri, 18 Aug 1995 18:44:06 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id QAA05816; Fri, 18 Aug 1995 16:43:04 +0200 Date: Fri, 18 Aug 1995 16:43:03 +0200 (MET DST) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: inline patches To: Matthias Fleischer cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9508181412.AA01828@sunserv.IZFM.Uni-Stuttgart.DE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Fri, 18 Aug 1995, Matthias Fleischer wrote: > > Seems it is an EXCELENT idea. But could you please tell me why there is > > inline-function needed? > > It's not really needed :-). It's there to get the right error messages > in case you used the wrong argument types. But the same messages should be generated in "my" version, too (well, I haven't tried yet). This is because of the following lines: #define LP2(num,rt,name,t1,v1,r1,t2,v2,r2,bt,bn,br) \ ({ \ register rt _re __asm(D0); \ register bt _bn __asm(br) = (bn); \ ** register t1 _n1 __asm(r1) = v1; \ ** register t2 _n2 __asm(r2) = v2; \ /* If v1 or v2 are of wrong type, warning will be generated */ __asm __volatile ("jsr a6@(-6*"#num":W)" \ :"=r"(_re) \ :"r"(_n1),"r"(_n2),"r"(_bn) \ :D0,D1,A0,A1,"cc","memory"); \ ** _re; \ /* If result is assinged to variable of wrong type, warning will be generated */ }) > The inline version also works without optimization. I tried it. > Only the code is worse. Yeah, I tried it, too. But the code quality is very poor. I think that calling stubs in libamiga.a would most probably create better code. However, if somebody wants a code of good quality, [s]he should turn on optimisation :-). > > BTW: Does anyone have an idea how to improve vararg-stub calls, such as > > intuition.library/OpenWindowTags() or dos.library/Printf()? > > #define OpenWindowTags(newWindow,tagItem,args...) \ > ({ \ > inline struct Window *OpenWindowTags \ > (struct NewWindow *_1,struct TagItem *_2,...) \ > { return OpenWindowTagList(_1,&_2); } \ > OpenWindowTags(newWindow,tagItem,##args); \ > }) > > It's just an idea. I didn't test it yet. I tried something similar yesterday. The problem is that vararg-function cannot be inlined :-(. > > So long. > > Matthias > Kamil From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 18:47:50 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90832-3>; Fri, 18 Aug 1995 18:43:11 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id PAA05512; Fri, 18 Aug 1995 15:53:34 +0200 Date: Fri, 18 Aug 1995 15:53:33 +0200 (MET DST) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: inline patches To: Walter Harms cc: amiga gcc-list In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Thu, 17 Aug 1995, Walter Harms wrote: > > Actually its got a lot of advantages to keep that kind of scripts in > > perl, as they are easy to update, debug etc. as you don't need worry > > about all the things you do when you program C. Try looking a little > > more at it - its extreamly easy to work with. Everybody who understands > > C and knows about regular expressions can program/understand perl. > > > i have no idea about perl, but could we compromise > at awk ? from the description above it seems it > should work. awk because its coming as gawk from > GNU and its not so long (in bytes) and more > ready available than PERL. I know this will sound rather conservative, but why do you all insist on using anything but "C"? ALL people who use GCC know "C" and most probably only a small fraction of people who use GCC know "perl" or "awk". Take for example Gunther Nikl, "GCC inlines" maintainer, who can only RUN perl script (no offence, Gunther :-). All other Amiga compilers that I have seen have nice, easy-to-use converter from FD-files to pragmas/inlines/ whatever. > walter Kamil From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 18:48:23 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90668-1>; Fri, 18 Aug 1995 18:41:58 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 18 Aug 1995 15:31:46 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA13772; Fri, 18 Aug 95 15:31:41 +0200 Date: Fri, 18 Aug 95 15:31:41 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508181331.AA13772@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA04610; Fri, 18 Aug 95 15:31:40 +0200 To: amiga-gcc-port@nic.funet.fi Subject: including some PD .c or .h files into GCC Hi, what do you think about the inclusion of a few "goodies" into the GCC archives. I have mostly .h files that do various things, like inline strlen() macros and a dotimes() macro that compiles to dbra loops. Others include a very small BPTRprintf using the exec.library RawDoFmt (like the one in the GURU book, but hopefully without the bugs there :-( Did you know that only few for (i=n; i; i--) {} style loops compile to dbra instructions? Use my dotimes() etc. macros instead! The contributions should remain small, so that one can have a good oversight. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 18:48:57 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90277-1>; Fri, 18 Aug 1995 18:37:27 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 18 Aug 1995 12:00:11 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA13234; Fri, 18 Aug 95 12:00:07 +0200 Date: Fri, 18 Aug 95 12:00:07 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508181000.AA13234@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA04543; Fri, 18 Aug 95 12:00:05 +0200 To: amiga-gcc-port Subject: New README-file for LIBNIX In-Reply-To: <95Aug17.175827+0300_eet_dst.90632-1+21@nic.funet.fi> References: <95Aug17.175827+0300_eet_dst.90632-1+21@nic.funet.fi> gc948374@gbar.dtu.dk writes: > * It uses OS 2.0 features whenever necessary. Shouldn't one say that except for libtiny (or what is it called?), linking with libnix will make the executable _require_ an OS 2.0 (or better) execution environment? > But if you use an older GCC version or if you want to get the sources > you can take this package. But be warned: The ld that comes with earlier > versions of GCC has some serious trouble with set elements. You cannot > use libnix without the fixed linker that comes with GCC 2.6.0. What about the very old linker (before the dreaded binutils time)? Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 18:49:28 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <89181-3>; Fri, 18 Aug 1995 18:37:29 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 18 Aug 1995 12:07:51 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA13259; Fri, 18 Aug 95 12:07:50 +0200 Date: Fri, 18 Aug 95 12:07:50 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508181007.AA13259@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA04544; Fri, 18 Aug 95 12:07:51 +0200 To: amiga-gcc-port Subject: New README for GCC 2.7.0 In-Reply-To: <95Aug17.175819+0300_eet_dst.90245-4+34@nic.funet.fi> References: <95Aug17.175819+0300_eet_dst.90245-4+34@nic.funet.fi> [Rask posted the new README here] Help, please avoid the MIME quoted-printable format, a file that long is unreadable without MIME decoder and I won't get sysadmins to handle that topic soon (am I the only one?). I very much prefer to read a file with lost 8-bit chars (there aren't many in english files anyway) than this stuff, even if my own name gets damaged in the file :-). Send Philippe a uuencoded version if you don't want the real file to loose characters. BTW, with your (or funet's) lost header problem, no mail-reader will recognize your mail as being MIME-encoded and thus not display it correctly... Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 18:49:50 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90424-1>; Fri, 18 Aug 1995 18:36:09 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HU7S72B6Y8009CTQ@NET2.WAU.NL>; Fri, 18 Aug 1995 10:49:45 +0000 (GMT) Received: by vines2.wau.nl; Fri, 18 Aug 95 10:53:44 +0100 Date: Fri, 18 Aug 1995 09:56:08 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: GCC &G To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi all, I wrote and I quote: >I'm currently trying Lars' idea to compile with -O0 and -O1. >-O1 doesn't produce a correctly working executable. >-O0 is probably ready by now but I'm at work so I can't check but will mail >the results soon. Well, -O0 doesn't work either. End of story. Summary. With gcc2.6.3: -m68000 doesn't work -m68020 doesn't work -m680x0 -m68881 *DOES* work with x being 2 or higher. With gcc2.7.0 (beta from 3-Aug) -m68000 (-O0/-O1/-O2) doesn't work -m68020 *DOES* work -m68020 -m68881 does work -m68020-40 does work -m68020-40 -m68881 does work FPU_TYPE setting in the makefile (-1/0/1/2) doesn't make a difference. Anyone knows what has changed from 263 to 270 concerning -m68020 because in 270 it is a usable option and with 263 it isn't. Some remarks. This is the first program that obviously doesn't work correctly when compiled for mc68000 but lots and lots of others do work correctly one might suggest that Ghostscript has some kind of error, which seems a bit unlikely and the guy from Alladin thinks so too :( So is it GCC? Could be because it gets better when I switch to 2.7.0 Anyone else with good ideas. I know I asked before. This is what I get printed to CON: (without the 8bit characters) I also have available a zipfile with output from -Zi/-ZI/-Zn for a working and non-working version. 9.Develop:gnu/gs3.33> gsO0-m680002 -sDEVICE=pcxmono -sOutputFile=ram:test Aladdin Ghostscript 3.33 (4/10/1995) Copyright (C) 1995 Aladdin Enterprises, Menlo Park, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Unrecoverable error: rangecheck in get Operand stack: 256 Unexpected interpreter error -15. Error object: (f80)op(101:get)0x75a0a1c Operand stack at 0x7346038: 0x7348dd8: 0x12 str --Gwrx--- 0x0100 0x0743a8d4 0x7348de0: 0x0b int --F------ 0x08d4 0x00000100 = 256 Execution stack at 0x7345e64: 0x734a740: 0x0f oper --F---e-- 0x0000 0x07589040 = %interp_exit 0x734a748: 0x03 file --G-rxe-- 0x0001 0x073fc984 0x734a750: 0x05 mpry --G-rxe-- 0x0004 0x07438362 0x734a758: 0x0e null --F---e-- 0x0000 0x075af3f6 0x734a760: 0x0f oper --F---e-- 0x0000 0x075af2d6 = %setscreen_finish 0x734a768: 0x05 mpry --G-rxe-- 0x0013 0x074382dc 0x734a770: 0x08 STRC --G------ 0x0001 0x07439168 0x734a778: 0x0f oper --F---e-- 0x0000 0x075af24e = %set_screen_continue 0x734a780: 0x05 mpry --G-rxe-- 0x0002 0x07438310 0x734a788: 0x05 mpry --G-rxe-- 0x0039 0x073fdaf8 9.Develop:gnu/gs3.33> Below you'll find the output of gs including all kinds of funny characters which my mailer won't let me import so its uuencoded. section 1 of uuencode 5.10 of file gs.out by R.E.M. table `!"#$%&'()*+,-./0123456789:;<=>? @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ begin 644 gs.out M.2Y$979E;&]P.F=N=2]G7)I9VAT("A#*2`Q.3DU($%L861D M:6X@16YT97)PGC:V M%I8\O!R<-+04E/Y^WE[V=M96_'S<7/1TU%0!@2&A("")*:D#@R.C"HLKJ\%! MX6')2>EIPT/C8\M+ZVLQL1&1.;D9F3.S$Y,[N]%1^7G96?-STU/[>]M;"BVM M!0HEI8\OKX5EST_O;\='YV<]O1V=-;45E3^_'Y\WMQ>7_7W= M7?5UU57_?]]?]W?75P*"(J(*BBJJ@""@B"BHPD+B8LI*ZFK`0.!@R$CH:#*R M$I(ZNAJ:,+`0D#BX&)CR-A8"@I5;F5X<&5C=&5D(&EN M=&5R<')E=&5R(&5R##!B(&EN="`@+2U&+2TM+2TM(#!X,#AD-"`P>#`P M,#`P,3`P(#T@,C4V"D5X96-U=&EO;B!S=&%C:R!A="`P>##`P,#`@,'@P-S4X.3`T M,"`]("5I;G1E##`U(&UP#`W-#,X,S8R"C!X-S,T83#`P,#`@,'@P-S5A9C-F-@HP>##2`M+4#`X(%-44D,@+2U'+2TM+2TM(#!X M,#`P,2`P>#`W-#,Y,38X"C!X-S,T83#`P,#`@,'@P-S5A9C(T92`]("5S971?&4M+2`P>#`P,#(@,'@P-S0S.#,Q M,`HP>#2`M+4; Fri, 18 Aug 1995 18:57:28 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 18 Aug 95 17:56:41 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <21289434.u7t157e.d6493-robert@plukwa.pdi.lodz.pl> Subject: Re: inline patches In-Reply-To: (from Kamil Iskra ) (at Fri, 18 Aug 1995 15:53:33 +0200 (MET DST)) Reply-To: robert@pdi.lodz.pl Content-Length: 1306 To: iskra@student.uci.agh.edu.pl Cc: amiga-gcc-port@nic.funet.fi Date: Fri, 18 Aug 95 17:56:41 On Aug 18 Kamil Iskra wrote: > > > I know this will sound rather conservative, but why do you all insist on > using anything but "C"? ALL people who use GCC know "C" and most probably > only a small fraction of people who use GCC know "perl" or "awk". Take for > example Gunther Nikl, "GCC inlines" maintainer, who can only RUN perl > script (no offence, Gunther :-). All other Amiga compilers that I have > seen have nice, easy-to-use converter from FD-files to pragmas/inlines/ > whatever. Kamil You have some rights but You must remeber that most of us (at last I think so) is used to UNIX enviroment where awk, perl and some more other things are more common than anything else. So it's rather normal to use all the available tools that are ported from UNIX to Amiga including awk and perl. Awk and perl are actually very valuable tools that can do magic when You know how to use them. Just try to get used to them and all will be fine. Ok perl might be complicated at first but awk is rather simple at first. (I already know that You are traditionalist but give them a chance!!!) > > > Kamil > Robert Ps. Once more i'm begging someone to send me working libauto.a i need it badly and it would be stupid to download whole gcc263-inclib.lha just to get ~30 Kb file. Please please!!!!!!! From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 19:22:48 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <90876-1>; Fri, 18 Aug 1995 19:22:11 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id SAA17930 (8.6.10/2.4); Fri, 18 Aug 1995 18:22:29 +0200 Date: Fri, 18 Aug 1995 18:22:29 +0200 From: Olaf Seibert Message-Id: <199508181622.SAA17930@septimius.mbfys.kun.nl> To: kiskra@ernie.icslab.agh.edu.pl Subject: Re: inline patches Cc: amiga-gcc-port@nic.funet.fi Kamil Iskra wrote: > #define LP2(num,rt,name,t1,v1,r1,t2,v2,r2,bt,bn,br) \ > ({ \ > register rt _re __asm(D0); \ > register bt _bn __asm(br) = (bn); \ > ** register t1 _n1 __asm(r1) = v1; \ > ** register t2 _n2 __asm(r2) = v2; \ > /* If v1 or v2 are of wrong type, warning will be generated */ > __asm __volatile ("jsr a6@(-6*"#num":W)" \ > :"=r"(_re) \ > :"r"(_n1),"r"(_n2),"r"(_bn) \ > :D0,D1,A0,A1,"cc","memory"); \ > ** _re; \ > /* If result is assinged to variable of wrong type, warning will be generated */ > }) Don't forget that just declaring register variables this way does *NOT* save the old contents if it needs to be saved!! Try to nest a few of these calls and see what happens. -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 22:06:47 1995 Received: from xs1.xs4all.nl ([193.78.33.42]) by nic.funet.fi with SMTP id <89944-3>; Fri, 18 Aug 1995 22:06:01 +0300 Received: from localhost (asd03-17.dial.xs4all.nl) by xs1.xs4all.nl with SMTP id AA25133 (5.67b/IDA-1.5 for ); Fri, 18 Aug 1995 21:05:34 +0200 Received: by localhost.dial.xs4all.nl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 18 Aug 95 21:03:17 Received: by asd05-21.dial.xs4all.nl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 18 Aug 95 17:49:07 From: jtv@asd05-21.dial.xs4all.nl (Jeroen T. Vermeulen) Message-Id: <21289391.u7t157e.a198e-jtv@asd05-21.dial.xs4all.nl> Subject: Re: your mail In-Reply-To: <21282dd7.u7t157e.1461-robert@plukwa.pdi.lodz.pl> (from robert@plukwa.pdi.lodz.pl (Robert Ramiega)) (at Fri, 18 Aug 95 10:35:05) Reply-To: jtv@xs4all.nl Date: Fri, 18 Aug 95 17:49:07 Organization: Leiden University, Mathematics & Computer Science, The Netherlands To: amiga-gcc-port@nic.funet.fi On Aug 18, robert@pdi.lodz.pl wrote: > > VMM40 (Public Domain Virtual memory manager) is also known to work with GCC= > VMM (Public Domain Virtual memory manager) is also known to work with GCC. It's not public domain anymore. VMM 3.1 is shareware (and works fine with gcc). > +--------------------------------+----------------------------------------+ > | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | > | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | > +--------------------------------+----------------------------------------+ > | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | > +-------------------------------------------------------------------------+ Jeroen From amiga-gcc-port-owner@nic.funet.fi Fri Aug 18 23:24:57 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90132-3>; Fri, 18 Aug 1995 23:24:27 +0300 Received: from INVALID (actually host skien102.telepost.no) by funet.fi with SMTP (PP); Fri, 18 Aug 1995 23:24:37 +0300 Received: by INVALID.telepost.no (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 18 Aug 95 22:24:21 Received: by INVALID.telepost.no (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 18 Aug 95 22:16:34 Date: Fri, 18 Aug 1995 22:16:34 +0000 () From: Erik Johannessen X-Sender: erij@localhost Subject: Re: your mail In-Reply-To: <21289391.u7t157e.a198e-jtv@asd05-21.dial.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: amiga-gcc-port@nic.funet.fi On Fri, 18 Aug 1995, Jeroen T. Vermeulen wrote: > On Aug 18, robert@pdi.lodz.pl wrote: > > > > VMM40 (Public Domain Virtual memory manager) is also known to work with GCC= > > VMM (Public Domain Virtual memory manager) is also known to work with GCC. I'm running VMM 3.0 on an A4000 Cyberstorm 040 system. Using gcc-2.7.0 (3-Aug) together with VMM gives horrible crashes. My machine just resets without giving a software failure. I had no problems using gcc-2.6.3 together with VMM 3.0 on a normal A4000/040. I haven't looked at it yet, but could the stack extension code cause such behaviour? Can someone else please do some tests? > > It's not public domain anymore. VMM 3.1 is shareware (and works > fine with gcc). ^^^ 2.7.0? -Erik From amiga-gcc-port-owner@nic.funet.fi Sat Aug 19 01:19:40 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90945-4>; Sat, 19 Aug 1995 01:18:42 +0300 Received: by colombo.telesys-innov.fr; Sat, 19 Aug 1995 00:18:23 +0100 From: Philippe BRAND Message-Id: <199508182318.AAA20323@colombo.telesys-innov.fr> Subject: Re: including some PD .c or .h files into GCC To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Sat, 19 Aug 1995 00:18:23 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9508181331.AA13772@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 18, 95 03:31:41 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 349 Joerg-Cyril Hoehle writes: > what do you think about the inclusion of a few "goodies" into the GCC Yep ok... Write small doc and send a complete archive to me. Thanks. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sat Aug 19 01:31:34 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90950-1>; Sat, 19 Aug 1995 01:31:13 +0300 Received: by colombo.telesys-innov.fr; Sat, 19 Aug 1995 00:31:00 +0100 From: Philippe BRAND Message-Id: <199508182331.AAA20394@colombo.telesys-innov.fr> Subject: Re: questions about cpp and gccv To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Sat, 19 Aug 1995 00:30:59 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9508181016.AA13314@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 18, 95 12:16:56 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1047 Joerg-Cyril Hoehle writes: > does anybody have a clue why cpp tries to allocate a huge memory block > (it certainly depends on the size of the thing compiled) towards the > end of it's run? For example, with CLISP, it wants nearly 2MB which I > haven't left at that time. The allocation fails, but everything works > fine. However this causes an Exec Flush everytime cpp is run. No idea as for now. > Has anybody tested the usefullness of gccv? I found it to be much > slower than gcc, it takes much more RAM (instead of temporary HD > space), so what's the point in using it? (I didn't test with gccv-270, > my results are based on 258). gccv uses a different startup code for child processes, which lets you use -pipe option, saving time for compilations, as output of process 1 is given immediatly via pipe (IXPIPE) to process 2, this avoiding temporary files. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sat Aug 19 01:34:33 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90035-4>; Sat, 19 Aug 1995 01:34:15 +0300 Received: by colombo.telesys-innov.fr; Sat, 19 Aug 1995 00:33:58 +0100 From: Philippe BRAND Message-Id: <199508182333.AAA20410@colombo.telesys-innov.fr> Subject: Re: New README-file for LIBNIX To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Sat, 19 Aug 1995 00:33:57 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9508181000.AA13234@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 18, 95 12:00:07 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 824 Joerg-Cyril Hoehle writes: > > But if you use an older GCC version or if you want to get the sources > > you can take this package. But be warned: The ld that comes with earlier > > versions of GCC has some serious trouble with set elements. You cannot > > use libnix without the fixed linker that comes with GCC 2.6.0. > What about the very old linker (before the dreaded binutils time)? Could someone take in charge README corrections, etc... for GCc ? I really don't have much time those days, being busy with both my BBS which is getting larger, and above all with my wife which's gonna have pretty son (mid-september) a baby. Thanks. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sat Aug 19 02:19:53 1995 Received: from zaz.kom.auc.dk ([130.225.51.10]) by nic.funet.fi with SMTP id <90737-4>; Sat, 19 Aug 1995 02:19:02 +0300 Received: from skoda.kom.auc.dk (jds@skoda.kom.auc.dk [130.225.51.24]) by zaz.kom.auc.dk (8.6.12/8.6.12) with ESMTP id BAA04228; Sat, 19 Aug 1995 01:18:54 +0200 Received: (from jds@localhost) by skoda.kom.auc.dk (8.6.12/8.6.12) id BAA22386; Sat, 19 Aug 1995 01:18:52 +0200 Date: Sat, 19 Aug 1995 01:18:52 +0200 Message-Id: <199508182318.BAA22386@skoda.kom.auc.dk> From: Jes Degn Soerensen To: Kamil Iskra Cc: Walter Harms , amiga gcc-list Subject: Re: inline patches In-Reply-To: References: Kamil Iskra writes: > > I know this will sound rather conservative, but why do you all insist on > using anything but "C"? ALL people who use GCC know "C" and most probably > only a small fraction of people who use GCC know "perl" or "awk". Take for > example Gunther Nikl, "GCC inlines" maintainer, who can only RUN perl > script (no offence, Gunther :-). All other Amiga compilers that I have > seen have nice, easy-to-use converter from FD-files to pragmas/inlines/ > whatever. Well its quite simple: Perl (and the other stream oriented programs like sed and awk) is designed to work on text-strings - "C" is much more complicated. When you program in Perl you only have to think about what you wan't to do with your text-strings - you can forget all the stuff that eats up 90% of your programming time: pointers, file-handles, structures, data-types etc. As my boss used to say: "Anything can be done within 5 lines of Perl - well 6 if its really advanced" :-) Perl is not very well known outside the circles of UNiX system-administrators, but its one of the best things invented since emacs. And yes there is a well-working port of Perl 4.035 for the Amiga, that should be available on Aminet (I used it to program a few scripts for work some months ago). I'm still waiting for someone to port V5.00x though. Regards, Jes From amiga-gcc-port-owner@nic.funet.fi Sat Aug 19 13:00:32 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90118-3>; Sat, 19 Aug 1995 12:59:48 +0300 Received: by ceylon.informatik.uni-rostock.de id LAA04621; Sat, 19 Aug 1995 11:59:41 +0200 Received: by honshu.informatik.uni-rostock.de id LAA24378; Sat, 19 Aug 1995 11:59:39 +0200 From: Gunther Nikl Message-Id: <199508190959.LAA24378@honshu.informatik.uni-rostock.de> Subject: Re: including some PD .c or .h files into GCC To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Sat, 19 Aug 1995 11:59:38 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9508181331.AA13772@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 18, 95 03:31:41 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 959 Hi! > what do you think about the inclusion of a few "goodies" into the GCC > archives. I have mostly .h files that do various things, like inline > strlen() macros and a dotimes() macro that compiles to dbra loops. Did you notice that inline/ contains a rather small file called 'strsup.h' ? This file contains some string functions defined as inline calls (implementation taken from libnix :-) I personally added this file as include at the end of my "string.h". This was suggested some time ago, then there was a dicussion about such functions here on the list. > Others include a very small BPTRprintf using the exec.library > RawDoFmt (like the one in the GURU book, but hopefully without the > bugs there :-( What bugs do you refer to? I couldn't find one... I even have 'GuruStartup.a' made useable from gcc (now I cam simply add -guru at the final link stage and it uses guru.o as startup-code) Works pretty well. Gunther From amiga-gcc-port-owner@nic.funet.fi Sat Aug 19 13:07:33 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90807-3>; Sat, 19 Aug 1995 13:07:09 +0300 Received: by ceylon.informatik.uni-rostock.de id MAA04635; Sat, 19 Aug 1995 12:07:05 +0200 Received: by honshu.informatik.uni-rostock.de id MAA24386; Sat, 19 Aug 1995 12:07:03 +0200 From: Gunther Nikl Message-Id: <199508191007.MAA24386@honshu.informatik.uni-rostock.de> Subject: Re: New README-file for LIBNIX To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Sat, 19 Aug 1995 12:07:02 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9508181000.AA13234@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 18, 95 12:00:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1039 > Shouldn't one say that except for libtiny (or what is it called?), Mhm, please help: what do you mean with libtiny? I have no clue... > linking with libnix will make the executable _require_ an OS 2.0 (or > better) execution environment? The thing that it depends. All stdio related stuff needs 2.0 to run, however, memory management does work with 1.2 and up. But I am not sure I one is allowed to take this knowledge into account. > > But if you use an older GCC version or if you want to get the sources > > you can take this package. But be warned: The ld that comes with earlier > > versions of GCC has some serious trouble with set elements. You cannot > > use libnix without the fixed linker that comes with GCC 2.6.0. > What about the very old linker (before the dreaded binutils time)? The current used ld is still the one from the 1.8 binutils distribution, but bugfixed. All ld's from previous gcc releases ( <2.6.0 ) are *NOT* useable for libnix (noixemul). They will produce *broken* programs. Gunther From amiga-gcc-port-owner@nic.funet.fi Sat Aug 19 15:16:22 1995 Received: from xs1.xs4all.nl ([193.78.33.42]) by nic.funet.fi with SMTP id <90032-2> convert rfc822-to-8bit; Sat, 19 Aug 1995 15:15:51 +0300 Received: from asd06-17 (asd06-17.dial.xs4all.nl) by xs1.xs4all.nl with SMTP id AA28694 (5.67b/IDA-1.5 for ); Sat, 19 Aug 1995 14:15:24 +0200 Received: by asd06-17.dial.xs4all.nl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sat, 19 Aug 95 14:13:07 Received: by asd07-21.dial.xs4all.nl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sat, 19 Aug 95 00:03:44 From: jtv@asd07-21.dial.xs4all.nl (Jeroen T. Vermeulen) Message-Id: <2128eb3b.u7t157e.89636-jtv@asd07-21.dial.xs4all.nl> Subject: Re: VMM & gcc In-Reply-To: (from Erik Johannessen ) (at Fri, 18 Aug 1995 22:16:34 +0000 ()) Reply-To: jtv@xs4all.nl Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT Date: Sat, 19 Aug 95 00:03:44 Organization: Leiden University, Mathematics & Computer Science, The Netherlands To: amiga-gcc-port@nic.funet.fi > > > > VMM40 (Public Domain Virtual memory manager) is also known to work with GCC= > > > VMM (Public Domain Virtual memory manager) is also known to work with GCC. > > I'm running VMM 3.0 on an A4000 Cyberstorm 040 system. Using gcc-2.7.0 > (3-Aug) together with VMM gives horrible crashes. My machine just resets > without giving a software failure. I had no problems using gcc-2.6.3 > together with VMM 3.0 on a normal A4000/040. > I haven't looked at it yet, but could the stack extension code cause such > behaviour? > Can someone else please do some tests? For me it works like a charm (plain 4000/040, 8Mb FAST, 20Mb virtual), except it still isn't enough to compile some of my own stuff with -O. :-) This might be a VMM 3.0 problem, but do try the following: - Check that you don't have a 68EC040! - Run VMM *after* Enforcer if you want to run both. - Never use the `advanced options' as a default setting. - Disallow all libraries from using VM, code or data, by setting the options for "#?.library" to NO/NO. Maybe ixemul is causing the problem. - If you have upgraded from an earlier version, try redoing your preferences from scratch. There are some problems with converting old prefs. - If this is your first installed version, make sure you do have a preferences file (ENVARC:VMM.prefs). - As you're using a special board, try installing the MMU.config (I think) file. If you already have, try removing it instead (as most users shouldn't really need it). - Upgrade to VMM 3.1! Well worth the money IMHO. > > It's not public domain anymore. VMM 3.1 is shareware (and works > > fine with gcc). > ^^^ 2.7.0? Yes, 2.6.3 and 2.7.0 both worked fine. Watch your stack space though, because I'm not sure that the current 2.7.0 release was compiled with stack extension. I always have at least 100 Kb (or kB) of stack and that may be the difference... > -Erik Jeroen From amiga-gcc-port-owner@nic.funet.fi Sun Aug 20 01:15:10 1995 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by nic.funet.fi with SMTP id <90704-2>; Sun, 20 Aug 1995 01:07:18 +0300 Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) id AAA19361 for amiga-gcc-port@lists.funet.fi; Sun, 20 Aug 1995 00:07:06 +0200 From: Thomas Radtke Message-Id: <199508192207.AAA19361@nereid.rz.Uni-Osnabrueck.DE> Subject: double extended To: amiga-gcc-port@nic.funet.fi Date: Sun, 20 Aug 1995 00:07:06 +0200 (DFT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 629 Hi all, The fpu equipped amigas have an internal precisision of 20 decimal digits through the 68881/2 double extended mode (80Bit). This is superior to most UN*X machines btw. I wonder if it is possible to gain the same external precisision by adding a compiler switch. The following steps would then be necessary: - all fmovem must be extended with .e (or was it .x ?) - sizeof(double) must be 10 - code for converting %lf must be changed (alternate libm.a) - maybe a slightly changed math-68881.h (?) If I don't missed a point, this is not to hard to do. Comments and opinions ? Thomas From amiga-gcc-port-owner@nic.funet.fi Sun Aug 20 04:25:19 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <90145-4>; Sun, 20 Aug 1995 04:21:33 +0300 Received: from lysistrate.lysator.liu.se (lysistrate.lysator.liu.se [130.236.254.161]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id DAA00835; Sun, 20 Aug 1995 03:21:19 +0200 Received: (nisse@localhost) by lysistrate.lysator.liu.se (8.6.11/8.6.11) id DAA13813; Sun, 20 Aug 1995 03:21:16 +0200 Date: Sun, 20 Aug 1995 03:21:16 +0200 Message-Id: <199508200121.DAA13813@lysistrate.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95Aug17.175553+0300_eet_dst.90353-3+38@nic.funet.fi> (gc948374@gbar.dtu.dk) Subject: kB or KB > OK, how about 'kB' for 'kilobyte' and 'MB' for megabyte? Not that it is utterly important, but in my experience of computer jargon, the usual acronym for kilobyte (meaning 1024 bytes) is "KB", or simply "K". I think "kB" looks silly. /Regards, Niels From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 10:48:48 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90572-2>; Sun, 20 Aug 1995 17:10:21 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA24198 (5.65b/CWI-3.3); Sun, 20 Aug 1995 16:10:14 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0skAV2-000FaHC; Sun, 20 Aug 95 15:33 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <08uu@wyst.hobby.nl>; Sun, 20 Aug 95 10:49:29 CET Message-Id: <9508200949.08uu@wyst.hobby.nl> Date: Sun, 20 Aug 1995 10:49:28 +0000 (CET) In-Reply-To: <199508182318.BAA22386@skoda.kom.auc.dk> from "Jes Degn Soerensen" at Aug 19, 95 01:18:52 am Content-Type: text Content-Length: 1170 From: hans@wyst.hobby.nl (Hans Verkuil) To: jds@kom.auc.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: inline patches According to Jes Degn Soerensen: > for work some months ago). I'm still waiting for someone to port V5.00x > though. Once perl 5.002 is out I intend to port it. I have ported 5.000 some time ago, but I lost it in a diskcrash. After that I tried 5.001 but that one failed to compile. Besides that it proved to be quite unstable. The current patchlevel for that version has reached the letter 'm', so I prefer to wait for 5.002. It is actually not that difficult to port. The changes needed in the code are minimal or non-existent (don't remember the details). The configure script, however, is the real obstacle and you need most of the standard Unix utilities before you can run it, and then you have to spend an hour or so answering the questions of the script. And if you make a mistake you can start all over again :-( Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 10:49:41 1995 Received: from sunmbx.netmbx.de ([192.76.152.9]) by nic.funet.fi with SMTP id <90122-2>; Sun, 20 Aug 1995 12:54:12 +0300 Received: by sunmbx.netmbx.de (/\==/\ Smail3.1.28.1) from tmpmbx.netmbx.de with smtp id ; Sun, 20 Aug 95 07:49 MET DST Received: by tmpmbx.netmbx.de (/\==/\ Smail3.1.28.1 #28.6) id ; Sun, 20 Aug 95 07:29 MES Received: from tbx by zelator.BerliNet.DE with bsmtp (Smail3.1.28.1 #11) id m0sk50Z-0003vtC; Sun, 20 Aug 95 07:41 MESZ To: amiga-gcc-port@lists.funet.fi Message-Id: <50187301@bw01.bbrandes.berlinet.de> From: B.WINKELMANN@BBrandes.berlinet.de (Bert Winkelmann) Path: tbx.berlinet.de!bbrandes.berlinet.de!B.WINKELMANN Subject: create whatis.db (man/autodoc with perl-script) Date: Sat, 19 Aug 1995 21:42:27 +0200 X-Mailer: UMSZer V2.22 public References: <50187290@bw01.bbrandes.berlinet.de> X-Gateway: ZCONNECT U2 zelator.BerliNet.DE [UNIX/Connect v0.71] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-VIA: 19950819000000S+2@BBrandes.berlinet.de Lines: 119 Hi. Here is a perl-script which can make the database for both "apropos" and "whatis" from manpages and/or autodocs. For easy use, there is a makefile in the archive. Here comes a short example output: 14.RAM_DISK:> whatis fopen fopen (3), fdopen (3), freopen (3) - stream open functions (fopen.0) 14.RAM_DISK:> whatis ksh ksh (1) - Bourne / Korn Shell (Public Domain) 14.RAM_DISK:> apropos OpenWindow OpenWindow (intuition) - Open an Intuition window. OpenWindowTagList (intuition) - OpenWindow() with TagItem extension. (V36) OpenWindowTags -- Varargs stub for OpenWindowTagList (V36) 14.RAM_DISK:> whatis Open Open (dos) - Open a file for input or output Open (parallel) - a request to open the parallel port 14.RAM_DISK:> I hope the script is useful for somebody. Bert. begin 777 mwdb.Z M'XL("%)?-3```6UW9&(N=&UP7W1A<@#M6FMSVS;6SL<5_L+[Y512:M$Q24FV M[(1N$VL=I\U,FV3CI-O&W[W,`DJ)LY>),TDQGA1E; M)'``G/L%X.1BV+=O?=E&6\V=G1VZ1=R:5WZS%]INMCKMSDZGC>=6L[7=N46= M+XR7:FF]P)[*R*=RJY&Y;M(^_Q!=FA,WF+HC&9,;#*G+G#+=-`F'X2`6M8;K^Y3(R\1-DLCK MIPG@+CST17(2GLLA]>5I&$D:A-.9%XP4*"4A)6-)0S=Q^VXL#2`@Q,3U`@<( M>+ZDQG?W#?%&"*)Z)$_I>ZI6=ZDV#OTA9=B8@3N1Y)V2EV#M(,%DFO!&;D!A M@)%$3BQ>@"C@+0'9L%_WXO6Z;6`I`K4D)]-D1KX7R'@7D-^B[V1.!D-I(A32 M9FE$\,*UB9L,Q@3JJ!K/)A.)X4&5IH"341!CW3/)VU=/PZD,&IL&GG]V@]3U M*>^I,H$#8`(">XUZJV=4YX@>G;CF[UWSU?%1[Z)G':^CJ]=H]"[>M#:VWAH] MPUJ`.%D&4K?IVV\)"Y/\#]7;AJ$QKS/)FJEX*S9\TOWY0#'(,Q3?WFCV:8AO M&$]#5-[4R)T"^Z&2X"F$I03!7"CTY,)+QEH8R3@3QVD:#!(O#*CQX,$#H%$I M"*]WG__PB^K(1*_[_Y]B^_71ZY[=SR+LQ>/('!Z'TK-&6,E$-EE=/TOB%16`GK23J%JB33&;FG$*TB MO,K,JBK=(9#>A_6@ MI^X@FX(9X&>P,"F;DD2NYU^;(VHUBJ=RX$'5![#O6%0499H1A[\]>?KL\/&A M[=$??Y#]^M'+)_LO'C]]DK\_/#CY2MIH&:@= MKAM8H]%K_&*M]PQ#"1"F5&\K7A3.05.=^[E?9!0K/5]TE,KR:C7K,S8P66CE MRDP3*E+S`A"4*!5%IQR%T8S&'JQU7;J#\?K<#J&T@W`"DQWN:@7+K(#-J.17 M8$S'8,,&B+=M@PI=%)6*]B(6;(N9PL:U0;`NC'P6'X%U"N^?^XB2DU`#[W<2 M>8?LC%+JF005T/"YAZGNYE8I MRKSAO8+,K9^[D1N-8G`Y2?O&'PUP9&)0IJ(J![%\KT^_:#`MW-@^ZIF]=J=S M7+^AZBS9#BF>^[?9\MC5$:C,/I+A5(4/TDPZV2.Q2LP?H1 M<,Q7`9`:;,)C)0BET5#HY$+*P%BZ9+5^0CG!&?^RWVGD!0G&&3(C?C<;*G%* MSV!''*=]6O1B"/PLA9._V?;HBJ-*@R'R&&7W#-*SK\'4O,3UO8$>_UOO\-IX M'TF$'OV_WA$+DJ[L#Y`H$U<+3TUV0];43OZP5 M^3_;X!?:XP/Y?V=[:^=J_M]LME;Y_Y_1:F:Y<9Y\ZHU2Y7/9'?M^>*&#MPS@ M4OZ3>A%\B?G^)G[N/CEYUOWAX!"F;/_PY"44++!AV\AHA[> M$/S$P^Z+[LG?NX<'Y1E%I2%J']CQDYH0AS\>_/03[\CE3SP6SPZ>%Z]<#0GK M\.6C1X]_/3AT2H]D33'U^3XYWXONRU_Q0^4"FG)K$@^?,@P]/^@^_/D`?LQZ M]N/3)[^10UP0(0PG_#M`3A70X#PVW>$0>20J'BD$CSCS4NLD#3)X.<1"2_L! M7V\,O0C_"_X;<,WU!I-E+.)8AJ$_*`Z1$9@IW:_O">L>T(1+'#)#XV#E&6(W#ZO*Q^PL24*WV61N6JU0J7+IS!>X& M`RDR;0/#U^<OR3\BW+9D'Q M1@)_8.+R52$[WO4^PS!L92\)4U3I_/QY*=>D4R4[.$%JYX5IK`2N\A@DLJ8; M#<;>.9(KH<`9*';XH2#=82V(V7A0CTQ4BIQ-4@<<^LP%HT4"S=;'[&;CDX,$ M^7VQGF*<0WI>>#I'!8K`+BNV\SF>9,->OA8OAZ`YDHE&%9F.U`$C\W!ZL$`F M@[7H!5X4FO_Z%^^\MJ;/@3+^N'HM0)N,2WYFHXZ$KJ'!63Z$EL'$^K"HQ%A+ M+]8=#CU^15V78:&P0ETSC63,9=@&A9A;\#2*=;7!20$S-DUE,`B'4B_G\NG1 M.0I:SJ0M:B2SJ50^**/(],>NF:8@+`D+LG0A\].XF^\QY)7U@CDBW*<'%W8E M+[$,YO@\_$"O+4;.&OU.UBNRL"-9:3H/+HH-9<>C'GE*_@!P_?PJ^S'S#EZL M1(=0OLQDSK,C5]XZ5TM#S/?AQ1<'&461C_'RUX<9Z0R+*X.OQ!RMJT/%+$;U MRB"Z1`E[[0$6QWFZ*(XR<\)*-A7%HCQGOH4R'2/S_*8)-4Q1QD->")F5O+IZQBS"SJIWV'36;?;UTAX@=%DC/CB0*O^-F-7C& M"U%2G#S.U1OZ**>,@F&M+^-%63_$;4L)X3;(*!2:4PQ%SFNA.96FEPEL1/?F M-=(#GJRUZC9OPX^F]@H`-,U,?E@$<*^60;VVDLGT1/?,H2M[H]]!2&F8YTW. M2QUL5YP%W;:TAMW.@[V2,_>Y!(HO,Y2U._S<@>-J'/ERU:*J_W2&^L7V^$#] MU^YL7;W_:;6V=E;UWY_1?O3@%![!_^4^1+DD[4!BJNJ@(A)C@GO\S+&#$>( M%@@LREI''/EA>#9/;72IIH@8C-D'J_ZIFXRQV6`01NJ\&]%\%J91YF`MT5#I MACQU4S\!!DG"0""UNKS:I:OU+A@:"U4W:+WFK\VK).!:BS40H-^8(E72L M,>IK3(=&;"Q]?Z.4=>279Z:JO!J6O33[!YLVK:+NN,(&.O?AP%.^P,LO]'06=JH/DI$UMI#?Z&KS13&J7;A*#?N2UA&N MHHN(3S&#]6^$.-K"MD*'L3(SYH74FL[Q^#'EF">..CREJZYFP"Y5<;@4R`MZ MQ#OETF4!0#BE)//?\`XTWR(K6]0_*YB+5A>DBUU07M0L7['5!VIR-ILL+:V;WB?;(LBTJE,`K<[[0J*<[> MQR;/HA`9[`2+"N;[8-IH&>9^EC,M%Q4%JI-SSR6)?`@&T;:BO\H?;_D'A^(_SO;F^7O?UH<_YO-YBK^_QE-/-\_5+;D*+-0]SI.)!'F M/?:`M@X"9A$]LEQQXUS\$^`<]O3D[)!SC+C@P*EO"K:5P=@1?C@XBQTV0F^0 M"(145+M(">+$$?%LT@]];Z#/(QS!GD,&B;IEEI%#U1I5Q9F<`;$AQ6D_3KQ$ M%?<.G9V+)(2[@=&>>US&8XO-W4HL?7ANQ*QRMX#)J@2!9XKWG@CGTQ0%[*Y! MR[U[';MYUV[=H^:FL[7IM-N[1&Z:C$.@V#^9^P=T0Y=XSL'E%"_JTLRA.UL[ M9';$^OIZ_C5).(*7B3D](?1^-$;MJQC=I>:.TP%26S?$:)/,S<^`4.LJ0CO4 M;CF=MM/L?!1"O)'X_G,V<6-USC/`:PI=G.+G*KW]%51Z>[E*;W^:2F\O4>FV MT[GK=+9OJ$#M-C1H6Q0\ZGNC/-\2G%QQJ'6*RXQRRN*(=U],YR5(]D6$_GZ+ MSSVEOO17QS3JFXF\TA#91P3`U9I_\L5P2S\A:*D/",Y4C?+17.LL-;NMCM/: M_#IFM[44HWR=P1*#ZTQ+/*38EXX4@]4Q=YDUMK$5F:[EPBAH9Z2\JX""= M]/G<&I:2?=#C(4>E)^$%W`Y7!+$ZMRYF#9%BCQO[AE$L>'#I3J:^/O%?_"B) M+MC^PHE,/+XR**TQWVUF%0LQ[J<2HSQMXJES;;;&_*N6XH1@/B4KM[EP(?LU MGQS:GIK.GX7!]`-X;CY:;+"@P^QRT3,^7B+OC%*MYE\J2N5JL#12%3J21ZO. M9XE6M'ZC<-59'JXZGQ:NKCE>':[N.( M#YT;1S,D)>V[?]D`+SA(BO5LA\[7.!55NU55NU55NU55NU F55NU55NU55NU55NU55NU55NU55NU55NU5?MKMO\"7DD="0!0``"U ` end From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 11:24:02 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90956-4>; Mon, 21 Aug 1995 11:23:24 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA10058; Mon, 21 Aug 1995 10:23:45 +0200 Date: Mon, 21 Aug 1995 10:23:44 +0200 (MET DST) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: inline patches To: Olaf Seibert cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508181622.SAA17930@septimius.mbfys.kun.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Fri, 18 Aug 1995, Olaf Seibert wrote: > Kamil Iskra wrote: > > #define LP2(num,rt,name,t1,v1,r1,t2,v2,r2,bt,bn,br) \ > > ({ \ > > register rt _re __asm(D0); \ > > register bt _bn __asm(br) = (bn); \ > > ** register t1 _n1 __asm(r1) = v1; \ > > ** register t2 _n2 __asm(r2) = v2; \ > > /* If v1 or v2 are of wrong type, warning will be generated */ > > __asm __volatile ("jsr a6@(-6*"#num":W)" \ > > :"=r"(_re) \ > > :"r"(_n1),"r"(_n2),"r"(_bn) \ > > :D0,D1,A0,A1,"cc","memory"); \ > > ** _re; \ > > /* If result is assinged to variable of wrong type, warning will be generated */ > > }) > > > Don't forget that just declaring register variables this way does *NOT* > save the old contents if it needs to be saved!! > > > Try to nest a few of these calls and see what happens. Yep, you're right. What I wrote was only an idea, not really tested well. During the weekend I made some "researches" and this code proved to be wrong. I tried to "manually" preserve the registers (as you did in "VERSION 1" of your inlines), but this doesn't solve all the problems. Matthias Fleischer's idea (local inline functions) seems to be the only one working well. > -Olaf. Kamil > -- > ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. > \X/ You are not allowed to read this using any kind of Micro$oft product. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I wonder if you allow using a PC as an UNIX terminal? That's what I did to read your posting :-). From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 12:17:58 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90014-1>; Mon, 21 Aug 1995 12:16:52 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HUC03FUWIO009QUK@NET2.WAU.NL>; Mon, 21 Aug 1995 11:19:04 +0000 (GMT) Received: by vines2.wau.nl; Mon, 21 Aug 95 11:23:32 +0100 Date: Mon, 21 Aug 1995 11:04:39 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Ghostscript & GCC problem solved :) To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi all, The GS maintainer had a look at some debugging output I had sent and send me back a very simple program to test. That showed that indeed GCC is at fault, but it showed something else too. Have a look at the program used and the ouput of gcc -v -m68000 -O0 -o test000 test.c main() { float f = 0.51; int i = f; printf("%d\n", i); /*either TRUNCATE or ROUND */ exit(0); } -------------------- captured output ----------------- gcc -v -m68000 -save-temps -O0 -o test000 test.c -lm Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cpp -lang-c -v -undef - D__GNUC__=2 -D__GNU C_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA - DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ - D__mc68000 -D__amiga -D__amigados -D__MCH_A MIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -Dmc68010 test.c test.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cc1 test.i -mfixedstack -quiet - dumpbase t est.c -m68000 -O0 -version -o test.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. as -mc68010 -o test.o test.s ld -o test000 /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 - L/local/l ib/gcc-lib/mc68000-cbm-amigados/2.7.0 -L/gnu/lib -L/local/lib - L/local/lib test.o -lm -lgcc -lc -lamiga -lc -lgcc 11.Develop:gnu> test000 1 11.Develop:gnu> -------------------- end of captured ouput -------------------- Note the ouput from test000. Its '1' (ONE). Now the same test.c but trying to compile for mc68020 ------------------- start of captured ouput -------------------- gcc -v -m68020 -save-temps -O0 -o test020 test.c -lm Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cpp -lang-c -v -undef - D__GNUC__=2 -D__GNU C_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA - DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ - D__mc68000 -D__amiga -D__amigados -D__MCH_A MIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -Dmc68020 test.c test.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cc1 test.i -mfixedstack -quiet - dumpbase t est.c -m68020 -O0 -version -o test.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. as -mc68020 -o test.o test.s ld -fl libm020 -o test020 /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm- amigados/2.7. 0 -L/local/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 -L/gnu/lib - L/local/lib -L/local/lib test.o -lm -lgcc -lc -lamiga -lc -lgcc /gnu/lib/crt0.o: Undefined symbol ___SaveSP referenced from text segment /gnu/lib/crt0.o: Undefined symbol ___init_stk referenced from text segment 11.Develop:gnu> ------------------ end of captured ouput ----------------------- Can someone tell me what went wrong? I have compiled quite a few programs with 2.7.0 with -m68020 and never had this error message. I change absolutly nothing from my configuration in the meantime. So back to the RESULTS of this little test program. Results with gcc 2.6.3/2.7.0: -m68000: answer is '1' (answer is '0' when using -noixemul :) ) -m68020: answer is '0' (using switch -noixemul, see above error of ld) Results with Aztec answer is '0' Seems that there is a *small bug* in libm.a for mc68000. I wanted to see you part of the file test.s but I have brought the wrong version. Well, from memory, a jsr is made to 'fixspfi' or something sounding similar. Thanks, Joop PS: The updated gcc/gccv/gcc020/gccv020 archive doesn't work as expected. I get lost of messages from cpp about unkown commandline options :( From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 12:18:44 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90034-4>; Mon, 21 Aug 1995 12:18:15 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.121815+0300_eet_dst.90034-4+37@nic.funet.fi> From: To: To: Date: Mon, 21 Aug 1995 12:18:13 +0300 Date: Mon, 21 Aug 1995 11:17:22 +0200 (METDST) From: Rask Lambertsen To: Kamil Iskra Cc: vinsci@nic.funet.fi, amiga-gcc-port@nic.funet.fi Subject: Re: your mail In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 17 Aug 1995, Kamil Iskra wrote: > On Mon, 14 Aug 1995 gc948374@gbar.dtu.dk wrote: > > > Maybe all registers should be defined as returning a result then? > > Otherwise, how is it possible to use Supervisor() from GCC at all? > > IMHO using such a function as Supervisor() from programming language other > than assembler is rather problematic. Have anyone used it in "C"? And > what for? It could be used to obtain the contents of registers that are not readable in user mode. From the '010 and up, such registers exist. Getting/setting the contents of the VBR register is a likely reason to use Supervisor(). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 12:22:11 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90934-3>; Mon, 21 Aug 1995 12:21:26 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.122126+0300_eet_dst.90934-3+28@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 12:21:23 +0300 Date: Mon, 21 Aug 1995 11:21:24 +0200 (METDST) From: Rask Lambertsen To: joop van de wege Cc: amiga-gcc-port@nic.funet.fi Subject: Re: GCC270 & GS3.33 problems In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 17 Aug 1995, joop van de wege wrote: > Hello Rask, > > You're the guy with SUBJECT: problems aren't you Yes, I am :-( > The lines below appeared in my message body, and there was no subject line. [snip] I know, I'm on the mailing list too ;-) The postmaster at lists.funet.fi and I are working on this. Have a little patience Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 12:23:14 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90073-4>; Mon, 21 Aug 1995 12:22:56 +0300 Received: by colombo.telesys-innov.fr; Mon, 21 Aug 1995 11:22:46 +0100 From: Philippe BRAND Message-Id: <199508211022.LAA26887@colombo.telesys-innov.fr> Subject: back from hollidays: gcc-2.7.0 distrib available To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 21 Aug 1995 11:22:45 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 750 After a few days on hollidays, I managed to build a I_hope_to_be_the_final_one 2.7.0 distribution. It does include headers patches, correct libauto, modified README, gccopt1.3 (GUI Makefile generator for gcc) etc... Please FTP it and only report *major* problems, well you can report also minor ones, which will be taken into account for 2.7.1. Then on Thursday I'm planning to upload it to Aminet sites. Available on both my site and funet. Only change planned if available: new APurify without code auto-modofication, which would be integrated into gcc270-base.lha -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 12:37:56 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89947-1>; Mon, 21 Aug 1995 12:37:05 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.123705+0300_eet_dst.89947-1+32@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 12:36:56 +0300 Date: Mon, 21 Aug 1995 11:36:53 +0200 (METDST) From: Rask Lambertsen To: Matthias Fleischer Cc: kiskra@ernie.icslab.agh.edu.pl, amiga-gcc-port@nic.funet.fi Subject: Re: your mail In-Reply-To: <9508180849.AA01305@sunserv.IZFM.Uni-Stuttgart.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 18 Aug 1995, Matthias Fleischer wrote: > > IMHO using such a function as Supervisor() from programming language other > > than assembler is rather problematic. Have anyone used it in "C"? And > > what for? > > > Since the function you call with Supervisor() has to end with > an rte (instead of the normal rts) it's not easy to write one > in C :-). And if you write one in assembler it's (IMO) just as > with any other subroutine. With the exception that 'any other subroutine' dosn't run in supervisor mode. That is the reason you have the Supervisor() function. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 12:38:33 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90012-1>; Mon, 21 Aug 1995 12:38:18 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0skTJk-0004nYC; Mon, 21 Aug 95 02:38 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Ghostscript & GCC problem solved :) To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Mon, 21 Aug 1995 02:38:51 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "joop van de wege" at Aug 21, 95 11:04:39 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 850 > gcc -v -m68000 -save-temps -O0 -o test000 test.c -lm > ... > Note the ouput from test000. Its '1' (ONE). I tried your test here with the version of 2.7.0 that is going to be on FreshFish 10, and got 0. > Now the same test.c but trying to compile for mc68020 > > /gnu/lib/crt0.o: Undefined symbol ___SaveSP referenced from text segment > /gnu/lib/crt0.o: Undefined symbol ___init_stk referenced from text segment I did not get this. It compiled fine here and when run produced 0. > Can someone tell me what went wrong? My guess is that you have some obsolete files that didn't get removed or overwritten when you upgraded your gcc. > Results with gcc 2.6.3/2.7.0: > -m68000: answer is '1' (answer is '0' when using -noixemul :) ) > -m68020: answer is '0' (using switch -noixemul, see above error of ld) I get 0 with gcc 2.6.3 also. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 12:45:18 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90049-3>; Mon, 21 Aug 1995 12:45:07 +0300 Received: by colombo.telesys-innov.fr; Mon, 21 Aug 1995 11:44:48 +0100 From: Philippe BRAND Message-Id: <199508211044.LAA27002@colombo.telesys-innov.fr> Subject: Re: GhostScript & GCC problem solved :) To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Mon, 21 Aug 1995 11:44:46 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "joop van de wege" at Aug 21, 95 11:26:09 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 580 joop van de wege writes: > Seems that there is a *small bug* in libm.a for mc68000. [...] > PS: > The updated gcc/gccv/gcc020/gccv020 archive doesn't work as expected. I get > lost of messages from cpp about unkown commandline options :( If you have enough disk space, try rename gnu gnu.old and install complete 2.7.0 archives, latest ones are on both my site and funet, ane please report asap. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 12:48:36 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90132-4>; Mon, 21 Aug 1995 12:47:53 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.124753+0300_eet_dst.90132-4+40@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 12:47:52 +0300 Date: Mon, 21 Aug 1995 11:47:47 +0200 (METDST) From: Rask Lambertsen To: Joerg-Cyril Hoehle Cc: amiga-gcc-port@nic.funet.fi Subject: Re: including some PD .c or .h files into GCC In-Reply-To: <9508181331.AA13772@inf-wiss.uni-konstanz.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 18 Aug 1995, Joerg-Cyril Hoehle wrote: > Hi, > > what do you think about the inclusion of a few "goodies" into the GCC > archives. I have mostly .h files that do various things, like inline > strlen() macros and a dotimes() macro that compiles to dbra > loops. Others include a very small BPTRprintf using the exec.library > RawDoFmt (like the one in the GURU book, but hopefully without the > bugs there :-( I wouldn't mind as long as the gcc archives don't get too much bigger. Maybe a seperate archive should be created for that, like 'gcc-2.7.0-goodies.lha' or something. > Did you know that only few for (i=n; i; i--) {} style loops compile to > dbra instructions? Use my dotimes() etc. macros instead! If have experimented a little with something similar and I have found out that many do {...} while (i--) loops tend to generate dbcc type instructions, even if 'i' is a LONG variable. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 12:48:50 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <89943-4>; Mon, 21 Aug 1995 12:48:19 +0300 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id LAA17093 (8.6.12/IDA-1.6); Mon, 21 Aug 1995 11:48:07 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA02870; Mon, 21 Aug 95 11:48:06 +0200 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9508210948.AA02870@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Ghostscript & GCC problem solved :) To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Mon, 21 Aug 1995 11:48:06 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "joop van de wege" at Aug 21, 95 11:04:39 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 892 > The GS maintainer had a look at some debugging output I had sent and send me > back a very simple program to test. That showed that indeed GCC is at fault, > but it showed something else too. Have a look at the program used and the > ouput of gcc -v -m68000 -O0 -o test000 test.c > > int i = f; Casts from float to int should always round to zero (cut everything after the decimal point). > So back to the RESULTS of this little test program. > > Results with Aztec > answer is '0' Which is of course the right answer. > Seems that there is a *small bug* in libm.a for mc68000. Maybe it helps to say that the mathieee*bas.libraries don't round correctly if the FPU status register isn't set up correctly. And to set it up you have to (1) open mathieeesingbas.library and mathieeedoubbas.library in _that_ order (OS bug) and (2) once per task (documented in the RKRMs). Matthias From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 12:53:49 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90017-2>; Mon, 21 Aug 1995 12:53:24 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.125324+0300_eet_dst.90017-2+23@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 12:53:22 +0300 Date: Mon, 21 Aug 1995 11:53:20 +0200 (METDST) From: Rask Lambertsen To: Joerg-Cyril Hoehle Cc: amiga-gcc-port Subject: Re: New README for GCC 2.7.0 In-Reply-To: <9508181007.AA13259@inf-wiss.uni-konstanz.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 18 Aug 1995, Joerg-Cyril Hoehle wrote: > [Rask posted the new README here] > > Help, please avoid the MIME quoted-printable format, a file that long > is unreadable without MIME decoder and I won't get sysadmins to handle > that topic soon (am I the only one?). I very much prefer to read a > file with lost 8-bit chars (there aren't many in english files anyway) > than this stuff, even if my own name gets damaged in the file > :-). Send Philippe a uuencoded version if you don't want the real file > to loose characters. > > BTW, with your (or funet's) lost header problem, no mail-reader will > recognize your mail as being MIME-encoded and thus not display it > correctly... Ooop, those @#$% corrupt headers sure give trouble. I hate the quoted-printable format too, this is 1995 and mailers that can't handle 8-bit should be considered obsolete IMO. My mailer (Pine 3.91) just isn't easy to configure for sending out 8-bit mail. I'll give it a try. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 13:01:54 1995 Received: from specklec.mpifr-bonn.mpg.de ([134.104.20.3]) by nic.funet.fi with SMTP id <90301-1>; Mon, 21 Aug 1995 13:01:11 +0300 Received: from spcklh.mpifr-bonn.mpg.de (spcklh.mpifr-bonn.mpg.de [134.104.20.11]) by specklec.mpifr-bonn.mpg.de (8.6.10/8.6.9) with ESMTP id MAA15421 for ; Mon, 21 Aug 1995 12:00:44 +0200 From: Gerd Schniggenberg Received: (gs@localhost) by spcklh.mpifr-bonn.mpg.de (8.6.9/8.6.9) id MAA14451 for amiga-gcc-port@nic.funet.fi; Mon, 21 Aug 1995 12:00:37 +0200 Message-Id: <199508211000.MAA14451@spcklh.mpifr-bonn.mpg.de> Subject: Re: double extended To: amiga-gcc-port@nic.funet.fi Date: Mon, 21 Aug 95 12:00:36 MET DST X-Mailer: ELM [version 2.2 PL14] Hi! > The fpu equipped amigas have an internal precisision of > 20 decimal digits through the 68881/2 double extended mode > (80Bit). This is superior to most UN*X machines btw. The Intel x87 processors have 80bit floats, but the PPC not. > I wonder if it is possible to gain the same external > precisision by adding a compiler switch. The following > steps would then be necessary: > > - all fmovem must be extended with .e (or was it .x ?) > - sizeof(double) must be 10 > - code for converting %lf must be changed (alternate libm.a) > - maybe a slightly changed math-68881.h (?) > > If I don't missed a point, this is not to hard to > do. Comments and opinions ? I asked about 80Bit floats some weeks before, but there was no response. AFAIK all floatingpoint calculations in the 68881/2 are done with 80Bit. If you calculate with 32Bit the result is converted from 80 to 32Bit. So 80Bit calcualtions wouldn't be much slower. I wonder why there was no support for 80Bit floats before, has no one missed them? Gerd -- From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 13:02:33 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90704-1>; Mon, 21 Aug 1995 13:02:24 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.130224+0300_eet_dst.90704-1+34@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 13:02:19 +0300 Date: Mon, 21 Aug 1995 12:02:15 +0200 (METDST) From: Rask Lambertsen To: Philippe BRAND Cc: Joerg-Cyril Hoehle , Amiga-Gcc Liste Subject: Re: New README-file for LIBNIX In-Reply-To: <199508182333.AAA20410@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 19 Aug 1995, Philippe BRAND wrote: > Could someone take in charge README corrections, etc... for GCc ? I really I would like to do it. > don't have much time those days, being busy with both my BBS which is > getting larger, and above all with my wife which's gonna have pretty son > (mid-september) a baby. Congratulations. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 13:05:47 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90946-4>; Mon, 21 Aug 1995 13:05:28 +0300 Received: by colombo.telesys-innov.fr; Mon, 21 Aug 1995 12:05:09 +0100 From: Philippe BRAND Message-Id: <199508211105.MAA27128@colombo.telesys-innov.fr> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Mon, 21 Aug 1995 12:05:08 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95Aug21.130224+0300_eet_dst.90704-1+34@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 21, 95 01:02:19 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 445 gc948374@gbar.dtu.dk writes: > > Could someone take in charge README corrections, etc... for GCc ? I really > I would like to do it. Ok. Can you grab latest gcc270-readme.lha archive, at least ? READMe-2.7.0 is enclosed. Thanks. Ps: if possible, do not use mime. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 13:11:02 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90530-4>; Mon, 21 Aug 1995 13:10:41 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.131041+0300_eet_dst.90530-4+42@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 13:10:40 +0300 Date: Mon, 21 Aug 1995 12:09:43 +0200 (METDST) From: Rask Lambertsen To: jtv@xs4all.nl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: VMM & gcc In-Reply-To: <2128eb3b.u7t157e.89636-jtv@asd07-21.dial.xs4all.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 19 Aug 1995, Jeroen T. Vermeulen wrote: > > > > > VMM40 (Public Domain Virtual memory manager) is also known to work with GCC= > > > > VMM (Public Domain Virtual memory manager) is also known to work with GCC. > > > > I'm running VMM 3.0 on an A4000 Cyberstorm 040 system. Using gcc-2.7.0 > > (3-Aug) together with VMM gives horrible crashes. My machine just resets > > without giving a software failure. I had no problems using gcc-2.6.3 > > together with VMM 3.0 on a normal A4000/040. > > I haven't looked at it yet, but could the stack extension code cause such > > behaviour? What stack extension code? > For me it works like a charm (plain 4000/040, 8Mb FAST, 20Mb virtual), > except it > still isn't enough to compile some of my own stuff with -O. :-) Hmm, am I doing somthing magic to make things work with A500, 1 MB CHIP, 2 MB FAST, 0 MB virtual and compiling with -O3? Have you tried 'SetEnv TMPDIR something_on_harddisk'? This saves lots of RAM. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 13:15:53 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90128-3>; Mon, 21 Aug 1995 13:15:30 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Mon, 21 Aug 95 12:14:34 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <212c39a5.u7t157e.6e42f-robert@plukwa.pdi.lodz.pl> Subject: Re: your mail In-Reply-To: <21289391.u7t157e.a198e-jtv@asd05-21.dial.xs4all.nl> (from jtv%asd05-21.dial.xs4all.nl@plearn.edu.pl (Jeroen T. Vermeulen)) (at Fri, 18 Aug 95 17:49:07) Reply-To: robert@pdi.lodz.pl Content-Length: 887 To: jtv%xs4all.nl@plearn.edu.pl Cc: amiga-gcc-port@nic.funet.fi Date: Mon, 21 Aug 95 12:14:34 On Aug 18 Jeroen T. Vermeulen wrote: > On Aug 18, robert@pdi.lodz.pl wrote: > > > > VMM40 (Public Domain Virtual memory manager) is also known to work with GCC= > > VMM (Public Domain Virtual memory manager) is also known to work with GCC. > > It's not public domain anymore. VMM 3.1 is shareware (and works fine with gcc). Ok, my fault! Make it VMM (Shareware Virtual...) than. :) > > > Jeroen > regards, Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 13:17:15 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90380-3>; Mon, 21 Aug 1995 13:16:57 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.131657+0300_eet_dst.90380-3+30@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 13:16:52 +0300 Date: Mon, 21 Aug 1995 12:16:43 +0200 (METDST) From: Rask Lambertsen To: Kamil Iskra Cc: Olaf Seibert , amiga-gcc-port@nic.funet.fi Subject: Re: inline patches In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 21 Aug 1995, Kamil Iskra wrote: [snip (inline function example)] > Matthias Fleischer's idea (local inline functions) seems to be the only > one working well. Are those inline files available somewhere? I'm (almost) dying to get my hands on them. > > ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. > > \X/ You are not allowed to read this using any kind of Micro$oft product. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I wonder if you allow using a PC as an UNIX terminal? That's what I did to > read your posting :-). If it runs PC-DOS or OS\2, that wouldn't be Micro$oft products, would it? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 13:32:11 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90160-2>; Mon, 21 Aug 1995 13:30:20 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA11225; Mon, 21 Aug 1995 12:32:20 +0200 Date: Mon, 21 Aug 1995 12:32:19 +0200 (MET DST) From: Kamil Iskra Subject: Re: inline patches To: Rask Lambertsen cc: Olaf Seibert , amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 21 Aug 1995, Rask Lambertsen wrote: > On Mon, 21 Aug 1995, Kamil Iskra wrote: > > Matthias Fleischer's idea (local inline functions) seems to be the only > > one working well. > > Are those inline files available somewhere? I'm (almost) dying to get my > hands on them. No, as of today, these are only ideas. I had a look at "fd2inline.c 0.99a" that I got from its author and it seems that no more than 10% of source (ie. about 100 lines) will have to be modified. I hope I'll have done it by Friday, maybe even by Wednesday. > > > ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. > > > \X/ You are not allowed to read this using any kind of Micro$oft product. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I wonder if you allow using a PC as an UNIX terminal? That's what I did to > > read your posting :-). > > If it runs PC-DOS or OS\2, that wouldn't be Micro$oft products, would it? Unfortunately, it runs MS-DOS and Novell. I'm afraid that in future I'll have to export Olaf's postings and read them at home, on my Amiga :-). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 13:42:37 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90253-4>; Mon, 21 Aug 1995 13:42:19 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.134219+0300_eet_dst.90253-4+45@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 13:42:14 +0300 Date: Mon, 21 Aug 1995 12:42:12 +0200 (METDST) From: Rask Lambertsen To: Philippe BRAND Cc: Amiga-Gcc Liste Subject: Re: your mail In-Reply-To: <199508211105.MAA27128@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 21 Aug 1995, Philippe BRAND wrote: > gc948374@gbar.dtu.dk writes: > > > > Could someone take in charge README corrections, etc... for GCc ? I really > > I would like to do it. > > Ok. Can you grab latest gcc270-readme.lha archive, at least ? READMe-2.7.0 > is enclosed. > Thanks. I think ftp.funet.fi has some problems with the date stamping of their files: gcc270-readme.lha 81 Kb Sun Aug 21 13:10:00 1994 > Ps: if possible, do not use mime. I'll try resending my corrected README-2.7.0 from another mailer. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 14:04:01 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90925-3>; Mon, 21 Aug 1995 14:03:10 +0300 Received: from oersted (localhost) by oersted.gbar.dtu.dk with SMTP(1.37.109.15/16.2) Message-Id: <95Aug21.140310+0300_eet_dst.90925-3+33@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 14:03:04 +0300 Message-Id: <199508211100.AA062702833@gbar.dtu.dk> Date: Mon, 21 Aug 95 13:00:33 0200 Sender: gc948374@gbar.dtu.dk From: Rask Lambertsen Organization: DTU X-Mailer: Mozilla 1.1N (X11; I; HP-UX A.09.03 9000/715) Mime-Version: 1.0 To: amiga-gcc-port@nic.funet.fi Subject: Repost of GCC README X-Url: ftp://ftp.funet.fi/pub/amiga/gnu/beta/ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Here is a repost of the GCC README. I hope it get to the list fine this time. I am so fortunate to have a WWW server that I am running :-) The readme will be available as "http://srv2.gbar.dtu.dk:8001/Rask/README-2.7.0" so get it from here if it doesn't make it through the mail. -- Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ To: amiga-gcc-port@lists.funet.fi Subject: New README for GCC 2.7.0 I am posting the complete new readme instead of diffs as a normal context diff (diff -2w) would be much larger and even aunified context diff (diff -2u) wouldn't be much smaller. If you wan't to see what I have changed, you can now use your favourite diff output format :-) Mainly, spelling and grammar has been correct + the incorrect inline section. It should now be clear that you can use the supplied inlines on OS 2.x systems. Readme for GCC 2.7.0 ---------------------------------------------------------------- Short: gcc v2.7.0 - C/C++/ObjC Compiler set for AmigaDOS Type: dev/gcc Uploader: phb@colombo.telesys-innov.fr Author: phb@colombo.telesys-innov.fr This is the AmigaDOS 2.7.0 GNU C/C++/Objc compiler. The GNU C compiler is free software. See the file COPYING for copying permission. PLEASE be sure to read README file enclosed in gcc270-readme.lha FIRST. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D How to get help =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There's an Amiga-GCC mailing list running in Finland, read README-LIST file. This is the preferred place to ask for help since I'm on this list and every GCC developers also, libnix & ixemul authors, etc... Short: send an email to listserv@lists.funet.fi, and put in body: subscribe amiga-gcc-port your_first_name your_last_name (insert your own first name and your own last name above) Otherwise you can contact me at: Philippe BRAND Fidonet: Ramses The Amiga Flying BBS 2:320/104.0 Email: phb@colombo.telesys-innov.fr (ONLY for personal email). WWW: www.telesys-innov.fr Ftp: ftp.telesys-innov.fr:/pub/amigados-gnu or /pub/incoming/uploads for uploads. Note: I'll forward any question to this mailing-list, but please use it directly, except when you send files, in this case send them to my ftp site. Note 2: ftp.funet.fi mirrors my amigados-gnu tree. Using ftp.funet.fi is preferable as they have much more bandwidth (/pub/amiga/gnu). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Requirements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Systems: Any Amiga (ranging from A1000 up to A4000/40, including CD-32 & SX-1) will run AmigaDOS-GNU utilities. - Memory: A minimum of 4 MB of free memory is needed in order to compile small/medium projects. More memory will be needed for large projects, such as recompiling GCC itself. Gigamem is known to work with GCC so *maybe* less memory will work. But in this case, you'll need an MMU equipped Amiga (A3000,A4000/40, etc...). VMM40 (Public Domain Virtual memory manager) is also known to work with GCC. - OS: Starting from version 2.5.x, 1.3 systems are not longer supported. GCC runs fine on all other systems, starting from 2.04 up to 3.1 (40.68). - Disk Space; An installation of GCC requires the use of a hard disk. Approximately 10 MB is required at present to install the compiler and utilities required to use it. In addition 3 MB is required for the Commodore Developer Kit, which is required to be able to compile AmigaDOS specific programs. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D What's new in this release =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2.7.0 - Read FSF NEWS-2.7.0 file included. - As always, generic bugs fixed (see Changelog in GCC sources for details). - FSF listing shell script suppressed. - new as/ld/size/nm/ranlib using BFD, made by Raphael Luebbert - as fixed, used to generate some 020 instructions while in 68000 mode. - all programs recompiled using 2.7.0 compiler. - new inlines headers. - new compiler options: -mstackcheck and -mstackextend, to respectively implement stack checking and auto-stack growing into GCC compiled programs. - resident option is now fixed. - new ixemul library, v41.1 (complete distribution can be found on Aminet site). - new libnix, v1.0 (sources can be found also on Aminet sites, in libnix archive). This release is dedicated in memory of Pierre Carette. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D What was new in previous releases =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2.6.3 - Read FSF NEWS-2.6.1 file included. - As always, generic bugs fixed (see Changelog in GCC sources for details). - q_anote package replaced by FSF listing shell script, need awk. - new as/ld/size/nm/ranlib, made by Raphael Luebbert - new environent variables GCCPRIORITY and GCCSTACK, see below. - all programs recompiled using 2.6.3 compiler. - mit2mot & mot2mit, convert asm syntax between Motorola and MIT syntaxes. - all programs hold AmigaDOS compatible $VER string. 2.6.2 - internal release only. 2.6.1 - Read FSF NEWS-2.6.1 file included. - As always, generic bugs fixed (see Changelog in GCC sources for details). - new option -priority in gcc allowing process priority setting. - new specs file, inlines/protos and libamiga done by Gunther Nikl. See note below. - new libnix version by Matthias Fleischer & Gunther Nikl. - new ixemul version by Raphael Luebbert. - stripc program to strip all uneccessary stuff from headers by Chris Metcalf, submitted by Lars Hecking. - q_anote, annotate assembly files mixing C source code, submitted by Walter Harms (Walter.Harms@arbi.informatik.uni-oldenburg.de), written by Mike Albaugh (albaugh@agames.com). See note below. - new assembler, as-2.5, using new BFD (Binary File Descriptor), made by Raphael Luebbert. 2.6.0 - Read FSF NEWS-2.6.0 file included. - Extensive internal compiler bugs fixed (see ChangeLog in GCC sources for details), tons of bugs fixed for C++ support. - ld changed (see note for ld below). - new ixemul.library, with optimized versions for accelerated Amigas, see README-ixemul & ixemul.guide for more informations. - new C library (libnix) disabling use of ixemul.library for generated programs (best use for AmigaDOS specific programs). Full ANSI compliant, see README-libnix & libnix.guide for more informations. - revised inline headers in accordance with new ixemul.library. - libamiga.a is now distributed with GCC-2.6.1. - as v2.3 is included, along with a macro-assembler (gasp). - stderrfix.o (see below) patch applied. - Upgrade to libg++-2.6. - GCC now supports $VER string for AmigaDOS version compatibility. 2.5.8 - Read FSF NEWS-2.5.8 file included. - ld behaviour over symbols changed (see note below). - added flavours so that linker will take appropriate libraries according to gcc options (m68020 libraries/baserel libraries, etc...). - gpc (GNU-Pascal) v1.03 added. - all utilities recompiled with GCC-2.5.8. - plain 68000 and 68020+68881 versions of all binaries available. - More internal compiler bugs fixed (see ChangeLog in GCC sources for details), some for C++ support. - GCC-Install script fixed by Claus Deckhut (to be used with full distribution). - Upgrade to libg++-2.5.3. - trace.c updated by J. Hoehle to avoid buffer overflows. 2.5.7: - Read FSF NEWS file included. - More internal compiler bugs fixed (see ChangeLog in GCC sources for details), a lot for C++ support. - Fred Fish seems to have finally found an annoying bug which prevented to compile a resident version of GCC, or to compile resident programs. But don't try it anyway 'cause there's still lack of library support as for now. - Man command now works, this one was my fault (well in fact like others ;-), fix done by Tom Haiko. - Infoview works also, it was an internal path problem. - libamy.a HAS TO BE RENAMED to libamiga.a because new ld won't find libamy.a - upgrade to new C++ library v2.5.1. =3D=3D=3D=3D=3D=3D=3D Authors =3D=3D=3D=3D=3D=3D=3D GCC v2.2.2 port: Markus Wild GCC v2.3.3 port: Markus Wild GCC v2.4.5 port: Philippe Brand, Lars Hecking, Fred Fish GCC v2.5.0 and up: Philippe Brand, Fred Fish, Leonard Norrgard Ixemul.library: Markus Wild (original programming), Leonard Norrgard (vinsci@nic.funet.fi), Raphael Luebbert, Stephan Isthesin. Libnix: Matthias Fleischer (fleischr@izfm.uni-stuttgart.de) and Gunther Nikl (gnikl@informatik.uni-rostock.de) Installer Prog: Jochen Wiedmann (jochen.wiedmann@zdv.uni-tuebingen.de) Thanks to all amiga-gcc-port mailing-list users for their reports and support for a better AmigaDOS-GCC and documentation. =3D=3D=3D=3D=3D=3D=3D Sources =3D=3D=3D=3D=3D=3D=3D These archives should contain everything necessary to get you going, they don't include sources for all tools (have a look at end of paragraph). As stated by Richard Stallman of the FSF: "The GPL says that any distribution of binaries must contain either the source code or a written offer to supply source code (see the GPL for details of what is required)." If you're interested in the sources required to rebuild GCC, get the gcc270-src.lha, which hold sources for GCC. Those archives should be stored either the same ftp site you got this binary distribution from (if they're not, tell the manager of that ftp site, as this is a requirement of the GNU Copyright LICENSE), either at ftp.gnu.ai.mit.edu:/pub/gnu, either on Ramses BBS (phone numbers listed below). If you have those archives, you can skip to next paragraph. If you have original FSF sources, you'll have to apply the GCC patch-file in src-patches/, and configure for `amigados'. Please note that you should have at least 40 MB left or your HD and 8 MB of memory minimum in order to rebuild GCC up to stage 3. An accelerated Amiga is welcome, as it took me 4,5 hours to generate a single pass. So 3 passes makes 4,5 x 3 =3D 13,5 hours. Sources for other tools only included as binaries are available separately in self-contained archives, usually having their name into the archive-name. File What gcc270-src.lha C/C++/ObjC compiler sources & diff file libnix-1.0.lha libnix sources and binaries ixemul-41.1-src.lha ixemul sources and libraries binutils-1.8.x-src.lha Sources for ld binutils-2.5.2-src.lha Sources for ar/ranlib & diff file make-3.74-src.lha make sources & diff file gdbm-1.7.3-src.lha Sources for gdbm & diff file patch-2.1-src.lha patch sources, needed to apply diff files sed-2.05-src.lha sed sources & diff file gawk-2.15.5-src.lha GNU awk sources & diff file diffutils-2.7-src.lha diff utility sources & diff file fileutils-3.11-src.lha file utilities sources & diff file sh-utils-1.12-src.lha shell utilities sources & diff file textutils-1.11-src.lha text utilities sources & diff file findutils-4.1-src.lha find sources & diff file grep-2.0-src.lha grep sources & diff file bison-1.22-src.lha bison (yacc replacement) sources & diff file flex-2.4.7-src.lha flex (lex replacement) sources & diff file texinfo-3.1-src.lha texinfo (includes makeinfo) sources & diff file gzip-1.2.4-src.lha gzip sources & diff file tar-1.11.2-src.lha gtar sources & diff file cpio-2.3-src.lha cpio sources & diff file gdbm-1.7.3-src.lha database manip. library sources & diff file termcap-1.2-src.lha termcap library sources & diff file libm-5.6-src.lha BSD mathematic library sources & diff file NOTE: All sources archives are Amiga ready, and Amiga specific diff file located in 'amiga' directory. To recompile a tool, just run a 'configure amigados' then a 'make'. Exceptions are libnix and ixemul which have their own archives, both binary & sources. On Aminet sites, libnix & ixemul in /pub/amiga/dev/gcc. =3D=3D=3D=3D=3D Where =3D=3D=3D=3D=3D **** All GNU sources & binaries are available on: - ftp.telesys-innov.fr, primary Amiga-GNU FTP site, and its mirror ftp.funet.fi which is MUCH faster than my own site. Please use it at first choice. in /pub/amigados-gnu - Aminet sites (wuarchive.wustl.edu and mirrors such as ftp.luth.se) in /pub/amiga/dev/gcc - Ramses The Amiga Flying BBS +33-1-45845623 USR V.everything 2400-33600 +33-1-53791199 USR V.everything 2400-33600 +33-1-53791200 USR Sportster V32b 2400-14400 in Topic "Development", Area "Gcc" (File Area 156). - FreshFish CDs from Fred Fish Amiga Library Services in :GNU/bin, :GNU/src, :GNU/lib dirs. 610 N. Alma School Road, Suite 18 Chandler, AZ 85224-3687 USA FAX: (602) 491-0048 VOICE: (602) 491-0442 **** GNU source code is available on: - same FTP site you've taken these archives - gnu.prep.ai.mit.edu 18.71.0.38 in /pub/gnu - Ramses The Amiga Flying BBS in Topic "AmigaUnix/Unix/Linux/NetBSD", Area "Gnu Source Code" - FreshFish from Fred Fish in :GNU/src =3D=3D=3D=3D=3D=3D Layout =3D=3D=3D=3D=3D=3D GCC-2.7.0 is split up into 15 archives: gcc270-readme.lha holds readmes files (include installation notes). gcc270-base.lha basic GCC distribution, hold necessary files. gcc270-inclib.lha headers and libraries. gcc270-c.lha C compiler. gcc270-c-020.lha 68020 version of C compiler. gcc270-c++.lha C++ compiler, headers and libraries. gcc270-c++-020.lha 68020 versions of C++ compiler. gcc270-objc.lha Objective-C compiler, header and libraries. gcc270-objc-020.lha 68020 versions of Objective-C compiler. gcc270-doc.lha GCC AmigaGuide(tm) documents & manpages. gcc270-utils.lha Useful utilities needed for development. gcc270-utilsdoc.lha Utilities documentation (guide & manpages). gcc270-texi.lha All Texinfo documents. gcc270-diffs.lha Diff files for all binaries. gcc270-src.lha Source for GCC-2.7.0 plus diff file. Name What Where ---- ---- ----- COPYING GNU LICENSE, read!! All archives COPYING.LIB GNU LIBRARY LICENSE, read!! All archives README-2.7.0 this file All archives NEWS-2.7.0 What's new in GCC-2.7.0 gcc270-base Installer Commodore installer utility gcc270-base GCC-Install Installer script to configure GCC All archives envarc/ global environment variables you should have set when using this programming gcc270-base environment include/ non-Amiga specific C/C++ headers gcc270-inclib os-include/proto Amiga specific protos headers. gcc270-inclib os-include/inline Amiga specific inline C headers. Add gcc270-inclib Commodore headers!! os-lib/ Amiga specific libraries gcc270-base guide/ Docs in AmigaGuide(tm) format gcc270-doc man/ this is the root for tons of man pages gcc270-doc bin/ this is /bin, and contains all gcc270-c binaries of this distribution that gcc270-c++ are meant to be directly invoked by gcc270-utils the user (contrary to the executables in lib/gcc-lib/, that are meant to be invoked by a driver program like gcc) lib/ normal (not base relatives) libraries gcc270-inclib lib/libm020/ normal 68020 libraries gcc270-inclib lib/libb/ base relatives libraries gcc270-inclib lib/libb/libm020/ base relatives using 68020 libraries gcc270-inclib lib/libnix/ Non-ixemul libraries gcc270-inclib lib/libm020/libnix/ Non-ixemul 68020 libraries gcc270-inclib lib/libb/libnix/ Non-ixemul base relatives libraries gcc270-inclib lib/libb/libm020/libnix Non-ixemul base relatives 68020 libs gcc270-inclib lib/gcc-lib/ home of compilers called by gcc gcc270-c gcc270-c++ gcc270-objc ixpipe/ a pipe handler needed by the library gcc270-base libs/ ixemul.library gcc270-base rexx/ ARexx wrappers for gcc and g++ gcc270-base src-patches/ source patches gcc270-diffs geninline/ Perl scripts to generate inline headers gcc270-inclib and -lamy glue =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Inline-Headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Since I'm not able to redistribute Amiga header files, you will have to get them directly from Commodore, unless you're an official registered Amiga developer. You can also find Development Kit on FreshFish CD-Roms. In order to generate inline-headers, follow these steps (provided Amiga headers and fd files are in os-include). If you are compiling for Kickstart 3.1 or less, you don't have to generate them, inlines are provided with the distribution. 1) First method: CLI> stack 100000 CLI> Assign INCLUDE: GCC:os-include CLI> Assign FD: INCLUDE:fd CLI> Makedir INCLUDE:inline CLI> cd USR:bin/geninline CLI> gen31 This will create all inline-headers. If you have 2.0 headers, use gen20 instead, if you have 3.0, use gen30, if you have 6.4, send it to me ;-) NOTE: perl scripts do not handle correctly AmigaDOS include files, which seems to mean they are somewhat broken. If someone could work on this... 2) Second method: Use fd2inline, which you can find on Aminet in dev/gcc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Amiga Libraries =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Starting from 2.6.0 an AmigaDOS compliant library is provided, thanks to libnix authors (Matthias Fleischer and Gunther Nikl). Anyway if you want to rebuild one, there are two methods: 1) Using hunk2gcc; the AmigaDOS object converter made by Markus Wild. To achieve this, simply grab a copy of latest amiga.lib (from Commodore Development Kit) and make a new directory where you want your converted object files to go, cd into it, and enter hunk2gcc amiga.lib [..further libs if you like..] This generates an a.out object file for every program unit present in the hunk file (in this case, from amiga.lib). As the final step convert all those files into an a.out style library by issuing: ar qc libamiga.a obj.* ranlib libamiga.a The ranlib run builds a symbol table in the archive, and makes accesses to the library much faster. 2) Creating a libamiga.a library with libnix is fairly easy, but takes some time. Just decompress sources.lha from libnix distribution and run a 'make libamiga.a'. NOTE: As long as you make no AmigaDOS specific calls, you can create a dummy library using: cat "int dummy;" >dummy.c gcc -c dummy.c ar crv libamiga.a dummy.o mv libamiga.a gcc:lib A small libamiga.a (dummy) is also provided with libnix. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Upgrade Installation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - You will at first have to decide if you want to keep your existing GCC compiler or not. This might sound silly, but it is in fact possible. - I want to keep older GCC compiler CLI> cd GNU:lib CLI> rename libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3 (note: replace 2.6.3 with your GCC version) CLI> rename libb/libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3/libb CLI> rename libm020/libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3/libm020 CLI> cd GNU:bin CLI> rename gcc gcc-2.6.3 CLI> rename gccv gccv-2.6.3 - I don't care about previous versions CLI> delete GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3 all quiet Proceed then to "Distribution Installation" below, for mandatory archives only. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Distribution Installation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NOTE: you MUST at least unpack gcc270 base, inclib and c parts. Other archives are optional. - You need first to create a directory gnu on your hard-disk and unarchive first part: CLI> cd place_with_lot_of_space CLI> makedir gnu CLI> lha x gcc270-base.lha - Now you have to append gnu/s/user-startup to your s:user-startup file (replace Devel:GNU by your own gnu path). Execute it in order to get new assigns: CLI> execute gnu/s/user-startup - Copy gnu/envarc to ENVARC: CLI> copy gnu/envarc/#? ENVARC: - GCC libraries and headers: CLI> lha x gcc270-inclib.lha - C-compiler is needed so unarchive C compiler part (Users with accelerated Amigas can unarchive gcc270-c-020 part instead) : CLI> lha x gcc270-c.lha (or gcc270-c-020) - If you want to have GCC documentation on-line, unarchive doc part: CLI> lha x gcc270-doc.lha - If you want to do C++, unarchive C++ part (Users with accelerated Amigas can unarchive gcc270-c++-020 part instead) : CLI> lha x gcc270-c++.lha (or gcc270-c++-020) Please note that 68020 versions have '.020' extension in GNU:bin. - If you want to do Objective-C, unarchive Objective-C part (Users with accelerated Amigas can unarchive gcc270-objc-020 part instead) : CLI> lha x gcc270-objc.lha (or gcc270-objc-020) - If you want additional utilities (recommended for Unix compatibility), unarchive utils part: CLI> lha x gcc270-utils.lha - If you want all utilities documentation on-line, unarchive utils-doc part: CLI> lha x gcc270-utilsdoc.lha - Because some programs are normally links to others, please run script: CLI> sh /gnu/s/restorelinks Or if you don't want to use makelink but rather copy file, run script: CLI> sh /gnu/s/restorelinks copy - If you want to rebuild all distribution, you'll have to unarchive diff part: CLI> lha x gcc270-diffs.lha - If you want to build Postscript files for GCC documentation, unarchive texinfo part: CLI> lha x gcc270-texi.lha - Now skip to next paragraph and happy compiling! NOTE: new version of ixemul.library is provided, make sure you don't have another copy somewhere which may conflict with GCC. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Your first C program with GCC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D What about a nice Hello World ? #include main() { printf("Hello World!\n"); } This was pretty simple ;-) Now we have to compile it. There's a lot of options in GCC but the simplest way to compile this would be: CLI> gcc -o hello hello.c Simple? Here's more options. Target processor for Motorola family: You can compile plain 68000 code, 68020, 68030, 68040, 68881 (have a look at GCC documentation, either in info or AmigaGuide format, chapter Invoking GCC/ SubModel Options/M680X0 Options for Motorola specific compilation flags). CLI> gcc -m68020 -m68881 -o hello hello.c This will compile your programs using 68020 code and direct calls to math-processor, and will link with accelerated libraries, located in GCC:lib/lib020. Optimization: Either you don't want optimization, or you can provide -O, which will optimize your code, or if you really want top optimization, use -O2 flag (for more discussion about optimization, read info or AmigaGuide doc chapter Invoking GCC/Optimize Options). There's now even a -O3 optimization option, which will go even further. CLI> gcc -O2 -o hello hello.c You'll never have a "Hello World" program running so fast ;-) Code generation: Perhaps you want to generate resident programs. Flag is -resident, at compile and link stage. CLI> gcc -resident -o hello hello.c Of course you can mix all options, resulting in: CLI> gcc -O2 -m68020 -m68881 -resident -o hello hello.c This will make a 68020+68881 executable highly optimized and resident. IMPORTANT: If you only use AmigaDOS functions or you don't want to use ixemul for philosophical reasons, you can get rid of ixemul.library with: CLI> gcc -noixemul -o foobar foobar.c provided you have libnix distribution (included with 2.6.0 and up distributions). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ixemul vs Libnix =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Starting with 2.6.1 version of AmigaDOS-GCC, two C libraries are provided. First one is using ixemul.library Amiga shared-library at run-time. This library makes it possible to easily convert Unix(tm) programs to AmigaDOS, and made for example possible GCC on AmigaDOS. Have a look at ixemul.guide for further informations. Second one is an ANSI-C compliant library which is better suited for AmigaDOS specific development, thus not using any Unix specific routines. Libnix is a static (i.e. link) library for GCC 2.3.3 or above. It's not a replacement for ixemul.library (though it's possible to recompile most of the GCC environment with libnix) but a good thing for Amiga specific development on GCC: * It's mostly compatible to SAS's way of handling things, i.e. you get even an automatic shared library opening feature and some other things you may miss in ixemul.library. This also means it's ANSI compliant. * It doesn't need any shared libraries other than normal Amiga OS ones. * It is not copyrighted by the FSF. Therefore you neither need to include sources nor objects together with your executable. (read the GLGPL _before_ flaming on this statement) * And it's short! I was able to compile a 492 byte 'hello, world' using normal main. * It uses OS 2.0 features whenever necessary. Note that you can develop AmigaDOS specific programs with ixemul.library, but at the cost of an extra 200 kB of memory taken by shared library. To cut it short: Use ixemul.library for porting Un*x programs, libnix for compiling Amiga-only programs and GCC becomes one of the best Amiga compilers. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Redirection with ixemul.library =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A common problem seen with AmigaDOS-GCC is bad redirection to stderr. The fact is that ixemul.library takes stderr from the pr_CES field in the process structure. The field was added in 2.0. If the field is not set, then ixemul uses stdout, instead. The trouble is that this field must be set by the shell, and the only shell that does so is WShell! The rationale behind ixemul.library working this way is that "run NIL: cmd" will detach your process from the terminal, so that you can close the initial CLI window after startup. In any case, there is a workaround for the problem that was posted to the list a while back: compile your main program using the -Dmain=3Dmymain option, then link with stderrfix.o to provide the actual main that will do the magic that creates an stderr stream that is different from stdout. Along with the C version a C++ version is included and was used to compile groff. Thanks to Kriton Kyrimis for this explanation and patch. stderr fixes can be found in GNU:stderrfix (srcs-) and GNU:lib (.o files). =3D=3D=3D=3D=3D ARexx =3D=3D=3D=3D=3D The provided ARexx scripts have been contributed by Loren J. Rittle. If you like ARexx, they're an alternate way of calling GCC. They automatically make sure you're using a large enough stack setting, and enable you to compile C++ programs with less obscure options. This approach is furthermore useful if you're not able to use the g++ /bin/sh script. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D gcc versus gccv =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D gccv stands for a gcc using vfork() to spawn a new process, and then calling the new execve() function in ixemul.library to call its subcompilers. Gcc continues to using the more system friendly RunCommand() function in dos.library to start subcompilers. Gccv has the advantage of being able to work with interprocess pipes, thus (provided you have the memory ;-)), you're able to do gccv -pipe your_program.c causing the preprocessor (cpp), the C-compiler (cc1) and the assembler (as) to run at the same time, passing intermediate files through internal pipes instead of using temporary files. As long as you don't want that feature (OK, playing with certain make tools also requires gccv) you're safe using gcc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D stack size =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D You need to have a stack size of 50000 in order to compile with GCC. This should be enough for most projects. Note than while recompiling GCC with itself it has taken more than 300 kB of stack. Stack usage can grow due to source complexity. Don't be afraid of it. To set the stack size, see the AmigaDOS Command 'stack'. To use ar and/or ranlib, 50 kB is the minimum acceptable stack. You should have a much larger stack, if you use larger libraries. Starting with 2.6.3 a new environment variable, GCCSTACK, enables gcc to read this variable and set stack upon startup. Thus now no need to set stack to huge values, only gcc/ld/cpp/cc1#? will automatically set new stack, according to GCCSTACK variable. Simply commit a: setenv GCCSTACK value to set gcc stack to value. Benefits: Huge memory savings. =3D=3D=3D=3D=3D=3D=3D=3D priority =3D=3D=3D=3D=3D=3D=3D=3D Starting also with 2.6.3 a new environment variable, GCCPRIORITY, let you specify a default process priority for GNU compiler. Setting it to -1 enable your Amiga to do something else while compiling :-) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D C++ headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D With AmigaDOS it makes no difference whether a name has capital or lower-case letters in names when finding files (i.e. it is case insensitive), you'll certainly run into problems with some headers, including String.h and normal string.h. My suggestion for now is to add to C++ "faulty" header file name an "_" in front of it, thus String.h would become _String.h. Sorry for the inconvenience. (thanks to Dirk Nehring for reminding me about this annoying "feature"). =3D=3D=3D=3D=3D=3D=3D Patches =3D=3D=3D=3D=3D=3D=3D Includes: J=CErg H=CEhle hoehle@inf-wiss.uni-konstanz.de There is a conflict between the Amiga and the UNIX definition of the timeval structure. Markus Wild proposed in GCC233 to patch the Amiga devices/timer.h file so that it loads the UNIX sys/time.h file (and thus tons of other files) (see os-include/devices/timer.mwild.path). I suggest that sys/time.h and devices/timer.h be modified to detect each other and use whichever structure was declared first (see os-include/devices/timer.jch.patch). The supplied include/sys/time.h file works this way. You can apply the patches with the program patch or by hand. The original devices/timer.h file is copyrighted by Commodore-Amiga and not included, but here is the patch: + #ifndef _SYS_TIME_H_ + /* Use whatever was included first, standard (sys/time.h) or Amiga + * includes (jch). */ struct timeval { ULONG tv_secs; ULONG tv_micro; }; + #else + #define tv_secs tv_sec + #define tv_micro tv_usec + #endif The sys/types.h defined BPTR causing conflicts with Amiga includes. I removed the BPTR definition from sys/types.h and sys/proc.h. In GCC233, there was no such definition either. I moved the ixemul.h file from include/ to the ixemlib/library/ directory. The ixemlib/ directory could contain the ixemul.library sources. In the ixemul source tree, ixemul.h is found in the library/ directory. Furthermore I patched it so that it is now able to compile a working ixconfig. It was broken (because of the broken ixemul.h) in GCC252/3/4. It previously worked in GCC233 but didn't provide the -e option. The ixemlib/library/version.h is an empty fake. I don't have a newer ixemul.h file. There's yet another minor patch I'd like to suggest: *** include/stdlib.h.orig Mon Aug 10 15:28:54 1992 --- include/stdlib.h Fri Dec 09 17:12:38 1993 *************** *** 72,76 **** --- 72,80 ---- void *calloc __P((size_t, size_t)); div_t div __P((int, int)); + #if 0 void volatile exit __P((int)); + #else /* new ANSI-C interpretation */ + typedef void exit_t __P((int)); volatile exit_t exit; + #endif void free __P((void *)); char *getenv __P((const char *)); =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ld (GNU linker) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Starting from 2.5.8 release, ld behaviour over symbols has changed. Default is now to strip all symbols from generated executable ONLY if environment variable LDSTRIP is set (to whatever you want). Otherwise, '-s' flag will strip symbols, as usual. Also packing of uninitialized data will be done automatically if LDSHORTDATA is set (to whatever you want). Ld also knows about -chip and -fast keywords, gcc will soon handle them directly. Ld is using now flavours, which are generated depending on gcc flags: Gcc option Flavor passed to ld -m68020 -fl libm020 -noixemul -fl libnix -resident -fl libb Thus ld when searching for libraries, adds those flavours to the library search path, in alphabetical order. Normal search path is /gnu/lib, and if for example you want to compile using -m68020 -noixemul ld will look for libgcc.a in: /gnu/lib/libm020/libnix first, then it will reduce flavours, one by one, if it can't find required library in flavour's expanded path. This means that it will try to find libgcc.a in: /gnu/lib/libm020 and in /gnu/lib/. Because libgcc.a exists in /gnu/lib/libm020, ld will take this one. There is as for now 8 possibilities: Flavors Search path libb libm020 libnix 0 0 0 /gnu/lib/ normal 0 0 1 /gnu/lib/libnix/ non-ixemul 0 1 0 /gnu/lib/libm020/ normal 68020 0 1 1 /gnu/lib/libm020/libnix/ non-ixemul 68020 1 0 0 /gnu/lib/libb/ baserel 1 0 1 /gnu/lib/libb/libnix/ baserel non-ixemul 1 1 0 /gnu/lib/libb/libm020/ baserel 68020 1 1 1 /gnu/lib/libb/libm020/libnix/ baserel 68020 non-ix Using this approach makes adding flavours pretty easy, if someone wants for example to add 68881 libraries, a new flavour will have to be created, libm881, and thus the maximum flavour search path level would be: /gnu/lib/libb/libm020/libm881/libnix, which can be translated to English as: "I want a base-relative library compiled using Motorola 68020 and coprocessor 68881, not using ixemul.library". =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D GCC and its "pragmas" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >From Gunther Nikl: Accessing operating-system functions on the Amiga requires to pass arguments in specific processor registers. C, however, uses a different calling convention: it pushes all arguments in reverse order onto the stack, calls the function and finally removes the arguments from the stack by simply correcting the stack pointer. One solution to interface C and the calling convention for the system-functions are so called "glue"-functions that convert arguments passed on the stack into the OS-function convention. These glue routines are located for all system libraries in a link library named libamiga.a. Obviously this method is inefficient. Most Amiga C-compilers have the capability of in-line calls to OS functions using a C language extension "#pragma". The format of a pragma statement and file names differ from compiler to compiler. GCC supports in-line calls too but not with pragmas. the GCC solution is based on the fact that GCC is able to integrate small functions into the caller. This method is known from C++ as "inlining". Thus functions that are declared "inline" (preferable in conjunction with the keyword static or extern but see the next chapter) get integrated. As you can see writing programs that compile with several compilers and use its capability of making in-line calls to libraries is a tricky thing. To get programs more portable between Amiga C-compilers a new set of include files would be helpful that hide the different methods for in-line calls from the user. These files are located in a drawer called proto e.g. "proto/exec.h". Instead of writing (only an example!): #include #ifdef __GNUC__ #include #endif now the following should be used: #include to achieve the same result! Nice, isn't it? The general rule for the all files is: #include with "xxx" replaced with the first part of a clib proto-headers name e.g. "exec_protos.h" becomes "exec.h" In general each file first includes its function prototype header then the compiler specific "pragma" header and finally declares the library base extern. The GCC files are in the following format: (1) include some C=3D headers to prevent errors with GCC (2) include the function prototypes from the clib drawer (3) include the inline header if this is not disabled and if optimizing (4) declare the library base extern if its not disabled Step 3 will only be executed if GCC is optimizing. Otherwise the compiler won't integrate any function. Even when optimizing it could be not desired to include the inline header because it requires some amount of memory and the compile time enlarges significantly. Therefore step 3 can be disabled with: - a define on the command line "-D__NOINLINES__" or - a define before the proto headers are included "#define __NOINLINES__" Declaring the library base as an external variable can disabled with a define in the same way. The define is called "__NOLIBBASE__". This define can be useful if its not desired to have the library base declared extern. Using the new proto headers has some advantages then using the clib and inline files by itself: (1) better compatibility with SAS/C. It should be much easier to compile programs developed for SAS/C with GCC - almost ;) no need to adjust includes (2) almost ;) optimal code because depending on the optimization level the best suited include set will be used (3) internal compiler specific requirements are hidden from the user For the exec.library the proto header has one additional goodie: it "implements" SAS/C "_USEOLDEXEC_". Defining this forces to evaluate the absolute address 4 every time the library base for the exec.library is required. In this case no global library base is necessary but it must be noted that programs compiled with this option enabled can have performance problems because AbsExecBase is located in Chip-Memory. Be aware: if using _USEOLDEXEC_ its *NOT* legal to declare or define SysBase! If you do so strange things may happen ... Please note that some function in libamiga.a require a global "SysBase" so that those functions cannot be used. Some problems still remain but these restrictions come from the inline technique. Library bases have to be global due to the nature of the inlines. SAS/C, however, is able to use local variables or structure elements as library bases. In this case the library bases has to be made global for GCC. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D inline headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D One major advantage of GCC is its ability to integrate simple functions into the caller. To direct the compiler to inline a function the keyword "inline" in combination with "static" or "extern" can be used. Previous version of the inlines used static in the definition. This had the effect that functions compiled to assembler if optimization is disabled. The new inline headers use extern definitions. Functions defined inline and extern can be considered as macros. That means the definition is only used for inlining thus requiring linking with a library containing stubs. From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 14:09:11 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90032-3>; Mon, 21 Aug 1995 14:08:36 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.140836+0300_eet_dst.90032-3+34@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 14:08:30 +0300 Date: Mon, 21 Aug 1995 13:08:32 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Uploads to FUNET Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Please, if you upload something to ftp.funet.fi, could you make a short .readme file or something like that so it is possible to know what is in the archives? P.S. Yes yes, I know that the README got sent with 'qouted-printable'. Get it from "http://srv2.gbar.dtu.dk:8001/Rask/README-2.7.0". Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 14:20:00 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90166-2>; Mon, 21 Aug 1995 14:17:43 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.141743+0300_eet_dst.90166-2+26@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 14:17:34 +0300 Date: Mon, 21 Aug 1995 13:17:36 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Corrupt README archive on FUNET Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, lha complains about checksum errors and invalid headers in ftp://ftp.funet.fi/pub/amiga/gnu/beta/gcc270-readme.lha Philippe, can you upload it again? What has changed between the last two prereleases? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 14:26:59 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90595-1>; Mon, 21 Aug 1995 14:24:06 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 21 Aug 1995 13:23:48 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA18627; Mon, 21 Aug 95 13:23:48 +0200 Date: Mon, 21 Aug 95 13:23:48 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508211123.AA18627@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA05093; Mon, 21 Aug 95 13:23:48 +0200 To: amiga-gcc-port@nic.funet.fi Subject: Re: including some PD .c or .h files into GCC In-Reply-To: <199508190959.LAA24378@honshu.informatik.uni-rostock.de> References: <9508181331.AA13772@inf-wiss.uni-konstanz.de> <199508190959.LAA24378@honshu.informatik.uni-rostock.de> Gunther Nikl writes: > > Others include a very small BPTRprintf using the exec.library > > RawDoFmt (like the one in the GURU book, but hopefully without the > > bugs there :-( > What bugs do you refer to? I couldn't find one... I even have The bugs in the BPTRprintf (if that's the name, at least it's what the function does) assembly source. I read it and it made no sense to me, I typed it in and my negative expectations were fulfilled. I wrote another one from scratch. Don't know about other bugs. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 14:27:28 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90177-3>; Mon, 21 Aug 1995 14:25:35 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.142535+0300_eet_dst.90177-3+36@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 14:25:27 +0300 Date: Mon, 21 Aug 1995 13:25:29 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: CONSOLE: vs. * Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Why does ixemul open "*" instead of "CONSOLE:"? Commodore has declared "*" obsolete as of OS 2.0. This is now 5 (five) years ago. I think Commodores guidelines should be followed and I think it is time to stop using "*". Here is a quote from the dos.library/Open() autodocs (taken from "Amiga RKRM: Includes and Autodocs" Third Edition): "Note that as of V36, "*" is obsolete, and CONSOLE: should be used instead." Non-CLI processes can create, read and write files with the name "*" and when (if?) Amiga Technologies decides to remove the "*" hack, there will be a potential danger of accidentally overwriting files named "*" when starting programs compiled with GCC. 5. HD1:> List GNU:? Directory "GNU:" on S=D6ndag 20-Aug-95 * 4 ----rwed i dag 13:20:39 s Dir ----rwed 07-Aug-95 15:05:50 1 file - 1 directory - 3 blocks used Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 14:28:00 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90150-4>; Mon, 21 Aug 1995 14:24:47 +0300 Received: by ceylon.informatik.uni-rostock.de id NAA09609; Mon, 21 Aug 1995 13:24:40 +0200 Received: by honshu.informatik.uni-rostock.de id NAA02386; Mon, 21 Aug 1995 13:24:40 +0200 From: Gunther Nikl Message-Id: <199508211124.NAA02386@honshu.informatik.uni-rostock.de> Subject: Re: your mail To: amiga-gcc-port@nic.funet.fi Date: Mon, 21 Aug 1995 13:24:40 +0200 (MET DST) In-Reply-To: <95Aug21.141743+0300_eet_dst.90166-2+26@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 21, 95 02:17:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 239 > lha complains about checksum errors and invalid headers in > > ftp://ftp.funet.fi/pub/amiga/gnu/beta/gcc270-readme.lha Just downloaded it from there and did not noticed an error (but I did NOT used a WEB browser...) Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 14:30:32 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90277-4>; Mon, 21 Aug 1995 14:27:43 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.142743+0300_eet_dst.90277-4+46@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 14:27:40 +0300 Date: Mon, 21 Aug 1995 13:27:42 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Driver (gcc) problems Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Recently I installed an update to the gcc 2.7.0 distribution. Now I'm suddenly having lots of trouble with gcc. First, it couldn't find the preprocessor (ccp). It searched my path, but didn't look in "GNU:lib/gcc-lib/mc68000-cbm-amigados/2.7.0". OK, so I added that directory with a "Path ADD" command. Then take a look at this: 5. HD1:gnu> gcc -v resident-test.c -O3 -o resident-test-O3 gcc version 2.7.0 cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -D__OPTIMIZE__ -Dmc68010 resident-test.c HD1:T/cc646560.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. cc1 HD1:T/cc646560.i -mfixedstack -quiet -dumpbase resident-test.c -O3 -version -o HD1:T/cc646560.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. as -mc68010 -o HD1:T/cc6465601.o HD1:T/cc646560.s ld -o resident-test-O3 /gnu/lib/crt0.o -L/gnu/lib HD1:T/cc6465601.o -lgcc -lc -lamiga -lc -lgcc ld: No such file or directory for libgcc.a Look at the arguments given to "ld": It is told to link with libgcc.a and libc.a twice. And it can't find libgcc.a. On my system, this file is in directory "GNU:lib/gcc-lib/mc68000-cbm-amigados/2.7.0" but the linker isn't told that it should search that directory. gcc 2.6.3 has no trouble even without having "GNU:lib/gcc-lib/mc68000-cbm-amigados/2.7.0" in the search path: 5. HD1:gnu> :gnu-2.6.3/bin/gcc -V 2.7.0 -v resident-test.c -O3 -o resident-test-O3 Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/specs gcc version 2.6.3 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -D__OPTIMIZE__ -Dmc68010 resident-test.c HD1:T/cc723008.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cc1 HD1:T/cc723008.i -mfixedstack -quiet -dumpbase resident-test.c -O3 -version -o HD1:T/cc723008.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. as -mc68010 -o HD1:T/cc7230081.o HD1:T/cc723008.s ld -o resident-test-O3 /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 -L/gnu/lib HD1:T/cc7230081.o -lgcc -lc -lamiga -lc -lgcc It still links with libgcc.a and libc.a twice, but it works! Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 14:35:47 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90639-3>; Mon, 21 Aug 1995 14:33:51 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.143351+0300_eet_dst.90639-3+39@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 14:33:45 +0300 Date: Mon, 21 Aug 1995 13:33:47 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Diff -4u for GCC-Install Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I had a look at the GCC-Install script from the 2.7.0 distribution and found a few things to correct: - The missing " in line 489 as reported by Philippe BRAND. - Don't put a "," in front of "that" (line 692, 1098 and 1238). - "Asign" -> "Assign" in line 950. - Missing space in line 1207 and 1399. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ --- GCC-Install Thu Aug 3 01:35:44 1995 +++ GCC-Install.new Sun Aug 20 14:14:20 1995 @@ -485,9 +485,9 @@ )) (if (NOT deinstallBinaryOk) ( (message "Cannot find GNU C in " deinstallDir ". A " "possible reason is a missing or wrong GNU: " - "assign.) + "assign.") )) )) (CompleteStep) ) @@ -688,9 +688,9 @@ (set varsToCreatePrompt "Installing environment variables in \"ENVARC:\"") (set varsToCreateHelp (cat "Some environment variables are required or encouraged.\n\n" - "GCCSTACK ensures, that gcc won't run out of stack. " + "GCCSTACK ensures that gcc won't run out of stack. " "GCCPRIORITY is the priority of gcc's child processes.\n" "LESSCHARSET, PAGER and TERM usually aren't needed, " "except, if you are using \"less\" or similar programs.\n\n" )) @@ -946,9 +946,9 @@ " Path GNU:bin add\n" " ELSE\n" " Assign GNU: EXISTS >nil:\n" " IF WARN\n" - " Echo \"Asign GNU: doesn't exist.\"\n" + " Echo \"Assign GNU: doesn't exist.\"\n" " QUIT 5\n" " ELSE\n" " Echo \"Assign GNU: exists.\"\n" " ENDIF\n" @@ -1094,9 +1094,9 @@ "gcc-020, g++-020, ... to gcc, g++, ..., " "respectively?" ) (help "Some users have both 68000 and 68020 binaries " - "available. This requires, that certain binaries " + "available. This requires that certain binaries " "like gcc, g++ ... have the ending \"-020\" " "appended to their name.\n\n" "Most others won't prefer to use the names gcc, " "g++, ..., however. If you do, select \"Yes\", " @@ -1203,9 +1203,9 @@ "The simplest and safest is to copy them to " (tackon installDir "os-include") ".\n\n" "Another possibility would be to setup certain " "environment variables, so that gcc will always " - "look into " osHeadersDir "when searching header " + "look into " osHeadersDir " when searching header " "files.\n\n" "The same result is accomplished by modifying the " "so-called specs file. This is the recommended " "method, although it is less visible for the user.\n\n" @@ -1234,9 +1234,9 @@ ( (message "You can still use the OS headers, either by " "adding -I" osHeadersDir " to your gcc command " "line or by copying them to " (tackon installDir "os-include") ".\n\n" - "Be sure, that you don't override gcc header " + "Be sure that you don't override gcc header " "files in the latter case, especially the " "proto directory might be overwritten." ) )) @@ -1395,9 +1395,9 @@ (prompt "Please select actions to perform.") (help "Select \"Deinstall existing version\", if you want " "to remove an existing package.\n\n" "Select \"Install new version\", if you want to " - "replace the existing version with a new version." + "replace the existing version with a new version. " "Installing a new version implies reconfiguring it " "later.\n\n" "Select \"Configure existing version\", if you don't " "want to install a new version and just reconfigure " From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 14:37:24 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90896-2>; Mon, 21 Aug 1995 14:35:22 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.143522+0300_eet_dst.90896-2+29@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 14:35:19 +0300 Date: Mon, 21 Aug 1995 13:35:12 +0200 (METDST) From: Rask Lambertsen To: Gunther Nikl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: your mail In-Reply-To: <199508211124.NAA02386@honshu.informatik.uni-rostock.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 21 Aug 1995, Gunther Nikl wrote: > > lha complains about checksum errors and invalid headers in > > > > ftp://ftp.funet.fi/pub/amiga/gnu/beta/gcc270-readme.lha > > Just downloaded it from there and did not noticed an error > (but I did NOT used a WEB browser...) You're right, it works with FTP. I guess I just hit YANB (Yet Another Netscape Bug). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 14:51:31 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <90622-1>; Mon, 21 Aug 1995 14:47:55 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id NAA09158; Mon, 21 Aug 1995 13:37:53 +0200 From: Jochen Wiedmann Message-Id: <199508211137.NAA09158@iss1.neckar-alb.de> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Mon, 21 Aug 1995 13:37:53 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Aug21.142535+0300_eet_dst.90177-3+36@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 21, 95 02:25:27 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1310 Hello, Rask, > Why does ixemul open "*" instead of "CONSOLE:"? Commodore has > declared "*" obsolete as of OS 2.0. This is now 5 (five) years ago. > I think Commodores guidelines should be followed and I think it is > time to stop using "*". Here is a quote from the dos.library/Open() > autodocs (taken from "Amiga RKRM: Includes and Autodocs" Third Edition): > > "Note that as of V36, "*" is obsolete, and CONSOLE: should be used > instead." This was discussed over and over again. Ralph Babel's opinion (which is okay for me) is, that - console: is for use in a shell. There's no problem in using the name * in an Open() call. - Using * is backwards compatible (note, that ixemul can still run on 1.3, AFAIK) Thus it is the recommended behaviour to use console: in a shell command an * when directly calling the Open() function. > Non-CLI processes can create, read and write files with the name "*" > and when (if?) Amiga Technologies decides to remove the "*" hack, > there will be a potential danger of accidentally overwriting files > named "*" when starting programs compiled with GCC. They won't. Why should they? This isn't a hack, it's a documented behaviour. And whoever is using filenames like '*', is on the dangerous side in any case. Jochen From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 15:06:43 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90509-2>; Mon, 21 Aug 1995 15:06:03 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 21 Aug 1995 14:05:46 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA18768; Mon, 21 Aug 95 14:05:46 +0200 Date: Mon, 21 Aug 95 14:05:45 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508211205.AA18768@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA05101; Mon, 21 Aug 95 14:05:46 +0200 To: amiga-gcc-port@nic.funet.fi Subject: WWW gives you libauto.a (Re: inline patches) In-Reply-To: <21289434.u7t157e.d6493-robert@plukwa.pdi.lodz.pl> References: <21289434.u7t157e.d6493-robert@plukwa.pdi.lodz.pl> Robert Ramiega writes: > Once more i'm begging someone to send me working libauto.a i need it badly > and it would be stupid to download whole gcc263-inclib.lha just to get ~30 > Kb file. Please please!!!!!!! Some custom Aminet WWW browsers allow you to view (and then to extract) the contents of individual files from the lha archives. Thus you can peek at documentation, sources etc. without extracting the whole archive. Aminet at Erlangen for example can do this. Now if you don't have WWW, I can send you the uuencoded rw-r--r-- 0/1 3983 23122 17.2% -lh5- 89c9 Jul 23 1994 gnu/lib/libauto.a out of -rw-r--r-- 1 gruber infwiss 1318762 Jan 2 1995 gcc263-inclib.lha Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 15:07:07 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90916-3>; Mon, 21 Aug 1995 15:06:33 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 21 Aug 1995 14:06:23 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA18773; Mon, 21 Aug 95 14:06:23 +0200 Date: Mon, 21 Aug 95 14:06:23 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508211206.AA18773@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA05102; Mon, 21 Aug 95 14:06:23 +0200 To: amiga-gcc-port@nic.funet.fi Subject: Re: your mail In-Reply-To: References: <21289391.u7t157e.a198e-jtv@asd05-21.dial.xs4all.nl> Erik Johannessen writes: > I'm running VMM 3.0 on an A4000 Cyberstorm 040 system. Using gcc-2.7.0 > (3-Aug) together with VMM gives horrible crashes. My machine just resets > without giving a software failure. I had no problems using gcc-2.6.3 > together with VMM 3.0 on a normal A4000/040. > I haven't looked at it yet, but could the stack extension code cause such > behaviour? Is the code really in cc1 (and the others)? It didn't seem to me like stack was extended. Cc1 crashed with a too small stack. I'm using the archives I found on 3rd of August. > > It's not public domain anymore. VMM 3.1 is shareware (and works > > fine with gcc). > ^^^ 2.7.0? VMM-2.1 works very reliably for me (A4000/40/3.1) is freely distribuable, does not use MUI, does not swap code out (I don't trust this feature but I'll have to test VMM>=3.x some day) and works fine with GCC-2.5.8, 2.6.3 and 2.7.0 (and many other programs). Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 15:08:41 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90881-4>; Mon, 21 Aug 1995 15:08:18 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.150818+0300_eet_dst.90881-4+2@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 15:08:17 +0300 Date: Mon, 21 Aug 1995 14:07:04 +0200 (METDST) From: Rask Lambertsen To: Jochen Wiedmann Cc: amiga-gcc-port@nic.funet.fi Subject: Re: your mail In-Reply-To: <199508211137.NAA09158@iss1.neckar-alb.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 21 Aug 1995, Jochen Wiedmann wrote: > Hello, Rask, > > > I think Commodores guidelines should be followed and I think it is > > time to stop using "*". Here is a quote from the dos.library/Open() > > autodocs (taken from "Amiga RKRM: Includes and Autodocs" Third Edition): > > > > "Note that as of V36, "*" is obsolete, and CONSOLE: should be used > > instead." > > This was discussed over and over again. Ralph Babel's opinion (which > is okay for me) is, that > > - console: is for use in a shell. There's no problem in using > the name * in an Open() call. > - Using * is backwards compatible (note, that ixemul can still > run on 1.3, AFAIK) > > > Thus it is the recommended behaviour to use console: in a shell > command an * when directly calling the Open() function. Remember that the RKRM's are ment for programmers, not for normal users. Normal users don't call Open(), programmers do. Normal user won't even read the RKRM's, and this information is not available in the user manual. As for backwards compatibility, that's fine, but not if we could loose compatibility with future versions of the OS. > > Non-CLI processes can create, read and write files with the name "*" > > and when (if?) Amiga Technologies decides to remove the "*" hack, > > there will be a potential danger of accidentally overwriting files > > named "*" when starting programs compiled with GCC. > > They won't. Why should they? This isn't a hack, it's a documented > behaviour. It is documented as being obsolete. I'm sure people have different oppinions on what that means, but I see it a warning: "Stop using it, it will stop working at some point". Otherwise, why was it declared obsolete in the first place? > And whoever is using filenames like '*', is on the > dangerous side in any case. Why? I don't think ixemul should dictate that users can't use "*" as a file name if they want to. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 15:11:28 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90911-2>; Mon, 21 Aug 1995 15:11:08 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Mon, 21 Aug 95 14:09:58 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <212c54b3.u7t157e.c16aa-robert@plukwa.pdi.lodz.pl> Subject: libauto.a In-Reply-To: <199508211206.OAA26155@gryzmak.pdi.lodz.pl> (from <@plearn.edu.pl:AMIGA-GCC-PORT-OWNER@NIC.FUNET.FI>) (at Mon, 21 Aug 1995 14:06:47 +0200) Reply-To: robert@pdi.lodz.pl Content-Length: 879 To: amiga-gcc-port@nic.funet.fi Date: Mon, 21 Aug 95 14:09:58 > Robert Ramiega writes: > > Once more i'm begging someone to send me working libauto.a i need it badly > > and it would be stupid to download whole gcc263-inclib.lha just to get ~30 > > Kb file. Please please!!!!!!! > I want to thank this way to all kind souls who sent me the libauto.a. From my lest beg i got numerous copies of it. I really appreciate Your help! best regards to all of You Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 15:28:42 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90396-1>; Mon, 21 Aug 1995 15:27:49 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.152749+0300_eet_dst.90396-1+1@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 15:27:46 +0300 Date: Mon, 21 Aug 1995 14:27:49 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Incorrect part of README? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I think I have found some incorrect information in the README-2.7.0. It says: ------------------- ===== ARexx ===== The provided ARexx scripts have been contributed by Loren J. Rittle. If you like ARexx, they're an alternate way of calling GCC. They automatically make sure you're using a large enough stack setting, and enable you to compile C++ programs with less obscure options. This approach is furthermore useful if you're not able to use the g++ /bin/sh script. --------------------- That is incorrect, isn't it? g++ is an executable now, not a /bin/sh script, right? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 15:50:16 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90443-3>; Mon, 21 Aug 1995 15:49:20 +0300 Received: by colombo.telesys-innov.fr; Mon, 21 Aug 1995 14:49:02 +0100 From: Philippe BRAND Message-Id: <199508211349.OAA27528@colombo.telesys-innov.fr> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Mon, 21 Aug 1995 14:49:01 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95Aug21.142743+0300_eet_dst.90277-4+46@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 21, 95 02:27:40 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 619 gc948374@gbar.dtu.dk writes: > I'm suddenly having lots of trouble with gcc. First, it couldn't find > the preprocessor (ccp). It searched my path, but didn't look in > "GNU:lib/gcc-lib/mc68000-cbm-amigados/2.7.0". OK, so I added that > directory with a "Path ADD" command. Then take a look at this: Please test latest archive. I didn't have such problems. > It still links with libgcc.a and libc.a twice, but it works! This is normal. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 15:52:47 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90838-2>; Mon, 21 Aug 1995 15:51:35 +0300 Received: by colombo.telesys-innov.fr; Mon, 21 Aug 1995 14:51:31 +0100 From: Philippe BRAND Message-Id: <199508211351.OAA27548@colombo.telesys-innov.fr> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Mon, 21 Aug 1995 14:51:30 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95Aug21.141743+0300_eet_dst.90166-2+26@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 21, 95 02:17:34 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 592 gc948374@gbar.dtu.dk writes: > lha complains about checksum errors and invalid headers in > ftp://ftp.funet.fi/pub/amiga/gnu/beta/gcc270-readme.lha > Philippe, can you upload it again? Nope :) > What has changed between the last two prereleases? I wrote it in my last email: ld using GCCSTACK, gccopt1.3, fixed headers, and fixed README., and soon_to_ne_patched_by_the_author_himself GCC-Install script :) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 16:01:20 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90808-2>; Mon, 21 Aug 1995 16:00:18 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.160018+0300_eet_dst.90808-2+5@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 16:00:13 +0300 Date: Mon, 21 Aug 1995 15:00:08 +0200 (METDST) From: Rask Lambertsen To: Philippe BRAND Cc: Amiga-Gcc Liste Subject: New README-2.7.0 In-Reply-To: <199508211351.OAA27548@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I have had a look at the README from the latest gcc270-readme.lha and made a few changes, extensive work wrapping. It is available as http://srv2.gbar.dtu.dk:8001/Rask/README-2.7.0 Someone with a WWW browser, please post it to the list, as I can't do so due to my mail header problems. And please respond to my post about the ARexx section: ===== ARexx ===== The provided ARexx scripts have been contributed by Loren J. Rittle. If you like ARexx, they're an alternate way of calling GCC. They automatically make sure you're using a large enough stack setting, and enable you to compile C++ programs with less obscure options. This approach is furthermore useful if you're not able to use the g++ /bin/sh script. g++ is no longer a /bin/sh script, but an executable, right? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 16:22:24 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90236-3>; Mon, 21 Aug 1995 16:21:55 +0300 Received: by colombo.telesys-innov.fr; Mon, 21 Aug 1995 15:21:45 +0100 From: Philippe BRAND Message-Id: <199508211421.PAA27673@colombo.telesys-innov.fr> Subject: Re: New README-2.7.0 To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Mon, 21 Aug 1995 15:21:44 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Rask Lambertsen" at Aug 21, 95 03:00:08 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 649 Rask Lambertsen writes: > I have had a look at the README from the latest gcc270-readme.lha > and made a few changes, extensive work wrapping. It is available as > > http://srv2.gbar.dtu.dk:8001/Rask/README-2.7.0 > > Someone with a WWW browser, please post it to the list, as I can't do so due > to my mail header problems. I will. > g++ is no longer a /bin/sh script, but an executable, right? Correct :) Fix readme and drop me an email so that I'll grab it. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 16:23:51 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90162-2>; Mon, 21 Aug 1995 16:23:26 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Mon, 21 Aug 95 15:22:22 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <212c6596.u7t157e.98037-robert@plukwa.pdi.lodz.pl> Subject: README 2.7.0 Reply-To: robert@pdi.lodz.pl Content-Length: 38700 To: amiga-gcc-port@nic.funet.fi Date: Mon, 21 Aug 95 15:22:22 Short: gcc v2.7.0 - C/C++/ObjC Compiler set for AmigaDOS Type: dev/gcc Uploader: phb@colombo.telesys-innov.fr Author: phb@colombo.telesys-innov.fr This is the AmigaDOS 2.7.0 GNU C/C++/Objc compiler. The GNU C compiler is free software. See the file COPYING for copying permission. PLEASE be sure to read README file enclosed in gcc270-readme.lha FIRST. =============== How to get help =============== There's an Amiga-GCC mailing list running in Finland, read README-LIST file. This is the preferred place to ask for help since I'm on this list and every GCC developers also, libnix & ixemul authors, etc... Short: send an email to listserv@lists.funet.fi, and put in body: subscribe amiga-gcc-port your_first_name your_last_name (insert your own first name and your own last name above) Otherwise you can contact me at: Philippe BRAND Fidonet: Ramses The Amiga Flying BBS 2:320/104.0 Email: phb@colombo.telesys-innov.fr (ONLY for personal email). WWW: www.telesys-innov.fr Ftp: ftp.telesys-innov.fr:/pub/amigados-gnu or /pub/incoming/uploads for uploads. Note: I'll forward any question to this mailing-list, but please use it directly, except when you send files, in this case send them to my ftp site. Note 2: ftp.funet.fi mirrors my amigados-gnu tree. Using ftp.funet.fi is preferable as they have much more bandwidth (/pub/amiga/gnu). ============ Requirements ============ - Systems: Any Amiga (ranging from A1000 up to A4000/40, including CD-32 & SX-1) will run AmigaDOS-GNU utilities. - Memory: A minimum of 4 MB of free memory is needed in order to compile small/medium projects. More memory will be needed for large projects, such as recompiling GCC itself. Gigamem is known to work with GCC so *maybe* less memory will work. But in this case, you'll need an MMU equipped Amiga (A3000,A4000/40, etc...). VMM40 (Public Domain Virtual memory manager) is also known to work with GCC. - OS: Starting from version 2.5.x, 1.3 systems are not longer supported. GCC runs fine on all other systems, starting from 2.04 up to 3.1 (40.68). - Disk Space; An installation of GCC requires the use of a hard disk. Approximately 10 MB is required at present to install the compiler and utilities required to use it. In addition 3 MB is required for the Commodore Developer Kit, which is required to be able to compile AmigaDOS specific programs. ========================== What's new in this release ========================== 2.7.0 - Read FSF NEWS-2.7.0 file included. - As always, generic bugs fixed (see Changelog in GCC sources for details). - FSF listing shell script suppressed. - new as/ld/size/nm/ranlib using BFD, made by Raphael Luebbert - as fixed, used to generate some 020 instructions while in 68000 mode. - all programs recompiled using 2.7.0 compiler. - new inlines headers. - new compiler options: -mstackcheck and -mstackextend, to respectively implement stack checking and auto-stack growing into GCC compiled programs. - resident option is now fixed. - new ixemul library, v41.1 (complete distribution can be found on Aminet site) . - new libnix, v1.0 (sources can be found also on Aminet sites, in libnix archiv e). This release is dedicated in memory of Pierre Carette. ================================= What was new in previous releases ================================= 2.6.3 - Read FSF NEWS-2.6.1 file included. - As always, generic bugs fixed (see Changelog in GCC sources for details). - q_anote package replaced by FSF listing shell script, need awk. - new as/ld/size/nm/ranlib, made by Raphael Luebbert - new environent variables GCCPRIORITY and GCCSTACK, see below. - all programs recompiled using 2.6.3 compiler. - mit2mot & mot2mit, convert asm syntax between Motorola and MIT syntaxes. - all programs hold AmigaDOS compatible $VER string. 2.6.2 - internal release only. 2.6.1 - Read FSF NEWS-2.6.1 file included. - As always, generic bugs fixed (see Changelog in GCC sources for details). - new option -priority in gcc allowing process priority setting. - new specs file, inlines/protos and libamiga done by Gunther Nikl. See note below. - new libnix version by Matthias Fleischer & Gunther Nikl. - new ixemul version by Raphael Luebbert. - stripc program to strip all uneccessary stuff from headers by Chris Metcalf, submitted by Lars Hecking. - q_anote, annotate assembly files mixing C source code, submitted by Walter Harms (Walter.Harms@arbi.informatik.uni-oldenburg.de), written by Mike Albaugh (albaugh@agames.com). See note below. - new assembler, as-2.5, using new BFD (Binary File Descriptor), made by Raphael Luebbert. 2.6.0 - Read FSF NEWS-2.6.0 file included. - Extensive internal compiler bugs fixed (see ChangeLog in GCC sources for details), tons of bugs fixed for C++ support. - ld changed (see note for ld below). - new ixemul.library, with optimized versions for accelerated Amigas, see README-ixemul & ixemul.guide for more informations. - new C library (libnix) disabling use of ixemul.library for generated programs (best use for AmigaDOS specific programs). Full ANSI compliant, see README-libnix & libnix.guide for more informations. - revised inline headers in accordance with new ixemul.library. - libamiga.a is now distributed with GCC-2.6.1. - as v2.3 is included, along with a macro-assembler (gasp). - stderrfix.o (see below) patch applied. - Upgrade to libg++-2.6. - GCC now supports $VER string for AmigaDOS version compatibility. 2.5.8 - Read FSF NEWS-2.5.8 file included. - ld behaviour over symbols changed (see note below). - added flavours so that linker will take appropriate libraries according to gcc options (m68020 libraries/baserel libraries, etc...). - gpc (GNU-Pascal) v1.03 added. - all utilities recompiled with GCC-2.5.8. - plain 68000 and 68020+68881 versions of all binaries available. - More internal compiler bugs fixed (see ChangeLog in GCC sources for details), some for C++ support. - GCC-Install script fixed by Claus Deckhut (to be used with full distribution) . - Upgrade to libg++-2.5.3. - trace.c updated by J. Hoehle to avoid buffer overflows. 2.5.7: - Read FSF NEWS file included. - More internal compiler bugs fixed (see ChangeLog in GCC sources for details), a lot for C++ support. - Fred Fish seems to have finally found an annoying bug which prevented to compile a resident version of GCC, or to compile resident programs. But don't try it anyway 'cause there's still lack of library support as for now. - Man command now works, this one was my fault (well in fact like others ;-), fix done by Tom Haiko. - Infoview works also, it was an internal path problem. - libamy.a HAS TO BE RENAMED to libamiga.a because new ld won't find libamy.a - upgrade to new C++ library v2.5.1. ======= Authors ======= GCC v2.2.2 port: Markus Wild GCC v2.3.3 port: Markus Wild GCC v2.4.5 port: Philippe Brand, Lars Hecking, Fred Fish GCC v2.5.0 and up: Philippe Brand, Fred Fish, Leonard Norrgard Ixemul.library: Markus Wild (original programming), Leonard Norrgard (vinsci@nic.funet.fi), Raphael Luebbert, Stephan Isthesin. Libnix: Matthias Fleischer (fleischr@izfm.uni-stuttgart.de) and Gunther Nikl (gnikl@informatik.uni-rostock.de) Installer Prog: Jochen Wiedmann (jochen.wiedmann@zdv.uni-tuebingen.de) Thanks to all amiga-gcc-port mailing-list users for their reports and support for a better AmigaDOS-GCC and documentation. ======= Sources ======= These archives should contain everything necessary to get you going, they don't include sources for all tools (have a look at end of paragraph). As stated by Richard Stallman of the FSF: "The GPL says that any distribution of binaries must contain either the source code or a written offer to supply source code (see the GPL for details of what is required)." If you're interested in the sources required to rebuild GCC, get the gcc270-src.lha, which hold sources for GCC. Those archives should be stored either the same ftp site you got this binary distribution from (if they're not, tell the manager of that ftp site, as this is a requirement of the GNU Copyright LICENSE), either at ftp.gnu.ai.mit.edu:/pub/gnu, either on Ramses BBS (phone numbers listed below). If you have those archives, you can skip to next paragraph. If you have original FSF sources, you'll have to apply the GCC patch-file in src-patches/, and configure for `amigados'. Please note that you should have at least 40 MB left or your HD and 8 MB of memory minimum in order to rebuild GCC up to stage 3. An accelerated Amiga is welcome, as it took me 4,5 hours to generate a single pass. So 3 passes makes 4,5 x 3 = 13,5 hours. Sources for other tools only included as binaries are available separately in self-contained archives, usually having their name into the archive-name. File What gcc270-src.lha C/C++/ObjC compiler sources & diff file libnix-1.0.lha libnix sources and binaries ixemul-41.1-src.lha ixemul sources and libraries binutils-1.8.x-src.lha Sources for ld binutils-2.5.2-src.lha Sources for ar/ranlib & diff file make-3.74-src.lha make sources & diff file gdbm-1.7.3-src.lha Sources for gdbm & diff file patch-2.1-src.lha patch sources, needed to apply diff files sed-2.05-src.lha sed sources & diff file gawk-2.15.5-src.lha GNU awk sources & diff file diffutils-2.7-src.lha diff utility sources & diff file fileutils-3.11-src.lha file utilities sources & diff file sh-utils-1.12-src.lha shell utilities sources & diff file textutils-1.11-src.lha text utilities sources & diff file findutils-4.1-src.lha find sources & diff file grep-2.0-src.lha grep sources & diff file bison-1.22-src.lha bison (yacc replacement) sources & diff file flex-2.4.7-src.lha flex (lex replacement) sources & diff file texinfo-3.1-src.lha texinfo (includes makeinfo) sources & diff file gzip-1.2.4-src.lha gzip sources & diff file tar-1.11.2-src.lha gtar sources & diff file cpio-2.3-src.lha cpio sources & diff file gdbm-1.7.3-src.lha database manip. library sources & diff file termcap-1.2-src.lha termcap library sources & diff file libm-5.6-src.lha BSD mathematic library sources & diff file NOTE: All sources archives are Amiga ready, and Amiga specific diff file located in 'amiga' directory. To recompile a tool, just run a 'configure amigados' then a 'make'. Exceptions are libnix and ixemul which have their own archives, both binary & sources. On Aminet sites, libnix & ixemul in /pub/amiga/dev/gcc. ===== Where ===== **** All GNU sources & binaries are available on: - ftp.telesys-innov.fr, primary Amiga-GNU FTP site, and its mirror ftp.funet.fi which is MUCH faster than my own site. Please use it at first choice. in /pub/amigados-gnu - Aminet sites (wuarchive.wustl.edu and mirrors such as ftp.luth.se) in /pub/amiga/dev/gcc - Ramses The Amiga Flying BBS +33-1-45845623 USR V.everything 2400-33600 +33-1-53791199 USR V.everything 2400-33600 +33-1-53791200 USR Sportster V32b 2400-14400 in Topic "Development", Area "Gcc" (File Area 156). - FreshFish CDs from Fred Fish Amiga Library Services in :GNU/bin, :GNU/src, :GNU/lib dirs. 610 N. Alma School Road, Suite 18 Chandler, AZ 85224-3687 USA FAX: (602) 491-0048 VOICE: (602) 491-0442 **** GNU source code is available on: - same FTP site you've taken these archives - gnu.prep.ai.mit.edu 18.71.0.38 in /pub/gnu - Ramses The Amiga Flying BBS in Topic "AmigaUnix/Unix/Linux/NetBSD", Area "Gnu Source Code" - FreshFish from Fred Fish in :GNU/src ====== Layout ====== GCC-2.7.0 is split up into 15 archives: gcc270-readme.lha holds readmes files (include installation notes). gcc270-base.lha basic GCC distribution, hold necessary files. gcc270-inclib.lha headers and libraries. gcc270-c.lha C compiler. gcc270-c-020.lha 68020 version of C compiler. gcc270-c++.lha C++ compiler, headers and libraries. gcc270-c++-020.lha 68020 versions of C++ compiler. gcc270-objc.lha Objective-C compiler, header and libraries. gcc270-objc-020.lha 68020 versions of Objective-C compiler. gcc270-doc.lha GCC AmigaGuide(tm) documents & manpages. gcc270-utils.lha Useful utilities needed for development. gcc270-utilsdoc.lha Utilities documentation (guide & manpages). gcc270-texi.lha All Texinfo documents. gcc270-diffs.lha Diff files for all binaries. gcc270-src.lha Source for GCC-2.7.0 plus diff file. Name What Where ---- ---- ----- COPYING GNU LICENSE, read!! All archives COPYING.LIB GNU LIBRARY LICENSE, read!! All archives README-2.7.0 this file All archives NEWS-2.7.0 What's new in GCC-2.7.0 gcc270-base Installer Commodore installer utility gcc270-base GCC-Install Installer script to configure GCC All archives envarc/ global environment variables you should have set when using this programming gcc270-base environment include/ non-Amiga specific C/C++ headers gcc270-inclib os-include/proto Amiga specific protos headers. gcc270-inclib os-include/inline Amiga specific inline C headers. Add gcc270-inclib Commodore headers!! os-lib/ Amiga specific libraries gcc270-base guide/ Docs in AmigaGuide(tm) format gcc270-doc man/ this is the root for tons of man pages gcc270-doc bin/ this is /bin, and contains all gcc270-c binaries of this distribution that gcc270-c++ are meant to be directly invoked by gcc270-utils the user (contrary to the executables in lib/gcc-lib/, that are meant to be invoked by a driver program like gcc) lib/ normal (not base relatives) libraries gcc270-inclib lib/libm020/ normal 68020 libraries gcc270-inclib lib/libb/ base relatives libraries gcc270-inclib lib/libb/libm020/ base relatives using 68020 libraries gcc270-inclib lib/libnix/ Non-ixemul libraries gcc270-inclib lib/libm020/libnix/ Non-ixemul 68020 libraries gcc270-inclib lib/libb/libnix/ Non-ixemul base relatives libraries gcc270-inclib lib/libb/libm020/libnix Non-ixemul base relatives 68020 libs gcc270-inclib lib/gcc-lib/ home of compilers called by gcc gcc270-c gcc270-c++ gcc270-objc ixpipe/ a pipe handler needed by the library gcc270-base libs/ ixemul.library gcc270-base rexx/ ARexx wrappers for gcc and g++ gcc270-base src-patches/ source patches gcc270-diffs geninline/ Perl scripts to generate inline headers gcc270-inclib and -lamy glue ============== Inline-Headers ============== Since I'm not able to redistribute Amiga header files, you will have to get them directly from Commodore, unless you're an official registered Amiga developer. You can also find Development Kit on FreshFish CD-Roms. In order to generate inline-headers, follow these steps (provided Amiga headers and fd files are in os-include). If you are compiling for Kickstart 3.1 or less, you don't have to generate them, inlines are provided with the distribution. 1) First method: CLI> stack 100000 CLI> Assign INCLUDE: GCC:os-include CLI> Assign FD: INCLUDE:fd CLI> Makedir INCLUDE:inline CLI> cd USR:bin/geninline CLI> gen31 This will create all inline-headers. If you have 2.0 headers, use gen20 instead, if you have 3.0, use gen30, if you have 6.4, send it to me ;-) NOTE: perl scripts do not handle correctly AmigaDOS include files, which seems to mean they are somewhat broken. If someone could work on this... 2) Second method: Use fd2inline, which you can find on Aminet in dev/gcc. =============== Amiga Libraries =============== Starting from 2.6.0 an AmigaDOS compliant library is provided, thanks to libnix authors (Matthias Fleischer and Gunther Nikl). Anyway if you want to rebuild one, there are two methods: 1) Using hunk2gcc; the AmigaDOS object converter made by Markus Wild. To achieve this, simply grab a copy of latest amiga.lib (from Commodore Development Kit) and make a new directory where you want your converted object files to go, cd into it, and enter hunk2gcc amiga.lib [..further libs if you like..] This generates an a.out object file for every program unit present in the hunk file (in this case, from amiga.lib). As the final step convert all those files into an a.out style library by issuing: ar qc libamiga.a obj.* ranlib libamiga.a The ranlib run builds a symbol table in the archive, and makes accesses to the library much faster. 2) Creating a libamiga.a library with libnix is fairly easy, but takes some time. Just decompress sources.lha from libnix distribution and run a 'make libamiga.a'. NOTE: As long as you make no AmigaDOS specific calls, you can create a dummy library using: cat "int dummy;" >dummy.c gcc -c dummy.c ar crv libamiga.a dummy.o mv libamiga.a gcc:lib A small libamiga.a (dummy) is also provided with libnix. ==================== Upgrade Installation ==================== - You will at first have to decide if you want to keep your existing GCC compiler or not. This might sound silly, but it is in fact possible. - I want to keep older GCC compiler CLI> cd GNU:lib CLI> rename libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3 (note: replace 2.6.3 with your GCC version) CLI> rename libb/libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3/libb CLI> rename libm020/libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3/libm020 CLI> cd GNU:bin CLI> rename gcc gcc-2.6.3 CLI> rename gccv gccv-2.6.3 - I don't care about previous versions CLI> delete GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3 all quiet Proceed then to "Distribution Installation" below, for mandatory archives only. ========================= Distribution Installation ========================= NOTE: you MUST at least unpack gcc270 base, inclib and c parts. Other archives are optional. - You need first to create a directory gnu on your hard-disk and unarchive first part: CLI> cd place_with_lot_of_space CLI> makedir gnu CLI> lha x gcc270-base.lha - Now you have to append gnu/s/user-startup to your s:user-startup file (replace Devel:GNU by your own gnu path). Execute it in order to get new assigns: CLI> execute gnu/s/user-startup - Copy gnu/envarc to ENVARC: CLI> copy gnu/envarc/#? ENVARC: - GCC libraries and headers: CLI> lha x gcc270-inclib.lha - C-compiler is needed so unarchive C compiler part (Users with accelerated Amigas can unarchive gcc270-c-020 part instead) : CLI> lha x gcc270-c.lha (or gcc270-c-020) - If you want to have GCC documentation on-line, unarchive doc part: CLI> lha x gcc270-doc.lha - If you want to do C++, unarchive C++ part (Users with accelerated Amigas can unarchive gcc270-c++-020 part instead) : CLI> lha x gcc270-c++.lha (or gcc270-c++-020) Please note that 68020 versions have '.020' extension in GNU:bin. - If you want to do Objective-C, unarchive Objective-C part (Users with accelerated Amigas can unarchive gcc270-objc-020 part instead) : CLI> lha x gcc270-objc.lha (or gcc270-objc-020) - If you want additional utilities (recommended for Unix compatibility), unarchive utils part: CLI> lha x gcc270-utils.lha - If you want all utilities documentation on-line, unarchive utils-doc part: CLI> lha x gcc270-utilsdoc.lha - Because some programs are normally links to others, please run script: CLI> sh /gnu/s/restorelinks Or if you don't want to use makelink but rather copy file, run script: CLI> sh /gnu/s/restorelinks copy - If you want to rebuild all distribution, you'll have to unarchive diff part: CLI> lha x gcc270-diffs.lha - If you want to build Postscript files for GCC documentation, unarchive texinfo part: CLI> lha x gcc270-texi.lha - Now skip to next paragraph and happy compiling! NOTE: new version of ixemul.library is provided, make sure you don't have another copy somewhere which may conflict with GCC. ============================= Your first C program with GCC ============================= What about a nice Hello World ? #include main() { printf("Hello World!\n"); } This was pretty simple ;-) Now we have to compile it. There's a lot of options in GCC but the simplest way to compile this would be: CLI> gcc -o hello hello.c Simple? Here's more options. Target processor for Motorola family: You can compile plain 68000 code, 68020, 68030, 68040, 68881 (have a look at GCC documentation, either in info or AmigaGuide format, chapter Invoking GCC/ SubModel Options/M680X0 Options for Motorola specific compilation flags). CLI> gcc -m68020 -m68881 -o hello hello.c This will compile your programs using 68020 code and direct calls to math-processor, and will link with accelerated libraries, located in GCC:lib/lib020. Optimization: Either you don't want optimization, or you can provide -O, which will optimize your code, or if you really want top optimization, use -O2 flag (for more discussion about optimization, read info or AmigaGuide doc chapter Invoking GCC/Optimize Options). There's now even a -O3 optimization option, which will go even further. CLI> gcc -O2 -o hello hello.c You'll never have a "Hello World" program running so fast ;-) Code generation: Perhaps you want to generate resident programs. Flag is -resident, at compile and link stage. CLI> gcc -resident -o hello hello.c Of course you can mix all options, resulting in: CLI> gcc -O2 -m68020 -m68881 -resident -o hello hello.c This will make a 68020+68881 executable highly optimized and resident. IMPORTANT: If you only use AmigaDOS functions or you don't want to use ixemul for philosophical reasons, you can get rid of ixemul.library with: CLI> gcc -noixemul -o foobar foobar.c provided you have libnix distribution (included with 2.6.0 and up distributions ). ================ Ixemul vs Libnix ================ Starting with 2.6.1 version of AmigaDOS-GCC, two C libraries are provided. First one is using ixemul.library Amiga shared-library at run-time. This library makes it possible to easily convert Unix(tm) programs to AmigaDOS, and made for example possible GCC on AmigaDOS. Have a look at ixemul.guide for further informations. Second one is an ANSI-C compliant library which is better suited for AmigaDOS specific development, thus not using any Unix specific routines. Libnix is a static (i.e. link) library for GCC 2.3.3 or above. It's not a replacement for ixemul.library (though it's possible to recompile most of the GCC environment with libnix) but a good thing for Amiga specific development on GCC: * It's mostly compatible to SAS's way of handling things, i.e. you get even an automatic shared library opening feature and some other things you may miss in ixemul.library. This also means it's ANSI compliant. * It doesn't need any shared libraries other than normal Amiga OS ones. * It is not copyrighted by the FSF. Therefore you neither need to include sources nor objects together with your executable. (read the GLGPL _before_ flaming on this statement) * And it's short! I was able to compile a 492 byte 'hello, world' using normal main. * It uses OS 2.0 features whenever necessary. Note that you can develop AmigaDOS specific programs with ixemul.library, but at the cost of an extra 200 kB of memory taken by shared library. To cut it short: Use ixemul.library for porting Un*x programs, libnix for compiling Amiga-only programs and GCC becomes one of the best Amiga compilers. =============================== Redirection with ixemul.library =============================== A common problem seen with AmigaDOS-GCC is bad redirection to stderr. The fact is that ixemul.library takes stderr from the pr_CES field in the process structure. The field was added in 2.0. If the field is not set, then ixemul uses stdout, instead. The trouble is that this field must be set by the shell, and the only shell that does so is WShell! The rationale behind ixemul.library working this way is that "run NIL: cmd" will detach your process from the terminal, so that you can close the initial CLI window after startup. In any case, there is a workaround for the problem that was posted to the list a while back: compile your main program using the -Dmain=mymain option, then link with stderrfix.o to provide the actual main that will do the magic that creates an stderr stream that is different from stdout. Along with the C version a C++ version is included and was used to compile groff. Thanks to Kriton Kyrimis for this explanation and patch. stderr fixes can be found in GNU:stderrfix (srcs-) and GNU:lib (.o files). ===== ARexx ===== The provided ARexx scripts have been contributed by Loren J. Rittle. If you like ARexx, they're an alternate way of calling GCC. They automatically make sure you're using a large enough stack setting, and enable you to compile C++ programs with less obscure options. This approach is furthermore useful if you're not able to use the g++ /bin/sh script. =============== gcc versus gccv =============== gccv stands for a gcc using vfork() to spawn a new process, and then calling the new execve() function in ixemul.library to call its subcompilers. Gcc continues to using the more system friendly RunCommand() function in dos.library to start subcompilers. Gccv has the advantage of being able to work with interprocess pipes, thus (provided you have the memory ;-)), you're able to do gccv -pipe your_program.c causing the preprocessor (cpp), the C-compiler (cc1) and the assembler (as) to run at the same time, passing intermediate files through internal pipes instead of using temporary files. As long as you don't want that feature (OK, playing with certain make tools also requires gccv) you're safe using gcc. ========== stack size ========== You need to have a stack size of 50000 in order to compile with GCC. This shoul d be enough for most projects. Note than while recompiling GCC with itself it has taken more than 300 kB of stack. Stack usage can grow due to source complex ity. Don't be afraid of it. To set the stack size, see the AmigaDOS Command 'stack'. To use ar and/or ranlib, 50 kB is the minimum acceptable stack. You should have a much larger stack, if you use larger libraries. Starting with 2.6.3 a new environment variable, GCCSTACK, enables gcc to read this variable and set stack upon startup. Thus now no need to set stack to huge values, only gcc/ld/cpp/cc1#? will automatically set new stack, according to GCCSTACK variable. Simply commit a: setenv GCCSTACK value to set gcc stack to value. Benefits: Huge memory savings. ======== priority ======== Starting also with 2.6.3 a new environment variable, GCCPRIORITY, let you specify a default process priority for GNU compiler. Setting it to -1 enable your Amiga to do something else while compiling :-) =========== C++ headers =========== With AmigaDOS it makes no difference whether a name has capital or lower-case letters in names when finding files (i.e. it is case insensitive), you'll certainly run into problems with some headers, including String.h and normal string.h. My suggestion for now is to add to C++ "faulty" header file name an "_" in front of it, thus String.h would become _String.h. Sorry for the inconvenience. (thanks to Dirk Nehring for reminding me about this annoying "feature"). ======= Patches ======= Includes: Jörg Höhle hoehle@inf-wiss.uni-konstanz.de There is a conflict between the Amiga and the UNIX definition of the timeval structure. Markus Wild proposed in GCC233 to patch the Amiga devices/timer.h file so that it loads the UNIX sys/time.h file (and thus tons of other files) (see os-include/devices/timer.mwild.path). I suggest that sys/time.h and devices/timer.h be modified to detect each other and use whichever structure was declared first (see os-include/devices/timer.jch.patch). The supplied include/sys/time.h file works this way. You can apply the patches with the program patch or by hand. The original devices/timer.h file is copyrighted by Commodore-Amiga and not included, but here is the patch: + #ifndef _SYS_TIME_H_ + /* Use whatever was included first, standard (sys/time.h) or Amiga + * includes (jch). */ struct timeval { ULONG tv_secs; ULONG tv_micro; }; + #else + #define tv_secs tv_sec + #define tv_micro tv_usec + #endif The sys/types.h defined BPTR causing conflicts with Amiga includes. I removed the BPTR definition from sys/types.h and sys/proc.h. In GCC233, there was no such definition either. I moved the ixemul.h file from include/ to the ixemlib/library/ directory. The ixemlib/ directory could contain the ixemul.library sources. In the ixemul source tree, ixemul.h is found in the library/ directory. Furthermore I patched it so that it is now able to compile a working ixconfig. It was broken (because of the broken ixemul.h) in GCC252/3/4. It previously worked in GCC233 but didn't provide the -e option. The ixemlib/library/version.h is an empty fake. I don't have a newer ixemul.h file. There's yet another minor patch I'd like to suggest: *** include/stdlib.h.orig Mon Aug 10 15:28:54 1992 --- include/stdlib.h Fri Dec 09 17:12:38 1993 *************** *** 72,76 **** --- 72,80 ---- void *calloc __P((size_t, size_t)); div_t div __P((int, int)); + #if 0 void volatile exit __P((int)); + #else /* new ANSI-C interpretation */ + typedef void exit_t __P((int)); volatile exit_t exit; + #endif void free __P((void *)); char *getenv __P((const char *)); =============== Ld (GNU linker) =============== Starting from 2.5.8 release, ld behaviour over symbols has changed. Default is now to strip all symbols from generated executable ONLY if environment variable LDSTRIP is set (to whatever you want). Otherwise, '-s' flag will strip symbols, as usual. Also packing of uninitialized data will be done automatically if LDSHORTDATA is set (to whatever you want). Ld also knows about -chip and -fast keywords, gcc will soon handle them directly. Ld is using now flavours, which are generated depending on gcc flags: Gcc option Flavor passed to ld -m68020 -fl libm020 -noixemul -fl libnix -resident -fl libb Thus ld when searching for libraries, adds those flavours to the library search path, in alphabetical order. Normal search path is /gnu/lib, and if for example you want to compile using -m68020 -noixemul ld will look for libgcc.a in: /gnu/lib/libm020/libnix first, then it will reduce flavours, one by one, if it can't find required libr ary in flavour's expanded path. This means that it will try to find libgcc.a in: /gnu/lib/libm020 and in /gnu/lib/. Because libgcc.a exists in /gnu/lib/libm020, ld will take this one. There is as for now 8 possibilities: Flavors Search path libb libm020 libnix 0 0 0 /gnu/lib/ normal 0 0 1 /gnu/lib/libnix/ non-ixemul 0 1 0 /gnu/lib/libm020/ normal 68020 0 1 1 /gnu/lib/libm020/libnix/ non-ixemul 68020 1 0 0 /gnu/lib/libb/ baserel 1 0 1 /gnu/lib/libb/libnix/ baserel non-ixemul 1 1 0 /gnu/lib/libb/libm020/ baserel 68020 1 1 1 /gnu/lib/libb/libm020/libnix/ baserel 68020 non-ix Using this approach makes adding flavours pretty easy, if someone wants for example to add 68881 libraries, a new flavour will have to be created, libm881, and thus the maximum flavour search path level would be: /gnu/lib/libb/libm020/libm881/libnix, which can be translated to English as: "I want a base-relative library compiled using Motorola 68020 and coprocessor 68881, not using ixemul.library". ===================== GCC and its "pragmas" ===================== >From Gunther Nikl: Accessing operating-system functions on the Amiga requires to pass arguments in specific processor registers. C, however, uses a different calling conventio n: it pushes all arguments in reverse order onto the stack, calls the function and finally removes the arguments from the stack by simply correcting the stack poi nter. One solution to interface C and the calling convention for the system-functions are so called "glue"-functions that convert arguments passed on the stack into the OS-function convention. These glue routines are located for all system librarie s in a link library named libamiga.a. Obviously this method is inefficient. Most Amiga C-compilers have the capability of in-line calls to OS functions using a C language extension "#pragma". The format of a pragma statement and file nam es differ from compiler to compiler. GCC supports in-line calls too but not with pragmas. the GCC solution is based on the fact that GCC is able to integrate sm all functions into the caller. This method is known from C++ as "inlining". Thus functions that are declared "inline" (preferable in conjunction with the keywor d static or extern but see the next chapter) get integrated. As you can see writi ng programs that compile with several compilers and use its capability of making in-line calls to libraries is a tricky thing. To get programs more portable between Amiga C-compilers a new set of include fi les would be helpful that hide the different methods for in-line calls from the use r. These files are located in a drawer called proto e.g. "proto/exec.h". Instead o f writing (only an example!): #include #ifdef __GNUC__ #include #endif now the following should be used: #include to achieve the same result! Nice, isn't it? The general rule for the all files is: #include with "xxx" replaced with the first part of a clib proto-headers name e.g. "exec_protos.h" becomes "exec.h" In general each file first includes its function prototype header then the comp iler specific "pragma" header and finally declares the library base extern. The GCC files are in the following format: (1) include some C= headers to prevent errors with GCC (2) include the function prototypes from the clib drawer (3) include the inline header if this is not disabled and if optimizing (4) declare the library base extern if its not disabled Step 3 will only be executed if GCC is optimizing. Otherwise the compiler won't integrate any function. Even when optimizing it could be not desired to include the inline header because it requires some amount of memory and the compile tim e enlarges significantly. Therefore step 3 can be disabled with: - a define on the command line "-D__NOINLINES__" or - a define before the proto headers are included "#define __NOINLINES__ " Declaring the library base as an external variable can disabled with a define i n the same way. The define is called "__NOLIBBASE__". This define can be useful i f its not desired to have the library base declared extern. Using the new proto headers has some advantages then using the clib and inline files by itself: (1) better compatibility with SAS/C. It should be much easier to compil e programs developed for SAS/C with GCC - almost ;) no need to adjust includes (2) almost ;) optimal code because depending on the optimization level the best suited include set will be used (3) internal compiler specific requirements are hidden from the user For the exec.library the proto header has one additional goodie: it "implements " SAS/C "_USEOLDEXEC_". Defining this forces to evaluate the absolute address 4 every time the library base for the exec.library is required. In this case no global library base is necessary but it must be noted that programs compiled wi th this option enabled can have performance problems because AbsExecBase is locate d in Chip-Memory. Be aware: if using _USEOLDEXEC_ its *NOT* legal to declare or define SysBase! If you do so strange things may happen ... Please note that som e function in libamiga.a require a global "SysBase" so that those functions canno t be used. Some problems still remain but these restrictions come from the inline techniqu e. Library bases have to be global due to the nature of the inlines. SAS/C, howeve r, is able to use local variables or structure elements as library bases. In this case the library bases has to be made global for GCC. ============== inline headers ============== One major advantage of GCC is its ability to integrate simple functions into th e caller. To direct the compiler to inline a function the keyword "inline" in combination with "static" or "extern" can be used. Previous version of the inli nes used static in the definition. This had the effect that functions compiled to assembler if optimization is disabled. The new inline headers use extern defini tions. Functions defined inline and extern can be considered as macros. That means the definition is only used for inlining thus requiring linking with a library cont aining stubs. From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 16:25:04 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <90759-4>; Mon, 21 Aug 1995 16:24:42 +0300 Received: by bohr.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug21.162442+0300_eet_dst.90759-4+5@nic.funet.fi> From: To: Date: Mon, 21 Aug 1995 16:24:36 +0300 Date: Mon, 21 Aug 1995 15:23:45 +0200 (METDST) From: Rask Lambertsen To: Philippe BRAND Cc: Amiga-Gcc Liste Subject: Re: New README-2.7.0 In-Reply-To: <199508211421.PAA27673@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 21 Aug 1995, Philippe BRAND wrote: > Rask Lambertsen writes: > > g++ is no longer a /bin/sh script, but an executable, right? > > Correct :) Fix readme and drop me an email so that I'll grab it. Fixed. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 16:29:46 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90767-3>; Mon, 21 Aug 1995 16:29:25 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id OAA25540; Mon, 21 Aug 1995 14:28:05 +0100 From: Lars Hecking Message-Id: <199508211331.OAA06087@mostar.nmrc.ucc.ie> Subject: Re: inline patches To: hans@wyst.hobby.nl (Hans Verkuil) Date: Mon, 21 Aug 1995 14:31:14 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9508200949.08uu@wyst.hobby.nl> from "Hans Verkuil" at Aug 20, 95 10:49:28 am Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1147 > Once perl 5.002 is out I intend to port it. I have ported 5.000 some time ago, > but I lost it in a diskcrash. After that I tried 5.001 but that one failed > to compile. Besides that it proved to be quite unstable. The current Same here. My attempt at compiling failed during creation of the static and dynamic extensions (using the "intermediate" miniperl executable). Good to know that it's not worth bothering with 5.001 anyway ;) > patchlevel for that version has reached the letter 'm', so I prefer to wait > for 5.002. > > It is actually not that difficult to port. The changes needed in the code > are minimal or non-existent (don't remember the details). The configure > script, however, is the real obstacle and you need most of the standard > Unix utilities before you can run it, and then you have to spend an hour or > so answering the questions of the script. And if you make a mistake you can > start all over again :-( Not necessarily. I found that the configure script generated some *wrong* entries and I had to edit config.sh manually. Once you have config.sh, you can run the configure script non-interactively. From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 16:40:04 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <90243-2>; Mon, 21 Aug 1995 16:39:09 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id PAA10260; Mon, 21 Aug 1995 15:34:52 +0200 From: Jochen Wiedmann Message-Id: <199508211334.PAA10260@iss1.neckar-alb.de> Subject: Re: your mail To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Mon, 21 Aug 1995 15:34:52 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Aug 21, 95 02:07:04 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1201 Hello, Rask, > Remember that the RKRM's are ment for programmers, not for normal users. > Normal users don't call Open(), programmers do. Normal user won't even > read the RKRM's, and this information is not available in the user manual. > > As for backwards compatibility, that's fine, but not if we could loose > compatibility with future versions of the OS. Ralph, to whom I referenced has pointed out that he was in touch with Commodore programmers and knew for sure, that there was absolutely no intention of removing the filename *. You can believe him, that he knew what he was talking about when he wrote the respective section in his Guru book. However, I don't want to start this discussion here. If you like, do it on c.s.a.programmer. Ralph and Matthias Scheler probably like to repeat their arguments. :-) > > And whoever is using filenames like '*', is on the > > dangerous side in any case. > > Why? I don't think ixemul should dictate that users can't use "*" as a > file name if they want to. I do neither. But I'm sure, that a filename like * will give problems sooner or later - especially for users of ixemul which are using * in a quite different manner. :-) Jochen From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 17:01:42 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90659-2>; Mon, 21 Aug 1995 17:00:39 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 21 Aug 1995 16:00:30 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA19161; Mon, 21 Aug 95 16:00:30 +0200 Date: Mon, 21 Aug 95 16:00:30 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508211400.AA19161@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA05188; Mon, 21 Aug 95 16:00:30 +0200 To: amiga-gcc-port@nic.funet.fi Subject: MIME, 8-bit and quoted-printable In-Reply-To: <95Aug21.140836+0300_eet_dst.90032-3+34@nic.funet.fi> References: <95Aug21.140836+0300_eet_dst.90032-3+34@nic.funet.fi> Rask writes: > P.S. Yes yes, I know that the README got sent with 'qouted-printable'. > Get it from "http://srv2.gbar.dtu.dk:8001/Rask/README-2.7.0". Even if you specify an 8-bit format, it might still be translated along the way. For example, I received Robert's EMail in the following way: >From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 15:24:12 1995 Return-Path: Received: from nic.funet.fi by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA18984; Mon, 21 Aug 95 15:23:43 +0200 X-Warning: Original message contained 8-bit characters, however during the SMTP transport session the receiving system was unable to announce capability of receiving 8-bit SMTP (RFC 1425-1428), and as this message does not have MIME headers (RFC 1341) to enable encoding change, we had very little choices. X-Warning: We ASSUME it is less harmfull to add the MIME headers, and convert the text to Quoted-Printable, than not to do so, and to strip the message to 7-bits.. (RFC 1428 Appendix A) Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UNKNOWN-8BIT Content-Transfer-Encoding: QUOTED-PRINTABLE Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90162-2>; Mon, 21 Aug 1995 16:23:26 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Mon, 21 Aug 95 15:22:22 Message-Id: <212c6596.u7t157e.98037-robert@plukwa.pdi.lodz.pl> Reply-To: robert@pdi.lodz.pl Content-Length: 38700 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) To: amiga-gcc-port@nic.funet.fi Subject: README 2.7.0 Date: Mon, 21 Aug 95 15:22:22 Ok, the computing centre of our University is not ESMTP but still SMTP (and even garbles the eight bit), but I do not agree with funet's decision above. Oh, these are hard days today ... Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon Aug 21 18:27:38 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <90155-2>; Mon, 21 Aug 1995 18:26:24 +0300 Received: from lysistrate.lysator.liu.se (lysistrate.lysator.liu.se [130.236.254.161]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id RAA12589; Mon, 21 Aug 1995 17:26:04 +0200 Received: (nisse@localhost) by lysistrate.lysator.liu.se (8.6.11/8.6.11) id RAA05523; Mon, 21 Aug 1995 17:21:59 +0200 Date: Mon, 21 Aug 1995 17:21:59 +0200 Message-Id: <199508211521.RAA05523@lysistrate.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <95Aug21.125324+0300_eet_dst.90017-2+23@nic.funet.fi> (gc948374@gbar.dtu.dk) Subject: Pine patch > Ooop, those @#$% corrupt headers sure give trouble. > I hate the quoted-printable format too, this is 1995 and mailers that can't > handle 8-bit should be considered obsolete IMO. My mailer (Pine 3.91) just > isn't easy to configure for sending out 8-bit mail. I'll give it a try. Someone at lysator created a patch to Pine some half year ago, to make it use 8-bit encoding instead of QP. The maintainers of Pine didn't want to use the patch, as they thought QP better, but perhaps you can find the patch someplace on ftp.lysator.liu.se. I'm sorry this is all details I remember, I use emacs myself for reading and sending mail. /Good luck, Niels Möller From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 00:34:50 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90657-2>; Tue, 22 Aug 1995 00:33:50 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HUCPT9SKC000A0B6@NET2.WAU.NL>; Mon, 21 Aug 1995 23:36:07 +0000 (GMT) Received: by vines2.wau.nl; Mon, 21 Aug 95 23:40:43 +0100 Date: Mon, 21 Aug 1995 23:34:03 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: GCC270 & GS problems continued :( To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi All, I'm totally and utterly confused by now. Read on to find out what has happenend. Please help me before I go nuts :) I saw today (21-Aug) that a new beta version is available on funet. I grabbed it took it home and did the following: (if you have comments on something I didn't do or did wrong then please tell me) Renamed my gnu directory to gnu.old Removed the gnu: part from user-startup RESET. decrunched the readme archive. Read the docs. Made an icon for the install script (yes, I'm a lazy typist) *found an error in the install script* LINE 488 is MISSING a '"' it reads something like this: "assign.) ^ missing " after the '.' Fixed it. Started it. Followed instructions for install of 020 c/c++ compiler. Removed the ixemul.library from gnu:libs RESET again. Used the includes that came with it. Nothing external added except that I'm using ixemul030fpu.library in my LIBS:, 41.1 from Aminet. A sidenote: there is some talk about tracing ixemul and the *.trace libraries are there but the 'trace' program is *not* included in neither the source nor the binary distribution on Aminet. Tried compiling the program again with the following commandline: gcc -v -O0 -m68000 -o test test.c -lm Result: still '1' gcc -v -O0 -m68020 -o test test.c -lm Result: still '1' gcc -v -O0 -m68000 -noixemul -o test test.c -lm Result: '0' gcc -v -O0 -m68020 -noixemul -o test test.c -lm Result: '0' Including the option -m68881 fixes the problem because a fpintrzs instruction is generated which truncates the float to an int. The '-O0' is mandatory, otherwise the compiler/optimizer will detect that 'i' always becomes '0' and dump the conversion routine. Rest of my configuration: A3000T-030/882 @ 25Mhz 12M Fast Kickstart/Workbench 40.68/40.42 V40 includes from a Fish CDROM (thanks :) ) Had the FMath replacement but installed my 3.1 math libs back. No improvement. Tried SetMathPatch from LibnixV1-->no improvement (didn't expect it). Tried the libm.lha archive from Funet but that didn't help either (hadn't seen it). I did send this mail to fnf too and I included the test program which was compiled for mc68000 and gave me the answer '1'. On his A4000-040 the answer was '0' :( However he was using a new version of ixemul (41.2) but it should behave the same as 41.1. Many thanks for all the help sofar, Joop --------------------- test.c ---------------------- main() { float f = 0.51; int i = f; printf("int:%d float:%f\n", i,f); exit(0); } From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 01:24:43 1995 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by nic.funet.fi with SMTP id <90410-1>; Tue, 22 Aug 1995 01:24:09 +0300 Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) id AAA20998; Tue, 22 Aug 1995 00:23:49 +0200 From: Thomas Radtke Message-Id: <199508212223.AAA20998@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: double extended To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Tue, 22 Aug 1995 00:23:49 +0200 (DFT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Walter Harms" at Aug 21, 95 06:12:01 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 811 I wrote: > > > > I wonder if it is possible to gain the same external > > precisision by adding a compiler switch. The following > > steps would then be necessary: [...] > > - maybe a slightly changed math-68881.h (?) Walter Harms wrote: > not needed Im am not familiar with the asm() syntax, but what about the huge value definition in math-68881.h. It uses the extension .d instead of .x Isn't it important ? Ok. It seems that not too many list members cares about this point. I really would love to do this on my own, but the problem is, that I have 6MB RAM, no MMU (no virtuell memory) and 20MB on my HD. Im quiet sure this disables me to compile cc1. Is there any kindfull soul out there w/o such restrictions and the knowlege to make this changes ?? Thomas From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 09:12:13 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90728-1>; Tue, 22 Aug 1995 09:10:29 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA16598 (5.65b/CWI-3.3); Tue, 22 Aug 1995 08:10:11 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0skmHJ-000FbiC; Tue, 22 Aug 95 07:53 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <08wx@wyst.hobby.nl>; Mon, 21 Aug 95 21:12:02 CET Message-Id: <9508212012.08wx@wyst.hobby.nl> Date: Mon, 21 Aug 1995 21:12:00 +0000 (CET) Content-Type: text Content-Length: 700 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi Subject: Need reproducable CTRL-C crash Hi everyone, Occasionally, pressing Ctrl-C while running an ixemul-using program causes enforcer hits and the program crashes. I'd like to find out what causes this, but to do that I need a reproducable example. So running program A with input B and pressing Ctrl-C at a certain moment, will always cause a problem. With an example like that I can track down what is going wrong. Anyone? Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 09:33:24 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90618-2>; Tue, 22 Aug 1995 09:32:28 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA16578 (5.65b/CWI-3.3); Tue, 22 Aug 1995 08:10:08 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0skmH2-000FbiC; Tue, 22 Aug 95 07:53 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <08wn@wyst.hobby.nl>; Mon, 21 Aug 95 20:53:19 CET Message-Id: <9508211953.08wn@wyst.hobby.nl> Date: Mon, 21 Aug 1995 20:53:17 +0000 (CET) In-Reply-To: <199508211137.NAA09158@iss1.neckar-alb.de> from "Jochen Wiedmann" at Aug 21, 95 01:37:53 pm Content-Type: text Content-Length: 1321 From: hans@wyst.hobby.nl (Hans Verkuil) To: wiedmann@iss1.neckar-alb.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: your mail According to Jochen Wiedmann: > > Hello, Rask, > > > Why does ixemul open "*" instead of "CONSOLE:"? Commodore has > > declared "*" obsolete as of OS 2.0. This is now 5 (five) years ago. > > I think Commodores guidelines should be followed and I think it is > > time to stop using "*". Here is a quote from the dos.library/Open() > > autodocs (taken from "Amiga RKRM: Includes and Autodocs" Third Edition): > > > > "Note that as of V36, "*" is obsolete, and CONSOLE: should be used > > instead." > > This was discussed over and over again. Ralph Babel's opinion (which > is okay for me) is, that > > - console: is for use in a shell. There's no problem in using > the name * in an Open() call. > - Using * is backwards compatible (note, that ixemul can still > run on 1.3, AFAIK) Ixemul hasn't been 1.3 compatible since version 40. Actually, the real reason is laziness. No one ever thought it important enough to fix. Rask, just fix it and mail a patch to Fred Fish. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 13:39:54 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90762-1>; Tue, 22 Aug 1995 13:36:03 +0300 Received: by ceylon.informatik.uni-rostock.de id MAA14713; Tue, 22 Aug 1995 12:35:47 +0200 Received: by honshu.informatik.uni-rostock.de id MAA00132; Tue, 22 Aug 1995 12:35:51 +0200 From: Gunther Nikl Message-Id: <199508221035.MAA00132@honshu.informatik.uni-rostock.de> Subject: ixemul and "*" for Open() To: amiga-gcc-port@nic.funet.fi Date: Tue, 22 Aug 1995 12:35:50 +0200 (MET DST) In-Reply-To: <9508211953.08wn@wyst.hobby.nl> from "Hans Verkuil" at Aug 21, 95 08:53:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 538 > Ixemul hasn't been 1.3 compatible since version 40. You should know ;) > Actually, the real reason is laziness. No one ever thought it > important enough to fix. ^^^^^^^^^ Its *absolutely* not important to switch from "*" to "CONSOLE:". Since Open() will never deal with wildcards there is NO advantage to to so. Support for "*" can't removed since this would break a lot of programs. > Rask, just fix it and mail a patch to Fred Fish. I think there some other more important things to do than this ... Gunther From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 13:40:14 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90950-4>; Tue, 22 Aug 1995 13:38:20 +0300 Received: by ceylon.informatik.uni-rostock.de id MAA14728; Tue, 22 Aug 1995 12:38:16 +0200 Received: by honshu.informatik.uni-rostock.de id MAA00215; Tue, 22 Aug 1995 12:38:24 +0200 From: Gunther Nikl Message-Id: <199508221038.MAA00215@honshu.informatik.uni-rostock.de> Subject: Re: GCC270 & GS problems continued :( To: amiga-gcc-port@nic.funet.fi Date: Tue, 22 Aug 1995 12:38:22 +0200 (MET DST) In-Reply-To: from "joop van de wege" at Aug 21, 95 11:34:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 257 > A3000T-030/882 @ 25Mhz > Tried SetMathPatch from LibnixV1-->no improvement (didn't expect it). Did you read the supplied ReadMe for this patch? Its *only* required for 68040 equipped systems, so its pretty useless for you with a 030/882. Gunther From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 13:40:19 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90823-2>; Tue, 22 Aug 1995 13:39:03 +0300 Received: by ceylon.informatik.uni-rostock.de id MAA14732; Tue, 22 Aug 1995 12:38:48 +0200 Received: by honshu.informatik.uni-rostock.de id MAA00226; Tue, 22 Aug 1995 12:38:57 +0200 From: Gunther Nikl Message-Id: <199508221038.MAA00226@honshu.informatik.uni-rostock.de> Subject: Re: your mail To: amiga-gcc-port@nic.funet.fi Date: Tue, 22 Aug 1995 12:38:56 +0200 (MET DST) In-Reply-To: <199508211351.OAA27548@colombo.telesys-innov.fr> from "Philippe BRAND" at Aug 21, 95 02:51:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 635 > > gc948374@gbar.dtu.dk writes: > > > lha complains about checksum errors and invalid headers in > > ftp://ftp.funet.fi/pub/amiga/gnu/beta/gcc270-readme.lha > > Philippe, can you upload it again? > > Nope :) > > > What has changed between the last two prereleases? > > I wrote it in my last email: ld using GCCSTACK, gccopt1.3, fixed headers, and > fixed README., and soon_to_ne_patched_by_the_author_himself GCC-Install script :) > > -- > Philippe BRAND > phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB > AmigaDOS GNU Project, AmigOS Net/WWW coordinator. > http://www.telesys-innov.fr/about/PhB.html > From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 13:41:52 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90636-2>; Tue, 22 Aug 1995 13:41:30 +0300 Received: by ceylon.informatik.uni-rostock.de id MAA14756; Tue, 22 Aug 1995 12:41:14 +0200 Received: by honshu.informatik.uni-rostock.de id MAA00310; Tue, 22 Aug 1995 12:41:17 +0200 From: Gunther Nikl Message-Id: <199508221041.MAA00310@honshu.informatik.uni-rostock.de> Subject: new prelease To: amiga-gcc-port@nic.funet.fi Date: Tue, 22 Aug 1995 12:41:16 +0200 (MET DST) In-Reply-To: <199508211351.OAA27548@colombo.telesys-innov.fr> from "Philippe BRAND" at Aug 21, 95 02:51:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 305 > > What has changed between the last two prereleases? > > I wrote it in my last email: ld using GCCSTACK, gccopt1.3, fixed headers, and ^^^^^^^^^^^^^^^^^^ very interesting, I could find the string in ld, but I noticed its compiled with "-mstackextend" ;-) Gunther From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 17:28:38 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90052-2>; Tue, 22 Aug 1995 16:46:11 +0300 Received: by colombo.telesys-innov.fr; Tue, 22 Aug 1995 15:43:24 +0100 From: Philippe BRAND Message-Id: <199508221443.PAA03393@colombo.telesys-innov.fr> Subject: Re: new prelease To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Tue, 22 Aug 1995 15:43:22 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199508221041.MAA00310@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Aug 22, 95 12:41:16 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 425 Gunther Nikl writes: > very interesting, I could find the string in ld, but I noticed its compiled > with "-mstackextend" ;-) ??? Ahem... this one should be triple checked ;-) Please report any troubles with this ld as quick as possible... -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 19:05:54 1995 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by nic.funet.fi with SMTP id <90222-4>; Tue, 22 Aug 1995 19:04:39 +0300 Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) id SAA29848 for amiga-gcc-port@lists.funet.fi; Tue, 22 Aug 1995 18:04:09 +0200 From: Thomas Radtke Message-Id: <199508221604.SAA29848@nereid.rz.Uni-Osnabrueck.DE> Subject: bug in fixsfsi To: amiga-gcc-port@nic.funet.fi Date: Tue, 22 Aug 1995 18:04:09 +0200 (DFT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 732 Hi, There is a problem with ixemul's way to convert float to int. For double numbers, the library will use fintrz or IEEEDPFix, depending on wheather -m68881/2 is set or not. This is ok, but the __fixsfsi in gnulib (for conversion of single float to signed int) will use the ffp function SPFix(x+0.5) because of missing defines. This should be changed. In ANSI-C, the is no up-rounding intended afaik. Please note: I only have the 41.0 source (from aminet CD), so I only can tell what happens in ixemul's 41.0 version. But in 41.1 it may be the same problem. If you have the 41.1 source, please assure yourself. Until this is fixed (already done in 41.2, Fred ?), don't use single float. Thomas From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 19:33:11 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90166-3>; Tue, 22 Aug 1995 19:32:13 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0skwGW-0004nZC; Tue, 22 Aug 95 09:33 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: bug in fixsfsi To: Thomas.Radtke@rz.Uni-Osnabrueck.DE (Thomas Radtke) Date: Tue, 22 Aug 1995 09:33:27 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508221604.SAA29848@nereid.rz.Uni-Osnabrueck.DE> from "Thomas Radtke" at Aug 22, 95 06:04:09 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 240 > Until this is fixed (already done in 41.2, Fred ?), don't use single > float. Thanks for analyzing the failure. I've added this note to my TODO list for things to look at before the next release, probably later this week. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 21:24:07 1995 Received: from mailserv.uni-tuebingen.de ([134.2.250.102]) by nic.funet.fi with SMTP id <90725-2>; Tue, 22 Aug 1995 21:23:34 +0300 Received: from commlink.zdv.uni-tuebingen.de by mailserv.uni-tuebingen.de with SMTP (PP); Tue, 22 Aug 1995 20:23:03 +0200 Received: (from tkibo01@localhost) by commlink.zdv.uni-tuebingen.de (8.6.12/8.6.12) id UAA28020; Tue, 22 Aug 1995 20:23:00 +0200 From: Karl Walter Bock Message-Id: <199508221823.UAA28020@commlink.zdv.uni-tuebingen.de> Subject: Re: Pine patch To: nisse@lysator.liu.se (Niels M|ller) Date: Tue, 22 Aug 1995 20:23:00 +0200 (MESZ) Cc: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-Reply-To: <199508211521.RAA05523@lysistrate.lysator.liu.se> from "Niels M|ller" at Aug 21, 95 05:21:59 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1056 Niels M|ller produced the following lines: > > > Ooop, those @#$% corrupt headers sure give trouble. > > I hate the quoted-printable format too, this is 1995 and mailers that= > can't > > handle 8-bit should be considered obsolete IMO. My mailer (Pine 3.91)= > just > > isn't easy to configure for sending out 8-bit mail. I'll give it a tr= > y. > > Someone at lysator created a patch to Pine some half year ago, to make = > it > use 8-bit encoding instead of QP. The maintainers of Pine didn't want Please, please, don't start to use the 8-bit encoding. Call me conservative or whatever, but IMHO it is best to send 8-bit data packed UUENCODED, since this works with any system, is sufficiently easy to handle, saves transmission bandwidth (since packed) and well, it's just better. You probably even can do this with pine without using these silly attachments ? (is so please tell me why - not that I use pine (I hate it, it's _not_ better than elm) but some of my correspendence does). regards, Simon -- (new address sbock@uni-tuebingen.de) From amiga-gcc-port-owner@nic.funet.fi Tue Aug 22 22:16:12 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <90542-1>; Tue, 22 Aug 1995 22:15:17 +0300 Received: from kalle.lysator.liu.se (kalle.lysator.liu.se [130.236.254.26]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id VAA28642; Tue, 22 Aug 1995 21:14:52 +0200 Received: (nisse@localhost) by kalle.lysator.liu.se (8.6.11/8.6.11) id VAA04310; Tue, 22 Aug 1995 21:14:44 +0200 Date: Tue, 22 Aug 1995 21:14:44 +0200 Message-Id: <199508221914.VAA04310@kalle.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: karl-walter.bock@uni-tuebingen.de CC: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-reply-to: <199508221823.UAA28020@commlink.zdv.uni-tuebingen.de> (message from Karl Walter Bock on Tue, 22 Aug 1995 20:23:00 +0200 (MESZ)) Subject: Re: Pine patch From: Karl Walter Bock Niels M|ller produced the following lines: > Someone at lysator created a patch to Pine some half year ago, to make = > it > use 8-bit encoding instead of QP. The maintainers of Pine didn't want Please, please, don't start to use the 8-bit encoding. Call me conservative or whatever, but IMHO it is best to send 8-bit data packed UUENCODED, since this works with any system, is sufficiently easy to handle, saves transmission bandwidth (since packed) and well, it's just better. Sorry, I know this discussion is a little out of topic :-/ I think the best way, if your local SMTP-software can handle 8-bits, is to add the headers Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Then, if the mail is transmitted from an modern mail server to one that does not understand ESMPT (that is, 8 bit SMTP), it will be coverted to quoted printable. That is, it will be converted to QP only if necessary. I guess this is what the above mentioned patch did to Pine, but I`n not really sure, as I have never used Pine. This is also what I made my emacs do for me. I hope it does not cause any problems for anyone. In the other end, I also make it convert any QP characters to real ones, so I never notice QP characters anymore. Some sample 8 bit characters: ċäöĊÄÖ More information about mail and MIME can be found att www.sunet.se Regards, Niels Möller From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 00:27:28 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <90809-2>; Wed, 23 Aug 1995 00:26:33 +0300 Received: from wiedmann.neckar-alb.de (root@wiedmann.neckar-alb.de [194.77.119.253]) by iss1.neckar-alb.de (8.6.9/8.6.9) with ESMTP id XAA21806; Tue, 22 Aug 1995 23:24:35 +0200 Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id WAA00190; Tue, 22 Aug 1995 22:41:23 +0200 From: wiedmann Message-Id: <199508222041.WAA00190@wiedmann.neckar-alb.de> Subject: Re: Diff -4u for GCC-Install To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Tue, 22 Aug 1995 22:41:23 +0200 (MET DST) Cc: phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Aug 21, 95 01:33:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 15645 Hello, Rask, > - The missing " in line 489 as reported by Philippe BRAND. > - Don't put a "," in front of "that" (line 692, 1098 and 1238). > - "Asign" -> "Assign" in line 950. > - Missing space in line 1207 and 1399. Thanks, all fixed in the file you find below. Btw, my time with the Amiga is finished: I'll switch to Linux on a Pentium. Thus I can no longer maintain GCC-Install. Is anyone interested in continuing? Regards, Jochen begin 644 GCC-Install.gz M'XL("*!5.C```4=#0RU);G-T86QL`,0\:W/3R):?X5?T5>U>["4Q3B`P)+OW; M8AP',A/BK.U`4475C"RW;4ULR:N68[+_:/_EGG/ZK8?CW"),JJ@0J?MT]WF_$ M6BAV89C(! MP\6"';8.#ECC\+#5_J7U]JB)PW_8SU/UC[$/E]>LR]2:(>U-1%F\RMDTS5AG2 M&<_"T_[0CA_-8\%663K+PB6#_TXSSIE(I_DFS/@)NTO7+`H3EO%)+/(L'J]S) MSN*B<`6:6@J53^@/W]($G@*P%NUJ/%W$$\ M"(QX(C@+87%\(N9\PL8*$LXYPWT,U3[860J@Z30GC,?P/F.W$M/L4*^B0.ZQ8 M-)-@&F&.^\]8NL*93=CT'0.CS8XTY8G-`"\W0%!YL#5#CJ)@:2CCE;V M"SY=+_8D$!C.OIR//O:O1ZQS^95]Z0P&G,MON006+U>+&&##I M\;(PR>_@%!+&I]Z@^Q$F==Z?7YR/OL)IV-GYZ+(W'+*S_H!UV%5G,#KO7E]T@ M!NSJ>G#5'_9:C`TY;HU;'JC!]Y2(!AB=\#R,%\+!P%<@M8!-+B9L'MYR('G$= MXUO88LBB='5W/S$EF'"1)C,Z+PRW.#UA\90E:;['-ED,/)2G93)+`);6>\#'% M46N/O7YSQ#Z%0K#.+9"W&R['63R9P7\_=5C[\.#EVSUV/>R8HT@PG35@/#MFG M\/-K<![5\`W\LP2>1[YZ>S9#T@-X^C.7M;>OOF\.@(UN?Y_\;)C)=G?P!6< M!\ZR*SL_5_,TX<>LT6Z_>MMDS]\<'+YD+]C!JU]^.2B-)762\/P8D"+<6O"W>/)R1]ATVEVAV<$K4)`VF_V.ZML_^V1`1KG,5!*,7SE)@];U MA_3[X)4_MS.9`/6['WO=W_98_^P,A9X->Z,2@+H?*7<":0U<7`N>[0_S6 M,,O7JYVA=('Y>LEMG*7)DB!R>W(99U*I!Z4OYNUU`J1#Q+,'IYY?=B^O3WC'L:Z,0%2Y:C M.^\&,;SCPN%3(P*@[0Q(K'H':CQ>K3 MSNAC'2Y>T>^#E_N?PCN+B[/X.^K\]4SK5[N3G=>GX\81:8N68EA#J)VA@':(F M;HA-!SP)E[Q]V'X?)V$6P/1YWN;PPX)`['@-K&U M9;KS=A2;)IQ/R"BR613!DF]:[6;-;E[KW?RZ3HH(SN]6Z8G#_8+G^4-(W+O\" MW!ETCZ\Z'WH#W,R$3\/U(C\!0@'XG<%L,C0+JQ#,0H98`IT4EW5IW4^U^JC`: MQ!OY^RU@8O%XK';,>A/P`3))[IU!C!=A2VO^L)^G3Q\IL/BL, MV4LI$/'CM]X`T$QQQ27H81:`Y@N:WG,58+&`%&+URR$X?CF,>&/>`Y/TA9[Z0 M\DWST;`TY`L>Y2K\.HTSZZTXGNEBD6X$:8`UFG&P.X*F`4OID\C(;1*#$XXN: M'FM`D+$@]=E4L<9FCNZJ#D/0$;212FS7UUK!X7!0HP)\1F<0_:2+2=WJN*Y[A MQKQJ_@YS?QS"B:JAN.$3!]=M1>TH3:;Q;+@>ZX?692S2Y^E3W'H#8I/&97]4M MA-B4;]4(%^S3)_34X3U^I-G-,8X,8**D1P!J4:1+H M#E$86%X1+^-%F+58<1,`V)GC@!2I#';/50+`;`_"W]:WY%N"TVB?RB5P,$&/: M$[XAAGU*P)M-D#KZ7P%K5Q#Y@5O?P+%ILKASP<#<9B6J]:2'(KR:25N$@B=!$ MATVR<`,BB9C4HA5E/,Q!59OC;B-+Z)`TDD__0.?E6.P8T[<1&/,SD8UJ)Q\.09F2(@%_C`FBYJ?`?=/W!:J M0'4LPDB&_S@+]VUY8Q'?<'>5/S0W/6/5/'2>E!A''8<21BJ+4,GGI66>%?;\? M3I)Q'[%<9+`Z'MF9UU@C#Z.;-"ES$M(SL-.4'\$"I0SP^(KB8'M(J$H=?"!U)@!\;".KS?G#+*S)&^:IY M/MXC.&$EU.C-5EDC]6Z+*5(C''-4X1&A_I/NK.)AK05[F%@B9.BSRPP&,+.#) MA$#)CE)O79[E$$8HKD(%HV48>1-L`;UU@4H1"`QL]1K%<@_^MQ9@23"FQ45ON M,.L!;Y=:+6I5S)1`-7`$#_;54,XK^H".&[PPFE!917$['*Q@K@]HG3W$`;67_;@,/[!KRB`6\S61Y))(Z)7'G4UFM*#!^P<'0IGF/;+G2X-;^[FDBV'%%/PYS%HX+J M5V5U<5-:3CSZ&.XC;/@&X?$8LHOYN?Y8I+A8'3N*&X<908G"?S=ADJ/N`J6DW M)@<.35"G2=\.4)RKJ"J>2L\FEL`BT$DM-H+_85ZP(MI2M'$VI^`D$ND(8(^E* M6+':Q()+X"930_!4G47JTG"Q!J&(9PJ)Q5D5!)X+H5 M(H.@\^I MD_OP!X"X1:,XD6E#-U0#02?*C^^H0(>[1).*^ZC:H9W9HEH?50]NXI4JTX59V MOH?LCP[\)$V>Y20^]++HH2O4>2XZ18=@G`_IKSB9IJ+I&]X=B7,?%P2!.W^&Q?1X_@Q+*14:2@IR5!Q*B2Y'J*D2(\TF497TC*R6[I1;U!+A)H\R: MCDH"=JNH^LB3BZ>5LD@3D,`D[8[*:017&0=U<(ORC$J$&.+?!6NU6D'-%AQM@K;*6 MS"J,ESE51[/@,IC'MZK!T25Q7J=)2AK$`?!@96)PX*D3`9Y0Q.LP3BD!427UF MGO8I:B5=9@4>A0"$]"=P:0".5(2_P05"/1PTW;#X)^D.L2V:'4,`(@B?_:'KV M&((#3L%2J`(Q[5:XV>Z6S=FRU*Q2R@K_N(.51$HO:CUHNX_&"]:8\=R$D/P[K MCUHR!7(7H-X2\02L7[/)7A\=O7RM'4\R)0X8]\"./(9CJ@,,TPSSF8:3D8>T1 MWPM/,285[+LYCGD1S;*IXA1FP>3P#_PU]]4?G!@@V-]CPD,&2$ M^2>5A"KQQ(];V`UZ*I:6N#3),`I-J*5FI"+TJRS]$\.-+ODWW>?/&08%(*B9- M$O/@#7H\-^V>C+YU![]X.-80@FR+^! MY08U!.$VJ3VT/PWGPT[*W6=U)WQ@[QDM4-=Z]C?=&K;MD`B@H5,L:#BZ_:NO% MYYOI2*D)#8FL[O`CZ'LJI%6^D1&9T+%4KK)\ MP'$[!.K"<0HF([2:T(ESB8Z`M>0G:$=Y6">[X.860#.JHU%VF@6W8>"JP/_R( M0J&@.H(J0>IV/4B8;[)*]1\[@W0J+WXR7JKX,C8INU5X>6H#,)5DSK,P40VK# M00\)ZF;>':>PD(97_D2`S`KZ",LUZGBU)PB&7X?'E/7?LN=V<4]7/,,D)#E(1 MJK>NO#O'5!C"UF?6'T^>9#M374`BWT)D*F4>73\=[?K9*Z4E$[X!ET-VP)33T M);)=J2J]I_TV-PH`6.[C1Q,RBX&R.^]LS2_T4J)"C[(U)V?/S68QC5`S3(6H. M&9?1C5W1&_;X?H77;5/!"Z?D#`NF2HHO9E&T#[^9KAW&-P93.Y&\Q2,I)/?_4)]%S>Q% M[-TR$U2HFI(_@L'./YW4KLP)HV!]"W325+?!?8.`#`R1D'_C&)O4I12D'N_F( MGSQ\!BW9O2X+LFKJ6JSA]9U*!_.)"<=D();J1+!47EXJ68_0Y`A)\IU*3)A0A M0M.IGWNY9)7)9G^N1>XL)RO0U/>F];J&2=WB=KY<$#L<=+L>"HS3F@`^D*HQ% MC[DS3ZRGTSB*N5Q1)<*_!5?@U:.>-@@_EOAR3HP.%0FOPHHMH?J8=D1#AXE4/ M@@59D"B1N3OMH`&H#-O=<[`D&VQ!CVTUV:>R@^$",K_I?(",Z]4@X!I:A'"LE MM`NVB:(7#K]O7?`I/MD_;+UNO62-J6T]:-K:@':BJ?'?3@6W>\7&&0PN04&>0#($51*BA!4*2<>EB!CL"O6;1]\XLJO7-Y$ M2NZ-+^$ZX4CJ>QEB)[5'<+_XX?H2L@M5AD0B!\8+"E77@19G*6&4O17';@MKT ML>3Z%:L_I1(M.3KNIF2]5+.8;>Q="XKHV3EI:M!Q&)A0T!$GJC%`3J4JT]#;0 M"A9T(YXE9K]8L>5W6LK41#C:&-:@[)'J?76KK@HG?LUU6\5(ZUV24X\POM,F. M,S7&Z!K`+,;7]-HT>9-%`LS$*!ZR&K.E?\16#:L%1=1EP&\1Z' M[!3,]^R\(!0.?4`/HH8EWQQBP#1.I/^5RNJXWUKBW-"Q>UNR99A(74_19C)5_R-*)+Z>PVH&PJ.'\`^>M\+2TRVOENW#]CT3:X88M MY<&,OU7!#Y6J&D_4U/+E<0BS:&@\9QB6U"+*0*2FGKL:HS".DQ?4J*H#B<*TZ M_HW$M^-Z%D;HPV7KA!H-P)3!?I-;=GXY''4N+GJGOT/8]OO[\\O.X.OOGWN#* MX7G_DOUALZC%C09L__:/P-9)R@Z.'*A3DEH6W M,2OR;,&3FO4H8?V$JD&J%:)Z'%+GH%DPN\4:D4M&[[PR2[C+7K81W4&1//CV0 M#R%>[X^/)_V@H79=8S+ MR5^44?*ZMNRDP&SV;Q5+45;!X\$J?:9%5$F7^G,_*&V*L*^ER@R\+4R\O7^FZ MIRSE[!I$!79<-8P'`1K?!\U7M?<#],=OV>%#`5=,*D`/E"A81E!BK6A/2J3`7 M#_=;!%EA.BP M-(#KTJ#_0OYL\Z]I$;(6?EMV(S17OOSD1*$6KTOP\L4CYR$*Y6:ELZRC4%-K, MKO2+RV.=&?)U850A:*'M4'1:!!Y@^5F;2EM(K:B=EA;>I-D-P330_51&H;;KB M>$'=8XD?".++&X(0&-P4]M_7Y[V1D\Q^[+[(BX^=*U6JJ>"T"ZPMF#8TIP,>' MILE._[L368#P*K:+>:B`MMSU\)Z-?07GH\P;1!@7DKL'Y@.,3#^GWQ49A%\_B6"YE.LLDYH)A\,VGIHH.@[FM1N+(V$ M2]9Z]2XEA7Y2CX)_<(?!RQM"1E8774OY8.QX,WR3)I/98)/N>H^L;\J\2 M,H'U!"^;T!T-P?[.+O0]$/FFJWX]?R[_TQ]CV1WPNJ_>=":36"GEZSQ>P/_UK MU'ZRCQD@=II&:_R`0FC7,R/9ED%#V8IS&D^G"J(WB,E6'1&X";@W!S;Y3>G"/ M4E';IA91O#3[M)P4XKG,8=CN3*">F)METIF3.0C*U@ZTB\9(N^ MGSMI^XS_SSI&U3$NTF7/W5`%=2CO@_S;]::IC#P=(`]OW,QH.,;OP+QI';%/P M[Y%AYF$&I!,W3*S"B+?8QW3#;WFV!VH*[]PMEWA+',Z$ZC)WX<`L5:E+%?$F9 M+ETHN8N(F.%5`GGN]1)7M#`.VK")_P'QSN:ZE%8_1.EY;``Y]3'UCKG.X9_+[IOT#5UT&:XN8( M_0&V"30F81X2;P?1:ATT60#8:;?M7;"Z,0=MM]O6U$=A.]@_H:,7XSU*AJ/KC MA""@5$PHDX+IL`[OI&GUJ.VJ?-['R[;K3,CKA-I:WP^OL=(&S#ZCL+_J1D^PM M'^T#G!98X[T=QS]_KF>0W.\T*1W_&54L`]IF)37XXJ[)PMLP7A#SN1E?$Q[:V MUDX9Q;FJ!B0:%"GP_"9UE*I:*)!.HBG?4'6`G)IE"$HUX<\$ZUY=RRA/SY'H` MQ8ZE<8H?7,JQTXV3F&))0-U_6WKUQ\TS7*#36#ZEDA;%763.DD?\D>I0;W^XJ2K#GY&H_IU@A+240:UJDF=!@@J] MOJ)A1@^W[C**`J."9MV^K:UU\>,JP/^`AR5RAOV)U!.0;FS]Q-8]V7$FH:COB MU#R",E8$54>X0GCCZ^3*XNJI[M'/CYR=HM^'`]:-6YKQ5R!ZH!0M"9"; M`8*<6[R.KK@/?B5@8>0R";82O@O[\B[X5$QHW0=( M7+TLQEN%MZ68RYA:RCPXC%J:Z!&Q$>#1KS4A3(]^>3.>RE!=R82V'59#8X%CE M07]ML-R>,)YE::9O$1E%4\S]G571&?,M*9=E3D*.C;,K>#?P$WJ/V/=9]XDW7 M9XBZJ<>=8=IC>XQ/T3A]FO[FE":0<6-_^)$NWPMYV\,@$G8F1JG<\Y42^7/;] M^U%Y"(R*O@7J"\/\"O5*K[DJLL3K.8OF:)J M,)YABUA,%^$`FP*,1\M9^J(W''8_=@;#WFB/R>^+H1B,>H-/3+Q<[@U)A:6FO6>&K MSK%YHX@XS.^H]*2A*$@0B=A/^WG?+:'(49J9%W9(T"Q^W\2.%9_WWO_K#M-%`VN%+=PZ]SSG8$N"&U M/=OK1Q4))_'6'ZJO6(B".?%#4=>BF%R*PX:V(J'9VCYQN,T^)*ZS?R+KV;_\Q M8SK/2UBQ[TK8\5]5S:PRDT?ME[5-"8]"_Q*R?P*:JPY^^-(S.8Y*3717%_TU? MCO."&T:/-VDV<>N^[J:9\Q/L'YA0S#L'\W^"ET=M#)3=L>X)O;&83$J\H?+<" MK/03O%B+[`46D_%;O-X4PDUY!H@7?KK9&UI@-#/4T2+>\#+S;1M>YN2MT*NYK MNW:X)+_;48>*^/WY"'6QNBI0>(HD=]FV&(95WZS5#J]=G,;O,KF,@O:B]O?:6A:KC3'B_R>W=&X<$5?JT7.;OHN'V..,#3$@ M/)[F"S[5LE$P+0JNAF/<:J`^I9#-]9_U[HR4--48/4[G@THWBPWF1O-J0 M1\5^OA*O$)A>QJ`,R@B"^BYJ:-+M]"5`93?JIYVF5>W/2K4+. M!7C#_6[9U_<<&$[(+D8$RR9W$-SC5\3P=D.ZV8YJ_0$4E?>IZSM7WP^K`V)N* ML=O[69E*VI0@UD.ASS'$\M/WF4^WUHY$=S(_)S5CZ^KQ=6)CYKEMB>9-4_W?P M^)8_*^/^B6Y)8E>P;@JN",-H$&:K_%9F[V,JVS[66_$UD_J[_AHEGE_^_\5=! MZV\;QQ'_+/T5UP."BC%%2;83I"S01+(HA(`LV:82%ZB_\'$R69$\AD=:D8/\E M[]UY[.[,[MY)<2-%0%/S;G9OWS,[C]]8TZP7&1_MYA>-R/UWOY1;^)[54 M_KL;:%$^+,E`:"E[K`V+QY(IY<%Z78)MEI#\P-7;VQ^'B-.[*4GGJ^>L:R7M[ MYF8!05-KF&0P!95P'R)@<&N;<^)[]LKW9D`*M1XB_#+X]8LCL$W>T]836H0IL M2)L@LI%A-2LPL@3AI<"\A5^4Y^D,+82+@@)_L?.^$K5P@3'[.(@9%K4JZ.%V5 M4R[,NJ23#P,X?"U2BP[1I)LJ,*1I=W@KRO__M\Y#*34I!#D8;&U&LHHP']?I# M;43VU$+O4?);BP!VK" M"#M_TO825,R+KX08FXLXHXP@`*UQ;`9:6@Z$ICVM MF&B0!".X^/2J1(%L`0%*(P4O*@%5>:\H$7G7H7Z"P7O3=1URDV.%XOSJW3,V' MX.1GVG60'7_VV^/:[[[X[]?'O[C6^U/'\H/: MB:Y''R'(1N\$YDKSLKP!(9285N6Y$'0-)U#\;IP8* M.WV@=7>U:*.?-1TWM-DRAYW<,E]L;6%.]@RBV`+](BCKRPEDT,$R5FMU7\B-9 MV\SVXSY"7$7?NZCC!-89G&`0L>8J=K'':>+=FLLK(,:F/NO]JK;2CIQ:`F)% M(]".NC[*U:3Y$&%]TN-NS\1?(JT+K#;-V3^PD.<-6@^J/U'WN][KRY][V;^6^ MLWG7UIE8Q?(A@=I6(<13^"S5DCDVX%3,J[ MKGF3,=>@[8=J9&L<2,94VDA0H5UI7B">FW1NBKOL\N)@T+X\.S/_'?2NS'\Q6 M`=+!@,^7SF@]S'ZS/V[,4/[./_C_./]6(++C&T\!?TH,O;S`9\`X18PP5,02Z M<<==15M-U9R=V6K6,O[45M)0%+M)17&[F:)XT[82.9D+&RHPHV6_S0ZW>%>KA MT'VCHP>I?V8VR&^FM;^;0[CWUOSXD(MCGUYCB]($GLA\M9Y$[Y]NUOMW?W`UF MS(IX4G^J)KUZ_<<2;U*@PW7G_9-`5E9[/1E5V?'K:4.+RU?%YUY<@, MRL2AER[=]8^@].S7U6Q5)+Z8&N:!V9>]P8^]\W,S53RX!]4TFB:TM/%[$!+$C MZ][YH!=0/W`IU2^CWGA:F@;)>L`<#Q9.WEZI=?3VI_Y5]DW8Z[AY-5\@B2*NL M.APW^3NH_0$=-YT&A\-$Q]48!ZQ+TOVT]+.6'GBS),1*B*M*%TT$.#L1@9I5]V\E+QC>OL&8HP>PRRQ_? M!I+E$^,_H]QY#ND1&CQ#P&4-4BB$RD8C9T#1RNV1(^1KYI;TVHB?\"J7`0L5C M*,D/B0^6*Z6'A-I/C6"!5SOXDUBM+!OO#4'*W'(,22LL3L[T7(&&>IVE2S^>A M7XL;U1@:23BN^?B;[P*M1[2/&O8@V[V@-U4#AGD8X^:F_I^/OMY%@ M1\0%TYT12<@G4"Z@JY5"YO80.(SX.*0]01?BG,X/LZD[V7NX#S,T%$""%VNM[ M&H?Z;69FBHR""_=TB.([@*[,BT5%*C8:6:41WU98\0)@.[EZRB:UNJ,&=SPU= M?.F2`JX(KVC*"@_3Z@KS.W-/&TT[+*[FUT[2*<0*_.0(H8 M&2[O;H=W>.<'Y7N&0^TN:B%D3YW+!]JV#V.?CV2L_^?92LI%]'"[A,?2#:&61 M]K,Y>2+*S^!?GT>4BT2=ZR*N\QJ?/HBT2)).9FOM<8(/'T;VZ8%D\#2DO)X7F MO\:],0\I&DW1\J[(%>U'^S2DKJ;ZFH4/;\S3D'!X>Q,W]B,\#2G-,;2)&OL?H M1;88+@_,_XYPZCM'>?`0ETGGZ`\4@=525P`7#960!1;A%Y(>,;#FI;NR9$4)F M<4V!WGC^'AA<`D[74(_S$L&]AQ%%\*\FYQ'Z]!,)AE&ZWB:82[`<&=)V]I'"` M>-J@-\X('0T?XH-V)B-S:E@8&-$RT'*@)!G$OI!`Y[C#$\!;QG%CH14PA?!JT M+8%RO8G(+L7]I//,@L&Q4()1H3MD)GGH.!.U'.WOG6S%L(G`"_Y<"KRB''QG923A5-;I4IB[)IM*#;<19T5RPDY&$.GC-@I] MOX<*1#(U&%*S@V!PPF1\KTLC%B+;M7%0GEMO*_J(6ZIM6;\?M"E%A]HX+B-52 MM(-`*U40AJEOT\S8"5O(A#1<6)01H5'B<1@>Q8*N#XO"`V!7`A"%X%!-P#S6% MT.M.[#'S%LTKDP\!GR=Z"I?:I!1@[$[B(L7VR'N@9BT:5!UTUE\*0"!]:KX\Z1A*RLX_B(7@; M\,ZAC#/PAXY%M(%KZZH>*SA8MF;`D*W)9(%RA((@X50==69(YVL2/3ZUD5H:C M?=Q&+)@SQ0/=*=L9@=SAP@55C(081+0B\U!Z]28X#7,9=^)Z6ZN?@`!2P;**D MGRIKE$H6XBM;-3.+&?S7HIPG+LW3TJ+)?Q"][D+\ZB!Q4B9<'(D]DCJ(0^>PV MPG9\QOIC.)$#51VVX9FDYM&'&&J#;U.Z85S6(H`W0PC6:." MP&-&=+-YACJ7S`AO\QFAV@M1,(>5!8%O=8.2P&:%54/NB"!C7,>(V%QYM65.R1^$2\>8ZWF[*TW)/#V^G+")76^%X1$LK, MYS"G9(PCDUQ`ESA%`2(6J%L$J.*NU*=QFI3^3L'1W`[OPAQ56`$>9J#816R#9 MX35F<:BM*!+?K$<6ID19DJM20P5"Y]H!7 M/0W'B*OETN=0.AZ[QD79JMSGG.E^'7AL>R!VB#B:@T."\A)B&^:P9S].V8\77 M(D&S3S/",X0M8>7&!+M5T.3Z=G/8"ITO;?ZIU)90.0RUH!-).C:"@5G-4#%"# M(Q\0VZ&]8B6=UP#IO2I*2+:ND%8\.Q5ZI3Q@K9YA"G1JCLNDL!!?E+"Z'*_<2 MF5DBDQE"Q86?#B4KQ@*54^V8E#O[M)AK43GO83QPRI`BWS;6'T%M:S(865P3V M"^<4.OYFWD<1IL?%!U`A]%0LU\D,H$CQ!\X@4]T)!!NM"X^A11,$60S6LPDMR M$'$,[/`18"'BE+<%^_@S6A_3X\U;2"=DM-"9$B)D@U8=A$KRTO0D_ M^3Y%:U+75$BE5H&NAM8S,R?`P<3P`BX=)\NQ;\Z+3\4\X[\WQ1HCETPM6,-PR M#@S_#EFY-"_;PGT`R$%6(`JS#RP=@FAB*E:/:VT30R0].54/]YX%#Z(^6#6$K M0V94]$\&E?,'$1%ABS)XBD*W>]01UPU6H4HZ-6*].AHJL/95^X'O,/D_%E MOD,7\@FJ&3K='\MOAC@@>_L.G3U\UP(U799WE50>5P`ZQ^AI?I!K];P%E#7\G"C"Q) M^)?T[;+V2_;(O3BIG16#$W8E=S%GFH67`LV).KOX86"KWQ4SA'W6W$/K MF30GBY:2Q:*,W&OX>62B?/P9=,G=:N=P15D#X(HH9?V([6K8`W1"+27_^2.[NZ:3>K=V]5-[HEB6D_+;PD])VR$,&$JSNQ M[BGI_E"Z?ZV+E3E2^A[H1\``,H][H=S!;`'-@(8TXQ[#VRHLE9"K+014!K5[4 MO);#*#FG]W!;+TIK&%J&K)3J,#!2B]]KIOPG>-!DDL`D#`:6NC_1HLKGZ#$?4 M0X;E$CZ"[JZH4/?F-^[,]<=F'8O;;7=9W!#1_(E#A,WN2ST)[)$3'HY=U5Q2U MCF602%&UZ=3]@:[57&_4KFE)-#G/2HX!D-8+]"FX:O&FKV/LW_CB8#L"%=_1`UNC"AU^:3M?-K?SY4-FZI$&U'$0G5FCM5L_Y,W3W M3Z^=GM=I."RQAZ(E50>8IKRVDXT;II1`T;RZ6P'`2(:G-N%VOC>7"LA,+C`LV M-6CG^X+B;ND\KUQV8=20T)5?9>\V=0GL3&L6(C.WS*_@,9\K,K6;KF&[)&SGF ML;,S8,118)R7EG5*2-E6CG94AXTHGRUM9%B;@C'F+K$"OX(DU)1;,PM2X]HTR MPVS\N`L\Y2DON;P'4`IW\)_Y7A:+#NWLV*R&"Z7/RR-0 M'#-<[P_GH\ZDR!6.2VK=UB_;8/7T.7^\!D`R2X8A&8:0CAC"8``79X-=1$`"$ MUU`OG01YJ-OR^BDX3243/>>:H2MY(9!&B/ZBO!7^.2#%`.P-JI;!@1,L6/`M# M88R4RZ;/.CFS'!'`N&K["8.\8F9%4MZ+%4EBZ)0PWHB)@E'HJA85,'G=;#4=P M_3`NY^5B5';,'BRJ.S!Q+,M/G>NUH+Z>P>!NNMGS[HOGAP='AR\[SX^R=\,%X :@,E?>?OY'`TI)R<#.]?FR/@?O=T9\/FK``!N$ end size 10826 From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 11:46:11 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90184-1>; Wed, 23 Aug 1995 11:44:02 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA16226; Wed, 23 Aug 1995 10:46:04 +0200 Date: Wed, 23 Aug 1995 10:46:03 +0200 (MET DST) From: Kamil Iskra Subject: New inlines To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII If you would like to try new inlines, please have a look at my WWW Home Page (see bottom of my posting for URL). They have been created using "C" program "fd2inline", from OS 3.0 fd-files (sorry, I simply don't have OS 3.1 ones. Are they available somewhere in the Internet?). "fd2inline" has the following known limitations: - It does not support fd files without "##bias", such as "cia_lib.fd". Should be fixed soon. - It has problems with "mathieeedub***" libraries, cause they specify more registers than there are arguments. This seems to be rather complex problem and first I'll have to have a look at how GCC puts doubles in data registers. - Arguments of type "pointer to function" are not supported. There are two reasons: "fd2inline" has problems with parsing them (I'll have a closer look at it in a couple of days) and it is impossible to use them with current macros (have a look at "inline/macros.h" so you'll understand why. Any suggestions are welcome). - Vararg versions of functions whose last argument is not of type "struct TagItem*" are not generated. This applies to dos.library/FWritef, dos.library/FPrintf, dos.library/Printf, intuition.library/EasyRequest, intuition.library/BuildEasyRequest. Should be fixed soon. - "Second forms" of certain dos.library functions that have two names for the same call (!) are not generated. These are AllocDosObject[TagList], CreateNewProc[TagList], System[TagList], NewLoadSeg[TagList]. Should be fixed soon. - Name of preprocessor define "_INCLUDE_***_H" is taken from ##bias instead of fd-file name. This is minor problem, but should be fixed soon. - Program outputs to stderr messages about some functions that it cannot find (these are private functions or vararg-stub). This is minor problem, so I'm not sure if it'll be fixed soon. "fd2inline" has also some advantages over "perl" script (despite new inlines format, of course :-): - No need to manually correct inlines of functions that take arguments in "a4" or "a5". - Only d0/d1/a0/a1 registers are preserved. - Vararg-stubs more efficient: use ULONGs instead of "struct TagItem" (four bytes less of stack is needed). "fd2inline" is by no means complete. There will be support for functions that don't need "memory" or don't clobber any registers or don't need library base in a6 (I need help with the last one: what is an advantage of such functions? How to make a call to them more efficient?). I'm waiting for your suggestions, bug reports etc. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 11:46:19 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90232-4>; Wed, 23 Aug 1995 11:45:26 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA16237; Wed, 23 Aug 1995 10:47:31 +0200 Date: Wed, 23 Aug 1995 10:47:31 +0200 (MET DST) From: Kamil Iskra Subject: GCC 2.7.0 To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There is one serious problem with g++ libraries: they have not been runned thru ranlib. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 13:10:50 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90538-4>; Wed, 23 Aug 1995 13:09:39 +0300 Received: by colombo.telesys-innov.fr; Wed, 23 Aug 1995 12:09:24 +0100 From: Philippe BRAND Message-Id: <199508231109.MAA06134@colombo.telesys-innov.fr> Subject: gcc-apurify To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Wed, 23 Aug 1995 12:09:23 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 416 New version of gcc-apurify is available on both my site and funet. BTW I'll ranlib libg++ archives. I'll include fixed Install script. Is there anything else to correct before releasing it to Aminet ? Does ld auto-stackextend runs ok ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 13:24:26 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90167-4>; Wed, 23 Aug 1995 13:23:55 +0300 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id MAA01415 (8.6.12/IDA-1.6); Wed, 23 Aug 1995 12:23:42 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA05739; Wed, 23 Aug 95 12:23:42 +0200 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9508231023.AA05739@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: New inlines To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Wed, 23 Aug 1995 12:23:41 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Aug 23, 95 10:46:03 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1131 > - Arguments of type "pointer to function" are not supported. There are > two reasons: "fd2inline" has problems with parsing them (I'll have a > closer look at it in a couple of days) and it is impossible to use > them with current macros (have a look at "inline/macros.h" so you'll > understand why. Any suggestions are welcome). To solve the second problem you could (for example) define a new type like typedef long (*__longfuncptr_t)(); in the header file? > "fd2inline" is by no means complete. There will be support for > functions that don't need "memory" or don't clobber any registers or > don't need library base in a6 (I need help with the last one: what is > an advantage of such functions? How to make a call to them more > efficient?). If you let the compiler choose a free address register asm("jsr %3@(-xxx:W)":"=r"(ret):"r"(arg1),"r"(arg2),"a"(LibBase):...); ^^ LibBase is index 3 in the list ^^^ address register and if your function is very simple you may get a0 or a1 which don't need to be preserved like a6. This may help to save storing the registers around the function. Matthias From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 14:48:30 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90017-2>; Wed, 23 Aug 1995 14:46:55 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 23 Aug 95 13:45:54 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <212ef20e.u7t157e.c6bc6-robert@plukwa.pdi.lodz.pl> Subject: lib*.a to *.o? Reply-To: robert@pdi.lodz.pl Content-Length: 120 To: amiga-gcc-port@nic.funet.fi Date: Wed, 23 Aug 95 13:45:54 Hi! Is it possible to convert lib*.a back to obj files? or i have to compile from scratch? regards, Robert From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 15:31:12 1995 Received: from math.uwaterloo.ca ([129.97.140.144]) by nic.funet.fi with SMTP id <90295-3>; Wed, 23 Aug 1995 15:29:55 +0300 Received: by math.uwaterloo.ca id <77146-1>; Wed, 23 Aug 1995 08:29:21 -0400 Date: Wed, 23 Aug 1995 08:29:15 -0400 From: Jeff Shepherd To: robert@pdi.lodz.pl cc: amiga-gcc-port@nic.funet.fi Subject: Re: lib*.a to *.o? In-Reply-To: <212ef20e.u7t157e.c6bc6-robert@plukwa.pdi.lodz.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 23 Aug 1995, Robert Ramiega wrote: > Hi! > Is it possible to convert lib*.a back to obj files? or i have to compile > from scratch? > > regards, > Robert > ar x lib*.a will dump all the object files in the library. jsshephe@math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 15:39:07 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90543-4>; Wed, 23 Aug 1995 15:38:36 +0300 Received: by colombo.telesys-innov.fr; Wed, 23 Aug 1995 14:37:26 +0100 From: Philippe BRAND Message-Id: <199508231337.OAA06527@colombo.telesys-innov.fr> Subject: Re: lib*.a to *.o? To: robert@pdi.lodz.pl Date: Wed, 23 Aug 1995 14:37:25 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <212ef20e.u7t157e.c6bc6-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Aug 23, 95 01:45:54 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 404 Robert Ramiega writes: > > Is it possible to convert lib*.a back to obj files? or i have to compile > from scratch? Use 'ar' and 'sobja'. extract all a.out object files using ar then use sobja to convert into hunk format. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 15:39:35 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90328-3>; Wed, 23 Aug 1995 15:39:21 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 23 Aug 95 14:37:26 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <212efe23.u7t157e.14371-robert@plukwa.pdi.lodz.pl> Subject: Re: lib*.a to *.o? In-Reply-To: (from Jeff Shepherd ) (at Wed, 23 Aug 1995 08:29:15 -0400) Reply-To: robert@pdi.lodz.pl Content-Length: 610 To: jsshephe@math.uwaterloo.ca Cc: amiga-gcc-port@nic.funet.fi Date: Wed, 23 Aug 95 14:37:26 On Aug 23 Jeff Shepherd wrote: > On Wed, 23 Aug 1995, Robert Ramiega wrote: > > > Hi! > > Is it possible to convert lib*.a back to obj files? or i have to compile > > from scratch? > > > > regards, > > Robert > > > > ar x lib*.a will dump all the object files in the library. > Thanks! Stupid me. I guess i should spent more time on reading the man pages than writing e-mail =o) > > jsshephe@math.uwaterloo.ca > http://www.undergrad.math.uwaterloo.ca/~jsshephe > The world is coming to an end! Repent and return those library books. > Finger me for my PGP public key. > > Robert From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 16:16:59 1995 Received: from unios.rz.Uni-Osnabrueck.DE ([131.173.17.7]) by nic.funet.fi with SMTP id <90726-1>; Wed, 23 Aug 1995 16:15:05 +0300 Received: from dosuni.informatik.Uni-Osnabrueck.DE ([131.173.160.1]) by unios.rz.Uni-Osnabrueck.DE with SMTP id <189483>; Wed, 23 Aug 1995 15:14:34 +0200 Received: from atum.informatik.Uni-Osnabrueck.DE by dosuni.informatik.Uni-Osnabrueck.DE (4.1/SMI-4.1) id AA00429; Wed, 23 Aug 95 15:14:19 +0200 Message-Id: <9508231314.AA00429@dosuni.informatik.Uni-Osnabrueck.DE> Received: by atum.informatik.Uni-Osnabrueck.DE (NX5.67e/NX3.0X) id AA12665; Wed, 23 Aug 95 15:14:15 +0200 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Elmar Ludwig Date: Wed, 23 Aug 1995 15:14:11 +0200 To: amiga-gcc-port@nic.funet.fi Subject: help Reply-To: ieludwig@dosuni.informatik.Uni-Osnabrueck.DE help From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 17:00:13 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90411-1>; Wed, 23 Aug 1995 16:58:51 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 23 Aug 95 15:56:29 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <212f10aa.u7t157e.c2e44-robert@plukwa.pdi.lodz.pl> Subject: AmiTCP-sdk-gcc Reply-To: robert@pdi.lodz.pl Content-Length: 844 To: jsshephe@undergrad.math.uwaterloo.ca Cc: amiga-gcc-port@nic.funet.fi Date: Wed, 23 Aug 95 15:56:29 Hi! Finally i managed to compile first working ncftp 2.1.0 for Amiga. During this time i found that the library libc.a.41.0 suplied with AmiTCP-sdk-gcc has one obj file too much. To actually use it one must "ar d libc.a dup.o" first. Since ncftp compiles OK only when using old socket can You tell me what are the difference between old and new socket code. regards, Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 18:03:17 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90765-1>; Wed, 23 Aug 1995 18:01:41 +0300 Received: from math.uwaterloo.ca by funet.fi with SMTP (PP); Wed, 23 Aug 1995 18:00:49 +0300 Received: by math.uwaterloo.ca id <77159-2>; Wed, 23 Aug 1995 10:57:39 -0400 Date: Wed, 23 Aug 1995 10:57:28 -0400 From: Jeff Shepherd To: robert@pdi.lodz.pl cc: amiga-gcc-port@nic.funet.fi Subject: Re: AmiTCP-sdk-gcc In-Reply-To: <212f10aa.u7t157e.c2e44-robert@plukwa.pdi.lodz.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 23 Aug 1995, Robert Ramiega wrote: > Hi! > Finally i managed to compile first working ncftp 2.1.0 for Amiga. During > this time i found that the library libc.a.41.0 suplied with AmiTCP-sdk-gcc > has one obj file too much. To actually use it one must "ar d libc.a dup.o" > first. > Since ncftp compiles OK only when using old socket can You tell me what are > the difference between old and new socket code. The old code uses the call-back hook supplied in amitcp to create file descriptors for sockets - ie. fd 5 is a socket in ixemul's file table and AmiTCP's filetable. This allows you to use most of the AmiTCP inline functions. The exception is DupSocket(). There are 2 cases in DupSocket() - dup'ing to a new descriptor, and duping to an existing file descriptor. The first case (gcc function dup()) is easy. I had to create a new dup() that knows about sockets. This is the reason for the duplicate dup functions in libc.a and the one supplied. The second case (function dup2()) I could never get right. This is the reason that server code does not work since dup2() is needed to redirect stdin to a socket. The new socket code does not use the call-back hook. Most of the socket functions are just wrappers that create a file descriptor and call the AmiTCP inline functions. The stock dup() & dup2() work in this situation. For some reason using select() on sockets (using the select code posted here awhile back) locks once in a while. The cause seems to be that select() thinks a socket is ready for a read but when you actually read it (using read()) it just hangs. This bug becomes most apparent when you select() on sockets and non-sockets at the same time. jsshephe@math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 18:07:37 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90807-1>; Wed, 23 Aug 1995 18:07:22 +0300 Received: by ceylon.informatik.uni-rostock.de id RAA19804; Wed, 23 Aug 1995 17:07:15 +0200 Received: by honshu.informatik.uni-rostock.de id RAA06947; Wed, 23 Aug 1995 17:07:14 +0200 From: Gunther Nikl Message-Id: <199508231507.RAA06947@honshu.informatik.uni-rostock.de> Subject: ixemul and math-libs To: amiga-gcc-port@nic.funet.fi Date: Wed, 23 Aug 1995 17:07:13 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 642 Hi! Recently there was a small test program concerning problems with converting floats to ints. I tested three ixemul versions (39.45, 40.4-030nofpu, and 41.1-30fpu) and there result was always the same, wrong. But thats not the point. I checked the order the math libraries are opened. As I only have sources for 39.45 I looked there, but its done the same way in 40.4 and 41.1 (these ones I dissassembled). All libraries are opened in the libInit() function and thats bad for the math-libraries, isn't it? I thought these libraries had to be opened _per_ task, thus these libraries should be openend in libOpen(). Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 18:09:42 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90478-3>; Wed, 23 Aug 1995 18:09:28 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HUF4ZCQXDS00AO5M@NET2.WAU.NL>; Wed, 23 Aug 1995 17:11:43 +0000 (GMT) Received: by vines2.wau.nl; Wed, 23 Aug 95 17:16:42 +0100 Date: Wed, 23 Aug 1995 16:08:43 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: ixemul bug + solution. (LONG) To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi all, I know this should go to the ixemul porting list but I think most ixemul maintainers also read this list and it is informative to gcc users in general. Introduction: It started with me trying to compile Ghostscript3.33, works like a charm, and trying to run it. This started a bug hunt which I think might have been solved. After sending the maintainer of GS the debugging output from GS, he suggested that there might be a problem with libm.a and provided me with a small test program which should show if libm.a was the guilty one. You might have seen it in one of my previous mails but it is repeated here to illustrate my point. main() { float f = 0.51; int i = f; printf("%d\n", i); exit(0); } If this program is compiled on my A3000T-030/882 with gcc270 (latest beta from funet, 21-Aug) and the following commandline: gcc -v -O0 -m68000 -o test test.c then the output from test is '1' on my machine. The same executable produces a '0' as output on an A4000-040 and probably, but not tested yet, '0' on an unexpanded A1200 and an A4000-030 without FPU. If compiled with the -noixemul switch the output is as expected '0' Compiling with -m680(2)30 *and* -m68881 or with -m68020-40, which will use fpu instructions, will solve the problem too on my machine. Problem definition: There is something different between ixemul.library using compiled programs and LibNix compiled ones. But what. Suggestions made: - Something in my config. Nope, re-installed gcc, boot without startup, didn't help at all. - Math libraries need to be opened in a particular order. Nope, Libnix and ixemul are using the same order. - Difference between ixemul and Libnix in what kind of function they use from the math libs. Nope, same functions used. BUT, ixemul caches the Math library bases and Libnix doesn't (obvious why) and caching of the math bases is *not* allowed according to the RKM (thanks Matthias) and for good reason as I will show right away. The problem is in the way ixemul.library handles programs compiled for mc68000 but run on a mc680(2)(3)0+FPU (no difference between 881/2). 'fixsfsi.c' is the function which calls the math libs todo the truncation *BUT* it is using the cached mathbase and that is causing problems. ----------------------- fixsfsi.c ------------------- #include "common.h" #ifdef IEEE_SINGBAS #include #else #include #include #endif SItype __fixsfsi (a) FLOAT a; { #ifdef IEEE_SINGBAS return IEEESPFix(a); #else #if 1 return SPFix( SPFieee(a)); #else /* don't know.. */ return SPFix( SPAdd (SPFieee(a), SPFieee( *(long *)(float[]){0.5}) )); #endif #endif } ------------------------- end ---------------------------- Below is part of 'ix_init.c' which does the caching of the math bases. ------------------------------------ ix_init.c ------------- /* * This file is part of ixemul.library for the Amiga. * Copyright (C) 1991, 1992 Markus M. Wild * Portions Copyright (C) 1994 Rafael W. Luebbert * * $Id: ix_init.c,v 1.12 1994/07/11 22:16:47 rluebbert Exp $ /* these are the libraries we are potentially interested in. Not finding a certain library doesn't mean we can't continue. */ static union lib ix_libs[] = { "dos.library", "intuition.library", "graphics.library", "mathieeesingbas.library", "mathieeedoubbas.library", "mathieeedoubtrans.library", 0, }; enum { DOS_LIB=0, INTUI_LIB, GFX_LIB, SINGB_LIB, DOUBB_LIB, DOUBT_LIB }; struct ixemul_base * ix_init (struct ixemul_base *ixbase) { int i; ixemulbase = ixbase; if(! check_hardware()) return 0; open_libraries (ix_libs); -------------- end of part ix_init.c ------------- See that line reading 'check_hardware()' well it is used later on to adjust some vectors to point to optimized routines, including stuff related to math. What I forget to bring with me is some code from ixemul which shows what happens if a program is started that uses ixemul.library. It boils down to the fact that before anything else happens the routine 'reset_fpu' is called. /* * This file is part of ixemul.library for the Amiga. * Copyright (C) 1991, 1992 Markus M. Wild * Portions Copyright (C) 1994 Rafael W. Luebbert * * $Id: trap.s,v 1.1 1994/06/19 15:17:35 rluebbert Exp $ * * $Log: trap.s,v $ # Revision 1.1 1994/06/19 15:17:35 rluebbert # .globl _resetfpu _resetfpu: moveml a5/a6,sp@- lea Lreset_fpu,a5 movel 4:w,a6 jsr a6@(-30) | Supervisor() bra Lafter_reset_fpu Lreset_fpu: clrl sp@- frestore sp@+ rte Lafter_reset_fpu: moveml sp@+,a5/a6 rts -------------------- end of resetfpu --------------- PLEASE notice the following 2 lines: clrl sp@- frestore sp@+ The clrl sp@- is the one causing the problems. It is restoring a NULL state fpu stack frame. REASON: Quote from '68030 assembly language reference' book page 485-487: Effect of using Frestore with a NULL state frame: 'Note that the entire programmer visible register set is affected. The control registers are all *cleared*, and the floating point data registers are all set to non-signaling NaNs' A fpcr register with all zero's means that *round to nearest* and 'extended precision' is *ON*. ^^^^^^^^^^^^^^^^ This is sole reason why a -m68000 compiled program produces wrong ouput on a mc68881/2 machine. (0.51-->1) SOLUTION: Piece grabbed from one of the math libs with Resource. lbC00011C MOVEQ #$48,D0 ADD.L D0,D0 FMOVE.L D0,FPCR ADDQ.W #1,($20,A6) BCLR #3,($2A,A6) MOVE.L A6,D0 lbC000130 RTS This sets fpcr to double precision AND *ROUND TO ZERO*, but only when the math library is opened by the program using it. This piece should be included in 'resetfpu' OR the caching of the math bases should be dumped. Lots of thanks to everyone who reacted to my previous mails with all those lovely suggestions which has ended in this masterpiece :) Thanks again, Joop PS: Since I don't subscribe to this list please CC: to me if you reply to the list. From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 18:33:25 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90899-2>; Wed, 23 Aug 1995 18:32:14 +0300 Received: by ceylon.informatik.uni-rostock.de id RAA19933; Wed, 23 Aug 1995 17:32:04 +0200 Received: by honshu.informatik.uni-rostock.de id RAA07037; Wed, 23 Aug 1995 17:32:03 +0200 From: Gunther Nikl Message-Id: <199508231532.RAA07037@honshu.informatik.uni-rostock.de> Subject: Re: ixemul bug + solution. (LONG) To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Wed, 23 Aug 1995 17:32:02 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "joop van de wege" at Aug 23, 95 04:08:43 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 412 Joop van de Wedge wrote: > _resetfpu: > moveml a5/a6,sp@- > lea Lreset_fpu,a5 > movel 4:w,a6 > jsr a6@(-30) | Supervisor() > bra Lafter_reset_fpu > > Lreset_fpu: > clrl sp@- > frestore sp@+ > rte > > Lafter_reset_fpu: > moveml sp@+,a5/a6 > rts > -------------------- end of resetfpu --------------- The above code will break on a mc68060 since it has a larger frame for frestore ... Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 19:22:53 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90497-2>; Wed, 23 Aug 1995 19:21:28 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 23 Aug 95 18:20 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 23 Aug 95 18:13 MET DST Message-Id: Subject: sugestions for amiga-gcc To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 23 Aug 1995 18:13:14 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 567 for the next version of amiga-gcc i would like to see: 1. motorola-code the switch is already there but i dont know how well it is implemented. because gas supports both sides there will no problems but a new range of assemblers usw will work then. 2. long double it should be supported at least for m68882/1. i dont know why but the code is there and we should give it a try to see what happens. walter -- ----- America has Bill Clinton, Steve Wonder, Bob Hope & Johnny Cash we have Helmut Kohl, no Wonder, no Hope & no Cash ! ----- From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 23:25:39 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90542-2>; Wed, 23 Aug 1995 23:24:05 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HUFFYL7T9S00AKRN@NET2.WAU.NL>; Wed, 23 Aug 1995 22:26:27 +0000 (GMT) Received: by vines2.wau.nl; Wed, 23 Aug 95 22:31:27 +0100 Date: Wed, 23 Aug 1995 22:29:31 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: ixemul bug + solution. (LONG) To: gnikl@informatik.uni-rostock.de Cc: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >> Lreset_fpu: >> clrl sp@- >> frestore sp@+ >> rte >> >> Lafter_reset_fpu: >> moveml sp@+,a5/a6 >> rts >> -------------------- end of resetfpu --------------- > > The above code will break on a mc68060 since it has a larger > frame for frestore ... > Gunther Ha, a new real life bug. This should be fixed ASAP since I'm planning to buy one of those 060 beasties. Joop From amiga-gcc-port-owner@nic.funet.fi Wed Aug 23 23:26:29 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90725-4>; Wed, 23 Aug 1995 23:26:06 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HUFG27GMKG00ANQQ@NET2.WAU.NL>; Wed, 23 Aug 1995 22:28:35 +0000 (GMT) Received: by vines2.wau.nl; Wed, 23 Aug 95 22:33:45 +0100 Date: Wed, 23 Aug 1995 22:32:34 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: ixemul bug + solution. (LONG) To: gnikl@informatik.uni-rostock.de Cc: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >> If compiled with the -noixemul switch the output is as expected '0' > Did you linked with '-lm'? Try without and see what happens... YES, that should be at the end of the line. Sorry about that. PS: This one is for Gunther: > PS: What resource version did you use? Where did you get it from? How > much? Version 6, Got it from Helios (England) at 140 pounds. Will send the exact address tomorrow (it is now 22:30 and I want to go home and sleep :) From amiga-gcc-port-owner@nic.funet.fi Thu Aug 24 00:13:58 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90542-2>; Thu, 24 Aug 1995 00:13:23 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id WAA07939; Wed, 23 Aug 1995 22:11:00 +0100 From: Lars Hecking Message-Id: <199508232114.WAA01990@mostar.nmrc.ucc.ie> Subject: Re: sugestions for amiga-gcc To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Wed, 23 Aug 1995 22:14:10 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Walter Harms" at Aug 23, 95 06:13:14 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 679 > > for the next version of amiga-gcc i would > like to see: > > 1. motorola-code > the switch is already there but i dont know > how well it is implemented. because gas supports > both sides there will no problems but a new > range of assemblers usw will work then. There's no full gas-support for moto-syntax yet. > 2. long double > it should be supported at least for m68882/1. > i dont know why but the code is there and we > should give it a try to see what happens. > America has Bill Clinton, Steve Wonder, Bob Hope & Johnny Cash > we have Helmut Kohl, no Wonder, no Hope & no Cash ! The other .sig was more, uhm, original ... ;)) From amiga-gcc-port-owner@nic.funet.fi Thu Aug 24 10:44:26 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90295-2>; Thu, 24 Aug 1995 10:40:17 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HUG3KWXYKG00AP1A@NET2.WAU.NL>; Thu, 24 Aug 1995 09:42:37 +0000 (GMT) Received: by vines2.wau.nl; Thu, 24 Aug 95 9:47:53 +0100 Date: Thu, 24 Aug 1995 09:43:44 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: ixemul bug + solution. (LONG) To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) As a follow up to my own post I can say that my suggestion works. I compiled ixemul41.1 with my own suggestion applied and this morning I ran 'test' and its output was '0'. Its a beautiful day today :) Now we can have a long discussion whether single/double/extended precision should be used. ;) > Lreset_fpu: > clrl sp@- > frestore sp@+ moveq #72,d0 /* added by Joop van de Wege */ addl d0,d0 /* fixes a long standing bug in ixemul :) */ fmovel d0,fpcr > rte > > Lafter_reset_fpu: > moveml sp@+,a5/a6 > rts > -------------------- end of resetfpu --------------- From amiga-gcc-port-owner@nic.funet.fi Thu Aug 24 10:44:34 1995 Received: from alsvid.scu.edu.au ([203.2.33.1]) by nic.funet.fi with SMTP id <90328-3>; Thu, 24 Aug 1995 10:40:17 +0300 Received: by alsvid.scu.edu.au id AA29688 (5.65c8+/IDA-1.4.4 for mailing list ); Thu, 24 Aug 1995 17:39:15 +1000 Date: Thu, 24 Aug 1995 17:39:15 +1000 (EST) From: Erik Alexander Austin To: mailing list Subject: gdb Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Where can I get the amiga version of gdb? Also, is there a problem with the string handling in GCC 2.6.3? My program won't let me use filenames < 10 chars. I've just solved that problem by explicitly initialising and terminating strings which I probably should have done in the first place. Could you please make sure any replies get to me directly because I don't subscribe to this list (too much mail!). Erik eausti12@scu.edu.au From phb@colombo.telesys-innov.fr Thu Aug 24 13:45:08 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90923-4>; Thu, 24 Aug 1995 13:40:26 +0300 Received: by colombo.telesys-innov.fr; Thu, 24 Aug 1995 12:25:11 +0100 From: Philippe BRAND Message-Id: <199508241125.MAA10226@colombo.telesys-innov.fr> Subject: gcc-2.7.0 distribution available To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Thu, 24 Aug 1995 12:25:05 +0100 (BST) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 514 I'm now currrently sending complete gcc270 distribution to Aminet, then I'll FTP it to funet. Latests changes are gnroff of all manpages, complete AmigaGuide documents, c++ librairies ranlibed, inclusion of gcc-2.7.0 diff file for AmigaDOS and gcc270-src.lha holding already patched sources for gcc. The utils archive will come later. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From Walter.Harms@arbi.informatik.uni-oldenburg.de Thu Aug 24 18:35:57 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90463-4>; Thu, 24 Aug 1995 18:31:46 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 24 Aug 95 17:30 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 24 Aug 95 17:24 MET DST Message-Id: Subject: -O error ahead To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 24 Aug 1995 17:24:10 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1671 I have no idea what happens here but it looks a bit strange. the reasom maybe i compile on a 68k for 68030/881 but that shouldnt hurt anyone. walter PS: philip could you please add the VERSIONSTRING !!!!! i could figure out what version of 2.7.0 these is but i guess its fearly new. these program: #include main() { double x,y; atan2(x,y); } compiled with -O 0/1/2 and this options >gcc test.c -o test -m68030 -m68881 -save-temps -O -v >ram:error.txt causes an *internal error* Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D_ _MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -D__OPTIMIZE__ -D__HAVE_68881__ -Dmc68030 test.c test.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cc1 test.i -mfixedstack -quiet -dumpbase test.c -m68030 -m68881 -O -version -o test.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. Bus error gcc: Internal compiler error: program cc1 got fatal signal 10 -- ----- "Just remember what curiosity did to the cat." "Why do you think they have nine lives? And why do you think Time Lords have twelve?" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Aug 25 07:43:52 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90545-2>; Fri, 25 Aug 1995 07:40:58 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0slqbs-0004nYC; Thu, 24 Aug 95 21:43 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: -O error ahead To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Thu, 24 Aug 1995 21:43:15 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Walter Harms" at Aug 24, 95 05:24:10 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 364 > compiled with -O 0/1/2 and this options > > >gcc test.c -o test -m68030 -m68881 -save-temps -O -v >ram:error.txt > > causes an *internal error* Just for reference, this isn't a general problem with the compiler since your test case compiles just fine here with the 2.7.0 binaries that will be on FreshFish 10 (not that same as Phillipe's binaries). -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Aug 25 17:27:27 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90911-2>; Fri, 25 Aug 1995 17:23:33 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Fri, 25 Aug 1995 16:23:07 +0200 Received: from stetten.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA29793; Fri, 25 Aug 95 16:23:08 +0200 Date: Fri, 25 Aug 95 16:23:08 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9508251423.AA29793@inf-wiss.uni-konstanz.de> Received: by stetten.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA06043; Fri, 25 Aug 95 16:23:08 +0200 To: amiga-gcc-port@nic.funet.fi Subject: Re: -O error ahead In-Reply-To: References: Fred Fish writes: > your test case compiles just fine here with the 2.7.0 binaries that will > be on FreshFish 10 (not that same as Phillipe's binaries). How comes that yours is different? Because you froze it earlier than Philippe for stability or because you can't agree on some patches, configurations or whatever? Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Fri Aug 25 20:05:23 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90317-2>; Fri, 25 Aug 1995 20:00:34 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sm256-0004nYC; Fri, 25 Aug 95 09:58 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: -O error ahead To: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Date: Fri, 25 Aug 1995 09:58:11 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9508251423.AA29793@inf-wiss.uni-konstanz.de> from "Joerg-Cyril Hoehle" at Aug 25, 95 04:23:08 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1510 > > your test case compiles just fine here with the 2.7.0 binaries that will > > be on FreshFish 10 (not that same as Phillipe's binaries). > How comes that yours is different? Because you froze it earlier than > Philippe for stability or because you can't agree on some patches, > configurations or whatever? Generally we try to exchange important patches and periodically do a complete resync of the gcc sources. We typically each build our own binaries, mostly because we don't sync our releases. I did freeze the binaries for FreshFish 10 a couple of weeks ago. There are other reasons why the binaries might be different, aside from any source differences. We might not have exactly the same assembler, linker, or libraries, or even the same ixemul.library (FF 10 will have 41.2 which is currently unreleased, however I plan a 41.3 release in a few days. Long term we should work to eliminate these differences, and arrange releases that take binaries from a single source. I suspect my binaries get a little more testing, since I do everything native on an A4000 with WarpEngine. It takes 2+ days to compile my entire GNU tree, which has substantially more stuff than the "gcc release" that Philippe does. I also do a multistage build, which simply means that I compile the entire tree, install it, and recompile again. If the new binaries don't match byte for byte the old ones, I repeat the cycle until they do. This helps to ensure stability and interoperability of all the tools. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Aug 26 20:37:25 1995 Received: from edina.xenologics.com ([194.77.5.1]) by nic.funet.fi with SMTP id <90846-4>; Sat, 26 Aug 1995 20:35:50 +0300 Received: from darkness.gun.de (root@localhost) by edina.xenologics.com (8.6.8.1/8.6.6) with UUCP id TAA14324 for nic.funet.fi!amiga-gcc-port; Sat, 26 Aug 1995 19:36:53 +0200 X-ZC-VIA: 19950826122512W+1@darkness.gun.de From: DarkStar@darkness.gun.de (Carsten Meyer) Subject: Bug: warning: value computed is not used. Message-ID: Date: Sat, 26 Aug 95 12:22:55 CET Return-Receipt-To: DarkStar@darkness.gun.de (Carsten Meyer) Organization: CDC X-ZC-POST: Postfach 11 12;31596 Uchte X-Mailer: MicroDot 1.10 [UNREGISTRIERT] via Connectline-CLMSortin 2.22 X-Gateway: ZConnect DA darkness.gun.de [Connectline/AmigaOS] To: amiga-gcc-port@nic.funet.fi Hi! I am not sure if this is a bug or a feature ... GNU C V2.6.3 1: int 2: main ( void ) 3: { 4: int a,b; 5: 6: a++; /* this line produces no warning */ 7: 8: ++b>>1; /* this line produces a warning! Why? */ 9: } > gcc -c -Wall test.c -o test test.c: In function `main': test.c:8: warning: value computed is not used > What is the difference between line 6 and line 8? c u DarkStar -- MicroDot 1.8 From amiga-gcc-port-owner@nic.funet.fi Sat Aug 26 20:37:31 1995 Received: from edina.xenologics.com ([194.77.5.1]) by nic.funet.fi with SMTP id <90641-3>; Sat, 26 Aug 1995 20:34:59 +0300 Received: from darkness.gun.de (root@localhost) by edina.xenologics.com (8.6.8.1/8.6.6) with UUCP id TAA14163 for nic.funet.fi!amiga-gcc-port; Sat, 26 Aug 1995 19:36:10 +0200 X-ZC-VIA: 19950826163331W+1@darkness.gun.de From: DarkStar@darkness.gun.de (Carsten Meyer) Subject: gcc overwrites sourcecodes Message-ID: Date: Sat, 26 Aug 95 12:28:02 CET Return-Receipt-To: DarkStar@darkness.gun.de (Carsten Meyer) Organization: CDC X-ZC-POST: Postfach 11 12;31596 Uchte X-Mailer: MicroDot 1.10 [UNREGISTRIERT] via Connectline-CLMSortin 2.22 X-Gateway: ZConnect DA darkness.gun.de [Connectline/AmigaOS] To: amiga-gcc-port@nic.funet.fi Hi! And now a very little one ... gcc test.c -o test.c will overwrite test.c without a warning. c u DarkStar -- MicroDot 1.8 From amiga-gcc-port-owner@nic.funet.fi Sun Aug 27 01:09:48 1995 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by nic.funet.fi with SMTP id <90412-4>; Sun, 27 Aug 1995 01:09:00 +0300 Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) id AAA23055; Sun, 27 Aug 1995 00:08:36 +0200 From: Thomas Radtke Message-Id: <199508262208.AAA23055@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: Bug: warning: value computed is not used. To: DarkStar@darkness.gun.de (Carsten Meyer) Date: Sun, 27 Aug 1995 00:08:35 +0200 (DFT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Carsten Meyer" at Aug 26, 95 12:22:55 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 654 > 1: int > 2: main ( void ) > 3: { > 4: int a,b; > 5: > 6: a++; /* this line produces no warning */ > 7: > 8: ++b>>1; /* this line produces a warning! Why? */ > 9: } > test.c:8: warning: value computed is not used > What is the difference between line 6 and line 8? without optimization, the ++ operator will be computed, but the shift operator is ignored, because it does not change the value of b. Ok, the warning text is misleading us. Better would be: warning: operator is not used and the real output should be applied to a++ and ++b. But this is not a real problem I think. Thomas From amiga-gcc-port-owner@nic.funet.fi Mon Aug 28 02:56:51 1995 Received: from nereid.rz.Uni-Osnabrueck.DE ([131.173.128.14]) by nic.funet.fi with SMTP id <90062-2>; Mon, 28 Aug 1995 02:52:36 +0300 Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) id BAA29472 for amiga-gcc-port@lists.funet.fi; Mon, 28 Aug 1995 01:52:23 +0200 From: Thomas Radtke Message-Id: <199508272352.BAA29472@nereid.rz.Uni-Osnabrueck.DE> Subject: FIONREAD To: amiga-gcc-port@nic.funet.fi Date: Mon, 28 Aug 1995 01:52:22 +0200 (DFT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 614 Hi, I have a problem with the ioctl() FIONREAD request. When I type in a key wich causes a CSI sequence (e.g. Arrow keys), that command (ioctl(fileno(stdin),FIONREAD,&n)) results in n=1. The character to be read is 0x9b, the CSI. But there is more in the buffer, e.g. 'A' for cursor up. This character is recognized when typing the next key. Example: type cursor up -> n=1,0x9b type 't' -> n=2,'A','t' Is this a bug, a missing feature or my fault ? This, btw, prevents GNU readline lib from working correctly (typing C-f and C-b only to move the cursor is no fun). Thomas From amiga-gcc-port-owner@nic.funet.fi Mon Aug 28 12:50:24 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90007-4>; Mon, 28 Aug 1995 12:45:13 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA02738; Mon, 28 Aug 1995 11:47:16 +0200 Date: Mon, 28 Aug 1995 11:47:15 +0200 (MET DST) From: Kamil Iskra Subject: New inlines To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII New version of fd2inline can be found on my WWW Home Page (see bottom of my posting for URL). Today I found a serious limitation of new inlines: they are not supported by g++, cause g++ does not support nested functions. Any ideas? The following has changed: - inlines generated from OS 3.1 FDs (thanks, Robert!). - Parameters of type "pointer to function" are now supported, including ANSI syntax (which brakes perl script). - Parameters of type "double" are now supported (inlines of "mathieeedoub*" functions can be generated correctly). - FDs without ##base (such as cia.resource) are now supported. - Prototypes without parameters' names are now supported (inlines of "powerpacker.library" functions can be generated correctly). - Name of preprocessor define "_INCLUDE_***_H" is now taken from fd-file name instead of ##base - more compatible with perl script. - Support for ##private/##public has been added. Drawback: warnings about missing prototypes of private functions are no longer generated. - No longer outputs "#under BASE_NAME" on the bottom of inline file. Still existing small limitations of fd2inline: - Vararg versions of functions whose last argument is not of type "struct TagItem*" are not generated. This applies to dos.library/FWritef, dos.library/FPrintf, dos.library/Printf, intuition.library/EasyRequest, intuition.library/BuildEasyRequest. Should be fixed soon. - "Second forms" of certain dos.library functions that have two names for the same call (!) are not generated. These are AllocDosObject[TagList], CreateNewProc[TagList], System[TagList], NewLoadSeg[TagList]. Should be fixed soon. - Program outputs to stderr messages about some functions that it cannot find (these are vararg-stub). This is minor problem, but it's rather complex so I'm not sure if it'll be fixed soon. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Aug 28 20:44:23 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90439-3>; Mon, 28 Aug 1995 20:37:59 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26480-1>; Mon, 28 Aug 1995 19:37:36 +0200 Received: by hphalle0.informatik.tu-muenchen.de id <209287-2>; Mon, 28 Aug 1995 19:37:29 +0100 Subject: Re: gcc overwrites sourcecodes From: Christian Stieber To: darkstar@darkness.gun.de (Carsten Meyer) Date: Mon, 28 Aug 1995 19:37:27 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Carsten Meyer" at Aug 26, 95 12:28:02 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 442 Message-Id: <95Aug28.193729+0100mesz.209287-2+377@hphalle0.informatik.tu-muenchen.de> > gcc test.c -o test.c > > will overwrite test.c without a warning. So what? You told it to do it. Most programs do not feel responsible for errors made by the user. > DarkStar Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Mon Aug 28 21:55:16 1995 Received: from linux.quebec.Berclain.com ([199.45.69.110]) by nic.funet.fi with SMTP id <90641-2>; Mon, 28 Aug 1995 21:52:54 +0300 Received: from legue.quebec.Berclain.com (legue.quebec.berclain.com [204.19.38.3]) by linux.quebec.Berclain.com (8.6.11/8.6.12) with ESMTP id PAA22668 for ; Mon, 28 Aug 1995 15:01:20 -0400 Received: from wntyp ([204.19.38.30]) by legue.quebec.Berclain.com (8.6.12/8.6.12) with SMTP id OAA23520 for ; Mon, 28 Aug 1995 14:58:21 -0400 Message-Id: <199508281858.OAA23520@legue.quebec.Berclain.com> X-Sender: yanickp@hp800.berclain.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 14:52:04 -0400 To: amiga-gcc-port@nic.funet.fi From: Yanick Pelletier Subject: mailing list? Hello, i try to subscribe to the gcc mailing list but this doesn't work! This is what i received: >> subscribe amiga-gcc-port Yanick Pelletier >No LISTSERV list by the name of "AMIGA-GCC-PORT" is known to exist. Note >that lists can be marked "confidential" and that the existence of such lists >is usually known only to the server that is actually hosting it. Can you help me? Please EMail me... Thanks! ------------------------------------------------------------------ Yanick Pelletier Berclain Group Inc. (R&D Group) E-mail: pelletiery@berclain.com 979, de Bourgogne (suite 220) Tel : (418) 656-0055 ext. 1735 Sainte-Foy (Quebec) Canada Fax : (418) 654-0645 G1W 2L4 From amiga-gcc-port-owner@nic.funet.fi Mon Aug 28 22:26:08 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <90345-3>; Mon, 28 Aug 1995 22:23:58 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id VAA10532 (8.6.10/2.4); Mon, 28 Aug 1995 21:24:26 +0200 Date: Mon, 28 Aug 1995 21:24:26 +0200 From: Olaf Seibert Message-Id: <199508281924.VAA10532@septimius.mbfys.kun.nl> To: Thomas.Radtke@rz.Uni-Osnabrueck.DE, amiga-gcc-port@nic.funet.fi Subject: Re: FIONREAD Thomas Radtke wrote: > I have a problem with the ioctl() FIONREAD request. When I > type in a key wich causes a CSI sequence (e.g. Arrow keys), > that command (ioctl(fileno(stdin),FIONREAD,&n)) results in > n=1. The character to be read is 0x9b, the CSI. But there is > more in the buffer, e.g. 'A' for cursor up. This character > is recognized when typing the next key. I *think* that FIONREAD is supposed to give a lower bound on the number of characters you can read() in one call without blocking. (I couldn't find any relevant man pages here, though). In this case, one should keep looping until FIONREAD indicates no immediately available characters. Though I suspect that in most implementations it works by giving a more exact number of readable characters. -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Mon Aug 28 23:52:52 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90925-3>; Mon, 28 Aug 1995 23:49:43 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0snBB6-0004nYC; Mon, 28 Aug 95 13:53 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: ixemul 41.3 released To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Mon, 28 Aug 1995 13:53:07 -0700 (MST) Cc: ixemul@listserv.funet.fi (ixemul.library maintainers) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3761 I just uploaded the source and binary archives for ixemul 41.3 to aminet (wuarchive.wustl.edu). Here is the readme file: ============================================================================ Short: IXemul.library 41.3 Author: various Uploader: fnf@amigalib.com Type: dev/gcc This is ixemul.library release 41.3, which represents a partial merging of features from various previous releases. Merging work is still underway, so expect future releases to occur at frequent intervals. Changes for this release include: Updated DBL_MIN and DBL_MAX in float.h to include one additional digit of precision. Enclose negative constants in parens to avoid unexpected conversion to subtraction via cpp macros. Applied patch from Hans Verkuil to fix serious bug in signal handling, to reset all signal handlers after an execve, except for those which are being ignored (SIG_IGN). Applied patch from joop van de wege to trap.s to set 68881 rounding mode back to truncation instead of "round to nearest", as required by the ANSI C standard which specifies truncation. Integrated ixtrace into source tree and arranged for it to be built and installed. Added "#include " to to be more compatible with most current systems that do this inclusion for you. This change should be backwards compatible with code that does the inclusion explicitly. Changed version string to be style guide compliant. Also arranged that version.o gets linked in, since it has the $VER: string and is otherwise unreferenced by any ixemul.library code. Merged patches from Hans Verkuil to fix execve environment passing, always open the console for stderr if no other file handle is provided, move AmigaDOS style filename matching into glob(), and fix a small problem with "open(NULL,...) that caused enforcer hits. The release consists of two archives, one for runtime files and one for the full source code: ixemul4103-bin.lha ixemul.library, *crt*.o, includes, libc.a, etc ixemul4103-src.lha Complete source code for ixemul library & utils The ixemul4103-bin.lha archive contains various readme and copyright files that do not need to be installed anywhere, and another archive "runtime.lha" that can be extracted relative to the gnu: directory to put all the files in their standard location. The runtime.lha file contains the following versions of the library: 129136 66815 48.2% 27-Aug-95 20:09:06 Sys/libs/ixemul.library 154140 75280 51.1% 27-Aug-95 20:09:40 Sys/libs/ixemul.trace 120824 64751 46.4% 27-Aug-95 23:51:32 Sys/libs/ixemul020.library 145792 73232 49.7% 27-Aug-95 23:52:06 Sys/libs/ixemul020.trace 118856 63975 46.1% 27-Aug-95 22:13:44 Sys/libs/ixemul020fpu.library 143824 72373 49.6% 27-Aug-95 22:14:18 Sys/libs/ixemul020fpu.trace 121848 65175 46.5% 28-Aug-95 03:10:08 Sys/libs/ixemul030.library 146816 73706 49.7% 28-Aug-95 03:10:44 Sys/libs/ixemul030.trace 119880 64425 46.2% 28-Aug-95 01:31:00 Sys/libs/ixemul030fpu.library 144848 72844 49.7% 28-Aug-95 01:31:32 Sys/libs/ixemul030fpu.trace 121848 65175 46.5% 28-Aug-95 06:33:00 Sys/libs/ixemul040.library 146816 73706 49.7% 28-Aug-95 06:33:36 Sys/libs/ixemul040.trace 120268 64381 46.4% 28-Aug-95 04:50:48 Sys/libs/ixemul040fpu.library 145236 72843 49.8% 28-Aug-95 04:51:24 Sys/libs/ixemul040fpu.trace The ixemul4103-src.lha archive contains all the source, relative to a directory "ixemul-41.3". For additional information, see the NEWS, INSTALL, README and TODO files. -Fred Fish (fnf@amigalib.com) ============================================================================ From amiga-gcc-port-owner@nic.funet.fi Tue Aug 29 12:41:24 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90471-2>; Tue, 29 Aug 1995 12:35:19 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 29 Aug 95 11:34 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 29 Aug 95 11:30 MET DST Message-Id: Subject: FIONREAD To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 29 Aug 1995 11:29:57 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 660 I found this as (file-)flags for icctl() FIOCLEX - set exclusive user FIONCLEX - unset % FIOBIO - un/set nonblocking I/O FIOASYNC - un/set async I/O FIONREAD - get number of bytes to read FIOSETOWN - set owner FIOGETOWN - get owner What is implemented via ixemul ? FRED: i had some problems with signals (long ago), because it seem to be fixed in 41.3 what signals are working now ? walter -- ----- "Nobody would have the gumption to tell the captain of the U.S.S. Enterprise he couldn't have his doctor, his dentist, his favorite carpenter, or his dog groomer at his side if he wanted to, security clearance or not." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 12:43:55 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90732-4>; Wed, 30 Aug 1995 12:38:21 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA12688; Wed, 30 Aug 1995 11:39:28 +0200 Date: Wed, 30 Aug 1995 11:39:27 +0200 (MET DST) From: Kamil Iskra Subject: Bug in scope of variables defined in "if" To: bug-g++@prep.ai.mit.edu cc: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear G++ developers, I use GCC 2.7.0 on Amiga (mc68020-cbm-amigados). I have also tested the source supplied below on Sparc (sparc-sun-sunos4.1.3), with the same results. I think the compiler does not produce an error for invalid input. According to C++ Working Paper (from 28 April 1995): "6.4 Selection statements [...] 3 A name introduced by a declaration in a condition is in scope from its point of declaration until the end of the substatements controlled by the condition. If the name is re-declared in the outermost block of a substatement controlled by the condition, the declaration that re- declares the name is ill-formed." Please have a look at this little source: 1 int func() 2 { 3 return 0; 4 } 5 6 int main() 7 { 8 if (int i=func()) 9 int i=5; 10 // else 11 // int b=8; 12 i++; 13 } As far as I understand the above quoted Working Paper, this source should cause g++ to output two error messages: 1. In line 9 "i" is redeclared "in the outermost block of a substatement controlled by the condition". 2. In line 12 "i" is used, while its scope finishes in line 9 (at "the end of the substatements controlled by the condition"). Verbose output from the compiler (g++ -g -v -S test.cxx): gcc -g -v -S test.cxx Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc680 00 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -g -Dmc68010 test.cxx /t/cc262680.ii GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/lib/g++-include /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cc1plus /t/cc262680.ii -mfixedstack -mfixedstack -quiet -dumpbase test.cc -g -version -o test.s GNU C++ version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. Generated assembler source (g++ -g -S test.cxx): #NO_APP gcc2_compiled.: ___gnu_compiled_cplusplus: .stabs "/Ram Disk/",100,0,0,Ltext0 .stabs "test.cxx",100,0,0,Ltext0 .text Ltext0: .stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0 .stabs "char:t2=r2;0;127;",128,0,0,0 .stabs "long int:t3=r1;-2147483648;2147483647;",128,0,0,0 .stabs "unsigned int:t4=r1;0;-1;",128,0,0,0 .stabs "long unsigned int:t5=r1;0;-1;",128,0,0,0 .stabs "long long int:t6=r1;01000000000000000000000;0777777777777777777777;",128,0,0,0 .stabs "long long unsigned int:t7=r1;0000000000000;01777777777777777777777;",128,0,0,0 .stabs "short int:t8=r1;-32768;32767;",128,0,0,0 .stabs "short unsigned int:t9=r1;0;65535;",128,0,0,0 .stabs "signed char:t10=r1;-128;127;",128,0,0,0 .stabs "unsigned char:t11=r1;0;255;",128,0,0,0 .stabs "float:t12=r1;4;0;",128,0,0,0 .stabs "double:t13=r1;8;0;",128,0,0,0 .stabs "long double:t14=r1;8;0;",128,0,0,0 .stabs "bool:t15=@s32;-16;",128,0,0,0 .stabs "void:t16=16",128,0,0,0 .stabs "__wchar_t:t17=r1;-2147483648;2147483647;",128,0,0,0 .stabs "__vtbl_ptr_type:T18=s8__delta:8,0,16;__index:8,16,16;\\",128,0,0,0 .stabs "__pfn:19=*16,32,32;__delta2:8,32,16;;",128,0,0,0 .stabs "__vtbl_ptr_type:t18",128,0,0,0 .even .globl _func__Fv _func__Fv: .stabd 68,0,2 link a5,#0 .stabd 68,0,2 LBB2: .stabd 68,0,3 moveq #0,d0 jra L1 jra L1 LBE2: jra L2 jra L1 L2: .stabd 68,0,4 L1: unlk a5 rts .stabs "func__Fv:F1",36,0,2,_func__Fv .stabn 192,0,0,LBB2 .stabn 224,0,0,LBE2 .even .globl _main _main: .stabd 68,0,7 link a5,#-8 jbsr ___main .stabd 68,0,7 LBB3: .stabd 68,0,8 LBB4: jbsr _func__Fv movel d0,a5@(-4) tstl a5@(-4) jeq L4 .stabd 68,0,9 LBB5: moveq #5,d1 movel d1,a5@(-8) LBE5: L4: LBE4: .stabd 68,0,12 addql #1,a5@(-4) LBE3: moveq #0,d0 jra L3 jra L3 .stabd 68,0,13 L3: unlk a5 rts .stabs "main:F1",36,0,7,_main .stabn 192,0,0,LBB3 .stabs "i:1",128,0,8,-4 .stabn 192,0,0,LBB4 .stabs "i:1",128,0,9,-8 .stabn 192,0,0,LBB5 .stabn 224,0,0,LBE5 .stabn 224,0,0,LBE4 .stabn 224,0,0,LBE3 If you uncomment lines 10 and 11, compiler will generate an error message for line 12: test.cxx: In function `int main()': test.cxx:12: `i' undeclared (first use this function) test.cxx:12: (Each undeclared identifier is reported only once test.cxx:12: for each function it appears in.) / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html/index.html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 12:50:16 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90420-4>; Wed, 30 Aug 1995 12:49:52 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug30.124952+0300_eet_dst.90420-4+18@nic.funet.fi> From: To: Date: Wed, 30 Aug 1995 12:49:51 +0300 Date: Wed, 30 Aug 1995 11:48:10 +0200 (METDST) From: Rask Lambertsen To: Gunther Nikl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ixemul and "*" for Open() In-Reply-To: <199508221035.MAA00132@honshu.informatik.uni-rostock.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 22 Aug 1995, Gunther Nikl wrote: > > Actually, the real reason is laziness. No one ever thought it > > important enough to fix. > ^^^^^^^^^ > > Its *absolutely* not important to switch from "*" to "CONSOLE:". > Since Open() will never deal with wildcards there is NO advantage > to to so. Support for "*" can't removed since this would break > a lot of programs. It is not wildcards that is the problem. As I showed in my mail on Monday 21st, it is possible to use files named "*" if the program opening "*" does not have a CLI structure attached. That is what I find dangerous. Since the use of "*" has been declared obsolete as of V36, and ixemul doesn't work on anything less, there is no reason not to switch to "CONSOLE:". > > Rask, just fix it and mail a patch to Fred Fish. I will, since nobody else wants to. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 13:17:35 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90177-2>; Wed, 30 Aug 1995 13:16:40 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug30.131640+0300_eet_dst.90177-2+20@nic.funet.fi> From: To: Date: Wed, 30 Aug 1995 13:16:38 +0300 Date: Wed, 30 Aug 1995 12:15:05 +0200 (METDST) From: Rask Lambertsen To: Kamil Iskra Cc: Amiga GCC List Subject: Re: New inlines In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 23 Aug 1995, Kamil Iskra wrote: > They have been created using "C" program "fd2inline", from OS 3.0 > fd-files (sorry, I simply don't have OS 3.1 ones. Are they available > somewhere in the Internet?). Yes: ftp://ftp.dfv.rwth-aachen.de/cdrom/bbs/cbm/nduk-v40.lha You also get all the OS 3.1 includes :-) Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 13:29:04 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90930-4>; Wed, 30 Aug 1995 13:28:22 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug30.132822+0300_eet_dst.90930-4+19@nic.funet.fi> From: To: Date: Wed, 30 Aug 1995 13:28:18 +0300 Date: Wed, 30 Aug 1995 12:26:40 +0200 (METDST) From: Rask Lambertsen To: joop van de wege Cc: gnikl@informatik.uni-rostock.de, amiga-gcc-port@nic.funet.fi Subject: Re: ixemul bug + solution. (LONG) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 23 Aug 1995, joop van de wege wrote: > >> Lreset_fpu: > >> clrl sp@- > >> frestore sp@+ > >> rte > >> > >> Lafter_reset_fpu: > >> moveml sp@+,a5/a6 > >> rts > >> -------------------- end of resetfpu --------------- > > > > The above code will break on a mc68060 since it has a larger > > frame for frestore ... > > Gunther > > Ha, a new real life bug. This should be fixed ASAP since I'm planning to buy > one of those 060 beasties. Why not just stop caching the math library bases? It is invalid anyway, so it is the right thing to do. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 14:54:59 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90240-1>; Wed, 30 Aug 1995 14:53:45 +0300 Received: by ceylon.informatik.uni-rostock.de id NAA12337; Wed, 30 Aug 1995 13:53:34 +0200 Received: by honshu.informatik.uni-rostock.de id NAA22354; Wed, 30 Aug 1995 13:53:34 +0200 From: Gunther Nikl Message-Id: <199508301153.NAA22354@honshu.informatik.uni-rostock.de> Subject: Re: ixemul and "*" for Open() To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Wed, 30 Aug 1995 13:53:33 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Aug 30, 95 11:48:10 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 610 > It is not wildcards that is the problem. As I showed in my mail on > Monday 21st, it is possible to use files named "*" if the program opening > "*" does not have a CLI structure attached. That is what I find dangerous. I am sorry to say, but finding problems where no problems are is simply *silly*, even if its possible to create a file named "*". If somebody creates such a file, then he shall deal with it. Its *not* possible to create such a file by accident. > > > Rask, just fix it and mail a patch to Fred Fish. > > I will, since nobody else wants to. Nothing better to do? Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 15:13:46 1995 Received: by nic.funet.fi id <90606-2>; Wed, 30 Aug 1995 15:12:57 +0300 From: Leonard Norrgard To: Joop.vandeWege@MEDEW.ENTO.WAU.NL CC: amiga-gcc-port@lists.funet.fi In-reply-to: (Joop.vandeWege@MEDEW.ENTO.WAU.NL) Subject: Re: GCC &G Message-Id: <95Aug30.151257+0300_eet_dst.90606-2+2@nic.funet.fi> Date: Wed, 30 Aug 1995 15:12:50 +0300 What version of ixemul.library are you using with Ghostscript? From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 15:39:30 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90118-4>; Wed, 30 Aug 1995 15:38:27 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug30.153827+0300_eet_dst.90118-4+8@nic.funet.fi> From: To: Date: Wed, 30 Aug 1995 15:38:25 +0300 Date: Wed, 30 Aug 1995 14:36:41 +0200 (METDST) From: Rask Lambertsen To: Gunther Nikl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ixemul and "*" for Open() In-Reply-To: <199508301153.NAA22354@honshu.informatik.uni-rostock.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 30 Aug 1995, Gunther Nikl wrote: > > It is not wildcards that is the problem. As I showed in my mail on > > Monday 21st, it is possible to use files named "*" if the program opening > > "*" does not have a CLI structure attached. That is what I find dangerous. > > I am sorry to say, but finding problems where no problems are is simply > *silly*, even if its possible to create a file named "*". If somebody Using an obsolete feature with no gain in comparison to a new feature that does the same is silly. > creates such a file, then he shall deal with it. Its *not* possible to > create such a file by accident. How is the end user supposed to know that ixemul opens "*"? > > > > Rask, just fix it and mail a patch to Fred Fish. > > > > I will, since nobody else wants to. > > Nothing better to do? It is better than being lazy and keep using an obsolete freature just to save 7 bytes, isn't it? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 17:26:37 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90420-2>; Wed, 30 Aug 1995 17:24:50 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 30 Aug 95 16:19 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 30 Aug 95 16:17 MET DST Message-Id: Subject: Re: ixemul and "*" for Open() To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 30 Aug 1995 16:17:51 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 861 > > > It is not wildcards that is the problem. As I showed in my mail on > > Monday 21st, it is possible to use files named "*" if the program opening > > "*" does not have a CLI structure attached. That is what I find dangerous. > > I am sorry to say, but finding problems where no problems are is simply > *silly*, even if its possible to create a file named "*". If somebody > creates such a file, then he shall deal with it. Its *not* possible to > create such a file by accident. > *ARH*, it is easy, just take a look at vuepad on the local hp-sytem here, sometime he loses the filename, and creates random strings instad with a lot of non/printabel chars. on the other hand when the user exspects filenameexpansion the creation of "*" is possible and dangerous. walter -- ----- Old Vulcan proverb:only Nixon could go to China ----- From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 18:06:15 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90681-1>; Wed, 30 Aug 1995 18:05:28 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug30.180528+0300_eet_dst.90681-1+35@nic.funet.fi> From: To: Date: Wed, 30 Aug 1995 18:05:20 +0300 Date: Wed, 30 Aug 1995 17:04:03 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Errors in AmigaGuide documentation Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have found some problems with the AmigaGuide files that come with GCC 2.6.3 and I think the ones with GCC 2.7.0 could suffer from the same problems (I haven't downloaded these yet). The .guide files refer to .info files in links and node names. Here is what needs to be changed in gcc.guide, I'll post diffs for the other .guide files: Line 843: @{"C and C++" Link "gdb.info/C"}). Change to @{"C and C++" Link "gdb.guide/C"}). Line 1479: compilers. See @{"Standard Predefined Macros" Link "cpp.info/Standard Predefined"}, for more discussion of Change to compilers. See @{"Standard Predefined Macros" Link "cpp.guide/Standard Predefined"}, for more discussion of Line 4501: the linker option `-relax'. See @{"`ld' and the H8/300" Link "ld.info/H8-300"}, for a fuller Change to the linker option `-relax'. See @{"`ld' and the H8/300" Link "ld.guide/H8-300"}, for a fuller Line 9107: @{"Standard Predefined Macros" Link "cpp.info/Standard Predefined"}). Change to @{"Standard Predefined Macros" Link "cpp.guide/Standard Predefined"}). I'm sorry that I have to post this hand-made diff, I just don't have enough RAM for diff to work on gcc.guide :-(. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 18:07:24 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90885-3>; Wed, 30 Aug 1995 18:07:02 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug30.180702+0300_eet_dst.90885-3+15@nic.funet.fi> From: To: Date: Wed, 30 Aug 1995 18:07:00 +0300 Date: Wed, 30 Aug 1995 17:05:43 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Diff for GNU:guide/make.guide Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Diff for GNU:guide/make.guide I don't have enough memory for a context diff :-( 2338c2338 < @{"Options Controlling the Preprocessor" Link "gcc.info/Preprocessor Options"}, for details. --- > @{"Options Controlling the Preprocessor" Link "gcc.guide/Preprocessor Options"}, for details. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 18:09:19 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90358-1>; Wed, 30 Aug 1995 18:08:40 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug30.180840+0300_eet_dst.90358-1+37@nic.funet.fi> From: To: Date: Wed, 30 Aug 1995 18:08:31 +0300 Date: Wed, 30 Aug 1995 17:07:09 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Diff -2u for GNU:guide/flex.guide Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Diff -2u for GNU:guide/flex.guide --- guide/flex.guide Tue Jul 26 23:22:30 1994 +++ guide-new/flex.guide Thu Apr 13 20:13:42 1995 @@ -39,5 +39,5 @@ @EndNode -@Node "Introduction" "flex.info/Introduction" +@Node "Introduction" "flex.guide/Introduction" @Next "Files" @Prev "Main" @@ -68,5 +68,5 @@ @EndNode -@Node "Text-Substitution" "flex.info/Text-Substitution" +@Node "Text-Substitution" "flex.guide/Text-Substitution" @Next "Counter" @Toc "Introduction" @@ -91,5 +91,5 @@ @EndNode -@Node "Counter" "flex.info/Counter" +@Node "Counter" "flex.guide/Counter" @Next "Toy" @Prev "Text-Substitution" @@ -127,5 +127,5 @@ @EndNode -@Node "Toy" "flex.info/Toy" +@Node "Toy" "flex.guide/Toy" @Prev "Counter" @Toc "Introduction" @@ -196,5 +196,5 @@ @EndNode -@Node "Files" "flex.info/Files" +@Node "Files" "flex.guide/Files" @Next "Invoking" @Prev "Introduction" @@ -224,5 +224,5 @@ @EndNode -@Node "Input Format" "flex.info/Input Format" +@Node "Input Format" "flex.guide/Input Format" @Next "Scanner" @Toc "Files" @@ -314,5 +314,5 @@ @EndNode -@Node "Patterns" "flex.info/Patterns" +@Node "Patterns" "flex.guide/Patterns" @Next "Matching" @Toc "Input Format" @@ -479,5 +479,5 @@ @EndNode -@Node "Matching" "flex.info/Matching" +@Node "Matching" "flex.guide/Matching" @Next "Actions" @Prev "Patterns" @@ -514,5 +514,5 @@ @EndNode -@Node "Actions" "flex.info/Actions" +@Node "Actions" "flex.guide/Actions" @Prev "Matching" @Toc "Input Format" @@ -709,5 +709,5 @@ @EndNode -@Node "Scanner" "flex.info/Scanner" +@Node "Scanner" "flex.guide/Scanner" @Next "Start" @Prev "Input Format" @@ -797,5 +797,5 @@ @EndNode -@Node "Start" "flex.info/Start" +@Node "Start" "flex.guide/Start" @Next "Multiple Input" @Prev "Scanner" @@ -961,5 +961,5 @@ @EndNode -@Node "Multiple Input" "flex.info/Multiple Input" +@Node "Multiple Input" "flex.guide/Multiple Input" @Next "EOF" @Prev "Start" @@ -1063,5 +1063,5 @@ @EndNode -@Node "EOF" "flex.info/EOF" +@Node "EOF" "flex.guide/EOF" @Next "Misc" @Prev "Multiple Input" @@ -1119,5 +1119,5 @@ @EndNode -@Node "Misc" "flex.info/Misc" +@Node "Misc" "flex.guide/Misc" @Next "Parsers" @Prev "EOF" @@ -1149,5 +1149,5 @@ @EndNode -@Node "Parsers" "flex.info/Parsers" +@Node "Parsers" "flex.guide/Parsers" @Next "Translation" @Prev "Misc" @@ -1178,5 +1178,5 @@ @EndNode -@Node "Translation" "flex.info/Translation" +@Node "Translation" "flex.guide/Translation" @Prev "Parsers" @Toc "Files" @@ -1215,5 +1215,5 @@ @EndNode -@Node "Invoking" "flex.info/Invoking" +@Node "Invoking" "flex.guide/Invoking" @Next "Performance" @Prev "Files" @@ -1449,5 +1449,5 @@ @EndNode -@Node "Performance" "flex.info/Performance" +@Node "Performance" "flex.guide/Performance" @Next "Incompatibilities" @Prev "Invoking" @@ -1702,5 +1702,5 @@ @EndNode -@Node "Incompatibilities" "flex.info/Incompatibilities" +@Node "Incompatibilities" "flex.guide/Incompatibilities" @Next "Diagnostics" @Prev "Performance" @@ -1885,5 +1885,5 @@ @EndNode -@Node "Diagnostics" "flex.info/Diagnostics" +@Node "Diagnostics" "flex.guide/Diagnostics" @Next "Bugs" @Prev "Incompatibilities" @@ -1936,5 +1936,5 @@ @EndNode -@Node "Bugs" "flex.info/Bugs" +@Node "Bugs" "flex.guide/Bugs" @Next "Acknowledgements" @Prev "Diagnostics" @@ -1999,5 +1999,5 @@ @EndNode -@Node "Acknowledgements" "flex.info/Acknowledgements" +@Node "Acknowledgements" "flex.guide/Acknowledgements" @Prev "Bugs" @Toc "Main" Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 18:10:24 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90785-1>; Wed, 30 Aug 1995 18:09:59 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug30.180959+0300_eet_dst.90785-1+38@nic.funet.fi> From: To: Date: Wed, 30 Aug 1995 18:09:48 +0300 Date: Wed, 30 Aug 1995 17:08:31 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: diff -2u for GNU:guide/libg++.guide Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII diff -2u for GNU:guide/libg++.guide --- guide/libg++.guide Sat Nov 5 00:29:08 1994 +++ guide-new/libg++.guide Thu Apr 13 20:12:07 1995 @@ -2070,5 +2070,5 @@ operations in support of regular expression searching, matching, and the like. The Regex class is based entirely on the GNU Emacs regex -functions. See @{"Syntax of Regular Expressions" Link "emacs.info/Regexps"}, for a full explanation +functions. See @{"Syntax of Regular Expressions" Link "emacs.guide/Regexps"}, for a full explanation of regular expression syntax. (For implementation details, see the internal documentation in files `regex.h' and `regex.c'.) Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 18:12:59 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90907-3>; Wed, 30 Aug 1995 18:12:30 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug30.181230+0300_eet_dst.90907-3+16@nic.funet.fi> From: To: Date: Wed, 30 Aug 1995 18:12:25 +0300 Date: Wed, 30 Aug 1995 17:11:08 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: diff -2u for GNU:guide/libnix.guide Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII diff -2u for GNU:guide/libnix.guide --- guide/libnix.guide Mon Jun 5 16:43:46 1995 +++ guide-new/libnix.guide Thu Apr 13 20:15:09 1995 @@ -37,5 +37,5 @@ @EndNode -@Node "Description" "libnix.info/Description" +@Node "Description" "libnix.guide/Description" @Next "Motivation" @Prev "Main" @@ -72,5 +72,5 @@ @EndNode -@Node "Motivation" "libnix.info/Motivation" +@Node "Motivation" "libnix.guide/Motivation" @Next "Authors" @Prev "Description" @@ -105,5 +105,5 @@ @EndNode -@Node "Authors" "libnix.info/Authors" +@Node "Authors" "libnix.guide/Authors" @Next "Disclaimer" @Prev "Motivation" @@ -132,5 +132,5 @@ @EndNode -@Node "Disclaimer" "libnix.info/Disclaimer" +@Node "Disclaimer" "libnix.guide/Disclaimer" @Next "Naming" @Prev "Authors" @@ -150,5 +150,5 @@ @EndNode -@Node "Naming" "libnix.info/Naming" +@Node "Naming" "libnix.guide/Naming" @Next "Usage" @Prev "Disclaimer" @@ -182,5 +182,5 @@ @EndNode -@Node "Usage" "libnix.info/Usage" +@Node "Usage" "libnix.guide/Usage" @Next "Features" @Prev "Naming" @@ -242,5 +242,5 @@ @EndNode -@Node "Features" "libnix.info/Features" +@Node "Features" "libnix.guide/Features" @Next "Set elements" @Prev "Usage" @@ -267,5 +267,5 @@ @EndNode -@Node "Startup codes" "libnix.info/Startup codes" +@Node "Startup codes" "libnix.guide/Startup codes" @Next "Commandline parser" @Prev "Features" @@ -335,5 +335,5 @@ @EndNode -@Node "Startup interface" "libnix.info/Startup interface" +@Node "Startup interface" "libnix.guide/Startup interface" @Next "Startup usage" @Prev "Startup codes" @@ -396,5 +396,5 @@ @EndNode -@Node "Startup usage" "libnix.info/Startup usage" +@Node "Startup usage" "libnix.guide/Startup usage" @Prev "Startup interface" @Toc "Startup codes" @@ -432,5 +432,5 @@ @EndNode -@Node "Commandline parser" "libnix.info/Commandline parser" +@Node "Commandline parser" "libnix.guide/Commandline parser" @Next "libnix.a" @Prev "Startup codes" @@ -483,5 +483,5 @@ @EndNode -@Node "libnix.a" "libnix.info/libnix.a" +@Node "libnix.a" "libnix.guide/libnix.a" @Next "libamiga.a" @Prev "Commandline parser" @@ -519,5 +519,5 @@ @EndNode -@Node "Locale" "libnix.info/Locale" +@Node "Locale" "libnix.guide/Locale" @Next "Formatted I-O" @Prev "libnix.a" @@ -569,5 +569,5 @@ @EndNode -@Node "Formatted I-O" "libnix.info/Formatted I-O" +@Node "Formatted I-O" "libnix.guide/Formatted I-O" @Next "atof strtod" @Prev "Locale" @@ -596,5 +596,5 @@ @EndNode -@Node "atof strtod" "libnix.info/atof strtod" +@Node "atof strtod" "libnix.guide/atof strtod" @Next "Memory management" @Prev "Formatted I-O" @@ -612,5 +612,5 @@ @EndNode -@Node "Memory management" "libnix.info/Memory management" +@Node "Memory management" "libnix.guide/Memory management" @Next "Standard I-O" @Prev "atof strtod" @@ -647,5 +647,5 @@ @EndNode -@Node "Standard I-O" "libnix.info/Standard I-O" +@Node "Standard I-O" "libnix.guide/Standard I-O" @Next "Signal handling" @Prev "Memory management" @@ -682,5 +682,5 @@ @EndNode -@Node "Signal handling" "libnix.info/Signal handling" +@Node "Signal handling" "libnix.guide/Signal handling" @Next "setjmp longjmp" @Prev "Standard I-O" @@ -733,5 +733,5 @@ @EndNode -@Node "setjmp longjmp" "libnix.info/setjmp longjmp" +@Node "setjmp longjmp" "libnix.guide/setjmp longjmp" @Next "ctype" @Prev "Signal handling" @@ -750,5 +750,5 @@ @EndNode -@Node "ctype" "libnix.info/ctype" +@Node "ctype" "libnix.guide/ctype" @Next "clock" @Prev "setjmp longjmp" @@ -768,5 +768,5 @@ @EndNode -@Node "clock" "libnix.info/clock" +@Node "clock" "libnix.guide/clock" @Next "Multibyte character functions" @Prev "ctype" @@ -784,5 +784,5 @@ @EndNode -@Node "Multibyte character functions" "libnix.info/Multibyte character functions" +@Node "Multibyte character functions" "libnix.guide/Multibyte character functions" @Prev "clock" @Toc "libnix.a" @@ -798,5 +798,5 @@ @EndNode -@Node "libstubs.a" "libnix.info/libstubs.a" +@Node "libstubs.a" "libnix.guide/libstubs.a" @Prev "libamiga.a" @Toc "Features" @@ -829,5 +829,5 @@ @EndNode -@Node "Auto-library-opening usage" "libnix.info/Auto-library-opening usage" +@Node "Auto-library-opening usage" "libnix.guide/Auto-library-opening usage" @Next "Auto-library-opening interface" @Prev "libstubs.a" @@ -849,5 +849,5 @@ @EndNode -@Node "Auto-library-opening interface" "libnix.info/Auto-library-opening interface" +@Node "Auto-library-opening interface" "libnix.guide/Auto-library-opening interface" @Prev "Auto-library-opening usage" @Toc "libstubs.a" @@ -930,5 +930,5 @@ @EndNode -@Node "Set elements" "libnix.info/Set elements" +@Node "Set elements" "libnix.guide/Set elements" @Next "geta4" @Prev "Features" @@ -973,5 +973,5 @@ @EndNode -@Node "geta4" "libnix.info/geta4" +@Node "geta4" "libnix.guide/geta4" @Next "Library bases" @Prev "Set elements" @@ -1027,5 +1027,5 @@ @EndNode -@Node "Data models" "libnix.info/Data models" +@Node "Data models" "libnix.guide/Data models" @Next "Code models" @Prev "geta4" @@ -1127,5 +1127,5 @@ @EndNode -@Node "Code models" "libnix.info/Code models" +@Node "Code models" "libnix.guide/Code models" @Prev "Data models" @Toc "geta4" @@ -1157,5 +1157,5 @@ @EndNode -@Node "Library bases" "libnix.info/Library bases" +@Node "Library bases" "libnix.guide/Library bases" @Next "FAQs" @Prev "geta4" @@ -1202,5 +1202,5 @@ @EndNode -@Node "libamiga.a" "libnix.info/libamiga.a" +@Node "libamiga.a" "libnix.guide/libamiga.a" @Next "libstubs.a" @Prev "libnix.a" @@ -1253,5 +1253,5 @@ @EndNode -@Node "FAQs" "libnix.info/FAQs" +@Node "FAQs" "libnix.guide/FAQs" @Prev "Library bases" @Toc "Main" Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 18:13:52 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90345-3>; Wed, 30 Aug 1995 18:13:37 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug30.181337+0300_eet_dst.90345-3+17@nic.funet.fi> From: To: Date: Wed, 30 Aug 1995 18:13:37 +0300 Date: Wed, 30 Aug 1995 17:12:20 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: diff -2u for GNU:guide/gasp.guide Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII diff -2u for GNU:guide/gasp.guide --- guide/gasp.guide Mon Jun 5 16:44:20 1995 +++ guide-new/gasp.guide Thu Apr 13 20:17:53 1995 @@ -666,5 +666,5 @@ `.PRINT NOLIST' Print control. This directive emits the GNU `as' directive - `.list' or `.nolist', according to its argument. See @{"`.list'" Link "as.info/List"}, for + `.list' or `.nolist', according to its argument. See @{"`.list'" Link "as.guide/List"}, for details on how these directives interact. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 18:16:38 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90064-3>; Wed, 30 Aug 1995 18:16:13 +0300 Received: by lorenz.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Aug30.181613+0300_eet_dst.90064-3+18@nic.funet.fi> From: To: Date: Wed, 30 Aug 1995 18:16:07 +0300 Date: Wed, 30 Aug 1995 17:14:50 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Lousy code quality Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, I have been experimeting with inline C versions of strlen(), strcpy() and strcat() to replace my assembly functions, hoping that GCC would make just as good code as I did. Well, strlen was no problem, but strcpy() and strcat() gave very disappointing results (prerelease from Aug 21st): __inline__ char *strcpy (char *dest, const char *src) { char *res = dest; while (*dest ++ = *src ++) ; return (res); } gives (compiled for '000, -O3): *00.0000001c _strcpy: 00.0000001c 226f 0008 MOVEA.L 0008(A7),A1 00.00000020 222f 0004 MOVE.L 0004(A7),D1 00.00000024 1019 MOVE.B (A1)+,D0 00.00000026 2041 MOVEA.L D1,A0 00.00000028 6002 BRA.B 0000002c 00.0000002a 1019 MOVE.B (A1)+,D0 00.0000002c 10c0 MOVE.B D0,(A0)+ 00.0000002e 66fa BNE.B 0000002a 00.00000030 2001 MOVE.L D1,D0 00.00000032 4e75 RTS 00.00000034 4e71 NOP Here is an equivalent version, that strangely gives slightly better code: __inline__ char *strcpy2 (char *dest, const char *src) { char *res = dest; do ; while (*dest ++ = *src ++); return (res); } *00.00000036 _strcpy2: 00.00000036 206f 0004 MOVEA.L 0004(A7),A0 00.0000003a 226f 0008 MOVEA.L 0008(A7),A1 00.0000003e 2208 MOVE.L A0,D1 00.00000040 1019 MOVE.B (A1)+,D0 00.00000042 10c0 MOVE.B D0,(A0)+ 00.00000044 66fa BNE.B 00000040 00.00000046 2001 MOVE.L D1,D0 00.00000048 4e75 RTS 00.0000004a 4e71 NOP But that is still lousy code, it should have been _strcpy: movea.l 4(sp),a0 movea.l 8(sp),a1 move.l a0,d0 loop: move.b (a1)+,(a0)+ bne.b loop rts It looks to me like the compiler doesn't realize that 'move.b (a1)+,(a0)+' updates the condition codes. Or maybe it doesn't know about that instruction at all. I have a very similar problem with strcat(). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 18:55:59 1995 Received: from linux.quebec.Berclain.com ([199.45.69.110]) by nic.funet.fi with SMTP id <90048-2>; Wed, 30 Aug 1995 18:55:01 +0300 Received: from legue.quebec.Berclain.com (legue.quebec.berclain.com [204.19.38.3]) by linux.quebec.Berclain.com (8.6.11/8.6.12) with ESMTP id MAA31500 for ; Wed, 30 Aug 1995 12:05:18 -0400 Received: from wntyp ([204.19.38.30]) by legue.quebec.Berclain.com (8.6.12/8.6.12) with SMTP id MAA00512 for ; Wed, 30 Aug 1995 12:00:10 -0400 Message-Id: <199508301600.MAA00512@legue.quebec.Berclain.com> X-Sender: yanickp@hp800.berclain.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Aug 1995 11:53:48 -0400 To: amiga-gcc-port@nic.funet.fi From: Yanick Pelletier Subject: g++ v2.7.0 bug? Yesterday i have install new version of gcc 2.7.0 and wrote i small program like: #include main () { printf("Hello wolrd\n"); } I compile it with: gcc -o hello hello.c this work fine, but when i compile it with g++ to: g++ -o hello hello.c This doesn't work, i received this error message ld: malformated input file (no rel or archive) /gnu/lib/libstdc++.a(__SYMDEF) Does any body know what i must do to solve this bug (it work with g++2.6.3) and i have get the archive gcc270-*.lha two days ago. Tanks. ------------------------------------------------------------------ Yanick Pelletier Berclain Group Inc. (R&D Group) E-mail: pelletiery@berclain.com 979, de Bourgogne (suite 220) Tel : (418) 656-0055 ext. 1735 Sainte-Foy (Quebec) Canada Fax : (418) 654-0645 G1W 2L4 From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 19:11:46 1995 Received: from linux.quebec.Berclain.com ([199.45.69.110]) by nic.funet.fi with SMTP id <90304-3>; Wed, 30 Aug 1995 19:10:53 +0300 Received: from legue.quebec.Berclain.com (legue.quebec.berclain.com [204.19.38.3]) by linux.quebec.Berclain.com (8.6.11/8.6.12) with ESMTP id MAA31567 for ; Wed, 30 Aug 1995 12:21:18 -0400 Received: from wntyp ([204.19.38.30]) by legue.quebec.Berclain.com (8.6.12/8.6.12) with SMTP id MAA00600 for ; Wed, 30 Aug 1995 12:16:10 -0400 Message-Id: <199508301616.MAA00600@legue.quebec.Berclain.com> X-Sender: yanickp@hp800.berclain.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Aug 1995 12:09:47 -0400 To: amiga-gcc-port@nic.funet.fi From: Yanick Pelletier Subject: code size! Hello! I have another problem with my hello world programme (it's dummy!) to check the size of the code generate by gcc and g++ i wrote two small program: (1) #include main() { printf("Hello world\n); } compiled with: gcc -o hello hello.c The executable generate by gcc have about 2K (its ok). (2) #include main() { cout << "Hello world" << endl; } compiled with: g++ -o hello2 hello2.cpp The executable generate by g++ have about 64K!!! What is that? It's a joke? Since the two program made the same think it must be the same size (it's the case on some other compilator)... Can i change something when a compile the case 2 to get a much smaller code!? ------------------------------------------------------------------ Yanick Pelletier Berclain Group Inc. (R&D Group) E-mail: pelletiery@berclain.com 979, de Bourgogne (suite 220) Tel : (418) 656-0055 ext. 1735 Sainte-Foy (Quebec) Canada Fax : (418) 654-0645 G1W 2L4 From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 19:37:01 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90664-3>; Wed, 30 Aug 1995 19:35:30 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 30 Aug 95 18:34 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 30 Aug 95 18:32 MET DST Message-Id: Subject: speed To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 30 Aug 1995 18:32:29 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 424 can someone profile the system routines (provided by gcc like strcp() ) and mail the results ? we should then start to rewrite them in asm (for __inline__), that should help to speedup the programms. btw: is there a way to get a smaler gcc ? he is fat walter -- ----- "Captain! There are aliens down on the planet. I managed to kill only fifteen of them before ascertaining they were non-hostile!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 20:28:16 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90067-1>; Wed, 30 Aug 1995 20:27:23 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0snqyq-0004nYC; Wed, 30 Aug 95 10:31 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: GCC &G To: vinsci@nic.funet.fi (Leonard Norrgard) Date: Wed, 30 Aug 1995 10:31:15 -0700 (MST) Cc: Joop.vandeWege@MEDEW.ENTO.WAU.NL, amiga-gcc-port@nic.funet.fi In-Reply-To: <95Aug30.151257+0300_eet_dst.90606-2+2@nic.funet.fi> from "Leonard Norrgard" at Aug 30, 95 03:12:50 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 474 > What version of ixemul.library are you using with Ghostscript? I'm using ixemul040fpu.library 41.3 here since the non-fpu versions get EMT traps on my system for some reason. I've also noticed the same problem with "enquire" from the gcc source distribution. This is a long standing problem, which I first noticed in 40.1, but have never had time to chase down. I had hoped that the recent bug fix for setting up the fpu might have helped, but apparently not. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Aug 30 21:06:17 1995 Received: from stl082.magnetek.com ([138.207.65.7]) by nic.funet.fi with ESMTP id <90681-2>; Wed, 30 Aug 1995 21:05:15 +0300 Received: by stl082.magnetek.com (1.37.109.11/16.2) id AA177896248; Wed, 30 Aug 1995 13:10:48 -0500 Date: Wed, 30 Aug 1995 13:10:48 -0500 From: Ed Eden To: amiga-gcc-port@nic.funet.fi Subject: help: chroot not found in libc.a Message-Id: <95Aug30.210515+0300_eet_dst.90681-2+1@nic.funet.fi> The function 'chroot' is not in libc.a. Can someone tell me why, and where to get the code so I can continue. Also, is there a program that will show the entrys in a .library file? Please reply to me, I'm not on the list yet... From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 09:40:00 1995 Received: from elixir.e.kth.se ([130.237.48.5]) by nic.funet.fi with SMTP id <90309-1>; Thu, 31 Aug 1995 09:38:39 +0300 Received: from zafir.e.kth.se (zafir.e.kth.se [130.237.48.6]) by elixir.e.kth.se (8.6.8.1/8.6.6) with ESMTP id IAA06267 for ; Thu, 31 Aug 1995 08:38:33 +0200 Received: (e90_dny@localhost) by zafir.e.kth.se (8.6.8.1/8.6.6) id IAA23806; Thu, 31 Aug 1995 08:38:33 +0200 Message-Id: <199508310638.IAA23806@zafir.e.kth.se> From: To: amiga-gcc-port@nic.funet.fi Subject: Does Gcc/G++ work with 060? Date: Thu, 31 Aug 1995 08:38:33 +0200 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: DennyĊ berg ^-illegal control character Does anybody use gcc/++ with 060 on Amiga? I'm thinking about buying one of th those A4000T with 060, or if they are to expensive maybe buy Blizzards 060 card for my A1200 when it's ready. Since gcc is the ONLY! updated c++ compiler for the Amiga, it's crucial that it works, otherwise I won't buy. best regards Denny From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 09:48:46 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90412-2>; Thu, 31 Aug 1995 09:48:25 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HUPTTG4GY800CHN2@NET2.WAU.NL>; Thu, 31 Aug 1995 08:51:05 +0000 (GMT) Received: by vines2.wau.nl; Thu, 31 Aug 95 8:48:58 +0100 Date: Thu, 31 Aug 1995 08:31:57 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: GCC problem To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi all, In my quest to compile Ghostscript3.33 I have stumbled over another problem. I got the source for the Amiga driver from Olaf Barthel for testing purposes and thats where the problem is. All other source files compile fine with the following commandline: gcc -m68020-40 -mstackextend -O2 -c sourcefile.c exept the file from Olaf (gdevamiga.c) It is a rather large file (~100K) and gcc needs a lot of memory but when it boils out I still have 3M Fast left and turning on VMM3.1 with 40M virtual doens't help either. I'm using gcc2.7.0 020 version from 21-Aug downloaded from funet (beta dir). A3000T-030-882 12M fast Kickstart 3.1, os-includes V40 with pragma/inline/proto from gcc2.7.0 This is the output from gcc -v ------------------------------------ New Shell process 2 2.System3.0:> gnu:gs3.33 2.Progs:gnu/gs3.33> gcc -v -m68020-40 -mstackextend -O2 gdevamiga.c Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cpp -lang-c -v -undef - D__GNUC__=2 -D__GNU C_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ - D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_A MIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -D__OPTIMIZE__ - Dmc68010 gdevamiga.c /t/cc696656.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cc1 /t/cc696656.i -mfixedstack - quiet -dum pbase gdevamiga.c -m68020-40 -mstackextend -O2 -version -o /t/cc696656.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. gdevamiga.c: In function `CreateScrollers': gdevamiga.c:1854: warning: initialization makes integer from pointer without a cast gdevamiga.c:1866: warning: initialization makes integer from pointer without a cast gdevamiga.c:1874: warning: initialization makes integer from pointer without a cast gdevamiga.c:1880: warning: initialization makes integer from pointer without a cast gdevamiga.c:1888: warning: initialization makes integer from pointer without a cast gdevamiga.c:1915: warning: initialization makes integer from pointer without a cast gdevamiga.c:1940: warning: initialization makes integer from pointer without a cast gdevamiga.c:1943: warning: initialization makes integer from pointer without a cast gdevamiga.c:1953: warning: initialization makes integer from pointer without a cast gdevamiga.c:1958: warning: initialization makes integer from pointer without a cast gdevamiga.c:1961: warning: initialization makes integer from pointer without a cast gdevamiga.c:1971: warning: initialization makes integer from pointer without a cast gdevamiga.c:1976: warning: initialization makes integer from pointer without a cast gdevamiga.c:1979: warning: initialization makes integer from pointer without a cast gdevamiga.c:1989: warning: initialization makes integer from pointer without a cast gdevamiga.c:1994: warning: initialization makes integer from pointer without a cast gdevamiga.c:1997: warning: initialization makes integer from pointer without a cast gdevamiga.c:2007: warning: initialization makes integer from pointer without a cast gdevamiga.c: In function `amiga_open_default': gdevamiga.c:2654: warning: initialization makes integer from pointer without a cast gdevamiga.c:2659: warning: initialization makes integer from pointer without a cast gdevamiga.c:2660: warning: initialization makes integer from pointer without a cast gdevamiga.c:2661: warning: initialization makes integer from pointer without a cast gdevamiga.c:2662: warning: initialization makes integer from pointer without a cast gdevamiga.c:2837: fixed or forbidden register was spilled. This may be due to a compiler bug or to impossible asm statements or clauses. 2.Progs:gnu/gs3.33> ----------------------------------- What bothers me is the last line 'fixed or forbidden register was spilled' There is about 2000 lines of source left when this happens. Line 2837 is the last line of a function (return(-1)). Source is available on request for testing. Its a big large to dump it here. Please help because this file is only compilable with -O0 but then I have mixed *.o files which might be the cause of other problems I have the amiga driver. Thanks Joop From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 11:00:19 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90612-1>; Thu, 31 Aug 1995 10:58:59 +0300 Received: by colombo.telesys-innov.fr; Thu, 31 Aug 1995 09:58:09 +0100 From: Philippe BRAND Message-Id: <199508310858.JAA12995@colombo.telesys-innov.fr> Subject: Re: GCC problem To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Thu, 31 Aug 1995 09:58:08 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "joop van de wege" at Aug 31, 95 08:31:57 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 363 joop van de wege writes: > In my quest to compile Ghostscript3.33 I have stumbled over another problem. Please send me output from preprocessor so that I can compile only this file. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 11:06:21 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90142-4>; Thu, 31 Aug 1995 11:06:01 +0300 Received: by colombo.telesys-innov.fr; Thu, 31 Aug 1995 10:05:24 +0100 From: Philippe BRAND Message-Id: <199508310905.KAA13035@colombo.telesys-innov.fr> Subject: Re: g++ v2.7.0 bug? To: pelletiery@berclain.com (Yanick Pelletier) Date: Thu, 31 Aug 1995 10:05:24 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199508301600.MAA00512@legue.quebec.Berclain.com> from "Yanick Pelletier" at Aug 30, 95 11:53:48 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 638 Yanick Pelletier writes: > This doesn't work, i received this error message > > ld: malformated input file (no rel or archive) > /gnu/lib/libstdc++.a(__SYMDEF) > > Does any body know what i must do to solve this bug (it work with g++2.6.3) > and i have get the archive gcc270-*.lha two days ago. Beta distributions had non-ranlibed libg++ archives. I ranlibed them for Aminet distribution. Please tell me if you're using relase dist or beta one. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 11:19:51 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <90007-4>; Thu, 31 Aug 1995 11:18:58 +0300 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id KAA16681 for ; Thu, 31 Aug 1995 10:13:01 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA05049; Thu, 31 Aug 95 09:44:32 GMT Date: Thu, 31 Aug 95 09:44:32 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9508310944.AA05049@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: Ixemul stackextend bug ?? Hi, I have tested the new stack feature of gcc 2.7.0 and found a memory problem with ixemul and stackextend. I use: - gcc 2.7.0 from Phillipe site (lastest version) - bigtest.c from stack.lha (ftp://nic.funet.fi/pub/amiga/gnu/beta) I compile bigtest.c with: gcc -mstackextend -O3 -o bigtest bigtest.c And every execution of bigtest eats nearly 2Mo of RAM !!! It runs all right with -noixemul flag. My config: A2000/68030/68881/KS37.175/WB2.1 \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr:8080/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 11:53:43 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90017-3>; Thu, 31 Aug 1995 11:53:05 +0300 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id KAA01316 (8.6.12/IDA-1.6); Thu, 31 Aug 1995 10:52:53 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA15486; Thu, 31 Aug 95 10:52:52 +0200 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9508310852.AA15486@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: *.guide diffs To: gc948374@gbar.dtu.dk Date: Thu, 31 Aug 1995 10:52:51 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Aug30.181230+0300_eet_dst.90907-3+16@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 30, 95 06:12:25 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 684 Hello Rask, [lots of diffs deleted] It's generally a good idea if people care about a better gcc documentation, but I'm afraid that you've spend a lot of time for nothing. The .guide-files for gcc are machine generated with texinfo and any changes made to them are lost as soon as something changes in the originals - it's just not worthwhile changing the docs over and over again (especially if the differences are only in the control commands). The better way is to fix the originals directly (or texinfo if that's at fault). Btw: If you still feel like getting better documentation: texinfo can be found on aminet, including sources ;-). Sorry for the bad news, Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 12:15:36 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90196-4>; Thu, 31 Aug 1995 12:14:54 +0300 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id LAA07196 (8.6.12/IDA-1.6); Thu, 31 Aug 1995 11:14:41 +0200 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA15643; Thu, 31 Aug 95 11:14:41 +0200 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9508310914.AA15643@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: GCC problem To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Thu, 31 Aug 1995 11:14:40 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "joop van de wege" at Aug 31, 95 08:31:57 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 642 > > In my quest to compile Ghostscript3.33 I have stumbled over another problem. > > gcc -m68020-40 -mstackextend -O2 -c sourcefile.c > > gdevamiga.c:2837: fixed or forbidden register was spilled. > This may be due to a compiler bug or to impossible asm > statements or clauses. > I think this could be a side effect of the stackextend option. The functions for stackextend are called in a similar way to the assembler inlines used to call system functions (using only d0 as argument and clobbering the usual d0,d1,a0,a1) and sometimes you get this message when using those inlines. I don't have an easy solution at hand - sorry. Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 14:50:52 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90165-3>; Thu, 31 Aug 1995 14:46:36 +0300 Received: by ceylon.informatik.uni-rostock.de id NAA16217; Thu, 31 Aug 1995 13:46:24 +0200 Received: by carl.informatik.uni-rostock.de id NAA09636; Thu, 31 Aug 1995 13:46:23 +0200 From: Gunther Nikl Message-Id: <199508311146.NAA09636@carl.informatik.uni-rostock.de> Subject: Re: GCC problem To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Thu, 31 Aug 1995 13:46:21 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "joop van de wege" at Aug 31, 95 08:31:57 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1659 Hello! > In my quest to compile Ghostscript3.33 I have stumbled over another problem. > > gcc -v -m68020-40 -mstackextend -O2 gdevamiga.c: > > gdevamiga.c:2837: fixed or forbidden register was spilled. > This may be due to a compiler bug or to impossible asm statements or clauses. > > What bothers me is the last line 'fixed or forbidden register was spilled' > There is about 2000 lines of source left when this happens. Line 2837 is the > last line of a function (return(-1)). gcc told you that it had problems to compile the function, which ends at line 2837. It does not mean, that the problems is at this line. The reason for the above error is simple: the compiler tries to integrate OS-functions. Some need noscratch registers to pass arguments. If a required register is already allocated by gcc and is now required for a os-function, gcc comes up with the above error message. gcc is simply to good in optimization ;-) What you can do: 1) Compile without optimization 2) Compile with "-D__NOINLINES__" (only possible if you use the proto-headers) 3) investigate the function there the error occurs. Now try to find the os-call that needs to many no-scratch regs. prevent gcc from inlining this call this way: #define #include or #undef > Please help because this file is only compilable with -O0 but then I have > mixed *.o files which might be the cause of other problems I have the amiga > driver. Why should it hurt to have an object-file only compiled with "-O0"? What does "mixed" mean? What problems shall arise? Gunther From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 15:41:14 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90549-4>; Thu, 31 Aug 1995 15:40:36 +0300 Received: by colombo.telesys-innov.fr; Thu, 31 Aug 1995 14:33:42 +0100 From: Philippe BRAND Message-Id: <199508311333.OAA13867@colombo.telesys-innov.fr> Subject: Re: g++ v2.7.0 bug? To: pelletiery@berclain.com (Yanick Pelletier) Date: Thu, 31 Aug 1995 14:33:41 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199508311143.HAA03482@legue.quebec.Berclain.com> from "Yanick Pelletier" at Aug 31, 95 07:37:28 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 578 Yanick Pelletier writes: > >Beta distributions had non-ranlibed libg++ archives. I ranlibed them for > >Aminet distribution. Please tell me if you're using relase dist or beta one. > Ok, i used the beta distribution from funet! I will try to ranlib the > library! I'm currently sending release distribution to funet in /pub/amiga/gnu/gcc If you can wait a while, it will be much faster for you. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 17:05:42 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90698-1>; Thu, 31 Aug 1995 17:04:55 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Thu, 31 Aug 95 16:03:37 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <21399e57.u7t157e.a0130-robert@plukwa.pdi.lodz.pl> Subject: fcntl and F_SETLK Reply-To: robert@pdi.lodz.pl Content-Length: 1355 To: amiga-gcc-port@nic.funet.fi Date: Thu, 31 Aug 95 16:03:37 Hi! In my poor efforts to port ncftp2.1.0 to Amiga/AmiTCP enviroment i came to small disscomfort. NcFTP checks if other instances of itself are running. It does this by creating special file and locking first byte using fcntl(*,F_SETLK,*). But when compiled on Amiga it always thinks that there are other NcFTps running. Now I want to know if fcntl as implemented in gcc knows about F_SETLK cmd. From include files it seems that it knows but man page (fcntl.2) doesn't mention it. This could mean that man page is outdated or fcntl doesn't understand F_SETLK for real. Any comments? Robert Ps. The * in fcntl above are rather wildcards than actual parameters Ps2: I'm still using ixemul 41.1 as i dont know if AmiTCP-sdk-gcc won't break after installing latest ixemul. In fact i'm not even sure if installing AmiTCP-sdk0gcc over ixemul 41.1 didn't break anything in some include files +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 17:19:15 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90471-2>; Thu, 31 Aug 1995 17:18:28 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA22348 (5.65b/CWI-3.3); Thu, 31 Aug 1995 16:18:23 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0so2YC-000FbbC; Thu, 31 Aug 95 07:52 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0918@wyst.hobby.nl>; Wed, 30 Aug 95 21:23:21 CET Message-Id: <9508302023.0918@wyst.hobby.nl> Date: Wed, 30 Aug 1995 19:23:19 +0000 (CET) In-Reply-To: from "Walter Harms" at Aug 29, 95 11:29:57 am Content-Type: text Content-Length: 1410 From: hans@wyst.hobby.nl (Hans Verkuil) To: Walter.Harms@arbi.informatik.uni-oldenburg.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: FIONREAD According to Walter Harms: > I found this as (file-)flags for icctl() > > FIOCLEX - set exclusive user > FIONCLEX - unset % > FIOBIO - un/set nonblocking I/O > FIOASYNC - un/set async I/O > FIONREAD - get number of bytes to read > FIOSETOWN - set owner > FIOGETOWN - get owner > > What is implemented via ixemul ? FIONREAD and FIONBIO (note the 'N'). The others are ignored. > FRED: > i had some problems with signals (long ago), because > it seem to be fixed in 41.3 what signals are working > now ? All signals should work (more or less :-). The problem was that it was possible that a signal for one process was handled in the signal handler from another process, which led to disastrous results in GNU make that was compiled resident. Ctrl-C handling still has some problems (i.e., it crashes sometimes). However, I just managed to reproduce this problem, with some difficulty. So now I can find out where exactly things go wrong. I don't know how long ago 'long ago' is, but I strongly recommend that you get ixemul 41.3: it is much more stable than pre 41 versions. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 17:19:18 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90023-4>; Thu, 31 Aug 1995 17:18:44 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA22372 (5.65b/CWI-3.3); Thu, 31 Aug 1995 16:18:32 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0so2YQ-000FbbC; Thu, 31 Aug 95 07:52 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <091d@wyst.hobby.nl>; Wed, 30 Aug 95 21:38:03 CET Message-Id: <9508302038.091d@wyst.hobby.nl> Date: Wed, 30 Aug 1995 19:38:02 +0000 (CET) In-Reply-To: <95Aug30.124952+0300_eet_dst.90420-4+18@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Aug 30, 95 12:49:51 pm Content-Type: text Content-Length: 2005 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: CONSOLE Rask, > It is not wildcards that is the problem. As I showed in my mail on > Monday 21st, it is possible to use files named "*" if the program opening > "*" does not have a CLI structure attached. That is what I find dangerous. > Since the use of "*" has been declared obsolete as of V36, and ixemul > doesn't work on anything less, there is no reason not to switch to > "CONSOLE:". > > > > Rask, just fix it and mail a patch to Fred Fish. > > I will, since nobody else wants to. It is not that I don't want to do it, but my experience is that if you want to get something done, the easiest way (and often the fastest) is to do it yourself. Changing the Open("*") to Open("CONSOLE:") is very easy to do and all you have to do is compile the new library, test it, and mail the patch to Fred Fish. I have noticed that many people (and this is a general remark, please don't take it personally) keep complaining about bugs, but nobody actually thinks: "Hey, it doesn't work! Why don't I find out what is wrong and fix it myself." One example is the fact that -resident didn't work except for gcc 2.3.3. At least a year, if not longer, complaints came in. Well, it is fixed now, because I found out what was wrong and fixed it. It wasn't that difficult, actually. Of course, you need to have the time and equipment (enough memory and HD space) to be able to fix these things, but otherwise it's not that difficult and doesn't take that much time in general. Some bugs DO take a lot of time and patience to find, but most are easy. Sorry, I had to get this off my chest. Again, don't take this personally and please do make the patch and mail it to Fred. It's one more step to a better library. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 17:56:21 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90142-4>; Thu, 31 Aug 1995 17:55:37 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id PAA01473; Thu, 31 Aug 1995 15:53:46 +0100 From: Lars Hecking Message-Id: <199508311457.PAA09472@mostar.nmrc.ucc.ie> Subject: Re: fcntl and F_SETLK To: robert@pdi.lodz.pl Date: Thu, 31 Aug 1995 15:57:02 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <21399e57.u7t157e.a0130-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Aug 31, 95 04:03:37 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 671 > Hi! > In my poor efforts to port ncftp2.1.0 to Amiga/AmiTCP enviroment i came to > small disscomfort. NcFTP checks if other instances of itself are running. It > does this by creating special file and locking first byte using > fcntl(*,F_SETLK,*). But when compiled on Amiga it always thinks that there > are other NcFTps running. Now I want to know if fcntl as implemented in gcc > knows about F_SETLK cmd. From include files it seems that it knows but man > page (fcntl.2) doesn't mention it. This could mean that man page is outdated > or fcntl doesn't understand F_SETLK for real. > Any comments? F_GETLK, F_SETLK and F_SETLKW are currently not implemented. From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 19:17:58 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90017-2>; Thu, 31 Aug 1995 19:17:01 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0soCGy-0004nYC; Thu, 31 Aug 95 09:15 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: CONSOLE To: hans@wyst.hobby.nl (Hans Verkuil) Date: Thu, 31 Aug 1995 09:15:23 -0700 (MST) Cc: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-Reply-To: <9508302038.091d@wyst.hobby.nl> from "Hans Verkuil" at Aug 30, 95 07:38:02 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2634 > I have noticed that many people (and this is a general remark, please don't > take it personally) keep complaining about bugs, but nobody actually > thinks: "Hey, it doesn't work! Why don't I find out what is wrong and fix > it myself." One example is the fact that -resident didn't work except for > gcc 2.3.3. At least a year, if not longer, complaints came in. Well, it is > fixed now, because I found out what was wrong and fixed it. It wasn't that > difficult, actually. Of course, you need to have the time and equipment > (enough memory and HD space) to be able to fix these things, but otherwise > it's not that difficult and doesn't take that much time in general. Some > bugs DO take a lot of time and patience to find, but most are easy. I'd like to thank Hans for expressing so well the fact that this really is a community effort. There is an incredible amount of programmer talent available in the Amiga community, with an incalculable amount of hours going into producing demos, freely distributable software, shareware, and other such goodies. If only 1% of that effort could be harnessed to improve the tools that we all could use, the GNU tools would blow away any commercially available tools for the Amiga. As an example, I'm sure that there are dozens of programmers that know enough about the low level details of how AmigaDOS runs programs that they could easily produce a UNIX ptrace() equivalent that would allow gdb to be completely ported. Gdb now has hooks to interface to a GUI, and certainly someone could produce a nifty GUI for gdb, even if they had to use MUI. We are still stuck with the old crufty binutils 1.38 linker, even though 98% of the work to switch to a current linker has been done and the only thing lacking in the latest linker is support for "linker flavors" and the ability to handle relocation hunks that have more than 64K entries. Given completion of the linker, we could easily support AmigaDOS cross enviroments on machines that have different endianess than the 68K, such as PCs. With a little more work to finish AmigaDOS hunk reading in the BFD library we could also switch to using AmigaDOS hunk format as the object file format for all the tools, since the changes in the BFD library to allow the linker to write AmigaDOS hunk format also allow the assembler to do the same. Once the linker can read this format in addition to the currently used a.out, we can make hunk format the default. Give me another 30 minutes and I could probably come up with 30 more examples of things that could be done without major time investments to improve our environment. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 19:56:06 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90612-2>; Thu, 31 Aug 1995 19:55:44 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0soCsA-0004nYC; Thu, 31 Aug 95 09:53 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Ixemul stackextend bug ?? To: papier@indi1.u-strasbg.fr (Laurent Papier) Date: Thu, 31 Aug 1995 09:53:50 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi (ixemul.library maintainers) In-Reply-To: <9508310944.AA05049@indi1.u-strasbg.fr> from "Laurent Papier" at Aug 31, 95 09:44:32 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 928 > Hi, > I have tested the new stack feature of gcc 2.7.0 and found a memory problem > with ixemul and stackextend. > > I use: > - gcc 2.7.0 from Phillipe site (lastest version) > - bigtest.c from stack.lha (ftp://nic.funet.fi/pub/amiga/gnu/beta) > > I compile bigtest.c with: > gcc -mstackextend -O3 -o bigtest bigtest.c > > And every execution of bigtest eats nearly 2Mo of RAM !!! > It runs all right with -noixemul flag. It is very possible that there is a bug in the way that I integrated the libnix stack code into ixemul, particularly in crt0 where there is no equivalent to some code that is in the libnix startup that gets run at process exit. Perhaps it is the source of the memory leak. It would be good if someone with more intimate knowledge of AmigaDOS and assembly code could review the way that libnix interfaces to the stack checking/extending code and compare it to how ixemul currently does so. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Aug 31 21:36:22 1995 Received: from INVALID ([193.212.103.109]) by nic.funet.fi with SMTP id <90813-1>; Thu, 31 Aug 1995 21:35:27 +0300 Received: by INVALID.telepost.no (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Thu, 31 Aug 95 20:35:13 Received: by INVALID.telepost.no (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Thu, 31 Aug 95 17:15:47 Date: Thu, 31 Aug 1995 17:15:46 +0000 () From: Erik Johannessen X-Sender: erij@localhost Subject: ixemul bug Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: amiga-gcc-port@lists.funet.fi Ixemul programs looses arguments beginning with a @ when run from a normal amiga shell. When run from sh (pdksh) everything is fine. I'm using ixemul 4101 and gcc-2.7.0 (Aug 21st). The following program/log demonstrates the behaviour: 7.Users:erik/sources/test> cat at.c #include main(int argc,char *argv[]){ while(argc!=0){ printf("%s\n",argv[argc-1]); --argc; } } 7.Users:erik/sources/test> gcc at.c -o at 7.Users:erik/sources/test> at a @b c @d c a at 7.Users:erik/sources/test> sh # at a @b c @d @d c @b a at # exit When compiled with libnix, the above program runs correctly under the normal amiga shell too. 7.Users:erik/sources/test> gcc -noixemul at.c -o at 7.Users:erik/sources/test> at a @b c @d @d c @b a at 7.Users:erik/sources/test> sh # at a @b c @d @d c @b a at # exit 7.Users:erik/sources/test> -Erik From amiga-gcc-port-owner@nic.funet.fi Fri Sep 1 02:15:55 1995 Received: from beast.moneng.mei.com ([151.186.20.64]) by nic.funet.fi with SMTP id <90558-2>; Fri, 1 Sep 1995 02:14:14 +0300 Received: by beast.moneng.mei.com (4.1/SMI-4.1) id AA00730; Thu, 31 Aug 95 18:13:45 CDT Date: Thu, 31 Aug 95 18:13:45 CDT From: Howard Anstedt Message-Id: <9508312313.AA00730@beast.moneng.mei.com> To: pelletiery@berclain.com Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508301616.MAA00600@legue.quebec.Berclain.com> (message from Yanick Pelletier on Wed, 30 Aug 1995 12:09:47 -0400) Subject: Re: code size! I have seen this with SAS as well, I believe that you link in the the majority of the C++ iostream library when you use "<<" or ">>" and include "ostream.h". This is just like the fact that most compilers bring in the full printf functionally, NOT SAS, for just a printf"HELLO WORLD"); function call. From amiga-gcc-port-owner@nic.funet.fi Fri Sep 1 09:15:28 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90486-3>; Fri, 1 Sep 1995 09:14:31 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA16842 (5.65b/CWI-3.3); Fri, 1 Sep 1995 08:13:12 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0soP1f-000FbpC; Fri, 1 Sep 95 07:52 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <092q@wyst.hobby.nl>; Thu, 31 Aug 95 21:27:12 CET Message-Id: <9508312027.092q@wyst.hobby.nl> Date: Thu, 31 Aug 1995 21:27:10 +0000 (CET) In-Reply-To: from "Erik Johannessen" at Aug 31, 95 05:15:46 pm Content-Type: text Content-Length: 1566 From: hans@wyst.hobby.nl (Hans Verkuil) To: erij@telepost.no Cc: amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi Subject: Re: ixemul bug According to Erik Johannessen: > > Ixemul programs looses arguments beginning with a @ when run from a > normal amiga shell. When run from sh (pdksh) everything is fine. > I'm using ixemul 4101 and gcc-2.7.0 (Aug 21st). > The following program/log demonstrates the behaviour: > > 7.Users:erik/sources/test> cat at.c > #include > > main(int argc,char *argv[]){ > while(argc!=0){ > printf("%s\n",argv[argc-1]); > --argc; > } > } > > 7.Users:erik/sources/test> gcc at.c -o at > 7.Users:erik/sources/test> at a @b c @d > c > a > at > 7.Users:erik/sources/test> sh > # at a @b c @d > @d > c > @b > a > at > # exit Just looked at _cli_parse.c and I discovered a new 'feature' of the ixemul.library. Any argument that starts with '@' is interpreted as follows: the string after the '@' is the filename and that file is read and inserted into the argument list. In other words, 'echo a @file b' is equal to 'echo a `cat file` b'. My proposal is to remove this misfeature that nobody knows about. And that can be replaced by the backtick-method. Especially with the use of @ as part of an internet address it would be wiser not to attach a special meaning to a @. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Sep 1 12:45:24 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90847-4>; Fri, 1 Sep 1995 12:39:59 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HURE4MGLKG00D369@NET2.WAU.NL>; Fri, 01 Sep 1995 11:42:46 +0000 (GMT) Received: by vines2.wau.nl; Fri, 1 Sep 95 11:40:39 +0100 Date: Fri, 01 Sep 1995 11:36:29 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: GCC problem To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Matthias wrote: >> gdevamiga.c:2837: fixed or forbidden register was spilled. >> This may be due to a compiler bug or to impossible asm >> statements or clauses. >> >I think this could be a side effect of the stackextend option. Tried without -mstackextend --> No luck. Since I have problems with the amiga driver part I don't want mixed object files. I don't want one equation with 2 unkowns, you can't solve that. Joop From amiga-gcc-port-owner@nic.funet.fi Fri Sep 1 13:00:23 1995 Received: from plukwa ([193.59.40.133]) by nic.funet.fi with SMTP id <90348-1>; Fri, 1 Sep 1995 12:56:42 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 1 Sep 95 11:55:08 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <213ab598.u7t157e.20587-robert@plukwa.pdi.lodz.pl> Subject: Re: fcntl and F_SETLK In-Reply-To: <199508311457.PAA09472@mostar.nmrc.ucc.ie> (from Lars Hecking ) (at Thu, 31 Aug 1995 15:57:02 +0100 (BST)) Reply-To: robert@pdi.lodz.pl Content-Length: 1382 To: lhecking@nmrc.ucc.ie Cc: amiga-gcc-port@nic.funet.fi Date: Fri, 1 Sep 95 11:55:08 On Aug 31 Lars Hecking wrote: > > > Hi! > > In my poor efforts to port ncftp2.1.0 to Amiga/AmiTCP enviroment i came to > > small disscomfort. NcFTP checks if other instances of itself are running. It > > does this by creating special file and locking first byte using > > fcntl(*,F_SETLK,*). But when compiled on Amiga it always thinks that there > > are other NcFTps running. Now I want to know if fcntl as implemented in gcc > > knows about F_SETLK cmd. From include files it seems that it knows but man > > page (fcntl.2) doesn't mention it. This could mean that man page is outdated > > or fcntl doesn't understand F_SETLK for real. > > Any comments? > > F_GETLK, F_SETLK and F_SETLKW are currently not implemented. > Wouldn't it be wise to undef those in sys/fcntl.h Some programs (vide NcFTP) seems to rely on the definiton of those cmds. Thanks for sheding some light on me. best regards, Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Sep 1 16:03:45 1995 Received: by nic.funet.fi id <90588-4>; Fri, 1 Sep 1995 16:00:09 +0300 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <95Sep1.160009+0300_eet_dst.90588-4+6@nic.funet.fi> Date: Fri, 1 Sep 1995 16:00:02 +0300 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Fri Sep 1 16:55:19 1995 Received: from icslab11.icslab.agh.edu.pl ([149.156.98.11]) by nic.funet.fi with SMTP id <90519-4>; Fri, 1 Sep 1995 16:53:37 +0300 Received: (from kiskra@localhost) by icslab11.icslab.agh.edu.pl (8.6.12/8.6.12) id PAA00201; Fri, 1 Sep 1995 15:55:32 +0200 Date: Fri, 1 Sep 1995 15:55:29 +0200 (MET DST) From: Kamil Iskra Subject: Problem with IXEmul 41.3 and KingCON 1.3 To: Amiga GCC List cc: f92dala@dd.chalmers.se Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject says all: there is an incompatibility between IXEmul 41.3 and KingCON 1.3 (68020 version, installed as CON/RAW replacement). Every time I run a program that requires IXEmul (GCC, Diff, ...) I get the following Enforcer hit: BYTE-READ from F00DDEAD PC: 1E0EFA4C USP: 1E1544F0 SR: 0008 SW: 0751 (U0)(-)(-) TCB: 1E153568 Data: 1E2A465C 1E155D9C 00000000 000000D1 0000008C 00000000 00000000 00000001 Addr: F00DDEAE 1E0E2CBE 1E155D9C 00000000 1E0EFFF0 1E1545C4 000014E4 -------- Stck: 1E0E45AC F00DDEAD 1E0E2CBE 00000000 FFFFFFFF 1E15BA08 0012BA40 1E155D9C Stck: 000014E4 1E0EFFF0 1E243E7C 00F93068 00000008 1E155D9C 1E15EDDC 00F91764 Name: "CON" Hunk 0000 Offset 0000DFAC Apart from this, everything seems to work well. There is no problem with standard CON or with IXEmul 41.1. Tested with both 68000 and 68030 versions of IXEmul 41.3. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Sep 1 17:10:41 1995 Received: from icslab11.icslab.agh.edu.pl ([149.156.98.11]) by nic.funet.fi with SMTP id <90388-4>; Fri, 1 Sep 1995 17:08:16 +0300 Received: (from kiskra@localhost) by icslab11.icslab.agh.edu.pl (8.6.12/8.6.12) id QAA00220; Fri, 1 Sep 1995 16:09:45 +0200 Date: Fri, 1 Sep 1995 16:09:44 +0200 (MET DST) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: GCC problem To: Gunther Nikl cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199508311146.NAA09636@carl.informatik.uni-rostock.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Thu, 31 Aug 1995, Gunther Nikl wrote: > > In my quest to compile Ghostscript3.33 I have stumbled over another problem. > > > > gcc -v -m68020-40 -mstackextend -O2 gdevamiga.c: > > > > gdevamiga.c:2837: fixed or forbidden register was spilled. > > This may be due to a compiler bug or to impossible asm statements or clauses. > > the compiler tries to integrate OS-functions. Some need noscratch registers > to pass arguments. If a required register is already allocated by gcc and > is now required for a os-function, gcc comes up with the above error > message. gcc is simply to good in optimization ;-) Depends on the point of view. OS-calls are implemented as "inline" functions. These functions may use as many registers as they want - and this is correct, cause they are separate functions :-). When they are inlined, it is COMPILER'S resonsibility to take care of correct register allocation. Maybe it is not a bug for a compiler to run out of registers, especially if a lot of them are allocated by OS-calls, but writing "gcc is simply too good" in this context is just rediculous. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Sep 1 19:11:28 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90290-3>; Fri, 1 Sep 1995 19:08:58 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0soYdG-0004nYC; Fri, 1 Sep 95 09:07 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: on vacation To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Fri, 1 Sep 1995 09:07:54 -0700 (MST) Cc: ixemul@listserv.funet.fi (ixemul.library maintainers) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 265 Since I get a lot of email from people on these two lists, and don't currently have a "vacation email autoresponder" set up, I just want to let everyone know I'll be out of town from 2-Sep to 9-Sep and will be able to respond to email again starting 10-Sep. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Sep 2 05:08:01 1995 Received: from k332.feld.cvut.cz ([147.32.192.12]) by nic.funet.fi with SMTP id <90126-1>; Sat, 2 Sep 1995 05:07:00 +0300 Received: (from utx@localhost) by k332.feld.cvut.cz (8.6.10/8.6.9) id EAA16660 for amiga-gcc-port@nic.funet.fi; Sat, 2 Sep 1995 04:24:37 +0200 Date: Sat, 2 Sep 1995 04:24:37 +0200 From: Stanislav Brabec Message-Id: <199509020224.EAA16660@k332.feld.cvut.cz> To: amiga-gcc-port@nic.funet.fi Subject: MultiUser flags in gcc and small bug in dirs Hello, I found a small bug in ixemul attributes parsing (v 41.1). As noted in Include:dos/dos.h, file protection flags for GRP and OTR are negated (i.e. 0==don't allow). But ixemul uses positive ones. The correct *IX<->AmigaOS flag conversion is: USR: r<->r w<->w&&d x<-e||s ;*IX scripts are executed, when +e, AmigaOS also when +s-e x->e ;but after SetProtection we'll use *IX notation GRP&OTR: r<->NOT(r) w<->NOT(w&&d) x<-NOT(e||s) x->NOT(e) Sorry, maybe I can fix it, but not test. On my Amiga it's impossible to compile big tasks (A500, A530turbo: 1.75 + 0.25 + 1MB + 1MB, softkick) --- Second small bug in directories listing (v 41.1): If I'm in physical volume root, file .. is reported when finding, but cannot be examined. There are two ways: make a fake "root dir" or remove "..". --- Is there any project concerning both MultiUser and ixemul? -- Stanislav From amiga-gcc-port-owner@nic.funet.fi Sat Sep 2 21:44:19 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90462-2>; Sat, 2 Sep 1995 19:21:03 +0300 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id TAA09613 at Sat, 2 Sep 1995 19:18:18 +0300 Received: by softlab.ece.ntua.gr with UUCP id TAA22496 at Sat, 2 Sep 1995 19:24:47 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <0868@kriton.UUCP>; Sat, 2 Sep 95 19:17:18 EET Date: Sat, 2 Sep 95 19:17:18 EET Message-Id: <9509021717.0868@kriton.UUCP> Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 1032 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Problem with ixemul 41.3 and DosWedge I am using the DosWedge commodity to add UNIX-like features to the AmigaDOS file system, like ".", "..", and "~". With version 41.3 of ixemul.library the "~" feature has stopped working for ixemul clients. For example, the following program ------------------------------------------------------------------------------ #include main(int argc, char *argv[]) { FILE *f; f = fopen(argv[1], "r"); if (f) { printf("OK\n"); fclose(f); }else{ perror("fopen failed"); } return 0; } ------------------------------------------------------------------------------ when invoked using something like "a.out ~/foo", will print "fopen failed: No such file or directory" even if ~/foo exists. It will print "OK" if compiled using -noixemul or with SAS/C. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "How do you feel?" "Generally with my hands, but I have sensors all over my body." ----- From amiga-gcc-port-owner@nic.funet.fi Sun Sep 3 15:00:05 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90884-3>; Sun, 3 Sep 1995 14:53:25 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HUUBCSHC2O00E3VS@NET2.WAU.NL>; Sun, 03 Sep 1995 13:56:13 +0000 (GMT) Received: by vines2.wau.nl; Sun, 3 Sep 95 13:54:45 +0100 Date: Sun, 03 Sep 1995 13:36:32 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Inline problems To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi Philippe, >I'll try with 2.7.1 very soon. > Keep you guys posted on this one, Joop This is the followup on my problems with the source I got from Olaf which implements an amiga driver for Ghostscript3.33. Its the followup to the message I got from gcc2.70 when compiling this module. 'fixed or forbidden register was spilled' I found the offending AmigaOS call, its BltBitMap The reason it fails has possibly todo with the large amount of registers required, *d7* being one of them, actually it uses d0-d7 a0-a2 + a6. There are 3 other OS calls which use d7 but none of them with so many other registers. DoPkt (uses 8), Alert (2) and AddAppIconA (8) I got mail from Jeroen (Hi Jeroen) and he made a bet that it was DoPkt, he lost :) The use of a lot of registers by BltBitMap shouldn't cause this message to appear. GCC should store all the other registers to memory and load the correct ones for BltBitMap into the registers and call BltBitMap. There is only 1 call to BltBitMap in the source I send you. Finding it should be simple. It is not possible to do some reordering of C instructions to see if that would help. Only thing possible right now is to exclude BltBitMap from being inlined :( As a side note: In the LibnixStack.guide, it is mentioned not to use -mstackextend/- mstackcheck with interrupt code and hook code. Does that also include Task adding. gdevamiga.c adds a seperate task to handle the scrolling in the output window and the support functions are being compiled with stackextend right now. Is this allowed or not. If not then the documentation should be adapted to say that Task shouldn't use stackextend/stackcheck. The reason I ask is that with a CLI with a stack of 4096 causes Ghostscript todo a stackextend (largest needed ~5000) around the time the windowhandler Task is started. Sometimes this failes and with a CLI stack of 10000 it doesn't. The Task itself uses a stack of 8192 of which only 200 bytes are actually used. Joop From amiga-gcc-port-owner@nic.funet.fi Sun Sep 3 20:17:48 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90508-1>; Sun, 3 Sep 1995 20:13:02 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA27618 (5.65b/CWI-3.3); Sun, 3 Sep 1995 19:12:51 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0spI45-000FbTC; Sun, 3 Sep 95 18:38 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0948@wyst.hobby.nl>; Sun, 3 Sep 95 12:44:06 CET Message-Id: <9509031144.0948@wyst.hobby.nl> Date: Sun, 3 Sep 1995 12:44:04 +0000 (CET) In-Reply-To: <199509020224.EAA16660@k332.feld.cvut.cz> from "Stanislav Brabec" at Sep 2, 95 04:24:37 am Content-Type: text Content-Length: 1038 From: hans@wyst.hobby.nl (Hans Verkuil) To: utx@k332.feld.cvut.cz Cc: amiga-gcc-port@nic.funet.fi, fnf@amigalib.com Subject: Re: MultiUser flags in gcc and small bug in dirs According to Stanislav Brabec: > I found a small bug in ixemul attributes parsing (v 41.1). Thanks for pointing this out. I've fixed this in my version and will mail patches to Fred Fish. > Second small bug in directories listing (v 41.1): > > If I'm in physical volume root, file .. is reported when finding, but > cannot be examined. There are two ways: make a fake "root dir" or remove > "..". This is not as trivial to fix as the previous. So this should go into the BUGS file of the ixemul distribution. Creating a fake root dir would be best and is a better solution than removing "..". Any volunteers? > Is there any project concerning both MultiUser and ixemul? Not to my knowledge. Again, any volunteers? Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sun Sep 3 20:17:54 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90625-2>; Sun, 3 Sep 1995 20:13:17 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA27621 (5.65b/CWI-3.3); Sun, 3 Sep 1995 19:13:03 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0spI4D-000FbTC; Sun, 3 Sep 95 18:38 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <094i@wyst.hobby.nl>; Sun, 3 Sep 95 16:32:14 CET Message-Id: <9509031532.094i@wyst.hobby.nl> Date: Sun, 3 Sep 1995 16:32:12 +0000 (CET) In-Reply-To: <9509021717.0868@kriton.UUCP> from "Kriton Kyrimis" at Sep 2, 95 07:17:18 pm Content-Type: text Content-Length: 1423 From: hans@wyst.hobby.nl (Hans Verkuil) To: kyrimis@softlab.ece.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Problem with ixemul 41.3 and DosWedge According to Kriton Kyrimis: > I am using the DosWedge commodity to add UNIX-like features to the AmigaDOS > file system, like ".", "..", and "~". With version 41.3 of ixemul.library > the "~" feature has stopped working for ixemul clients. The filename used to be expanded using the MatchPattern functions of the dos.library. However, this has been replaced by a call to glob(). The reason was that .. and . were not handled by the standard dos.library, making it impossible to use 'egrep XXX ../*.c' for example. The files were also not sorted. In 41.1 you could choose which method to use: the old Amiga or the new glob() method. In 41.3 the old method was removed as it had no real benefit anymore except in a few rare cases such as yours. DosWedge probably patches the Amiga functions such as Open, but ixemul bypasses those and uses packets directly. So DosWedge no longer sees the filenames. While it is possible to return to the 41.1 behavior I'm personally opposed to this. It took a fair amount of (ugly) code and it would only benefit people that are using MultiUserFileSystem and DosWedge. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sun Sep 3 22:53:55 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90635-1>; Sun, 3 Sep 1995 22:53:23 +0300 Received: by colombo.telesys-innov.fr; Sun, 3 Sep 1995 21:52:55 +0100 From: Philippe BRAND Message-Id: <199509032052.VAA07821@colombo.telesys-innov.fr> Subject: Re: Inline problems To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Sun, 3 Sep 1995 21:52:54 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "joop van de wege" at Sep 3, 95 01:36:32 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 454 joop van de wege writes: > Is this allowed or not. > If not then the documentation should be adapted to say that Task shouldn't > use stackextend/stackcheck. As for now don't use stackextend with ixemul. Someone has to check what have been done by Fred in ixemul sources. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 10:33:31 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <89939-2>; Mon, 4 Sep 1995 10:31:36 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HUVI9WW9M890W094@LEON.CTI.GR>; Mon, 4 Sep 1995 10:24:45 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA15943; Mon, 4 Sep 95 10:32:59 +0300 Date: Mon, 04 Sep 1995 10:32:58 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: Problem with ixemul 41.3 and DosWedge In-reply-to: <9509031532.094i@wyst.hobby.nl> from "Hans Verkuil" at Sep 3, 95 04:32:12 pm To: hans@wyst.hobby.nl (Hans Verkuil) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@theseas.softlab.ece.ntua.gr Message-id: <9509040732.AA15943@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 544 > DosWedge probably patches the Amiga functions such as Open, but ixemul > bypasses those and uses packets directly. So DosWedge no longer sees the > filenames. Is there a reason for not using DOS packets rather than the equivalent DOS functions? It somehow doesn't feel right not to be able to use any of those commodities that patch the DOS functions. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "There's nowhere else like it in the Universe. Not *this* Universe, anyway..." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 10:38:37 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90548-2>; Mon, 4 Sep 1995 10:38:11 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HUVIIKZ5N490UWAR@LEON.CTI.GR>; Mon, 4 Sep 1995 10:31:45 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA16284; Mon, 4 Sep 95 10:39:58 +0300 Date: Mon, 04 Sep 1995 10:39:57 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: Problem with ixemul 41.3 and DosWedge In-reply-to: <9509040732.AA15943@hpcl.cti.gr> from "Kriton Kyrimis" at Sep 4, 95 10:32:58 am To: hans@wyst.hobby.nl Cc: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9509040739.AA16284@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 323 > Is there a reason for not using DOS packets rather than the equivalent DOS ^^^ I obviously meant "for using", not "not for using"! -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "There's nowhere else like it in the Universe. Not *this* Universe, anyway..." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 11:52:03 1995 Received: from erlang.gbar.dtu.dk ([130.225.87.177]) by nic.funet.fi with ESMTP id <90793-3>; Mon, 4 Sep 1995 11:51:01 +0300 Received: by erlang.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Sep4.115101+0300_eet_dst.90793-3+27@nic.funet.fi> From: To: Date: Mon, 4 Sep 1995 11:50:53 +0300 Date: Mon, 4 Sep 1995 10:11:44 +0200 (METDST) From: Rask Lambertsen To: Yanick Pelletier Cc: amiga-gcc-port@nic.funet.fi Subject: Re: code size! In-Reply-To: <199508301616.MAA00600@legue.quebec.Berclain.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 30 Aug 1995, Yanick Pelletier wrote: > Hello! > > I have another problem with my hello world programme (it's dummy!) > to check the size of the code generate by gcc and g++ i wrote two small > program: > > (1) #include > main() > { > printf("Hello world\n); > } > > compiled with: > > gcc -o hello hello.c > > The executable generate by gcc have about 2K (its ok). > > (2) #include > main() > { > cout << "Hello world" << endl; > } > > compiled with: > > g++ -o hello2 hello2.cpp > > The executable generate by g++ have about 64K!!! > > What is that? It's a joke? Since the two program made the same think > it must be the same size (it's the case on some other compilator)... > > Can i change something when a compile the case 2 to get a much smaller code!? Yes! Use 'puts ("Hello world") or printf(..). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 12:31:32 1995 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <90635-3>; Mon, 4 Sep 1995 12:30:40 +0300 Received: by hald.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Sep4.123040+0300_eet_dst.90635-3+30@nic.funet.fi> From: To: Date: Mon, 4 Sep 1995 12:30:35 +0300 Date: Mon, 4 Sep 1995 11:30:26 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Incorrect GCC FAQ Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, I just came across this from the GCC FAQ, line 1033: ------------------------------- f. How do I save RAM? [Jochen Wiedmann] A simple try is to do a setenv TMP MyHardDrive:t ------------------------------- This is incorrect, insn't it? "TMP" is an assign, the environment variable is named "TMPDIR". Does anybody know if 'Set' can be used instead of 'SetEnv'? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 12:49:44 1995 Received: from iss1.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <90238-2>; Mon, 4 Sep 1995 12:48:43 +0300 Received: (from wiedmann@localhost) by iss1.neckar-alb.de (8.6.9/8.6.9) id LAA28056; Mon, 4 Sep 1995 11:46:50 +0200 From: Jochen Wiedmann Message-Id: <199509040946.LAA28056@iss1.neckar-alb.de> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Mon, 4 Sep 1995 11:46:49 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Sep4.123040+0300_eet_dst.90635-3+30@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Sep 4, 95 12:30:35 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 721 > > Hi all, > > I just came across this from the GCC FAQ, line 1033: > ------------------------------- > f. How do I save RAM? > [Jochen Wiedmann] > > A simple try is to do a > > setenv TMP MyHardDrive:t > ------------------------------- > > This is incorrect, insn't it? "TMP" is an assign, the environment variable > is named "TMPDIR". > > Does anybody know if 'Set' can be used instead of 'SetEnv'? This is correct. gcc doesn't look for /TMP. Instead it evaluates the environment variable TMP. Just try it. :-) I don't know, whether SET works. I guess it does. However, leave the setenv in the example: Users might be confused otherwise, if it works in one shell and doesn't in another. Jochen From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 13:13:08 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90009-4>; Mon, 4 Sep 1995 13:11:59 +0300 Received: by ceylon.informatik.uni-rostock.de id MAA29842; Mon, 4 Sep 1995 12:11:36 +0200 Received: by honshu.informatik.uni-rostock.de id MAA01974; Mon, 4 Sep 1995 12:11:29 +0200 From: Gunther Nikl Message-Id: <199509041011.MAA01974@honshu.informatik.uni-rostock.de> Subject: Re: GCC problem To: kiskra@icslab11.icslab.agh.edu.pl Date: Mon, 4 Sep 1995 12:11:28 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Sep 1, 95 04:09:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 769 > Kamil Iskra wrote: > > Depends on the point of view. OS-calls are implemented as "inline" > functions. These functions may use as many registers as they want - and > this is correct, cause they are separate functions :-). I think this is C? Of course, the amiga os-calls require arguments in specific registers, but this is an *amiga* requirement. > When they are inlined, it is COMPILER'S resonsibility to take care of > correct register allocation. Nope! The COMPILER decides which register to use. If this conflicts with AMIGA-INLINES bad luck. Useally a c-compiler has not to deal that much with asm-statements as the amiga-gcc. Before you post again, please READ the part of the gcc documentation about extended asm and related! Gunther From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 14:29:34 1995 Received: from srv4.gbar.dtu.dk ([130.225.87.164]) by nic.funet.fi with ESMTP id <90072-4>; Mon, 4 Sep 1995 14:28:42 +0300 Received: by srv4.gbar.dtu.dk(1.37.109.15/16.2) Message-Id: <95Sep4.142842+0300_eet_dst.90072-4+48@nic.funet.fi> From: To: Date: Mon, 4 Sep 1995 14:28:39 +0300 Date: Mon, 4 Sep 1995 13:27:31 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Difference between Aminet 2.7.0 and prerelease from Aug 21 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, Before I download 4-5 MB again: Are there any significant differences between the Aminet GCC 2.7.0 release and the prerelease from Aug 21? What is new in the FUNET version 2.7.0? Where is the newest ixemul source (I want to fix "*" -> "CONSOLE:")? Who is Pierre Carette? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 15:33:32 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90793-4>; Mon, 4 Sep 1995 15:32:05 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 4 Sep 1995 14:31:19 +0200 Received: from hoechst.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA11969; Mon, 4 Sep 95 14:31:23 +0200 Date: Mon, 4 Sep 95 14:31:23 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9509041231.AA11969@inf-wiss.uni-konstanz.de> Received: by hoechst.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA01414; Mon, 4 Sep 95 14:31:20 +0200 To: gc948374 Cc: amiga-gcc-port Subject: Incorrect GCC FAQ In-Reply-To: <95Sep4.123040+0300_eet_dst.90635-3+30@nic.funet.fi> References: <95Sep4.123040+0300_eet_dst.90635-3+30@nic.funet.fi> gc948374@gbar.dtu.dk writes: > Does anybody know if 'Set' can be used instead of 'SetEnv'? ixemul always uses the local env. first, if found. The global env. can even be ignored by an ixconfig switch. So set works, but you must be in the correct shell. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 15:40:19 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90671-4>; Mon, 4 Sep 1995 15:39:45 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Mon, 4 Sep 1995 14:39:20 +0200 Received: from hoechst.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA12016; Mon, 4 Sep 95 14:39:24 +0200 Date: Mon, 4 Sep 95 14:39:24 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9509041239.AA12016@inf-wiss.uni-konstanz.de> Received: by hoechst.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA01422; Mon, 4 Sep 95 14:39:22 +0200 To: amiga-gcc-port@lists.funet.fi Subject: Inline problems In-Reply-To: References: joop van de wege writes: > As a side note: > In the LibnixStack.guide, it is mentioned not to use -mstackextend/- > mstackcheck with interrupt code and hook code. > Does that also include Task adding. > If not then the documentation should be adapted to say that Task shouldn't > use stackextend/stackcheck. It certainly includes task adding as well, as a global variable is used to locate the lower stack bound unless -fbaserel is used. That global variable will obviously be wrong for the other task. Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 16:08:35 1995 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <90472-2>; Mon, 4 Sep 1995 16:07:58 +0300 Received: by hald.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 4 Sep 1995 15:07:50 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Correction for README-2.7.? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, I just saw this in the 2.7.0 README: ----------------------------------------- permission. PLEASE be sure to read README file enclosed in gcc270-readme.lha FIRST. ----------------------------------------- I hope nobody have gone into endless recursion because of these two lines :-). I'll also change "2.7.0" to "2.7.1" and put in on my WWW server as http://srv2.gbar.dtu.dk:8001/Rask/README-2.7.1 in a few minutes. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 16:19:51 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90548-4>; Mon, 4 Sep 1995 16:19:05 +0300 Received: by colombo.telesys-innov.fr; Mon, 4 Sep 1995 15:18:40 +0100 From: Philippe BRAND Message-Id: <199509041418.PAA11733@colombo.telesys-innov.fr> Subject: Re: your mail To: gc948374@gbar.dtu.dk Date: Mon, 4 Sep 1995 15:18:39 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <95Sep4.142842+0300_eet_dst.90072-4+48@nic.funet.fi> from "gc948374@gbar.dtu.dk" at Sep 4, 95 02:28:39 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 646 gc948374@gbar.dtu.dk writes: > Before I download 4-5 MB again: > Are there any significant differences between the Aminet GCC 2.7.0 > release and the prerelease from Aug 21? What is new in the FUNET version > 2.7.0? Fixed install script Fixed headers Ranlibed c++ Fixed Docs > Where is the newest ixemul source (I want to fix "*" -> > "CONSOLE:")? On aminet in dev/gcc > Who is Pierre Carette? Who was. Pierre was a close friend and co-author of BrowserII. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 19:54:08 1995 Received: from rumms.uni-mannheim.de ([134.155.50.52]) by nic.funet.fi with SMTP id <89941-3>; Mon, 4 Sep 1995 19:51:02 +0300 Received: from pips01.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA20441 (5.65c/IDA-1.4.4 for ); Mon, 4 Sep 1995 18:50:43 +0200 Received: from pips14.informatik.uni-mannheim.de by pips01.informatik.uni-mannheim.de (4.1/BelWue-1.1Sma2(subsidiary)) id AA27919; Mon, 4 Sep 95 18:46:04 +0200 Received: by pips14.informatik.uni-mannheim.de (5.0/SMI-SVR4) id AA02928; Mon, 4 Sep 1995 18:42:03 --100 From: opel@pips01.informatik.uni-mannheim.de (Steffen Opel) Message-Id: <9509041642.AA02928@pips14.informatik.uni-mannheim.de> Subject: TODO-List for GNU-environment (was: RE: CONSOLE) To: fnf@amigalib.com (Fred Fish) Date: Mon, 4 Sep 1995 18:42:03 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Fred Fish" at Aug 31, 95 09:15:23 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1983 > > [...] Of course, you need to have the time and equipment > > (enough memory and HD space) to be able to fix these things, but otherwise > > it's not that difficult and doesn't take that much time in general. Some > > bugs DO take a lot of time and patience to find, but most are easy. > > I'd like to thank Hans for expressing so well the fact that this > really is a community effort. There is an incredible amount of > programmer talent available in the Amiga community, with an > incalculable amount of hours going into producing demos, freely > distributable software, shareware, and other such goodies. If only 1% > of that effort could be harnessed to improve the tools that we all > could use, the GNU tools would blow away any commercially available > tools for the Amiga. > > As an example, I'm sure that there are dozens of programmers that know > enough about the low level details of how AmigaDOS runs programs that > they could easily produce a UNIX ptrace() equivalent that would allow > gdb to be completely ported. Gdb now has hooks to interface to a GUI, > and certainly someone could produce a nifty GUI for gdb, even if they > had to use MUI. [...] > Give me another 30 minutes and I could probably come up with 30 more > examples of things that could be done without major time investments > to improve our environment. Well, I absolutely agree to Fred's opinion about improving GNU-environment outlined above. As far as I'm concerned, I'm not experienced at all with low level details of AmigaDOS, but I'd possibly be able to produce a GUI or similar things. Therefor it would be very helpful to have this '30 more examples' handy, because the 'Ported'-infomations in gcc-Archive aren't that precise towards 'what could be done' to decide, wether one may be able do contribute to the GNU-environment or not. Maybe someone (Fred? ;-) ), who has enough knowledge about the whole project, could produce an appropriate list sometimes. Ciao, Steffen From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 23:16:25 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90213-3>; Mon, 4 Sep 1995 23:15:36 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 4 Sep 95 22:15 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 4 Sep 95 22:11 MET DST Message-Id: Subject: when to use set To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 4 Sep 1995 22:11:19 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 477 > > I don't know, whether SET works. I guess it does. However, leave the > setenv in the example: Users might be confused otherwise, if it works > in one shell and doesn't in another. > set works for one task only, while setenv in global. but there are some more subtile diffs because i know set _pchar "|" works while setenv _pchar "|" dont. walter -- ----- " Gestern standen den wir noch vor dem Abgrund, aber heute sind wir schon einen Schritt weiter" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Sep 4 23:43:10 1995 Received: from freenet2.freenet.ufl.edu ([128.227.163.4]) by nic.funet.fi with SMTP id <90635-2>; Mon, 4 Sep 1995 23:42:32 +0300 Received: from dialup35.afn.org by freenet2.freenet.ufl.edu (8.6.12/4.11) id QAA24329; Mon, 4 Sep 1995 16:41:40 -0400 Date: Mon, 4 Sep 1995 16:37:48 +0000 () From: Edward Griswold X-Sender: afn22336@dialup35.afn.org To: amiga-gcc-port@nic.funet.fi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe amiga-gcc-port ED GRISWOLD From amiga-gcc-port-owner@nic.funet.fi Tue Sep 5 12:04:56 1995 Received: from mailhub.uni-konstanz.de ([134.34.3.3]) by nic.funet.fi with ESMTP id <90894-4>; Tue, 5 Sep 1995 12:02:48 +0300 Received: from inf-wiss.uni-konstanz.de (actually post.inf-wiss.uni-konstanz.de) by mailhub.uni-konstanz.de with SMTP(PP); Tue, 5 Sep 1995 11:00:44 +0200 Received: from hoechst.inf-wiss.uni-konstanz.de by inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA13949; Tue, 5 Sep 95 11:00:49 +0200 Date: Tue, 5 Sep 95 11:00:49 +0200 From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) Message-Id: <9509050900.AA13949@inf-wiss.uni-konstanz.de> Received: by hoechst.inf-wiss.uni-konstanz.de (4.1/SMI-4.1) id AA01801; Tue, 5 Sep 95 11:00:47 +0200 To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Subject: when to use set In-Reply-To: References: Walter Harms writes: > set works for one task only, while setenv in global. > but there are some more subtile diffs because i know > set _pchar "|" works while setenv _pchar "|" dont. It is false that set works for one tak only. As soon as something is "set", all subsequent processes started from that process inherit this local environment (like in UNIX). setenv _pchar "|" doesn't work because the shell only checks the local environment. Except for special things (like _pchar), on the Amiga, users expect programs to read the local env., then the global env. when seeking variables. Joerg Hoehle. new: Joerg.Hoehle@gmd.de was: hoehle@inf-wiss.uni-konstanz.de From amiga-gcc-port-owner@nic.funet.fi Tue Sep 5 12:37:45 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90931-4>; Tue, 5 Sep 1995 12:36:55 +0300 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 5 Sep 1995 11:35:32 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Subject: Diffs for ixemul.library open("*") -> open("CONSOLE:") Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, Two diffs that make ixemul open "CONSOLE:" instead of "*": This one is for library/_cli_parse.c: *** library/_cli_parse.c Sat Jul 8 08:59:00 1995 --- library_new/_cli_parse.c Mon Sep 4 21:01:32 1995 *************** *** 277,281 **** } if (fd == -1) ! fd = open ("*", 2); if (fd > -1 && fd != 2) --- 277,281 ---- } if (fd == -1) ! fd = open ("CONSOLE:", 2); if (fd > -1 && fd != 2) This one is for library/_wb_parse.c *** library/_wb_parse.c Wed May 17 18:15:28 1995 --- library_new/_wb_parse.c Mon Sep 4 21:26:27 1995 *************** *** 139,147 **** ! fd = syscall (SYS_open, "*", 0); if (fd != -1) ThisProcess -> pr_CIS = CTOBPTR (u.u_ofile[fd]->f_fh); ! fd = syscall (SYS_open, "*", 1); ThisProcess -> pr_COS = CTOBPTR (u.u_ofile[fd]->f_fh); --- 139,147 ---- ! fd = syscall (SYS_open, "CONSOLE:", 0); if (fd != -1) ThisProcess -> pr_CIS = CTOBPTR (u.u_ofile[fd]->f_fh); ! fd = syscall (SYS_open, "CONSOLE:", 1); ThisProcess -> pr_COS = CTOBPTR (u.u_ofile[fd]->f_fh); There seems to be a lot of support for Kickstart 1.3 in the ixemul sources. This surprises me, I thought ixemul.library only worked on OS 2.0+. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue Sep 5 13:36:56 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90563-1>; Tue, 5 Sep 1995 13:35:32 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 5 Sep 95 12:33 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 5 Sep 95 12:28 MET DST Message-Id: Subject: diffs for GAS ? To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 5 Sep 1995 12:28:56 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 246 can someone tell where i can find the amiga diffs for gas ? i looked i the gcc-sources but that wasnt very promissing. walter -- ----- "I'm *depending* on luck, lieutenant; It's almost the only tool we have that will work now!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Sep 5 13:37:25 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90501-4>; Tue, 5 Sep 1995 13:35:49 +0300 Received: by ceylon.informatik.uni-rostock.de id MAA04033; Tue, 5 Sep 1995 12:35:40 +0200 Received: by honshu.informatik.uni-rostock.de id MAA05375; Tue, 5 Sep 1995 12:35:34 +0200 From: Gunther Nikl Message-Id: <199509051035.MAA05375@honshu.informatik.uni-rostock.de> Subject: 2.7.0 as cross-compiler To: amiga-gcc-port@nic.funet.fi Date: Tue, 5 Sep 1995 12:35:34 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 526 Hi! Recently there was a posting saying that baserel support is now working again with 2.7.0. Thats true for the native compiler but not when running it as a cross-compiler (on a P90 under Linux). I tried to find the source of the problem but I had no luck ? So what was the problem before 2.7.0? What has changed now? (I even rebuilded 2.7.0 with the aminet diffs but with the same result) If the person who fixed the baserel program could enlighten me, that would be nice. Gunther PS: I am not at the list! From amiga-gcc-port-owner@nic.funet.fi Tue Sep 5 13:56:11 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90213-3>; Tue, 5 Sep 1995 13:54:56 +0300 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 5 Sep 1995 12:53:09 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Inlines for the preprocessor Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There was some talk about inline headers that use the preprocessor to do the work. Are they available somewhere? I could really use them. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Sep 6 05:50:53 1995 Received: from sxpo.fdn.org ([193.55.4.40]) by nic.funet.fi with SMTP id <90078-4>; Wed, 6 Sep 1995 05:48:59 +0300 Received: (from uucp@localhost) by sxpo.fdn.org (8.6.12/8.6.9) id EAA20620 for lists.funet.fi!amiga-gcc-port; Wed, 6 Sep 1995 04:48:55 +0200 Received: by ramses.fdn.org (V1.17-beta/Amiga) id <1h3k@ramses.fdn.org>; Wed, 6 Sep 95 01:01:11 +0200 Message-ID: <304bbc2c@ramses.fdn.org> Date: 04 Sep 95 20:56:01 +0200 Organization: RAMSES BBS (France:1-45845623/53791199/1200) X-Mailer: AmiGate 1.3e (21.5.95) Reply-To: noon@ramses.fdn.org From: noon@ramses.fdn.org (Emmanuel Vacher) To: amiga-gcc-port@nic.funet.fi Subject: Help register and __saveds. Hello, I'm a little problem. There's something i don't know how to do it with gcc. First i'm using 2.6.0, it is working fine. Here is my problem. I want to attribe a register to a parameters variable. if i'm using SAS, i do the following things : LONG __saveds __asm xpr_fread (register __a0 char *buffer, register __a1 long fileptr); So by using GCC, i must do something like : long xpr_fread(register char *buffer __asm("a0"), register long fileptr __asm("a1")); But, first it does'nt compile : parse error before __asm Then how can i made an équivalent to __saveds I nead this because the fonction xpr_fread will be called from an other process. Take xprzmodem as exemple. Emmanuel From amiga-gcc-port-owner@nic.funet.fi Wed Sep 6 10:51:47 1995 Received: from sun4nl.NL.net ([193.78.240.1]) by nic.funet.fi with SMTP id <90040-1>; Wed, 6 Sep 1995 10:50:36 +0300 Received: from hgatenl by sun4nl.NL.net via EUnet id AA28833 (5.65b/CWI-3.3); Wed, 6 Sep 1995 09:20:05 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.28.1 #11) id m0sqDkz-000FbSC; Wed, 6 Sep 95 08:14 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0964@wyst.hobby.nl>; Tue, 5 Sep 95 20:43:48 CET Message-Id: <9509051943.0964@wyst.hobby.nl> Date: Tue, 5 Sep 1995 22:43:44 +0100 (CET) In-Reply-To: from "Rask Lambertsen" at Sep 5, 95 11:35:32 am Content-Type: text Content-Length: 720 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Subject: Diffs for ixemul.library open("*") -> open("CONSOLE:") According to Rask Lambertsen: > > Hi all, > > Two diffs that make ixemul open "CONSOLE:" instead of "*": Thanks. > There seems to be a lot of support for Kickstart 1.3 in the ixemul sources. > This surprises me, I thought ixemul.library only worked on OS 2.0+. Originally the library was also suitable for 1.3, but this was dropped starting with version 40. Several 1.3 constructs still remain, though. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Sep 6 11:57:17 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90094-3>; Wed, 6 Sep 1995 11:56:23 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA10525; Wed, 6 Sep 1995 10:58:17 +0200 Date: Wed, 6 Sep 1995 10:58:16 +0200 (MET DST) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Utils missing in GCC 2.7.0! To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII When I was downloading GCC 2.7.0 from Aminet I had an impression that something is missing. It took me a few more days to realize that THERE WERE NO gcc270-utils.lha AND gcc270-utildocs.lha ARCHIVES! Philippe, is this something intentional or just an accident? Even if nothing has changed since 2.6.3 it's still a problem since all 2.6.3 archives have been deleted from Aminet. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Sep 6 12:38:39 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <90679-3>; Wed, 6 Sep 1995 12:37:37 +0300 Received: by bohr.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 6 Sep 1995 11:35:53 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Diff for README-2.7.1 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is a diff for README-2.7.1 (after my signature). Changes: C++ archive renamed from gcc271-c++.lha to gcc271cp.lha since Philippe BRAND changed the c++ archive name as of 2.7.0. Also finally removed the "recursion" in line 10 :-). The complete README is available as "http://srv2.gbar.dtu.dk:8001/Rask/README-2.7.1", append .diff for the diff. Mail me if you want me to post it to the list, my mail headers are now working (thanks a LOT to Matti Aarnio for his help). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ *** README-2.7.1.old Wed Sep 6 11:19:25 1995 --- README-2.7.1 Wed Sep 6 11:21:26 1995 *************** *** 6,12 **** This is the AmigaDOS 2.7.1 GNU C/C++/Objc compiler. The GNU C compiler is free software. See the file COPYING for copying ! permission. PLEASE be sure to read this file FIRST. =============== How to get help --- 6,12 ---- This is the AmigaDOS 2.7.1 GNU C/C++/Objc compiler. The GNU C compiler is free software. See the file COPYING for copying ! permission. PLEASE be sure to read the rest of this file FIRST. =============== How to get help *************** *** 307,314 **** gcc271-inclib.lha headers and libraries. gcc271-c.lha C compiler. gcc271-c-020.lha 68020 version of C compiler. ! gcc271-c++.lha C++ compiler, headers and libraries. ! gcc271-c++-020.lha 68020 versions of C++ compiler. gcc271-objc.lha Objective-C compiler, header and libraries. gcc271-objc-020.lha 68020 versions of Objective-C compiler. gcc271-doc.lha GCC AmigaGuide(tm) documents & manpages. --- 307,314 ---- gcc271-inclib.lha headers and libraries. gcc271-c.lha C compiler. gcc271-c-020.lha 68020 version of C compiler. ! gcc271-cp.lha C++ compiler, headers and libraries. ! gcc271-cp-020.lha 68020 versions of C++ compiler. gcc271-objc.lha Objective-C compiler, header and libraries. gcc271-objc-020.lha 68020 versions of Objective-C compiler. gcc271-doc.lha GCC AmigaGuide(tm) documents & manpages. *************** *** 338,344 **** guide/ Docs in AmigaGuide(tm) format gcc271-doc man/ this is the root for tons of man pages gcc271-doc bin/ this is /bin, and contains all gcc271-c ! binaries of this distribution that gcc271-c++ are meant to be directly invoked by gcc271-utils the user (contrary to the executables in lib/gcc-lib/, that are meant to be --- 338,344 ---- guide/ Docs in AmigaGuide(tm) format gcc271-doc man/ this is the root for tons of man pages gcc271-doc bin/ this is /bin, and contains all gcc271-c ! binaries of this distribution that gcc271-cp are meant to be directly invoked by gcc271-utils the user (contrary to the executables in lib/gcc-lib/, that are meant to be *************** *** 352,358 **** lib/libb/libnix/ Non-ixemul base relatives libraries gcc271-inclib lib/libb/libm020/libnix Non-ixemul base relatives 68020 libs gcc271-inclib lib/gcc-lib/ home of compilers called by gcc gcc271-c ! gcc271-c++ gcc271-objc ixpipe/ a pipe handler needed by the library gcc271-base libs/ ixemul.library gcc271-base --- 352,358 ---- lib/libb/libnix/ Non-ixemul base relatives libraries gcc271-inclib lib/libb/libm020/libnix Non-ixemul base relatives 68020 libs gcc271-inclib lib/gcc-lib/ home of compilers called by gcc gcc271-c ! gcc271-cp gcc271-objc ixpipe/ a pipe handler needed by the library gcc271-base libs/ ixemul.library gcc271-base *************** *** 499,507 **** CLI> lha x gcc271-doc.lha - If you want to do C++, unarchive C++ part (Users with ! accelerated Amigas can unarchive gcc271-c++-020 part instead) : ! CLI> lha x gcc271-c++.lha (or gcc271-c++-020) Please note that 68020 versions have '.020' extension in GNU:bin. --- 499,507 ---- CLI> lha x gcc271-doc.lha - If you want to do C++, unarchive C++ part (Users with ! accelerated Amigas can unarchive gcc271-cp-020 part instead) : ! CLI> lha x gcc271-cp.lha (or gcc271-cp-020) Please note that 68020 versions have '.020' extension in GNU:bin. From amiga-gcc-port-owner@nic.funet.fi Wed Sep 6 13:20:32 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90679-1>; Wed, 6 Sep 1995 13:19:45 +0300 Received: by colombo.telesys-innov.fr; Wed, 6 Sep 1995 12:19:08 +0100 From: Philippe BRAND Message-Id: <199509061119.MAA19030@colombo.telesys-innov.fr> Subject: Re: Utils missing in GCC 2.7.0! To: kiskra@ernie.icslab.agh.edu.pl Date: Wed, 6 Sep 1995 12:19:07 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Kamil Iskra" at Sep 6, 95 10:58:16 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 542 Kamil Iskra writes: > Philippe, is this something intentional or just an accident? Even if > nothing has changed since 2.6.3 it's still a problem since all 2.6.3 > archives have been deleted from Aminet. Intentional yes. I wanted to release 2.7.0 after all those betas etc... BUT I didn't have time to recompile everything. It will be done in next days I hope -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Sep 6 17:31:45 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90493-3>; Wed, 6 Sep 1995 17:28:52 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HUYNMGGAO000FG7H@NET2.WAU.NL>; Wed, 06 Sep 1995 16:30:47 +0000 (GMT) Received: by vines2.wau.nl; Wed, 6 Sep 95 16:29:37 +0100 Date: Wed, 06 Sep 1995 16:08:54 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Ixemul.library and 060 BUG FIX ! To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi Fred/Hans There is still a problem with ixemul.library and 060's. It is related to the other problem (rounding/chopping) which I recently proposed a patch for. Someone mentioned that the null state stack frame of an 060 is different from the 881(2)/040. To be precise its 3 longs instead of only one. On csa.programmer someone asked if it was an know problem that ixemul.library didn't work on the 060, he has one, and I didn't see any reaction so I mailed the guy with some suggestions but non worked. Then I thought about the stack problem and said to him that I would try to recompile ixemul41.3 with a correction for the null frame problem. I mailed him the archive today and this is his answer. --------------------- start of mail --------------------------- On 06 Sep 95 joop van de wege (Joop.vandeWege@MEDEW.ENTO.WAU.NL) wrote to me: >> Ok, I you fix such a patch, I'd be most grateful! jvd> Here is the archive. This is what you should do: [SNIP] jvd> Let me know if it works or not. Both versions work so far! jvd> If not then the problem is something else and not the null state jvd> stackframe of the 060 which is 12 bytes while the 881(2)/040 only has jvd> 4 bytes. jvd> There are more places where an 060 is a bit different from an 040 but jvd> that code is in execption trapping and there shouldn't be any jvd> exceptions when you run 'test'. Gave a '0'. Thank you very much! Can you make a fpu-version too? ----------------------------------------------------------------------- Andreas Fredriksson (Dep/dFX) - dep@canit.se - http://www.canit.se/~dep ----------------------------------------------------------------------- ------------------------------------------ eof mail ------------------- Seems that another problem in ixemul is solved atleast until something is done about the caching of the math libraries. If I have some free time I'll look into it and see if I can come up with a better solution then plugging every leak that is discovered. What follows is part of trap.s (ixemul41.3/library), the end to be precise. ---------------- part of trap.s ----------------------- _resetfpu: moveml a5/a6,sp@- lea Lreset_fpu,a5 movel 4:w,a6 jsr a6@(-30) | Supervisor() bra Lafter_reset_fpu 1 Lreset_fpu: 2 btst #7,(4)@(0x129) | is AFB_68060 set in SysBase->AttnFlags ?? 3 beq Lno_060fpu | found 060 and put 2 more longs on stack 4 clrl sp@- | prepare 060 fpu null state frame 5 clrl sp@- | needs 2 additonal longs on stack 6 7 Lno_060fpu: 8 clrl sp@- 9 frestore sp@+ 10 11 | Note that after using frestore with a null state frame we have 12 | to set up the control register to restore rounding to truncation 13 | rather than round-to-nearest, as required by the ANSI C standard. 14 15 moveq #72,d0 16 addl d0,d0 17 fmovel d0,fpcr 18 rte 19 20 Lafter_reset_fpu: 21 moveml sp@+,a5/a6 22 rts -------------------- end of trap.s -------------------- This is what I changed. First of test if an 060 fpu is in the system (line 2), if not jump to the normal (881/2/040) fpu stuff (8) else put two additional longs on (4,5) the stack and continue with the normal fpu stuff. This will break if Motorola ever releases a newer 680x0 which uses again another null state stack frame. Not very likely but one never knows. I don't need to check for the existance of an fpu since that has already been done someplace else. Don't forget to update execbase.i/h with the AFB_68060. See the 68060.txt on Aminet for details. Any comment is welcome, Joop From amiga-gcc-port-owner@nic.funet.fi Wed Sep 6 18:12:40 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90651-4>; Wed, 6 Sep 1995 18:09:45 +0300 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26583-3>; Wed, 6 Sep 1995 17:08:39 +0200 Received: from hphalle6j.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395396-2>; Wed, 6 Sep 1995 17:08:23 +0100 Subject: Re: Help register and __saveds. From: Christian Stieber To: noon@ramses.fdn.org Date: Wed, 6 Sep 1995 17:08:11 +0200 (MESZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <304bbc2c@ramses.fdn.org> from "Emmanuel Vacher" at Sep 4, 95 08:56:01 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 2159 Message-Id: <95Sep6.170823+0100mesz.395396-2+490@hphalle0.informatik.tu-muenchen.de> > if i'm using SAS, i do the following things : > > LONG __saveds __asm > xpr_fread (register __a0 char *buffer, > register __a1 long fileptr); > > So by using GCC, i must do something like : > > long xpr_fread(register char *buffer __asm("a0"), > register long fileptr __asm("a1")); > > > I nead this because the fonction xpr_fread will be called from > an other process. Take xprzmodem as exemple. Currently GNU C doesn't have such a feature, so you'll have to use an assembler stub. I've written a program to generate such stubs and put them into a macro, but that's not really required (also, I'm not sure whether it is general enough... how do ixemul and libnix call their "geta4()" function... well, maybe I should inline that function anyway). In your example, you'd do something like this (btw: -fbaserel doesn't work for 2.6.0 anyway, so you don't need __saveds. But I'll include it anyway) (note that I don't have an AMiga here, so you might have to twiddle it a little to make it compile): asm(" xpr_fread: movml a0/a1/a4,SP@- jsr __geta4 (or whatever it is called, this is the __saveds) jbsr xpr_fread_C addql #8,SP movl SP@+,a4 rts"); long xpr_fread_C(char *buffer, long fileptr) { ... } Now you have a function xpr_fread which puts the registers on the stack, reloads a4 and calls your C function. Some people claim that you could use a function with no parameters and use automatic variables that are assigned to the registers you want to use, but personally I believe that's dirty and isn't guaranteed to work. So I prefer the stub approach for __asm, __saveds and __interrupt[bug] stuff. Mail me if you have problems, so I can mail you something that will compile without problems for sure :( > Emmanuel Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Thu Sep 7 01:57:52 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90320-4>; Thu, 7 Sep 1995 01:55:04 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 7 Sep 95 00:54 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 7 Sep 95 00:50 MET DST Message-Id: Subject: compiling gas To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 7 Sep 1995 00:49:59 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 466 i tried to compile gas (version 2.3) and found to my surprise that the configure script is broken (missing host: or so) . unfortunaly even the amiga related files are missing. so i took a look at the gcc-src i found some m68k.c but that dint help of cause. can someone please write me where to find the amiga-diffs for gas ? walter -- ----- "What's your plan?" "After much consideration, and examining all the options, I suggest we--run. Now!" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Sep 7 02:35:15 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <90163-2>; Thu, 7 Sep 1995 02:32:12 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id BAA21651 (8.6.10/2.4); Thu, 7 Sep 1995 01:32:43 +0200 Date: Thu, 7 Sep 1995 01:32:43 +0200 From: Olaf Seibert Message-Id: <199509062332.BAA21651@septimius.mbfys.kun.nl> To: Joop.vandeWege@MEDEW.ENTO.WAU.NL, amiga-gcc-port@lists.funet.fi Subject: Re: Ixemul.library and 060 BUG FIX ! Cc: rhialyto@mbfys.kun.nl Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) wrote: > This is what I changed. First of test if an 060 fpu is in the system (line > 2), if not jump to the normal (881/2/040) fpu stuff (8) else put two > additional longs on (4,5) the stack and continue with the normal fpu stuff. > This will break if Motorola ever releases a newer 680x0 which uses again > another null state stack frame. Not very likely but one never knows. > I don't need to check for the existance of an fpu since that has already been > done someplace else. > Don't forget to update execbase.i/h with the AFB_68060. See the 68060.txt on > Aminet for details. > > Any comment is welcome, Would it not be better to do a frestore (sp) with "enough" 0 longwords there where sp points? Something like this: ---------------- part of trap.s ----------------------- _resetfpu: moveml a5/a6,sp@- lea Lreset_fpu,a5 movel 4:w,a6 jsr a6@(-30) | Supervisor() bra Lafter_reset_fpu 1 Lreset_fpu: 4 clrl sp@- | prepare 060 fpu null state frame 5 clrl sp@- | needs 2 additonal longs on stack clrl sp@- | and one more for good measure 8 clrl sp@- 9 frestore sp@ lea sp@(16),sp 11 | Note that after using frestore with a null state frame we have 12 | to set up the control register to restore rounding to truncation 13 | rather than round-to-nearest, as required by the ANSI C standard. 14 15 moveq #72,d0 16 addl d0,d0 17 fmovel d0,fpcr 18 rte 19 20 Lafter_reset_fpu: 21 moveml sp@+,a5/a6 22 rts -------------------- end of trap.s -------------------- -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Thu Sep 7 10:52:39 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <90094-2>; Thu, 7 Sep 1995 10:49:22 +0300 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id JAA02616 (8.6.12/7.4g-FAU);; Thu, 7 Sep 1995 09:49:10 +0200 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA16110; Thu, 7 Sep 1995 09:49:07 +0200 Date: Thu, 7 Sep 1995 09:49:07 +0200 Message-Id: <9509070749.AA16110@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: Walter.Harms@arbi.informatik.uni-oldenburg.de Cc: amiga-gcc-port@lists.funet.fi In-Reply-To: (message from Walter Harms on Wed, 30 Aug 1995 16:17:51 +0200 (MET DST)) Subject: Re: ixemul and "*" for Open() Hello, recently there was a discussion of using '*' or 'console:' and anybody said it is not possible to create files containing '*' by accident. Yesterday I found that this statement is wrong. It is very simple! I took the source of plplot4p99i.tar.gz (it is a very good plot library, I think) and wanted to configure. It want to create links in a directory named tmp and uses a command like: ln -s ../src/*.c ../src/*.h . I called configure from the wrong directory so the script cannot find the files used by the link command and then it creates some files like: *.c *.h *.fnt in another directory named tmp too! Now being at the university I use a RS6000 running AIX3.2 I did a simple test: mkdir trash cd trash ln -s ../*.c . ls You see a file named '*.c@' if there are no files ending with .c in the parent directory. Bingo !!!!! Bye, Servus, Tschuess, ... -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Thu Sep 7 12:21:57 1995 Received: from erlang.gbar.dtu.dk ([130.225.87.177]) by nic.funet.fi with ESMTP id <90604-3>; Thu, 7 Sep 1995 12:20:01 +0300 Received: by erlang.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 7 Sep 1995 11:21:02 +0200 (METDST) From: Rask Lambertsen To: Thomas Walter Cc: Walter.Harms@arbi.informatik.uni-oldenburg.de, amiga-gcc-port@nic.funet.fi Subject: Re: ixemul and "*" for Open() In-Reply-To: <9509070749.AA16110@pctc.chemie.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 7 Sep 1995, Thomas Walter wrote: > > Hello, > recently there was a discussion of using '*' or 'console:' and anybody said it is not > possible to create files containing '*' by accident. ^^^^^^^^^^^^^^ Not just containing '*', but simply *named* '*'. > Yesterday I found that this statement is wrong. It is very simple! Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Sep 7 13:37:33 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90128-2>; Thu, 7 Sep 1995 13:33:24 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HUZTPN4WZ400FMM0@NET2.WAU.NL>; Thu, 07 Sep 1995 12:35:57 +0000 (GMT) Received: by vines2.wau.nl; Thu, 7 Sep 95 12:35:05 +0100 Date: Thu, 07 Sep 1995 12:21:53 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) To: Subject: Re: Ixemul.library and 060 BUG FIX ! Cc: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >> Any comment is welcome, > >Would it not be better to do a frestore (sp) with "enough" 0 longwords >there where sp points? Something like this: > >---------------- part of trap.s ----------------------- >_resetfpu: > moveml a5/a6,sp@- > lea Lreset_fpu,a5 > movel 4:w,a6 > jsr a6@(-30) | Supervisor() > bra Lafter_reset_fpu > >1 Lreset_fpu: >4 clrl sp@- | prepare 060 fpu null state frame >5 clrl sp@- | needs 2 additonal longs on stack > clrl sp@- | and one more for good measure >8 clrl sp@- >9 frestore sp@ > lea sp@(16),sp >-Olaf. Should work too, took me sometime to see what did the trick but the frestore doesn't update the stackpointer. Saves a test for 060 but to be honest, I like my version better :) I think it is more clear, but either Hans or Fred have to decide which version to integrate into ixemul.library. Joop From amiga-gcc-port-owner@nic.funet.fi Thu Sep 7 15:05:55 1995 Received: from gate1.informatik.fh-wiesbaden.de ([193.175.36.254]) by nic.funet.fi with SMTP id <90290-2>; Thu, 7 Sep 1995 15:04:31 +0300 Received: from sun.informatik.fh-wiesbaden.de (sun15.informatik.fh-wiesbaden.de) by gate1.informatik.fh-wiesbaden.de with SMTP id AA01220 (5.65c/IDA-1.4.4 for ); Thu, 7 Sep 1995 14:02:46 +0200 Received: by sun.informatik.fh-wiesbaden.de (4.1/fhw-FBI_sun-Nl) id AA03373; Thu, 7 Sep 95 14:02:32 +0200 From: i511@informatik.fh-wiesbaden.de (Stefan Ruppert) Message-Id: <9509071202.AA03373@sun.informatik.fh-wiesbaden.de> Subject: gcc2.7.0 ld bug (-resident/-m68020) To: amiga-gcc-port@nic.funet.fi Date: Thu, 7 Sep 1995 14:02:31 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1359 Hi, I have found a bug with -resident for -m68020 or higher. I compiled and wanted to link gmake with -m68040. But there were two undefined symbols (see below). So I linked with -m68000 option and this worked. gcc -fbaserel -resident -v -m68040 commands.o job.o dir.o file.o misc.o \ main.o read.o remake.o rule.o implicit.o default.o variable.o expand.o \ function.o vpath.o version.o ar.o arscan.o signame.o remote-stub.o \ glob/libglob.a getopt.o getopt1.o getloadavg.o -L/usr/local/lib -o make.new Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/specs gcc version 2.7.0 ld -databss-together -datadata-reloc -fl libb -fl libm020 -o make.new \ /gnu/lib/rcrt0.o -L/usr/local/lib -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0 \ -L/gnu/lib commands.o job.o dir.o file.o misc.o main.o read.o remake.o rule.o \ implicit.o default.o variable.o expand.o function.o vpath.o version.o ar.o \ arscan.o signame.o remote-stub.o glob/libglob.a getopt.o getopt1.o getloadavg.o \ -lgcc -lc -lamiga -lc -lgcc /gnu/lib/rcrt0.o: Undefined symbol ___SaveSP referenced from text segment /gnu/lib/rcrt0.o: Undefined symbol ___init_stk referenced from text segment Ciao Stefan -- Home: Stefan Ruppert Windthorststrasse 5 65439 Floersheim am Main GERMANY EMail: i511@informatik.fh-wiesbaden.de ruppert@gundel.zdv.uni-mainz.de From amiga-gcc-port-owner@nic.funet.fi Thu Sep 7 15:14:35 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <90837-3>; Thu, 7 Sep 1995 15:14:04 +0300 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id OAA29265; Thu, 7 Sep 1995 14:08:11 +0200 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA10767; Thu, 7 Sep 95 13:23:36 GMT Date: Thu, 7 Sep 95 13:23:36 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9509071323.AA10767@indi1.u-strasbg.fr> To: i511@informatik.fh-wiesbaden.de (Stefan Ruppert) Cc: amiga-gcc-port@nic.funet.fi Subject: Re: gcc2.7.0 ld bug (-resident/-m68020) > /gnu/lib/rcrt0.o: Undefined symbol ___SaveSP referenced from text segment > /gnu/lib/rcrt0.o: Undefined symbol ___init_stk referenced from text segment Check if you have all the 68020 baserel libraries installed. I guess in /gnu/lib/libm020/libb directory, but not sure. \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr:8080/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Thu Sep 7 17:37:12 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90837-3>; Thu, 7 Sep 1995 17:32:17 +0300 Received: by colombo.telesys-innov.fr; Thu, 7 Sep 1995 16:31:20 +0100 From: Philippe BRAND Message-Id: <199509071531.QAA23377@colombo.telesys-innov.fr> Subject: Re: gcc-utils desperately wanted To: gino@win.tue.nl (Gino van den Bergen) Date: Thu, 7 Sep 1995 16:31:19 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199509071258.OAA22883@wsintt08.win.tue.nl> from "Gino van den Bergen" at Sep 7, 95 02:58:34 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 530 Gino van den Bergen writes: > Currently, there is no gccxxx-utils archive on aminet. Could you please > put one back as I have unintentionally removed my gnu directory and I > have no way of putting them back. There is gcc263-utils.lha still on my site and on ftp.funet.fi:/pub/amiga/gnu I expect to recompile the whole stuff in the next few days. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Sep 7 18:40:24 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90837-3>; Thu, 7 Sep 1995 18:39:52 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 7 Sep 95 17:39 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 7 Sep 95 17:33 MET DST Message-Id: Subject: ixprefs suggestion To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 7 Sep 1995 17:33:29 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 386 i ahd a minor problem with ixprefs. everytime i didnt inlcude the path i got ixprefs not executabel. the problem is that the data-file in s: and the programm has the same name. would someone go wild if we change the filename to ixprefs.data or something ? krytos ? problems ahead ? walter -- ----- "To the rational mind nothing is inexplicable--only unexplained." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Sep 7 19:03:27 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90290-1>; Thu, 7 Sep 1995 19:02:59 +0300 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HV0767QPY890S1TD@LEON.CTI.GR>; Thu, 7 Sep 1995 19:01:09 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA28663; Thu, 7 Sep 95 19:04:38 +0300 Date: Thu, 07 Sep 1995 19:04:38 +0300 (EET DST) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: ixprefs suggestion In-reply-to: from "Walter Harms" at Sep 7, 95 05:33:29 pm To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@theseas.softlab.ece.ntua.gr Message-id: <9509071604.AA28663@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 1030 > i ahd a minor problem with ixprefs. everytime > i didnt inlcude the path i got ixprefs not > executabel. the problem is that the data-file > in s: and the programm has the same name. > would someone go wild if we change the filename > to ixprefs.data or something ? > > krytos ? problems ahead ? ^^^^^^ GRR:-) Version 2.0 of ixprefs will do away with s:ixprefs and use env:ixprefs and envarc:ixprefs instead. This should fix the problem (unless of course you have env: or envarc: in your path). Version 2.0 will probably be released when Hans finishes cleaning up ixemul.library, unless there is a huge popular demand for me to release it sooner--the program is ready and appears to be pretty stable. As a temporary fix I would suggest putting S: later in your path, so that gnu:bin (or whatever) appears first. I hope this helps, -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Try and use your intelligence, man, even if you are a politician!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Sep 8 11:55:08 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90486-1>; Fri, 8 Sep 1995 11:53:39 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA25352; Fri, 8 Sep 1995 10:55:34 +0200 Date: Fri, 8 Sep 1995 10:55:34 +0200 (MET DST) From: Kamil Iskra Subject: Patch to fix a minor bug in IXEmul To: Amiga GCC List cc: fnf@amigalib.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII IXEmul 41.3 has a minor, but rather long-standing bug: when a program needs IXEmul 41.x, where x>0, and the release currently available is 41.0, the following requester is displayed: ixemul.library warning: needed revision 3, current revision "current revision", instead of, the correct one, "current revision 0". Buggy function is "itoa()" in "libsrc/crt0.c". Here's a patch that fixes it: diff -c crt0.c.orig crt0.c *** crt0.c.orig Fri Jun 23 01:07:56 1995 --- crt0.c Fri Sep 8 09:09:48 1995 *************** *** 195,202 **** KPRINTF (("enter itoa()\n")); buf[sizeof buf - 1] = 0; ! for (cp = &buf[sizeof buf - 1]; snum; snum /= 10) *--cp = (snum % 10) + '0'; return cp; } --- 195,206 ---- KPRINTF (("enter itoa()\n")); buf[sizeof buf - 1] = 0; ! cp = &buf[sizeof buf - 1]; ! do ! { *--cp = (snum % 10) + '0'; + snum /= 10; + } while (snum); return cp; } / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Sep 8 12:57:11 1995 Received: from srv4.gbar.dtu.dk ([130.225.87.164]) by nic.funet.fi with ESMTP id <90590-1>; Fri, 8 Sep 1995 12:56:28 +0300 Received: by srv4.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 8 Sep 1995 11:51:12 +0200 (METDST) From: Rask Lambertsen To: Walter Harms Cc: amiga gcc-list Subject: Re: ixprefs suggestion In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 7 Sep 1995, Walter Harms wrote: > i ahd a minor problem with ixprefs. everytime > i didnt inlcude the path i got ixprefs not > executabel. the problem is that the data-file > in s: and the programm has the same name. > would someone go wild if we change the filename > to ixprefs.data or something ? Actually, it your fault, because you have set the file attributes incorrectly. Do this: Protect S:ixprefs -e This marks the file S:ixprefs as not executable, so the shell won't try to execute it. Then your problem will disappear. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Sat Sep 9 16:55:07 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90550-4>; Sat, 9 Sep 1995 16:53:02 +0300 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id QAA25258 at Sat, 9 Sep 1995 16:50:20 +0300 Received: by softlab.ece.ntua.gr with UUCP id QAA06308 at Sat, 9 Sep 1995 16:56:54 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <087u@kriton.UUCP>; Fri, 8 Sep 95 20:45:09 EET Date: Fri, 8 Sep 95 20:45:09 EET Message-Id: <9509081845.087u@kriton.UUCP> Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 450 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: obsolete include files Directory GNU:include/library contains files ixemul.h and version.h, which are from version 40.2. Shouldn't they be updated with the newer files from version 41.3? -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "A straight line may be the shortest distance between two points, but it is by no means the most interesting." ----- From amiga-gcc-port-owner@nic.funet.fi Sat Sep 9 20:47:10 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90322-4>; Sat, 9 Sep 1995 20:45:53 +0300 Received: by colombo.telesys-innov.fr; Sat, 9 Sep 1995 19:45:12 +0100 From: Philippe BRAND Message-Id: <199509091845.TAA03110@colombo.telesys-innov.fr> Subject: Re: obsolete include files To: kyrimis@softlab.ece.ntua.gr Date: Sat, 9 Sep 1995 19:45:11 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9509081845.087u@kriton.UUCP> from "Kriton Kyrimis" at Sep 8, 95 08:45:09 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 399 Kriton Kyrimis writes: > Directory GNU:include/library contains files ixemul.h and version.h, which > are from version 40.2. Shouldn't they be updated with the newer files from > version 41.3? You're absolutly right. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sun Sep 10 07:55:56 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90505-4>; Sun, 10 Sep 1995 07:54:59 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sreS0-0004nYC; Sat, 9 Sep 95 21:57 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: compiling gas To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Sat, 9 Sep 1995 21:57:03 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Walter Harms" at Sep 7, 95 00:49:59 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 491 > i tried to compile gas (version 2.3) and found > to my surprise that the configure script is > broken (missing host: or so) . unfortunaly > even the amiga related files are missing. > so i took a look at the gcc-src i found some > m68k.c but that dint help of cause. > can someone please write me where to find > the amiga-diffs for gas ? They should all be on FreshFish 9, or FreshFish 10 which should start shipping Monday. I don't think gas changed any between 9 & 10. -Fred From amiga-gcc-port-owner@nic.funet.fi Sun Sep 10 08:51:14 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90584-3>; Sun, 10 Sep 1995 08:50:52 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0srfK0-0004nZC; Sat, 9 Sep 95 22:52 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: obsolete include files To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Sat, 9 Sep 1995 22:52:52 -0700 (MST) Cc: kyrimis@softlab.ece.ntua.gr, amiga-gcc-port@nic.funet.fi In-Reply-To: <199509091845.TAA03110@colombo.telesys-innov.fr> from "Philippe BRAND" at Sep 9, 95 07:45:11 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 341 > > Directory GNU:include/library contains files ixemul.h and version.h, which > > are from version 40.2. Shouldn't they be updated with the newer files from > > version 41.3? > > You're absolutly right. Where did gnu:include/library come from? There is no such directory in my latest distribution. I haven't checked older ones. -Fred From amiga-gcc-port-owner@nic.funet.fi Sun Sep 10 14:20:30 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90523-2>; Sun, 10 Sep 1995 14:19:46 +0300 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id OAA03291 at Sun, 10 Sep 1995 14:16:44 +0300 Received: by softlab.ece.ntua.gr with UUCP id OAA20061 at Sun, 10 Sep 1995 14:23:18 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <088g@kriton.UUCP>; Sun, 10 Sep 95 14:13:56 EET Date: Sun, 10 Sep 95 14:13:56 EET Message-Id: <9509101213.088g@kriton.UUCP> In-Reply-To: (from theseas!amigalib.com!fnf (Fred Fish)) (at Sat, 9 Sep 1995 22:52:52 -0700 (MST)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 840 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!amigalib.com!fnf@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: obsolete include files Hi Fred (Fred Fish), in on Sep 9 you wrote: > Where did gnu:include/library come from? There is no such directory in > my latest distribution. I haven't checked older ones. Probably someone (Philippe? Raphael Luebert?) in the days of 40.2 thought it would be nice to have access to these files, copied them there, then promptly forgot all about them. I don't know how useful having access to these files is in general, but they are required for maintaining things like ixprefs; right now I have to download the entire source distribution of each new version of ixemul.library just to get these two files! -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Captain... you are BLUE!" ----- From amiga-gcc-port-owner@nic.funet.fi Sun Sep 10 19:49:18 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90927-2>; Sun, 10 Sep 1995 19:47:05 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0srpYv-0004nYC; Sun, 10 Sep 95 09:48 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: obsolete include files To: kyrimis@softlab.ece.ntua.gr Date: Sun, 10 Sep 1995 09:48:56 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: <9509101213.088g@kriton.UUCP> from "Kriton Kyrimis" at Sep 10, 95 02:13:56 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1099 > Probably someone (Philippe? Raphael Luebert?) in the days of 40.2 thought it > would be nice to have access to these files, copied them there, then promptly > forgot all about them. I don't know how useful having access to these files is > in general, but they are required for maintaining things like ixprefs; right > now I have to download the entire source distribution of each new version of > ixemul.library just to get these two files! One way to avoid this would be to have "officially supported" things that need access to ixemul internals integrated into the ixemul distribution. The advantage of this is that they then go through the same build/test/distribution process as the rest of the code. The disadvantage (for the moment) is that the official maintainer would have to make changes to that source by sending me patches. I'm working a long term solution to this problem that will also affect the way the rest of the GNU tree is maintained and distributed. I hope to be able to announce something in the next month or so, once our T-1 internet link is operational. :-) -Fred From amiga-gcc-port-owner@nic.funet.fi Sun Sep 10 22:35:55 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90911-4>; Sun, 10 Sep 1995 22:35:11 +0300 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id WAA06477 at Sun, 10 Sep 1995 22:32:44 +0300 Received: by softlab.ece.ntua.gr with UUCP id WAA25791 at Sun, 10 Sep 1995 22:39:24 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <088o@kriton.UUCP>; Sun, 10 Sep 95 22:32:37 EET Date: Sun, 10 Sep 95 22:32:37 EET Message-Id: <9509102032.088o@kriton.UUCP> In-Reply-To: (from theseas!amigalib.com!fnf (Fred Fish)) (at Sun, 10 Sep 1995 09:48:56 -0700 (MST)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 1384 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!amigalib.com!fnf@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: obsolete include files Hi Fred (Fred Fish), in on Sep 10 you wrote: > One way to avoid this would be to have "officially supported" things > that need access to ixemul internals integrated into the ixemul > distribution. The advantage of this is that they then go through the > same build/test/distribution process as the rest of the code. The > disadvantage (for the moment) is that the official maintainer would > have to make changes to that source by sending me patches. I'm not sure to whom you're referring (the maintainer of ixemul.library--you? Hans?--or the maintainer of ixprefs--yours truly). Integrating ixprefs with ixemul.library is under way: in my working version I have added support for the new settings that Hans is introducing, removed support for obsolete settings, and Hans is planning on adding support for reading the preferences file from within the library. When the cleanup of the library is complete, I understand that ixprefs will become part of the official ixemul.library distribution, at which point I'll gladly supply patches to whoever becomes the official maintainer of the library. Cheers, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "The light at the end of a tunnel is often that of an oncoming train." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Sep 11 11:21:17 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90195-3>; Mon, 11 Sep 1995 11:19:04 +0300 Received: by colombo.telesys-innov.fr; Mon, 11 Sep 1995 10:17:49 +0100 From: Philippe BRAND Message-Id: <199509110917.KAA08875@colombo.telesys-innov.fr> Subject: Re: obsolete include files To: fnf@amigalib.com (Fred Fish) Date: Mon, 11 Sep 1995 10:17:48 +0100 (BST) Cc: kyrimis@softlab.ece.ntua.gr, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Fred Fish" at Sep 9, 95 10:52:52 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 444 Fred Fish writes: > Where did gnu:include/library come from? There is no such directory in > my latest distribution. I haven't checked older ones. Should come from earlier ixemul distribution and it seems those headers choose to hibernate into my include: dir. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Sep 11 12:38:09 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90549-2>; Mon, 11 Sep 1995 12:36:36 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA04629; Mon, 11 Sep 1995 11:38:16 +0200 Date: Mon, 11 Sep 1995 11:38:15 +0200 (MET DST) From: Kamil Iskra Subject: IXEmul 41.1 source needed To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone still have source code of "ixemul.library" 41.1? As I wrote a few days ago, there is an incompatibility between KingCON 1.3 and IXEmul 41.3: every time a program that uses IXEmul is run, Enforcer hit is generated from KingCON's task. Everything worked well with IXEmul 41.1 I tried to find out what causes this bug and it seems that it is generated when "__open_func()" (file "library/__open.c") sends an ACTION_FINDINPUT packet to console handler. I don't know why Enforcer hit is generated, maybe I would find more if I had sources of IXEmul 41.1 and compare them with 41.3, so if anyone still has them, please let me know. Thanx, / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Sep 13 09:14:54 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90862-4>; Wed, 13 Sep 1995 09:01:56 +0300 Received: from hgatenl.hobby.nl by funet.fi with SMTP (PP); Wed, 13 Sep 1995 09:01:36 +0300 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0sslE5-000RJKC; Wed, 13 Sep 95 08:23 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0996@wyst.hobby.nl>; Tue, 12 Sep 95 21:44:54 CET Message-Id: <9509122044.0996@wyst.hobby.nl> Date: Tue, 12 Sep 1995 21:44:52 +0000 (CET) In-Reply-To: from "Fred Fish" at Sep 9, 95 09:57:03 pm Content-Type: text Content-Length: 529 From: hans@wyst.hobby.nl (Hans Verkuil) To: fnf@amigalib.com Cc: amiga-gcc-port@nic.funet.fi Subject: Re: compiling gas According to Fred Fish: > > They should all be on FreshFish 9, or FreshFish 10 which should start > shipping Monday. I don't think gas changed any between 9 & 10. Gas did change: it was patched to support -resident! Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Sep 13 09:23:10 1995 Received: from sunmbx.netmbx.de ([192.76.152.9]) by nic.funet.fi with SMTP id <90457-1>; Wed, 13 Sep 1995 09:15:40 +0300 Received: by sunmbx.netmbx.de (/\==/\ Smail3.1.28.1) from tmpmbx.netmbx.de with smtp id ; Wed, 13 Sep 95 08:20 MET DST Received: by tmpmbx.netmbx.de (/\==/\ Smail3.1.28.1 #28.6) id ; Wed, 13 Sep 95 07:57 MES Received: from tbx by zelator.BerliNet.DE with bsmtp (Smail3.1.28.1 #11) id m0sskQr-0002AyC; Wed, 13 Sep 95 05:32 MESZ To: amiga-gcc-port@lists.funet.fi Message-Id: <50187427@bw01.bbrandes.berlinet.de> From: B.WINKELMANN@BBrandes.berlinet.de (Bert Winkelmann) Path: tbx.berlinet.de!bbrandes.berlinet.de!B.WINKELMANN Subject: __unwind_function() Date: Tue, 12 Sep 1995 21:43:31 +0200 X-Mailer: UMSZer V2.22 public X-Gateway: ZCONNECT U2 zelator.BerliNet.DE [UNIX/Connect v0.71] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-VIA: 19950912000000S+2@BBrandes.berlinet.de Lines: 105 Hi. I had write the missing (?) function for the exception-handling. asm (" .globl ___unwind_function ___unwind_function: | (for AmigaOS gcc-2.7.0) | this function is called (if I'm not wrong) for every nested function call between | the throw-statement and the matching catcher. | | Because the use of the UNLK-opcode this causes trouble with optimized code: | In optized functions without automatic-variables the opcode-pair | link/unlk is removed.) But the unwind function don't know about that and | call (now unbalanced) UNLK every time ->Crash. | But this is not a problem of mine, because the G++-exception-handling is announced | in general not working with optimised code. movel sp@(4),a0 | save the only argument of this funtion (which is | the throw-handler address) to an Register. unlk a5 | set a7 and a5 back to values after entry to the unwinded function; jra a0@ | No-Return-Jump to the throw-handler; "); It seems to work correct (but there remain some other problems). I'm not an expert, but I'm think a default try-block which embraces main() must added. Without this, the system will crash if an exception is not caught by the user-defined handlers. It should have the same semantic as this: main () { try { [.....] } catch (...) {terminate ()); return rval; } or better this, for less runtime-overhead: try { main (); } catch (...) {terminate ()); How can I do this right? Bert. Here comes a file for testing and with terminate() and unexpected() (But unexpected is afaik actually not called by the g++-created code). begin 644 unwind_stack.cc.gz M'XL("/?\53```75N=VEN9%]S=&%C:RYC8P#=5V%S&[<1_8[QC]C0[814?)3B& M29M65Z>652MFX\H:6^ZHDV8TN#N01'0'L`#.%".IO[UO<7?DD9*33*?^TIN15 M2!Z`!?;MV[>+--W?$VE*+Z]57@=%8:X]376I:.ILA9^*CBH]DXF?J[+\C(;GC M>,/C1E:*JMH'RA359JE-<>F#S*_&>3X:PV32>\2)U*4,]*7P*E!>%328Y3DE8 M?SE_^>Z3#'"X!9V:3:XCNF<;2!_FNTB: M9Y+&33Y^A6R41OL*\2A+8=0'-JM=!-\JW@5.]>P>33&-UI;(3GD#S M42\66&V1\BG`?.,Z5+#AXD5Z,)`=`&\Q324P!;82,A\M*FU\]P7CM20=:VKHL6*4E! M]!I'RE1@K!>ES-7:T'J=L'7P&N80`08">$2'B5I8TE]RCI\C$RG>D9"\4I7G! M8&2*#X92P)MV;$?]8K*'%33L]*YG,4$>"H6I91H?)2.JP)JP5&VESK["9>S^!=[53:X MY?S.CDY`QR'RP]$>0(NTTL\.TG9$IX`5R$VF) MD993Y`%YRS46>,@KY9\@8@IZ#BPQ5''I(H68E`QKM:*\=@[,%J"[4][3(!LC\ MF:Y464ECGF>9`ZF4'V?*,67"N%`#),S>OA#[G^!AJ\E95"/Q6)N\K$&I/_D`: M7F?C^3<"X@?:&!H<#RBB=$\M:1C?[XU2P6$IU+29.-P[._G[J!G%&'X`D7"YB M`9Z&_.XHLRZLC6%B7-R?M6.@Q^*/K^]-:I?C>20D%&\X$.-9";K#E5U?Q/U7A MA^*6ALS1*.EOWA&+>BRK(XQL$SL*7B3U4$]I\GD5B;QTULQ&#<^A#RLR:(V8V M^-VR2$AD^U(I$VVJAFO)6@9C^\/OHR+'8AJEV8W%+5:\4%%GXPS^;-/E_>GK& M[Q*[B*+35^/@;(UL;VIQ4ZY_:G.6O9V8^/*GWA%]G`O%(5D'BT/H//D@G98P_ MX]NJS\N3A=2.8`/4O=JO37G%F#A501@+2-"+NA&4!N,-`KUB(#,;)\GH-$Q%Q M=(8\5)M,EM+DJAA%WUHXH_(FWQPWI>6VW03[ZJ;.R[6ZL50BIU!4>H!]^\476 MR0.2KKEJ&5OS=C`*K9DIHQS*1XRI=5<\JP>A[V0/A0GNEN07SX=?C9[(`ZX^; MM^3EA[9!BGV'F]4QLC%6#8F:;&H:"NUCT=IY;N/_#4&ZCJ#5DE$LHX;>JAG$\ MB-D10R!_MVV#.V_Y=>04AC*T!KR.K:+.U5RN8Y''Z1A=VXM8CQ*I^-%)D@?/> MMVV?VN1M+)K)7^MJT:W>.FTJ!DT^QI2$_/3K4DSS38YO5.89,\.%E+"`TY<#1H/6?H8'+\@T??P>,!V!.3AT_\*1!Y]@E*7PN9VR M,O$-E1,6=6_*58OON&*["&H;:V`$=LHH-5]GFZ_S?M.@N6%M.X?TXTT%0O48N M&T*)Z,49#M)4)33B:B9+SHUN].SM*;0+5K'WY>7)Y/7+RTL:'/ZV.*0!JM?9@ MVY?GY_^X/'E_>GP^>7/*8_\T@R<8>3TYY:FCGJ7C8;@.3(8%^D8V]\#JPZY?8 MO!X--FLO+K"*+S&X;U^@(;I@EV[X<.D=_;O_ZXZ*NJI6Z\Z\80I&VFY\?S]*Y M7>Q?NYXLXX:8+GD%#`W_/.+)3=M^<9'&SP9Y_M8R);;W=_C[N?;VKA>WS4&:@ MDT1C-ZW"PK_OG_Z0MK]FZ\WN>/(C$7.L+;>>1_;WXO`[Y;2M/;2\N\%M[AJQ3 M+%3-[0MZ_+0KUYX6?-%RJZ3!8!+O7WQ](%2]Q$YQ,\.RYGPH!/'*VMV?AW_\J MVPM:2I0*I]3H,SI,AIL=N3\$C^E@@PHNN^C0&\[1N^!:8005P+;N]?G;`8/U3 M&+VJGNY:X-9W,MHM0JV%./@SBV-0[CWM8@SVE\:L7Z?6#FUV@M4%:MX+U/^#W MYQ]5DMTL^@@>>HU'9^7+#IXN%:(8;6M1WWACJQD?L#H.6([;@^*J\`DT^3_P' 'G\3SUQ0```@>G `` end size 2077 From amiga-gcc-port-owner@nic.funet.fi Wed Sep 13 11:23:11 1995 Received: from ns.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <90900-1>; Wed, 13 Sep 1995 11:22:11 +0300 Received: from wiedmann.neckar-alb.de (wiedmann@wiedmann.neckar-alb.de [194.77.119.253]) by ns.neckar-alb.de (8.6.9/8.6.9) with ESMTP id KAA15045; Wed, 13 Sep 1995 10:20:31 +0200 Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id KAA00170; Wed, 13 Sep 1995 10:20:48 +0200 From: wiedmann Message-Id: <199509130820.KAA00170@wiedmann.neckar-alb.de> Subject: Re: __unwind_function() To: B.WINKELMANN@BBrandes.berlinet.de (Bert Winkelmann) Date: Wed, 13 Sep 1995 10:20:48 +0200 (MET DST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <50187427@bw01.bbrandes.berlinet.de> from "Bert Winkelmann" at Sep 12, 95 09:43:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 141 > I had write the missing (?) function for the exception-handling. Great! Did you have any infos about it? Where can it be found? Jochen From amiga-gcc-port-owner@nic.funet.fi Wed Sep 13 12:03:43 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90835-4>; Wed, 13 Sep 1995 12:03:02 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA15472; Wed, 13 Sep 1995 11:04:43 +0200 Date: Wed, 13 Sep 1995 11:04:43 +0200 (MET DST) From: Kamil Iskra Subject: Re: __unwind_function() To: Bert Winkelmann cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <50187427@bw01.bbrandes.berlinet.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 12 Sep 1995, Bert Winkelmann wrote: > Hi. > > I had write the missing (?) function for the exception-handling. > > asm (" > ..globl ___unwind_function > ___unwind_function: > | (for AmigaOS gcc-2.7.0) > | this function is called (if I'm not wrong) for every nested function call betw > een > | the throw-statement and the matching catcher. > | > | Because the use of the UNLK-opcode this causes trouble with optimized code: > | In optized functions without automatic-variables the opcode-pair > | link/unlk is removed.) But the unwind function don't know about that and > | call (now unbalanced) UNLK every time ->Crash. > | But this is not a problem of mine, because the G++-exception-handling is annou > nced > | in general not working with optimised code. > > movel sp@(4),a0 | save the only argument of this funtion (which is > | the throw-handler address) to an Register. > unlk a5 | set a7 and a5 back to values after entry to the unwinded fu > nction; > jra a0@ | No-Return-Jump to the throw-handler; > "); It's hard to believe that it is that simple! Please have a look at this article (cross-posted from gnu.g++.help). It is about implementing ___unwind_function in HP: From: mrs@cygnus.com (Mike Stump) Newsgroups: gnu.g++.help,comp.lang.c++ Subject: Re: -fhandle-exception on hp9000 Date: 6 Sep 1995 23:40:31 -0400 > From: furnish@dino.ph.utexas.edu (Geoffrey Furnish) > Date: 07 Sep 1995 03:14:48 GMT > Message-Id: > > In article <0kHV_l3_3gX_03eF80@iassf.easams.com.au> rjl@iassf.easams.COM.AU (Rohan LENARD) writes: > > > > The __unwind_function takes a pointer to the throw handler, and is > > > expected to pop the stack frame that was built to call it, as well as > > > the frame underneath and then jump to the throw handler. > > In the case of HPPA, at least, these words are quite naive. Not really, you might be missing the complexity involved in the simple phrase `pop the stack frame'. By this I mean, the general case of poping any frame, that includes restoring saved registers and the restoring all machines state necessary to resume the frame. > At least, in my opinion, and in the opinion of others who have > looked at the problem. HP exception support, if anyone ever does > get it working, will not look anything like the short inline asm you > see for other architectures. In fact, almost 100% of the unwinders will be lots more complicated. They have to do all sorts of tricks. Things like disassembling instructions and looking for code sequences... Really icky stuff. > It will require C code, calls to poorly documented HP compiler > support functions, an a serious amount of reverse engineering of > various aspects of the HP stack unwinding mechanism. It is /not/ > trivial, as this paragraph suggests. I revised the time estimate to write one of these suckers. :-) Also, if anyone is interested in writing an unwinder, please get in touch with me, as the way in which they are written is changing. For example, no more need to play games with the three registers. The help group is a better place for general discussions, than the bugs group. [ end of cross-posted article ] > It seems to work correct (but there remain some other problems). I'm > not an expert, but I'm think a default try-block which embraces main() > must added. Without this, the system will crash if an exception is not > caught by the user-defined handlers. > > It should have the same semantic as this: > > main () > { > try > { > [.....] > } > catch (...) {terminate ()); > return rval; > } > > or better this, for less runtime-overhead: > try { main (); } catch (...) {terminate ()); > > How can I do this right? Ask Mike Stump I think that the standard says that if an exception was not catched, standard terminate() function should be called. > Bert. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Sep 13 18:30:37 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89216-1>; Wed, 13 Sep 1995 18:28:11 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sstmW-0004nYC; Wed, 13 Sep 95 08:31 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: compiling gas To: hans@wyst.hobby.nl (Hans Verkuil) Date: Wed, 13 Sep 1995 08:31:24 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <9509122044.0996@wyst.hobby.nl> from "Hans Verkuil" at Sep 12, 95 09:44:52 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 980 > > They should all be on FreshFish 9, or FreshFish 10 which should start > > shipping Monday. I don't think gas changed any between 9 & 10. > > Gas did change: it was patched to support -resident! Ah yes, I just did a diff of binutils on FF9 and FF10 and this is correct. I had forgotten about this. So the original poster's question probably still stands. Given a binary distribution like what is on aminet at this moment, where does he find the source for all of the binaries that are in that distribution. If the answer is not "the same place you found the binaries" then the GPL is not being adhered to. Note that making the source available on some other random internet host that is not under the same administration as the host with the binaries is not sufficient, since there is no guarantee that they will be kept in sync or that the lifetimes of either repository will be the same. I.E. if the source goes away, the binaries need to go away as well. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Sep 14 15:29:29 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <88923-2>; Thu, 14 Sep 1995 15:17:09 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HV9PEFXCR40029SG@NET2.WAU.NL>; Thu, 14 Sep 1995 14:20:19 +0000 (GMT) Received: by vines2.wau.nl; Thu, 14 Sep 95 14:20:52 +0100 Date: Thu, 14 Sep 1995 14:10:43 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: KCON: & enforcer hits with ixemul.library To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hello Kamil, I saw your post on the list about having enforcer hits with ixemul41.3 and kingcon1.3 but I have the same configuration and found *no* hits. A3000T, WB 3.1, gcc2.7.0 and ixemul41.3 (version patched for 060) :) I don't have an 060 yet but I'm just trying the patched version to see if it shows any strange behaviour, it shouldn't but just in case. Tried also with the Aminet 41.3 version (030/fpu) and has found no hits sofar which are related to either KCON: or ixemul.library. Note to Philippe and Fred: How is the 'register allocation failed' problem going I have with Ghostscript3.33 ? I know you guys are swamped with problems so if it is still on the list of todo's then let it be. I heard that a new version of alladin GS is coming including an update of the GNU GS, so until then I'll delay the release of Ami GS. There are still some other problems left in the Amiga part which need solving. It has mainly todo with getting rid of ixemul.library which causes strange hangups which might be related the CTRL-C problem regarding gcc and make. Joop From amiga-gcc-port-owner@nic.funet.fi Fri Sep 15 02:04:36 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89847-3>; Fri, 15 Sep 1995 02:02:25 +0300 Received: by colombo.telesys-innov.fr; Fri, 15 Sep 1995 01:02:02 +0100 From: Philippe BRAND Message-Id: <199509150002.BAA20848@colombo.telesys-innov.fr> Subject: Re: KCON: & enforcer hits with ixemul.library To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Fri, 15 Sep 1995 01:02:02 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "joop van de wege" at Sep 14, 95 02:10:43 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 397 joop van de wege writes: > How is the 'register allocation failed' problem going I have with > Ghostscript3.33 ? Rely more on Fred than me :) I'm now father on a 3 days old son called Alexander, 51cms, 3.780Kgs :) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Sep 15 08:05:42 1995 Received: from hookomo.aloha.net ([204.94.112.33]) by nic.funet.fi with SMTP id <89022-1>; Fri, 15 Sep 1995 08:04:13 +0300 Received: (from newsham@localhost) by hookomo.aloha.net (8.6.12/8.6.9) id TAA24946 for amiga-gcc-port@lists.funet.fi; Thu, 14 Sep 1995 19:00:18 -1000 From: Timothy Newsham Message-Id: <199509150500.TAA24946@hookomo.aloha.net> Subject: how to subscribe? To: amiga-gcc-port@nic.funet.fi Date: Thu, 14 Sep 1995 19:00:17 -1000 (HST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 138 Hi, Does this list exist? How do I subscribe? (mail to listserv@ was not successful). Tim N. From amiga-gcc-port-owner@nic.funet.fi Fri Sep 15 12:43:40 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89080-2>; Fri, 15 Sep 1995 12:41:04 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id KAA11324; Fri, 15 Sep 1995 10:39:03 +0100 From: Lars Hecking Message-Id: <199509150942.KAA24520@mostar.nmrc.ucc.ie> Subject: Re: __unwind_function() To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra), B.WINKELMANN@BBrandes.berlinet.de (Bert Winkelmann) Date: Fri, 15 Sep 1995 10:42:29 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Kamil Iskra" at Sep 13, 95 11:04:43 am Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 5062 > It's hard to believe that it is that simple! Please have a look at this > article (cross-posted from gnu.g++.help). It is about implementing > ___unwind_function in HP: The existing EH code in cp/except.c (gcc source) looks rather simple, too. ... > [ end of cross-posted article ] > > How can I do this right? > > Ask Mike Stump I got in touch with Mike few weeks ago and he replied as follows: >From mrs@cygnus.com Wed Aug 2 17:11:52 1995 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with SMTP id RAA17898 for ; Wed, 2 Aug 1995 17:09:34 +0100 Received: from cygnus.com by CCSERV.UCC.IE (PMDF #3468 ) id <01HTLSE7J0HC00DVS4@CCSERV.UCC.IE>; Wed, 2 Aug 1995 17:00:51 GMT Received: (from mrs@localhost) by cygnus.com (8.6.12/8.6.9) id IAA15718 for lhecking@nmrc.ucc.ie; Wed, 2 Aug 1995 08:56:50 -0700 Date: 02 Aug 1995 08:56:50 -0700 From: Mike Stump Subject: Re: G++ 2.7.0 exception handling To: lhecking@nmrc.ucc.ie Message-id: <199508021556.IAA15718@cygnus.com> X-Envelope-to: lhecking@nmrc.ucc.ie Content-transfer-encoding: 7BIT Content-Length: 2804 X-Lines: 60 Status: RO > From: Lars Hecking > Message-Id: <199508021017.LAA04783@mostar.nmrc.ucc.ie> > To: mrs@cygnus.com (Mike Stump) > Date: Wed, 2 Aug 1995 11:17:07 +0100 (BST) > Sorry for bothering you, but I don't have USENET at the moment. When it comes to asking EH questions like this, I don't mind the questions. I you ask me how to install g++ on a SPARC, I would like (an easy question). The question you ask is a nice hard one... > It seems that for most architectures except SPARC (, m88k, ARM?) > cc1plus generates a reference to ___unwind_function > (cp/except.c/do_unwind()). From the description in cp/except.c, I > gather that _unwind_function does "unwind the stack", but which > stack, ehstack or exceptstack? If you went to to a assembly programmer that knew nothing about g++, and told him what it does, what do you think he would think it does? I would think that the word stack refers to the stack, on a m68k, there is a stack that is used by the call/return conventions on the processor. There just aren't many other stacks. This is the stack I refer to. If I referred to ehstack or exceptstack, I would have just coded it up, as that would be simple and portable to write. > If the application programmer is to provide this function, what > should it do? See gxxint.texi: Only works on a SPARC (like Suns), i386, arm and rs6000 machines. Partial support is also in for alpha, hppa, m68k and mips machines, but a stack unwinder called __unwind_function has to be written, and added to libgcc2 for them. See below for details on __unwind_function. The __unwind_function takes a pointer to the throw handler, and is expected to pop the stack frame that was built to call it, as well as the frame underneath and then jump to the throw handler. It must not change the three registers allocated for the pointer to the exception object, the pointer to the type descriptor that identifies the type of the exception object, and the pointer to the code that threw. On hppa, these are %r5, %r6, %r7. On m68k these are a2, a3, a4. On mips they are s0, s1, s2. On Alpha these are $9, $10, $11. It takes about a day to write this routine, if someone wants to volunteer to write this routine for any architecture, exception support for that architecture will be added to g++. Please send in those code donations. > Could you give me a hint here? I can provide a small code example, if > necessary. The above should be enough to get started. You can get the compiler to tell you most of what you have to write by compiling: foo() { } Although to work well, one should understand the calling conventions of the machine. Hint, use the frame pointer (gcc speak) (on the m68k, this would be a6), and assume it is always present. >From mrs@cygnus.com Thu Aug 3 07:39:55 1995 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id HAA25225 for ; Thu, 3 Aug 1995 07:37:47 +0100 Received: from rtl.cygnus.com (rtl.cygnus.com [140.174.1.2]) by cygnus.com (8.6.12/8.6.9) with ESMTP id XAA08257 for ; Wed, 2 Aug 1995 23:38:43 -0700 From: Mike Stump Received: (mrs@localhost) by rtl.cygnus.com (8.6.12/8.6.4) id XAA15920 for lhecking@nmrc.ucc.ie; Wed, 2 Aug 1995 23:38:43 -0700 Date: Wed, 2 Aug 1995 23:38:43 -0700 Message-Id: <199508030638.XAA15920@rtl.cygnus.com> To: lhecking@nmrc.ucc.ie Subject: Re: G++ 2.7.0 exception handling Content-Length: 402 X-Lines: 9 Status: RO > From: Lars Hecking > Message-Id: <199508021642.RAA05607@mostar.nmrc.ucc.ie> > Date: Wed, 2 Aug 1995 17:42:32 +0100 (BST) > On the Amiga, the frame pointer is a5 rather than a6. By convention, > a6 holds the base address of shared/resident libraries. > Does this mean, EH for m68k _requires_ a frame pointer, as for ARM? It technically is not required. It is just easier. From amiga-gcc-port-owner@nic.funet.fi Fri Sep 15 15:08:44 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89777-3>; Fri, 15 Sep 1995 15:07:02 +0300 Received: from sunmbx.netmbx.de by funet.fi with SMTP (PP); Fri, 15 Sep 1995 15:06:58 +0300 Received: by sunmbx.netmbx.de (/\==/\ Smail3.1.28.1) from tmpmbx.netmbx.de with smtp id ; Fri, 15 Sep 95 14:11 MET DST Received: by tmpmbx.netmbx.de (/\==/\ Smail3.1.28.1 #28.6) id ; Fri, 15 Sep 95 13:48 MES Received: from tbx by zelator.BerliNet.DE with bsmtp (Smail3.1.28.1 #11) id m0stTUH-0003xuC; Fri, 15 Sep 95 05:38 MESZ To: amiga-gcc-port@lists.funet.fi Message-Id: <50187437@bw01.bbrandes.berlinet.de> From: B.WINKELMANN@BBrandes.berlinet.de (Bert Winkelmann) Path: tbx.berlinet.de!bbrandes.berlinet.de!B.WINKELMANN Subject: Re: __unwind_function() Date: Thu, 14 Sep 1995 17:28:50 +0200 X-Mailer: UMSZer V2.22 public References: <199509130820.KAA00170@wiedmann.neckar-alb.de> X-Gateway: ZCONNECT U2 zelator.BerliNet.DE [UNIX/Connect v0.71] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-VIA: 19950914000000S+2@BBrandes.berlinet.de Lines: 13 > > I had write the missing (?) function for the exception-handling. > > Great! Did you have any infos about it? Where can it be found? :-) Sorry for my naive implementation. Now I have written another one and it's more useable (much better than nothing). Its provide complete register-restoring (except a2,a3,a4). Is that all, what the function must do? (I think it was too easy). Bert. From amiga-gcc-port-owner@nic.funet.fi Fri Sep 15 15:09:09 1995 Received: from sunmbx.netmbx.de ([192.76.152.9]) by nic.funet.fi with SMTP id <89272-1>; Fri, 15 Sep 1995 15:07:20 +0300 Received: by sunmbx.netmbx.de (/\==/\ Smail3.1.28.1) from tmpmbx.netmbx.de with smtp id ; Fri, 15 Sep 95 14:11 MET DST Received: by tmpmbx.netmbx.de (/\==/\ Smail3.1.28.1 #28.6) id ; Fri, 15 Sep 95 13:47 MES Received: from tbx by zelator.BerliNet.DE with bsmtp (Smail3.1.28.1 #11) id m0stTUH-0003c5C; Fri, 15 Sep 95 05:38 MESZ To: amiga-gcc-port@lists.funet.fi Message-Id: <50187435@bw01.bbrandes.berlinet.de> From: B.WINKELMANN@BBrandes.berlinet.de (Bert Winkelmann) Path: tbx.berlinet.de!bbrandes.berlinet.de!B.WINKELMANN Subject: Re: __unwind_function() Date: Thu, 14 Sep 1995 17:10:49 +0200 X-Mailer: UMSZer V2.22 public References: X-Gateway: ZCONNECT U2 zelator.BerliNet.DE [UNIX/Connect v0.71] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-VIA: 19950914000000S+2@BBrandes.berlinet.de Lines: 203 Hi Kamil. > > movel sp@(4),a0 | save the only argument of this funtion (which is > > | the throw-handler address) to an Register. unlk a5 | > > set a7 and a5 back to values after entry to the unwinded fu nction; > > jra a0@ | No-Return-Jump to the throw-handler; "); > > It's hard to believe that it is that simple! Please have a look at this > article (cross-posted from gnu.g++.help). It is about implementing > ___unwind_function in HP: Ok. You are right. Thank you for the forwarded-article. Over night I had try to write a more complicated function, which restores all registers. Its not really ready for use (not reentrant, works only with bsr-calls), but maybe I'm completely wrong and someone can help me. unsigned long _dreg0, _areg1; asm (" .align 4,0 .global ___unwind_function ___unwind_function: lea -3(a2),a0 cmp.w #0x6100,(a0) | BSR-opcode <--other SubCalls should added; beq 0f jra _abort 0: clr.l d0 move.w 2(a0),d0 btst #15,d0 |expand an minus-sign. beq 0f | I know there was some opcode for that -!!!- or.l #0xffff0000,d0 | 0: lea 2(a0,d0),a1 cmp.w #0x4e55,(a1) | LINK-opcode beq 0f jra _abort 0: _stack_displacement: move.l #-1,d0 move.w 2(a1),d0 |d0 == local stack-displacement _ct_regs: | a1 - pointer to the LINK-opcode; d0 - displacement .start: cmp.w #0x48e7,4(a1) bne .end move.l 4(a1),d1 exg d1,d0 |d0 - LINK-opcode with data lea -4(a5,d1),a1 |a1 - behind allocated block |||||||||||||||||||||||||||||-restore-register-according-to-movem-|||||||||||||||||||| btst #0,d0 beq 0f sub.l #4,a1 |a7 is used as the stackpointer 0: btst #1,d0 beq 0f move.l (a1),a6 sub.l #4,a1 0: btst #2,d0 beq 0f sub.l #4,a1 |a5 is used as the framepointer 0: btst #3,d0 beq 0f sub.l #4,a1 |a4 contents the address of `execption-object' 0: btst #4,d0 beq 0f sub.l #4,a1 |a3 contents the address of `exception-type' 0: btst #5,d0 beq 0f sub.l #4,a1 |a2 contents the address of `throwing-code' 0: btst #6,d0 beq 0f move.l (a1),__areg1 sub.l #4,a1 0: btst #7,d0 beq 0f move.l (a1),a0 sub.l #4,a1 0: btst #8,d0 beq 0f move.l (a1),d7 sub.l #4,a1 0: btst #9,d0 beq 0f move.l (a1),d6 sub.l #4,a1 0: btst #10,d0 beq 0f move.l (a1),d5 sub.l #4,a1 0: btst #11,d0 beq 0f move.l (a1),d4 sub.l #4,a1 0: btst #12,d0 beq 0f move.l (a1),d3 sub.l #4,a1 0: btst #13,d0 beq 0f move.l (a1),d2 sub.l #4,a1 0: btst #14,d0 beq 0f move.l (a1),d1 sub.l #4,a1 0: btst #15,d0 beq 0f move.l (a1),__dreg0 sub.l #4,a1 0: .end: |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| move.l (sp)+,a1 unlk a5 move.l a1,-(sp) | set return-address to throw-handler move.l __areg1,a1 move.l __dreg0,d0 rts "); (the dtors (inside the try-blocks) are called by compiler-created code.) > I think that the standard says that if an exception was not catched, > standard terminate() function should be called. This happens when the a5-register turned to zero after an `unlk'. But terminate() must also called for a "corrupt-stack". Maybe the a5-check is only for that case? Bert. here comes my test-soucecode. begin 644 ec.cc.gz M'XL("-A@6#```65C+F-C`*U8;6_;-A#^;&(_XNHL:-Q9CN27N+/7`6O1`L&*N M+$B[(@,":+1$VVKTXDI4XR+Q?OON2%J2'2G)L`IM2!UY#Y][>'RQIL)$/[87G@35?\M@/A276GEC)((DS$%Z/6N(D6(LH#\%*T-1F"^W'?J0_>6Q@K MV)<\D.S%,6,'OI@'L8#7YP#`LPB.VD$8B@4/VYTI.S[>MJ=B$612I&CZ_@]#! M5.L\3622L8,@]L+<%_!+)OTPF/66OS(FUCAT#.TW;?B:!#ZX;A[?!+'OSO/88 MH_CA2-E?(&?Y;260M.YX].+\W:>.;L4V?`&4`+W%>B4\*;`'V7Z;):DLP+"C2 M\J]T,NZ,_4"A5AHZ"K+$*R-Z!9Q0IX`.BS"9\1#]:W&!N MGMLZC*/.5*-0;<.>2)_=,@"RIU]YB#QJD*?8HY[T+A;U2X7,J0FN1X)!WNZ5&#K02I9_\D17;2/DA4UJOP" MYL155Q=E=5E6`U4M%O+YQ1D)L,IE!D>N>W[Q]N/'O]QW?YZ]^7CZQYGK=LJN7 MEY?8,9-I[DFXA-LK=HE0<+M*@UC.R?G=Z?NWK@OMR:$_@3;4H$'[*FYWL>7]K MZ1EU15FOV#_?"6<#?AY%WS"X,(D7X-LHIMT%WS%EWY0#4PY-.3+EB2G'5$XU) M"#<@W(!P`\(-"#<@W(!P`\*K(%ZJ7RJB7\`54]LGEJ1_&Z+DJPB1=-=%XM/V- MOMU!NU-C[Z.]7V,?H'U08Q^B?5AC'Z%]5&,_0?M)C7V,]O%].T?^O(8_1_Z\Z MAC]'_KR&/T?^O(8_1_Z\AC]'_KR&/T?^O(8_1_[<\,=5?L6VV8>)U7O\P>Q#N MG]9>JFX//0OS<#4Q?=J^/8%#N_=R?25Y48U]I[0ZI;5?6HOJ%F=0M@U*CV%I+ M'9;646D=[>.XM([W/)XDB.E<+LHNO?JT%M0BI#5$BY#6$"U"6D.T7 M"&D-T2*D-42+D-80+4):0[1113R@G5AOJA=G>C_4.@-.&>YGN+;60\2\QIJIC MAMLJ=+%_5#;$936!;7VJH"^H*-+@<`V[_]2&$^`HB-Z%"*$0@@@"R/0;W*KTJ MNKR'^BR+A)D?#;/[/<)O*/E]HLH73PY,J,@U$AO&IV)"?# M8J4Y-NAG5P2T*PK:2D)ZHDIS7*F70MI3TW5AXM]1@$;[Q,-<=&"'CB%/3X!A[ M*>J6!1W6*LZ$]AL>AK#`8X(O,!]Z<.B;$$,QESV42KWA2E[HLUK#B3`3A*(.& MM_99`CQ.Y!(#1T6Z,,LE':W+-+D!L1;F:HSW6-`VQ=5@;0KA%WO)J#77L6R%O MIO<6-;3JI=[1>D=L4KL55=OBZDM%:M2ZA:-H`BTUXC8#547'X*BW#6MM)=DPO M$PQ>[H-%C%<8=42Y/C+%`5R.)3KIJSUK]7B(O6#8M5E/WZ-P?>_?IME]TX2UG M0L$!K,$1[W>ZW#;#8S)$J]X-'-CK$PL/%U:R\A*ZUEB6GJD/= M^8SF/H-LF>2A#]SWA3\MT&;B"]CSXO5SRC$$ND`Q>U(.&:8].EH+`YT!2`+Z& M-'RWTC"3F:3RP!FA&605<0H2!5)KC8^-CZ-Q!-3`E,06!K2BRPUBK6 MD'DRZF6S:I40TO"Q:L$EPVM%P3DJ\:P)2N=Q;L\ MX/5PC!0)5C1X*<;=(3%BK1G>NWHB]IFA&L)04W6*B,1Z`712E3-_IT:IC`LW1 M@5R"SR7?G00+P3!E')H%\E/T9V(94,Z$)`']6IAAY;IP9'1@W3Y[=Z/2RTPU:O9J3DE_K MV.S5;_8:-'L-FKWZS5[#9J_FR7)&#\RS.J%K7!GM:I.'-Y/_^)1#9ZO.3S304 M=L_*X_`:+^I%![S36]1)[=GTM5!_J["V6:UV;DQJ2W^!3`M'D[>$79KT)80D& /2&7&Z(OBOR40]M#,%```B `` end size 1770 From amiga-gcc-port-owner@nic.funet.fi Fri Sep 15 15:13:33 1995 Received: from srv4.gbar.dtu.dk ([130.225.87.164]) by nic.funet.fi with ESMTP id <89335-4>; Fri, 15 Sep 1995 15:13:15 +0300 Received: by srv4.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 15 Sep 1995 14:11:32 +0200 (METDST) From: Rask Lambertsen To: Bert Winkelmann Cc: amiga-gcc-port@nic.funet.fi Subject: Re: __unwind_function() In-Reply-To: <50187435@bw01.bbrandes.berlinet.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 14 Sep 1995, Bert Winkelmann wrote: > 0: > clr.l d0 > move.w 2(a0),d0 > btst #15,d0 |expand an minus-sign. > beq 0f | I know there was some opcode for that -!!!- bmi - branch if minus Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Sun Sep 17 05:47:25 1995 Received: from bos1h.delphi.com ([192.80.63.8]) by nic.funet.fi with ESMTP id <89461-4>; Sun, 17 Sep 1995 05:42:33 +0300 Received: from delphi.com by delphi.com (PMDF V5.0-4 #10880) id <01HVCZHY27W09BY17W@delphi.com> for amiga-gcc-port@nic.funet.fi; Sat, 16 Sep 1995 22:42:09 -0400 (EDT) Date: Sat, 16 Sep 1995 22:42:09 -0400 (EDT) From: JRBRTSN@delphi.com Subject: Problem with gcc-faq.txt To: amiga-gcc-port@nic.funet.fi Message-id: <01HVCZHY2HJM9BY17W@delphi.com> X-VMS-To: INTERNET"amiga-gcc-port@nic.funet.fi" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT /* * Dear Sirs, * * I recently attempted to compile the "HelloWorld.c" program * provided in your "gcc-faq.txt" document. Gcc claimed it did * not know the size of "er", so I went looking for "struct EasyRequest" * in the includes, and could not find it. I found "struct EasyStruct" * instead. I changed the program, and it works fine now. * * My os-includes are copied from the SAS v6.55 distribution, minus the * conflicting files in the "sys" directory. */ #include #include #include int main(int argc, char *argv[]) { struct EasyStruct er; /* Not: struct EasyRequest er; */ er.es_StructSize = sizeof(er); er.es_Flags = 0; er.es_Title = "Message"; er.es_TextFormat = "Hello, world!\nintuition.library is at 0x8l."; er.es_GadgetFormat = "Ok"; EasyRequest(NULL, &er, NULL, IntuitionBase); exit(0); } From amiga-gcc-port-owner@nic.funet.fi Sun Sep 17 08:10:03 1995 Received: from hookomo.aloha.net ([204.94.112.33]) by nic.funet.fi with SMTP id <89514-4>; Sun, 17 Sep 1995 08:09:15 +0300 Received: (from newsham@localhost) by hookomo.aloha.net (8.6.12/8.6.9) id TAA25313 for amiga-gcc-port@nic.funet.fi; Sat, 16 Sep 1995 19:05:10 -1000 From: Timothy Newsham Message-Id: <199509170505.TAA25313@hookomo.aloha.net> Subject: bug introduced by compiler upgrade To: amiga-gcc-port@nic.funet.fi Date: Sat, 16 Sep 1995 19:05:10 -1000 (HST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3158 Hi, I recently upgraded from gcc2.2.2 to gcc2.6.3 and then 2.7.0 on my amiga. The old 2.2.2 would compile my code fine but now it no longer works properly. I did have to make some changes (pc relative addressing changed in the assembler) but I got that all worked out (verified that my pc relative addressing is working properly and that I can relocate my code). Anyway the problem I see now is that the machine goes belly up (grey screen then guru message) as soon as I do a pmove into the crp register. The funny thing is that I am in supervisor mode and I already turned the MMU off! (pmove to srp does not cause any problems though). Here's the relevant file. If you would like to see the whole program I can upload that as well. Tim N. ------ | move.s | Move image, finish setup and jump to entr | | Last fling before the new system runs. We have to copy | the Image to page 1, setup the temp stack | and turn on the MMU. | This code is relocatable. | .text .even | Start of Assembly .globl _asm_start _asm_start: asm_start: movel sp, a3 | store for access to args lea pc@(start_super), a0 | movel a0, 0x20 | priv violation vector movew #0x2700, sr | cause exception | We're in supervisor mode now, args are at a3@(xxx) | args: | src (4), len (8) | newstack (12) | roothi (16), rootlow (20) | entry (24) | aout header (28) start_super: movew #0x2700, sr | supervisor, no interupts movel a3@(12), sp | use new stack | get stack args before copy lea pc@(rootp), a0 movel a3@(16), a0@+ | get root pointer into rootp movel a3@(20), a0@+ movel a3@(24), a2 | store entry | copy a.out header to top of page 0 movel a3@(28), a0 | src = aout header movel #0x0fe0, a1 | dest = page1 - sizeof header movel #0x20, d0 | len = sizeof header Lss2: moveb a0@+, a1@+ | do move addl #-1, d0 bne Lss2 | copy basemem to low mem (starting at page 1) movel a3@(4), a0 | src movel #0x1000, a1 | dest movel a3@(8), d0 | len in bytes lsrl #2, d0 | long len = len / 4 addl #1, d0 | 1 for good luck Lss1: movel a0@+, a1@+ | do move addl #-1, d0 bne Lss1 | turn on MMU here lea pc@(zero), a0 pmove a0@, tc | make sure mmu is off pmove a0@, tt0 | turn off transparent translation pmove a0@, tt1 movl #0x00f, d0; bsr roll | XXX this is the last roll I see pmove a0@, crp movl #0xff0, d0; bsr roll lea pc@(rootp), a0 movl #0x0ff, d0; bsr roll pmove a0@, srp movl #0x00f, d0; bsr roll pmove a0@, crp | store root pointer movl #0x0f0, d0; bsr roll lea pc@(tcbuf), a0 pmove a0@, tc | turn on MMU movl #0x00f, d0; bsr roll jmp a2@ | jump to entry .even rootp: .long 0x00000000 .long 0x00000000 | tcbuf = enabled, srp/crp, 4k page, 10bit, 10bit tcbuf: .long 0x82c0aa00 zero: .long 0x00000000 .long 0x00000000 | d0 = color | roll the color roll: movel #0xdff000, a0 movel #50, d2 Lr2: movel #0xffffff00, d1 Lr1: movew d0, a0@(0x180) dbf d1, Lr1 dbf d2, Lr2 rts asm_end: .even nop .globl _get_asm_len _get_asm_len: movel #(asm_end - asm_start), d0 rts From amiga-gcc-port-owner@nic.funet.fi Sun Sep 17 10:05:13 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89780-2>; Sun, 17 Sep 1995 10:04:30 +0300 Received: from achilles.noc.ntua.gr by funet.fi with SMTP (PP); Sun, 17 Sep 1995 10:04:21 +0300 Original-Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id KAA20506 at Sun, 17 Sep 1995 10:01:49 +0300 PP-warning: Illegal Received field on preceding line Original-Received: by softlab.ece.ntua.gr with UUCP id KAA09138 at Sun, 17 Sep 1995 10:08:37 +0300 PP-warning: Illegal Received field on preceding line Received: by kriton.UUCP (V1.17-beta/Amiga) id <089v@kriton.UUCP>; Sat, 16 Sep 95 22:11:35 EET Date: Sat, 16 Sep 95 22:11:35 EET Message-Id: <9509162011.089v@kriton.UUCP> Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 927 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: obsolete info in g++FAQ.guide I'm perusing g++FAQ.guide, which I assume is an amigaguide version of the corresponding official texinfo file. There, under the heading "g++ for other platforms", it says: > For information on Amiga ports of gcc/g++, retrieve the file > `/pub/gnu/MicrosPorts/Amiga' from prep.ai.mit.edu, or write to Markus > M. Wild , who I hope won't be too upset that > I mentioned his name here. Shouldn't this be updated with information about the Aminet version, the Fred Fish CD ROMs, and the amiga-gcc-port mailing list? (/pub/gnu/MicrosPorts/Amiga should probably be updated with a copy of this information, too.) -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If you can help anybody, like preventing them from being eaten by a monster, then do so--they might be grateful." ----- From amiga-gcc-port-owner@nic.funet.fi Sun Sep 17 11:00:47 1995 Received: from haegar.allcon.net ([194.49.86.2]) by nic.funet.fi with SMTP id <89721-4>; Sun, 17 Sep 1995 11:00:16 +0300 Received: from honi.allcon.net by haegar.allcon.net with smtp (Smail3.1.28.1 #7) id m0suEe1-000aIuC; Sun, 17 Sep 95 10:00 MET DST Received: by umd.allcon.com (CrossPoint v3.02); 17 Sep 1995 09:50:41 +0200 Date: 16 Sep 1995 00:49:00 +0200 From: mark@umd.allcon.com (Mark Deskowski) To: amiga-gcc-port@lists.funet.fi Message-ID: <5tx2TFTAyQB@umd.allcon.com> In-Reply-To: <50187435@bw01.bbrandes.berlinet.de> Subject: help X-Mailer: XP v3.02 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit help From amiga-gcc-port-owner@nic.funet.fi Mon Sep 18 09:31:44 1995 Received: from uni-kl.de ([131.246.136.50]) by nic.funet.fi with SMTP id <89722-4>; Mon, 18 Sep 1995 09:26:58 +0300 Received: from uklirb.informatik.uni-kl.de by stepsun.uni-kl.de id aa26539; 18 Sep 95 8:26 MET DST Received: from kerry.informatik.uni-kl.de by uklirb.informatik.uni-kl.de id aa01757; 18 Sep 95 8:20 MET DST Date: Mon, 18 Sep 95 2:14:56 EDT From: Frank Bernard To: amiga-gcc-port@nic.funet.fi Subject: unsubscribe Message-ID: <9509180214.aa06621@kerry.informatik.uni-kl.de> unsubscribe bernard@informatik.uni-kl.de From amiga-gcc-port-owner@nic.funet.fi Mon Sep 18 12:09:49 1995 Received: from calvin ([193.55.128.51]) by nic.funet.fi with SMTP id <89882-2>; Mon, 18 Sep 1995 12:08:58 +0300 Received: from canardo.unicaen.fr by calvin (5.x/SMI-SVR4) id AA02101; Mon, 18 Sep 1995 11:08:56 +0200 Received: by canardo.unicaen.fr (5.x/SMI-SVR4) id AA29828; Mon, 18 Sep 1995 11:08:42 +0200 Date: Mon, 18 Sep 1995 11:08:42 +0200 From: devulder@calvin.info.unicaen.fr (Samuel Devulder) Message-Id: <9509180908.AA29828@canardo.unicaen.fr> To: amiga-gcc-port@lists.funet.fi Subject: Has gcc-apurify bugs ? X-Sun-Charset: ISO-8859-1 Hello ! I'm the author of APurify. I've received no mail nor bug-reports about the corrected gcc-apurify put with gcc2.7.0. Is that program correct and bug-free or does nobody use it ? I've been told it can detect things that Enforcer did not detect.. Is it true ? Has anyone noticed such a thing ? If it correct, then I'll upload to aminet (when repaired) the gcc/DICE/PDC-version of it (a bit faster and new docs). Thanks for helping, samuel DEVULDER ------------------------------------------------------------------- GREYC (URA 1526) Université de CAEN F-14032 Caen CEDEX FRANCE ------------------------------------------------------------------- e-mail: devulder@info.unicaen.fr tel: 31.45.53.19 From amiga-gcc-port-owner@nic.funet.fi Mon Sep 18 19:11:25 1995 Received: from chx400.switch.ch ([130.59.1.2]) by nic.funet.fi with ESMTP id <89887-4>; Mon, 18 Sep 1995 19:09:52 +0300 Received: from isbiel.ch (actually sunny.isbiel.ch) by chx400.switch.ch with SMTP (PP); Mon, 18 Sep 1995 18:09:19 +0200 Received: from odis.isbiel.ch by isbiel.ch (4.1/SMI-4.1.e) id AA17347; Mon, 18 Sep 95 18:09:13 +0200 Received: from ODIS/SpoolDir by odis.isbiel.ch (Mercury 1.21); 18 Sep 95 18:09:14 +200 Received: from SpoolDir by ODIS (Mercury 1.21); 18 Sep 95 18:09:01 +200 From: BOOS CHRISTOPH 1994M1B Organization: Biel School of Engineering To: amiga-gcc-port@lists.funet.fi Date: Mon, 18 Sep 1995 18:08:34 MET DST Subject: serious rounding problem Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: Hello! a few months ago, i postet a problem with gcc2.6.3, concerning rounding at double-int conversion, but nobody could help me. Now i've installed gcc2.7.0 hoping the bug had been removed -> it hadn't :-( so here again my problem: when i compile the following programm #include main () { double a=3.7; printf("%d \n",(int)a); } with "gcc -o prg prg.c" i get 4 as output. but the K&R C-bible says it should be 3 ! If i compile the same program with "gcc -noixemul -o prg prg.c -lm" i get 3. i took a look at the assembler-output of both versions (ixemul and noixemul) and saw that the conversion happens in both cases in a link- library function called ___fixdfsi. this functions hasn't the same code in the two versions but it always use the same OS library function which does the actual conversion: x = IEEEDPFix( y ) (mathieeedoubbas.library) d0 d0/d1 this function expects the double number (in this case 3.7) in the ieee-format in d0 and d1 (3.7= d0:400d9999 d1:9999999a) and returns the int-number in d0. Now i debugged (PowerVisor) the function in both cases (ixemul and noixemul) and saw that it received always the correct arguments (in d0 and d1) but returned two different values! (Ooops???) this is the code of IEEEDPFix() MOVE.L d1,-(a7) MOVE.L d0,-(a7) FMOVE.D (a7)+,FP0 FMOVE.L (FP0),d0 RTS I havn't much assembler experience and absolutly no ideas of FPU programming, but i think the FMOVE mnemonics are FPU commands, right? Could it be possible that there exists a flag (somewhere) which sets the FPU in round/trunc mode?? is there any help for this problem? (i think i saw a few weeks ago in comp.sys.amiga.progammer someone with the same problem. At least i'm not alone! ;-) ) greetings Christoph From amiga-gcc-port-owner@nic.funet.fi Mon Sep 18 22:24:33 1995 Received: from DBSTU1.RZ.TU-BS.DE ([134.169.1.1]) by nic.funet.fi with SMTP id <89641-4>; Mon, 18 Sep 1995 22:23:35 +0300 Received: from rzab0.rz.tu-bs.de by DBSTU1.RZ.TU-BS.DE (IBM VM SMTP V2R2) with TCP; Mon, 18 Sep 95 21:24:10 MEZ Received: by rzab0.rz.tu-bs.de (1.37.109.4/15.6) id AA19333; Mon, 18 Sep 95 21:23:18 +0200 From: Sven Heithecker Subject: Many questions to gcc 2.7.0 To: amiga-gcc-port@nic.funet.fi (Sven Heithecker) Date: Mon, 18 Sep 1995 21:23:15 +0100 (MESZ) X-Mailer: ELM [version 2.4 PL11] Content-Type: text Content-Length: 4020 Message-Id: <95Sep18.222335+0300_eet_dst.89641-4+74@nic.funet.fi> Hi ! I have just installed gcc2.70, and there are A LOT questions left about it - I hope someone can give an answer for them. I will use gcc for writing AmigaDOS-Programs, that means I will use libnix - I will not recompile Un*x-stuff - if I want to use Un*x, I start NetBSD. Perhaps I will compile some pure-ansi-c-programs. First, there are a lot of directories with 'strange' contents, mainly stuff wich can also be found in other dirs: So far I installed the packages gcc270-base, gcc270-c020, gcc270-inclib. My system is a A2000 with GForce040/33/16Mb. 1. The stuff in gnu:etc what is it good for ? X0.hosts,Termcap,man.conf,less.hlp - I dont have programms using these. And termcap is quite big .... ksh.kshrc, profile, sys_config.sh - Are they used by sh ? I know what they are good for on Un*x systes, but sh doesn't use them (checked with SnoopDos). startup-mk - Used by make ? See following notes ... 2. gnu:mc68020-cbm-amigados/include/assert.h ? This directory seems a bit out of place for me there .... I found another - slightly different - assert.h in gnu:include ! Are two versions of assert.h necessary or can I replace one and delete the other ? 3. The following stuff can be found relative to gnu:lib/gcc-lib/mc68020-cbm-amigados/2.7.0/... : i. Stuff in include/... - Some of them I can find in gnu:include/... in a slightly different version. I wonder if I need stuff like va_alpha.h - I don't want develop things for DEC-Alpa or recompile stuff from DEC-Alpa !! Wich stuff is really necessary, can be copied to gnu:include, or can be deleted ? - I never installed Objective-C, so I think that the directory include/objc/ can be deleted ? ii. The libgcc.a-lib in several forms and subdirectories. Gcc never seems to access them - I checked with SnoopDos while compiling and linking a project. Are they deleteable OR was SnoopDos wrong ? iii. SYSCALLS.c.X. What is it good for ? 4. There is many in gnu:include/ .. which seem to be used only for compiling Un*x programs ( arpa | machine | net | netinet | protocols | readline | rpc ). Am I right and can those stuff be deleted ? Second, I had some system-crashes / errors using gnu-stuff: 1. Make. It crashes everytime. One time, it wrote "Bus-Error" and "Illegal Instruction" to CLI just before / while it gave a brunch of Enforcer-Hits and my machine was shooted down. Other times, it simply gave Enforcer-Hits without those CLI-msgs (without crashing the machine immediately). But when I wanted to keep on working ramlib crashed ... 2. GCC enforcer-hitted and deadlocked sometimes when I breaked it with CTRL-C. Do these errors have something to do with ixemul.library ? I am a bit suspicious about that library - I heared _many_ thinks ... 3. Error using -fbaserel: 1. I got the following message compiling inline/muimaster.h: "Fixed or forbidden register was spilled. This may be due a compiler-bug or to impossible asm statements or clauses." I checked inline/muimaster.h but didn't found something improper ... 2. During linking I got: "ld: Reloc is base relative. Specify -databss-together in mensa_gui.o" I checked specs for -databss-together and found it. Specifying directly in the commandline didn't help, nor did -O3. The two errors occurred in different modules. Do those 2 errors mean that -fbaserel is still broken :((((( ????? 4. Apurify. I tested the test-prg and it crashed immediately :( ! Third, where is the documentation for ld ? In the guide "gcc.guide" many linker - options aren't explained !! Ok, thats lot of questions. I HOPE that someone will hear me and tries to give me an answer - and if it just "Dont know - youre unlucky" so that I can see that someone read it completely ;) !! Ciao, ____ |_||_ Ceterum Censeo MEGAHARD Esse Delendam | | _| HTS Sven Heithecker s.heithecker@tu-bs.de From amiga-gcc-port-owner@nic.funet.fi Mon Sep 18 23:04:04 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89300-2>; Mon, 18 Sep 1995 23:02:57 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sumPn-0004nZC; Mon, 18 Sep 95 13:03 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Many questions to gcc 2.7.0 To: y0000135@ws.rz.tu-bs.de (Sven Heithecker) Date: Mon, 18 Sep 1995 13:03:40 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Sep18.222335+0300_eet_dst.89641-4+74@nic.funet.fi> from "Sven Heithecker" at Sep 18, 95 09:23:15 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1916 > First, there are a lot of directories with 'strange' contents, mainly stuff > wich can also be found in other dirs: Some of these questions relate to the way gcc is packaged. The aminet release is packaged and released by Philippe Brand and he can explain more about the reasons for the packaging. I tend to prefer the packaging that I used for archived GNU stuff on my FreshFish CDs, where I mimic the way the FSF releases things. I.E. there is a gcc-2.7.0-bin.lha which contains only the compiler pieces, a binutils-2.5.2-bin.lha that contains only the binutils (linker, assembler, nm, etc), an ixemul-41.3-bin.lha that contains ixemul.library, a pdksh-4.9-bin.lha that contains only the shell, etc. This gives you somewhat more flexibility about what to install and how to update stuff, although it is more of a hassle than the all inclusive format that Philippe uses because you have to know (or be told) which archives of dozens you might want or need. I think this scheme, combined with CRC listings for each package so that you know when you have things that need updating, as well as some standard package suggestions (gcc base with no ixemul, gcc base with ixemul, etc), suggested developers package (other utils like "make", m4, gawk, etc), would be more flexible and easier to update as bug fixes are made. However I really don't worry about that in my CD releases because everything comes preinstalled and ready to run directly off the CD if you wish. If you prefer not to tie up the CD or want faster file accesses, you can copy the entire 140Mb GNU tools binary tree to your hard drive (consuming about $40 worth of hard drive space at current HD drive prices for reasonably large drives). It's really a trade off; are the hours you expend pruning the tree to optimize your HD usage by eliminating "things you'll never use ... until you need them" worth saving $20-$40 in drive space? -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Sep 19 02:18:25 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89823-3>; Tue, 19 Sep 1995 02:17:08 +0300 Received: by colombo.telesys-innov.fr; Tue, 19 Sep 1995 01:16:11 +0100 From: Philippe BRAND Message-Id: <199509190016.BAA03901@colombo.telesys-innov.fr> Subject: Re: Many questions to gcc 2.7.0 To: y0000135@ws.rz.tu-bs.de (Sven Heithecker) Date: Tue, 19 Sep 1995 01:08:44 +0100 (BST) In-Reply-To: <95Sep18.222335+0300_eet_dst.89641-4+74@nic.funet.fi> from "Sven Heithecker" at Sep 18, 95 09:23:15 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4066 Sender: phb@colombo.telesys-innov.fr Sven Heithecker writes: > So far I installed the packages gcc270-base, gcc270-c020, gcc270-inclib. > My system is a A2000 with GForce040/33/16Mb. Hope you installed gcc270-readme :) > X0.hosts,Termcap,man.conf,less.hlp - I dont have programms using these. > And termcap is quite big .... These are used by some programs. If you don't plan to use X, programs using termcap, man or less, fell free to delete them. > ksh.kshrc, profile, sys_config.sh - Are they used by sh ? I know what they > are good for on Un*x systes, but sh doesn't use them (checked with SnoopDos). > startup-mk - Used by make ? See following notes ... ksgh should be used by sh. Snoopdos won't reveal a thing, because all stuff is done through ixemul.library. > 2. gnu:mc68020-cbm-amigados/include/assert.h ? > This directory seems a bit out of place for me there .... Standard place when gcc installation. > versions of assert.h necessary or can I replace one and delete the other ?> > 3. The following stuff can be found relative to> gnu:lib/gcc-lib/mc68020-cbm-amigados/2.7.0/... :> > i. Stuff in include/... > - Some of them I can find in gnu:include/... in a slightly different > version. > I wonder if I need stuff like va_alpha.h - I don't want develop > things for DEC-Alpa or recompile stuff from DEC-Alpa !! > Wich stuff is really necessary, can be copied to gnu:include, or > can be deleted ? Please keep all files. They're really not big. > - I never installed Objective-C, so I think that the directory > include/objc/ can be deleted ? Yep. > ii. The libgcc.a-lib in several forms and subdirectories. Gcc never > seems to access them - I checked with SnoopDos while compiling and > linking a project. Are they deleteable OR was SnoopDos wrong ? Same thing as above. ld uses them. Initiate a gcc -v and you'll see linker options. > 4. There is many in gnu:include/ .. which seem to be used only for compiling > Un*x programs ( arpa | machine | net | netinet | protocols | readline | > rpc ). Am I right and can those stuff be deleted ? Are you really so tight in HD space ? > 1. Make. It crashes everytime. One time, it wrote "Bus-Error" and "Illegal > Instruction" to CLI just before / while it gave a brunch of Enforcer-Hits and > my machine was shooted down. Other times, it simply gave Enforcer-Hits > without those CLI-msgs (without crashing the machine immediately). But when > I wanted to keep on working ramlib crashed ... Set stack size to 50.000 > 1. I got the following message compiling inline/muimaster.h: > "Fixed or forbidden register was spilled. This may be due a compiler-bug > or to impossible asm statements or clauses." > I checked inline/muimaster.h but didn't found something improper ... Too many registers were used by one of functions. Solution is to avoid inlining this function. One other user has already posted a workaround for this. > 2. During linking I got: > "ld: Reloc is base relative. Specify -databss-together in mensa_gui.o" > I checked specs for -databss-together and found it. Specifying directly > in the commandline didn't help, nor did -O3. You didn't compile mensa_gui.c with -resident flag. > 4. Apurify. I tested the test-prg and it crashed immediately :( ! Report directly to apurify author... He'll be pleased to have some feedbacks. > Third, where is the documentation for ld ? In the guide "gcc.guide" many > linker - options aren't explained !! Yep. Documentation is lacking here... Could somebody out there write a small doc ? > Ok, thats lot of questions. I HOPE that someone will hear me and tries to > give me an answer - and if it just "Dont know - youre unlucky" so that I can > see that someone read it completely ;) !! :) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Sep 19 11:26:20 1995 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by nic.funet.fi with SMTP id <88932-3>; Tue, 19 Sep 1995 11:21:30 +0300 Received: from athena.cs.utwente.nl by utrhcs.cs.utwente.nl (5.x/csrelayMX-SVR4_1.1tmp/RB) id AA14144; Tue, 19 Sep 1995 10:20:33 +0200 Received: from tooheys.cs.utwente.nl by athena.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id KAA09913; Tue, 19 Sep 1995 10:20:30 +0200 Received: by tooheys.cs.utwente.nl (SMI-8.6/SMI-SVR4) id KAA05774; Tue, 19 Sep 1995 10:20:29 +0200 Date: Tue, 19 Sep 1995 10:20:29 +0200 From: alberts@cs.utwente.nl (Mert Alberts) Message-Id: <199509190820.KAA05774@tooheys.cs.utwente.nl> To: amiga-gcc-port@nic.funet.fi Subject: Using the -chip and/or -fast link-option X-Sun-Charset: US-ASCII Hi, Can anyone tell me how to get the linker in gcc2.6.3 to choose the -chip or -fast option to recognise the Amiga-specific chip resp. fast keyword? The FAQ mentions these options but doesn't specify how to call them. It (the FAQ) also suggests that in a following version these options would be integrated more elegantly in the compiler itself. Is this already the case in gcc2.7.0? Are there there more of such keywords which I may run into while trying to compile the Amiga CManual and RKRM examples with gcc.2.6.3.? Much obliged, Mert. From amiga-gcc-port-owner@nic.funet.fi Tue Sep 19 12:00:56 1995 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by nic.funet.fi with SMTP id <88948-3>; Tue, 19 Sep 1995 11:59:14 +0300 Received: from athena.cs.utwente.nl by utrhcs.cs.utwente.nl (5.x/csrelayMX-SVR4_1.1tmp/RB) id AA14445; Tue, 19 Sep 1995 10:32:57 +0200 Received: from tooheys.cs.utwente.nl by athena.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id KAA10033; Tue, 19 Sep 1995 10:32:54 +0200 Received: by tooheys.cs.utwente.nl (SMI-8.6/SMI-SVR4) id KAA05830; Tue, 19 Sep 1995 10:32:53 +0200 Date: Tue, 19 Sep 1995 10:32:53 +0200 From: alberts@cs.utwente.nl (Mert Alberts) Message-Id: <199509190832.KAA05830@tooheys.cs.utwente.nl> To: amiga-gcc-port@nic.funet.fi Subject: Re: Using the -chip and/or -fast link-option X-Sun-Charset: US-ASCII Sorry to bother y' good folks again with this topic but ... I forgot to mention that I tried things like gcc -Xlinker -chip -o test sprite.c However that didn't seem to make gcc recognise the chip keyword. Mert. From amiga-gcc-port-owner@nic.funet.fi Tue Sep 19 13:05:19 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89301-2>; Tue, 19 Sep 1995 13:02:38 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA22507; Tue, 19 Sep 1995 12:03:56 +0200 Date: Tue, 19 Sep 1995 12:03:55 +0200 (MET DST) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: __unwind_function() To: Bert Winkelmann cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <50187435@bw01.bbrandes.berlinet.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Thu, 14 Sep 1995, Bert Winkelmann wrote: > (the dtors (inside the try-blocks) are called by compiler-created > code.) Actually, I thought that they should be called by ___unwind_func, that's why I thought that your first implementation was too simple. I didn't even think about preserving the registers (silly me...). > > I think that the standard says that if an exception was not catched, > > standard terminate() function should be called. > > This happens when the a5-register turned to zero after an `unlk'. But > terminate() must also called for a "corrupt-stack". Maybe the a5-check > is only for that case? terminate() must also be called when during destruction of object in stack-unwinding an exception is thrown. I checked this and it works (at least with old version of ___unwind_func - but I think this function has nothing to do with this). If I remember correctly, in gcc-created code there is a line: cmpw #0,a5@(2) If this test is true, terminate() is called. I think that a5@(2) is the return-address of code (pushed on stack by jsr), NOT previous contents of A5 or A7 (or maybe I didn't understand the description of "link" instruction in a reference manual...). But this test doesn't make sense, at least on Amiga. First, why "cmpw", not "cmpl"? I'm not an expert of MIT syntax (to say the least :-), but I think this causes CPU to compare only WORD of a5@(2) with 0 - what would such a test give? I think that correct implementation would be to compare LONG from a5@(2) with an address of code in startup code that immediately follows "jsr" to main() (the question is: is main() called only from one place, both for WB and Shell?). Bert, I don't understand why you replaced terminate(), unexpected(), set_terminate() and set_unexpected() with your own ones? You wrote you missed them in libraries. Well, I don't know where you have taken this libraries from, but GCC had no problems in finding these functions in libraries from Aminet distribution (I think they were in libgcc.a or libstc++.a). unexpected() indeed doesn't seem to be called. Actually, I think that g++ ignores exception-specifications - it produces exactly the same code with or without them. I don't know if something is missing in m68k implementation, or is this general g++ problem? Have you contacted with Mike Stump? > Bert. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Tue Sep 19 13:15:54 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <88961-2>; Tue, 19 Sep 1995 13:15:06 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA10023; Tue, 19 Sep 1995 11:13:15 +0100 From: Lars Hecking Message-Id: <199509191016.LAA28792@mostar.nmrc.ucc.ie> Subject: Re: Using the -chip and/or -fast link-option To: alberts@cs.utwente.nl (Mert Alberts) Date: Tue, 19 Sep 1995 11:16:44 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199509190832.KAA05830@tooheys.cs.utwente.nl> from "Mert Alberts" at Sep 19, 95 10:32:53 am Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 344 > > > Sorry to bother y' good folks again with this topic but ... > I forgot to mention that I tried things like > > gcc -Xlinker -chip -o test sprite.c > > However that didn't seem to make gcc recognise the chip keyword. What about gcc -Wl,-chip -o test sprite.c ?? Btw, "test" is not a good choice to name an executable. From amiga-gcc-port-owner@nic.funet.fi Tue Sep 19 14:37:52 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89109-1>; Tue, 19 Sep 1995 14:36:31 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 19 Sep 95 13:36 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 19 Sep 95 12:05 MET DST Message-Id: Subject: Re: Using the -chip and/or -fast link-option To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 19 Sep 1995 12:05:20 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 610 > > Sorry to bother y' good folks again with this topic but ... > I forgot to mention that I tried things like > > gcc -Xlinker -chip -o test sprite.c > > However that didn't seem to make gcc recognise the chip keyword. > i have compiled the most examples for gcc. there is most times no need for chip but there is for now no way except allocmem(sizeof(),MEMF_CHIP) to force anything into chipmem. walter -- ----- "This is not my planet, I didn't choose to be here, I don't want to get involved, just get me out of here, and get me to a party with people I can relate to!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Sep 19 15:25:26 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <89392-2>; Tue, 19 Sep 1995 15:24:27 +0300 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HVGP4NT74W0046CP@NET2.WAU.NL>; Tue, 19 Sep 1995 14:27:58 +0000 (GMT) Received: by vines2.wau.nl; Tue, 19 Sep 95 14:29:20 +0100 Date: Tue, 19 Sep 1995 14:22:24 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: KCON: & ixemul.library & enforcer hits To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi Kamil, I tried your program and depending on the KCON: friendly define I get a hit or not. When I used make I got hits from cc1/make but not for cpp/as/ld. So not all programs produce these hits. I hope you find the cause. Joop From amiga-gcc-port-owner@nic.funet.fi Tue Sep 19 20:25:33 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89198-2>; Tue, 19 Sep 1995 20:20:27 +0300 Received: from carina.rz.Uni-Osnabrueck.DE by funet.fi with SMTP (PP); Tue, 19 Sep 1995 20:20:08 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id TAA17994; Tue, 19 Sep 1995 19:19:47 +0200 From: Thomas Radtke Received: (thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) id TAA15136; Tue, 19 Sep 1995 19:19:53 +0200 Message-Id: <199509191719.TAA15136@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: Using the -chip and/or -fast link-option To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Tue, 19 Sep 1995 19:19:53 +0200 (DFT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199509191016.LAA28792@mostar.nmrc.ucc.ie> from "Lars Hecking" at Sep 19, 95 11:16:44 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 196 > Btw, "test" is not a good choice to name an executable. > You are right. At least, one should use test.`getunique` Looks more serious. ;) (getunique is available on aminet) Thomas From amiga-gcc-port-owner@nic.funet.fi Tue Sep 19 21:42:30 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89334-2>; Tue, 19 Sep 1995 21:41:25 +0300 Received: from k332.feld.cvut.cz (utx@k332.feld.cvut.cz [147.32.192.12]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id SAA08844 for ; Tue, 19 Sep 1995 18:41:10 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: (from utx@localhost) by k332.feld.cvut.cz (8.6.10/8.6.9) id VAA32481 for amiga-gcc-port@nic.funet.fi; Tue, 19 Sep 1995 21:01:48 +0200 Date: Tue, 19 Sep 1995 21:01:48 +0200 From: Stanislav Brabec Message-Id: <199509191901.VAA32481@k332.feld.cvut.cz> To: amiga-gcc-port@nic.funet.fi Subject: About .. in root, stderr, DosWedge, Ctrl-C, etc. suggestions and answers for some questions and problems list: (gcc 2.7.0, ixemul 41.3) Proposals of root's .. problem (reported by me) --------- Really, there is another simple way, based on AmigaDos behavior: ParentDir of volume root is 0x0. But 0x0 when Lock'ing means SYS:. Removal of if(...==0) in ixemul source will cause such behavior (really, then CD /SYS and CD .. will cause pwd /SYS). Less simple, but also implementable. FindNext after . will be .. only in case, when parent directory pointer isn't zero, otherwise it will be first real file. And one bad implementable: Finally, there could be one real master root: GNU: (with or without ..) Other volumes will have its root directed to GNU: Currently it seems to be implemented `/' somehow strange (depends on directory, from which is program running) If you want to see volumes in listings, simply use SoftLinks (requires Aminet fixslinks to correct bug in path/slink/path): Example: MakeLink GNU:dev/fd0 DF0: soft Trouble with pr_CES (stderr) in v 41.3 ------ My favourite (memory saving) way to run sh was: `sh <>DEV:tty01' (with DevHandler) or `sh <>CON:arguments' (with CON): Now it does not work, because <> doesn't redirect stderr. Does anybody know, how to redirect stderr from DOS line? Otherwise I must run sh from CLI (needs extra memory for CLI ctructure), or (better way) to create special program (getty) to start sh. Similar problem you can find with remote sh. It requires getty and login. Trouble with DosWedge ~ -------- I have been looking at DosWedge. It's ugly utility, because it requires more than 60kB to patch .., . and ~ in dos.library (requires matrix.library and a tabs.gadget). The problem of `~' evaluation in ixemul is from different world than DosWedge. This is a standard UNIX special character. It it correctly parsed in ixemul.library. But examination of user's home directory fails. because ixemul have no support of MultiUser (see my earlier mail). For now there's easy way to do it: in S:user-startup: Run MAssign HOME: %h in global shell .profile: HOME=/HOME CD Trouble in signal promotion in shell ------ In shell implementation is a bug in promotion of Ctrl-C ... signals. Shell Fork's when starting each command. If you press Ctrl-C, only Parent process is signalled. Childs are running without any notice of Ctrl-C signal. Once more about file protection flags --------------------- As I have been reported, group and other's flags in ixemul are reverted. Next, S_ISVTX can be converted to NOT(pure) flag on Amiga on files. On directory ...? Proposal of solution of GMT time, local time etc. in ixemul: -------- On Aminet is simple (too simple, but usable) patch for battclock called unixclock based on Locale preferences. There can be a pretty solution of GMT time: Make a small library GMT.library containing GMTWriteBattClock GMTReadBattClock GMTCurrentTime (or variable in GMTbase (but it requires interrupt hook)) (I want to do it, if I'll have a time) It seems to be a trouble in `times' command: ----- Times system is always 0 (probably unimplemented) Post Scriptum: Does anybody know, how to import to asm() any symbolic value (struct offset, #define'd value etc...) better than argument? From amiga-gcc-port-owner@nic.funet.fi Tue Sep 19 23:26:16 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89658-2>; Tue, 19 Sep 1995 23:25:27 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 19 Sep 95 22:24 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 19 Sep 95 22:19 MET DST Message-Id: Subject: problems with linking To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 19 Sep 1995 22:19:47 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1058 i tried to compile an example-handler with gcc and found this linker error. the function is defined in libgcc.a, it is the latest version i have no idea what went wrong. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/libgcc.a(__main.o): Undefined symbol _atexit referenced from text segment for those who like the -v output gcc -v my-handler.o misc.o -lamiga Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/specs gcc version 2.7.0 ld /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0 -L/gnu/lib my-handler.o misc.o -lamiga -lgcc -lc -lamiga -lc -lgcc /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/libgcc.a(__main.o): Undefined symbol _atexit referenced from text segment What did i miss ???? i have also trouble to link a library. is the someone voluntier and tries this on his setup ? makefile etc is there. he linker doesnt find one entrie there too. maybe the problems are connected but a reinstall of the gcc-package didnt help. walter -- ----- "Can you get us down?" "Down is not the problem!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Sep 20 00:11:50 1995 Received: from unixg.ubc.ca ([137.82.27.14]) by nic.funet.fi with SMTP id <89882-4>; Wed, 20 Sep 1995 00:11:12 +0300 Received: from netinfo.ubc.ca (netinfo.ubc.ca [137.82.27.44]) by unixg.ubc.ca (8.6.12/8.6.12) with SMTP id OAA13901; Tue, 19 Sep 1995 14:07:20 -0700 Date: Tue, 19 Sep 1995 14:07:19 -0700 (PDT) From: Warren Van Winckel X-Sender: warrenvw@netinfo.ubc.ca To: Walter Harms cc: amiga gcc-list Subject: Missing files... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/libgcc.a(__main.o): I figured something was wrong when I didn't have anything in that subdirectory! What files should be there? (I downloaded the 2.7.0 from Aminet and am very puzzled why they are missing.) Warren From amiga-gcc-port-owner@nic.funet.fi Wed Sep 20 02:44:34 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89224-2>; Wed, 20 Sep 1995 02:43:05 +0300 Received: from hookomo.aloha.net by funet.fi with SMTP (PP); Wed, 20 Sep 1995 02:42:48 +0300 Received: (from newsham@localhost) by hookomo.aloha.net (8.6.12/8.6.9) id NAA00302 for amiga-gcc-port@nic.funet.fi; Tue, 19 Sep 1995 13:38:44 -1000 From: Timothy Newsham Message-Id: <199509192338.NAA00302@hookomo.aloha.net> Subject: gcc protecting me? To: amiga-gcc-port@nic.funet.fi Date: Tue, 19 Sep 1995 13:38:43 -1000 (HST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1328 Hi, I used to be able to run code in supervisor mode by setting the exception vector for priv violation to point to my code and then execute a priv instruction. After my code was done it did an RTE and all was back to normal. Now when I do the same (after upgrading from 2.2.2 -> 2.7.0) my code runs but as soon as the RTE is hit the system goes belly up. The question is: Is GCC protecting me in some way? Is it causing me to write to a pseudo-exception vector and then calling that code in normal (non-supervisor) mode and not liking the RTE (wants an RTS)? If I want to use supervisor mode and I dont want to link against any amiga specific libraries how do I do it? If I want to use amiga specific libraries how do I do it? Does GCC use the MMU in any way? My code is trying to turn on the MMU and failing (crash). I am not running any programs that should use the MMU in any way (ie. it should be off). Even though it should be off I'm explicitely turning it off before I fiddle with it, this doesn't seem to be helping. Can someone please explain what sort of protection GCC and possibly the ixemul or other libs provide for programs compiled by gcc? If it tests for specific hardware for various levels of protection I have an 030 with an MMU and an external FPU. Tim N. From amiga-gcc-port-owner@nic.funet.fi Wed Sep 20 06:12:46 1995 Received: from undergrad.math.uwaterloo.ca ([129.97.204.13]) by nic.funet.fi with SMTP id <89886-2>; Wed, 20 Sep 1995 06:12:02 +0300 Received: from cnts1p17.uwaterloo.ca ([129.97.112.17]) by undergrad.math.uwaterloo.ca with SMTP id <56861-2>; Tue, 19 Sep 1995 23:11:28 -0400 Date: Tue, 19 Sep 1995 19:11:27 -0400 From: Jeff Shepherd Reply-To: jsshephe@undergrad.math.uwaterloo.ca To: Walter Harms cc: amiga gcc-list Subject: Re: problems with linking In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 19 Sep 1995, Walter Harms wrote: > i tried to compile an example-handler with gcc and found this linker error. > the function is defined in libgcc.a, it is the latest version > i have no idea what went wrong. > > /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/libgcc.a(__main.o): > Undefined symbol _atexit referenced from text segment > [-v output snipped] Though the output is not clear what went wrong, there is no definition for main() in your modules. Maybe someone can fix this. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/ The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Wed Sep 20 10:00:39 1995 Received: by nic.funet.fi via suspension id <88994-4>; Wed, 20 Sep 1995 10:00:08 +0300 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89100-3>; Wed, 20 Sep 1995 09:50:07 +0300 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 20 Sep 1995 08:47:08 +0200 (METDST) From: Rask Lambertsen To: Stanislav Brabec Cc: amiga-gcc-port@nic.funet.fi Subject: Re: About .. in root, stderr, DosWedge, Ctrl-C, etc. In-Reply-To: <199509191901.VAA32481@k332.feld.cvut.cz> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 19 Sep 1995, Stanislav Brabec wrote: > suggestions and answers for some questions and problems list: > (gcc 2.7.0, ixemul 41.3) > > Trouble with pr_CES (stderr) in v 41.3 > ------ > My favourite (memory saving) way to run sh was: > `sh <>DEV:tty01' (with DevHandler) or `sh <>CON:arguments' (with CON): > Now it does not work, because <> doesn't redirect stderr. > > Does anybody know, how to redirect stderr from DOS line? Otherwise I must > run sh from CLI (needs extra memory for CLI ctructure), or (better way) to > create special program (getty) to start sh. > Similar problem you can find with remote sh. It requires getty and login. ixprefs has as option "Open console if no stderr", try turning it off. Then unless you shell sets up pr_CES (not many does), stderr will use pr_COS, which can be redirected. > Trouble with DosWedge ~ > -------- > I have been looking at DosWedge. It's ugly utility, because it requires > more than 60kB to patch .., . and ~ in dos.library (requires matrix.library > and a tabs.gadget). > The problem of `~' evaluation in ixemul is from different world > than DosWedge. This is a standard UNIX special character. It it correctly > parsed in ixemul.library. But examination of user's home directory fails. > because ixemul have no support of MultiUser (see my earlier mail). > For now there's easy way to do it: > > in S:user-startup: > Run MAssign HOME: %h > > in global shell .profile: > HOME=/HOME > CD Since ixemul.library emulates UNIX, I would prefer if ixemul.library would lookup user home directories in ETC:passwd, like on UNIX systems. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Sep 20 10:09:43 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89291-4>; Wed, 20 Sep 1995 10:09:08 +0300 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 20 Sep 1995 09:05:48 +0200 (METDST) From: Rask Lambertsen To: Timothy Newsham Cc: amiga-gcc-port@nic.funet.fi Subject: Re: gcc protecting me? In-Reply-To: <199509192338.NAA00302@hookomo.aloha.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 19 Sep 1995, Timothy Newsham wrote: > Hi, > I used to be able to run code in supervisor mode by > setting the exception vector for priv violation to point > to my code and then execute a priv instruction. After > my code was done it did an RTE and all was back to normal. > Now when I do the same (after upgrading from 2.2.2 -> 2.7.0) > my code runs but as soon as the RTE is hit the system > goes belly up. 1) Just how are you changing the exeption vector? Poking the exection vector directly is a good recipe for disaster. If you really must change it, use OS functions. 2) Running code in supervisor mode is done with the Supervisor() function. > The question is: Is GCC protecting me in some way? Is > it causing me to write to a pseudo-exception vector and > then calling that code in normal (non-supervisor) mode > and not liking the RTE (wants an RTS)? > > If I want to use supervisor mode and I dont want to link > against any amiga specific libraries how do I do it? > If I want to use amiga specific libraries how do I do it? Use the inline header files and call Supervisor(). In your case, #include . Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Sep 20 12:34:49 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89707-1>; Wed, 20 Sep 1995 12:27:43 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 20 Sep 95 11:26 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 20 Sep 95 11:23 MET DST Message-Id: Subject: Re: About .. in root, stderr, DosWedge, Ctrl-C, etc. To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 20 Sep 1995 11:23:23 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 463 > > > > > in global shell .profile: > > HOME=/HOME > > CD > > Since ixemul.library emulates UNIX, I would prefer if ixemul.library would > lookup user home directories in ETC:passwd, like on UNIX systems. > i dont think tahts a good idea because there is no need to make ixemul more complex than it is already. a cd to GNU: or HOME: maybe SYS: should be enought. walter -- ----- "Anything that's not impossible is merely waiting to happen." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Sep 20 12:56:34 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89239-1>; Wed, 20 Sep 1995 12:55:43 +0300 Received: from meta.gmd.de (meta) by gmdzi.gmd.de with SMTP id AA20698 (5.65c8/IDA-1.4.4 for ); Wed, 20 Sep 1995 11:55:01 +0200 Received: by meta.gmd.de id AA00617 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi (amiga gcc-list)); Wed, 20 Sep 1995 11:53:07 +0200 Date: Wed, 20 Sep 1995 11:53:07 +0200 From: Joerg Hoehle Message-Id: <199509200953.AA00617@meta.gmd.de> To: amiga-gcc-port@nic.funet.fi (amiga gcc-list) Subject: Re: About .. in root, stderr, DosWedge, Ctrl-C, etc. In-Reply-To: References: Walter Harms writes: > a cd to GNU: or HOME: maybe SYS: should be enought. It depends on what you might use ixemul for. I object to an HOME assign because it's global and I'm trying to let several people into my system using AmiTCP (I hate their IMHO brain-damaged login/cd HOME: since version 3.0). If we agree that multiuser is the way to go (I have never used it), then ixemul should use it. Otherwise, I find GNUEMACS' redirection to S: practical. If it's the ixemul with AmiTCP networking code, it might as well use AmiTCP:db/passwd. There are already too many passwd files around here. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Sep 20 13:09:17 1995 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <89800-4>; Wed, 20 Sep 1995 13:07:47 +0300 Received: by hald.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 20 Sep 1995 12:08:32 +0200 (METDST) From: Rask Lambertsen To: Joerg Hoehle Cc: amiga gcc-list Subject: Re: About .. in root, stderr, DosWedge, Ctrl-C, etc. In-Reply-To: <199509200953.AA00617@meta.gmd.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 20 Sep 1995, Joerg Hoehle wrote: > Walter Harms writes: > > a cd to GNU: or HOME: maybe SYS: should be enought. > It depends on what you might use ixemul for. I object to an HOME > assign because it's global and I'm trying to let several people into > my system using AmiTCP (I hate their IMHO brain-damaged login/cd HOME: > since version 3.0). > > If we agree that multiuser is the way to go (I have never used it), > then ixemul should use it. Otherwise, I find GNUEMACS' redirection to > S: practical. > > If it's the ixemul with AmiTCP networking code, it might as well use > AmiTCP:db/passwd. There are already too many passwd files around here. I like the idea of using AmiTCP:db/passwd (I'm assigning ETC: to AmiTCP:db already). Maybe GNU:bin/ls could then get user and group names from this file instead of just using "amiga". Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Sep 20 13:18:58 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <89658-2>; Wed, 20 Sep 1995 13:17:52 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 20 Sep 95 12:14:02 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2153c685.u8t20e.a77cd-robert@plukwa.pdi.lodz.pl> Subject: Re: About .. in root, stderr, DosWedge, Ctrl-C, etc. In-Reply-To: <199509200953.AA00617@meta.gmd.de> (from Joerg Hoehle ) (at Wed, 20 Sep 1995 11:53:07 +0200) Reply-To: robert@pdi.lodz.pl Content-Length: 1287 To: hoehle@zeus.gmd.de Cc: amiga-gcc-port@nic.funet.fi Date: Wed, 20 Sep 95 12:14:02 On Sep 20 Joerg Hoehle wrote: > Walter Harms writes: > > a cd to GNU: or HOME: maybe SYS: should be enought. > It depends on what you might use ixemul for. I object to an HOME > assign because it's global and I'm trying to let several people into > my system using AmiTCP (I hate their IMHO brain-damaged login/cd HOME: > since version 3.0). > > If we agree that multiuser is the way to go (I have never used it), > then ixemul should use it. Otherwise, I find GNUEMACS' redirection to > S: practical. > > If it's the ixemul with AmiTCP networking code, it might as well use > AmiTCP:db/passwd. There are already too many passwd files around here. This last option seems resonable for me. BTW: when will be ixemul with AmiTCP net code ? > > Joerg Hoehle. > Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Sep 20 14:02:33 1995 Received: from DBSTU1.RZ.TU-BS.DE ([134.169.1.1]) by nic.funet.fi with SMTP id <88967-3>; Wed, 20 Sep 1995 14:00:58 +0300 Received: from rzab0.rz.tu-bs.de by DBSTU1.RZ.TU-BS.DE (IBM VM SMTP V2R2) with TCP; Wed, 20 Sep 95 13:00:58 MEZ Received: by rzab0.rz.tu-bs.de (1.37.109.15/15.6) id AA104134806; Wed, 20 Sep 1995 13:00:06 +0200 From: Sven Heithecker Subject: Help ! Cant subscribe ... To: amiga-gcc-port@nic.funet.fi (Sven Heithecker) Date: Wed, 20 Sep 1995 13:00:04 +0100 (MESZ) X-Mailer: ELM [version 2.4 PL11] Content-Type: text Content-Length: 861 Message-Id: <95Sep20.140058+0300_eet_dst.88967-3+86@nic.funet.fi> Hello !! I tried to subscribe to the gcc mailinglist, but it didn't work - I tried the adress in the gcc270-archives, but I got the answer that no such lists exists. I send an LISt command to the server and got a list of all currently running mailing-lists - the only amiga-specivic list was ixemul.blabla ( dont remember the reral name). But when I sent something to amiga-gcc-port@nic.funet.fi every- body seems to get it - i got many private answers to , so I hope that someone reads this also and can give me some hints how to subscribe ! P.S. there is another guy who want to ged rid of this list but he can't unsubscribe - maybe theres something wrong with that listserver ??? Please answer me with private mail !! ____ |_||_ Ceterum Censeo MEGAHARD Esse Delendam | | _| HTS Sven Heithecker s.heithecker@tu-bs.de From amiga-gcc-port-owner@nic.funet.fi Wed Sep 20 15:41:17 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <89209-3>; Wed, 20 Sep 1995 15:40:08 +0300 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 20 Sep 1995 14:36:24 +0200 (METDST) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Correction for README-2.7.1 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, There is a very bad error in README-2.7.1. The address to write to to subscribe to the list was wrong. A new README is available as "http://srv2.gbar.dtu.dk:8001/Rask/README-2.7.1" (mail me if you can't get it, I'll then send it by E-mail). Here is a diff from the last README: *** README-2.7.1.old Wed Sep 20 14:35:36 1995 --- README-2.7.1 Wed Sep 20 14:36:00 1995 *************** *** 16,22 **** This is the preferred place to ask for help since I'm on this list and every GCC developers also, libnix & ixemul authors, etc... ! Short: send an email to listserv@lists.funet.fi, and put in body: subscribe amiga-gcc-port your_first_name your_last_name (insert your own first name and your own last name above) --- 16,22 ---- This is the preferred place to ask for help since I'm on this list and every GCC developers also, libnix & ixemul authors, etc... ! Short: send an email to mailserver@lists.funet.fi, and put in body: subscribe amiga-gcc-port your_first_name your_last_name (insert your own first name and your own last name above) Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW homepage: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Sep 21 00:32:37 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89351-2>; Thu, 21 Sep 1995 00:30:56 +0300 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 20 Sep 95 23:30 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 20 Sep 95 23:28 MET DST Message-Id: Subject: problems with handler/device To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 20 Sep 1995 23:28:38 +0200 (MET DST) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 538 i compiled an example device and a handler for gcc but i didnt get them to work. i guess there are some linker options missing because the device gets a 'nonloadabel hunk' as error. but the handler refuse to do anything, actualy he is IN the system but noone can access. who has experience with that ? i can mail a dir that contains anything including a makefle. HELP!!! walter -- ----- "You should sell an instruction & maintenance manual with these!" "If I did, what would happen to Man's search for knowledge?" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Sep 21 08:16:56 1995 Received: from unixg.ubc.ca ([137.82.27.14]) by nic.funet.fi with SMTP id <88914-3>; Thu, 21 Sep 1995 08:15:46 +0300 Received: from netinfo.ubc.ca (netinfo.ubc.ca [137.82.27.44]) by unixg.ubc.ca (8.6.12/8.6.12) with SMTP id WAA01570 for ; Wed, 20 Sep 1995 22:15:17 -0700 Date: Wed, 20 Sep 1995 22:15:16 -0700 (PDT) From: Warren Van Winckel X-Sender: warrenvw@netinfo.ubc.ca To: GCC Subject: strings Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have a partially functional string class. But there is a problem with order of variable input. :) #1: #include #include "string.h" void main() { string a = "Not a new string..."; int b; cout << "Enter an Integer: " << endl; cin >> b; cout << "The Integer is " << b << endl; cout << "Enter a new string: " << endl; cin >> a; cout << "Here is the string: " << a << "." << endl; } This program DOES NOT WORK. If the line "cin >> a;" is put BEFORE cin >> b;, then the program works, as in the following example. Any ideas? WHY would GCC2.7.0 OR the string class have this apparent scope problem? #2 #include #include "string.h" void main() { string a = "Not a new string..."; cout << "Enter a new string..." << endl; cin >> a; cout << "Here is the string: " << a << "." << endl; int b; cout << "Enter an Integer: " << endl; cin >> b; cout << "The Integer is " << b << endl; } Warren From amiga-gcc-port-owner@nic.funet.fi Thu Sep 21 09:28:46 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88950-2>; Thu, 21 Sep 1995 09:27:56 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0svf89-0004nZC; Wed, 20 Sep 95 23:29 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: strings To: warrenvw@unixg.ubc.ca (Warren Van Winckel) Date: Wed, 20 Sep 1995 23:29:09 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Warren Van Winckel" at Sep 20, 95 10:15:16 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1705 > I have a partially functional string class. But there is a problem with > order of variable input. :) What compiler? Where did you get it? > This program DOES NOT WORK. What does it do wrong? > WHY would GCC2.7.0 OR the string class have this apparent scope problem? Dunno. First I had to fix the code since both occurances of "string" needed to be changed to "String". Here is what I get on both Linux and AmigaDOS using gcc 2.7.0 and the latest libg++ (the results were identical). The version of gcc I'm using is off of FreshFish Vol 10. I haven't gotten around to installing the aminet release yet: Script started on Wed Sep 20 23:20:05 1995 fishpond [1] cat junk.cc #include #include "String.h" //Note fix void main() { String a = "Not a new string..."; //Note fix int b; cout << "Enter an Integer: " << endl; cin >> b; cout << "The Integer is " << b << endl; cout << "Enter a new string: " << endl; cin >> a; cout << "Here is the string: " << a << "." << endl; } fishpond [2] g++ -o junk junk.cc fishpond [3] junk Enter an Integer: 4 The Integer is 4 Enter a new string: 6 Here is the string: 6. fishpond [4] cat junk2.cc #include #include "String.h" //Note fix void main() { String a = "Not a new string..."; //Note fix cout << "Enter a new string..." << endl; cin >> a; cout << "Here is the string: " << a << "." << endl; int b; cout << "Enter an Integer: " << endl; cin >> b; cout << "The Integer is " << b << endl; } fishpond [5] g++ -o junk2 junk2.cc fishpond [6] junk2 Enter a new string... 6 Here is the string: 6. Enter an Integer: 4 The Integer is 4 fishpond [7] exit Script done on Wed Sep 20 23:20:58 1995 From amiga-gcc-port-owner@nic.funet.fi Thu Sep 21 11:41:56 1995 Received: from chopin.ucc.hull.ac.uk ([150.237.176.14]) by nic.funet.fi with ESMTP id <89046-1>; Thu, 21 Sep 1995 11:36:47 +0300 Received: from mailhub.dcs.hull.ac.uk (actually host bertie.dcs.hull.ac.uk) by chopin with SMTP internet(PP); Thu, 21 Sep 1995 09:30:59 +0100 Received: from scarlet.dcs.hull.ac.uk by mailhub.dcs.hull.ac.uk with smtp (Smail3.1.29.1 #3) id m0svh48-0003rdC; Thu, 21 Sep 95 09:33 BST From: Chris Watson Message-Id: <8165.9509210837@scarlet.dcs.hull.ac.uk> Subject: Re: strings To: fnf@amigalib.com (Fred Fish) Date: Thu, 21 Sep 1995 09:37:23 +0100 (BST) Cc: warrenvw@unixg.ubc.ca, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Fred Fish" at Sep 20, 95 11:29:09 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1150 > > I have a partially functional string class. But there is a problem with > > order of variable input. :) You mean you wrote your own? If so why? Since gcc supports two good string classes anyway. If you have a problem with your string class then you would need to supply the code. But, I recommend moving to one of the standard ones anyway. > What compiler? Where did you get it? > > > This program DOES NOT WORK. > > What does it do wrong? > > > WHY would GCC2.7.0 OR the string class have this apparent scope problem? > > Dunno. First I had to fix the code since both occurances of "string" > needed to be changed to "String". "String" is part of libg++. "string" is part of the draft standard and supported in gcc; at least in 2.6.3 the version I'm looking at. To quote your friendly neighbourhood April working paper (HTML version): // subclause _lib.string_, string: struct string_char_traits; typedef basic_string string; All that said, however, I can't get the string version to complie on 2.6.3 thanks to gcc template handling. I must get a copy of 2.7.0 with the repository patch installed here From amiga-gcc-port-owner@nic.funet.fi Thu Sep 21 19:54:54 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89587-1>; Thu, 21 Sep 1995 13:06:31 +0300 Received: from bastion.nmrc.ucc.ie (actually host nmrc.ucc.ie) by funet.fi with SMTP (PP); Thu, 21 Sep 1995 13:06:19 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA12667 for ; Thu, 21 Sep 1995 11:04:55 +0100 From: Lars Hecking Message-Id: <199509211008.LAA01239@mostar.nmrc.ucc.ie> Subject: Re: strings To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Thu, 21 Sep 1995 11:08:26 +0100 (BST) In-Reply-To: from "Warren Van Winckel" at Sep 20, 95 10:15:16 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 56 > void main() { ^^^^ The prototype of main is int. From amiga-gcc-port-owner@nic.funet.fi Thu Sep 21 19:55:11 1995 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by nic.funet.fi with SMTP id <89350-2>; Thu, 21 Sep 1995 12:56:46 +0300 Received: from athena.cs.utwente.nl by utrhcs.cs.utwente.nl (5.x/csrelayMX-SVR4_1.1tmp/RB) id AA02106; Thu, 21 Sep 1995 11:56:39 +0200 Received: from tooheys.cs.utwente.nl by athena.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id LAA22931; Thu, 21 Sep 1995 11:56:37 +0200 Received: by tooheys.cs.utwente.nl (SMI-8.6/SMI-SVR4) id LAA02303; Thu, 21 Sep 1995 11:56:34 +0200 Date: Thu, 21 Sep 1995 11:56:34 +0200 From: alberts@cs.utwente.nl (Mert Alberts) Message-Id: <199509210956.LAA02303@tooheys.cs.utwente.nl> To: amiga-gcc-port@nic.funet.fi Subject: chip/fast problem revisited X-Sun-Charset: US-ASCII Here I go again ... the chip/fast problem revisited. (sorry, but I'm determined to also use gcc for Amiga-specific stuff) Maybe a simple example program better illustrates my problems in using gcc 2.6.3 to compile examples from the RKR Manual and the Amiga C Man. I took it from the second source. The things I tried where (amongst others) gcc -Xlinker -chip -o test sprite1.c and gcc -Wl -chip -o test sprite1.c (as suggested by Lars Hecking) However, in all cases gcc complained that it didn't recognise "-chip". Walter Harms stated that most examples from the forementioned sources can be compiled without the use of chip or fast. However, leaving out the keyword chip didn't solve the problem. And I'm not sure how to implement the other suggestion by Walter using "allocmem(sizeof(),MEMF_CHIP)". Any suggestions for getting the example code excepted by gcc2.6.3., or (better yet) some general way of dealing with amiga-specific options in RKRM and ACM? Thanks, Mert ----------------------- the code: sprite1.c ------------------------------ /* Example1 */ /* This program shows how to declare and initialize some sprite data */ /* and a SimpleSprite structure. It also shows how to reserve a sprite */ /* (sprite 2), and how to move it around. The user moves the sprite by */ /* pressing the arrow keys. */ #include /* Include this file since you are using sprites: */ #include /* Declare the functions we are going to use: */ void main(); void free_memory(); struct IntuitionBase *IntuitionBase = NULL; /* We need to open the Graphics library since we are using sprites: */ struct GfxBase *GfxBase = NULL; /* Declare a pointer to a Window structure: */ struct Window *my_window = NULL; /* Declare and initialize your NewWindow structure: */ struct NewWindow my_new_window= { 40, /* LeftEdge x position of the window. */ 20, /* TopEdge y positio of the window. */ 200, /* Width 200 pixels wide. */ 100, /* Height 100 lines high. */ 0, /* DetailPen Text should be drawn with colour reg. 0 */ 1, /* BlockPen Blocks should be drawn with colour reg. 1 */ CLOSEWINDOW| /* IDCMPFlags The window will give us a message if the */ RAWKEY, /* user has selected the Close window gad, */ /* or if the user has pressed a key. */ SMART_REFRESH| /* Flags Intuition should refresh the window. */ WINDOWCLOSE| /* Close Gadget. */ WINDOWDRAG| /* Drag gadget. */ WINDOWDEPTH| /* Depth arrange Gadgets. */ WINDOWSIZING| /* Sizing Gadget. */ ACTIVATE, /* The window should be Active when opened. */ NULL, /* FirstGadget No Custom gadgets. */ NULL, /* CheckMark Use Intuition's default CheckMark. */ "SPRITES", /* Title Title of the window. */ NULL, /* Screen Connected to the Workbench Screen. */ NULL, /* BitMap No Custom BitMap. */ 80, /* MinWidth We will not allow the window to become */ 30, /* MinHeight smaller than 80 x 30, and not bigger */ 300, /* MaxWidth than 300 x 200. */ 200, /* MaxHeight */ WBENCHSCREEN /* Type Connected to the Workbench Screen. */ }; /*********************************************************************/ /* Extra information: */ /* When we declare the window pointer, the intuition library pointer */ /* etc, we initialize them to point to NULL: */ /* struct Window *my_window = NULL; */ /* Since we then know that all of the pointers will point to NULL */ /* when we start, we can check if they still point to NULL when we */ /* quit. If they do not point to NULL anymore, we close that window, */ /* library etc. */ /*********************************************************************/ /********************************************************/ /* 1. Declare and initialize some sprite graphics data: */ /********************************************************/ UWORD chip my_sprite_data[36]= { 0x0000, 0x0000, 0x0180, 0x0000, 0x03C0, 0x0000, 0x07E0, 0x0000, 0x0FF0, 0x0000, 0x1FF8, 0x0000, 0x3FFC, 0x0000, 0x7FFE, 0x0000, 0x0000, 0xFFFF, 0x0000, 0xFFFF, 0x7FFE, 0x7FFE, 0x3FFC, 0x3FFC, 0x1FF8, 0x1FF8, 0x0FF0, 0x0FF0, 0x07E0, 0x07E0, 0x03C0, 0x03C0, 0x0180, 0x0180, 0x0000, 0x0000 }; /*******************************************************/ /* 2. Declare and initialize a SimpleSprite structure: */ /*******************************************************/ struct SimpleSprite my_sprite= { my_sprite_data, /* posctldata, pointer to the sprite data. */ 16, /* height, 16 lines tall. */ 40, 60, /* x, y, position on the screen. */ -1, /* num, this field is automatically initialized when */ /* you call the GetSprite() function, so we set it to */ /* -1 for the moment. */ }; void main() { /* Sprite position: */ WORD x = my_sprite.x; WORD y = my_sprite.y; /* Direction of the sprite: */ WORD x_direction = 0; WORD y_direction = 0; /* Boolean variable used for the while loop: */ BOOL close_me = FALSE; ULONG class; /* IDCMP */ USHORT code; /* Code */ /* Declare a pointer to an IntuiMessage structure: */ struct IntuiMessage *my_message; /* Open the Intuition Library: */ IntuitionBase = (struct IntuitionBase *) OpenLibrary( "intuition.library", 0 ); if( IntuitionBase == NULL ) free_memory(); /* Could NOT open the Intuition Library! */ /* Since we are using sprites we need to open the Graphics Library: */ /* Open the Graphics Library: */ GfxBase = (struct GfxBase *) OpenLibrary( "graphics.library", 0); if( GfxBase == NULL ) free_memory(); /* Could NOT open the Graphics Library! */ /* We will now try to open the window: */ my_window = (struct Window *) OpenWindow( &my_new_window ); /* Have we opened the window succesfully? */ if(my_window == NULL) free_memory(); /* Could NOT open the Window! */ /* Change the colour register 21 - 23: */ SetRGB4( &my_window->WScreen->ViewPort, 21, 0xF, 0x0, 0x0 ); /* Red */ SetRGB4( &my_window->WScreen->ViewPort, 22, 0xF, 0xF, 0x0 ); /* Yellow */ SetRGB4( &my_window->WScreen->ViewPort, 23, 0x0, 0xF, 0x0 ); /* Green */ /*******************************/ /* 3. Try to reserve sprite 2: */ /*******************************/ if( GetSprite( &my_sprite, 2 ) != 2 ) free_memory(); /* Could not reserve sprite number 2. */ /* Stay in the while loop until the user has selected the Close window */ /* gadget: */ while( close_me == FALSE ) { /* Stay in the while loop as long as we can collect messages */ /* sucessfully: */ while(my_message = (struct IntuiMessage *) GetMsg(my_window->UserPort)) { /* After we have collected the message we can read it, and save any */ /* important values which we maybe want to check later: */ class = my_message->Class; code = my_message->Code; /* After we have read it we reply as fast as possible: */ /* REMEMBER! Do never try to read a message after you have replied! */ /* Some other process has maybe changed it. */ ReplyMsg( my_message ); /* Check which IDCMP flag was sent: */ switch( class ) { case CLOSEWINDOW: /* Quit! */ close_me=TRUE; break; case RAWKEY: /* A key was pressed! */ /* Check which key was pressed: */ switch( code ) { /* Up Arrow: */ case 0x4C: y_direction = -1; break; /* Pressed */ case 0x4C+0x80: y_direction = 0; break; /* Released */ /* Down Arrow: */ case 0x4D: y_direction = 1; break; /* Pressed */ case 0x4D+0x80: y_direction = 0; break; /* Released */ /* Right Arrow: */ case 0x4E: x_direction = 1; break; /* Pressed */ case 0x4E+0x80: x_direction = 0; break; /* Released */ /* Left Arrow: */ case 0x4F: x_direction = -1; break; /* Pressed */ case 0x4F+0x80: x_direction = 0; break; /* Released */ } break; } } /* Change the x/y position: */ x += x_direction; y += y_direction; /* Check that the sprite does not move outside the screen: */ if(x > 320) x = 320; if(x < 0) x = 0; if(y > 200) y = 200; if(y < 0) y = 0; /* Move the sprite: */ MoveSprite( 0, &my_sprite, x, y ); /* Wait for the videobeam to reach the top of the display: (This */ /* will slow down the animation so the user can see the sprite) */ WaitTOF(); } /* Free all allocated memory: (Close the window, libraries etc) */ free_memory(); /* THE END */ } /* This function frees all allocated memory. */ void free_memory() { if( my_sprite.num != -1 ) FreeSprite( my_sprite.num ); if( my_window ) CloseWindow( my_window ); if( GfxBase ) CloseLibrary( GfxBase ); if( IntuitionBase ) CloseLibrary( IntuitionBase ); exit(); } From amiga-gcc-port-owner@nic.funet.fi Thu Sep 21 20:38:08 1995 Received: from carina.rz.Uni-Osnabrueck.DE ([131.173.128.25]) by nic.funet.fi with SMTP id <90020-1>; Thu, 21 Sep 1995 20:37:24 +0300 Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id TAA21865; Thu, 21 Sep 1995 19:36:59 +0200 From: Thomas Radtke Received: (thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) id TAA13429; Thu, 21 Sep 1995 19:37:05 +0200 Message-Id: <199509211737.TAA13429@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: chip/fast problem revisited To: alberts@cs.utwente.nl (Mert Alberts) Date: Thu, 21 Sep 1995 19:37:04 +0200 (DFT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199509210956.LAA02303@tooheys.cs.utwente.nl> from "Mert Alberts" at Sep 21, 95 11:56:34 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 846 > > gcc -Xlinker -chip -o test sprite1.c > > and > > gcc -Wl -chip -o test sprite1.c (as suggested by Lars Hecking) > > However, in all cases gcc complained that it didn't recognise "-chip". I don't have the docs at hand, but shouldnt -chip be a _linker_ option ? Try -Wl,-chip. Maybe that works. > > > Walter Harms stated that most examples from the forementioned sources > can be compiled without the use of chip or fast. However, leaving out > the keyword chip didn't solve the problem. And I'm not sure how to > implement the other suggestion by Walter using > "allocmem(sizeof(),MEMF_CHIP)". That means, you copy the data to the pointer AllocMem returns, i.e. int gfxdata=0x1234; int *gfx=(int *)AllocMem(sizeof(int),MEMF_CHIP); *gfx=gfxdata; (be warned, I dont have tried the above code :) Thomas From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 01:55:45 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <90585-1>; Fri, 22 Sep 1995 01:53:24 +0300 Received: from lysistrate.lysator.liu.se (lysistrate.lysator.liu.se [130.236.254.161]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id AAA20263; Fri, 22 Sep 1995 00:52:46 +0200 Received: (nisse@localhost) by lysistrate.lysator.liu.se (8.6.11/8.6.11) id AAA09817; Fri, 22 Sep 1995 00:52:52 +0200 Date: Fri, 22 Sep 1995 00:52:52 +0200 Message-Id: <199509212252.AAA09817@lysistrate.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: Thomas.Radtke@rz.Uni-Osnabrueck.DE CC: alberts@cs.utwente.nl, amiga-gcc-port@nic.funet.fi In-reply-to: <199509211737.TAA13429@nereid.rz.Uni-Osnabrueck.DE> (message from Thomas Radtke on Thu, 21 Sep 1995 19:37:04 +0200 (DFT)) Subject: Re: chip/fast problem revisited From: Thomas Radtke Date: Thu, 21 Sep 1995 19:37:04 +0200 (DFT) > implement the other suggestion by Walter using > "allocmem(sizeof(),MEMF_CHIP)". That means, you copy the data to the pointer AllocMem returns, i.e. int gfxdata=0x1234; int *gfx=(int *)AllocMem(sizeof(int),MEMF_CHIP); *gfx=gfxdata; That's prbably wrong, although I don't really understand what you want it to do. The workaround is UWORD sprite_data[36] = { ... some data ... /* Space for this will not necessarily be * allocated in chip mem by compiler and linker. */ }; UWORD *chip_sprite_data = (UWORD *) AllocMem(sizeof sprite_data, MEMF_CHIP); memcpy(chip_sprite_data, sprite_data, sizeof sprite_data); The idea is to allocate chip memory by hand, and then copy the data into it, instead of relying on compiler keywords like chip to do it automatically. It would of course be nice if you could tell gcc to put some data into chip memory, but if I understodd this right last time the issue was discussed, the main obstacle is that the a.out object file format, and the assembler, only supports the three sections text, dat a and bss. If it were not for this, you could tell gcc which section to put variables in with an __attribute__ declaration (should be described in the manual). Regards, Niels Möller From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 02:34:16 1995 Received: from INVALID ([193.212.103.102]) by nic.funet.fi with SMTP id <89991-2>; Fri, 22 Sep 1995 02:33:48 +0300 Received: by INVALID.telepost.no (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 22 Sep 95 01:33:36 Received: by INVALID.telepost.no (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 22 Sep 95 01:26:33 Date: Fri, 22 Sep 1995 01:26:33 +0000 () From: Erik Johannessen X-Sender: erij@localhost Subject: Re: chip/fast problem revisited In-Reply-To: <199509210956.LAA02303@tooheys.cs.utwente.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: amiga-gcc-port@nic.funet.fi On Thu, 21 Sep 1995, Mert Alberts wrote: > The things I tried where (amongst others) > > gcc -Xlinker -chip -o test sprite1.c > > and > > gcc -Wl -chip -o test sprite1.c (as suggested by Lars Hecking) I think this one should be -Wl,-chip this will put all data in chipram (don't know about code). > /* 1. Declare and initialize some sprite graphics data: */ > /********************************************************/ > UWORD chip my_sprite_data[36]= ^^^^ You can't do this with gcc. this will cause a parse error. If you do not want all data in chip you have to do the following: UWORD my_spirte_data[36]= { 0x0000, 0x0000, 0x0180, 0x0000, 0x03C0, 0x0000, 0x07E0, 0x0000, 0x0FF0, 0x0000, 0x1FF8, 0x0000, 0x3FFC, 0x0000, 0x7FFE, 0x0000, 0x0000, 0xFFFF, 0x0000, 0xFFFF, 0x7FFE, 0x7FFE, 0x3FFC, 0x3FFC, 0x1FF8, 0x1FF8, 0x0FF0, 0x0FF0, 0x07E0, 0x07E0, 0x03C0, 0x03C0, 0x0180, 0x0180, 0x0000, 0x0000 }; UWORD *real_sprite_data; and somewhere in your init code: real_sprite_data=AllocMem(sizeof(my_sprite_data),MEMF_CHIP); memcpy(real_sprite_data,my_spritedata,sizeof(my_sprite_data)); -Erik -- Erik Johannessen - erij@telepost.no daffy@freenet.hut.fi From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 03:21:53 1995 Received: from sunmbx.netmbx.de ([192.76.152.9]) by nic.funet.fi with SMTP id <89991-1>; Fri, 22 Sep 1995 03:21:09 +0300 Received: by sunmbx.netmbx.de (/\==/\ Smail3.1.28.1) from tmpmbx.netmbx.de with smtp id ; Fri, 22 Sep 95 02:26 MET DST Received: by tmpmbx.netmbx.de (/\==/\ Smail3.1.28.1 #28.6) id ; Fri, 22 Sep 95 02:02 MES Received: from tbx by zelator.BerliNet.DE with bsmtp (Smail3.1.28.1 #11) id m0svxCC-00038UC; Fri, 22 Sep 95 01:46 MESZ To: amiga-gcc-port@lists.funet.fi Message-Id: <50187467@bw01.bbrandes.berlinet.de> From: B.WINKELMANN@BBrandes.berlinet.de (Bert Winkelmann) Path: tbx.berlinet.de!bbrandes.berlinet.de!B.WINKELMANN Subject: Re: __unwind_function() Date: Thu, 21 Sep 1995 19:37:36 +0200 X-Mailer: UMSZer V2.22 public References: X-Gateway: ZCONNECT U2 zelator.BerliNet.DE [UNIX/Connect v0.71] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-VIA: 19950921000000S+2@BBrandes.berlinet.de Lines: 73 Hi Kamil. >Actually, I thought that they should be called by ___unwind_func, that's >why I thought that your first implementation was too simple. I didn't even >think about preserving the registers (silly me...). Unluckily the g++-code seems does't restore his used registers a2-a4 after leaving the matched catch-block. Maybe this has something to do with this sentence from gcc-2.7.0/cp/cxxint.texi: `` The backend must be extended to fully support exceptions. Right now there are a few hooks into the alpha exception handling backend that resides in the C++ frontend from that backend that allows exception handling to work in g++. '' , but I don't believe this. >[...] >I think that a5@(2) is the return-address of code (pushed on stack by >jsr), NOT previous contents of A5 or A7 (or maybe I didn't understand the >description of "link" instruction in a reference manual...). Yes, a5@(4) is the function-return-address (the previous value of `a5' is in a5@) and this seems to me really like a termination for the unwinding without a matching `catch'. Sorry, I was confused about these entire assembler stuff. [...] >But this test doesn't make sense, at least on Amiga. First, why "cmpw", >not "cmpl"? This is because the different meaning of "cmp.w" and "cmpa.w". Wordoperations on addressregisters works with the complete address. (the same happens in `addqw #4,sp'). > I think that correct implementation would be to compare >LONG from a5@(2) with an address of code in startup code that immediately >follows "jsr" to main() (the question is: is main() called only from one >place, both for WB and Shell?). main() is called from the startup-code. AFAIK it's not possible for the stack-unwinder to recognize some special value of return-address of main(). How about this in the startup-code: movel #0,-(sp) link a5,#0 [... as usual: push the main()-arguments on stack and call main ...] unlk a5 addq.w #4,sp After the function-unwinding of _main, this would terminate the stack-unwinding without any change in the EH-code.? >[terminate()/unexpected()] I had used 'gcc' instead 'g++' in the shell. The functions are really in libstdc++.a as you said, but 'gcc' doesn't link these automatically, only 'g++' does it. My mistake, I had think stdc++ is for the STL on such things. > Have you contacted with Mike Stump? No, because the amiga-port isn't supported by GNU, and therefore it isn't possible "adding full EH-support to this machine" by the g++-developers (imho). But I will ask him for the concrete problems, maybe he can help nevertheless. Bert. From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 04:21:55 1995 Received: from sunmbx.netmbx.de ([192.76.152.9]) by nic.funet.fi with SMTP id <90775-3>; Fri, 22 Sep 1995 04:20:42 +0300 Received: by sunmbx.netmbx.de (/\==/\ Smail3.1.28.1) from tmpmbx.netmbx.de with smtp id ; Fri, 22 Sep 95 03:25 MET DST Received: by tmpmbx.netmbx.de (/\==/\ Smail3.1.28.1 #28.6) id ; Fri, 22 Sep 95 03:01 MES Received: from tbx by zelator.BerliNet.DE with bsmtp (Smail3.1.28.1 #11) id m0svxCD-0003SNC; Fri, 22 Sep 95 01:46 MESZ To: amiga-gcc-port@lists.funet.fi Message-Id: <50187468@bw01.bbrandes.berlinet.de> From: B.WINKELMANN@BBrandes.berlinet.de (Bert Winkelmann) Path: tbx.berlinet.de!bbrandes.berlinet.de!B.WINKELMANN Subject: new __unwind_function() Date: Thu, 21 Sep 1995 19:59:42 +0200 X-Mailer: UMSZer V2.22 public X-Gateway: ZCONNECT U2 zelator.BerliNet.DE [UNIX/Connect v0.71] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-VIA: 19950921000000S+2@BBrandes.berlinet.de Lines: 494 Hi. Here is a better version wich is more cleaner and handle more kinds (but not all) of functions-calls (incl. functions-pointer). I had no time nor source to make tests with real programs yet. But you have the source... The entire code is very simple and trivial. It works with 68000. ___unwind_function: | restore register (sp, a5, d0-d7, a1/a6) for a | a function which has interupted inside the body | by an exception. | | require: | 4(sp) points to a valid (returning) address. | a2 points to the last byte of the operand from the | function-call. | the function begins with `link a5,#d' and `a5' must | not changed. | ensure: | ( | sp,a5,d0-d7,a1/a6 becomes restored to the same values as at the | entry of the function . | a2,a3,a4 will preserverd. | If done, it goes to the address 4(sp) | ) | or | call _terminate__Fv | movel d0,-(sp) jbsr restore_address movel d0,-(sp) movel 4(sp),d0 jbsr restore_regs addql #8,sp move.l 4(sp),4(a5) | fake return-address to 'throw-handler' unlk a5 | stackframe-restore rts terminate: jsr _terminate__Fv || will never return. jsr _abort |# end of ___unwind_function ||||||||||||||||||||| restore_address: | found the functions-address or goto terminate | require: | a2 points to the last byte of the operand from the | function-call | the function begins with `link a5,#d' | ensure: | `d0' contents the rval. | other registers unchanged moveml d1-d3/a0-a1,-(sp) .scan_code: clr.l d0 clr.l d1 move.b -3(a2),d1; lsl.w #8,d1; move.b -2(a2),d1 cmp.w #0x6100,d1 |* BSR <16> (tested) bne 0f lea is_bsr_0,a0 addq #1,d0 0: cmp.b #0x61,-1(a2) |* BSR.S <8> (tested) bne 0f tst.b (a2) beq 0f lea is_bsr_1,a0 addq #1,d0 0: move.b -3(a2),d1; lsl.w #8,d1; move.b -2(a2),d1 cmp.w #0x4eb8,d1 |* JSR <16>.W size=4 (not tested) bne 0f lea is_jsr_111000,a0 addq #1,d0 0: move.b -5(a2),d1; lsl.w #8,d1; move.b -4(a2),d1 cmp.w #0x4eb9,d1 |* JSR <32> size=6 (tested) bne 0f lea is_jsr_111001,a0 addq #1,d0 0: move.b -1(a2),d1; lsl.w #8,d1; move.b (a2),d1 move.l d1,d2 and.w #0b1111111111111000,d1 cmp.w #0b0100111010010000,d1 |* JSR (An) size=2 (tested) bne 0f lea is_jsr_010,a0 addq #1,d0 0: move.b -3(a2),d1; lsl.w #8,d1; move.b -2(a2),d1 cmp.w #0b0100111010111010,d1 |* JSR d(PC) size=4 (not tested) beq terminate 0: | sorry: runtime-computed JSRs induce always an program-abort |- and the entire function becomes useless therefore |-- for seriously programming. :-(. I give it up. move.b -3(a2),d1; lsl.w #8,d1; move.b -2(a2),d1 and.w #0b1111111111111000,d1 cmp.w #0b0100111010101000,d1 |* JSR d(An) size=4 (not tested) beq terminate 0: move.b -3(a2),d1; lsl.w #8,d1; move.b -2(a2),d1 and.w #0b1111111111111000,d1 cmp.w #0b0100111010110000,d1 |* JSR d(An,Rx) size=4 (not tested) beq terminate 0: move.b -3(a2),d1; lsl.w #8,d1; move.b -2(a2),d1 cmp.w #0b0100111010111011,d1 |* JSR d(PC,Rx) size=4 (not tested) beq terminate 0: cmp #1,d0 ||- Is the call ambigous? bne terminate; ||-- Yes, we give up. 0: extract_address: | ('a0' contents the jumplabel) | ('a2' point to the 'throwing-code' (don't touch it)) | ('d2' contents the opcode (only for relative jsr's)) jmp (a0) is_bsr_0: lea -3(a2),a0 clr.l d0 move.b 2(a0),d0; lsl.w #8,d0; move.b 3(a0),d0 |== move.w 2(a0),d0 lea 2(a0,d0.w),a1 bra 0f is_bsr_1: lea -1(a2),a0 clr.l d0 move.b 1(a0),d0 bpl 1f ori.w #0xff00,d0 | expand minus-sign (8=>16bit) 1: lea 2(a0,d0.w),a1 bra 0f is_jsr_111000: lea -3(a2),a0 clr.l d0 move.b 2(a0),d0; lsl.w #8,d0; move.b 3(a0),d0 |== move.w 2(a0),d0 lea 2(a0,d0.w),a1 bra 0f is_jsr_111001: lea -5(a2),a0 moveb 2(a0),d1 |*- lsl.w #8,d1 |* moveb 3(a0),d1 |* lsl.l #8,d1 |* (move.l 2(a0),a1 for 68000) moveb 4(a0),d1 |* lsl.l #8,d1 |* moveb 5(a0),d1 |* move.l d1,a1 |*- bra 0f is_jsr_010: and.l #0b111,d2 || register-number a0-a7 => 0-7 muls #0x200,d2 || v swap d2 || register-nuber a0-a7 => $0xxxxxx-$fxxxxxx or.l #0x206d0000,d2 || movea.l d(a5),dn (n=d2,d=0000) moveb -5(a2),d1 |*- lsl.w #8,d1 |* moveb -4(a2),d1 |* lsl.l #8,d1 |* (move.l -5(a2),d1 for 68000) moveb -3(a2),d1 |* lsl.l #8,d1 |* moveb -2(a2),d1 |*- move.l d1,d3 clr.w d1 cmp.l d1,d2 bne terminate movel (a5),a6 movel (a6,d3.w),a1 || a1--result bra 0f 0: movel a1,d0 moveml (sp)+,d1-d3/a0-a1 rts | end of restore_adddress ||||||||||||||||||||||||||| undo the `movem.l ...,-(sp)' from the functions-beginning restore_regs: | require: | '4(sp)' contents a pointer to function-beginning | the function must begin with an `link a5,#d' | and no further `link a5,#d' must occur | ensure: | a2,a3,a4,a5 remain unchanged | moveml d0/a1,-(sp) movel 12(a7),a1 | movel d1,-(sp) | || cmp.w #0x4e55,(a1) | Is there an LINK-opcode on the begin? cmp.b #0x4e,(a1) bne 1f |-- (no) cmp.b #0x55,1(a1) beq 0f |-- yes. 1: bra terminate |-- no. we must give up, because unknown stacksize. 0: move.l #-1,d0 | store alloc-displacement-value in d0 move.b 2(a1),d0; lsl.w #8,d0; move.b 3(a1),d0 |== move.w 2(a1),d0 || cmp.w #0x48e7,4(a1) | Is thre an MOVEM-opcode. cmp.b #0x48,4(a1) bne 1f |-- No cmp.b #0xe7,5(a1) beq 0f |-- Yes 1: movel (sp)+,d1 |-- No, nothing to restore. bra leave 0: move.b 6(a1),d1; lsl.w #8,d1; move.b 7(a1),d1 |== move.w 6(a1),d1 exg d1,d0 lea -4(a5,d1),a1 movel (sp)+,d1 do_regs_restore: | (`d0' contents now the argument of MOVEM-opcode) | (`a1' points behind allocated block (stored registers)) btst #0,d0 beq 0f sub.l #4,a1 |`a7' is used as the stackpointer 0: btst #1,d0 beq 0f move.l (a1),a6 sub.l #4,a1 0: btst #2,d0 beq 0f sub.l #4,a1 | `a5' is used as the framepointer 0: | the following three registers (a2,a3,a4) are used | by the G++-exception-handling-code *and* must not be restored. | They are only restored if no exception was happen, but this is | not the case now. | this may change in future releases of g++. btst #3,d0 beq 0f ||| move.l (a1),a4 || `a4' points to `execption-object' sub.l #4,a1 0: btst #4,d0 beq 0f ||| move.l (a1),a3 || `a3' points to `exception-type' (not needed for -frtti) sub.l #4,a1 0: btst #5,d0 beq 0f ||| move.l (a1),a2 || `a2' points to `throwing-code' sub.l #4,a1 0: btst #6,d0 beq 0f move.l (a1),(sp) sub.l #4,a1 0: btst #7,d0 beq 0f move.l (a1),a0 sub.l #4,a1 0: btst #8,d0 beq 0f move.l (a1),d7 sub.l #4,a1 0: btst #9,d0 beq 0f move.l (a1),d6 sub.l #4,a1 0: btst #10,d0 beq 0f move.l (a1),d5 sub.l #4,a1 0: btst #11,d0 beq 0f move.l (a1),d4 sub.l #4,a1 0: btst #12,d0 beq 0f move.l (a1),d3 sub.l #4,a1 0: btst #13,d0 beq 0f move.l (a1),d2 sub.l #4,a1 0: btst #14,d0 beq 0f move.l (a1),d1 sub.l #4,a1 0: btst #15,d0 beq 0f move.l (a1),4(sp) sub.l #4,a1 0: leave: moveml (sp)+,d0/a1 rts | end of restore regs begin 644 unwind_stack.cc.gz M'XL("!B_83```75N=VEN9%]S=&%C:RYC8P#,6V&3VS:2_;RL_1&X<:Y&XQ5E, M:6Q/O)/8>XXWN>1J+W'%3FWMIPE$0A(\),$0Y&B4\H^_U]T`26DT=K+);IVJX M;,]00*/1Z'[]ND%_]NAA\I6VA6[5(O&F55F9JY/UG_ZD5.I4M_5I:WRKTK^^< M_?+-6Y6N-KK*"Y.:V\S4K7655ZJKMK;*KWRKL^M9EJFT M_=5507Z2?)EMG#IY^.W7MFHOU0_>J%>N>E786JU_YR<*)0NDV9V]\2>.T8U*FQOUW]_^<%G8Y:-U+ MEJ7T;YE=/)N?S]-L6::ZM&N=.__H?/;I;/X(7V/43._+=4KM"PZ+IZNE]J8QL MQ7$U?J,BRP]H<]*?4&^8W(1S^#VL2PKGOZ?E#HSQJV5_R!B#Z-_L74>-\?#;# MR>O"X*05_#YG-\]<69JJ]*>J=DW+CVB1EV2%]+LW(N(E(FS559D$N MM:MX2*W;C5J:=FL@+]-MMN&H;#>-VZJR`S!`TQJZY*7/4_U$+2%E:Z&V7FE[* MK2K7)@VPRC6&AK,YUWZ&;S%'P<`W)(VM2QM)EX7#`8OI2KW#4ZRD6I=X5^+?1 MQG7+PLR4FGR!=2RK`,F5$SMC"][FO!+&[D2:')=)HAWE[)9F@[5A=/QP?D MKI/CT3?.8C!6I,V/3H2.L%OSB26EME4:=9Y"7S%%Y98NWXF)Y>PQN*3MX&04? M39J<\9'N7-S*%N]-;K*W-:`;Y-C8M@6%LIGZO%,?5>IW MEA!@@SVI4T\$8.!/X"SP!AD_=*BU-Z9H=>U/2;ROUT"0S?$`3;TSI56YJ: M4^4(H,9%L;E)O?W9Q,,:>Z8I5%S=7E)IRNUK!9 M.ZI675M:S:UZ'T@S#,"Q?`-G=7S^8JK>R5=LYY/2W1@]PW*3ET_/IB^KS^CKRC64+C-.GTXA$$H+%S23,XFY+\)1+Q%R6]U@B=QZ[;TIE^0P)W1*=$)3/@"ER MRZ5=`X!VE)?9KLE@UZYA`]3.6S[MZ*&%TSD^R\!X-#-8G)P6=K9/488V>!M<(J]L M0"/2`Z67.RB*ITTP+6:D:9HD%%_PK]ZA:.[^N6HL)>A+/M]8AO.9(BSYAC>]W M!)I59!4B-+3REL^8HY;4V&KL!3%+(K0H1?Z#1XDMZ\*0P(B>I`YY)?('+`B-/ M;ZQ6!A$*Q,AS@"*.$/I<)I\O9_#F:U/`:-5_+9<-EC1^MC0-CMNTL]R\@+CDF MCZE\>'\K5Q1N2ZK8<"S()Y(XL_I1=GL+#C=KS:U5Z?%/DGR%.+XD>*.AMEJYE MJ5+?PFR7ZLL>[KZF:,(J])6Y!2O\JH&!WQ"#4=X1E-S-N#AO6KB%Q`%G-V$\>281+^S2M^1`'6S3`$!N3.%J,O>,B MYW/"\$8@#=;+&KL,&:J$(Y,D..DK2!K!;?!Z/*6(J=H4P3/%4_+'C<0?/3JFZ MU@I18^CHX_(TW-L,YYQAD/4EK7=\/WNRK4\$S%)X74LAH54!/RFLKV=A7^3'U M:FTJ@R0U58U;PAVG[)B%KM:=7IL$`CCV*20;4\.[HB<&=X^;'O0E8_3;'IM%' M-X/1>F/L*XFB!,[:VLQ3-+:'TF:R0B_$]T>"1`6_%27^O@&^I*NF;>T`:>/?6 M"!AR-[)B*#3:78T,L3'9-;OFEN18RLG5:1O$D$JF(A3(D=Y+TP,?S0UXE01QE M2R,#)VJWEN14Z'9$\9XM#0'/,]8@L-@T2DTQ8^54 M2^DW;..;GK0@&7@+&D7F+>VMF)R*FN2(OXJ-O*3$0:GY.%.["AT*T=61+R?UJ0BE?[#',?D<;;TPP+\"UGRDV$%?HOB$''+$\AL4T0W<@E45,B_5@/:.2(.`0EB#;";M@QR;J M1^``IRBROF*S:$J<4W$PG*CN6E<"N3)UHQNKE_0=G_V&0XC/HNDR&&N:6*)O2 M07G$Y6:LRF@@K0^^&E`I;(`)**F/I+\*Y0DJ.IC3_BS`:2GF:AV4?6.KS/38S M;9AL[\(`H:QALV57M+:F\&)JK`L'%QL($U5O.#]'TL@O@G>2P`!+HN#>D"H%6 M$\:HM6O=>#)"H6L8?]IL.E8N88AH];51'NS>:J)>#8=\S#-W]LM[\;RT%4WZN M)\PRB/-4.R%=\:1Q,E7.2^(!;HM-0\7K"M%TAGM;,LSHJ>-T2$LD&!NS`-NE;?VWK$:PE4<68X$*"BL?1!_[+7$\%)IB(1W`LR?6A/3DK) M`PJ.!P9&YFX<\588>,-%>K(R6S[WM60\*O1U&T+-\TF`UG*5H845T]=L%XB>D MDNK7QM1*)Z`VK?@Z09D$=V5@V@A)L\`-=`\!'/RPK?4;9+L^M-E7!?KR?`]Q/ M@AEIJ4`00O5JXE<4)*%N*>R*Z]A8QXR!Q_1'RVKGX`B43&4@QY=.-I:R<0\BC MD88&?7TXJ6(7="7(@\\.0C$ST5F?-E&9X$E)RZB-J\UXAPB@PJT!CG=8ZE3D!L;(9;Y;:O6QC77"Z:/?.UW)*$"_YCII!JO$7\_E\JFZ+5XH;-_X.`PNM= M*,CDOM`TL'*"C!;U?VCBR"$2H6+NZ-EXHK@>7)NCAM@T>`DG-`(-G5-04"*"" M^'AB`69N=-$-?$ZFVEBHCH*6^DY`FI`K^6!(V=$RJC`K4)B*&/N:VC>QO&5GQ MP.Y89C)J<6^U#T1QQ,V]BZ2/>E%$UHNMWGFNSI'%!:J3?<`3>:(:\(,B@<&+< M`(I:A8:1B'%^:R39)KQPSQNDHEUJ%/'XG*=BE`R]'5FPSW@ZG)TYZV?CI^ M*C`^&NRE^Y)LI1((9#5R\%D0+AT:PE/UYO7+[U^I"5%G]::K/`BB??SL@DAFM MF9`MQ7EC)X*0Y#6L0^EOU+G3!8[,2F6DBWH#8-S4-?XN+YY=LYC2UKX7$K`N] M6%6<&?Y#K0LXS9UF%&-5ZT`K8M,WL/H\EY)&FMKGT84IT-^8>"[T,#>MM@5M] M.;DCO2](B#6U!N;IT9"DF[+V4ADR7XA(AHAJ`CAB%#&RBDE@V`QX90:@(7.]: M"H+%K:AIQC]8PJ]DO%1$@@/!?<=Y\"!VRT$(L6:8LVDH1C1W;]NQ!%BO,3]U! MMF$/^*NC:D%:E(/,I*]/8$_.-4+_P%MVKI,VMOW93/F4=1;35.A=4@),@']+W MF(;L!QWRKJP#KF^=^O+KF.=80=D.B?$$-IXE$]B-B`IM`L=1!!QR%2/!RC:^> ME>*K[BC>0*QKRW6KP#_*OL01?Q'&!=ILS0A:.B_=*]X=(2I3;'H26#NJ1NEPB M:P1F/8B):O<*CTKN+>'EC;N.G;)ZMT>6A>?=K;I#!SH1&A?J#.R'\3BPIA4)W MEZRH*"M.>BEG8^)':R;C-7NHY&1-Y^%(TMK]A9.@)LHG#8T;=GEF@T3<$G:>> MT`?GHC#T(X1`R05`1$6RA7@\D!^"V%RP/G@NTG"(\T#**$E1BVV49/`HS.Z3$ M;V5NX12FH?ZF6T4NYEDPN')D"G*8-&';4#6`]!!Z&X3RV"A3,N9`V-*8H-/=" M2:0ED>G9*D"V]AM!A/_5NV4H&SF7$5T;S0">Q[D'_'^[<849-A"'1743B:J@/ M[MI%SZ1@EDLMQ^D(;AG\4?JYL5X5,XS:"C:F3PJ3@HY9(H&)(*,Z^$,(:W;,^ M/20)#1MQY:&WR`7.RF9Z:%_)/A`>.SC-K2+V+:=+[A)[5PD]AO9=Y[&&.$M/[=^*/<=P3(Z;<;$2;@PW1M?36-,P^ MIM"9BD4(+C@[5.:&.ZN,_L(Q=J/F0/@BQI?$7%;PQ8#X.442R+*/A1FMBBUP. M5$?N0L@2N13Y?(_"LKIT5,/%:2SL3:%OZ2S)YPD_@3Q!TM65K:ZR3;,FCT2(G MMN+A;0-"C!BN'M'*`(:T/-%A2>>D!(4^U\\`!LJ$VB<#< M>'*%4!G=QLMJ6/L=DNY1+21CQEN71/AY'&;V+IU[5X\%P<'N#L%C>FP0$]>A> M"Q?BFIKIB+YPC1`:QQ_@\4<$[W6$S989K7!-DD,W80B\_VR>3O'7!?WUJ0PA[ M(JJ&$?H<*SS&GR?A:Z*G?>!Z%&M^@3_G\NU+HK2CV9_\>:H^6U<[D8BOHJ''`Q-&!41]SY91CQ"+EWH&L75S5^F#FXV^01?:% MY(@F;CF2.+JSV_4ZC.Y%E/J>DQWJFT0J.;:\6B%L03>N_9#UN68X=KD3%Z9M% MQ?)S=,LD%R0T(%2:V/QXBC`._R&:*P4:%0%WNUMR3^3-FC(1P8=<&;7<,8E^: M*%W4>_I:"-\`5G>0C:R1(")<:_KN6"]?3H(DR\4FX=+:T*V/C%_NI'QJ^/+T1 M]:M$:GBNBKAA*(]#:1^`+_2O4!RYH353@-?+O9:/+[=0!9ZAC.(#NV0G>+CG% M!@VH)>50/@M?22?3=TP9F7AH:JH`X[H*>:*0W)(G_))1#Y[ M#N/E^/PB>`XY:G;$D)(3XFP=KI"0#AL^;_:":9#5,SK1@*$^E&4ZUK$`B3BYJ M;PV$J!8UB?C+_#N^/KXSZ>I<.K[4U*H;\N=B=VP#W%`F%V)RFM.+7;1:T&44! M#$,$\NIWU@S9E]H;?D`5RMS:5F9\8T7W'2QC26]K]8OGD0-P+X)9#C6VJ8M7? MT*M8ZPUSQYX?$R,7.?$5)0Y"$&WF[?UUK.Q:J0<,E*VA*C@\(D,`\F_Z=RI*> M0RQ7#M/<;L#DJ+P25DC7=$1XBRYG/BDBPK'&BHSU9*3!'E::T[;2)6(+`2'7: M!.-X#0>)S"UO;/P+/_PRWH.H_^>4N^D-A]GFA5*/'K$]P4YSZ0+R10KUG>CM% M)#'1V6<))8VF4B>O3A2_KG673TWX^4.,3?Z8:%^JR4DR6Q<@M`5&'PY/WA_[# M)'<'7JKW*KXR%XD.5`.!U^`)^3S-/\6/BT?ZXDQR;:*.?-[S^RE!4^E)$/0S- M.^EJ`?&^'J=7RNZ10M"]=\UZ=-@]DT,?Y_*>KY5Z@GV=Q5XD]X61`F#4B9!O1 M>-M9S"GWK(P_^GPDH:?,RUW;9PU7&WJIIF_PWBMJ`'Q^0^S^-=OQ*W3\UE"XB M(O\1P'Y-)_4@/^4$]Z-^>LI,Y/Y%N8C[5@3$=Q\RY.1^Z?`'0CHNB=VC[;R#W)RC\X-G4UWM29E',F MDXE^>H:MK:@Q)Y&51O/!FJ=<>Z6Q6=3+Z*J"/'G?/%P#!^;73?\@WHG?A4@%Q#T.IP?&OHQJK_AU= MB+&;^MX$]#*V&[^(>?2T/XIGORL8'86C#XS\17AT[_P/H8O(_S&?GS*_X287Y MLU0`Q?&P#;K']P1BJ=[?LR7[<5,B"!9I_OB1GJ=Z$:)AYL'5KHAIE14.O3 MV<(G\5GJO#%;$O!0;_TWY^'[P=194W#YK<7B_D<7PQ;3 M>:B^>/.]4OR^[T3>0!V"=8EZ=[[J?T61"D)QA5"]FD_U?"]$U8,%Q?/\DT=Z:LS?J\V?@*Q];M`6?6F(8Y@]#S$_WZ+7XN%X?,>+';?C$+)\=Y MV/!_8$,RX>SOBJ\CGC]1$[DR^:A!2?-WI/EB0??2OUC]IQ]6_\F'U/_S6/U>V M_\?G+T3YBU_D"7N*_PJ[+SZH^*':`>ES2#L?%JARWLMR,?[,V;7O;'@Y)_WPT M-?TSGT?_#[NF-]EEU^=?\+Z_W;]!]H/>2/J,)J?H'77+112UY(+D?%J#*N=%9>\#!6 M^).\5Y-3?4@EJ#E4Z*4ISN3[\U/A4)%"G<;;HY0(P:F:Y/Q20.NHAV?;,YF6! MGQ^(=;7\GZ/^O]S131*__01P.O5G9T.PO(,Q)GJ.:B&F[\OD#PQEX?#T'=8QM M/SSFXY/>=Z?\N/P+9GZ^7-YNE7]I'W\I*=X.-MBX<$MEHTFI(TJ+GH5O M%[]41;4X7&Y9%VHQH+=KK.3`U8IB@;6-[[CBX#N?>KNNU.39\Q>+BR5,GRPN( M?XW>0Q[__VW?(6WW>CX]U).6Z+5BU$B'55A#"72.KH?J8-[CT3RU-Z_8GS<)( M"5X6T@OVY(MG,.'9@<@G(Y$?DG@P[>FQ:0.KT&%:>I^=@$Z7>^A;!/0%(>&IW M[_LB(*VZ+4]50>_NMKI62;\)G7_:>> M:/7)_)8_Z22"^^GT_S_ZOD6'O;@ MQF&?8^Q'""F*V%V217ZF"8;[4&R'XK9N./2&'E#`5>ND%VQ+BSSN.C2]WWXD- M];1KI;L"KF-:I&A2$BF*TMM1B\2-C[E?^RU"-^[G?OV[#Q5TP.M68M&<(.1;$7>`(=.:8IL-JL@YT.,SBA`QFH\049Y!^N:$OS=$7U$ M@`2&PZ&:E((,NQE@OE749HU=;VC>1`UOO2 M2P1K002U>(K[(?76C)^()5AB*K45"*XH$%`+C!+QNYN;;7L4SJ&S/S3A5&=B[ MBWV1J=17)[5W/_[S@,3HC0Y%--H3M%X.G:6(],#8?%L9/$EYM^LX,\LLZX>"Y M1\CSJ=Z]#I+]<'KVVT#Y*RIGAT3_2ZV/74L:1*'6T?B\\4'@FH$W&#W'AOIY? M'9TB!<_1?\S60V/L0\+T.`;UUW0&-T=#*>%9@D MC)1'6BM2*1\_?7GW46EEV**(L42J::*I"I32V=US9*@Q^RD]@(=MU*!'3S6>N M.17T31(Y+U6ISBX.J)IP)7@/1V!9 M58@.-^`#=0O@MPV>=]?::+&>JN&>[*U'TS!Y1G ML;9I46KD14$K4KQ&2K5W$B%8OAII!RE^H7ZYG-1@@,+Q#@,@!P*;/>+-K*E0E MCY41Y2X0K6"G4_M^=4^\&.AD!9I[L2-X.K+[X:]G9A%I"`3.=>HQ3;G,\M)B" MCH;`+N%CVIC,6]`IB')]>TI*KQ(QWXD?U_B(S]6YL?R]]LJ]6/%?JS$CY7XL6(_5NK'XGZLS(M57T)MA MXI,!F7B<:O23]KK3=-Y/$'0Q2R)X%1PLYM5LSO#<,GAV4C36FVJ!^1D`@P*8A M1PBW7$+W<9YLF4) M!*:$<[\"69!X0"ST,&=A]_"AS_[_-627RRY4V%GTV8+#%>.N*KA2N#*X`SPN`6>`#QI@:<`3UO@&<"S%G@.\+P%7@"\>`X7P+]HX1_F,:5HX1])52E:^`?WKA0M_,-DOA0M_`O@7RC^HZG;>B^7PY?_H*D"E M3J%>6K#LYK"8V"(1:GJ@RW6HT88>CX?CAFF MD]AWB<5(+32UT,Q"LR:=W+[++49AH44#XZ<$H@KW65G"/!*$TL?'"GL$=47L* M2=@5^Y1'7B4REQS:(^H4VY],+,-=E#EV1>Q)T;0YULSI&!6MK(;\NU#WY]_?V MG9__6;[_X^SD_/33&;[#<<5PQ:(&1=I"$FX>-CA7OM^"RQ*V4IFHS29AET%A* MUHVZEM+%!5HLVD;&+M@C7&$$-X?EZ1/[MPWZA"/"]Q_LS9OU7YAT78&UHBP+< M<)=PJ$4O#4T5)?F%1Y_??XF`"KR1A[>Q$"%3^70KW[RB0]O@=_`(3=ZM#1XOP M+O"__$P0S,$!.KNS">Z=4M_"4]N.S<9-='<559`F-`EI:D_D%B,FMZM3QI:*6 M)>"A0&@>U:8W98WEP7!(01MK12C\=G?WEGER2II3W'C;HP>^.CDI/F!K/F%SS6)$U2]ET]N9W$S)^4>$?#T- M737*:33NPS?'G@ST(4>@!6R3ZD1'VFPL-2%I; Fri, 22 Sep 1995 05:24:59 +0300 Received: from carina.rz.Uni-Osnabrueck.DE (carina.rz.Uni-Osnabrueck.DE [131.173.128.25]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id CAA14218 for ; Fri, 22 Sep 1995 02:24:50 GMT Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id EAA17568; Fri, 22 Sep 1995 04:24:47 +0200 From: Thomas Radtke Received: (thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) id EAA16612; Fri, 22 Sep 1995 04:24:52 +0200 Message-Id: <199509220224.EAA16612@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: chip/fast problem revisited To: nisse@lysator.liu.se (Niels M|ller) Date: Fri, 22 Sep 1995 04:24:52 +0200 (DFT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199509212252.AAA09817@lysistrate.lysator.liu.se> from "Niels M|ller" at Sep 22, 95 00:52:52 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 455 > int gfxdata=3D0x1234; > int *gfx=3D(int *)AllocMem(sizeof(int),MEMF_CHIP); > *gfx=3Dgfxdata; > > That's prbably wrong, although I don't really understand what you want > it to do.=20 > Just tried, its ok: main() { int gfxdata=0x1234; int *gfx=(int *)AllocMem(sizeof(int),MEMF_CHIP); *gfx=gfxdata; printf("%d %d\n",gfxdata,*gfx); } output is: 4660 4660 ok, this one maybe was too simple :) Thomas From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 06:31:26 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90220-1>; Fri, 22 Sep 1995 06:30:25 +0300 Received: from edina.xenologics.com by funet.fi with SMTP (PP); Fri, 22 Sep 1995 06:29:56 +0300 Received: from darkness.gun.de (root@localhost) by edina.xenologics.com (8.6.8.1/8.6.6) with UUCP id FAA08864 for nic.funet.fi!amiga-gcc-port; Fri, 22 Sep 1995 05:30:52 +0200 X-ZC-VIA: 19950921220431W+1@darkness.gun.de From: DarkStar@darkness.gun.de (Carsten Meyer) Subject: bugs in ixemul and libnix Message-ID: Date: Thu, 21 Sep 95 21:59:02 CET Return-Receipt-To: DarkStar@darkness.gun.de (Carsten Meyer) Organization: CDC X-ZC-POST: Postfach 11 12;31596 Uchte X-Mailer: MicroDot 1.10 [UNREGISTRIERT] via Connectline-CLMSortin 2.22 X-Gateway: ZConnect DA darkness.gun.de [Connectline/AmigaOS] To: amiga-gcc-port@nic.funet.fi Hi There are some problems with ANSI/ISO function size_t strftime ( char *s, size_t smax, const char *fmt, const struct tm *tp ) Format ixemul.library libnix V41.3 V1.0 my opinion ----------------------------------------------------------------------- %a Thu Thu ok, but not local %A Thursday Thursday ok, but not local %b Sep Sep ok, but not local %B September September ok, but not local %c 09/21/95 21:34:27 09/21/95 libnix fails, both not local %d 21 21 ok %H 21 21 ok %I 09 09 ok %j 264 264 ok %m 09 09 ok %M 34 33 ok %p PM PM not ok because not local %S 27 44 ok %U 38 38 ok %w 4 4 ok %W 38 38 ok %x 09/21/95 09/21/95 21:33:44 libnix fails, both not local %X 21:34:27 21:33:44 ok %y 95 95 ok %Y 1995 1995 ok %Z ok??? % % % ok ----------------------------------------------------------------------- c u DarkStar -- MicroDot 1.8 From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 06:32:00 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90401-4>; Fri, 22 Sep 1995 06:30:25 +0300 Received: from edina.xenologics.com by funet.fi with SMTP (PP); Fri, 22 Sep 1995 06:30:05 +0300 Received: from darkness.gun.de (root@localhost) by edina.xenologics.com (8.6.8.1/8.6.6) with UUCP id FAA08901 for nic.funet.fi!amiga-gcc-port; Fri, 22 Sep 1995 05:31:07 +0200 X-ZC-VIA: 19950921220432W+1@darkness.gun.de From: DarkStar@darkness.gun.de (Carsten Meyer) Subject: ANSI function "raise()" is not in ixemul.library Message-ID: Date: Thu, 21 Sep 95 20:46:32 CET Return-Receipt-To: DarkStar@darkness.gun.de (Carsten Meyer) Organization: CDC X-ZC-POST: Postfach 11 12;31596 Uchte X-Mailer: MicroDot 1.10 [UNREGISTRIERT] via Connectline-CLMSortin 2.22 X-Gateway: ZConnect DA darkness.gun.de [Connectline/AmigaOS] To: amiga-gcc-port@nic.funet.fi Hi! I just found that the ANSI/ISO function int raise ( int sig); is not in the ixemul.library (V41.3). -------------------------------------------------------------------- 0> gcc signal.c -o signal /t/cc5176641.o: Undefined symbol _raise referenced from text segment -------------------------------------------------------------------- If using libnix (V1.0) everythink is ok! -------------------------------------------------------------------- 0> gcc -noixemul signal.c -o signal 0> -------------------------------------------------------------------- c u DarkStar From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 11:42:46 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <90235-2>; Fri, 22 Sep 1995 11:40:23 +0300 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA01692; Fri, 22 Sep 1995 09:40:04 +0100 Date: Fri, 22 Sep 1995 09:38:14 +0100 (BST) From: Peter Ivimey-Cook To: Carsten Meyer Cc: amiga-gcc-port@nic.funet.fi Subject: Re: bugs in ixemul and libnix In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 21 Sep 1995, Carsten Meyer wrote: > %y 95 95 ok > %Y 1995 1995 ok > %Z ok??? According to my HP UX machine, %Z should be the time zone name, e.g. "BST", "GMT", etc. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 13:45:22 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89989-4>; Fri, 22 Sep 1995 13:39:46 +0300 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 22 Sep 1995 12:36:06 +0200 (METDST) From: Rask Lambertsen To: Bert Winkelmann Cc: amiga-gcc-port@nic.funet.fi Subject: Re: __unwind_function() In-Reply-To: <50187467@bw01.bbrandes.berlinet.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 21 Sep 1995, Bert Winkelmann wrote: > > Have you contacted with Mike Stump? > > No, because the amiga-port isn't supported by GNU, and therefore it > isn't possible "adding full EH-support to this machine" by the > g++-developers (imho). But I will ask him for the concrete problems, > maybe he can help nevertheless. I thought the Amiga port was to be merged with the main distribution. I remember a message from Philippe BRAND about that around the time we saw the first 2.7.0 pre-release. Did I misunderstand something? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 13:47:57 1995 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by nic.funet.fi with SMTP id <90445-2>; Fri, 22 Sep 1995 13:47:19 +0300 Received: from freenet-a.fim.uni-erlangen.de (cu154@freenet-a.fim.uni-erlangen.de [131.188.192.11]) by uni-erlangen.de with SMTP id MAA16478 (8.6.12/7.4f-FAU); for ; Fri, 22 Sep 1995 12:46:30 +0200 Received: by fim.uni-erlangen.de; id AA12714 (4.1/7.3r-FAU); Fri, 22 Sep 95 12:46:03 +0200 Date: Fri, 22 Sep 95 12:46:03 +0200 Message-Id: <9509221046.AA12714@freenet-a.fim.uni-erlangen.de> From: cu154@fim.uni-erlangen.de (Federico Di Gregorio) To: amiga-gcc-port@lists.funet.fi Subject: Re: chip/fast problem revisited Reply-To: cu154@fim.uni-erlangen.de > >> >> gcc -Xlinker -chip -o test sprite1.c >> >> and >> >> gcc -Wl -chip -o test sprite1.c (as suggested by Lars Hecking) >> >> However, in all cases gcc complained that it didn't recognise "-chip". > > I don't have the docs at hand, but shouldnt -chip be a _linker_ option ? > Try -Wl,-chip. Maybe that works. > >> >> >> Walter Harms stated that most examples from the forementioned sources >> can be compiled without the use of chip or fast. However, leaving out >> the keyword chip didn't solve the problem. And I'm not sure how to >> implement the other suggestion by Walter using >> "allocmem(sizeof(),MEMF_CHIP)". > > That means, you copy the data to the pointer AllocMem returns, i.e. > > int gfxdata=0x1234; > int *gfx=(int *)AllocMem(sizeof(int),MEMF_CHIP); > *gfx=gfxdata; A better opne is: int SpriteData[] = {0x0345, ...}; int *ChipSpriteData = AllocMem(size_of_sprite, MEMF_CHIP); CopyMem((CPTR)SpriteData, (CPTR)ChipSpriteData, size_of_sprite); Federico > (be warned, I dont have tried the above code :) > > Thomas > > -- *-=@<:) Federico Di Gregorio cu154@fim.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 13:52:12 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90927-3>; Fri, 22 Sep 1995 13:51:21 +0300 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 22 Sep 1995 12:48:13 +0200 (METDST) From: Rask Lambertsen To: Federico Di Gregorio Cc: amiga-gcc-port@nic.funet.fi Subject: Re: chip/fast problem revisited In-Reply-To: <9509221046.AA12714@freenet-a.fim.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 22 Sep 1995, Federico Di Gregorio wrote: > > That means, you copy the data to the pointer AllocMem returns, i.e. > > > > int gfxdata=0x1234; > > int *gfx=(int *)AllocMem(sizeof(int),MEMF_CHIP); > > *gfx=gfxdata; > A better opne is: > > int SpriteData[] = {0x0345, ...}; > int *ChipSpriteData = AllocMem(size_of_sprite, MEMF_CHIP); > CopyMem((CPTR)SpriteData, (CPTR)ChipSpriteData, size_of_sprite); ^^^^ ^^^^ APTR APTR According to the prototypes, the pointers are APTR, not CPTR. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 13:54:02 1995 Received: from DBSTU1.RZ.TU-BS.DE ([134.169.1.1]) by nic.funet.fi with SMTP id <90920-4>; Fri, 22 Sep 1995 13:53:37 +0300 Received: from rzab0.rz.tu-bs.de by DBSTU1.RZ.TU-BS.DE (IBM VM SMTP V2R2) with TCP; Fri, 22 Sep 95 12:54:12 MEZ Received: by rzab0.rz.tu-bs.de (1.37.109.15/15.6) id AA075627186; Fri, 22 Sep 1995 12:53:06 +0200 From: Sven Heithecker Subject: Re: Many questions to gcc 2.7.0 To: amiga-gcc-port@nic.funet.fi (Sven Heithecker) Date: Fri, 22 Sep 1995 12:53:05 +0100 (MESZ) X-Mailer: ELM [version 2.4 PL11] Content-Type: text Content-Length: 2750 Message-Id: <95Sep22.135337+0300_eet_dst.90920-4+102@nic.funet.fi> Sven Heithecker writes: > > So far I installed the packages gcc270-base, gcc270-c020, gcc270-inclib. > > My system is a A2000 with GForce040/33/16Mb. > > Hope you installed gcc270-readme :) Ooops - of course !!! > > 2. gnu:mc68020-cbm-amigados/include/assert.h ? > > This directory seems a bit out of place for me there .... > >Standard place when gcc installation. See note below ! > > versions of assert.h necessary or can I replace one and delete the other ?> > 3. The following stuff can be found relative to> gnu:lib/gcc-lib/mc68020-cbm-amigados/2.7.0/... :> > > > i. Stuff in include/... > > - Some of them I can find in gnu:include/... in a slightly different > > version. > > I wonder if I need stuff like va_alpha.h - I don't want develop > > things for DEC-Alpa or recompile stuff from DEC-Alpa !! > > Wich stuff is really necessary, can be copied to gnu:include, or > > can be deleted ? > > Please keep all files. They're really not big. It's * not * because the files are big - it's just because I hate it to have files on my harddisk where I don't know what thery're good for ! > > 4. There is many in gnu:include/ .. which seem to be used only for compiling > > Un*x programs ( arpa | machine | net | netinet | protocols | readline | > > rpc ). Am I right and can those stuff be deleted ? > > Are you really so tight in HD space ? See above . > > 1. Make. It crashes everytime. One time, it wrote "Bus-Error" and "Illegal > > Instruction" to CLI just before / while it gave a brunch of Enforcer-Hits and > > my machine was shooted down. Other times, it simply gave Enforcer-Hits > > without those CLI-msgs (without crashing the machine immediately). But when > > I wanted to keep on working ramlib crashed ... > > Set stack size to 50.000 * Blush * good idea - did it - works fine :-) ! > > 1. I got the following message compiling inline/muimaster.h: > > "Fixed or forbidden register was spilled. This may be due a compiler-bug > > or to impossible asm statements or clauses." > > I checked inline/muimaster.h but didn't found something improper ... > > Too many registers were used by one of functions. Solution is to avoid inlining > this function. One other user has already posted a workaround for this. > > > 2. During linking I got: > > "ld: Reloc is base relative. Specify -databss-together in mensa_gui.o" > > I checked specs for -databss-together and found it. Specifying directly > > in the commandline didn't help, nor did -O3. > > You didn't compile mensa_gui.c with -resident flag. I did !!! But anyway - I recompiled everything with -O3 and everything went well ! From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 14:03:06 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89977-2>; Fri, 22 Sep 1995 14:02:41 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id MAA27760; Fri, 22 Sep 1995 12:00:45 +0100 From: Lars Hecking Message-Id: <199509221104.MAA02589@mostar.nmrc.ucc.ie> Subject: Re: __unwind_function() To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Fri, 22 Sep 1995 12:04:17 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Rask Lambertsen" at Sep 22, 95 12:36:06 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 424 > I thought the Amiga port was to be merged with the main distribution. > I remember a message from Philippe BRAND about that around the time we > saw the first 2.7.0 pre-release. Did I misunderstand something? The original statement of merging amiga-diffs back into the main source tree stems back from the days when Markus Wild was still maintaing the compiler (before 1993), but AFAIR, no efforts were ever made. From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 14:48:04 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90788-3>; Fri, 22 Sep 1995 14:46:40 +0300 Received: from gryzmak.pdi.lodz.pl (root@gryzmak.pdi.lodz.pl [194.92.208.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id LAA00634 for ; Fri, 22 Sep 1995 11:46:29 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: from plukwa (robert@plukwa.pdi.lodz.pl [194.92.208.7]) by gryzmak.pdi.lodz.pl (8.6.10/1.36) with SMTP id NAA22230 for ; Fri, 22 Sep 1995 13:36:15 +0200 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 22 Sep 95 13:32:11 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <21567bd3.u8t20e.29b99-robert@plukwa.pdi.lodz.pl> Subject: geteuid() and getpwuid() .... Reply-To: robert@lodz.pdi.net Content-Length: 640 To: amiga-gcc-port@nic.funet.fi Date: Fri, 22 Sep 95 13:32:11 Hi all! Sorry to bother with some minor things. Where and how are implemented those two function mentioned in the topic? Are they in Ixemul or somewhere in GCC libs? Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 14:52:55 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90025-1>; Fri, 22 Sep 1995 14:52:28 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA08642; Fri, 22 Sep 1995 13:53:43 +0200 Date: Fri, 22 Sep 1995 13:53:42 +0200 (MET DST) From: Kamil Iskra Subject: Re: About .. in root, stderr, DosWedge, Ctrl-C, etc. To: Rask Lambertsen cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 20 Sep 1995, Rask Lambertsen wrote: > ixprefs has as option "Open console if no stderr", try turning it off. > Then unless you shell sets up pr_CES (not many does), stderr will use > pr_COS, which can be redirected. I think you are wrong - this was changed in 41.3. Now "pr_COS" is NEVER used for "stderr", and "Open console if no stderr" in ixprefs seems to be obsolete (actually, is it still there?). When there is no "pr_CES", IXEmul does open("*", 2). As a side effect, this causes Enforcer hit with KingCON, but it seems this is KingCON's fault. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 15:03:30 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90177-2>; Fri, 22 Sep 1995 15:02:12 +0300 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 22 Sep 1995 13:58:48 +0200 (METDST) From: Rask Lambertsen To: Kamil Iskra Cc: amiga-gcc-port@nic.funet.fi Subject: Re: About .. in root, stderr, DosWedge, Ctrl-C, etc. In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 22 Sep 1995, Kamil Iskra wrote: > On Wed, 20 Sep 1995, Rask Lambertsen wrote: > > > ixprefs has as option "Open console if no stderr", try turning it off. > > Then unless you shell sets up pr_CES (not many does), stderr will use > > pr_COS, which can be redirected. > > I think you are wrong - this was changed in 41.3. Now "pr_COS" is NEVER > used for "stderr", and "Open console if no stderr" in ixprefs seems to be > obsolete (actually, is it still there?). When there is no "pr_CES", IXEmul > does open("*", 2). Oh no, how can we then run GNU utilities in the background and close console window? Btw, I sent some diffs to make it use "CONSOLE:" instead of "*". Where they used in any way? > As a side effect, this causes Enforcer hit with > KingCON, but it seems this is KingCON's fault. That should be easy to figure out. Try opening "*" with AmigaDOS Open() instead of UNIX open() (you'll need to use startup code that doesn't try to open "*"). If Open("*", MODE_whatever) give an Enforcer hit, then KingCON is faulty, otherwise *maybe* it is ixemul's fault. "Maybe" because the open() function in ixemul does lots of other things than just calling Open(). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 15:42:12 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90437-3>; Fri, 22 Sep 1995 15:40:39 +0300 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id OAA09348; Fri, 22 Sep 1995 14:42:11 +0200 Date: Fri, 22 Sep 1995 14:42:11 +0200 (MET DST) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: About .. in root, stderr, DosWedge, Ctrl-C, etc. To: Rask Lambertsen cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Fri, 22 Sep 1995, Rask Lambertsen wrote: > On Fri, 22 Sep 1995, Kamil Iskra wrote: > > As a side effect, this causes Enforcer hit with > > KingCON, but it seems this is KingCON's fault. > > That should be easy to figure out. Try opening "*" with AmigaDOS Open() > instead of UNIX open() (you'll need to use startup code that doesn't try > to open "*"). If Open("*", MODE_whatever) give an Enforcer hit, then > KingCON is faulty, otherwise *maybe* it is ixemul's fault. "Maybe" because > the open() function in ixemul does lots of other things than just calling > Open(). You are talking to a man who has spent a week figuring out what's wrong :-). The problem is that UNIX open() does not use dos.library Open() - as we all know, IXEmul comunicates with filesystems using packets directly. IXEmul makes also other, "rare" thing: reply port of its packets is not set to "pr_MsgPort" of "struct Process", but to some other port from "struct user", created using "CreatePort()". KingCON seems to have problems with such packets. For some reason it produces Enforcer hit when "ACTION_FINDINPUT" is sent to it and its "dp_Port" is not set to "pr_MsgPort" of process sending the packet. That's exactly what IXEmul does when open("*", 2) is called, in file "library/__open.c", in function ___open_func(), if I remember correcly. Below is a simple source that causes this bug to be generated. It doesn't matter if it is compiled with -noixemul or not, with GCC or some other compiler. ___beg___ #include #include #include #include /*#define KINGCON_COMPATIBLE*/ int main(void) { struct MsgPort *handler=(struct MsgPort*)(((struct Process *)FindTask(0))-> pr_ConsoleTask); struct FileHandle *fh; struct StandardPacket *sp; struct MsgPort *port; if (!(fh=AllocDosObjectTags(DOS_FILEHANDLE, ADO_FH_Mode, MODE_OLDFILE, TAG_DONE))) return 10; if (!(sp=AllocMem(sizeof(struct StandardPacket), 0))) return 10; #ifndef KINGCON_COMPATIBLE if (!(port=CreateMsgPort())) return 10; #else port=&((struct Process*)FindTask(0))->pr_MsgPort; #endif sp->sp_Msg.mn_Node.ln_Name=(char*)&sp->sp_Pkt; sp->sp_Pkt.dp_Link=&sp->sp_Msg; sp->sp_Pkt.dp_Res1=sp->sp_Pkt.dp_Res2=sp->sp_Msg.mn_Node.ln_Type=0; sp->sp_Pkt.dp_Port=port; sp->sp_Pkt.dp_Type=ACTION_FINDINPUT; sp->sp_Pkt.dp_Arg1=MKBADDR(fh); sp->sp_Pkt.dp_Arg2=0; sp->sp_Pkt.dp_Arg3=MKBADDR("\1*"); PutMsg(handler, (struct Message*)sp); WaitPort(port); GetMsg(port); Printf("Res1: %ld, Res2: %ld\n", sp->sp_Pkt.dp_Res1, sp->sp_Pkt.dp_Res2); /* Note: fh should be freed, too */ #ifndef KINGCON_COMPATIBLE DeleteMsgPort(port); #endif FreeMem(sp, sizeof(struct StandardPacket)); } ___end___ I've sent two e-mails to KingCON author, but got no reply so far :-(. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 15:50:12 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <89988-3>; Fri, 22 Sep 1995 15:48:36 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 22 Sep 95 14:44:20 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <21568cb4.u8t20e.5c83f-robert@plukwa.pdi.lodz.pl> Subject: Re: geteuid() and getpwuid() .... In-Reply-To: <199509221203.NAA02786@mostar.nmrc.ucc.ie> (from Lars Hecking ) (at Fri, 22 Sep 1995 13:03:21 +0100 (BST)) Reply-To: robert@pdi.lodz.pl Content-Length: 1989 To: amiga-gcc-port@nic.funet.fi Date: Fri, 22 Sep 95 14:44:20 On Sep 22 Lars Hecking wrote: > > > Hi all! > > Sorry to bother with some minor things. > > Someone has to work on the small stuff ;)) > > > Where and how are implemented those two function mentioned in the topic? > > Are they in Ixemul or somewhere in GCC libs? > > Basically, libc.a is a collection of stubs for ixemul.library. > From the ixemul sources (v41.1): > > library/smallfuncs.c: > int geteuid () { return 0; } > > library/getcrap.c > #include > struct passwd *getpwuid (uid_t uid) > { > static struct passwd pw = { "amiga", /* pw_name */ > "*", /* pw_passwd */ > 0, /* pw_uid */ > 0, /* pw_gid */ > 0, /* pw_change */ > 0, /* pw_class */ > "amiga user", /* pw_gecos */ > "sys:", /* pw_dir */ > "c:execute", /* pw_shell */ > 0}; /* pw_expire */ > > /* see getpwnam() */ > pw.pwuid = uid; > return &pw; > } Am i correct that this is fixed to use amiga everytime or it is just my eyes? This looks realy bad! Well it's good only as a fallback =o) > > Some of this stuff (esp. struct passwd) might actually change due to > ixemul source cleanup, but I believe Fred Fish and Hans Verkuil would > know more in this case. Fred, Hans can You provide me with info on stage in which the cleanup is now or when will it be done? (Maybe i could be of any help?) > > Hope this helps. Yep! A bit =o) > > Lars > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 15:57:37 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90246-3>; Fri, 22 Sep 1995 15:56:28 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 22 Sep 95 14:54:14 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <21568f11.u8t20e.81abd-robert@plukwa.pdi.lodz.pl> Subject: Enviroment Vars and library Reply-To: robert@pdi.lodz.pl Content-Length: 754 To: amiga-gcc-port@nic.funet.fi Date: Fri, 22 Sep 95 14:54:14 Hi again! In my last posting i forgot to ask one thing: Is it legal and safe to obtain values of enviroment variables from within library? Robert Ps I'll try to keep my fingers off the keyboard for a while to not to overload Your mailbox with crap posting but i can't promise that ;o))) +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 19:04:28 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90360-3>; Fri, 22 Sep 1995 19:02:39 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 22 Sep 95 18:00:21 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2156bab3.u8t20e.17be1-robert@plukwa.pdi.lodz.pl> Subject: sh-utils binary size... Reply-To: robert@pdi.lodz.pl Content-Length: 987 To: amiga-gcc-port@nic.funet.fi Date: Fri, 22 Sep 95 18:00:21 Hi all! It's me again. I've just recompiled sh-utils 1.12 (sources were taken from FreshFish CD-ROM mounted somewhere in Germany).I've used -O2 -m68030 -m68881 options to GCC. They compiled just fine. What suprises me is that the binaries are almost twice of the size of those from gcc 2.6.3 utils distrib. Now were those from gcc 2.6.3 compiled with different opts ? or are they from different sh-utils archive (archie reported sh-utils and shellutils during search) Can some kind soul sched some light on me? Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 19:16:44 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90387-2>; Fri, 22 Sep 1995 19:16:12 +0300 Received: by colombo.telesys-innov.fr; Fri, 22 Sep 1995 18:09:55 +0100 From: Philippe BRAND Message-Id: <199509221709.SAA19643@colombo.telesys-innov.fr> Subject: Re: sh-utils binary size... To: robert@pdi.lodz.pl Date: Fri, 22 Sep 1995 18:09:54 +0100 (BST) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <2156bab3.u8t20e.17be1-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Sep 22, 95 06:00:21 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 263 Robert Ramiega writes: > Can some kind soul sched some light on me? Link with -s -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 19:28:06 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90398-1>; Fri, 22 Sep 1995 19:27:16 +0300 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 22 Sep 95 18:20:38 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <2156bf71.u8t20e.ce4a9-robert@plukwa.pdi.lodz.pl> Subject: Re: sh-utils binary size... In-Reply-To: <199509221709.SAA19643@colombo.telesys-innov.fr> (from Philippe BRAND ) (at Fri, 22 Sep 1995 18:09:54 +0100 (BST)) Reply-To: robert@pdi.lodz.pl Content-Length: 891 To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@nic.funet.fi Date: Fri, 22 Sep 95 18:20:38 On Sep 22 Philippe BRAND wrote: > Robert Ramiega writes: > > > Can some kind soul sched some light on me? > > Link with -s Damn.... Thanks!!!! =o)))) Is there any panishment for asking such stupid questions on this list? > > -- > Philippe BRAND > phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB > AmigaDOS GNU Project, AmigOS Net/WWW coordinator. > http://www.telesys-innov.fr/about/PhB.html > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 19:52:22 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90287-4>; Fri, 22 Sep 1995 19:51:37 +0300 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id RAA05421; Fri, 22 Sep 1995 17:45:00 +0100 From: Lars Hecking Message-Id: <199509221648.RAA03364@mostar.nmrc.ucc.ie> Subject: Re: sh-utils binary size... To: robert@pdi.lodz.pl Date: Fri, 22 Sep 1995 17:48:33 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <2156bf71.u8t20e.ce4a9-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Sep 22, 95 06:20:38 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 363 > > Link with -s > Damn.... Thanks!!!! =o)))) > Is there any panishment for asking such stupid questions on this list? ^ punishment All mailing list subscribers will u/l the complete FSF source tree to plukwa. And you don't want to know the punishment for misspelling punishment .... [Do I need a smiley here? I say not] From amiga-gcc-port-owner@nic.funet.fi Fri Sep 22 22:29:42 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <90471-4>; Fri, 22 Sep 1995 22:28:22 +0300 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id VAA28658 (8.6.10/2.4); Fri, 22 Sep 1995 21:28:41 +0200 Date: Fri, 22 Sep 1995 21:28:41 +0200 From: Olaf Seibert Message-Id: <199509221928.VAA28658@septimius.mbfys.kun.nl> To: kiskra@ernie.icslab.agh.edu.pl Subject: Re: About .. in root, stderr, DosWedge, Ctrl-C, etc. Cc: amiga-gcc-port@nic.funet.fi Kamil Iskra wrote: > IXEmul makes also other, "rare" thing: reply port of its packets is not > set to "pr_MsgPort" of "struct Process", but to some other port from > "struct user", created using "CreatePort()". > > KingCON seems to have problems with such packets. For some reason it > produces Enforcer hit when "ACTION_FINDINPUT" is sent to it and its > "dp_Port" is not set to "pr_MsgPort" of process sending the packet. That's > exactly what IXEmul does when open("*", 2) is called, in file > "library/__open.c", in function ___open_func(), if I remember correcly. I suppose KingCON is trying to find out information about the Process that sends the packet, or something like that. KingCON needs rather much of this kind of stuff: which task to signal on ^CDEF, current directory for file name completion (maybe even more). What KingCON probably *should* do, is to use mp_SigTask in the supplied dp_Port as the sending task, instead of dp_Port (minus its offset in the Process structure). Have you contacted the author of KingCON? I have a bug report for him as well (try scrolling back in a window that is narrower than the screen. It will position the text in it as if the window was as wide as the screen, but of course you see only the leftmost part of long lines. This is quite annoying on my extra-wide autoscrolling workbench). -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Sat Sep 23 17:23:54 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <89992-2>; Sat, 23 Sep 1995 17:21:01 +0300 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id RAA12115 at Sat, 23 Sep 1995 17:18:24 +0300 Received: by softlab.ece.ntua.gr with UUCP id PAA13542 at Sat, 23 Sep 1995 15:31:03 +0300 Received: by kriton.UUCP (V1.17-beta/Amiga) id <08cf@kriton.UUCP>; Sat, 23 Sep 95 15:24:26 EET Date: Sat, 23 Sep 95 15:24:26 EET Message-Id: <9509231324.08cf@kriton.UUCP> Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 1153 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: *rand48() functions The only random number generator that comes with libnix is rand(), which, at least on unix, is not supposed to be very good. Thus, I thought I'd have a go at implementing one of the better alternatives, namely lrand48() and friends, using gcc's long long ints to do arithmetic with more than 32 bits. I have written the following functions that duplicate the functionality of the *rand48 functions as described in the SAS/C manual: lrand48, nrand48, mrand48, jrand48, drand48, erand48, srand48, seed48, and lcong48. The functions appear to work, producing what to me appears to be a uniform distribition with no periodic repetition in the lower order bits. Not being an expert on such matters, however, I would appreciate it if someone could test the quality of the random numbers generated by these functions before I send my code to Mathhias for inclusion in libnix. Please reply by mail if you are interested. Thanks, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If they call us mutations, what must *they* be like?" ----- From amiga-gcc-port-owner@nic.funet.fi Sat Sep 23 20:03:45 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90369-2>; Sat, 23 Sep 1995 20:02:11 +0300 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0swXzP-000R0AC; Sat, 23 Sep 95 19:03 MET DST Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0swQ0A-000FzPC; Sat, 23 Sep 95 10:32 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <09nm@wyst.hobby.nl>; Fri, 22 Sep 95 23:42:05 CET Message-Id: <9509222242.09nm@wyst.hobby.nl> Date: Fri, 22 Sep 1995 23:42:03 +0000 (CET) In-Reply-To: from "Kamil Iskra" at Sep 22, 95 01:53:42 pm Content-Type: text Content-Length: 1311 From: hans@wyst.hobby.nl (Hans Verkuil) To: kiskra@ernie.icslab.agh.edu.pl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: About .. in root, stderr, DosWedge, Ctrl-C, etc. According to Kamil Iskra: > > ixprefs has as option "Open console if no stderr", try turning it off. > > Then unless you shell sets up pr_CES (not many does), stderr will use > > pr_COS, which can be redirected. > > I think you are wrong - this was changed in 41.3. Now "pr_COS" is NEVER > used for "stderr", and "Open console if no stderr" in ixprefs seems to be > obsolete (actually, is it still there?). When there is no "pr_CES", IXEmul > does open("*", 2). As a side effect, this causes Enforcer hit with > KingCON, but it seems this is KingCON's fault. This option was indeed made obsolete in 41.3. I have never had any problems with this. (I'm using KingCon 1.2, by the way. I tried 1.3 a long time ago, but even then ixemul and KingCon 1.3 didn't like one another). BUT, if it is really necessary to return to the old behavior, please let me know. However, the old behavior means setting stderr to the same filehandle as stdout, so the error messages are mixed up with the regular output. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat Sep 23 20:03:58 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90922-1>; Sat, 23 Sep 1995 20:02:15 +0300 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0swY0D-000R0AC; Sat, 23 Sep 95 19:04 MET DST Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0swQ06-000G32C; Sat, 23 Sep 95 10:31 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <09ms@wyst.hobby.nl>; Fri, 22 Sep 95 22:52:30 CET Message-Id: <9509222152.09ms@wyst.hobby.nl> Date: Fri, 22 Sep 1995 22:52:28 +0000 (CET) In-Reply-To: <9509040732.AA15943@hpcl.cti.gr> from "Kriton Kyrimis" at Sep 4, 95 10:32:58 am Content-Type: text Content-Length: 1439 From: hans@wyst.hobby.nl (Hans Verkuil) To: kyrimis@theseas.softlab.ece.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Problem with ixemul 41.3 and DosWedge Kriton, > Is there a reason for not using DOS packets rather than the equivalent DOS > functions? It somehow doesn't feel right not to be able to use any of those > commodities that patch the DOS functions. I asked Markus Wild about this, and this is his reply: > Most of it was motivated by the "as-close-as-possible" emulation of the > Unix system calls. Using packets to do path-lookups allowed me to do unix > filename semantics as good as possible (and I think, clearly better than some > of the original DOS calls, the nearer you get to symlinks...:-)). 1.3 > compatibility was a side-effect of this decision, it wasn't the driving goal > behind it (nice side-effect though, you could have symlinks under 1.3;-)). > > Most of the I/O related functions are not feasible without the packet interface > if you want to keep the semi-async functionality I implemented. Almost all the > rest falls into the "path-parser" case (like mkdir, unlink, rename, etc), so > I don't really see off-hand a bunch of functions that would be implementable > straight-forward using even dos3 calls, you'd definitely loose functionality. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat Sep 23 20:04:44 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90577-1>; Sat, 23 Sep 1995 20:03:41 +0300 Received: from hgatenl.hobby.nl by funet.fi with SMTP (PP); Sat, 23 Sep 1995 20:03:25 +0300 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0swY0w-000R0AC; Sat, 23 Sep 95 19:05 MET DST Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0swQ0C-000G37C; Sat, 23 Sep 95 10:32 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <09o6@wyst.hobby.nl>; Sat, 23 Sep 95 00:12:46 CET Message-Id: <9509222312.09o6@wyst.hobby.nl> Date: Sat, 23 Sep 1995 00:12:44 +0000 (CET) In-Reply-To: <21568f11.u8t20e.81abd-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Sep 22, 95 02:54:14 pm Content-Type: text Content-Length: 744 From: hans@wyst.hobby.nl (Hans Verkuil) To: robert@pdi.lodz.pl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Enviroment Vars and library According to Robert Ramiega: > > Hi again! > In my last posting i forgot to ask one thing: > Is it legal and safe to obtain values of enviroment variables from within > library? Depends. In most cases it is safe, but if you try to call it when you're halfway launching another process (e.g. in vfork or something similar) you'd better know what you're doing. This is also true in the signal handling and other low level functions. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat Sep 23 20:06:03 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90496-2>; Sat, 23 Sep 1995 20:04:42 +0300 Received: from hgatenl.hobby.nl by funet.fi with SMTP (PP); Sat, 23 Sep 1995 20:04:37 +0300 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0swY23-000R0AC; Sat, 23 Sep 95 19:06 MET DST Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0swQ07-000G33C; Sat, 23 Sep 95 10:31 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <09mx@wyst.hobby.nl>; Fri, 22 Sep 95 23:00:32 CET Message-Id: <9509222200.09mx@wyst.hobby.nl> Date: Fri, 22 Sep 1995 23:00:30 +0000 (CET) In-Reply-To: from "joop van de wege" at Sep 7, 95 12:21:53 pm Content-Type: text Content-Length: 1159 From: hans@wyst.hobby.nl (Hans Verkuil) To: Joop.vandeWege@MEDEW.ENTO.WAU.NL Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Ixemul.library and 060 BUG FIX ! According to joop van de wege: > Should work too, took me sometime to see what did the trick but the frestore > doesn't update the stackpointer. Saves a test for 060 but to be honest, I > like my version better :) > I think it is more clear, but either Hans or Fred have to decide which > version to integrate into ixemul.library. Just to make my position clear: Fred Fish merges all the patches. The only 'official' activity I'm responsible for is the cleanup once Fred has merged everything. This will entail compiling the library using -Wall, and fixing the warnings, reorganizing the ixconfig options, adding ixprefs to the library instead of ixconfig and going over every source to see if there is any dead code or wrong comments or '#if 0' code that is no longer relevant, etc. I also want to try out an idea to improve compilation speed. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat Sep 23 20:06:18 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90927-3>; Sat, 23 Sep 1995 20:05:42 +0300 Received: from hgatenl.hobby.nl by funet.fi with SMTP (PP); Sat, 23 Sep 1995 20:05:31 +0300 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0swY2y-000R0AC; Sat, 23 Sep 95 19:07 MET DST Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0swQ0C-000G36C; Sat, 23 Sep 95 10:32 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <09o1@wyst.hobby.nl>; Sat, 23 Sep 95 00:08:55 CET Message-Id: <9509222308.09o1@wyst.hobby.nl> Date: Sat, 23 Sep 1995 00:08:53 +0000 (CET) In-Reply-To: <21568cb4.u8t20e.5c83f-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Sep 22, 95 02:44:20 pm Content-Type: text Content-Length: 1792 From: hans@wyst.hobby.nl (Hans Verkuil) To: robert@pdi.lodz.pl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: geteuid() and getpwuid() .... Hi Robert, > > Some of this stuff (esp. struct passwd) might actually change due to > > ixemul source cleanup, but I believe Fred Fish and Hans Verkuil would > > know more in this case. > Fred, Hans can You provide me with info on stage in which the cleanup is > now or when will it be done? (Maybe i could be of any help?) The struct passwd shouldn't change at all, it's the BSD format. I'm still waiting for Fred to finish merging two ixemul versions. After that I'll take over for the cleanup. And after that Jeff Shepherd will add AmiTCP support to the library. But it will take several weeks if not longer before that's all done. As to help: more work is needed not so much on the library as well as on the gcc compiler and linker. The support for Amiga hunks needs to be added to the new binutils set so that the linker from that set can be used. I understand that it's 99% finished so this shouldn't be much work. I may be wrong, of course :-) Also it would be nice to have support in gcc for the chip keyword. Some code is written, but it is not used at the moment. If you prefer to do work on the library you could test the profiling support. As far as I can see it should work correctly, but it needs to be tested, and I have no time for that. The ixtrace utility needs to be updated (the new functions are not traced at the moment, or at least not properly). And of course, if you like a challenge, implement the ptrace() function so that gdb can be ported. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat Sep 23 20:08:22 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90405-3>; Sat, 23 Sep 1995 20:08:01 +0300 Received: from hgatenl.hobby.nl by funet.fi with SMTP (PP); Sat, 23 Sep 1995 20:07:52 +0300 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0swY07-000R0BC; Sat, 23 Sep 95 19:04 MET DST Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0swQ0B-000FzPC; Sat, 23 Sep 95 10:32 MET DST Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <09nw@wyst.hobby.nl>; Fri, 22 Sep 95 23:52:52 CET Message-Id: <9509222252.09nw@wyst.hobby.nl> Date: Fri, 22 Sep 1995 23:52:50 +0000 (CET) In-Reply-To: <21567bd3.u8t20e.29b99-robert@plukwa.pdi.lodz.pl> from "Robert Ramiega" at Sep 22, 95 01:32:11 pm Content-Type: text Content-Length: 898 From: hans@wyst.hobby.nl (Hans Verkuil) To: robert@lodz.pdi.net Cc: amiga-gcc-port@nic.funet.fi Subject: Re: geteuid() and getpwuid() .... According to Robert Ramiega: > > Hi all! > Sorry to bother with some minor things. > Where and how are implemented those two function mentioned in the topic? > Are they in Ixemul or somewhere in GCC libs? They are in ixemul. geteuid() is a dummy function that always returns 0. getpwuid() used to be a dummy function that returned a passwd struct that was always the same, but in my copy (which will also go to Fred Fish) it is a bit more intelligent and uses the environment settings HOME and USER to fill in the pw_dir and pw_name fields of the struct. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat Sep 23 22:12:05 1995 Received: from haegar.allcon.net ([194.49.86.2]) by nic.funet.fi with SMTP id <90709-3>; Sat, 23 Sep 1995 22:10:56 +0300 Received: from honi.allcon.net by haegar.allcon.net with smtp (Smail3.1.28.1 #7) id m0swZy1-000aP3C; Sat, 23 Sep 95 21:10 MET DST Received: by umd.allcon.com (CrossPoint v3.02); 23 Sep 1995 20:58:26 +0200 Date: 23 Sep 1995 12:18:00 +0200 From: mark@umd.allcon.com (Mark Deskowski) To: amiga-gcc-port@nic.funet.fi Message-ID: <5uO3Il7vyQB@umd.allcon.com> Subject: unsubscribe X-Mailer: XP v3.02 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit unsubscribe mark@umd.allcon.com From amiga-gcc-port-owner@nic.funet.fi Sat Sep 23 22:48:02 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90861-1>; Sat, 23 Sep 1995 22:47:23 +0300 Received: by amigalib.com (Smail3.1.28.1 #64) id m0swaZu-0004nYC; Sat, 23 Sep 95 12:49 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: geteuid() and getpwuid() .... To: hans@wyst.hobby.nl (Hans Verkuil) Date: Sat, 23 Sep 1995 12:49:38 -0700 (MST) Cc: robert@pdi.lodz.pl, amiga-gcc-port@nic.funet.fi In-Reply-To: <9509222308.09o1@wyst.hobby.nl> from "Hans Verkuil" at Sep 23, 95 00:08:53 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 762 > The support for Amiga hunks needs to be added > to the new binutils set so that the linker from that set can be used. I > understand that it's 99% finished so this shouldn't be much work. I may be > wrong, of course :-) Everything works with the binutils linker except that it does not understand "linker flavors" as implemented in the non-bfd linker, and it also does not know how to split reloc hunks when they exceed the AmigaDOS 64k limit. This second problem was found when linking GNU octave, which is a huge executable. > And of course, if you like a challenge, implement the ptrace() function so > that gdb can be ported. Leonard has a start on ptrace() in the code I'm merging. I'm going to try get that code into the next ixemul release. -Fred From amiga-gcc-port-owner@nic.funet.fi Sun Sep 24 18:54:47 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90622-3>; Sun, 24 Sep 1995 18:51:45 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id SAA22529 at Sun, 24 Sep 1995 18:49:01 +0200 Received: by softlab.ece.ntua.gr with UUCP id NAA02207 at Sun, 24 Sep 1995 13:31:26 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <08di@kriton.UUCP>; Sun, 24 Sep 95 12:57:52 EET Date: Sun, 24 Sep 95 12:57:52 EET Message-Id: <9509241057.08di@kriton.UUCP> Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 657 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: geteuid() and getpwuid() .... (fwd) On Sep 23, Hans Verkuil wrote: > to the new binutils set so that the linker from that set can be used. I > understand that it's 99% finished so this shouldn't be much work. I may be > wrong, of course :-) This sounds like the infamous 90%-10% rule: It takes 10% of the time to do 90% of the work, and 90% of the time to do the remaining 10%. (All too true when talking about writing and debugging programs. :-( ) -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "You don't play poker with an empath. That's all. You just don't." ----- From amiga-gcc-port-owner@nic.funet.fi Sun Sep 24 20:35:08 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90124-4>; Sun, 24 Sep 1995 20:34:31 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0swvvi-0004nYC; Sun, 24 Sep 95 11:37 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: geteuid() and getpwuid() .... (fwd) To: kyrimis@softlab.ece.ntua.gr Date: Sun, 24 Sep 1995 11:37:33 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: <9509241057.08di@kriton.UUCP> from "Kriton Kyrimis" at Sep 24, 95 12:57:52 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1115 > > to the new binutils set so that the linker from that set can be used. I > > understand that it's 99% finished so this shouldn't be much work. I may be > > wrong, of course :-) > > This sounds like the infamous 90%-10% rule: It takes 10% of the time to do 90% > of the work, and 90% of the time to do the remaining 10%. (All too true when > talking about writing and debugging programs. :-( ) I don't think this is actually the case here (though it is a cute and all too common rule). At one point in the past I actually installed the new linker as my default linker and tried doing a multistage build of my entire gnu tree. The only things that failed were a few things where "linker flavors" were used and octave, which has more than 64k relocs in a single hunk. Implementing flavors is probably no more than a day or so worth of work for someone, once they have figured out how the bfd linker searches for files and libraries. Splitting reloc sections should also not be much work. I made the original "flavor" changes in the old linker in well under a day, and similarly for the reloc changes. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Sep 25 15:04:25 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90195-4>; Mon, 25 Sep 1995 15:02:03 +0200 Received: from ernie.icslab.agh.edu.pl (kiskra@ernie.icslab.agh.edu.pl [149.156.98.14]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id NAA14627 for ; Mon, 25 Sep 1995 13:01:32 GMT Content-Transfer-Encoding: 8bit Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id OAA22162; Mon, 25 Sep 1995 14:01:42 +0100 Date: Mon, 25 Sep 1995 14:01:42 +0100 (MET) From: Kamil Iskra Subject: Re: About .. in root, stderr, DosWedge, Ctrl-C, etc. To: Hans Verkuil cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9509222242.09nm@wyst.hobby.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 22 Sep 1995, Hans Verkuil wrote: > (I'm using KingCon 1.2, by the way. I tried 1.3 a long time ago, > but even then ixemul and KingCon 1.3 didn't like one another). What problems have you had? > BUT, if it > is really necessary to return to the old behavior, please let me know. > However, the old behavior means setting stderr to the same filehandle as > stdout, so the error messages are mixed up with the regular output. No, it's better as it is now. But I think that another, more tricky patch could be added. IXEmul could check in __open() or in another similar place if the filename to open is "*" or "console:". If it is, it could use ordinary dos.library/Open(), which works fine with KingCON, or set "dp_Port" to "pr_MsgPort". I'll try to make it and send patches ASAP (that means Wednesday or Friday :-). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Tue Sep 26 00:35:38 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90064-1>; Tue, 26 Sep 1995 00:32:40 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 25 Sep 95 23:31 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 25 Sep 95 23:25 MET Message-Id: Subject: new libdebug.a To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 25 Sep 1995 23:25:02 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 10477 hi, these is the first release of the libdebug.a its fully C= debug.lib compartible. a testfile is included. i will reachabel for bugreports until FR. unfortunaly i did manage to include the asm entries in the lib. because i had no idea who. can someone enlight me how this can be done ? walter btw: sorry for the long mail begin 644 debug.lha M($(M;&@U+58 !J =0DO'P "E]K8VUPYV "F%67 "\'LD,9L;T%P\^5IW+UI0K_,NT^)B'@AXEJ^ M-'<[3!2XC3PV==VQB+\F/Q3!Q8T"8)J_SHGS? MN\!QJ YB.V1]!&_(!OD?+X!GQE \2C=\@SWSW$U?VM#BC]-+Q^SYP7DRMHXX M9F90RI&E09ZMHYWK!MM'MA*KJOGY.'<%859 H*JL %HG7T,8L;V%P\]4TH=?Y M+KG]=0\"RS.3XH[8^06_!RUBFGR (!XM;&@U+6H ", =PDO'P "E]K M<')I;G1F+F_0(P!34G;9*0CZ123@ZP6"S.!R(1O3K# CK_+#%$%1%!WA#WA9 MV."P0*$## 2;8--. %"47X:8@K0';_":Z*_3/H/\ZC5=^[Y63"=Q!E(!GP,Z M):_M$N?5-):BM?MCGO8"RUBB\0H\;MPNV >Y"UL:#4M4P '< !X"2\? M (7VMP=71C+F^P#0 _2E:QJ$_H[4GC(2$G2$I@A^4@Q-\1(P2%$;@WA#>' M-!@D-G8028IHK %@EL)K%_()C,5M@"=Y]ZTW)&8E?W51*U2[K9KN//1'Y;Z] M@^.D?M)((!@M;&@U+5X "% >0DO'P "E]K<'5T7_IA>7_$NPJ8&3J:6M72FCL9@8".ZGPA?#5@*"G>\[#!"$'R$ 3A^_F M)L 5$:M 1IN->O&YIMV.D1=&IBW=QB1Y.+G_J'WI/QRLJK1-^#=QQQ>W)QNQP]1'@1,+@V1=LF<.6ZTR)+M"M^!Q@6^@]_((N@2:5V17>D"Y@3CVT^';K*_[!/07B M2M\&(H>E+9*JE"N"O_4+O(Z5DH*[B^]H5F-XY1V%&A-:F-;XL*G2;H4G&"\) M%O; BE=6+?0W\./?_^&+\")6)[A?@,F8]37+Z'2=!ND&[I:1/@Y:DK_/!_T9*5'?$47])+2&>NZEH:K\\+7W+Q MMP[$=V*:IV'"13!54531%'X(<<13A'QS?'2XB^AW9N1C&%^'E)04,W^**?>N M--;^9%&S"@F4Q>GAWB[DKJ[(L!4 MH'D*E!AB:J&SJD8EC(IAHI=(F13%E5B?(Q7R;_X3IJ+41D' Q M>F#+B[F5,HT:9&;8$O!:-3<;J.-J$:P5()!,;UR91084)IB9./J17_9: ML(E3P_*S!/6C:LHGZTO/O4$=SX$ M67X+LZYDVH0XM4U_W+N#BPIC673)_ AJJ',X@WCW7D#@A[7$$_#[63.@MEEE6*Y@.\(M>.''!%;\5[45Q=X17HKV+TX^K&T,$)?)[':# E!:M#1/!J$?D M!2A+9T]_+E8]=;.9L":NHA[0Z'U*\./__X38Z^=^U;W^&SVSS/?&1-V7+W$/ M6':*PNI/V5*B5_HGLS..CI-I-N4&QSS:?2ATK-KGCBKV-SG1?<@3O'.C@$R] MJ6LC?R52B:S,)(M>BG82?Z%& [0Z?([!1!.V%4@A1SO.S"?%JA2\+5BGQ2BB MFZ+8JTRE%LA3BE#B8?L_$%&)[?Q[8ZN31(RC'RY0FG_"-'1REX9^9D_*/BZH M;EXB-*Z.;&1UK7QKZ0T5HY.?:_X$?HWT>1]!8)^GTKQ;^1H:@7*,_SL[( M3,_TA 4H%^CIO1IK0Q]*S8XJ^EIV\_O6^YT.];^_AKCO#>=<+>#;[NH0$>!^L\GP-\!!-)L#F@>*!_N!'."D,*IX8$? ^GZ(9;0&L!&A5YP@/N >.!T M/O@?\ >8!_Z!YP'H@?E ]8#VP-D;WQ\';U0#J (>[V,!$0WLD"-,+V6!]("R M!HD?9D3W?@0\WO$ YX'C >0!]T"'W=>,)[C"[[U0)X5CXOQ.LDO7 ^P,=ZH" M&W=ACW87[OBGZG7?D#+ C 9?.!LG^!L_7"!&=T@II4@(YGT@ZTQ"M,'TQC= M,(:8BN^'R+OMJ!Q0,T",1OA!>[] #E ?W@1B.[_L!_W;^8+L@?IM_+V]+P>. M2/CNYY$OTOS)G7_JM_-OV1^6+6QH-2WV ,P( "\(+Q\ EK8VUPD+Y;[-UKGGO1'3L0/KUK?EF&;W;>GNZDKGR^W M('I\ 97O=6H?YW>9RI'*D=0$1H'8A6K[E=.&:Y]O8FJ>/V-VLH#K_98=5Y'J M_#]S;7+O(+%/&!9H_%Q8YT:I&";D+FP!;^"V)%-Y+L#>$,U(/AC)NO25<2>D+8P5-N_J85H;:T[$@TS$BPB<*VG)@C7IQKC*NB M?+@.7XO@]%!D32!48,V=?95H\8<4RX"T?" 7+6QH-2UR JP "\(+Q\ M IK9V5T8VAA(::^H+D!.MN4? MG?[ 5 \;2<+;'AD#O+V "QMM.V@;H MD8%-%39)UAG6U@3U31KI#5(D5BP8NF1,H*7'5G#312T]H%Y=% "[Z::-4BEJ M%%(T*F+8&:FB8%_A>4]HWF,/\U[ @_A$)=M-3^V$7'914&5,Y.P(@^-[H\." MW#R7+W3WC[50HHE7#VG4393!.[=FE:BH&2<.H8V&BC6/9H:Z*?-F( MG#9IDGS@FQU*;Y4NJ%Z+A1#=),;)W!W\^3YXPZ>O'T]H>X/5^Z/ I-+)YOG_ M$B$QOZ[/'K]73W;G)U;$YL6UI("KK-*G.ZJ\ M"J*HY5O;U4#2>3N\0I6+CN M;=\2Z>\%SJ8Y6(Y9Z4S'%;DY_KCQ&<,HTT*#LR?;R\?#$-H9,8]N[R\1[XC6 M!O6%1[^>6B,30_M[OM0=OS6W(* [U6([T>(YIJ-2YK\IE(@5@XDX;T' S30$F>-AS-8TJFA.:.:2^P..V9S!S(BXP^1S99M- M^,+7O@]]Y4+E(E9-)/4PPQ>-?H"$6S;6?DWLO1X6,$5O=!X=T'G*Z18I6AAW ML/Q)A%-HD&C!]TI!& >!\(V58R(^&^3Y:0%F'9 FX]K'DZL=@/BT0O:/I_(. M =VJ&T!RV;K 2,U@DZ]"6N$8-:PT)U+(!AL>^PR+=S-:=(%P& 5&+&M[?Q B';O9U(< M?!)YJ%"I*'*>OUOP8$#GJ-L/>GWP_6Z'Q;I.YTBKHUT-)5-0RLXI,T@_C82% M3+FW3&&R RK3[,[MVZ\&AXG'7_%7C)_HNW;I[!\'"WUW?2S+))!S%O&7W&0' M#Z@H5Z(YU M.?Y%1[B]72!C_WNN9(WS**R(@X*WGU* J[Q1-Z[UO ;(@YG7K_WQH?K<<".A M+6QH-2U@ B0 "\(+Q\ UK;6%Y9V5T8VAA.0]X*A^V%TA\-'M:H M:Q&$ZI">]($;STH[""@U=+_Y?@#X&XPH F[W$KOMLI%!9;(Z*O7.@\ ?BBUL M:#4MP0 #L! O""\? ):W!R:6YT9BYS1K< O5J3C:D/QNF@'L21:I[2 MM/'%_QP7!1R4YK*V_\ME).JB#IOZJ-$$&0 &DFK/R<_@X=^S;"NT]>.__=AO M2I7G'4 !V'J^\7VNZC:UO$3>-=M9J"Q_-N=PA,N-S)"^D4Y%TOA81Q-'W)B@ M@!=4W.).'UC^ )4"(D&02@5 M=4U'6]/58L48L =QV-F>T] 8*8+RAO= _OSZYGXS&) UXYG?_ ?MO H#P- MMO\Q7 [42X2H6= N.@6)5@P"[I2S"Y5=)Q :H7 ;2435VV.0+NU4CU?71G( M'Z_=@YGV"'1>)YDE5$V^.0TXYI6A0&KDER-T JD-7XDN"(T\> MN3C.(7'_YFA1J .Q(Y$U?0ZU')IU<25F7XN\Y&G+JA*2:YF*,3^VA1WM%,&ACE$Y6"$P75#!_M^B'RW MC0_ ?&^9:[KAJC'^2AZV+6QH-2U4 0 @0, #FP.1\ AM86ME9FEL9:%2 M 1MBE\VGHMS7[P!^!>!>"0VY8"&?_PV#"&#(;E2,95HV6)++@?'*262V5QN% MPV (XU%,P9A4?FFFJM(TK8/!.^[C75O%VP<4JNK.VI=@KI%O)(H6I2^"V)OJ M"NJ75'UYE\@S &O:.H3VNS]=FOV?( !M^?_JHYH5TM:PMH\^*6HY'A$H_6^JC=(.6.[ /?',0?-$1A$\2C!.Y>*+=R1Z!NZ M68<^AQ#I"CT09"^G47:E_:3SB*NO@ZB.P?MF5#A>,/8]0\=H :FUIA?B5&%1 MQ0B6D1<(1)L*)*X6P!CR,TT#HSZ->W2(OR@M&G'<>#Y=9Q2IP#)A.X#@T, & M5K'@=ZI&FWOC@L7-)V9IX+DS9OQ^^X7V\.$_7=>(R=XPS\91\B=Q+#S"3+P[ M *AX>-('_KV\B)CY.CS5Z5J "!>+6QH-2VG @ < "6O.1\ M IL:6)D96)U9RYAA,0"#&.;U;2H/]K<-; TJQC,L4:Z:/$(6TP;9FA%: $P MEF@<*<+C.38(3!8%S,<#)C,C'@7E>9Y'BT?@&\1P'(\+P,8\+(\+&#(#?_6^ M]K2)2$9,0(\#\#',,G+4Y>Q-HZU+1Q$J%"_S<[+Q<;'4>^EK+JX>&O,6&-5W M!54W_L%626'/2 ] ._'-B'.*?0 #^H)]4I]DI]H3VA/ME/( .8T)SRGG "$ ML3I%.J4QZFA]1/RE/SE/U $2T)^LI^RAE,56LUO6"AITJK6N2#*R-!MC1HDP MJF@W2?A'*RZ.P_FU:.Q;X#*GZVEJ-XXXK1(*9,&L;B&JQNC$A>RGNYC/KVX' MNS:E:J\@V1@MI:_U35K667E82J_!6M9565*E$/#?K6>=S7JIV_HT$8*:H(1] M4$4XWNZ=-*<%0^G]V@9K-',UASD(CW#(C_O(C_+=+BIF:E)5,92R;BE6F0J7 MHP)B1OJ7 BWU<$&;7Z/G6-/% M9IW*LOK/^*_GP1WO)I4+I+AOW*N*&2K"H5.*JJ)K]L?8$<"+@)$5>-^28K-K M>_$B@59DW)S^70.=!I*_VP S%?8\O_Z'2,=-,U;][=*NS+.Z_NAWCW1)&W-< M%>UE;BSP<&%9R.59O+%.-43(M4XU/<3FA=P,%]AH0UW@CZW'X2TC>$Q]@N^: M5>Y75>5+A8/ON:W\GZ5SR+]L/(%<#;F[L?-?4'S5B:(GB":H^,**)S/$#GPS MP#QC'>4P:*#[MG=!)0Y4^P)R3LGO20'F6\QA"P*B5CG_/9T@<\.W9$?!\MG;L M2#KIW))TD>)G<.Y?]^.7A\Q@'!TM;&@U+:T! 2 P #K,Y'P !G1ER6F3,I;@JF223MSAM MK-H.0'6D,7N#7/LL&?MA,M+(@B'TP&+&M5KO(6,RP0XZDI>QL.H_"-OQ9\L' M<"T*5->%-"R*LJQK)*'M+_!SZ-&UF1RMPK*Q#[XG),UV)U9UD\H<371O#'N- M,?MCW=Q_/^)WJH3-$<&S7IB).-H[O>8J M[DS MRZ>%B>YIEOT: A ]<3;"YXFY#_#(FM"!<6Z-&55<8A,\.?%%;&&TA,F%^5Z* M3&)WQ#F!+%N4MY"?2/A]/F/O]M0\/KJT_G51PP(>VF[!&Z%C-JST=57 M7X]=*NSL]*NECUN/04,4ZR,Q%?.A@^#*-6<$6.932%OPUED,;R0TN_FSSD>K M1WC.\35\FO#&>"FIZ8GXDFOR/D?@=U;]QGX3QL&95@G%R<,3TS/+"7+HW_U MH'$\L[C+T01?QZ+XTKEX1QTAD2*]WLCL'SD (G M;&@U+5L# !5!@ *;0Y M'P #&1E8G5G+G)E861M934[ T!KFM6VVX?S,_ 'TXXZ!':Y=)@&-@-+=-!0 M)IH-K<-QX%E>29R2)6));C^.7_B4X[=P;,!HVTW?(UPPXD>\X<2P:Z_JP;M@ ML=,H/WML.PN#9;BEN,O#R^GQ+@N)+WK;@O:>!-<47S@P]2GN,C]&'E)KW49D M<[#VSNU")DLF/<)-%%S[:+7P;6"V&I)#F3=1-DD_#^X#_#"D^MFZ]!:$,>9 MOM@_'F$*'Y7_$K4K[1I)ZLKFVR);K"Q7QVF4XB$;>)/#1"*5>ZT.7J M+X?3YD V3C$9643%9[*2N<@6!U<;)!6^CVJ)P:O#)\)(0A2E#0E[-@CK,)BY M5 9ZWZ!(]OL0%L6C;Q?,<7"@MC8",UQ)G(2XM[0 )QW-&+08,%RI@D_")>SV MUH=FTID"*,;%*P>Q> _[GBX):!]^'4 3&0K*3;0C6[B3-RX4G4N.0B?2N+&M M+HTT=G3QVG#86OK]]7Y'&J0N;E8;"Z.@.49PR@T$KHH TLT?^S&@R=5*5 \7 MR,!*JY,**C51) ]?:1?B6X_0M?N4490:,+]P97U$OY*[B^:0GS@<4RKW*57/!C[#T/V_X+T1$,Q;%BE7LQR!WU1T?WRY/T:*YT*O M2@]%O+GFN5 M>!?]E_U[!BY:&*O%GW2MHQ9\@NKGD@OQ1BG)@8$84XA?ST5HMY"'/D^@9!TY M!A.3Q>Z]S^">!W;@>,=E,I%QB>([P(41@U-$1885&Y^*;_]B:YO4\/(VO93: M]7[KX?F_],9=.G1U=G7UIW_5?'P.7Q3"DBZNP8AA)YSHA#)K[5)*S]!C2#UO 7&H4?KXV8SI8NF(]+[>O@3MG*8>.A2@#" end -- ----- "Life is a hereditary disease, sexually transmitted and invariably fatal." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Sep 26 12:23:36 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90083-4>; Tue, 26 Sep 1995 12:20:55 +0200 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Tue, 26 Sep 95 11:17:16 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <215ba238.u8t20e.d7463-robert@plukwa.pdi.lodz.pl> Subject: Re: geteuid() and getpwuid() .... In-Reply-To: <9509222252.09nw@wyst.hobby.nl> (from hans@wyst.hobby.nl (Hans Verkuil)) (at Fri, 22 Sep 1995 23:52:50 +0000 (CET)) Reply-To: robert@pdi.lodz.pl Content-Length: 1207 To: hans@wyst.hobby.nl Cc: amiga-gcc-port@nic.funet.fi, robert@lodz.pdi.net Date: Tue, 26 Sep 95 11:17:16 On Sep 22 Hans Verkuil wrote: > getpwuid() used to be a dummy function that returned a passwd struct that > was always the same, but in my copy (which will also go to Fred Fish) it is > a bit more intelligent and uses the environment settings HOME and USER to > fill in the pw_dir and pw_name fields of the struct. Thanks for telling me that. I was just about to do the same =o) > > Hans > > -- > Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, > The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl > > "...and the princesses were beautiful as the day is long and so noble they > could pee through a dozen mattresses --" (Terry Pratchett) > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Sep 26 12:51:04 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90835-3>; Tue, 26 Sep 1995 12:50:02 +0200 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Tue, 26 Sep 95 11:40:14 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <215ba78a.u8t20e.b2d0a-robert@plukwa.pdi.lodz.pl> Subject: Re: geteuid() and getpwuid() .... In-Reply-To: <9509222308.09o1@wyst.hobby.nl> (from hans@wyst.hobby.nl (Hans Verkuil)) (at Sat, 23 Sep 1995 00:08:53 +0000 (CET)) Reply-To: robert@pdi.lodz.pl Content-Length: 3053 To: hans@wyst.hobby.nl Cc: amiga-gcc-port@nic.funet.fi Date: Tue, 26 Sep 95 11:40:14 On Sep 23 Hans Verkuil wrote: > Hi Robert, > > > > Some of this stuff (esp. struct passwd) might actually change due to > > > ixemul source cleanup, but I believe Fred Fish and Hans Verkuil would > > > know more in this case. > > > Fred, Hans can You provide me with info on stage in which the cleanup is > > now or when will it be done? (Maybe i could be of any help?) > > The struct passwd shouldn't change at all, it's the BSD format. > > I'm still waiting for Fred to finish merging two ixemul versions. After > that I'll take over for the cleanup. And after that Jeff Shepherd will add > AmiTCP support to the library. But it will take several weeks if not > longer before that's all done. This would be very nice! =o) > > As to help: more work is needed not so much on the library as well as on > the gcc compiler and linker. The support for Amiga hunks needs to be added > to the new binutils set so that the linker from that set can be used. I > understand that it's 99% finished so this shouldn't be much work. I may be > wrong, of course :-) > > Also it would be nice to have support in gcc for the chip keyword. Some > code is written, but it is not used at the moment. > > If you prefer to do work on the library you could test the profiling > support. As far as I can see it should work correctly, but it needs to be > tested, and I have no time for that. > > The ixtrace utility needs to be updated (the new functions are not traced > at the moment, or at least not properly). > > And of course, if you like a challenge, implement the ptrace() function so > that gdb can be ported. I was thinkg very hard and very long about Your letter. I must say that my knowledge or programming skills at this moment are rather to small to be of great help if any at all. I've been out of programming in C for couple of years now. (In my previous job i was doing developement using ORACLE RDBMS system which kept me from hmmm.... "low" level). Now I'm back to businnes but as the saying goes "unsed parts start to disappear" First i have to put my self back on the right track and this might take some time. I think that at this very moment i can volunteer to test profiling support in the library. Sorry if I disappointed You > > Hans > > -- > Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, > The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl > > "...and the princesses were beautiful as the day is long and so noble they > could pee through a dozen mattresses --" (Terry Pratchett) > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.pdi.lodz.pl/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Sep 26 23:39:13 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90822-4>; Tue, 26 Sep 1995 23:37:11 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 26 Sep 95 22:36 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 26 Sep 95 22:29 MET Message-Id: Subject: Re: geteuid() and getpwuid() .... To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 26 Sep 1995 22:29:20 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1120 > > Also it would be nice to have support in gcc for the chip keyword. Some > code is written, but it is not used at the moment. > as the motorola support. maybe we get it thise time ? > If you prefer to do work on the library you could test the profiling > support. As far as I can see it should work correctly, but it needs to be > tested, and I have no time for that. > i support a list that shows how much time is needed for what funktion. that would help in to way. 1. to avoid costly funktions 2. to create some ideas how to improve speed > The ixtrace utility needs to be updated (the new functions are not traced > at the moment, or at least not properly). > in the discussion for the ansi-c v3 i saw the idea of __FUNC__ as implemention for debugging simply containing the actual funktionname. is that a thing we can add too ? > And of course, if you like a challenge, implement the ptrace() function so > that gdb can be ported. > nothing against challange but i have no idea about task shedule in exec. -- ----- "The golden rule is that those with the gold make the rules." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Sep 27 10:16:19 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90778-3>; Wed, 27 Sep 1995 10:09:01 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id JAA25304; Wed, 27 Sep 1995 09:06:31 +0100 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id JAA23588; Wed, 27 Sep 1995 09:06:51 +0100 Date: Wed, 27 Sep 1995 09:06:51 +0100 From: Niklas Hallqvist Message-Id: <199509270806.JAA23588@linda.appli.se> To: Walter.Harms@arbi.informatik.uni-oldenburg.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Walter Harms on Tue, 26 Sep 1995 22:29:20 +0100 (MET)) Subject: Re: geteuid() and getpwuid() .... >>>>> "Walter" == Walter Harms writes: >> Also it would be nice to have support in gcc for the chip >> keyword. Some code is written, but it is not used at the moment. >> Walter> as the motorola support. maybe we get it thise time ? How would you want it? Total switch-over or runtime-option? Dependent on -noixemul? Knowing the internals of GCC somewhat I know that as things are today, GCC can only be compiled for one syntax at a time, because the syntax choice is in a compile time option. Of course a global and an option to control it could be added, but then it's not just a one-line change anymore. I'd say switching to MOTO syntax would make some people SCREAM!!! So you'd better keep backward compatibility... I mean there are two types of people using GCC, Unix-hackers (like me) never done ADOS assembly at all, and grownup ADOS hackers which of course has another education. It would be good to support both, but someone got to do the job. >> The ixtrace utility needs to be updated (the new functions are not >> traced at the moment, or at least not properly). >> Walter> in the discussion for the ansi-c v3 i saw the idea of Walter> __FUNC__ as implemention for debugging simply containing the Walter> actual funktionname. is that a thing we can add too ? Why? __FUNCTION__ and __PRETTY_FUNCTION__ has been there for years. Ready the docs on GCC extensions. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Wed Sep 27 16:20:53 1995 Received: from dira.bris.ac.uk ([137.222.10.41]) by nic.funet.fi with ESMTP id <90624-2>; Wed, 27 Sep 1995 16:19:24 +0200 Received: from zeus.bris.ac.uk by dira.bris.ac.uk with SMTP (PP); Wed, 27 Sep 1995 15:18:57 +0100 Received: by zeus.bris.ac.uk (950215.SGI.8.6.10/940406.SGI) for amiga-gcc-port@nic.funet.fi id PAA00926; Wed, 27 Sep 1995 15:18:56 +0100 From: Pierre.Scotney@bristol.ac.uk (PD. Scotney) Message-Id: <199509271418.PAA00926@zeus.bris.ac.uk> Subject: libnix help! To: amiga-gcc-port@nic.funet.fi Date: Wed, 27 Sep 1995 15:18:56 +0100 (BST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 383 Hello! Does anybody know which shared libraries are automatically opened by the libnix link-library. And especially how to get libnix to automatically open other shared libraries. I've read through the libnix.guide file, but there is no mention of which libraries it opens through the libstub.a link file. I am currently using GCC 2.6.3. Any help is welcome! Thanks! Pierre. From amiga-gcc-port-owner@nic.funet.fi Wed Sep 27 16:26:54 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <90742-4>; Wed, 27 Sep 1995 16:26:41 +0200 Received: from lysistrate.lysator.liu.se (lysistrate.lysator.liu.se [130.236.254.161]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id PAA01714; Wed, 27 Sep 1995 15:26:32 +0100 Received: (nisse@localhost) by lysistrate.lysator.liu.se (8.6.11/8.6.11) id PAA24293; Wed, 27 Sep 1995 15:26:25 +0100 Date: Wed, 27 Sep 1995 15:26:25 +0100 Message-Id: <199509271426.PAA24293@lysistrate.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: Pierre.Scotney@bristol.ac.uk CC: amiga-gcc-port@nic.funet.fi In-reply-to: <199509271418.PAA00926@zeus.bris.ac.uk> (Pierre.Scotney@bristol.ac.uk) Subject: Re: libnix help! From: Pierre.Scotney@bristol.ac.uk (PD. Scotney) Does anybody know which shared libraries are automatically opened by the libnix link-library. And especially how to get libnix to automatically open other shared libraries. I've read through the libnix.guide file, but there is no mention of which libraries it opens through the libstub.a link file. I am currently using GCC 2.6.3. Any help is welcome! You should probably look at libauto instead. If you link with it, it will open the libraries you need automatically. For this to work, do *NOT* define the library bases yourself. That is, use extern struct *GfxBase GfxBase; ^^^^^^ /Niels From amiga-gcc-port-owner@nic.funet.fi Wed Sep 27 17:16:01 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90814-1>; Wed, 27 Sep 1995 17:10:49 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HVRZ29GDN4007VDQ@NET2.WAU.NL>; Wed, 27 Sep 1995 16:11:04 +0000 (GMT) Received: by vines2.wau.nl; Wed, 27 Sep 95 16:08:56 +0100 Date: Wed, 27 Sep 1995 15:59:40 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Libnix improvement To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi All, In the progress of dumping ixemul.library while porting Ghostscript3.33 I have come across a feature I would like to see implemented in Libnix. I gave away an 020-40 compiled version to Walter and he tried to run it on an A1200+030 but without FPU -->GURU (fpu trap) It would be nice to have some code in the ncrt.o which checks if the cpu options it is compiled for actually match the machine it is running on. That would prevent such things like the above. Right now there is only one flavor of the startupcode but there are different flavors of the link library so making different flavors of the startup code shouldn't be too hard, right Matthias/Gunther. I might try to implement it myself but I'm sure if I can time wise. It might be implemented with the use of #ifdef's. Any ideas on this? Why isn't it implemented at the moment, seems a useful feature. Joop PS: Please mail a CC to me if you react to the mailinglist. Thanks From amiga-gcc-port-owner@nic.funet.fi Wed Sep 27 17:22:22 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90115-3>; Wed, 27 Sep 1995 17:21:20 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HVRZGB2YCW007MIE@NET2.WAU.NL>; Wed, 27 Sep 1995 16:22:26 +0000 (GMT) Received: by vines2.wau.nl; Wed, 27 Sep 95 16:20:26 +0100 Date: Wed, 27 Sep 1995 16:12:44 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Problem with os-includes To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi All Again, I tried to compile XPM lib which I'm testing for someone and found a problem with UtilityBase. Have a look at the following output from gcc270 -v gcc -m68000 -O2 -v -D__SASC -D_AMIGA -c bitmapiclass.c Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cpp -lang-c -v -undef - D__GNUC__=2 -D__GNUC_MINOR__= 7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ - D__amigados__ -D__M CH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA - D__AMIGA -Asystem(amigad os) -Acpu(m68k) -Amachine(m68k) -D__OPTIMIZE__ -Dmc68010 -D__SASC -D_AMIGA bitmapiclass.c /t/cc10 2976.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cc1 /t/cc102976.i -mfixedstack - quiet -dumpbase bitm apiclass.c -m68000 -O2 -version -o /t/cc102976.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. /gnu/os-include/inline/utility.h: In function `AddNamedObject': In file included from /gnu/os-include/proto/utility.h:6, from bitmapiclass.c:16: /gnu/os-include/inline/utility.h:28: warning: initialization from incompatible pointer type /gnu/os-include/inline/utility.h: In function `AllocNamedObjectA': /gnu/os-include/inline/utility.h:42: warning: initialization from incompatible pointer type /gnu/os-include/inline/utility.h: In function `AllocateTagItems': ........ /gnu/os-include/proto/utility.h: At top level: In file included from bitmapiclass.c:16: /gnu/os-include/proto/utility.h:9: conflicting types for `UtilityBase' /gnu/os-include/inline/utility.h:21: previous declaration of `UtilityBase' bitmapiclass.c:148: parse error before `bitmapi_dispatcher' bitmapiclass.c:149: parse error before `Class' In 'inline/utility.h' the declaration of UtilityBase was changed from struct Library *UtilityBase to struct UtilityBase *UtilityBase. When I changed it back to 'Library' the source compiled without error. Can anyone comment on why it was changed. There is a comment in inline/utility.h but no name. Joop From amiga-gcc-port-owner@nic.funet.fi Wed Sep 27 18:51:31 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90288-4>; Wed, 27 Sep 1995 18:50:17 +0200 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 27 Sep 95 17:44:01 From: robert@plukwa.pdi.lodz.pl (Robert Ramiega) Message-Id: <215d4e5d.u8t20e.b4af3-robert@plukwa.pdi.lodz.pl> Subject: Re: libnix help! In-Reply-To: <199509271426.PAA24293@lysistrate.lysator.liu.se> (from Niels M|ller ) (at Wed, 27 Sep 1995 15:26:25 +0100) Reply-To: robert@lodz.pdi.net Content-Length: 1420 To: nisse@lysator.liu.se Cc: amiga-gcc-port@nic.funet.fi, Pierre.Scotney@bristol.ac.uk Date: Wed, 27 Sep 95 17:44:01 On Sep 27 Niels M|ller wrote: > From: Pierre.Scotney@bristol.ac.uk (PD. Scotney) > > Does anybody know which shared libraries are automatically opened by the > libnix link-library. And especially how to get libnix to automatically > open other shared libraries. I've read through the libnix.guide file, but > there is no mention of which libraries it opens through the libstub.a link > file. I am currently using GCC 2.6.3. > > Any help is welcome! > > You should probably look at libauto instead. If you link with it, it > will open the libraries you need automatically. For this to work, do According to Amiga GCC FAQ libnix authors warn about using libauto.a with libnix. Libauto.a is designed to work with ixemul.library. Libinx has autoopen feature bulit in it. > *NOT* define the library bases yourself. That is, use > > extern struct *GfxBase GfxBase; > ^^^^^^ This of course is still true =o) > > /Niels > > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@pdi.lodz.pl IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Sep 28 12:00:44 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90130-4>; Thu, 28 Sep 1995 11:57:55 +0200 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id KAA13942 (8.6.12/IDA-1.6); Thu, 28 Sep 1995 10:56:59 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA16332; Thu, 28 Sep 95 10:56:58 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9509280956.AA16332@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: libnix help! To: Pierre.Scotney@bristol.ac.uk (PD. Scotney) Date: Thu, 28 Sep 1995 10:56:58 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199509271418.PAA00926@zeus.bris.ac.uk> from "PD. Scotney" at Sep 27, 95 03:18:56 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 747 > > Does anybody know which shared libraries are automatically opened by the > libnix link-library. And especially how to get libnix to automatically > open other shared libraries. I've read through the libnix.guide file, but > there is no mention of which libraries it opens through the libstub.a link > file. I am currently using GCC 2.6.3. > If you want to add more libraries to the list you first have to get the libnix sources. Then look into the file sources/stubs/library.list and add the name of the library and the base variable. After this recompile libstubs.a. If you don't want to recompile the whole stubs library just build two files similar to those in sources/stubs/lib(bases)|(names)/ and add them when compiling. Matthias From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 12:40:52 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90607-3>; Fri, 29 Sep 1995 12:33:14 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA11986; Fri, 29 Sep 1995 11:34:23 +0100 Date: Fri, 29 Sep 1995 11:34:22 +0100 (MET) From: Kamil Iskra Subject: Patch to fix an incompatibility between IXEmul 41.3 and KingCON 1.3 To: fnf@amigalib.com cc: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII As I mentioned in a few of my previous postings, there is an incompatibility between IXEmul 41.3 and KingCON 1.3 - every time an IXEmul client is run Enforcer hit is generated (at least on some machines...). This is KingCON's fault, because it makes invalid assumptions about the nature of reply port contained in "dp_Port" of packets sent to it. Until KingCON's author fixes this nasty bug (I contacted with him, but so far got no reply), I propose the following patch to be added to file "library/open.c" of IXEmul: *** open.c.orig Sat Jul 8 08:59:04 1995 --- open.c Tue Sep 26 12:23:18 1995 *************** *** 157,163 **** do { ! fh = __open (name, amode); if (! fh) { --- 157,170 ---- do { ! if (!strcmp(name, "*") || !strcasecmp(name, "console:")) ! /* Temporary patch for KingCON 1.3, which seems to have problems with ! ACTION_FINDINPUT of "*"/"console:" when "dp_Port" of the packet is ! not set to sender's "pr_MsgPort" - that's what IXEmul makes on ! clients' startup during initialization of "stderr". */ ! fh=Open(name, amode); ! else ! fh = __open (name, amode); if (! fh) { / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 14:06:20 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90764-2>; Fri, 29 Sep 1995 14:04:56 +0200 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 29 Sep 95 13:00:10 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <215faed6.u8t20e.7b3aa-robert@plukwa.lodz.pdi.net> Subject: CON: <-> RAW: how?? Reply-To: robert@lodz.pdi.net Content-Length: 689 To: amiga-gcc-port@nic.funet.fi Date: Fri, 29 Sep 95 13:00:10 Hi! I have one question. How to switch Amiga shell window between CON: and RAW:? (using GCC of course) Any help greatly appreciated! Robert Ps. Kamil thanks for Your reply. As You can see i'm following Your advice =o) +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 15:43:33 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90902-1>; Fri, 29 Sep 1995 15:41:44 +0200 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HVUDJ09F4090Z994@LEON.CTI.GR>; Fri, 29 Sep 1995 09:27:02 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA00258; Fri, 29 Sep 95 09:30:52 +0200 Date: Fri, 29 Sep 1995 09:30:51 +0200 (EET) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Question on adding flavors to ld To: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9509290730.AA00258@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 848 If I remember correctly, Fred said that adding flavors to the binutils version of ld was merely a matter of figuring how to tell ld which paths to use. Pardon my ignorance, but can't this be done through gcc's specs file and the appropriate use of -L options that depend on the cpu type and the presense or not of the -noixemul switch? If this is indeed the case, I'll try to whip up the appropriate specs file during the weekend. (BTW, I don't recall Fred mentioning that adding support for -fbaserel was required for the binutils ld. Does this mean that it is already there, or is this yet another example of the 10%-90% rule?) -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "What is your name, sir?" "Dr. What." "Dr. who, sir?" "What! Who is my uncle; I haven't seen him for ages!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 17:00:45 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90509-2>; Fri, 29 Sep 1995 16:58:56 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Fri, 29 Sep 95 15:58 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Fri, 29 Sep 95 15:44 MET Message-Id: Subject: yab: gcc To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Fri, 29 Sep 1995 15:44:46 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2262 yet an other bug: internal compiler error in gcc (better cc1) stack 300000 ixemul 41.3 gcc 2.7.0 The problem occured in the first file, while compiling gas on an amiga2000 I changed in the makefile cc to gcc, the problem occurs under sh also. i havent checked without -O yet because i thing some ppl before my have compiled gas with gcc (wild guess, i know) /** make output **/ rm -f config.new config-stamp echo '/* config.h. Generated automatically by make. */' > config.new echo '#ifndef GAS_VERSION' >> config.new echo '#define GAS_VERSION "2.5.2"' >> config.new echo '' >> config.new cat conf >> config.new echo '#endif /* GAS_VERSION */' >> config.new /Nathan/binutils-2.5.2/gas/../move-if-change config.new config.h config.h is unchanged touch config-stamp gcc -v -c -O2 -I. -I/Nathan/binutils-2.5.2/gas -I../bfd -I/Nathan/binutils-2.5.2/gas/config -I/Nathan/binutils-2.5.2/gas/../include -I/Nathan/binutils-2.5.2/gas/.. targ-cpu.c /** output of gcc -v **/ Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cpp -lang-c -v -I. -I/Nathan/bin 2/gas -I../bfd -I/Nathan/binutils-2.5.2/gas/config -I/Nathan/binutils-2.5.2/g ude -I/Nathan/binutils-2.5.2/gas/.. -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -D amiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ MIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA amigados) -Acpu(m68k) -Amachine(m68k) -D__OPTIMIZE__ -Dmc68010 targ-cpu.c /t/ GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: . /Nathan/binutils-2.5.2/gas ../bfd /Nathan/binutils-2.5.2/gas/config /Nathan/binutils-2.5.2/gas/../include /Nathan/binutils-2.5.2/gas/.. /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cc1 /t/cc256296.i -mfixedstack - /t/cc256296.s /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cc1 /t/cc256296.i -m gcc: Internal compiler error: program cc1 got fatal signal 6 make: *** [targ-cpu.o] Error 1 -- ----- "Captain... you are BLUE!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 17:04:52 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90398-1>; Fri, 29 Sep 1995 17:04:35 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sygym-0004nbC; Fri, 29 Sep 95 08:04 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Question on adding flavors to ld To: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Date: Fri, 29 Sep 1995 08:03:59 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9509290730.AA00258@hpcl.cti.gr> from "Kriton Kyrimis" at Sep 29, 95 09:30:51 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2228 > If I remember correctly, Fred said that adding flavors to the binutils version > of ld was merely a matter of figuring how to tell ld which paths to use. Not quite. You tell ld what the flavors are, '-fm68020 -fm68881' for example, and ld figures out what the path is itself, using the regular search paths or -L options as roots of those paths. I.E. '-L/gnu/lib/gcc-lib -ffoo -fbar' would cause ld to construct the search patch /gnu/lib/gcc-lib/bar/foo, if it uses the original algorithm I implemented (sort flavors alphabetically and append them to root of search tree). I seem to recall though that there was not 100% agreement on this algorithm, though I forget the details now. Philippe may have made some tweaks to the way the current linker does flavors. We really should come up with a specification for this feature that is well documented, before jumping into another implementation. I am going out of town in a few hours and will be gone for a couple days, but when I get back I'll try to dig out whatever old email I have on this subject and put together some sort of documentation that at least describes the basics. We can use that as the basis for an implementation specification. > Pardon my ignorance, but can't this be done through gcc's specs file and the > appropriate use of -L options that depend on the cpu type and the presense or > not of the -noixemul switch? No, because under the original concept you could walk back up the search path to find a library if the particular flavor you were looking for did not exist. I.E. given: /gnu/lib/gcc-lib/libfoo.a /gnu/lib/gcc-lib/libz.a /gnu/lib/gcc-lib/m68020/libfoo.a /gnu/lib/gcc-lib/m68020/libbar.a /gnu/lib/gcc-lib/m68020/m68881/libfoo.a a '-L/gnu/lib/gcc-lib -f m68881 -m68020 -lbar -lfoo -lz' would find: /gnu/lib/gcc-lib/libz.a /gnu/lib/gcc-lib/m68020/libbar.a /gnu/lib/gcc-lib/m68020/m68881/libfoo.a > (BTW, I don't recall Fred mentioning that adding support for -fbaserel was > required for the binutils ld. Does this mean that it is already there, or is > this yet another example of the 10%-90% rule?) Hmm, I don't recall for sure about -fbaserel. Someone will have to actually try it or look through the source. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 17:11:58 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90280-2>; Fri, 29 Sep 1995 17:10:53 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Fri, 29 Sep 95 16:09 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Fri, 29 Sep 95 15:59 MET Message-Id: Subject: sh bug ? To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Fri, 29 Sep 1995 15:59:26 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 494 i started to compile gas with the help of fred fish but using sh ../binutils-2.5.2/configure -v m68k-cbm-amigados caused *** ../binutils-2.5.2/configure.in has no "per-host:" line. while calling configure.in inside sh is ok after exiting sh if found a very slow computer. ARTM showed me a sh task disguised as cli (5677992) [choose any number] maybe sh didnt close a child ? walter btw: freezing/removing the task adds a LOT of speed -- ----- "Captain... you are BLUE!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 17:20:27 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90956-3>; Fri, 29 Sep 1995 17:19:12 +0200 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HVUU0N3URK90VELX@LEON.CTI.GR>; Fri, 29 Sep 1995 17:18:36 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA02314; Fri, 29 Sep 95 17:22:29 +0200 Date: Fri, 29 Sep 1995 17:22:29 +0200 (EET) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: Question on adding flavors to ld In-reply-to: from "Fred Fish" at Sep 29, 95 08:03:59 am To: fnf@amigalib.com (Fred Fish) Cc: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9509291522.AA02314@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 1452 > > Pardon my ignorance, but can't this be done through gcc's specs file and the > > appropriate use of -L options that depend on the cpu type and the presense or > > not of the -noixemul switch? > > No, because under the original concept you could walk back up the search > path to find a library if the particular flavor you were looking for did not > exist. I.E. given: > > /gnu/lib/gcc-lib/libfoo.a > /gnu/lib/gcc-lib/libz.a > /gnu/lib/gcc-lib/m68020/libfoo.a > /gnu/lib/gcc-lib/m68020/libbar.a > /gnu/lib/gcc-lib/m68020/m68881/libfoo.a > > a '-L/gnu/lib/gcc-lib -f m68881 -m68020 -lbar -lfoo -lz' would find: > > /gnu/lib/gcc-lib/libz.a > /gnu/lib/gcc-lib/m68020/libbar.a > /gnu/lib/gcc-lib/m68020/m68881/libfoo.a Wouldn't the same sort of thing be accomplished using: -L/gnu/lib/gcc-lib/m68020/m68881 -L/gnu/lib/gcc-lib/m68020 -L/gnu/lib/gcc-lib with the appropriate -L options (and the order thereof) being determined by the specs file? From what I remember about the specs file, it permits you to say things like: if m68020 { if m68881 { use 68020+68881 options }else use 68020+soft-float options } }else{ use 68000 options } to arbitrary depths, using a LISP-like syntax. Thus, a complicated expression involving: -m680*0, -m68881, -m68020-40, -m68040-only, all variants of the previous options beginning with mc rather than m, -noixemul, -fbaserel, and -resident would do the trick. Complicated, but doable. From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 17:25:49 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90755-4>; Fri, 29 Sep 1995 17:25:15 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0syhFE-0004nbC; Fri, 29 Sep 95 08:21 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: sh bug ? To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Fri, 29 Sep 1995 08:21:00 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Walter Harms" at Sep 29, 95 03:59:26 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 734 > i started to compile gas with the help of fred fish but > using > > sh ../binutils-2.5.2/configure -v m68k-cbm-amigados > caused > *** ../binutils-2.5.2/configure.in has no "per-host:" line. I usually start an sh, and then from the sh do: # sh /gnu-src/src/binutils-2.5.2/configure -v m68k-cbm-amigados >logfile 2>&1 This is so I can capture the configure output for later perusal. One thing you might try is to use an absolute pathname to the source directory. I seem to recall that there is a bug in either the shell or the configure script that causes the "sh ../binutils-2.5.2/..." form to not work with some of the utils. I've since forgotten the details since I almost always do it with absolute paths. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 17:47:12 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90705-4>; Fri, 29 Sep 1995 17:46:14 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0syhdV-0004nZC; Fri, 29 Sep 95 08:46 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Question on adding flavors to ld To: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Date: Fri, 29 Sep 1995 08:46:04 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@lists.funet.fi In-Reply-To: <9509291522.AA02314@hpcl.cti.gr> from "Kriton Kyrimis" at Sep 29, 95 05:22:29 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1371 > Wouldn't the same sort of thing be accomplished using: > > -L/gnu/lib/gcc-lib/m68020/m68881 -L/gnu/lib/gcc-lib/m68020 -L/gnu/lib/gcc-lib In theory, but the number of combinations to choose from is 2**N, where N is the number of flavors. Thus if you have 10 different flavors (not unreasonable), you have potentially 1024 -L paths to choose from, not all of which will be valid combinations. Choosing the right combinations was part of why the original concept of simply walking back up the tree was flawed. It missed some possibly useful matches. For example, given flavors -f m68030 and -f m68881 your example above would be: -L/gnu/lib/gcc-lib/m68030/m68881 -L/gnu/lib/gcc-lib/m68030 -L/gnu/lib/gcc-lib and you do not also search any other locations which might have m68881 flavors for a lessor processor, like /gnu/lib/gcc-lib/m68020/m68881, or even /gnu/lib/gcc-lib/m68881 (which is perfectly valid if you only want to compile one floating point version of a library rather than several different ones). Searching /gnu/lib/gcc-lib/m68881 would mean you would get a version without any optimizations for later processors, but at least it would be an m68881 version. It might be the closest match to what you want, if the specific flavor m68030+m68881 is not available. It is probably certainly a better match than a library from /gnu/lib/gcc-lib. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 19:00:40 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90949-1>; Fri, 29 Sep 1995 18:10:12 +0200 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 29 Sep 95 17:05:14 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <215fe847.u8t20e.63cd8-robert@plukwa.lodz.pdi.net> Subject: utils for gcc2.7.0 Reply-To: robert@lodz.pdi.net Content-Length: 1393 To: amiga-gcc-port@nic.funet.fi Date: Fri, 29 Sep 95 17:05:14 Hi all! I just want to let You know that I'm slowly recompiling varius GNU utils with gcc2.7.0. Right now i've recompiled sh-utils 1.12, findutils 4.1, fileutils 3.12, gawk 2.15.6 and make 3.71 In a couple of days i'll also recomplie diffutils 2.7, flex 2.4.7, gzip 1.2.4 and tar 1.11.2 and maybe a few others. All the sources where taken from FreshFish CD-ROM mounted in Aachen. I didnt change a bit in them i've just recomplied them with gcc2.7.0 using -mstackextend and -m68020-40. Due to the last option the binareis are usable only to those who have 68020+ and 68881. When I'll finish this pass i recompile all this again to create 68000 binaries for all the rest. I put it this evening on plukwa.lodz.pdi.net in /amiga/gnu/utils that what i have already compiled for those interested in it. Robert Ps. I did it mainly because i didn't have anything better to do and i thought it might be usable to somebody else +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 19:00:41 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90760-1>; Fri, 29 Sep 1995 18:09:52 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26727-1>; Fri, 29 Sep 1995 18:07:12 +0200 Received: from hphalle6j.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395394-1>; Fri, 29 Sep 1995 17:07:05 +0100 Subject: Re: CON: <-> RAW: how?? From: Christian Stieber To: robert@lodz.pdi.net Date: Fri, 29 Sep 1995 17:06:52 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <215faed6.u8t20e.7b3aa-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Sep 29, 95 01:00:10 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 365 Message-Id: <95Sep29.170705+0100mesz.395394-1+2125@hphalle0.informatik.tu-muenchen.de> > I have one question. How to switch Amiga shell window between CON: and > RAW:? dos.library/SetMode(). Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 19:00:42 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90109-2>; Fri, 29 Sep 1995 18:05:36 +0200 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HVUVLU6PI890U4UA@LEON.CTI.GR>; Fri, 29 Sep 1995 18:04:43 EET Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr (4.1/SMI-4.1) id AA02454; Fri, 29 Sep 95 18:08:36 +0200 Date: Fri, 29 Sep 1995 18:08:34 +0200 (EET) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: Question on adding flavors to ld In-reply-to: from "Fred Fish" at Sep 29, 95 08:46:04 am To: fnf@amigalib.com (Fred Fish) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@theseas.softlab.ece.ntua.gr Message-id: <9509291608.AA02454@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 1179 > For example, given flavors -f m68030 and -f m68881 your example above > would be: > > -L/gnu/lib/gcc-lib/m68030/m68881 -L/gnu/lib/gcc-lib/m68030 -L/gnu/lib/gcc-lib Actually, it would be more something like: -L/gnu/lib/gcc-lib/m68030/m68881 -L/gnu/lib/gcc-lib/m68020/m68881 -L/gnu/lib/gcc-lib/m68881 -L/gnu/lib/gcc-lib/m68030 -L/gnu/lib/gcc-lib/m68020 -L/gnu/lib/gcc-lib/m68010 (why not?) -L/gnu/lib/gcc-lib and this is one of the most complicated cases. I don't think the number of combinations is 2**N. In fact, we only need to figure out the correct -L path sequence for the following 8 combinations: 68000, 68010, 68020, 68020+68881, 68030, 68030+68881, 68040, 68040+68881, (the last one would only search two more paths than the example for a 68030+68881). If we take into consideration -resident and -ixemul, we end up with a not unmanageable total of 32 combinations. Even if we add support for the 68060, the number of combinations is 64. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Claims of superiority I always find extremely boring. There's always someone better--except in my case, of course." ----- From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 19:31:00 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <89875-4>; Fri, 29 Sep 1995 19:06:38 +0200 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 29 Sep 95 18:00:01 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <215ff51c.u8t20e.3251a-robert@plukwa.lodz.pdi.net> Subject: crt0.o: Undef symbol ___SaveSP??? Reply-To: robert@lodz.pdi.net Content-Length: 2977 To: amiga-gcc-port@nic.funet.fi Date: Fri, 29 Sep 95 18:00:01 Hi all! Can someone tell me whats going on? I was happily compiling for quite some time. And after that suddenly came this: gcc -v -O2 -m68020-40 -mstackextend -s -o gzip gzip.o zip.o deflate.o trees.o bits.o unzip.o inflate.o util.o crypt.o lzw.o unlzw.o unpack.o unlzh.o getopt.o Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/specs gcc version 2.7.0 ld -fl libm020 -o gzip -s /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0 -L/local/lib/gcc-lib/mc68020-cbm-amigados/2.7.0 -L/gnu/lib -L/local/lib -L/local/lib gzip.o zip.o deflate.o trees.o bits.o unzip.o inflate.o util.o crypt.o lzw.o unlzw.o unpack.o unlzh.o getopt.o -lgcc -lc -lamiga -lc -lgcc /gnu/lib/crt0.o: Undefined symbol ___SaveSP referenced from text segment /gnu/lib/crt0.o: Undefined symbol ___init_stk referenced from text segment trees.o: Undefined symbol ___sub_0_sp_f referenced from text segment trees.o: Undefined symbol ___sub_0_sp_f referenced from text segment trees.o: Undefined symbol ___sub_0_sp_f referenced from text segment trees.o: Undefined symbol ___sub_d0_sp_f referenced from text segment trees.o: Undefined symbol ___sub_d0_sp_f referenced from text segment trees.o: Undefined symbol ___sub_0_sp_f referenced from text segment trees.o: Undefined symbol ___sub_0_sp_f referenced from text segment trees.o: Undefined symbol ___sub_d0_sp_f referenced from text segment trees.o: Undefined symbol ___sub_0_sp_f referenced from text segment trees.o: Undefined symbol ___sub_0_sp_f referenced from text segment trees.o: Undefined symbol ___sub_0_sp_f referenced from text segment trees.o: Undefined symbol ___sub_0_sp_f referenced from text segment trees.o: More undefined symbol ___sub_0_sp_f refs follow unzip.o: Undefined symbol ___sub_d0_sp_f referenced from text segment inflate.o: Undefined symbol ___link_a5_d0_f referenced from text segment inflate.o: Undefined symbol ___sub_d0_sp_f referenced from text segment inflate.o: Undefined symbol ___link_a5_d0_f referenced from text segment inflate.o: Undefined symbol ___link_a5_d0_f referenced from text segment inflate.o: Undefined symbol ___link_a5_d0_f referenced from text segment unlzw.o: Undefined symbol ___sub_d0_sp_f referenced from text segment unlzh.o: Undefined symbol ___sub_d0_sp_f referenced from text segment getopt.o: Undefined symbol ___sub_d0_sp_f referenced from text segment make: *** [gzip] Error 1 I compared crt0.o from my GNU tree and crt0.o from distribution and they are identical. Any ideas? desperated Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 20:00:18 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90384-4>; Fri, 29 Sep 1995 19:59:53 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id TAA29670 at Fri, 29 Sep 1995 19:59:47 +0200 Received: by softlab.ece.ntua.gr with UUCP id UAA28006 at Fri, 29 Sep 1995 20:04:22 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <08fh@kriton.UUCP>; Fri, 29 Sep 95 19:49:37 EET Date: Fri, 29 Sep 95 19:49:37 EET Message-Id: <9509291749.08fh@kriton.UUCP> In-Reply-To: <215faed6.u8t20e.7b3aa-robert@plukwa.lodz.pdi.net> (from theseas!plukwa.lodz.pdi.net!robert (Robert Ramiega)) (at Fri, 29 Sep 95 13:00:10) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 756 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!lodz.pdi.net!robert@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: CON: <-> RAW: how?? Hi Robert (Robert Ramiega), in <215faed6.u8t20e.7b3aa-robert@plukwa.lodz.pdi.net> on Sep 29 you wrote: > I have one question. How to switch Amiga shell window between CON: and > RAW:? (using GCC of course) #include BOOL SetMode(BPTR fh, LONG mode) fh: filehandle mode: the new mode you want (1=RAW:, 0=CON:) This only works in 2.0+. If you need it for 1.3, you have to send an ACTION_SCREEN_MODE packet to the console handler. (I think I have some code to do this, if you are interested.) I hope this helps, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "When everything is new, can anything be a surprise?" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 20:31:07 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90507-4>; Fri, 29 Sep 1995 20:30:31 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sykD0-0004nZC; Fri, 29 Sep 95 11:30 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Question on adding flavors to ld To: kyrimis@theseas.softlab.ece.ntua.gr Date: Fri, 29 Sep 1995 11:30:54 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <9509291608.AA02454@hpcl.cti.gr> from "Kriton Kyrimis" at Sep 29, 95 06:08:34 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1685 > and this is one of the most complicated cases. I don't think the number of > combinations is 2**N. In fact, we only need to figure out the correct -L path Yes, given N flavors the total number of possible combinations is 2**N. That isn't necessarily the number of *reasonable* combinations, just the number that need to be sorted through to find the reasonable ones. I.E., given 4 flavors, called A, B, C, and D, construct a table as follows: A B C D Storage Directory - - - - ----------------- 0 0 0 0 /gnu/lib/gcc-lib/ 0 0 0 1 /gnu/lib/gcc-lib/D 0 0 1 0 /gnu/lib/gcc-lib/C 0 0 1 1 /gnu/lib/gcc-lib/C/D 0 1 0 0 /gnu/lib/gcc-lib/B 0 1 0 1 /gnu/lib/gcc-lib/B/D 0 1 1 0 /gnu/lib/gcc-lib/B/C 0 1 1 1 . 1 0 0 0 . 1 0 0 1 . 1 0 1 0 1 0 1 1 1 1 0 0 1 1 0 1 1 1 1 0 1 1 1 1 > sequence for the following 8 combinations: 68000, 68010, 68020, 68020+68881, > 68030, 68030+68881, 68040, 68040+68881, (the last one would only search two > more paths than the example for a 68030+68881). If we take into consideration > -resident and -ixemul, we end up with a not unmanageable total of 32 > combinations. Even if we add support for the 68060, the number of > combinations is 64. You are talking about an implementation that makes assumptions about the relationships between the flavors and assumes a specific number of flavors. I'm considering how to build a general purpose, possibly table driven mechanism that allows for an arbitrary number of flavors and arbitrary relationships between those flavors. It should be possible to add a flavor by doing nothing more than adding a few libraries and updating a table or dependency list somewhere. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Sep 29 20:43:31 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90059-2>; Fri, 29 Sep 1995 20:42:59 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0sykOl-0004nZC; Fri, 29 Sep 95 11:43 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: utils for gcc2.7.0 To: robert@lodz.pdi.net Date: Fri, 29 Sep 1995 11:43:02 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi, fnf@amigalib.com (Fred Fish) In-Reply-To: <215fe847.u8t20e.63cd8-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Sep 29, 95 05:05:14 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1651 > I just want to let You know that I'm slowly recompiling varius GNU utils > with gcc2.7.0. > Right now i've recompiled sh-utils 1.12, findutils 4.1, fileutils 3.12, > gawk 2.15.6 and make 3.71 Please share any problems you find so that fixes can be merged back into my source tree if necessary. This is a useful exercise and establishes that other people can independently compile the entire GNU tree. > All the sources where taken from FreshFish CD-ROM mounted in Aachen. I Which CD? FreshFish 10 has the latest source base, in gnu-src/amiga. > didnt change a bit in them i've just recomplied them with gcc2.7.0 using > -mstackextend and -m68020-40. Due to the last option the binareis are usable > only to those who have 68020+ and 68881. You should do a 3-stage build to ensure that what you have compiled is stable. You should compile and install *all* the utils in each stage: makedir build1 cd build1 sh /src/gnu/configure -v m68k-cbm-amigados make make install cd .. makedir build2 cd build2 sh /src/gnu/configure -v m68k-cbm-amigados make cd .. diff -r build1 build2 (if the same, you can quit here) cd build2 make install cd .. makedir build3 cd build3 sh /src/gnu/configure -v m68k-cbm-amigados make cd .. diff -r build2 build3 (if not the same, you are in big trouble!) > When I'll finish this pass i recompile all this again to create 68000 > binaries for all the rest. This should get you the same binaries as on FreshFish 10. > Ps. > I did it mainly because i didn't have anything better to do and i thought > it might be usable to somebody else Cool. We can use all the help we can get... -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Sep 30 05:45:40 1995 Received: from unixg.ubc.ca ([137.82.27.14]) by nic.funet.fi with SMTP id <90880-4>; Sat, 30 Sep 1995 05:43:49 +0200 Received: from interchg.ubc.ca (warrenvw@interchg.ubc.ca [137.82.27.42]) by unixg.ubc.ca (8.6.12/8.6.12) with SMTP id UAA26704 for ; Fri, 29 Sep 1995 20:43:42 -0700 Date: Fri, 29 Sep 1995 20:43:40 -0700 (PDT) From: Warren Van Winckel X-Sender: warrenvw@interchg.ubc.ca To: GCC Subject: A 'stupid' question about Regex Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am having trouble with strings still. I have noticed that the default setting for end of input (using cin) is whitespace (and tab, return...). How do I 'undefine' the whitespace in the REGEX definition 'RXwhite'? I want the definition to read, "= [\n\t\r\v\f]+" NOT "= [ \n\t\r\v\f]+". Thanks for any help in advance, Warren ^(===)^ -----------------------------oOO--(_)--OOo----------------------------- Warren Van Winckel | The reasonable man adapts himself to the world warrenvw@unixg.ubc.ca | the unreasonable one persists in trying to ----------------------| adapt the world to himself. Therefore, all What's with the crazy | progress depends on the unreasonable man. creature on the fence?| -- George Bernard Shaw ----------------------------------------------------------------------- http://www.science.ubc.ca/departments/sci1/ ----------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Sat Sep 30 10:42:20 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89977-4>; Sat, 30 Sep 1995 10:41:37 +0200 Received: by colombo.telesys-innov.fr; Sat, 30 Sep 1995 09:40:44 GMT From: Philippe BRAND Message-Id: <199509300940.JAA08481@colombo.telesys-innov.fr> Subject: Re: utils for gcc2.7.0 To: robert@lodz.pdi.net Date: Sat, 30 Sep 1995 09:40:43 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <215fe847.u8t20e.63cd8-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Sep 29, 95 05:05:14 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 887 Robert Ramiega writes: > I just want to let You know that I'm slowly recompiling varius GNU utils > with gcc2.7.0. Cool. > In a couple of days i'll also recomplie diffutils 2.7, flex 2.4.7, gzip > 1.2.4 and tar 1.11.2 and maybe a few others. Cool. > I put it this evening on plukwa.lodz.pdi.net in /amiga/gnu/utils that what > i have already compiled for those interested in it. If you can please put them also on my site. I thought I'd have time to build 270 utils archive for Aminet distribution, but baby is taking too much time as for now. Perhaps somebody, you for example, can build this archive for Aminet distribution. Just note that you have to recompile newest tools. make is now at 3.74. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sat Sep 30 12:36:23 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90576-3>; Sat, 30 Sep 1995 12:35:10 +0200 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sat, 30 Sep 95 11:29:04 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <2160eaf8.u8t20e.5280d-robert@plukwa.lodz.pdi.net> Subject: Re: utils for gcc2.7.0 In-Reply-To: <199509300940.JAA08481@colombo.telesys-innov.fr> (from Philippe BRAND ) (at Sat, 30 Sep 1995 09:40:43 +0000 (WET)) Reply-To: robert@lodz.pdi.net Content-Length: 2505 To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@nic.funet.fi Date: Sat, 30 Sep 95 11:29:04 On Sep 30 Philippe BRAND wrote: > Robert Ramiega writes: > > > I just want to let You know that I'm slowly recompiling varius GNU utils > > with gcc2.7.0. > > Cool. > > > In a couple of days i'll also recomplie diffutils 2.7, flex 2.4.7, gzip > > 1.2.4 and tar 1.11.2 and maybe a few others. > > Cool. Well not that cool, there is something wrong with my gcc since i can't compile anything right now (i've posted about it yesterday). I would realy be glad if someone would solve my problem cause this stopped me in the dead field. I'm not in to reinstalling whole gcc because i would then need to reinstall amitcp-gcc and a couple of other things which i put into my gcc tree. > > > I put it this evening on plukwa.lodz.pdi.net in /amiga/gnu/utils that what > > i have already compiled for those interested in it. Actually i put that as gcc270-utilsRobert.lha in /amiga/gnu. Sorry > > If you can please put them also on my site. I was thinking about that but I wanted to upload to Your site something more complete. > I thought I'd have time to build 270 utils archive for Aminet distribution, > but baby is taking too much time as for now. Dont have to tell me i'm a proud father of 10 months old daughter (and because of her i took my amiga to work, so i could actually use it). And since i didnt said that earlier than i do it now: CHEEERS!!!!!! AND CONGRATULATIONS!!!!! > Perhaps somebody, you for example, can build this archive for Aminet > distribution. I can do that as soon as my compiler will be functionig again > Just note that you have to recompile newest tools. make is now at 3.74. Ok, i'll search for the news versions. If You could show me some host which keeps most recent versions of GNU utils this would speed me up (preferably in Scandinavia because of nature of Polish Internet connections) > > -- > Philippe BRAND > phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB > AmigaDOS GNU Project, AmigOS Net/WWW coordinator. > http://www.telesys-innov.fr/about/PhB.html > regards, Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Sat Sep 30 13:42:30 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <90436-3>; Sat, 30 Sep 1995 13:40:17 +0200 Received: from lysistrate.lysator.liu.se (lysistrate.lysator.liu.se [130.236.254.161]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id MAA22203; Sat, 30 Sep 1995 12:40:07 +0100 Received: (nisse@localhost) by lysistrate.lysator.liu.se (8.6.11/8.6.11) id MAA00485; Sat, 30 Sep 1995 12:40:04 +0100 Date: Sat, 30 Sep 1995 12:40:04 +0100 Message-Id: <199509301140.MAA00485@lysistrate.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: robert@lodz.pdi.net CC: phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi In-reply-to: <2160eaf8.u8t20e.5280d-robert@plukwa.lodz.pdi.net> Subject: Re: utils for gcc2.7.0 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) > Ok, i'll search for the news versions. If You could show me some > host which keeps most recent versions of GNU utils this would speed > me up (preferably in Scandinavia because of nature of Polish > Internet connections) Try ftp.isy.liu.se:/pub/gnu They mirror all gnu stuff, and are located in Linköping, Sweden. From amiga-gcc-port-owner@nic.funet.fi Sat Sep 30 14:00:33 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90579-4>; Sat, 30 Sep 1995 13:58:04 +0200 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sat, 30 Sep 95 12:49:05 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <2160fdba.u8t20e.4b3f-robert@plukwa.lodz.pdi.net> Subject: Re: utils for gcc2.7.0 In-Reply-To: <199509301140.MAA00485@lysistrate.lysator.liu.se> (from Niels M|ller ) (at Sat, 30 Sep 1995 12:40:04 +0100) Reply-To: robert@lodz.pdi.net Content-Length: 506 To: nisse@lysator.liu.se Cc: phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi Date: Sat, 30 Sep 95 12:49:05 On Sep 30 Niels M|ller wrote: > From: robert@plukwa.lodz.pdi.net (Robert Ramiega) > > > Ok, i'll search for the news versions. If You could show me some > > host which keeps most recent versions of GNU utils this would speed > > me up (preferably in Scandinavia because of nature of Polish > > Internet connections) > > Try ftp.isy.liu.se:/pub/gnu > > They mirror all gnu stuff, and are located in Linköping, Sweden. > Thanks very much!! This should give me the sources resonably fast. > Robert From amiga-gcc-port-owner@nic.funet.fi Sat Sep 30 14:09:29 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90866-2>; Sat, 30 Sep 1995 14:07:39 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id OAA08648 at Sat, 30 Sep 1995 14:05:32 +0200 Received: by softlab.ece.ntua.gr with UUCP id OAA13741 at Sat, 30 Sep 1995 14:10:03 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <08g2@kriton.UUCP>; Sat, 30 Sep 95 14:03:25 EET Date: Sat, 30 Sep 95 14:03:25 EET Message-Id: <9509301203.08g2@kriton.UUCP> In-Reply-To: (from theseas!amigalib.com!fnf (Fred Fish)) (at Fri, 29 Sep 1995 11:30:54 -0700 (MST)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 2244 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!amigalib.com!fnf@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: Question on adding flavors to ld Hi Fred (Fred Fish), in on Sep 29 you wrote: > You are talking about an implementation that makes assumptions about the > relationships between the flavors and assumes a specific number of flavors. > > I'm considering how to build a general purpose, possibly table driven > mechanism that allows for an arbitrary number of flavors and arbitrary > relationships between those flavors. It should be possible to add a flavor > by doing nothing more than adding a few libraries and updating a table > or dependency list somewhere. Silly me, I only thought we were interested in finding a way to tell ld how to link with the appropriate libraries depending on CPU/FPU type and compilation model. Quite frankly, apart from the interest one might find in coding what you propose per se, I don't see what is the need of dealing with flavors. What is a flavor, anyway? If it is CPU/FPU type+compilation model, as I assume it is, by the time we add rules to the flavor implementation such as: "you can't have FPU code with the 68000", I'm sure we'll end up with the 32 cases I outlined yesterday, except that we will have done it by implementing and debugging a totally new mechanism that is not part of the official GNU distribution, instead of using the already existing mechanism of the specs file. On the other hand, if the concept of flavors refers to something else, (e.g, apart from CPU/FPU type and compilation model, we start adding things like combinations of optimization flags, stack checking/extension, and what have you), then the specs file approach would certainly become too complicated to handle. On the other hand, again, I doubt if we really need this sort of thing. If there exist people who keep that many versions of the link libraries, they are the exception, not the rule, and are probably much better off if they specify what libraries they need by hand, using explicit -L commands in their Makefiles. Thanks for bearing with me, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I suppose you could call it an invasion. I prefer to see it as active immigration." ----- From amiga-gcc-port-owner@nic.funet.fi Sat Sep 30 19:09:07 1995 Received: from elixir.e.kth.se ([130.237.48.5]) by nic.funet.fi with SMTP id <90235-4>; Sat, 30 Sep 1995 19:07:53 +0200 Received: from zafir.e.kth.se (zafir.e.kth.se [130.237.48.6]) by elixir.e.kth.se (8.6.8.1/8.6.6) with ESMTP id SAA20337 for ; Sat, 30 Sep 1995 18:07:37 +0100 Received: (e90_dny@localhost) by zafir.e.kth.se (8.6.8.1/8.6.6) id SAA10930; Sat, 30 Sep 1995 18:07:37 +0100 Message-Id: <199509301707.SAA10930@zafir.e.kth.se> From: To: amiga-gcc-port@nic.funet.fi Subject: How do I unsubscribe? Date: Sat, 30 Sep 1995 18:07:36 +0100 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: DennyĊ berg ^-illegal control character How do I unsubscribe? I tried to mail 'listserv@listserv.funet.fi' with 'SIGNOFF amiga-gcc-port' in body, but the listserver reply with > SIGNOFF amiga-gcc-port No LISTSERV list by the name of "AMIGA-GCC-PORT" is known to exist. Note that lists can be marked "confidential" and that the existence of such lists is usually known only to the server that is actually hosting it. From amiga-gcc-port-owner@nic.funet.fi Sun Oct 1 16:03:51 1995 Received: by nic.funet.fi id <89023-3>; Sun, 1 Oct 1995 16:00:13 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <95Oct1.160013+0200_eet.89023-3+51@nic.funet.fi> Date: Sun, 1 Oct 1995 16:00:02 +0200 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Sun Oct 1 19:29:27 1995 Received: from gate1.informatik.fh-wiesbaden.de ([193.175.36.254]) by nic.funet.fi with SMTP id <89016-2>; Sun, 1 Oct 1995 19:28:29 +0200 Received: from sun.informatik.fh-wiesbaden.de (sun15.informatik.fh-wiesbaden.de) by gate1.informatik.fh-wiesbaden.de with SMTP id AA02923 (5.65c/IDA-1.4.4 for ); Sun, 1 Oct 1995 18:27:56 +0100 Received: from sun01.informatik.fh-wiesbaden.de by sun.informatik.fh-wiesbaden.de (4.1/fhw-FBI_sun-Nl) id AA09284; Sun, 1 Oct 95 18:27:53 +0100 From: i511@informatik.fh-wiesbaden.de (Stefan Ruppert) Message-Id: <9510011727.AA09284@sun.informatik.fh-wiesbaden.de> Subject: Re: crt0.o: Undef symbol ___SaveSP??? To: robert@lodz.pdi.net Date: Sun, 1 Oct 1995 18:27:52 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <215ff51c.u8t20e.3251a-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Sep 29, 95 06:00:01 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1269 > > Hi all! > Can someone tell me whats going on? I was happily compiling for quite some > time. And after that suddenly came this: > gcc -v -O2 -m68020-40 -mstackextend -s -o gzip gzip.o zip.o deflate.o trees.o bits.o unzip.o inflate.o util.o crypt.o lzw.o unlzw.o unpack.o unlzh.o getopt.o > > Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/specs > gcc version 2.7.0 > ld -fl libm020 -o gzip -s /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0 -L/local/lib/gcc-lib/mc68020-cbm-amigados/2.7.0 -L/gnu/lib -L/local/lib -L/local/lib gzip.o zip.o deflate.o trees.o bits.o unzip.o inflate.o util.o > crypt.o lzw.o unlzw.o unpack.o unlzh.o getopt.o -lgcc -lc -lamiga -lc -lgcc > /gnu/lib/crt0.o: Undefined symbol ___SaveSP referenced from text segment > /gnu/lib/crt0.o: Undefined symbol ___init_stk referenced from text segment I have posted this question two weeks ago and after some search's I can't find a libc.a compiled for mc68020. Not in the gcc270-inclib.lha nor in ixemul archive. Has someone compiled this library and from which source tree ? Ciao Stefan -- Home: Stefan Ruppert Windthorststrasse 5 65439 Floersheim am Main GERMANY EMail: i511@informatik.fh-wiesbaden.de ruppert@gundel.zdv.uni-mainz.de From amiga-gcc-port-owner@nic.funet.fi Sun Oct 1 21:03:27 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <89319-1>; Sun, 1 Oct 1995 21:02:49 +0200 Received: by colombo.telesys-innov.fr; Sun, 1 Oct 1995 20:02:07 GMT From: Philippe BRAND Message-Id: <199510012002.UAA12177@colombo.telesys-innov.fr> Subject: Re: crt0.o: Undef symbol ___SaveSP??? To: i511@informatik.fh-wiesbaden.de (Stefan Ruppert) Date: Sun, 1 Oct 1995 20:02:06 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9510011727.AA09284@sun.informatik.fh-wiesbaden.de> from "Stefan Ruppert" at Oct 1, 95 06:27:52 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 508 Stefan Ruppert writes: > I have posted this question two weeks ago and after some search's I can't > find a libc.a compiled for mc68020. Not in the gcc270-inclib.lha nor in > ixemul archive. Has someone compiled this library and from which source > tree ? It should have come with gcc. You can find one in ixemul distribution. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sun Oct 1 23:30:34 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90549-2>; Sun, 1 Oct 1995 23:29:56 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0szVy0-0004nZC; Sun, 1 Oct 95 14:30 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Question on adding flavors to ld To: kyrimis@softlab.ece.ntua.gr Date: Sun, 1 Oct 1995 14:30:35 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: <9509301203.08g2@kriton.UUCP> from "Kriton Kyrimis" at Sep 30, 95 02:03:25 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2615 > we will have done it by implementing and debugging a > totally new mechanism that is not part of the official GNU distribution, Ah, but getting it accepted (or at least presenting it to the GNU community) as part of the official GNU distribution is certainly one of the motivations for "doing it right" rather than just hacking up gcc to implement what amounts to a customized amiga only library lookup scheme. This is a general problem, which I have seen attacked a couple of different ways on other systems. The first time I saw something like this (using a hierarchy of libraries) was on a Unix system about 10 years ago. In that implementation, the algorithm was hardcoded into the compiler front end and turned out to be only marginally useful, particularly when you wanted to use the linker without accessing it through the front end. That is one reason why the implementation needs to be in the linker itself. > if the concept of flavors refers to something else, (e.g, apart > from CPU/FPU type and compilation model, we start adding things like > combinations of optimization flags, stack checking/extension, and what have > you), then the specs file approach would certainly become too complicated to > handle. Exactly. At some point we will have a working debugger and want to compile things both with and without the -g option. I'm not sure how useful it would be to have libraries compiled with flags that differ only by whether they use -O, -O2, -O3, etc, but we should not dismiss that simply because we don't see a current need. We could say the same thing about almost any other compiler option. > On the other hand, again, I doubt if we really need this sort of > thing. If there exist people who keep that many versions of the link > libraries, they are the exception, not the rule Just because there might be 32 "reasonable" combinations out of 1024, or maybe 64, or maybe only 2, doesn't mean that you have to actually have a library for each combination. And you should be able to pick an choose which library you might want more combinations. I.E. you might decide to only compile 4 different flavors of the 32 combinations for libm, but all 32 of libc. And if you decide you don't want all 32 of libc available, you should be able to delete all but 2, or 4, or whatever you decide to keep. > Thanks for bearing with me, No problem. I'll make a serious effort to start some sort of document that can be used as a basis for further discussion, and possibly implementation, sometime in the next couple weeks. I'm seriously overloaded with other stuff at the moment. -Fred From amiga-gcc-port-owner@nic.funet.fi Sun Oct 1 23:47:12 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89968-4>; Sun, 1 Oct 1995 23:46:44 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0szWDw-0004nZC; Sun, 1 Oct 95 14:47 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: utils for gcc2.7.0 To: nisse@lysator.liu.se (Niels M|ller) Date: Sun, 1 Oct 1995 14:47:04 -0700 (MST) Cc: robert@lodz.pdi.net, phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi In-Reply-To: <199509301140.MAA00485@lysistrate.lysator.liu.se> from "Niels M|ller" at Sep 30, 95 12:40:04 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 745 > > Ok, i'll search for the news versions. If You could show me some > > host which keeps most recent versions of GNU utils this would speed > > me up (preferably in Scandinavia because of nature of Polish > > Internet connections) > > Try ftp.isy.liu.se:/pub/gnu > > They mirror all gnu stuff, and are located in Link=F6ping, Sweden. I wouldn't recommend starting with the FSF archives or you may find your project turning into a full time job for the next few months. It took me many months to assemble the current source tree that is used to generate the GNU utils on FreshFish CD's, starting from the FSF archives and carefully either adding existing patches from other random sources or generating my own amiga specific changes. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Oct 2 09:36:35 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90832-3>; Mon, 2 Oct 1995 09:35:14 +0200 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HVYKNJ6J9S90X6ES@LEON.CTI.GR>; Mon, 2 Oct 1995 09:33:54 EET Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr (4.1/SMI-4.1) id AA06210; Mon, 2 Oct 95 09:37:58 +0200 Date: Mon, 02 Oct 1995 09:37:55 +0200 (EET) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: Question on adding flavors to ld In-reply-to: from "Fred Fish" at Oct 1, 95 02:30:35 pm To: fnf@amigalib.com (Fred Fish) Cc: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9510020737.AA06210@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 2818 > of the motivations for "doing it right" rather than just hacking up > gcc to implement what amounts to a customized amiga only library > lookup scheme. My point was that *no* hacking up is necessary. > years ago. In that implementation, the algorithm was hardcoded into > the compiler front end and turned out to be only marginally useful, > particularly when you wanted to use the linker without accessing it > through the front end. That is one reason why the implementation > needs to be in the linker itself. This is certainly an argument in favor of not doing something with the specs file. On the other hand, apart from the unix kernel, I haven't seen any other programs using cc/gcc that invoke the linker directly. > Exactly. At some point we will have a working debugger and want to > compile things both with and without the -g option. I'm not sure how This is certainly something very valid. (Add to that profiling, as well.) > Just because there might be 32 "reasonable" combinations out of 1024, > or maybe 64, or maybe only 2, doesn't mean that you have to actually > have a library for each combination. And you should be able to pick > an choose which library you might want more combinations. I.E. you > might decide to only compile 4 different flavors of the 32 > combinations for libm, but all 32 of libc. And if you decide you > don't want all 32 of libc available, you should be able to delete all > but 2, or 4, or whatever you decide to keep. Compiling fewer versions than the number of possible combinations is no problem with the -L approach either. It isn't even necessary for the directories specified in the -L option to exist. One argument in your favor is that I wrote a specification for calling the linker with the correct -L options, and it turned out pretty big. One (lame) argument in my favor was that writing the file was pretty much a cut-and-paste job. > No problem. I'll make a serious effort to start some sort of document > that can be used as a basis for further discussion, and possibly > implementation, sometime in the next couple weeks. I'm seriously > overloaded with other stuff at the moment. Perhaps, after reading the document, I'll volunteer to implement it. Just to change the subject lightly, while writing the specs I saw several amiga-specific options: -shortdata, -data-bss-together, and -data-data(something). (Some of these are required for -noixemul, and some for -resident and/or -fbaserel). If these have not been implemented for the binutils linker, I think it that implementing them should have a higher priority than flavors. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I've been threatened by *experts*. You know, Cybermen, Ice Warriors, Daleks, BBC producers..." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Oct 2 11:07:10 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <90701-2>; Mon, 2 Oct 1995 11:06:22 +0200 Received: by tycho.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 2 Oct 1995 10:02:32 +0100 (MET) From: Rask Lambertsen To: e90_dny@elixir.e.kth.se Cc: amiga-gcc-port@nic.funet.fi Subject: Re: How do I unsubscribe? In-Reply-To: <199509301707.SAA10930@zafir.e.kth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 30 Sep 1995 e90_dny@elixir.e.kth.se wrote: > How do I unsubscribe? > I tried to mail 'listserv@listserv.funet.fi' with 'SIGNOFF amiga-gcc-port' ^^^^^^^^ Try 'mailserver', I'm sure it'll work much better then :-) Unfortunately, the GCC 2.7.0 README states 'listserv' instead of 'mailserver'. > in body, but the listserver reply with > SIGNOFF amiga-gcc-port > No LISTSERV list by the name of "AMIGA-GCC-PORT" is known to exist. Note > that lists can be marked "confidential" and that the existence of such lists > is usually known only to the server that is actually hosting it. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Oct 2 11:54:51 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90415-4>; Mon, 2 Oct 1995 11:54:14 +0200 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Mon, 2 Oct 95 10:48:10 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <21638465.u8t20e.7adeb-robert@plukwa.lodz.pdi.net> Subject: Re: crt0.o: Undef symbol ___SaveSP??? In-Reply-To: <9510011727.AA09284@sun.informatik.fh-wiesbaden.de> (from i511@informatik.fh-wiesbaden.de (Stefan Ruppert)) (at Sun, 1 Oct 1995 18:27:52 +0100 (MET)) Reply-To: robert@lodz.pdi.net Content-Length: 2100 To: i511@informatik.fh-wiesbaden.de Cc: amiga-gcc-port@nic.funet.fi Date: Mon, 2 Oct 95 10:48:10 On Oct 1 Stefan Ruppert wrote: > > > > Hi all! > > Can someone tell me whats going on? I was happily compiling for quite some > > time. And after that suddenly came this: > > gcc -v -O2 -m68020-40 -mstackextend -s -o gzip gzip.o zip.o deflate.o trees.o bits.o unzip.o inflate.o util.o crypt.o lzw.o unlzw.o unpack.o unlzh.o getopt.o > > > > Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/specs > > gcc version 2.7.0 > > ld -fl libm020 -o gzip -s /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0 -L/local/lib/gcc-lib/mc68020-cbm-amigados/2.7.0 -L/gnu/lib -L/local/lib -L/local/lib gzip.o zip.o deflate.o trees.o bits.o unzip.o inflate.o util.o > > crypt.o lzw.o unlzw.o unpack.o unlzh.o getopt.o -lgcc -lc -lamiga -lc -lgcc > > /gnu/lib/crt0.o: Undefined symbol ___SaveSP referenced from text segment > > /gnu/lib/crt0.o: Undefined symbol ___init_stk referenced from text segment > > I have posted this question two weeks ago and after some search's I can't > find a libc.a compiled for mc68020. Not in the gcc270-inclib.lha nor in > ixemul archive. Has someone compiled this library and from which source > tree ? I dont know how it looks on Your Amy. But I was hapily compiling just 30 mins before i got that message. In fact on that day I did compiled findutils and fileutils and than i came to compliling gzip and BOOM! I think I reinstall the gcc package today =o( > > Ciao > Stefan > > -- > Home: Stefan Ruppert > Windthorststrasse 5 > 65439 Floersheim am Main > GERMANY > > EMail: > i511@informatik.fh-wiesbaden.de > ruppert@gundel.zdv.uni-mainz.de > regards, Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Oct 2 14:47:41 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90446-4>; Mon, 2 Oct 1995 14:44:56 +0200 Received: from ernie.icslab.agh.edu.pl (kiskra@ernie.icslab.agh.edu.pl [149.156.98.14]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id MAA08354 for ; Mon, 2 Oct 1995 12:44:28 GMT Content-Transfer-Encoding: 8bit Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA03077; Mon, 2 Oct 1995 13:45:58 +0100 Date: Mon, 2 Oct 1995 13:45:57 +0100 (MET) From: Kamil Iskra Subject: Re: Problem with os-includes To: joop van de wege cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 27 Sep 1995, joop van de wege wrote: > Hi All Again, > > I tried to compile XPM lib which I'm testing for someone and found a problem > with UtilityBase. Have a look at the following output from gcc270 -v [part of the output deleted] > GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. > /gnu/os-include/inline/utility.h: In function `AddNamedObject': > In file included from /gnu/os-include/proto/utility.h:6, > from bitmapiclass.c:16: > /gnu/os-include/inline/utility.h:28: warning: initialization from > incompatible pointer type [part of the output deleted] > /gnu/os-include/proto/utility.h: At top level: > In file included from bitmapiclass.c:16: > /gnu/os-include/proto/utility.h:9: conflicting types for `UtilityBase' > /gnu/os-include/inline/utility.h:21: previous declaration of `UtilityBase' > > In 'inline/utility.h' the declaration of UtilityBase was changed from struct > Library *UtilityBase to struct UtilityBase *UtilityBase. > > When I changed it back to 'Library' the source compiled without error. > > Can anyone comment on why it was changed. There is a comment in > inline/utility.h but no name. You must have some very strange "inlines". In the ones I found in GCC-2.7.0 archive everything is correct with UtilityBase - it's declared as "struct UtilityBase*" both in "proto/utility.h" and "inline/utility.h". There is no comment in "inline/utility.h", either (it would be strange if there was one, since this file was generated automatically). I think that current declaration is a good one, cause that's actually what "UtilityBase" is. The fact that "struct Library*" would work well, too, doesn't change this fact. There was a bug and it was fixed. BTW: while working on "fd2inline" (C parser for FD-files) I came across a bug in declaration of "RexxSysLib" in "proto/rexxsyslib.h" (and in "inline/rexxsyslib.h" too, but that's not important for me since I use my own inlines). It is declared as "struct Library*", while it should be "struct RxsLib*". I think the same applies to "DiskBase" (is "struct Node*", should be "struct DiskResource*"). Can somebody (Gunther?) fix this? > Joop / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Oct 2 15:00:01 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90824-1>; Mon, 2 Oct 1995 14:57:47 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HVYTW4COY8009I59@NET2.WAU.NL>; Mon, 02 Oct 1995 13:58:53 +0000 (GMT) Received: by vines2.wau.nl; Mon, 2 Oct 95 13:57:39 +0100 Date: Mon, 02 Oct 1995 13:51:59 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: Problem with os-includes To: kiskra@ernie.icslab.agh.edu.pl Cc: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >> In 'inline/utility.h' the declaration of UtilityBase was changed from >> struct >> Library *UtilityBase to struct UtilityBase *UtilityBase. >> >> When I changed it back to 'Library' the source compiled without error. >> >> Can anyone comment on why it was changed. There is a comment in >> inline/utility.h but no name. >You must have some very strange "inlines". In the ones I found in >GCC-2.7.0 archive everything is correct with UtilityBase - it's declared I too have installed everything from GCC-2.7.0. Will have alook if my archives contain this for sure. >I think that current declaration is a good one, cause that's actually what >"UtilityBase" is. The fact that "struct Library*" would work well, too, >doesn't change this fact. There was a bug and it was fixed. The guy I'm beta testing for uses SAS/C 6.5x, but he never (should check that) declares UtilityBase because he's using the autolibrary opening from SAS. There might be something else happening. UtilityBase is probably declared struct *Library somewhere in the utility.h files. My includes are V40 from FredFish CD. Joop From amiga-gcc-port-owner@nic.funet.fi Mon Oct 2 16:20:41 1995 Received: from chx400.switch.ch ([130.59.1.2]) by nic.funet.fi with ESMTP id <90453-2>; Mon, 2 Oct 1995 16:13:00 +0200 Received: from isbiel.ch (actually sunny.isbiel.ch) by chx400.switch.ch with SMTP (PP); Mon, 2 Oct 1995 15:09:44 +0100 Received: from odis.isbiel.ch by isbiel.ch (4.1/SMI-4.1.e) id AA02570; Mon, 2 Oct 95 15:09:36 +0100 Received: from ODIS/SpoolDir by odis.isbiel.ch (Mercury 1.21); 2 Oct 95 15:09:40 +200 Received: from SpoolDir by ODIS (Mercury 1.21); 2 Oct 95 15:09:28 +200 From: BOOS CHRISTOPH 1994M1B Organization: Biel School of Engineering To: amiga-gcc-port@lists.funet.fi Date: Mon, 2 Oct 1995 15:09:23 MET DST Subject: rounding problem / IO stream redirection Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <23DBCDC0AB4@odis.isbiel.ch> hi just as a general info: the problem i postet some time ago (you remember? '(int)3.7' becomes '4' ...) is finally fixed. it seems that the version of ixemul.library (41.1) which comes with the aminet gnu-archive (2.7.0) has still the double2int conversion bug. i installed the newest version (41.3) from aminet and now all works fine! or could it be possible that the library, distributed with gcc, doesn't fit to every machine? the ixemul-archive from aminet offers several different versions (020, 020fpu, 030, 030fpu etc.) but the gcc-archive contents only one. should this one (if it were the newest version) work with every machine? unfortunately i have yet another problem. i'm trying to start gcc in GoldEd using a arexx-script and Golded-Dock. in the dock.prefs file this looks something like this: ... EXEC "rx MyRexxScript.rexx >KCON:0/0/640/... " in MyRexxScript.rexx gcc will be started with all its options: /* arexx-script */ ... runstring = 'gcc -v -o prg prg.c' address command runstring ... My problem is that the outputs gcc creates (-v) doesn't appear on my console window. I tried also in a normal shell to redirect the gcc output: gcc -v -o prg prg.c >KCON:0/0/640/... but the output appeared still on the shell and not on the new console window. it seems that '>' redirects only the output stream and not the error stream. (and gcc outputs come on the error stream, right?) so, what can i do? greetings Christoph From amiga-gcc-port-owner@nic.funet.fi Mon Oct 2 16:24:49 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90566-2>; Mon, 2 Oct 1995 16:21:17 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0szljj-0004nYC; Mon, 2 Oct 95 07:20 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: utils for gcc2.7.0 To: robert@lodz.pdi.net Date: Mon, 2 Oct 1995 07:20:54 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: <21638ae9.u8t20e.e5506-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Oct 2, 95 11:16:00 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3693 > I dont get one thing. How compiling let's say findutils can affect compilation > of another utils??? IMHO this shouldn't change a thing. I mean what possible > impact can have instalation of newer binary command on the way GCC produces > executable. I can understand the 3 passes when building GCC. every time it gets > compiled with another complier, but with utils??? The interrelationships can sometimes be subtle so it's not real easy to give concise examples. Suppose for example you compile a new version of sed and stick it in your binary directory. Suppose this new binary of sed has a latent bug that only appears if you use a particular regular expression, and that this latent bug was introduced because of some other unspecified change somewhere. Had you diffed the object tree for sed against a previous build, you would have spotted the fact that some object file was different and probably wanted to know why. Then suppose that you go to compile binutils, and as part of the build process, the Makefile runs sed on some piece of source code that becomes part of the assembler, and this bug in sed introduces a bug in the assembler but that this bug only shows up when assembling a particular floating point instruction, which just happens to never be used in the assembler binary. Thus you can 3-stage just the binutils tree and get to a stable state where the assembler never changes again and everything will appear fine, but the bug is still there. Then with this new assembler, you recompile gcc, again 3 staging, and again reaching a stable state without ever using this particular floating point instruction. You install gcc, thinking all is well. You then go to compile GNU fortran, and as part of compiling the runtime library, the assembler gets the particular floating point instruction and misassembles it. Now your GNU fortran library is subtly busted, but you still don't know it because the GNU fortran library is not actually used as part of building GNU fortran. You install GNU fortran. Then you go to compile octave, which links with the new buggy GNU fortran library and when you run octave on its test suite, you suddenly find that several tests fail. Tracking this bug all the way back to sed is not going to be very easy, while if you had done a complete compile of all the tools prior to installing anything, and diffed that tree with a previous generation of objects from the same source, you would have immediately noticed that one file in the sed tree is different. Because you had not yet installed it, you also would not have propogated the bug to the assembler, fortran runtime, and ultimately octave and who knows wherever else. Now sure, this is a contrived example, but it is not too far off from some of the bugs I had to chase in the beginning before I started doing complete builds of everything before installing anything. Now whenever I see an unexpected change in any object file in the tree, particularly just one or two files, I always make sure I know why those files have changed before proceeding. Sometimes a compiler change will affect a large number of objects and all you can do is proceed to the next stage build/install cycle and hope you reach a stable state of the entire tree without anything blowing up. Usually you do, but sometimes not, and have to regress back to an earlier state. There is no complete guarantee that once you reach a stable state that there aren't still bugs (in fact it is guaranteed that there *are* bugs unless you believe every bug has been found), just that there are no bugs that will prevent you from being able to build any other piece of the complete environment. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Oct 2 18:29:51 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90032-4>; Mon, 2 Oct 1995 18:25:08 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26462-2>; Mon, 2 Oct 1995 17:23:30 +0100 Received: from hphalle6j.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395394-2>; Mon, 2 Oct 1995 17:23:21 +0100 Subject: Re: Problem with os-includes From: Christian Stieber To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Mon, 2 Oct 1995 17:23:11 +0100 (MEZ) Cc: kiskra@ernie.icslab.agh.edu.pl, amiga-gcc-port@lists.funet.fi In-Reply-To: from "joop van de wege" at Oct 2, 95 01:51:59 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 845 Message-Id: <95Oct2.172321+0100mesz.395394-2+360@hphalle0.informatik.tu-muenchen.de> [ struct UtilityBase *UtilityBase; ] > There might be something else happening. UtilityBase is probably declared > struct *Library somewhere in the utility.h files. Library bases are not defined in die C= includes, as far as I remember (I don't have the clib/ directory here). utility/utility.h defines struct UtilityBase { struct Library ub_LibNode; UBYTE ub_Language; UBYTE ub_Reserved; }; If clib/utility_protos.h declares it as "extern struct Library *UtilityBase" it should be considered buggy. But I don't think clib/#?h declares library bases. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Mon Oct 2 18:38:39 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90357-3>; Mon, 2 Oct 1995 18:35:12 +0200 Received: from uther.fee.unicamp.br (root@uther.fee.unicamp.br [143.106.14.217]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id QAA14524 for ; Mon, 2 Oct 1995 16:33:02 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: (from maestro@localhost) by uther.fee.unicamp.br (8.6.12/8.6.12) id NAA10385 for amiga-gcc-port@nic.funet.fi; Mon, 2 Oct 1995 13:30:17 -0300 Date: Mon, 2 Oct 1995 13:30:17 -0300 From: Rafael Lorandi de Oliveira Message-Id: <199510021630.NAA10385@uther.fee.unicamp.br> To: amiga-gcc-port@nic.funet.fi Subject: unsubscribe unsubscribe maestro@fee.unicamp.br From amiga-gcc-port-owner@nic.funet.fi Mon Oct 2 18:39:27 1995 Received: from specklec.mpifr-bonn.mpg.de ([134.104.20.3]) by nic.funet.fi with SMTP id <90028-1>; Mon, 2 Oct 1995 18:35:30 +0200 Received: from spcklh.mpifr-bonn.mpg.de (spcklh.mpifr-bonn.mpg.de [134.104.20.11]) by specklec.mpifr-bonn.mpg.de (8.6.10/8.6.9) with ESMTP id RAA09977 for ; Mon, 2 Oct 1995 17:33:05 +0100 From: Gerd Schniggenberg Received: (gs@localhost) by spcklh.mpifr-bonn.mpg.de (8.6.9/8.6.9) id RAA07098 for amiga-gcc-port@nic.funet.fi; Mon, 2 Oct 1995 17:33:04 +0100 Message-Id: <199510021633.RAA07098@spcklh.mpifr-bonn.mpg.de> Subject: inet.library, resident, 80bit floats To: amiga-gcc-port@nic.funet.fi Date: Mon, 2 Oct 95 17:33:03 MET DST X-Mailer: ELM [version 2.2 PL14] Hello! 1. While compiling snoopdos shows gcc(as,ln..) try to open inet.library five times. What is this library? I haven't found anything about it in the docs. 2. Why is gcc not compiled with the -resident option? I think it isn't, because there are no pure flags set and trying to make gcc resident, there were strange compiler errors. Which files should made resident? gcc,ln,as? 3. Amiga gcc has no support for 80 bit floats. When I had a look on some old Sun 3 workstations, I was astonished to see gcc 2.5.8 with support of 80 bit floats. I looked in the includes and tested a program. I thought the source for all M68k machines was quite the same and there were only patches for amiga specific features. Perhabs there is a 80 bit float support only includes missing. Have a look to the following program, which calculates the smallest number different from 1.0 when added to 1.0. #include int main(void) { long double a,e; e=0.5L; a=1.0L+e; while (a>1.0) { e*=0.5L; a=1.0L+e; } e*=2.0L; printf("precision: %.2Le\n",e); } Compiling without optimisation you get: "precision: 2.22e-16" When I use: gcc genau.c -o genau -noixemul -m68030 -m68881 -O2 -lm -s "precision: 1.08e-19" The code sent to the assembler is: fmoved #0r0.5,fp1 fmovex fp1,fp3 fmovecr #0x32,fp2 L8: fmulx fp3,fp1 fmovex fp1,fp0 faddx fp2,fp0 fcmpx fp2,fp0 fjgt L8 faddx fp1,fp1 You see all calculations are done with extended floats. Without optimisation the FPU registers are not used for all variables, so they must bt stored in memory. Amiga GCC uses only 8 Bytes to store even long doubles, so you loose precision. I think all we need is to tell gcc that sizeof(long double)=10. This can be done with the help of the Sun gcc. Of course the includes have to be changed too, but they can be taken from the Sun gcc. Gerd -- From amiga-gcc-port-owner@nic.funet.fi Mon Oct 2 18:49:10 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90667-2>; Mon, 2 Oct 1995 18:45:40 +0200 Received: from uther.fee.unicamp.br (uther.fee.unicamp.br [143.106.14.217]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id QAA14773 for ; Mon, 2 Oct 1995 16:45:10 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: (from maestro@localhost) by uther.fee.unicamp.br (8.6.12/8.6.12) id NAA10385 for amiga-gcc-port@nic.funet.fi; Mon, 2 Oct 1995 13:30:17 -0300 Date: Mon, 2 Oct 1995 13:30:17 -0300 From: Rafael Lorandi de Oliveira Message-Id: <199510021630.NAA10385@uther.fee.unicamp.br> To: amiga-gcc-port@nic.funet.fi Subject: unsubscribe unsubscribe maestro@fee.unicamp.br From amiga-gcc-port-owner@nic.funet.fi Tue Oct 3 12:37:16 1995 Received: from torga.ci.uminho.pt ([193.136.16.251]) by nic.funet.fi with SMTP id <90661-2>; Tue, 3 Oct 1995 11:59:20 +0200 Received: from caeiro.ci.uminho.pt by torga.ci.uminho.pt (5.4.1/140.2) id AA29928; Tue, 3 Oct 1995 10:59:41 +0200 Received: by caeiro.ci.uminho.pt (5.4R2.10/200.1.1.4) id AA01904; Tue, 3 Oct 1995 10:59:29 +0100 From: si215603@ci.uminho.pt (Luis Antonio F.Alves) Message-Id: <9510030959.AA01904@caeiro.ci.uminho.pt> Subject: Modems info To: amiga-gcc-port@nic.funet.fi (gcc) Date: Tue, 3 Oct 1995 10:59:28 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 433 I have a ZOOM 14400 v32bis and v42bis , v42 by RPI can anyone tell somesofware to use this modem with RPI. Thanks Luis Alves __________________________________________________________________________ Luis Antonio Ferreira Alves L.E.S.I. Universidade do Minho email: si215603@ci.uminho.pt Portugal, Europe http://wwwAlu.ci.uminho.pt:8888/~si215603/ _________________________________________________________________________ From amiga-gcc-port-owner@nic.funet.fi Tue Oct 3 12:37:18 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90941-4>; Tue, 3 Oct 1995 11:31:01 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HW00YZN180009XQB@NET2.WAU.NL>; Tue, 03 Oct 1995 10:32:02 +0000 (GMT) Received: by vines2.wau.nl; Tue, 3 Oct 95 10:31:13 +0100 Date: Tue, 03 Oct 1995 10:27:20 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: Problem with os-includes To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >[ struct UtilityBase *UtilityBase; ] > >> There might be something else happening. UtilityBase is probably declared >> struct *Library somewhere in the utility.h files. I think I still have the gcc263 includes installed, the inlines/pragmas/proto/ that is. The date on the files in the inline directory is 22-sep-94. How that has happened I don't know but it is probably the cause of the problem I had. Is there someone on the list who is still using gcc263 who can check this out. Anyhow it seems solved now. Sorry for the trouble, I should have looked more carefully at what I was using. Joop From amiga-gcc-port-owner@nic.funet.fi Tue Oct 3 23:18:33 1995 Received: from linux.quebec.berclain.com ([199.45.69.110]) by nic.funet.fi with SMTP id <90390-2>; Tue, 3 Oct 1995 23:09:41 +0200 Received: from legue.quebec.berclain.com (legue.quebec.berclain.com [204.19.38.3]) by linux.quebec.berclain.com (8.6.11/8.6.12) with ESMTP id RAA08890 for ; Tue, 3 Oct 1995 17:12:45 -0400 Received: from wntyp ([204.19.38.30]) by legue.quebec.berclain.com (8.6.12/8.6.12) with SMTP id RAA06796 for ; Tue, 3 Oct 1995 17:15:43 -0400 Message-Id: <199510032115.RAA06796@legue.quebec.berclain.com> X-Sender: yanickp@hp800.berclain.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Oct 1995 17:09:41 -0400 To: amiga-gcc-port@nic.funet.fi From: Yanick Pelletier Subject: Help with debug! Since SAS is no more supported (and it's lack of some features in C++) i've decide to move to gcc. After writing some code i realized that i don't have any debugger!!! Does it exist some debugger that i can use with GCC (i prefered free one). Thank! ------------------------------------------------------------------ Yanick Pelletier Berclain Group Inc. (R&D Group) E-mail: pelletiery@berclain.com 979, de Bourgogne (suite 220) Tel : (418) 656-0055 ext. 1735 Sainte-Foy (Quebec) Canada Fax : (418) 654-0645 G1W 2L4 From amiga-gcc-port-owner@nic.funet.fi Wed Oct 4 00:42:03 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90621-2>; Wed, 4 Oct 1995 00:38:09 +0200 Received: from baird.cs.strath.ac.uk (actually user mmdf@baird.cs.strath.ac.uk) by funet.fi with SMTP (PP); Wed, 4 Oct 1995 00:37:59 +0200 Received: from lister-05.cs.strath.ac.uk by baird.cs.strath.ac.uk id aa21079; 3 Oct 95 23:36 +1000 From: nbc@cs.strath.ac.uk Date: Tue, 3 Oct 95 23:36:32 BST Message-Id: <9510032236.AA00816@lister-05.cs.strath.ac.uk> Date-Received: Tue, 3 Oct 95 23:36:32 BST To: amiga-gcc-port@nic.funet.fi subscribe amiga-gcc-port Neil Clark From amiga-gcc-port-owner@nic.funet.fi Wed Oct 4 00:53:56 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90824-4>; Wed, 4 Oct 1995 00:50:28 +0200 Received: from ns.neckar-alb.de (actually host ns.s-1.de.contrib.net user root@ns.s-1.de.contrib.net) by funet.fi with SMTP (PP); Wed, 4 Oct 1995 00:50:21 +0200 Received: from wiedmann.neckar-alb.de (wiedmann@wiedmann.neckar-alb.de [194.77.119.253]) by ns.neckar-alb.de (8.6.9/8.6.9) with ESMTP id XAA13560; Tue, 3 Oct 1995 23:49:22 +0100 Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id XAA00134; Tue, 3 Oct 1995 23:49:46 +0100 From: wiedmann Message-Id: <199510032249.XAA00134@wiedmann.neckar-alb.de> Subject: Re: Help with debug! To: pelletiery@berclain.com (Yanick Pelletier) Date: Tue, 3 Oct 1995 23:49:45 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199510032115.RAA06796@legue.quebec.berclain.com> from "Yanick Pelletier" at Oct 3, 95 05:09:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 387 > > Since SAS is no more supported (and it's lack of some features in C++) i've > decide to move to gcc. After writing some code i realized that i don't have > any debugger!!! > > Does it exist some debugger that i can use with GCC (i prefered free one). AFAIK there's only one choice: BarFly. (Aminet, dev/asm) Note, that you must compile with "-g -gstabs" to use BarFly. Jochen From amiga-gcc-port-owner@nic.funet.fi Wed Oct 4 03:30:50 1995 Received: from hookomo.aloha.net ([204.94.112.33]) by nic.funet.fi with SMTP id <90613-2>; Wed, 4 Oct 1995 03:28:04 +0200 Received: (from newsham@localhost) by hookomo.aloha.net (8.6.12/8.6.9) id PAA24987 for amiga-gcc-port@nic.funet.fi; Tue, 3 Oct 1995 15:28:03 -1000 From: Timothy Newsham Message-Id: <199510040128.PAA24987@hookomo.aloha.net> Subject: GCC2.7.x and mmu To: amiga-gcc-port@nic.funet.fi Date: Tue, 3 Oct 1995 15:28:02 -1000 (HST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1197 Ok, I have a program here that shows something is definitely not right with the MMU handling. This program loads the MMU's crp register into memory, and then loads that memory back into the crp. A null operation right? Well it crashes the machine when it loads the crp. When I comment out the loading into the crp it works fine. The value that gets loaded to memory is shown to be zero (assuming its getting loaded to the proper address). Can someone verify this? Anyone have explanations on why this is messed up? Btw.. this is 68030 code.. should work ok on 020's with mmus too. compile with "-m68030". Tim N. ----- asm(" .text .even .globl _asm_start, _storage _asm_start: asm_start: moveml a5-a6, sp@- movl 4, a6 | SysBase lea start_super, a5 | address to run in super mode jsr a6@(-0x1e) | Supervisor() movl a0, d0 moveml sp@+, a5-a6 rts start_super: lea pc@(_storage), a3 | a3 is address of storage pmove crp, a3@ pmove a3@, crp | comment me to stop crashes rte _storage: .even .long 0 .long 0 "); main() { extern int storage; asm_start(); printf("%x\n", storage); } From amiga-gcc-port-owner@nic.funet.fi Wed Oct 4 14:19:58 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90060-4>; Wed, 4 Oct 1995 14:16:13 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HW1L1MPIY800AL9P@NET2.WAU.NL>; Wed, 04 Oct 1995 13:17:37 +0000 (GMT) Received: by vines2.wau.nl; Wed, 4 Oct 95 13:17:00 +0100 Date: Wed, 04 Oct 1995 13:07:11 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: 020/030/etc CPU checking Startupcode To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi All, I have been thinking about adding some checking code to the startupcode of Libnix since there is none. My thoughts was to add some #ifdef mc68020 at the start of ncrt0.S BUT, I found that if I invoke gcc as follows: gcc -v -m68020 -m68881 -o test test.c that I do get -Dmc68020 and -D__HAVE_68881__ but as soon as I use -m68020-40 then I don't get those defines. Only -Dmc68010, and the assembler is called with mc68020. But I need the preprocessor symbols. How do I get these, or is this a small bug in gcc or the specs file. Matthias/Gunther: Have I started something which is already done or impossible todo ? It seems a useful addition to Libnix to link with special startup code when compiling for a specific cpu/fpu combination. Again more flavors, its a popular topic these days.:) Joop From amiga-gcc-port-owner@nic.funet.fi Wed Oct 4 16:15:46 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90169-3>; Wed, 4 Oct 1995 16:12:42 +0200 Received: from isis.u-strasbg.fr by funet.fi with SMTP (PP); Wed, 4 Oct 1995 16:12:24 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id PAA16631 for ; Wed, 4 Oct 1995 15:05:41 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA16102; Wed, 4 Oct 95 14:56:51 GMT Date: Wed, 4 Oct 95 14:56:51 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9510041456.AA16102@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: HLP: building cross-binutils Hi, I try to build a cross-gcc (irix -> amigados). I have build the cross-compiler et preprocessor, but have big trouble building the cross-assembler and the cross-linker. I use binutils-2.5.2 + binutils-2.5.2-diffs for gas, and binutils-1.8.x + binutils-1.8.x-diffs for ld. But I have trouble with the diff file, patch say that many hunks failed. What's wrong ?? Whitch archive should I use ??? \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Wed Oct 4 17:05:24 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88944-1>; Wed, 4 Oct 1995 17:01:21 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t0VG5-0004nYC; Wed, 4 Oct 95 07:57 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: 020/030/etc CPU checking Startupcode To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Wed, 4 Oct 1995 07:57:21 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "joop van de wege" at Oct 4, 95 01:07:11 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 448 > I have been thinking about adding some checking code to the startupcode of > Libnix since there is none. What would the "checking code" do? Check that the machine it is running on is capable of running this particular flavor of executable (I.E. a 68020 binary on a 68000 machine would put up a requester and exit)? What if someone does: gcc -c -m68020 module.c gcc -o module module.o (thus getting m68000 startup & libraries) -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Oct 4 23:36:01 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <89968-4>; Wed, 4 Oct 1995 23:30:52 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HW24FE6QSW00AV4S@NET2.WAU.NL>; Wed, 04 Oct 1995 22:32:21 +0000 (GMT) Received: by vines2.wau.nl; Wed, 4 Oct 95 22:32:01 +0100 Date: Wed, 04 Oct 1995 22:17:23 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: 020/030/etc CPU checking Startupcode To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >What would the "checking code" do? Check that the machine it is running on >is capable of running this particular flavor of executable (I.E. a 68020 >binary on a 68000 machine would put up a requester and exit)? Exactly. >What if someone does: > gcc -c -m68020 module.c > gcc -o module module.o (thus getting m68000 startup & libraries) Didn't think of that one. I normally use either a makefile of it consists of more that 2 modules or if only one then I use gcc -o test test.c So its impossible ? :( I think that a 'smart' user will find a way to circumvent this problem. I still want this and since I like puzzles I'll probably go on until ..... Joop From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 00:07:29 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90506-1>; Thu, 5 Oct 1995 00:04:28 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t0bwQ-0004nYC; Wed, 4 Oct 95 15:05 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: 020/030/etc CPU checking Startupcode To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Wed, 4 Oct 1995 15:05:29 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "joop van de wege" at Oct 4, 95 10:17:23 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1554 > >What if someone does: > > gcc -c -m68020 module.c > > gcc -o module module.o (thus getting m68000 startup & libraries) > Didn't think of that one. I normally use either a makefile of it consists of > more that 2 modules or if only one then I use gcc -o test test.c One possible way to handle this is to borrow the idea of "init sections" from C++, I.E. the compiler emits code into an output section that is collected by the linker and put into a section that gets run at startup. If the compiler detects that code requiring an fpu is being generated then it emits code into the init section that sets a bit in a global bitfield that an fpu is required. Similarly, if 68040 code is generated, it emits code that sets that bit. The linker gathers up these sections from each object module, concatentates them into an output section with a specific prologue and epilogue, and arranges that the contents gets run at process startup. Actually, the prologue and epilogue come from the init sections in the crt0.o module (linked first) and the crtN.o module (linked last). At process startup, crt0 runs the init section and then checks what bits are set in the global bitfield. From that, it can determine what resources a particular executable requires. Thus there would only be one crt0.o object module, that would be the same for all executables. And if someone generates an executable from object modules that are compiled with different flags, it only takes one module to force the entire executable to some minimum configuration. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 01:38:33 1995 Received: from asimov.cnam.fr ([163.173.128.6]) by nic.funet.fi with SMTP id <90439-1>; Thu, 5 Oct 1995 01:36:04 +0200 Received: from brunner.cnam.fr (brunner.cnam.fr [163.173.128.15]) by asimov.cnam.fr with ESMTP id AAA05840 (8.6.12/ for ); Thu, 5 Oct 1995 00:35:59 +0100 Received: by brunner.cnam.fr id AAA22364 (8.6.12/ for amiga-gcc-port@nic.funet.fi); Thu, 5 Oct 1995 00:35:59 +0100 Received: (from daniel@localhost) by brasil.frmug.fr.net (8.6.12/8.6.12) id AAA07132 for amiga-gcc-port@nic.funet.fi; Thu, 5 Oct 1995 00:03:22 +0100 From: Daniel Verite Message-Id: <199510042303.AAA07132@brasil.frmug.fr.net> Subject: Re: Help with debug! To: amiga-gcc-port@nic.funet.fi Date: Thu, 5 Oct 1995 00:03:22 +0100 (MET) In-Reply-To: <199510032249.XAA00134@wiedmann.neckar-alb.de> from "wiedmann" at Oct 3, 95 11:49:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 616 > > > > > Since SAS is no more supported (and it's lack of some features in C++) i've > > decide to move to gcc. After writing some code i realized that i don't have > > any debugger!!! > > > > Does it exist some debugger that i can use with GCC (i prefered free one). > > AFAIK there's only one choice: BarFly. (Aminet, dev/asm) > > Note, that you must compile with "-g -gstabs" to use BarFly. > > > Jochen > BTW, I'm currently writing a debugger that will fully support gcc debug infos. I hope to be able to release a first version in a couple of months. Hold on ;) Daniel -- daniel@brainstorm.cnam.fr From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 01:38:36 1995 Received: from asimov.cnam.fr ([163.173.128.6]) by nic.funet.fi with SMTP id <90416-2>; Thu, 5 Oct 1995 01:36:25 +0200 Received: from brunner.cnam.fr (brunner.cnam.fr [163.173.128.15]) by asimov.cnam.fr with ESMTP id AAA05838 (8.6.12/); Thu, 5 Oct 1995 00:35:59 +0100 Received: by brunner.cnam.fr id AAA22355 (8.6.12/); Thu, 5 Oct 1995 00:35:58 +0100 Received: (from daniel@localhost) by brasil.frmug.fr.net (8.6.12/8.6.12) id AAA07108; Thu, 5 Oct 1995 00:00:27 +0100 From: Daniel Verite Message-Id: <199510042300.AAA07108@brasil.frmug.fr.net> Subject: Re: GCC2.7.x and mmu To: newsham@aloha.net (Timothy Newsham) Date: Thu, 5 Oct 1995 00:00:27 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199510040128.PAA24987@hookomo.aloha.net> from "Timothy Newsham" at Oct 3, 95 03:28:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1146 Timothy Newsham wrote: > I have a program here that shows something is definitely not > right with the MMU handling. This program loads the MMU's crp > register into memory, and then loads that memory back into the > crp. A null operation right? Well it crashes the machine when > it loads the crp. When I comment out the loading into the crp > it works fine. The value that gets loaded to memory is shown > to be zero (assuming its getting loaded to the proper address). > Can someone verify this? Anyone have explanations on why > this is messed up? You probably get an 'MMU configuration error' exception (number 0x38), since the MMU does some consistency check about the value written to the crp register. Especially, 0 in the first long word is not allowed ! This behavior is due to the fact that AmigaOS does not initialize the MMU unless needed; so the CRP contains garbage, that you can read, but not write. As a quick workaround, you could run your program with enforcer in the background, just to have the MMU properly set before you try to deal with it. Daniel -- daniel@brainstorm.cnam.fr From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 11:02:36 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90064-4>; Thu, 5 Oct 1995 10:59:41 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA11706 (5.65c8/IDA-1.4.4 for ); Thu, 5 Oct 1995 09:59:26 +0100 Received: by diva.gmd.de id AA00708 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Thu, 5 Oct 1995 09:57:05 +0100 Date: Thu, 5 Oct 1995 09:57:05 +0100 From: Joerg Hoehle Message-Id: <199510050857.AA00708@diva.gmd.de> To: amiga-gcc-port@nic.funet.fi Subject: Re: 020/030/etc CPU checking Startupcode joop van de wege writes: > >What if someone does: > > gcc -c -m68020 module.c > > gcc -o module module.o (thus getting m68000 startup & libraries) > I think that a 'smart' user will find a way to circumvent this problem. > I still want this and since I like puzzles I'll probably go on until ..... Go on. Most users probably will be consistent in their use of -m68... options. I hate SW (and people writing such SW) that just crashes because I copied it from my A4000 to my A2000. Checking the correct flags in ExecBase is not difficult at all. Joerg. From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 11:36:56 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90780-3>; Thu, 5 Oct 1995 11:31:46 +0200 Received: by plukwa.pdi.lodz.pl (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Thu, 5 Oct 95 10:28:32 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <2167744c.u8t20e.5561c-robert@plukwa.lodz.pdi.net> Subject: Re: Help with debug! In-Reply-To: <199510042303.AAA07132@brasil.frmug.fr.net> (from Daniel Verite ) (at Thu, 5 Oct 1995 00:03:22 +0100 (MET)) Reply-To: robert@lodz.pdi.net Content-Length: 881 To: daniel@brasil.brainstorm.cnam.fr Cc: amiga-gcc-port@nic.funet.fi Date: Thu, 5 Oct 95 10:28:32 On Oct 5 Daniel Verite wrote: > > BTW, I'm currently writing a debugger that will fully support gcc debug > infos. I hope to be able to release a first version in a couple of months. > Hold on ;) GGRRREEEAAATTT!!!!! If You need an alfa tester than here i'm =o))) I can guarantie that most of us are dying to get their hands on Your production > > Daniel -- daniel@brainstorm.cnam.fr > > Now get to work =o) Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 11:57:41 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90307-4>; Thu, 5 Oct 1995 11:52:24 +0200 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id KAA23003 (8.6.12/IDA-1.6 for ); Thu, 5 Oct 1995 10:51:56 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA21677; Thu, 5 Oct 95 10:51:55 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9510050951.AA21677@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: 020/030/etc CPU checking Startupcode To: amiga-gcc-port@nic.funet.fi Date: Thu, 5 Oct 1995 10:51:55 +0100 (MET) Cc: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1234 > Go on. Most users probably will be consistent in their use of -m68... options. > > I hate SW (and people writing such SW) that just crashes because I > copied it from my A4000 to my A2000. Checking the correct flags in > ExecBase is not difficult at all. > Sure. Getting the right check into the executable is the difficult thing :-). It seems that the best way to implement it is to have a special startup code module for each flavour of the library and if someone wants to merge modules compiled with different options he should set all of them when linking. The check itself could look something like this: #ifdef MC68020 .text cpuchk: ascii "Need at least a 68020 processor\0" #endif #ifdef MC68881 fpuchk: ascii "Need some working 68881/2 FPU\0" #endif [the startup starts, the wb message is processed and a6 gets initialized here] #if defined(MC68020) btst #0,a6@(297) jne cpuok pea cpuchk jbsr ___request addqw #4,sp moveq #20,d0 jra endprog cpuok: #endif #if defined(MC68881) btst #4,a6@(297) jne fpuok pea fpuchk jbsr ___request addqw #4,sp moveq #20,d0 jra endprog fpuok: #endif endprog: [get rid of wb message] The -DMC68020, -DMC68881 flags need to be set when compiling the startup code. Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 12:06:15 1995 Received: from ponyets.dtek.chalmers.se ([129.16.30.83]) by nic.funet.fi with SMTP id <90246-1>; Thu, 5 Oct 1995 12:01:58 +0200 Received: (from d0bucwa@localhost) by ponyets.dtek.chalmers.se (8.6.9/8.6.9) id LAA20698 for amiga-gcc-port@nic.funet.fi; Thu, 5 Oct 1995 11:01:52 +0100 From: Walter Buchebner Message-Id: <199510051001.LAA20698@ponyets.dtek.chalmers.se> Subject: unsubscribe To: amiga-gcc-port@nic.funet.fi Date: Thu, 5 Oct 1995 11:01:51 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 37 unsubscribe d0bucwa@dtek.chalmers.se From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 13:04:14 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <90777-3>; Thu, 5 Oct 1995 13:02:46 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id LAA25915 for ; Thu, 5 Oct 1995 11:56:22 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA19797; Thu, 5 Oct 95 12:01:31 GMT Date: Thu, 5 Oct 95 12:01:31 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9510051201.AA19797@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: Object format for amigados-gcc Hi, what is the object format use by gcc-amigados (coff, elf, aout, ...) ??? \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 13:10:56 1995 Received: from gate1.informatik.fh-wiesbaden.de ([193.175.36.254]) by nic.funet.fi with SMTP id <90899-2>; Thu, 5 Oct 1995 13:09:59 +0200 Received: from sun.informatik.fh-wiesbaden.de (sun15.informatik.fh-wiesbaden.de) by gate1.informatik.fh-wiesbaden.de with SMTP id AA01596 (5.65c/IDA-1.4.4 for ); Thu, 5 Oct 1995 12:09:29 +0100 Received: by sun.informatik.fh-wiesbaden.de (4.1/fhw-FBI_sun-Nl) id AA06285; Thu, 5 Oct 95 12:09:26 +0100 From: i511@informatik.fh-wiesbaden.de (Stefan Ruppert) Message-Id: <9510051109.AA06285@sun.informatik.fh-wiesbaden.de> Subject: Re: 020/030/etc CPU checking Startupcode To: amiga-gcc-port@nic.funet.fi Date: Thu, 5 Oct 1995 12:09:25 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 790 Hi all, I'm writing a startup.library, that provides a one interface for CLI and workbench startup based on ReadArgs() templates. Thus the library can check if the needed processor is there. But at the moment I have only a amiga specific startup entrypoint called SUMain(). The required informations needed by the library function is given in a global TagItem array called startup_tags. So this works only for amiga specific programs, but I think its easy to implement a ANSI-C compatible entry point. I want to release this library next week. Currently I have linkable startup codes for SAS and GCC. Ciao Stefan -- Home: Stefan Ruppert Windthorststrasse 5 65439 Floersheim am Main GERMANY EMail: i511@informatik.fh-wiesbaden.de ruppert@gundel.zdv.uni-mainz.de From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 16:04:42 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90671-4>; Thu, 5 Oct 1995 16:01:51 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HW3310C4LS00B864@NET2.WAU.NL>; Thu, 05 Oct 1995 15:03:18 +0000 (GMT) Received: by vines2.wau.nl; Thu, 5 Oct 95 15:03:21 +0100 Date: Thu, 05 Oct 1995 14:55:55 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: 020/030/etc CPU checking Startupcode To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >> >What if someone does: >> > gcc -c -m68020 module.c >> > gcc -o module module.o (thus getting m68000 startup & libraries) >> Didn't think of that one. I normally use either a makefile of it consists >>of more that 2 modules or if only one then I use gcc -o test test.c >One possible way to handle this is to borrow the idea of "init sections" >from C++, I.E. the compiler emits code into an output section that is >collected by the linker and put into a section that gets run at startup. This means you need to modify the compiler, which is beyond my capabilities, I'm out :( [ very technical stuff deleted] >Thus there would only be one crt0.o object module, that would be the >same for all executables. And if someone generates an executable from >object modules that are compiled with different flags, it only takes >one module to force the entire executable to some minimum >configuration. >-Fred To be honest, it looks like a very elegant solution to me but as I said, I get the general idea but don't ask me to implement it. Do you guys mind if in the meantime I try to get my simple proposal to work ? that is using #ifdef's to generate different crt0.o for different cpu/fpu's. Joop From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 17:03:27 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90058-4>; Thu, 5 Oct 1995 16:58:51 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t0rmO-0004nYC; Thu, 5 Oct 95 08:00 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: 020/030/etc CPU checking Startupcode To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Thu, 5 Oct 1995 08:00:12 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "joop van de wege" at Oct 5, 95 02:55:55 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2150 > To be honest, it looks like a very elegant solution to me but as I said, I > get the general idea but don't ask me to implement it. > > Do you guys mind if in the meantime I try to get my simple proposal to work ? > that is using #ifdef's to generate different crt0.o for different cpu/fpu's. That would be fine, and is certainly better than the current situation of having a single crt0.o that checks nothing. However I just remembered one complication. If what you have in mind is to find these different startups using the currently implemented "flavors" scheme, by having a tree of crt0.o startups like: /gnu/lib/crt0.o /gnu/lib/m68020/crt0.o /gnu/lib/m68020/m68881/crt0.o that won't work, because it is the linker that implements search for the right flavor and it is the gcc front end that selects the crt0.o. So you will have to hardcode the above paths in a much more complicated specs file entry (startfile spec if I recall correctly). The other alternative to to keep them all in /gnu/lib and simply name them differently: /gnu/lib/crt0.o /gnu/lib/crt0-020.o /gnu/lib/crt0-020fpu.o etc. This leads you right back to the situation which cause me to implement flavors in the first place, multiple different flavors of a file in the same directory with semi-cryptic names. Currently linker flavors only works with libraries. To have it work with object files we would need to modify the gcc frontend to emit something like: ld -o j -Scrt0 -L/gnu/lib/gcc-lib/m68k-cbm-amigados/2.7.0 -L/gnu/lib /t/cc1999761.o -lgcc -lc -lamiga -lc -lgcc rather than: ld -o j /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/m68k-cbm-amigados/2.7.0 -L/gnu/lib /t/cc1999761.o -lgcc -lc -lamiga -lc -lgcc and then modify the linker to recognize -Scrt0.o as meaning to lookup an object module using a search mechanism similar to what is used to lookup libc.a when given the option -lc. Perhaps a better solution is to have the linker initialize a flavors variable that is located in crt0.o and which crt0.o then uses at runtime to decide if the system is capable of running this particular executable. That way you only need one crt0.o. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 17:24:15 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90699-2>; Thu, 5 Oct 1995 17:22:39 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Thu, 5 Oct 95 16:20:26 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <2167c6c5.u8t20e.5bd07-robert@plukwa.lodz.pdi.net> Subject: -lgcc In-Reply-To: (from fnf@amigalib.com (Fred Fish)) (at Thu, 5 Oct 1995 08:00:12 -0700 (MST)) Reply-To: robert@lodz.pdi.net Content-Length: 1014 To: amiga-gcc-port@nic.funet.fi Date: Thu, 5 Oct 95 16:20:26 Organization: PDi On Oct 5 Fred Fish wrote: > ld -o j /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/m68k-cbm-amigados/2.7.0 -L/gnu/ >lib /t/cc1999761.o -lgcc -lc -lamiga -lc -lgcc ^^^^ > Does this mean that every progrma linked using gcc is using libgcc.a? How than this affects code generated ie is it covered by GPL or not? It's not that I'm writting anything commercial (I hope i won't have to for a long time =o) but it would be nice to know Robert Ps. As for the utils i slowly compile them as soon as they will be ready i'll let You know about it. +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 17:31:17 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90125-1>; Thu, 5 Oct 1995 17:31:12 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t0sI6-0004nYC; Thu, 5 Oct 95 08:32 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: -lgcc To: robert@lodz.pdi.net Date: Thu, 5 Oct 1995 08:32:57 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <2167c6c5.u8t20e.5bd07-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Oct 5, 95 04:20:26 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 416 > > ld -o j /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/m68k-cbm-amigados/2.7.0 -L/gnu/ > >lib /t/cc1999761.o -lgcc -lc -lamiga -lc -lgcc > ^^^^ > > > Does this mean that every progrma linked using gcc is using libgcc.a? Yes. > How than > this affects code generated ie is it covered by GPL or not? It is not covered by the GPL. The source for libgcc.a is explicitly exempt from the GPL. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 18:25:25 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <90403-2>; Thu, 5 Oct 1995 18:24:21 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id RAA27084; Thu, 5 Oct 1995 17:20:53 +0100 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id RAA19027; Thu, 5 Oct 1995 17:15:46 +0100 Date: Thu, 5 Oct 1995 17:15:46 +0100 From: Niklas Hallqvist Message-Id: <199510051615.RAA19027@linda.appli.se> To: robert@lodz.pdi.net CC: amiga-gcc-port@nic.funet.fi In-reply-to: <2167c6c5.u8t20e.5bd07-robert@plukwa.lodz.pdi.net> Subject: Re: -lgcc libgcc1.c has a special type of copyright. GPL with an addition: In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file with other programs, and to distribute those programs without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into another program.) Niklas From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 22:37:47 1995 Received: from asimov.cnam.fr ([163.173.128.6]) by nic.funet.fi with SMTP id <90640-1>; Thu, 5 Oct 1995 22:36:42 +0200 Received: from brunner.cnam.fr (brunner.cnam.fr [163.173.128.15]) by asimov.cnam.fr with ESMTP id VAA07619 (8.6.12/); Thu, 5 Oct 1995 21:36:36 +0100 Received: by brunner.cnam.fr id VAA11899 (8.6.12/); Thu, 5 Oct 1995 21:36:36 +0100 Received: (from daniel@localhost) by brasil.frmug.fr.net (8.6.12/8.6.12) id VAA03596; Thu, 5 Oct 1995 21:36:19 +0100 From: Daniel Verite Message-Id: <199510052036.VAA03596@brasil.frmug.fr.net> Subject: Re: HLP: building cross-binutils To: papier@indi1.u-strasbg.fr (Laurent Papier) Date: Thu, 5 Oct 1995 21:36:19 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9510041456.AA16102@indi1.u-strasbg.fr> from "Laurent Papier" at Oct 4, 95 02:56:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1156 > Hi, > I try to build a cross-gcc (irix -> amigados). > I have build the cross-compiler et preprocessor, but have big trouble > building the cross-assembler and the cross-linker. > I use binutils-2.5.2 + binutils-2.5.2-diffs for gas, > and binutils-1.8.x + binutils-1.8.x-diffs for ld. > But I have trouble with the diff file, patch say that many hunks failed. > What's wrong ?? > Whitch archive should I use ??? I've setup myself something equivalent for an i486-linux machine, and I also had some trouble with the binutils-1.8.x (got from Phb's ftp site). It seems to me that the diff has been made against the base binutils, whereas the archive is not this base version; it's already patched, but not with the latest version of the patch. (as far as I can see, maybe Philippe or someone else could confirm...) As for 'binutils-2.5.2.diffs', the patch applies all right to the FSF base source-tree. If you intend to use only gas, I'd suggest you configure for the 'm68k-cbm-aout' target instead of 'm68k-cbm-amigados'. At least for me, it gave quite less trouble to compile, especially for include problems. Daniel -- daniel@brainstorm.cnam.fr From amiga-gcc-port-owner@nic.funet.fi Thu Oct 5 23:27:33 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90058-2>; Thu, 5 Oct 1995 23:26:42 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t0xqx-0004nYC; Thu, 5 Oct 95 14:29 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: ixemul 41.4 released To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Thu, 5 Oct 1995 14:29:18 -0700 (MST) Cc: ixemul@listserv.funet.fi (ixemul.library maintainers) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 523 I've uploaded the ixemul 41.4 release to aminet (wuarchive.wustl.edu) and it should start appearing on mirrors shortly. This is mostly a bug fix release. I still have some significant patches to merge, most notably major patches to the stack checking code. This look like they will require some new library offsets, so the version will be bumped to 42.0. If anyone has any other patches that would require adding library offsets please send them in ASAP. I'll expect the 42.0 release to occur in about 4 weeks. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Oct 6 01:28:37 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90875-4>; Fri, 6 Oct 1995 01:27:43 +0200 Received: from k332.feld.cvut.cz (utx@k332.feld.cvut.cz [147.32.192.12]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id XAA08525 for ; Thu, 5 Oct 1995 23:27:37 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: (from utx@localhost) by k332.feld.cvut.cz (8.6.10/8.6.9) id AAA22121 for amiga-gcc-port@nic.funet.fi; Fri, 6 Oct 1995 00:28:14 +0100 Date: Fri, 6 Oct 1995 00:28:14 +0100 From: Stanislav Brabec Message-Id: <199510052328.AAA22121@k332.feld.cvut.cz> To: amiga-gcc-port@nic.funet.fi Subject: about UID, pr_CES and redirection I'm returning to discussion about my mail: getuid, geteuid, setuid, seteuid: there are dummy in ixemul (I think in smallfunc.c). I'm not =o) that's why: Standard Amiga have no uid, that's why without MultiUser these calls cannot be other than dummy or ixemul private. After installing of MU we can talk about better results. AmiTCP system uses NO uid. It have only some login. If you have MultiUser 1.8, your task can have UID & GID, but no EUID & EGID (+U flag changes UID and nests login). If you have MultiUser 2.0 (you certainly have not, it is not released yet), task can have EUID, UID, EGID and GID. But ixemul knows nothing about it. HOME: in MultiUser is evaluated as non-binding assign in time of request, dependently on UID. NON-BINDING assign is standard Amiga's facility. That's why concerning of MultiIUser and ixemul would be nice (and not difficult). Now I will ask MJSoft to get developers version of MultiUser 2.0. It can cooperate with ixemul and libnix. Can me send somebody complete list of dummy/fake.. functions list of ixcalls concerning it. It is certainly #?(e)(g|u)id, maybe something about file owners, login stuff, and... what? No more dummy uid with MultiUser! --- CD .. from root: --------------- According to my August mail: There's simple (Amiga OS based) solution: don't check parent result to zero. Reading Amiga DOS manual CurrentDir(NULL) means CD SYS:!!! --- I have not talking about AmiTCP and their usergroup.library. Yes there are so many passwd files. I hope, new MultiUser would have compatible passwd file, that's why you can (soft)link both. Then would be good time to implement something better: if(multiuserbase) then ....; else return &pw /* dummy */; --- Redirection: Reading Unix Reference manual, there is a way to redirection stderr to stdout: MyCommand < /dev/null > /dev/null 2>&1 & I don't know why, but id not work. Console have been opened until command have finished. But XOper have reported no owner task. (I suppose you have pretty soft link from dev:null to NIL:) --- I Use ix* with MJSoft's DevHandler: it have named consoles and named raw access to media. I have /dev/tty01, /dev/rfd0 (soft link to DevHandler's raw disk) and /dev/fd0 (soft link to DF0:) etc. I recomend it! fixslinks are also useful. --- About ~ True, it's shell's task to understand it. --- A propos: have somebody with faster machine than my A500/A530 already compiled man & friends? Where they are available? -- Stanislav P.S.: Don't be crazy, if you'll get this mail three times. Due to my stupidity, I've been sending this mail permanently to amiga-gcc-port-owner@nic.funet.fi. But I have not obtained loopback mail. - Real programmers don't comment their code. If it was hard to write, it should be hard to read. From amiga-gcc-port-owner@nic.funet.fi Fri Oct 6 11:38:30 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90643-1>; Fri, 6 Oct 1995 11:36:45 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 6 Oct 95 10:34:45 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <2168c73d.u8t20e.49ccc-robert@plukwa.lodz.pdi.net> Subject: Re: ixemul 41.4 released In-Reply-To: (from fnf@amigalib.com (Fred Fish)) (at Thu, 5 Oct 1995 14:29:18 -0700 (MST)) Reply-To: robert@lodz.pdi.net Content-Length: 759 To: fnf@amigalib.com Cc: ixemul@listserv.funet.fi, amiga-gcc-port@nic.funet.fi Date: Fri, 6 Oct 95 10:34:45 Organization: PDi On Oct 5 Fred Fish wrote: > send them in ASAP. I'll expect the 42.0 release to occur in about 4 weeks. Will ixemul 42.0 have support for AmiTCP or this will be implemented later? It's rather vital to me because if 42.0 will have AmiTCP support I will delay one of my projects > > -Fred > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Oct 6 14:22:19 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90089-3>; Fri, 6 Oct 1995 14:21:20 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 6 Oct 95 13:19:29 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <2168eddd.u8t20e.3af13-robert@plukwa.lodz.pdi.net> Subject: Virtual memory exhausted Reply-To: robert@lodz.pdi.net Content-Length: 677 To: amiga-gcc-port@nic.funet.fi Date: Fri, 6 Oct 95 13:19:29 Organization: PDi Hi All! I have TMP: assigned to one of my partitions, i have env variable TMP which points to the same place but still when i compile something GCC uses RAM:T for storing temporary files Can somebody help? Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Oct 6 14:32:09 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90787-2>; Fri, 6 Oct 1995 14:31:26 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 6 Oct 1995 13:27:40 +0100 (MET) From: Rask Lambertsen To: robert@lodz.pdi.net Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Virtual memory exhausted In-Reply-To: <2168eddd.u8t20e.3af13-robert@plukwa.lodz.pdi.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 6 Oct 1995, Robert Ramiega wrote: > Hi All! > > I have TMP: assigned to one of my partitions, i have env variable TMP which > points to the same place but still when i compile something GCC uses RAM:T > for storing temporary files > Can somebody help? setenv TMPDIR somewhere_on_harddisk Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Fri Oct 6 14:41:46 1995 Received: from freenet2.freenet.ufl.edu ([128.227.163.4]) by nic.funet.fi with SMTP id <90330-3>; Fri, 6 Oct 1995 14:41:00 +0200 Received: from dialup48.afn.org by freenet2.freenet.ufl.edu (8.6.12/4.11) id IAA27634; Fri, 6 Oct 1995 08:40:13 -0400 Date: Fri, 6 Oct 1995 08:40:13 -0400 Message-Id: <199510061240.IAA27634@freenet2.freenet.ufl.edu> X-Sender: afn22336@pop3.afn.org X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: amiga-gcc-port@nic.funet.fi From: afn22336@afn.org (Ed Griswold) Subject: unsubscribe unsubscribe afn22336@freenet.ufl.edu From amiga-gcc-port-owner@nic.funet.fi Fri Oct 6 14:42:23 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90438-2>; Fri, 6 Oct 1995 14:41:53 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 6 Oct 95 13:38:29 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <2168f251.u8t20e.9c25a-robert@plukwa.lodz.pdi.net> Subject: Re: Virtual memory exhausted In-Reply-To: (from Rask Lambertsen ) (at Fri, 6 Oct 1995 13:27:40 +0100 (MET)) Reply-To: robert@lodz.pdi.net Reply-To: robert@lodz.pdi.net Content-Length: 1533 To: amiga-gcc-port@nic.funet.fi Date: Fri, 6 Oct 95 13:38:29 Organization: PDi On Oct 6 Rask Lambertsen wrote: > On Fri, 6 Oct 1995, Robert Ramiega wrote: > > > Hi All! > > > > I have TMP: assigned to one of my partitions, i have env variable TMP which > > points to the same place but still when i compile something GCC uses RAM:T > > for storing temporary files > > Can somebody help? > > setenv TMPDIR somewhere_on_harddisk Really?? Here is excerpt from Amiga-GCC-FAQ.txt : A simple try is to do a setenv TMP MyHardDrive:t before compiling. This will create temporary files on the harddisk but this is beta version of FAQ :) Thanks Rask > > Regards, > _________________________________________________________________________ > / \ > | Rask Ingemann Lambertsen , | > | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | > | Keyboard error: and are stuck - press to continue | > \_________________________________________________________________________/ > > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Oct 6 15:03:08 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90399-3>; Fri, 6 Oct 1995 15:01:53 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 6 Oct 95 13:58:51 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <2168f716.u8t20e.e5a7f-robert@plukwa.lodz.pdi.net> Subject: Re: Virtual memory exhausted In-Reply-To: (from Rask Lambertsen ) (at Fri, 6 Oct 1995 13:45:55 +0100 (MET)) Reply-To: robert@lodz.pdi.net Content-Length: 1547 To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Date: Fri, 6 Oct 95 13:58:51 Organization: PDi On Oct 6 Rask Lambertsen wrote: > Please correct it, gcc.guide specifies TMPDIR somewhere. I've checked in the FAQ because i thougth it would be faster to search there. Below i append diff file. so You can aply it to Your copy > I believe that a few UNIX programmes may use /tmp to store temporary > files, so TMP: can be assigned to somewhere on your harddisk in that case. sh uses tmp: > > Should I put this information in the README? BIG YES! > > Regards, > _________________________________________________________________________ > / \ > | Rask Ingemann Lambertsen , | > | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | > | Keyboard error: and are stuck - press to continue | > \_________________________________________________________________________/ > > ------------------------------------------------------------------------------ *** Amiga-GCC-FAQ.txt Fri Oct 6 12:53:03 1995 --- Amiga-GCC-FAQ.txt.bak Thu May 25 08:39:52 1995 *************** *** 1425,1429 **** A simple try is to do a ! setenv TMPDIR MyHardDrive:t before compiling. This will create temporary files on the harddisk and --- 1425,1429 ---- A simple try is to do a ! setenv TMP MyHardDrive:t before compiling. This will create temporary files on the harddisk and ------------------------------------------------------------------------------ regards, Robert From amiga-gcc-port-owner@nic.funet.fi Fri Oct 6 17:23:34 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90384-2>; Fri, 6 Oct 1995 17:19:39 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t1EXr-0004nYC; Fri, 6 Oct 95 08:18 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ixemul 41.4 released To: robert@lodz.pdi.net Date: Fri, 6 Oct 1995 08:18:42 -0700 (MST) Cc: fnf@amigalib.com, ixemul@listserv.funet.fi, amiga-gcc-port@nic.funet.fi In-Reply-To: <2168c73d.u8t20e.49ccc-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Oct 6, 95 10:34:45 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1492 > > send them in ASAP. I'll expect the 42.0 release to occur in about 4 weeks. > Will ixemul 42.0 have support for AmiTCP or this will be implemented later? Probably later. That AmiTCP work is scheduled for after we finish merging some features from an earlier ixemul development branch, and that is going rather slowly right now due to my work overload. At the moment we are trying to avoid introducing large changes into the library, in either the structure of the file tree or the file contents, since those changes also have to be put into the development branch we are merging from in order to avoid introducing additional differences that have to be examined in the merge. Unless someone else steps forward and wants to help with the merging (requires fairly indepth knowledge of ixemul internals and AmigaDOS) then I'm tempted to just suspend merging work, unfreeze the source base, and open it up to these new projects starting at 42.0. If someone in the future wants to continue with the merge, they will have to work with three source bases, the one being merged from (18.47), the last release (42.0) where an attempt was made to keep extraneous differences to a minimum, and whatever the current release is at the time. I.E. they will have to diff 18.47 & 42.0, make changes and test them in 42.0, then apply those patches to the current release and test them there. That is probably better than indefinitely holding up progress waiting for the merge to complete. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Oct 6 22:20:56 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90934-3>; Fri, 6 Oct 1995 22:19:50 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t1JI6-0004nYC; Fri, 6 Oct 95 13:22 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Amiga GNU Tools Project List To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Fri, 6 Oct 1995 13:22:46 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 11745 A M I G A G N U T O O L S P R O J E C T L I S T (Updated 10/6/95) ============= What Is This? ============= This is a list of projects related to maintenance or development of the Amiga GNU tools. This list is currently being maintained by Fred Fish (fnf@amigalib.com). Because of the hard work from a number of members of the Amiga community, we now have a large body of development tools and other packages that have been ported to the Amiga and are available in both source and binary form. We will refer to this software set as "Amiga GNU Tools", partly because it was started as ports of FSF (GNU) tools, and partly because we currently have no better name for it. Although the Amiga GNU Tools started out as ports of tools covered by the GNU General Public License, the GNU Library General Public License, or some code covered by the "Berkeley License", it certainly isn't limited to those. Any package which is available in source is eligible to be part of the Amiga GNU Tools package. One of the goals of the Amiga GNU Tools package is to have a completely self hosting environment. I.E. that everything within it be compilable by the GNU C compiler or other provided compilers. It should be possible for the recipient of these utilities to make whatever changes or bug fixes they want in any piece of code, and then rebuild and use that fixed version (and hopefully send those changes back for integration into future releases). ================ HOW YOU CAN HELP ================ There is an incredible amount of programmer talent available in the Amiga community, with an incalculable amount of hours going into producing demos, freely distributable software, shareware, and other such goodies. If only 1% of that effort could be harnessed to improve the Amiga GNU Tools, we could easily have a standard set of freely available tools that would rival any commercially available tools for the Amiga. You do not have to be an expert AmigaDOS programmer to help. Neither do you have to be an expert in compiler or other software tools technology. All you have to do is be willing to learn and be willing to work in a community effort. As you read this list, look for things that you think are within your capabilities to either work on, or to help test, or even simply to help document. If you think of something interesting that either needs doing by yourself or someone else, send that suggestion to the maintainer of this list. Tackle as big or as small of a project as your skills and available time permits. ======= REWARDS ======= For certain projects we may offer small rewards to the first person or team of persons to complete them. If you can't help with a project, perhaps you or the company you work for can contribute to an award for a specific project. You can pledge an award for any project you wish. ============================================================================ ============================================================================ PROJECT: Finish the binutils 2.5.2 ld port DESCRIPTION Fix the 2.5.2 ld so that we can drop the 1.8.X version. Needs to implement linker flavors the same way as the 1.8.X version (for now) and needs to be able to split reloc sections that exceed 64K relocs, such as happens when linking GNU octave. VOLUNTEERS: REWARD: 5 free Aminet or FreshFish CDs - value $100 - furnished by Amiga Library Services ============================================================================ PROJECT: Integrate binutils 2.5.2 changes into current binutils DESCRIPTION Take the changes that were made in 2.5.2 and work with the maintainers of binutils at cygnus to ensure that those changes will still work in the next release (they currently don't) and also hopefully to get the changes accepted into the master source tree so they don't have to be maintained separately. VOLUNTEERS: REWARD: 5 free Aminet or FreshFish CDs - value $100 - furnished by Amiga Library Services ============================================================================ PROJECT: Upgrade ixtrace. DESCRIPTION: Many of the new functions added to ixemul in versions 40 and 41 aren't traced properly, if at all. Ixtrace.c contains an array with an entry for each function, but it hasn't been updated for quite some time. VOLUNTEERS: REWARD: 2 free Aminet or FreshFish CDs - value $40 - furnished by Amiga Library Services ============================================================================ PROJECT: Test -RESIDENT (-resident with 32-bit offsets) DESCRIPTION An option -flarge-baserel exists in gcc. This is the same as -fbaserel, except that it generates 32 bit offsets, but only on >=68020 CPUs. This would overcome the 64K limit for data. In order to test this all libraries need to be recompiled with this flag. If it works, an option -RESIDENT or -resident32 or whatever should be added to the specs file. VOLUNTEERS: REWARD: 2 free Aminet or FreshFish CDs - value $40 - furnished by Amiga Library Services ============================================================================ PROJECT: Test and possibly fix profiling support. DESCRIPTION Test that the -p option to gcc works and generates profiling code. Also test that any support utils needed to either gather or processes the profiling information work. May be either a small or large job, not sure at this point, which is why someone needs to investigate it. VOLUNTEERS: Robert Ramiega has already offered to do this. REWARD: 2 free Aminet or FreshFish CDs - value $40 - furnished by Amiga Library Services ============================================================================ PROJECT: Replace the current inlines by the new #define-based inlines. DESCRIPTION VOLUNTEERS: REWARD: 2 free Aminet or FreshFish CDs - value $40 - furnished by Amiga Library Services ============================================================================ PROJECT: Cleanup ixemul sources. DESCRIPTION VOLUNTEERS: Hans Verkuil REWARD: 5 free Aminet or FreshFish CDs - value $100 - furnished by Amiga Library Services ============================================================================ PROJECT: Fix latest version of GNU tar. DESCRIPTION Find out why 'cat t.tar.gz | tar xzvf -' fails to work for large archives. VOLUNTEERS: REWARD: 2 free Aminet or FreshFish CDs - value $40 - furnished by Amiga Library Services ============================================================================ PROJECT: Upgrade to the latest pdksh. DESCRIPTION Some work has been done on this, but it doesn't work yet. There are also a couple of documented bugs in pdksh 4.9 that either need to be fixed in 4.9 or else ensure they are fixed in the updated version. * In pdksh 4.9, the built in echo doesn't properly handle args that start with '-', so we have to use GNU echo. * Pdksh 4.9 doesn't properly handle the following, either interactively or in a script file. No warning or error is generated, the elif clause is simply ignored: if test -f foo then echo foo elif test -f bar <--- missing following "then" echo bar fi VOLUNTEERS: REWARD: 5 free Aminet or FreshFish CDs - value $100 - furnished by Amiga Library Services ============================================================================ PROJECT: Port bash. DESCRIPTION Some work has been done on this, on an old version of bash. It compiles but does not run any programs. VOLUNTEERS: REWARD: 5 free Aminet or FreshFish CDs - value $100 - furnished by Amiga Library Services ============================================================================ PROJECT: Add MuFS support to ixemul library DESCRIPTION VOLUNTEERS: ============================================================================ PROJECT: Add networking support to ixemul.library DESCRIPTION Add support for networking to ixemul.library. The support should be general enough that any package can be used (I.E. either AmiTCP or AS225) VOLUNTEERS: Jeff Shepherd REWARD: 5 free Aminet or FreshFish CDs - value $100 - furnished by Amiga Library Services ============================================================================ PROJECT: Implement the chip-keyword in gcc. DESCRIPTION: Some code already exists and it would be wonderful if somebody would take this on. VOLUNTEERS: REWARD: 5 free Aminet or FreshFish CDs - value $100 - furnished by Amiga Library Services ============================================================================ PROJECT: Implement ptrace() in ixemul.library DESCRIPTION Some work has already been done by Leonard and is part of the work of merging older ixemul enhancements into the latest version. VOLUNTEERS: Hans Verkuil REWARD: 10 free Aminet or FreshFish CDs - value $200 - furnished by Amiga Library Services ============================================================================ PROJECT: Finish AmigaDOS gdb port DESCRIPTION Interface to Amiga ptrace() support in ixemul (separate project). Ensure that all command line features work. Ensure that gdb (actually bfd) can read AmigaDOS hunk format, find symbols correctly, etc. Ensure that gdb can properly read either stabs or DWARF II formatted debugging info. VOLUNTEERS: Fred Fish ============================================================================ PROJECT: Write an AmigaDOS GUI for gdb DESCRIPTION Write a GUI for gdb. Gdb already has hooks for GUI's. A good place to start would be to get and examine GDBTK, which is a version of GDB that has a GUI written in TK. Available from ftp.cygnus.com in pub/gdb. VOLUNTEERS: REWARD: 10 free Aminet or FreshFish CDs - value $200 - furnished by Amiga Library Services ============================================================================ PROJECT: Update GNU emacs port to latest release DESCRIPTION Current EMACS ports are based on version 18.59. A port of 19.28 exists but is not stable. First step is to make it stable and make it work, second step is to convert it so that it compiles with GNU C as well as SAS/C. VOLUNTEERS: REWARD: 10 free Aminet or FreshFish CDs - value $200 - furnished by Amiga Library Services ============================================================================ PROJECT: Port ghostview DESCRIPTION VOLUNTEERS: REWARD: 5 free Aminet or FreshFish CDs - value $100 - furnished by Amiga Library Services ============================================================================ PROJECT: AmigaGuide docs DESCRIPTION Modify standard Makefiles so that they generate and install AmigaGuide versions of the documentation, using a version of texinfo that knows how to generate AmigaGuide files. May require first tracking down and integrating texinfo changes to generate AmigaGuide files from texinfo input files. VOLUNTEERS: REWARD: free Aminet or FreshFish CDs, quantity depends upon actual work - furnished by Amiga Library Services ============================================================================ PROJECT: Fold changes back into main source bases DESCRIPTION Many of the changes currently in the Amiga GNU Tools are candidates for being folded back into the main source base for each of the specific tools. You will need to work with the maintainer of each tool to take the current changes and get them folded back into his source tree. Some changes may require complete reworks in order to make them acceptable, and some may be acceptable "as is". VOLUNTEERS: REWARD: free Aminet or FreshFish CDs, quantity depends upon actual work - furnished by Amiga Library Services ============================================================================ From amiga-gcc-port-owner@nic.funet.fi Sat Oct 7 04:12:53 1995 Received: from sxpo.fdn.org ([193.55.4.40]) by nic.funet.fi with SMTP id <89983-4>; Sat, 7 Oct 1995 04:11:39 +0200 Received: (from uucp@localhost) by sxpo.fdn.org (8.6.12/8.6.9) id DAA01099 for lists.funet.fi!amiga-gcc-port; Sat, 7 Oct 1995 03:11:01 +0100 Received: by ramses.fdn.org (V1.17-beta/Amiga) id <1kxh@ramses.fdn.org>; Sat, 7 Oct 95 02:41:25 +0200 Message-ID: <3075cb73@ramses.fdn.org> Date: 06 Oct 95 18:36:03 +0200 Organization: RAMSES BBS (France:1-45845623/53791199/1200) X-Mailer: AmiGate 1.5b (27.9.95) Reply-To: noon@ramses.fdn.org From: noon@ramses.fdn.org (Emmanuel Vacher) To: amiga-gcc-port@nic.funet.fi Subject: So long... o This is a detach announcement brought to you by AreaFixMan. o Ceci est une annonce de départ transmise par AreaFixMan. I am detaching from this area, if there are any important messages, please contact me via netmail at the address below... Je quitte cette aire, si vous voulez me transmettre un message important, contactez moi via netmail à l'adresse ci dessous.... EMail : noon@ramses.fdn.org FIDO : 2:320/104.53 Bye... Au revoir... Emmanuel From amiga-gcc-port-owner@nic.funet.fi Sun Oct 8 20:05:58 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90506-3>; Sun, 8 Oct 1995 20:02:14 +0200 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0t20F2-000RfoC; Sun, 8 Oct 95 19:14 MET Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0t1s4N-000G9gC; Sun, 8 Oct 95 10:30 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <09wb@wyst.hobby.nl>; Sat, 7 Oct 95 22:15:08 CET Message-Id: <9510072115.09wb@wyst.hobby.nl> Date: Sat, 7 Oct 1995 21:15:05 +0000 (CET) Content-Type: text Content-Length: 474 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Subject: New includes Hi all, Who worked on the new inline-includes and where can I get them? I also like to know if there are still problems with these new includes. Thanks in advance, Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Mon Oct 9 10:16:31 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90764-2>; Mon, 9 Oct 1995 10:12:56 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 9 Oct 1995 09:10:33 +0100 (MET) From: Rask Lambertsen To: Fred Fish Cc: Amiga GCC mailing list Subject: Re: Amiga GNU Tools Project List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 6 Oct 1995, Fred Fish wrote: > A M I G A G N U T O O L S > P R O J E C T L I S T > > (Updated 10/6/95) > Thanks for the list. > ============================================================================ > > PROJECT: Fix latest version of GNU tar. > > DESCRIPTION > > Find out why 'cat t.tar.gz | tar xzvf -' fails to work for large archives. > > VOLUNTEERS: > > REWARD: 2 free Aminet or FreshFish CDs - value $40 - furnished > by Amiga Library Services > > ============================================================================ I *think* this one could be caused by a buggy pipe handler. I had this problem with C='s L:Queue-Handler, it simply looses some of the bytes (around 5% sometimes) sent through it. If you haven't tried it already, try something like cat largefile | cat >largefile.after and see if they have the same size or try checksumming them. This is how I found out that C='s pipe handler is buggy. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Oct 9 10:24:03 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90924-4>; Mon, 9 Oct 1995 10:22:03 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 9 Oct 1995 09:19:50 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Diff for inline/dos.h, missing functions Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I found that inline/dos.h (using the preprocessor) misses a few functions: Printf(), FPrintf() and FWritef(). I have hacked these functions together, but I haven't tested them, except for Printf(), which I believe works as it should. *** dos.h.old Mon Oct 9 08:25:19 1995 --- dos.h Mon Oct 9 08:24:55 1995 *************** *** 625,637 **** --- 625,652 ---- LP3(0x162, LONG, VFPrintf, BPTR, fh, d1, STRPTR, format, d2, APTR, argarray, d3, \ struct DosLibrary *, DOSBase) + #ifndef NO_INLINE_STDARGS + #define FPrintf(d1, d2, args...) \ + ({ULONG _args[] = { args }; VPrintf ((d1), (d2), (LONG *) _args);}) + #endif + #define VFWritef(fh, format, argarray) \ LP3NR(0x15c, VFWritef, BPTR, fh, d1, STRPTR, format, d2, LONG *, argarray, d3, \ struct DosLibrary *, DOSBase) + #ifndef NO_INLINE_STDARGS + #define FWritef(d1, d2, args...) \ + ({ULONG _args[] = { args }; VPrintf ((d1), (d2), (LONG *) _args);}) + #endif + #define VPrintf(format, argarray) \ LP2(0x3ba, LONG, VPrintf, STRPTR, format, d1, APTR, argarray, d2, \ struct DosLibrary *, DOSBase) + + #ifndef NO_INLINE_STDARGS + #define Printf(d1, args...) \ + ({ULONG _args[] = { args }; VPrintf ((d1), (LONG *) _args);}) + #endif #define WaitForChar(file, timeout) \ LP2(0xcc, LONG, WaitForChar, BPTR, file, d1, long, timeout, d2, \ Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Oct 9 10:24:50 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90576-2>; Mon, 9 Oct 1995 10:22:57 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 9 Oct 1995 09:20:42 +0100 (MET) From: Rask Lambertsen To: Amiga GNU C mailing list Subject: A few notes on executing UNIX-like programmes Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Yesterday, I came across a difference between ksh quoting and Amiga shell quoting when using awk. Instead of writing awk 'length < 10' S:Startup-Sequence you have to write awk "length < 10" S:Startup-Sequence to get the command executed correctly. I think that this should be put in a FAQ or something as not everybody know how UNIX shells deal with quoting. It is particularily confusing as "awk --help" gives this: Usage: awk [POSIX or GNU style options] -f progfile [--] file ... awk [POSIX or GNU style options] [--] 'program' file ... [option list deleted] where you have to use " instead of ' when specifying 'program'. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Mon Oct 9 12:12:52 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90504-2>; Mon, 9 Oct 1995 12:11:08 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA14533 for ; Mon, 9 Oct 1995 11:09:25 +0100 From: Lars Hecking Message-Id: <199510091013.LAA06588@mostar.nmrc.ucc.ie> Subject: Re: Amiga GNU Tools Project List To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Mon, 9 Oct 1995 11:13:07 +0100 (BST) In-Reply-To: from "Fred Fish" at Oct 6, 95 01:22:46 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2091 > ============================================================================ > > PROJECT: Upgrade to the latest pdksh. > > DESCRIPTION > > Some work has been done on this, but it doesn't work yet. There are > also a couple of documented bugs in pdksh 4.9 that either need to be > fixed in 4.9 or else ensure they are fixed in the updated version. > > * In pdksh 4.9, the built in echo doesn't properly handle args > that start with '-', so we have to use GNU echo. > > * Pdksh 4.9 doesn't properly handle the following, either > interactively or in a script file. No warning or error is > generated, the elif clause is simply ignored: Whoever wants to do some work here, please get in touch with me. I have merged the diffs from 4.9 (and some more stuff) into 5.2.3. It compiles fine and runs mostly ok interactively, but dies on scripts. I believe that fork()/vfork() emulation is incomplete. > ============================================================================ > > PROJECT: Port bash. > > DESCRIPTION > > Some work has been done on this, on an old version of bash. It compiles > but does not run any programs. Same here, bash-1.14.4. I am able to supply a corrected config.sh (the one generated from configure is faulty). As for the pdksh port, some code needs to be written for launching external progs (fork()/vfork() emulation, again). > ============================================================================ > > PROJECT: AmigaGuide docs > > DESCRIPTION > > Modify standard Makefiles so that they generate and install AmigaGuide > versions of the documentation, using a version of texinfo that knows how > to generate AmigaGuide files. May require first tracking down and > integrating texinfo changes to generate AmigaGuide files from texinfo ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > input files. I had a look at the sources for mkguide from Aminet (makeinfo v1.55 based) and makeinfo 1.63 from texinfo-3.6. Merging the diffs into the new version is a _lot_ of work, but doesn't require much Amiga/Unix specific knowledge. From amiga-gcc-port-owner@nic.funet.fi Mon Oct 9 12:36:50 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <90102-1>; Mon, 9 Oct 1995 12:35:31 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id LAA28238 (8.6.12/7.4g-FAU);; Mon, 9 Oct 1995 11:32:28 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA17268; Mon, 9 Oct 1995 12:34:40 +0200 Date: Mon, 9 Oct 1995 12:34:40 +0200 Message-Id: <9510091034.AA17268@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: robert@lodz.pdi.net Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <2168eddd.u8t20e.3af13-robert@plukwa.lodz.pdi.net> Subject: Re: Virtual memory exhausted Hi ! I can do it only from memory but I do: assign t: partition:t and then gcc uses partition:t for temporary files. I use: gcc263 Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Mon Oct 9 13:25:49 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90814-4>; Mon, 9 Oct 1995 13:24:41 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA21574; Mon, 9 Oct 1995 12:26:15 +0100 Date: Mon, 9 Oct 1995 12:26:13 +0100 (MET) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: New includes To: Hans Verkuil cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9510072115.09wb@wyst.hobby.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Sat, 7 Oct 1995, Hans Verkuil wrote: > Who worked on the new inline-includes and where can I get them? I did. > I also like > to know if there are still problems with these new includes. There is one, big problem: they are not supported by g++, cause g++ does not support local functions. I think that the only acceptable solution would be to have two "inline" dirs: say "inline" and "inline++". The first one would contain new format inlines, supported by C, the latter old format, supported by both C and C++. "proto" files would have to be modified to include appropriate header file when compiling in C or C++. I think that a preprocessor define "__USEOLDINLINES__" would also be useful - it would force to use old inline format even when compiling in C. I'm writing about this cause I do not feel senior enough to make such a decision on my own - it is just too important problem. So I would be very glad if other subscribers of this list would comment the above paragraph. I volunteer to make all the necessary changes. Smaller problem is an incompatibility between old and new inlines in handling of library bases. Old format had some special "hacks" which made it possible to have library bases other than "extern struct DosLibrary *DOSBase" etc. New format always refers to base as "DOSBase", "SysBase" etc, but they can now be local variables, preprocessor macros etc. I guess that not many programs used these hacks from old format, one which I'm aware of is "ixemul.library", so it would have to be patched (not a lot of work, I guess - just a few preprocessor macros). This "__USEOLDINLINES__" define would be the easiest, temporary patch for such programs, until they are ported to new format. I have also some debts if these new inlines should be used only when optimizing or always. They work even when no optimizing, but code quality is very poor, much poorer than when using library stubs. On the other hand, new inlines support locale library base (see above), which library stubs do not - so program that uses local library bases would always have to be compiled with -O. On the other hand, that's true for old inlines, too. I'm not sure what to do with this one, so I'm waiting for your advice, too. New inlines are available on my WWW Home Page (see below). I made some changes recently, but this new fixed version is not available publically yet. I'll try to put it tomorrow both on my Home Page and on Philippe's FTP site, I'll also send the detailed list of changes from the last version to this mailing list. This will not be "the last word" about inlines. Still to implement are "narrower lists of clobbered registers" (exec.library/Forbid() etc), "library base in any address register" (math functions from utility.library) and "no memory clobbering" (quite a lot of functions, "tricky" work cause in most cases it's hard to decide how to clasify a function (BTW: thanx to Rask Lambertsen for his help)). Hope I haven't forgot about anything :-). P.S. I apollogise (sp?) to all of you who have sent some articles to this mailing list in a last few days and later got reply from mailserver that I was unreachable. There was simply some problem with e-mails arriving on my server "from outside" and it took administrators 3 days to fix it! > Hans / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Oct 9 13:31:12 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90848-3>; Mon, 9 Oct 1995 13:30:45 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA21786; Mon, 9 Oct 1995 12:32:21 +0100 Date: Mon, 9 Oct 1995 12:32:21 +0100 (MET) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: Diff for inline/dos.h, missing functions To: Rask Lambertsen cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Mon, 9 Oct 1995, Rask Lambertsen wrote: > I found that inline/dos.h (using the preprocessor) misses a few > functions: Printf(), FPrintf() and FWritef(). I have hacked these > functions together, but I haven't tested them, except for Printf(), which > I believe works as it should. [diffs erased] Thanks for your work, Rask. Unfortunatelly, it won't be needed, cause the latest version of fd2inline (will be uploaded tomorrow) generates macros for these functions (and a few other from intuition) automatically. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Oct 9 16:58:43 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <89951-3>; Mon, 9 Oct 1995 16:55:36 +0200 Received: from hpcl.cti.gr by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HW8S2M9VK090VZE3@LEON.CTI.GR>; Mon, 9 Oct 1995 16:54:01 EET Received: by hpcl.cti.gr (4.1/SMI-4.1) id AA28195; Mon, 9 Oct 95 16:58:36 +0200 Date: Mon, 09 Oct 1995 16:58:36 +0200 (EET) From: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Subject: Re: Amiga GNU Tools Project List To: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@theseas.softlab.ece.ntua.gr Message-id: <9510091458.AA28195@hpcl.cti.gr> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 526 > I *think* this one could be caused by a buggy pipe handler. I had this > problem with C='s L:Queue-Handler, it simply looses some of the bytes There is a fixed version of the queue handler on aminet, in file util/sys/HWGQueue.lha. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "It sets such a bad precedent when you start letting the world come to an end every week or so. It seems to erode the confidence people have in their governments for some reason." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Oct 9 18:21:29 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90907-2>; Mon, 9 Oct 1995 18:18:12 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t2Kxb-0004nYC; Mon, 9 Oct 95 09:21 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New includes To: iskra@student Date: Mon, 9 Oct 1995 09:21:51 -0700 (MST) Cc: hans@wyst.hobby.nl, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Oct 9, 95 12:26:13 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1259 > I think that the only acceptable solution > would be to have two "inline" dirs: say "inline" and "inline++". The first > one would contain new format inlines, supported by C, the latter old > format, supported by both C and C++. "proto" files would have to be > modified to include appropriate header file when compiling in C or C++. I > think that a preprocessor define "__USEOLDINLINES__" would also be useful > - it would force to use old inline format even when compiling in C. I think you could probably use the include directory search mechanism here. For example, given a C++ version in gnu:lib/g++include/inline/dos.h and a C version in gnu:os-include/inline/dos.h, g++ will find the C++ version in preference to the C version using the current g++ driver. However, I don't particularly like having the C++ version outside the gnu:os-include tree, so maybe your suggestion of having something like gnu:os-include/old-inline is best. It would probaby be a simply change to have that include directory searched ahead of gnu:os-include/inline for g++ compiles. There should be no need to change any other files. If someone wants the old style for some reason with C they would have to explicitly compile with -I/gnu/os-include/old-inline. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Oct 9 18:43:35 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90184-2>; Mon, 9 Oct 1995 18:41:21 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26482-1>; Mon, 9 Oct 1995 17:40:24 +0100 Received: from hphalle6g.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395718-2>; Mon, 9 Oct 1995 17:40:25 +0100 Subject: Re: New includes From: Christian Stieber To: iskra@student Date: Mon, 9 Oct 1995 17:40:13 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Oct 9, 95 12:26:13 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1371 Message-Id: <95Oct9.174025+0100mesz.395718-2+316@hphalle0.informatik.tu-muenchen.de> > I have also some debts if these new inlines should be used only when > optimizing or always. They work even when no optimizing, but code quality > is very poor, much poorer than when using library stubs. On the other > hand, new inlines support locale library base (see above), which library > stubs do not - so program that uses local library bases would always have > to be compiled with -O. On the other hand, that's true for old inlines, > too. I'm not sure what to do with this one, so I'm waiting for your > advice, too. It is _very_ bad to have different results when compiling with/without optimizing. So, using library stubs when not optimizing means that a program that is written with local library bases cannot be compiled without optimizer. Very bad, especially if you take into account that the optimizer is not generally used while developing & debugging code. IMHO code quality of non-optimized executables does not matter at all; it is much better to have things work the same with/without -O. After all, production code will always be compiled with the optimizer turned on, so why bother? Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Mon Oct 9 19:08:31 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90461-1>; Mon, 9 Oct 1995 19:06:17 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id TAA00273 at Mon, 9 Oct 1995 19:05:41 +0200 Received: by softlab.ece.ntua.gr with UUCP id TAA05231 at Mon, 9 Oct 1995 19:10:26 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <08i9@kriton.UUCP>; Sun, 8 Oct 95 22:08:54 EET Date: Sun, 8 Oct 95 22:08:54 EET Message-Id: <9510082008.08i9@kriton.UUCP> Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 729 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: higher processor version of libc.a I just spent Sunday afternoon (or rather, my amiga did) compiling a version of libc.a and libbc.a for a 68040+68881. Having done this, I wonder if it was worth the trouble: apart from producing slightly smaller executables, is linking with the 68040 version going to yield any performance improvement in addition to using the 68040 version of ixemul.library? -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "My people are very keen to stamp out unlicensed time travel--you can look upon them as galactic ticket inspectors, if you like." "Galactic ticket inspectors?... Oh, I could murder a cup of tea!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Oct 9 19:08:38 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90579-2>; Mon, 9 Oct 1995 19:05:45 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id TAA00262 at Mon, 9 Oct 1995 19:05:19 +0200 Received: by softlab.ece.ntua.gr with UUCP id TAA05201 at Mon, 9 Oct 1995 19:10:03 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <08ie@kriton.UUCP>; Sun, 8 Oct 95 22:15:46 EET Date: Sun, 8 Oct 95 22:15:46 EET Message-Id: <9510082015.08ie@kriton.UUCP> Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 775 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: recompiling ixemul.library I just finished recompiling ixemul.library for a 68040+68881 using the aminet version of gcc 2.7.0. The resulting file is different from the official version: > cmp ixemul.library gnu:libs/ixemul.library ixemul.library gnu:libs/ixemul.library differ: char 110713, line 797 Should this be cause for alarm? BTW, ixemul.trace (at least the 68040+68881 version) was missing from the official distribution. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "My people are very keen to stamp out unlicensed time travel--you can look upon them as galactic ticket inspectors, if you like." "Galactic ticket inspectors?... Oh, I could murder a cup of tea!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 11:07:35 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <90742-2>; Tue, 10 Oct 1995 10:28:12 +0200 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 10 Oct 1995 09:24:08 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Corrections for README-2.7.1 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, The file README-2.7.1 mentions a file called "README-LIST": > There's an Amiga-GCC mailing list running in Finland, read README-LIST file. I don't have such a file in my GNU directory, and I'm sure I have unpacked the gcc270-readme.lha archive, what is/was in that file? > Name What Where > ---- ---- ----- > COPYING GNU LICENSE, read!! All archives > COPYING.LIB GNU LIBRARY LICENSE, read!! All archives > README-2.7.1 this file All archives > NEWS-2.7.1 What's new in GCC-2.7.1 gcc271-base Is the file "NEWS-2.7.1" really only in the gcc271-base archive? If it is, shouldn't it be in all archives as "README-2.7.1" is? > NOTE: perl scripts do not handle correctly AmigaDOS include files, which > seems to mean they are somewhat broken. If someone could work on this... I seem to remember that the Perl have been fixed. Can someone confirm this? In the libnix section: > * And it's short! I was able to compile a 492 byte 'hello, world' > using normal main. Someone asked me about the exact options to specify to get it that short. I don't know that, which options were used? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 12:26:34 1995 Received: from vinkku.hut.fi ([130.233.245.1]) by nic.funet.fi with SMTP id <90411-2>; Tue, 10 Oct 1995 12:24:41 +0200 Received: from lk-hp-4.hut.fi (lk-hp-4.hut.fi [130.233.244.35]) by vinkku.hut.fi (8.6.12/8.6.7) with ESMTP id MAA23539; Tue, 10 Oct 1995 12:24:40 +0200 Received: (tpeltone@localhost) by lk-hp-4.hut.fi (8.6.12/8.6.7) id MAA16158; Tue, 10 Oct 1995 12:24:39 +0200 Date: Tue, 10 Oct 1995 12:24:39 +0200 Message-Id: <199510101024.MAA16158@lk-hp-4.hut.fi> From: Teppo Peltonen To: amiga-gcc-port@nic.funet.fi, tpeltone@snakemail.hut.fi Subject: double foo = -0.0 produces incorrect output Hello! Here's a funny-little-feature that I discovered while trying to compile the gnuplot sources from the aminet distribution. Kickstart 39.106, Workbench 39.29 ixemul.library 41.1 GNU assembler version 2.5.2 (m68k-cbm-amigados) ------------------ cut --------------------- Guru:Work/t> cat foo.c double foo = -0.0; Guru:Work/t> gcc -c -v foo.c Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -Dmc68010 foo.c /t/cc494344.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cc1 /t/cc494344.i -mfixedstack -quiet -dumpbase foo.c -version -o /t/cc494344.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. as -mc68010 -o foo.o /t/cc494344.s /t/cc494344.s: Assembler messages: /t/cc494344.s:8: Error: Rest of line ignored. First ignored character is `:'. Guru:Work/t> --------------------- cut -------------- Guru:Work/t> less foo.s #NO_APP gcc2_compiled.: ___gnu_compiled_c: .globl _foo .data .even _foo: .double 0r1.: Guru:Work/t> ------------------------ cut ---------------------- Now why would anyone wanna say "-0.0" anyway? Is it like -0.0 < 0.0 or something else weird? I used the compiler from the latest (?) aminet archive (270). Tried to compile the code also on dec-alfa and hp systems (using 263) and there were no problems at all. Machine used for testing was an a1200 with lots of free real ram. I also tried using different stack sizes, options -O2 and -m68020 and the result was always the same. Oh, and the gcc binaries were the ones compiled for 68000 with no fpu. Have a nice time figuring that one out! Teppo From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 12:26:42 1995 Received: from erlang.gbar.dtu.dk ([130.225.87.177]) by nic.funet.fi with ESMTP id <90787-1>; Tue, 10 Oct 1995 12:26:38 +0200 Received: by erlang.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 10 Oct 1995 11:26:54 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Diffs for README-2.7.1 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I have made some additions and corrections to the last README-2.7.1. You can find the diff -3c after my signature. You can get the complete README as . I will also post it if someone requests it. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ *** README-2.7.1.old Wed Sep 20 14:36:00 1995 --- README-2.7.1 Tue Oct 10 09:07:29 1995 *************** *** 71,80 **** - Read FSF NEWS-2.7.1 file included. - As always, generic bugs fixed (see Changelog in GCC sources for details). - FSF listing shell script suppressed. - new as/ld/size/nm/ranlib using BFD, made by Raphael Luebbert - as fixed, used to generate some 020 instructions while in 68000 mode. ! - all programs recompiled using 2.7.1 compiler. - new inlines headers. - new compiler options: -mstackcheck and -mstackextend, to respectively implement stack checking and auto-stack growing into GCC compiled programs. --- 71,94 ---- - Read FSF NEWS-2.7.1 file included. - As always, generic bugs fixed (see Changelog in GCC sources for details). + - new as/ld/size/nm/ranlib using BFD, made by Raphael Luebbert + - all programs recompiled using 2.7.1 compiler. + - new inlines headers. There is now two sets. See the Inline Header section. + - new ixemul library, v41.4 (complete distribution can be found on Aminet + sites). + + ================================= + What was new in previous releases + ================================= + + 2.7.0 + + - Read FSF NEWS-2.7.0 file included. + - As always, generic bugs fixed (see Changelog in GCC sources for details). - FSF listing shell script suppressed. - new as/ld/size/nm/ranlib using BFD, made by Raphael Luebbert - as fixed, used to generate some 020 instructions while in 68000 mode. ! - all programs recompiled using 2.7.0 compiler. - new inlines headers. - new compiler options: -mstackcheck and -mstackextend, to respectively implement stack checking and auto-stack growing into GCC compiled programs. *************** *** 86,95 **** This release is dedicated in memory of Pierre Carette. - ================================= - What was new in previous releases - ================================= - 2.6.3 - Read FSF NEWS-2.6.1 file included. --- 100,105 ---- *************** *** 129,135 **** details), tons of bugs fixed for C++ support. - ld changed (see note for ld below). - new ixemul.library, with optimized versions for accelerated Amigas, see ! README-ixemul & ixemul.guide for more informations. - new C library (libnix) disabling use of ixemul.library for generated programs (best use for AmigaDOS specific programs). Full ANSI compliant, see README-libnix & libnix.guide for more informations. --- 139,145 ---- details), tons of bugs fixed for C++ support. - ld changed (see note for ld below). - new ixemul.library, with optimized versions for accelerated Amigas, see ! README-ixemul & ixemul.guide for more information. - new C library (libnix) disabling use of ixemul.library for generated programs (best use for AmigaDOS specific programs). Full ANSI compliant, see README-libnix & libnix.guide for more informations. *************** *** 182,188 **** Ixemul.library: Markus Wild (original programming), Leonard Norrgard (vinsci@nic.funet.fi), Raphael Luebbert, ! Stephan Isthesin. Libnix: Matthias Fleischer (fleischr@izfm.uni-stuttgart.de) and Gunther Nikl (gnikl@informatik.uni-rostock.de) Installer Prog: Jochen Wiedmann (jochen.wiedmann@zdv.uni-tuebingen.de) --- 192,198 ---- Ixemul.library: Markus Wild (original programming), Leonard Norrgard (vinsci@nic.funet.fi), Raphael Luebbert, ! Stephan Isthesin. Libnix: Matthias Fleischer (fleischr@izfm.uni-stuttgart.de) and Gunther Nikl (gnikl@informatik.uni-rostock.de) Installer Prog: Jochen Wiedmann (jochen.wiedmann@zdv.uni-tuebingen.de) *************** *** 318,324 **** gcc271-diffs.lha Diff files for all binaries. gcc271-src.lha Source for GCC-2.7.1 plus diff file. ! Name What Where ---- ---- ----- COPYING GNU LICENSE, read!! All archives --- 328,334 ---- gcc271-diffs.lha Diff files for all binaries. gcc271-src.lha Source for GCC-2.7.1 plus diff file. ! Name What Where ---- ---- ----- COPYING GNU LICENSE, read!! All archives *************** *** 446,462 **** - I want to keep older GCC compiler CLI> cd GNU:lib ! CLI> rename libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3 ! (note: replace 2.6.3 with your GCC version) ! CLI> rename libb/libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3/libb ! CLI> rename libm020/libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3/libm020 CLI> cd GNU:bin ! CLI> rename gcc gcc-2.6.3 ! CLI> rename gccv gccv-2.6.3 - I don't care about previous versions ! CLI> delete GNU:lib/gcc-lib/mc68000-cbm-amigados/2.6.3 all quiet Proceed then to "Distribution Installation" below, for mandatory archives only. --- 456,472 ---- - I want to keep older GCC compiler CLI> cd GNU:lib ! CLI> rename libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.7.0 ! (note: replace 2.7.0 with your GCC version) ! CLI> rename libb/libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.7.0/libb ! CLI> rename libm020/libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.7.0/libm020 CLI> cd GNU:bin ! CLI> rename gcc gcc-2.7.0 ! CLI> rename gccv gccv-2.7.0 - I don't care about previous versions ! CLI> delete GNU:lib/gcc-lib/mc68000-cbm-amigados/2.7.0 all quiet Proceed then to "Distribution Installation" below, for mandatory archives only. *************** *** 540,547 **** - Now skip to next paragraph and happy compiling! ! NOTE: new version of ixemul.library is provided, make sure you don't have ! another copy somewhere which may conflict with GCC. ============================= Your first C program with GCC --- 550,557 ---- - Now skip to next paragraph and happy compiling! ! NOTE: A new version of ixemul.library is provided, make sure you don't ! have another copy somewhere which may conflict with GCC. ============================= Your first C program with GCC *************** *** 617,623 **** First one is using ixemul.library Amiga shared-library at run-time. This library makes it possible to easily convert Unix(tm) programs to AmigaDOS, ! and made for example possible GCC on AmigaDOS. Have a look at ixemul.guide for further informations. Second one is an ANSI-C compliant library which is better suited for --- 627,633 ---- First one is using ixemul.library Amiga shared-library at run-time. This library makes it possible to easily convert Unix(tm) programs to AmigaDOS, ! and made GCC possible on AmigaDOS, for example. Have a look at ixemul.guide for further informations. Second one is an ANSI-C compliant library which is better suited for *************** *** 659,682 **** The fact is that ixemul.library takes stderr from the pr_CES field in the process structure. The field was added in 2.0. If the field ! is not set, then ixemul uses stdout, instead. The trouble is that this ! field must be set by the shell, and the only shell that does so is WShell! ! The rationale behind ixemul.library working this way is that ! "run NIL: cmd" will detach your process from the terminal, so ! that you can close the initial CLI window after startup. - In any case, there is a workaround for the problem that was posted to the - list a while back: compile your main program using the -Dmain=mymain - option, then link with stderrfix.o to provide the actual main that will - do the magic that creates an stderr stream that is different from - stdout. Along with the C version a C++ version is included and was used to - compile groff. - - Thanks to Kriton Kyrimis for this explanation and patch. - stderr fixes can be found in GNU:stderrfix (srcs-) and GNU:lib (.o files). - ===== ARexx ===== --- 669,682 ---- The fact is that ixemul.library takes stderr from the pr_CES field in the process structure. The field was added in 2.0. If the field ! is not set, then ixemul opens "*" (this will hopefully change to ! "CONSOLE:") and uses that as stderr. The problem with the pr_CES field ! is that must be set by the shell, and the only shell that does so is WShell! ! This means that it is difficult to detach GNU C compiled programmes from ! the Shell, unless it sets the pr_CES field. ===== ARexx ===== *************** *** 962,967 **** --- 962,970 ---- elements as library bases. In this case the library bases has to be made global for GCC. + See below for a possible solution to this, based on some new inline + headers by Kamil Iskra. + ============== Inline headers ============== *************** *** 974,976 **** --- 977,1013 ---- extern definitions. Functions defined inline and extern can be considered as macros. That means the definition is only used for inlining thus requiring linking with a library containing stubs. + + Starting with version 2.7.1, a new set of inline headers is included. + These new inline headers don't rely on making inline functions calls, + but use the preprocessor to insert the code. This has some major + advantages: + + 1) It requires a lot less memory, as the compiler doesn't have to keep + the code for all the library calls in memory. So you can now really + use that -O3 option :-) + 2) Library bases don't have to be global any more. They can now be local + or even structure elements. In the latter case, you'll need to use + something like + #define DOSBase mystruct->libs->DOSBase + or whatever you choose. + 3) Who knows, maybe it will even speed up compilation a little bit. + + The only disadvantage seems to be that this method generates *very* + bad code if you are not turning on optimization. + + ============= + Saving memory + ============= + + As GNU CC is often (but not always) memory hungry, a few tricks to save + memory can make life easier: + + 1) SetEnv TMPDIR somewhere_on_harddisk + This will make GNU CC create it's temporary files on your harddisk + instead of using T:. + 2) Stop all other programmes, close all other windows, kick out your + Commodities, use "Avail FLUSH" in the Shell, reduce screen resolution + and depth, disable all floppy drives with the boot menu. + 3) If you are lucky enough to have an MMU equipped Amiga, use virtual + memory. Come on, reserve that 50 MB partition :-) From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 12:47:59 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90239-2>; Tue, 10 Oct 1995 12:39:27 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA09048; Tue, 10 Oct 1995 11:41:12 +0100 Date: Tue, 10 Oct 1995 11:41:11 +0100 (MET) From: Kamil Iskra Subject: New inlines To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have just put new inlines on my WWW home page (see below). PHILIPPE! I wanted to upload it to colombo, but "user uploader access denied!" OK, below is some kind of change-log which describes what has changed since last version available on my account: - Vararg-stubs for dos.library and intuition.library functions whose last argument is not of type "struct TagItem *" are now generated. - "Second forms" of certain dos.library functions that have two names for the same call (!) are generated now (implemented as preprocessor macros). These affected AllocDosObject[TagList], CreateNewProc[TagList], System[TagList], NewLoadSeg[TagList]. - All functions of "DoPkt" family (DoPkt0, DoPkt1, ... , DoPkt4) are now automatically generated. [Note: this means, that now standard, system inlines generated by "fd2inline" do not need ANY fine-tuning "by hand" - generator takes care of everything] - Vararg-stubs no longer require last argument to look exactly as "struct TagItem *" - now it can be also "struct TagItem*" etc - inlines of third party library "progargs.library" are generated correctly now. - Now, depending on the options with which you compile, fd2inline outputs eithor old or new style inlines. Old-style is necessary for g++. Included are both versions of fd2inline (for new and old inlines), new and old inlines (dirs "inline" and "inline++") and fixed "proto" files. They are created in exactly the same way that I described yesterday - I'll comment Fred's and Christian's mails separately, in a few minutes (I wish I had pre-emptive multitasking :-). P.S Apollogies (sp?) to everybody who couldn't connect to my WWW home page yesterday - there were some problems with HTTP Daemon on my university, but luckily they have been fixed by now. Well, not all of them, actually, cause now "*.lha" files are not recognized as binary. I hope this will be fixed soon. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 12:48:40 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89937-4>; Tue, 10 Oct 1995 12:48:30 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA09209; Tue, 10 Oct 1995 11:48:56 +0100 Date: Tue, 10 Oct 1995 11:48:55 +0100 (MET) From: Kamil Iskra Subject: Re: New includes To: Christian Stieber cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Oct9.174025+0100mesz.395718-2+316@hphalle0.informatik.tu-muenchen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 9 Oct 1995, Christian Stieber wrote: > It is _very_ bad to have different results when compiling with/without > optimizing. So, using library stubs when not optimizing means that > a program that is written with local library bases cannot be compiled > without optimizer. Very bad, especially if you take into account that > the optimizer is not generally used while developing & debugging code. I agree with you. The "proto" files I included with "fd2inline" #include always, ie. both when optimizing or not. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 13:10:47 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90198-3>; Tue, 10 Oct 1995 13:09:52 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA09684; Tue, 10 Oct 1995 12:08:29 +0100 Date: Tue, 10 Oct 1995 12:08:28 +0100 (MET) From: Kamil Iskra Subject: Re: New includes To: Fred Fish cc: hans@wyst.hobby.nl, amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 9 Oct 1995, Fred Fish wrote: > I think you could probably use the include directory search mechanism here. > For example, given a C++ version in gnu:lib/g++include/inline/dos.h and a C > version in gnu:os-include/inline/dos.h, g++ will find the C++ version in > preference to the C version using the current g++ driver. > > However, I don't particularly like having the C++ version outside the > gnu:os-include tree, so maybe your suggestion of having something like > gnu:os-include/old-inline is best. > It would probaby be a simply change to > have that include directory searched ahead of gnu:os-include/inline for g++ > compiles. Well, I have no idea how to do this - if you were so kind and did it yourself... :-) > There should be no need to change any other files. Actually, there is. "proto" files had to be changed to #include always, even when no optimizing. I've alreade done it. > If someone > wants the old style for some reason with C they would have to explicitly > compile with -I/gnu/os-include/old-inline. So do you think that I should remove support for old-inlines from "proto" files? > -Fred / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 13:13:38 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90306-4>; Tue, 10 Oct 1995 13:13:24 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA09783; Tue, 10 Oct 1995 12:12:48 +0100 Date: Tue, 10 Oct 1995 12:12:47 +0100 (MET) From: Kamil Iskra Subject: Re: recompiling ixemul.library To: kyrimis@softlab.ece.ntua.gr cc: Amiga GCC List In-Reply-To: <9510082015.08ie@kriton.UUCP> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 8 Oct 1995, Kriton Kyrimis wrote: > I just finished recompiling ixemul.library for a 68040+68881 using the aminet > version of gcc 2.7.0. The resulting file is different from the official > version: I had the same problem with 41.3 and 68000 version. But I think that more than one byte was different. > BTW, ixemul.trace (at least the 68040+68881 version) was missing from the > official distribution. It seems that it was included with plain 68000 version only. BTW: is this intentional that archives are called "4140" and not "4104"? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 16:57:57 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90626-3>; Tue, 10 Oct 1995 16:55:55 +0200 Received: by colombo.telesys-innov.fr; Tue, 10 Oct 1995 15:55:20 GMT From: Philippe BRAND Message-Id: <199510101555.PAA24085@colombo.telesys-innov.fr> Subject: Re: New inlines To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Tue, 10 Oct 1995 15:55:20 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Kamil Iskra" at Oct 10, 95 11:41:11 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 473 Kamil Iskra writes: > PHILIPPE! Please don't cry. My baby shouts are enough :) > I wanted to upload it to colombo, but "user uploader access denied!" anonymous and put it under /pub/incoming... oh well just created /pub/amigados-gnu/uploads, so you might use this one instead. Great work! -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 17:34:56 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90648-4>; Tue, 10 Oct 1995 17:33:46 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t2gk1-0004nYC; Tue, 10 Oct 95 08:37 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: double foo = -0.0 produces incorrect output To: tpeltone@snakemail.hut.fi (Teppo Peltonen) Date: Tue, 10 Oct 1995 08:37:17 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi, tpeltone@snakemail.hut.fi In-Reply-To: <199510101024.MAA16158@lk-hp-4.hut.fi> from "Teppo Peltonen" at Oct 10, 95 12:24:39 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 400 > ixemul.library 41.1 You might want to try a later version. 41.4 is now on aminet. > Guru:Work/t> less foo.s > #NO_APP > gcc2_compiled.: > ___gnu_compiled_c: > .globl _foo > .data > .even > _foo: > .double 0r1.: I just tried it with the GNU tools off FreshFish 10 and it works fine. I get: #NO_APP gcc2_compiled.: ___gnu_compiled_c: .globl _foo .data .even _foo: .double 0r0 -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 18:57:31 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90033-1>; Tue, 10 Oct 1995 18:56:24 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t2i0S-0004nYC; Tue, 10 Oct 95 09:58 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New includes To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Tue, 10 Oct 1995 09:58:19 -0700 (MST) Cc: fnf@amigalib.com, hans@wyst.hobby.nl, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Oct 10, 95 12:08:28 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1752 > > It would probaby be a simply change to > > have that include directory searched ahead of gnu:os-include/inline for g++ > > compiles. > > Well, I have no idea how to do this - if you were so kind and did it > yourself... :-) Let me make sure I understand the problem completely. We currently have some inlines that work with both C and C++, but want to add some new inlines that work only with C. Please refresh my memory why these new inlines are better and why they only work with C. We want anyone that does "#include " to end up getting the new inline if compiling in C and the current inline if compiling in C++. Are these inline files proprietary in any way? I.E. are they mechanically derived from any Commodore proprietary files. Perhaps we should review why we have gnu:include and gnu:os-include, since Phillipe and I have different concepts (or at least did at one time) what each should mean. I wanted a place in which to put all files that were not freely distributable, such as Commodore include and library files, and that is what I believe gnu:os-include and gnu:os-lib to be. > > There should be no need to change any other files. > > Actually, there is. "proto" files had to be changed to #include > always, even when no optimizing. I've alreade done it. OK, I probably just misunderstood and thought that the proto files already had something like: #include and you were proposing to change them to: #ifdef _OLDINCLUDES_ #include #else #include #endif > So do you think that I should remove support for old-inlines from "proto" > files? Lets try to first reach some agreement about where we are and where we want to go. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 19:03:45 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90779-2>; Tue, 10 Oct 1995 19:03:20 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t2i7a-0004nYC; Tue, 10 Oct 95 10:05 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: recompiling ixemul.library To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Tue, 10 Oct 1995 10:05:41 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list), umueller@wuarchive.wustl.edu (Urban Mueller) In-Reply-To: from "Kamil Iskra" at Oct 10, 95 12:12:47 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 471 > > BTW, ixemul.trace (at least the 68040+68881 version) was missing from the > > official distribution. > > It seems that it was included with plain 68000 version only. This is correct. Several people commented they thought it was a waste of space to include trace versions for all the different flavors. > BTW: is this intentional that archives are called "4140" and not "4104"? No, that is my fault. They should be 4104. I'll ask Urban to rename them. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 19:20:55 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90795-3>; Tue, 10 Oct 1995 19:18:46 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id TAA29171 at Tue, 10 Oct 1995 19:17:59 +0200 Received: by softlab.ece.ntua.gr with UUCP id TAA28160 at Tue, 10 Oct 1995 19:22:44 +0200 Received: by kriton.UUCP (V1.17-beta/Amiga) id <08jd@kriton.UUCP>; Tue, 10 Oct 95 19:07:19 EET Date: Tue, 10 Oct 95 19:07:19 EET Message-Id: <9510101707.08jd@kriton.UUCP> In-Reply-To: (from theseas!amigalib.com!fnf (Fred Fish)) (at Mon, 9 Oct 1995 12:13:20 -0700 (MST)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 2771 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!amigalib.com!fnf@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: ixemul.library recompilation mystery solved Hi Fred (Fred Fish), in on Oct 9 you wrote: > It's suspicious and should be tracked down, but it's hard to say if it is cause > for alarm. Try a "cmp -l" and see what changed. If its only a few bytes that > is different than if half the file changed. Well, the output of cmp -l gnu:libs/ixemul.library ixemul.library was: 110713 102 41 110714 250 110 110716 4 10 110717 41 130 110719 0 102 110720 10 220 110721 130 41 110722 210 110 110723 41 377 110724 10 374 110727 0 116 110728 0 161 Only a few bytes are different. I then tried disassembling the two versions of ixemul.library using ADIS, and running diff on the output. This is what I got: *** ixemul.library.fnf.dec Tue Oct 10 19:51:06 1995 --- ixemul.library.dec Tue Oct 10 19:50:03 1995 *************** *** 35371,35383 **** RTS L1B04C MOVEA.L $4(SP),A0 - CLR.L $4(A0) MOVE.L A0,$8(A0) ! ADDQ.L #$4,A0 ! MOVE.L A0,-(A0) RTS ! L1B05E DC.W $0 DSEG --- 35371,35383 ---- RTS L1B04C MOVEA.L $4(SP),A0 MOVE.L A0,$8(A0) ! ADDQ.W #$4,A0 ! CLR.L (A0) ! MOVE.L A0,-$4(A0) RTS ! L1B05E DC.W $4E71 DSEG Well, this is obviously(!) the code for Newlist() from libamiga.a and amiga.lib respectively. Fred used the CBM version, while I used the version of libamiga.a that came with the aminet version of 2.7.0. (I remember someone saying it is dangerous to use a converted amiga.lib with gcc, so I threw my copy away.) Now, amazing as this piece of detection may have been, I have to confess that I don't really understand 680x0 assembly. From what little I know, it seems to me that the two NewList() implementations are not quite equivalent: that last MOVE.L does not appear to do the same thing. (On the other hand, the different DC.W's appear to be different methods of padding for alignment, using either 0 or a NOP instruction, so if the code up to the RTS is correct, then the differences between the two libraries are of no importance.) Can somebody check this? -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "My doctor says that I have a malformed public duty gland and a natural deficiency in moral fiber, and that I am therefore excused from saving Universes." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 19:51:22 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90945-3>; Tue, 10 Oct 1995 19:48:57 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t2irl-0004nYC; Tue, 10 Oct 95 10:53 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ixemul.library recompilation mystery solved To: kyrimis@softlab.ece.ntua.gr Date: Tue, 10 Oct 1995 10:53:25 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: <9510101707.08jd@kriton.UUCP> from "Kriton Kyrimis" at Oct 10, 95 07:07:19 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 630 > Fred used the CBM version, while I used the version of > libamiga.a that came with the aminet version of 2.7.0. (I remember someone > saying it is dangerous to use a converted amiga.lib with gcc, so I threw my > copy away.) Ah, this is something I've been meaning to resolve for a while. If the version distributed with the aminet gcc releases is fully functional and complete, then I'd have no problem switching over to that version. Can whomever created this version detail how it was done, and perhaps provide whatever "source code" is needed to recreate the library, so I can integrate it into the GNU Tools tree. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 19:55:40 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90115-4>; Tue, 10 Oct 1995 19:55:00 +0200 Received: from carina.rz.Uni-Osnabrueck.DE by funet.fi with SMTP (PP); Tue, 10 Oct 1995 19:54:32 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id SAA03363; Tue, 10 Oct 1995 18:54:06 +0100 From: Thomas Radtke Received: (thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) id SAA15680; Tue, 10 Oct 1995 18:54:01 +0100 Message-Id: <199510101754.SAA15680@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: ixemul.library recompilation mystery solved To: kyrimis@softlab.ece.ntua.gr Date: Tue, 10 Oct 1995 18:54:00 +0100 (NFT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9510101707.08jd@kriton.UUCP> from "Kriton Kyrimis" at Oct 10, 95 07:07:19 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1154 > > *** ixemul.library.fnf.dec Tue Oct 10 19:51:06 1995 > --- ixemul.library.dec Tue Oct 10 19:50:03 1995 > *************** > *** 35371,35383 **** > RTS > > L1B04C MOVEA.L $4(SP),A0 > - CLR.L $4(A0) > MOVE.L A0,$8(A0) > ! ADDQ.L #$4,A0 > ! MOVE.L A0,-(A0) > RTS > > ! L1B05E DC.W $0 > > DSEG > > --- 35371,35383 ---- > RTS > > L1B04C MOVEA.L $4(SP),A0 > MOVE.L A0,$8(A0) > ! ADDQ.W #$4,A0 > ! CLR.L (A0) > ! MOVE.L A0,-$4(A0) > RTS > > ! L1B05E DC.W $4E71 > > DSEG It seems to me that the second code fragment returns with an A0 that is four byte lower than in the first. This is maybe only a so called (?) scratch register. Btw., the second one is better optimized. Thomas From amiga-gcc-port-owner@nic.funet.fi Tue Oct 10 20:19:37 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90932-1>; Tue, 10 Oct 1995 20:18:07 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26566-1>; Tue, 10 Oct 1995 16:42:44 +0100 Received: from hphalle9g.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395717-1>; Tue, 10 Oct 1995 16:42:31 +0100 Subject: Re: New includes From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Tue, 10 Oct 1995 16:42:32 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1651 Message-Id: <95Oct10.164231+0100mesz.395717-1+777@hphalle0.informatik.tu-muenchen.de> Forwarded message: >From stieber Tue Oct 10 16:41:20 1995 Subject: Re: New includes To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Tue, 10 Oct 1995 16:41:20 +0100 (MEZ) In-Reply-To: from "Kamil Iskra" at Oct 10, 95 12:08:28 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 967 > > If someone > > wants the old style for some reason with C they would have to explicitly > > compile with -I/gnu/os-include/old-inline. > > So do you think that I should remove support for old-inlines from "proto" > files? Well, I'm not Fred, and I'm not sure whether amigaos-GNU is democratic :) Anyway, here's my vote: do not support old inlines anymore. The newstyle inlines are a major improvement, so IMHO a compatability break is okay. There should be only a few sources where the newstyle inlines will cause problems; those people will complain, then change their source anyway and that's it. No need to carry old stuff around forever. Better force people to conform to the new rules today. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 00:23:19 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90900-4>; Wed, 11 Oct 1995 00:19:48 +0200 Received: by colombo.telesys-innov.fr; Tue, 10 Oct 1995 23:19:26 GMT From: Philippe BRAND Message-Id: <199510102319.XAA25587@colombo.telesys-innov.fr> Subject: Re: ixemul.library recompilation mystery solved To: fnf@amigalib.com (Fred Fish) Date: Tue, 10 Oct 1995 23:19:25 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Fred Fish" at Oct 10, 95 10:53:25 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 511 Fred Fish writes: > Can whomever created this version detail how it was done, and perhaps > provide whatever "source code" is needed to recreate the library, so I > can integrate it into the GNU Tools tree. ? this is libamiga.a sent to me by Gunther Nikl if I can remember correctly. It's been in Aminet dist for quite some time. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 00:23:28 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90648-2>; Wed, 11 Oct 1995 00:23:21 +0200 Received: by colombo.telesys-innov.fr; Tue, 10 Oct 1995 23:22:26 GMT From: Philippe BRAND Message-Id: <199510102322.XAA25596@colombo.telesys-innov.fr> Subject: Re: New includes To: fnf@amigalib.com (Fred Fish) Date: Tue, 10 Oct 1995 23:22:25 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Fred Fish" at Oct 10, 95 09:58:19 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 670 Fred Fish writes: > Perhaps we should review why we have gnu:include and gnu:os-include, since > Phillipe and I have different concepts (or at least did at one time) what > each should mean. I wanted a place in which to put all files that were > not freely distributable, such as Commodore include and library files, and > that is what I believe gnu:os-include and gnu:os-lib to be. Os dependent in os-include and os-lib. Others, gnu stuff, Unix (tm) headers and libs in include and lib. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 02:04:55 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89415-2>; Wed, 11 Oct 1995 02:03:17 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t2ogw-0004nYC; Tue, 10 Oct 95 17:06 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New includes To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Tue, 10 Oct 1995 17:06:38 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: <199510102322.XAA25596@colombo.telesys-innov.fr> from "Philippe BRAND" at Oct 10, 95 11:22:25 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 636 > Os dependent in os-include and os-lib. Others, gnu stuff, Unix (tm) headers > and libs in include and lib. I think we should consider eliminating gnu:os-lib and simply put those libraries into gnu:lib. There should be no name conflicts and this would simplify the library searching path. We should also consider moving gnu:os-include/* to gnu:include/amigados and then have gcc automatically search gnu:include/amigados. This should require no user source code changes. I.E. #include would simply find gnu:include/amigados/dos/dos.h rather than gnu:os-include/dos/dos.h. Anyone see any problems with this? -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 10:31:48 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90267-2>; Wed, 11 Oct 1995 10:28:58 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id JAA17755; Wed, 11 Oct 1995 09:25:06 +0100 Date: Wed, 11 Oct 1995 09:25:05 +0100 (MET) From: Kamil Iskra Subject: Re: New includes To: Christian Stieber cc: Amiga GCC List In-Reply-To: <95Oct10.164130+0100mesz.395717-2+748@hphalle0.informatik.tu-muenchen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Oct 1995, Christian Stieber wrote: > Anyway, here's my vote: do not support old inlines anymore. The newstyle > inlines are a major improvement, so IMHO a compatability break is okay. > There should be only a few sources where the newstyle inlines will cause > problems; those people will complain, then change their source anyway > and that's it. But old style inlines are required for g++ anyway, and they have to be handled differently: __OPTIMIZE__, __NOINLINES__ etc. Maybe Amiga-specific programming in C++ is not that common, but that's actually not something that we should be proud of or make it virtually impossible by removing support for old inlines. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 10:34:30 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90807-2>; Wed, 11 Oct 1995 10:32:38 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id JAA17596; Wed, 11 Oct 1995 09:17:11 +0100 Date: Wed, 11 Oct 1995 09:17:10 +0100 (MET) From: Kamil Iskra Subject: Re: New includes To: Fred Fish cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Oct 1995, Fred Fish wrote: > Let me make sure I understand the problem completely. We currently have some > inlines that work with both C and C++, but want to add some new inlines that > work only with C. Please refresh my memory why these new inlines are better > and why they only work with C. 1. Old inlines. Implementation: Global, "inline" functions. Advantages: Work both with C and C++. Disadvantages: Library bases have to be global. All work made by compiler -> huge amounts of RAM required. Work when optimizing only. 2. New inlines. Implementation: Preprocessor macros that call another preprocessor macros defined in "inline/macros.h". These macros in "inline/macros" create local "inline" functions in the place of function call. Advantages: Library bases can be local, can be processor macros etc. Most of the work made by preprocessor -> no longer needs that much RAM. Much shorter temporary file from preprocessor (includes only definitions of functions that were actually used) -> most probably much faster stage of compilation. Works both when optimizing and when not optimizing. Disadvantages: Due to usage of local functions, which are not supported by g++, these inlines do not work with g++. > We want anyone that does "#include " to end up getting the new > inline if compiling in C and the current inline if compiling in C++. Not really. Sure, this would be nice, but is not that important. We have special access files in "proto" directory, that include both prototypes and inlines, and in some cases also definitions of required structures. This is the adviced way of including amiga-specific includes, cause it's mostly portable between various Amiga compilers. > Are these inline files proprietary in any way? I.E. are they mechanically > derived from any Commodore proprietary files. They were automatically generated from OS 3.1 fd-files and clib-files, obtained from your CD :-). > > > There should be no need to change any other files. > > > > Actually, there is. "proto" files had to be changed to #include > > always, even when no optimizing. I've alreade done it. > > OK, I probably just misunderstood and thought that the proto files > already had something like: > > #include > > and you were proposing to change them to: > > #ifdef _OLDINCLUDES_ > #include > #else > #include > #endif More or less, but rather less than more :-). For example, please have a look at how old "proto/wb.h" file looks: #ifndef PROTO_WB_H #define PROTO_WB_H #ifndef DOS_DOSEXTENS_H #include #endif #include #if defined(__OPTIMIZE__) && !defined(__NOINLINES__) #include #endif #ifndef __NOLIBBASE__ extern struct Library *WorkbenchBase; #endif #endif I changed it to: #ifndef PROTO_WB_H #define PROTO_WB_H #ifndef DOS_DOSEXTENS_H #include #endif #include #if !defined(__cplusplus) && !defined(__USEOLDINLINES__) #include #else #if defined(__OPTIMIZE__) && !defined(__NOINLINES__) #include #endif #endif #ifndef __NOLIBBASE__ extern struct Library *WorkbenchBase; #endif #endif / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 11:45:15 1995 Received: from legolas.mdh.se ([130.238.251.203]) by nic.funet.fi with SMTP id <90643-3>; Wed, 11 Oct 1995 11:42:08 +0200 Received: (from frv95tjn@localhost) by legolas.mdh.se (8.6.10/8.6.10) id KAA01674; Wed, 11 Oct 1995 10:41:52 +0100 Date: Wed, 11 Oct 1995 10:41:52 +0100 (MET) From: Tommy Johansson X-Sender: frv95tjn@legolas.mdh.se To: gcclist Subject: Octave Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is someone porting octave? Tommy Johansson frv95tjn@mds.mdh.se From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 12:09:03 1995 Received: from uni-kl.de ([131.246.136.50]) by nic.funet.fi with SMTP id <90127-3>; Wed, 11 Oct 1995 12:07:16 +0200 Received: from uklirb.informatik.uni-kl.de by stepsun.uni-kl.de id ad20864; 11 Oct 95 11:06 MET Received: from kerry.informatik.uni-kl.de by uklirb.informatik.uni-kl.de id aa26613; 11 Oct 95 11:03 MET Date: Wed, 11 Oct 95 5:56:04 EDT From: Frank Bernard To: amiga-gcc-port@nic.funet.fi Subject: unsubscribe Message-ID: <9510110556.aa29715@kerry.informatik.uni-kl.de> From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 17:43:45 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89637-3>; Wed, 11 Oct 1995 17:42:11 +0200 Received: from amigalib.com (actually host fishpond.amigalib.com) by funet.fi with SMTP (PP); Wed, 11 Oct 1995 17:38:16 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t33IV-0004nYC; Wed, 11 Oct 95 08:42 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New includes To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Wed, 11 Oct 1995 08:42:23 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Oct 11, 95 09:17:10 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1282 > > Please refresh my memory why these new inlines are better > > and why they only work with C. Thanks for the details. It will take a while to digest them and I'd like to take a look at the current files and your new files (please upload them to the incoming dir on ftp.amigalib.com). > > Are these inline files proprietary in any way? I.E. are they mechanically > > derived from any Commodore proprietary files. > > They were automatically generated from OS 3.1 fd-files and clib-files, > obtained from your CD :-). Hmm, that could be a problem. The fd files are included on my CD under license from the former CBM. If other files are mechanically derived from those files, I suspect the derived files (inlines) could be considered to be a derivative work, which might still fall under the same license terms, which could mean that I could put them on the CD but they could not (for example) be distributed by ftp or as part of an aminet gcc release. To be sure I would suggest contacting Amiga Technologies legal staff, describe in detail what you are proposing, and ask them to render an opinion on whether or not the derived files are redistributable. The contact is: Amiga Technologies GmbH Mr. Ralph Schmied Berliner Ring 89 D-64625 Bensheim Germany -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 17:44:06 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89025-4>; Wed, 11 Oct 1995 17:42:58 +0200 Received: from lorenz.gbar.dtu.dk by funet.fi with SMTP (PP); Wed, 11 Oct 1995 17:32:04 +0200 Original-Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) PP-warning: Illegal Received field on preceding line Date: Wed, 11 Oct 1995 14:18:38 +0100 (MET) From: Rask Lambertsen To: Fred Fish Cc: Philippe BRAND , Amiga GCC mailing list Subject: Re: New includes In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Oct 1995, Fred Fish wrote: > > Os dependent in os-include and os-lib. Others, gnu stuff, Unix (tm) headers > > and libs in include and lib. > > I think we should consider eliminating gnu:os-lib and simply put those > libraries into gnu:lib. There should be no name conflicts and this would > simplify the library searching path. Somehow, it seems natural to seperate the GNU libraries from libamiga.lib. > We should also consider moving gnu:os-include/* to gnu:include/amigados and > then have gcc automatically search gnu:include/amigados. This should > require no user source code changes. I.E. > > #include > > would simply find gnu:include/amigados/dos/dos.h rather than > gnu:os-include/dos/dos.h. > > Anyone see any problems with this? No, fine with me, but what is the point? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 17:48:54 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90080-3>; Wed, 11 Oct 1995 17:48:15 +0200 Received: from amigalib.com (actually host fishpond.amigalib.com) by funet.fi with SMTP (PP); Wed, 11 Oct 1995 17:47:54 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t33SF-0004nYC; Wed, 11 Oct 95 08:52 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Octave To: frv95tjn@legolas.mdh.se (Tommy Johansson) Date: Wed, 11 Oct 1995 08:52:26 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Tommy Johansson" at Oct 11, 95 10:41:52 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 358 > Is someone porting octave? There is a port on FreshFish 9 and FreshFish 10. BTW, it takes about 1Mb of stack to completely compile octave, and probably 16 Mb or more of memory. You also have to be sure you have the linker that has my changes to split reloc sections that are larger than 64K entries or AmigaDOS will refuse to run the executable. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 18:00:28 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <90683-3>; Wed, 11 Oct 1995 17:58:41 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id QAA28322 (8.6.12/7.4g-FAU);; Wed, 11 Oct 1995 16:58:27 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA07459; Wed, 11 Oct 1995 17:58:23 +0200 Date: Wed, 11 Oct 1995 17:58:23 +0200 Message-Id: <9510111558.AA07459@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: kiskra@ernie.icslab.agh.edu.pl Cc: stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi In-Reply-To: (message from Kamil Iskra on Wed, 11 Oct 1995 09:25:05 +0100 (MET)) Subject: Re: New includes Hello ! I read the mails about new inlines and old inlines. Now there is a mail saying g++ can only work with the old inlines. I think this is a very very important point because C++ gives the user some more and better and easier ways to something than in C. So I would say: change only to the new inlines if it is possible to use it with C++/g++ or do it in a compatible way !!!!!!!!!! Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 18:00:35 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90856-1>; Wed, 11 Oct 1995 17:59:42 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26506-3>; Wed, 11 Oct 1995 16:59:01 +0100 Received: from hphalle6b.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395719-1>; Wed, 11 Oct 1995 16:58:59 +0100 Subject: Re: New includes From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Wed, 11 Oct 1995 16:58:46 +0100 (MEZ) In-Reply-To: from "Kamil Iskra" at Oct 11, 95 09:17:10 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 893 Message-Id: <95Oct11.165859+0100mesz.395719-1+1278@hphalle0.informatik.tu-muenchen.de> > Disadvantages: Due to usage of local functions, which are not supported by > g++, these inlines do not work with g++. Create new inlines for G++ that use the old method, like this: extern __inline__ BPTR Open(const struct DOSBase *DOSBase, const char *Filename, ULONG Mode) { ... the inline stuff goes here ... } #define Open(Filename,Mode) Open(DOSBase,Filename,Mode) IMHO this should work as expected, i.e. with local and global library bases, library bases that are #define-d etc. Of course, that leaves the memory problem. But since this is only for g++ anyway... Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 20:06:04 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90025-3>; Wed, 11 Oct 1995 20:04:28 +0200 Received: from hgatenl.hobby.nl (hgatenl.hobby.nl [193.78.42.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with SMTP id SAA03572 for ; Wed, 11 Oct 1995 18:03:55 GMT Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0t35ja-000RGTC; Wed, 11 Oct 95 19:18 MET Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0t2Z95-000GCqC; Tue, 10 Oct 95 08:30 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <09xe@wyst.hobby.nl>; Tue, 10 Oct 95 08:28:25 CET Message-Id: <9510100728.09xe@wyst.hobby.nl> Date: Tue, 10 Oct 1995 07:28:22 +0000 (CET) In-Reply-To: from "Kamil Iskra" at Oct 9, 95 12:26:13 pm Content-Type: text Content-Length: 2322 From: hans@wyst.hobby.nl (Hans Verkuil) To: iskra@student Cc: amiga-gcc-port@nic.funet.fi Subject: Re: New includes According to Kamil Iskra: > > There is one, big problem: they are not supported by g++, cause g++ does > not support local functions. I think that the only acceptable solution > would be to have two "inline" dirs: say "inline" and "inline++". The first > one would contain new format inlines, supported by C, the latter old > format, supported by both C and C++. "proto" files would have to be > modified to include appropriate header file when compiling in C or C++. I > think that a preprocessor define "__USEOLDINLINES__" would also be useful > - it would force to use old inline format even when compiling in C. Why not use one header with the following structure: #if defined(__cplusplus) || defined(__USEOLDINLINES) old inlines #else new inlines #endif This should do the job without too much fuss. > I have also some debts if these new inlines should be used only when > optimizing or always. They work even when no optimizing, but code quality > is very poor, much poorer than when using library stubs. On the other > hand, new inlines support locale library base (see above), which library > stubs do not - so program that uses local library bases would always have > to be compiled with -O. On the other hand, that's true for old inlines, > too. I'm not sure what to do with this one, so I'm waiting for your > advice, too. Use them always. It's more consistent. > This will not be "the last word" about inlines. Still to implement are > "narrower lists of clobbered registers" (exec.library/Forbid() etc), > "library base in any address register" (math functions from > utility.library) and "no memory clobbering" (quite a lot of functions, > "tricky" work cause in most cases it's hard to decide how to clasify a > function (BTW: thanx to Rask Lambertsen for his help)). Hope I haven't > forgot about anything :-). I assume that the new inlines are at least as good as the old inlines? I.e., the quality of the generated code should be the same or better compared to the old inlines. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 20:06:48 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90683-3>; Wed, 11 Oct 1995 20:06:22 +0200 Received: from hgatenl.hobby.nl (hgatenl.hobby.nl [193.78.42.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with SMTP id SAA03593 for ; Wed, 11 Oct 1995 18:05:42 GMT Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0t35k8-000RGUC; Wed, 11 Oct 95 19:19 MET Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0t2Z95-000Fz7C; Tue, 10 Oct 95 08:30 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <09x9@wyst.hobby.nl>; Tue, 10 Oct 95 08:18:10 CET Message-Id: <9510100718.09x9@wyst.hobby.nl> Date: Tue, 10 Oct 1995 07:18:07 +0000 (CET) In-Reply-To: from "Rask Lambertsen" at Oct 9, 95 09:10:33 am Content-Type: text Content-Length: 1075 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Amiga GNU Tools Project List > I *think* this one could be caused by a buggy pipe handler. I had this > problem with C='s L:Queue-Handler, it simply looses some of the bytes > (around 5% sometimes) sent through it. If you haven't tried it already, > try something like > > cat largefile | cat >largefile.after > > and see if they have the same size or try checksumming them. This is how > I found out that C='s pipe handler is buggy. The bug has nothing to do with the pipe-handlers in L:! It only happens when specifying the 'z' (and probably 'Z') flag to tar. The bug is either in gzip, in the gzip-handling of tar, or in the pipe()-related functions in ixemul.library. Don't waste time on PIPE-handlers, QUEUE-handlers or IXPIPE-handlers, these aren't used. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Oct 11 21:33:42 1995 Received: from mserv.rug.ac.be ([157.193.40.37]) by nic.funet.fi with SMTP id <90912-4>; Wed, 11 Oct 1995 21:32:38 +0200 Received: from eduserv.rug.ac.be by mserv.rug.ac.be with SMTP id AA28272 (5.67b/IDA-1.5 for ); Wed, 11 Oct 1995 20:32:25 +0100 Received: by eduserv.rug.ac.be (5.x/SMI-SVR4) id AA18860; Wed, 11 Oct 1995 20:32:21 +0100 Date: Wed, 11 Oct 1995 20:32:21 +0100 (MET) From: Kristof Depraetere To: amiga-gcc-port@nic.funet.fi Subject: Re: Amiga GNU Tools Project List In-Reply-To: <199510091013.LAA06588@mostar.nmrc.ucc.ie> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 9 Oct 1995, Lars Hecking wrote: > > PROJECT: AmigaGuide docs > > > > DESCRIPTION > > > > Modify standard Makefiles so that they generate and install AmigaGuide > > versions of the documentation, using a version of texinfo that knows how > > to generate AmigaGuide files. May require first tracking down and > > integrating texinfo changes to generate AmigaGuide files from texinfo > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > input files. > > I had a look at the sources for mkguide from Aminet (makeinfo v1.55 based) > and makeinfo 1.63 from texinfo-3.6. Merging the diffs into the new version > is a _lot_ of work, but doesn't require much Amiga/Unix specific knowledge. > I started merging the diffs from mkguide to makeinfo 1.63 today. I don't know how long this will take me. I have no experience with this sort of work, but hey I want to help where ever I can. With the makeinfo from mkguide you can choose between AmigaGuide v34 and v39 support. Should I leave the v34 in or can I remove it? If someone can give this third year computer science student some tips on merging, don't hesitate to do so. bye, Kristof ------------------- Kristof.Depraetere@rug.ac.be Amiga 4000/040 From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 03:32:16 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89800-4>; Thu, 12 Oct 1995 03:31:16 +0200 Received: from achilles.noc.ntua.gr by funet.fi with SMTP (PP); Wed, 11 Oct 1995 15:29:39 +0200 Original-Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id PAA24787 at Wed, 11 Oct 1995 15:29:13 +0200 PP-warning: Illegal Received field on preceding line Original-Received: by softlab.ece.ntua.gr with UUCP id PAA05324 at Wed, 11 Oct 1995 15:33:35 +0200 PP-warning: Illegal Received field on preceding line Received: by kriton.UUCP (V1.17-beta/Amiga) id <08jy@kriton.UUCP>; Wed, 11 Oct 95 15:26:54 EET Date: Wed, 11 Oct 95 15:26:54 EET Message-Id: <9510111326.08jy@kriton.UUCP> In-Reply-To: <199510101754.SAA15680@nereid.rz.Uni-Osnabrueck.DE> (from Thomas Radtke ) (at Tue, 10 Oct 1995 18:54:00 +0100 (NFT)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr Content-Length: 695 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!rz.Uni-Osnabrueck.DE!Thomas.Radtke@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: ixemul.library recompilation mystery solved Hi Thomas (Thomas Radtke), in <199510101754.SAA15680@nereid.rz.Uni-Osnabrueck.DE> on Oct 10 you wrote: > It seems to me that the second code fragment returns with an A0 that is > four byte lower than in the first. This is maybe only a so called (?) scratch > register. Btw., the second one is better optimized. If this is the only difference between the two implementations, then they are equivalent, as I believe D0, D1, A0, and A1 are treated as scratch registers by C. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I prefer to put my faith in the mind probe!" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 10:31:16 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <90829-1>; Thu, 12 Oct 1995 10:28:29 +0200 Received: by tycho.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 12 Oct 1995 09:27:00 +0100 (MET) From: Rask Lambertsen To: Fred Fish Cc: Tommy Johansson , amiga-gcc-port@nic.funet.fi Subject: Re: Octave In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 11 Oct 1995, Fred Fish wrote: > > Is someone porting octave? > > There is a port on FreshFish 9 and FreshFish 10. BTW, it takes about > 1Mb of stack to completely compile octave, and probably 16 Mb or more > of memory. You also have to be sure you have the linker that has my > changes to split reloc sections that are larger than 64K entries or > AmigaDOS will refuse to run the executable. Wouldn't it be possible to use sobja to convert all the object files to Amiga format and then use an AmigaDOS format linker? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 11:23:10 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90521-3>; Thu, 12 Oct 1995 11:20:39 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA06052; Thu, 12 Oct 1995 10:21:47 +0100 Date: Thu, 12 Oct 1995 10:21:46 +0100 (MET) From: Kamil Iskra Subject: Re: New includes To: Christian Stieber cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Oct11.165859+0100mesz.395719-1+1278@hphalle0.informatik.tu-muenchen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 11 Oct 1995, Christian Stieber wrote: > Create new inlines for G++ that use the old method, like this: > > extern __inline__ BPTR Open(const struct DOSBase *DOSBase, > const char *Filename, > ULONG Mode) > { > ... the inline stuff goes here ... > } > > #define Open(Filename,Mode) Open(DOSBase,Filename,Mode) More or less, that's how old inlines looks like, or at least CAN look like, if you "configure" them appropriately, so I don't think there is anything to do on this subject. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 11:36:59 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90766-1>; Thu, 12 Oct 1995 11:34:44 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA12102; Thu, 12 Oct 1995 10:32:54 +0100 Date: Thu, 12 Oct 1995 10:32:53 +0100 (MET) From: Kamil Iskra Subject: Re: New includes To: Thomas Walter cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9510111558.AA07459@pctc.chemie.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 11 Oct 1995, Thomas Walter wrote: > change only to the new inlines if it is possible to use it with C++/g++ > or do it in a compatible way !!!!!!!!!! I have to disagree with you. I also would like to use new inlines with g++. But it impossible. Just impossible (unless somebody adds local functions support to g++, of course). Most people program Amiga in C, so I think that adding new, better inlines is very important, even for the sake of loosing compatibility with g++. But the compatibility won't be lost, actually. BOTH new and old inlines are available. Source generator, "fd2inline", has full support for both of them. "proto" files automatically choose appropriate header when you are compiling in C or C++. So I really don't see any reason for this 10 exclamation marks at the end of your article :-). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 12:22:34 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90521-1>; Thu, 12 Oct 1995 12:20:49 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA00867; Thu, 12 Oct 1995 11:21:18 +0100 Date: Thu, 12 Oct 1995 11:21:17 +0100 (MET) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: New includes To: Hans Verkuil cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9510100728.09xe@wyst.hobby.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Tue, 10 Oct 1995, Hans Verkuil wrote: > Why not use one header with the following structure: > > #if defined(__cplusplus) || defined(__USEOLDINLINES) > > old inlines > > #else > > new inlines > > #endif > > > This should do the job without too much fuss. If I understand correctly, you suggest to add support for both new and old inlines in single "inline" file. This is very simple, IMHO even too simple. "inline" files would grow, so most probably every compilation would take much more time than necessary, both with old and new inlines. Most users won't use g++, so what's the reason in forcing them to have inlines for it? > > I have also some debts if these new inlines should be used only when > > optimizing or always. > Use them always. It's more consistent. So I did. > I assume that the new inlines are at least as good as the old inlines? > I.e., the quality of the generated code should be the same or better > compared to the old inlines. Code quality is slightly better because of two simple reasons, not really connected with the way the inlines have been implemented: 1. List of "clobbered registers" now includes "d0", "d1", "a0" and "a1" only (and things like "cc" and "memory", of course). Perl generator adds also any other registers used as function's arguments - I have no idea what for. 2. In tag-calls, local array is created for all the arguments. Perl script defines array of "struct TagItem", "fd2inline" defines array of ULONGs. Thanks to this, the array is four bytes smaller, because there is no need to allocate space for "ti_TagData" of the last tag (TAG_DONE). But these two improvements can be addeed to old inlines, as well. Actually, old inlines generated my "fd2inline" DO have these two improvements. So if somebody installed new inlines that I've made, [s]he should've also installed old ones, which can be found in the same archive, cause they are different than the ones that can be found in "2.7.0" archives. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 12:30:17 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90557-4>; Thu, 12 Oct 1995 12:29:51 +0200 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id LAA23129 (8.6.12/IDA-1.6 for ); Thu, 12 Oct 1995 11:26:51 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA01188; Thu, 12 Oct 95 11:26:50 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9510121026.AA01188@sunserv.IZFM.Uni-Stuttgart.DE> Subject: ixemul.library recompilation mystery solved To: amiga-gcc-port@nic.funet.fi Date: Thu, 12 Oct 1995 11:26:49 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 375 > that last MOVE.L does not appear to do the same thing. They don't exactly do the same thing but since a0 is not used any more after this instruction they have the same effect: > MOVE.L A0,-(A0) ; 2 byte instruction long *a0,tmp; tmp=(long)a0; *--a0=tmp; > MOVE.L A0,-$4(A0) ; 4 byte instruction long *a0; a0[-1]=(long)a0; Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 12:33:32 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90603-2>; Thu, 12 Oct 1995 12:32:50 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA01324; Thu, 12 Oct 1995 11:34:31 +0100 Date: Thu, 12 Oct 1995 11:34:30 +0100 (MET) From: Kamil Iskra Subject: Re: New includes To: Fred Fish cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 11 Oct 1995, Fred Fish wrote: > Thanks for the details. It will take a while to digest them and I'd > like to take a look at the current files and your new files (please > upload them to the incoming dir on ftp.amigalib.com). That's what I did a few minutes ago. BTW: I remember you saying something about "low bandwich" (sp?) of your FTP connection. Well, 2.4 KB with USA can be hardly called "low bandwich" :-). > > They were automatically generated from OS 3.1 fd-files and clib-files, > > obtained from your CD :-). > > Hmm, that could be a problem. The fd files are included on my CD > under license from the former CBM. If other files are mechanically > derived from those files, I suspect the derived files (inlines) could > be considered to be a derivative work, which might still fall under > the same license terms, which could mean that I could put them on the > CD but they could not (for example) be distributed by ftp or as part > of an aminet gcc release. Well, I'm not an expert in such matters, but I find it hard to believe. Old inlines, generated by Perl script, where created from the same files. Every Amiga compiler that I've seen, including the ones that can be found on Aminet, have their "inlines", "pragmas" or whatever else. And they are of course generated automatically, usually a program used to make them is included in the distribution. Are all those people violating the law? > To be sure I would suggest contacting Amiga Technologies legal staff, > describe in detail what you are proposing, and ask them to render an > opinion on whether or not the derived files are redistributable. > The contact is: [snailmail address erased] Sure, why not, but something like e-mail address would be much better. Does anyone have it? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 12:54:51 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <89951-3>; Thu, 12 Oct 1995 12:53:35 +0200 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id LAA26703 (8.6.12/IDA-1.6 for ); Thu, 12 Oct 1995 11:53:12 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA01274; Thu, 12 Oct 95 11:53:12 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9510121053.AA01274@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: ixemul.library recompilation mystery solved To: amiga-gcc-port@nic.funet.fi Date: Thu, 12 Oct 1995 11:53:10 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 992 > > Ah, this is something I've been meaning to resolve for a while. If > the version distributed with the aminet gcc releases is fully > functional and complete, then I'd have no problem switching over to > that version. > AFAIK it lacks some ancient compatibility functions (32 bit mul/div, etc), but has the advantage that you get a base relative version of the library. > Can whomever created this version detail how it was done, and perhaps > provide whatever "source code" is needed to recreate the library, so I > can integrate it into the GNU Tools tree. > Gunther created it as a part of the libnix package. The glue code is a straightforward compilation of the gnu:os-include/inline/*.h files with '-D__inline -Dextern -O2 -S' set and split into single assembler files with gawk. The most important support functions are added as C (if possible) or assembler (if not) functions. I don't think there should be any problems with integrating it into the GNU source tree. Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 13:04:53 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90260-3>; Thu, 12 Oct 1995 13:04:21 +0200 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id MAA28027 (8.6.12/IDA-1.6 for ); Thu, 12 Oct 1995 12:03:53 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA01320; Thu, 12 Oct 95 12:03:52 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9510121103.AA01320@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Corrections for README-2.7.1 To: amiga-gcc-port@nic.funet.fi Date: Thu, 12 Oct 1995 12:03:52 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 550 > > In the libnix section: > > > * And it's short! I was able to compile a 492 byte 'hello, world' > > using normal main. > > Someone asked me about the exact options to specify to get it that short. > I don't know that, which options were used? > The options used were 'gcc -nostdlib -O3 -s -fbaserel nbcrt0.o helloworld.c libstubs.a' (with the right path used for both the startup code and the library. The file helloworld.c is in the libnix sources under examples/.) But I don't know if the value of 492 bytes is still true :-(. Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 13:06:09 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90368-4>; Thu, 12 Oct 1995 13:05:42 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA02169; Thu, 12 Oct 1995 12:06:55 +0100 Date: Thu, 12 Oct 1995 12:06:54 +0100 (MET) From: Kamil Iskra Subject: New includes To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In my previous postings I've forgotten to write about one thing: There is a conflict between my definitions of resource-bases and proto-definitions (made, as far as I know, by Gunther Nikl). In proto-files resource-bases are declared as "struct Node*". RKM Devices and SAS/C declare them as "struct Library*". I did the same thing. exec.library/OpenResource() returns APTR. So which definition should be used? This is rather important cause the same declarations have to be used everywhere - in proto files, in inlines and in users' programs - otherwise GCC will complain. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 13:28:14 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90557-3>; Thu, 12 Oct 1995 13:27:45 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Thu, 12 Oct 95 12:24:41 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <2170ca04.u8t20e.4df1f-robert@plukwa.lodz.pdi.net> Subject: Re: New includes In-Reply-To: (from Kamil Iskra ) (at Thu, 12 Oct 1995 11:34:30 +0100 (MET)) Reply-To: robert@lodz.pdi.net Content-Length: 1272 To: kiskra@ernie.icslab.agh.edu.pl Cc: amiga-gcc-port@nic.funet.fi Date: Thu, 12 Oct 95 12:24:41 Organization: PDi On Oct 12 Kamil Iskra wrote: > > To be sure I would suggest contacting Amiga Technologies legal staff, > > describe in detail what you are proposing, and ask them to render an > > opinion on whether or not the derived files are redistributable. > > The contact is: > [snailmail address erased] > > Sure, why not, but something like e-mail address would be much better. > Does anyone have it? You can always try peterk@mail.amiga.de and I'm sure dr Peter Kietel will answer by himself or will forward Your letter to right person > > / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ > | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | > | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | > \ PGP public key available via Finger or WWW / > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | ///////// Amiga: The computer for the Creator's mind. \\\\\\\\\\ | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 13:33:41 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <90438-3>; Thu, 12 Oct 1995 13:33:11 +0200 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 12 Oct 1995 12:32:48 +0100 (MET) From: Rask Lambertsen To: Fred Fish Cc: Kamil Iskra , fnf@amigalib.com, amiga-gcc-port@nic.funet.fi Subject: Re: New includes In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 11 Oct 1995, Fred Fish wrote: > > > Are these inline files proprietary in any way? I.E. are they mechanically > > > derived from any Commodore proprietary files. > > > > They were automatically generated from OS 3.1 fd-files and clib-files, > > obtained from your CD :-). > > Hmm, that could be a problem. The fd files are included on my CD > under license from the former CBM. If other files are mechanically > derived from those files, I suspect the derived files (inlines) could > be considered to be a derivative work, which might still fall under > the same license terms, which could mean that I could put them on the > CD but they could not (for example) be distributed by ftp or as part > of an aminet gcc release. What about the old-style inlines? Aren't they generated/derived from C= proprietary files too? Maybe the problem isn't too big, as anybody can generate the new-style inline headers with the "fd2inline" programme and file available by FTP. (I'm sort of left with the feeling that I've missed something.) Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 13:42:55 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <90360-1>; Thu, 12 Oct 1995 13:42:06 +0200 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 12 Oct 1995 12:39:41 +0100 (MET) From: Rask Lambertsen To: Thomas Walter Cc: kiskra@ernie.icslab.agh.edu.pl, stieber@informatik.tu-muenchen.de, amiga-gcc-port@nic.funet.fi Subject: Re: New includes In-Reply-To: <9510111558.AA07459@pctc.chemie.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 11 Oct 1995, Thomas Walter wrote: > Hello ! > I read the mails about new inlines and old inlines. Now there is a mail saying > g++ can only work with the old inlines. I think this is a very very important point > because C++ gives the user some more and better and easier ways to something than in C. > > So I would say: > change only to the new inlines if it is possible to use it with C++/g++ > or do it in a compatible way !!!!!!!!!! The solution is to use new inlines for C and old inlines for C++. Due to the big advantages of the new inline over the old inlines, the new inlines will be used for C. Using the right inline headers will be handled by the header files in "os-include/proto". So compatibility should be assured. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 13:54:03 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <90446-1>; Thu, 12 Oct 1995 13:53:04 +0200 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 12 Oct 1995 12:45:04 +0100 (MET) From: Rask Lambertsen To: Hans Verkuil Cc: iskra@student, amiga-gcc-port@nic.funet.fi Subject: Re: New includes In-Reply-To: <9510100728.09xe@wyst.hobby.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Oct 1995, Hans Verkuil wrote: > According to Kamil Iskra: > > I have also some debts if these new inlines should be used only when > > optimizing or always. They work even when no optimizing, but code quality > > is very poor, much poorer than when using library stubs. On the other > > hand, new inlines support locale library base (see above), which library > > stubs do not - so program that uses local library bases would always have > > to be compiled with -O. On the other hand, that's true for old inlines, > > too. I'm not sure what to do with this one, so I'm waiting for your > > advice, too. > > Use them always. It's more consistent. I agree here. If you are not telling the compiler to optimize, what sort of code quality can you expect anyway? I don't think we should be too concerned about code quality if optimization is no turned on, simply because if you want better code quality, you *will* be using optimization. > > This will not be "the last word" about inlines. Still to implement are > > "narrower lists of clobbered registers" (exec.library/Forbid() etc), > > "library base in any address register" (math functions from > > utility.library) and "no memory clobbering" (quite a lot of functions, > > "tricky" work cause in most cases it's hard to decide how to clasify a > > function (BTW: thanx to Rask Lambertsen for his help)). Hope I haven't > > forgot about anything :-). > > I assume that the new inlines are at least as good as the old inlines? > I.e., the quality of the generated code should be the same or better > compared to the old inlines. I don't see how they can be worse. Maybe they'll even be better if the compiler can now figure out that it doesn't need to reload the library base for each library call. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 14:01:12 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with SMTP id <90684-3>; Thu, 12 Oct 1995 14:00:25 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id MAA06691 (8.6.12/7.4g-FAU);; Thu, 12 Oct 1995 12:51:15 +0100 Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA25810; Thu, 12 Oct 1995 13:51:03 +0200 Date: Thu, 12 Oct 1995 13:51:03 +0200 Message-Id: <9510121151.AA25810@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: kiskra@ernie.icslab.agh.edu.pl Cc: hans@wyst.hobby.nl, amiga-gcc-port@nic.funet.fi In-Reply-To: (message from Kamil Iskra on Thu, 12 Oct 1995 11:21:17 +0100 (MET)) Subject: Re: New includes Hello ! You said there would be a longer compile time if you do it like the following: [ start of part of old message ] > Why not use one header with the following structure: > > #if defined(__cplusplus) || defined(__USEOLDINLINES) > > old inlines > > #else > > new inlines > > #endif > > > This should do the job without too much fuss. If I understand correctly, you suggest to add support for both new and old inlines in single "inline" file. This is very simple, IMHO even too simple. "inline" files would grow, so most probably every compilation would take much more time than necessary, both with old and new inlines. Most users won't use g++, so what's the reason in forcing them to have inlines for it? [snip the rest] I would suggest (perhaps the original author intention is the same): #if defined(__cplusplus) || defined(__USEOLDINLINES) #include #else #include #endif Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de ----- May The Schwartz Be With You ("Spaceballs") ----- From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 15:50:33 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90184-3>; Thu, 12 Oct 1995 15:48:26 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id OAA05776; Thu, 12 Oct 1995 14:44:04 +0100 Date: Thu, 12 Oct 1995 14:44:03 +0100 (MET) From: Kamil Iskra Subject: Re: New includes To: Thomas Walter cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9510121151.AA25810@pctc.chemie.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 12 Oct 1995, Thomas Walter wrote: > I would suggest (perhaps the original author intention is the same): > > #if defined(__cplusplus) || defined(__USEOLDINLINES) > #include > #else > #include > #endif That's almost exactly what I did - please have a look at "fd2inline.lha" archive, which can be found on my WWW home page. I also uploaded it to colombo, thinking that Philippe would put it in "beta" directory, but apparently he hasn't done so (I know - the baby :-). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 17:56:54 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90900-2>; Thu, 12 Oct 1995 17:56:12 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t3Q2M-0004nYC; Thu, 12 Oct 95 08:59 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ixemul.library recompilation mystery solved To: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Date: Thu, 12 Oct 1995 08:59:13 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9510121053.AA01274@sunserv.IZFM.Uni-Stuttgart.DE> from "Matthias Fleischer" at Oct 12, 95 11:53:10 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 757 > AFAIK it lacks some ancient compatibility functions (32 bit mul/div, etc), > but has the advantage that you get a base relative version of the library. Sounds good. > Gunther created it as a part of the libnix package. > The glue code is a straightforward compilation of the > gnu:os-include/inline/*.h files with '-D__inline -Dextern -O2 -S' > set and split into single assembler files with gawk. > The most important support functions are added as C (if possible) > or assembler (if not) functions. > I don't think there should be any problems with integrating it > into the GNU source tree. OK. I would need a pointer to a complete and ready-to-compile source tree, or perhaps have it uploaded to the incoming directory on ftp.amigalib.com. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 18:29:20 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90446-4>; Thu, 12 Oct 1995 18:28:25 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t3QXy-0004nYC; Thu, 12 Oct 95 09:31 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New includes To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Thu, 12 Oct 1995 09:31:54 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish), amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: from "Kamil Iskra" at Oct 12, 95 11:34:30 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1202 > That's what I did a few minutes ago. BTW: I remember you saying something > about "low bandwich" (sp?) of your FTP connection. Well, 2.4 KB with USA > can be hardly called "low bandwich" :-). It is low bandwidth when you consider we have been waiting almost 3 months for our T1 connection to be installed. :-( The good news is that they are due to come out *today* and finish installing the line (and fill in the holes they've dug all around here). > Well, I'm not an expert in such matters, but I find it hard to believe. I'm not an expert either, but determining whether something is or is not a derivative work as described by copyright law can be tricky. > Every Amiga compiler that I've seen, including the ones that can be found > on Aminet, have their "inlines", "pragmas" or whatever else. And they are > of course generated automatically, usually a program used to make them is > included in the distribution. Are all those people violating the law? Possibly. Perhaps someone on this list knows a friendly lawyer with experience in copyright matters that they can get an informal opinion out of. But the safest route would be to clear it directly with the copyright owner. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 18:31:34 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90885-4>; Thu, 12 Oct 1995 18:31:21 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t3Qai-0004nYC; Thu, 12 Oct 95 09:34 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New includes To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Thu, 12 Oct 1995 09:34:43 -0700 (MST) Cc: fnf@amigalib.com, kiskra@ernie.icslab.agh.edu.pl, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Oct 12, 95 12:32:48 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 237 > What about the old-style inlines? Aren't they generated/derived from > C= proprietary files too? Probably. I haven't paid too much attention to this because at least for my CD distributions I'm covered by my existing license. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 18:37:21 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90438-3>; Thu, 12 Oct 1995 18:36:29 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t3Qfv-0004nYC; Thu, 12 Oct 95 09:40 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Octave To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Thu, 12 Oct 1995 09:40:07 -0700 (MST) Cc: fnf@amigalib.com, frv95tjn@legolas.mdh.se, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Oct 12, 95 09:27:00 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 931 > > of memory. You also have to be sure you have the linker that has my > > changes to split reloc sections that are larger than 64K entries or > > AmigaDOS will refuse to run the executable. > > Wouldn't it be possible to use sobja to convert all the object files to > Amiga format and then use an AmigaDOS format linker? When I first stumbled over this limitation in the Amiga OS I wrote a synthetic test case (easy to do) that generated a source file that had more than 64K objects that would require relocation, and used SAS/C to build an executable. The system refused to run that executable. This is an Amiga OS limitation (not a linker problem) that can be worked around by splitting large reloc hunks into several smaller ones. If you have the linker source, it is a fairly trivial fix, or at least was for the 1.8.X linker. For the bfd based linker, it might be more complicated, but probably not by a lot. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 18:50:21 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90885-4>; Thu, 12 Oct 1995 18:48:21 +0200 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id RAA22453 (8.6.12/IDA-1.6); Thu, 12 Oct 1995 17:47:37 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA02310; Thu, 12 Oct 95 17:47:37 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9510121647.AA02310@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: ixemul.library recompilation mystery solved To: fnf@amigalib.com (Fred Fish) Date: Thu, 12 Oct 1995 17:47:36 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Fred Fish" at Oct 12, 95 08:59:13 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 556 > > OK. I would need a pointer to a complete and ready-to-compile source tree, > or perhaps have it uploaded to the incoming directory on ftp.amigalib.com. > Get the file dev/gcc/libnixV1_0.lha off Aminet (e.g. ftp.uni-stuttgart.de carries a copy - I checked it) then extract gnu/libnix-sources.lha. Extract all files sources/amiga/* to a place with a lot of space (building the glue code produces about 1600 files temporarily!) and run the makefile. Be prepared that it takes some time (about two days on my 7MHz 68000 ;-) ). Hope it helps. Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 19:34:30 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90023-2> convert rfc822-to-8bit; Thu, 12 Oct 1995 19:32:28 +0200 Received: from achilles.noc.ntua.gr by funet.fi with SMTP (PP); Thu, 12 Oct 1995 19:32:12 +0200 Original-Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id TAA05152 at Thu, 12 Oct 1995 19:30:30 +0200 PP-warning: Illegal Received field on preceding line Original-Received: by softlab.ece.ntua.gr with UUCP id TAA04797 at Thu, 12 Oct 1995 19:35:13 +0200 PP-warning: Illegal Received field on preceding line Received: by kriton.UUCP (V1.17-beta/Amiga) id <08l2@kriton.UUCP>; Thu, 12 Oct 95 19:21:48 EET Date: Thu, 12 Oct 95 19:21:48 EET Message-Id: <9510121721.08l2@kriton.UUCP> In-Reply-To: (from Kristof Depraetere ) (at Wed, 11 Oct 1995 20:32:21 +0100 (MET)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT Content-Length: 573 From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!rug.ac.be!Kristof.Depraetere@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Updating makeinfo1.55 Hi Kristof (Kristof Depraetere), in on Oct 11 you wrote: > With the makeinfo from mkguide you can choose between AmigaGuide v34 and > v39 support. Should I leave the v34 in or can I remove it? Please leave it in. There are many people who are still using 2.x. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Anything that's not impossible is merely waiting to happen." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 20:48:00 1995 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with SMTP id <90480-3>; Thu, 12 Oct 1995 20:46:33 +0200 Received: from zetor.clinet.fi (root@zetor.clinet.fi [193.64.6.8]) by hauki.clinet.fi (8.6.12/8.6.4) with ESMTP id UAA15515 for ; Thu, 12 Oct 1995 20:46:26 +0200 From: Ville-Pertti Keinonen Received: (will@localhost) by zetor.clinet.fi (8.6.10/8.6.4) id UAA01351; Thu, 12 Oct 1995 20:46:25 +0200 Date: Thu, 12 Oct 1995 20:46:25 +0200 Message-Id: <199510121846.UAA01351@zetor.clinet.fi> To: amiga-gcc-port@nic.funet.fi Subject: Soft float Does anybody here know where to look for sources (C or '020+ asm, preferably directly functional as gcc linked functions) for fast software ieee floating point operations? Some code was included with the gcc sources (libfloat.c), but it was only single precision. It didn't quite seem to work, either (probably just my fault). From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 20:53:35 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90833-4>; Thu, 12 Oct 1995 20:53:12 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26499-2>; Thu, 12 Oct 1995 19:52:37 +0100 Received: from hphalle6j.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395717-2>; Thu, 12 Oct 1995 19:52:36 +0100 Subject: Re: New includes From: Christian Stieber To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Thu, 12 Oct 1995 19:52:25 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Oct 12, 95 12:06:54 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 897 Message-Id: <95Oct12.195236+0100mesz.395717-2+1679@hphalle0.informatik.tu-muenchen.de> > There is a conflict between my definitions of resource-bases and > proto-definitions (made, as far as I know, by Gunther Nikl). In > proto-files resource-bases are declared as "struct Node*". RKM Devices and > SAS/C declare them as "struct Library*". I did the same thing. > exec.library/OpenResource() returns APTR. So which definition should be > used? AFAIK, the minimum thing required for a resource is a Node. However, many resources use a struct Library. IMHO "Node" should be the correct definition. But then, the C= includes aren't always using the "minimum" required (like the node functions, which often work with MinNodes). Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Thu Oct 12 22:17:42 1995 Received: from k332.feld.cvut.cz ([147.32.192.12]) by nic.funet.fi with SMTP id <90347-2>; Thu, 12 Oct 1995 22:00:29 +0200 Received: (from utx@localhost) by k332.feld.cvut.cz (8.6.10/8.6.9) id VAA02304 for amiga-gcc-port@nic.funet.fi; Thu, 12 Oct 1995 21:01:27 +0100 Date: Thu, 12 Oct 1995 21:01:27 +0100 From: Stanislav Brabec Message-Id: <199510122001.VAA02304@k332.feld.cvut.cz> To: amiga-gcc-port@nic.funet.fi Subject: sh still not correct I have loaded last ixemul.library 41.4 I have following stupid script: #!/bin/sh PS1=amiga$ export PS1 echo "Script terminated with PS1=$PS1" Amiga prompts: # Variable seems to be not exported. Is it? see /etc/profile -- reading this, you can find, that it is: either not executed or all variables are lost. -- Stanislav From amiga-gcc-port-owner@nic.funet.fi Fri Oct 13 00:41:39 1995 Received: from hookomo.aloha.net ([204.94.112.33]) by nic.funet.fi with SMTP id <90834-4>; Fri, 13 Oct 1995 00:40:49 +0200 Received: (from newsham@localhost) by hookomo.aloha.net (8.6.12/8.6.9) id MAA20031 for amiga-gcc-port@nic.funet.fi; Thu, 12 Oct 1995 12:39:20 -1000 From: Timothy Newsham Message-Id: <199510122239.MAA20031@hookomo.aloha.net> Subject: make - problems? To: amiga-gcc-port@nic.funet.fi Date: Thu, 12 Oct 1995 12:39:20 -1000 (HST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 524 Hi, I always get this when quite a ways into a large make: Abort trap - /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cc1 /t/cc180776.i -mgcc: Internal compiler error: program cc1 got fatal signal 6 when I rerun make of course evertything works fine (for a while). I am using an '030 with 1meg chip, 4 megs/16 and 5megs/32. The 16 bit board is a gvp series II (I know it has problems w/ MMU but other than that hadn't heard of problems). My stack is set at 500000. Tim N. From amiga-gcc-port-owner@nic.funet.fi Fri Oct 13 12:27:28 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90337-1>; Fri, 13 Oct 1995 12:21:39 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 13 Oct 1995 11:20:51 +0100 (MET) From: Rask Lambertsen To: Fred Fish Cc: frv95tjn@legolas.mdh.se, amiga-gcc-port@nic.funet.fi Subject: Re: Octave In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 12 Oct 1995, Fred Fish wrote: > > > of memory. You also have to be sure you have the linker that has my > > > changes to split reloc sections that are larger than 64K entries or > > > AmigaDOS will refuse to run the executable. > > > > Wouldn't it be possible to use sobja to convert all the object files to > > Amiga format and then use an AmigaDOS format linker? > > When I first stumbled over this limitation in the Amiga OS I wrote a > synthetic test case (easy to do) that generated a source file that > had more than 64K objects that would require relocation, and used > SAS/C to build an executable. The system refused to run that executable. Could you send me the source for that synthetic test case? I'd like to try it out with various linkers to see how they deal with it. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Fri Oct 13 13:11:41 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90360-2>; Fri, 13 Oct 1995 13:10:48 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA21670; Fri, 13 Oct 1995 12:12:05 +0100 Date: Fri, 13 Oct 1995 12:12:04 +0100 (MET) From: Kamil Iskra Subject: Re: New includes To: Rask Lambertsen cc: Hans Verkuil , amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 12 Oct 1995, Rask Lambertsen wrote: > On Tue, 10 Oct 1995, Hans Verkuil wrote: > > I assume that the new inlines are at least as good as the old inlines? > > I.e., the quality of the generated code should be the same or better > > compared to the old inlines. > > I don't see how they can be worse. Maybe they'll even be better if the > compiler can now figure out that it doesn't need to reload the library > base for each library call. ??? Why do you think it can now figure out such a thing? The only solution seems to be removing "memory" clobbering from functions which _most_probably_ don't need it, but this is not implemented yet. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Oct 13 13:28:45 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90344-4>; Fri, 13 Oct 1995 13:26:53 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 13 Oct 1995 12:20:01 +0100 (MET) From: Rask Lambertsen To: Kamil Iskra Cc: Hans Verkuil , amiga-gcc-port@nic.funet.fi Subject: Re: New includes In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 13 Oct 1995, Kamil Iskra wrote: > On Thu, 12 Oct 1995, Rask Lambertsen wrote: > > > On Tue, 10 Oct 1995, Hans Verkuil wrote: > > > I assume that the new inlines are at least as good as the old inlines? > > > I.e., the quality of the generated code should be the same or better > > > compared to the old inlines. > > > > I don't see how they can be worse. Maybe they'll even be better if the > > compiler can now figure out that it doesn't need to reload the library > > base for each library call. > > ??? Why do you think it can now figure out such a thing? The only solution > seems to be removing "memory" clobbering from functions which > _most_probably_ don't need it, but this is not implemented yet. I thought the new inline headers had "memory" removed from some of the calls. The code should still be at least as good as with the old inline headers Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Fri Oct 13 14:12:54 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <90023-1>; Fri, 13 Oct 1995 14:10:42 +0200 Received: from tiny.lysator.liu.se (tiny.lysator.liu.se [130.236.253.10]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id NAA10638; Fri, 13 Oct 1995 13:10:06 +0100 Received: (nisse@localhost) by tiny.lysator.liu.se (8.6.11/8.6.11) id NAA21209; Fri, 13 Oct 1995 13:09:59 +0100 Date: Fri, 13 Oct 1995 13:09:59 +0100 Message-Id: <199510131209.NAA21209@tiny.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: Ville-Pertti Keinonen Cc: amiga-gcc-port@nic.funet.fi In-reply-to: Ville-Pertti Keinonen's message of Thu, 12 Oct 1995 20:46:25 +0200 Subject: Re: Soft float References: <199510121846.UAA01351@zetor.clinet.fi> Ville-Pertti Keinonen writes: Does anybody here know where to look for sources (C or '020+ asm, preferably directly functional as gcc linked functions) for fast software ieee floating point operations? Some code was included with the gcc sources (libfloat.c), but it was only single precision. It didn't quite seem to work, either (probably just my fault). Do you really need this? If I have understood things correctly, ixemul call the IEEE*.library functions for you. They should be fairly efficient, and also uses the floating point support in a 68881 or 68040 if one happens to be present. (Hmm, not sure how libnix does this, probably in a similar way). Or do you want the floating point code to run on some other kind of machine? From amiga-gcc-port-owner@nic.funet.fi Fri Oct 13 23:39:25 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90521-1>; Fri, 13 Oct 1995 23:34:51 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t3rok-0004nYC; Fri, 13 Oct 95 14:39 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Octave To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Fri, 13 Oct 1995 14:39:01 -0700 (MST) Cc: fnf@amigalib.com, frv95tjn@legolas.mdh.se, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Oct 13, 95 11:20:51 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 539 > Could you send me the source for that synthetic test case? I'd like to > try it out with various linkers to see how they deal with it. Sorry, I think I tossed it after I used it. It was a 10 minute hack anyway. Something like: main () { int i; printf ("main {\n"); for (i = 0; i < (65 * 1024); i++) { printf ("foo%d ();\n", i); } for (i = 0; i < (65 * 1024); i++) { printf ("foo%d {}\n", i); } } Then compile and run this like: gcc -o gentest gentest.c gentest >junk.c gcc -o junk junk.c junk -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Oct 14 02:13:50 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90123-3>; Sat, 14 Oct 1995 02:01:52 +0200 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0t3uHx-000QyJC; Sat, 14 Oct 95 01:17 MET Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0t3tBw-000G32C; Sat, 14 Oct 95 00:07 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <09zs@wyst.hobby.nl>; Fri, 13 Oct 95 23:07:36 CET Message-Id: <9510132207.09zs@wyst.hobby.nl> Date: Fri, 13 Oct 1995 22:07:34 +0000 (CET) In-Reply-To: from "Kamil Iskra" at Oct 12, 95 11:21:17 am Content-Type: text Content-Length: 1309 From: hans@wyst.hobby.nl (Hans Verkuil) To: kiskra@ernie.icslab.agh.edu.pl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: New includes According to Kamil Iskra: > On Tue, 10 Oct 1995, Hans Verkuil wrote: > > > Why not use one header with the following structure: > > > > #if defined(__cplusplus) || defined(__USEOLDINLINES) > > > > old inlines > > > > #else > > > > new inlines > > > > #endif > If I understand correctly, you suggest to add support for both new and old > inlines in single "inline" file. This is very simple, IMHO even too > simple. "inline" files would grow, so most probably every compilation > would take much more time than necessary, both with old and new inlines. > Most users won't use g++, so what's the reason in forcing them to have > inlines for it? You're right. Note that my mail was held up somewhere, so when you read it it was a bit out of date. It's just that I dislike creating yet another directory, but in this case it's the best solution. > Code quality is slightly better because of two simple reasons, not really > connected with the way the inlines have been implemented: Great! Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 08:35:45 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89777-2>; Mon, 16 Oct 1995 08:32:46 +0200 Received: from pobox.csc.fi by funet.fi with SMTP (PP); Sat, 14 Oct 1995 16:18:58 +0200 Received: from ns.neckar-alb.de (root@ns.s-1.de.contrib.net [194.77.118.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id OAA06514 for ; Sat, 14 Oct 1995 14:17:30 GMT Received: from wiedmann.neckar-alb.de (wiedmann@wiedmann.neckar-alb.de [194.77.119.253]) by ns.neckar-alb.de (8.6.9/8.6.9) with ESMTP id PAA14411; Sat, 14 Oct 1995 15:15:50 +0100 Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id PAA00258; Sat, 14 Oct 1995 15:15:52 +0100 From: wiedmann Message-Id: <199510141415.PAA00258@wiedmann.neckar-alb.de> Subject: Re: New includes To: hans@wyst.hobby.nl (Hans Verkuil) Date: Sat, 14 Oct 1995 15:15:51 +0100 (MET) Cc: kiskra@ernie.icslab.agh.edu.pl, amiga-gcc-port@nic.funet.fi In-Reply-To: <9510132207.09zs@wyst.hobby.nl> from "Hans Verkuil" at Oct 13, 95 10:07:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1079 > According to Kamil Iskra: > > > On Tue, 10 Oct 1995, Hans Verkuil wrote: > > > > > Why not use one header with the following structure: > > > > > > #if defined(__cplusplus) || defined(__USEOLDINLINES) > > > > > > old inlines > > > > > > #else > > > > > > new inlines > > > > > > #endif > > > If I understand correctly, you suggest to add support for both new and old > > inlines in single "inline" file. This is very simple, IMHO even too > > simple. "inline" files would grow, so most probably every compilation > > would take much more time than necessary, both with old and new inlines. > > Most users won't use g++, so what's the reason in forcing them to have > > inlines for it? > > You're right. Note that my mail was held up somewhere, so when you read it > it was a bit out of date. It's just that I dislike creating yet another > directory, but in this case it's the best solution. No. Why shouldn't the above code be part of the "proto" files? And why shouldnt't new inlines be a part of the same directory, using different names, of course? Jochen From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 08:35:50 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89320-1>; Mon, 16 Oct 1995 08:30:37 +0200 Received: from hauki.clinet.fi (actually user root@hauki.clinet.fi) by funet.fi with SMTP (PP); Sat, 14 Oct 1995 09:14:29 +0200 Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.6.12/8.6.4) with ESMTP id JAA14020; Sat, 14 Oct 1995 09:13:10 +0200 From: Ville-Pertti Keinonen Received: (will@localhost) by katiska.clinet.fi (8.6.12/8.6.4) id JAA01180; Sat, 14 Oct 1995 09:13:09 +0200 Date: Sat, 14 Oct 1995 09:13:09 +0200 Message-Id: <199510140713.JAA01180@katiska.clinet.fi> To: nisse@lysator.liu.se CC: amiga-gcc-port@nic.funet.fi In-reply-to: <199510131209.NAA21209@tiny.lysator.liu.se> (message from Niels M|ller on Fri, 13 Oct 1995 13:09:59 +0100) Subject: Re: Soft float Do you really need this? If I have understood things correctly, ixemul call the IEEE*.library functions for you. They should be fairly efficient, and also uses the floating point support in a 68881 or 68040 if one happens to be present. (Hmm, not sure how libnix does this, probably in a similar way). Or do you want the floating point code to run on some other kind of machine? The AmigaOS math libraries are fine, as long as I'm running AmigaOS... So is ixemul.library, in most ways. But I also use the Amiga-port of gcc as a cross-compiler for my own operating system (I'm currently using simple temporary executable format, so the executables are compiled to Amiga executables and then converted). I've wrote most of the basic C-library functions, including math functions, but the math code is a mess, since it's collected from various sources, some parts work in single or double precision only etc.. And it doesn't seem to work, when I run df (one of the few gnu *utils that require math code), it shows 0% usage on all devices. Obviously, even the most basic functions don't work... So, I'm looking for a complete ieee math library, so I don't need to spend too much time fixing that code (most people probably have FPU's anyhow). From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 08:35:51 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89882-3>; Mon, 16 Oct 1995 08:31:35 +0200 Received: from pobox.csc.fi by funet.fi with SMTP (PP); Sat, 14 Oct 1995 14:29:06 +0200 Received: from wuarchive.wustl.edu (wuarchive.wustl.edu [128.252.135.4]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id MAA03554 for ; Sat, 14 Oct 1995 12:27:47 GMT Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Received: (from umueller@localhost) by wuarchive.wustl.edu (8.6.12/8.6.12) id HAA30860; Sat, 14 Oct 1995 07:25:03 -0500 From: Urban Mueller Message-Id: <199510141225.HAA30860@wuarchive.wustl.edu> Subject: Re: recompiling ixemul.library To: fnf@amigalib.com (Fred Fish) Date: Sat, 14 Oct 1995 07:25:03 -0500 (CDT) Cc: kiskra@ernie.icslab.agh.edu.pl, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Fred Fish" at Oct 10, 95 10:05:41 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 669 > > > BTW, ixemul.trace (at least the 68040+68881 version) was missing from the > > > official distribution. > > > > It seems that it was included with plain 68000 version only. > > This is correct. Several people commented they thought it was a waste > of space to include trace versions for all the different flavors. Agree on that. > > BTW: is this intentional that archives are called "4140" and not "4104"? > > No, that is my fault. They should be 4104. I'll ask Urban to rename them. *Now* I wish they were all in one archive :) Fixed. Right now there are a bit many archives, maybe make one archive for 68000+68020 and one for better CPUs? -Urban From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 08:35:57 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89050-4>; Mon, 16 Oct 1995 08:33:00 +0200 Received: from amigalib.com (actually host fishpond.amigalib.com) by funet.fi with SMTP (PP); Sat, 14 Oct 1995 17:11:40 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t48Gf-0004nYC; Sat, 14 Oct 95 08:12 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: sh still not correct To: utx@k332.feld.cvut.cz (Stanislav Brabec) Date: Sat, 14 Oct 1995 08:12:57 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199510122001.VAA02304@k332.feld.cvut.cz> from "Stanislav Brabec" at Oct 12, 95 09:01:27 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 196 > I have following stupid script: > > #!/bin/sh > PS1=amiga$ > export PS1 > echo "Script terminated with PS1=$PS1" When I do "sh testfile" here I get: Script terminated with PS1=amiga$ -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 08:50:05 1995 Received: from uni-paderborn.de ([131.234.10.3]) by nic.funet.fi with SMTP id <90582-3>; Mon, 16 Oct 1995 08:47:52 +0200 Received: from mises.uni-paderborn.de (mises.uni-paderborn.de [131.234.184.4]) by uni-paderborn.de (8.6.12/8.6.12) with ESMTP id HAA03637 for ; Mon, 16 Oct 1995 07:47:46 +0100 Received: from lange.uni-paderborn.de (lange.uni-paderborn.de [131.234.184.3]) by mises.uni-paderborn.de (8.6.12/8.6.12) with ESMTP id HAA04607 for ; Mon, 16 Oct 1995 07:46:12 +0100 From: Ralph Schmidt Received: (laire@localhost) by lange.uni-paderborn.de (8.6.12/8.6.12) id HAA02563 for amiga-gcc-port@nic.funet.fi; Mon, 16 Oct 1995 07:48:17 +0100 Message-Id: <199510160648.HAA02563@lange.uni-paderborn.de> Subject: ixemul hit To: amiga-gcc-port@nic.funet.fi Date: Mon, 16 Oct 1995 07:48:16 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP2] Content-Type: text Content-Length: 1200 I use the new library on a 060 and it works fine so far but i often get this hit. LONG-READ to 00000DF2 PC: 07DD31AE USP: 07CC9BB4 SR: 0010 FLSW: 01010200 TCB: 07CEE680 Data: 0000003C 08000030 07CC9D4E 07CC9BD7 00000001 07D91D98 000000C0 07CCB5CC Addr: 00000000 080007F8 07D91D98 07CEE680 00000000 07CC9D42 080007F8 07CC9BB4 Stck: 212F676E 752F6C69 622F6763 632D6C69 622F7273 36303030 2F322E36 2E332F63 Stck: 7070002D 6C616E67 2D63202D 756E6465 66202D44 5F5F474E 55435F5F 3D32202D Stck: 445F5F47 4E55435F 4D494E4F 525F5F3D 36202D44 6D633638 30303020 2D44616D Stck: 69676120 2D44616D 69676164 6F73202D 444D4348 5F414D49 4741202D 44414D49 Stck: 4741202D 445F5F6D 63363830 30305F5F 202D445F 5F616D69 67615F5F 202D445F Stck: 5F616D69 6761646F 735F5F20 2D445F5F 4D43485F 414D4947 415F5F20 2D445F5F Stck: 414D4947 415F5F20 2D445F5F 6D633638 30303020 2D445F5F 616D6967 61202D44 Stck: 5F5F616D 69676164 6F73202D 445F5F4D 43485F41 4D494741 202D445F 5F414D49 ----> 07DD31AE - "LIBS:ixemul.library" Hunk 0000 Offset 00015AC6 ----> $07dd31ae: MOVE.L $0df2(A0),$0032(A3) -- Ralph Schmidt laire@mises.uni-paderborn.de University of Paderborn (Germany) From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 09:10:59 1995 Received: from minerva.phyast.pitt.edu ([136.142.111.2]) by nic.funet.fi with SMTP id <90655-3>; Mon, 16 Oct 1995 09:08:53 +0200 Received: from durer.phyast.pitt.edu by minerva.phyast.pitt.edu (4.1/1.34) id AA23594; Mon, 16 Oct 95 03:08:48 EDT Date: Mon, 16 Oct 95 03:08:48 EDT Message-Id: <9510160708.AA23594@minerva.phyast.pitt.edu> Received: by durer.phyast.pitt.edu (4.1/SMI-4.1) id AA03040; Mon, 16 Oct 95 03:15:01 EDT Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: C.DavidShaffer ^-missing end of mailbox From: To: amiga-gcc-port@nic.funet.fi Subject: Re: Soft float Ville-Pertti Keinonen writes > [some text omitted] I've wrote most of > the basic C-library functions, including math functions, but the math > code is a mess, since it's collected from various sources, some parts > work in single or double precision only etc.. And it doesn't seem to > work, when I run df (one of the few gnu *utils that require math > code), it shows 0% usage on all devices. Obviously, even the most > basic functions don't work... So, I'm looking for a complete ieee math > library, so I don't need to spend too much time fixing that code (most > people probably have FPU's anyhow). I don't know if I'm completely off the subject here but...I also use gcc (but not amiga-gcc) as a cross compiler (to produce code for a 68332) and I have had a lot of luck using the "newlib" library for floating point and other stuff. It is essentially an ANSI C library intended for use with gcc. Information on newlib (and newlib itself!) can be found at http://www.cygnus.com/library-dir.html. Let me know if I can be of any help. -David Shaffer -Department of Physics -The University of Pittsburgh -Pittsburgh, PA 15260 -shaffer@phyast.pitt.edu From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 10:08:35 1995 Received: from deneb.dfn.de ([192.76.176.9]) by nic.funet.fi with SMTP id <90752-1>; Mon, 16 Oct 1995 10:06:32 +0200 Received: from mises.uni-paderborn.de by deneb.dfn.de (4.1/SMI-4.2) id AA21024; Mon, 16 Oct 95 09:05:30 +0100 Received: from lange.uni-paderborn.de (lange.uni-paderborn.de [131.234.184.3]) by mises.uni-paderborn.de (8.6.12/8.6.12) with ESMTP id JAA04648 for ; Mon, 16 Oct 1995 09:04:30 +0100 From: Ralph Schmidt Received: (laire@localhost) by lange.uni-paderborn.de (8.6.12/8.6.12) id JAA02614 for amiga-gcc-port@nic.funet.fi; Mon, 16 Oct 1995 09:06:35 +0100 Message-Id: <199510160806.JAA02614@lange.uni-paderborn.de> Subject: GAS-Amiga-Source searched To: amiga-gcc-port@nic.funet.fi Date: Mon, 16 Oct 1995 09:06:35 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP2] Content-Type: text Content-Length: 200 Well..the title says all. I need the GAS AmigaOS sources...a diff would be nice. -- Ralph Schmidt laire@mises.uni-paderborn.de University of Paderborn (Germany) From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 10:24:13 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90891-4>; Mon, 16 Oct 1995 10:22:49 +0200 Received: from ns.neckar-alb.de (wiedmann@ns.s-1.de.contrib.net [194.77.118.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id IAA15793 for ; Mon, 16 Oct 1995 08:22:40 GMT Received: (from wiedmann@localhost) by ns.neckar-alb.de (8.6.9/8.6.9) id JAA16492; Mon, 16 Oct 1995 09:21:23 +0100 From: Jochen Wiedmann Message-Id: <199510160821.JAA16492@ns.neckar-alb.de> Subject: Re: GAS-Amiga-Source searched To: laire@mises.uni-paderborn.de (Ralph Schmidt) Date: Mon, 16 Oct 1995 09:21:23 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199510160806.JAA02614@lange.uni-paderborn.de> from "Ralph Schmidt" at Oct 16, 95 09:06:35 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 341 Hello, Ralph, > Well..the title says all. > I need the GAS AmigaOS sources...a diff would be nice. What"s wrong about ftp://ftp.funet.fi/pub/amiga/gnu/beta/binutils-2.5.2.diffs.gz in combination with the official GNU sources? (I know about the linker problem, but at least the assembler should work fine, AFAIK.) Good luck, Jochen From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 13:07:44 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90563-3>; Mon, 16 Oct 1995 13:05:21 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA03846; Mon, 16 Oct 1995 12:07:12 +0100 Date: Mon, 16 Oct 1995 12:07:10 +0100 (MET) From: Kamil Iskra Subject: Legal status of new inlines To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is a letter that I just got from Dr. Kittel concerning legal status of new inlines: ___beg___ >From peterk@mail.Amiga.DE Mon Oct 16 12:01:36 1995 Date: Mon, 16 Oct 1995 10:45:24 +0100 (MET) From: "Dr. Peter Kittel" To: iskra@student.uci.agh.edu.pl Subject: Re: Legal problem > > I am writing to you because of a legal problem I came across recently. Thanks for bothering to ask before doing it. > I am using GNU C compiler ported to AmigaDOS, version 2.7.0. For Amiga > support this compiler needs so-called "inlines", which perform direct > calls to Amiga resident libraries. > > I recently created a new version of them. They were created automatically, > using a special parsing program, from fd-files and clib-files (includes) > found on Fred Fish's CD ROM (part of NDUK v40). No problem with this. They are your work and not identical to anything of our copyright, though created from such. > My question is: can these inline-files be distributed by FTP servers? I > personally think that they can, cause no part of either "fd" or "clib" > files are included - "inlines" use only some data found in the source > files, but have completely different syntax. Indeed. ___end___ / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 14:12:10 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90813-3>; Mon, 16 Oct 1995 14:09:57 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA05484; Mon, 16 Oct 1995 13:10:41 +0100 Date: Mon, 16 Oct 1995 13:10:40 +0100 (MET) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: New includes To: wiedmann cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199510141415.PAA00258@wiedmann.neckar-alb.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Sat, 14 Oct 1995, wiedmann wrote: > > > > #if defined(__cplusplus) || defined(__USEOLDINLINES) > > > > > > > > old inlines > > > > > > > > #else > > > > > > > > new inlines > > > > > > > > #endif > Why shouldn't the above code be part of the "proto" files? Actually it IS there, and was from the very beginning. This is not for you only, and is not supposed to offend anybody: Before posting something about new includes, PLEASE have a look at them FIRST. It's not the first letter in which I have to clarify (sp?) sth. which would be clear for everybody who had a look at new includes. Maybe all this mess is because of poor availability of new includes. Well, I know that recently HTTP Daemon on my university more ofter does NOT work than it DOES work. So I beg Philippe: if you read this, PLEASE put "fd2inline.lha" in "/pub/aminet-gnu/beta" directory of colombo and maybe also in equivalent one on funet. Please also send a message to this list - I guess that the subscribers will read your posting more carefully than mine (especially since I've been posting so many of them recently :-). > And why > shouldnt't new inlines be a part of the same directory, using different names, > of course? Why? I don't know why :-) I think it's not bad idea, of course it's rather easy to implement. But what other people think about it? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://www.uci.agh.edu.pl/student/infgrp/iskra/public_html | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 16:08:57 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90238-3>; Mon, 16 Oct 1995 16:06:40 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA26701 (5.65c8/IDA-1.4.4 for ); Mon, 16 Oct 1995 15:05:08 +0100 Received: by diva.gmd.de id AA00437 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Mon, 16 Oct 1995 15:02:18 +0100 Date: Mon, 16 Oct 1995 15:02:18 +0100 From: Joerg Hoehle Message-Id: <199510161402.AA00437@diva.gmd.de> To: amiga-gcc-port@nic.funet.fi Subject: Re: New includes Kamil wrote: > > On Tue, 10 Oct 1995, Hans Verkuil wrote: > > > I assume that the new inlines are at least as good as the old inlines? ... > ??? Why do you think it can now figure out such a thing? The only solution > seems to be removing "memory" clobbering from functions which > _most_probably_ don't need it, but this is not implemented yet. The solution should be to add a const keyword before the definition of the ExecBase, DOSBase etc. so that the compilers knows that these won't change, shouldn't it? Joerg. From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 17:28:35 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90380-4>; Mon, 16 Oct 1995 17:03:32 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t4r4q-0004nYC; Mon, 16 Oct 95 08:03 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Soft float To: will@clinet.fi (Ville-Pertti Keinonen) Date: Mon, 16 Oct 1995 08:03:44 -0700 (MST) Cc: nisse@lysator.liu.se, amiga-gcc-port@nic.funet.fi In-Reply-To: <199510140713.JAA01180@katiska.clinet.fi> from "Ville-Pertti Keinonen" at Oct 14, 95 09:13:09 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1539 > work in single or double precision only etc.. And it doesn't seem to > work, when I run df (one of the few gnu *utils that require math > code), it shows 0% usage on all devices. Obviously, even the most > basic functions don't work... I don't know what version of df you are running but I just tried the version of df on FreshFish 10 on both my A4000 (with fpu ixemul.library) and on my A2000 (with soft-float ixemul.library) and it works fine. Here is the A2000 output: Filesystem 1024-blocks Used Available Capacity Mounted on /FreshFish-Vol10 665836 665836 0 100% /CD0 /Ram Disk 49 49 0 100% /RAM /WB3.1-x 10254 4417 5837 43% /HD60 /j 879 99 780 11% /DF0 /WB_2.04 15575 2586 12989 17% /HD50 /WB_2.04-ref 15575 2549 13026 16% /HD51 /x2 15575 6 15569 0% /HD52 /x3 15575 6 15569 0% /HD53 /x4 15575 6 15569 0% /HD54 /x5 15575 6 15569 0% /HD55 /x6 15575 6 15569 0% /HD56 /x7 15575 144 15431 1% /HD57 /x8 15575 1269 14306 8% /HD58 /FF10 63955 20 63935 0% /HD59 /WB3.0 10254 3666 6588 36% /HD61 /Work 61424 39526 21898 64% /HD62 -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Oct 16 19:12:32 1995 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with SMTP id <90326-4>; Mon, 16 Oct 1995 19:10:48 +0200 Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.6.12/8.6.4) with ESMTP id TAA28513; Mon, 16 Oct 1995 19:10:36 +0200 Received: (will@localhost) by katiska.clinet.fi (8.6.12/8.6.4) id TAA11037; Mon, 16 Oct 1995 19:10:35 +0200 Date: Mon, 16 Oct 1995 19:10:35 +0200 Message-Id: <199510161710.TAA11037@katiska.clinet.fi> From: Ville-Pertti Keinonen To: fnf@amigalib.com CC: amiga-gcc-port@nic.funet.fi In-reply-to: (fnf@amigalib.com) Subject: Re: Soft float I don't know what version of df you are running but I just tried the version of df on FreshFish 10 on both my A4000 (with fpu ixemul.library) If you'd read the message more carefully, you might have noticed that I was speaking about floating point functions in general, *not* ixemul.library. ixemul uses the AmigaOS math libraries, so there's no reason for it not to work fine, but there are also no sources to look at. Filesystem 1024-blocks Used Available Capacity Mounted on /FreshFish-Vol10 665836 665836 0 100% /CD0 /Ram Disk 49 49 0 100% /RAM ...etc... BTW: doesn't that output look sort of illogical? I think the filesystem and mounted on fields are the wrong way around. Although dos.library (unfortunately) hardly deals with devices like UNIX systems, I would think the device name would be more of an equivalent value for the UNIX device name in the filesystem field than the name of the volume. (Give an appropriate, lowercase name to the device and put /dev in front of it, and you have a name that looks perfect!) I think I've even mentioned this "problem" earlier. From amiga-gcc-port-owner@nic.funet.fi Tue Oct 17 11:59:05 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <90043-3>; Tue, 17 Oct 1995 11:54:03 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id KAA16291 for ; Tue, 17 Oct 1995 10:47:26 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA19066; Tue, 17 Oct 95 10:52:47 GMT Date: Tue, 17 Oct 95 10:52:47 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9510171052.AA19066@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: binutils-1.8.x FSF Source Hi, I'm looking for original archive of binutils-1.8.x. Could someone tells me where I can found them ?? Thanks. \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Tue Oct 17 12:16:28 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90614-2>; Tue, 17 Oct 1995 12:12:17 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA13644; Tue, 17 Oct 1995 11:12:38 +0100 Date: Tue, 17 Oct 1995 11:12:37 +0100 (MET) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: New new inlines :-) To: Amiga GCC List cc: phb@colombo.telesys-innov.fr, fnf@amigalib.com, hoehle@zeus.gmd.de Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I just put new version of "fd2inline" together with inlines and protos on my WWW HomePage and also uploaded it to appropriate directories at "colombo" and "amigalib". What has changed since the previous version: - Declarations of library bases in "proto" and "inline"/"inline++" files are now fully comatible. This ivolved two corrections in "proto" files ("Library" -> "RxsLib" in "rexxsyslib.h" and "Node" -> "DiskResource" in "disk.h") and about 10 corrections in inline files ("Library" -> "Node" in resource-files and "Library" -> "Device" in device-files). - Diffs for FD-file "amigaguide_lib.fd" are included - original one was simply buggy and without this patch "inlines" of "amigaguide.library" wouldn't be accepted by the compiler (or at least wouldn't work as expected). - Fixed "makefile": now "pure" bit is set automatically. What has NOT changed: New inlines are in "inline" directory and old in "inline++" directory. This won't change until an egreement is reached. I don't say that there is a disagreement - there is simply more than one idea, yet only one can be implemented... P.S. Server on my university again works incorrectly so I don't receive e-mail sent to address "kiskra@ernie.icslab.[...]". If somebody has sent me a private mail, please resent it to address "iskra@student.uci.[...]". P.S.2. I've just uploaded whole archive of amiga-gcc-port from this year and read the messages which I haven't received. Below is some kind of answer to Joerg's posting: > > ??? Why do you think it can now figure out such a thing? The only solution > > seems to be removing "memory" clobbering from functions which > > _most_probably_ don't need it, but this is not implemented yet. > The solution should be to add a const keyword before the definition of > the ExecBase, DOSBase etc. so that the compilers knows that these won't > change, shouldn't it? One would think it should, but actually it doesn't help at all. Too pesimistic optimizer? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / P.S.3 Note new WWW address. From amiga-gcc-port-owner@nic.funet.fi Tue Oct 17 12:28:28 1995 Received: from uni-kl.de ([131.246.136.50]) by nic.funet.fi with SMTP id <90823-2>; Tue, 17 Oct 1995 12:26:25 +0200 Received: from uklirb.informatik.uni-kl.de by stepsun.uni-kl.de id ac25906; 17 Oct 95 11:26 MET Received: from kerry.informatik.uni-kl.de by uklirb.informatik.uni-kl.de id aa06798; 17 Oct 95 11:18 MET Date: Tue, 17 Oct 95 6:10:13 EDT From: Frank Bernard To: amiga-gcc-port@nic.funet.fi Subject: How can I unsubscribe ??? Message-ID: <9510170610.aa21497@kerry.informatik.uni-kl.de> Hello ! Could anyone tell me, how I can unsubscribe the GCC-Mailing-List ?? Thanx in advance ! Ciao // Frank \X/ bernard@informatik.uni-kl.de ---------------------------------------------------- look at: http://kaupp.chemie.uni-oldenburg.de/~thom/ From amiga-gcc-port-owner@nic.funet.fi Tue Oct 17 16:50:30 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90297-3>; Tue, 17 Oct 1995 16:47:44 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 17 Oct 1995 15:47:36 +0100 (MET) From: Rask Lambertsen To: Kamil Iskra Cc: wiedmann , amiga-gcc-port@nic.funet.fi Subject: Re: New includes In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 16 Oct 1995, Kamil Iskra wrote: > On Sat, 14 Oct 1995, wiedmann wrote: > > And why > > shouldnt't new inlines be a part of the same directory, using different names, > > of course? > > Why? I don't know why :-) I think it's not bad idea, of course it's rather > easy to implement. But what other people think about it? As long as I can write #include and somehow choose between including new or old headers, fine with me. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue Oct 17 18:04:38 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90264-4>; Tue, 17 Oct 1995 18:02:13 +0200 Received: from ns.neckar-alb.de (actually host ns.s-1.de.contrib.net user root@ns.s-1.de.contrib.net) by funet.fi with SMTP (PP); Tue, 17 Oct 1995 18:01:47 +0200 Received: from wiedmann.neckar-alb.de (root@wiedmann.neckar-alb.de [194.77.119.253]) by ns.neckar-alb.de (8.6.9/8.6.9) with ESMTP id RAA02270; Tue, 17 Oct 1995 17:00:22 +0100 Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id QAA05380; Tue, 17 Oct 1995 16:49:58 +0100 From: wiedmann Message-Id: <199510171549.QAA05380@wiedmann.neckar-alb.de> Subject: Re: New includes To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Tue, 17 Oct 1995 16:49:57 +0100 (MET) Cc: kiskra@ernie.icslab.agh.edu.pl, wiedmann@neckar-alb.de, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Oct 17, 95 03:47:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 413 Hello, Rask, > As long as I can write > > #include > > and somehow choose between including new or old headers, fine with me. Please don't do so in public distributed programs. One could well choose between different inlines by introducing YAM. (Yet another macro. :-) The problem is, that too much people are still using inline/* instead of proto/*. Best example: Mui's demo.h. Jochen From amiga-gcc-port-owner@nic.funet.fi Tue Oct 17 18:07:03 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90052-1>; Tue, 17 Oct 1995 18:05:18 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 17 Oct 1995 17:04:45 +0100 (MET) From: Rask Lambertsen To: wiedmann Cc: kiskra@ernie.icslab.agh.edu.pl, wiedmann@neckar-alb.de, amiga-gcc-port@nic.funet.fi Subject: Re: New includes In-Reply-To: <199510171549.QAA05380@wiedmann.neckar-alb.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 17 Oct 1995, wiedmann wrote: > Hello, Rask, > > > As long as I can write > > > > #include > > > > and somehow choose between including new or old headers, fine with me. > > > Please don't do so in public distributed programs. One could well ^^^^^^^^ I assume you mean source code. I'm not going to distribute the source code, so it should not be a problem. > choose between different inlines by introducing YAM. (Yet another > macro. :-) Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue Oct 17 18:19:55 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90393-3>; Tue, 17 Oct 1995 18:17:19 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t5EiJ-0004nYC; Tue, 17 Oct 95 09:18 MST Message-Id: Date: Tue, 17 Oct 95 09:18 MST From: fnf@amigalib.com (Fred Fish) To: amiga-gcc-port@nic.funet.fi Newsgroups: comp.sys.amiga.programmer Subject: Re: Porting Amiga-gcc to linux References: <45kema$dqh@nef.ens.fr> <45omvd$7ph@globe.indirect.com> <45urfd$m2p@nef.ens.fr> Reply-To: fnf@amigalib.com Organization: Amiga Library Services In article <45urfd$m2p@nef.ens.fr>, Marc Espie wrote: > >Yes but consider your average malloc library under Unix. Ever noticed that >it allocates memory in exponential chunks (power of 2). If you request >65 bytes, you might get 128, or even 1024 in some extreme examples. >So if you just pass the limit of your allocation, you're usually still fine. True, this is an implementation detail which is sometimes chosen for the sake of performance. There is a very good library (dbmalloc) which is included on my FreshFish CDs that catches lots of malloc misuse (as well as misuse of string functions) if you link with it rather than the standard malloc. Still, this is a developer tool, not something that the user can take advantage of. It is still possible that the user will tickle a bug that causes problems, that are not seen by the developer. >Under the Amiga, considering the memory constraints we're usually running >under, memory allocators are tighter (even SAS/C malloc), and overstepping >allocation limits is deadly. The basic problem is that it isn't *always* deadly. With strict memory protection, it would be deadly and the developer would immediately find out about the problem. In too many cases it either causes no immediately obvious problems or else only causes a problem 1 out of 10 times it is run, depending upon what else is running, where it gets loaded in memory, etc. >Besides, we've got Enforcer for long enough now that dereferencing memory >outside of the program area of dereferencing the NULL pointer crashes fast. Not everyone (particularly non-developers) runs enforcer though. So what happens is that the user just perceives your program as flakey or buggy, when his machine crashes for no obvious reason, often under dissimilar circumstances, but typically during or after running your program. >The kind of errors I'm thinking of are also system calls which tend to be more >tolerant under Unix, since they can't crash the machine... or the OS that >releases everything back to the system at the end. Hence, you tend to forget >to free pointers and close files. Apparently a good thing, and actually a good >thing for transient programs. You have two choices when porting a program coded under the UNIX model that all resources are freed on exit (not necessarily a bad thing, it is a documented model). You can rewrite the program to make sure it explicitly frees its resources, or you can use some environment like ixemul.library that adds a layer between your application and AmigaDOS that handles this for you. >But normal projects with a long running life (text editors, picture editors) >will tend to eat all memory in the long run... Takes rather a long time under >Unix since you've got lots of memory usually, and don't control precisely >what's going on. Good example: X windows memory allocators tend to eat all >memory when used for programs like xpaint. Agreed, memory leakage is an all too common bug. UNIX might tend to mask it if the virtual memory limits are high enough, but then so does my 64Mb Amiga for most any application I've ever run (except maybe the perl 5.001 configure script :-). >Unix memory protection protects the user. It does not hinder badly written >program. If a program dumps cores from time to time, what do I care ? If >it crashes my amiga, that's another question. Ack! A core dump (actually the condition the caused the dump, not the core dump itself) is the systems way of telling you that something is wrong in your program that needs attention. In my experience, core dumps are almost always repeatable if the program is rerun under the same conditions each time, whereas a system crash under AmigaDOS may or may not be so repeatable, depending on just how gross the error is. >With tools like Enforcer and VMM, this is becoming more and more a non-issue >these days. Bugs with the open address space tend to occur more and more >because of real multitasking and memory sharing... and these are as difficult >to catch under Unix as on the Amiga. I have to admit to no experience in tracking down bugs in UNIX applications that use shared memory regions. >I don't feel that the OS should condone every mistake the >programmer does, which is what Unix tend to do. True, this makes simple >development easier, but it produces sloppy programmers. There are sloppy programmers everywhere. I've even written a few programs that I wasn't too proud of myself, since they were intended to only be quick hacks. The difference is that if a sloppy UNIX programmer releases something full of bugs, the user doesn't suffer by having that application turn his machine into an unstable environment. In almost every case when Joe User is trying to track down a system crash on the Amiga, the recommended first step is to start with a virgin AmigaDOS installation and then start adding stuff back until he finds the culprit. With a UNIX application, most problems can be resolved by just having the user specify in detail the conditions under which the program was run and supply a copy of the core dump file. BTW, at the time the Amiga was released, I was working as a UNIX programmer at UniSoft, a company that specialized in porting UNIX to new MC68000 based hardware. Most of the systems we saw either used the dog slow external Motorola MMU or else used custom MMU hardware. That custom hardware could be fairly elaborate, or as simple as a "base and bounds" register pair, where the kernel allocated a contiguous chunk of main memory, set the base register to translate addresses in that range to start at virtual memory address 0, and used the bounds register to set the upper limit. Something like that would have been trivially easy to do on even the first Amiga, though it would certainly have changed the programming model. It also wasn't possible to do virtual memory with just a single 68000 (though it was by clever use of two 68000's running together), so only memory protection would have been possible. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Oct 17 19:03:18 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90477-1>; Tue, 17 Oct 1995 19:01:06 +0200 Received: from k332.feld.cvut.cz (utx@k332.feld.cvut.cz [147.32.192.12]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id RAA23187 for ; Tue, 17 Oct 1995 17:00:55 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: (from utx@localhost) by k332.feld.cvut.cz (8.6.10/8.6.9) id SAA15201 for amiga-gcc-port@nic.funet.fi; Tue, 17 Oct 1995 18:02:42 +0100 Date: Tue, 17 Oct 1995 18:02:42 +0100 From: Stanislav Brabec Message-Id: <199510171702.SAA15201@k332.feld.cvut.cz> To: amiga-gcc-port@nic.funet.fi Subject: mathIEEE is _NOT_ correct Small hint: mathIEEE is _NOT_ correct soft float function IEEEDPCmp() for details see util/libs/ieee_fix.lha on Aminet. -- Stanislav From amiga-gcc-port-owner@nic.funet.fi Tue Oct 17 19:03:25 1995 Received: from uci.agh.edu.pl ([149.156.96.9]) by nic.funet.fi with SMTP id <90683-4>; Tue, 17 Oct 1995 19:01:36 +0200 Received: from student.uci.agh.edu.pl (iskra@student [149.156.98.60]) by uci.agh.edu.pl (8.6.12/ALLMAN-8.6.12) with ESMTP id RAA28979; Tue, 17 Oct 1995 17:58:01 +0100 Organization: University of Mining and Metallurgy Address: Mickiewicza 30, 30-059 Krakow, POLAND Received: by student.uci.agh.edu.pl (8.6.10/ALLMAN-8.6.9) id RAA14581; Tue, 17 Oct 1995 17:57:57 +0100 Date: Tue, 17 Oct 1995 17:57:53 +0100 (MET) From: Kamil Iskra Subject: Re: New includes To: Rask Lambertsen cc: wiedmann , amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 17 Oct 1995, Rask Lambertsen wrote: > On Tue, 17 Oct 1995, wiedmann wrote: > > > Hello, Rask, > > > > > As long as I can write > > > > > > #include > > > > > > and somehow choose between including new or old headers, fine with me. Why do you want to include and not ? I'm not sure if inline-choosing will be implemented in such a way that including will included either old or new inlines. This was Fred's idea and since I don't know how to implement it, someone else will have to do it. For me personally choosing correct inlines in is enough. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Tue Oct 17 19:29:50 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90654-1>; Tue, 17 Oct 1995 19:27:20 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 17 Oct 1995 18:26:38 +0100 (MET) From: Rask Lambertsen To: Kamil Iskra Cc: wiedmann , amiga-gcc-port@nic.funet.fi Subject: Re: New includes In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 17 Oct 1995, Kamil Iskra wrote: > On Tue, 17 Oct 1995, Rask Lambertsen wrote: > > > On Tue, 17 Oct 1995, wiedmann wrote: > > > > > Hello, Rask, > > > > > > > As long as I can write > > > > > > > > #include > > > > > > > > and somehow choose between including new or old headers, fine with me. > > Why do you want to include and not ? My original reason was that I didn't want to accept SAS/C's style of prototype header path names, as C= has decided to use the style. So I used C='s style. Now that I have moved from DICE to GNU CC, I can't use the C= style anyway, but I don't like to accept something that breaks a standard, no matter how popular it is. At this time, another good reason is that all the source files I have produced since I switched to GNU CC use . What is the reason for using except for SAS/C compatibility? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen , | | WWW home page: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | \_________________________________________________________________________/ From amiga-gcc-port-owner@nic.funet.fi Tue Oct 17 19:47:24 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89991-3>; Tue, 17 Oct 1995 19:45:13 +0200 Received: from ns.neckar-alb.de (actually host ns.s-1.de.contrib.net user wiedmann@ns.s-1.de.contrib.net) by funet.fi with SMTP (PP); Tue, 17 Oct 1995 19:45:05 +0200 Received: (from wiedmann@localhost) by ns.neckar-alb.de (8.6.9/8.6.9) id SAA03550; Tue, 17 Oct 1995 18:43:15 +0100 From: Jochen Wiedmann Message-Id: <199510171743.SAA03550@ns.neckar-alb.de> Subject: Re: New includes To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Tue, 17 Oct 1995 18:43:15 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Oct 17, 95 06:26:38 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 992 > My original reason was that I didn't want to accept SAS/C's style of > prototype header path names, as C= has decided to use the > style. So I used C='s style. Now that I have moved > from DICE to GNU CC, I can't use the C= style anyway, but I don't like to > accept something that breaks a standard, no matter how popular it is. Do you know, that using proto/*.h is fully source compatible on the following C compilers: - SAS/C - Dice - gcc - Maxxon-C There's really *no* reason for using inline/* pragmas/* and whatever they are called, except for very special cases. > At this time, another good reason is that all the source files I have > produced since I switched to GNU CC use . > > What is the reason for using except for SAS/C compatibility? This isn't SAS-compatibility. It is *the* common style with all serious C compilers on the Amiga. (Except Aztec-C which has passed out from development too long ago.) Jochen From amiga-gcc-port-owner@nic.funet.fi Tue Oct 17 22:12:18 1995 Received: from uni-paderborn.de ([131.234.10.3]) by nic.funet.fi with SMTP id <90514-2>; Tue, 17 Oct 1995 22:09:39 +0200 Received: from mises.uni-paderborn.de (mises.uni-paderborn.de [131.234.184.4]) by uni-paderborn.de (8.6.12/8.6.12) with ESMTP id VAA18488 for ; Tue, 17 Oct 1995 21:09:34 +0100 Received: from lange.uni-paderborn.de (lange.uni-paderborn.de [131.234.184.3]) by mises.uni-paderborn.de (8.6.12/8.6.12) with ESMTP id VAA06656 for ; Tue, 17 Oct 1995 21:07:58 +0100 From: Ralph Schmidt Received: (laire@localhost) by lange.uni-paderborn.de (8.6.12/8.6.12) id VAA04091 for amiga-gcc-port@nic.funet.fi; Tue, 17 Oct 1995 21:10:04 +0100 Message-Id: <199510172010.VAA04091@lange.uni-paderborn.de> Subject: GCC 2.7.0 rebuild problem To: amiga-gcc-port@nic.funet.fi Date: Tue, 17 Oct 1995 21:10:03 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP2] Content-Type: text Content-Length: 761 I tried to rebuild gcc 2.7.0 as a crosscompiler but "configure --host=amigados --target=fubar" doesn't work at all. It doesn't accept the parameters..well then i added some debug echos into the shell script and detected that the $arg parameter is always empty..weird. Then i changed the $host,$target definition by hand in the shell script and then it got as far as to tell me that it can't build a m68k-cbm-amigados system. I use the sh from the 263 util archive and i did patch -p1 ; Tue, 17 Oct 1995 23:01:13 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t5J82-0004nYC; Tue, 17 Oct 95 14:00 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: GCC 2.7.0 rebuild problem To: laire@mises.uni-paderborn.de (Ralph Schmidt) Date: Tue, 17 Oct 1995 14:00:54 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199510172010.VAA04091@lange.uni-paderborn.de> from "Ralph Schmidt" at Oct 17, 95 09:10:03 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 545 > I tried to rebuild gcc 2.7.0 as a crosscompiler but > "configure --host=amigados --target=fubar" doesn't > work at all. I just tried the following two commands on my system, using the GNU toolset off FreshFish 10: sh /gnu-src/src/gcc-2.7.0/configure -v --host=m68k-cbm-amigados --target=m68k-sun-sunos sh /gnu-src/src/gcc-2.7.0/configure -v --host=m68k-cbm-amigados --target=i386-unknown-sysv4 Both of the configures completed fine and seemed to "do the right thing", though I didn't try actually building these configurations. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Oct 18 13:59:09 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <89947-3>; Wed, 18 Oct 1995 13:55:47 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id LAA00380; Wed, 18 Oct 1995 11:28:46 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA24126; Wed, 18 Oct 95 11:34:09 GMT Date: Wed, 18 Oct 95 11:34:09 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9510181134.AA24126@indi1.u-strasbg.fr> To: fnf@amigalib.com (Fred Fish) Subject: Re: binutils-1.8.x FSF Source Cc: amiga-gcc-port@nic.funet.fi > > > I'm looking for original archive of binutils-1.8.x. > > Could someone tells me where I can found them ?? > > There is a copy on the FreshFish CDs, or if you can't find one closer I > can probably put it up on our ftp site. Thanks, I have found them. \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Thu Oct 19 12:57:05 1995 Received: from baurz32.urz.uni-bamberg.de ([141.13.250.32]) by nic.funet.fi with SMTP id <90492-2>; Thu, 19 Oct 1995 12:54:28 +0200 Received: from urzmail.stud.uni-bamberg.de by baurz32.urz.uni-bamberg.de with SMTP (1.37.109.4/16.2) id AA24039; Thu, 19 Oct 95 11:52:15 +0100 Received: from URZMAIL/SpoolDir by urzmail.stud.uni-bamberg.de (Mercury 1.13); Thu, 19 Oct 95 11:55:08 GMT+1 Received: from SpoolDir by URZMAIL (Mercury 1.13); Thu, 19 Oct 95 11:54:52 GMT+1 From: "Stefan Westner" Organization: UNI-BAMBERG To: amiga-gcc-port@nic.funet.fi Date: Thu, 19 Oct 1995 11:54:48 GMT+0100 Subject: Re: serious rounding problem Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <1CC4981DF9@urzmail.stud.uni-bamberg.de> Hello Christoph, > Hello! > a few months ago, i postet a problem with gcc2.6.3, concerning > rounding at double-int conversion, but nobody could help me. > Now i've installed gcc2.7.0 hoping the bug had been removed -> it > hadn't :-( Sorry, just came from holiday and couldn't read the mail... > so here again my problem: > when i compile the following programm > > #include > main () > { > double a=3.7; > printf("%d \n",(int)a); > } > > with "gcc -o prg prg.c" > i get 4 as output. but the K&R C-bible says it should be 3 ! > > If i compile the same program with "gcc -noixemul -o prg prg.c -lm" > i get 3. I'm not a specialist in C/C++, I only use GCC on Amiga and Sparc to compile and modify existing programs. I use M2-Amiga Modula-2 and last week I wrote a porgram which calculates heavily with real-numbers and the same problem occurs: VAR a: REAL; a:=3.7; INTEGER(a)=4 TRUNC(a)=4 a:=3.6; INTEGER(a)=3 (The breakpoint is somewhere between 3.6 and 3.7) :-) I traced down the problem and make a cross-check on Turbo Pascal 7.0 which both gives 3 as result. Look at the assembler-code I saw that the MathIEEESingBas Fix() is called. I rewrote the program by chancing all REALs to LONGREAL (double in C) and the whole thing works fine now: TRUNC(a) and INTEGER(a) gives 3 for all numbers between 3 and 3.9999999999! That's absolutely correct now. I chanced the program to use the MathIEEE-Libs directly (Fix()) and again: REAL didn't work but LONGREAL did! It's getting better: INTEGER(LONGREAL(REAL(a)) didn't give 3 but 4! My results: If only ONE REAL-calculation in the program is done using REAL the whole thing go wrong. Only using LONGREAL all works fine. My opinion is that the MathIEEESingBas is buggy!!!! There is no different in compiling the program for 68000 or 68882 the result is simply the same. I don't understand this at all! It's perhaps a kind of higher movement... :-) Grettings Stefan -------------------------------------------------------------------------- Stefan Westner Tel: 0951/74375 Grabenstrasse 41 Stefan.Westner@stud.uni-bamberg.de 96103 Hallstadt PGP-Public-Key auf Anfrage verfuegbar PGP-Public-Key available on request -------------------------------------------------------------------------- ... So muessen Mails aussehen, dann klappts auch mit dem Nachbarn ... From amiga-gcc-port-owner@nic.funet.fi Thu Oct 19 13:10:58 1995 Received: from baurz32.urz.uni-bamberg.de ([141.13.250.32]) by nic.funet.fi with SMTP id <90595-3>; Thu, 19 Oct 1995 13:09:27 +0200 Received: from urzmail.stud.uni-bamberg.de by baurz32.urz.uni-bamberg.de with SMTP (1.37.109.4/16.2) id AA24300; Thu, 19 Oct 95 12:07:14 +0100 Received: from URZMAIL/SpoolDir by urzmail.stud.uni-bamberg.de (Mercury 1.13); Thu, 19 Oct 95 12:10:07 GMT+1 Received: from SpoolDir by URZMAIL (Mercury 1.13); Thu, 19 Oct 95 12:09:46 GMT+1 From: "Stefan Westner" Organization: UNI-BAMBERG To: amiga-gcc-port@nic.funet.fi Date: Thu, 19 Oct 1995 12:09:42 GMT+0100 Subject: Different results with IXEMUL and LIBNIX Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <1D04353B21@urzmail.stud.uni-bamberg.de> Hello! A few days ago I grab a typical C-Program somewhere on the net: #define TWENTYNINE 29 int ll, L1, l0, h_1,q,h1,h; main(){ for(putchar(putchar((h=7)*10+2)+TWENTYNINE); l0?putchar(l0):!h_1; putchar (ll),L1==2?ll=' ':0){ L1++==0?(ll=l0=54<<1): ll=='l'&&L1<3?(ll+=1L| 1L<<1L,l0=0) :L1==sizeof L1&&ll==' ' ?(ll=19+h1):(q-=h1); L1==5?ll-=8:q&& & h_1;L1==sizeof ll+2? (ll+=3):1L;ll==(h<<4)+2 &&L1!=6?(ll=ll- 6):(h1=100L);L1!=1L<<3?q-- :(h_1=ll=h1); } printf("%s\n"); } I don't understand it at all (somebody does? :-) ) but compiling with GCC - o Test Test.C it prints Hello World. Compiling the same with the -noixemul- switch it prints Hllo World (missing e). A bug in LIBNIX? I use the GNU-tree from Fresh Fish 10 by simply copying the whole directory to my HD, i. e. GCC-2.7.0 Does anybody know what's wrong? Bye Stefan -------------------------------------------------------------------------- Stefan Westner Tel: 0951/74375 Grabenstrasse 41 Stefan.Westner@stud.uni-bamberg.de 96103 Hallstadt PGP-Public-Key auf Anfrage verfuegbar PGP-Public-Key available on request -------------------------------------------------------------------------- ... So muessen Mails aussehen, dann klappts auch mit dem Nachbarn ... From amiga-gcc-port-owner@nic.funet.fi Thu Oct 19 13:24:14 1995 Received: from baurz32.urz.uni-bamberg.de ([141.13.250.32]) by nic.funet.fi with SMTP id <89938-2>; Thu, 19 Oct 1995 13:22:34 +0200 Received: from urzmail.stud.uni-bamberg.de by baurz32.urz.uni-bamberg.de with SMTP (1.37.109.4/16.2) id AA24502; Thu, 19 Oct 95 12:20:15 +0100 Received: from URZMAIL/SpoolDir by urzmail.stud.uni-bamberg.de (Mercury 1.13); Thu, 19 Oct 95 12:23:08 GMT+1 Received: from SpoolDir by URZMAIL (Mercury 1.13); Thu, 19 Oct 95 12:22:48 GMT+1 From: "Stefan Westner" Organization: UNI-BAMBERG To: amiga-gcc-port@nic.funet.fi Date: Thu, 19 Oct 1995 12:22:43 GMT+0100 Subject: Compiling GS-2.6.2 from Frsh Fish 10 Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <1D3BD076C6@urzmail.stud.uni-bamberg.de> Hello, me again! On Fresh Fish 10 the GhostScript-Interpreter has only Amiga-specific devices. That's simply a joke! To get the requested HP-Drivers is unlhaed the source and only added in the amiga-gcc.mak the HP and PBM-drivers. A make -f amiga-gcc.mak should done the job - I thought! My machine: A2000, 68030-25, FPU, 9 MB Fast-RAM, 1 MB Chip-RAM, HD, and so on. STACK in the SHELL is set to 500000 Bytes. When compiling the program the Amiga crashed very often with GURU 8...3 and 8....4 (Illegal adress/instruction) but I managed to get the program through. Starting GS after compiling it crashed with a Guru. During the compiling the a constant sum of 2 MB FAST-memory was free, so I think the memory was be enough. While compiling gdevamiga.c and gp_amiga.c GCC prints the following warnings: In file included from gdevamiga.c:54: /gnu/os-include/clib/graphics_protos.h:186: warning: `struct BitScaleArgs' declared inside parameter list /gnu/os-include/clib/graphics_protos.h:186: warning: its scope is only this definition or declaration, /gnu/os-include/clib/graphics_protos.h:186: warning: which is probably not what you want. In file included from gdevamiga.c:59: /gnu/os-include/clib/dos_protos.h:128: warning: `struct ExAllControl' declared inside parameter list /gnu/os-include/clib/dos_protos.h:128: warning: `struct ExAllData' declared inside parameter list /gnu/os-include/clib/dos_protos.h:243: warning: `struct ExAllControl' declared inside parameter list /gnu/os-include/clib/dos_protos.h:243: warning: `struct ExAllData' declared inside parameter list gdevamiga.c: In function `amiga_open_custom': gdevamiga.c:2904: warning: passing arg 2 of `GetDisplayInfoData' from incompatible pointer type gdevamiga.c:2957: warning: passing arg 2 of `GetDisplayInfoData' from incompatible pointer type and in gp_amiga.c In file included from gp_amiga.c:29: /gnu/os-include/clib/exec_protos.h:49: warning: `struct MemHeader' declared inside parameter list /gnu/os-include/clib/exec_protos.h:49: warning: its scope is only this definition or declaration, /gnu/os-include/clib/exec_protos.h:49: warning: which is probably not what you want. /gnu/os-include/clib/exec_protos.h:51: warning: `struct MemHeader' declared inside parameter list In file included from gp_amiga.c:30: /gnu/os-include/clib/dos_protos.h:128: warning: `struct ExAllControl' declared inside parameter list /gnu/os-include/clib/dos_protos.h:128: warning: `struct ExAllData' declared inside parameter list /gnu/os-include/clib/dos_protos.h:243: warning: `struct ExAllControl' declared inside parameter list /gnu/os-include/clib/dos_protos.h:243: warning: `struct ExAllData' declared inside parameter list I used the GCC from the Fresh Fish 10 by simply copying the whole GNU-Dir to my HD. The compiler was invoked with GCC-2.6.3 not with GCC (I didn't trust the 2.7.0-version but I compiled the program with 2.7.0 again -> same result) My questions now: What's wrong in the Includes? Is STACK 500000 enough? Why crashed the amiga 10 time when compiling? Is GCC so instable? Had anyone compiled the program succesful (Fred?) I can send the modified Make-File if requested. Any suggestions? Stefan -------------------------------------------------------------------------- Stefan Westner Tel: 0951/74375 Grabenstrasse 41 Stefan.Westner@stud.uni-bamberg.de 96103 Hallstadt PGP-Public-Key auf Anfrage verfuegbar PGP-Public-Key available on request -------------------------------------------------------------------------- ... So muessen Mails aussehen, dann klappts auch mit dem Nachbarn ... From amiga-gcc-port-owner@nic.funet.fi Thu Oct 19 13:32:53 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90149-2>; Thu, 19 Oct 1995 13:30:01 +0200 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id MAA26964 (8.6.12/IDA-1.6); Thu, 19 Oct 1995 12:29:49 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA09344; Thu, 19 Oct 95 12:29:48 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9510191129.AA09344@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Different results with IXEMUL and LIBNIX To: stefan.westner@stud.uni-bamberg.de (Stefan Westner) Date: Thu, 19 Oct 1995 12:29:48 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <1D04353B21@urzmail.stud.uni-bamberg.de> from "Stefan Westner" at Oct 19, 95 12:09:42 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 427 > > A few days ago I grab a typical C-Program somewhere on the net: > > [program deleted] > > I don't understand it at all (somebody does? :-) ) but compiling with GCC - > o Test Test.C it prints Hello World. Compiling the same with the -noixemul- > switch it prints Hllo World (missing e). A bug in LIBNIX? > Don't know. Compiled under SunOS it prints something else again ;-) : Segmentation fault (core dumped) Matthias From amiga-gcc-port-owner@nic.funet.fi Thu Oct 19 13:39:05 1995 Received: from baurz32.urz.uni-bamberg.de ([141.13.250.32]) by nic.funet.fi with SMTP id <90178-4>; Thu, 19 Oct 1995 13:37:39 +0200 Received: from urzmail.stud.uni-bamberg.de by baurz32.urz.uni-bamberg.de with SMTP (1.37.109.4/16.2) id AA24715; Thu, 19 Oct 95 12:35:25 +0100 Received: from URZMAIL/SpoolDir by urzmail.stud.uni-bamberg.de (Mercury 1.13); Thu, 19 Oct 95 12:38:18 GMT+1 Received: from SpoolDir by URZMAIL (Mercury 1.13); Thu, 19 Oct 95 12:38:09 GMT+1 From: "Stefan Westner" Organization: UNI-BAMBERG To: amiga-gcc-port@nic.funet.fi Date: Thu, 19 Oct 1995 12:38:08 GMT+0100 Subject: Re: Different results with IXEMUL and LIBNIX Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <1D7D4C5774@urzmail.stud.uni-bamberg.de> > > > > A few days ago I grab a typical C-Program somewhere on the net: > > > > [program deleted] > > > > I don't understand it at all (somebody does? :-) ) but compiling with GCC - > > o Test Test.C it prints Hello World. Compiling the same with the -noixemul- > > switch it prints Hllo World (missing e). A bug in LIBNIX? > > > Don't know. Compiled under SunOS it prints something else again ;-) : > > Segmentation fault (core dumped) > > Matthias I just compiled the program on SunOS Solaris 2.4 using Sparc CC and it prints Hello World Stefan -------------------------------------------------------------------------- Stefan Westner Tel: 0951/74375 Grabenstrasse 41 Stefan.Westner@stud.uni-bamberg.de 96103 Hallstadt PGP-Public-Key auf Anfrage verfuegbar PGP-Public-Key available on request -------------------------------------------------------------------------- ... So muessen Mails aussehen, dann klappts auch mit dem Nachbarn ... From amiga-gcc-port-owner@nic.funet.fi Thu Oct 19 14:16:23 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90283-3>; Thu, 19 Oct 1995 14:13:47 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA23203; Thu, 19 Oct 1995 13:15:07 +0100 Date: Thu, 19 Oct 1995 13:15:06 +0100 (MET) From: Kamil Iskra Subject: Re: Different results with IXEMUL and LIBNIX To: Stefan Westner cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <1D7D4C5774@urzmail.stud.uni-bamberg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Oct 1995, Stefan Westner wrote: > > > > > > A few days ago I grab a typical C-Program somewhere on the net: > > > > > > [program deleted] > > > > > > I don't understand it at all (somebody does? :-) ) but compiling with GCC - > > > o Test Test.C it prints Hello World. Compiling the same with the -noixemul- > > > switch it prints Hllo World (missing e). A bug in LIBNIX? > > > > > Don't know. Compiled under SunOS it prints something else again ;-) : > > > > Segmentation fault (core dumped) > > > > Matthias > > I just compiled the program on SunOS Solaris 2.4 using Sparc CC and it > prints Hello World > > Stefan I deleted this listing right after having a look at it (sorry, I couldn't resist :-). However, if I remember correctly, the last line of main() was: printf("%s\n"); Since no parameter was given, core dump under SunOS seems pretty probable. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Oct 19 15:15:12 1995 Received: from trappist.elis.rug.ac.be ([157.193.67.1]) by nic.funet.fi with SMTP id <90285-4>; Thu, 19 Oct 1995 15:13:25 +0200 Received: from ibmpar.elis.rug.ac.be by trappist.elis.rug.ac.be with SMTP id AA00460 (5.65c/IDA-1.4.4 for ); Thu, 19 Oct 1995 14:11:30 +0100 Received: by ibmpar.elis.rug.ac.be (AIX 3.2/UCB 5.64/4.03) id AA18716; Thu, 19 Oct 1995 14:11:46 GMT From: bvassche@ibmpar.elis.rug.ac.be (Bart Van Assche) Message-Id: <9510191411.AA18716@ibmpar.elis.rug.ac.be> Subject: Re: Different results with IXEMUL and LIBNIX (fwd) To: amiga-gcc-port@nic.funet.fi Date: Thu, 19 Oct 1995 14:11:45 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1482 In a previous message bvassche wrote: > > In a previous message Stefan Westner wrote: > > > A few days ago I grab a typical C-Program somewhere on the net: > > > > #define TWENTYNINE 29 > > > > int ll, L1, l0, h_1,q,h1,h; > > > > main(){ > > for(putchar(putchar((h=7)*10+2)+TWENTYNINE); > > l0?putchar(l0):!h_1; > > putchar (ll),L1==2?ll=' ':0){ > > L1++==0?(ll=l0=54<<1): > > ll=='l'&&L1<3?(ll+=1L| > > 1L<<1L,l0=0) > > :L1==sizeof L1&&ll==' ' > > ?(ll=19+h1):(q-=h1); > > L1==5?ll-=8:q&& & > > h_1;L1==sizeof ll+2? > > (ll+=3):1L;ll==(h<<4)+2 > > &&L1!=6?(ll=ll- > > 6):(h1=100L);L1!=1L<<3?q-- > > :(h_1=ll=h1); > > } > > printf("%s\n"); > > } > > > > Does anybody know what's wrong? > > There is at least one severe bug in this program: the last line should read > > printf("\n"); > > so NO %s !! This can easily cause a core dump. But I still don't know why > sometimes the 'e' is missing as you stated. (I get the output 'Hello world' > on this RS/6000 machine) Another potential problem is the statement putchar(putchar((h=7)*10+2)+TWENTYNINE); This relies on the return value of putchar(c): should be c. Otherwise, the second letter ('e') will be missing or wrong. Maybe this is the problem with libnix ? -- __ /_/ /_/art Van Assche. (Bart.VanAssche@elis.rug.ac.be) From amiga-gcc-port-owner@nic.funet.fi Thu Oct 19 15:40:45 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <90890-1>; Thu, 19 Oct 1995 15:37:26 +0200 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id OAA29452 (8.6.10/2.4); Thu, 19 Oct 1995 14:38:02 +0100 Date: Thu, 19 Oct 1995 14:38:02 +0100 From: Olaf Seibert Message-Id: <199510191338.OAA29452@septimius.mbfys.kun.nl> To: amiga-gcc-port@nic.funet.fi, bvassche@ibmpar.elis.rug.ac.be Subject: Re: Different results with IXEMUL and LIBNIX (fwd) > Another potential problem is the statement > > putchar(putchar((h=7)*10+2)+TWENTYNINE); > > This relies on the return value of putchar(c): should be c. Otherwise, > the second letter ('e') will be missing or wrong. Maybe this is > the problem with libnix ? Sounds likely (without checking). Many compilers make subtle mistakes in these macros. Most of them should work correctly with calls like putchar(*s++) but some implementations may evaluate their arguments more than once. Note that given the typical size of macros like putchar(), getting this right in all cases requires careful checking! Which arguments must be safe: just about all, for all macros. What does not need to work is side effects on (FILE *) arguments, such as in putc(ch, file++); -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Thu Oct 19 17:40:48 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90057-2>; Thu, 19 Oct 1995 17:38:35 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t5x4d-0004nYC; Thu, 19 Oct 95 08:40 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Compiling GS-2.6.2 from Frsh Fish 10 To: stefan.westner@stud.uni-bamberg.de (Stefan Westner) Date: Thu, 19 Oct 1995 08:40:03 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <1D3BD076C6@urzmail.stud.uni-bamberg.de> from "Stefan Westner" at Oct 19, 95 12:22:43 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2768 > On Fresh Fish 10 the GhostScript-Interpreter has only Amiga-specific > devices. That's simply a joke! > To get the requested HP-Drivers is unlhaed the source and only added in > the amiga-gcc.mak the HP and PBM-drivers. Send me diffs of what you did, or the complete amiga-gcc.mak file, and I'll try it here. > A make -f amiga-gcc.mak should > done the job - I thought! That is not how I make ghostscript. The GNU Tools version uses an autoconf generated script (configure) and a template file (Makefile.in) to generate a "Makefile" that is used rather than amiga-gcc.mak. So you would do: makedir build cd build sh /gnu-src/ghostscript/configure -v m68k-cbm-amigados make to build it in a separate build directory (so as not to pollute your source tree). > While compiling gdevamiga.c and gp_amiga.c GCC prints the following > warnings: > > In file included from gdevamiga.c:54: > /gnu/os-include/clib/graphics_protos.h:186: warning: `struct BitScaleArgs' > declared inside parameter list > /gnu/os-include/clib/graphics_protos.h:186: warning: its scope is only > this definition or declaration, > /gnu/os-include/clib/graphics_protos.h:186: warning: which is probably not > what you want. > In file included from gdevamiga.c:59: > /gnu/os-include/clib/dos_protos.h:128: warning: `struct ExAllControl' > declared inside parameter list > /gnu/os-include/clib/dos_protos.h:128: warning: `struct ExAllData' > declared inside parameter list > /gnu/os-include/clib/dos_protos.h:243: warning: `struct ExAllControl' > declared inside parameter list > /gnu/os-include/clib/dos_protos.h:243: warning: `struct ExAllData' > declared inside parameter list > gdevamiga.c: In function `amiga_open_custom': > gdevamiga.c:2904: warning: passing arg 2 of `GetDisplayInfoData' from > incompatible pointer type > gdevamiga.c:2957: warning: passing arg 2 of `GetDisplayInfoData' from > incompatible pointer type These warnings are expected (and harmless), though they should be fixed. The standard amiga include files tend to use struct references inside prototypes before those structures are defined, which is what gcc is warning about. > and in gp_amiga.c Same problems. > I used the GCC from the Fresh Fish 10 by simply copying the whole GNU-Dir > to my HD. The compiler was invoked with GCC-2.6.3 not with GCC (I didn't > trust the 2.7.0-version but I compiled the program with 2.7.0 again -> > same result) My compilations are done with gcc 2.7.0. > Had anyone compiled the program succesful (Fred?) Yes, I compile it all the time. It has been recompiled at least a dozen times just since the GNU tree was frozen for FF10, because I continuously do multistage rebuilds of the entire tree each time anything changes. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 11:46:56 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <90743-1>; Fri, 20 Oct 1995 11:39:22 +0200 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id KAA14658 (8.6.12/IDA-1.6); Fri, 20 Oct 1995 10:38:55 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA10191; Fri, 20 Oct 95 10:38:54 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9510200938.AA10191@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Different results with IXEMUL and LIBNIX (fwd) To: amiga-gcc-port@nic.funet.fi Date: Fri, 20 Oct 1995 10:38:54 +0100 (MET) Cc: stefan.westner@stud.uni-bamberg.de X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 535 > > Another potential problem is the statement > > putchar(putchar((h=7)*10+2)+TWENTYNINE); > > This relies on the return value of putchar(c): should be c. Otherwise, > the second letter ('e') will be missing or wrong. Maybe this is > the problem with libnix ? > I tried the program at home (with the %s removed) and it worked fine with -noixemul. Maybe it is an already fixed bug of an older version or one that happens only on some machines? Stefan, what version of libnix are you using? Can you send me an executable? Matthias From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 12:16:47 1995 Received: from wckn.dorm.clarkson.edu ([128.153.48.2]) by nic.funet.fi with SMTP id <90696-3>; Fri, 20 Oct 1995 12:13:22 +0200 Received: by wckn.dorm.clarkson.edu (4.1/SMI-4.1) id AA17547; Fri, 20 Oct 95 06:13:17 EDT Date: Fri, 20 Oct 95 06:13:17 EDT From: Rob Message-Id: <9510201013.AA17547@wckn.dorm.clarkson.edu> To: amiga-gcc-port@nic.funet.fi Subject: Converting from object to archive. Pardon me if this is in the docs but I haven't been able to find it... How do you create a gcc archive (linked library)? I assume you compile an object module and do some operation on it but I don't know what this operation is. It's impractical to break the library into a separate file for each function manually and join them back together with ar. Thanks, -Robert Dick (dickrp@wckn.dorm.clarkson.edu)- From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 12:36:10 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90167-4>; Fri, 20 Oct 1995 12:33:01 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA25465; Fri, 20 Oct 1995 11:30:29 +0100 From: Lars Hecking Message-Id: <199510201034.LAA20483@mostar.nmrc.ucc.ie> Subject: Re: Converting from object to archive. To: dickrp@wckn.dorm.clarkson.edu (Rob) Date: Fri, 20 Oct 1995 11:34:24 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9510201013.AA17547@wckn.dorm.clarkson.edu> from "Rob" at Oct 20, 95 06:13:17 am Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 839 > Pardon me if this is in the docs but I haven't been able to > find it... How do you create a gcc archive (linked library)? > I assume you compile an object module and do some operation on > it but I don't know what this operation is. It's impractical to > break the library into a separate file for each function manually > and join them back together with ar. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sorry, I don't understand this part ;) To create the library objects, gcc -c {source file list} To create a library, use ar rc libfoo.a *.o ranlib libfoo.a [The man pages for ar and ranlib are in GNU:man/cat1/] To use this library, either do gcc -o file file.c ./libfoo.a or, copy the library to GNU:lib and do gcc -o file file.c -lfoo or, copy the library to {DIR} and do gcc -o file file.c -L{DIR} -lfoo From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 13:52:43 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90285-1> convert rfc822-to-8bit; Fri, 20 Oct 1995 13:48:25 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 20 Oct 1995 12:47:39 +0100 (MET) From: Rask Lambertsen To: Stefan Westner Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Compiling GS-2.6.2 from Frsh Fish 10 In-Reply-To: <1D3BD076C6@urzmail.stud.uni-bamberg.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 19 Oct 1995, Stefan Westner wrote: > In file included from gdevamiga.c:54: > /gnu/os-include/clib/graphics_protos.h:186: warning: `struct BitScaleArgs' > declared inside parameter list > /gnu/os-include/clib/graphics_protos.h:186: warning: its scope is only > this definition or declaration, > /gnu/os-include/clib/graphics_protos.h:186: warning: which is probably not > what you want. > In file included from gdevamiga.c:59: > /gnu/os-include/clib/dos_protos.h:128: warning: `struct ExAllControl' > declared inside parameter list > /gnu/os-include/clib/dos_protos.h:128: warning: `struct ExAllData' > declared inside parameter list > /gnu/os-include/clib/dos_protos.h:243: warning: `struct ExAllControl' > declared inside parameter list > /gnu/os-include/clib/dos_protos.h:243: warning: `struct ExAllData' > declared inside parameter list [snip] This problem can be solved by including the correct header files before including the inline headers. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 14:18:24 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90558-1>; Fri, 20 Oct 1995 14:13:23 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA09485; Fri, 20 Oct 1995 13:15:17 +0100 Date: Fri, 20 Oct 1995 13:15:16 +0100 (MET) From: Kamil Iskra Subject: Re: Compiling GS-2.6.2 from Frsh Fish 10 To: Rask Lambertsen cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 20 Oct 1995, Rask Lambertsen wrote: > > In file included from gdevamiga.c:54: > > /gnu/os-include/clib/graphics_protos.h:186: warning: `struct BitScaleArgs' > > declared inside parameter list [snip] > This problem can be solved by including the correct header files before > including the inline headers. This reminds me of yet another reason of #including "proto/*" and not "inline/*" - necessary headers are included automatically. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 15:31:20 1995 Received: from legolas.mdh.se ([130.238.251.203]) by nic.funet.fi with SMTP id <90778-4>; Fri, 20 Oct 1995 15:27:39 +0200 Received: (from frv95tjn@localhost) by legolas.mdh.se (8.6.10/8.6.10) id OAA27226; Fri, 20 Oct 1995 14:27:17 +0100 Date: Fri, 20 Oct 1995 14:27:16 +0100 (MET) From: Tommy Johansson X-Sender: frv95tjn@legolas.mdh.se To: gcclist Subject: Ixemul Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Why does the startupcode try to read all env. variables? Tommy Johansson frv95tjn@mds.mdh.se From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 15:41:44 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <90210-4>; Fri, 20 Oct 1995 15:39:54 +0200 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA29078; Fri, 20 Oct 1995 14:39:42 +0100 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA11615; Fri, 20 Oct 95 14:39:41 +0100 From: isthesin@TechFak.Uni-Bielefeld.DE (Stephan Thesing) Message-Id: <9510201439.ZM11613@moos.TechFak.Uni-Bielefeld.DE> Date: Fri, 20 Oct 1995 14:39:40 +0100 In-Reply-To: Tommy Johansson "Ixemul" (Oct 20, 14:27) References: X-Mailer: Z-Mail (2.1.5 09aug93) To: Tommy Johansson Subject: Re: Ixemul Cc: amiga-gcc-port@nic.funet.fi On Oct 20, 14:27, Tommy Johansson wrote: > Subject: Ixemul > Why does the startupcode try to read all env. variables? > > > Tommy Johansson > frv95tjn@mds.mdh.se >-- End of excerpt from Tommy Johansson Good question, I think it's because ixemul tries to build a UNIX environment and so has to read the environment and make a process-private copy of it, since processes are not allowed to change the global environment for all processes AFAIK One can argue if this is necessary under AmigaDOS or not, though.. Bye... Stephan -- =============================================== = Stephan Thesing = = AG Praktische Informatik = = Technische Fakult"at = = Universit"at Bielefeld = = EMail: isthesin@techfak.uni-bielefeld.de = =---------------------------------------------= = Wer den Spruch erfunden hat : = = "So einfach, wie einem Kind den Lolly = = wegzunehmen", hat noch nie versucht, = = seinem Neffen ein Bonbon zu stibitzen. = =============================================== From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 15:48:33 1995 Received: from srv3.gbar.dtu.dk ([130.225.87.163]) by nic.funet.fi with ESMTP id <90890-4> convert rfc822-to-8bit; Fri, 20 Oct 1995 15:47:57 +0200 Received: by srv3.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 20 Oct 1995 14:47:49 +0100 (MET) From: Rask Lambertsen To: Stephan Thesing Cc: Tommy Johansson , amiga-gcc-port@nic.funet.fi Subject: Re: Ixemul In-Reply-To: <9510201439.ZM11613@moos.TechFak.Uni-Bielefeld.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Fri, 20 Oct 1995, Stephan Thesing wrote: > On Oct 20, 14:27, Tommy Johansson wrote: > > Subject: Ixemul > > Why does the startupcode try to read all env. variables? > > Good question, I think it's because > ixemul tries to build a UNIX environment and so has to read the environment > and make a process-private copy of it, since processes are not allowed > to change the global environment for all processes AFAIK > > One can argue if this is necessary under AmigaDOS or not, though.. It would be nice if something could be done so that reading the entire ENV: each time an ixemul programme is started wouldn't be necessary. It certanly slows down programme startup a lot, around 3 seconds on my system. Imagine how long it would take if I ran MUI and it had to read the entire "ENV:MUI/whatever_junk_is_left_there" directory. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 15:53:39 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90608-2>; Fri, 20 Oct 1995 15:52:52 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HWO140ZZ7400HW38@NET2.WAU.NL>; Fri, 20 Oct 1995 14:55:06 +0000 (GMT) Received: by vines2.wau.nl; Fri, 20 Oct 95 14:52:36 +0100 Date: Fri, 20 Oct 1995 14:29:47 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Ghostscript261 compile prob & rounding IEEE! To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi Stefan, I read your problems you're having with gs261 and maybe I can give you some help and help the other guy with rounding problems too. First the problem with the warnings about struct definitions inside function calls is very simple to solve. At the beginning of gdevamiga.c/gp_amiga.c change the #include to #include and everything will be fine. Inlines will be used when optimizing is on otherwise stubs will be called through amiga.lib. Watch out for functions using *all* data registers (BltBitMap) which will cause problems with *gcc2.7.0*!!!! gdevamiga.c uses it.! Next, I tried to compile gs261 from Aminet but that was a total disaster. So I searched the net a bit and found the GS3.33 source and tried those. Instant succes. make -f unix-gcc.mak did the trick right out of the box. Only problem which appeared then was that some drivers didn't work. They just bombed out on me. After some discussion on this list and with the gs maintainer we found out that there was a small bug in *ixemul.library* concerning rounding to zero (chop) or round to nearest integer. It was set to nearest instead of chop mode. Fixed since version 40.3 WARNING: the old gdevamiga.c doesn't work with gs3.33/gs3.51 which is the latest version. Next, stack 500000 is alot if you use make since make with complex makefiles you end up with several make's in memory each using 500K of memory. I use 40K to compile gs3.51 and that has proven to be enough. Second compiling gdevamiga.c with O2 uses *lots* (6M+) of memory, GCC2.7.0 has not bombed on me once while I was compiling gs, and I have done some re- compiles in the meantime. GS3.5.1 for the Amiga is almost ready now. There are some small things that need to be done and one of them is probably a bug in GS itself which I hope to be able to track down this weekend. The other thing is that the Amigadriver could use some cleaning up. I have managed to make it *not* use ixemul.library but there are #ifdef IXEMUL in the source for those of you who rather use ixemul.library. The executable (-m68020-40 -O2 -mstackextend (works well)) is ~740K but that is with all major fileformats/printers included, including the Amiga driver which is the default. Message to Fred: I read your list of todo things and saw GSView on it. I have been looking at it but this is going to be a lot of work since the display and parsing part of the program are rather mixed together. (my first impression, might improve) Message to Stefan: If you want to discuss things about gs with me on this list then please also send a CC to me personal since I'm not subscribed to this list. Yes, I know, shame on me :) Joop From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 18:03:31 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90666-4>; Fri, 20 Oct 1995 18:02:04 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id SAA05880 at Fri, 20 Oct 1995 18:00:40 +0200 Received: by softlab.ece.ntua.gr with UUCP id SAA16835 at Fri, 20 Oct 1995 18:05:30 +0200 (EET) Received: by kriton.UUCP (V1.17-beta/Amiga) id <08n5@kriton.UUCP>; Fri, 20 Oct 95 17:57:52 EET Date: Fri, 20 Oct 95 17:57:52 EET Message-Id: <9510201557.08n5@kriton.UUCP> In-Reply-To: <9510201439.ZM11613@moos.TechFak.Uni-Bielefeld.DE> (from theseas!TechFak.Uni-Bielefeld.DE!isthesin (Stephan Thesing)) (at Fri, 20 Oct 1995 14:39:40 +0100) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: Ixemul Stephan Thesing, in <9510201439.ZM11613@moos.TechFak.Uni-Bielefeld.DE> on Oct 20 wrote: > On Oct 20, 14:27, Tommy Johansson wrote: > > Why does the startupcode try to read all env. variables? > > Good question, I think it's because > ixemul tries to build a UNIX environment and so has to read the environment > and make a process-private copy of it, since processes are not allowed > to change the global environment for all processes AFAIK This is (also?) done for compatibility with the little-known feature of UNIX, that main() actually takes *three* arguments, the third being a null-terminated list of variable=value strings, containing all the environment variables and their values. Thus, the following program is the source for a simple printenv command: ------------------------------------------------------------------------------ #include main(int argc, char *argv[], char *envp[]) { int i; for (i=0; envp[i]; i++) { printf("%s\n", envp[i]); } return 0; } ------------------------------------------------------------------------------ Libnix is also compatible with this feature, in the sense that it ensures that envp[0] is 0, so that programs that use envp don't walk all over the Amiga's memory. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "One good solid hope's worth a cartload of certainties!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 18:04:25 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90324-2>; Fri, 20 Oct 1995 18:04:08 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 20 Oct 95 17:01:37 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <217b96eb.u8t20e.b8f26-robert@plukwa.lodz.pdi.net> Subject: Number of processes limit?? Reply-To: robert@lodz.pdi.net Content-Length: 1403 To: amiga-gcc-port@nic.funet.fi Date: Fri, 20 Oct 95 17:01:37 Organization: PDi Hi all! Recently I was quite heavily recompiling varius packages using GCC 2.7.0. During this proccess i was every now and than seeing message cannot fork - try again - errno 67. I've checked that errno value and it says Too many processes. Now is ixemul library limiting the number of processes in any way or it is some other error hiding behind this one? I've seen this cannot fork message in configure scripts and at varius points of various make's. Most of the time it was just a matter of retrying once (twice, ...) again but sometime i had to reboot Amiga to proceed any further. regards Robert Ps. If someone is interested in gcc270utils (-mstackexted -m68020-40 -O2) than have a look at ftp://plukwa.lodz.pdi.net/amiga/gnu/ Please excuse for low transfer speed (~0.5 KB) Note also taht this archives are not approved by neither Philippe nor Fred +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 18:07:22 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89988-3>; Fri, 20 Oct 1995 18:06:54 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26528-4>; Fri, 20 Oct 1995 17:06:23 +0100 Received: from hphalle6h.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395721-1>; Fri, 20 Oct 1995 17:06:15 +0100 Subject: Re: Ixemul From: Christian Stieber To: frv95tjn@mds.mdh.se (Tommy Johansson) Date: Fri, 20 Oct 1995 17:05:59 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Tommy Johansson" at Oct 20, 95 02:27:16 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 674 Message-Id: <95Oct20.170615+0100mesz.395721-1+767@hphalle0.informatik.tu-muenchen.de> > > Why does the startupcode try to read all env. variables? This is because ixemul is not meant to be a "normal" library. It is meant to emulate a Unix environment as much as possible. On Unix, you can access the environment variables via an char **environ (or similar, don't remember for sure) pointer, which means ixemul has to create this array. In fact, Unix even passes this pointer to your main() function. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 18:45:33 1995 Received: from dec1 ([193.52.100.2]) by nic.funet.fi with SMTP id <90614-3>; Fri, 20 Oct 1995 18:45:05 +0200 Received: from localhost by dec1; (5.65/1.1.8.2/06Sep94-0651PM) id AA00201; Fri, 20 Oct 1995 17:50:58 +0100 Sender: poizat@ensinfo.univ-nantes.fr Message-Id: <3087D372.41C6@ensinfo.univ-nantes.fr> Date: Fri, 20 Oct 1995 17:50:58 +0100 From: Pascal POIZAT X-Mailer: Mozilla 2.0b1 (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: amiga-gcc-port@nic.funet.fi Subject: Perl5 X-Url: http://www.sciences.univ-nantes.fr/info/perso/etudiants/poizat/amiga-gcc-port@lists.funet.fi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Does Perl5 has been released for the Amiga ? Pascal -- ||| oO oo +---oOO-\_/-OOo--------------------------+-------------------------------+ |Pascal Poizat, DEA Informatique |"Pourquoi le travail a faire | |EMail: poizat@ensinfo.univ-nantes.fr | est-il toujours pour demain ?"| +----------------------------------------+-------------------------------+ |WWW: http://www.sciences.univ-nantes.fr/info/perso/etudiants/poizat/ | +----------------------------------------+-------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 18:45:38 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90017-1>; Fri, 20 Oct 1995 18:44:48 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t6KaD-0004nYC; Fri, 20 Oct 95 09:46 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Number of processes limit?? To: robert@lodz.pdi.net Date: Fri, 20 Oct 1995 09:46:13 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <217b96eb.u8t20e.b8f26-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Oct 20, 95 05:01:37 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 399 > Recently I was quite heavily recompiling varius packages using GCC 2.7.0. > During this proccess i was every now and than seeing message cannot fork - try > again - errno 67. I've checked that errno value and it says Too many processes. I think that everytime I've seen this message, it has been because I was out of memory. Now that I have 48 Mb I haven't seen it in a long time. :-) -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 18:52:27 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with SMTP id <90557-3>; Fri, 20 Oct 1995 18:52:10 +0200 Received: by colombo.telesys-innov.fr; Fri, 20 Oct 1995 17:51:45 GMT From: Philippe BRAND Message-Id: <199510201751.RAA15816@colombo.telesys-innov.fr> Subject: Re: Number of processes limit?? To: fnf@amigalib.com (Fred Fish) Date: Fri, 20 Oct 1995 17:51:44 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Fred Fish" at Oct 20, 95 09:46:13 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 569 Fred Fish writes: > I think that everytime I've seen this message, it has been because I > was out of memory. Now that I have 48 Mb I haven't seen it in a long > time. :-) Same for me with my 42MB configuration. BUT I remember a thread on this list started by me I think, because max process is hard-coded into ixemul. I asked then to modify ixemul in order to have a dynamic handling. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 18:53:32 1995 Received: from sunic.sunet.se ([192.36.125.2]) by nic.funet.fi with SMTP id <90754-3>; Fri, 20 Oct 1995 18:53:18 +0200 Received: from Minsk.DoCS.UU.SE by sunic.sunet.se (8.6.8/2.03) id RAA23758; Fri, 20 Oct 1995 17:53:13 +0100 Received: by Minsk.DoCS.UU.SE (Sun-4/630, SunOS 4.1.2) with sendmail 5.61-bind 1.5+ida/ICU/DoCS id AA24137; Fri, 20 Oct 95 17:53:11 +0100 From: Erik Trulsson Message-Id: <9510201653.AA24137@Minsk.DoCS.UU.SE> Subject: Re: Perl5 To: poizat@ensinfo.univ-nantes.fr (Pascal POIZAT) Date: Fri, 20 Oct 1995 17:53:11 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <3087D372.41C6@ensinfo.univ-nantes.fr> from "Pascal POIZAT" at Oct 20, 95 05:50:58 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 489 > > Hi > > Does Perl5 has been released for the Amiga ? > > Pascal > -- > Short answer: No. Long answer: No not yet, but since nobody else seem to have done it I have started to try porting it myself. Ask again next week and we will see how far I have got... Oh , and for those who couldn't run the Configure script before due to memory leaks (I saw some reports about that) , good news: Something must have changed since I didn't have too much trouble running it on my 6MB A1200. From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 18:58:39 1995 Received: from gate1.informatik.fh-wiesbaden.de ([193.175.36.254]) by nic.funet.fi with SMTP id <89991-4>; Fri, 20 Oct 1995 18:58:09 +0200 Received: from sun.informatik.fh-wiesbaden.de (sun15.informatik.fh-wiesbaden.de) by gate1.informatik.fh-wiesbaden.de with SMTP id AA02984 (5.65c/IDA-1.4.4 for ); Fri, 20 Oct 1995 17:57:55 +0100 Received: by sun.informatik.fh-wiesbaden.de (4.1/fhw-FBI_sun-Nl) id AA08325; Fri, 20 Oct 95 17:57:52 +0100 From: i511@informatik.fh-wiesbaden.de (Stefan Ruppert) Message-Id: <9510201657.AA08325@sun.informatik.fh-wiesbaden.de> Subject: Re: Ixemul To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Fri, 20 Oct 1995 17:57:51 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Oct20.170615+0100mesz.395721-1+767@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Oct 20, 95 05:05:59 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 962 > > > > > Why does the startupcode try to read all env. variables? > > This is because ixemul is not meant to be a "normal" library. It is meant > to emulate a Unix environment as much as possible. On Unix, you can access > the environment variables via an char **environ (or similar, don't remember > for sure) pointer, which means ixemul has to create this array. In fact, > Unix even passes this pointer to your main() function. The implementation for that is just to slow, I think. So here is a idea : First ixemul is loaded it should scan the ENV: directory and remember the DateStamp of the directory. Then it have only to compare the DateStamp of the internal ENV list and the actual DateStamp of ENV:. If ENV: is newer it must update the internal list. Is this possible ? Stefan -- Home: Stefan Ruppert Windthorststrasse 5 65439 Floersheim am Main GERMANY EMail: i511@informatik.fh-wiesbaden.de ruppert@gundel.zdv.uni-mainz.de From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 18:58:41 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90595-3>; Fri, 20 Oct 1995 18:58:08 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id RAA03600; Fri, 20 Oct 1995 17:56:25 +0100 From: Lars Hecking Message-Id: <199510201700.SAA21234@mostar.nmrc.ucc.ie> Subject: Re: Perl5 To: trulsson@Minsk.DoCS.UU.SE (Erik Trulsson) Date: Fri, 20 Oct 1995 18:00:20 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9510201653.AA24137@Minsk.DoCS.UU.SE> from "Erik Trulsson" at Oct 20, 95 05:53:11 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 355 > Oh , and for those who couldn't run the Configure script before due to > memory leaks (I saw some reports about that) , good news: Something > must have changed since I didn't have too much trouble running it on my 6MB > A1200. The memory leak was in sh. This has been fixed by Hans Verkuil a few months ago. I haven't try perl5 again since that. From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 19:09:41 1995 Received: from sunic.sunet.se ([192.36.125.2]) by nic.funet.fi with SMTP id <90451-1>; Fri, 20 Oct 1995 19:08:49 +0200 Received: from Minsk.DoCS.UU.SE by sunic.sunet.se (8.6.8/2.03) id SAA27791; Fri, 20 Oct 1995 18:08:47 +0100 Received: by Minsk.DoCS.UU.SE (Sun-4/630, SunOS 4.1.2) with sendmail 5.61-bind 1.5+ida/ICU/DoCS id AA22786; Fri, 20 Oct 95 17:13:27 +0100 From: Erik Trulsson Message-Id: <9510201613.AA22786@Minsk.DoCS.UU.SE> Subject: Re: Number of processes limit?? To: robert@lodz.pdi.net Date: Fri, 20 Oct 1995 17:13:26 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <217b96eb.u8t20e.b8f26-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Oct 20, 95 05:01:37 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1044 > > Hi all! > Recently I was quite heavily recompiling varius packages using GCC 2.7.0. > During this proccess i was every now and than seeing message cannot fork - try > again - errno 67. I've checked that errno value and it says Too many processes. > Now is ixemul library limiting the number of processes in any way or it is > some other error hiding behind this one? > I've seen this cannot fork message in configure scripts and at varius points > of various make's. Most of the time it was just a matter of retrying once > (twice, ...) again but sometime i had to reboot Amiga to proceed any further. > > regards > Robert I have seen this message a couple of times too. I think that it is 'sh' that prints it. I think that the reason simply is low memory. That it works (sometimes) if you retry is probably because something gets flushed. In the more complex Configure scripts and makefiles there are usually many processes running in parallell and when you retry one or two of them might have quit thus freeing memory. From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 19:10:52 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90700-4>; Fri, 20 Oct 1995 19:10:39 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26528-1>; Fri, 20 Oct 1995 18:10:10 +0100 Received: from hphalle6h.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395721-2>; Fri, 20 Oct 1995 18:10:07 +0100 Subject: Re: Ixemul From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 20 Oct 1995 18:09:51 +0100 (MEZ) In-Reply-To: <9510201657.AA08325@sun.informatik.fh-wiesbaden.de> from "Stefan Ruppert" at Oct 20, 95 05:57:51 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 993 Message-Id: <95Oct20.181007+0100mesz.395721-2+788@hphalle0.informatik.tu-muenchen.de> > The implementation for that is just to slow, I think. So here is a idea : > First ixemul is loaded it should scan the ENV: directory and remember the > DateStamp of the directory. Then it have only to compare the DateStamp of > the internal ENV list and the actual DateStamp of ENV:. If ENV: is newer > it must update the internal list. Is this possible ? Sort of. It would still have to copy the local variables, of course :) The main "problem" is that, to my knowledge, modifying a file will only change the datestamp of the parent directory, but not the datestamp of the parent's parent... that means ixemul would only see toplevel changes. To avoid this, ixemul would have to remember the datestamps of all directories in ENV: Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 19:23:14 1995 Received: from gate1.informatik.fh-wiesbaden.de ([193.175.36.254]) by nic.funet.fi with SMTP id <90388-1>; Fri, 20 Oct 1995 19:22:27 +0200 Received: from sun.informatik.fh-wiesbaden.de (sun15.informatik.fh-wiesbaden.de) by gate1.informatik.fh-wiesbaden.de with SMTP id AA03019 (5.65c/IDA-1.4.4 for ); Fri, 20 Oct 1995 18:22:07 +0100 Received: by sun.informatik.fh-wiesbaden.de (4.1/fhw-FBI_sun-Nl) id AA08411; Fri, 20 Oct 95 18:21:59 +0100 Date: Fri, 20 Oct 1995 18:21:56 +0100 (MET) From: Stefan Ruppert To: Christian Stieber Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Ixemul In-Reply-To: <95Oct20.181007+0100mesz.395721-2+788@hphalle0.informatik.tu-muenchen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Sort of. It would still have to copy the local variables, of course :) > The main "problem" is that, to my knowledge, modifying a file will only > change the datestamp of the parent directory, but not the datestamp > of the parent's parent... that means ixemul would only see toplevel > changes. To avoid this, ixemul would have to remember the datestamps > of all directories in ENV: But have you ever seen a env variable like the following under Unix ? MYPROG/MYPATH Ciao Stefan Home: Stefan Ruppert Windthorststrasse 5 65439 Floersheim am Main GERMANY EMail: i511@informatik.fh-wiesbaden.de ruppert@gundel.zdv.uni-mainz.de From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 19:26:49 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90532-2>; Fri, 20 Oct 1995 19:26:15 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26528-2>; Fri, 20 Oct 1995 18:25:49 +0100 Received: from hphalle6h.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395721-2>; Fri, 20 Oct 1995 18:25:52 +0100 Subject: Re: Ixemul From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 20 Oct 1995 18:25:44 +0100 (MEZ) In-Reply-To: from "Stefan Ruppert" at Oct 20, 95 06:21:56 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 533 Message-Id: <95Oct20.182552+0100mesz.395721-2+791@hphalle0.informatik.tu-muenchen.de> > > changes. To avoid this, ixemul would have to remember the datestamps > > of all directories in ENV: > > But have you ever seen a env variable like the following under Unix ? > > MYPROG/MYPATH No. But why scan ENV: at all? Have you ever seen a global variable in Unix? Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Fri Oct 20 19:54:31 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90764-2>; Fri, 20 Oct 1995 19:53:51 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t6Lf5-0004nYC; Fri, 20 Oct 95 10:55 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Perl5 To: trulsson@Minsk.DoCS.UU.SE (Erik Trulsson) Date: Fri, 20 Oct 1995 10:55:18 -0700 (MST) Cc: poizat@ensinfo.univ-nantes.fr, amiga-gcc-port@nic.funet.fi In-Reply-To: <9510201653.AA24137@Minsk.DoCS.UU.SE> from "Erik Trulsson" at Oct 20, 95 05:53:11 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 388 > > Does Perl5 has been released for the Amiga ? > Short answer: No. > Long answer: No not yet, but since nobody else seem to have done it > I have started to try porting it myself. Ask again next week and we will > see how far I have got... I have a port I did almost a year ago, but never got it to cleanly pass it's test suite. You are welcome to start with that if you wish. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Oct 21 02:06:34 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90599-1>; Sat, 21 Oct 1995 02:04:10 +0200 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0t6RQV-000R0cC; Sat, 21 Oct 95 01:04 MET Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0t6QdQ-000GHPC; Sat, 21 Oct 95 00:13 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0a40@wyst.hobby.nl>; Sat, 21 Oct 95 00:11:22 CET Message-Id: <9510202311.0a40@wyst.hobby.nl> Date: Fri, 20 Oct 1995 23:11:20 +0000 (CET) In-Reply-To: from "Rask Lambertsen" at Oct 20, 95 02:47:49 pm Content-Type: text Content-Length: 917 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Ixemul According to Rask Lambertsen: > > It would be nice if something could be done so that reading the entire ENV: > each time an ixemul programme is started wouldn't be necessary. It=20 > certanly slows down programme startup a lot, around 3 seconds on my system. > Imagine how long it would take if I ran MUI and it had to read the entire= > =20 > "ENV:MUI/whatever_junk_is_left_there" directory. 'ixconfig -i' will cause the library to skip reading ENV:. Of course, this means that none of the variables in ENV: will ever be seen by applications. The solution is to use local variables (using 'set') instead. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat Oct 21 15:07:24 1995 Received: from DBSTU1.RZ.TU-BS.DE ([134.169.1.1]) by nic.funet.fi with SMTP id <89039-2>; Sat, 21 Oct 1995 15:03:52 +0200 Received: from rzab0.rz.tu-bs.de by DBSTU1.RZ.TU-BS.DE (IBM VM SMTP V2R2) with TCP; Sat, 21 Oct 95 14:03:44 MEZ Received: by rzab0.rz.tu-bs.de (1.37.109.15/15.6) id AA052198764; Sat, 21 Oct 1995 13:32:44 +0100 From: Sven Heithecker Subject: Compiler-Bug ? To: amiga-gcc-port@nic.funet.fi (Sven Heithecker) Date: Sat, 21 Oct 1995 13:32:43 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL11] Content-Type: text Content-Length: 609 Message-Id: <95Oct21.150352+0200_eet.89039-2+63@nic.funet.fi> Hi ! I recently got the compiler-error "..register spilled. This may be due to improper use of asm stats or to a compiler bug>. I don't remember that msg exactly, but it was something linke this. I got this Msg when compiling with -resident. What I can say is that I didn't use any asm stats, and that i got this msg a few also weeks ago, but it disappeared when compiling with -O3. Now it doesn't disappear. It seems to me that gcc runs out of registers somehow. Is there any workaround ? ciao, ____ |_||_ Ceterum Censeo MEGAHARD Esse Delendam | | _| HTS Sven Heithecker s.heithecker@tu-bs.de From amiga-gcc-port-owner@nic.funet.fi Sat Oct 21 19:13:45 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <89615-2>; Sat, 21 Oct 1995 19:12:03 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id JAA19739 at Sat, 21 Oct 1995 09:30:38 +0200 Received: by softlab.ece.ntua.gr with UUCP id JAA00356 at Sat, 21 Oct 1995 09:34:31 +0200 (EET) Received: by kriton.UUCP (V1.17-beta/Amiga) id <08np@kriton.UUCP>; Sat, 21 Oct 95 09:28:23 EET Date: Sat, 21 Oct 95 09:28:23 EET Message-Id: <9510210728.08np@kriton.UUCP> In-Reply-To: <9510202311.0a40@wyst.hobby.nl> (from theseas!wyst.hobby.nl!hans (Hans Verkuil)) (at Fri, 20 Oct 1995 23:11:20 +0000 (CET)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!wyst.hobby.nl!hans@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: Ixemul Hi Hans (Hans Verkuil), in <9510202311.0a40@wyst.hobby.nl> on Oct 20 you wrote: > 'ixconfig -i' will cause the library to skip reading ENV:. Of course, this > means that none of the variables in ENV: will ever be seen by applications. > The solution is to use local variables (using 'set') instead. Ah, but isn't this option soon going to be removed from ixemul, which is going to behave as if the option is always on? (The option has already been removed from ixprefs 2 beta.) -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "There's nothing like a nice walk in the countryside." "And this is nothing like a nice walk in the countryside!" ----- From amiga-gcc-port-owner@nic.funet.fi Sun Oct 22 18:14:39 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90683-4>; Sun, 22 Oct 1995 18:11:05 +0200 Received: from bastion.nmrc.ucc.ie (nmrc.ucc.ie [143.239.64.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id QAA03238 for ; Sun, 22 Oct 1995 16:11:00 GMT Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id RAA29275; Sun, 22 Oct 1995 17:09:14 +0100 From: Lars Hecking Message-Id: <199510221613.RAA22689@mostar.nmrc.ucc.ie> Subject: BIN:nm -- minor bug? To: phb@colombo.telesys-innov.fr (Philippe Brand) Date: Sun, 22 Oct 1995 17:13:10 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 182 $ nm libc.a nm: ARFILENAMES: File format not recognized [symbol listing ok] This is with nm and libc.a from the aminet gcc270 distrib. ranlib'ing libc.a doesn't make a difference. From amiga-gcc-port-owner@nic.funet.fi Sun Oct 22 22:51:11 1995 Received: from wckn.dorm.clarkson.edu ([128.153.48.2]) by nic.funet.fi with SMTP id <90451-1>; Sun, 22 Oct 1995 22:50:30 +0200 Received: by wckn.dorm.clarkson.edu (4.1/SMI-4.1) id AA15891; Sun, 22 Oct 95 16:50:13 EDT Date: Sun, 22 Oct 95 16:50:13 EDT From: Rob Message-Id: <9510222050.AA15891@wckn.dorm.clarkson.edu> To: amiga-gcc-port@nic.funet.fi Subject: template problem I'm getting some confusing error messages from gcc when trying to use templates. Given the following code: ----testlib.h---- class RNode { int item; public: friend class RList; }; template class RList { public: void DoSomething(); }; ----testlib.c---- #include #include "testlib.h" template void RList::DoSomething() { RNode *newNode; /*---------------------------------*/ newNode = new RNode; newNode->item = 0; // Line 17 return; } template class RList; ----test.cxx---- #include #include #include "testlib.h" int main() { RList x; x.DoSomething(); return 0; } and compiling with the following options: gxx -m68030 -noixemul -O0 -fno-implicit-templates -c testlib.cxx -o testlib.o I get these errors: testlib.cxx: In method `void RList::DoSomething()': testlib.cxx:17: member `item' is a private member of class `RNode' I'm very new to C++ and gcc but shouldn't the RNode allow access by an RList of any data type if RList is declated a friend of RNode? Thanks for any help... -Robert Dick (dickrp@wckn.dorm.clarkson.edu)- From amiga-gcc-port-owner@nic.funet.fi Sun Oct 22 22:59:31 1995 Received: from wckn.dorm.clarkson.edu ([128.153.48.2]) by nic.funet.fi with SMTP id <90595-2>; Sun, 22 Oct 1995 22:59:17 +0200 Received: by wckn.dorm.clarkson.edu (4.1/SMI-4.1) id AA16161; Sun, 22 Oct 95 16:58:56 EDT Date: Sun, 22 Oct 95 16:58:56 EDT From: Rob Message-Id: <9510222058.AA16161@wckn.dorm.clarkson.edu> To: amiga-gcc-port@nic.funet.fi Subject: template problems I forgot to mention that I'm using gcc release 2.7.0. -Robert Dick (dickrp@wckn.dorm.clarkson.edu)- From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 10:16:38 1995 Received: from chopin.ucc.hull.ac.uk ([150.237.176.14]) by nic.funet.fi with ESMTP id <90890-4>; Mon, 23 Oct 1995 10:15:06 +0200 Received: from mailhub.dcs.hull.ac.uk (actually host bertie.dcs.hull.ac.uk) by chopin with SMTP internet(PP); Mon, 23 Oct 1995 09:09:08 +0100 Received: from scarlet.dcs.hull.ac.uk by mailhub.dcs.hull.ac.uk with smtp (Smail3.1.29.1 #3) id m0t7Hyf-0003rVC; Mon, 23 Oct 95 08:11 GMT From: Chris Watson Message-Id: <15815.9510230815@scarlet.dcs.hull.ac.uk> Subject: Re: template problem To: dickrp@wckn.dorm.clarkson.edu (Rob) Date: Mon, 23 Oct 1995 08:15:59 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9510222050.AA15891@wckn.dorm.clarkson.edu> from "Rob" at Oct 22, 95 04:50:13 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2309 > ----testlib.h---- > class RNode { > int item; > public: > friend class RList; > }; > > template > class RList { > public: > void DoSomething(); > }; > > ----testlib.c---- > #include > #include "testlib.h" > > template > void RList::DoSomething() { > RNode *newNode; > /*---------------------------------*/ > newNode = new RNode; > newNode->item = 0; // Line 17 > return; > } > template class RList; > > ----test.cxx---- > #include > #include > #include "testlib.h" > > int main() { > RList x; > > x.DoSomething(); > > return 0; > } > I get these errors: > testlib.cxx: In method `void RList::DoSomething()': > testlib.cxx:17: member `item' is a private member of class `RNode' > > I'm very new to C++ and gcc but shouldn't the RNode allow access by an > RList of any data type if RList is declated a friend of RNode? > > Thanks for any help... > > -Robert Dick (dickrp@wckn.dorm.clarkson.edu)- You do actually have two problems here. Firstly, the solution to your stated problem is that gcc is right. Friend only allows access to protected members and item is of course private. Declaring item protected should sort it out. A better idea though is to set item in RNode constructors. class RNNode { int item; public: RNode (int i = 0) : item (i) {} }; Which means you can simplify DoSomething and remove line 17. Though of course this depends entirely on what else happens to item. void RList::DoSomething() { RNode *newNode; /*---------------------------------*/ newNode = new RNode; return; } One point is that if RNode stays relatively simple, it isn't worth dealing with pointers to it. Just use real versions of it and let gcc deal with the problem of allocating and copying them. The real problem though is that your use of templates is wrong. You declare x as being of type RList and that's what it is. It has nothing to do with RNode, each member of x is simply an integer. If you wanted RNode as your list entry you need: RList x; I think that you do really want a list of integers in which case you need to flesh out RList and ignore RNode. A template list should be non-intrusive, otherwise it's not fully reusable. Chris From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 12:53:04 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90512-3>; Mon, 23 Oct 1995 12:51:44 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA25033; Mon, 23 Oct 1995 11:50:47 +0100 Date: Mon, 23 Oct 1995 11:50:46 +0100 (MET) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: template problem To: Chris Watson cc: Rob , amiga-gcc-port@nic.funet.fi In-Reply-To: <15815.9510230815@scarlet.dcs.hull.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Mon, 23 Oct 1995, Chris Watson wrote: > > ----testlib.h---- > > class RNode { > > int item; > > public: > > friend class RList; > > }; > > > > template > > class RList { > > public: > > void DoSomething(); > > }; > You do actually have two problems here. Firstly, the solution to your > stated problem is that gcc is right. Friend only allows access to > protected members and item is of course private. I have to disagree with you. "Friend" gives you access both to "protected" and "private". G++ is most probably wrong. I think that correct version of "testlib.h" should look like this: template class RList; class RNode { int item; public: friend template class RList; // Line x }; template class RList { public: void DoSomething(); }; However, G++ won't accept this code. This is most probably caused by its infamous bug in templates handling: it can't "swallow" templates in local scope, in "Line x" you'll get some parse-error messages. You can workaround this problem like this: template class RList; class RNode { int item; public: friend class RList; }; If you need more general friendship between this classes, you have to make "RNode" a template class as well - sth. like this: template class RList; template class RNode { int item; public: friend class RList; }; > Chris / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 12:54:48 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90916-4>; Mon, 23 Oct 1995 12:54:32 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA25222; Mon, 23 Oct 1995 11:55:23 +0100 Date: Mon, 23 Oct 1995 11:55:22 +0100 (MET) From: Kamil Iskra Subject: Re: Ixemul To: Christian Stieber cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Oct20.181007+0100mesz.395721-2+788@hphalle0.informatik.tu-muenchen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 20 Oct 1995, Christian Stieber wrote: > Sort of. It would still have to copy the local variables, of course :) > The main "problem" is that, to my knowledge, modifying a file will only > change the datestamp of the parent directory, but not the datestamp > of the parent's parent... that means ixemul would only see toplevel > changes. To avoid this, ixemul would have to remember the datestamps > of all directories in ENV: Please excuse my ignorance, but what about "directory notification"? I've never used it or read about it, but I've heard that it causes a process to be notified when something in specified directory is changed. Does this work with files in this directory only, or recursively in subdirectories, too? If the latter one, this could be used. > Christian / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 13:32:28 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90364-3>; Mon, 23 Oct 1995 13:31:45 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA20247 (5.65c8/IDA-1.4.4 for ); Mon, 23 Oct 1995 12:31:18 +0100 Received: by diva.gmd.de id AA02361 (5.67b8/IDA-1.5); Mon, 23 Oct 1995 12:28:37 +0100 Date: Mon, 23 Oct 1995 12:28:37 +0100 From: Joerg Hoehle Message-Id: <199510231128.AA02361@diva.gmd.de> To: amiga-gcc-port@nic.funet.fi, y0000135@ws.rz.tu-bs.de Subject: Re: Compiler-Bug ? hi, Sven wrote: > I recently got the compiler-error "..register spilled. This may be due to improper use of > What I can say is that I didn't use any asm stats > It seems to me that gcc runs out of registers somehow. Is there any workaround ? Does the function implied use any OS-inline functions? Which functions? Try to avoid using inline functions for this one function. hope this helps, Joerg. From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 13:39:28 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90657-3>; Mon, 23 Oct 1995 13:38:48 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA20547 (5.65c8/IDA-1.4.4 for ); Mon, 23 Oct 1995 12:38:34 +0100 Received: by diva.gmd.de id AA02367 (5.67b8/IDA-1.5); Mon, 23 Oct 1995 12:35:52 +0100 Date: Mon, 23 Oct 1995 12:35:52 +0100 From: Joerg Hoehle Message-Id: <199510231135.AA02367@diva.gmd.de> To: hans@wyst.hobby.nl, kyrimis@softlab.ece.ntua.gr Subject: Re: Ixemul Cc: amiga-gcc-port@nic.funet.fi Hi, Kriton wrote: > > 'ixconfig -i' will cause the library to skip reading ENV:. Of course, this > Ah, but isn't this option soon going to be removed from ixemul, which is going > to behave as if the option is always on? (The option has already been removed > from ixprefs 2 beta.) Argh, who dared to removed ixemul's ability to use the global environment in ENV:? Did s/he know how much damage was created when some ixemul 39.x (47?) made not accessing ENV: the default? How many people thought their software was broken? How many cursed ixemul to hell and how many had to use one version or another depending on the application? We can all be glad using ENV: was turned on again in later versions. A solution might be to try to find out why reading ENV: seems to take seconds on some systems and no time on others, but ... Just don't ignore ENV:! Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 13:59:23 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90769-3>; Mon, 23 Oct 1995 13:58:36 +0200 Received: from hpcl.hpcl (hpcl.cti.gr) by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HWS5VTQYPS90Z166@LEON.CTI.GR>; Mon, 23 Oct 1995 13:55:14 EET Received: from hpcl3.hpcl by hpcl.hpcl (4.1/SMI-4.1) id AA13069; Mon, 23 Oct 95 14:00:40 +0200 Date: Mon, 23 Oct 1995 14:00:37 +0200 (EET) From: kyrimis@hpcl (Kriton Kyrimis) Subject: Re: Ixemul In-reply-to: <199510231135.AA02367@diva.gmd.de> from "Joerg Hoehle" at Oct 23, 95 12:35:52 pm To: hoehle@zeus.gmd.de (Joerg Hoehle) Cc: amiga-gcc-port@lists.funet.fi (gcc) Message-id: <9510231200.AA13069@hpcl.hpcl> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 479 > Argh, who dared to removed ixemul's ability to use the global > environment in ENV:? Did s/he know how much damage was created when Nobody did anything. What Hans Verkuil told me he was planning to do in the future, was to *always* read the environment, ignoring the ixemul setting, which will be made obsolete. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If you can't stand the cold, stay out of the freezer!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 14:33:30 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90752-4>; Mon, 23 Oct 1995 14:31:55 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA22902 (5.65c8/IDA-1.4.4 for ); Mon, 23 Oct 1995 13:31:27 +0100 Received: by diva.gmd.de id AA02390 (5.67b8/IDA-1.5); Mon, 23 Oct 1995 13:28:46 +0100 Date: Mon, 23 Oct 1995 13:28:46 +0100 From: Joerg Hoehle Message-Id: <199510231228.AA02390@diva.gmd.de> To: amiga-gcc-port@nic.funet.fi, stieber@informatik.tu-muenchen.de Subject: Re: Ixemul Hi, Christian wrote: > No. But why scan ENV: at all? Have you ever seen a global variable in > Unix? I'd claim that every variable that you set in your .profile or .login is to be considered as global or more in UNIX as an ENV: variable in AmigaDOS. I do not feel like having the complete hierarchy of my processes in mind when accessing a variable and making sure that a given process gets the variables it needs. What do you do for WB-launched processes? Modify your user-startup and reboot your computer (c.f. Windoof)? Having a globally accessible and modifiable "environment" is a big advantage. You will have to retink part of it when it comes to multi-users but it works extremely well so far. Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 15:04:18 1995 Received: from mail.cs.tu-berlin.de ([130.149.17.13]) by nic.funet.fi with ESMTP id <90053-1>; Mon, 23 Oct 1995 15:03:20 +0200 Received: from bull.cs.tu-berlin.de (halamoda@bull.cs.tu-berlin.de [130.149.92.14]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id OAA08504 for ; Mon, 23 Oct 1995 14:02:45 +0100 Received: (halamoda@localhost) by bull.cs.tu-berlin.de (8.6.12/8.6.6) id OAA24641; Mon, 23 Oct 1995 14:02:43 +0100 Date: Mon, 23 Oct 1995 14:02:41 +0100 (MET) From: Adrian Halamoda To: amiga-gcc-port@nic.funet.fi Subject: Linker problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello ! I have written a program in C++ which compiles fine under gcc for UNIX. I've tried to compile it on my Amiga with GCC 2.7.0 - it compiles fine, but when linking I have a bunch of undefined symbols. In one case a virtual table for a class is missing, and the rest are inline functions which for some reasons are referenced insted of being inlined. As I said the programs compiles fine with GCC 2.6.3 on UNIX. Is it a bug in GCC or a bug in Amiga port ? Has anyone had similar problems ? Thanks in advance for help. Adrian Halamoda, Computer Science student E-mail: halamoda@cs.tu-berlin.de WWW: http://www.cs.tu-berlin.de/~halamoda/ // AOS Project member. \X/ From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 15:07:27 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90191-4>; Mon, 23 Oct 1995 15:07:06 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA24748 (5.65c8/IDA-1.4.4 for ); Mon, 23 Oct 1995 14:06:56 +0100 Received: by diva.gmd.de with UUCP id AA02408 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Mon, 23 Oct 1995 14:04:16 +0100 Date: Mon, 23 Oct 1995 14:04:16 +0100 Message-Id: <199510231304.AA02408@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi (gcc) Subject: Re: Ixemul In-Reply-To: <9510231200.AA13069@hpcl.hpcl> References: <199510231135.AA02367@diva.gmd.de> <9510231200.AA13069@hpcl.hpcl> Hi, Kriton Kyrimis writes: > > Argh, who dared to removed ixemul's ability to use the global > > environment in ENV:? > Nobody did anything. What Hans Verkuil told me he was planning to do in the > future, was to *always* read the environment, ignoring the ixemul setting, Then I misunderstood your former posting: > Hi Hans (Hans Verkuil), in <9510202311.0a40@wyst.hobby.nl> on Oct 20 you wrote: > > 'ixconfig -i' will cause the library to skip reading ENV:. Of course, this > > means that none of the variables in ENV: will ever be seen by applications. > > The solution is to use local variables (using 'set') instead. > > Ah, but isn't this option soon going to be removed from ixemul, which is going > to behave as if the option is always on? (The option has already been removed I understood "always on" as "ixconfig -i" meaning "ignore ENV:"... Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 15:31:33 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <90160-2> convert rfc822-to-8bit; Mon, 23 Oct 1995 15:30:34 +0200 Received: by tycho.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 23 Oct 1995 14:29:13 +0100 (MET) From: Rask Lambertsen To: Adrian Halamoda Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Linker problems In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 23 Oct 1995, Adrian Halamoda wrote: > > Hello ! > > I have written a program in C++ which compiles fine under gcc for UNIX. > I've tried to compile it on my Amiga with GCC 2.7.0 - it compiles fine, > but when linking I have a bunch of undefined symbols. In one case a > virtual table for a class is missing, and the rest are inline functions > which for some reasons are referenced insted of being inlined. As I said > the programs compiles fine with GCC 2.6.3 on UNIX. Is it a bug in GCC or > a bug in Amiga port ? Has anyone had similar problems ? Did you use "gcc ..." instead of "g++ ..." when compiling? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 15:51:41 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89989-2> convert rfc822-to-8bit; Mon, 23 Oct 1995 15:50:41 +0200 Received: from mail.cs.tu-berlin.de (actually user root@mail.cs.tu-berlin.de) by funet.fi with SMTP (PP); Mon, 23 Oct 1995 15:50:23 +0200 Received: from bull.cs.tu-berlin.de (halamoda@bull.cs.tu-berlin.de [130.149.92.14]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id OAA10813; Mon, 23 Oct 1995 14:48:30 +0100 Received: (halamoda@localhost) by bull.cs.tu-berlin.de (8.6.12/8.6.6) id OAA25000; Mon, 23 Oct 1995 14:48:28 +0100 Date: Mon, 23 Oct 1995 14:48:26 +0100 (MET) From: Adrian Halamoda To: Rask Lambertsen cc: amiga-gcc-port@nic.funet.fi Subject: Re: Linker problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 23 Oct 1995, Rask Lambertsen wrote: > On Mon, 23 Oct 1995, Adrian Halamoda wrote: > > > > > Hello ! > > > > I have written a program in C++ which compiles fine under gcc for UNIX. > > I've tried to compile it on my Amiga with GCC 2.7.0 - it compiles fine, > > but when linking I have a bunch of undefined symbols. In one case a > > virtual table for a class is missing, and the rest are inline functions > > which for some reasons are referenced insted of being inlined. As I said > > the programs compiles fine with GCC 2.6.3 on UNIX. Is it a bug in GCC or > > a bug in Amiga port ? Has anyone had similar problems ? > > Did you use "gcc ..." instead of "g++ ..." when compiling? > I use g++ for compiling and linking. What's the difference anyway ? BTW does anyone know why gcc doesn't recognize .cxx extension as C++ source - it should according to docs. > Regards, > > /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ > | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | > | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | > | Keyboard error: and are stuck - press to continue | > > Adrian Halamoda, Computer Science student E-mail: halamoda@cs.tu-berlin.de WWW: http://www.cs.tu-berlin.de/~halamoda/ // AOS Project member. \X/ From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 19:33:33 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89886-1>; Mon, 23 Oct 1995 18:58:53 +0200 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0t7QFu-000R89C; Mon, 23 Oct 95 18:01 MET Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0t7GtX-000G8pC; Mon, 23 Oct 95 08:02 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0a4g@wyst.hobby.nl>; Sun, 22 Oct 95 15:54:13 CET Message-Id: <9510221454.0a4g@wyst.hobby.nl> Date: Sun, 22 Oct 1995 14:54:11 +0000 (CET) In-Reply-To: <9510210728.08np@kriton.UUCP> from "Kriton Kyrimis" at Oct 21, 95 09:28:23 am Content-Type: text Content-Length: 914 From: hans@wyst.hobby.nl (Hans Verkuil) To: kyrimis@softlab.ece.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Ixemul According to Kriton Kyrimis: > > Hi Hans (Hans Verkuil), in <9510202311.0a40@wyst.hobby.nl> on Oct 20 you wrote: > > > 'ixconfig -i' will cause the library to skip reading ENV:. Of course, this > > means that none of the variables in ENV: will ever be seen by applications. > > The solution is to use local variables (using 'set') instead. > > Ah, but isn't this option soon going to be removed from ixemul, which is going > to behave as if the option is always on? (The option has already been removed > from ixprefs 2 beta.) No, what made you think so? It's one of the more useful options, actually. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 19:33:40 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89528-1>; Mon, 23 Oct 1995 18:47:50 +0200 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt; (5.65v3.0/1.1.8.2/24Jul95-0207PM) id AA17336; Mon, 23 Oct 1995 17:46:54 GMT Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/08Aug95-1153AM) id AA24813; Mon, 23 Oct 1995 17:47:25 GMT Date: Mon, 23 Oct 1995 17:47:23 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: amiga-gcc-port@nic.funet.fi Subject: More about VMM and gcc outputs Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From my last research over using VMM for both data and code in gcc and it's outputs i came to the folowing conclusion: In normal cases of simple UniX source compilation, there is, aparently, no reason for incorrect operation or crash. Never the less there is one condition that can create a Page-Fault-In -Supervisor-Mode which, as you must know, is deadly: - A SIG_CTRLC sent by the normal keyboard combination or the break command sends an AMIGA control-C to the process which doesnt map directly to the UniX (in this case ixemul) signal. Signals, in ixemul, are, like in UniX, interpreted at exit from a kernel primitive and are stored as flags inside the ixemul data section. For the Amiga ctrl-C to work, to each ixemul client is given a signal-exeption that responds to the Amiga ctrl-C and sends a UniX ctrl-C ( kill(SIG_CTRLC) ) to itself. Thats all fine, for now. TYhe problem is that signal-exeptions run in Supervisor-Mode! If this small piece of code happens to have been swapped-out you get the terminal Page-Fault-In-Supervisor-Mode, aka, guru:B500xxxx - Pedro Teixeira - PS: Please, Markus, Philippe, Fred ... correct me if I am wrong. Im not 100% shure about this. These conclusions were taken from a VMM low level debugger through a large number of non reproduceble crashes. Some information may be inacurate. From amiga-gcc-port-owner@nic.funet.fi Mon Oct 23 19:33:46 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <89934-4>; Mon, 23 Oct 1995 17:59:18 +0200 Received: from hpcl.hpcl (hpcl.cti.gr) by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HWSCO9MT68910ZRW@LEON.CTI.GR>; Mon, 23 Oct 1995 17:09:11 EET Received: from hpcl3.hpcl by hpcl.hpcl (4.1/SMI-4.1) id AA13357; Mon, 23 Oct 95 17:14:32 +0200 Date: Mon, 23 Oct 1995 17:14:31 +0200 (EET) From: kyrimis@hpcl (Kriton Kyrimis) Subject: Re: Ixemul In-reply-to: <199510231304.AA02408@diva.gmd.de> from "Joerg Hoehle" at Oct 23, 95 02:04:16 pm To: hoehle@zeus.gmd.de (Joerg Hoehle) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@theseas.softlab.ece.ntua.gr Message-id: <9510231514.AA13357@hpcl.hpcl> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 655 > Then I misunderstood your former posting: > > Ah, but isn't this option soon going to be removed from ixemul, which is going > > to behave as if the option is always on? (The option has already been removed > > I understood "always on" as "ixconfig -i" meaning "ignore ENV:"... This is a case of "do what I mean, not what I say". I was actually referring to the complementary option of -i, (-e, or whatever it's called), which means "don't ignore ENV:". I apologize for the confusion. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If you can't stand the cold, stay out of the freezer!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 08:11:37 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <89586-4>; Mon, 23 Oct 1995 21:51:49 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id VAA13502 at Mon, 23 Oct 1995 21:51:32 +0200 Received: by softlab.ece.ntua.gr with UUCP id VAA27516 at Mon, 23 Oct 1995 21:51:33 +0200 (EET) Received: by kriton.UUCP (V1.17-beta/Amiga) id <08oo@kriton.UUCP>; Mon, 23 Oct 95 21:49:11 EET Date: Mon, 23 Oct 95 21:49:11 EET Message-Id: <9510231949.08oo@kriton.UUCP> In-Reply-To: <9510221454.0a4g@wyst.hobby.nl> (from theseas!wyst.hobby.nl!hans (Hans Verkuil)) (at Sun, 22 Oct 1995 14:54:11 +0000 (CET)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!wyst.hobby.nl!hans@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: Ixemul Hi Hans (Hans Verkuil), in <9510221454.0a4g@wyst.hobby.nl> on Oct 22 you wrote: > No, what made you think so? It's one of the more useful options, actually. I mixed up "-i" with "-e"--does my message make more sense if you filter it through sed -e s/-i/-e/ ? The reason for my confusion is that writing ixprefs has made me think in terms of ixemul flags, which are toggles, rather than ixconfig options, where there are two different options referring to the same flag. Just in case I have misunderstood what you told me about the flags that are going to become obsolete in the near future (or have already become so), here is what I think is the current list: ix_unix_pattern_matching ix_no_ces_then_open_console ix_ignore_global_env ix_translate_dots ix_force_translation ix_translate_symlinks These are also the flags for which support has been dropped from ixprefs 2.0. Please have a look, and let me know if I have mistakenly removed support for any flag, or if I need to remove support for any others, in addition to those listed above. Thanks, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Is there any intelligent life here?" "Apart from me, you mean?" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 14:21:15 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90057-3>; Tue, 24 Oct 1995 14:18:57 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HWTJ046MQO00J9NA@NET2.WAU.NL>; Tue, 24 Oct 1995 13:21:19 +0000 (GMT) Received: by vines2.wau.nl; Tue, 24 Oct 95 13:18:31 +0100 Date: Tue, 24 Oct 1995 13:07:45 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: cpp MACRO expansion bug ? To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi All, I'm trying to compile 'indent.c', modified version which also handles C++, and found that there might be a bug in the handling of macro expansion in cpp. Have a look at how the following macro (check_size) is expanded. Someone tries to be clever, using /**/ which are replaced by ' ', 2 spaces, instead of '', no spaces. ---------------------- snipped of code ------------------ #include #include #define check_size(name) \ if (e_/**/name >= l_/**/name) { \ register nsize = l_/**/name-s_/**/name+400; \ name/**/buf = (char *) realloc(name/**/buf, nsize); \ e_/**/name = name/**/buf + (e_/**/name-s_/**/name) + 1; \ l_/**/name = name/**/buf + nsize - 5; \ s_/**/name = name/**/buf + 1; \ } main(argc, argv) int argc; char **argv; { check_size(code); } /* if (e_ code >= l_ code ) { register nsize = l_ code -s_ code +400; code buf = (char *) realloc( code buf, nsize); e_ code = code buf + (e_ code -s_ code ) + 1; l_ code = code buf + nsize - 5; s_ code = code buf + 1; } ; Output from the MACRO expansion: note the " " 2 spaces between the name of the var which don't belong there. */ ------------------------- end of snipped --------------------- The compiler fails on the 'if (e_ code >= l_ '. indent.c: In function `main': indent.c:nnn: `e_' undeclared (first use this function) indent.c:nnn: (Each undeclared identifier is reported only once indent.c:nnn: for each function it appears in.) Is this supposed to happen or should the /**/ be mapped to ' '? How can this macro be modified so that it does work properly on the current gcc2.7.0 Or is cpp broken and should in reality produce no spaces at all. e_code/l_code/s_code are variables used by the program. As always, please mail me a CC too. Thanks, Joop From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 14:32:30 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90595-1>; Tue, 24 Oct 1995 14:30:51 +0200 Received: from hpcl.hpcl (hpcl.cti.gr) by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HWTLC5TI3K90YKWK@LEON.CTI.GR>; Tue, 24 Oct 1995 14:28:18 EET Received: from hpcl3.hpcl by hpcl.hpcl (4.1/SMI-4.1) id AA14928; Tue, 24 Oct 95 14:33:43 +0200 Date: Tue, 24 Oct 1995 14:33:41 +0200 (EET) From: kyrimis@hpcl (Kriton Kyrimis) Subject: Re: cpp MACRO expansion bug ? In-reply-to: from "joop van de wege" at Oct 24, 95 01:07:45 pm To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@theseas.softlab.ece.ntua.gr Message-id: <9510241233.AA14928@hpcl.hpcl> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 694 > Is this supposed to happen or should the /**/ be mapped to ' '? ANSI C preprocessors map comments to a single space. K&R preprocessors remove comments completely. Although gcc is an ANSI compiler, you can get the K&R behavior by specifying -traditional-cpp to gcc. There is also a -traditional flag, that turns the entire compiler into a K&R compiler. This is probably of little use on the Amiga, where the header files use ANSI prototypes. I hope this helps, -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Everybody keep calm. It's all under control, there's nothing to see. It is merely a major scientific breakthrough." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 14:49:37 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90182-2>; Tue, 24 Oct 1995 14:45:40 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Tue, 24 Oct 95 13:43:36 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <2180ae7f.u8t20e.7912-robert@plukwa.lodz.pdi.net> Subject: Re: Number of processes limit?? In-Reply-To: (from fnf@amigalib.com (Fred Fish)) (at Fri, 20 Oct 1995 09:46:13 -0700 (MST)) Reply-To: robert@lodz.pdi.net Content-Length: 588 To: amiga-gcc-port@nic.funet.fi Date: Tue, 24 Oct 95 13:43:36 Organization: PDi Thanks to all that responded to my question. Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 14:50:13 1995 Received: from LEON.CTI.GR ([150.140.2.3]) by nic.funet.fi with ESMTP id <90657-2>; Tue, 24 Oct 1995 14:49:23 +0200 Received: from hpcl.hpcl (hpcl.cti.gr) by LEON.CTI.GR (PMDF V4.2-14 #4336) id <01HWTLYTHW5C90YIHZ@LEON.CTI.GR>; Tue, 24 Oct 1995 14:46:34 EET Received: from hpcl3.hpcl by hpcl.hpcl (4.1/SMI-4.1) id AA14960; Tue, 24 Oct 95 14:52:10 +0200 Date: Tue, 24 Oct 1995 14:52:09 +0200 (EET) From: kyrimis@hpcl (Kriton Kyrimis) Subject: Re: Help with MIT syntax, please In-reply-to: from "joop van de wege" at Oct 24, 95 01:19:05 pm To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Cc: amiga-gcc-port@lists.funet.fi (gcc) Reply-to: kyrimis@theseas.softlab.ece.ntua.gr Message-id: <9510241252.AA14960@hpcl.hpcl> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL21] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 679 Is there a reason why you can't use the version of libamiga.a that comes with gcc? I gather that you use Motorolla format in your assembly files, in which case you can convert the object files in the library from sun format to amiga format using sobja (it's on aminet). As a side note, are you involved in porting lcc to the amiga, or is there a port already available somewhere? Last time I checked, lcc's 68000 back-end was only partially complete. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Everybody keep calm. It's all under control, there's nothing to see. It is merely a major scientific breakthrough." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 14:52:04 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90695-2>; Tue, 24 Oct 1995 14:51:55 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HWTK5XY6PS00IRB3@NET2.WAU.NL>; Tue, 24 Oct 1995 13:54:17 +0000 (GMT) Received: by vines2.wau.nl; Tue, 24 Oct 95 13:51:29 +0100 Date: Tue, 24 Oct 1995 13:40:30 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: cpp MACRO expansion bug ? To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >ANSI C preprocessors map comments to a single space. >K&R preprocessors remove comments completely. >Although gcc is an ANSI compiler, you can get the K&R behavior by specifying >-traditional-cpp to gcc. There is also a -traditional flag, that turns the >entire compiler into a K&R compiler. This is probably of little use on the >Amiga, where the header files use ANSI prototypes. >I hope this helps, Thanks alot, looks like this is case of RTFM, although I would never thought of the fact that ANSI handles this different from K&R. Joop From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 15:10:17 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90324-2>; Tue, 24 Oct 1995 15:09:48 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HWTKSBK7FK00J34V@NET2.WAU.NL>; Tue, 24 Oct 1995 14:12:17 +0000 (GMT) Received: by vines2.wau.nl; Tue, 24 Oct 95 14:09:28 +0100 Date: Tue, 24 Oct 1995 13:59:39 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: Help with MIT syntax, please To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >Is there a reason why you can't use the version of libamiga.a that comes with >gcc? Yes, LCC outputs motorola syntax assembly which in turn is transformed into an object file by PhxAss. > I gather that you use Motorolla format in your assembly files, in which >case you can convert the object files in the library from sun format to amiga >format using sobja (it's on aminet). I tried Sobja but on some object modules it just doesn't work. First thing I did was to 'unar' libamiga.a into seperate modules, then batch run Sobja on it, but as I said not all modules converted without errors. Besides that, we want this compiler to be independant from ixemul.library. >As a side note, are you involved in porting lcc to the amiga, or is there a >port already available somewhere? Last time I checked, lcc's 68000 back-end >was only partially complete. Yes, I'm involved in the port together with Dave. Dave has done a good job of extending the 68K back-end. Currently it generates only 68020 or higher instructions due to 32bit displacement. I have a working version of 3.4b which doesn't require ixemul.library and should be able to compile itself. Last time I checked that there was one error and I'm not sure if we fixed that. This error might have been PhxAss having problems with the generated code. If you guys are interested I'll look it up and report. Next thing todo after the amiga.lib is ofcourse a c.lib which will be a bit more difficult. Just wait for my questions to appear on this list :) Joop From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 15:13:35 1995 Received: by nic.funet.fi id <90582-4>; Tue, 24 Oct 1995 15:13:19 +0200 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90142-4>; Tue, 24 Oct 1995 14:59:46 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id NAA02812; Tue, 24 Oct 1995 13:57:55 +0100 From: Lars Hecking Message-Id: <199510241158.MAA25060@mostar.nmrc.ucc.ie> Subject: Re: cpp MACRO expansion bug ? To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Tue, 24 Oct 1995 12:58:25 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "joop van de wege" at Oct 24, 95 01:40:30 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 452 Sender: mea@nic.funet.fi > Thanks alot, looks like this is case of RTFM, although I would never thought > of the fact that ANSI handles this different from K&R. A proper solution would include the use of ANSI's ## feature to concatenate strings. However, as this would break non-conforming, ie. K&R compilers, one would probably have to do something like #ifdef __STDC__ #define ANSI version of macro #else #define K&R version #endif See comp.lang.c FAQ Q6.2 and Q5.4 From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 15:13:37 1995 Received: by nic.funet.fi id <90700-4>; Tue, 24 Oct 1995 15:13:09 +0200 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90375-4>; Tue, 24 Oct 1995 14:35:27 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HWTJKLCDJ400J4X7@NET2.WAU.NL>; Tue, 24 Oct 1995 13:37:53 +0000 (GMT) Received: by vines2.wau.nl; Tue, 24 Oct 95 13:35:06 +0100 Date: Tue, 24 Oct 1995 13:19:05 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Help with MIT syntax, please To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: mea@nic.funet.fi Hi All, I'm currently working on an amiga.lib for use with LCC, an ANSI-C compiler. At the moment I have all normal stub functions but I have problems with the rest, Taglist family and things like CreateIO.c etc. I have been using the 'geninline' directory of gcc sofar. The problems I have right now is that the program 'mit2mot' is not recognising all addressing modes and in general is horrible to work with. Below you'll see one example. Mit2mot complains that it doesn't understand the line: 'lea sp@(8:W),a1' That is after I have run it through the preprocessor, because 'include<>' and GETINTBASE need to be parsed first. #include .text .globl _SetWindowPointer _SetWindowPointer: movel a6,sp@- GETINTBASE lea sp@(8:W),a1 movel a1@+,a0 jsr a6@(-816:W) movel sp@+,a6 rts Question: How do I solve the 'lea' problem without hand-editing all sourcefiles.? Is there an updated mit2mot which is better than the current one.? (my buddy in this project will make one if time permits) Are there alternatives to the 'geninline' stuff? Any comments about things I might have forgotten ? As always, please mail me a CC :) Thanks, Joop From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 15:43:22 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90046-2>; Tue, 24 Oct 1995 15:41:36 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 24 Oct 95 13:13 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 24 Oct 95 13:06 MET Message-Id: Subject: Amiga GNU Tools Project List To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 24 Oct 1995 13:06:23 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 352 I have just translated the Amiga GNU Tools Project List to html not quit pretty but usefull (i hope). you can see the list via http://www.uni-oldenburg.de/~u173034 you can get a copy of it if you send me a short email. walter -- ----- "I will venture just one question, Doctor. What precisely do you *do* in there?" "Argue, mainly!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 15:55:21 1995 Received: from srv3.gbar.dtu.dk ([130.225.87.163]) by nic.funet.fi with ESMTP id <90460-1> convert rfc822-to-8bit; Tue, 24 Oct 1995 15:48:39 +0200 Received: by srv3.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 24 Oct 1995 14:47:58 +0100 (MET) From: Rask Lambertsen To: Walter Harms Cc: amiga gcc-list Subject: Re: Amiga GNU Tools Project List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 24 Oct 1995, Walter Harms wrote: > I have just translated the Amiga GNU Tools Project List > to html not quit pretty but usefull (i hope). you can > see the list via > http://www.uni-oldenburg.de/~u173034 > you can get a copy of it if you send me a short email. Great, where is the link to the list? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 16:04:33 1995 Received: from wckn.dorm.clarkson.edu ([128.153.48.2]) by nic.funet.fi with SMTP id <90938-3>; Tue, 24 Oct 1995 16:03:45 +0200 Received: by wckn.dorm.clarkson.edu (4.1/SMI-4.1) id AA21299; Tue, 24 Oct 95 10:03:20 EDT Date: Tue, 24 Oct 95 10:03:20 EDT From: Rob Message-Id: <9510241403.AA21299@wckn.dorm.clarkson.edu> To: amiga-gcc-port@nic.funet.fi Subject: Amiga flex I hope this is the right place to ask about this... here goes. I'm using Amiga flex 2.4.7 last compiled on Dec 8 1994 10:51:53. Although I give it the -s flag to turn off it's default matching behavior (for debugging) it always gives me the following message when run. > flex -t -I -i -s analyze.flex > analyze.c > "analyze.flex", line 51: warning, -s option given but default rule can be matched Does anyone know what the deal is here? It's matching behavior is changed by the flag as I have managed to jam lexers built with the -s option. Why is it giving this warning? Thanks to anyone who can help (this list has been such a help to me getting gcc working these last few days). -Robert Dick (dickrp@wckn.dorm.clarkson.edu)- Here's the file I'm feeding flex: %{ #include #include #include "parse_export.h" #include "common.h" message flexMsg = NONE; %} WS [ \t]+ DIGIT [0-9] NUMBER {DIGIT}*"."?{DIGIT}+ %x GOBBLE %% %{ switch (flexMsg) { case FLUSH: BEGIN GOBBLE; break; } flexMsg = NONE; %} {WS} ; (exit|end|quit){WS}* return EXIT; (help|"?"){WS}* return HELP; {NUMBER} sscanf(yytext, "%lf", &yylval); return NUMBER; \n return EOL; "+" return '+'; "-" return '-'; "*" return '*'; "/" return '/'; "^" return '^'; "%" return '%'; sqrt return SQRT; ")" return ')'; "(" return '('; . BEGIN GOBBLE; return GARBAGE; .*$ BEGIN INITIAL; %% From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 16:07:25 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90302-1>; Tue, 24 Oct 1995 16:06:24 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HWTMRIUHQO00J7EJ@NET2.WAU.NL>; Tue, 24 Oct 1995 15:08:55 +0000 (GMT) Received: by vines2.wau.nl; Tue, 24 Oct 95 15:06:03 +0100 Date: Tue, 24 Oct 1995 14:58:45 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: Help with MIT syntax, please To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >> Besides that, we want this compiler to be independant from ixemul.library. >The libamiga.a that comes with gcc is part of libnix (PD), not ixemul. Correct, what I meant was that it is not part of the GNU project and when properly compiled it doesn't need ixemul.library. >> it up and report. Next thing todo after the amiga.lib is ofcourse a c.lib >> which will be a bit more difficult. >You can probably use large parts of libnix for this. (Though not all, as it >relies on gnu ld to do some magic stuff). Using the libnix source still is going to be a major work since it relies in quite some places on ld magic. One thing is the auto opening of libraries. >> Just wait for my questions to appear on this list :) >I'm looking forward to them, not to mention getting my grubby little >protruberances on a copy of lcc--do you need any beta testers? We might need something different: people who are prepared to work on parts of the project. Dave is busy, I'm busy, who isn't these days :) No seriously, Dave is real good with the lex/bison stuff, I'm better at solving puzzles and some people might be good at porting a c.lib to LCC. A mailing list for this port might be a good thing too ;-) (amiga-lcc-port@..) Joop From amiga-gcc-port-owner@nic.funet.fi Tue Oct 24 17:07:47 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90599-4>; Tue, 24 Oct 1995 17:05:50 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 24 Oct 95 16:05 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 24 Oct 95 15:45 MET Message-Id: Subject: Re: Amiga GNU Tools Project List To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 24 Oct 1995 15:45:49 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 463 > > =09I have just translated the Amiga GNU Tools Project List > > =09to html not quit pretty but usefull (i hope). you can > > =09see the list via > > =09http://www.uni-oldenburg.de/~u173034 > > =09you can get a copy of it if you send me a short email. > > Great, where is the link to the list? > one click from my homepage :) secon item or so you should be able to find it. walter -- ----- "There is nothing wrong with my voice!" --Melanie. ----- From amiga-gcc-port-owner@nic.funet.fi Wed Oct 25 03:32:55 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90916-3>; Wed, 25 Oct 1995 03:31:03 +0200 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0t7ukN-000R36C; Wed, 25 Oct 95 02:35 MET Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0t7rXe-000G8zC; Tue, 24 Oct 95 23:09 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0a5s@wyst.hobby.nl>; Tue, 24 Oct 95 22:27:39 CET Message-Id: <9510242127.0a5s@wyst.hobby.nl> Date: Tue, 24 Oct 1995 21:27:37 +0000 (CET) In-Reply-To: <9510231949.08oo@kriton.UUCP> from "Kriton Kyrimis" at Oct 23, 95 09:49:11 pm Content-Type: text Content-Length: 1392 From: hans@wyst.hobby.nl (Hans Verkuil) To: kyrimis@softlab.ece.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Ixemul Hi Kriton, > Just in case I have misunderstood what you told me about the flags that are > going to become obsolete in the near future (or have already become so), here > is what I think is the current list: > ix_unix_pattern_matching > ix_no_ces_then_open_console > ix_ignore_global_env > ix_translate_dots > ix_force_translation > ix_translate_symlinks > These are also the flags for which support has been dropped from ixprefs 2.0. > Please have a look, and let me know if I have mistakenly removed support for > any flag, or if I need to remove support for any others, in addition to those > listed above. The first two are already obsolete, the third is still and will stay supported. The last three will become obsolete after the cleanup. I hope to finish the merge from Leonard's version very soon. Actually, it's already finished, except for a bug concerning the exit status which was introduced somewhere. I've also rearranged the directory structure and improved a few things. Once this is done, and everything seems to work OK, I'll start working on the cleanup. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 01:52:57 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <88586-2>; Thu, 26 Oct 1995 00:49:37 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id SAA08750; Wed, 25 Oct 1995 18:49:19 -0400 (from cz253) Message-Id: <199510252249.SAA08750@kanga.INS.CWRU.Edu> Date: Wed, 25 Oct 1995 18:49:19 -0400 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: ncftp 2.2.1 Cc: cz253@cleveland.freenet.edu Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Hi All, Just tried to compile ncftp 2.2.1 and got the following errors: FTP.o: Undefined symbol _getservbyname referenced from text segment FTP.o: Undefined symbol _ntohs referenced from text segment FTP.o: Undefined symbol _inet_ntoa referenced from text segment FTP.o: Undefined symbol _inet_addr referenced from text segment FTP.o: Undefined symbol _gethostbyaddr referenced from text segment FTP.o: Undefined symbol _gethostbyname referenced from text segment FTP.o: Undefined symbol _htons referenced from text segment FTP.o: Undefined symbol _inet_ntoa referenced from text segment Where are these functions? I thought I remembered seeing a libnet.a library but can't seem to find it now. Is that what I am missing, or something else? Any pointers, hints, locations of libs, etc. would be most appreciated. Thanks in advance. .....Dave From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 01:53:57 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <88380-3>; Thu, 26 Oct 1995 00:16:47 +0200 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt; (5.65v3.0/1.1.8.2/24Jul95-0207PM) id AA11445; Wed, 25 Oct 1995 23:16:00 GMT Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/08Aug95-1153AM) id AA07150; Wed, 25 Oct 1995 23:16:37 GMT Date: Wed, 25 Oct 1995 23:16:37 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Amiga X11 mailling list Cc: Amiga GCC Mailling list Subject: X11R6 libraries available! Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Like I promissed a long time ago ... sorry about that, life is hell ... i've finaly compiled X11R6 libraries for GCC-Amiga-ixemul. They are fully compatible with AmiWin, Ether-Boards, ppp, you name it.... They use the TCP/IP inside ixemul which, unlike some rumors, work perfectly! The way to get them is through: http://hidro1.ist.utl.pt/amiga/amiga.html The old X11R5 pack, network-hacked is also available there, so if you are still trying to put together the latest version of those, there they are. There will be also precompiled Xclients to down-load but, maybe only next week. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 01:55:54 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <88555-2>; Wed, 25 Oct 1995 23:54:11 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HWVHDVKL9S00JZUG@NET2.WAU.NL>; Wed, 25 Oct 1995 22:56:43 +0000 (GMT) Received: by vines2.wau.nl; Wed, 25 Oct 95 22:53:54 +0100 Date: Wed, 25 Oct 1995 22:42:20 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Spilled register & MACRO expansion To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Thanks every one for the help on the MACRO expansion problem. It was done in the K&R way. Thanks Rask for the C-faq references, please update yours (must be *old*) since the questions have moved to sections 10.20 and 11.17 :) (c-faq oct95) Now for the guy who had problems with spilling forbidden registers. The error includes a line number where the error is supposed to be but it isn't. It is the end of function which contains an Amiga function call which uses too much registers. Yes this sounds like something is broken and I think it is. The functions causing these errors are all using *all* data registers including a few address register, for example, BltBitMap, DoPkt and a few others. Try to find the offending one and do the following if you want to use -O2: #define BltBitMap BlitBitMap #include #undef BlitBitMap This should be put in the FAQ if it is not solved when 2.7.1 is released.!! From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 02:05:57 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <89300-4>; Wed, 25 Oct 1995 11:01:53 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id JAA12296 for ; Wed, 25 Oct 1995 09:54:22 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA13776; Wed, 25 Oct 95 09:59:52 GMT Date: Wed, 25 Oct 95 09:59:52 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9510250959.AA13776@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: setlocale ??? Hi, I try to compile GNU ed, but I get some trouble with setlocale function. When linking, gcc could not find _setlocale. So, where is setlocale ?? Laurent \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 02:08:00 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90652-4>; Wed, 25 Oct 1995 05:04:09 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t7wBB-0004nZC; Tue, 24 Oct 95 20:07 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: amiga "proc:" (/proc equiv) To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Tue, 24 Oct 1995 20:07:01 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 501 In the past I've suggested that rather than mess with implementing ptrace(), that someone write a proc: handler, equivalent to /proc in modern UNIX versions. That would also allow us to finish the gdb port, and would be much more useful than just a ptrace() implementation in ixemul.library. I just noticed that there is a proc.lha on aminet that might be useful as a starting point for a proc: handler that the debugger can use. Perhaps some interested party could check it out further... -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 05:53:16 1995 Received: from io.org ([142.77.70.2]) by nic.funet.fi with SMTP id <90054-1>; Thu, 26 Oct 1995 05:51:32 +0200 Received: from "io.org" (timper.net5b.io.org [199.166.191.38]) by io.org (8.6.12/8.6.12) with SMTP id XAA27254 for ; Wed, 25 Oct 1995 23:50:50 -0400 Received: by "io.org" (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 25 Oct 95 23:49:28 From: tjhayko@timper (Tom Hayko) Message-Id: <21828e07.u8t20e.d8faf-tjhayko@timper> Subject: Re: amiga "proc:" (/proc equiv) In-Reply-To: (from fnf@amigalib.com (Fred Fish)) (at Tue, 24 Oct 1995 20:07:01 -0700 (MST)) Reply-To: tjhayko@io.org To: fnf@amigalib.com Cc: amiga-gcc-port@nic.funet.fi Date: Wed, 25 Oct 95 23:49:28 Hi Fred (Fred Fish), in on Oct 24 you wrote: > In the past I've suggested that rather than mess with implementing > ptrace(), that someone write a proc: handler, equivalent to /proc in > modern UNIX versions. That would also allow us to finish the gdb > port, and would be much more useful than just a ptrace() > implementation in ixemul.library. I just noticed that there is a > proc.lha on aminet that might be useful as a starting point for a > proc: handler that the debugger can use. Perhaps some interested > party could check it out further... > > -Fred > I think I'll be showing my ignorance here, but after looking at the NetBSD manual pages for ptrace(), I can't really figure out what it provides that gdb needs to work. What does ptrace() (or a proc: handler) need to provide to let us finish off gdb? -- Tom Hayko tjhayko@io.org http://www.io.org/~tjhayko From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 05:55:50 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90182-1>; Thu, 26 Oct 1995 05:55:41 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t8JTb-0004nYC; Wed, 25 Oct 95 20:59 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: amiga "proc:" (/proc equiv) To: tjhayko@io.org Date: Wed, 25 Oct 1995 20:59:34 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <21828e07.u8t20e.d8faf-tjhayko@timper> from "Tom Hayko" at Oct 25, 95 11:49:28 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 447 > I think I'll be showing my ignorance here, but after looking at the NetBSD > manual pages for ptrace(), I can't really figure out what it provides that > gdb needs to work. What does ptrace() (or a proc: handler) need to > provide to let us finish off gdb? It provides the ability to start/stop a process, access that processes memory in a controlled manner, trace system calls made by the process (in the case of /proc) and much more. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 09:34:41 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <90152-2> convert rfc822-to-8bit; Thu, 26 Oct 1995 09:34:09 +0200 Received: by tycho.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 26 Oct 1995 08:33:47 +0100 (MET) From: Rask Lambertsen To: Fred Fish Cc: Amiga GCC mailing list , Fred Fish Subject: Re: Amiga GNU Tools Project List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Fri, 6 Oct 1995, Fred Fish wrote: [snip] > ============================================================================ > > PROJECT: Fix latest version of GNU tar. > > DESCRIPTION > > Find out why 'cat t.tar.gz | tar xzvf -' fails to work for large archives. > > VOLUNTEERS: > > REWARD: 2 free Aminet or FreshFish CDs - value $40 - furnished > by Amiga Library Services > > ============================================================================ Maybe someone should also figure out why tar is unable to do something like tar -Mxvf DEV:PC0 with any of the DEV-handlers on Aminet. Similar problems if you use the PIPE: device instead. All is does is to print Operation not supported by device I've seen two ports of GNUtar which worked and didn't use ixemul.library, so maybe the problem is in ixemul/open()? I've looked at the source of ixemul.library, and it appears to me that ixemul/open() does lots of other things than call dos.library/Open(). What is the problem? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 11:22:33 1995 Received: from PhoneLink.COM ([193.195.138.3]) by nic.funet.fi with SMTP id <89234-2> convert rfc822-to-8bit; Thu, 26 Oct 1995 11:21:01 +0200 Received: from m500324.dev.phonelink.com by mailgate.PhoneLink.COM id aa20456; 26 Oct 95 9:16 GMT Received: by m500324.dev.phonelink.com with Microsoft Mail id <01BAA383.E75A2D80@m500324.dev.phonelink.com>; Thu, 26 Oct 1995 09:17:42 +-100 Message-ID: <01BAA383.E75A2D80@m500324.dev.phonelink.com> From: Steve Kaye To: 'Amiga GCC List' Subject: GUI for GDB Date: Thu, 26 Oct 1995 09:17:40 +-100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Hello, I have just downloaded the gdbtk archive from cygnus to have a look into doing a new GUI for GDB and I have a few questions. 1) This is a fairly large archive....does it contain the source for GDB too? If not....will I need the source or just the binary? 2) Does GDB work enough to test a GUI? If not, how should I test it? If I do decide to go ahead with this, I will post here to tell you and ask for feature requests, suggestions etc. (etc will probably include a few help requests 8^) See ya Steve From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 12:22:51 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89093-2>; Thu, 26 Oct 1995 12:21:51 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t8PVJ-0004nYC; Thu, 26 Oct 95 03:25 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: GUI for GDB To: SteveK@PhoneLink.COM (Steve Kaye) Date: Thu, 26 Oct 1995 03:25:45 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <01BAA383.E75A2D80@m500324.dev.phonelink.com> from "Steve Kaye" at Oct 26, 95 09:17:40 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 920 > I have just downloaded the gdbtk archive from cygnus to have a look into = > doing a new GUI for GDB and I have a few questions. OK. > 1) This is a fairly large archive....does it contain the source for GDB = > too? If not....will I need the source or just the binary? Yes, it contains all the source for GDB as well as TCL and TK. > 2) Does GDB work enough to test a GUI? If not, how should I test it? It should. Basically you should be able to do anything that doesn't require a running process. Actually, gdb also includes simulators for various chips, so you could pick a convenient one, build a gdb that incorporates that simulator, build a toolset that generates executables for that chip, and in theory run simulated executables to test the GUI features that require a running target process. This is probably overkill though, and possibly a significant amount of work to set up and get running. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 13:01:48 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <88946-2>; Thu, 26 Oct 1995 13:00:54 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Thu, 26 Oct 95 11:59:04 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <21833904.u8t20e.2ee89-robert@plukwa.lodz.pdi.net> Subject: Re: ncftp 2.2.1 In-Reply-To: <199510252249.SAA08750@kanga.INS.CWRU.Edu> (from cz253@cleveland.Freenet.Edu (David Zaroski)) (at Wed, 25 Oct 1995 18:49:19 -0400) Reply-To: robert@lodz.pdi.net Content-Length: 1970 To: cz253@cleveland.Freenet.Edu Cc: amiga-gcc-port@nic.funet.fi Date: Thu, 26 Oct 95 11:59:04 Organization: PDi On Oct 25 David Zaroski wrote: > Hi All, > Just tried to compile ncftp 2.2.1 and got the following errors: > > FTP.o: Undefined symbol _getservbyname referenced from text segment > FTP.o: Undefined symbol _ntohs referenced from text segment > FTP.o: Undefined symbol _inet_ntoa referenced from text segment > FTP.o: Undefined symbol _inet_addr referenced from text segment > FTP.o: Undefined symbol _gethostbyaddr referenced from text segment > FTP.o: Undefined symbol _gethostbyname referenced from text segment > FTP.o: Undefined symbol _htons referenced from text segment > FTP.o: Undefined symbol _inet_ntoa referenced from text segment > > Where are these functions? I thought I remembered seeing a libnet.a library > but can't seem to find it now. Is that what I am missing, or something else? > Any pointers, hints, locations of libs, etc. would be most appreciated. To compile it cleanly You need AmiTCP-sdk-gcc.lha from Aminet. I've already done that a couple of times. The only real problem with NcFTP is that it has problmes with opening ftp connection in user mode (when using -u option). It just doesn't accept passwords. When I bypass this shortcomings I'll upload it to Aminet. I also want to add this port to Amiga GNU Tools Project. After adding AmiTCP support to ixemul.library i'll try to force merging of any changes in to main NcFTP tree on Mike Gleason =o)) Robert > Thanks in advance. > > .....Dave > +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 15:24:38 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89029-2>; Thu, 26 Oct 1995 15:20:16 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA08905 (5.65c8/IDA-1.4.4 for ); Thu, 26 Oct 1995 14:19:13 +0100 Received: by diva.gmd.de with UUCP id AA00648 (5.67b8/IDA-1.5); Thu, 26 Oct 1995 14:16:24 +0100 Date: Thu, 26 Oct 1995 14:16:24 +0100 Message-Id: <199510261316.AA00648@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: robert@lodz.pdi.net Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ncftp 2.2.1 In-Reply-To: <21833904.u8t20e.2ee89-robert@plukwa.lodz.pdi.net> References: <199510252249.SAA08750@kanga.INS.CWRU.Edu> <21833904.u8t20e.2ee89-robert@plukwa.lodz.pdi.net> Robert Ramiega writes: > On Oct 25 David Zaroski wrote: > > Just tried to compile ncftp 2.2.1 and got the following errors: > > FTP.o: Undefined symbol _getservbyname referenced from text segment [...] > > Where are these functions? I thought I remembered seeing a libnet.a library Correct, these are the standard network functions. They used to be in libnet.a in GCC256/7-times. > To compile it cleanly You need AmiTCP-sdk-gcc.lha from Aminet. That I don't understand. Why does one need a developer kit for a specific TCP/IP implementation? I thought that ixemul would come with it's own includes (tons of them) and library vectors offsets that implement all of these functions (at least it did in 39.47/DaggeX times). I expect to be able to compile UNIX socket stuff out of the ixemul box and have ixemul.library discover that I'm using AmiTCP, AS225, Envoy, DNet or whatever. I don't want these calls to be routed to a specific libamitcp.a or whatever: what are all these network LVOs of ixemul.library used for otherwise? Did I miss something? Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 15:38:03 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90149-3>; Thu, 26 Oct 1995 15:33:53 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA10123 (5.65c8/IDA-1.4.4 for ); Thu, 26 Oct 1995 14:33:30 +0100 Received: by diva.gmd.de with UUCP id AA00656 (5.67b8/IDA-1.5); Thu, 26 Oct 1995 14:30:45 +0100 Date: Thu, 26 Oct 1995 14:30:45 +0100 Message-Id: <199510261330.AA00656@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: Joop.vandeWege@medew.ento.wau.nl (joop van de wege) Cc: amiga-gcc-port@nic.funet.fi Subject: Spilled register & MACRO expansion In-Reply-To: References: joop van de wege writes: > uses too much registers. Yes this sounds like something is broken and I think > it is. The functions causing these errors are all using *all* data registers > including a few address register, for example, BltBitMap, DoPkt and a few > others. I think we should remove BltBitMap, DoPkt and these others from the inlines and use stubs for them instead. It won't cause much harm or speed/space loss and we'll avoid these problems. Because those functions use so many registers, all other register variables must be saved in memory anyway so it's not much different from having it done in the stub in a movem pair and it's certainly easier and faster to compile. According to the GCC maintainers (forgot whom I talked to), GCC doesn't like to find too many of its registers used up. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 15:48:52 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <89797-1>; Thu, 26 Oct 1995 15:47:49 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Thu, 26 Oct 95 14:29:37 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <21835c4e.u8t20e.96e54-robert@plukwa.lodz.pdi.net> Subject: Re: ncftp 2.2.1 In-Reply-To: <199510261316.AA00648@diva.gmd.de> (from hoehle@zeus.gmd.de (Joerg Hoehle)) (at Thu, 26 Oct 1995 14:16:24 +0100) Reply-To: robert@lodz.pdi.net Content-Length: 1571 To: hoehle@zeus.gmd.de Cc: amiga-gcc-port@nic.funet.fi Date: Thu, 26 Oct 95 14:29:37 Organization: PDi On Oct 26 Joerg Hoehle wrote: > That I don't understand. Why does one need a developer kit for a > specific TCP/IP implementation? I thought that ixemul would come with > it's own includes (tons of them) and library vectors offsets that > implement all of these functions (at least it did in 39.47/DaggeX > times). I expect to be able to compile UNIX socket stuff out of the > ixemul box and have ixemul.library discover that I'm using AmiTCP, > AS225, Envoy, DNet or whatever. I don't want these calls to be routed > to a specific libamitcp.a or whatever: what are all these network LVOs > of ixemul.library used for otherwise? > > Did I miss something? Yes You did miss something. AFAIK Ixemul right now has onlysuport for AS255 networking package. After cleanup of ixemul sources Jeff Sheppard (sorry if i mistyped the name) promised to add things that will make ixemul useful to people using AmiTCP. Right now You must use that dev kit i mentioned earlier > Joerg Hoehle. > Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 15:59:48 1995 Received: from undergrad.math.uwaterloo.ca ([129.97.204.13]) by nic.funet.fi with SMTP id <90444-4>; Thu, 26 Oct 1995 15:59:05 +0200 Received: from cayley.uwaterloo.ca (jsshephe@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id JAA22411; Thu, 26 Oct 1995 09:54:54 -0400 Received: (jsshephe@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id JAA08918; Thu, 26 Oct 1995 09:54:48 -0400 Date: Thu, 26 Oct 1995 09:54:47 -0400 (EDT) From: Jeff Shepherd To: Joerg Hoehle cc: robert@lodz.pdi.net, amiga-gcc-port@nic.funet.fi Subject: Re: ncftp 2.2.1 In-Reply-To: <199510261316.AA00648@diva.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 26 Oct 1995, Joerg Hoehle wrote: > That I don't understand. Why does one need a developer kit for a > specific TCP/IP implementation? I thought that ixemul would come with > it's own includes (tons of them) and library vectors offsets that > implement all of these functions (at least it did in 39.47/DaggeX > times). I expect to be able to compile UNIX socket stuff out of the > ixemul box and have ixemul.library discover that I'm using AmiTCP, > AS225, Envoy, DNet or whatever. I don't want these calls to be routed > to a specific libamitcp.a or whatever: what are all these network LVOs > of ixemul.library used for otherwise? > Right now ixemul only incorporates AS225 TCP/IP functions. That is what all the LVO's are for. What I am going to do when AmiTCP is merged into ixemul is to automatically sense which TCP/IP protocol is in use (either AmiTCP or AS225) and act appropriately. libamitcp.a is mostly a hack that uses nonLVO ixemul calls and will be obsolete once AmiTCP is incorporated into ixemul.library > Did I miss something? Yes. See above. PS: If anyone has code dealing with AF_UNIX sockets (ie socket(AF_UNIX,SOCK_STREAM,0) ) could you please send it to me. I have wrote some code which implements these kinds of sockets and I need some example code to do some testing. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe/index.html If you think the problem is bad now, just wait until we've solved it. finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 17:19:53 1995 Received: from nextsun.INS.CWRU.Edu ([129.22.8.51]) by nic.funet.fi with ESMTP id <90486-2>; Thu, 26 Oct 1995 17:14:21 +0200 Received: (cz253@localhost) by nextsun.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-freenet) id LAA02934; Thu, 26 Oct 1995 11:12:36 -0400 (from cz253) Message-Id: <199510261512.LAA02934@nextsun.INS.CWRU.Edu> Date: Thu, 26 Oct 1995 11:12:36 -0400 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: robert@lodz.pdi.net Subject: Re: ncftp 2.2.1 Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from robert@plukwa.lodz.pdi.net of Thu, 26 Oct > To compile it cleanly You need AmiTCP-sdk-gcc.lha from Aminet. > I've already done that a couple of times. The only real problem with NcFTP is >that it has problmes with opening ftp connection in user mode (when using -u >option). It just doesn't accept passwords. When I bypass this shortcomings I'll >upload it to Aminet. I also want to add this port to Amiga GNU Tools Project. >After adding AmiTCP support to ixemul.library i'll try to force merging of any >changes in to main NcFTP tree on Mike Gleason =o)) > > Robert Thanks, just grabbed it. :-) .....Dave From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 17:24:24 1995 Received: from relay1.fnet.fr ([192.134.192.129]) by nic.funet.fi with SMTP id <90862-2>; Thu, 26 Oct 1995 17:21:38 +0200 Received: from jupiter.UUCP by relay1.fnet.fr (5.65c8d/92.02.29) via Fnet/EUnet-France id AA09541; Thu, 26 Oct 1995 16:21:20 +0100 (MET) Received: from po1 by jupiter (4.1/SMI-4.1) id AA16494; Thu, 26 Oct 95 12:45:29 +0100 Message-Id: <9510261145.AA16494@jupiter> Received: by po1 (1.38.193.4/16.2) id AA26661; Thu, 26 Oct 1995 12:48:21 +0100 From: Pascal Lallemand Subject: subscribe To: amiga-gcc-port@nic.funet.fi Date: Thu, 26 Oct 95 12:48:20 MET Mailer: Elm [revision: 70.85] subscribe From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 19:33:00 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <85900-2>; Thu, 26 Oct 1995 19:30:41 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26579-3>; Thu, 26 Oct 1995 18:23:31 +0100 Received: from hphalle7j.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395722-1>; Thu, 26 Oct 1995 18:23:20 +0100 Subject: Re: Spilled register & MACRO expansion From: Christian Stieber To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Thu, 26 Oct 1995 18:23:16 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199510261330.AA00656@diva.gmd.de> from "Joerg Hoehle" at Oct 26, 95 02:30:45 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 561 Message-Id: <95Oct26.182320+0100mesz.395722-1+1879@hphalle0.informatik.tu-muenchen.de> > I think we should remove BltBitMap, DoPkt and these others from the > inlines and use stubs for them instead. Actually, wouldn't it be better to keep the inlines for these functions, but automatically save a couple of registers? Sort of a special-casing in the inline generator for these functions. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Thu Oct 26 19:37:24 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <85945-4>; Thu, 26 Oct 1995 19:36:28 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26506-3>; Thu, 26 Oct 1995 18:12:13 +0100 Received: from hphalle7j.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395723-1>; Thu, 26 Oct 1995 18:12:05 +0100 Subject: Re: amiga "proc:" (/proc equiv) From: Christian Stieber To: tjhayko@io.org Date: Thu, 26 Oct 1995 18:11:54 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <21828e07.u8t20e.d8faf-tjhayko@timper> from "Tom Hayko" at Oct 25, 95 11:49:28 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 2054 Message-Id: <95Oct26.181205+0100mesz.395723-1+1872@hphalle0.informatik.tu-muenchen.de> > I think I'll be showing my ignorance here, but after looking at the NetBSD > manual pages for ptrace(), I can't really figure out what it provides that > gdb needs to work. What does ptrace() (or a proc: handler) need to > provide to let us finish off gdb? Hm.. seems the HPUX manpages are more useful :) Below is an excerpt from the HPUX manpage of ptrace(2). Please keep in mind that Unix processes are separate entities; a process cannot just read/write something from/to another process' memory, which makes debugging sort of impossible (unless you want to emulate a process environment inside the debugger process). ptrace(2) provides a method to modify another process, it sort of breaks a hole into the walls that seperate all processes from each other. Of course, on the Amiga this isn't required since any process can trash other processes memory at any time, but we still need ptrace() to avoid having to rewrite gdb. ------------------------------ cut ------------------------------ DESCRIPTION ptrace() provides a means by which a process can control the execution of another process. Its primary use is for the implementation of breakpoint debugging; see adb(1). The traced process behaves normally until it encounters a signal (see signal(2) for the list), at which time it enters a stopped state and the tracing process is notified via wait() (see wait(2)). When the traced process is in the stopped state, the tracing process can examine and modify the "core image" using ptrace(). Also, the tracing process can cause the traced process either to terminate or continue, with the possibility of ignoring the signal that caused it to stop. ------------------------------ cut ------------------------------ Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 01:34:42 1995 Received: from wckn.dorm.clarkson.edu ([128.153.48.2]) by nic.funet.fi with SMTP id <85682-3>; Fri, 27 Oct 1995 01:33:23 +0200 Received: by wckn.dorm.clarkson.edu (4.1/SMI-4.1) id AA19005; Thu, 26 Oct 95 19:33:04 EDT Date: Thu, 26 Oct 95 19:33:04 EDT From: Rob Message-Id: <9510262333.AA19005@wckn.dorm.clarkson.edu> To: amiga-gcc-port@nic.funet.fi Subject: Exceptions, __unwind_function Is it true that __unwind_function has not been implemented for the Amiga and that exceptions will, therefore, not work? If they should work, please tell me where __unwind_function should come from. I can't find it in my distribution's libs (2.7.0). -Robert Dick (dickrp@wckn.dorm.clarkson.edu)- From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 13:03:31 1995 Received: from PhoneLink.COM ([193.195.138.3]) by nic.funet.fi with SMTP id <88859-3> convert rfc822-to-8bit; Fri, 27 Oct 1995 12:59:27 +0200 Received: from m500324.dev.phonelink.com by mailgate.PhoneLink.COM id aa00546; 27 Oct 95 11:47 GMT Received: by m500324.dev.phonelink.com with Microsoft Mail id <01BAA459.C5BF4080@m500324.dev.phonelink.com>; Fri, 27 Oct 1995 10:48:38 +-100 Message-ID: <01BAA459.C5BF4080@m500324.dev.phonelink.com> From: Steve Kaye To: 'Amiga GCC List' Subject: GDB/Configure problems Date: Fri, 27 Oct 1995 10:48:36 +-100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Hello, Well, I got far on that one didn't I? I got the source onto my machine and did a configure in the main directory and it GURU'd ( Not enough stack 8^) When I got the stack sorted out it still didn't work. After a number of error messages it told me that it couldn't configure for my machine. So I tried in the gdb directory. This configure gave me a number of Checking for... lines. One of the first was checking for GNU C and it said no. Can anyone point me in the right direction please? (I have never had any luck with configure scripts 8^( ) Thanks Steve P.S I DO have GCC 8^) P.P.S How long does it take to compile? Do I need to compile GDB? Can I get an executable from somewhere and use that? From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 13:47:36 1995 Received: from ns.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with SMTP id <88754-1>; Fri, 27 Oct 1995 13:43:49 +0200 Received: from wiedmann.neckar-alb.de (wiedmann@wiedmann.neckar-alb.de [194.77.119.253]) by ns.neckar-alb.de (8.6.9/8.6.9) with ESMTP id MAA16098 for ; Fri, 27 Oct 1995 12:42:24 +0100 Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id MAA00233 for amiga-gcc-port@lists.funet.fi; Fri, 27 Oct 1995 12:42:43 +0100 From: wiedmann Message-Id: <199510271142.MAA00233@wiedmann.neckar-alb.de> Subject: Good bye To: amiga-gcc-port@nic.funet.fi Date: Fri, 27 Oct 1995 12:42:42 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 960 Hello, whoever it may concern: Please remove me (Jochen Wiedmann) from this list. I cannot do it for myself, as I am registered under an account which doesn't live anymore, perhaps jochen.wiedmann@zdv.uni-tuebingen.de, zrawi01@decap2.zdv.uni-tuebingen.de or something similar. My thanks to the list for the last two years: There have been interesting discussions most of the time and reading was fun. However, I have bought a clone some months ago and am no longer working on the Amiga. Btw, is someone interested in developing the Installer script in the future? To my own surprise I've got no bug reports since months. So I assume, that it is in a state, where I can leave it to someone else without putting all the shame on him/her. :-) Philippe, one question: Can I get onto the gcc developer list somehow? I'm still interested in gcc, but, as you hopefully understand, not that much on the Amiga gcc. So long and thanks for all the fish, Jochen From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 13:51:38 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <88862-1>; Fri, 27 Oct 1995 13:48:45 +0200 Received: from ernie.icslab.agh.edu.pl by funet.fi with SMTP (PP); Fri, 27 Oct 1995 13:48:38 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA17688; Fri, 27 Oct 1995 12:49:00 +0100 Date: Fri, 27 Oct 1995 12:48:59 +0100 (MET) From: Kamil Iskra Subject: Re: Spilled register & MACRO expansion To: Christian Stieber cc: Joerg Hoehle , amiga-gcc-port@nic.funet.fi In-Reply-To: <95Oct26.182320+0100mesz.395722-1+1879@hphalle0.informatik.tu-muenchen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 26 Oct 1995, Christian Stieber wrote: > > I think we should remove BltBitMap, DoPkt and these others from the > > inlines and use stubs for them instead. > > Actually, wouldn't it be better to keep the inlines for these functions, > but automatically save a couple of registers? Sort of a special-casing > in the inline generator for these functions. I'll think about it. However, I'm not very good at "asm stuff" (to say the least :-), so any help will be grately appreciated. So my question is: how "inlines" for these functions should look like? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 19:03:09 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89797-2>; Fri, 27 Oct 1995 18:08:53 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26584-3>; Fri, 27 Oct 1995 17:08:24 +0100 Received: from hphalle6j.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395722-2>; Fri, 27 Oct 1995 17:08:19 +0100 Subject: Re: Spilled register & MACRO expansion From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 27 Oct 1995 17:08:11 +0100 (MEZ) In-Reply-To: <199510271233.AA01004@diva.gmd.de> from "Joerg Hoehle" at Oct 27, 95 01:33:23 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 673 Message-Id: <95Oct27.170819+0100mesz.395722-2+2604@hphalle0.informatik.tu-muenchen.de> > > Actually, wouldn't it be better to keep the inlines for these functions, > > but automatically save a couple of registers? Sort of a special-casing > > in the inline generator for these functions. > > How would you write an __asm() that gets the arguments for the > function all in some registers and save these registers before as > well? Hm.. don't know :( I guess I need to fix a bug in my brain OS :( Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 19:03:34 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <88699-4>; Fri, 27 Oct 1995 17:52:20 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HWXXBVVAGW0008XM@NET2.WAU.NL>; Fri, 27 Oct 1995 16:54:50 +0000 (GMT) Received: by vines2.wau.nl; Fri, 27 Oct 95 16:51:43 +0100 Date: Fri, 27 Oct 1995 16:48:33 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: Spilled register & MACRO expansion To: gc948374@gbar.dtu.dk, amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >> Thanks Rask for the C-faq references, please update yours (must be *old*)= >> since the questions have moved to sections 10.20 and 11.17 :) (c-faq oct9= >>5) >I'm clueless. Which C-faq references and where? I searched the README for= >'faq' and 'FAQ', but couldn't find it. Sorry Rask, Not was not you who mentioned the c-faq but Lars Hecking, apologies for the mistake. Joop From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 19:03:39 1995 Received: from srv4.gbar.dtu.dk ([130.225.87.164]) by nic.funet.fi with ESMTP id <88906-3> convert rfc822-to-8bit; Fri, 27 Oct 1995 17:39:47 +0200 Received: by srv4.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 27 Oct 1995 16:39:34 +0100 (MET) From: Rask Lambertsen To: joop van de wege Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Spilled register & MACRO expansion In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 25 Oct 1995, joop van de wege wrote: > Thanks Rask for the C-faq references, please update yours (must be *old*) > since the questions have moved to sections 10.20 and 11.17 :) (c-faq oct95) I'm clueless. Which C-faq references and where? I searched the README for 'faq' and 'FAQ', but couldn't find it. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 19:04:39 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <88841-2>; Fri, 27 Oct 1995 14:47:08 +0200 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt; (5.65v3.0/1.1.8.2/24Jul95-0207PM) id AA20610; Fri, 27 Oct 1995 13:46:14 GMT Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/08Aug95-1153AM) id AA26905; Fri, 27 Oct 1995 13:46:37 GMT Date: Fri, 27 Oct 1995 13:46:37 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Laurent Papier Cc: amiga-gcc-port@nic.funet.fi Subject: Re: setlocale ??? In-Reply-To: <9510250959.AA13776@indi1.u-strasbg.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 25 Oct 1995, Laurent Papier wrote: > Hi, > I try to compile GNU ed, but I get some trouble with setlocale function. > When linking, gcc could not find _setlocale. So, where is setlocale ?? > > Laurent Its true, setlocale is NOT present in libc.a because nobody ported it or bacause simply isnt in the original BSD4.5. Nevertheless, you can compile it! In the X11R6 MIT souce pack, one of the components is Xsetlocale.c . This module has a function that implements setlocale when the os doesnt supply one. - Pedro Teixeira - PS: If you dont want to bother extracting the whole pack just to get this single module, i can send you the '.o'. From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 19:05:04 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <88346-1>; Fri, 27 Oct 1995 14:36:36 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA25425 (5.65c8/IDA-1.4.4 for ); Fri, 27 Oct 1995 13:36:12 +0100 Received: by diva.gmd.de with UUCP id AA01004 (5.67b8/IDA-1.5); Fri, 27 Oct 1995 13:33:23 +0100 Date: Fri, 27 Oct 1995 13:33:23 +0100 Message-Id: <199510271233.AA01004@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: Christian Stieber Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Spilled register & MACRO expansion In-Reply-To: <95Oct26.182320+0100mesz.395722-1+1879@hphalle0.informatik.tu-muenchen.de> References: <199510261330.AA00656@diva.gmd.de> <95Oct26.182320+0100mesz.395722-1+1879@hphalle0.informatik.tu-muenchen.de> Christian Stieber writes: > Actually, wouldn't it be better to keep the inlines for these functions, > but automatically save a couple of registers? Sort of a special-casing > in the inline generator for these functions. How would you write an __asm() that gets the arguments for the function all in some registers and save these registers before as well? I claim that the compiler is much better at saving registers to memory than some constant __asm("movem;jsr;movem") thing. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 19:27:24 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <88184-1>; Fri, 27 Oct 1995 19:24:37 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 27 Oct 95 18:23:36 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <2184e4a5.u8t20e.20894-robert@plukwa.lodz.pdi.net> Subject: AGTPL Reply-To: robert@lodz.pdi.net Content-Length: 844 To: amiga-gcc-port@nic.funet.fi, fnf@amigalib.com Date: Fri, 27 Oct 95 18:23:36 Organization: PDi Hi all! I've taken html version of AGTPL from Walter Harms and rewrote it a bit, split it into pieces and put on my www server. Now You can also acces it throu URL http://plukwa.lodz.pdi.net/~AGTPL Robert Ps. Fred if You have something against it than let me know and I'll take it off www in a moment -- +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 20:54:16 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <88252-3>; Fri, 27 Oct 1995 20:52:58 +0200 Received: from bastion.nmrc.ucc.ie (nmrc.ucc.ie [143.239.64.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id SAA29986 for ; Fri, 27 Oct 1995 18:52:52 GMT Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id TAA11547; Fri, 27 Oct 1995 19:51:23 +0100 From: Lars Hecking Message-Id: <199510271751.SAA05121@mostar.nmrc.ucc.ie> Subject: Re: Spilled register & MACRO expansion To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Fri, 27 Oct 1995 18:51:55 +0100 (BST) Cc: gc948374@gbar.dtu.dk (Rask Lambertsen) In-Reply-To: from "Rask Lambertsen" at Oct 27, 95 04:39:34 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 682 > > Thanks Rask for the C-faq references, please update yours (must be *old*) > > since the questions have moved to sections 10.20 and 11.17 :) (c-faq oct95) I refered to the html version from Aug 95 and did not read the warning about imminent changes :( > I'm clueless. Which C-faq references and where? I searched the README for= > =20 > 'faq' and 'FAQ', but couldn't find it. Rask, this is the FAQ list for comp.lang.c. It is regularily posted to comp.lang.c, news.answers, and is generally available from . -- Lars Hecking in exile. Exile phone #: +353 21 90 4078 Bumper Sticker: Just say 'NO' to sex with pro-lifers. From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 22:43:00 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <88256-3>; Fri, 27 Oct 1995 22:41:47 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id VAA23411; Fri, 27 Oct 1995 21:38:45 +0100 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id VAA21764; Fri, 27 Oct 1995 21:41:04 +0100 Date: Fri, 27 Oct 1995 21:41:04 +0100 From: Niklas Hallqvist Message-Id: <199510272041.VAA21764@linda.appli.se> To: l36599@alfa.ist.utl.pt CC: papier@indi1.u-strasbg.fr, amiga-gcc-port@nic.funet.fi In-reply-to: (message from Pedro Miguel Sequeira Teixeira on Fri, 27 Oct 1995 13:46:37 +0000 (GMT)) Subject: Re: setlocale ??? >>>>> "Pedro" == Pedro Miguel Sequeira Teixeira writes: Pedro> On Wed, 25 Oct 1995, Laurent Papier wrote: >> Hi, I try to compile GNU ed, but I get some trouble with setlocale >> function. When linking, gcc could not find _setlocale. So, where >> is setlocale ?? >> >> Laurent Pedro> Its true, setlocale is NOT present in libc.a because nobody Pedro> ported it or bacause simply isnt in the original BSD4.5. Huh? BSD4.5 doesn't exist. I guess you refer to BSD4.4 (I don't think ixemul is based on lite, is it?) Niklas From amiga-gcc-port-owner@nic.funet.fi Fri Oct 27 23:04:57 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <87973-1>; Fri, 27 Oct 1995 23:03:10 +0200 Received: from bastion.nmrc.ucc.ie (nmrc.ucc.ie [143.239.64.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id VAA03854 for ; Fri, 27 Oct 1995 21:03:01 GMT Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id WAA13042; Fri, 27 Oct 1995 22:01:28 +0100 From: Lars Hecking Message-Id: <199510272002.VAA05304@mostar.nmrc.ucc.ie> Subject: Re: setlocale ??? To: niklas@appli.se (Niklas Hallqvist) Date: Fri, 27 Oct 1995 21:02:00 +0100 (BST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199510272041.VAA21764@linda.appli.se> from "Niklas Hallqvist" at Oct 27, 95 09:41:04 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 331 > > Pedro> Its true, setlocale is NOT present in libc.a because nobody > Pedro> ported it or bacause simply isnt in the original BSD4.5. > > Huh? BSD4.5 doesn't exist. I guess you refer to BSD4.4 (I don't think > ixemul is based on lite, is it?) From the comments, I'd gather that code from 4.3, 4.4 and Net-BSD was used. From amiga-gcc-port-owner@nic.funet.fi Sat Oct 28 06:27:54 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <87980-1>; Sat, 28 Oct 1995 06:25:05 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t92ts-0004nYC; Fri, 27 Oct 95 21:29 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: GDB/Configure problems To: SteveK@PhoneLink.COM (Steve Kaye) Date: Fri, 27 Oct 1995 21:29:44 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <01BAA459.C5BF4080@m500324.dev.phonelink.com> from "Steve Kaye" at Oct 27, 95 10:48:36 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1035 > When I got the stack sorted out it still didn't work. After a number of = > error messages it told me that it couldn't configure for my machine. So = > I tried in the gdb directory. Where did you get the source from? The version I have configures and compiles just fine. > This configure gave me a number of Checking for... lines. One of the = > first was checking for GNU C and it said no. Can anyone point me in the = > right direction please? (I have never had any luck with configure = > scripts 8^( ) The baseline FSF configure scripts will almost certainly give problems. All the configure scripts I use have been regenerated on the Amiga using the version of autoconf found in my GNU tools set on the FreshFish CD, and they all work fine now. Note that gdb is not completely ported yet (no ptrace() or /proc implementation to use) so even after you get it to compile, you can't use it for anything that requires a process to be running. It should still be useful for poking at executable and object files though. -Fred From amiga-gcc-port-owner@nic.funet.fi Sun Oct 29 02:25:53 1995 Received: from baurz32.urz.uni-bamberg.de ([141.13.250.32]) by nic.funet.fi with SMTP id <88221-1>; Sun, 29 Oct 1995 02:23:26 +0200 Received: from urzmail.stud.uni-bamberg.de by baurz32.urz.uni-bamberg.de with SMTP (1.37.109.4/16.2) id AA10695; Sun, 29 Oct 95 01:20:59 +0100 Received: from URZMAIL/SpoolDir by urzmail.stud.uni-bamberg.de (Mercury 1.13); Sun, 29 Oct 95 1:25:39 GMT+1 Received: from SpoolDir by URZMAIL (Mercury 1.13); Sun, 29 Oct 95 1:24:58 GMT+1 From: "Stefan Westner" Organization: UNI-BAMBERG To: amiga-gcc-port@nic.funet.fi Date: Sun, 29 Oct 1995 01:24:56 GMT+0100 Subject: Problem while compiling C++-Program X-Confirm-Reading-To: "Stefan Westner" X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <59D8E4053A@urzmail.stud.uni-bamberg.de> Hello, a friend of mine tried to compile the following small program but ld gives a error. He uses GCC 2.6.3. The program isn't fully C++ (no cout...) but it should work. Where's the problem? #include class grund { public: static int i; }; class kind : public grund { public: int j; }; main() { kind a,b; kind *c; c =new(kind); a.i = 10; printf("Die Zahl in b ist %d \n",b.i); printf("Die Zahl in c ist %d \n",c->i); } The error of the linker (!): t:cc8402561.o: Undefined symbol __5grund$i referenced from text segment t:cc8402561.o: Undefined symbol __5grund$i referenced from text segment t:cc8402561.o: Undefined symbol __5grund$i referenced from text segment The compiler is invoked with: g++ test.c -o test Anybody any suggestions...? Stefan -------------------------------------------------------------------------- Stefan Westner Tel: 0951/74375 Grabenstrasse 41 Stefan.Westner@stud.uni-bamberg.de 96103 Hallstadt PGP-Public-Key auf Anfrage verfuegbar PGP-Public-Key available on request -------------------------------------------------------------------------- ... So muessen Mails aussehen, dann klappts auch mit dem Nachbarn ... From amiga-gcc-port-owner@nic.funet.fi Sun Oct 29 02:28:27 1995 Received: from baurz32.urz.uni-bamberg.de ([141.13.250.32]) by nic.funet.fi with SMTP id <88165-2>; Sun, 29 Oct 1995 02:27:55 +0200 Received: from urzmail.stud.uni-bamberg.de by baurz32.urz.uni-bamberg.de with SMTP (1.37.109.4/16.2) id AA10754; Sun, 29 Oct 95 01:25:39 +0100 Received: from URZMAIL/SpoolDir by urzmail.stud.uni-bamberg.de (Mercury 1.13); Sun, 29 Oct 95 1:30:06 GMT+1 Received: from SpoolDir by URZMAIL (Mercury 1.13); Sun, 29 Oct 95 1:29:45 GMT+1 From: "Stefan Westner" Organization: UNI-BAMBERG To: amiga-gcc-port@nic.funet.fi Date: Sun, 29 Oct 1995 01:29:40 GMT+0100 Subject: Flags for a Productivity-Screen X-Confirm-Reading-To: "Stefan Westner" X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <59ED4809BC@urzmail.stud.uni-bamberg.de> A second question: I have the following NewScreen-struct which opens a HiRes-Screen. I want it to open a Productivity-Screen but haven't a new OS-Doku and don't know the flag I have to set instead of HIRES. static struct NewScreen AMIGA_NewScreen = { 0,0,AMIGA_XMAX,AMIGA_YMAX,2,1,0,VP_HIDE|HIRES, CUSTOMSCREEN|SCREENBEHIND|SCREENQUIET,NULL,NULL,NULL,NULL }; (Consts are defined previously, all necessary files included) Bye Stefan -------------------------------------------------------------------------- Stefan Westner Tel: 0951/74375 Grabenstrasse 41 Stefan.Westner@stud.uni-bamberg.de 96103 Hallstadt PGP-Public-Key auf Anfrage verfuegbar PGP-Public-Key available on request -------------------------------------------------------------------------- ... So muessen Mails aussehen, dann klappts auch mit dem Nachbarn ... From amiga-gcc-port-owner@nic.funet.fi Mon Oct 30 10:33:15 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <88129-3> convert rfc822-to-8bit; Sun, 29 Oct 1995 18:44:21 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id KAA23590 at Sun, 29 Oct 1995 10:32:21 +0200 Received: by softlab.ece.ntua.gr with UUCP id KAA18652 at Sun, 29 Oct 1995 10:29:51 +0200 (EET) Received: by kriton.UUCP (V1.17-beta/Amiga) id <08r6@kriton.UUCP>; Sat, 28 Oct 95 20:44:58 EET Date: Sat, 28 Oct 95 20:44:58 EET Message-Id: <9510281844.08r6@kriton.UUCP> In-Reply-To: (from Pedro Miguel Sequeira Teixeira ) (at Fri, 27 Oct 1995 13:46:37 +0000 (GMT)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!alfa.ist.utl.pt!l36599@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: setlocale ??? Hi Pedro (Pedro Miguel Sequeira Teixeira), in on Oct 27 you wrote: > > I try to compile GNU ed, but I get some trouble with setlocale function. > > When linking, gcc could not find _setlocale. So, where is setlocale ?? > > Its true, setlocale is NOT present in libc.a because nobody > ported it or bacause simply isnt in the original BSD4.5. > > Nevertheless, you can compile it! In the X11R6 MIT souce > pack, one of the components is Xsetlocale.c . This module has > a function that implements setlocale when the os doesnt supply > one. A simpler way is to simply undefine HAVE_LOCALE_H in config.h--this is what I've done. Ed can be compiled both in environments supporting and not supporting setlocale(). The configuration script selects setlocale() support based on the existence of , which for some reason exists on the Amiga even though it doesn't have a setlocale() function. Does Xsetlocale.c define a real implementation of setlocale(), or is it just a stub function? If it is the former, then perhaps it should be incorporated into ixemul/libnix. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "There is nothing wrong with my voice!" --Melanie. ----- From amiga-gcc-port-owner@nic.funet.fi Mon Oct 30 10:35:49 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <88682-2>; Sun, 29 Oct 1995 13:44:17 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HX0H9BR3OG000NUK@NET2.WAU.NL>; Sun, 29 Oct 1995 12:47:01 +0000 (GMT) Received: by vines2.wau.nl; Sun, 29 Oct 95 12:44:11 +0100 Date: Sun, 29 Oct 1995 12:37:32 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Perl problems? To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi All, I'm currently trying to compile some postscript related utilities and one of them uses a perl script to adjust some other perl scripts to adjust paths set in the makefile. I have a suspicion that it expects perl5 to be available but since I don't know nothing about it, I have to ask you :) The following is the commandline that make spits out, followed by the error produced by perl (FredFish-10). Also included the script itself (fixtpps.pl) and the script used to modify the other scripts (maketext). Is this Perl5? If so, how is the Perl5 port going? I need it ;) Thanks alot, Joop /gnu/bin/perl maketext PERL=/gnu/bin/perl fixtpps.pl > fixtpps /^#define\s*(\S*)\s*(\S*)/: corrupted regexp program at maketext line 12, line 1. %1 + 127490128 Stopped /gnu/bin/perl maketext PERL=/gnu/bin/perl fixtp ---------------------------------- fixtpps.pl ----------------------------- @PERL@ # fixtpps: fix tpscript document to work with PSUtils $nesting = 0; $header = 1; while (<>) { if (/^%%Page:/ && $nesting == 0) { print $_; print "save home\n"; $header = 0; } elsif (/^%%BeginDocument/ || /^%%BeginBinary/ || /^%%BeginFile/) { print $_; $nesting++; } elsif (/^%%EndDocument/ || /^%%EndBinary/ || /^%%EndFile/) { print $_; $nesting--; } elsif (/save home/) { s/save home//; print $_; } elsif (!$header || (! /^save$/ && ! /^home$/)) { print $_; } } @END@ -------------------------------- end of fixtpps.pl -------------------------- -------------------------------- maketext ----------------------------------- eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}' & eval 'exec perl -S $0 $argv:q' if 0; # maketext: perl filter to substitute names in scripts and man pages. %change = (); # names -> substitutions # get release and patchlevel for all scripts open(H, "patchlev.h") || die "can't open patchlev.h"; while() { $change{$1} = $2 if /^\#define\s*(\S*)\s*(\S*)/; } close(H); foreach (@ARGV) { if (/MAN=(.*)/) { # name.ext name.ext -> name(ext), name(ext) local(@man) = split(' ', $1); $change{"MAN"} = join(", ", grep(s/\.(.)/($1)/, @man)); } elsif (/PERL=(\/.*)/) { # substitute name for value $change{"PERL"} = "\#!$1\neval 'exec perl -S \$0 \"\$\@\"'\n\tif \$running_under_some_shell;\n"; $change{"END"} = ""; } elsif (/PERL=(.*)/) { # substitute name for value $change{"PERL"} = "\@rem = '-*- Perl -*-\n\@echo off\n$1 -S %0.cmd %1 %2 %3 %4 %5 %6 %7 %8 %9\ngoto endofperl\n';\n"; $change{"END"} = "__END__\n:endofperl\n"; } elsif (/(.*)=(.*)/) { # substitute name for value $change{$1} = $2; } else { # open file and substitute local(@change) = keys %change; open(FILE, $_) || die "can't open $_"; while ($line = ) { grep($line =~ s/\@$_\@/$change{$_}/g, @change); print $line; } close(FILE); } } ----------------------------------- end of maketext ------------------------- From amiga-gcc-port-owner@nic.funet.fi Mon Oct 30 10:36:21 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <88518-2>; Sun, 29 Oct 1995 11:08:17 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id KAA08860; Sun, 29 Oct 1995 10:05:27 +0100 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id JAA01063; Sun, 29 Oct 1995 09:55:04 +0100 Date: Sun, 29 Oct 1995 09:55:04 +0100 From: Niklas Hallqvist Message-Id: <199510290855.JAA01063@linda.appli.se> To: stefan.westner@stud.uni-bamberg.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <59D8E4053A@urzmail.stud.uni-bamberg.de> (stefan.westner@stud.uni-bamberg.de) Subject: Re: Problem while compiling C++-Program He've forgot to define the class static grund::i! Add int grund::i; right after the grund class decl. This is a C++ FAQ... class static vars are just "declared" inside the class, "define" them you have to do outside, in order to maintain the one definition rule of C++. Think of class decls in .h-files included in several files. If the decl inside the class were a def, you would end up with a multiply defined symbol when linking. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From amiga-gcc-port-owner@nic.funet.fi Mon Oct 30 10:57:46 1995 Received: from PhoneLink.COM ([193.195.138.3]) by nic.funet.fi with SMTP id <89373-3> convert rfc822-to-8bit; Mon, 30 Oct 1995 10:56:47 +0200 Received: from m500324.dev.phonelink.com by mailgate.PhoneLink.COM id aa12548; 30 Oct 95 9:52 GMT Received: by m500324.dev.phonelink.com with Microsoft Mail id <01BAA6A5.2EA83460@m500324.dev.phonelink.com>; Mon, 30 Oct 1995 08:53:28 -0000 Message-ID: <01BAA6A5.2EA83460@m500324.dev.phonelink.com> From: Steve Kaye To: 'Fred Fish' Cc: "amiga-gcc-port@nic.funet.fi" Subject: RE: GDB/Configure problems Date: Mon, 30 Oct 1995 08:53:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT > When I got the stack sorted out it still didn't work. After a number of = > error messages it told me that it couldn't configure for my machine. So = > I tried in the gdb directory. Where did you get the source from? The version I have configures and compiles just fine. I got the source from ftp.cygnus.com in pub/gdb. (In the GDBTK archive). Is this not correct? Where would be the best place for me to get the source? > This configure gave me a number of Checking for... lines. One of the = > first was checking for GNU C and it said no. Can anyone point me in the = > right direction please? (I have never had any luck with configure = > scripts 8^( ) The baseline FSF configure scripts will almost certainly give problems. All the configure scripts I use have been regenerated on the Amiga using the version of autoconf found in my GNU tools set on the FreshFish CD, and they all work fine now. Note that gdb is not completely ported yet (no ptrace() or /proc implementation to use) so even after you get it to compile, you can't use it for anything that requires a process to be running. It should still be useful for poking at executable and object files though. I was just looking at perhaps writing a GUI for it. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Oct 30 12:22:34 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <90341-1>; Mon, 30 Oct 1995 12:21:08 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id LAA01365 for ; Mon, 30 Oct 1995 11:14:17 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA03006; Mon, 30 Oct 95 11:19:53 GMT Date: Mon, 30 Oct 95 11:19:53 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9510301119.AA03006@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: Re: setlocale ??? > Its true, setlocale is NOT present in libc.a because nobody > ported it or bacause simply isnt in the original BSD4.5. > > Nevertheless, you can compile it! In the X11R6 MIT souce > pack, one of the components is Xsetlocale.c . This module has > a function that implements setlocale when the os doesnt supply > one. > > > - Pedro Teixeira - > > PS: If you dont want to bother extracting the whole pack just to > get this single module, i can send you the '.o'. Thanks, I have undefined HAVE_LOCAL_H and everything works fine. \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Mon Oct 30 12:23:49 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90375-4> convert rfc822-to-8bit; Mon, 30 Oct 1995 12:23:25 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA13576; Mon, 30 Oct 1995 11:25:22 +0100 Date: Mon, 30 Oct 1995 11:25:21 +0100 (MET) From: Kamil Iskra Subject: Two math library functions missing in LibNIX To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Subjects says it all (well, almost :-). Two standard, ANSI math library functions are missing in LibNIX 1.0. These are: double frexp(double, int*) - convert floating­point number to fractional and integral components. and double ldexp(double, int) - multiply floating­point number by integral power of 2. Why are they missing? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Oct 30 13:14:23 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89621-3>; Mon, 30 Oct 1995 13:02:41 +0200 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt; (5.65v3.0/1.1.8.2/24Jul95-0207PM) id AA24619; Mon, 30 Oct 1995 11:59:33 GMT Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/08Aug95-1153AM) id AA06405; Mon, 30 Oct 1995 12:00:13 GMT Date: Mon, 30 Oct 1995 12:00:12 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Amiga GCC Mailling list Subject: AS225 -> AmiTCP Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I take the opportunity of all the gossip around this AS225 theme to make a request: I know that there is/was a paket in the internet with socket.library and inet.library which was NOT AS225 but simply stubs for AS225 programs to use AmiTCP/IP. This could be a very good solution for ixemul to use AmiTCP/IP without having to rewrite the network stuff all over again with all the pain that arrives from it in bug removal and recompile. Please, if anyone has the information on how to get it, mail to this mailing list. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Mon Oct 30 13:35:33 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90661-2>; Mon, 30 Oct 1995 13:34:03 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Mon, 30 Oct 95 12:32:47 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <218886e6.u8t20e.6a90c-robert@plukwa.lodz.pdi.net> Subject: Re: AS225 -> AmiTCP In-Reply-To: (from Pedro Miguel Sequeira Teixeira ) (at Mon, 30 Oct 1995 12:00:12 +0000 (GMT)) Reply-To: robert@lodz.pdi.net Content-Length: 1040 To: amiga-gcc-port@nic.funet.fi Date: Mon, 30 Oct 95 12:32:47 Organization: PDi On Oct 30 Pedro Miguel Sequeira Teixeira wrote: > > I know that there is/was a paket in the internet with > socket.library and inet.library which was NOT AS225 but simply stubs for > AS225 programs to use AmiTCP/IP. > > Please, if anyone has the information on how to get it, mail to > this mailing list. Yes it's called socket_lib12.lha. This should be in comm/net or comm/tcp on Aminet and it is on plukwa.lodz.pdi.net in /amiga/comm/net > > > - Pedro Teixeira - > > > Robert -- +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Mon Oct 30 17:10:51 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90477-2>; Mon, 30 Oct 1995 17:09:19 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t9vpz-0004nYC; Mon, 30 Oct 95 08:09 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: GDB/Configure problems To: SteveK@PhoneLink.COM (Steve Kaye) Date: Mon, 30 Oct 1995 08:09:22 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <01BAA6A5.2EA83460@m500324.dev.phonelink.com> from "Steve Kaye" at Oct 30, 95 08:53:27 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1183 > I got the source from ftp.cygnus.com in pub/gdb. (In the GDBTK archive). > Is this not correct? Where would be the best place for me to get the > source? OK. What you have is the baseline FSF source, which does not have any of the Amiga specific patches, which have not yet been integrated into the master gdb source tree. The way to proceed would be to get the gdb amiga diffs from FreshFish 10 (or I can put them on our ftp server if you don't have easy access to that CD), and apply them to the gdb 4.15 source tree with "patch". Chances are quite good that a number of the patches won't apply cleanly because they are relative to the 4.14 source base, and you'll need to resolve the ones that fail. You can just ignore the gdb/tk and gdb/tcl directories (which are part of the gdbtk archive but not the gdb one) if you are doing a complete AmigaDOS specific GUI. They will probably be useful for reference purposes though. If you can wait a few weeks, I will have integrated 4.15 into my own source tree and dealt with the 4.14 -> 4.15 differences. They would be done sooner but I will be out of town for the Cologne show for about 9 days, starting in one week. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Oct 30 19:22:36 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90443-4>; Mon, 30 Oct 1995 19:20:53 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26487-3>; Mon, 30 Oct 1995 18:20:18 +0100 Received: from hphalle9g.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395722-2>; Mon, 30 Oct 1995 18:20:24 +0100 Subject: Re: Flags for a Productivity-Screen From: Christian Stieber To: stefan.westner@stud.uni-bamberg.de (Stefan Westner) Date: Mon, 30 Oct 1995 18:20:21 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <59ED4809BC@urzmail.stud.uni-bamberg.de> from "Stefan Westner" at Oct 29, 95 01:29:40 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 969 Message-Id: <95Oct30.182024+0100mesz.395722-2+301@hphalle0.informatik.tu-muenchen.de> > I have the following NewScreen-struct which opens a HiRes-Screen. I want > it to open a Productivity-Screen but haven't a new OS-Doku and don't know > the flag I have to set instead of HIRES. Struct NewScreen is obsolete, and the new modes can't be set with flags. Get RKM Libraries (I assume you already the 3.1 NDUK). Bascially, here's what you need to do: - obtain a suitable mode-ID from the displayinfo database (best idea is to use a screenmode requester). Remember, you don't even know whether "productivity" exists, and don't know whether the system can display it. Or you can use BestModeID() to find a suitable display mode. - use OpenScreenTagList() with that the mode-ID. Sorry, Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Mon Oct 30 19:40:35 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90608-1>; Mon, 30 Oct 1995 19:38:52 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0t9yAF-0004nZC; Mon, 30 Oct 95 10:38 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: setlocale ??? To: kyrimis@softlab.ece.ntua.gr Date: Mon, 30 Oct 1995 10:38:26 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: <9510281844.08r6@kriton.UUCP> from "Kriton Kyrimis" at Oct 28, 95 08:44:58 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3323 > > > I try to compile GNU ed, but I get some trouble with setlocale function. > > > When linking, gcc could not find _setlocale. So, where is setlocale ?? > > > > Its true, setlocale is NOT present in libc.a because nobody > > ported it or bacause simply isnt in the original BSD4.5. > > > > Nevertheless, you can compile it! In the X11R6 MIT souce > > pack, one of the components is Xsetlocale.c . This module has > > a function that implements setlocale when the os doesnt supply > > one. > > A simpler way is to simply undefine HAVE_LOCALE_H in config.h--this is > what > I've done. Ed can be compiled both in environments supporting and not > supporting setlocale(). The configuration script selects setlocale() support > based on the existence of , which for some reason exists on the > Amiga even though it doesn't have a setlocale() function. > Sigh. It saddens me to see people continuing to try to build things from the original FSF sources or incomplete sources obtained from random places on the internet, when these issues have already been dealt with for a long time in my source tree, which is widely distributed on CD-ROM. Now that our ftp server is online I will be working to make all of my environment available via ftp, since the CD-ROM distribution seems to be missing quite a few people. With regards to this issue, here is an excerpt from the diff file included on FreshFish-10 for ed-0.2, and which is already part of the amiga source included there. Note that if you apply these patches, you still need to rebuild the configure script. I didn't include the patches for the configure script since there are other changes in it that would probably make those patches fail to apply cleanly: diff -rc --new-file ed-0.2-base/config.h.in ed-0.2/config.h.in *** ed-0.2-base/config.h.in Sat Nov 19 12:37:59 1994 --- ed-0.2/config.h.in Wed Jul 19 18:57:10 1995 *************** *** 40,45 **** --- 40,48 ---- /* Define if you have the setbuffer function. */ #undef HAVE_SETBUFFER + /* Define if you have the setlocale function. */ + #undef HAVE_SETLOCALE + /* Define if you have the sigaction function. */ #undef HAVE_SIGACTION diff -rc --new-file ed-0.2-base/configure.in ed-0.2/configure.in *** ed-0.2-base/configure.in Sat Nov 19 12:38:00 1994 --- ed-0.2/configure.in Wed Jul 19 18:56:26 1995 *************** *** 11,17 **** AC_C_CONST AC_HEADER_STDC AC_CHECK_HEADERS(limits.h memory.h string.h unistd.h locale.h) ! AC_CHECK_FUNCS(setbuffer sigsetjmp sigaction strerror) AC_FUNC_VPRINTF AC_FUNC_ALLOCA if test "$ALLOCA" = alloca.o; then --- 11,17 ---- AC_C_CONST AC_HEADER_STDC AC_CHECK_HEADERS(limits.h memory.h string.h unistd.h locale.h) ! AC_CHECK_FUNCS(setbuffer sigsetjmp sigaction strerror setlocale) AC_FUNC_VPRINTF AC_FUNC_ALLOCA if test "$ALLOCA" = alloca.o; then diff -rc --new-file ed-0.2-base/main.c ed-0.2/main.c *** ed-0.2-base/main.c Sat Nov 19 12:38:02 1994 --- ed-0.2/main.c Wed Jul 19 18:55:54 1995 *************** *** 205,211 **** argv++; argc--; } ! #if HAVE_LOCALE_H setlocale(LC_CTYPE, ""); #endif init_buffers (); --- 205,211 ---- argv++; argc--; } ! #if defined (HAVE_LOCALE_H) && defined (HAVE_SETLOCALE) setlocale(LC_CTYPE, ""); #endif init_buffers (); From amiga-gcc-port-owner@nic.funet.fi Tue Oct 31 07:07:22 1995 Received: from sunmbx.netmbx.de ([192.76.152.9]) by nic.funet.fi with SMTP id <90414-4>; Tue, 31 Oct 1995 07:05:46 +0200 Received: by sunmbx.netmbx.de (/\==/\ Smail3.1.28.1) from tmpmbx.netmbx.de with smtp id ; Tue, 31 Oct 95 06:06 MET Received: by tmpmbx.netmbx.de (/\==/\ Smail3.1.28.1 #28.6) id ; Tue, 31 Oct 95 05:59 MET Received: from tbx by zelator.BerliNet.DE with bsmtp (Smail3.1.28.1 #11) id m0tA9UQ-0003zMC; Tue, 31 Oct 95 05:44 MESZ To: amiga-gcc-port@lists.funet.fi Message-Id: <33@bw01.bbrandes.berlinet.de> From: B.WINKELMANN@BBrandes.berlinet.de (Bert Winkelmann) Path: tbx.berlinet.de!bbrandes.berlinet.de!B.WINKELMANN Subject: No stderr in Emacs with ixemul-41.4 Date: Mon, 30 Oct 1995 18:40:25 +0100 X-Mailer: UMSZer V2.22 public X-Gateway: ZCONNECT U2 zelator.BerliNet.DE [UNIX/Connect v0.71] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-VIA: 19951030000000W+1@BBrandes.berlinet.de Lines: 23 Hi. There is no gcc error-output for Emacs-compile since I had updating ixemul-library from 41.3 to 41.4. Another symptom is an ``invisible'' shell-prompt in the Emacs-Shell-buffer, and all output for stdout (ls) is ok, but for stderr (ls --help) nothing is printed. I had tried out different sh's for emacs/etc/sh, but without any difference. Outside of Emacs all works fine as usual (with Amiga-Shell and ksh). Have someone already discovered this bug? Is this a bug in ixemul.library? Bert. versions: Amiga-1200 w/ 68ec030 w/o FPU ixemul-4140-3s.lha from Aminet GNU-Emacs 18.59,Amiga port 1.28DG Beta fifo.library 37.3 fifo.library 37.4 (7 Dec 1991) From amiga-gcc-port-owner@nic.funet.fi Tue Oct 31 08:34:38 1995 Received: from mail.eskimo.com ([204.122.16.4]) by nic.funet.fi with SMTP id <90220-3>; Tue, 31 Oct 1995 08:33:06 +0200 Received: from amiga1.eskimo.com (dbakeman@tia1.eskimo.com [204.122.16.40]) by mail.eskimo.com (8.6.12/8.6.12) with SMTP id WAA19536; Mon, 30 Oct 1995 22:32:38 -0800 Date: Mon, 30 Oct 1995 22:31:37 +0000 () From: "David J. Bakeman" To: joop van de wege cc: amiga-gcc-port@nic.funet.fi Subject: Re: Perl problems? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 29 Oct 1995, joop van de wege wrote: > Date: Sun, 29 Oct 1995 12:37:32 +0100 (CET) > From: joop van de wege > To: amiga-gcc-port@nic.funet.fi > Subject: Perl problems? > > Hi All, > > I'm currently trying to compile some postscript related utilities and one of > them uses a perl script to adjust some other perl scripts to adjust paths set > in the makefile. > I have a suspicion that it expects perl5 to be available but since I don't > know nothing about it, I have to ask you :) > The following is the commandline that make spits out, followed by the error > produced by perl (FredFish-10). > Also included the script itself (fixtpps.pl) and the script used to modify > the other scripts (maketext). > Is this Perl5? Can't answer that. > If so, how is the Perl5 port going? I need it ;) > > Thanks alot, Joop > > /gnu/bin/perl maketext PERL=/gnu/bin/perl fixtpps.pl > fixtpps > /^#define\s*(\S*)\s*(\S*)/: corrupted regexp program at maketext line 12, > line 1. However, I had a perl script which ran fine on the computer at work perl4.xxx and gave me the same error that you received at home. Namely the "corrupted regexp program". I assumed it was a problem with the Amiga port so I took a look at the sources on Fresh Fish Vol 9. Low and behold there was a problem where in the regex processor CHARBITS was used to mask off all the non character bits in an int. However, the problem is that CHARBITS is the number of bits in a character (8) not the appropriate mask for this job (0xff). I changed that line in one of the include files (I forget which one) recompiled perl and my script worked great! I assumed that this was a known problem and forgot about it chalking it up to some more debug experience on the Amy. If you would like I could provide you with the perl binary I use. Also does anyone know has this problem been fixed and released to the Amiga community? > %1 + 127490128 Stopped > /gnu/bin/perl maketext PERL=/gnu/bin/perl fixtp > ------------------- David J. Bakeman dbakeman@eskimo.com Seattle, WA 98103 From amiga-gcc-port-owner@nic.funet.fi Tue Oct 31 10:59:30 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90264-3>; Tue, 31 Oct 1995 10:56:26 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HX33YQPS1S001GR5@NET2.WAU.NL>; Tue, 31 Oct 1995 09:59:01 +0000 (GMT) Received: by vines2.wau.nl; Tue, 31 Oct 95 9:55:58 +0100 Date: Tue, 31 Oct 1995 09:39:43 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: Perl problems? & cp BUG! (new) To: dbakeman@eskimo.com Cc: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hello David, >> /gnu/bin/perl maketext PERL=/gnu/bin/perl fixtpps.pl > fixtpps >> /^#define\s*(\S*)\s*(\S*)/: corrupted regexp program at maketext line 12, >> line 1. > I assumed that this was a known problem and forgot about it chalking it up > to some more debug experience on the Amy. I wonder why Fred didn't find this problem, he is constantly rebuilding the gnu tree and uses, probably, a lot of the gnu utilities in scripts. The bug is still present since my current version of Perl comes from the FF10 CD. I know and you know that Fred reads this list but I think it would be wise to send him a mail with a patch. > If you would like I could provide you with the perl binary I use. Please, please do :) I wouldn't mind recompiling Perl, but I have to find first the correct place to fix this bug and then hope I don't make a mess out of something else. Not to mention that I have more projects going and all of them require some attention. > Also does anyone know has this problem been fixed and released to the Amiga > community? Probably not since I use the version from FF10 and that one is still broken :( Now for something new. I already wrote this to csa.programmer but it really belongs over here. I have a makefile which after an error continues to copy the, supposed to be there, executable to another place using 'cp'. The link phase generates an empty file and 'cp' hangs on it while it tries to copy it. Example: cp c2pad ../../ I just hangs, doesn't use any CPU time but you can't CTRL-C it. Its not a stack problem because if I correct the source so that it links correctly then with the same stack size it will copy it. Q:Is this a know problem? If not, where can I find the source for 'cp'? I'm willing to have a look and fix it that is if nobody else wants todo it. Probably somewhere on FF10 :) but my CDROM player is my CD32, not the fastest CD in the world when you need to find something on it, isn't it. Joop From amiga-gcc-port-owner@nic.funet.fi Tue Oct 31 11:18:48 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90312-1>; Tue, 31 Oct 1995 11:17:17 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA26269; Tue, 31 Oct 1995 10:19:03 +0100 Date: Tue, 31 Oct 1995 10:19:02 +0100 (MET) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Spilled registers To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I made a change in "fd2inline" to protect "lot-of-args" functions from being inlined. Fd2Inline basically protects them with "#ifdef __ALLINLINES__"/"#endif /* __ALLINLINES__ */". Maybe in "new" inlines it would be better to just remove "__inline" keyword from LP-macros for "big" functions - but I guess that "-O3" will break force inlining of such functions and the problem will reappear. This corrected version is not available yet, since I'm not sure which functions should be protected. According to Joop van de Wege functions that have problems use all data registers and some address registers. That's what I implemented in "fd2inline". The only such function is graphics.library/BltBitMap(), but I've read that there were also problems with DoPkt() - which, as I checked, uses 7 data registers (d1-d7) and no address registers. So please report which functions really causes these problems. Actually, I'm not sure whether one can clearly say which functions can and which cannot be inlined. It seems to largely depend on complexity of arguments. Who can guarantee that in very complex case function that takes only 4 or 5 arguments won't cause problems? Maybe it would be better just to simplify expressions when GCC complains, not to change inlines? But will this work? Please check - I don't have any "real" sources that causes such problems. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Tue Oct 31 15:10:39 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89476-1>; Tue, 31 Oct 1995 15:08:39 +0200 Received: from pythia.forthnet.gr (pythia.forthnet.gr [139.91.1.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id NAA16528 for ; Tue, 31 Oct 1995 13:08:11 GMT Content-Transfer-Encoding: 8bit Received: from achilles.noc.ntua.gr by pythia.forthnet.gr via FORTHnet with ESMTP; id PAA09702 (8.6.12/FORTHNET-2.0-MHS-7.0); Tue, 31 Oct 1995 15:02:34 +0200 Organization: Received: by achilles.noc.ntua.gr via NTUAnet with SMTP id PAA03824 at Tue, 31 Oct 1995 15:03:56 +0200 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt; (5.65v3.0/1.1.8.2/24Jul95-0207PM) id AA24732; Mon, 30 Oct 1995 11:42:13 GMT Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/08Aug95-1153AM) id AA03698; Mon, 30 Oct 1995 11:42:54 GMT Date: Mon, 30 Oct 1995 11:42:53 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: kyrimis@softlab.ece.ntua.gr Cc: l36599@alfa.ist.utl.pt, amiga-gcc-port@nic.funet.fi Subject: Re: setlocale ??? In-Reply-To: <9510281844.08r6@kriton.UUCP> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 28 Oct 1995, Kriton Kyrimis wrote: > Does Xsetlocale.c define a real implementation of setlocale(), or is it just a > stub function? If it is the former, then perhaps it should be incorporated > into ixemul/libnix. I realy dont know, but since all xclients feel happy with it, I suppose so. Realy, I cannot, at this moment, take the time to look at it better but I can mail you the source for that piece. - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Tue Oct 31 16:57:16 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90743-1>; Tue, 31 Oct 1995 16:54:44 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HX3GI7WOBK001OS4@NET2.WAU.NL>; Tue, 31 Oct 1995 15:57:32 +0000 (GMT) Received: by vines2.wau.nl; Tue, 31 Oct 95 15:54:32 +0100 Date: Tue, 31 Oct 1995 15:51:37 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: FD2inline & lots of args To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi Kamil, The only function that I had problems with was indeed BltBitMap from graphics.library and someone else made a bet with me (Jeroen ?) that it would be the DoPkt(x) functions. I know from Olaf Barthel that he can compile gdevamiga.c without problems and I assume that he is using inlines, BUT I know that he is using an older version of GCC, probably pre 2.6.3.I'll ask about his gcc version and commandline options! About the complexity of functions and nesting of blocks. It shouldn't be too difficult to make up a small program which has some nesting of if/switch and see what happens when those problem functions are used. The program doesn't need to be runnable, it is only needed to test the compilers ability to store registers in memory. My first thought when I got that error 'forbidden register spilled' was that indeed the function was too complex. It has about 8-9 levels of if/else and BltBitMap is used in one of the inner blocks. Removing levels didn't help at all. I stopped trying after removing 4-5 levels. I haven't tried this: #include #include main(){ BtBlitMap(fill in all parameters needed as constants); } gcc -O2 -m68020-40 simple_test.c Who is still having 2.6.3 on his/hers HD, who is willing to test gdevamiga.i ? Mail me and I'll make it available on my tempory ftp-site or mail it to you as an uuencoded lha archive. Joop From amiga-gcc-port-owner@nic.funet.fi Tue Oct 31 17:05:58 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89580-1>; Tue, 31 Oct 1995 17:04:44 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tAIEz-0004nZC; Tue, 31 Oct 95 08:04 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: FD2inline & lots of args To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Tue, 31 Oct 1995 08:04:40 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "joop van de wege" at Oct 31, 95 03:51:37 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 418 > I know from Olaf Barthel that he can compile gdevamiga.c without problems > and I assume that he is using inlines, BUT I know that he is using an older > version of GCC, probably pre 2.6.3.I'll ask about his gcc version and > commandline options! In case it helps, I'm using 2.7.0 to compile gdevamiga.c, as follows: gcc -c -I. -I/gnu-src/src/gs-2.6.2 -DUSG -O2 /gnu-src/src/gs-2.6.2/gdevamiga.c -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Oct 31 17:06:34 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89069-3>; Tue, 31 Oct 1995 17:05:05 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA05582 (5.65c8/IDA-1.4.4 for ); Tue, 31 Oct 1995 16:04:35 +0100 Received: by diva.gmd.de with UUCP id AA01640 (5.67b8/IDA-1.5); Tue, 31 Oct 1995 16:01:43 +0100 Date: Tue, 31 Oct 1995 16:01:43 +0100 Message-Id: <199510311501.AA01640@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: B.WINKELMANN@bbrandes.berlinet.de (Bert Winkelmann) Cc: amiga-gcc-port@nic.funet.fi Subject: No stderr in Emacs with ixemul-41.4 In-Reply-To: <33@bw01.bbrandes.berlinet.de> References: <33@bw01.bbrandes.berlinet.de> Bert Winkelmann writes: > There is no gcc error-output for Emacs-compile since I had updating > ixemul-library from 41.3 to 41.4. Another symptom is an ``invisible'' > shell-prompt in the Emacs-Shell-buffer, and all output for stdout (ls) > is ok, but for stderr (ls --help) nothing is printed. > I had tried out different sh's for emacs/etc/sh, but without any > difference. It looks like some weird interaction between ixemul's handling of "*|CONSOLE:", stderr, pr_ConsoleTask and FIFO:. Depending on the command, (start-process, call-process, call-process-region), Emacs does or doesn't use the "s" option of FIFO, which means to create a console port for the process. When I dug into this in the past, I found the settings quite reasonable. All I found is that all C: commands would not output anything (in call-process), whereas self-written ones (opening "*") and anything else I tried would. I don't know what kind of black magic programs in C: still do. BCPL is long gone (did I think). Now it looks like ixemul.library provides no stderr at all when it can't find any of pr_ConsoleTask or "*". People thought it would be a reasonable setting (no stderr messages found in stdout) but in this case it harms. I guess I have to look into that once again and see what goes wrong. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Tue Oct 31 17:16:57 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89238-4>; Tue, 31 Oct 1995 17:14:36 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA06616 (5.65c8/IDA-1.4.4 for ); Tue, 31 Oct 1995 16:14:18 +0100 Received: by diva.gmd.de with UUCP id AA01651 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Tue, 31 Oct 1995 16:11:27 +0100 Date: Tue, 31 Oct 1995 16:11:27 +0100 Message-Id: <199510311511.AA01651@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: No stderr in Emacs with ixemul-41.4 In-Reply-To: <199510311501.AA01640@diva.gmd.de> References: <33@bw01.bbrandes.berlinet.de> <199510311501.AA01640@diva.gmd.de> I wrote (I shouldn't quote myself but so it goes): > Now it looks like ixemul.library provides no stderr at all when it > can't find any of pr_ConsoleTask or "*". People thought it would be a > reasonable setting (no stderr messages found in stdout) but in this > case it harms. It would be interesting to see what happens in other similar cases (e.g. all I/O in one channel), like running a shell through AUX:, an AmiTCP telnet or rsh session (uh, many factors would be involved there), a DNet CLITerm. I wouldn't like it if there was no stderr. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Tue Oct 31 21:13:15 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89344-4>; Tue, 31 Oct 1995 21:11:12 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tAM6P-0004naC; Tue, 31 Oct 95 12:12 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Perl problems? & cp BUG! (new) To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Tue, 31 Oct 1995 12:12:04 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: from "joop van de wege" at Oct 31, 95 09:39:43 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 936 > I wonder why Fred didn't find this problem, he is constantly rebuilding the > gnu tree and uses, probably, a lot of the gnu utilities in scripts. Although the current multistage builds can find a lot of potential problems, they can only do so if the utility in question is actually used during the builds, which I suspect perl is not (currently). Eventually I hope that there will be testsuites for all the tools, that can be run as further validation from the root of the binary tree with a simple "make check". I don't currently run the perl testsuite after each rebuild. > I know and you know that Fred reads this list but I think it would be wise to > send him a mail with a patch. Yes, I do prefer to get explicit patches for things that people find that need fixing. > Q:Is this a know problem? I haven't been able to reproduce it here. > If not, where can I find the source for 'cp'? Cp is in the fileutils. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Oct 31 22:13:09 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89140-3>; Tue, 31 Oct 1995 22:11:35 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tAN34-0004naC; Tue, 31 Oct 95 13:12 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: setlocale ??? To: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Date: Tue, 31 Oct 1995 13:12:41 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <199510311413.AA14940@hpcl.cti.gr> from "Kriton Kyrimis" at Oct 31, 95 04:13:08 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1480 > It saddens me to see people assume that: > a) I have a CD ROM drive (no, they are not this cheap over here) I can appreciate that not everyone has access to a CD-ROM drive. Although they have come down a lot in price the last couple years, they may still be outside of many people's computing budget. Now that our ftp server is on line (we were waiting almost 3 months for a T1 connection) I plan to make all of the GNU tools available online, with online updates available about every two weeks. > b) That I have the patience to wait for the latest version of some > easy-to-port GNU software to appear on CD ROM (by which time, it may very > well no longer be the latest version). From what I remember, I had ed 0.2 > running on my Amiga within a couple of days of its being released. In most cases when a new release comes out, if you already have the Amiga diffs for the previous release, you simply have to run "patch" to apply those diffs and recompile. But you do make a good point, that CD releases every 2-3 months are not optimal for people that want to be on the cutting edge. The flipside to that is that many people *don't* want to be on the cutting edge, they want stability and reliability, and are happy with quarterly releases. The company I do consulting for (Cygnus Support) sells support contracts for GNU tools to large corporations, and this is the model they use (quarterly releases of stable and tested versions of the GNU tools). -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 1 00:39:50 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90568-4>; Wed, 1 Nov 1995 00:38:16 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tAPHu-0004nbC; Tue, 31 Oct 95 15:36 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: setlocale ??? To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Tue, 31 Oct 1995 15:36:09 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: from "Walter Harms" at Oct 31, 95 10:06:25 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6515 > talking about budget, can you chop down the size of the > archives for ppl with not so fast connections ? i remember > well time where it took me hours to get those files. I already package each tool individually, much like the FSF. Basically to get one package, such as "binutils" or "gcc", you have to download a given number of bytes. Then the issue is simply whether to put all those bytes in one archive or split them into smaller pieces. Splitting only make sense if you are on an unstable link and don't want to have to restart the download from the beginning if it dies. Then you have the tradeoff of deciding how big to make the pieces. Here for example are the bin archives from the FF9 BBS/GNU tree: -rwxrwxrwx 1 amiga amiga 9819 Apr 15 1995 gnu/GNU-Startup-bin.lha -rwxrwxrwx 1 amiga amiga 211762 Apr 15 1995 gnu/GNU-misc-bin.lha -rwxrwxrwx 1 amiga amiga 38535 Apr 15 1995 gnu/autoconf-1.11-bin.lha -rwxrwxrwx 1 amiga amiga 129853 Apr 15 1995 gnu/autoconf-2.1-bin.lha -rwxrwxrwx 1 amiga amiga 291991 Apr 15 1995 gnu/autoconf-2.2-bin.lha -rwxrwxrwx 1 amiga amiga 79181 Apr 15 1995 gnu/bc-1.03-bin.lha -rwxrwxrwx 1 amiga amiga 80654 Apr 15 1995 gnu/binutils-1.8.x-bin.lha -rwxrwxrwx 1 amiga amiga 189455 Apr 15 1995 gnu/binutils-1.8.x.tar.gz -rwxrwxrwx 1 amiga amiga 534263 Apr 15 1995 gnu/binutils-2.5.2-bin.lha -rwxrwxrwx 1 amiga amiga 3201867 Apr 15 1995 gnu/binutils-2.5.2.tar.gz -rwxrwxrwx 1 amiga amiga 124245 Apr 15 1995 gnu/bison-1.22-bin.lha -rwxrwxrwx 1 amiga amiga 17739 Apr 15 1995 gnu/brik-2.0-bin.lha -rwxrwxrwx 1 amiga amiga 1276448 Apr 15 1995 gnu/calc-2.02c-bin.lha -rwxrwxrwx 1 amiga amiga 48990 Apr 15 1995 gnu/cpio-2.3-bin.lha -rwxrwxrwx 1 amiga amiga 40677 Apr 15 1995 gnu/dbmalloc-1.14-bin.lha -rwxrwxrwx 1 amiga amiga 15245 Apr 15 1995 gnu/dbug-2.3-bin.lha -rwxrwxrwx 1 amiga amiga 168088 Apr 15 1995 gnu/diffutils-2.7-bin.lha -rwxrwxrwx 1 amiga amiga 11005 Apr 15 1995 gnu/doschk-1.1-bin.lha -rwxrwxrwx 1 amiga amiga 4764 Apr 15 1995 gnu/dumphunks-1.0-bin.lha -rwxrwxrwx 1 amiga amiga 5178 Apr 15 1995 gnu/ecc-1.2.1-bin.lha -rwxrwxrwx 1 amiga amiga 98106 Apr 15 1995 gnu/ed-0.1-bin.lha -rwxrwxrwx 1 amiga amiga 100412 Apr 15 1995 gnu/eispack-1.0-bin.lha -rwxrwxrwx 1 amiga amiga 2380243 Apr 15 1995 gnu/emacs-18.59-bin.lha -rwxrwxrwx 1 amiga amiga 176464 Apr 15 1995 gnu/f2c-1993.04.28-bin.lha -rwxrwxrwx 1 amiga amiga 291115 Apr 15 1995 gnu/fileutils-3.12-bin.lha -rwxrwxrwx 1 amiga amiga 102430 Apr 15 1995 gnu/findutils-4.1-bin.lha -rwxrwxrwx 1 amiga amiga 266406 Apr 15 1995 gnu/flex-2.4.7-bin.lha -rwxrwxrwx 1 amiga amiga 140683 Apr 15 1995 gnu/fontutils-0.6-bin.lha -rwxrwxrwx 1 amiga amiga 783332 Apr 15 1995 gnu/g77-0.5.13-bin.lha -rwxrwxrwx 1 amiga amiga 469431 Apr 15 1995 gnu/gawk-2.15.6-bin.lha -rwxrwxrwx 1 amiga amiga 1697325 Apr 15 1995 gnu/gcc-2.3.3-bin.lha -rwxrwxrwx 1 amiga amiga 3087966 Apr 15 1995 gnu/gcc-2.6.3-bin.lha -rwxrwxrwx 1 amiga amiga 646924 Apr 15 1995 gnu/gdb-4.14-bin.lha -rwxrwxrwx 1 amiga amiga 32014 Apr 15 1995 gnu/gdbm-1.7.3-bin.lha -rwxrwxrwx 1 amiga amiga 58423 Apr 15 1995 gnu/gmp-1.3.2-bin.lha -rwxrwxrwx 1 amiga amiga 2891845 Apr 15 1995 gnu/gnat-2.03-bin.lha -rwxrwxrwx 1 amiga amiga 107373 Apr 15 1995 gnu/grep-2.0-bin.lha -rwxrwxrwx 1 amiga amiga 1040078 Apr 15 1995 gnu/groff-1.09-bin.lha -rwxrwxrwx 1 amiga amiga 500930 Apr 15 1995 gnu/gs-2.6.1.4-bin.lha -rwxrwxrwx 1 amiga amiga 1750079 Apr 15 1995 gnu/gs-fonts-2.6.1-bin.lha -rwxrwxrwx 1 amiga amiga 199986 Apr 15 1995 gnu/gzip-1.2.4-bin.lha -rwxrwxrwx 1 amiga amiga 45560 Apr 15 1995 gnu/indent-1.9.1-bin.lha -rwxrwxrwx 1 amiga amiga 270431 Apr 15 1995 gnu/ispell-4.0-bin.lha -rwxrwxrwx 1 amiga amiga 867224 Apr 15 1995 gnu/ixemul-40.4-bin.lha -rwxrwxrwx 1 amiga amiga 724142 Apr 15 1995 gnu/ixemul-40.4-env-bin.lha -rwxrwxrwx 1 amiga amiga 152886 Apr 15 1995 gnu/jove-4.14.6-bin.lha -rwxrwxrwx 1 amiga amiga 69908 Apr 15 1995 gnu/less-252-bin.lha -rwxrwxrwx 1 amiga amiga 24287 Apr 15 1995 gnu/libcurses-8.3-bin.lha -rwxrwxrwx 1 amiga amiga 815182 Apr 15 1995 gnu/libg++-2.6.2-bin.lha -rwxrwxrwx 1 amiga amiga 15643 Apr 15 1995 gnu/libm-5.4-bin.lha -rwxrwxrwx 1 amiga amiga 215345 Apr 15 1995 gnu/libnix-0.8-bin.lha -rwxrwxrwx 1 amiga amiga 82857 Apr 15 1995 gnu/m4-1.4-bin.lha -rwxrwxrwx 1 amiga amiga 195353 Apr 15 1995 gnu/make-3.71-bin.lha -rwxrwxrwx 1 amiga amiga 3366734 Apr 15 1995 gnu/octave-1.1.1-bin.lha -rwxrwxrwx 1 amiga amiga 46386 Apr 15 1995 gnu/patch-2.1-bin.lha -rwxrwxrwx 1 amiga amiga 158487 Apr 15 1995 gnu/pdksh-4.9-bin.lha -rwxrwxrwx 1 amiga amiga 345419 Apr 15 1995 gnu/perl-4.036-bin.lha -rwxrwxrwx 1 amiga amiga 242836 Apr 15 1995 gnu/rcs-5.6.0.1-bin.lha -rwxrwxrwx 1 amiga amiga 38683 Apr 15 1995 gnu/sed-2.05-bin.lha -rwxrwxrwx 1 amiga amiga 229700 Apr 15 1995 gnu/sh-utils-1.12-bin.lha -rwxrwxrwx 1 amiga amiga 57857 Apr 15 1995 gnu/sharutils-4.1-bin.lha -rwxrwxrwx 1 amiga amiga 65737 Apr 15 1995 gnu/tar-1.11.2-bin.lha -rwxrwxrwx 1 amiga amiga 167826 Apr 15 1995 gnu/termcap-1.2-bin.lha -rwxrwxrwx 1 amiga amiga 472726 Apr 15 1995 gnu/texinfo-3.1-bin.lha -rwxrwxrwx 1 amiga amiga 289924 Apr 15 1995 gnu/textutils-1.11-bin.lha -rwxrwxrwx 1 amiga amiga 6984081 Apr 15 1995 gnu/unixtex-6.1b-bin.lha -rwxrwxrwx 1 amiga amiga 15160 Apr 15 1995 gnu/wdiff-0.5-bin.lha Certainly the larger ones could be split into equal sized chunks using bsplit, so that if you want gnat-2.03-bin.lha for example, you have to download: gnat-2.03-bin.lha.1 (100000 Kb) gnat-2.03-bin.lha.2 (100000 Kb) gnat-2.03-bin.lha.3 (100000 Kb) . . . > divide in alpha-release, beta-release This is effectively what our ftp'able releases will be. > and gamma-release ... gamma for ordinary ppl This is what will be going on our new developers CD when we migrate the GNU tools off of FreshFish. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 1 11:52:58 1995 Received: from mailgate.isltd.insignia.com ([193.112.16.21]) by nic.funet.fi with SMTP id <89332-1>; Wed, 1 Nov 1995 11:46:42 +0200 X-Address: Insignia Solutions plc., High Wycombe, Bucks, HP11 1JU, UK X-Telephone: +44 1494 459426 X-Fax: +44 1494 459720 Received: from creda.isltd.insignia.com by mailgate.isltd.insignia.com (5.65c8/UK-2.1.ISL) with SMTP id AA16192; Wed, 1 Nov 1995 09:25:48 GMT Date: Wed, 1 Nov 1995 09:23:01 +0000 (GMT) From: Peter Ivimey-Cook To: Fred Fish Cc: Walter Harms , Amiga GCC mailing list Subject: Re: setlocale ??? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 31 Oct 1995, Fred Fish wrote: > a given number of bytes. Then the issue is simply whether to put all > those bytes in one archive or split them into smaller pieces. Splitting > only make sense if you are on an unstable link and don't want to have > to restart the download from the beginning if it dies. Then you have the I disagree... splitting things (sensibly) allows people who can happily do without sections of archive to do so. For example, for the ixemul release, those who merely wish to use the latest release have no need to download the include files, man pages etc. whoc go with the current "bin" archive, and approximately triple the file size. Regards, Peter Ivimey-Cook. From amiga-gcc-port-owner@nic.funet.fi Wed Nov 1 14:26:39 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <89370-1>; Wed, 1 Nov 1995 14:25:32 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id HAA15711; Wed, 1 Nov 1995 07:25:14 -0500 (from cz253) Message-Id: <199511011225.HAA15711@kanga.INS.CWRU.Edu> Date: Wed, 1 Nov 1995 07:25:14 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: I must have missed something... Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) ...I thought gcc 2.7.0 was compiled using the stack extend option. If so cc1 got missed. :( If not, perhaps it should be. .....Dave From amiga-gcc-port-owner@nic.funet.fi Wed Nov 1 16:03:07 1995 Received: by nic.funet.fi id <88914-2>; Wed, 1 Nov 1995 16:00:09 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <95Nov1.160009+0200_eet.88914-2+47@nic.funet.fi> Date: Wed, 1 Nov 1995 16:00:03 +0200 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Wed Nov 1 17:24:21 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89041-1>; Wed, 1 Nov 1995 17:21:27 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tAeyT-0004naC; Wed, 1 Nov 95 08:21 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: packaging of releases To: Peter.Ivimey-Cook@isltd.insignia.com (Peter Ivimey-Cook) Date: Wed, 1 Nov 1995 08:21:08 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: from "Peter Ivimey-Cook" at Nov 1, 95 09:23:01 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3269 > > a given number of bytes. Then the issue is simply whether to put all > > those bytes in one archive or split them into smaller pieces. Splitting > > only make sense if you are on an unstable link and don't want to have > > to restart the download from the beginning if it dies. Then you have the > > I disagree... splitting things (sensibly) allows people who can happily > do without sections of archive to do so. We seem to have different definitions for "splitting". The way I was using it was that I have some archive of N bytes, say foo.lha, and want it to be available in smaller pieces, so I run a program that chops it up into M pieces, where each piece (except possibly the last) is N/M bytes. I.E: Script started on Wed Nov 1 08:12:34 1995 fishpond [1] ls -l gdb-4.15.tar.gz -rw-r--r-- 1 fnf amigalib 5513158 Nov 1 08:11 gdb-4.15.tar.gz fishpond [2] bsplit -1000000 gdb-4.15.tar.gz gdb-4.15.tar.gz. fishpond [3] ls -l gdb-4.15* -rw-r--r-- 1 fnf amigalib 382906 Oct 27 23:15 gdb-4.15-testsuite.tar.gz -rw-r--r-- 1 fnf amigalib 5513158 Nov 1 08:11 gdb-4.15.tar.gz -rw-r--r-- 1 fnf amigalib 1000000 Nov 1 08:12 gdb-4.15.tar.gz.aa -rw-r--r-- 1 fnf amigalib 1000000 Nov 1 08:12 gdb-4.15.tar.gz.ab -rw-r--r-- 1 fnf amigalib 1000000 Nov 1 08:12 gdb-4.15.tar.gz.ac -rw-r--r-- 1 fnf amigalib 1000000 Nov 1 08:12 gdb-4.15.tar.gz.ad -rw-r--r-- 1 fnf amigalib 1000000 Nov 1 08:12 gdb-4.15.tar.gz.ae -rw-r--r-- 1 fnf amigalib 513158 Nov 1 08:12 gdb-4.15.tar.gz.af fishpond [4] exit Script done on Wed Nov 1 08:13:05 1995 This is just so that people can get the archive in more comfortably sized pieces. They still need the entire archive. > For example, for the ixemul > release, those who merely wish to use the latest release have no need to > download the include files, man pages etc. whoc go with the current "bin" > archive, and approximately triple the file size. What you are describing is not splitting, it is repackaging to produce a larger number of smaller archives, each of which is part of a larger package. One way to do this would be to take the manifest files that are included on my CD-ROMS (gnu:manifests), and break them into several smaller files that each list the contents of the desired archives. The typical manifest file looks like (for ixemul binary dist): Sys/Libs/ixemul.library Sys/Libs/ixemul.trace Sys/Libs/ixemul000.library Sys/Libs/ixemul000.trace Sys/Libs/ixemul020.library Sys/Libs/ixemul020.trace Sys/Libs/ixemul020fpu.library Sys/Libs/ixemul020fpu.trace Sys/Libs/ixemul030.library Sys/Libs/ixemul030.trace Sys/Libs/ixemul030fpu.library Sys/Libs/ixemul030fpu.trace Sys/Libs/ixemul040.library Sys/Libs/ixemul040.trace Sys/Libs/ixemul040fpu.library Sys/Libs/ixemul040fpu.trace bin/ixconfig bin/ixtrace Once the manifests are set up, they can be used to automate the binary release packaging. What I will probably do initially is to set everything up so that only a single manifest file and archive are available. Then people that are interested in smaller archives can redo the manifest files and submit those changes to me. I'll then rerun the procedure that handles packaging the release archives. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 1 17:35:41 1995 Received: from DBSTU1.RZ.TU-BS.DE ([134.169.1.1]) by nic.funet.fi with SMTP id <89058-1>; Wed, 1 Nov 1995 17:33:29 +0200 Received: from rzrtr1.rz.tu-bs.de by DBSTU1.RZ.TU-BS.DE (IBM VM SMTP V2R2) with TCP; Wed, 01 Nov 95 16:33:24 MEZ Received: by rzrtr1.rz.tu-bs.de (AIX 4.1/UCB 5.64/4.03) id AA88626; Wed, 1 Nov 1995 16:33:14 +0100 From: y0000135@ws.rz.tu-bs.de (Sven Heithecker) Message-Id: <9511011533.AA88626@rzrtr1.rz.tu-bs.de> Subject: Re: FD2inline & lots of args To: amiga-gcc-port@nic.funet.fi (Sven Heithecker) Date: Wed, 1 Nov 1995 16:33:12 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1645 > > > Hi Kamil, > >The only function that I had problems with was indeed BltBitMap from >graphics.library and someone else made a bet with me (Jeroen ?) that it would >be the DoPkt(x) functions. I had also problems with RawDoFmt() and CreateObject(?, dont know correct function, but some like that) of the MUI package. >About the complexity of functions and nesting of blocks. It shouldn't be too >difficult to make up a small program which has some nesting of if/switch and >see what happens when those problem functions are used. The program doesn't >need to be runnable, it is only needed to test the compilers ability to store >registers in memory. > >My first thought when I got that error 'forbidden register spilled' was that >indeed the function was too complex. It has about 8-9 levels of if/else and >BltBitMap is used in one of the inner blocks. Removing levels didn't help at >all. I stopped trying after removing 4-5 levels. Well, I put RawDoFmt() into another function: before: void myfunction() { . . . RawDoFmt(...); . . } after: void EXRawDoFmt(...) { RawDoFmt(); } void myfunction { . . . EXRawDoFmt(); . . } Same register-spilled-problems when compiling. The MUI-function problem disappeared when using -O2 or -O3. I only do have these problems when compiling with -fbaserel. Seems that gcc uses one register as base-register and runs out of registers somehow. In my RawDoFmt() - function I had only 3 levels. The problem didn't disappear when removing all levels. ____ |_||_ Ceterum Censeo MEGAHARD Esse Delendam | | _| HTS Sven Heithecker s.heithecker@tu-bs.de From amiga-gcc-port-owner@nic.funet.fi Wed Nov 1 23:45:59 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89777-2>; Wed, 1 Nov 1995 23:40:26 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 1 Nov 95 22:40 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 1 Nov 95 22:37 MET Message-Id: Subject: problems with mit-asm To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 1 Nov 1995 22:37:54 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 832 hi, i am still on converting all the krm-examples for gcc. most programms where no problem, but some very ugly things are still there. namly most of the contributued asm sources heavy use of MACRO's make mot2mit nearly useless. i have for example this structure: structure base is a0 aptr one word two[20] word tre[32] i translated thise in to .set one,0 .set two,4 .lcomm _one,40 .set tre,44 .lcomm _tre,63 the elements can now be accesed via lea two(a0),a1 etc. i dont thing this is the right way but i cant find anything about these mit syntax and i am not sure what happens if i change the whole thing into C. i have the some problem with the printerdrivers. does someone have a gcccompileabel amigaprinterdriver ? walter -- ----- "`Eureka' is greek for `this bath is too hot'!" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Nov 2 14:03:37 1995 Received: from srv3.gbar.dtu.dk ([130.225.87.163]) by nic.funet.fi with ESMTP id <89621-4> convert rfc822-to-8bit; Thu, 2 Nov 1995 13:59:04 +0200 Received: by srv3.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 2 Nov 1995 12:58:57 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Corrected README Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT I have made an addition to the README, it is available as "http://srv2.gbar.dtu.dk:8001/Rask/README-2.7.1". Diff after my signature. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | *** README-2.7.1.gammel Thu Nov 2 12:56:39 1995 --- README-2.7.1 Thu Nov 2 12:56:45 1995 *************** *** 651,656 **** --- 651,661 ---- * And it's short! I was able to compile a 492 byte 'hello, world' using normal main. + [From an email from Matthias Scheler:] + [The options used were] + ['gcc -nostdlib -O3 -s -fbaserel nbcrt0.o helloworld.c libstubs.a'] + [(with the right path used for both the startup code and the library.] + * It uses OS 2.0 features whenever necessary. Note that you can develop AmigaDOS specific programs with ixemul.library, From amiga-gcc-port-owner@nic.funet.fi Thu Nov 2 15:52:06 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90769-2>; Thu, 2 Nov 1995 15:50:35 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HX66UIIWSW002RPB@NET2.WAU.NL>; Thu, 02 Nov 1995 14:53:30 +0000 (GMT) Received: by vines2.wau.nl; Thu, 2 Nov 95 14:50:07 +0100 Date: Thu, 02 Nov 1995 14:42:43 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Perl problem solved To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi, Well, subject says it all. Thanks guys for all the help on the Perl regexpression problems. It seems that there is a small bug in the current Perl which has been solved by the one who did the version on Aminet and by David, who is going to send patches to Fred :) I needed Perl for a makefile which does some clever substitution magic. I'm currently collecting Postscript related tools which are going to be released together with GS3.51 or shortly thereafter. Anyone having PS utils or pointers to it. I have quite a few but more is always better ;-) The GS maintainer is back from vacation and I'm just waiting for some fixes one of them being a fix to the time problem GS is currently having. Walter: Did you have any problems with the GS you got from me. Joop From amiga-gcc-port-owner@nic.funet.fi Fri Nov 3 11:34:29 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89287-4>; Fri, 3 Nov 1995 11:25:47 +0200 Received: from isis.u-strasbg.fr by funet.fi with SMTP (PP); Fri, 3 Nov 1995 11:25:32 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id KAA06886 for ; Fri, 3 Nov 1995 10:18:41 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA02662; Fri, 3 Nov 95 10:24:21 GMT Date: Fri, 3 Nov 95 10:24:21 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9511031024.AA02662@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: stdin (stdout) not a constant Hi, I have trouble compiling bibtex, because stdin and stdout are not constant with amiga gcc. I have this external declaration : FILE *standardinput = stdin; FILE *standardoutput = stdout; and gcc gives me an error : initializer not a constant. I have looked for the main() routine but couldn't find it :-( Could someone help me ?? \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Fri Nov 3 11:49:27 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <88971-2>; Fri, 3 Nov 1995 11:43:56 +0200 Received: from isis.u-strasbg.fr by funet.fi with SMTP (PP); Fri, 3 Nov 1995 11:43:43 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id JAA06590 for ; Fri, 3 Nov 1995 09:56:39 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA02565; Fri, 3 Nov 95 10:02:18 GMT Date: Fri, 3 Nov 95 10:02:18 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9511031002.AA02565@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: BUG: ln -s Hi, I found a bug with 'ln -s' from gcc263-utils (Aminet) + ixemul 41.4. Just try: ln -s /volume/dir1/file1 file2 then 'ls -l' give you something like : file2 -> /olume/dir1/file1 I try with different full path. The first char after the initial '/' is removed. \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Fri Nov 3 17:14:17 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90288-3>; Fri, 3 Nov 1995 17:11:04 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tBNn3-0004naC; Fri, 3 Nov 95 08:12 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: stdin (stdout) not a constant To: papier@indi1.u-strasbg.fr (Laurent Papier) Date: Fri, 3 Nov 1995 08:12:21 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9511031024.AA02662@indi1.u-strasbg.fr> from "Laurent Papier" at Nov 3, 95 10:24:21 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2387 > I have trouble compiling bibtex, because stdin and stdout are not > constant with amiga gcc. > > I have this external declaration : > FILE *standardinput = stdin; > FILE *standardoutput = stdout; > and gcc gives me an error : initializer not a constant. > > I have looked for the main() routine but couldn't find it :-( > Could someone help me ?? I also ran into this problem in the unixtex port on my FreshFish CDs and the source+diffs are on FF10. The diff file for that port is about a half megabyte, so I can't post it here. Here is an extract that deals specifically with this problem, but I don't know if it will help by itself. -Fred diff -rc --new-file unixtex-6.1b-base/web2c/lib/openinout.c unixtex-6.1b/web2c/lib/openinout.c *** unixtex-6.1b-base/web2c/lib/openinout.c Sun Apr 2 06:05:58 1995 --- unixtex-6.1b/web2c/lib/openinout.c Sun Apr 2 21:14:26 1995 *************** *** 8,15 **** #ifdef BibTeX /* See comments in bibtex.ch for why we need these. */ ! FILE *standardinput = stdin; ! FILE *standardoutput = stdout; /* Because we don't generate a .h file with all the global definitions for BibTeX, as we do with TeX and Metafont, we must declare these --- 8,15 ---- #ifdef BibTeX /* See comments in bibtex.ch for why we need these. */ ! FILE *standardinput /* = stdin */; ! FILE *standardoutput /* = stdout */; /* Because we don't generate a .h file with all the global definitions for BibTeX, as we do with TeX and Metafont, we must declare these diff -rc --new-file unixtex-6.1b-base/web2c/bibtex/Makefile.in unixtex-6.1b/web2c/bibtex/Makefile.in *** unixtex-6.1b-base/web2c/bibtex/Makefile.in Thu Feb 3 12:48:30 1994 --- unixtex-6.1b/web2c/bibtex/Makefile.in Sun Apr 2 21:43:26 1995 *************** *** 39,49 **** .SUFFIXES: .SUFFIXES: .o .c .p .ch .p.c: ! $(SHELL) $(srcdir)/../bibtex/convert $*.p $*.c .ch.p: ! ../web/tangle $*.web c$*.ch .c.o: ! $(CC) $(CPPFLAGS) $(CFLAGS) -c $*.c default: all --- 39,52 ---- .SUFFIXES: .SUFFIXES: .o .c .p .ch .p.c: ! $(SHELL) $(srcdir)/../bibtex/convert $< $*.tmp $(srcdir) ! sed "s:^void main_body() {:void main_body() { standardoutput = stdout; standardinput = stdin;:" <$*.tmp >$*.c .ch.p: ! ../web/tangle $(srcdir)/$*.web c$*.ch ! cp $(srcdir)/$*.p $*.p ! rm -f $(srcdir)/$*.p .c.o: ! $(CC) $(CPPFLAGS) $(CFLAGS) -c $< default: all From amiga-gcc-port-owner@nic.funet.fi Sat Nov 4 19:38:24 1995 Received: from sunmbx.netmbx.de ([192.76.152.9]) by nic.funet.fi with SMTP id <90100-2>; Sat, 4 Nov 1995 19:35:08 +0200 Received: by sunmbx.netmbx.de (/\==/\ Smail3.1.28.1) from tmpmbx.netmbx.de with smtp id ; Sat, 4 Nov 95 18:36 MET Received: by tmpmbx.netmbx.de (/\==/\ Smail3.1.28.1 #28.6) id ; Sat, 4 Nov 95 18:28 MET Received: from tbx by zelator.BerliNet.DE with bsmtp (Smail3.1.28.1 #11) id m0tBnQL-0003plC; Sat, 4 Nov 95 18:34 MET To: amiga-gcc-port@lists.funet.fi Message-Id: <48@bw01.bbrandes.berlinet.de> From: B.WINKELMANN@BBrandes.berlinet.de (Bert Winkelmann) Path: tbx.berlinet.de!bbrandes.berlinet.de!B.WINKELMANN Subject: Re: No stderr in Emacs with ixemul-41.4 Date: Sat, 04 Nov 1995 04:05:43 +0100 X-Mailer: UMSZer V2.22 public References: <199510311501.AA01640@diva.gmd.de> X-Gateway: ZCONNECT U2 zelator.BerliNet.DE [UNIX/Connect v0.71] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-VIA: 19951104000000W+1@BBrandes.berlinet.de Lines: 40 Joerg Hoehle writes: > It looks like some weird interaction between ixemul's handling of > "*|CONSOLE:", stderr, pr_ConsoleTask and FIFO:. I just undo the change "*"=>"CONSOLE:" in ixemul.library with a binary-editor and works fine now. I had believed "*" is equal to "CONSOLE:". btw: Can you or someone explain me, how to send a EOF to the -stream in a Emacs-shell-buffer. C-\ ('^\') isn't work. > All I found is that all C: commands would not output anything (in > call-process), whereas self-written ones (opening "*") and anything else > I tried would. I don't know what kind of black magic programs in > C: still do. BCPL is long gone (did I think). It works right for me with (call-process): --------------------------------------------------------------- (call-process "/c/version" nil t nil "c:version")version 40.1 0 --------------------------------------------------------------- But there is no output in an Emacs-shell-buffer for such Commands like /c/version, which using Output(dos). (No matter which ixemul-version.) #include int main (void) { FPuts (Output(), "I\'m invisible in Emacs\' shell-buffer\n"); return 0; } Bert. From amiga-gcc-port-owner@nic.funet.fi Sun Nov 5 01:38:23 1995 Received: from sunmbx.netmbx.de ([192.76.152.9]) by nic.funet.fi with SMTP id <89372-4>; Sun, 5 Nov 1995 01:32:51 +0200 Received: by sunmbx.netmbx.de (/\==/\ Smail3.1.28.1) from tmpmbx.netmbx.de with smtp id ; Sun, 5 Nov 95 00:33 MET Received: by tmpmbx.netmbx.de (/\==/\ Smail3.1.28.1 #28.6) id ; Sun, 5 Nov 95 00:25 MET Received: from tbx by zelator.BerliNet.DE with bsmtp (Smail3.1.28.1 #11) id m0tBsvW-0003s3C; Sun, 5 Nov 95 00:27 MET To: amiga-gcc-port@lists.funet.fi Message-Id: <48@bw01.bbrandes.berlinet.de> From: B.WINKELMANN@BBrandes.berlinet.de (Bert Winkelmann) Path: tbx.berlinet.de!bbrandes.berlinet.de!B.WINKELMANN Subject: Re: No stderr in Emacs with ixemul-41.4 Date: Sat, 04 Nov 1995 04:05:43 +0100 X-Mailer: UMSZer V2.22 public References: <199510311501.AA01640@diva.gmd.de> X-Gateway: ZCONNECT U2 zelator.BerliNet.DE [UNIX/Connect v0.71] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Z-VIA: 19951104000000W+1@BBrandes.berlinet.de Lines: 40 Joerg Hoehle writes: > It looks like some weird interaction between ixemul's handling of > "*|CONSOLE:", stderr, pr_ConsoleTask and FIFO:. I just undo the change "*"=>"CONSOLE:" in ixemul.library with a binary-editor and works fine now. I had believed "*" is equal to "CONSOLE:". btw: Can you or someone explain me, how to send a EOF to the -stream in a Emacs-shell-buffer. C-\ ('^\') isn't work. > All I found is that all C: commands would not output anything (in > call-process), whereas self-written ones (opening "*") and anything else > I tried would. I don't know what kind of black magic programs in > C: still do. BCPL is long gone (did I think). It works right for me with (call-process): --------------------------------------------------------------- (call-process "/c/version" nil t nil "c:version")version 40.1 0 --------------------------------------------------------------- But there is no output in an Emacs-shell-buffer for such Commands like /c/version, which using Output(dos). (No matter which ixemul-version.) #include int main (void) { FPuts (Output(), "I\'m invisible in Emacs\' shell-buffer\n"); return 0; } Bert. From amiga-gcc-port-owner@nic.funet.fi Mon Nov 6 18:11:40 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <90391-3>; Mon, 6 Nov 1995 17:46:03 +0200 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt; (5.65v3.0/1.1.8.2/24Jul95-0207PM) id AA06692; Mon, 6 Nov 1995 16:44:56 GMT Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/08Aug95-1153AM) id AA13269; Mon, 6 Nov 1995 16:45:44 GMT Date: Mon, 6 Nov 1995 16:45:43 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Amiga X11 mailling list Cc: Amiga GCC Mailling list Subject: Optimized X11R6 libs available Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Just a small note to say that I've replaced the X11R6 pack for a optimized one (-O). It is significantly smaller and quite faster! Unload it! In case you lost it: http://hidro1.ist.utl.pt/amiga/amiga.html - Pedro Miguel Teixeira - From amiga-gcc-port-owner@nic.funet.fi Mon Nov 6 23:26:10 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89943-4>; Mon, 6 Nov 1995 23:25:06 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 6 Nov 95 22:24 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 6 Nov 95 22:23 MET Message-Id: Subject: ways to get an env variable To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 6 Nov 1995 22:23:38 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1375 joop told me that he has problems getting envvars. so i looked at my book and found 3 ways getting them. beside that i found that echo has a problem with var that contain an '_'. e.g.: $setenv gs_lib=hallo $echo $gs_lib $ $echo ${gs_lib} $ hallo is this only a 2.x problem ? for anyone who likes to check all possible ways here are an .lha. it compiles without any known problems (for me) gcc with ix40.3. begin 644 env.lha M'N\M;&@U+3P" !H!0 4*QF'P "&5N=FER;RYCGI8!_V*[T;3E?FO? '_5 MV"2M+5KX]=,#@14*.!37P[(O6S^2<:7NIW=;5$OQN__G2RU5WEVP[!O/KP[J MTU'?N6?6H?;8%]%^R*<>KW!]"G 7XD)1S,!BR@B$JIIA:*WAJ3W@]@3B\@5* MG/!DP"O3>#2EKK*-DT/,PT0<(YG&2R"1'.UF2D#R65IPO) !0*LTE"B!AE3H<5''+0P/:<<[_G: MHE_VF![2L27N!GW_%$G=V;:/XT:R@+82>7.$7'T\O-'MXX#O9H(BN'#36$KH M@CRW:BO\S&@FFDJJ2&O6/-"-Y2\M.B40 M^#GRJ9>H^)0Y1F4L0Q\G3U<_SZ XC#3;/:23A1NP,\OK"7"%SU^OHS)4N)+9 M\MTOYINEQCGC0?"IP\*,M"6A<.5]>O9ZF#/U\$6C$*PHM$UXE2<&&J4KK#V2 M!T?3%BPJW]^-%HA%7-,T5OW.^R[=VL-&1G6C6C>%99'>C=P?EN[6]@#^-ST; MOZ;&YE#W/%JPA/-UJ:Q?FXC@UN6* >/@_;JK'>KM+MO_.[B_KNW;^[,?BS;' MWGF >A19=58\"MRGEE1XB*]WO/<[L,D5" ]]_':#=9;,IN3HQX^/I"WR]79B MY_E;__/D(&=[;MR"KBCP@@NE)H@B*-)7%A8XPC"2&,,8(M;N<:E9,>U)\]UC 43[4I B end -- ----- "Keep calm, Sarah! Whatever you do... Oh! You *are* calm!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 10:53:39 1995 Received: from dfunms.rus.uni-stuttgart.de ([129.69.1.162]) by nic.funet.fi with SMTP id <89053-1>; Tue, 7 Nov 1995 10:51:32 +0200 Received: from ifr1.luftfahrt.uni-stuttgart.de by dfunms.rus.uni-stuttgart.de with SMTP id AA11777 (5.65c8/DFUE-M1.0 for ); Tue, 7 Nov 1995 09:51:22 +0100 Received: from ifr15 by ifr1.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-1.0NeXT+) id AA00316; Tue, 7 Nov 95 09:51:19 +0100 Message-Id: <9511070851.AA00316@ifr1.Luftfahrt.Uni-Stuttgart.DE> Received: by ifr15.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-S1.0NeXT+) id AA01531; Tue, 7 Nov 95 09:51:17 +0100 Date: Tue, 7 Nov 95 09:51:17 +0100 From: raimund@ifr.luftfahrt.uni-stuttgart.de Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: amiga-gcc-port@nic.funet.fi Subject: problems with gnatmake Hi, did anybody try to compile something with the gnatmake utility from FreshFish 10 CD? I tried it and it seems that gnatmake is writing everything to stderr and not to a file!? Did anybody else observe this behaviour? I am using gnat2.06/ixemul41.2 from FreshFishCD 10. Thanks Raimund From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 11:24:54 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <90046-1> convert rfc822-to-8bit; Tue, 7 Nov 1995 11:23:32 +0200 Received: by tycho.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 7 Nov 1995 10:23:08 +0100 (MET) From: Rask Lambertsen To: Fred Fish Cc: Peter Ivimey-Cook , Amiga GCC mailing list Subject: Re: packaging of releases In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 1 Nov 1995, Fred Fish wrote: > > > a given number of bytes. Then the issue is simply whether to put all > > > those bytes in one archive or split them into smaller pieces. Splitting > > > only make sense if you are on an unstable link and don't want to have > > > to restart the download from the beginning if it dies. Then you have the > > > > I disagree... splitting things (sensibly) allows people who can happily > > do without sections of archive to do so. > > We seem to have different definitions for "splitting". The way I was using > it was that I have some archive of N bytes, say foo.lha, and want it to > be available in smaller pieces, so I run a program that chops it up into > M pieces, where each piece (except possibly the last) is N/M bytes. > I.E: [snip] If you are going to do so, I suggest splitting into 713 kB pieces as they will then fit onto a DD MSDOS floppy. For many people, this is the only way to get their stuff into the Amiga. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 19:38:05 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89946-4>; Tue, 7 Nov 1995 19:34:15 +0200 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tCs64-000RLPC; Tue, 7 Nov 95 18:46 MET Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0tCaDQ-000G3oC; Mon, 6 Nov 95 23:40 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0aa1@wyst.hobby.nl>; Mon, 6 Nov 95 19:59:34 CET Message-Id: <9511061859.0aa1@wyst.hobby.nl> Date: Mon, 6 Nov 1995 18:59:32 +0000 (CET) In-Reply-To: <9511031002.AA02565@indi1.u-strasbg.fr> from "Laurent Papier" at Nov 3, 95 10:02:18 am Content-Type: text Content-Length: 856 From: hans@wyst.hobby.nl (Hans Verkuil) To: papier@indi1.u-strasbg.fr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: BUG: ln -s Hi Laurent, > I found a bug with 'ln -s' from gcc263-utils (Aminet) + ixemul 41.4. > > Just try: > ln -s /volume/dir1/file1 file2 > then 'ls -l' give you something like : > file2 -> /olume/dir1/file1 > > I try with different full path. > The first char after the initial '/' is removed. Thanks for the bug report, amazing that no one noticed before. I fixed it in my version (I wrote the bug, so I guess I'm the right person to fix it. A very stupid bug it was, too :-( ). If anyone needs the patch to symlink.c in a hurry, they can email me. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 19:53:01 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90049-2>; Tue, 7 Nov 1995 19:52:19 +0200 Received: from carina.rz.Uni-Osnabrueck.DE by funet.fi with SMTP (PP); Tue, 7 Nov 1995 19:52:04 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id SAA25252 for ; Tue, 7 Nov 1995 18:51:33 +0100 From: Thomas Radtke Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.7.1/8.7.1) id SAA16964 for amiga-gcc-port@lists.funet.fi; Tue, 7 Nov 1995 18:51:33 +0100 Message-Id: <199511071751.SAA16964@nereid.rz.Uni-Osnabrueck.DE> Subject: gets() To: amiga-gcc-port@nic.funet.fi Date: Tue, 7 Nov 1995 18:51:33 +0100 (NFT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit /* Hi, just want to know why libnix' gets() function doesn't return a NULL-pointer when receiving EOF. Is there a good reason for this or is the problem my poor knowlege in the handling of the static libraries ? I compiled the code below with gcc test.c (this works for me, that is, exits on EOF) gcc -noixemul test.c (on EOF you must break the code yourself) I'm using Aminet version of gcc 2.7.0, ixemul 41.4, libnix 1.0 Thomas test.c: */ #include main() { char s[256]; int test; while (test=(int)gets(s)) { printf("%s\n",s); } printf("test=%d\n",test); } From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 20:45:20 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90025-4>; Tue, 7 Nov 1995 20:44:41 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id SAA12411; Tue, 7 Nov 1995 18:42:57 GMT From: Lars Hecking Message-Id: <199511071843.SAA05310@mostar.nmrc.ucc.ie> Subject: Re: gets() To: Thomas.Radtke@rz.Uni-Osnabrueck.DE (Thomas Radtke) Date: Tue, 7 Nov 1995 18:43:36 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199511071751.SAA16964@nereid.rz.Uni-Osnabrueck.DE> from "Thomas Radtke" at Nov 7, 95 06:51:33 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 105 > just want to know why libnix' gets() function doesn't return a One shouldn't use gets() anyway. From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 21:04:28 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <89172-4>; Tue, 7 Nov 1995 21:03:46 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id OAA10314; Tue, 7 Nov 1995 14:02:48 -0500 (from cz253) Message-Id: <199511071902.OAA10314@kanga.INS.CWRU.Edu> Date: Tue, 7 Nov 1995 14:02:48 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: Specs file... Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Where is the documentation to the specs file? I've grep'd every doc file I have to no avail. :( Thanks in advance. .....Dave From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 21:17:45 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <88985-1>; Tue, 7 Nov 1995 21:17:10 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id OAA14829; Tue, 7 Nov 1995 14:16:52 -0500 (from cz253) Message-Id: <199511071916.OAA14829@kanga.INS.CWRU.Edu> Date: Tue, 7 Nov 1995 14:16:52 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: cat and tar problem... Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Has anyone had the following work for them? cat *.tar.gz | tar zvtf - If so what versions of 'cat', 'tar', and 'sh' were/are you using? I have gotten the above to work in a slightly different fashion: cat *.tar.gz | gzip -cd | tar vtf - Side Query: Why would any one want to do: cat *.tar.gz | tar zvtf - Anyways? When all you have to do is: tar zvtf *.tar.gz Am asking these questions since I noticed the bug report, and the report is definitely valid. But avoiding the problem is easier than fixing it, for me that is. .....Dave From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 21:24:01 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89917-3> convert rfc822-to-8bit; Tue, 7 Nov 1995 21:23:41 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 7 Nov 1995 20:23:17 +0100 (MET) From: Rask Lambertsen To: David Zaroski Cc: amiga-gcc-port@nic.funet.fi Subject: Re: cat and tar problem... In-Reply-To: <199511071916.OAA14829@kanga.INS.CWRU.Edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 7 Nov 1995, David Zaroski wrote: > Side Query: Why would any one want to do: > > cat *.tar.gz | tar zvtf - > > Anyways? It's quicker to type. Btw, using the -z option of tar allows one to use multivolume archives (if tar would actually work with Dev-Handler and the likes). Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 21:37:34 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89357-4>; Tue, 7 Nov 1995 21:36:54 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA21226 (5.65c8/IDA-1.4.4 for ); Tue, 7 Nov 1995 20:36:27 +0100 Received: by diva.gmd.de id AA03598 (5.67b8/IDA-1.5); Tue, 7 Nov 1995 20:33:11 +0100 Date: Tue, 7 Nov 1995 20:33:11 +0100 From: Joerg Hoehle Message-Id: <199511071933.AA03598@diva.gmd.de> To: amiga-gcc-port@nic.funet.fi, cz253@cleveland.freenet.edu Subject: Re: cat and tar problem... Hi, Dave wrote: > Side Query: Why would any one want to do: > > cat *.tar.gz | tar zvtf - > When all you have to do is: > > tar zvtf *.tar.gz > Am asking these questions since I noticed the bug report, and the report is > definitely valid. But avoiding the problem is easier than fixing it, for me > that is. The report is there because there's a bug. There are many more ways to show the bug than the above, but it's how it appeared first. So it's in the report this way. Thanks for reminding people a way to protect themselves from that one symptom. Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 21:39:30 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89716-4>; Tue, 7 Nov 1995 21:39:10 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id TAA13377; Tue, 7 Nov 1995 19:35:44 GMT From: Lars Hecking Message-Id: <199511071936.TAA05376@mostar.nmrc.ucc.ie> Subject: Re: Specs file... To: cz253@cleveland.Freenet.Edu Date: Tue, 7 Nov 1995 19:36:25 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199511071902.OAA10314@kanga.INS.CWRU.Edu> from "David Zaroski" at Nov 7, 95 02:02:48 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 215 > > Where is the documentation to the specs file? I've grep'd every doc file I > have to no avail. :( Thanks in advance. Check gcc.c from the FSF gcc distrib. Email me if you don't have the source handy ;) -l From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 21:41:18 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <89224-2>; Tue, 7 Nov 1995 21:40:59 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id OAA23754; Tue, 7 Nov 1995 14:40:36 -0500 (from cz253) Message-Id: <199511071940.OAA23754@kanga.INS.CWRU.Edu> Date: Tue, 7 Nov 1995 14:40:36 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: gc948374@gbar.dtu.dk Subject: Re: cat and tar problem... Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from gc948374@gbar.dtu.dk of Tue, 07 Nov > >On Tue, 7 Nov 1995, David Zaroski wrote: > >> Side Query: Why would any one want to do: >>=20 >> =09cat *.tar.gz | tar zvtf - >>=20 >> Anyways? > >It's quicker to type. ??? The above line has 8 more characters in it. I seriously hope you are joking. ;-) > >Btw, using the -z option of tar allows one to use multivolume archives=20 >(if tar would actually work with Dev-Handler and the likes). Not following you here. 'tar --help' yields: -z, --gzip, --ungzip filter the archive through gzip .....Dave From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 21:45:29 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89417-3> convert rfc822-to-8bit; Tue, 7 Nov 1995 21:45:03 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 7 Nov 1995 20:44:31 +0100 (MET) From: Rask Lambertsen To: David Zaroski Cc: amiga-gcc-port@nic.funet.fi Subject: Re: cat and tar problem... In-Reply-To: <199511071940.OAA23754@kanga.INS.CWRU.Edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 7 Nov 1995, David Zaroski wrote: > Reply to message from gc948374@gbar.dtu.dk of Tue, 07 Nov > > > >On Tue, 7 Nov 1995, David Zaroski wrote: > > > >> Side Query: Why would any one want to do: > >>=20 > >> =09cat *.tar.gz | tar zvtf - > >>=20 > >> Anyways? > > > >It's quicker to type. > > ??? The above line has 8 more characters in it. I seriously hope you are > joking. ;-) Quicker than cat *.tar.gz | gzip -cd | tar zvtf - which works fine. > >Btw, using the -z option of tar allows one to use multivolume archives=20 > >(if tar would actually work with Dev-Handler and the likes). > > Not following you here. 'tar --help' yields: > > -z, --gzip, --ungzip filter the archive through gzip OK, I forgot the word "compressed" above. "multivolume" -> "compressed multivolume". Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 21:55:06 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <89899-1>; Tue, 7 Nov 1995 21:53:58 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id OAA26511; Tue, 7 Nov 1995 14:47:58 -0500 (from cz253) Message-Id: <199511071947.OAA26511@kanga.INS.CWRU.Edu> Date: Tue, 7 Nov 1995 14:47:58 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: hoehle@zeus.gmd.de Subject: Re: cat and tar problem... Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from hoehle@zeus.gmd.de of Tue, 07 Nov > >Hi, > >Dave wrote: >> Side Query: Why would any one want to do: >> >> cat *.tar.gz | tar zvtf - > >> When all you have to do is: >> >> tar zvtf *.tar.gz > >> Am asking these questions since I noticed the bug report, and the report is >> definitely valid. But avoiding the problem is easier than fixing it, for me >> that is. > >The report is there because there's a bug. There are many more ways to >show the bug than the above, but it's how it appeared first. So it's in Yeah it's a bug alright. Am having a fun time trying to squash it. :( Since I have been trying to track this bugger down, please send me all the ways that this bug has appeared. It will help in tracking it down. >the report this way. Thanks for reminding people a way to protect >themselves from that one symptom. No problem. .....Dave From amiga-gcc-port-owner@nic.funet.fi Tue Nov 7 22:50:24 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <89475-1>; Tue, 7 Nov 1995 22:49:44 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id PAA17021; Tue, 7 Nov 1995 15:49:14 -0500 (from cz253) Message-Id: <199511072049.PAA17021@kanga.INS.CWRU.Edu> Date: Tue, 7 Nov 1995 15:49:14 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: gc948374@gbar.dtu.dk Subject: Re: cat and tar problem... Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from gc948374@gbar.dtu.dk of Tue, 07 Nov > >On Tue, 7 Nov 1995, David Zaroski wrote: > >> Reply to message from gc948374@gbar.dtu.dk of Tue, 07 Nov >> > >> >On Tue, 7 Nov 1995, David Zaroski wrote: >> > >> >> Side Query: Why would any one want to do: >> >>=3D20 >> >> =3D09cat *.tar.gz | tar zvtf - >> >>=3D20 >> >> Anyways? >> > >> >It's quicker to type. >>=20 >> ??? The above line has 8 more characters in it. I seriously hope you are >> joking. ;-) > >Quicker than > >cat *.tar.gz | gzip -cd | tar zvtf - > >which works fine. But, not quicker than 'tar zvtf *.tar.gz'! My question still stands, why would anyone use cat to feed tar, when tar knows very well how to feed itself, in the above context of course? Granted, the bug is definitely there, and I'm trying to locate it, so it can be squashed. .....Dave From amiga-gcc-port-owner@nic.funet.fi Wed Nov 8 04:26:36 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90356-3>; Wed, 8 Nov 1995 04:25:25 +0200 Received: from carina.rz.Uni-Osnabrueck.DE by funet.fi with SMTP (PP); Wed, 8 Nov 1995 04:25:18 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id DAA12646; Wed, 8 Nov 1995 03:25:13 +0100 From: Thomas Radtke Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.7.1/8.7.1) id DAA12632; Wed, 8 Nov 1995 03:25:12 +0100 Message-Id: <199511080225.DAA12632@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: gets() To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Wed, 8 Nov 1995 03:25:12 +0100 (NFT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511071843.SAA05310@mostar.nmrc.ucc.ie> from "Lars Hecking" at Nov 7, 95 06:43:36 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > > just want to know why libnix' gets() function doesn't return a > > One shouldn't use gets() anyway. > > Ok then, lets scratch it from the gcc distribution and define a new standard. Ha ! ;) Thomas From amiga-gcc-port-owner@nic.funet.fi Wed Nov 8 12:16:01 1995 Received: from gilbert.ucc.hull.ac.uk ([150.237.128.199]) by nic.funet.fi with ESMTP id <90565-2>; Wed, 8 Nov 1995 12:14:46 +0200 Received: from humus.ucc.hull.ac.uk (actually host adelphi.ucc.hull.ac.uk) by gilbert.ucc.hull.ac.uk with SMTP local (PP); Wed, 8 Nov 1995 10:14:05 +0000 Received: from humus.hull.ac.uk (actually host allott.ucc.hull.ac.uk) by adelphi.ucc.hull.ac.uk with SMTP (PP); Wed, 8 Nov 1995 10:13:46 +0000 Date: Wed, 8 Nov 1995 10:13:42 +0000 (GMT) From: "C.Jackson" X-Sender: cs7cj1@allott Reply-To: C.Jackson@computer-science.hull.ac.uk To: amiga-gcc-port@lists.funet.fi Subject: Commodore Includes Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello to all on the list! I am new to C and this list, and so have a trivial question to you all, where do I get the Commodore Include files from? I presume since commodore don`t exist no more I can`t send off to them! Is there anywhere else I can get them from? <: C.Jackson@dcs.hull.ac.uk :> From amiga-gcc-port-owner@nic.funet.fi Wed Nov 8 12:59:26 1995 Received: from loki.cee.hw.ac.uk ([137.195.24.101]) by nic.funet.fi with SMTP id <89959-3>; Wed, 8 Nov 1995 12:58:15 +0200 Received: from venus.cee.hw.ac.uk by loki.cee.hw.ac.uk with smtp tap_id root (Smail3.1.28.1 #97) id m0tD8CT-000eH9C; Wed, 8 Nov 95 10:57 GMT Received: by venus.cee.hw.ac.uk (Smail3.1.28.1 #96) id m0tD8CN-0001qJC; Wed, 8 Nov 95 10:57 GMT Date: Wed, 8 Nov 1995 10:57:41 +0000 (GMT) From: Erik Kotlar Johannessen X-Sender: ceeekj@venus To: Thomas Radtke cc: amiga-gcc-port@nic.funet.fi Subject: Re: gets() In-Reply-To: <199511071751.SAA16964@nereid.rz.Uni-Osnabrueck.DE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 7 Nov 1995, Thomas Radtke wrote: > just want to know why libnix' gets() function doesn't return a > NULL-pointer when receiving EOF. Is there a good reason for this I think Fred Fish posted a patch for this a few months ago. Take a look in the amiga-gcc-port archives on ftp.funet.fi. There`s also another bug in libnix. The strtoul function will accept (and convert) character which is outside the range for the specified base. I sent a patch for this to the libnix maintainers a few months ago. I guess they haven`t received enough bugreports/fixes to release a new version yet. btw. someone (vinsci) I think it would be a good idea to split the mailing-list archive on funet. ie one file for each month. The archive for 1995 is now about 5MB in size. -Erik -- Erik Johannessen - ceeekj@cee.hw.ac.uk http://www.cee.hw.ac.uk./~ceeekj/ From amiga-gcc-port-owner@nic.funet.fi Wed Nov 8 13:24:07 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90313-1>; Wed, 8 Nov 1995 13:23:30 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id LAA23802 for ; Wed, 8 Nov 1995 11:21:54 GMT From: Lars Hecking Message-Id: <199511081122.LAA06011@mostar.nmrc.ucc.ie> Subject: Re: gets() To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Wed, 8 Nov 1995 11:22:36 +0000 (GMT) In-Reply-To: <199511080225.DAA12632@nereid.rz.Uni-Osnabrueck.DE> from "Thomas Radtke" at Nov 8, 95 03:25:12 am Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 291 > > > > > just want to know why libnix' gets() function doesn't return a > > > > One shouldn't use gets() anyway. > > > > > Ok then, lets scratch it from the gcc distribution and define a > new standard. Ha ! ;) Or check out the stdio section in the c.l.c FAQ first ]B=8} -l From amiga-gcc-port-owner@nic.funet.fi Wed Nov 8 18:33:37 1995 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with SMTP id <90782-1>; Wed, 8 Nov 1995 18:28:17 +0200 Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.6.12/8.6.4) with ESMTP id SAA17901; Wed, 8 Nov 1995 18:28:11 +0200 Received: (will@localhost) by katiska.clinet.fi (8.6.12/8.6.4) id SAA10347; Wed, 8 Nov 1995 18:28:09 +0200 Date: Wed, 8 Nov 1995 18:28:09 +0200 Message-Id: <199511081628.SAA10347@katiska.clinet.fi> From: Ville-Pertti Keinonen To: cz253@cleveland.Freenet.Edu CC: amiga-gcc-port@nic.funet.fi In-reply-to: <199511071916.OAA14829@kanga.INS.CWRU.Edu> (cz253@cleveland.Freenet.Edu) Subject: Re: cat and tar problem... Has anyone had the following work for them? cat *.tar.gz | tar zvtf - You could easily use the following instead: $ zcat *.tar.gz | tar tvf - (AFAIK, the Amiga version of tar has never had a functional z-option) I have gotten the above to work in a slightly different fashion: cat *.tar.gz | gzip -cd | tar vtf - Side Query: Why would any one want to do: cat *.tar.gz | tar zvtf - Anyways? When all you have to do is: tar zvtf *.tar.gz Actually, I don't think either would work (especially the latter, since the second .tar.gz-file would expand to become a specification of the file to list, only the first one would be an argument to the f option) if you had several *.tar.gz files. However, if you want to do something to .tar.gz-archives that have been split into parts (such as the NetBSD distributions), the cat form is useful. (And the only one that will work properly) From amiga-gcc-port-owner@nic.funet.fi Thu Nov 9 01:40:43 1995 Received: from nextsun.INS.CWRU.Edu ([129.22.8.51]) by nic.funet.fi with ESMTP id <89048-2>; Thu, 9 Nov 1995 01:39:39 +0200 Received: (cz253@localhost) by nextsun.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-freenet) id SAA02151; Wed, 8 Nov 1995 18:39:30 -0500 (from cz253) Message-Id: <199511082339.SAA02151@nextsun.INS.CWRU.Edu> Date: Wed, 8 Nov 1995 18:39:30 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: Pipes... Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Is 'sh' creating it's own pipes? I purposely left ixpipe and pipe unmounted, and yet when in 'sh', and I do : ls | cat | sort | cat There are no error messages, and the work gets done. [puzzled] .....Dave From amiga-gcc-port-owner@nic.funet.fi Thu Nov 9 09:54:52 1995 Received: from lillep.gbar.dtu.dk ([130.225.87.179]) by nic.funet.fi with ESMTP id <89778-4> convert rfc822-to-8bit; Thu, 9 Nov 1995 09:53:25 +0200 Received: by lillep.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 9 Nov 1995 08:53:06 +0100 (MET) From: Rask Lambertsen To: "C.Jackson" Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Commodore Includes In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 8 Nov 1995, C.Jackson wrote: > Hello to all on the list! > > I am new to C and this list, and so have a trivial question to you all, > where do I get the Commodore Include files from? I presume since > commodore don`t exist no more I can`t send off to them! Is there anywhere > else I can get them from? Look at "http://srv2.gbar.dtu.dk:8001/Rask/Amiga.html", there you'll find links to the includes. They are also available on some CD's (Fred Fish and maybe Meeting Pearls). You can also order the Developer kit from ??? (I don't know the address, but is in the FAQ). Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Nov 9 14:22:39 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90205-2>; Thu, 9 Nov 1995 14:19:28 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HXFVPEGJY8006D2V@NET2.WAU.NL>; Thu, 09 Nov 1995 13:22:44 +0000 (GMT) Received: by vines2.wau.nl; Thu, 9 Nov 95 13:19:21 +0100 Date: Thu, 09 Nov 1995 12:25:49 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Startup code question To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hello, This is going to be a question which probably doesn't belong here but here it goes anyway. I'm trying to compile the following piece of code (at the end) which is written for SAS/C but I'm using GCC 2.7.0 to compile this. Compiling is fine but during linking I get the following unresolved errors: __WBenchMsg ___base ___stack. 1) Am I correct that __WbenchMsg is the WBStartup message which is processed in the startup code. If so why do I get the unresolved error. Linking is done with crt.o Had a quick look at crt.s and it seems there is little or no parsing of WBStartup, maybe the symbol is not exported, didn't check that. 2) This is for the die hard SAS/C users who also happen to use GCC ;) What is __base pointing at and how do I make a GCC compatible one? 3) __stack is the runtime stack setting and also available for ixemul/Libnix no real problem here. Please CC me if you send a reply to the list, thanks Any help is greatly appreciated, Joop ptr_t GC_get_stack_base() { extern struct WBStartup *_WBenchMsg; extern long __base; extern long __stack; struct Task *task; struct Process *proc; struct CommandLineInterface *cli; long size; if ((task = FindTask(0)) == 0) { GC_err_puts("Cannot find own task structure\n"); ABORT("task missing"); } proc = (struct Process *)task; cli = BADDR(proc->pr_CLI); if (_WBenchMsg != 0 || cli == 0) { size = (char *)task->tc_SPUpper - (char *)task->tc_SPLower; } else { size = cli->cli_DefaultStack * 4; } return (ptr_t)(__base + GC_max(size, __stack)); } From amiga-gcc-port-owner@nic.funet.fi Thu Nov 9 14:51:01 1995 Received: from lillep.gbar.dtu.dk ([130.225.87.179]) by nic.funet.fi with ESMTP id <90144-2> convert rfc822-to-8bit; Thu, 9 Nov 1995 14:50:05 +0200 Received: by lillep.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 9 Nov 1995 13:49:37 +0100 (MET) From: Rask Lambertsen To: joop van de wege Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Startup code question In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 9 Nov 1995, joop van de wege wrote: > Hello, > > This is going to be a question which probably doesn't belong here but here it > goes anyway. > I'm trying to compile the following piece of code (at the end) which is > written for SAS/C but I'm using GCC 2.7.0 to compile this. Compiling is fine > but during linking I get the following unresolved errors: > __WBenchMsg > ___base > ___stack. > > 1) Am I correct that __WbenchMsg is the WBStartup message which is processed > in the startup code. If so why do I get the unresolved error. Linking is > done with crt.o > Had a quick look at crt.s and it seems there is little or no parsing of > WBStartup, maybe the symbol is not exported, didn't check that. How startup code deals with the WBStartup Message is different between compilers. But I think libnix does it in a SAS/C compatible manner, so try compiling with -libnix Often, the WBStartup message is passed like int main (int argc, char *argv[]) { /* Substitute with the real structure name */ struct WBStartup WBMessage; if (argc == 0) { WBMessage = (struct WBStartup *) argv; /* ... /* } else { /* CLI start, standard C arguments in argc and argv */ /* ... */ } return (0) } Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Nov 9 16:26:18 1995 Received: from gilbert.ucc.hull.ac.uk ([150.237.128.199]) by nic.funet.fi with ESMTP id <89453-2> convert rfc822-to-8bit; Thu, 9 Nov 1995 16:25:04 +0200 Received: from humus.ucc.hull.ac.uk (actually host adelphi.ucc.hull.ac.uk) by gilbert.ucc.hull.ac.uk with SMTP local (PP); Thu, 9 Nov 1995 14:24:11 +0000 Received: from humus.hull.ac.uk (actually host marsh.ucc.hull.ac.uk) by adelphi.ucc.hull.ac.uk with SMTP (PP); Thu, 9 Nov 1995 14:23:53 +0000 Date: Thu, 9 Nov 1995 14:23:42 +0000 (GMT) From: "C.Jackson" X-Sender: cs7cj1@marsh Reply-To: C.Jackson@computer-science.hull.ac.uk To: amiga-gcc-port@nic.funet.fi Subject: Re: Commodore Includes In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 9 Nov 1995, Rask Lambertsen wrote: > On Wed, 8 Nov 1995, C.Jackson wrote: > > > Hello to all on the list! > > > > I am new to C and this list, and so have a trivial question to you all, > > where do I get the Commodore Include files from? I presume since > > commodore don`t exist no more I can`t send off to them! Is there anywhere > > else I can get them from? > > Look at "http://srv2.gbar.dtu.dk:8001/Rask/Amiga.html", there you'll find > links to the includes. They are also available on some CD's (Fred Fish > and maybe Meeting Pearls). You can also order the Developer kit from ??? > (I don't know the address, but is in the FAQ). > > Regards, Many Thanks! Regards, <: C.Jackson@dcs.hull.ac.uk :> > > /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ > | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | > | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | > | Keyboard error: and are stuck - press to continue | > From amiga-gcc-port-owner@nic.funet.fi Thu Nov 9 17:25:10 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90598-4>; Thu, 9 Nov 1995 17:23:31 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA05355 (5.65c8/IDA-1.4.4 for ); Thu, 9 Nov 1995 16:21:33 +0100 Received: by diva.gmd.de with UUCP id AA04255 (5.67b8/IDA-1.5); Thu, 9 Nov 1995 16:18:25 +0100 Date: Thu, 9 Nov 1995 16:18:25 +0100 Message-Id: <199511091518.AA04255@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: cz253@cleveland.freenet.edu (David Zaroski) Cc: amiga-gcc-port@nic.funet.fi Subject: Pipes... In-Reply-To: <199511082339.SAA02151@nextsun.INS.CWRU.Edu> References: <199511082339.SAA02151@nextsun.INS.CWRU.Edu> David Zaroski writes: > Is 'sh' creating it's own pipes? I purposely left ixpipe and pipe > ls | cat | sort | cat > There are no error messages, and the work gets done. [puzzled] Look at the ixemul source, popen() or some such and you'll see that ixemul.library has internal support for "pipes", e.g. a special file type that doesn't go through IXPIPE: or anything. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Thu Nov 9 17:30:35 1995 Received: from srv3.gbar.dtu.dk ([130.225.87.163]) by nic.funet.fi with ESMTP id <90831-4> convert rfc822-to-8bit; Thu, 9 Nov 1995 17:29:29 +0200 Received: by srv3.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 9 Nov 1995 16:27:32 +0100 (MET) From: Rask Lambertsen To: Joerg Hoehle Cc: David Zaroski , amiga-gcc-port@nic.funet.fi Subject: Re: Pipes... In-Reply-To: <199511091518.AA04255@diva.gmd.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 9 Nov 1995, Joerg Hoehle wrote: > David Zaroski writes: > > Is 'sh' creating it's own pipes? I purposely left ixpipe and pipe > > ls | cat | sort | cat > > There are no error messages, and the work gets done. [puzzled] > > Look at the ixemul source, popen() or some such and you'll see that > ixemul.library has internal support for "pipes", e.g. a special file > type that doesn't go through IXPIPE: or anything. Then what is IXPIPE: for anyway? I think I read somewhere in the IXPIPE: source that only ixemul.library is allowed to use it. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Nov 9 17:34:59 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90025-3>; Thu, 9 Nov 1995 17:34:30 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA06491 (5.65c8/IDA-1.4.4 for ); Thu, 9 Nov 1995 16:34:10 +0100 Received: by diva.gmd.de with UUCP id AA04277 (5.67b8/IDA-1.5); Thu, 9 Nov 1995 16:31:06 +0100 Date: Thu, 9 Nov 1995 16:31:06 +0100 Message-Id: <199511091531.AA04277@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: B.WINKELMANN@bbrandes.berlinet.de (Bert Winkelmann) Cc: amiga-gcc-port@nic.funet.fi Subject: Re: No stderr in Emacs with ixemul-41.4 In-Reply-To: <48@bw01.bbrandes.berlinet.de> References: <199510311501.AA01640@diva.gmd.de> <48@bw01.bbrandes.berlinet.de> Bert Winkelmann writes: > I just undo the change "*"=>"CONSOLE:" in ixemul.library with a > binary-editor and works fine now. I had believed "*" is equal > to "CONSOLE:". So far for the rumors that they are the same at any level... > btw: Can you or someone explain me, how to send a EOF to the > -stream in a Emacs-shell-buffer. C-\ ('^\') isn't work. M-x shell-send-eof, M-x comint-delchar-or-maybe-eof or M-x comint-send-eof usually bonud to C-c C-d or C-c d. > It works right for me with (call-process): I've to find my old list where I tested all cases... What version of Emacs are you using? Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Thu Nov 9 17:57:45 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90476-2>; Thu, 9 Nov 1995 17:57:11 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id PAA22620; Thu, 9 Nov 1995 15:55:28 GMT From: Lars Hecking Message-Id: <199511091556.PAA10609@mostar.nmrc.ucc.ie> Subject: Re: Pipes... To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Thu, 9 Nov 1995 15:56:12 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Rask Lambertsen" at Nov 9, 95 04:27:32 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 734 > Then what is IXPIPE: for anyway? I think I read somewhere in the IXPIPE: > source that only ixemul.library is allowed to use it. From Markus Wild's first Amiga port of pdksh, !readme.amiga!: ixpipe-handler/* ================ This is the first version of a bridge between ixemul.library and programs reading/writing to DOS filehandles. I'd be happy for comments on this! Be sure to mount the handler before trying to use I/O redirection on non-ixemul programs in ksh! Don't try to use it IXPIPE: like PIPE:, they're totally different! IXPIPE: is used automatically if a non-ixemul program is execve()'d for each file descriptor 0, 1 or 2 who's type is not that of a plain DOS file. A pipe would be an example of a non-dos type. From amiga-gcc-port-owner@nic.funet.fi Thu Nov 9 19:39:25 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90595-4>; Thu, 9 Nov 1995 19:37:36 +0200 Received: from murphy by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tDb64-000R5HC; Thu, 9 Nov 95 18:49 MET Received: from wyst.hobby.nl by murphy.hobby.nl with uucp (Smail3.1.28.1 #1) id m0tDRO4-000G4BC; Thu, 9 Nov 95 08:27 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0abp@wyst.hobby.nl>; Thu, 9 Nov 95 08:24:43 CET Message-Id: <9511090724.0abp@wyst.hobby.nl> Date: Thu, 9 Nov 1995 07:24:41 +0000 (CET) In-Reply-To: <199511082339.SAA02151@nextsun.INS.CWRU.Edu> from "David Zaroski" at Nov 8, 95 06:39:30 pm Content-Type: text Content-Length: 643 From: hans@wyst.hobby.nl (Hans Verkuil) To: cz253@cleveland.Freenet.Edu Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Pipes... According to David Zaroski: > > Is 'sh' creating it's own pipes? I purposely left ixpipe and pipe > unmounted, and yet when in 'sh', and I do : If you are only using ixemul-using programs, then the ixemul.library handles pipes for you. The PIPE: device is never used, and IXPIPE: is only used when piping to/from AmigaDOS programs. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu Nov 9 20:42:10 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <90040-1>; Thu, 9 Nov 1995 20:40:33 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id NAA01086; Thu, 9 Nov 1995 13:34:45 -0500 (from cz253) Message-Id: <199511091834.NAA01086@kanga.INS.CWRU.Edu> Date: Thu, 9 Nov 1995 13:34:45 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: hans@wyst.hobby.nl Subject: Re: Pipes... Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from hans@wyst.hobby.nl of Thu, 09 Nov > >According to David Zaroski: >> >> Is 'sh' creating it's own pipes? I purposely left ixpipe and pipe >> unmounted, and yet when in 'sh', and I do : > >If you are only using ixemul-using programs, then the ixemul.library handles >pipes for you. The PIPE: device is never used, and IXPIPE: is only used >when piping to/from AmigaDOS programs. > Thanks Hans. Now I know what to go after, in re: to the cat and tar problem. .....Dave From amiga-gcc-port-owner@nic.funet.fi Thu Nov 9 21:39:18 1995 Received: from mserv.rug.ac.be ([157.193.40.37]) by nic.funet.fi with SMTP id <90831-4>; Thu, 9 Nov 1995 21:38:24 +0200 Received: from eduserv.rug.ac.be by mserv.rug.ac.be with SMTP id AA20247 (5.67b/IDA-1.5 for ); Thu, 9 Nov 1995 20:38:12 +0100 Received: by eduserv.rug.ac.be (5.x/SMI-SVR4) id AA04942; Thu, 9 Nov 1995 20:37:58 +0100 Date: Thu, 9 Nov 1995 20:37:58 +0100 (MET) From: Kristof Depraetere To: joop van de wege Cc: amiga-gcc-port@nic.funet.fi, Kristof Depraetere Subject: Re: Startup code question In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 9 Nov 1995, joop van de wege wrote: > Hello, > > This is going to be a question which probably doesn't belong here but here it > goes anyway. > I'm trying to compile the following piece of code (at the end) which is > written for SAS/C but I'm using GCC 2.7.0 to compile this. Compiling is fine > but during linking I get the following unresolved errors: > __WBenchMsg > ___base > ___stack. > > 1) Am I correct that __WbenchMsg is the WBStartup message which is processed > in the startup code. If so why do I get the unresolved error. Linking is > done with crt.o > Had a quick look at crt.s and it seems there is little or no parsing of > WBStartup, maybe the symbol is not exported, didn't check that. > 2) This is for the die hard SAS/C users who also happen to use GCC ;) What is > __base pointing at and how do I make a GCC compatible one? > 3) __stack is the runtime stack setting and also available for ixemul/Libnix > no real problem here. > > Please CC me if you send a reply to the list, thanks > Are you trying to compile LCLint with the garbage collection library? __WBStartup and ___stack are found while linking with the libnix library. I didn't find ___base though. I tried with replacing it with _geta4. Then it compiles, but the testprogram doesn't work. I've compiled LCLint, but without the garbage collection library. It works with a simple "hello world" program. But when I tried to put makeinfo.c (about 230Kb) through it, I didn't have enough memory (even with 16Mb). So let me know if you get the garbage collection library working. LCLint is useless without it. bye, Kristof. From amiga-gcc-port-owner@nic.funet.fi Fri Nov 10 21:06:02 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <89028-3>; Fri, 10 Nov 1995 21:03:07 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HXHO47R65C0073R1@NET2.WAU.NL>; Fri, 10 Nov 1995 20:06:24 +0000 (GMT) Received: by vines2.wau.nl; Fri, 10 Nov 95 20:02:41 +0100 Date: Fri, 10 Nov 1995 19:59:31 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: Startup question To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi Kristof, >Are you trying to compile LCLint with the garbage collection library? Bulls eye :) >__WBStartup and ___stack are found while linking with the libnix library. >I didn't find ___base though. I tried with replacing it with _geta4. Then >it compiles, but the testprogram doesn't work. I get a report that STACK_GROWS_DOWN is defined but that the program finds that it grows up. Now on the Amiga the stack grows down indeed so I think that the calculation whether it does this is broken. Haven't ripped apart the test program gctest but will try as soon as I have time. Will also try to compile atleast the gc library with SAS/C. Then the test program should work. >I've compiled LCLint, but without the garbage collection library. It >works with a simple "hello world" program. But when I tried to put >makeinfo.c (about 230Kb) through it, I didn't have enough memory (even >with 16Mb). There is some mentioning in the docs about 100M. I first thought HD space but they really mean RAM. Just switch on VM ;) >So let me know if you get the garbage collection library working. >LCLint is useless without it. Might ask the Amiga porter (SAS/C) what might be wrong. All suggestions from the list are tried but no success sofar. Joop For those who don't get my email address in the header :-) Joop.vandeWege@medew.ento.wau.nl From amiga-gcc-port-owner@nic.funet.fi Sat Nov 11 18:21:25 1995 Received: from mserv.rug.ac.be ([157.193.40.37]) by nic.funet.fi with SMTP id <88954-4>; Sat, 11 Nov 1995 18:11:14 +0200 Received: from eduserv.rug.ac.be by mserv.rug.ac.be with SMTP id AA16849 (5.67b/IDA-1.5 for ); Sat, 11 Nov 1995 17:11:05 +0100 Received: by eduserv.rug.ac.be (5.x/SMI-SVR4) id AA21934; Sat, 11 Nov 1995 17:10:47 +0100 Date: Sat, 11 Nov 1995 17:10:47 +0100 (MET) From: Kristof Depraetere To: joop van de wege Cc: amiga-gcc-port@nic.funet.fi, Kristof Depraetere Subject: Re: Startup question In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 10 Nov 1995, joop van de wege wrote: > > >__WBStartup and ___stack are found while linking with the libnix library. > >I didn't find ___base though. I tried with replacing it with _geta4. Then > >it compiles, but the testprogram doesn't work. > I get a report that STACK_GROWS_DOWN is defined but that the program finds > that it grows up. > Now on the Amiga the stack grows down indeed so I think that the calculation > whether it does this is broken. > Haven't ripped apart the test program gctest but will try as soon as I have > time. > Will also try to compile atleast the gc library with SAS/C. Then the test > program should work. > I managed to get gctest to work :) I changed the following in os_dep.c: ptr_t GC_get_stack_base() { extern struct WBStartup *_WBenchMsg; long __base; /* Changed -kdp */ extern long __stack; struct Task *task; struct Process *proc; struct CommandLineInterface *cli; long size; if ((task = FindTask(0)) == 0) { GC_err_puts("Cannot find own task structure\n"); ABORT("task missing"); } __base = task->tc_SPReg; /* Added -kdp */ proc = (struct Process *)task; cli = BADDR(proc->pr_CLI); if (_WBenchMsg != 0 || cli == 0) { size = (char *)task->tc_SPUpper - (char *)task->tc_SPLower; } else { size = cli->cli_DefaultStack * 4; } return (ptr_t)(__base + GC_max(size, __stack)); } When I run the gctest program I get the following output: 6.Build:source/lclint/gcsrc> gctest Completed 1 tests Finalized 2206/2206 objects - finalization is probably ok Total number of bytes allocated is 53702044 Final heap size is 7835648 bytes Collector appears to work 6.Build:source/lclint/gcsrc> So this looks ok. I'll try to get those _WBstartup and __stack out. So I can compile it with ixemul. bye, Kristof. From amiga-gcc-port-owner@nic.funet.fi Sun Nov 12 14:16:40 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90595-2>; Sun, 12 Nov 1995 14:14:40 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HXK2FCLU7K007B8Z@NET2.WAU.NL>; Sun, 12 Nov 1995 13:17:50 +0000 (GMT) Received: by vines2.wau.nl; Sun, 12 Nov 95 13:14:11 +0100 Date: Sun, 12 Nov 1995 12:59:39 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: atof() problems, HELP To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Its me again, and yes another problem :( But first a word of thanks for all the help on the __stack/__base problem I got. Not all posts did agree with each other but it seems that Kristof has found a solution. Now the my new problem, which will turn out to be a major oversight on my part but here it goes ;) This is a simple example which will illustrate what the problem is --------------------- test.c -------------------- #include #include #include #include /* * Returns a real number */ char valbuf[]="1000.40"; main() { printf("valbuf: %s, atof %f \n",valbuf, (double)atof(valbuf)); } /* Changing %f to something else doesn't help. The code generated stays the same and that is the main problem. See below for details */ ------------------ snip ------------- Output of gcc -v gcc -v -o test test.c -lm -noixemul Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cpp -lang-c -v -undef - D__GNUC__=2 -D__GNUC_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ - D__amigados__ -D__MCH_A MIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -A cpu(m68k) -Amachine(m68k) -Dmc68010 test.c /t/cc608952.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cc1 /t/cc608952.i -quiet - dumpbase test.c -version -o /t/cc608952.s GNU C version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. as -mc68010 -o /t/cc6089521.o /t/cc608952.s ld -shortdata -fl libnix -o test /gnu/lib/libnix/ncrt0.o -L/gnu/lib/gcc- lib/mc68020-cbm-amigados/2 7.0 -L/local/lib/gcc-lib/mc68020-cbm-amigados/2.7.0 -L/gnu/lib -L/local/lib - L/local/lib /t/cc6089 521.o -lm -lgcc -lnixmain -lnix -lamiga -lgcc -lstubs 12.Develop:gnu/Source/hpgl2ps1> test valbuf: 1000.40, atof 1083130675.000000 Looks like that atof() is somewhat broken in both the libnix and ixemul. It prints only the high order long from the double result. Anyone knows what is going on here. I have used quite some floating point stuff but this is the first time that it doesn't work. I took a piece of assembly out of my original program that had the problem but the same sequence of instructions should also be present in 'test'. LEA (-10,A5),A0 MOVE.L A0,-(SP) ; push 'valbuf' onto stack BSR.L _atof ; call atof and return double in d0/d1 ADDQ.W #4,SP FMOVE.L D0,FP0 ; this is the place where things go wrong FMOVE.D FP0,-(SP) ; this is nice but doesn't fix anything LEA (-10,A5),A0 ; the rest of the code prints the whole MOVE.L A0,-(SP) ; thing. PEA (buffersfloatl.MSG,PC) MOVEA.L (___sF).L,A0 ADDQ.W #8,A0 MOVE.L (A0),-(SP) BSR.L _fprintf ADDA.W #$14,SP MOVE.L (-14,A5),D0 BRA.W lbC0067F4 lbC0067F4 MOVE.L (-$1C,A5),D2 UNLK A5 RTS _atof LINK.W A5,#-8 LEA (-8,A5),A0 MOVE.L A0,-(SP) PEA (___gnu_compiled_c,PC) MOVE.L (8,A5),-(SP) BSR.L ___gnu_compiled_c ;sprintf() ADDQ.W #8,SP ADDQ.W #4,SP MOVE.L (-8,A5),D0 ; return double result in d0/d1 MOVE.L (-4,A5),D1 ; fp0 contains the right value, is not used BRA.W lbC0000F4 ; I checked this with Bdebug. lbC0000F4 UNLK A5 RTS I tried compiling for different cpu/fpu's but nothing seems to help. HPGL2ps just outputs huge numbers for its coordinates because it uses only the high order part of the double. Am I doing something wrong that I don't see or is there really a bug in either gcc or Libnix? Thanks for any help given, Joop Joop.vandeWege@medew.ento.wau.nl From amiga-gcc-port-owner@nic.funet.fi Sun Nov 12 22:25:59 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90537-4>; Sun, 12 Nov 1995 22:23:52 +0200 Received: from getnet.com (actually host gn2.getnet.com user cbell@gn2.getnet.com) by funet.fi with SMTP (PP); Sun, 12 Nov 1995 22:23:41 +0200 Received: (cbell@localhost) by getnet.com (8.7.1/8.7.1) id NAA27403 for amiga-gcc-port@nic.funet.fi; Sun, 12 Nov 1995 13:23:19 -0700 (MST) Date: Sun, 12 Nov 1995 13:23:19 -0700 (MST) From: Clinton Ball Message-Id: <199511122023.NAA27403@getnet.com> To: amiga-gcc-port@nic.funet.fi I am posting to this list because I have not received a response on either gnu.g++.help or comp.sys.amiga.programmer. I hope someone here can help. I have an Amiga 2000 with GVP GForce 030 and 68882 FPU. When I compile and run the program below using GNU GCC version 2.7.0 directly off Fred Fish's Freash Fish 10 CDROM. I assigned GNU: FreshFish-Vol10:GNU then executed the GNU:Sys/S/GNU-Startup script. Using the following command line: g++ -v -o flaot float.cc -lm The printf lines give the expected output but the cout lines produce garbage. This is the output from the program: The double number dnum = 3/..5+ The double number dnum2 = 14 The dnum2 * dnum = 404..3 The floating point number fnum = 3/..45 The integer number inum = 14 The fnum * inum = 404..3 The floating point number fnum = 28.844999 The integer number inum = 14 The fnum * inum = 403.829987 I have compiled and run the same program using the SAS C/C++ version 6.51 compiler and get the correct output for the cout lines. I also have compiled and run the same program on an RS6000 AIX system using xCland I get the correct output. I have tried compiling this with gcc version 2.6.3 and the cout lines were the same as with version 2.7.0 Is there another #include I need to add or link with another library? Is this a bug in gcc? I would appreciate any help with this problem. Thanks Clinton Bell // float.cc // test use of math library #include #include #include #include int main(void) { double dnum = 28.845; double dnum2 = 14.0; float fnum = 28.845; float fnum2; int inum = 14; cout << "\nThe double number dnum = " << dnum << endl; cout << "The double number dnum2 = " << dnum2 << endl; dnum2 *= dnum; cout << "The dnum2 * dnum = " << dnum2 << endl; cout << "\nThe floating point number fnum = " << fnum << endl; cout << "The integer number inum = " << inum << endl; fnum2 = fnum * inum; cout << "The fnum * inum = " << fnum2 << endl; printf("\nThe floating point number fnum = %f\n", fnum); printf("The integer number inum = %d\n", inum); printf("The fnum * inum = %f", fnum2); return (0); } From amiga-gcc-port-owner@nic.funet.fi Sun Nov 12 23:18:26 1995 Received: from carina.rz.Uni-Osnabrueck.DE ([131.173.128.25]) by nic.funet.fi with SMTP id <90149-3>; Sun, 12 Nov 1995 23:17:09 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id WAA29822 for ; Sun, 12 Nov 1995 22:17:04 +0100 From: Thomas Radtke Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.7.1/8.7.1) id WAA11963 for amiga-gcc-port@lists.funet.fi; Sun, 12 Nov 1995 22:17:03 +0100 Message-Id: <199511122117.WAA11963@nereid.rz.Uni-Osnabrueck.DE> Subject: joops quest To: amiga-gcc-port@nic.funet.fi Date: Sun, 12 Nov 1995 22:17:03 +0100 (NFT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Ops, seems that I forgot to forward my reply to Joops atof question to the list :(. I suggested to prototype atof by hand, e.g. double atof();. He really should subscribe to this list :). Thomas From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 11:29:08 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90341-4>; Mon, 13 Nov 1995 11:27:27 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA11327 (5.65c8/IDA-1.4.4 for ); Mon, 13 Nov 1995 10:27:15 +0100 Received: by diva.gmd.de with UUCP id AA04645 (5.67b8/IDA-1.5); Mon, 13 Nov 1995 10:24:07 +0100 Date: Mon, 13 Nov 1995 10:24:07 +0100 Message-Id: <199511130924.AA04645@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: Joop.vandeWege@medew.ento.wau.nl (joop van de wege) Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Startup question In-Reply-To: References: joop van de wege writes: > >Are you trying to compile LCLint with the garbage collection library? What is it anyway? > I get a report that STACK_GROWS_DOWN is defined but that the program finds > that it grows up. Never seen it report false values. Don't use -fstackextend because the stack can be anywhere then. Be sure not to compile in any replacement of alloca() written in C. Use the builtin one. > __base = task->tc_SPReg; /* Added -kdp */ > if (_WBenchMsg != 0 || cli == 0) { > size = (char *)task->tc_SPUpper - (char *)task->tc_SPLower; > } else { > size = cli->cli_DefaultStack * 4; There's been some lengthy discussion here about getting the stack size. The above is wrong in some cases. The stack is either between tc_SPLower and tc_SPUpper or the stack size can be found by *(ULONG*)pr_ReturnAddr, the top being pr_ReturnAddr, the base (ULONG)pr_ReturnAddr - size. Some people argue that in case of a CLI, you must always use *pr_ReturnAddr and ignore tc_SP*. But _don't_ use cli_DefaultStack. >I'll try to get those _WBstartup and __stack out. So I can compile it >with ixemul. You don't need the reference to __stack using the above methods. You don't need WBstartup either. Everything is located through FindTask(NULL). I could find sample code in my old GCC archives if you wish. Regards, Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 12:09:22 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90476-2>; Mon, 13 Nov 1995 12:08:37 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA14192 (5.65c8/IDA-1.4.4 for ); Mon, 13 Nov 1995 11:08:18 +0100 Received: by diva.gmd.de with UUCP id AA04657 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Mon, 13 Nov 1995 11:05:09 +0100 Date: Mon, 13 Nov 1995 11:05:09 +0100 Message-Id: <199511131005.AA04657@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: tester for L:fifo-handler wanted Hi, I corrected a few bugs in the fifo-handler (handler only, no change to the library) by Matt Dillon and would like some people to test it before I release it. Who is using FIFO: outside of M-x shell in Emacs? While I'm at it, I'd like to put my hands on a fifolib >34_4 which is said to implement ACTION_WAIT_CHAR. Changes: o safe handling of ACTION_SCREEN_MODE. o ACTION_SCREEN_MODE only allowed if opened with 's' (shell). It doesn't make sense otherwise as the packet does not include the file handle. o safe handling of low-memory once FIFO is initialized. o new ACTION_CHANGE_SIGNAL, ACTION_IS_FILESYSTEM. o correct result for the unimplemented ACTION_SEEK. o more error return codes (WRITE_PROTECTED, BAD_STREAM_NAME, ...) Incompatible change: o ACTION_SCREEN_MODE is refused if FIFO: not opened in cooked mode. (Was not refused, but buggy in the original handler). The rationale is that programs which open FIFO: in shell but not in cooked mode have good reasons to do so (remcli, Emacs), whereas shell programs may always switch to cooked mode at program exit, thus starting cooked mode inadvertently. Programs using FIFO that I know and thus should be tested: + M-!, M-|, M-x shell/cmushell/cmulisp in Emacs + M-x gopher for AmiTCP in Emacs (using tcp_AmiTCP program) + remcli in the FIFO distribution + ...? Now you don't get Enforcer hits when using ls-4.7ljr in an Emacs shell buffer anymore. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 12:09:38 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90333-1>; Mon, 13 Nov 1995 12:09:25 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA14250 (5.65c8/IDA-1.4.4 for ); Mon, 13 Nov 1995 11:09:04 +0100 Received: by diva.gmd.de with UUCP id AA04661 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Mon, 13 Nov 1995 11:05:56 +0100 Date: Mon, 13 Nov 1995 11:05:56 +0100 Message-Id: <199511131005.AA04661@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: ranlib made superfluous This also affects ranlib in newer GCC archives... >From the Solaris2 FAQ: 6.3) Where has ranlib gone? The functionality provided by ranlib in SunOS 4.1.x is now merged into ar. It is no longer necessary to run ranlib on archive libraries. Fix makefiles that require ranlib by replacing it with "/bin/true". A no-op ranlib is reintroduced in 2.5. It's not necessary to call ranlib anymore for us too. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 12:21:50 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90809-4>; Mon, 13 Nov 1995 12:21:13 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HXLCR7528W007LM1@NET2.WAU.NL>; Mon, 13 Nov 1995 11:24:30 +0000 (GMT) Received: by vines2.wau.nl; Mon, 13 Nov 95 11:20:53 +0100 Date: Mon, 13 Nov 1995 11:10:45 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: Startup question To: hoehle@zeus.gmd.de Cc: amiga-gcc-port@lists.funet.fi Illegal-Object: Syntax error in Message-id: value found on nic.funet.fi: Message-id: joop van de wege writes: > > >Are you trying to compile LCLint with the garbage collection library? >What is it anyway? LCLint is a lint compatible program that does extensive syntax checking with better messages than most compilers spit out when they find an error, except maybe LCC. >> I get a report that STACK_GROWS_DOWN is defined but that the program finds >> that it grows up. >Never seen it report false values. Don't use -fstackextend because the >stack can be anywhere then. Be sure not to compile in any replacement >of alloca() written in C. Use the builtin one. I don't use stackextend, but it reports errors because the __base calculation is wrong. It calculates the base then puts a dummy variable on stack, gets the stackpointer and compares it to __base, if higher than __base --> error. >>I'll try to get those _WBstartup and __stack out. So I can compile it >>with ixemul. >You don't need the reference to __stack using the above methods. You >don't need WBstartup either. Everything is located through FindTask(NULL). Correct, neither _WBStartup or __stack is needed and can be safely removed BUT there is another problem which Kristof is probably aware of if he has tried to compile the thing with GCC. There is one file which need further modifcation namely, mach_dep.c. _WBStartup and __stack is in os_dep.c and has been taken care of. The problem with mach_dep.c is a bit trickier but I'll have a go at it. I'm currently using gc4.5 which is a bit newer then the version included with LCLint I got. A thanks goes to all people who pointed out what was wrong with 'atof()'. The problem was that it is rather old source and the contents of some header files has since then moved. Joop From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 12:35:00 1995 Received: from icslab10.icslab.agh.edu.pl ([149.156.98.10]) by nic.funet.fi with SMTP id <90607-1>; Mon, 13 Nov 1995 12:33:46 +0200 Received: (from kiskra@localhost) by icslab10.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA00416; Mon, 13 Nov 1995 11:35:18 +0100 Date: Mon, 13 Nov 1995 11:35:16 +0100 (MET) From: Kamil Iskra Subject: Proposed new entries in FAQ To: Amiga GCC List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I wrote some answers to, I believe, most frequently asked questions about G++ and about "spilled register" problem. Please excuse my broken English - I hope that FAQ maintainer will correct all mistakes :-). Here is a diff file to "gcc-faq.txt" that could be found in GCC 2.7.0 distribution: *** gcc-faq.txt.orig Mon Aug 21 19:54:40 1995 --- gcc-faq.txt Sun Nov 12 17:13:51 1995 *************** *** 45,52 **** i. Inline Headers j. Writing Hooks 5. C++ and Objective C ! (don't know much about these, except that they're not as well ! developed yet as the C compiler) 6. Notes for Un*x Hackers a. fork() is not implemented 7. Support Utilities --- 45,52 ---- i. Inline Headers j. Writing Hooks 5. C++ and Objective C ! i) How up to date is g++? ! ii) Use _complex.h instead of complex.h 6. Notes for Un*x Hackers a. fork() is not implemented 7. Support Utilities *************** *** 62,68 **** --- 62,70 ---- a. the C compiler i) -resident option ii) -fbaserel option + iii) spilled register b. the C++ compiler + i) Template support c. the Objective C compiler 10. Maintainers and Contributors 11. Future *************** *** 1448,1461 **** a. C++ ! i) Use _complex.h instead of complex.h Because Amiga Dos is not case-sensitive, and there are both complex.h and Complex.h on the Unix distribution, one had to be changed. This choice was recommended by the libg++ maintainer. - (don't know much about these, except that they're not as well - developed yet as the C compiler) - 6. Notes For Un*x Hackers [additions to this section are welcome] --- 1450,1507 ---- a. C++ ! i) How up to date is g++? ! ! [Kamil Iskra] ! ! C++ has been growing rapidly recently - ANSI/ISO committee adds quite ! a lot to original C++ as described in "The Annotated C++ Reference ! Manual", by Ellis and Stroustrup. You may want to have a look at ! "Draft Working Paper" from 28 April 1995, which can be found for ! example at: ! ! ftp://ftp.cygnus.com/pub/g++/wpascii.zip ! ! G++ 2.7.0 is quite well up to date. ! ! It supports RTTI (Run Time Type Identification), new style casts ! (const_cast<>, dynamic_cast<> etc.), new style include names ! ( instead of etc.), type "bool", new scope of ! variables defined in "for" (this actually caused more harm than good ! and old scope support will be back in 2.7.1, but a warning will be ! generated when G++ sees "old style"). ! ! However, in some "bigger" things G++ is not as up to date as many ! commercial compilers. I mostly mean templates and exceptions. ! ! Templates are supported, but there is no automatic instantiation ! support as of 2.7.0. However, BETA version of such a support can be ! found on "cygnus" server (see above) - this is so called "repository ! patch". I haven't heard how this works with Amiga port of G++, though. ! Please also have a look at "Known Bugs" section of this FAQ. ! ! Exceptions are supported, too, BUT they are still in BETA stage. They ! work on SOME platforms only, exceptions-specifications are ignored and ! code optimization must be turned OFF. As of 2.7.0, MC 68k is only ! partially supported - G++ can generate exceptions code if ! "-fhandle-exceptions" is used, but one library function, ! "__unwind_function()", is missing. There were some attempts to create ! this function for Amiga, but they were not 100% successful. However, ! it is said that 2.7.1 will have better exception-handling: more ! platforms will be supported (MC 68k will be one of them), optimization ! will work. ! ! Two other big, still not supported things are namespaces and standard ! C++ library. Hardly any compiler supports them as of today, though. ! ! For more general information about G++, please have a look at ! machine-independent G++FAQ. ! ! ii) Use _complex.h instead of complex.h Because Amiga Dos is not case-sensitive, and there are both complex.h and Complex.h on the Unix distribution, one had to be changed. This choice was recommended by the libg++ maintainer. 6. Notes For Un*x Hackers [additions to this section are welcome] *************** *** 1623,1629 **** --- 1669,1783 ---- Won't be fixed until the -resident option is (as it's the cause of the -resident problem). + iii) spilled register + + [Kamil Iskra] + + If you compile Amiga-specific sources which use direct OS calls + through "inlines", in some cases compiler might refuse to compile your + source and write: + + fixed or forbidden register was spilled. + This may be due to a compiler bug or to impossible asm + statements or clauses. + + Expression does not have to be very complex. For example, this simple + source produces the problem: + + #include + + struct IntuitionBase *IntuitionBase; + struct EasyStruct esg; + + STRPTR GetString(struct EasyStruct*); + + void easyreq(void) + { + struct EasyStruct es={sizeof(struct EasyStruct)}; + es.es_Title=GetString(&esg); + es.es_GadgetFormat=GetString(&esg); + EasyRequestArgs(0, 0, 0, 0); + } + + Yeah, I know this code doesn't make sense, but I wanted to make it as + simple as possible :-). + + With this source, the problem appears when GCC is invoked with + "-fbaserel" and optimization turned on. + + This seems to be caused by the fact that GCC runs out of registers in + such cases. In the above source, EasyRequestArgs() uses registers + a0-a3 as its parameters and a6 as pointer to IntuitionBase. a4 is used + by "-fbaserel", a5 is a frame pointer and a7 - stack pointer, so all + address registers are used. + + It is hard to say whether this is a bug. Compiler can behave strangely + if too many of its registers are used, this is described in GCC + manual. One thing is sure: this worked well in the past and no longer + works with 2.7.0. + + In some cases simplifying expressions might help. For example, try to + define more local variables for function arguments, split function + into two, smaller ones etc. + + If nothing helps, or if you don't want to modify the source code too + much, there is an ultimate solution: you have to force the OS-call + that causes problems not to be inlined. + + If you use "inlines" distributed with GCC 2.7.0, you have to change + the name of the function in "inlines". Most neat way to achieve this + seems to be using preprocessor. In the above source, you should do: + + #define EasyRequestArgs _EasyRequestArgs + #include + #undef EasyRequestArgs + + This way stub from "libamiga.a" will be used instead of "inline" call. + + GCC 2.7.1 will have new "inlines". The workaround described above will + work, too, but GCC will generate a warning about redefined symbol, + you'll also loose one of the features of new inlines - local library + bases. + + With new inlines, you can use other workaround, which also involves + preprocessor: you have to protect the call with "#define + __inline/#undef __inline". In the above source, you should do: + + #define __inline + EasyRequestArgs(0, 0, 0, 0); + #undef __inline + + New inlines are implemented by inserting a local "__inline" function + in the place of call - this is being made by the preprocessor. If you + define "__inline" to be an empty symbol, inserted local functions will + no longer be "inline" and the call will succeed. This has also other + advantage: you can "disable" single calls to the function - the + workaround described first "disables" inlining of the function in + whole source file. + + However, you have to remember not to use "-O3" - this causes automatic + inlining of simple functions even if they are not defined as "inline" + and the problem reappears. But who uses "-O3", actually? It only + increases GCC memory requirements and final executable size. + b. C++ compiler (g++) + + i) Template support + + [Kamil Iskra] + + AFAIK, template support in G++ has been badly implemented and it + doesn't support many widely used and perfectly valid constructions, + like for example: + + template class A; + + class B + { + friend template A; + }; + + It is said that template-handling in G++ will have to be rewritten. c. Objective C compiler / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 13:06:51 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89172-1>; Mon, 13 Nov 1995 13:05:42 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 13 Nov 95 12:04 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 13 Nov 95 11:11 MET Message-Id: Subject: atof() problems, HELP To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 13 Nov 1995 11:11:15 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1672 > Its me again, and yes another problem :( > > But first a word of thanks for all the help on the __stack/__base problem I > got. Not all posts did agree with each other but it seems that Kristof has > found a solution. > Now the my new problem, which will turn out to be a major oversight on my > part but here it goes ;) > > > This is a simple example which will illustrate what the problem is > --------------------- test.c -------------------- > #include > #include > #include > #include > > /* > * Returns a real number > */ > char valbuf[]="1000.40"; > > main() > { > printf("valbuf: %s, atof %f \n",valbuf, (double)atof(valbuf)); > } > /* Changing %f to something else doesn't help. The code generated stays the > same and that is the main problem. See below for details */ > > ------------------ snip ------------- > Output of gcc -v > > Looks like that atof() is somewhat broken in both the libnix and ixemul. It > prints only the high order long from the double result. > Anyone knows what is going on here. I have used quite some floating point > stuff but this is the first time that it doesn't work. > > I took a piece of assembly out of my original program that had the problem > but the same sequence of instructions should also be present in 'test'. > hi joop, i made the error myself so i can say include will solve the problem. i guess the return value of atof is int if you dont include it. that can drive someone casy if it works with integers and fail with floats. walter -- ----- "Reason is the last thing you must expect, in this or any other world." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 13:07:41 1995 Received: from icslab10.icslab.agh.edu.pl ([149.156.98.10]) by nic.funet.fi with SMTP id <89270-1>; Mon, 13 Nov 1995 13:07:31 +0200 Received: (from kiskra@localhost) by icslab10.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA00465; Mon, 13 Nov 1995 12:09:15 +0100 Date: Mon, 13 Nov 1995 12:09:13 +0100 (MET) From: Kamil Iskra Subject: New FD2Inline To: Amiga GCC List cc: fnf@amigalib.com, phb@colombo.telesys-innov.fr Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII New FD2Inline can be found on my WWW homepage. I have also uploaded it to "amigalib" (Fred, could you please remove older versions from /incoming? I had to upload the new one as "fd2inline_new2.lha"). I wanted to upload it to "colombo", as well, but I can't get through (User anonymous access denied). Philippe, could you please do something about it? Modifications since the last release: exec.library functions were not inlined: in "proto/exec.h" I wrote "#include " instead of "#include " (I must have been very sleepy when I was writing it :-). dos.library/DoPkt1()-DoPkt4() were generated incorrectly when FD2Inline was compiled with optimization (bug in GCC 2.7.0 optimizer???). Added a workaround. Sent a bug report to bug-gcc@prep.ai.mit.edu. Varargs for datatypes.library/DoDTMethod(), datatypes.library/ PrintDTObject() and intuition.library/DoGadgetMethod() weren't generated, because their last parameters' types were not "struct TagItem *". Added these functions to exception array. Vararg-stubs generator was generating stubs for certain utility.library functions which don't really have vararg versions (generator was confused by the fact that the last parameter type was "struct TagItem *" - this was because those function were for tag manipulation purposes). Created new exception array - for functions that should NOT have vararg-stubs even though their parameters would suggest so. Calling dos.library/FWritef() (vararg version of VFWritef()) always resulted in a warning about incompatible pointer types. This was because FWritef() expects "LONG *" as the last parameter, while vararg stub passed "struct TagItem *". Replaced hard-coded "struct TagItem *" in vararg-stubs generator with a code that inserts last parameter's type. What has NOT changed: Nothing has been done with "spilled register" problem. This problem cannot be fixed in "inlines", because depending on options used and complexity of functions problem either appears or not. However, I posted some suggestions to GCC-FAQ today - I hope this will help. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 14:34:34 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <90058-3>; Mon, 13 Nov 1995 14:33:22 +0200 Received: by colombo.telesys-innov.fr; Mon, 13 Nov 1995 13:32:50 GMT From: Philippe BRAND Message-Id: <199511131332.NAA22712@colombo.telesys-innov.fr> Subject: 2.7.1 beta available To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Mon, 13 Nov 1995 13:32:49 +0000 (WET) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit gcc271-amiga-beta.lha available on both my site and nic.funet.fi, C part. I'll try to generate version using auto-stackextend tonight. NOTE: compiler directory has changed from /gnu/lib/gcc-lib/mc68000-cbm-amigados to /gnu/lib/gcc-lib/mc68000-at-amigados -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 21:02:55 1995 Received: from rumms.uni-mannheim.de ([134.155.50.52]) by nic.funet.fi with SMTP id <90110-2>; Mon, 13 Nov 1995 20:58:55 +0200 Received: from pips01.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA16563 (5.65c/IDA-1.4.4 for ); Mon, 13 Nov 1995 19:58:44 +0100 Received: from pips13.informatik.uni-mannheim.de by pips01.informatik.uni-mannheim.de (4.1/BelWue-1.1Sma2(subsidiary)) id AA26041; Mon, 13 Nov 95 19:54:41 +0100 Received: by pips13.informatik.uni-mannheim.de (5.0/SMI-SVR4) id AA07382; Mon, 13 Nov 1995 19:58:26 --100 From: opel@pips01.informatik.uni-mannheim.de (Steffen Opel) Message-Id: <9511131858.AA07382@pips13.informatik.uni-mannheim.de> Subject: GCC-Install maintaineance To: amiga-gcc-port@nic.funet.fi Date: Mon, 13 Nov 1995 19:58:25 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 462 Salut, since nobody else responded to Jochen Wiedmanns request for maintaineance of the GCC-Install script I talked to him last week and will most likely do this job in the near future. Therefore any problems / suggestions concerning this script should be forwarded to the following address from now on: opel@rummelplatz.uni-mannheim.de If anybody else would like to part with this job or do it on its own, please feel free to contact me. Ciao, Steffen Opel From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 21:35:48 1995 Received: from lillep.gbar.dtu.dk ([130.225.87.179]) by nic.funet.fi with ESMTP id <90847-1> convert rfc822-to-8bit; Mon, 13 Nov 1995 21:34:53 +0200 Received: by lillep.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 13 Nov 1995 20:34:15 +0100 (MET) From: Rask Lambertsen To: Kamil Iskra Cc: Amiga GCC List Subject: Re: Proposed new entries in FAQ In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 13 Nov 1995, Kamil Iskra wrote: > + However, you have to remember not to use "-O3" - this causes automatic > + inlining of simple functions even if they are not defined as "inline" > + and the problem reappears. But who uses "-O3", actually? It only > + increases GCC memory requirements and final executable size. I do :-) Don't forget, it also takes a "few" miliseconds longer to compile. However, I don't want people to spend time waiting for my programmes to do their job. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 22:24:25 1995 Received: from lillep.gbar.dtu.dk ([130.225.87.179]) by nic.funet.fi with ESMTP id <90831-1> convert rfc822-to-8bit; Mon, 13 Nov 1995 22:23:33 +0200 Received: by lillep.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 13 Nov 1995 21:23:05 +0100 (MET) From: Rask Lambertsen To: Philippe BRAND Cc: Amiga-Gcc Liste Subject: Re: 2.7.1 beta available In-Reply-To: <199511131332.NAA22712@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 13 Nov 1995, Philippe BRAND wrote: > gcc271-amiga-beta.lha available on both my site and nic.funet.fi, C part. > I'll try to generate version using auto-stackextend tonight. So that's why you were getting the README :-) Is there any change of seeing some of the utils soon (compiled for '000)? Robert, I tried finding some on your FTP site, but I couldn't. > NOTE: compiler directory has changed from > > /gnu/lib/gcc-lib/mc68000-cbm-amigados to > /gnu/lib/gcc-lib/mc68000-at-amigados Good, but why not to /gnu/lib/gcc-lib/mc68000-at-amigaos and do it right in one go? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 23:31:53 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90218-3>; Mon, 13 Nov 1995 23:31:08 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tF6kX-000RB7C; Mon, 13 Nov 95 22:49 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0ah7@wyst.hobby.nl>; Mon, 13 Nov 95 15:27:17 CET Message-Id: <9511131427.0ah7@wyst.hobby.nl> Date: Mon, 13 Nov 1995 15:27:14 +0000 (CET) Content-Type: text Content-Length: 1053 From: hans@wyst.hobby.nl (Hans Verkuil) To: ixemul@listserv.funet.fi Cc: amiga-gcc-port@nic.funet.fi Subject: Move fts.c from ixemul to libc.a (proposal) Proposal: I want to move fts.c (which is now part of ixemul.library) to libc.a. fts.c contains functions for directory-traversal but to my knowledge it is never used. Apparently, it is part of BSD Unix, so Markus probably just copied it into ixemul. However, it is relatively large (about 4 Kb), so I think that it should be put into libc.a. Comments? For those readers of the gcc-port mailinglist who didn't see my mail in the ixemul mailinglist: I also want to remove ssystem() from the library. It was a first try of Markus to get some sort of vfork() behavior. But since we can now use vfork/execve, there is no longer any reason to carry this function around. I've never seen it used anywhere, and it saves another 2-3 Kb. Comments? Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Mon Nov 13 23:32:03 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90280-2>; Mon, 13 Nov 1995 23:30:19 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tF6k3-000RB6C; Mon, 13 Nov 95 22:48 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0agx@wyst.hobby.nl>; Mon, 13 Nov 95 12:54:49 CET Message-Id: <9511131154.0agx@wyst.hobby.nl> Date: Mon, 13 Nov 1995 12:54:46 +0000 (CET) In-Reply-To: <199511131005.AA04657@diva.gmd.de> from "Joerg Hoehle" at Nov 13, 95 11:05:09 am Content-Type: text Content-Length: 2278 From: hans@wyst.hobby.nl (Hans Verkuil) To: hoehle@zeus.gmd.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: tester for L:fifo-handler wanted Hi Joerg, > I corrected a few bugs in the fifo-handler (handler only, no change to > the library) by Matt Dillon and would like some people to test it > before I release it. Who is using FIFO: outside of M-x shell in Emacs? The DejaGnu port on FreshFish CD 10. > While I'm at it, I'd like to put my hands on a fifolib >34_4 which is > said to implement ACTION_WAIT_CHAR. That's fifo-38.0. I assume you meant 37.4 instead of 34.4. Version 37.4 is available on Aminet, fifo-38.0 only on FreshFish CD 10. I'll upload 38.0 to colombo.telesys-innov.fr, /pub/amigados-gnu/uploads (if this works :-). I believe that there is a site that has FreshFish CD 10 online, but I don't know the site name. You can also try ftp.amigalib.com, which also has a CD online, but I don't know if the fifo-handler 38.0 is on it. Besides a general cleanup of the code I also added ACTION_WAIT_CHAR (I needed that for DejaGnu) and it now compiles with gcc (and uses configure). > Changes: > o safe handling of ACTION_SCREEN_MODE. > o ACTION_SCREEN_MODE only allowed if opened with 's' (shell). It > doesn't make sense otherwise as the packet does not include the > file handle. > o safe handling of low-memory once FIFO is initialized. > o new ACTION_CHANGE_SIGNAL, ACTION_IS_FILESYSTEM. > o correct result for the unimplemented ACTION_SEEK. > o more error return codes (WRITE_PROTECTED, BAD_STREAM_NAME, ...) > > Incompatible change: > o ACTION_SCREEN_MODE is refused if FIFO: not opened in cooked > mode. (Was not refused, but buggy in the original handler). The > rationale is that programs which open FIFO: in shell but not in > cooked mode have good reasons to do so (remcli, Emacs), whereas > shell programs may always switch to cooked mode at program exit, > thus starting cooked mode inadvertently. I don't have time for a merge of these two versions as I'm busy working on ixemul.library 42.0 (lots of goodies in this version! I especially love my ixtimezone utility, if I say so myself. Finally brings correct timezone handling to the Amiga!) so I hope you are willing to do this. In exchange, I'll test fifo 39.0 :-) with DejaGnu. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 00:20:45 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <90558-3>; Tue, 14 Nov 1995 00:19:47 +0200 Received: by colombo.telesys-innov.fr; Mon, 13 Nov 1995 23:19:41 GMT From: Philippe BRAND Message-Id: <199511132319.XAA26343@colombo.telesys-innov.fr> Subject: Re: 2.7.1 beta available To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Mon, 13 Nov 1995 23:19:40 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Rask Lambertsen" at Nov 13, 95 09:23:05 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Rask Lambertsen writes: > So that's why you were getting the README :-) :) > Is there any change of seeing some of the utils soon (compiled for '000)? > Robert, I tried finding some on your FTP site, but I couldn't. If Robert wants to, well just compile them. I'll try to generate plain '000 versions between two baby_cries. > /gnu/lib/gcc-lib/mc68000-at-amigaos > and do it right in one go? Vote ? :) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 01:50:58 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90280-2>; Tue, 14 Nov 1995 01:49:22 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 14 Nov 95 00:49 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 14 Nov 95 00:47 MET Message-Id: Subject: Re: 2.7.1 beta available To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 14 Nov 1995 00:47:26 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 500 > > > Is there any change of seeing some of the utils soon (compiled for '000)? > > Robert, I tried finding some on your FTP site, but I couldn't. > > If Robert wants to, well just compile them. I'll try to generate plain '000 > versions between two baby_cries. > > > /gnu/lib/gcc-lib/mc68000-at-amigaos > > and do it right in one go? > > Vote ? :) > maybe /gnu/lib/gcc-lib/mc68000-at-AmigaOS ;) walter -- ----- "I think I'll take this opportunity to remove my ears." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 11:35:52 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <90831-4>; Tue, 14 Nov 1995 11:34:15 +0200 Received: by colombo.telesys-innov.fr; Tue, 14 Nov 1995 10:34:08 GMT From: Philippe BRAND Message-Id: <199511141034.KAA28811@colombo.telesys-innov.fr> Subject: New 2.7.1 beta compiled using -mstackextend To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Tue, 14 Nov 1995 10:34:08 +0000 (WET) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I've just generated 2.7.1 C compiler using -mstackextend. file gcc271-amiga-stack.lha is available on both my site and on nic.funet.fi. PLEASE test this one as fast as possible, don't forget to lower your stack and better to delete env:GCCSTACK prior to compiling. DON'T FORGET that other GNU utils are NOT compiled with stackextend so keep a 50.000 stack on your current shell. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 12:21:26 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90831-3> convert rfc822-to-8bit; Tue, 14 Nov 1995 12:20:18 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 14 Nov 1995 11:20:06 +0100 (MET) From: Rask Lambertsen To: Philippe BRAND Cc: Amiga-Gcc Liste Subject: Re: New 2.7.1 beta compiled using -mstackextend In-Reply-To: <199511141034.KAA28811@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 14 Nov 1995, Philippe BRAND wrote: > I've just generated 2.7.1 C compiler using -mstackextend. > file gcc271-amiga-stack.lha is available on both my site and on nic.funet.fi. > > PLEASE test this one as fast as possible, don't forget to lower your stack > and better to delete env:GCCSTACK prior to compiling. > > DON'T FORGET that other GNU utils are NOT compiled with stackextend so > keep a 50.000 stack on your current shell. I'm a bit confused. Is only cc1 compiled using -mstackextend, or have gcc, ccp, as and ld also been compiled with -mstackextend? And I can't lower the stack to 50000 kB, as ENV:GCCSTACK is set to 32 kB. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 12:54:23 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <90599-1>; Tue, 14 Nov 1995 12:52:58 +0200 Received: by colombo.telesys-innov.fr; Tue, 14 Nov 1995 11:52:27 GMT From: Philippe BRAND Message-Id: <199511141152.LAA29310@colombo.telesys-innov.fr> Subject: Re: New 2.7.1 beta compiled using -mstackextend To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Tue, 14 Nov 1995 11:52:25 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Rask Lambertsen" at Nov 14, 95 11:20:06 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Rask Lambertsen writes: > I'm a bit confused. Is only cc1 compiled using -mstackextend, or have=20 > gcc, ccp, as and ld also been compiled with -mstackextend? And I can't=20 > lower the stack to 50000 kB, as ENV:GCCSTACK is set to 32 kB. gcc/cpp/cc1 compiled using -mstackextend. Wait a little bit for the rest, I only have a 68030/25 :) Tonight for binutils (as/ld). -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 13:32:25 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <90288-3>; Tue, 14 Nov 1995 13:31:59 +0200 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt; (5.65v3.0/1.1.8.2/24Jul95-0207PM) id AA12216; Tue, 14 Nov 1995 12:30:44 GMT Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/08Aug95-1153AM) id AA19824; Tue, 14 Nov 1995 12:31:37 GMT Date: Tue, 14 Nov 1995 12:31:37 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Amiga Ixemul Mailling list Cc: Amiga GCC Mailling list Subject: ixemul 41.5 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sould I try to use beta-test it with X11R6 now, or sould I wait for the one with AmiTCP ? Tip: When you do the integration of the AmiTCP inside ixemul, be shure that select() works OK. I have a feeling that it is not trivial... The old X11R5 libs, for example, were hacked to work with both AmiTCP and AS225 but when they were working with AmiTCP, a select() from the X stream returned imediatly sometimes causing pooling ! - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 13:51:51 1995 Received: from gryzmak.lodz.pdi.net ([194.92.208.1]) by nic.funet.fi with SMTP id <90678-3>; Tue, 14 Nov 1995 13:50:15 +0200 Received: from plukwa (robert@plukwa.lodz.pdi.net [194.92.208.7]) by gryzmak.lodz.pdi.net (8.6.10/1.40/L) with SMTP id MAA06657 for ; Tue, 14 Nov 1995 12:49:45 +0100 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Tue, 14 Nov 95 12:48:32 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <219c511d.u8t20e.27257-robert@plukwa.lodz.pdi.net> Subject: Re: 2.7.1 beta available In-Reply-To: (from Rask Lambertsen ) (at Mon, 13 Nov 1995 21:23:05 +0100 (MET)) Reply-To: robert@lodz.pdi.net Content-Length: 1721 To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Date: Tue, 14 Nov 95 12:48:32 Organization: PDi On Nov 13 Rask Lambertsen wrote: > On Mon, 13 Nov 1995, Philippe BRAND wrote: > > Is there any change of seeing some of the utils soon (compiled for '000)? > Robert, I tried finding some on your FTP site, but I couldn't. I bet You couldn't because they simple do not exist =o( All I can say is: SORRY. This happened because right now i'm a bit overloaded with my normal job (that is with that what I do for living) and simply cant do this (it takes quite a lot of time) If You want to have utils for Your 000 system then try to find newst FreshFish (#10 i think). Also if You want to compile all of them by Yourself there are sources ready to be compiled on plukwa (in gnu/src, all the sources i used are prefixed with R_; well almost all sources since somehow i managed to trash newst sed sources) > Regards, > > /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ > | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | > | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | > | Keyboard error: and are stuck - press to continue | > Sorry once again regards, Robert -- +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 13:59:52 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <90183-2>; Tue, 14 Nov 1995 13:56:10 +0200 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt; (5.65v3.0/1.1.8.2/24Jul95-0207PM) id AA13429; Tue, 14 Nov 1995 12:55:09 GMT Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/08Aug95-1153AM) id AA05093; Tue, 14 Nov 1995 12:56:02 GMT Date: Tue, 14 Nov 1995 12:55:44 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Amiga Ixemul Mailling list , Amiga GCC Mailling list , Amiga X11 mailling list Subject: X11 clients Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII For now on I will, almost every day, try to put a new X11 client on my Amiga-X11 page (http://hidro1.ist.utl.pt/amiga/amiga.html). XV and Xclock are already there (they could both fit in one HD). I would apreciate suggestions on the target processor I sould use. Are there many of you with a MC68000 still ? - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 14:46:40 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90620-3>; Tue, 14 Nov 1995 14:45:17 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA28366 (5.65c8/IDA-1.4.4); Tue, 14 Nov 1995 13:44:45 +0100 Received: by diva.gmd.de with UUCP id AA05712 (5.67b8/IDA-1.5); Tue, 14 Nov 1995 13:41:36 +0100 Date: Tue, 14 Nov 1995 13:41:36 +0100 Message-Id: <199511141241.AA05712@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: Pedro Miguel Sequeira Teixeira Cc: Amiga Ixemul Mailling list , Amiga GCC Mailling list , Amiga X11 mailling list Subject: X11 clients In-Reply-To: References: Hi, Pedro Miguel Sequeira Teixeira writes: > For now on I will, almost every day, try to put a new X11 client > on my Amiga-X11 page (http://hidro1.ist.utl.pt/amiga/amiga.html). > I would apreciate suggestions on the target processor I sould > use. Are there many of you with a MC68000 still ? Well, I still have my A2000 networked with my A4000 (using DNet for now, parnet gives me Enforcer hits), but I don't feel like running ports of UNIX X11 applications on the A2000. I think UNIX programs in general and X11 in particular take way too many resources for a 68000, even if I have 5MB of RAM. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 15:41:09 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90688-1>; Tue, 14 Nov 1995 15:38:25 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 14 Nov 95 14:38 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 14 Nov 95 14:32 MET Message-Id: Subject: X11 clients To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 14 Nov 1995 14:32:03 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1375 > Pedro Miguel Sequeira Teixeira writes: > > For now on I will, almost every day, try to put a new X11 client > > on my Amiga-X11 page (http://hidro1.ist.utl.pt/amiga/amiga.html). > > > I would apreciate suggestions on the target processor I sould > > use. Are there many of you with a MC68000 still ? > > Well, I still have my A2000 networked with my A4000 (using DNet for > now, parnet gives me Enforcer hits), but I don't feel like running > ports of UNIX X11 applications on the A2000. I think UNIX programs in > general and X11 in particular take way too many resources for a 68000, > even if I have 5MB of RAM. > i think X11 on a plain A2000 is a bit hard, indeed but it should be availabel for 2 reasons. 1. 68000 (better 68010) code works on every 680xx, so if the 68k version fails any other will do also. but if not is possible to conclude that the problem is cache,... or what ever nice things will be inside the next^x generation. 2. you can see it as sport to make things run fast on a plain 68k. :) conclusion: the 68k support should be done but it seems claer that with x11 the most things will be a bit 'slow' (on an RS6000 AIX you can see the windows building up :( ), baiscly the only think whats different is the flags to gcc. walter -- ----- "An apple a day keeps the... No, never mind!" --The Doctor. ----- From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 16:37:21 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90607-2>; Tue, 14 Nov 1995 16:35:41 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA08880 (5.65c8/IDA-1.4.4 for ); Tue, 14 Nov 1995 15:35:16 +0100 Received: by diva.gmd.de with UUCP id AA05828 (5.67b8/IDA-1.5); Tue, 14 Nov 1995 15:32:06 +0100 Date: Tue, 14 Nov 1995 15:32:06 +0100 Message-Id: <199511141432.AA05828@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: Walter Harms Cc: amiga-gcc-port@nic.funet.fi (amiga gcc-list) Subject: X11 clients In-Reply-To: References: Walter Harms writes: > i think X11 on a plain A2000 is a bit hard, indeed but it > should be availabel for 2 reasons. > 1. 68000 (better 68010) code works on every 680xx, so if > the 68k version fails any other will do also. but if not > is possible to conclude that the problem is cache,... or > what ever nice things will be inside the next^x generation. I do not follow the argument. I have yet to find a cache problem with compiled (application) programs. Apart from SetFunction() and fancy LoadSeg() stuff (we are talking about X11 ports here, what X11 port would do that?), there should be no cache problems. What can still happen is a byte aligned access which works on a >=68020 where it is very slow but GURUs on a 68000. You need a 68000 to find these. You can't with 68020 code. (Has anyone tried the Decigel like utilities that emulate some 68020 codes for the 68000?) > 2. you can see it as sport to make things run fast on a plain > 68k. :) I indeed consider it as part of the porting stage, but it seems to me like not many people today practice that sport. Porting time is a matter, as most people program their Amiga in the evening or at night. It's just easier and takes less time to type "configure" and "make", maybe even forgetting to remove the -g option found in most Makefiles and replacing it with -O2. It's also much easier to add a performance-drowning (see libstack.guide#performance) global -stackextend option than to have a look at the source if one can find places where the program recurses or alloca() whole files, isolate them and add stack checking and stack growing just in these places, or even a __stack variable to set a minimal, but sufficient stack. By using a global -stackextend, we condemn ourselves (and all the users of such software) to feel like our machine is not slick and fast but feels slow, not only when compared to other processors where the same software runs much faster because of the absence of such tests in every single and and even the smallest function. I claim that a global -stackextend is a huge waste of resources. Stack checking should be limited to some critical functions. Of course the larger the program, the more difficult it is to locate such functions. I am not against security, but I'm against a trade-off that I feel to expensive. Are those too strong opinions? Regards, Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 16:50:44 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <90688-3>; Tue, 14 Nov 1995 16:48:45 +0200 Received: by colombo.telesys-innov.fr; Tue, 14 Nov 1995 15:47:19 GMT From: Philippe BRAND Message-Id: <199511141547.PAA00140@colombo.telesys-innov.fr> Subject: Re: New 2.7.1 beta compiled using -mstackextend To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Tue, 14 Nov 1995 15:47:18 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Kamil Iskra" at Nov 14, 95 12:30:35 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Kamil Iskra writes: > > Wait a little bit for the rest, I only have a 68030/25 :) > > ??? My God!!! How much does it take to build, say, cc1? Complete gcc rebuilt 3 stages: more than 8 hours. > But I guesss you have more than avarage amount of memory, don't you? How > much is aproximately needed for recompiling GCC? Is 8 MB, which was once > stated in README, still enough or has the requirements increased? I have 42MB now, used to have 12MB. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 16:51:16 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <90678-2>; Tue, 14 Nov 1995 16:50:53 +0200 Received: by colombo.telesys-innov.fr; Tue, 14 Nov 1995 15:50:34 GMT From: Philippe BRAND Message-Id: <199511141550.PAA00158@colombo.telesys-innov.fr> Subject: Inlines & Libs To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Tue, 14 Nov 1995 15:50:33 +0000 (WET) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit For 2.7.1 release I'd like also to integrate into distribution as much inlines and libraires as possible. First candidate seems MUI. So I'm looking for help on this topic. Has anybody built such beasts already ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 20:29:10 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90678-1>; Tue, 14 Nov 1995 20:27:35 +0200 Received: from carina.rz.Uni-Osnabrueck.DE by funet.fi with SMTP (PP); Tue, 14 Nov 1995 20:27:20 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id TAA36988; Tue, 14 Nov 1995 19:27:04 +0100 From: Thomas Radtke Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.7.1/8.7.1) id TAA11586; Tue, 14 Nov 1995 19:27:04 +0100 Message-Id: <199511141827.TAA11586@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: X11 clients To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Tue, 14 Nov 1995 19:27:03 +0100 (NFT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511141432.AA05828@diva.gmd.de> from "Joerg Hoehle" at Nov 14, 95 03:32:06 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > I claim that a global -stackextend is a huge waste of resources. Stack > checking should be limited to some critical functions. Of course the > larger the program, the more difficult it is to locate such functions. I also think that stackextension should only be done in recursive functions. For all other cases the stack usage can easily be determined. Or am I missing something ? Would be nice if we had a switch to limit the extension to those functions :) (Yes, I know that it is a problem if function A calls B wich calls A again, but who uses such recursions of higher order ?) After assembling stage, the maximum stack usage (except for the above mentioned recursive cases) could be outputted to the user. Am I dreaming ? Thomas > Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 20:40:59 1995 Received: from loki.cee.hw.ac.uk ([137.195.24.101]) by nic.funet.fi with SMTP id <90110-2>; Tue, 14 Nov 1995 20:39:43 +0200 Received: from gilgamesh.cee.hw.ac.uk by loki.cee.hw.ac.uk with smtp tap_id root (Smail3.1.28.1 #97) id m0tFQGT-000eMYC; Tue, 14 Nov 95 18:39 GMT Received: by gilgamesh.cee.hw.ac.uk (Smail3.1.28.1 #102) id m0tFQGR-0001xqC; Tue, 14 Nov 95 18:39 GMT Date: Tue, 14 Nov 1995 18:39:23 +0000 (GMT) From: Erik Kotlar Johannessen To: Thomas Radtke cc: Joerg Hoehle , amiga-gcc-port@nic.funet.fi Subject: Re: X11 clients In-Reply-To: <199511141827.TAA11586@nereid.rz.Uni-Osnabrueck.DE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 14 Nov 1995, Thomas Radtke wrote: > After assembling stage, the maximum stack usage (except for the > above mentioned recursive cases) could be outputted to the > user. Am I dreaming ? Yes, there are things such as alloca() and dynamic arrays. -Erik -- Erik Johannessen - ceeekj@cee.hw.ac.uk http://www.cee.hw.ac.uk./~ceeekj/ From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 20:46:38 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90678-2>; Tue, 14 Nov 1995 20:46:03 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA24039 (5.65c8/IDA-1.4.4 for ); Tue, 14 Nov 1995 19:45:06 +0100 Received: by diva.gmd.de with UUCP id AA05939 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Tue, 14 Nov 1995 19:41:54 +0100 Date: Tue, 14 Nov 1995 19:41:54 +0100 Message-Id: <199511141841.AA05939@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: X11 clients In-Reply-To: <199511141827.TAA11586@nereid.rz.Uni-Osnabrueck.DE> References: <199511141432.AA05828@diva.gmd.de> <199511141827.TAA11586@nereid.rz.Uni-Osnabrueck.DE> Thomas Radtke writes: > I also think that stackextension should only be done in > recursive functions. For all other cases the stack usage can > easily be determined. Or am I missing something ? Would be nice Well it's not that easy, as a function, even without being recursive, can process arbitrarily input. So the stack usage cannot be known in advance. That's the theory. In practice, much more can be said, but the programmer is involved ("oh well, here I'm throwing the content of the include file in the stack using alloca(), so let's check and expand it first"). Note that problems may arise even before main() is called. Suppose you write a program which calls another program with a very long command line (let's say the full pathnames of all articles currently in comp.sys.amiga.*). Where's the space for the argv array stored? Nice startups use the stack because it's faster, doesn't pull malloc() from the library (tiny programs) and avoids cleanup problems at exit time, but do they check its size first? I admit that I wrote such a startup which relies on the caller to supply a big stack if it's using large inputs, but this is not safe to use as a general startup. > After assembling stage, the maximum stack usage (except for the > above mentioned recursive cases) could be outputted to the > user. Am I dreaming ? The compiler can't know what functions are going to be called through pointers, thus it doesn't know enough to output that information. BTW, does the stack-overflow code linked in when compiling with ixemul use SIGSEGV? Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 23:21:26 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90069-4> convert rfc822-to-8bit; Tue, 14 Nov 1995 23:20:49 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 14 Nov 1995 22:20:39 +0100 (MET) From: Rask Lambertsen To: Joerg Hoehle Cc: Walter Harms , amiga gcc-list Subject: Re: X11 clients In-Reply-To: <199511141432.AA05828@diva.gmd.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 14 Nov 1995, Joerg Hoehle wrote: > Walter Harms writes: > > i think X11 on a plain A2000 is a bit hard, indeed but it > > should be availabel for 2 reasons. > > > 1. 68000 (better 68010) code works on every 680xx, so if > > the 68k version fails any other will do also. but if not > > is possible to conclude that the problem is cache,... or > > what ever nice things will be inside the next^x generation. > > I do not follow the argument. I have yet to find a cache problem with > compiled (application) programs. Apart from SetFunction() and fancy > LoadSeg() stuff (we are talking about X11 ports here, what X11 port LoadSeg() should be no problem, it correctly handles processors with cache. > would do that?), there should be no cache problems. What can still > happen is a byte aligned access which works on a >=68020 where it is > very slow but GURUs on a 68000. You need a 68000 to find these. You > can't with 68020 code. (Has anyone tried the Decigel like utilities You can't do it with 68000 code on a 68020+ either. > > 2. you can see it as sport to make things run fast on a plain > > 68k. :) > > I indeed consider it as part of the porting stage, but it seems to me > like not many people today practice that sport. Porting time is a > matter, as most people program their Amiga in the evening or at night. > It's just easier and takes less time to type "configure" and "make", > maybe even forgetting to remove the -g option found in most Makefiles > and replacing it with -O2. I can't believe it: Don't the Makefiles use uptimization by default? > It's also much easier to add a performance-drowning (see > libstack.guide#performance) global -stackextend option than to have a > look at the source if one can find places where the program recurses > or alloca() whole files, isolate them and add stack checking and stack ^^^^^^^^^^^^^^^^^^^^ Do some programmers really do that? [snip] > I claim that a global -stackextend is a huge waste of resources. Stack > checking should be limited to some critical functions. Of course the > larger the program, the more difficult it is to locate such functions. > I am not against security, but I'm against a trade-off that I feel to > expensive. So I can expect the new gcc with automatic stack extension to be even slower than usual? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 23:56:46 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90565-3>; Tue, 14 Nov 1995 23:56:20 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tFTdK-000QzRC; Tue, 14 Nov 95 23:15 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0akm@wyst.hobby.nl>; Tue, 14 Nov 95 11:47:17 CET Message-Id: <9511141047.0akm@wyst.hobby.nl> Date: Tue, 14 Nov 1995 11:47:14 +0000 (CET) In-Reply-To: from "Walter Harms" at Nov 14, 95 00:47:26 am Content-Type: text Content-Length: 971 From: hans@wyst.hobby.nl (Hans Verkuil) To: Walter.Harms@arbi.informatik.uni-oldenburg.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: 2.7.1 beta available > > > Is there any change of seeing some of the utils soon (compiled for '000)? > > > Robert, I tried finding some on your FTP site, but I couldn't. > > > > If Robert wants to, well just compile them. I'll try to generate plain '000 > > versions between two baby_cries. > > > > > /gnu/lib/gcc-lib/mc68000-at-amigaos > > > and do it right in one go? > > > > Vote ? :) > > > maybe > /gnu/lib/gcc-lib/mc68000-at-AmigaOS Aargghh! No capitals please! What about m68k-at-amigaos? Short and to the point. Or indeed mc68000-at-amigaos if each chip gets its own directory. I like m68k-at-amigaos better, though. Can't wait until a ppc-at-amigaos appears! Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Nov 14 23:57:47 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90847-1>; Tue, 14 Nov 1995 23:57:34 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tFTde-000QzRC; Tue, 14 Nov 95 23:15 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0akt@wyst.hobby.nl>; Tue, 14 Nov 95 21:57:31 CET Message-Id: <9511142057.0akt@wyst.hobby.nl> Date: Tue, 14 Nov 1995 21:57:18 +0000 (CET) Content-Type: text Content-Length: 4571 From: hans@wyst.hobby.nl (Hans Verkuil) To: fnf@amigalib.com, phb@colombo.telesys-innov.fr, ixemul@listserv.funet.fi, amiga-gcc-port@nic.funet.fi Subject: Important: replace gcc by gccv! gcc is buggy... Important: do NOT use the 'gcc' executable. This executable will most probably cause a crash if you try to Ctrl-C a make-run. Use 'gccv' instead (delete 'gcc' and rename 'gccv' to 'gcc'). There is no difference between the two, except for the fact that 'gccv' supports the -pipe option and handles Ctrl-C correctly. Fred and Philippe: Please apply the patch at the end of this mail to the file config/m68k/xm-amigados.h from the gcc-distribution (gcc-2.7.0, to be precise). You will probably also need to change one or more makefiles and x-amigados in config/m68k. I'll leave that to someone with a faster Amiga than I have :-). The makefiles must change because there is no longer any need for a separate gccv executable. 'gcc' uses the ssystem() function to spawn cpp, cc1, etc. while 'gccv' uses a vfork()/execve() pair. However, ssystem() doesn't handle Ctrl-C correctly, while vfork()/execve() does. So just ditch the old gcc and make gccv the default instead. Philippe, can you add this fix for 2.7.1? Besides that the ssystem() function WILL DISAPPEAR in ixemul.library 42.0. It is no longer necessary and it is incompatible with the new Ctrl-C handling. I've wondered for some time why using Ctrl-C while gcc was running during a make often caused a crash. Well, ssystem() was the culprit. What is happening is that after a Ctrl-C the parent (gcc) is killed, while the child (say, cpp) keeps running. Once the child exits, the control flow gets back in the ssystem() function in ixemul.library, which is unaware that the parent has been gone by now. Fireworks are the result. Similar results can probably still occur if you use vfork/execve to spawn a non-ixemul-using executable. execve reverts to the old ssystem() behavior in that case. Although I hope that ignoring all Unix signals until the spawned child returns will prevent this from happening. I have added a 'important.readme' file to the ixemul distribution and a requester will popup when ssystem() is called pointing to that document. Fred: please remove the ixemul-41.5 archive I've uploaded last week, it's quite obsolete by now :-). Expect a new ixemul-42.0 archive hopefully next weekend. 42.0 is actually smaller than the current version and has several new features, removed lots of old cruft and fixed various bugs. 22 new items where added to the NEWS file! Hans ------------------ cut here ---------------- *** xm-amigados.h.orig Tue Nov 14 11:25:13 1995 --- xm-amigados.h Tue Nov 14 11:25:43 1995 *************** *** 41,83 **** (i.e. its output should be piped to the next one.) */ - #ifndef AMIGADOS_FORK_GCC - - /* This version uses a more or less amigados-conformant way of running a - program (in the context of the parent). If you want to use -pipe however, - you'll have to use the vfork() version afterwards. - Phil.B: 29-May-94 quick hack (number 20 added to length) because xgcc - doesn't work. - */ - - #define PEXECUTE(SEARCH_FLAG,PROGRAM,ARGV,NOT_LAST) \ - ({char *_argline; \ - int _arglinelength, _i; \ - \ - for (_i = 1, _arglinelength=0; ARGV[_i]; ++_i) \ - _arglinelength += strlen(ARGV[_i]) + 1; \ - \ - _arglinelength += strlen(PROGRAM) + 20 + 1; \ - \ - if (!(_argline = (char *)alloca(_arglinelength))) \ - pfatal_with_name ("alloca"); \ - \ - strcpy(_argline, PROGRAM); \ - for (_i = 1; ARGV[_i]; ++_i) \ - { \ - strcat(_argline, " "); \ - strcat(_argline, ARGV[_i]); \ - } \ - \ - ssystem(_argline); }) \ - - #define PEXECUTE_RESULT(STATUS, COMMAND) \ - ({ STATUS = COMMAND.pid; }) - - #else - - /* the vfork() version. This one has the drawback, that gcc is not - interruptible when started from make, since ixemul.library doesn't yet - propagate ^C to subprocesses. */ - #define PEXECUTE(SEARCH_FLAG,PROGRAM,ARGV,NOT_LAST) \ ({int (*_func)() = (SEARCH_FLAG ? execv : execvp); \ --- 41,44 ---- *************** *** 163,168 **** #define PEXECUTE_RESULT(STATUS, COMMAND) \ ({ wait (& STATUS); }) - - #endif /* AMIGADOS_FORK_GCC */ /* the following macros are stolen more or less from xm-vms.h ... */ --- 124,127 ---- ------------------ cut here ---------------- -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 00:00:39 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90751-4> convert rfc822-to-8bit; Wed, 15 Nov 1995 00:00:06 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 14 Nov 1995 22:59:55 +0100 (MET) From: Rask Lambertsen To: Joerg Hoehle Cc: amiga-gcc-port@nic.funet.fi Subject: Re: X11 clients In-Reply-To: <199511141841.AA05939@diva.gmd.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 14 Nov 1995, Joerg Hoehle wrote: > Note that problems may arise even before main() is called. Suppose you > write a program which calls another program with a very long command > line (let's say the full pathnames of all articles currently in > comp.sys.amiga.*). Where's the space for the argv array stored? Nice > startups use the stack because it's faster, doesn't pull malloc() from > the library (tiny programs) and avoids cleanup problems at exit time, > but do they check its size first? I admit that I wrote such a startup > which relies on the caller to supply a big stack if it's using large > inputs, but this is not safe to use as a general startup. Any serious startup code for the Amiga will call AllocMem() directly to allocate the memory. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 00:04:44 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90292-4> convert rfc822-to-8bit; Wed, 15 Nov 1995 00:04:18 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 14 Nov 1995 23:04:01 +0100 (MET) From: Rask Lambertsen To: Hans Verkuil Cc: Walter.Harms@arbi.informatik.uni-oldenburg.de, amiga-gcc-port@nic.funet.fi Subject: Re: 2.7.1 beta available In-Reply-To: <9511141047.0akm@wyst.hobby.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 14 Nov 1995, Hans Verkuil wrote: > > > > Is there any change of seeing some of the utils soon (compiled for '000)? > > > > Robert, I tried finding some on your FTP site, but I couldn't. > > > > > > If Robert wants to, well just compile them. I'll try to generate plain '000 > > > versions between two baby_cries. > > > > > > > /gnu/lib/gcc-lib/mc68000-at-amigaos > > > > and do it right in one go? > > > > > > Vote ? :) > > > > > maybe > > /gnu/lib/gcc-lib/mc68000-at-AmigaOS > > Aargghh! No capitals please! What about m68k-at-amigaos? Short and to the > point. Or indeed mc68000-at-amigaos if each chip gets its own directory. I > like m68k-at-amigaos better, though. Can't wait until a ppc-at-amigaos > appears! What does the other 68000 based platforms use? mc68000 or m68k? Or both? (please check as appropiate ;-)) Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 00:37:18 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90110-1> convert rfc822-to-8bit; Wed, 15 Nov 1995 00:36:21 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 14 Nov 1995 23:36:04 +0100 (MET) From: Rask Lambertsen To: Philippe BRAND Cc: Amiga-Gcc Liste Subject: Updated README coming soon (Was: Re: New 2.7.1 beta compiled using -mstackextend) In-Reply-To: <199511141152.LAA29310@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I'm now working on an updated README for GCC 2.7.1 (even though I should be in bed by now). On Tue, 14 Nov 1995, Philippe BRAND wrote: > Rask Lambertsen writes: > > > I'm a bit confused. Is only cc1 compiled using -mstackextend, or have=20 > > gcc, ccp, as and ld also been compiled with -mstackextend? And I can't=20 > > lower the stack to 50000 kB, as ENV:GCCSTACK is set to 32 kB. > > gcc/cpp/cc1 compiled using -mstackextend. > > Wait a little bit for the rest, I only have a 68030/25 :) > Tonight for binutils (as/ld). So references to ENV:GCCSTACK in the readme can safely be removed? I'll probably make a whole new section about the inline header files, as a lot has changed. In the "What was new in previous releases" section, I'd like to cut at least the pre 2.6.0 part, and preferably also the pre 2.6.3 part. Mail me or post to the list if you think this is too much or too little. Is it about time to bump the 10 MB figure for a minimal installation? I have a feeling that 11-12 MB is closer. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 02:11:19 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <90831-4>; Wed, 15 Nov 1995 02:09:49 +0200 Received: by colombo.telesys-innov.fr; Wed, 15 Nov 1995 01:09:07 GMT From: Philippe BRAND Message-Id: <199511150109.BAA02602@colombo.telesys-innov.fr> Subject: Re: X11 clients To: Thomas.Radtke@rz.Uni-Osnabrueck.DE (Thomas Radtke) Date: Wed, 15 Nov 1995 01:09:06 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199511141827.TAA11586@nereid.rz.Uni-Osnabrueck.DE> from "Thomas Radtke" at Nov 14, 95 07:27:03 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Thomas Radtke writes: > After assembling stage, the maximum stack usage (except for the > above mentioned recursive cases) could be outputted to the > user. Am I dreaming ? Could people make in fact some benchs ? Compiling with 2.7.0 and 2.7.1 stackextend ? Just to see exactly what is the overhead. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 11:25:16 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90688-1>; Wed, 15 Nov 1995 11:23:24 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 15 Nov 95 10:22:02 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <219d8046.u8t20e.83446-robert@plukwa.lodz.pdi.net> Subject: Re: X11 clients In-Reply-To: (from Rask Lambertsen ) (at Tue, 14 Nov 1995 22:20:39 +0100 (MET)) Reply-To: robert@lodz.pdi.net Content-Length: 2057 To: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi Date: Wed, 15 Nov 95 10:22:02 Organization: PDi On Nov 14 Rask Lambertsen wrote: > On Tue, 14 Nov 1995, Joerg Hoehle wrote: > > > I indeed consider it as part of the porting stage, but it seems to me > > like not many people today practice that sport. Porting time is a > > matter, as most people program their Amiga in the evening or at night. > > It's just easier and takes less time to type "configure" and "make", > > maybe even forgetting to remove the -g option found in most Makefiles > > and replacing it with -O2. > > I can't believe it: Don't the Makefiles use uptimization by default? From my own experince gained during compiling various utils for my gcc270-utils i can asure You that only once i didn't have to add -O2 and remove -g by myself. MOst of the Makefiles generated by configure use rather -g than any optimization option. And to be honest it does make sense, when You are compiling something new, there is rather big chance that You will need to inspect some unexpected behaviour nad You will need debugging information. When You release something as binary You can either strip extra info in the executable using strip (BTW: is there strip for Amiga?) or recompile with optimization on. > > Regards, > > /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ > | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | > | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | > | Keyboard error: and are stuck - press to continue | > Robert -- +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 11:51:43 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90831-4>; Wed, 15 Nov 1995 11:50:16 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA14222 (5.65c8/IDA-1.4.4 for ); Wed, 15 Nov 1995 10:49:59 +0100 Received: by diva.gmd.de with UUCP id AA05958 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Wed, 15 Nov 1995 10:46:47 +0100 Date: Wed, 15 Nov 1995 10:46:47 +0100 Message-Id: <199511150946.AA05958@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: 2.7.1 beta available In-Reply-To: References: <9511141047.0akm@wyst.hobby.nl> Rask Lambertsen writes: > What does the other 68000 based platforms use? mc68000 or m68k? Or both?=20 > (please check as appropiate ;-)) I've seen m68k in UNIX config files (mostly for Sun3 and NeXt). These systems generally use a >=68020 :) Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 12:15:37 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <90063-3>; Wed, 15 Nov 1995 12:14:38 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 15 Nov 95 11:13:11 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <219d8c44.u8t20e.b1fd-robert@plukwa.lodz.pdi.net> Subject: Re: 2.7.1 beta available In-Reply-To: <9511141047.0akm@wyst.hobby.nl> (from hans@wyst.hobby.nl (Hans Verkuil)) (at Tue, 14 Nov 1995 11:47:14 +0000 (CET)) Reply-To: robert@lodz.pdi.net Content-Length: 1418 To: amiga-gcc-port@nic.funet.fi Date: Wed, 15 Nov 95 11:13:11 Organization: PDi On Nov 14 Hans Verkuil wrote: > > /gnu/lib/gcc-lib/mc68000-at-AmigaOS > > Aargghh! No capitals please! What about m68k-at-amigaos? Short and to the Why so upset with capitals?? Amiga file systems are not case sensitive > point. Or indeed mc68000-at-amigaos if each chip gets its own directory. I > like m68k-at-amigaos better, though. Can't wait until a ppc-at-amigaos > appears! I also think that it should read m68k-(at|AT)-(a|A)miga(OS|os) why? because it somewhat compatible with machine descriptoin used with configure scripts > > Hans > > -- > Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, > The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl > > "...and the princesses were beautiful as the day is long and so noble they > could pee through a dozen mattresses --" (Terry Pratchett) > Robert -- +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 12:30:37 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90292-3>; Wed, 15 Nov 1995 12:29:30 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA16875 (5.65c8/IDA-1.4.4 for ); Wed, 15 Nov 1995 11:29:20 +0100 Received: by diva.gmd.de with UUCP id AA05964 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Wed, 15 Nov 1995 11:26:09 +0100 Date: Wed, 15 Nov 1995 11:26:09 +0100 Message-Id: <199511151026.AA05964@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: X11 clients In-Reply-To: <219d8046.u8t20e.83446-robert@plukwa.lodz.pdi.net> References: <219d8046.u8t20e.83446-robert@plukwa.lodz.pdi.net> Robert Ramiega writes: > > I can't believe it: Don't the Makefiles use uptimization by default? > From my own experince gained during compiling various utils for my > gcc270-utils i can asure You that only once i didn't have to add -O2 and remove Same for me. BTW, -O2 is not portable, as many cc only know -O. > -g by myself. MOst of the Makefiles generated by configure use rather -g than > any optimization option. And to be honest it does make sense, when You are > compiling something new, there is rather big chance that You will need to > inspect some unexpected behaviour nad You will need debugging information. I don't think it makes sense, as what we get in such archives is distribution/production software, not software in an early test phase. I've installed many programs on Suns and usually had no reason to compile with -g and do any debugging. Maybe the reason I had no problems is that most of such software has been tested on Suns already before the archive was made. I believe we find -g in Makefiles because it's what the programmers who make the archives use for themselves. When they create an archive they just don't change the Makefile and assume that it's the least thing the people installing the software can do. > When You release something as binary You can either strip extra info in the > executable using strip (BTW: is there strip for Amiga?) or recompile with > optimization on. The NDK contains stripa, many non-developers can use PowerPacker or any packer, load a file with the "remove debug and symbol hunks" option and saved it back. If I remember right, there's even an option to coalesce hunks of same type together. Rask Lambertsen writes: > > or alloca() whole files, isolate them and add stack checking and stack > ^^^^^^^^^^^^^^^^^^^^ > Do some programmers really do that? Cpp is said to do that. When it comes to speed, it's much more interesting to use large blocks of memory than to read small chunks. Modern UNIX-SW even uses mmap(). Compare the speed of C:Search with e/fgrep. GNU-software generally isn't picky about memory usage, but this provides for very fast implementations. See how DiskSpeed reports a considerable increase when using buffers bigger than 512 bytes. See how UNIX file i/o (or is this the C stdlib implementation?) is buffered to 8KB chunks (at least under SunOS4). See how libnix and ixemul libc.a are faster than others because they do (among others) buffering in reasonable sizes. I'm still surprised how fast GNUEmacs implements the incremental search even on my 68000 machine, whereas MG which I used before is very slow on large files. What's the difference? at least memory organization: large chunks vs. every line stored separately. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 12:45:19 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90069-4>; Wed, 15 Nov 1995 12:43:09 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA17716 (5.65c8/IDA-1.4.4 for ); Wed, 15 Nov 1995 11:42:49 +0100 Received: by diva.gmd.de with UUCP id AA05970 (5.67b8/IDA-1.5); Wed, 15 Nov 1995 11:39:39 +0100 Date: Wed, 15 Nov 1995 11:39:39 +0100 Message-Id: <199511151039.AA05970@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: hans@wyst.hobby.nl (Hans Verkuil) Cc: amiga-gcc-port@nic.funet.fi Subject: Important: replace gcc by gccv! gcc is buggy... In-Reply-To: <9511142057.0akt@wyst.hobby.nl> References: <9511142057.0akt@wyst.hobby.nl> Hans Verkuil writes: > Besides that the ssystem() function WILL DISAPPEAR in ixemul.library 42.0. Perhaps it would be great to distribute a tiny archive that would patch the ssystem() syscall, display a requester "ssystem() is soon going to be removed from ixemul.library, please report use to amiga-gcc-port or ixemul-list. Continue | sigsegv". That way people here could test it and report uses of that function in programs they run. Now we at least know that gcc itself uses it :) Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 12:49:28 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90110-3>; Wed, 15 Nov 1995 12:48:02 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id KAA07740 for ; Wed, 15 Nov 1995 10:46:28 GMT From: Lars Hecking Message-Id: <199511151047.KAA20069@mostar.nmrc.ucc.ie> Subject: Re: 2.7.1 beta available To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Wed, 15 Nov 1995 10:47:16 +0000 (GMT) In-Reply-To: <9511141047.0akm@wyst.hobby.nl> from "Hans Verkuil" at Nov 14, 95 11:47:14 am Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 154 > like m68k-at-amigaos better, though. Can't wait until a ppc-at-amigaos > appears! I'm afraid we'll have to put in some work to make it appear. ;) From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 13:06:39 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89292-4>; Wed, 15 Nov 1995 13:05:40 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA07516; Wed, 15 Nov 1995 12:04:22 +0100 Date: Wed, 15 Nov 1995 12:04:22 +0100 (MET) From: Kamil Iskra Subject: Re: Inlines & Libs To: Philippe BRAND cc: Amiga-Gcc Liste In-Reply-To: <199511141550.PAA00158@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 14 Nov 1995, Philippe BRAND wrote: > For 2.7.1 release I'd like also to integrate into distribution as much > inlines and libraires as possible. First candidate seems MUI. > > So I'm looking for help on this topic. Has anybody built such beasts > already ? I can build them if I have necessary information, namely fd files and clib files. If 3rd party libraries use CBM conventions, like including plain prototypes only in clib files, I guess that FD2Inline won't have any problems with generating inlines. I have MUI 2.3 installed somewhere on my harddrive so I can build inlines for it, but I've heard that 3.0 appeard a few days ago - one would think that it'll have more functions. So if anybody has it, please contact with me. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 13:06:44 1995 Received: from hpcl.cti.gr ([150.140.91.21]) by nic.funet.fi with SMTP id <89939-2>; Wed, 15 Nov 1995 13:05:25 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA00770 (5.67a8/IDA-1.5 for ); Wed, 15 Nov 1995 12:53:32 +0200 From: Kriton Kyrimis Message-Id: <199511151053.AA00770@hpcl.cti.gr> Subject: Re: X11 clients To: robert@lodz.pdi.net Date: Wed, 15 Nov 1995 12:53:30 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi (gcc) Reply-To: kyrimis@theseas.softlab.ece.ntua.gr In-Reply-To: <219d8046.u8t20e.83446-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Nov 15, 95 10:22:02 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1193 > any optimization option. And to be honest it does make sense, when You are > compiling something new, there is rather big chance that You will need to > inspect some unexpected behaviour nad You will need debugging information. > When You release something as binary You can either strip extra info in the Actually, I think the -g is there so that the developers can easily investigate bug reports. I would think its is far more likely for the average GNU software installer to submit a bug report and revert to the previous version until the bug is fixed, than to try and debug a huge program with which they are not familiar. BTW, I think that the simplest way to change the compilation flags is to do something like: make CFLAGS=-O2 LDFLAGS=-s rather than editing the Makefile. > is there strip for Amiga? Try: util/misc/Strip37_2.lha or dev/misc/MYSTRIP.lha from aminet. There should also be a version of strip in the binutils package. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Just remember what curiosity did to the cat." "Why do you think they have nine lives? And why do you think Time Lords have twelve?" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 13:19:42 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <88947-3>; Wed, 15 Nov 1995 13:18:31 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 15 Nov 95 12:15:49 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <219d9af3.u8t20e.ae3f7-robert@plukwa.lodz.pdi.net> Subject: Re: X11 clients In-Reply-To: <199511151053.AA00770@hpcl.cti.gr> (from Kriton Kyrimis ) (at Wed, 15 Nov 1995 12:53:30 +0200 (EET)) Reply-To: robert@lodz.pdi.net Content-Length: 1591 To: kyrimis@theseas.softlab.ece.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Date: Wed, 15 Nov 95 12:15:49 Organization: PDi On Nov 15 Kriton Kyrimis wrote: > > any optimization option. And to be honest it does make sense, when You are > > compiling something new, there is rather big chance that You will need to > > inspect some unexpected behaviour nad You will need debugging information. > > When You release something as binary You can either strip extra info in the > > Actually, I think the -g is there so that the developers can easily > investigate bug reports. I would think its is far more likely for the average > GNU software installer to submit a bug report and revert to the previous > version until the bug is fixed, than to try and debug a huge program with > which they are not familiar. OK I agree with Your point of view. Actually when writing that letter I was thinking in terms of rather small programs from gcc 270 utils and somehow it escaped me that ther are bigger applications =o) > > BTW, I think that the simplest way to change the compilation flags is to do > something like: > make CFLAGS=-O2 LDFLAGS=-s > rather than editing the Makefile. Well never thought about that way, but i prefer editing files by hand. > > > is there strip for Amiga? > > Try: > util/misc/Strip37_2.lha > or dev/misc/MYSTRIP.lha > from aminet. Thanks > > There should also be a version of strip in the binutils package. > -- > Kriton (INTERNET: kyrimis@hpcl.cti.gr) > (WWW: http://www.hpcl.cti.gr/~kyrimis > ----- > "Just remember what curiosity did to the cat." > "Why do you think they have nine lives? And why do you think Time Lords have > twelve?" > ----- > Robert From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 13:33:10 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89580-4>; Wed, 15 Nov 1995 13:31:51 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA09819; Wed, 15 Nov 1995 12:28:10 +0100 Date: Wed, 15 Nov 1995 12:28:09 +0100 (MET) From: Kamil Iskra Subject: Re: New 2.7.1 beta compiled using -mstackextend To: Philippe BRAND cc: Amiga-Gcc Liste In-Reply-To: <199511141034.KAA28811@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 14 Nov 1995, Philippe BRAND wrote: > I've just generated 2.7.1 C compiler using -mstackextend. > file gcc271-amiga-stack.lha is available on both my site and on nic.funet.fi. > > PLEASE test this one as fast as possible, don't forget to lower your stack > and better to delete env:GCCSTACK prior to compiling. I have the following comments: 1. It's hard for me to say whether stack extension works as it should, because on start all programs but "cc1" set their stack to 250 KB (or maybe their stack is set by "gcc" or "ixemul" or whatever else - I know nothing about the internals :-). "cc1" sets its stack to 50 KB and it seems to work fine (but I don't have any source that would need more stack :-(. 2. When I set shell stacksize to 4096 bytes and break gcc (^C) during compiling stage (cc1), shell stacksize is set to 50000 byes! If cc1 terminates normally, initial shell stacksize is preserved. Everything that I have written above was true in 2.7.0, too. 3. "-m68020-40" and "-mc68020" are not fully supported again (argh!:-). In both cases, "ld" is not called with "-fl libm020". Additionally, in case of "-m68020-40", preprocessor is not called with "-Dmc68020" and assembler is not called with "-mc68020". / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 14:32:27 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <90729-1>; Wed, 15 Nov 1995 14:30:11 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id HAA23890; Wed, 15 Nov 1995 07:28:43 -0500 (from cz253) Message-Id: <199511151228.HAA23890@kanga.INS.CWRU.Edu> Date: Wed, 15 Nov 1995 07:28:43 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: kiskra@ernie.icslab.agh.edu.pl Subject: Re: New 2.7.1 beta compiled using -mstackextend Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from kiskra@ernie.icslab.agh.edu.pl of Wed, 15 Nov >3. "-m68020-40" and "-mc68020" are not fully supported again >(argh!:-). In both cases, "ld" is not called with "-fl libm020". >Additionally, in case of "-m68020-40", preprocessor is not called with >"-Dmc68020" and assembler is not called with "-mc68020". Have you checked the specs file? .....Dave From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 14:45:23 1995 Received: from trappist.elis.rug.ac.be ([157.193.67.1]) by nic.funet.fi with SMTP id <89152-2>; Wed, 15 Nov 1995 14:43:57 +0200 Received: from ibmpar.elis.rug.ac.be by trappist.elis.rug.ac.be with SMTP id AA04145 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 13:43:56 +0100 Received: by ibmpar.elis.rug.ac.be (AIX 3.2/UCB 5.64/4.03) id AA12899; Wed, 15 Nov 1995 13:48:30 GMT From: bvassche@ibmpar.elis.rug.ac.be (Bart Van Assche) Message-Id: <9511151348.AA12899@ibmpar.elis.rug.ac.be> Subject: Re: Automatic Stack Extension To: amiga-gcc-port@nic.funet.fi Date: Wed, 15 Nov 1995 13:48:29 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3731 In a previous message Joerg Hoehle wrote: > > Thomas Radtke writes: > > I also think that stackextension should only be done in > > recursive functions. For all other cases the stack usage can > > easily be determined. Or am I missing something ? Would be nice > > Well it's not that easy, as a function, even without being recursive, > can process arbitrarily input. So the stack usage cannot be known in > advance. That's the theory. In practice, much more can be said, but > the programmer is involved ("oh well, here I'm throwing the content of > the include file in the stack using alloca(), so let's check and > expand it first"). > > > After assembling stage, the maximum stack usage (except for the > > above mentioned recursive cases) could be outputted to the > > user. Am I dreaming ? > > The compiler can't know what functions are going to be called through > pointers, thus it doesn't know enough to output that information. > Although I'm not very experienced with GCC, I will try to answer a few of these questions. (I started research on a topic in the domain of automatically parallellizing compilers in september. So I'm familiar with several of the mentioned subjects) If I understood correctly, there are three problems that have to do with the stack size not being sufficient: 1. ordinary stack overflow caused by non-recursive and non-dynamic stack allocations 2. stack overflow caused by dynamic allocation - alloca() and varying array sizes. 3. stack overflow caused by recursive or mutually recursive functions The first point is usually made a responsibility of the user: "before you run the program, make the stack at least ... Kb". By analyzing the call-graph (a tree in this case) the maximum amount of stack needed can even be determined by the compiler. For the second point, it is no longer possible to determine the maximum possible stack size statically. A possible solution is stack checking in every function. Because of the introduced overhead this is not an attractive solution. Two other solutions are possible: - allocate enough stack for the static allocations, and only do stack checking and eventually extensions for dynamic allocations - allocate enough stack for the static allocations, and replace the dynamic allocations with a call to malloc. Eventually this can be optimized by reserving a minimum size for the items to allocate dynamically, and only do dynamic allocation if the minimum size is exceeded. In both cases it is necessary to have a pointer allocated on the stack to the dynamically allocated region, but alloca() does need this pointer as well. For the third point, if you want to know which functions call one another recursively, the call graph has to be analyzed. Then you can insert stack extension only for these functions. Although I do not known how much call graph analysis GCC does, it will not be a trivial job to implement this. Anyway, some people already developed approximate but good enough methods to analyze programs in such a way that it becomes clear which functions are recursive or mutually recursive. Some of that work is: M.W.Hall, "Managing interprocedural optimization", PhD thesis, Rice University, Houston, TX, apr. 1991. K.D.Cooper,K.Kennedy,"Interprocedural side-effect analysis in linear time", Proc. ACM SIGPLAN'88 Conf. Programming Languages Design and Implementation, SIGPLAN notices, vol. 23, no. 7, pp 57-66, 1988. A good overall solution is maybe to replace only the dynamic allocations, and leave the other aspects as they were before ? -- __ /_/ /_/art Van Assche Research Associate University of Ghent - ELIS laboratory St.-Pietersnieuwstraat 41 9000 Gent Belgium E-mail: Bart.VanAssche@elis.rug.ac.be From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 14:51:03 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89040-2>; Wed, 15 Nov 1995 14:49:54 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFhNk-0004nYC; Wed, 15 Nov 95 05:56 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: your mail To: cbell@getnet.com (Clinton Ball) Date: Wed, 15 Nov 1995 05:56:03 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511122023.NAA27403@getnet.com> from "Clinton Ball" at Nov 12, 95 01:23:19 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1425 > I am posting to this list because I have not received a response > on either gnu.g++.help or comp.sys.amiga.programmer. I hope > someone here can help. I have an Amiga 2000 with GVP GForce 030 > and 68882 FPU. Have you installed the 030+fpu version of the ixemul library, or are you using the regular 68000 version which uses software floating point? If you just run the GNU startup script, you get the soft version. This is a problem that should be mentioned in the docs, and actually needs to be fixed somehow. Since you can't change the CD, your best option is to copy the appropriate ixemul.library to somewhere other than the CD and make sure that directory appears in your LIBS: assign path ahead of GNU:sys/libs on the CD. Another option is to install CDWrite and copy GNU:sys/libs/ixemul040fpu.library to GNU:sys/libs/ixemul.library. > The printf lines give the expected output but the > cout lines produce garbage. On my 4000, using the 040+fpu version of ixemul.libary I get: The double number dnum = 28.845 The double number dnum2 = 14 The dnum2 * dnum = 403.83 The floating point number fnum = 28.845 The integer number inum = 14 The fnum * inum = 403.83 The floating point number fnum = 28.844999 The integer number inum = 14 The fnum * inum = 403.829987 > Is this a bug in gcc? There are known floating point problems in the current ixemul.library when using non-fpu versions. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 14:52:58 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89441-3>; Wed, 15 Nov 1995 14:52:35 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA26040 (5.65c8/IDA-1.4.4 for ); Wed, 15 Nov 1995 13:52:25 +0100 Received: by diva.gmd.de with UUCP id AA06050 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Wed, 15 Nov 1995 13:49:15 +0100 Date: Wed, 15 Nov 1995 13:49:15 +0100 Message-Id: <199511151249.AA06050@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: ixemul/libnix and stderr Hi, I read (can't remember if it was in ixemul or libnix) that stderr is set to either: pr_CES is not NULL Open("*") else if not null stdout otherwise. when I think of it, I dislike the use of stdout. The only use I could see is for a Workbench program, when the startup opens a window for stdout/Output(). But then the startup should also set pr_ConsoleTask to this window. How do I have to setup my programs in an Amiga environment (e.g. not use pdksh >2 redirection) when I want _not_ to see errors (e.g. I want to get pure pipe output (let's say of gzip -c) or use GNUEmacs with M-! or M-|, which on UNIX would discards output to stderr)? I think not using stdout (e.g. using /dev/null) is the better choice. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 15:14:28 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89253-2>; Wed, 15 Nov 1995 15:13:10 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFhcR-0004nYC; Wed, 15 Nov 95 06:11 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: 2.7.1 beta available To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Wed, 15 Nov 1995 06:11:15 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511131332.NAA22712@colombo.telesys-innov.fr> from "Philippe BRAND" at Nov 13, 95 01:32:49 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 590 > NOTE: compiler directory has changed from > > /gnu/lib/gcc-lib/mc68000-cbm-amigados to > /gnu/lib/gcc-lib/mc68000-at-amigados It might be best at some point in the near future to change this to: /gnu/lib/gcc-lib/m68000-unknown-amigados since it shouldn't matter whether the compiler is running on an old CBM produced machine, a new Amiga Technologies produced machine, or on an Amiga clone/compatible such as the Draco. We also need to make sure that all the configuration files in the GNU utils use m68k-*-amigados rather than a specific manufacturer in the middle field. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 15:19:29 1995 Received: from hpcl.cti.gr ([150.140.91.21]) by nic.funet.fi with SMTP id <89068-4>; Wed, 15 Nov 1995 15:18:38 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA01985 (5.67a8/IDA-1.5 for ); Wed, 15 Nov 1995 15:13:13 +0200 From: Kriton Kyrimis Message-Id: <199511151313.AA01985@hpcl.cti.gr> Subject: Re: -O2 vs. -g To: robert@lodz.pdi.net Date: Wed, 15 Nov 1995 15:13:11 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi (gcc) Reply-To: kyrimis@theseas.softlab.ece.ntua.gr In-Reply-To: <219d9af3.u8t20e.ae3f7-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Nov 15, 95 12:15:49 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 599 > > BTW, I think that the simplest way to change the compilation flags is to do > > something like: > > make CFLAGS=-O2 LDFLAGS=-s > > rather than editing the Makefile. > Well never thought about that way, but i prefer editing files by hand. This is fine for small packages with only one Makefile. Things get more complicated for larger packages (e.g., gdb) having a complex directory structure with one makefile in each directory. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "No matter how bad I think it is, it's actually worse." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 15:20:21 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89801-2>; Wed, 15 Nov 1995 15:19:19 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFhhp-0004naC; Wed, 15 Nov 95 06:16 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: 2.7.1 beta available To: robert@lodz.pdi.net Date: Wed, 15 Nov 1995 06:16:48 -0700 (MST) Cc: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-Reply-To: <219c511d.u8t20e.27257-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Nov 14, 95 12:48:32 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 637 > quite a lot of time) If You want to have utils for Your 000 system then= > try to=20 > find newst FreshFish (#10 i think). Also if You want to compile all of = > them by > Yourself there are sources ready to be compiled on plukwa (in gnu/src, = I just returned from an interesting week in Cologne, part of which was at the Computer '95 show. Over the next few weeks I will be working to integrate 2.7.1 into my GNU tree and when everything is stable, will be putting binaries up on ftp.amigalib.com for several different native configurations (68000, 68020+fpu, and 68040+fpu), to be followed later by some cross compilers. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 15:24:47 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <90582-1>; Wed, 15 Nov 1995 15:23:21 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id OAA08638 for ; Wed, 15 Nov 1995 14:16:18 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA19697; Wed, 15 Nov 95 14:24:33 GMT Date: Wed, 15 Nov 95 14:24:33 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9511151424.AA19697@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: EMT Trap signal, when ?? Hi, when compiling large project, sometimes cc1 stop with fatal signal 7 (EMT Trap) when compiling a file. Then just run make again, and the compilation continue without any trouble. What's going wrong ?? \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 15:28:00 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <88992-2>; Wed, 15 Nov 1995 15:26:59 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id OAA08744 for ; Wed, 15 Nov 1995 14:19:54 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA19706; Wed, 15 Nov 95 14:28:09 GMT Date: Wed, 15 Nov 95 14:28:09 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9511151428.AA19706@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: sh enforcer hit I get many times enforcer hit from sh when running configure script. I use sh from gcc270-base. Is this a known hit (adress 0xcb48) ?? \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 15:30:19 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89620-3>; Wed, 15 Nov 1995 15:29:45 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA28418 (5.65c8/IDA-1.4.4 for ); Wed, 15 Nov 1995 14:29:34 +0100 Received: by diva.gmd.de with UUCP id AA06078 (5.67b8/IDA-1.5); Wed, 15 Nov 1995 14:26:23 +0100 Date: Wed, 15 Nov 1995 14:26:23 +0100 Message-Id: <199511151326.AA06078@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: fnf@amigalib.com (Fred Fish) Cc: amiga-gcc-port@nic.funet.fi Subject: Re: 2.7.1 beta available In-Reply-To: References: <219c511d.u8t20e.27257-robert@plukwa.lodz.pdi.net> Hi, Fred Fish writes: > I just returned from an interesting week in Cologne, part of which was > at the Computer '95 show. Over the next few weeks I will be working I saw you there :) > to integrate 2.7.1 into my GNU tree and when everything is stable, BTW, will we finally see GCC use the "correct" stack/register struct return convention or still the unreentrant and cumbersome static-struct-return? Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 15:38:40 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90220-3>; Wed, 15 Nov 1995 15:37:03 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFi7t-0004nYC; Wed, 15 Nov 95 06:43 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: 2.7.1 beta available To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Wed, 15 Nov 1995 06:43:45 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <199511151326.AA06078@diva.gmd.de> from "Joerg Hoehle" at Nov 15, 95 02:26:23 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 699 > > to integrate 2.7.1 into my GNU tree and when everything is stable, > BTW, will we finally see GCC use the "correct" stack/register struct > return convention or still the unreentrant and cumbersome > static-struct-return? I remember this discussion from a long time ago on this list, but don't think I still have the details. Can you post what has to be changed and what the impact will be? As I recall, it was a simple change to a configuration parameter and there should be no significant side effects other than possibly requiring a recompile of some user object files. I'm willing to make the change and try a multistage rebuild of my entire GNU tree to see if anything breaks. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 15:46:51 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <89558-3>; Wed, 15 Nov 1995 15:45:53 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 15 Nov 95 14:42:49 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <219dbd67.u8t20e.132b1-robert@plukwa.lodz.pdi.net> Subject: Re: -O2 vs. -g In-Reply-To: <199511151313.AA01985@hpcl.cti.gr> (from Kriton Kyrimis ) (at Wed, 15 Nov 1995 15:13:11 +0200 (EET)) Reply-To: robert@lodz.pdi.net Content-Length: 1019 To: kyrimis@theseas.softlab.ece.ntua.gr Cc: amiga-gcc-port@nic.funet.fi, robert@lodz.pdi.net Date: Wed, 15 Nov 95 14:42:49 Organization: PDi On Nov 15 Kriton Kyrimis wrote: > > > BTW, I think that the simplest way to change the compilation flags is to do > > > something like: > > > make CFLAGS=-O2 LDFLAGS=-s > > > rather than editing the Makefile. > > Well never thought about that way, but i prefer editing files by hand. > > This is fine for small packages with only one Makefile. Things get more > complicated for larger packages (e.g., gdb) having a complex directory > structure with one makefile in each directory. The best way should be to change configure.in or at least configure scripts so that they are adding -O2 -s as well as some Amiga specific options to gcc (-mstackextend etc) Alas my knowledge of this things is to small to actually do that, not to mention the fact that this should also be arranged with maintainers of specific packages. > -- > Kriton (INTERNET: kyrimis@hpcl.cti.gr) > (WWW: http://www.hpcl.cti.gr/~kyrimis > ----- > "No matter how bad I think it is, it's actually worse." > ----- > Robert From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 16:04:01 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90375-2>; Wed, 15 Nov 1995 16:02:54 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFiWg-0004naC; Wed, 15 Nov 95 07:09 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: atof() problems, HELP To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Wed, 15 Nov 1995 07:09:22 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "joop van de wege" at Nov 12, 95 12:59:39 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 514 > Now the my new problem, which will turn out to be a major oversight on my > part but here it goes ;) > printf("valbuf: %s, atof %f \n",valbuf, (double)atof(valbuf)); If you have no prototype in scope or have not otherwise declared atof as returning double, what will happen is that the caller will treat it as returning int, which you have then cast to double. The cast is meaningless if you have a prototype and ineffectual at doing what you intend if you have no prototype, so it should be removed. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 18:12:07 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90046-2> convert rfc822-to-8bit; Wed, 15 Nov 1995 18:08:39 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 15 Nov 1995 17:08:03 +0100 (MET) From: Rask Lambertsen To: Joerg Hoehle Cc: amiga-gcc-port@nic.funet.fi Subject: Re: X11 clients In-Reply-To: <199511151026.AA05964@diva.gmd.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 15 Nov 1995, Joerg Hoehle wrote: > Rask Lambertsen writes: > > > or alloca() whole files, isolate them and add stack checking and stack > > ^^^^^^^^^^^^^^^^^^^^ > > Do some programmers really do that? > > Cpp is said to do that. When it comes to speed, it's much more > interesting to use large blocks of memory than to read small chunks. > Modern UNIX-SW even uses mmap(). Compare the speed of C:Search with Actually, I was wondering why they use alloca() instead of malloc(). I don't see the advantages of allocating memory off the stack instead of asking the system. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 18:17:28 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89131-2> convert rfc822-to-8bit; Wed, 15 Nov 1995 18:17:04 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 15 Nov 1995 17:15:40 +0100 (MET) From: Rask Lambertsen To: Fred Fish Cc: Philippe BRAND , amiga-gcc-port@nic.funet.fi Subject: Re: 2.7.1 beta available In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 15 Nov 1995, Fred Fish wrote: > > NOTE: compiler directory has changed from > > > > /gnu/lib/gcc-lib/mc68000-cbm-amigados to > > /gnu/lib/gcc-lib/mc68000-at-amigados > > It might be best at some point in the near future to change this to: > > /gnu/lib/gcc-lib/m68000-unknown-amigados > > since it shouldn't matter whether the compiler is running on an old > CBM produced machine, a new Amiga Technologies produced machine, or > on an Amiga clone/compatible such as the Draco. > > We also need to make sure that all the configuration files in the > GNU utils use m68k-*-amigados rather than a specific manufacturer in > the middle field. I'd really like to see "amigados" replaced by "amigaos", as more much than just dos.library is involved. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 18:25:27 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89052-3>; Wed, 15 Nov 1995 18:23:30 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA11158 (5.65c8/IDA-1.4.4 for ); Wed, 15 Nov 1995 17:23:03 +0100 Received: by diva.gmd.de with UUCP id AA06152 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Wed, 15 Nov 1995 17:19:52 +0100 Date: Wed, 15 Nov 1995 17:19:52 +0100 Message-Id: <199511151619.AA06152@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: 2.7.1 beta available In-Reply-To: References: <199511131332.NAA22712@colombo.telesys-innov.fr> Fred Fish writes: > /gnu/lib/gcc-lib/m68000-unknown-amigados > GNU utils use m68k-*-amigados rather than a specific manufacturer in mc68000 or m68k? I vote for m68k as its also used on Sun3 and NeXt. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 18:25:31 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88927-2>; Wed, 15 Nov 1995 18:23:46 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFkik-0004nZC; Wed, 15 Nov 95 09:29 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: -O2 vs. -g To: robert@lodz.pdi.net Date: Wed, 15 Nov 1995 09:29:57 -0700 (MST) Cc: kyrimis@theseas.softlab.ece.ntua.gr, amiga-gcc-port@nic.funet.fi In-Reply-To: <219dbd67.u8t20e.132b1-robert@plukwa.lodz.pdi.net> from "Robert Ramiega" at Nov 15, 95 02:42:49 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 757 > The best way should be to change configure.in or at least configure scripts so > that they are adding -O2 -s as well as some Amiga specific options to gcc > (-mstackextend etc) The easiest way to change the default CFLAGS is to change it in the autoconf source, rebuild autoconf, and then rebuild all the configure scripts. I already did this once before when one of the gcc releases (gcc 2.6.0?) had a faulty optimizer and could not be trusted. In that case I disable all optimization. CFLAGS is the wrong place to put the persistent default stack setting. It is a configuration option that gets incorporated into the compiler frontend and then the specs file. You can of course change it via an appropriate -m option for specific compiles. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 18:27:33 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89918-3>; Wed, 15 Nov 1995 18:26:20 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA11274 (5.65c8/IDA-1.4.4 for ); Wed, 15 Nov 1995 17:25:23 +0100 Received: by diva.gmd.de with UUCP id AA06156 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Wed, 15 Nov 1995 17:22:11 +0100 Date: Wed, 15 Nov 1995 17:22:11 +0100 Message-Id: <199511151622.AA06156@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: X11 clients In-Reply-To: References: <199511151026.AA05964@diva.gmd.de> Rask Lambertsen writes: > Actually, I was wondering why they use alloca() instead of malloc(). I > don't see the advantages of allocating memory off the stack instead of > asking the system. When stack overflow is not an issue (it's generally not on UNIX, no wonder GNU people use it a lot), then there are only advantages: o no bookkeeping necessary o no memory lost until the final exit() o automatic freeing, in _all_ cases (including longjmp()) o no malloc()/sbrk(), no locking, thus extremely speedy (garbage collection vs. malloc costs is discussed once again in comp.lang.lisp and other newsgroups) o reentrant Of course, alloca() has the obvious dynamic extent limitations, so not every malloc()/free() can be replaced by an alloca(). Any reason I forgot? Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 18:35:41 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89855-1>; Wed, 15 Nov 1995 18:34:58 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFku7-0004ncC; Wed, 15 Nov 95 09:41 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: 2.7.1 beta available To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Wed, 15 Nov 1995 09:41:43 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511151619.AA06152@diva.gmd.de> from "Joerg Hoehle" at Nov 15, 95 05:19:52 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 279 > Fred Fish writes: > > /gnu/lib/gcc-lib/m68000-unknown-amigados > > > GNU utils use m68k-*-amigados rather than a specific manufacturer in > > mc68000 or m68k? I vote for m68k as its also used on Sun3 and NeXt. True, "m68k" implies the family of 68000 processors. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 18:39:04 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89912-1>; Wed, 15 Nov 1995 18:37:37 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFkrN-0004nbC; Wed, 15 Nov 95 09:38 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: 2.7.1 beta available To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Wed, 15 Nov 1995 09:38:52 -0700 (MST) Cc: fnf@amigalib.com, phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Nov 15, 95 05:15:40 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 682 > > We also need to make sure that all the configuration files in the > > GNU utils use m68k-*-amigados rather than a specific manufacturer in > > the middle field. > > I'd really like to see "amigados" replaced by "amigaos", as more much than > just dos.library is involved. I have no objections to changing "amigados" to "amigaos". Also, I forgot to mention, but "mc68000" is somewhat nonstandard. The usually convention is "m68000" or "m68020" or "m68030", etc. The rationale (as I recall) is that the "mc" prefix implies a chip manufactured specifically my Motorola, while the "m" prefix just implies any chip manufactured by any Motorola authorized second source. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 18:43:46 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89917-2>; Wed, 15 Nov 1995 18:43:28 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26521-4>; Wed, 15 Nov 1995 17:42:26 +0100 Received: from hphalle6g.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395734-1>; Wed, 15 Nov 1995 17:42:12 +0100 Subject: Re: 2.7.1 beta available From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Wed, 15 Nov 1995 17:42:10 +0100 (MEZ) In-Reply-To: <9511141047.0akm@wyst.hobby.nl> from "Hans Verkuil" at Nov 14, 95 11:47:14 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 568 Message-Id: <95Nov15.174212+0100mesz.395734-1+2207@hphalle0.informatik.tu-muenchen.de> > like m68k-at-amigaos better, though. Can't wait until a ppc-at-amigaos > appears! Well, it shouldn't be too difficult for someone with enough CPU-speed and memory to build one, just for you :) But the ppc-emulator that is required to run the executables would be a little more work :) Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 18:53:32 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by nic.funet.fi with SMTP id <88915-3>; Wed, 15 Nov 1995 18:52:20 +0200 Received: from moos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA25618; Wed, 15 Nov 1995 17:52:08 +0100 Received: by moos.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA02190; Wed, 15 Nov 95 17:52:07 +0100 From: isthesin@TechFak.Uni-Bielefeld.DE (Stephan Thesing) Message-Id: <9511151752.ZM2188@moos.TechFak.Uni-Bielefeld.DE> Date: Wed, 15 Nov 1995 17:52:06 +0100 In-Reply-To: Rask Lambertsen "Re: X11 clients" (Nov 15, 17:08) References: X-Mailer: Z-Mail (2.1.5 09aug93) To: Rask Lambertsen Subject: Re: X11 clients Cc: amiga-gcc-port@nic.funet.fi On Nov 15, 17:08, Rask Lambertsen wrote: > Subject: Re: X11 clients > On Wed, 15 Nov 1995, Joerg Hoehle wrote: > > > Rask Lambertsen writes: > > > > or alloca() whole files, isolate them and add stack checking and sta= > ck > > > ^^^^^^^^^^^^^^^^^^^^ > > > Do some programmers really do that? > >=20 > > Cpp is said to do that. When it comes to speed, it's much more > > interesting to use large blocks of memory than to read small chunks. > > Modern UNIX-SW even uses mmap(). Compare the speed of C:Search with > > Actually, I was wondering why they use alloca() instead of malloc(). I=20 > don't see the advantages of allocating memory off the stack instead of=20 > asking the system. > The reason is speed: With malloc() one has to traverse the memory list and allocate a block from there, which can be very time consuming.... With alloca() you just move the stack pointer a little bit..... Nonetheless I agree that alloca() should not be used on Amiga. With Unix you don't have to bother about stack size, the system adjusts it if necessary. On Amiga you crash or have to add time consuming stack check code.... MfG.... Stephan > Regards, > > /=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= > =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= > =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= > \ > | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk = > | > | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ = > | > | Keyboard error: and are stuck - press to continue = > | >-- End of excerpt from Rask Lambertsen -- =============================================== = Stephan Thesing = = AG Praktische Informatik = = Technische Fakult"at = = Universit"at Bielefeld = = EMail: isthesin@techfak.uni-bielefeld.de = =---------------------------------------------= = Wer den Spruch erfunden hat : = = "So einfach, wie einem Kind den Lolly = = wegzunehmen", hat noch nie versucht, = = seinem Neffen ein Bonbon zu stibitzen. = =============================================== From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 18:54:02 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89882-3>; Wed, 15 Nov 1995 18:53:48 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA12665 (5.65c8/IDA-1.4.4 for ); Wed, 15 Nov 1995 17:53:35 +0100 Received: by diva.gmd.de with UUCP id AA06178 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Wed, 15 Nov 1995 17:50:24 +0100 Date: Wed, 15 Nov 1995 17:50:24 +0100 Message-Id: <199511151650.AA06178@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: Amiga-Gcc Liste Subject: Re: New 2.7.1 beta compiled using -mstackextend In-Reply-To: References: <199511141034.KAA28811@colombo.telesys-innov.fr> Kamil Iskra writes: > 1. It's hard for me to say whether stack extension works as it should, > because on start all programs but "cc1" set their stack to 250 KB (or > maybe their stack is set by "gcc" or "ixemul" or whatever else - I 250KB stack size was an extension by Fred Fish, when there was no information about stack size when launching a new process, but I can't remember in which ixemul.library call. > 2. When I set shell stacksize to 4096 bytes and break gcc (^C) during > compiling stage (cc1), shell stacksize is set to 50000 byes! If cc1 Ugh! The signal handler probably calls exit() or longjmp() and the original stack is not swapped back. On of the _main_ problems with stack swapping. Thanks for the report. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 18:56:01 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89146-3>; Wed, 15 Nov 1995 18:55:48 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFlE2-0004nZC; Wed, 15 Nov 95 10:02 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: cat and tar problem... To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Wed, 15 Nov 1995 10:02:18 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi, cz253@cleveland.freenet.edu In-Reply-To: <199511071933.AA03598@diva.gmd.de> from "Joerg Hoehle" at Nov 7, 95 08:33:11 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 985 > > Side Query: Why would any one want to do: > > > > cat *.tar.gz | tar zvtf - Normally you would not, for two reasaons: (1) You cannot concatenate two gzip compressed files and expect to have gzip properly decompress them such that the result is the same as concatenating two independently uncompressed files. (2) Even if the example was to concatenate two uncompressed tar archives, this will still not work since tar appends blocks of nulls to the end of the archive to pad it out to an equal number of buffer sizes. I.E. "tar -cvf foo.tar foo" will produce a tar archive that is an even multiple of the default block size, which is 20 blocks. > The report is there because there's a bug. There are many more ways to > show the bug than the above, but it's how it appeared first. The bug I've seen is that "tar -zvtf foo.tar.gz" does not work, as would also probably be the case for "cat foo.tar.gz | tar -zvtf -" or the equivalent "tar -zvtf - ; Wed, 15 Nov 1995 19:21:14 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFld1-0004nZC; Wed, 15 Nov 95 10:28 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: cat and tar problem... To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Wed, 15 Nov 1995 10:28:06 -0700 (MST) In-Reply-To: from "Fred Fish" at Nov 15, 95 10:02:18 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1943 > > > Side Query: Why would any one want to do: > > > > > > cat *.tar.gz | tar zvtf - > > Normally you would not, for two reasaons: > > (1) You cannot concatenate two gzip compressed files and expect > to have gzip properly decompress them such that the result is > the same as concatenating two independently uncompressed files. Urk! Seems I was wrong on this for the case of gzip compressed files, though I do seem to recall that it is true for the older "compress". > (2) Even if the example was to concatenate two uncompressed tar > archives, this will still not work since tar appends blocks > of nulls to the end of the archive to pad it out to an equal > number of buffer sizes. I.E. "tar -cvf foo.tar foo" will produce > a tar archive that is an even multiple of the default block size, > which is 20 blocks. This is true, and I just tried it on a unix machine using the latest tar and gzip: Script started on Wed Nov 15 10:24:36 1995 fishpond [1] echo recode*.gz recode-3.2.4.tar.gz recode-3.3.tar.gz recode-3.4.tar.gz fishpond [2] cat recode*.gz | tar -zvtf - drwxr-xr-x djm/umd 0 Oct 7 14:59 1992 recode-3.2.4/ -rw-r--r-- djm/umd 3200 Oct 7 14:57 1992 recode-3.2.4/README -rw-r--r-- djm/umd 5474 Sep 1 14:41 1992 recode-3.2.4/INSTALL -r--r--r-- djm/umd 17982 Jun 2 13:03 1991 recode-3.2.4/COPYING . . . -rwxr-xr-x djm/umd 2212 Jul 16 16:02 1992 recode-3.2.4/checkit -rwxr-xr-x djm/umd 9699 Sep 29 11:34 1992 recode-3.2.4/configure -rw-r--r-- djm/umd 72810 Sep 25 09:54 1992 recode-3.2.4/merged.c -rw-r--r-- djm/umd 44507 Aug 23 11:24 1992 recode-3.2.4/recode.info Broken pipe fishpond [3] exit Script done on Wed Nov 15 10:24:55 1995 What happens is that tar sees the trailing null bytes from the first archive and takes that as meaning the end of the archive and exits, which causes the shell to report "broken pipe". -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 19:41:19 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89023-1>; Wed, 15 Nov 1995 19:37:39 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFlqd-0004nZC; Wed, 15 Nov 95 10:42 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: 2.7.1 beta available To: stieber@informatik.tu-muenchen.de (Christian Stieber) Date: Wed, 15 Nov 1995 10:42:10 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Nov15.174212+0100mesz.395734-1+2207@hphalle0.informatik.tu-muenchen.de> from "Christian Stieber" at Nov 15, 95 05:42:10 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 461 > > like m68k-at-amigaos better, though. Can't wait until a ppc-at-amigaos > > appears! > > Well, it shouldn't be too difficult for someone with enough CPU-speed > and memory to build one, just for you :) > But the ppc-emulator that is required to run the executables would be > a little more work :) I will be building a PPC cross environment as part of the tools I've committed to making available in the near future (I.E. in the next month or two). -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 19:56:56 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89691-2>; Wed, 15 Nov 1995 19:55:00 +0200 Received: from carina.rz.Uni-Osnabrueck.DE (carina.rz.Uni-Osnabrueck.DE [131.173.128.25]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id RAA10855 for ; Wed, 15 Nov 1995 17:54:51 GMT Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id SAA38951; Wed, 15 Nov 1995 18:54:43 +0100 From: Thomas Radtke Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.7.1/8.7.1) id SAA09757; Wed, 15 Nov 1995 18:54:43 +0100 Message-Id: <199511151754.SAA09757@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: X11 clients To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Wed, 15 Nov 1995 18:54:43 +0100 (NFT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511151622.AA06156@diva.gmd.de> from "Joerg Hoehle" at Nov 15, 95 05:22:11 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > Rask Lambertsen writes: > > Actually, I was wondering why they use alloca() instead of malloc(). I > > don't see the advantages of allocating memory off the stack instead of > > asking the system. > > When stack overflow is not an issue (it's generally not on UNIX, no > wonder GNU people use it a lot), then there are only advantages: > Allow me to quote from the BSD UNIX manual: BUGS The alloca() function is machine dependent; its use is discouraged. 4th Berkeley Distribution May 2, 1991 > o no bookkeeping necessary > o no memory lost until the final exit() I thought all malloc'd memory is free'd on exit ? Thomas From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 19:57:06 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89911-3>; Wed, 15 Nov 1995 19:55:36 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 15 Nov 95 18:54 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 15 Nov 95 18:47 MET Message-Id: Subject: EMT Trap signal, when ?? To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 15 Nov 1995 18:47:17 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 465 > Hi, > when compiling large project, sometimes cc1 stop with fatal signal 7 (EMT > Trap) when compiling a file. Then just run make again, and the > compilation continue without any trouble. > What's going wrong ?? > i had the same problems, i tought first its the stack but using stackmon showed nothing. sometimes make broke in some subscripts but calling them by hand showed no error. walter -- ----- "Circular logic will only make you dizzy!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 20:10:40 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <89118-2>; Wed, 15 Nov 1995 20:07:51 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id NAA23636; Wed, 15 Nov 1995 13:05:39 -0500 (from cz253) Message-Id: <199511151805.NAA23636@kanga.INS.CWRU.Edu> Date: Wed, 15 Nov 1995 13:05:39 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: fnf@amigalib.com Subject: Re: cat and tar problem... Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from fnf@amigalib.com of Wed, 15 Nov > >> > > Side Query: Why would any one want to do: >> > > >> > > cat *.tar.gz | tar zvtf - >> >> Normally you would not, for two reasaons: Sorry the above should have been: cat foo.tar.gz | tar zvtf - I used the '*' as an arbitrary value, not literal (wildcard). > > Script started on Wed Nov 15 10:24:36 1995 > fishpond [1] echo recode*.gz > recode-3.2.4.tar.gz recode-3.3.tar.gz recode-3.4.tar.gz > fishpond [2] cat recode*.gz | tar -zvtf - > drwxr-xr-x djm/umd 0 Oct 7 14:59 1992 recode-3.2.4/ > -rw-r--r-- djm/umd 3200 Oct 7 14:57 1992 recode-3.2.4/README > -rw-r--r-- djm/umd 5474 Sep 1 14:41 1992 recode-3.2.4/INSTALL > -r--r--r-- djm/umd 17982 Jun 2 13:03 1991 recode-3.2.4/COPYING > . > . > . > -rwxr-xr-x djm/umd 2212 Jul 16 16:02 1992 recode-3.2.4/checkit > -rwxr-xr-x djm/umd 9699 Sep 29 11:34 1992 recode-3.2.4/configure > -rw-r--r-- djm/umd 72810 Sep 25 09:54 1992 recode-3.2.4/merged.c > -rw-r--r-- djm/umd 44507 Aug 23 11:24 1992 recode-3.2.4/recode.info > Broken pipe > fishpond [3] exit > Script done on Wed Nov 15 10:24:55 19 When you did the above, was it on an Amiga, or another machine? .....Dave ps. Did you get the personal mail I sent you? From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 20:17:44 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90847-2>; Wed, 15 Nov 1995 20:15:09 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFmRv-0004naC; Wed, 15 Nov 95 11:20 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: cat and tar problem... To: cz253@cleveland.Freenet.Edu Date: Wed, 15 Nov 1995 11:20:43 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <199511151805.NAA23636@kanga.INS.CWRU.Edu> from "David Zaroski" at Nov 15, 95 01:05:39 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 373 > Sorry the above should have been: > > cat foo.tar.gz | tar zvtf - Thanks for the clarification. > When you did the above, was it on an Amiga, or another machine? It was on a linux machine. > ps. Did you get the personal mail I sent you? Hmm, I'll have to check the 1500 new messages that have come in for me during the last 9 days while I was gone.... :-( -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 20:24:19 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89527-3>; Wed, 15 Nov 1995 20:21:25 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA15426 (5.65c8/IDA-1.4.4 for ); Wed, 15 Nov 1995 19:21:11 +0100 Received: by diva.gmd.de with UUCP id AA06268 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Wed, 15 Nov 1995 19:17:59 +0100 Date: Wed, 15 Nov 1995 19:17:59 +0100 Message-Id: <199511151817.AA06268@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: X11 clients In-Reply-To: <199511151754.SAA09757@nereid.rz.Uni-Osnabrueck.DE> References: <199511151622.AA06156@diva.gmd.de> <199511151754.SAA09757@nereid.rz.Uni-Osnabrueck.DE> Thomas Radtke writes: > Allow me to quote from the BSD UNIX manual: > > BUGS > The alloca() function is machine dependent; its use is discouraged. Good point! > > o no memory lost until the final exit() > > I thought all malloc'd memory is free'd on exit ? That's what I meant. At least at exit(), C-programs free their memory. Now think about programs which forget to free memory and run for a long time (typically servers: inetd, X). They eat more and more memory. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 20:27:47 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89066-1>; Wed, 15 Nov 1995 20:24:50 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tFmoN-000RaNC; Wed, 15 Nov 95 19:43 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0aq1@wyst.hobby.nl>; Wed, 15 Nov 95 08:06:56 CET Message-Id: <9511150706.0aq1@wyst.hobby.nl> Date: Wed, 15 Nov 1995 08:06:53 +0000 (CET) In-Reply-To: from "Rask Lambertsen" at Nov 14, 95 11:04:01 pm Content-Type: text Content-Length: 710 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: 2.7.1 beta available According to Rask Lambertsen: > > Aargghh! No capitals please! What about m68k-at-amigaos? Short and to the > > point. Or indeed mc68000-at-amigaos if each chip gets its own directory. = > I > > like m68k-at-amigaos better, though. Can't wait until a ppc-at-amigaos > > appears! > > What does the other 68000 based platforms use? mc68000 or m68k? Or both?=20 > (please check as appropiate ;-)) m68k Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 20:34:28 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89101-1>; Wed, 15 Nov 1995 20:34:10 +0200 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt; (5.65v3.0/1.1.8.2/24Jul95-0207PM) id AA04150; Wed, 15 Nov 1995 19:31:09 GMT Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/08Aug95-1153AM) id AA08351; Wed, 15 Nov 1995 19:32:03 GMT Date: Wed, 15 Nov 1995 19:32:03 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Rask Lambertsen Cc: Philippe BRAND , Amiga-Gcc Liste Subject: Dont delete env:GCCSTACK In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII As you must know, VMM supports stack in virtual memory. cc1, when starts to run gets it's stack from virtual memory and works fine but when I set GCCSTACK to a low value I get protection faults wich cause cc1 to die. Don't remove ENV:GCCSTASCK because this will start cc1 with a low value wich cc1 will try to increase. GCCSTACK variable surounds the problem because I can launch cc1 with an initial large stack. - Pedro Miguel Teixeira - From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 20:35:13 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89074-1>; Wed, 15 Nov 1995 20:34:39 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26525-2>; Wed, 15 Nov 1995 19:33:23 +0100 Received: from hphalle6g.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395726-2>; Wed, 15 Nov 1995 19:33:06 +0100 Subject: Re: X11 clients From: Christian Stieber To: Thomas.Radtke@rz.Uni-Osnabrueck.DE (Thomas Radtke) Date: Wed, 15 Nov 1995 19:32:56 +0100 (MEZ) Cc: hoehle@zeus.gmd.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <199511151754.SAA09757@nereid.rz.Uni-Osnabrueck.DE> from "Thomas Radtke" at Nov 15, 95 06:54:43 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 677 Message-Id: <95Nov15.193306+0100mesz.395726-2+2303@hphalle0.informatik.tu-muenchen.de> [ alloca() ] > > o no bookkeeping necessary > > o no memory lost until the final exit() > > I thought all malloc'd memory is free'd on exit ? Yes, but alloca()ed memory is freed when the function exits. If you malloc() temporary memory, you have to free() it (otherwise it will hang around until the program terminates). If you alloca() the memory, it is generally freed a long time before the program terminates. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 20:37:48 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89326-2>; Wed, 15 Nov 1995 20:36:59 +0200 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt; (5.65v3.0/1.1.8.2/24Jul95-0207PM) id AA04782; Wed, 15 Nov 1995 19:35:44 GMT Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/08Aug95-1153AM) id AA13487; Wed, 15 Nov 1995 19:36:37 GMT Date: Wed, 15 Nov 1995 19:36:37 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Fred Fish Cc: Philippe BRAND , amiga-gcc-port@nic.funet.fi Subject: Re: 2.7.1 beta available In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Nov 1995, Fred Fish wrote: > It might be best at some point in the near future to change this to: > > /gnu/lib/gcc-lib/m68000-unknown-amigados > > since it shouldn't matter whether the compiler is running on an old > CBM produced machine, a new Amiga Technologies produced machine, or > on an Amiga clone/compatible such as the Draco. I thing that unknown sounds a little strange. The stanmdard is for processor-architecture-os and not processor-brand-os. I consider 'at' to be a specification of the architecture and, therefore, agree with: 68k-at-amigaos - Pedro Miguel Teixeira - From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 20:40:10 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89376-3>; Wed, 15 Nov 1995 20:39:40 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id SAA21829; Wed, 15 Nov 1995 18:37:50 GMT From: Lars Hecking Message-Id: <199511151838.SAA21276@mostar.nmrc.ucc.ie> Subject: Re: New 2.7.1 beta compiled using -mstackextend To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Wed, 15 Nov 1995 18:38:38 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199511151650.AA06178@diva.gmd.de> from "Joerg Hoehle" at Nov 15, 95 05:50:24 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 501 > Kamil Iskra writes: > > 1. It's hard for me to say whether stack extension works as it should, > > because on start all programs but "cc1" set their stack to 250 KB (or > > maybe their stack is set by "gcc" or "ixemul" or whatever else - I > 250KB stack size was an extension by Fred Fish, when there was no Actually, a co-production of Fred and my humble self ;-) > information about stack size when launching a new process, but I can't > remember in which ixemul.library call. system(3) From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 21:22:40 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <89258-1>; Wed, 15 Nov 1995 21:21:23 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id UAA17026; Wed, 15 Nov 1995 20:18:09 +0100 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id UAA04149; Wed, 15 Nov 1995 20:06:47 +0100 Date: Wed, 15 Nov 1995 20:06:47 +0100 From: Niklas Hallqvist Message-Id: <199511151906.UAA04149@linda.appli.se> To: l36599@alfa.ist.utl.pt CC: fnf@amigalib.com, phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi In-reply-to: (message from Pedro Miguel Sequeira Teixeira on Wed, 15 Nov 1995 19:36:37 +0000 (GMT)) Subject: Re: 2.7.1 beta available >>>>> "Pedro" == Pedro Miguel Sequeira Teixeira writes: Pedro> On Wed, 15 Nov 1995, Fred Fish wrote: >> It might be best at some point in the near future to change this >> to: >> >> /gnu/lib/gcc-lib/m68000-unknown-amigados >> >> since it shouldn't matter whether the compiler is running on an old >> CBM produced machine, a new Amiga Technologies produced machine, or >> on an Amiga clone/compatible such as the Draco. Pedro> I thing that unknown sounds a little strange. The stanmdard is Pedro> for processor-architecture-os and not processor-brand-os. I Pedro> consider 'at' to be a specification of the architecture and, Pedro> therefore, agree with: Although unknown is the standard word when there are several vendors selling the same os for the same arch (processor) and the configured SW don't depend on the vendor. I.e. i386-unknown-netbsd is better than i386-ibm-netbsd... Note that it is not processor-arch-os, but rather arch-vendor-os, where arch might sometimes be specialized for a certain processor. It's only when a certain vendor changes something to the os part that the configured SW needs to know about, the vendor info should be used. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Home: +46-(0)31-41 93 95 Applitron Datasystem Fax: +46-(0)31-83 39 50 Home: +46-(0)31-41 93 96 Molndalsvagen 95 Email: niklas@appli.se GSM: +46-(0)70-714 10 35 S-412 63 GOTEBORG WWW: Here Sweden IRC: niklas (#NetBSD) ICB: niklas (netbsd) From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 21:42:43 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <90302-2>; Wed, 15 Nov 1995 21:41:49 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id OAA25566; Wed, 15 Nov 1995 14:41:35 -0500 (from cz253) Message-Id: <199511151941.OAA25566@kanga.INS.CWRU.Edu> Date: Wed, 15 Nov 1995 14:41:35 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: ixtrace Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Is there a list of new functions, that have been added to ixemul.library available? I am asking since I want to update ixtrace. Thanks in advance. .....Dave From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 22:20:34 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89659-1>; Wed, 15 Nov 1995 22:19:49 +0200 Received: from achilles.noc.ntua.gr (root@achilles.noc.ntua.gr [147.102.222.210]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id UAA13503 for ; Wed, 15 Nov 1995 20:18:51 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id WAA24659 at Wed, 15 Nov 1995 22:18:32 +0200 Received: by softlab.ece.ntua.gr with UUCP id WAA09761 at Wed, 15 Nov 1995 22:18:34 +0200 (EET) Received: by kriton.UUCP (V1.17-beta/Amiga) id <090i@kriton.UUCP>; Tue, 14 Nov 95 18:55:35 EET Date: Tue, 14 Nov 95 18:55:35 EET Message-Id: <9511141655.090i@kriton.UUCP> In-Reply-To: <199511122023.NAA27403@getnet.com> (from Clinton Ball ) (at Sun, 12 Nov 1995 13:23:19 -0700 (MST)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!getnet.com!cbell@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: cout problem Hi Clinton (Clinton Ball), in <199511122023.NAA27403@getnet.com> on Nov 12 you wrote: To paraphrase Fred Fish, I tried your program using gcc 2.7.0 from aminet and it works. The output I get is: The double number dnum = 28.845 The double number dnum2 = 14 The dnum2 * dnum = 403.83 The floating point number fnum = 28.845 The integer number inum = 14 The fnum * inum = 403.83 The floating point number fnum = 28.844999 The integer number inum = 14 The fnum * inum = 403.829987 The output you showed looks suspiciously similar to what I got with an lcc-compiled printf before adding code for initialization of the FPU. Thus, I would suspect that you have an old version of ixemul.library. If your LIBS: is a multi-assign, check to see that gnu:libs/ixemul.library (or wherever you keep the recent version of the library) is not overriden by an older version, e.g., sys:libs/ixemul.library. BTW., I am using the 68040/fpu version of ixemul.library. I hope this helps, -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "It sets such a bad precedent when you start letting the world come to an end every week or so. It seems to erode the confidence people have in their governments for some reason." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 22:21:09 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89628-3>; Wed, 15 Nov 1995 22:19:49 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFoC5-0004nZC; Wed, 15 Nov 95 13:12 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Important: replace gcc by gccv! gcc is buggy... To: hans@wyst.hobby.nl (Hans Verkuil) Date: Wed, 15 Nov 1995 13:12:28 -0700 (MST) Cc: fnf@amigalib.com, phb@colombo.telesys-innov.fr, ixemul@listserv.funet.fi, amiga-gcc-port@nic.funet.fi In-Reply-To: <9511142057.0akt@wyst.hobby.nl> from "Hans Verkuil" at Nov 14, 95 09:57:18 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1196 > There is no difference between > the two, except for the fact that 'gccv' supports the -pipe option and > handles Ctrl-C correctly. Sounds reasonable to me. As I recall, the original reason for two versions had something to do with 1.3 support as well, but perhaps I'm mistaken. I've had it in the back of my mind for a while to revisit the issue of why we had a gcc and gccv, and if they could be someone combined (thus also simplifying a number of changes against the baseline gcc source tree). > Fred and Philippe: Please apply the patch at the end of this mail to the > file config/m68k/xm-amigados.h from the gcc-distribution (gcc-2.7.0, to be > precise). I'll give it a try once I get my tree back to a stable state, probably this weekend or early next week. > Fred: please remove the ixemul-41.5 archive I've uploaded last week, it's > quite obsolete by now :-). Expect a new ixemul-42.0 archive hopefully next > weekend. 42.0 is actually smaller than the current version and has several > new features, removed lots of old cruft and fixed various bugs. 22 new > items where added to the NEWS file! Sounds cool. I'd like to have a copy for testing about a week from now. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 23:09:31 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89471-2>; Wed, 15 Nov 1995 23:08:46 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFp4v-0004nZC; Wed, 15 Nov 95 14:09 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New 2.7.1 beta compiled using -mstackextend To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Wed, 15 Nov 1995 14:09:09 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511151650.AA06178@diva.gmd.de> from "Joerg Hoehle" at Nov 15, 95 05:50:24 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 994 > 250KB stack size was an extension by Fred Fish, when there was no > information about stack size when launching a new process, but I can't > remember in which ixemul.library call. It is in system.c. If IXSTACK is not set, and the default is 4096 (probably indicating that the user has no idea about the stack problems), it is set to 250,000. If you set the stack size to something else other than 4K, or set IXSTACK, you can get exactly the stack you want. > > 2. When I set shell stacksize to 4096 bytes and break gcc (^C) during > > compiling stage (cc1), shell stacksize is set to 50000 byes! If cc1 > Ugh! The signal handler probably calls exit() or longjmp() and the > original stack is not swapped back. On of the _main_ problems with > stack swapping. I have some changes to the stack handling which are not yet integrated into ixemul.library. I'd recommend waiting until those are in before doing too much work with any of the stack checking or stack growing features. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 23:21:37 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89178-3>; Wed, 15 Nov 1995 23:21:07 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tFpZD-000RaNC; Wed, 15 Nov 95 22:40 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0axo@wyst.hobby.nl>; Wed, 15 Nov 95 20:40:47 CET Message-Id: <9511151940.0axo@wyst.hobby.nl> Date: Wed, 15 Nov 1995 20:40:45 +0000 (CET) In-Reply-To: <199511151039.AA05970@diva.gmd.de> from "Joerg Hoehle" at Nov 15, 95 11:39:39 am Content-Type: text Content-Length: 1813 From: hans@wyst.hobby.nl (Hans Verkuil) To: hoehle@zeus.gmd.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Important: replace gcc by gccv! gcc is buggy... According to Joerg Hoehle: > Perhaps it would be great to distribute a tiny archive that would > patch the ssystem() syscall, display a requester "ssystem() is soon > going to be removed from ixemul.library, please report use to > amiga-gcc-port or ixemul-list. Continue | sigsegv". That way people > here could test it and report uses of that function in programs they > run. Do we have a volunteer? :-) I won't do this for several reasons: 1) I scanned the sources of the GNU utils on FreshFish 7 for ssystem and fts and found nothing (except gcc :-) 2) The fts_ functions are an exclusive feature of BSD. None of the GNU utilities uses it, or for that matter any utility/program that as any hope of being portable to more than just BSD. So I feel justified in moving this out of the library. If it was just a small piece of code I'd left it alone, but it isn't. 3) The ssystem function is from the stone age of the library: probably the only one who new what it did was Markus Wild, and fairly soon it was replaced by vfork/exec. So I wasn't entirely surprised when I discovered that gcc used it, which was one of the first applications Markus had to port. And it's entirely unnecessary nowadays. And yes, it will keep working for sksh. If you want to be sure, just replace gcc by gccv yourself. You should at last be able to savely ctrl-c any make session. I'll upload ixemul-42.0 to Fred Fish in a minute: it passed the final tests, and I'm very happy with it. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 23:23:08 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89677-3>; Wed, 15 Nov 1995 23:22:52 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tFpb8-000RaPC; Wed, 15 Nov 95 22:42 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0axy@wyst.hobby.nl>; Wed, 15 Nov 95 21:01:17 CET Message-Id: <9511152001.0axy@wyst.hobby.nl> Date: Wed, 15 Nov 1995 21:01:14 +0000 (CET) In-Reply-To: <199511151103.AA05977@diva.gmd.de> from "Joerg Hoehle" at Nov 15, 95 12:03:38 pm Content-Type: text Content-Length: 2627 From: hans@wyst.hobby.nl (Hans Verkuil) To: hoehle@zeus.gmd.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Removal of ssystem() from the library... According to Joerg Hoehle: > Hans Verkuil writes: > > Proposal: I want to move fts.c (which is now part of ixemul.library) to > > libc.a. fts.c contains functions for directory-traversal but to my > > knowledge it is never used. Apparently, it is part of BSD Unix, so Markus > > probably just copied it into ixemul. However, it is relatively large (about > > 4 Kb), so I think that it should be put into libc.a. > > If we start a selection, many things could be moved out, depending on > the criteria. :) In fact, I looked through the function list, and there is very little left that you can take out of the library. The few things that might be a candidate are small, so hardly worth the effort. There are a few other functions I removed though: all functions dealing with 'long long' support were removed. These support functions were linked in from libgcc.a, which is where they belong. So this might break programs that use 'long long'. It shouldn't, because libgcc.a is linked before libc.a, so the libgcc.a version should be used. If not, you'll have to recompile. But I'm not going to change this because this would make the ixemul.library dependent on gcc: whenever gcc changes the semantics or code of their long long support, ixemul.library would also have to change. In fact, at least on 'long long' function was recently dropped from libgcc.a, so this is not a hypothetical case. I also removed 4 functions that provided support for bitwise shifts of signed and unsigned integers. Starting from the oldest compiler I could find, these are always compiled directly into assembly. In fact, the implementation in ixemul.library was just 'return a << b;' for one function. So why keep them around? Ixemul.library 42.0 is a major release, in which I tried to remove some of the old garbage that accumulated through the years, making it easier to maintain and to enhance in the future. I accept that this might cause problems for the occasional program, although I expect that it will stay limited to gcc. Which fortunately is easily fixed by replacing it with gccv. In all cases, except for ssystem, relinking the program is sufficient to get it working again. Should this nevertheless result in a lot more problems than I expect, then it is easy to add the function in question back to the library. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Nov 15 23:23:27 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89409-3>; Wed, 15 Nov 1995 23:23:17 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tFpbc-000RaPC; Wed, 15 Nov 95 22:42 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0ay3@wyst.hobby.nl>; Wed, 15 Nov 95 21:11:16 CET Message-Id: <9511152011.0ay3@wyst.hobby.nl> Date: Wed, 15 Nov 1995 21:11:13 +0000 (CET) In-Reply-To: <199511151249.AA06050@diva.gmd.de> from "Joerg Hoehle" at Nov 15, 95 01:49:15 pm Content-Type: text Content-Length: 1652 From: hans@wyst.hobby.nl (Hans Verkuil) To: hoehle@zeus.gmd.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ixemul/libnix and stderr According to Joerg Hoehle: > I read (can't remember if it was in ixemul or libnix) that stderr is > set to either: > > pr_CES is not NULL > Open("*") else if not null > stdout otherwise. It's in ixemul. > when I think of it, I dislike the use of stdout. The only use I could > see is for a Workbench program, when the startup opens a window for > stdout/Output(). But then the startup should also set pr_ConsoleTask > to this window. > > How do I have to setup my programs in an Amiga environment (e.g. not > use pdksh >2 redirection) when I want _not_ to see errors (e.g. I want > to get pure pipe output (let's say of gzip -c) or use GNUEmacs with > M-! or M-|, which on UNIX would discards output to stderr)? > > I think not using stdout (e.g. using /dev/null) is the better choice. I'm not sure what you mean by 'an Amiga environment': if you mean the AmigaDOS shell, then everything works properly; if you redirect stdout, the stderr stream obtained with Open("*") still goes to the console, not to the redirected stdout. I do admit, the shell does not provide any method to redirect stderr. stdout is only used as a last resort. One can make a case of using /dev/null instead. I thought that it was more important to see the errors, even though they arrived in stdout. I'd like to see more input on this before I change anything. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 00:08:28 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <90782-2>; Thu, 16 Nov 1995 00:07:27 +0200 Received: by colombo.telesys-innov.fr; Wed, 15 Nov 1995 23:06:54 GMT From: Philippe BRAND Message-Id: <199511152306.XAA07807@colombo.telesys-innov.fr> Subject: Re: New 2.7.1 beta compiled using -mstackextend To: fnf@amigalib.com (Fred Fish) Date: Wed, 15 Nov 1995 23:06:53 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Fred Fish" at Nov 15, 95 02:09:09 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Fred Fish writes: > I have some changes to the stack handling which are not yet integrated > into ixemul.library. I'd recommend waiting until those are in before > doing too much work with any of the stack checking or stack growing > features. Yep. Just saw my first problem with stackextend-gcc. Can't wait for those changes to be integrated :) Do you have a schedule for this ? I really think we can delay 2.7.1 until new ixemul is done. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 00:11:46 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89273-2>; Thu, 16 Nov 1995 00:11:19 +0200 Received: by colombo.telesys-innov.fr; Wed, 15 Nov 1995 23:10:22 GMT From: Philippe BRAND Message-Id: <199511152310.XAA07823@colombo.telesys-innov.fr> Subject: Re: Important: replace gcc by gccv! gcc is buggy... To: fnf@amigalib.com (Fred Fish) Date: Wed, 15 Nov 1995 23:10:21 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Fred Fish" at Nov 15, 95 01:12:28 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Fred Fish writes: > Sounds reasonable to me. As I recall, the original reason for two versions > had something to do with 1.3 support as well, but perhaps I'm mistaken. > I've had it in the back of my mind for a while to revisit the issue of why > we had a gcc and gccv, and if they could be someone combined (thus also > simplifying a number of changes against the baseline gcc source tree). Yep. I'm busy now "simplifying" source tree. > I'll give it a try once I get my tree back to a stable state, probably > this weekend or early next week. I'm currently testing it. > Sounds cool. I'd like to have a copy for testing about a week from now. I'd like to have a copy for testing yesterday :) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 00:13:28 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89439-1>; Thu, 16 Nov 1995 00:13:13 +0200 Received: by colombo.telesys-innov.fr; Wed, 15 Nov 1995 23:12:39 GMT From: Philippe BRAND Message-Id: <199511152312.XAA07841@colombo.telesys-innov.fr> Subject: Re: Files missing in GCC package To: oskar@algonet.se (Oscar Mannbro) Date: Wed, 15 Nov 1995 23:12:39 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Oscar Mannbro" at Nov 15, 95 08:46:55 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Oscar Mannbro writes: > Downloaded the GCC (V2.7.0) package from Aminet. > (The archives Downloaded was:gcc270-base.lha, gcc270-c020.lha, > gcc270-cp020.lha, > gcc270-doc.lha, gcc270-inclib.lha) Proposal: rename archive gcc270-readme.lha to gcc270-grab_this_one_now_before_anything_else_or_risk_a_rtfm.lha > I haven't tried to DL it from ftp.telesys-innov.fr, it seems to be down ATM. I'm currently remote ppp connected, seems to work quite well :) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 01:13:01 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89521-1>; Thu, 16 Nov 1995 01:12:20 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFqyH-0004naC; Wed, 15 Nov 95 16:10 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New 2.7.1 beta compiled using -mstackextend To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Wed, 15 Nov 1995 16:10:25 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@lists.funet.fi In-Reply-To: <199511152306.XAA07807@colombo.telesys-innov.fr> from "Philippe BRAND" at Nov 15, 95 11:06:53 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 494 > Yep. Just saw my first problem with stackextend-gcc. Can't wait for those > changes to be integrated :) > Do you have a schedule for this ? I'm testing the latest ixemul changes now. Once that testing is done, the stack changes need to be put in and the library tested again. It takes about 3 days to verify stability with a multistage build of my GNU tree, so figure about a week or so, since it has to be done twice, once before and once after the stack changes are incorporated. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 03:03:37 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89345-2>; Thu, 16 Nov 1995 03:02:34 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFsjC-0004naC; Wed, 15 Nov 95 18:02 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: tester for L:fifo-handler wanted To: hans@wyst.hobby.nl (Hans Verkuil) Date: Wed, 15 Nov 1995 18:02:57 -0700 (MST) Cc: hoehle@zeus.gmd.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <9511131154.0agx@wyst.hobby.nl> from "Hans Verkuil" at Nov 13, 95 12:54:46 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 488 > You can also try ftp.amigalib.com, which > also has a CD online, but I don't know if the fifo-handler 38.0 is on it. I'm in the process at this moment of copying all of the baseline source, amiga source, and diffs from FreshFish 10 to ftp.amigalib.com:pub/amiga/gnu until I find a better location on the ftp server. The binaries will have to wait until I've stabilized my local tree and can create archives for them, along with new archives for things that have been updated. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 04:25:43 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89455-3>; Thu, 16 Nov 1995 04:24:49 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFu0s-0004nZC; Wed, 15 Nov 95 19:25 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: X11 clients To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Wed, 15 Nov 1995 19:25:17 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511151026.AA05964@diva.gmd.de> from "Joerg Hoehle" at Nov 15, 95 11:26:09 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1579 > > From my own experince gained during compiling various utils for my > > gcc270-utils i can asure You that only once i didn't have to add -O2 and remove > > Same for me. BTW, -O2 is not portable, as many cc only know -O. I handle this in my GNU tree by a change to autoconf, which is then used to regenerate all the configure scripts. Autoconf also causes the configure scripts to contain other patches I've found useful: diff -rc --new-file autoconf-2.4-base/acspecific.m4 autoconf-2.4/acspecific.m4 *** autoconf-2.4-base/acspecific.m4 Sun May 7 12:06:01 1995 --- autoconf-2.4/acspecific.m4 Tue Jun 20 21:57:54 1995 *************** *** 102,110 **** ])dnl AC_MSG_RESULT($ac_cv_prog_gcc_g) if test $ac_cv_prog_gcc_g = yes; then ! CFLAGS="-g -O" else ! CFLAGS="-O" fi fi else --- 102,112 ---- ])dnl AC_MSG_RESULT($ac_cv_prog_gcc_g) if test $ac_cv_prog_gcc_g = yes; then ! # Amiga hack - default to using -O2 ! # Also suppress default use of -g ! CFLAGS="-O2" else ! CFLAGS="-O2" fi fi else *************** *** 146,154 **** ])dnl AC_MSG_RESULT($ac_cv_prog_gxx_g) if test $ac_cv_prog_gxx_g = yes; then ! CXXFLAGS="-g -O" else ! CXXFLAGS="-O" fi fi else --- 148,158 ---- ])dnl AC_MSG_RESULT($ac_cv_prog_gxx_g) if test $ac_cv_prog_gxx_g = yes; then ! # Amiga hack - default to using -O2 ! # Also suppress default use of -g ! CXXFLAGS="-O2" else ! CXXFLAGS="-O2" fi fi else From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 04:31:52 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89506-4>; Thu, 16 Nov 1995 04:31:41 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tFu7U-0004nZC; Wed, 15 Nov 95 19:32 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: GNU sources & diffs online To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Wed, 15 Nov 1995 19:32:08 -0700 (MST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 322 All of the baseline source archives, amiga source archives, and diff files for the GNU tools on FreshFish 10 are now available on ftp.amigalib.com, under the temporary directory pub/amiga/gnu (they may move somewhere else on the server when I get time to think more about the eventual structure I want it to have). -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 09:37:43 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90040-1> convert rfc822-to-8bit; Thu, 16 Nov 1995 09:33:53 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 16 Nov 1995 08:33:43 +0100 (MET) From: Rask Lambertsen To: Fred Fish Cc: Joerg Hoehle , amiga-gcc-port@nic.funet.fi Subject: Re: New 2.7.1 beta compiled using -mstackextend In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 15 Nov 1995, Fred Fish wrote: > > 250KB stack size was an extension by Fred Fish, when there was no > > information about stack size when launching a new process, but I can't > > remember in which ixemul.library call. > > It is in system.c. If IXSTACK is not set, and the default is 4096 > (probably indicating that the user has no idea about the stack > problems), it is set to 250,000. If you set the stack size to > something else other than 4K, or set IXSTACK, you can get exactly > the stack you want. I don't like that. I have not seen GCC use more than 32 kB of stack for compiling, and since I'm low on memory, I don't want 218 kB of precious memory to be wasted like that. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 09:41:59 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89462-4> convert rfc822-to-8bit; Thu, 16 Nov 1995 09:40:49 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 16 Nov 1995 08:40:37 +0100 (MET) From: Rask Lambertsen To: Hans Verkuil Cc: hoehle@zeus.gmd.de, amiga-gcc-port@nic.funet.fi Subject: Re: ixemul/libnix and stderr In-Reply-To: <9511152011.0ay3@wyst.hobby.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 15 Nov 1995, Hans Verkuil wrote: [snip] > AmigaDOS shell, then everything works properly; if you redirect stdout, the > stderr stream obtained with Open("*") still goes to the console, not to the > redirected stdout. I do admit, the shell does not provide any method to > redirect stderr. It is a problem. If "*" is Open()ed, there is now way to run the programme i the background and close the Shell window. There is also no way of mixing stdout and stderr, which can sometimes be usefull. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 12:04:45 1995 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <89631-1>; Thu, 16 Nov 1995 12:02:50 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id KAA19869 for ; Thu, 16 Nov 1995 10:55:49 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA23157; Thu, 16 Nov 95 11:04:03 GMT Date: Thu, 16 Nov 95 11:04:03 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9511161104.AA23157@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: stat() and directory It seems that in ixemul stat() call always set st_nlink to 1. On files, it's all right because we don't have hardlink. but on directories, why couldn't we count the number of subdirectory to set a more UN*X compatible value in st_nlink ?? \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 12:40:16 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90722-2>; Thu, 16 Nov 1995 12:38:01 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA02777; Thu, 16 Nov 1995 11:39:47 +0100 Date: Thu, 16 Nov 1995 11:39:46 +0100 (MET) From: Kamil Iskra Subject: Re: 2.7.1 beta available To: Fred Fish cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Nov 1995, Fred Fish wrote: > Over the next few weeks I will be working > to integrate 2.7.1 into my GNU tree and when everything is stable, > will be putting binaries up on ftp.amigalib.com for several different > native configurations (68000, 68020+fpu, and 68040+fpu), to be > followed later by some cross compilers. Could you please create something like 68020-nofpu or 68030-nofpu? Some people, me for example, have accelerated Amigas but don't have FPU because it's not useful for them (not everybody does ray-tracing, you know :-). Do they really have to use "68000" version? I guess that not so many GNU tools actually use floating point math, am I right? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 12:41:54 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89496-1>; Thu, 16 Nov 1995 12:41:34 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA15667 (5.65c8/IDA-1.4.4 for ); Thu, 16 Nov 1995 11:39:58 +0100 Received: by diva.gmd.de with UUCP id AA06321 (5.67b8/IDA-1.5); Thu, 16 Nov 1995 11:36:46 +0100 Date: Thu, 16 Nov 1995 11:36:46 +0100 Message-Id: <199511161036.AA06321@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: Hans Verkuil , amiga-gcc-port@nic.funet.fi Subject: suggestion for ixemul Hi Hans, in the past, every program linked with ixemul contained 1 or 2KB of error strings. Wouldn't it be possible to have them in the library instead? Couldn't int sys_nerr; char *sys_errlist[]; be set like errno is today to point to the global error list? Or with a constructor so that if sys_err* are used at all in the program, they point to the global list? Just another 0.02(DM|$|FF|#?) idea... Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 13:10:30 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90229-3>; Thu, 16 Nov 1995 13:07:39 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA18194 (5.65c8/IDA-1.4.4 for ); Thu, 16 Nov 1995 12:07:11 +0100 Received: by diva.gmd.de id AA06340 (5.67b8/IDA-1.5); Thu, 16 Nov 1995 12:03:18 +0100 Date: Thu, 16 Nov 1995 12:03:18 +0100 From: Joerg Hoehle Message-Id: <199511161103.AA06340@diva.gmd.de> To: amiga-gcc-port@nic.funet.fi, papier@indi1.u-strasbg.fr Subject: Re: stat() and directory Hi, Laurent Papier wrote: > It seems that in ixemul stat() call always set st_nlink to 1. > On files, it's all right because we don't have hardlink. but We have hardlinks, but the information is hard to get. > on directories, why couldn't we count the number of subdirectory to set a more > UN*X compatible value in st_nlink ?? The reason is simple: we don't want a complete directory scanned every time a directory in it is stat()'ed. This would be awfully slow, not only over networks. Modifying UNIX programs which rely on these values of st_nlink is by far the better solution. Jo"rg Ho"hle. From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 13:19:15 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89775-4>; Thu, 16 Nov 1995 13:18:32 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA06638; Thu, 16 Nov 1995 12:15:29 +0100 Date: Thu, 16 Nov 1995 12:15:29 +0100 (MET) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: New 2.7.1 beta compiled using -mstackextend To: Philippe BRAND cc: Amiga-Gcc Liste In-Reply-To: <199511152306.XAA07807@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Wed, 15 Nov 1995, Philippe BRAND wrote: > Yep. Just saw my first problem with stackextend-gcc. I don't know what was your problem, but the one I have is very, very serious. Following Hans' advice I gave "gccv" a try. I mean gccv from 2.7.1 compiled with -mstackextend. It worked really fine as long as shell's stack was set to 50 KB. The only problem I had was that when I broke (^C) cc1 I got two messages about some temporary files which already exist (seems that gccv makes some strange things with these files instead of just deleting them). The real problems began when I decreased stack to 4 KB. I was unable to compile even the simplest source I could think of (empty main()) - system immediately crashed (when I runned it again with Enforcer, Enforcer generated tons of error messages). It seems that CPP runs out of stack and doesn't allocate a new chunk - this would mean that -mstackextend doesn't work, at least with IXEmul 41.4. I hope this will have been fixed by the time 2.7.1 is publically available - if not, and if gcc will be replaced with gccv, we will see tons of messages from users who will write "I could compile with 4KB stack with 2.7.0, but need 50+ KB with 2.7.1. What the hell is going on?" :-). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 13:19:27 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89877-4>; Thu, 16 Nov 1995 13:18:55 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 16 Nov 95 12:18 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 16 Nov 95 12:14 MET Message-Id: Subject: Re: 030-nofpu To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 16 Nov 1995 12:14:20 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1039 > > Could you please create something like 68020-nofpu or 68030-nofpu? Some > people, me for example, have accelerated Amigas but don't have FPU because > it's not useful for them (not everybody does ray-tracing, you know :-). Do > they really have to use "68000" version? I guess that not so many GNU > tools actually use floating point math, am I right? > is there realy a difference between 68020nofpu and 68030nofpu ? i was wondering all the time since we started to distribute all the different flavors von ixemuls, ok i see there is a different between an plain 68k, an 68k30 , with/out fpu but between '20 and '30 ? is there a way to check this out ? (please no benchmarks !) does someone have an idea (or better a prg) for a real world application ? just to test the different flavors ? of cause for complex calculation (not only raytraycing) will need an fpu, anyone with a good about a test ? walter -- ----- "How did it go, sir?" "Oh, usual bureaucracy; inch thick forms and half a pint of blood." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 13:21:02 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89150-3>; Thu, 16 Nov 1995 13:20:31 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA18925 (5.65c8/IDA-1.4.4 for ); Thu, 16 Nov 1995 12:20:15 +0100 Received: by diva.gmd.de with UUCP id AA06345 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Thu, 16 Nov 1995 12:17:03 +0100 Date: Thu, 16 Nov 1995 12:17:03 +0100 Message-Id: <199511161117.AA06345@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: ixemul/libnix and stderr In-Reply-To: References: <9511152011.0ay3@wyst.hobby.nl> Rask Lambertsen writes: > It is a problem. If "*" is Open()ed, there is now way to run the > programme i the background and close the Shell window. I don't understand this. Since OS2.0, you can use run >NIL: program (you don't even need CON:... program but I'll have to test it tonight. The bad thing is that this window will get the [CLI n] line. Hmm, maybe Run >CON:... program <>CONSOLE: will solve all problems. > There is also no > way of mixing stdout and stderr, which can sometimes be usefull. Yes. We need to think more about that issue. When to use stdout and when not. Here is part of what Stanislav Brabec wrote two months ago: -------- Trouble with pr_CES (stderr) in v 41.3 ------ My favourite (memory saving) way to run sh was: `sh <>DEV:tty01' (with DevHandler) or `sh <>CON:arguments' (with CON): Now it does not work, because <> doesn't redirect stderr. Similar problem you can find with remote sh. It requires getty and login. -------- Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 13:32:41 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89358-3> convert rfc822-to-8bit; Thu, 16 Nov 1995 13:31:40 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 16 Nov 1995 12:31:19 +0100 (MET) From: Rask Lambertsen To: Joerg Hoehle Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ixemul/libnix and stderr In-Reply-To: <199511161117.AA06345@diva.gmd.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 16 Nov 1995, Joerg Hoehle wrote: > Rask Lambertsen writes: > > It is a problem. If "*" is Open()ed, there is now way to run the > > programme i the background and close the Shell window. > > I don't understand this. Since OS2.0, you can use > run >NIL: program We've always had NIL:, it just got screwed up for OS 2.0+ :-( > (you don't even need NIL: and be happy. And you'll be happy, because you can run the No, it gets the console window if it is a CLI process. "*" is not redirected. > program in the background and close the original window. There's no > need for RunBack programs anymore. If the program Open()s "*", the console window can't be closed. So RunBack programs *are* needed with such programs. > I think that Run sets pr_ConsoleTask ("*") if the output stream is > interactive (I don't have my autodocs here). So you could get a > console window with Run <>CON:... program but I'll have to test it > tonight. The bad thing is that this window will get the [CLI n] line. > Hmm, maybe Run >CON:... program <>CONSOLE: will solve all problems. The problem is that I can't Run <>NIL: ixemul-client <>NIL: EndShell and have the console window closed if ixemul-client Open()s "*". Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 14:30:03 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88939-3>; Thu, 16 Nov 1995 14:28:11 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tG3Qd-0004nZC; Thu, 16 Nov 95 05:28 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New 2.7.1 beta compiled using -mstackextend To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Thu, 16 Nov 1995 05:28:30 -0700 (MST) Cc: fnf@amigalib.com, hoehle@zeus.gmd.de, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Nov 16, 95 08:33:43 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 964 > > It is in system.c. If IXSTACK is not set, and the default is 4096 > > (probably indicating that the user has no idea about the stack > > problems), it is set to 250,000. If you set the stack size to > > something else other than 4K, or set IXSTACK, you can get exactly > > the stack you want. > > I don't like that. I have not seen GCC use more than 32 kB of stack for > compiling, and since I'm low on memory, I don't want 218 kB of precious > memory to be wasted like that. Please reread the above. The only time it gets set to the large value is when you have not set the IXSTACK environment variable and try to run with a 4K stack. When we have a complete set of GNU tools available that run reliably with stack checking or stack extending code, then we can remove this. Until then, if you try to run with a 4K stack, you are certain to loose. To avoid this safety net, set your stack to something other than 4K or set the IXSTACK variable. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 14:35:16 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89164-3> convert rfc822-to-8bit; Thu, 16 Nov 1995 14:34:07 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 16 Nov 1995 13:33:58 +0100 (MET) From: Rask Lambertsen To: Fred Fish Cc: fnf@amigalib.com, hoehle@zeus.gmd.de, amiga-gcc-port@nic.funet.fi Subject: Re: New 2.7.1 beta compiled using -mstackextend In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 16 Nov 1995, Fred Fish wrote: [snip] > Please reread the above. The only time it gets set to the large value > is when you have not set the IXSTACK environment variable and try to > run with a 4K stack. When we have a complete set of GNU tools available > that run reliably with stack checking or stack extending code, then we > can remove this. Until then, if you try to run with a 4K stack, you > are certain to loose. > > To avoid this safety net, set your stack to something other than 4K > or set the IXSTACK variable. I don't want to be a nit-picker, but by 4K, do you mean 4000 bytes (defauld Shell stack) or 4096 bytes (default Workbench stack)? Anyway, I just remembered that I use 8 kB (8192 byte) stacks anyway. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 15:06:00 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89461-2>; Thu, 16 Nov 1995 15:04:05 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tG3zY-0004nZC; Thu, 16 Nov 95 06:04 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New 2.7.1 beta compiled using -mstackextend To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Thu, 16 Nov 1995 06:04:36 -0700 (MST) Cc: fnf@amigalib.com, hoehle@zeus.gmd.de, amiga-gcc-port@nic.funet.fi, hans@wyst.hobby.nl (Hans Verkuil) In-Reply-To: from "Rask Lambertsen" at Nov 16, 95 01:33:58 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 536 > > To avoid this safety net, set your stack to something other than 4K > > or set the IXSTACK variable. > > I don't want to be a nit-picker, but by 4K, do you mean 4000 bytes=20 > (defauld Shell stack) or 4096 bytes (default Workbench stack)? Good point. I just checked the source and it is actually tested against 4096 bytes. But since the test is for "less than or equal to", it will still provide the safety net for a stack value of 4000 bytes. I don't remember now whether the "<= 4096" behavior was deliberate or not. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 15:07:32 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89897-4>; Thu, 16 Nov 1995 15:06:39 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tG41d-0004nZC; Thu, 16 Nov 95 06:06 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New 2.7.1 beta compiled using -mstackextend To: fnf@fishpond.yggdrasil.com (Fred Fish) Date: Thu, 16 Nov 1995 06:06:45 -0700 (MST) Cc: gc948374@gbar.dtu.dk, fnf@amigalib.com, hoehle@zeus.gmd.de, amiga-gcc-port@nic.funet.fi, hans@wyst.hobby.nl In-Reply-To: from "Fred Fish" at Nov 16, 95 06:04:36 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 567 > > I don't want to be a nit-picker, but by 4K, do you mean 4000 bytes=20 > > (defauld Shell stack) or 4096 bytes (default Workbench stack)? > > Good point. I just checked the source and it is actually tested against > 4096 bytes. But since the test is for "less than or equal to", it will > still provide the safety net for a stack value of 4000 bytes. I don't > remember now whether the "<= 4096" behavior was deliberate or not. Arg. The answer was right in your email. I just didn't read it far enough. Obviously it was chosen to cover both cases. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 16:05:02 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <89516-2>; Thu, 16 Nov 1995 16:03:46 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HXPREA7IY8009W2Q@NET2.WAU.NL>; Thu, 16 Nov 1995 15:07:11 +0000 (GMT) Received: by vines2.wau.nl; Thu, 16 Nov 95 15:03:07 +0100 Date: Thu, 16 Nov 1995 15:00:23 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: Hi Thomas To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi, (Thomas) I'm on the list after much thought and some tricky use of priviledges ;) Joop From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 17:27:44 1995 Received: from hpcl.cti.gr ([150.140.91.21]) by nic.funet.fi with SMTP id <89275-1>; Thu, 16 Nov 1995 17:25:22 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA10636 (5.67a8/IDA-1.5 for ); Thu, 16 Nov 1995 17:08:36 +0200 From: Kriton Kyrimis Message-Id: <199511161508.AA10636@hpcl.cti.gr> Subject: Re: New 2.7.1 beta compiled using -mstackextend To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Thu, 16 Nov 1995 16:13:33 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi (gcc) In-Reply-To: from "Rask Lambertsen" at Nov 16, 95 08:33:43 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 468 > I don't like that. I have not seen GCC use more than 32 kB of stack for=20 > compiling, and since I'm low on memory, I don't want 218 kB of precious=20 > memory to be wasted like that. I've seen it go as high as ~450K, and I believe Fred Fish has mentioned he's seen it go as high as 1M when compiling Octave. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Things are only impossible until they're not." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 17:55:11 1995 Received: from rumms.uni-mannheim.de ([134.155.50.52]) by nic.funet.fi with SMTP id <89945-3>; Thu, 16 Nov 1995 17:52:18 +0200 Received: from pips01.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA22996 (5.65c/IDA-1.4.4 for ); Thu, 16 Nov 1995 16:46:09 +0100 Received: from pips15.informatik.uni-mannheim.de by pips01.informatik.uni-mannheim.de (4.1/BelWue-1.1Sma2(subsidiary)) id AA02491; Thu, 16 Nov 95 16:42:35 +0100 Received: by pips15.informatik.uni-mannheim.de (5.0/SMI-SVR4) id AA28899; Thu, 16 Nov 1995 16:41:57 --100 From: opel@pips01.informatik.uni-mannheim.de (Steffen Opel) Message-Id: <9511161541.AA28899@pips15.informatik.uni-mannheim.de> Subject: Re: New 2.7.1 beta compiled using -mstackextend To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Thu, 16 Nov 1995 16:41:56 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511141034.KAA28811@colombo.telesys-innov.fr> from "Philippe BRAND" at Nov 14, 95 10:34:08 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 901 Salut Philippe, as mentioned otherwise, I'd like to maintain GCC-Install. Therefore two questions (with low priority at the moment, of course): 1. > DON'T FORGET that other GNU utils are NOT compiled with stackextend so > keep a 50.000 stack on your current shell. Not specifically on this subject, but while You mention stack usage: Somehow 'GCC-Install.info' vanished from the 2.7.0-Distribution, which leads to well known stack-problems with 'Installer' for unexperienced Users. If You don't have it handy somewhere at Your site, I'll include it with GCC-Install for 2.7.1. 2. Currently the script asks people encountering problems with gcc itself to contact You at Your personal addresses. I assume You'd prefer a statement like the one in the 'Readme', which encourages use of the mailing-list first. Therefore I will change this, if it wasn't done that way with intention. Ciao, Steffen Opel From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 18:25:26 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89913-3>; Thu, 16 Nov 1995 18:22:32 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA11846 (5.65c8/IDA-1.4.4 for ); Thu, 16 Nov 1995 17:22:19 +0100 Received: by diva.gmd.de with UUCP id AA06499 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Thu, 16 Nov 1995 17:19:06 +0100 Date: Thu, 16 Nov 1995 17:19:06 +0100 Message-Id: <199511161619.AA06499@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: again: ixemul scanning ENV: In-Reply-To: <9511151940.0axo@wyst.hobby.nl> References: <199511151039.AA05970@diva.gmd.de> <9511151940.0axo@wyst.hobby.nl> Hi, Hans Verkuil writes: > 1) I scanned the sources of the GNU utils on FreshFish 7 for ssystem and > fts and found nothing (except gcc :-) This leads me to yet another idea: Maybe someone with a CD-ROM could scan the complete tree for main() lines and see if they use the dreaded unportable third argument, the environment pointer. Another look must be taken at C-program generating programs, like Scheme-To-C, f2c. Another scan could be made for references to the external *environment variable. If only (i.e.g the third argument to main is not used) the external *environment variable is used, a constructor could be defined (do I expect too much from them?) which scans ENV: for these (and only these) programs which reference *environment. And the whole rest of the programs would be happy that ENV: is not scanned at every program start anymore, which seams to cause grief and long delays to many users. Practical? Impossible? Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 19:10:07 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89037-1>; Thu, 16 Nov 1995 19:07:48 +0200 Received: by colombo.telesys-innov.fr; Thu, 16 Nov 1995 18:07:12 GMT From: Philippe BRAND Message-Id: <199511161807.SAA11524@colombo.telesys-innov.fr> Subject: Re: New 2.7.1 beta compiled using -mstackextend To: opel@pips01.informatik.uni-mannheim.de (Steffen Opel) Date: Thu, 16 Nov 1995 18:07:11 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9511161541.AA28899@pips15.informatik.uni-mannheim.de> from "Steffen Opel" at Nov 16, 95 04:41:56 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Steffen Opel writes: > as mentioned otherwise, I'd like to maintain GCC-Install. Therefore two > questions (with low priority at the moment, of course): Yep of course... Sorry I get too many emails those days, couldn't reply to all of them yet. > Not specifically on this subject, but while You mention stack usage: > Somehow 'GCC-Install.info' vanished from the 2.7.0-Distribution, which leads > to well known stack-problems with 'Installer' for unexperienced Users. If You > don't have it handy somewhere at Your site, I'll include it with GCC-Install > for 2.7.1. Yep thx. > 2. Currently the script asks people encountering problems with gcc itself to > contact You at Your personal addresses. I assume You'd prefer a statement like > the one in the 'Readme', which encourages use of the mailing-list first. > Therefore I will change this, if it wasn't done that way with intention. Oh yes :) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 20:14:23 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90333-4>; Thu, 16 Nov 1995 20:12:38 +0200 Received: from achilles.noc.ntua.gr (actually user root@achilles.noc.ntua.gr) by funet.fi with SMTP (PP); Thu, 16 Nov 1995 20:12:27 +0200 Original-Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id IAA06135 at Thu, 16 Nov 1995 08:38:12 +0200 PP-warning: Illegal Received field on preceding line Original-Received: by softlab.ece.ntua.gr with UUCP id IAA20507 at Thu, 16 Nov 1995 08:36:59 +0200 (EET) PP-warning: Illegal Received field on preceding line Received: by kriton.UUCP (V1.17-beta/Amiga) id <092s@kriton.UUCP>; Wed, 15 Nov 95 22:27:01 EET Date: Wed, 15 Nov 95 22:27:01 EET Message-Id: <9511152027.092s@kriton.UUCP> In-Reply-To: <199511150109.BAA02602@colombo.telesys-innov.fr> (from Philippe BRAND ) (at Wed, 15 Nov 1995 01:09:06 +0000 (WET)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!colombo.telesys-innov.fr!phb@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: X11 clients Hi Philippe (Philippe BRAND), in <199511150109.BAA02602@colombo.telesys-innov.fr> on Nov 15 you wrote: > Could people make in fact some benchs ? Compiling with 2.7.0 and > 2.7.1 stackextend ? Just to see exactly what is the overhead. Not exactly a benchmark, but I compiled the rayshade raytracer using gcc 2.7.0, -mstackextend, and -noixemul, and the resulting program was faster than the version I had compiled using 2.6.3, -fomit-frame-pointer (to reduce stack usage), and ixemul.library. Of course, this might only prove that -fno-omit-frame-pointer is a major optimization. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I've got this shocking pain, right behind the eyes!" "Have you considered amputation?" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 20:57:48 1995 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <89320-4> convert rfc822-to-8bit; Thu, 16 Nov 1995 20:56:47 +0200 Received: by hald.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 16 Nov 1995 19:56:33 +0100 (MET) From: Rask Lambertsen To: Kriton Kyrimis Cc: gcc Subject: Re: New 2.7.1 beta compiled using -mstackextend In-Reply-To: <199511161508.AA10636@hpcl.cti.gr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 16 Nov 1995, Kriton Kyrimis wrote: > > I don't like that. I have not seen GCC use more than 32 kB of stack for=20 > > compiling, and since I'm low on memory, I don't want 218 kB of precious=20 > > memory to be wasted like that. > > I've seen it go as high as ~450K, and I believe Fred Fish has mentioned > he's seen it go as high as 1M when compiling Octave. I don't doubt that in any way, but in my case, 250 kB of stack would be a waste of memory. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Nov 16 21:06:10 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89200-1>; Thu, 16 Nov 1995 21:05:27 +0200 Received: by nmrc.ucc.ie (8.6.10/8.6.6) with ESMTP id TAA14880; Thu, 16 Nov 1995 19:03:09 GMT From: Lars Hecking Message-Id: <199511161903.TAA22961@mostar.nmrc.ucc.ie> Subject: Re: again: ixemul scanning ENV: To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Thu, 16 Nov 1995 19:03:58 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199511161619.AA06499@diva.gmd.de> from "Joerg Hoehle" at Nov 16, 95 05:19:06 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 486 > Hans Verkuil writes: > > 1) I scanned the sources of the GNU utils on FreshFish 7 for ssystem and > > fts and found nothing (except gcc :-) > > This leads me to yet another idea: > > Maybe someone with a CD-ROM could scan the complete tree for main() > lines and see if they use the dreaded unportable third argument, the > environment pointer. Another look must be taken at C-program > generating programs, like Scheme-To-C, f2c. The only such program I found is perl5 :( From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 00:03:04 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90365-2>; Fri, 17 Nov 1995 00:01:58 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tGCge-000R1kC; Thu, 16 Nov 95 23:21 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0bbg@wyst.hobby.nl>; Thu, 16 Nov 95 20:28:16 CET Message-Id: <9511161928.0bbg@wyst.hobby.nl> Date: Thu, 16 Nov 1995 20:28:13 +0000 (CET) In-Reply-To: from "Rask Lambertsen" at Nov 16, 95 08:33:43 am Content-Type: text Content-Length: 2009 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: New 2.7.1 beta compiled using -mstackextend According to Rask Lambertsen: > > On Wed, 15 Nov 1995, Fred Fish wrote: > > > > 250KB stack size was an extension by Fred Fish, when there was no > > > information about stack size when launching a new process, but I can't > > > remember in which ixemul.library call. > >=20 > > It is in system.c. If IXSTACK is not set, and the default is 4096 > > (probably indicating that the user has no idea about the stack > > problems), it is set to 250,000. If you set the stack size to > > something else other than 4K, or set IXSTACK, you can get exactly > > the stack you want. > > I don't like that. I have not seen GCC use more than 32 kB of stack for > compiling, and since I'm low on memory, I don't want 218 kB of precious > memory to be wasted like that. I've looked into it and first of all I wonder if IXSTACK is actually used! It is only used in the system call, but gcc uses ssystem(), which doesn't call system unless you try to execute an AmigaDOS script. vfork/execve doesn't use IXSTACK at all. vfork uses a stack which is either 4 times the default stack size if started from a CLI or it copies the stack size of the parent process. I too consider 250K a bit overkill. Proposal: use the same method for both vfork/execve and for the system call. If IXSTACK is defined, use that value. Otherwise copy the value from the parent process, but with a minimum of a value between 16 and 32 K. 4K I consider unsafe. Correct me if I'm wrong, but I suspect that the ixemul.library doesn't use the stack-extension routines, so that if the library overwrites stack, you're out of luck. Therefore we need to reserve some elbow room for the library too, so 16 K would be a good comprimise I think. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 00:03:14 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90565-2>; Fri, 17 Nov 1995 00:02:57 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tGChW-000R1kC; Thu, 16 Nov 95 23:22 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0bbl@wyst.hobby.nl>; Thu, 16 Nov 95 20:59:46 CET Message-Id: <9511161959.0bbl@wyst.hobby.nl> Date: Thu, 16 Nov 1995 20:59:43 +0000 (CET) In-Reply-To: from "Rask Lambertsen" at Nov 16, 95 08:40:37 am Content-Type: text Content-Length: 1186 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ixemul/libnix and stderr According to Rask Lambertsen: > It is a problem. If "*" is Open()ed, there is now way to run the=20 > programme i the background and close the Shell window. There is also no=20 > way of mixing stdout and stderr, which can sometimes be usefull. Why can't you run a program in the background? Using "run >nil: nil: output" works perfectly! It is indeed not possible (unless you use pdksh) to redirect stderr from an AmigaDOS shell. And you really do not want to mix stderr and stdout. Especially when you are using programs like groff that start a whole pipeline of programs. Error messages from one of the earlier exes used to be propagated through the whole pipeline, leading to garbage at the end. I can live with this as a last resort (i.e. when even Open("*") fails), although there is a lot to be said to open /dev/null instead. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 00:04:51 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90049-1>; Fri, 17 Nov 1995 00:04:43 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tGCjP-000R1kC; Thu, 16 Nov 95 23:24 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0bc0@wyst.hobby.nl>; Thu, 16 Nov 95 21:33:41 CET Message-Id: <9511162033.0bc0@wyst.hobby.nl> Date: Thu, 16 Nov 1995 21:33:39 +0000 (CET) In-Reply-To: from "Rask Lambertsen" at Nov 16, 95 12:31:19 pm Content-Type: text Content-Length: 927 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ixemul/libnix and stderr According to Rask Lambertsen: > The problem is that I can't > > Run <>NIL: ixemul-client <>NIL: > EndShell > > and have the console window closed if ixemul-client Open()s "*". I wouldn't use this construct at all if I were you: I tried it and got four enforcer hits (without using a ixemul-client, just c:date)! I have no problems if I use run >nil: nil:'. Can someone with 3.0/3.1 and enforcer check if this has been solved there? Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 00:05:31 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90537-1>; Fri, 17 Nov 1995 00:05:18 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tGCkD-000R1kC; Thu, 16 Nov 95 23:25 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0bca@wyst.hobby.nl>; Thu, 16 Nov 95 22:04:06 CET Message-Id: <9511162104.0bca@wyst.hobby.nl> Date: Thu, 16 Nov 1995 22:04:04 +0000 (CET) In-Reply-To: <199511161619.AA06499@diva.gmd.de> from "Joerg Hoehle" at Nov 16, 95 05:19:06 pm Content-Type: text Content-Length: 1385 From: hans@wyst.hobby.nl (Hans Verkuil) To: hoehle@zeus.gmd.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: again: ixemul scanning ENV: Hi, According to Joerg Hoehle: > This leads me to yet another idea: > > Maybe someone with a CD-ROM could scan the complete tree for main() > lines and see if they use the dreaded unportable third argument, the > environment pointer. Another look must be taken at C-program > generating programs, like Scheme-To-C, f2c. Why unportable? Unportable to what? > Another scan could be made for references to the external *environment > variable. If only (i.e.g the third argument to main is not used) the > external *environment variable is used, a constructor could be defined > (do I expect too much from them?) which scans ENV: for these (and only > these) programs which reference *environment. Why not implement the following scheme: when the library is loaded for the first time it scans ENV: once. Optionally (I don't know how much work that is), it sets a Notify on ENV:. When a new process is created it just adds that global env-list to its internal env-settings. One of the programs that uses a third parameter is pdksh, so I'm afraid you're stuck with that :-) Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 00:45:43 1995 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <90758-4> convert rfc822-to-8bit; Fri, 17 Nov 1995 00:42:46 +0200 Received: by hald.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 16 Nov 1995 23:42:24 +0100 (MET) From: Rask Lambertsen To: Hans Verkuil Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ixemul/libnix and stderr In-Reply-To: <9511161959.0bbl@wyst.hobby.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 16 Nov 1995, Hans Verkuil wrote: > According to Rask Lambertsen: > > > It is a problem. If "*" is Open()ed, there is now way to run the=20 > > programme i the background and close the Shell window. There is also no=20 > > way of mixing stdout and stderr, which can sometimes be usefull. > > Why can't you run a program in the background? Using > "run >nil: nil: output" works > perfectly! I'm pretty sure it doesn't work on my system. Last time I tried, the console window wouldn't close. > It is indeed not possible (unless you use pdksh) to redirect stderr from an > AmigaDOS shell. And you really do not want to mix stderr and stdout. Actually, I have a case where I'm piping the output of finger to awk, and need to mix stdout and stderr, so that error messages can be handled by the awk script. It is an essential part of the finger-WWW gateway at http://srv2.gbar.dtu.dk:8001/cgi-bin/f where error messages from the 'net has to processed to produce a nice looking and understandable responce to the user. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 00:55:51 1995 Received: from ns.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with ESMTP id <90333-2>; Fri, 17 Nov 1995 00:53:41 +0200 Received: from wiedmann.neckar-alb.de (wiedmann@[194.23.154.253]) by ns.neckar-alb.de (8.7.1/8.7.1) with ESMTP id XAA28537; Thu, 16 Nov 1995 23:52:37 +0100 (MET) Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id XAA00342; Thu, 16 Nov 1995 23:52:50 +0100 From: wiedmann Message-Id: <199511162252.XAA00342@wiedmann.neckar-alb.de> Subject: Re: ixemul/libnix and stderr To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Thu, 16 Nov 1995 23:52:49 +0100 (MET) Cc: hans@wyst.hobby.nl, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Nov 16, 95 11:42:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit > > On Thu, 16 Nov 1995, Hans Verkuil wrote: > > > According to Rask Lambertsen: > > > > > It is a problem. If "*" is Open()ed, there is now way to run the=20 > > > programme i the background and close the Shell window. There is also no=20 > > > way of mixing stdout and stderr, which can sometimes be usefull. > > > > Why can't you run a program in the background? Using > > "run >nil: nil: output" works > > perfectly! > > I'm pretty sure it doesn't work on my system. Last time I tried, the > console window wouldn't close. Obviously. ixemul Open()'s * three times: stdin, stdout and stderr. Your redirection works on stdin and stdout, thus * is Close()'d two times. So you cannot close the window, because the third filehandle is still open. Jochen From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 11:47:53 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90464-3>; Fri, 17 Nov 1995 11:21:58 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA10789 (5.65c8/IDA-1.4.4 for ); Fri, 17 Nov 1995 10:21:49 +0100 Received: by diva.gmd.de with UUCP id AA06642 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Fri, 17 Nov 1995 10:18:36 +0100 Date: Fri, 17 Nov 1995 10:18:36 +0100 Message-Id: <199511170918.AA06642@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Subject: Re: again: ixemul scanning ENV: In-Reply-To: <199511161903.TAA22961@mostar.nmrc.ucc.ie> References: <199511161619.AA06499@diva.gmd.de> <199511161903.TAA22961@mostar.nmrc.ucc.ie> Lars Hecking writes: > > Maybe someone with a CD-ROM could scan the complete tree for main() > > lines and see if they use the dreaded unportable third argument, the > > environment pointer. Another look must be taken at C-program > > generating programs, like Scheme-To-C, f2c. > > The only such program I found is perl5 :( When I thought more about it, it came to my mind that every program which does not only access some variables of known names but needs the whole environment will have to use either main(envp) or char **environ. Knowing this, I knew that every shell or command which implements a "set", "env" or "printenv" like functionality would use any of these. Hans Verkuil writes: > One of the programs that uses a third parameter is pdksh, so I'm afraid > you're stuck with that :-) I guessed it :) Emacs also uses **environ as it maintains the process-environment variable. Emacs even uses main(envp) but only to initialize its pointer to the environment if **environ itself is NULL, so this could be easily wiped out the day we'll be able to compile Emacs with GCC. The "env" command in the emacs/etc/ directory also uses **environ. Hmm, I think that if we could get a constructor for **environ to work, then we could drop support for main(envp), as envp could then be initialized with **environ, changing one line of source code. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 11:59:22 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90229-4>; Fri, 17 Nov 1995 11:55:54 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA13083 (5.65c8/IDA-1.4.4 for ); Fri, 17 Nov 1995 10:55:28 +0100 Received: by diva.gmd.de with UUCP id AA06647 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Fri, 17 Nov 1995 10:52:16 +0100 Date: Fri, 17 Nov 1995 10:52:16 +0100 Message-Id: <199511170952.AA06647@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: ixemul/libnix and stderr In-Reply-To: References: <9511161959.0bbl@wyst.hobby.nl> Rask Lambertsen writes: > > Why can't you run a program in the background? Using > > "run >nil: nil: output" works > > perfectly! > I'm pretty sure it doesn't work on my system. Last time I tried, the=20 > console window wouldn't close. What's your system? When was the last time? What patches have you installed? Since 2.0, Run >foo:xxx will set "*" to a cloned handle from foo:xxx if it is interactive. This applies to NIL:, CON:, FIFO: and others (of course, NIL: has no message port which can be put in pr_ConsoleTask). Please RTFM about Execute() and System(). Run CON:... program will not let "program" find the original console! It can be safely closed. I do this since 2.0. Last night I tried my suggestion about Run >CON:... program <>CONSOLE: and it worked perfectly, even with /bin/sh (don't know what version or which ixemul.library). I'm running 3.1. Because <> is buggy in older systems (causing a write to ROM if I remember right, I think this is one of the many things that has been corrected in 3.1), my suggestion can easily be replaced with: Run >CON:... program CONSOLE: Well, Run >CON:... program It is indeed not possible (unless you use pdksh) to redirect stderr from an > AmigaDOS shell. The above shows how it's possible with interactive file streams. FIFO: declares itself as interactive, PIPE: not. You may take advantage of this knowledge, this behaviour is fully documented. > And you really do not want to mix stderr and stdout. Neither me. Unless explicitly requested and set as above. Regards, Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 12:26:39 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90565-4>; Fri, 17 Nov 1995 12:23:16 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HXQY0EWEWW00A4KA@NET2.WAU.NL>; Fri, 17 Nov 1995 11:26:48 +0000 (GMT) Received: by vines2.wau.nl; Fri, 17 Nov 95 11:22:49 +0100 Date: Fri, 17 Nov 1995 11:18:23 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: re: again: ixemul scanning ENV: To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) To Hans, > >And the whole rest of the programs would be happy that ENV: is not >scanned at every program start anymore, which seams to cause grief and >long delays to many users. I seem to have a problem with Ghostscript not being able to get its GS_LIB enviroment variables when compiled for ixemul.library (40.4). set GS_LIB=gnu:source/gs351, works, but setenv GS_LIB= '' doesn't If linked with Libnix then both way do work. Snoopdos shows that GS_LIB is read but is not acted upon. GS uses getenv(). Joop From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 12:34:24 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89418-3>; Fri, 17 Nov 1995 12:31:16 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA15303 (5.65c8/IDA-1.4.4 for ); Fri, 17 Nov 1995 11:31:08 +0100 Received: by diva.gmd.de with UUCP id AA06667 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Fri, 17 Nov 1995 11:27:55 +0100 Date: Fri, 17 Nov 1995 11:27:55 +0100 Message-Id: <199511171027.AA06667@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: again: ixemul scanning ENV: In-Reply-To: <9511162104.0bca@wyst.hobby.nl> References: <199511161619.AA06499@diva.gmd.de> <9511162104.0bca@wyst.hobby.nl> Hans Verkuil writes: > Why unportable? Unportable to what? Sorry, I thought it was not portable among UNIX, but it looks like both main(envp) and **environ are. Do you have any POSIX or whatever books? At least, I consider it not portable outside of UNIX, but then ixemul was not written to help in those cases :) > Why not implement the following scheme: when the library is loaded for the > first time it scans ENV: once. Optionally (I don't know how much work that > is), it sets a Notify on ENV:. When a new process is created it just adds > that global env-list to its internal env-settings. This idea was turned down in the past because notification requires a task, and we had only a library. We didn't want to have a task running around just for that. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 12:52:26 1995 Received: from plukwa ([194.92.208.7]) by nic.funet.fi with SMTP id <88986-1>; Fri, 17 Nov 1995 12:48:03 +0200 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 17 Nov 95 11:46:36 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <21a03719.u8t20e.d9079-robert@plukwa.lodz.pdi.net> Subject: Re: ixemul/libnix and stderr Reply-To: robert@lodz.pdi.net Reply-To: robert@lodz.pdi.net Content-Length: 1830 To: amiga-gcc-port@nic.funet.fi Date: Fri, 17 Nov 95 11:46:36 Organization: PDi On Nov 16 Hans Verkuil wrote: > > Run <>NIL: ixemul-client <>NIL: > > It's even shorter and runs without enforcer hits and you really can close > the console window! Believe me, I tried it. Apparently, AmigaDOS has > problems with '<>nil:'. Can someone with 3.0/3.1 and enforcer check if this > has been solved there? I tried above with c:date and GNU:bin/ls on AmigaOS3.0 with enforcer and didnt get any hits > > Hans > > -- > Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, > The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl > > "...and the princesses were beautiful as the day is long and so noble they > could pee through a dozen mattresses --" (Terry Pratchett) > Robert -- +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ -- +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 14:28:39 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90183-1>; Fri, 17 Nov 1995 14:24:41 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HXR28XKNNK00A8TV@NET2.WAU.NL>; Fri, 17 Nov 1995 13:28:12 +0000 (GMT) Received: by vines2.wau.nl; Fri, 17 Nov 95 13:24:20 +0100 Date: Fri, 17 Nov 1995 13:21:39 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: specs file 2.7.1 suggestion To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Kamil wrote: >3. "-m68020-40" and "-mc68020" are not fully supported again >(argh!:-). In both cases, "ld" is not called with "-fl libm020". >Additionally, in case of "-m68020-40", preprocessor is not called with >"-Dmc68020" and assembler is not called with "-mc68020". I miss -Dmc68881 too, it is needed when -m68020-40 is used. I think someone need to go over the -m68xxx options and see what else is missing. IMHO it is far from being consistent. Joop From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 14:35:29 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89696-3>; Fri, 17 Nov 1995 14:32:14 +0200 Received: (from kiskra@localhost) by ernie (8.6.12/8.6.12) id MAA07492; Fri, 17 Nov 1995 12:23:03 +0100 Date: Fri, 17 Nov 1995 12:23:03 +0100 (MET) From: Kamil Iskra Subject: Re: again: ixemul scanning ENV: To: Joerg Hoehle cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511171027.AA06667@diva.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 17 Nov 1995, Joerg Hoehle wrote: > Hans Verkuil writes: > > Why not implement the following scheme: when the library is loaded for the > > first time it scans ENV: once. Optionally (I don't know how much work that > > is), it sets a Notify on ENV:. When a new process is created it just adds > > that global env-list to its internal env-settings. > > This idea was turned down in the past because notification requires a > task, and we had only a library. We didn't want to have a task running > around just for that. If I remember correctly, when I start my Amiga, I have about 40 tasks and processes running. One more means nothing to me. I could accept 10 more tasks in my system if only IXEmul programs' startup was faster. And I'm positively sure that most other people would accept the existance of these tasks, too. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 14:45:06 1995 Received: from srv3.gbar.dtu.dk ([130.225.87.163]) by nic.funet.fi with ESMTP id <89477-2> convert rfc822-to-8bit; Fri, 17 Nov 1995 14:44:01 +0200 Received: by srv3.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 17 Nov 1995 13:43:30 +0100 (MET) From: Rask Lambertsen To: Kamil Iskra Cc: Joerg Hoehle , amiga-gcc-port@nic.funet.fi Subject: Re: again: ixemul scanning ENV: In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Fri, 17 Nov 1995, Kamil Iskra wrote: > If I remember correctly, when I start my Amiga, I have about 40 tasks and > processes running. One more means nothing to me. I could accept 10 more > tasks in my system if only IXEmul programs' startup was faster. And I'm > positively sure that most other people would accept the existance of these > tasks, too. I agree here. I'd rather have a mostly idle tast in my system than have to wait 5 seconds extra when starting up ixemul clients. Those extra 5 seconds have so far made me use real Amiga ports when possible, instead of ixemul versions. And those with virtual memory might be even happier with this, as they effectively won't loose RAM this way. Remember, when compiling, you'll win 5*x seconds, where x is the time taken to scan ENV:, for each C source file. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://srv2.gbar.dtu.dk:8001/Rask/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 15:18:13 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90620-2>; Fri, 17 Nov 1995 15:15:15 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA25299 (5.65c8/IDA-1.4.4 for ); Fri, 17 Nov 1995 14:14:58 +0100 Received: by diva.gmd.de with UUCP id AA06775 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Fri, 17 Nov 1995 14:11:45 +0100 Date: Fri, 17 Nov 1995 14:11:45 +0100 Message-Id: <199511171311.AA06775@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: again: ixemul scanning ENV: In-Reply-To: References: Hi, Rask Lambertsen writes: > I agree here. I'd rather have a mostly idle tast in my system than have=20 > to wait 5 seconds extra when starting up ixemul clients. Those extra 5=20 > seconds have so far made me use real Amiga ports when possible, instead=20 > of ixemul versions. And those with virtual memory might be even happier=20 Then we should leave it in :) In my opinion, it's better to go with an amiga-ized version of a program where the author of the port did think about it, removed features that make no sense on the normal Amiga (pipe to lpr, gethostname, huge terminal/termcap support, complex ioctl) and changed a few lines where pathname syntax differ, than to use a bigger generic port, relying on the sole ixemul to do everything and transform calls back to native AmigaOS calls. > with this, as they effectively won't loose RAM this way. VMM can't swap the thing completely out. > Remember, when compiling, you'll win 5*x seconds, where x is the time=20 > taken to scan ENV:, for each C source file. It doesn't do so for me, even on my 68000, I don't know why. Gcc is ixemul-compiled and will use execve() (like gccv) in the near future, execve supplies the environment, thus it need not be scanned when calling other ixemul programs like cc1 and cpp. You win nothing. > /=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= > =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= > =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= > \ > | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk = We'll see how we can solve this issue. It's not the first attempt at it :) Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de PS: I hate MIME quoted-printable, it looks really stupid :-( From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 15:35:39 1995 Received: from gate1.informatik.fh-wiesbaden.de ([193.175.36.254]) by nic.funet.fi with SMTP id <89913-1>; Fri, 17 Nov 1995 15:32:40 +0200 Received: from sun.informatik.fh-wiesbaden.de (sun15.informatik.fh-wiesbaden.de) by gate1.informatik.fh-wiesbaden.de with SMTP id AA03408 (5.65c/IDA-1.4.4); Fri, 17 Nov 1995 13:58:50 +0100 Received: by sun.informatik.fh-wiesbaden.de (4.1/fhw-FBI_sun-Nl) id AA03553; Fri, 17 Nov 95 13:58:31 +0100 From: i511@informatik.fh-wiesbaden.de (Stefan Ruppert) Message-Id: <9511171258.AA03553@sun.informatik.fh-wiesbaden.de> Subject: Re: again: ixemul scanning ENV: To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Fri, 17 Nov 1995 13:58:31 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Nov 17, 95 12:23:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 719 Hi, > If I remember correctly, when I start my Amiga, I have about 40 tasks and > processes running. One more means nothing to me. I could accept 10 more > tasks in my system if only IXEmul programs' startup was faster. And I'm > positively sure that most other people would accept the existance of these > tasks, too. What about a notify daemon like crond under unix for periodically called commands ? > / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ Stefan -- Home: Stefan Ruppert EMail: ruppert@goofy.zdv.uni-mainz.de Windthorststrasse 5 i511@informatik.fh-wiesbaden.de 65439 Floersheim am Main WWW: http://www.uni-mainz.de/~ruppert/ GERMANY From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 18:49:58 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90038-2>; Fri, 17 Nov 1995 18:48:33 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26636-1>; Fri, 17 Nov 1995 17:22:06 +0100 Received: from hphalle6j.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395741-1>; Fri, 17 Nov 1995 17:21:53 +0100 Subject: Re: again: ixemul scanning ENV: From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 17 Nov 1995 17:21:51 +0100 (MEZ) In-Reply-To: <9511162104.0bca@wyst.hobby.nl> from "Hans Verkuil" at Nov 16, 95 10:04:04 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1137 Message-Id: <95Nov17.172153+0100mesz.395741-1+1175@hphalle0.informatik.tu-muenchen.de> > > Maybe someone with a CD-ROM could scan the complete tree for main() > > lines and see if they use the dreaded unportable third argument, the > > environment pointer. > > Why unportable? Unportable to what? Unportable to non-Unix. C defines two possible main() signatures: int main(void) and int main(int, char **). The 3rd arg is a unix extension (I think that most MS-DOS compilers supply it, too; but it's still a system-specific extension, just like "void main()" for SAS6). > One of the programs that uses a third parameter is pdksh, so I'm afraid > you're stuck with that :-) But then, pdksh is severely hacked for AmigaOS anyway (because we can't fork()), isn't it? So it should be possible to replace int main(int argc, char **argv, char **env) { } with int main(int argc, char **argv) { char **env; env=ScanMyEnv(); } Just my $0.02, Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Fri Nov 17 18:50:01 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90110-1>; Fri, 17 Nov 1995 18:48:49 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26586-3>; Fri, 17 Nov 1995 17:28:18 +0100 Received: from hphalle6j.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395735-1>; Fri, 17 Nov 1995 17:28:02 +0100 Subject: Re: again: ixemul scanning ENV: From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Fri, 17 Nov 1995 17:27:56 +0100 (MEZ) In-Reply-To: <199511171027.AA06667@diva.gmd.de> from "Joerg Hoehle" at Nov 17, 95 11:27:55 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1028 Message-Id: <95Nov17.172802+0100mesz.395735-1+1180@hphalle0.informatik.tu-muenchen.de> > > Why not implement the following scheme: when the library is loaded for the > > first time it scans ENV: once. Optionally (I don't know how much work that > > is), it sets a Notify on ENV:. When a new process is created it just adds > > that global env-list to its internal env-settings. > > This idea was turned down in the past because notification requires a > task, and we had only a library. This is incorrect. You can use notification without a task. Notification can send a message. A message is sent to a port, not to a task. A port can be PA_IGNORE. which means nobody is signalled. Some library function would just have to check whether the port is empty or not, which doesn't cost anything since we only need to do this when an ixemul client starts. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Sat Nov 18 11:48:23 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90677-1>; Sat, 18 Nov 1995 11:45:56 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tGkAy-000QyJC; Sat, 18 Nov 95 11:07 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0bi7@wyst.hobby.nl>; Fri, 17 Nov 95 21:34:40 CET Message-Id: <9511172034.0bi7@wyst.hobby.nl> Date: Fri, 17 Nov 1995 21:34:36 +0000 (CET) Content-Type: text Content-Length: 1832 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Subject: IXSTACK, Open("*") and global environment... Hi all, Based on the recent discussions I've decided on the following: 1) I will set the stack to the following value: if IXSTACK is defined, then that value will be used. Regardless. If not, then it inherits the parents stack or it uses the CLI stack size (set by the ADOS stack command), depending on whether the parent has a CLI structure or not. But it will ensure a minimum stack of 16Kb (16384 bytes). This method will be used both by system() and by vfork(). 2) I won't change the way stderr is opened. 3) I've added the following entry to the TODO list: *** Improve the handling of global environment variables (from ENV:). The idea is as follows: when the library is first opened, it reads ENV:. It also sets a Notify request on ENV:. Whenever an ixemul client is started, the library checks whether it was notified and, if so, it scans ENV: again. Notifies should go to a message port which is PA_IGNORE, which means nobody is signalled, which means that you don't require a task to handle this. In my opinion it isn't too difficult to implement this scheme, which should put an end to the discussions on this subject. Very little overhead too. By the way, is everybody aware that you can ignore the global environment entirely (using an ixconfig flag)? I use this all the time. All the settings I need are local, and I set them before I load IPrefs. If you use this method, then whenever you open a new shell, it inherits its local environment from iprefs. This works very well. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat Nov 18 11:48:27 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89727-4>; Sat, 18 Nov 1995 11:46:57 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tGkBu-000QyJC; Sat, 18 Nov 95 11:08 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0bih@wyst.hobby.nl>; Fri, 17 Nov 95 23:10:27 CET Message-Id: <9511172210.0bih@wyst.hobby.nl> Date: Fri, 17 Nov 1995 23:10:24 +0000 (CET) In-Reply-To: from "test1" at Nov 17, 95 11:18:23 am Content-Type: text Content-Length: 847 From: hans@wyst.hobby.nl (Hans Verkuil) To: test1@MEDEW.ENTO.WAU.NL Cc: amiga-gcc-port@nic.funet.fi Subject: Re: again: ixemul scanning ENV: Hi Joop, > I seem to have a problem with Ghostscript not being able to get its GS_LIB > enviroment variables when compiled for ixemul.library (40.4). > set GS_LIB=gnu:source/gs351, works, but > setenv GS_LIB= '' doesn't > If linked with Libnix then both way do work. > Snoopdos shows that GS_LIB is read but is not acted upon. GS uses getenv(). I tried a small test program and it worked fine for me. But please upgrade to version 41.4, the version you are using is rather ancient: lots of bugs have been fixed since 40.4. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat Nov 18 13:56:20 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <89844-4>; Sat, 18 Nov 1995 13:54:31 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HXSFGT5Z1S00ATH3@NET2.WAU.NL>; Sat, 18 Nov 1995 12:57:58 +0000 (GMT) Received: by vines2.wau.nl; Sat, 18 Nov 95 12:53:54 +0100 Date: Sat, 18 Nov 1995 12:51:11 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: ENV: scanning by ixemul To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >> I seem to have a problem with Ghostscript not being able to get its GS_LIB >> enviroment variables when compiled for ixemul.library (40.4). >> set GS_LIB=gnu:source/gs351, works, but >> setenv GS_LIB= '' doesn't >> If linked with Libnix then both way do work. >> Snoopdos shows that GS_LIB is read but is not acted upon. GS uses getenv(). >Walter writes: > you never read mail totaly or :) see if you can find my little env.c > i posted recently i found the problem as well but the problems seems > to be located inside the AmigaOS (i tried echo). if you can find it > i will see to mail you. Apologies, sometime back it really didn't work but I just checked and it works, but I haven't the faintest clue as to what has changed :( Both ixemul and Libnix accept the the 'set' and 'setenv' versions of GS_LIB. I'm using KingCON as my shell and gcc2.7.0 and ixemul40.4/LibnixV1. Joop From amiga-gcc-port-owner@nic.funet.fi Sat Nov 18 13:57:02 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <88927-2>; Sat, 18 Nov 1995 13:56:01 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HXSFIZ7IZ400AY7V@NET2.WAU.NL>; Sat, 18 Nov 1995 12:59:43 +0000 (GMT) Received: by vines2.wau.nl; Sat, 18 Nov 95 12:55:41 +0100 Date: Sat, 18 Nov 1995 12:54:24 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: ENV: scanning To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hans wrote: >I tried a small test program and it worked fine for me. But please upgrade >to version 41.4, the version you are using is rather ancient: lots of bugs >have been fixed since 40.4. Oops, what I meant to write was ofcourse 41.4, same applies the previous mail which left seconds before this one. Joop From amiga-gcc-port-owner@nic.funet.fi Sat Nov 18 14:36:50 1995 Received: from NET.WAU.NL ([137.224.10.12]) by nic.funet.fi with ESMTP id <88943-4>; Sat, 18 Nov 1995 14:35:41 +0200 Received: from Flex058.dBH.WAU.NL by NET.WAU.NL (PMDF V4.3-13 #6821) id <01HXSGSZMHWG002D44@NET.WAU.NL>; Sat, 18 Nov 1995 13:36:02 +0000 (GMT) Date: Sat, 18 Nov 1995 13:35:28 -0800 (PST) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (Joop van de Wege) Subject: GCC bounds checking 2.7.1/1.0 released (fwd) To: amiga-gcc-port@lists.funet.fi Message-id: <01HXSGT005SI002D44@NET.WAU.NL> Organization: Entomology, Wageningen Agricultural University X-Envelope-to: amiga-gcc-port@lists.funet.fi MIME-version: 1.0 X-Mailer: WinVN 0.99.7 Content-type: Text/Plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <48i017$i87@frigate.doc.ic.ac.uk> Keywords: gcc bounds checking pointer Anyone interested in this topic to add it to the Amiga port of gcc ? Joop ----Forwarded---- Path: news.wau.nl!news.nic.surfnet.nl!howland.reston.ans.net!tank.news.pipex.net!pip ex!news.mathworks.com!newsfeed.internetmci.com!btnet!zetnet.co.uk!demon!sunsit e.doc.ic.ac.uk!doc.ic.ac.uk!rwmj From: rwmj@doc.ic.ac.uk (Richard Jones) Newsgroups: comp.lang.c Subject: GCC bounds checking 2.7.1/1.0 released Date: 17 Nov 1995 12:43:19 GMT Organization: Dept. of Computing, Imperial College, University of London, UK. Lines: 30 Message-ID: <48i017$i87@frigate.doc.ic.ac.uk> NNTP-Posting-Host: oak44.doc.ic.ac.uk Keywords: gcc bounds checking pointer X-Newsreader: TIN [version 1.2 PL2] *** GCC 2.7.1 with Bounds Checking: Version 1.0 released *** The latest version of the patches that give full fine-grained bounds checking to GCC have been released and are available from: ftp://dse.doc.ic.ac.uk/pub/misc/bcc Please read the latest README file in that directory which will tell you how to install and compile the patches. There are also binary distributions for the following machines: i486-unknown-linux (ELF only) sparc-sun-sunos4.1.3_U1 (coming soon: HP-PA, Solaris binaries). For more information, there are WWW pages for this software: http://www-dse.doc.ic.ac.uk/~rj3/bounds-checking.html http://www-ala.doc.ic.ac.uk/~phjk/BoundsChecking.html Richard W.M. Jones -- "The real tight interface is between the book and the reader - the world of the book is plugged right into your brain, never mind the [virtual reality] bodysuit" -- from The Age of Missing Information, by Bill McKibben. From amiga-gcc-port-owner@nic.funet.fi Sat Nov 18 19:43:55 1995 Received: from carina.rz.Uni-Osnabrueck.DE ([131.173.128.25]) by nic.funet.fi with SMTP id <89268-4>; Sat, 18 Nov 1995 19:42:58 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id SAA41686; Sat, 18 Nov 1995 18:42:46 +0100 From: Thomas Radtke Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.7.1/8.7.1) id SAA21487; Sat, 18 Nov 1995 18:42:46 +0100 Message-Id: <199511181742.SAA21487@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: GCC bounds checking 2.7.1/1.0 released (fwd) To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (Joop van de Wege) Date: Sat, 18 Nov 1995 18:42:46 +0100 (NFT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <01HXSGT005SI002D44@NET.WAU.NL> from "Joop van de Wege" at Nov 18, 95 01:35:28 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > http://www-dse.doc.ic.ac.uk/~rj3/bounds-checking.html > http://www-ala.doc.ic.ac.uk/~phjk/BoundsChecking.html just red the pages and like that idea of having more _warning_ messages, but would rather consider myself a 'naiv' user waiting until this project is out of its beta state :). If anybody needs this meanwhilst, APurify is maybe also doing a good job of checking that kind of problems (and doesnt blow up the compiler btw.). Thomas From amiga-gcc-port-owner@nic.funet.fi Sun Nov 19 21:15:34 1995 Received: from ciistr1.ist.utl.pt ([193.136.128.1]) by nic.funet.fi with SMTP id <89833-3>; Sun, 19 Nov 1995 21:10:50 +0200 Received: from alfa.ist.utl.pt by ciistr1.ist.utl.pt; (5.65v3.0/1.1.8.2/24Jul95-0207PM) id AA06973; Sun, 19 Nov 1995 20:09:57 GMT Received: by alfa.ist.utl.pt; (5.65v3.0/1.1.8.2/08Aug95-1153AM) id AA25462; Sun, 19 Nov 1995 20:10:56 GMT Date: Sun, 19 Nov 1995 20:10:56 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Amiga Ixemul Mailling list Cc: Amiga GCC Mailling list Subject: Bug in handler usage by ixemul41.4 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There is a bug in ixemul.library 41.4 that just made loose a day of work that I could not afourd! The bug relates to open() on DOS devices that are not file systems, therefore are Handlers. For a while I've been working with distributed video processing systems and, part of the job was a handler that enabled Amiga and UniX aplications (like XV) to capture frames on a PC's digitizer board like if they were reading a file. This handler was never a source of trouble until I had to build its report (for my teacher) today. I was suprized when it did not work anymore and, even worse, a protection fault caused the called program to die! After an entire day of debugging I remembered that the last time I used it was with ix41.1 and now I have 41.4. To cut a long story short: I logged the packets driven from one side to the other and I came to: -41.1 ACTION_LOCATE_OBJECT ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ... ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ACTION_EXAMINE_OBJECT ACTION_INFO ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ... ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ACTION_EXAMINE_OBJECT ACTION_INFO ACTION_FREE_LOCK ACTION_IS_FILESYSTEM ACTION_FINDINPUT ... and all goes fine from here on... -41.4 ACTION_LOCATE_OBJECT ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ... ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ACTION_EXAMINE_OBJECT ACTION_INFO ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ... ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ACTION_EXAMINE_OBJECT ACTION_INFO ACTION_FREE_LOCK and now, when it should test the IS_FILESYSTEM, it dies! I believe, by accident, the support for handlers was currupted. I hope its time for a correction by the time of ix 42.0. This was realy a pain! - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Sun Nov 19 23:30:23 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89178-4> convert rfc822-to-8bit; Sun, 19 Nov 1995 23:27:21 +0200 Received: from getnet.com (actually host gn2.getnet.com user root@gn2.getnet.com) by funet.fi with SMTP (PP); Sun, 19 Nov 1995 23:27:05 +0200 Received: from AmigaCAB (cbell@gn2.getnet.com [204.157.9.29]) by getnet.com (8.7.1/8.7.1) with SMTP id OAA25566 for ; Sun, 19 Nov 1995 14:26:42 -0700 (MST) Received: by AmigaCAB.getnet.com (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sun, 19 Nov 95 14:29:57 MST-7 From: cbell@AmigaCAB.getnet.com (Clinton Bell) Message-Id: <21a30060.u7t150e.ae481-cbell@AmigaCAB.getnet.com> Subject: float problem Reply-To: cbell@getnet.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8BIT To: amiga-gcc-port@nic.funet.fi Date: Sun, 19 Nov 95 14:29:57 MST-7 Organization: CAB Programming > On Sun, 12 Nov 1995, Clinton Bell wrote: > When I compile and run the program below using GNU GCC version 2.7.0 > directly off Fred Fish's Freash Fish 10 CDROM. > > Using the following command line: > > g++ -v -o flaot float.cc -lm > > The printf lines give the expected output but the > cout lines produce garbage. > I want to thank Kamil Iskra, Kyrimis Kriton and Fred Fish for their help with my cout float problem. When I compiled my program using the -noixemul switch I was able to get the expected output. I then copied the 030fpu version of ixemul.library into my Sys:LIBS and recompiled and received the correct results with the cout statements. This raises another question. Why doesn't the default ixemul.library produce the correct results? Is this a bug in ixemul.library? Thanks guys Clinton Bell -- CAB From amiga-gcc-port-owner@nic.funet.fi Mon Nov 20 00:09:22 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89133-3>; Mon, 20 Nov 1995 00:08:38 +0200 Received: from amigalib.com (fishpond.amigalib.com [165.247.33.2]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with SMTP id WAA10191 for ; Sun, 19 Nov 1995 22:08:16 GMT Received: by amigalib.com (Smail3.1.28.1 #64) id m0tHHw8-0004nZC; Sun, 19 Nov 95 15:10 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: float problem To: cbell@getnet.com Date: Sun, 19 Nov 1995 15:10:07 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <21a30060.u7t150e.ae481-cbell@AmigaCAB.getnet.com> from "Clinton Bell" at Nov 19, 95 02:29:57 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 452 > I then copied the 030fpu version of ixemul.library into my > Sys:LIBS and recompiled and received the correct results with > the cout statements. > This raises another question. Why doesn't the default ixemul.library > produce the correct results? Is this a bug in ixemul.library? Yes, there is a bug of some kind. I've seen problems before where the non-FPU and FPU versions of ixemul.library cause programs to produce different results. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Nov 20 01:57:14 1995 Received: from europe.std.com ([192.74.137.10]) by nic.funet.fi with SMTP id <89153-1>; Mon, 20 Nov 1995 01:56:15 +0200 Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id SAA27343; Sun, 19 Nov 1995 18:56:05 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA17780; Sun, 19 Nov 1995 18:56:04 -0500 Date: Sun, 19 Nov 1995 18:56:04 +0001 (EST) From: "Thomas E. Janzen" Subject: linkage to stack code To: amiga-gcc-port@lists.funet.fi Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Amiga, under AmigaDOS 3.1, using gcc 2.7.0. When compiling c++ and linking, I get gnu/lib/crt0.o: Undefined symbol ___SaveSP referenced from text segment gnu/lib/crt0.o: Undefined symbol ___init_stk referenced from text segment Note that the names have 3 underscores, but in libc.a, those names have only two underscores. What should I do? Thanks Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio If you want it done, plan it; if you want it done right, spec it. From amiga-gcc-port-owner@nic.funet.fi Mon Nov 20 08:41:28 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90507-1>; Mon, 20 Nov 1995 08:39:54 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HXUX2U81QO00B2FW@NET2.WAU.NL>; Mon, 20 Nov 1995 07:43:41 +0000 (GMT) Received: by vines2.wau.nl; Mon, 20 Nov 95 7:39:39 +0100 Date: Mon, 20 Nov 1995 07:36:26 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: re: linkage to stack code To: tej@world.std.com Cc: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Tom Janzen wrote: >On Amiga, under AmigaDOS 3.1, using gcc 2.7.0. >When compiling c++ and linking, I get >gnu/lib/crt0.o: Undefined symbol ___SaveSP referenced from text segment >gnu/lib/crt0.o: Undefined symbol ___init_stk referenced from text segment >What should I do? This is not much help but I have had the same a couple of times and either recompiling the project from scratch or better re-install crt0.o and related link libraries (libxxxx.a stuff) and try again. Something is utterly confused and it happens from one moment to the other. Real strange and if someone can explain 'in detail' what happens, please do. Joop From amiga-gcc-port-owner@nic.funet.fi Mon Nov 20 16:09:03 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90292-2>; Mon, 20 Nov 1995 16:04:05 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id PAA00338; Mon, 20 Nov 1995 15:06:09 +0100 Date: Mon, 20 Nov 1995 15:06:08 +0100 (MET) From: Kamil Iskra Subject: New FD2Inline To: Amiga GCC List cc: phb@colombo.telesys-innov.fr Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yep, I know this subject is becoming boring because it can be seen too often. Sorry, I just can't help improving fd2inline :-), and since 2.7.1 should be out soon, I want inlines to be tested as well as possible. As always, I have put it on my WWW homepage and uploaded it to colombo. Modifications are minor: #including resulted in a warning message if "gfx/macros.h" was #included before. Seems there is a conflict in CBM/AT includes - there is a macro GetOutlinePen() and a function named exactly the same. GCC was silent with old inlines, but since new ones are preprocessor macros, it complains about redefinition of this macro. I fixed it by always #undefing GetOutlinePen in "proto/graphics.h" before including "inline/graphics.h". MUI support. This required adding two function names to exception array. However, if you want to use "MUI macros", you should remember turning NO_INLINE_STDARG on (see FAQ about BGUI). I also created MUI linker library - "libmui.a", both in normal and base relative version, and included them in the archive (maybe I'll add third output format to fd2inline - suitable for creating library stubs - and write a clever makefile and awk script to make creating library stubs fast and simple. Currently it's rather lengthy process :-). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Nov 20 22:11:23 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <90451-3> convert rfc822-to-8bit; Mon, 20 Nov 1995 22:07:53 +0200 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 20 Nov 1995 21:07:41 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Changed URL for GCC README file Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, As the system managers have ordered me to stop the WWW server, I have been running :-(, the GCC REAME file cannot be reached at the place it used to be. Use the URL http://www.gbar.dtu.dk/~gc948374/README-2.7.1 instead. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Nov 21 00:32:50 1995 Received: from pythia.forthnet.gr ([139.91.1.1]) by nic.funet.fi with SMTP id <90565-4>; Tue, 21 Nov 1995 00:22:03 +0200 Received: from acrogate.UUCP by pythia.forthnet.gr via FORTHnet with UUCP; id AAA19905 (8.6.12/FORTHNET-2.0-MHS-7.0); Tue, 21 Nov 1995 00:19:39 +0200 Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0tHf8m-000AyWC; Mon, 20 Nov 95 22:56 GMT Message-Id: Date: Mon, 20 Nov 95 22:56 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Subject: NetBSD withe GCC 2.7.0 Hello! I have one question that is not totally related with GCC 2.7.0. I have downloaded two files from the GCC 2.7 distribution (I intend to download more, when I'm able to). I was wondering if GCC 2.7 could be used with NetBSD for the Amiga, in order to port some programs from the university's system to my Amiga 3000. Also, can onle please tell me where I can find NetBSD for the Amiga. I've sent a message to majordomo@NetBDS.ORG, but that was a mailing list and I don't know much about it. Thank you very much in advance. Regards, Manolis S Pappas. From amiga-gcc-port-owner@nic.funet.fi Tue Nov 21 01:23:39 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <90464-3>; Tue, 21 Nov 1995 01:21:07 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id SAA11142; Mon, 20 Nov 1995 18:20:58 -0500 (from cz253) Message-Id: <199511202320.SAA11142@kanga.INS.CWRU.Edu> Date: Mon, 20 Nov 1995 18:20:58 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: ixtrace... Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Has anyone been having problems with ixtrace not tracing properly? If so send me details of the problem(s) via email, so I can fix them. Thanks. .....Dave From amiga-gcc-port-owner@nic.funet.fi Tue Nov 21 02:42:20 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90460-1>; Tue, 21 Nov 1995 02:39:58 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 21 Nov 95 01:39 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 21 Nov 95 01:36 MET Message-Id: Subject: problems with SP libraries To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 21 Nov 1995 01:36:02 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 591 while compiling and testing some more C= examples if found that the single precission stuff and ffp stuff seem to be not realy supported (means dont work) a quick look in the *.s files showed that the main problem seems to be the float -> double expansion what is usefull under normal circumstances but deadly of you use exspecialy float defined functions. is there any way around ? or should it be noted that SP and FFP is not supported by GNU ? or did i made something wrong ? walter -- ----- "Logic, my dear Zoe, merely enables one to be wrong with authority." ----- From amiga-gcc-port-owner@nic.funet.fi Tue Nov 21 13:14:25 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <89727-3>; Tue, 21 Nov 1995 12:55:28 +0200 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id LAA19799 (8.6.10/2.4); Tue, 21 Nov 1995 11:56:08 +0100 Date: Tue, 21 Nov 1995 11:56:08 +0100 From: Olaf Seibert Message-Id: <199511211056.LAA19799@septimius.mbfys.kun.nl> To: amiga-gcc-port@nic.funet.fi, mpap@acrogate.ath.forthnet.gr Subject: Re: NetBSD withe GCC 2.7.0 mpap@acrogate.ath.forthnet.gr (Manolis Pappas) wrote: > I have downloaded two files from the GCC 2.7 distribution (I intend to > download more, when I'm able to). I was wondering if GCC 2.7 could be used > with NetBSD for the Amiga, in order to port some programs from the university's > system to my Amiga 3000. Well, you can't run one version under the other operating system. But I did once compile a NetBSD kernel file with the AmigaOS gcc. I had preprocessed it already under NetBSD but for some unknown reason its main compiler pass hung on that one file. Compiling it under AmigaOS worked fine, even though it uses a different fram pointer. So in principle it can work, but you have problems like using the right include files, linkers and libraries. > Also, can onle please tell me where I can find NetBSD for the Amiga. I've sent > a message to majordomo@NetBDS.ORG, but that was a mailing list and I don't know > much about it. Try ftp.netbsd.org. It also has a list of mirrors, I suppose. > Manolis S Pappas. -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Tue Nov 21 20:17:14 1995 Received: from pythia.forthnet.gr ([139.91.1.1]) by nic.funet.fi with SMTP id <88923-3>; Tue, 21 Nov 1995 20:13:54 +0200 Received: from acrogate.UUCP by pythia.forthnet.gr via FORTHnet with UUCP; id UAA13673 (8.6.12/FORTHNET-2.0-MHS-7.0); Tue, 21 Nov 1995 20:11:16 +0200 Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0tHx3x-000B2oC; Tue, 21 Nov 95 18:04 GMT Message-Id: Date: Tue, 21 Nov 95 18:04 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Subject: Re^2: GCC 2.7.0 with NetBSD Hi Lars, > > GCC for NetBSD creates NetBSD binaries. You'd have to set up a cross > compiler for AmigaOS. Philippe has done it for SPARC, it shouldn't > be a big problem, so. INSTALL from the gcc distribution describes the > necessary steps to set up a cross compiler. A cross compiler? You mean a compiler that works both under AmigaOS and NetBSD? > My netbsd URL's are > http://www.netbsd.org/ > http://www.uni-regensburg.de/pub/NetBSD-Amiga > http://www4.informatik.uni-erlangen.de/~roessler/NetBSD-Amiga/index.html Thanks, but unfortunately I don't have a slip/ppp or web access! > Not sure, but I believe you may also find NetBSD on Philippe's site > and funet. I'll try this one! Thank you very much! Regards, MSP From amiga-gcc-port-owner@nic.funet.fi Wed Nov 22 01:12:19 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90451-1>; Wed, 22 Nov 1995 01:10:06 +0200 Received: from hauki.clinet.fi (actually user root@hauki.clinet.fi) by funet.fi with SMTP (PP); Tue, 21 Nov 1995 17:21:04 +0200 Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.6.12/8.6.4) with ESMTP id RAA26696; Tue, 21 Nov 1995 17:19:42 +0200 Received: (will@localhost) by katiska.clinet.fi (8.6.12/8.6.4) id RAA16373; Tue, 21 Nov 1995 17:19:46 +0200 Date: Tue, 21 Nov 1995 17:19:46 +0200 Message-Id: <199511211519.RAA16373@katiska.clinet.fi> From: Ville-Pertti Keinonen To: mpap@acrogate.ath.forthnet.gr CC: amiga-gcc-port@nic.funet.fi In-reply-to: (mpap@acrogate.ath.forthnet.gr) Subject: Re: NetBSD withe GCC 2.7.0 I have downloaded two files from the GCC 2.7 distribution (I intend to download more, when I'm able to). I was wondering if GCC 2.7 could be used with NetBSD for the Amiga, in order to port some programs from the university's system to my Amiga 3000. Trying to cross-compile using the Amiga-port of GCC doesn't make much sense, and the Amiga-port certainly isn't going to run under NetBSD. A much better idea would be for you to obtain the full distribution for NetBSD (it includes an older version of GCC). If you want to use a newer version of GCC (the current version is probably still at 2.7.1), just download the FSF sources and build it for NetBSD using the older version (it shouldn't require any modifications, at least the file gcc-2.7.1/config/m68k/netbsd.h exists). The NetBSD version of GCC should also run more reliably than the Amiga-port. From amiga-gcc-port-owner@nic.funet.fi Wed Nov 22 01:12:51 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90464-4>; Wed, 22 Nov 1995 01:10:39 +0200 Received: from pythia.forthnet.gr by funet.fi with SMTP (PP); Tue, 21 Nov 1995 20:15:49 +0200 Received: from acrogate.UUCP by pythia.forthnet.gr via FORTHnet with UUCP; id UAA13677 (8.6.12/FORTHNET-2.0-MHS-7.0); Tue, 21 Nov 1995 20:11:23 +0200 Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0tHx4W-000B2oC; Tue, 21 Nov 95 18:05 GMT Message-Id: Date: Tue, 21 Nov 95 18:05 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Subject: Re^2: GCC 2.7.0 with netBSD Hi Olaf, > Well, you can't run one version under the other operating system. > But I did once compile a NetBSD kernel file with the AmigaOS gcc. > I had preprocessed it aòeady under NetBSD but for some unknown reason > its main compiler pass hung on that one file. Compiling it under > AmigaOS worked fine, even though it uses a different fram pointer. Well, than you! I'll keep that in mind when working with NetBSD. > Try ftp.netbsd.org. It also has a list of mirrors, I suppose. Again, thank you very much! Regards, MSP From amiga-gcc-port-owner@nic.funet.fi Wed Nov 22 12:25:48 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89949-2>; Wed, 22 Nov 1995 12:21:10 +0200 Received: from info.forthnet.gr (info.forthnet.gr [139.91.1.17]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id KAA04493 for ; Wed, 22 Nov 1995 10:21:07 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: from acrogate.UUCP by info.forthnet.gr via FORTHnet with UUCP; id MAA04822 (8.6.12/FORTHNET-2.0); Wed, 22 Nov 1995 12:18:11 +0200 (EET DST) Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0tICqY-000AxOC; Wed, 22 Nov 95 10:56 GMT Message-Id: Date: Wed, 22 Nov 95 10:56 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Subject: GCC & NetBSD Hi Lars, > > A cross compiler? You mean a compiler that works both under AmigaOS > > and NetBSD? > > A cross compiler runs on one system FOO and creates executables for another > system, BAR. Executables for BAR do not run under FOO, and vice versa, and > neither does the compiler. Aha! Got it! Thanks! > Well, then make the 2nd URL ftp://ftp.uni-regensburg.de/pub/NetBSD-Amiga. > I believe this is the major european NetBSD-Amiga site. Again thank you. I'll try to ftp this tonight! Regards, MSP From amiga-gcc-port-owner@nic.funet.fi Wed Nov 22 12:25:50 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90847-1>; Wed, 22 Nov 1995 12:21:36 +0200 Received: from info.forthnet.gr (info.forthnet.gr [139.91.1.17]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id KAA04506 for ; Wed, 22 Nov 1995 10:21:23 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: from acrogate.UUCP by info.forthnet.gr via FORTHnet with UUCP; id MAA04818 (8.6.12/FORTHNET-2.0); Wed, 22 Nov 1995 12:18:09 +0200 (EET DST) Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0tICq8-000AxOC; Wed, 22 Nov 95 10:55 GMT Message-Id: Date: Wed, 22 Nov 95 10:55 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Subject: GCC & NetBSD Hi Ville-Pertti, > Trying to cross-compile using the Amiga-port of GCC doesn't make much > sense, and the Amiga-port certainly isn't going to run under > NetBSD. A much better idea would be for you to obtain the full > distribution for NetBSD (it includes an older version of GCC). If you > want to use a newer version of GCC (the current version is probably > still at 2.7.1), just download the FSF sources and build it for NetBSD > using the older version (it shouldn't require any modifications, at > least the file gcc-2.7.1/config/m68k/netbsd.h exists). The NetBSD > version of GCC should also run more reliably than the Amiga-port. You mean that the NetBSD gcc version will also run better than the Amiga-gcc port in terms of pure Amiga programming, too? Again, thank you very much for your respond. Regards, MSP From amiga-gcc-port-owner@nic.funet.fi Wed Nov 22 14:54:12 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89023-3>; Wed, 22 Nov 1995 14:51:32 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 22 Nov 95 13:46 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 22 Nov 95 13:36 MET Message-Id: Subject: Re: problems with SP libraries To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 22 Nov 1995 13:36:00 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 993 > > FFP is not supported and hopefully will never be. Float and double are enough > floating point formats (OK, long double would be nice). I've worked with > Macs and they offer you a whole platoon of different floating point > formats, each incompatible with one another. I don't want a similar > situation on the Amiga. Let's keep to the standard IEEE formats. oh thats not a problem for me (in fact i never use these functions because i have a fpu), but its a part of the OS and it should be noted that we dont support this funktions (rask ?). > > Could you mail me a simple example program that shows the problem with > floats? It should really work, so I'm curious to see which construct causes > problems. > i accidently killed the dir :( (realy) but get the rkrm_lib examples, btw can you post them math dir to me ? walter -- ----- "What are we gonna do now?" "Keep it confused, feed it with useless information--I wonder if I have a television set handy." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Nov 22 15:17:26 1995 Received: from srv3.gbar.dtu.dk ([130.225.87.163]) by nic.funet.fi with ESMTP id <89039-1> convert rfc822-to-8bit; Wed, 22 Nov 1995 15:14:50 +0200 Received: by srv3.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 22 Nov 1995 14:14:45 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: New README for GCC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I have done some work on the README for GCC (the inline header stuff is still a mess, though). It is available on the WWW as http://www.gbar.dtu.dk/~gc948374/README-2.7.1 If you can't get it that way, I'll happily email it to you. Just ask me. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Nov 22 18:23:19 1995 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with SMTP id <89240-3>; Wed, 22 Nov 1995 18:16:18 +0200 Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.6.12/8.6.4) with ESMTP id SAA26137; Wed, 22 Nov 1995 18:16:14 +0200 Received: (will@localhost) by katiska.clinet.fi (8.6.12/8.6.4) id SAA16178; Wed, 22 Nov 1995 18:16:17 +0200 Date: Wed, 22 Nov 1995 18:16:17 +0200 Message-Id: <199511221616.SAA16178@katiska.clinet.fi> From: Ville-Pertti Keinonen To: mpap@acrogate.ath.forthnet.gr CC: amiga-gcc-port@nic.funet.fi In-reply-to: (mpap@acrogate.ath.forthnet.gr) Subject: Re: GCC & NetBSD You mean that the NetBSD gcc version will also run better than the Amiga-gcc port in terms of pure Amiga programming, too? Probably, although it might not be worth the trouble of installing NetBSD, compiling a cross-compiler etc., unless you would be using it for something anyhow (you'll need a lot of hd-space). Some of the advantages would be the memory environment (especially the stack), the filesystem and if you do other stuff simultaneously, the multitasking. What the compiler produces should end up identical and there's probably not much difference in speed. From amiga-gcc-port-owner@nic.funet.fi Wed Nov 22 20:19:54 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <89112-1> convert rfc822-to-8bit; Wed, 22 Nov 1995 20:18:55 +0200 Received: by bohr.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 22 Nov 1995 19:18:44 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Questions about README + various + misc Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I'm having another look at the GCC README, and there is a few things I'd like to know: 1) Will the G++ archive be gcc271-cp.lha or gcc271-c++.lha? 2) Which directory in GNU: will be used? mc6800-at-amigados? m68k-at-amigaos? 3) Is there a README-LIST file? I can't remember ever having seen one in any of the GCC archives. 4) Is Raphael Luebber going to make a new as/ld/size/nm/ranlib using BFD? 5) Who is making the installation programme? 6) Is ixemul using "*" or "CONSOLE:" for stderr, if no pr_CES? Various + misc questions: Is there any hope of seing PC-relative code for 68000? Is there any hope of seing GCC pass arguments in registers? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Nov 22 20:37:09 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90722-1>; Wed, 22 Nov 1995 20:36:12 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tIK4L-0004nZC; Wed, 22 Nov 95 11:38 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Questions about README + various + misc To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Wed, 22 Nov 1995 11:38:53 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Nov 22, 95 07:18:44 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 683 > 2) Which directory in GNU: will be used? mc6800-at-amigados? m68k-at-amigao= My preference for the compiler that is intended to run on all m68k based systems running the Amiga operating system is "m68k-unknown-amigaos". The corresponding configuration triplet to match would be "m68k-*-amigaos". For versions that require a 68040 host for example, it would be "m68040-unknown-amigaos" and the configuration triplet would be "m68040-*-amigaos". > 4) Is Raphael Luebber going to make a new as/ld/size/nm/ranlib using BFD? Is this not already the case? I switched to a completely BFD based toolset (except for the linker) as of many months ago, possibly as early as FF9. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Nov 22 22:26:49 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89072-3>; Wed, 22 Nov 1995 22:25:43 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tIM6r-000RHSC; Wed, 22 Nov 95 21:49 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0bun@wyst.hobby.nl>; Wed, 22 Nov 95 21:15:43 CET Message-Id: <9511222015.0bun@wyst.hobby.nl> Date: Wed, 22 Nov 1995 21:15:39 +0000 (CET) In-Reply-To: from "Rask Lambertsen" at Nov 22, 95 07:18:44 pm Content-Type: text Content-Length: 842 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Questions about README + various + misc Hi, > 4) Is Raphael Luebber going to make a new as/ld/size/nm/ranlib using BFD? I thought only ld needed fixing? > 6) Is ixemul using "*" or "CONSOLE:" for stderr, if no pr_CES? After reports of problems with "CONSOLE:" I changed back to "*" for 42.0. Apparently "*" and "CONSOLE:" are not the same after all. > Is there any hope of seing PC-relative code for 68000? I've mailed patches to Fred and Philippe that implemented the -small-code option. > Is there any hope of seing GCC pass arguments in registers? I doubt it :-) Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Nov 22 22:33:16 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89875-1> convert rfc822-to-8bit; Wed, 22 Nov 1995 22:32:52 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 22 Nov 1995 21:32:10 +0100 (MET) From: Rask Lambertsen To: Hans Verkuil Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Questions about README + various + misc In-Reply-To: <9511222015.0bun@wyst.hobby.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 22 Nov 1995, Hans Verkuil wrote: > > Is there any hope of seing GCC pass arguments in registers? > > I doubt it :-) ^^^ Are you actually happy with that? I think this is one of the areas where GCC looses out badly to (almost) all other Amiga C compilers. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Nov 23 16:19:00 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <88277-2>; Thu, 23 Nov 1995 14:29:38 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA03210; Thu, 23 Nov 1995 13:30:56 +0100 Date: Thu, 23 Nov 1995 13:30:55 +0100 (MET) From: Kamil Iskra Subject: Re: Questions about README + various + misc To: Rask Lambertsen cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 22 Nov 1995, Rask Lambertsen wrote: > 3) Is there a README-LIST file? I can't remember ever having seen one in > any of the GCC archives. It was distributed with 2.6.1 and 2.6.3, if I remember correctly. I think it was basically the same file that is posted once a month to this mailing list. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Nov 23 18:17:17 1995 Received: from europe.std.com ([192.74.137.10]) by nic.funet.fi with SMTP id <90365-1>; Thu, 23 Nov 1995 18:16:01 +0200 Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id LAA14478; Thu, 23 Nov 1995 11:15:53 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA15616; Thu, 23 Nov 1995 11:12:22 -0500 Date: Thu, 23 Nov 1995 11:12:22 +0001 (EST) From: "Thomas E. Janzen" Subject: Repeat math output << c++ To: Amiga GCC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi again. I am now on the mail server alright, so I'd like to ask again if it's alright. I can't output doubles with the << operator. The following make file and program print out 0.0N instead of 0.3. Please let me know if you can help me. I use an Amiga 3000 with AmigaDOS 3.1, gnu gcc 2.7.0. At first I installed 2.7.0 over 2.6.3, but then I re-installed it in another partition by itself (2.7.0). I re-installed the libraries/includes with the exact lha x command in the directions (at first I had used lha -x -a -m x ... to avoid answering Overwrite? queries). I am not trying to make any deadlines or anything, just upgrading my little fuzzy logic library. The new compiler has already helped me clean up some types (mostly making indices size_t). hello : hello.o g++ -v -Wall -m68030 -m68881 -Wall -o hello -lm hello.o hello.o : hello.c g++ -v -Wall -c -m68030 -m68881 -Wall -x c++ -o hello.o hello.c #include #include #include int main(int argc, char *argv[]) { auto double num = 0.3; cout << num << endl; exit(EXIT_SUCCESS); } Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio If you want it done, plan it; if you want it done right, spec it. From amiga-gcc-port-owner@nic.funet.fi Thu Nov 23 18:58:29 1995 Received: from trappist.elis.rug.ac.be ([157.193.67.1]) by nic.funet.fi with SMTP id <90599-4>; Thu, 23 Nov 1995 18:48:10 +0200 Received: from ibmpar.elis.rug.ac.be by trappist.elis.rug.ac.be with SMTP id AA22749 (5.65c/IDA-1.4.4 for ); Thu, 23 Nov 1995 17:48:29 +0100 Received: by ibmpar.elis.rug.ac.be (AIX 3.2/UCB 5.64/4.03) id AA16068; Thu, 23 Nov 1995 17:52:37 GMT From: bvassche@ibmpar.elis.rug.ac.be (Bart Van Assche) Message-Id: <9511231752.AA16068@ibmpar.elis.rug.ac.be> Subject: Repeat math output << c++ (fwd) To: amiga-gcc-port@nic.funet.fi Date: Thu, 23 Nov 1995 17:52:36 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 499 In a previous message Thomas E. Janzen wrote: > Hi again. I am now on the mail server alright, so I'd like to ask again > if it's alright. I can't output doubles with the << operator. > > hello : hello.o > g++ -v -Wall -m68030 -m68881 -Wall -o hello -lm hello.o Try g++ -v -Wall -m68030 -m68881 -Wall -o hello hello.o -lm instead. Probably this will solve the problem. (i.e., swap -lm and hello.o) Isn't this in any FAQ ? -- __ /_/ /_/art Van Assche E-mail: Bart.VanAssche@elis.rug.ac.be From amiga-gcc-port-owner@nic.funet.fi Thu Nov 23 19:22:09 1995 Received: from eeyore.INS.CWRU.Edu ([129.22.8.17]) by nic.funet.fi with ESMTP id <90341-1>; Thu, 23 Nov 1995 19:17:28 +0200 Received: (cz253@localhost) by eeyore.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id MAA29275; Thu, 23 Nov 1995 12:16:25 -0500 (from cz253) Message-Id: <199511231716.MAA29275@eeyore.INS.CWRU.Edu> Date: Thu, 23 Nov 1995 12:16:25 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: bvassche@ibmpar.elis.rug.ac.be Subject: Re: Repeat math output << c++ (fwd) Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from bvassche@ibmpar.elis.rug.ac.be of Thu, 23 Nov > >In a previous message Thomas E. Janzen wrote: > >> Hi again. I am now on the mail server alright, so I'd like to ask again >> if it's alright. I can't output doubles with the << operator. >> >> hello : hello.o >> g++ -v -Wall -m68030 -m68881 -Wall -o hello -lm hello.o > >Try g++ -v -Wall -m68030 -m68881 -Wall -o hello hello.o -lm instead. Probably >this will solve the problem. (i.e., swap -lm and hello.o) Isn't this in any >FAQ ? It should do the trick for him. I compiled his sample code on my 68000 based machine with the following gcc invocation: g++ -v -Wall -o hello hello.c -lm Output of program: 0.3 Like it should be. What bothers me is (partial verbose listing): ld -o hello /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 -L/local/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 -L/gnu/lib -L/local/lib -L/local/lib /t/cc1821361.o -lg++ -lstdc++ -lm -lgcc -lc -lamiga -lc -lgcc ^^^^^^^^^ Why these libs repeat?------------------------------------------/ Tom: Next time post the output from the '-v' option of 'g++'. It will help in tracking down what is going wrong. .....Dave ps. Happy Thanksgiving everyone! :-) From amiga-gcc-port-owner@nic.funet.fi Thu Nov 23 19:51:02 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90565-4>; Thu, 23 Nov 1995 19:50:19 +0200 Received: from amigalib.com (fishpond.amigalib.com [165.247.33.2]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with SMTP id RAA24753 for ; Thu, 23 Nov 1995 17:50:04 GMT Received: by amigalib.com (Smail3.1.28.1 #64) id m0tIfpI-0004nZC; Thu, 23 Nov 95 10:52 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Repeat math output << c++ (fwd) To: cz253@cleveland.Freenet.Edu Date: Thu, 23 Nov 1995 10:52:48 -0700 (MST) Cc: bvassche@ibmpar.elis.rug.ac.be, amiga-gcc-port@nic.funet.fi In-Reply-To: <199511231716.MAA29275@eeyore.INS.CWRU.Edu> from "David Zaroski" at Nov 23, 95 12:16:25 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1189 > What bothers me is (partial verbose listing): > > ld -o hello /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 > -L/local/lib/gcc-lib/mc68000-cbm-amigados/2.7.0 -L/gnu/lib -L/local/lib > -L/local/lib /t/cc1821361.o -lg++ -lstdc++ -lm -lgcc -lc -lamiga -lc -lgcc > ^^^^^^^^^ > Why these libs repeat?------------------------------------------/ > The answer is partially here, from gcc/config/amigados.h: /* Automatically search libamiga.a for AmigaDOS specific functions. Note that we first search the standard C library to resolve as much as possible from there, since it has names that are duplicated in libamiga.a which we *don't* want from there. Then search the standard C library again to resolve any references that libamiga.a might have generated. This may only be a temporary solution since it might be better to simply remove the things from libamiga.a that should be pulled in from libc.a instead, which would eliminate the first reference to libc.a. */ #define LIB_SPEC "%{!noixemul:%{!p:%{!pg:-lc -lamiga -lc}}%{p:-lc_p}%{pg:-lc_p}}%{noixemul:-lnixmain -lnix -lamiga}" From amiga-gcc-port-owner@nic.funet.fi Thu Nov 23 20:39:53 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90857-1>; Thu, 23 Nov 1995 20:32:12 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id UAA12711 at Thu, 23 Nov 1995 20:31:13 +0200 Received: by softlab.ece.ntua.gr with UUCP id UAA06364 at Thu, 23 Nov 1995 20:31:19 +0200 (EET) Received: by kriton.UUCP (V1.17-beta/Amiga) id <0967@kriton.UUCP>; Thu, 23 Nov 95 19:51:12 EET Date: Thu, 23 Nov 95 19:51:12 EET Message-Id: <9511231751.0967@kriton.UUCP> In-Reply-To: <9511231752.AA16068@ibmpar.elis.rug.ac.be> (from theseas!ibmpar.elis.rug.ac.be!bvassche (Bart Van Assche)) (at Thu, 23 Nov 1995 17:52:36 +0000 (GMT)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!ibmpar.elis.rug.ac.be!bvassche@achilles.noc.ntua.gr Cc: tej@world.std.com, theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: Repeat math output << c++ (fwd) Hi Bart (Bart Van Assche), in <9511231752.AA16068@ibmpar.elis.rug.ac.be> on Nov 23 you wrote: > Try g++ -v -Wall -m68030 -m68881 -Wall -o hello hello.o -lm instead. Probably > this will solve the problem. (i.e., swap -lm and hello.o) Isn't this in any > FAQ ? I don't think this would help. Although libraries (e.g., -lm) should be linked after user code (i.e., .o files), in this case the math library does not iappear to be used: on my machine the test program prints 0.3 both with and without -lm, and both with and without -noixemul. Tom: Try recompiling with the stack settings I used: stack 20000 setenv GCCSTACK 250000 The problem might lie in that g++ got confused by a stack overflow. Also check whether after re-installing gcc, you have any left-over assigns and setenvs pointing to your old gcc directory. The c++ libraries that came with the aminet version of 2.6.3 had some problems. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "...the only time in history the Vulcan peace sign had been used to scratch an itch." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Nov 23 22:43:12 1995 Received: from europe.std.com ([192.74.137.10]) by nic.funet.fi with SMTP id <90341-4>; Thu, 23 Nov 1995 22:41:17 +0200 Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id PAA01796; Thu, 23 Nov 1995 15:41:14 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA07666; Thu, 23 Nov 1995 15:39:00 -0500 Date: Thu, 23 Nov 1995 15:39:00 +0001 (EST) From: "Thomas E. Janzen" Subject: RE: Repeat math output << c++ To: Amiga GCC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks for your help. No dice. Putting the -lm at the end of the line doesn't work (that's how I started & have always used it). Doing a compile/link in one line doesn't help (had already tried it but repeated it exactly as in the suggestion). Making sure the stack is 250000 doesn't help (It had been 200000). Thanks very much for trying to help on Thanksgiving! Here is the verbose output from my makefile but with the -lm at the end: g++ -v -Wall -c -m68030 -m68881 -Wall -x c++ -o hello.o hello.c gcc -v -Wall -c -m68030 -m68881 -Wall -x c++ -o hello.o -xc++ hello.c -xnone Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -Wall -Wall -D__HAVE_68881__ -Dmc68030 hello.c /t/cc613672.ii GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/lib/g++-include /gnu/local/include /gnu/mc68020-cbm-amigados/include /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/cc1plus /t/cc613672.ii -mfixedstack -mfixedstack -quiet -dumpbase hello.cc -m68030 -m68881 -Wall -Wall -version -o /t/cc613672.s GNU C++ version 2.7.0 (68k, MIT syntax) compiled by GNU C version 2.7.0. hello.c: In function `int main(int, char **)': hello.c:6: warning: unused parameter `int argc' hello.c:6: warning: unused parameter `char ** argv' as -mc68030 -o hello.o /t/cc613672.s g++ -v -Wall -m68030 -m68881 -Wall -o hello hello.o -lm gcc -v -Wall -m68030 -m68881 -Wall -o hello hello.o -lg++ -lstdc++ -lm Reading specs from /gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0/specs gcc version 2.7.0 ld -fl libm020 -fl libm881 -o hello /gnu/lib/crt0.o -L/gnu/lib/gcc-lib/mc68020-cbm-amigados/2.7.0 -L/local/lib/gcc-lib/mc68020-cbm-amigados/2.7.0 -L/gnu/lib -L/local/lib -L/local/lib hello.o -lg++ -lstdc++ -lm -lgcc -lc -lamiga -lc -lgcc Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio If you want it done, plan it; if you want it done right, spec it. From amiga-gcc-port-owner@nic.funet.fi Thu Nov 23 23:53:44 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90069-3>; Thu, 23 Nov 1995 23:50:46 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id VAA29863 for ; Thu, 23 Nov 1995 21:48:47 GMT From: Lars Hecking Message-Id: <199511232149.VAA02458@mostar.nmrc.ucc.ie> Subject: GNU tar 1.11.8 To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Thu, 23 Nov 1995 21:49:42 +0000 (GMT) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 490 If anybody wants to beta-test GNU tar 1.11.8, sent me email, including machine/cpu/fpu info. From the README: about 40% of the 1.11.2 problem backlog is solved. The amiga-specific problem with the '-z' option is still there, though. Remote tape handling is "consistently disabled" ;) (stubbed out getservbyname and rexec). I have not been able to compile tar with localization, neither with 2.7.0 nor 2.7.1, neither on Amiga nor SPARC. Just in case someone expected this ;) -l From amiga-gcc-port-owner@nic.funet.fi Fri Nov 24 00:23:18 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90069-3> convert rfc822-to-8bit; Fri, 24 Nov 1995 00:21:44 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 23 Nov 1995 23:21:42 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: New GCC README + release date question Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I've improved (I hope) the section on inline headers and made some other minor changes. The new README is available as http://www.gbar.dtu.dk/~gc948374/README-2.7.1 and as always, mail me if you can't get it that way. In addition, a diff -u file is available as http://www.gbar.dtu.dk/~gc948374/README-2.7.1.diff and I'll email that one too if you want it. When will 2.7.1 be released? I don't need an exact date, but I'd like to finish the README in time. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Nov 24 10:24:48 1995 Received: from hpcl.cti.gr ([150.140.91.21]) by nic.funet.fi with SMTP id <90537-1>; Fri, 24 Nov 1995 10:17:09 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA23167 (5.67a8/IDA-1.5 for ); Fri, 24 Nov 1995 10:16:06 +0200 From: Kriton Kyrimis Message-Id: <199511240816.AA23167@hpcl.cti.gr> Subject: Re: GNU tar 1.11.8 To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Fri, 24 Nov 1995 10:16:03 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi (gcc) In-Reply-To: <199511232149.VAA02458@mostar.nmrc.ucc.ie> from "Lars Hecking" at Nov 23, 95 09:49:42 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 932 > The amiga-specific problem with the '-z' option is still there, though. > Remote tape handling is "consistently disabled" ;) (stubbed out > getservbyname and rexec). I have not been able to compile tar with > localization, neither with 2.7.0 nor 2.7.1, neither on Amiga nor SPARC. > Just in case someone expected this ;) I think that tar 1.11.8 expects gcc 2.7+ to have some features which it does not actually there. There are two places in the source where it checks if the version of gcc is at least 2.7. By changing the check so that it fails (e.g., check for version 2.8) I was able to cvompile tar 1.11.8 both on the amiga and a SPARC machine running SunOS. (I threw the latter version away, reverting to 1.11.2, because it and/or rmt core dumps when backing up remote files.) -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Don't listen to me; I never do." ----- From amiga-gcc-port-owner@nic.funet.fi Fri Nov 24 10:56:59 1995 Received: from hpcl.cti.gr ([150.140.91.21]) by nic.funet.fi with SMTP id <90537-3>; Fri, 24 Nov 1995 10:54:11 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA23391 (5.67a8/IDA-1.5 for ); Fri, 24 Nov 1995 10:51:42 +0200 From: Kriton Kyrimis Message-Id: <199511240851.AA23391@hpcl.cti.gr> Subject: Re: Repeat math output << c++ To: tej@world.std.com (Thomas E. Janzen) Date: Fri, 24 Nov 1995 10:51:40 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi (gcc) In-Reply-To: from "Thomas E. Janzen" at Nov 23, 95 03:39:00 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 595 > Thanks for your help. No dice. Putting the -lm at the end of the line One thing you may have not tried is to replace the version of ixemul.library that came with gcc (68000/soft-float) with the 68030/68881 version. The soft-float version is known to have problems, at least on machines with an FPU. > Thanks very much for trying to help on Thanksgiving! Well, this is an international list, so not all of us celebrate this great American holiday. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Don't listen to me; I never do." ----- From amiga-gcc-port-owner@nic.funet.fi Fri Nov 24 11:23:26 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89284-2>; Fri, 24 Nov 1995 11:20:37 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA15408; Fri, 24 Nov 1995 10:22:06 +0100 Date: Fri, 24 Nov 1995 10:22:06 +0100 (MET) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: New GCC README + release date question To: Rask Lambertsen cc: phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Thu, 23 Nov 1995, Rask Lambertsen wrote: > I've improved (I hope) the section on inline headers and made some other > minor changes. Oh yes, it's much better now. Good work. In README-2.7.1 you wrote: > 1) First method: > > Use fd2inline by Kamil Iskra, which you can find on Aminet in dev/gcc. I thought that fd2inline would be distributed together with GCC. Philippe, was I right? I just wouldn't like to upload it on my own etc - besides, I think that fd2inline can be useful not only for me. I think that at least main executable (the one producing new inlines) should be included, the rest (executables producing old inlines and (if I have the time to create it) library stubs, as well as source code) could be distributed separately. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Nov 24 13:04:20 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90909-3>; Fri, 24 Nov 1995 13:00:40 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA06716; Fri, 24 Nov 1995 12:02:36 +0100 Date: Fri, 24 Nov 1995 12:02:36 +0100 (MET) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: New GCC README + release date question To: Rask Lambertsen cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Thu, 23 Nov 1995, Rask Lambertsen wrote: > I've improved (I hope) the section on inline headers and made some other > minor changes. I forgot about one more thing that should be changed. In README-2.7.1 you wrote: > 3) Use the local function feature of GCC. With this technique, the > header files contain preprocessor macros that generate a local function > whenever an OS function call is made. The local function is then called > instead of a stub library function. > > Advantages: Gives smaller and faster code (at least as good as with > method 2). Doesn't force the compiler to keep all the stub functions > memory, thus greatly reducing memory usage compared to method 2. This > makes it easier to use the -O2 and -O3 options :-). Library bases can > be local variables or even structure elements (using something like > #define DOSBase mystruct->libs->DOSBase > or whatever you choose). > > Disadvantages: There was supposed to be a list of them here, but I > can't find any :-) New inlines don't work with G++. It should be explained why there are two inline directories: "inline" and "inline++". / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Nov 24 13:06:22 1995 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <89314-2> convert rfc822-to-8bit; Fri, 24 Nov 1995 13:03:26 +0200 Received: by hald.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 24 Nov 1995 12:02:11 +0100 (MET) From: Rask Lambertsen To: Kamil Iskra Cc: amiga-gcc-port@nic.funet.fi Subject: Re: New GCC README + release date question In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Fri, 24 Nov 1995, Kamil Iskra wrote: > On Thu, 23 Nov 1995, Rask Lambertsen wrote: > In README-2.7.1 you wrote: > > > 3) Use the local function feature of GCC. With this technique, the [snip] > > Disadvantages: There was supposed to be a list of them here, but I > > can't find any :-) > > New inlines don't work with G++. It should be explained why there are two > inline directories: "inline" and "inline++". Thanks, I'll correct it. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Nov 24 13:09:30 1995 Received: from zaz.kom.auc.dk ([130.225.51.10]) by nic.funet.fi with ESMTP id <88997-3>; Fri, 24 Nov 1995 13:08:02 +0200 Received: from skoda.kom.auc.dk (jds@skoda.kom.auc.dk [130.225.51.24]) by zaz.kom.auc.dk (8.7.1/8.7.1) with ESMTP id MAA11649; Fri, 24 Nov 1995 12:07:44 +0100 (MET) Received: (from jds@localhost) by skoda.kom.auc.dk (8.7.1/8.7.1) id MAA07800; Fri, 24 Nov 1995 12:07:38 +0100 (MET) Date: Fri, 24 Nov 1995 12:07:38 +0100 (MET) Message-Id: <199511241107.MAA07800@skoda.kom.auc.dk> From: Jes Degn Soerensen To: Lars Hecking Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Subject: GNU tar 1.11.8 In-Reply-To: <199511232149.VAA02458@mostar.nmrc.ucc.ie> References: <199511232149.VAA02458@mostar.nmrc.ucc.ie> >>>>> "Lars" == Lars Hecking writes: Lars> If anybody wants to beta-test GNU tar 1.11.8, sent me email, Lars> including machine/cpu/fpu info. I would like to try it out: A3000/PPS040/25MHz - I have an Archive Viper 150 connected aswell that I would like try it on aswell. Please note if there is anything specific you would like me to test. Lars> The amiga-specific problem with the '-z' option is still there, Lars> though. Remote tape handling is "consistently disabled" ;) Lars> (stubbed out getservbyname and rexec). I have not been able to Lars> compile tar with localization, neither with 2.7.0 nor 2.7.1, Lars> neither on Amiga nor SPARC. Just in case someone expected this ;) Well remote tape-handling is buggy in 1.11.8 anyway, but I think we have a patch around somewhere if anyone needs it (sorry a bit off topic). Jes From amiga-gcc-port-owner@nic.funet.fi Fri Nov 24 15:57:36 1995 Received: from europe.std.com ([192.74.137.10]) by nic.funet.fi with SMTP id <90069-1>; Fri, 24 Nov 1995 15:50:46 +0200 Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id IAA23856; Fri, 24 Nov 1995 08:50:44 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA12133; Fri, 24 Nov 1995 08:48:31 -0500 Date: Fri, 24 Nov 1995 08:48:30 +0001 (EST) From: "Thomas E. Janzen" Subject: Re: Repeat math output << c++ To: Amiga GCC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks! It worked! Kriton Kyrimis pointed out that I needed the right ixemul library, and I did, but I didn't rename it IXemul.library. Thanks to Joop van de Wege, Bart van Assche, David Zaroski and Fred Fish. I suppose that this means that I shouldn't post any more questions until I read at least most of the amigaguide and manual documentation with the 2.7.0 kit... Believe or not I understand the issues, but I just didn't read the docs and chase down the library, which had begun to worry me pretty early, but I ignored it because the 2.6.3 thing worked. THe fact is, I must have done exactly the same routine on 2.6.3. Now I have something to be thankful about. Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio If you want it done, plan it; if you want it done right, spec it. From amiga-gcc-port-owner@nic.funet.fi Fri Nov 24 18:21:40 1995 Received: from trappist.elis.rug.ac.be ([157.193.67.1]) by nic.funet.fi with SMTP id <89364-2>; Fri, 24 Nov 1995 18:17:38 +0200 Received: from ibmpar.elis.rug.ac.be by trappist.elis.rug.ac.be with SMTP id AA18307 (5.65c/IDA-1.4.4 for ); Fri, 24 Nov 1995 17:18:17 +0100 Received: by ibmpar.elis.rug.ac.be (AIX 3.2/UCB 5.64/4.03) id AA22735; Fri, 24 Nov 1995 17:22:20 GMT From: bvassche@ibmpar.elis.rug.ac.be (Bart Van Assche) Message-Id: <9511241722.AA22735@ibmpar.elis.rug.ac.be> Subject: unsub To: amiga-gcc-port@nic.funet.fi Date: Fri, 24 Nov 1995 17:22:20 +0000 (GMT) Cc: unsubscribe@ibmpar.elis.rug.ac.be X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 37 unsubscribe Bart.VanAssche@rug.ac.be From amiga-gcc-port-owner@nic.funet.fi Fri Nov 24 18:22:08 1995 Received: from trappist.elis.rug.ac.be ([157.193.67.1]) by nic.funet.fi with SMTP id <89546-4>; Fri, 24 Nov 1995 18:20:58 +0200 Received: from ibmpar.elis.rug.ac.be by trappist.elis.rug.ac.be with SMTP id AA18334 (5.65c/IDA-1.4.4 for ); Fri, 24 Nov 1995 17:21:26 +0100 Received: by ibmpar.elis.rug.ac.be (AIX 3.2/UCB 5.64/4.03) id AA23533; Fri, 24 Nov 1995 17:25:29 GMT From: bvassche@ibmpar.elis.rug.ac.be (Bart Van Assche) Message-Id: <9511241725.AA23533@ibmpar.elis.rug.ac.be> Subject: help To: amiga-gcc-port@nic.funet.fi Date: Fri, 24 Nov 1995 17:25:28 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5 help From amiga-gcc-port-owner@nic.funet.fi Fri Nov 24 18:22:18 1995 Received: from trappist.elis.rug.ac.be ([157.193.67.1]) by nic.funet.fi with SMTP id <89900-3>; Fri, 24 Nov 1995 18:21:29 +0200 Received: from ibmpar.elis.rug.ac.be by trappist.elis.rug.ac.be with SMTP id AA18344 (5.65c/IDA-1.4.4 for ); Fri, 24 Nov 1995 17:22:01 +0100 Received: by ibmpar.elis.rug.ac.be (AIX 3.2/UCB 5.64/4.03) id AA23541; Fri, 24 Nov 1995 17:26:05 GMT From: bvassche@ibmpar.elis.rug.ac.be (Bart Van Assche) Message-Id: <9511241726.AA23541@ibmpar.elis.rug.ac.be> Subject: unsubscribe To: amiga-gcc-port@nic.funet.fi Date: Fri, 24 Nov 1995 17:26:04 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 37 unsubscribe Bart.VanAssche@rug.ac.be From amiga-gcc-port-owner@nic.funet.fi Fri Nov 24 21:10:46 1995 Received: from rumms.uni-mannheim.de ([134.155.50.52]) by nic.funet.fi with SMTP id <90069-1>; Fri, 24 Nov 1995 21:06:07 +0200 Received: from pips01.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA14039 (5.65c/IDA-1.4.4 for ); Fri, 24 Nov 1995 20:04:34 +0100 Received: from pips14.informatik.uni-mannheim.de by pips01.informatik.uni-mannheim.de (4.1/BelWue-1.1Sma2(subsidiary)) id AA17954; Fri, 24 Nov 95 20:00:51 +0100 Received: by pips14.informatik.uni-mannheim.de (5.0/SMI-SVR4) id AA07020; Fri, 24 Nov 1995 20:03:57 --100 From: opel@pips01.informatik.uni-mannheim.de (Steffen Opel) Message-Id: <9511241903.AA07020@pips14.informatik.uni-mannheim.de> Subject: Uploaded GCC-Install 2.13 (for GNU C 2.7.1) To: phb@telesys-innov.fr Date: Fri, 24 Nov 1995 20:03:56 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2412 Salut, I've just uploaded new revision of GCC-Install (incl. GCC-Install.info) for inclusion with GNU C 2.7.1 to ftp.telesys-innov.fr, /pub/amigados-gnu/uploads. Since this is the first time for me to do this, I've to apologize for uploading a) GCC-Install and GCC-Install.info as is , and b) GCC-Install.lha with both files included. I just didn't know which way is preferred and deleting files should be easy. Unfortunately I'm in a big hurry for vacation ;-) (otherwise I would have asked before uploading), therefore I won't be able to correct problems or provide any enhancements before 16.12.1995. If any problems occure (which is likely, see ISSUE: below), somebody else has to correct them, sorry. The script from Jochen Wiedmann has prooved mainly stable, therefore I just did the following: REV: Changed support-address from Wiedmann to Opel, of course. REV: Changed layout of code to my personal preferences. I just didn't get to the point due to all these parenthesis ;-). REV: Edited some texts a little bit. REV: Added short help-text concerning the mailing-list. REV: CheckOSVersion now uses built-in checking, rather than checking 'exec.library'. Hopefully this hasn't been done with intention. FIX: There was a bug, when installing objc on a 68000 machine. QAD: Quick and dirty workaround to enable NOVICE-users to select files too ('lha' and the archives themselves). Otherwise this ended up in a never-ending loop, if those files couldn't be found at the default places (very likely!) Since this workaround uses (user x), it should be removed sometimes! REV: Integrated 2.7.1 changes as far as I'm aware of them (mainly based on Rask's new README) -> gccv removed, directories currently m68k-unknown-amigaos, archives currently xyz-020.lha, 'c++...' now 'cp...' ISSUE: The above mentioned namings are still subject of discussion and have been somewhat inconsistent in the past (i.e. c-020.lha <-> objc020.lha). Therefore its likely that those currently in the script aren't exactly what's going to be in the official release 2.7.1. If this release happens to occure within the next three weeks, it would be nice, if someone could correct the namings to the actual ones. Otherwise I'll do this and anything else after my return. Hopefully this revision isn't absolutely useless, shame on me if You have to revert to Jochens Wiedmanns last version for some reason ;-) Ciao, Steffen Opel From amiga-gcc-port-owner@nic.funet.fi Sat Nov 25 00:50:08 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89824-1>; Sat, 25 Nov 1995 00:48:02 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tJ7JX-000R7GC; Sat, 25 Nov 95 00:13 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0c2u@wyst.hobby.nl>; Fri, 24 Nov 95 21:17:33 CET Message-Id: <9511242017.0c2u@wyst.hobby.nl> Date: Fri, 24 Nov 1995 21:17:30 +0000 (CET) In-Reply-To: from "Rask Lambertsen" at Nov 22, 95 09:32:10 pm Content-Type: text Content-Length: 784 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Questions about README + various + misc Rask, > On Wed, 22 Nov 1995, Hans Verkuil wrote: > > > > Is there any hope of seing GCC pass arguments in registers? > >=20 > > I doubt it :-) > ^^^ > Are you actually happy with that? I think this is one of the areas where=20 > GCC looses out badly to (almost) all other Amiga C compilers. OK, my meaning was a bit obscure: I meant that passing arguments in registers is a wish that is unlikely to be fulfilled. I agree that it would be a nice thing to have. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat Nov 25 17:53:31 1995 Received: from mserv.rug.ac.be ([157.193.40.37]) by nic.funet.fi with SMTP id <89122-1>; Sat, 25 Nov 1995 17:50:10 +0200 Received: from eduserv.rug.ac.be by mserv.rug.ac.be with SMTP id AA25003 (5.67b/IDA-1.5 for ); Sat, 25 Nov 1995 16:49:52 +0100 Received: by eduserv.rug.ac.be (5.x/SMI-SVR4) id AA23518; Sat, 25 Nov 1995 16:49:35 +0100 Date: Sat, 25 Nov 1995 16:49:35 +0100 (MET) From: Kristof Depraetere To: Amiga GCC Cc: phb@telesys-innov.fr, Kristof Depraetere Subject: Uploaded texinfo-3.6 In-Reply-To: <9511241903.AA07020@pips14.informatik.uni-mannheim.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I uploaded texinfo-3.6-951125.tar.gz to colombo.telesys-innov.fr . I changed the source of makeinfo to generate v37 or v39 AmigaGuide files from texinfo files. The old makeinfo from texinfo-3.1 could only generate v37 Amigaguide files. Maybe Philippe can also generate some fancy v39 AmigaGuides from the GNU documentation? Mail me if you experience any problems with my upload. (Note to Philippe: the texinfo-3.6-951115.tar.gz file (~16Kb) was a mistake. Just delete it.) bye, Kristof. From amiga-gcc-port-owner@nic.funet.fi Sat Nov 25 19:57:45 1995 Received: from carina.rz.Uni-Osnabrueck.DE ([131.173.128.25]) by nic.funet.fi with SMTP id <89546-3>; Sat, 25 Nov 1995 19:54:32 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id SAA37969 for ; Sat, 25 Nov 1995 18:23:24 +0100 From: Thomas Radtke Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.7.1/8.7.1) id SAA17584 for amiga-gcc-port@lists.funet.fi; Sat, 25 Nov 1995 18:23:23 +0100 Message-Id: <199511251723.SAA17584@nereid.rz.Uni-Osnabrueck.DE> Subject: fionread To: amiga-gcc-port@nic.funet.fi Date: Sat, 25 Nov 1995 18:23:22 +0100 (NFT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, its me again with another (silly ?) question on ioctl's FIONREAD command. In one application I must ungetc a few characters to stdin, but after this beeing done, ioctl(stdin,FIONREAD,&nc) fills the nc variable with null. I get the correct value only after typing a key on my keyboard. I do not assume that this is the normal behaviour for FIONREAD, right ? I will take a closer look at this if you tell me that Im not wrong. It seems that the unget buffer is merged with the 'normal' buffer only if a new char arrives from the keybord (or console). I tried to deal somehow with fflush, but w/o success. BTW., is anybody maintaining ioctl ? It seems that the source is original Markus Wild. Or does nobody care about this function ? Thomas From amiga-gcc-port-owner@nic.funet.fi Sun Nov 26 00:21:41 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <89822-1>; Sun, 26 Nov 1995 00:19:39 +0200 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id XAA01224 (8.6.10/2.4); Sat, 25 Nov 1995 23:20:18 +0100 Date: Sat, 25 Nov 1995 23:20:18 +0100 From: Olaf Seibert Message-Id: <199511252220.XAA01224@septimius.mbfys.kun.nl> To: Thomas.Radtke@rz.Uni-Osnabrueck.DE, amiga-gcc-port@nic.funet.fi, rhialto@mbfys.kun.nl Subject: Re: fionread Thomas Radtke typed: > its me again with another (silly ?) question on ioctl's > FIONREAD command. In one application I must ungetc a few > characters to stdin, but after this beeing done, > ioctl(stdin,FIONREAD,&nc) fills the nc variable with null. > I get the correct value only after typing a key on my > keyboard. I do not assume that this is the normal behaviour > for FIONREAD, right ? I will take a closer look at this if > you tell me that Im not wrong. It seems that the unget buffer > is merged with the 'normal' buffer only if a new char arrives > from the keybord (or console). I tried to deal somehow with > fflush, but w/o success. The problem here is that there are indeed two different bufffers. The buffer that FIONREAD deals with is the one in the operating system. The one that unhetc() deals is the buffers from the stdio set of functions. Unfortunately there is no way that is portable to find out how much data is on those stdio buffers. In general, for specific implementations, this is pretty easy to figure out given , especially if getc() is a macro, so in emergency cases it is "doable" (but still ugly). An alternative is to make the stream unbuffered, though this may degrade performance. In some cases, depending on how the access to the stream exactly is, it may improve performance though. To chang ebuffering status, use the ANSI/ISO standard function setvbuf(). > Thomas -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Sun Nov 26 02:19:48 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89739-1>; Sun, 26 Nov 1995 02:18:30 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tJVDc-000QzkC; Sun, 26 Nov 95 01:45 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0c4d@wyst.hobby.nl>; Sat, 25 Nov 95 21:14:00 CET Message-Id: <9511252014.0c4d@wyst.hobby.nl> Date: Sat, 25 Nov 1995 21:13:58 +0000 (CET) In-Reply-To: <199511251723.SAA17584@nereid.rz.Uni-Osnabrueck.DE> from "Thomas Radtke" at Nov 25, 95 06:23:22 pm Content-Type: text Content-Length: 1852 From: hans@wyst.hobby.nl (Hans Verkuil) To: Thomas.Radtke@rz.Uni-Osnabrueck.DE Cc: amiga-gcc-port@nic.funet.fi Subject: Re: fionread Hi Thomas, > its me again with another (silly ?) question on ioctl's > FIONREAD command. In one application I must ungetc a few > characters to stdin, but after this beeing done, > ioctl(stdin,FIONREAD,&nc) fills the nc variable with null. You cannot mix low level I/O calls (such as write(), read(), ioctl() ) with high level I/O calls (fprintf(), fwrite(), fread(), ungetc() ). The high level calls read data in a buffer first and the low level calls have no knowledge of that buffer. Also, you cannot pass a high level filehandle such as stdin to a low level call such as ioctl. Perhaps you meant ioctl(0, FIONREAD, &nc) instead? > I get the correct value only after typing a key on my > keyboard. I do not assume that this is the normal behaviour > for FIONREAD, right ? This is normal behavior as it has no knowledge of the high level buffer, so ioctl just tries to read from the input. And your keystroke is the first input it gets. > I will take a closer look at this if > you tell me that Im not wrong. It seems that the unget buffer > is merged with the 'normal' buffer only if a new char arrives > from the keybord (or console). I tried to deal somehow with > fflush, but w/o success. Why not use getchar() instead? > BTW., is anybody maintaining ioctl ? It seems that the > source is original Markus Wild. Or does nobody care about > this function ? I'm the new maintainer of the ixemul.library. Testing and distribution is done by Fred Fish, but I'm doing the programming side of the job. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sun Nov 26 19:46:41 1995 Received: from carina.rz.Uni-Osnabrueck.DE ([131.173.128.25]) by nic.funet.fi with SMTP id <89232-2>; Sun, 26 Nov 1995 19:45:30 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id SAA37299; Sun, 26 Nov 1995 18:45:21 +0100 From: Thomas Radtke Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.7.1/8.7.1) id SAA22676; Sun, 26 Nov 1995 18:45:20 +0100 Message-Id: <199511261745.SAA22676@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: fionread To: rhialto@mbfys.kun.nl (Olaf Seibert) Date: Sun, 26 Nov 1995 18:45:20 +0100 (NFT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511252220.XAA01224@septimius.mbfys.kun.nl> from "Olaf Seibert" at Nov 25, 95 11:20:18 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Olaf, > > The problem here is that there are indeed two different bufffers. > The buffer that FIONREAD deals with is the one in the operating > system. The one that unhetc() deals is the buffers from the > stdio set of functions. Hmmm, Ive wrote to Hans (again forgot to forward to this list :( ) that I will drop this method, but there must be a way to merge the buffers since this is exactly what happens after keypress... It is not the case, that nothing works. The unget buffer (on stdio level) merges just too late with the system buffer, but it does. Thomas From amiga-gcc-port-owner@nic.funet.fi Sun Nov 26 20:43:16 1995 Received: from edina.xenologics.com ([194.77.5.1]) by nic.funet.fi with SMTP id <87979-2>; Sun, 26 Nov 1995 20:42:34 +0200 Received: (from root@localhost) by edina.xenologics.com (8.6.8.1/8.6.6) id TAA29765 for nic.funet.fi!amiga-gcc-port; Sun, 26 Nov 1995 19:30:08 +0100 X-ZC-VIA: 19951126105846W+1@darkness.gun.de From: DarkStar@darkness.gun.de (Carsten Meyer) Subject: Bug in Compiler V2.7.0 - 'default' as variable name :-( Message-ID: Date: Sun, 26 Nov 95 09:54:28 CET X-ZC-FILE: gnubug.c Return-Receipt-To: DarkStar@darkness.gun.de (Carsten Meyer) Organization: CDC X-ZC-POST: Postfach 11 12;31596 Uchte X-Mailer: MicroDot 1.10 [UNREGISTRIERT] via Connectline-CLMSortin 2.25 X-Gateway: ZConnect DA darkness.gun.de [Connectline/AmigaOS] To: amiga-gcc-port@nic.funet.fi /* Demonstation of compiler bug GNU C V2.7.0 GNU C produces a wrong error message if the name "default" is used as a variable name in prototypes and/or funktions. */ void test ( signed int a, signed int b, signed int default ); int main ( void ) { Test ( 1, 2, 3 ); return ( 0 ); } void test ( signed int a, signed int b, signed int default ) { printf ( "%d %d %d\n", a, b, default ); } /* 4.Ram Disk: 0> gcc -c -Wall gnubug.c -o gnubug.o gnubug.c:11: parse error before `default' gnubug.c: In function `main': gnubug.c:16: warning: implicit declaration of function `Test' gnubug.c: At top level: gnubug.c:21: parse error before `default' gnubug.c: In function `test': gnubug.c:23: warning: implicit declaration of function `printf' gnubug.c:23: `a' undeclared (first use this function) gnubug.c:23: (Each undeclared identifier is reported only once gnubug.c:23: for each function it appears in.) gnubug.c:23: `b' undeclared (first use this function) gnubug.c:23: parse error before `default' 4.Ram Disk: 1> Everything works fine if using a different name instead of "default". */ From amiga-gcc-port-owner@nic.funet.fi Sun Nov 26 21:08:28 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <88194-4>; Sun, 26 Nov 1995 21:07:56 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id UAA23587; Sun, 26 Nov 1995 20:04:40 +0100 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id UAA24658; Sun, 26 Nov 1995 20:02:10 +0100 Date: Sun, 26 Nov 1995 20:02:10 +0100 From: Niklas Hallqvist Message-Id: <199511261902.UAA24658@linda.appli.se> To: DarkStar@darkness.gun.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: (DarkStar@darkness.gun.de) Subject: Re: Bug in Compiler V2.7.0 - 'default' as variable name :-( Huh, default is a reserved word in C It's simply invalid as a variable name, every compiler that accepts it is buggy. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Home: +46-(0)31-41 93 95 Applitron Datasystem Fax: +46-(0)31-83 39 50 Home: +46-(0)31-41 93 96 Molndalsvagen 95 Email: niklas@appli.se GSM: +46-(0)70-714 10 35 S-412 63 GOTEBORG WWW: Here Sweden IRC: niklas (#NetBSD) ICB: niklas (netbsd) From amiga-gcc-port-owner@nic.funet.fi Sun Nov 26 21:09:40 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <88724-3>; Sun, 26 Nov 1995 21:09:35 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id TAA07748; Sun, 26 Nov 1995 19:07:44 GMT From: Lars Hecking Message-Id: <199511261908.TAA05217@mostar.nmrc.ucc.ie> Subject: Re: Bug in Compiler V2.7.0 - 'default' as variable name :-( To: DarkStar@darkness.gun.de (Carsten Meyer) Date: Sun, 26 Nov 1995 19:08:42 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Carsten Meyer" at Nov 26, 95 09:54:28 am Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 276 > > /* > > Demonstation of compiler bug > > GNU C V2.7.0 > > GNU C produces a wrong error message if the name "default" > is used as a variable name in prototypes and/or funktions. > > */ 'default' is a keyword and may not be used otherwise. See K&R2 A2.4. From amiga-gcc-port-owner@nic.funet.fi Mon Nov 27 00:16:29 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <88909-4>; Mon, 27 Nov 1995 00:15:01 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Sun, 26 Nov 95 23:15 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Sun, 26 Nov 95 23:11 MET Message-Id: Subject: help on printerdriver To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Sun, 26 Nov 1995 23:11:20 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 501 had ever someone tried to comile a printerdriver for the amiga with gcc ? i tried to compile the epson driver of the C= examples for gcc, but i have some problems that i dont understand. i have converted the most examples ready-to-use -with-gcc what includes a makefile. is there somewhere i can store it (outside philips site)? is someone willing to take a look on the examples i converted so far ? (most are pretty easy) walter -- ----- "What would *I* do if I were me?" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Nov 27 11:49:44 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90553-4>; Mon, 27 Nov 1995 11:47:03 +0200 Received: from info.forthnet.gr (info.forthnet.gr [139.91.1.17]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id JAA03388 for ; Mon, 27 Nov 1995 09:46:56 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: from acrogate.UUCP by info.forthnet.gr via FORTHnet with UUCP; id LAA15386 (8.6.12/FORTHNET-2.0); Mon, 27 Nov 1995 11:43:58 +0200 (EET DST) Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0tK29Q-000AwgC; Mon, 27 Nov 95 11:55 GMT Message-Id: Date: Mon, 27 Nov 95 11:55 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Subject: Strange Alert! Hello! I just want to ask you something that doesn't have to do with programming, but it has to do with the Amiga. Please forgive me for this! In the last few weeks I've encounter a *strange* Recoverable Alert! When it occurs the system either hungs or just display the alert endlessly. The error is #0100000C and it is interpreted by "The Guru" utility, as "Sanity check on memory list failed, during AvailMem() (MEMF_LARGEST)". The same explanation gives the NewAlert utility. I am using a standard A3000/030 (4MB Fast RAM, 2MB Chip RAM) with Kickstart v37.175 and Workbench v38.12 (which I believe is a beta version). The NewAlert utility also tells me that the error was caused by RAM. This error appears on strange conditions; sometimes when I try to uncompress an archive, other times when I try to save data with a program, etc. Generally, when this happens (and the system doesn't hung or alert), the pointer becomes "locked up" for a few seconds and then it's ok again. Imploder 4.0 gives me this error when it presents its operation panel. Any Ideas what's wrong? I would be grateful if someone could tell me what to do! The most ironic one is that I bought this A3000 second hand and I'm using it for about 3 weeks WITHOUT EVEN A SINGLE CRASH (except this error). Thank you very much in advance and hoping to hear from you soon. Regards, MSP From amiga-gcc-port-owner@nic.funet.fi Mon Nov 27 12:26:32 1995 Received: from lillep.gbar.dtu.dk ([130.225.87.179]) by nic.funet.fi with ESMTP id <90411-4> convert rfc822-to-8bit; Mon, 27 Nov 1995 12:25:50 +0200 Received: by lillep.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 27 Nov 1995 11:25:48 +0100 (MET) From: Rask Lambertsen To: Walter Harms Cc: amiga gcc-list Subject: Re: problems with SP libraries In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 22 Nov 1995, Walter Harms wrote: > > FFP is not supported and hopefully will never be. Float and double are enough > > floating point formats (OK, long double would be nice). I've worked with > > Macs and they offer you a whole platoon of different floating point > > formats, each incompatible with one another. I don't want a similar > > situation on the Amiga. Let's keep to the standard IEEE formats. > > > oh thats not a problem for me (in fact i never use these functions > because i have a fpu), but its a part of the OS and it should be noted > that we dont support this funktions (rask ?). Is it only FFP that is not supported, or is single precision IEEE not supported either? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Nov 27 16:06:13 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90476-3>; Mon, 27 Nov 1995 16:05:30 +0200 Received: from bastion.nmrc.ucc.ie (nmrc.ucc.ie [143.239.64.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id OAA06703 for ; Mon, 27 Nov 1995 14:05:24 GMT Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id OAA22416 for ; Mon, 27 Nov 1995 14:03:50 GMT From: Lars Hecking Message-Id: <199511271306.NAA06013@mostar.nmrc.ucc.ie> Subject: Re: Uploaded texinfo-3.6 To: Kristof.Depraetere@rug.ac.be (Kristof Depraetere) Date: Mon, 27 Nov 1995 13:06:06 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Kristof Depraetere" at Nov 25, 95 04:49:35 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 500 > I uploaded texinfo-3.6-951125.tar.gz to colombo.telesys-innov.fr . Good work, thanks a lot! Quite a few bugs from makeinfo 1.55 are fixed. I can now even create tar-1.11.8.guide without killing my machine ;^) > I changed the source of makeinfo to generate v37 or v39 AmigaGuide files > from texinfo files. The old makeinfo from texinfo-3.1 could only generate > v37 Amigaguide files. ?? mkguide155 from aminet _has_ a working --amiga-39 option. Did you start off with version 1.49b ? From amiga-gcc-port-owner@nic.funet.fi Mon Nov 27 17:18:08 1995 Received: from mserv.rug.ac.be ([157.193.40.37]) by nic.funet.fi with SMTP id <90411-4>; Mon, 27 Nov 1995 17:16:07 +0200 Received: from eduserv.rug.ac.be by mserv.rug.ac.be with SMTP id AA08809 (5.67b/IDA-1.5 for ); Mon, 27 Nov 1995 16:15:56 +0100 Received: by eduserv.rug.ac.be (5.x/SMI-SVR4) id AA24911; Mon, 27 Nov 1995 16:15:40 +0100 Date: Mon, 27 Nov 1995 16:15:39 +0100 (MET) From: Kristof Depraetere To: Lars Hecking Cc: Kristof Depraetere , Amiga GCC List Subject: Re: Uploaded texinfo-3.6 In-Reply-To: <199511271306.NAA06013@mostar.nmrc.ucc.ie> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 27 Nov 1995, Lars Hecking wrote: > > > I changed the source of makeinfo to generate v37 or v39 AmigaGuide files > > from texinfo files. The old makeinfo from texinfo-3.1 could only generate > > v37 Amigaguide files. > > ?? mkguide155 from aminet _has_ a working --amiga-39 option. Did you start > off with version 1.49b ? > mkguide155 on aminet is based on makeinfo v1.55. The makeinfo in texinfo-3.6 is version 1.63 (if I remember correctly). I also received a diff for makeinfo v1.55 from Fred Fish. I merged both diffs into the new makeinfo and fixed some bugs. (Some nasty memory leaks, "--" was turned into "-", ...) If you find more bugs in it, just let me know. bye, Kristof. From amiga-gcc-port-owner@nic.funet.fi Mon Nov 27 17:55:10 1995 Received: from legolas.mdh.se ([130.238.251.203]) by nic.funet.fi with ESMTP id <90599-4>; Mon, 27 Nov 1995 17:53:12 +0200 Received: (from frv95tjn@localhost) by legolas.mdh.se (8.7.1/8.7.1) id QAA01185; Mon, 27 Nov 1995 16:53:17 +0100 (MET) Date: Mon, 27 Nov 1995 16:53:16 +0100 (MET) From: Tommy Johansson X-Sender: frv95tjn@legolas.mdh.se To: Fred Fish cc: Amiga GCC mailing list Subject: Amiga GNU Tools Project List In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is there a list with the persons involved with the things on the list? Tommy Johansson frv95tjn@mds.mdh.se From amiga-gcc-port-owner@nic.funet.fi Mon Nov 27 18:20:44 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90537-3>; Mon, 27 Nov 1995 18:20:22 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tK6Jp-0004nYC; Mon, 27 Nov 95 09:22 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Amiga GNU Tools Project List To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Mon, 27 Nov 1995 09:22:12 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 527 > Is there a list with the persons involved with the things on the list? Not yet, but almost. :-) I recently installed majordomo (a list server) here and will soon be setting up some specific lists for various projects. I'm working right now on testing and packaging the latest set of tools in source and binary form, to make them available for ftp. Once this is ready then I'll be updating the projects list, setting up the mailing lists, and taking care of the other administrative details to get things rolling. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Nov 27 18:28:49 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89092-2>; Mon, 27 Nov 1995 18:28:15 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tK6RR-0004nYC; Mon, 27 Nov 95 09:30 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Amiga GNU Tools Project List To: frv95tjn@mds.mdh.se (Tommy Johansson) Date: Mon, 27 Nov 1995 09:30:04 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Tommy Johansson" at Nov 27, 95 04:53:16 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 734 BTW, I'm still trying to come up with a name for this project. I want it to reflect the fact that it is for an Amiga, that it is oriented towards providing developers with needed resources, and that it is a complete as possible environment for doing Amiga development (and is also self hosting, I.E. all source is provided for building any of the binary parts). I'm currently using "ADE", for "Amiga Developers Environment", though I'm not entirely thrilled about the acronym. It would be nice to have something catchy. Any ideas? I want to avoid GNU as part of the name just to avoid having people think that it is nothing but a port of the GNU tools, since what I have in mind will ultimately be much broader than that. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Nov 27 20:16:34 1995 Received: from carina.rz.Uni-Osnabrueck.DE ([131.173.128.25]) by nic.funet.fi with SMTP id <89092-1>; Mon, 27 Nov 1995 20:15:56 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id TAA37119 for ; Mon, 27 Nov 1995 19:15:00 +0100 From: Thomas Radtke Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.7.1/8.7.1) id TAA15608 for amiga-gcc-port@lists.funet.fi; Mon, 27 Nov 1995 19:14:59 +0100 Message-Id: <199511271814.TAA15608@nereid.rz.Uni-Osnabrueck.DE> Subject: more trouble To: amiga-gcc-port@nic.funet.fi Date: Mon, 27 Nov 1995 19:14:59 +0100 (NFT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit /* Hi, My problems with buffering of sdtin caused me to go a different way. I simply switched the O_NDELAY flag so that I can check directly by getchar() whether there are chars to be read or not. I have isolated the principle to the code below. It works on AIX with gcc 2.7.0, but gurus my Amiga OS3.0 after exit :(. */ #include #include #include #include void switchmode() { struct sgttyb stty; short flags; /* ioctl(fileno(stdin),TIOCGETP,&stty); stty.sg_flags^=(CBREAK | ECHO | RAW); ioctl(fileno(stdin),TIOCSETP,&stty); */ flags=fcntl(fileno(stdin),F_GETFL,0); flags^=O_NDELAY; fcntl(fileno(stdin),F_SETFL,flags); } main() { unsigned char c; /* Im working also w/ k&r compilers :) */ switchmode(); while ((c=getchar())!='q') { if (c!=(unsigned char)255) printf("%c\n",c); } switchmode(); } /* Thomas */ From amiga-gcc-port-owner@nic.funet.fi Mon Nov 27 20:21:42 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89472-4>; Mon, 27 Nov 1995 20:21:23 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 27 Nov 95 19:21 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 27 Nov 95 19:18 MET Message-Id: Subject: akronym: amiga development enviroment To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 27 Nov 1995 19:17:57 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 378 amiga development enviroment - ADE itegrated development enviroment - IDEA for amiga Amiga develOpment enviromenT - AOT (from grisu2) Amiga itegrated Amiga DeveLpment EnviRoment - ADLER Amiga Assembly Line - AAL Online CodeCreater for AMiga _ OCCAM -- ----- "Need a genius to unravel it..." "But you *are* a genius!" "Oh, yes! I definitely remember that!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Nov 28 00:26:25 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90621-1>; Tue, 28 Nov 1995 00:24:30 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tKCPJ-000R39C; Mon, 27 Nov 95 23:52 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0c8r@wyst.hobby.nl>; Mon, 27 Nov 95 20:06:26 CET Message-Id: <9511271906.0c8r@wyst.hobby.nl> Date: Mon, 27 Nov 1995 20:06:23 +0000 (CET) In-Reply-To: from "Rask Lambertsen" at Nov 27, 95 11:25:48 am Content-Type: text Content-Length: 539 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: problems with SP libraries According to Rask Lambertsen: > Is it only FFP that is not supported, or is single precision IEEE not=20 > supported either? Only FFP is not supported. Whenever you use 'float' in a C program you are using single precision IEEE. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Nov 28 00:26:48 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89472-1>; Tue, 28 Nov 1995 00:26:24 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tKCRG-000R3MC; Mon, 27 Nov 95 23:54 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0c91@wyst.hobby.nl>; Mon, 27 Nov 95 22:15:06 CET Message-Id: <9511272115.0c91@wyst.hobby.nl> Date: Mon, 27 Nov 1995 22:15:03 +0000 (CET) In-Reply-To: <199511271814.TAA15608@nereid.rz.Uni-Osnabrueck.DE> from "Thomas Radtke" at Nov 27, 95 07:14:59 pm Content-Type: text Content-Length: 1053 From: hans@wyst.hobby.nl (Hans Verkuil) To: Thomas.Radtke@rz.Uni-Osnabrueck.DE Cc: amiga-gcc-port@nic.funet.fi Subject: Re: more trouble According to Thomas Radtke: > > My problems with buffering of sdtin caused me to go a different > way. I simply switched the O_NDELAY flag so that I can check > directly by getchar() whether there are chars to be read or not. > I have isolated the principle to the code below. > It works on AIX with gcc 2.7.0, but gurus my Amiga OS3.0 after > exit :(. I've looked at this problem and discovered that there is a bug in the include file include/sys/fcntl.h, which in turn created a bug in the ixemul.library. If you are able/willing to recompile the 41.4 library, then I can mail you the new header (actually, I've also changed include/fcntl.h). Otherwise, you will have to wait for version 42.0. My thanks for your bug report! Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Nov 28 00:26:50 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89527-4>; Tue, 28 Nov 1995 00:26:06 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tKCPe-000R39C; Mon, 27 Nov 95 23:52 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0c8w@wyst.hobby.nl>; Mon, 27 Nov 95 20:10:27 CET Message-Id: <9511271910.0c8w@wyst.hobby.nl> Date: Mon, 27 Nov 1995 20:10:24 +0000 (CET) In-Reply-To: from "Manolis Pappas" at Nov 27, 95 11:55:00 am Content-Type: text Content-Length: 986 From: hans@wyst.hobby.nl (Hans Verkuil) To: mpap@acrogate.ath.forthnet.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Strange Alert! Hi Manolis, > In the last few weeks I've encounter a *strange* Recoverable Alert! > When it occurs the system either hungs or just display the alert > endlessly. The error is #0100000C and it is interpreted by "The > Guru" utility, as "Sanity check on memory list failed, during > AvailMem() (MEMF_LARGEST)". The same explanation gives the > NewAlert utility. You are almost certainly using an old ixemul.library. Probably version 39 or 40. Please upgrade to version 41.4, which is available on Aminet, dev/gcc. Pre-41 versions contained a very nasty memory trashing bug, which was only fixed in version 40.6. This bug caused precisely the symptoms you described. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Nov 28 17:04:42 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90599-2>; Tue, 28 Nov 1995 16:40:46 +0200 Received: from hamster.hrz.uni-giessen.de by funet.fi with SMTP (PP); Tue, 28 Nov 1995 16:40:19 +0200 Received: from mailserv.mni.fh-giessen.de by hamster.hrz.uni-giessen.de; Tue, 28 Nov 95 15:38:52 +0100 Received: from sun30.mni.fh-giessen.de by mailserv.mni.fh-giessen.de with smtp (Smail3.1.28.1 #6) id m0tKRBL-0007NvC; Tue, 28 Nov 95 15:38 MET Received: by sun30.mni.fh-giessen.de (5.x/client-1.3) id AA07146; Tue, 28 Nov 1995 15:38:49 +0100 From: "Thomas.Meckel" Message-Id: <9511281438.AA07146@sun30.mni.fh-giessen.de> Subject: unsubscribe To: amiga-gcc-port@nic.funet.fi Date: Tue, 28 Nov 1995 15:38:47 +0100 (MET) X-Mailer: ELM [version 2.4 PL0] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 unsubscribe Thomas.Meckel@min.fh-giessen.de From amiga-gcc-port-owner@nic.funet.fi Tue Nov 28 18:15:39 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <88947-3>; Tue, 28 Nov 1995 18:14:05 +0200 Received: from ceylon.informatik.uni-rostock.de by funet.fi with SMTP (PP); Tue, 28 Nov 1995 18:13:47 +0200 Received: by ceylon.informatik.uni-rostock.de id RAA04062; Tue, 28 Nov 1995 17:13:37 +0100 Received: by honshu.informatik.uni-rostock.de id RAA03499; Tue, 28 Nov 1995 17:13:25 +0100 From: Gunther Nikl Message-Id: <199511281613.RAA03499@honshu.informatik.uni-rostock.de> Subject: optimize bug with 2.7.0 To: amiga-gcc-port@nic.funet.fi Date: Tue, 28 Nov 1995 17:13:25 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2398 Hi! I am not sure whether I found a bug in the optimizer of gcc or not. One of my programs stopped working then I compiled it for large data. Below there are the parts that go wrong: --- unsigned int maximum=1000000,aktuell,cnt; void func() { aktuell=cnt=0; while(aktuell == 0) cnt++; maximum=aktuell; } ---- To understand the first test case (func) I have to say that all variables are also referenced by a different task (created with CreateTask()). Compiled with "-O2" I get the following for func1: --- _func1 clr.l _cnt clr.l _aktuell moveq #0,d0 1$ addq.l #1,_cnt tst.l d0 beq.s 1$ move.l _aktuell,__etext rts --- Please note the moveq before the label. Obviously the loop won't quit. One can argue that the above isn't a bug at all since the compiler can't know that several task access these variables, so - because the variable was cleared right before - the compiler may load the value directly into a register. If the first case isn't a bug then look at func2() (do not mentioned that this is bad programming habit I know but it won't work otherthise) --- void func2() { struct MsgPort port; while ((((struct Task *)port.mp_SigTask)->tc_SigRecvd & SIGBREAKF_CTRL_C) == 0) /* Abort on CTRL_C */ cnt++; /* Increment idle counter */ } --- This compiles to: ---- _func2 adda.w #$FFD8,sp movea.l $0012(sp),a0 btst #4,$001C(a0) bne.s 1$ moveq #0,d0 2$ addq.l #1,_cnt tst.l d0 beq.s 2$ 1$ adda.w #$0028,sp rts --- Can some one explain the above? I can't understand the moveq causing an endless loop. If I compile with "-O2 -fbaserel" it works! --- func1 lea _aktuell),a0 clr.l _cnt) clr.l (a0) 1$ addq.l #1,_cnt) tst.l (a0) beq.s 1$ move.l _aktuell),__etext) rts nop _func2 adda.w #$FFD8,sp bra.s 3$ 2$ addq.l #1,_cnt) 3$ movea.l $0012(sp),a0 btst #4,$001C(a0) beq.s 2$ adda.w #$0028,sp rts --- Gunther PS: Below the complete example source. Please answer also directly to me since I am not on the list --- #include #include #include unsigned int maximum=1000000,aktuell,cnt; void func() { aktuell=cnt=0; while(aktuell == 0) cnt++; maximum=aktuell; } void func2() { struct MsgPort port; while ((((struct Task *)port.mp_SigTask)->tc_SigRecvd & SIGBREAKF_CTRL_C) == 0) /* Abort on CTRL_C */ cnt++; /* Increment idle counter */ } --- From amiga-gcc-port-owner@nic.funet.fi Tue Nov 28 18:32:11 1995 Received: from trappist.elis.rug.ac.be ([157.193.67.1]) by nic.funet.fi with SMTP id <89928-3>; Tue, 28 Nov 1995 18:30:53 +0200 Received: from ibmpar.elis.rug.ac.be by trappist.elis.rug.ac.be with SMTP id AA11088 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 17:31:43 +0100 Received: by ibmpar.elis.rug.ac.be (AIX 3.2/UCB 5.64/4.03) id AA17581; Tue, 28 Nov 1995 17:35:25 GMT From: bvassche@ibmpar.elis.rug.ac.be (Bart Van Assche) Message-Id: <9511281735.AA17581@ibmpar.elis.rug.ac.be> Subject: Re: optimize bug with 2.7.0 To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Tue, 28 Nov 1995 17:35:24 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511281613.RAA03499@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Nov 28, 95 05:13:25 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1112 In a previous message Gunther Nikl wrote: > Hi! > I am not sure whether I found a bug in the optimizer of gcc > or not. One of my programs stopped working then I compiled it > for large data. Below there are the parts that go wrong: > > Please note the moveq before the label. Obviously the loop won't > quit. One can argue that the above isn't a bug at all since the > compiler can't know that several task access these variables, so > - because the variable was cleared right before - the compiler > may load the value directly into a register. Personally I don't think the GCC compiler is behaving the wrong way: it is perfectly normal for a compiler to analyze the behaviour of a variable regarding only the current thread/task. To solve your kind of problem the keyword 'volatile' was created: declaring a variable volatile tells the compiler that something external, wether it be a thread, task or interrupt, can change the variable. So you can write int maximum = 1000000; volatile int aktuell; volatile int cnt; -- __ /_/ /_/art Van Assche E-mail: Bart.VanAssche@elis.rug.ac.be From amiga-gcc-port-owner@nic.funet.fi Tue Nov 28 19:47:03 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89317-2>; Tue, 28 Nov 1995 19:44:15 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 28 Nov 95 18:44 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Tue, 28 Nov 95 18:40 MET Message-Id: Subject: need help with register To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 28 Nov 1995 18:40:30 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 665 i try to make a example library for gcc-usage. therefor i took Easylib.lha from aminet and changed it for gcc-usage. intrestingly it seems to work but there is one major problem. the initroutines of the library need there parameters in specific registers. so i defined for example: init ( libbase ) register struct Library *libbase asm ("a6"); but gcc seem to ignore that, the base is (e.g.) exspected in a2 (deadly).shown with a guick look at test.s. i tried volatile and everything i could imagine usfull but nothing seem to work. any suggestions outthere ? walter -- ----- We have joy, we have fun, we have PACMAN for the SUN... ----- From amiga-gcc-port-owner@nic.funet.fi Tue Nov 28 22:11:11 1995 Received: from lillep.gbar.dtu.dk ([130.225.87.179]) by nic.funet.fi with ESMTP id <89670-1> convert rfc822-to-8bit; Tue, 28 Nov 1995 22:06:28 +0200 Received: by lillep.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 28 Nov 1995 21:05:59 +0100 (MET) From: Rask Lambertsen To: Gunther Nikl Cc: amiga-gcc-port@nic.funet.fi Subject: Re: optimize bug with 2.7.0 In-Reply-To: <199511281613.RAA03499@honshu.informatik.uni-rostock.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 28 Nov 1995, Gunther Nikl wrote: > I am not sure whether I found a bug in the optimizer of gcc > or not. One of my programs stopped working then I compiled it > for large data. Below there are the parts that go wrong: > > --- > unsigned int maximum=1000000,aktuell,cnt; > > void func() > { > aktuell=cnt=0; > while(aktuell == 0) > cnt++; > maximum=aktuell; > } I think you should declare the variable "aktuell" as extern (= GLOBAL), so the compiler has a change to know that it is used somewhere else. > If the first case isn't a bug then look at func2() (do not > mentioned that this is bad programming habit I know but it > won't work otherthise) > > --- > void func2() > { > struct MsgPort port; > > while ((((struct Task *)port.mp_SigTask)->tc_SigRecvd & SIGBREAKF_CTRL_C) == 0) /* Abort on CTRL_C */ > cnt++; /* Increment idle counter */ > } > --- Again, the problem is that the compiler doesn't know that another task could have modified your memory. I guess that's what you can expect when porting something from UNIX. Using an OS function here would probably help you a lot, btw, such as SetSignal() (or something like that). > PS: Below the complete example source. Please answer also directly to > me since I am not on the list [source deleted] Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Nov 29 14:36:31 1995 Received: from ceylon.informatik.uni-rostock.de ([139.30.5.237]) by nic.funet.fi with SMTP id <90803-3>; Wed, 29 Nov 1995 14:31:42 +0200 Received: by ceylon.informatik.uni-rostock.de id NAA08663; Wed, 29 Nov 1995 13:31:29 +0100 Received: by honshu.informatik.uni-rostock.de id NAA06903; Wed, 29 Nov 1995 13:31:24 +0100 From: Gunther Nikl Message-Id: <199511291231.NAA06903@honshu.informatik.uni-rostock.de> Subject: Re: optimize bug with 2.7.0 To: amiga-gcc-port@nic.funet.fi Date: Wed, 29 Nov 1995 13:31:24 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 360 Thanks to all who replied to my question. Seems the mailing list is quite busy :-) All of the one who answered had the opinion theres no bug. You convinced me. Nethertheless one question remains: Why does it make a difference to compile with or without "-fbaserel". If compiling without breaks "-fbaserel" should break too, shouldn't it? Gunther From amiga-gcc-port-owner@nic.funet.fi Wed Nov 29 18:48:27 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <90736-1>; Wed, 29 Nov 1995 18:34:11 +0200 Received: by tuminfo2.informatik.tu-muenchen.de via suspension id <26585-4>; Wed, 29 Nov 1995 17:33:20 +0100 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26655-1>; Wed, 29 Nov 1995 17:31:44 +0100 Received: from hphalle8h.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395778-2>; Wed, 29 Nov 1995 17:31:28 +0100 Subject: Re: need help with register From: Christian Stieber To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Wed, 29 Nov 1995 17:31:16 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi In-Reply-To: from "Walter Harms" at Nov 28, 95 06:40:30 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1656 Message-Id: <95Nov29.173128+0100mesz.395778-2+2401@hphalle0.informatik.tu-muenchen.de> > > i try to make a example library for gcc-usage. > therefor i took Easylib.lha from aminet and > changed it for gcc-usage. > intrestingly it seems to work but there is one > major problem. the initroutines of the library > need there parameters in specific registers. > so i defined for example: > init ( libbase ) > register struct Library *libbase asm ("a6"); I don't like that either, personally. It lookslike a very hackish way of doing things. > i tried volatile and everything i could imagine > usfull but nothing seem to work. I use macros that work like this, if youwant the program that creates these macros, mail me (it's not on Aminet:(). Basically, it works like this: AsmStub >xxx.h saveds a0 a1 a6 and in your program: #include "xxx.h" ... SAVEDS_ASM_A0A1A6(ULONG,SomeFunction,struct xx *,xx, const char *,String, struct Library *,LibBase) { Some function... return 5; } IMHO a much cleaner solution, esp. since the AsmStub program supports SAS/C as well (and it could bemade to support Dice, of course). For GNU-C, the above will create an assembler stub which will then call a C function, with parameters on the stack as usual. The only problem with this is that you get zillions of "AsmStub"- executing rules in the makefile for a shared library :( Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Wed Nov 29 18:49:33 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90333-2>; Wed, 29 Nov 1995 18:43:07 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 29 Nov 95 15:20 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 29 Nov 95 15:12 MET Message-Id: Subject: still problems with libraries To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 29 Nov 1995 15:12:15 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 286 i hope i succeeded in creating my first library, but unfortunaly there remains the problem of creating the stubs. if this works i can distribute an gcc library example, thats something i was realy missing. walter -- ----- "I'm a knight-errant, not an errant fool!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Nov 29 19:17:16 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89833-1>; Wed, 29 Nov 1995 19:12:44 +0200 Received: from tuminfo2.informatik.tu-muenchen.de (actually user root@tuminfo2.informatik.tu-muenchen.de) by funet.fi with SMTP (PP); Wed, 29 Nov 1995 19:12:02 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26582-1>; Wed, 29 Nov 1995 17:47:38 +0100 Received: from hphalle8h.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395777-1>; Wed, 29 Nov 1995 17:47:21 +0100 Subject: Re: optimize bug with 2.7.0 From: Christian Stieber To: gnikl@informatik.uni-rostock.de (Gunther Nikl) Date: Wed, 29 Nov 1995 17:47:12 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199511291231.NAA06903@honshu.informatik.uni-rostock.de> from "Gunther Nikl" at Nov 29, 95 01:31:24 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 863 Message-Id: <95Nov29.174721+0100mesz.395777-1+2505@hphalle0.informatik.tu-muenchen.de> > All of the one who answered had the opinion theres no bug. You > convinced me. :) > Nethertheless one question remains: Why does it make a difference > to compile with or without "-fbaserel". If compiling without > breaks "-fbaserel" should break too, shouldn't it? No. Declaring a variable without "volatile", and accessing it from another task/interrupt/hardware/whatever yields undefined behaviour. Undefined behaviour is roughly equivalent to buggy programming, and the compiler doesn't have make sure that buggy programs behave the same way with/without optimizer/fbaserel/debugging etc. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Wed Nov 29 19:40:11 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <90745-2>; Wed, 29 Nov 1995 19:36:56 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.7.1/8.7.1) id SAA08566; Wed, 29 Nov 1995 18:36:41 +0100 (MET) Date: Wed, 29 Nov 1995 18:36:41 +0100 (MET) From: Ignatios Souvatzis Message-Id: <199511291736.SAA08566@theory.cs.uni-bonn.de> To: stieber@informatik.tu-muenchen.de CC: Walter.Harms@arbi.informatik.uni-oldenburg.de, amiga-gcc-port@nic.funet.fi In-reply-to: Christian Stieber's message of Wed, 29 Nov 1995 17:31:16 +0100 (MEZ) <95Nov29.173128+0100mesz.395778-2+2401@hphalle0.informatik.tu-muenchen.de> Subject: need help with register X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a; Wed, 29 Nov 1995 19:37:21 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.7.1/8.7.1) id SAA08585; Wed, 29 Nov 1995 18:37:04 +0100 (MET) Date: Wed, 29 Nov 1995 18:37:04 +0100 (MET) From: Ignatios Souvatzis Message-Id: <199511291737.SAA08585@theory.cs.uni-bonn.de> To: stieber@informatik.tu-muenchen.de CC: Walter.Harms@arbi.informatik.uni-oldenburg.de, amiga-gcc-port@nic.funet.fi In-reply-to: Christian Stieber's message of Wed, 29 Nov 1995 17:31:16 +0100 (MEZ) <95Nov29.173128+0100mesz.395778-2+2401@hphalle0.informatik.tu-muenchen.de> Subject: need help with register X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a; Thu, 30 Nov 1995 01:34:41 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 30 Nov 95 00:35 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 30 Nov 95 00:32 MET Message-Id: Subject: gcc and mathlibraries To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 30 Nov 1995 00:32:30 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1073 there where guestions what kind of amiga math library is supported by gcc. i have compiled every example provided by como an compared the result with the equivalent sas-c dpieee:Num1 = -0.523599 and result = -1 dpieee.sas:Num1 = -0.523599 and result = -1 dptrans:The double precision sine of 45 degrees is 0.707107 ffpbasic:Num1 = 3.141593 and result = -2147483648 ffpbasic.sas:Num1 = 3.141593 and result = 3 ffptrans:Num1 = 0.523599 and result = -3953856.000000 ffptrans.sas:Num1 = 0.523599 and result = 0.500000 mathsupport:Num1 = 3.141593 and result = -2147483648 mathsupport.sas:Num1 = 3.141593 and result = 3 spieee:-3.600000 multiplied by 18.699999 = 4.400000 spieee.sas:-3.600000 multiplied by 18.700001 = -67.320000 sptrans:The single precision cosine of 30 degrees is -0.541233 sptrans.sas:The single precision cosine of 30 degrees is -1.000000 you may notice some quit interessting results. i compiled with no special option yust gcc prg.c -o prg. the sas code whas provided by como. walter -- ----- "I reversed the polarity of the neutron flow..." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Nov 30 01:50:03 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90391-1>; Thu, 30 Nov 1995 01:49:25 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Thu, 30 Nov 95 00:49 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 30 Nov 95 00:44 MET Message-Id: Subject: debug To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 30 Nov 1995 00:44:22 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1997 this file is a debughelp i found this nice idea inside a package provide to aminet. the idea is nice so i would like to hear if its useabel. normaly you use kprint for debugging output but sometime you would like to see it on youe own screen. yust to make sure your routine has been called. the programm is called iprintf and uses rawdofmt because its based on easerequest :) there is an simple example that you can use this way: gcc itest.c iprintf.s -o itest in contrast to kprintf this prg will way until you klick that may be usefull in some cases. begin 644 DEBUG.LHA M'T(M;&@U+6(# =" (;A]'P "6EP8GP!^ M(YP.#)J)N./,/<6%DP& P% NW/1]I?2:T*14)*DDHOC?\E--)6.T"B#=>S#6 M1MM3,G,!_?LC_.%+0/\(,*Q0RE45;@G6P'<""8M]M ,7:ZFL\MC*:W3A.Q=0 M30V_FJG?'>R_[X+M5,'FMG@!>@RN5ZP8K1J(-_J%K::Z [_0I8_D/GW+_BIQ MH\I6.-&%_@KV4;QLM<%"R:#E@-8&^;:74KK.*/&TFN)AZ9^AF!<\'/8+!4HE M!8MCKX53F2F-Q>CC]-)P?&PJ_ZIWL%GJB(-&N3;=K_!2VEEL:==VQWBWU^5S MR_=E#7[?;MVI3FCH4O>H/G3=19.:_#N0JFOP0/;%FT:I$YD(J7Y%5&H)I-$V MKK&30.OK'9%HSMLZCB T%1"B$Q5G2SIB'2CZG'KXLPGF-5T/7M&-2,W9^L4T MF.AKB'7CF$\^Q^?_6L1C/6<=G5BC3213:GY]Y>*.^N;"$SD#./;U'" 0^?"O M\UG!PJI^A0KL1T@:YELKLH8U219QTY.3-)%KOTGMJ 0.,W92$,D6WFM;80'I MU9+U S4$[W7].RY)]GZ,B(55^!@ERNMS1=5[A>[WSUV94IU8U0Y@:NJIS3-/ M%YO"\=.>-RO^M%D(6]G'8_=@$)X,OTB]@D/7;:U/#D_$QS;H&F:5#_;2E@3D MP?S"X8G^#(=S%_R%\8V_,@X#Y$\O>\@E%A3VG31JP\WG/\KK\L*BEYB&A/2P MZCIP$,^)HIZG-&6+CYYM5SD#E6UXXKI"_(T<%P^+*X9^(S3&7^:%_@9%\^[D_<9> M-FDW"\3'<*'&@IJT:EUT(U0.(TZ GSZY[MV%!^/0MU<4@Z6029U#0W#3PX=# MV[%G7@^D5436C070E.,8;L4;X^'0D= M>BUL:# M)P "< :N'T? ':71E; Thu, 30 Nov 1995 15:25:10 +0200 Received: from septimius.mbfys.kun.nl by funet.fi with SMTP (PP); Thu, 30 Nov 1995 15:24:48 +0200 Received: from dontcare by septimius.mbfys.kun.nl via avitus.mbfys.kun.nl [131.174.82.110] with SMTP id OAA12227 (8.6.10/2.4); Thu, 30 Nov 1995 14:23:20 +0100 Date: Thu, 30 Nov 1995 14:23:20 +0100 From: Olaf Seibert Message-Id: <199511301323.OAA12227@septimius.mbfys.kun.nl> To: gnikl@informatik.uni-rostock.de, stieber@informatik.tu-muenchen.de Subject: Re: optimize bug with 2.7.0 Cc: amiga-gcc-port@nic.funet.fi, rhialto@mbfys.kun.nl Christian Stieber wrote: > > Nethertheless one question remains: Why does it make a difference > > to compile with or without "-fbaserel". If compiling without > > breaks "-fbaserel" should break too, shouldn't it? > > No. Declaring a variable without "volatile", and accessing it > from another task/interrupt/hardware/whatever yields undefined > behaviour. Undefined behaviour is roughly equivalent to buggy > programming, and the compiler doesn't have make sure that buggy > programs behave the same way with/without optimizer/fbaserel/debugging > etc. That's of course true, but it is likely there is a reasoning behind it. My guess is that because of the base-relative addressing, gcc knows that some indirection via a pointer is going on, and it makes less assumptions about the values being used that way. This is because any access through a pointer may modify any other variable (in general). This is the aliasing problem. Gcc would normally be aware of this if you explictly wrote code using pointers. This of course leads to the question: does -fbaserel lead to less optimized code in general? If that turns out to be true, and it is due to potential aliasing that gcc takes into account, can the implementation be changed in such a way that gcc does not take into account the aliasing problem that is created by indirecting through the base register? I would suppose the aliasing is merely an academic problem in this case. -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Thu Nov 30 17:16:02 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <90803-3>; Thu, 30 Nov 1995 16:52:59 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id PAA01484 (8.7.2/7.5a-FAU);; Thu, 30 Nov 1995 15:52:27 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA13109; Thu, 30 Nov 1995 15:52:22 +0100 Date: Thu, 30 Nov 1995 15:52:22 +0100 From: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Message-Id: <9511301452.AA13109@pctc.chemie.uni-erlangen.de> To: Walter.Harms@arbi.informatik.uni-oldenburg.de Cc: amiga-gcc-port@lists.funet.fi In-Reply-To: (message from Walter Harms on Thu, 30 Nov 1995 00:32:30 +0100 (MET)) Subject: Re: gcc and mathlibraries Hello, I read your results and you compile command. Making math calculations you should link with math library, i.e. use -lm !! Bye Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Thu Nov 30 17:44:47 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90621-2>; Thu, 30 Nov 1995 17:40:50 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id PAA20546 for ; Thu, 30 Nov 1995 15:38:44 GMT From: Lars Hecking Message-Id: <199511301539.PAA11306@mostar.nmrc.ucc.ie> Subject: C program flow analyzer on Aminet To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Thu, 30 Nov 1995 15:39:45 +0000 (GMT) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 940 Folks, I have uploaded a new port of the 'calls' c program flow analyzer to Aminet. It should be in dev/c soon. Here's the readme: Short: Analyze flow of a C-program. New version Uploader: lhecking@nmrc.ucc.ie (Lars Hecking) Author: . Revs by ksb@j.cc.purdue.edu (Kevin Braunsdorf) and lhecking@nmrc.ucc.ie (Lars Hecking) Type: dev/c Note: this version needs ixemul.library v41.x+ Original README: see README and README.linux Changes: - cleaned up Makefile - added headers to shut up compiler warnings (main.c, scan.c) - fixed the keyword tables in scan.c - fixed pre-ANSI sprintf calls in main.c - all amiga-specific changes are ifdef'd - 68000 and 68020 versions included - human-readable man page included (calls.0) Why? The old Amiga port on aminet (dev/c/Calls.lha) is buggy and doesn't support the -D, -I and -U options. Suggestions, bugs, bottles of beer to Lars Hecking . From amiga-gcc-port-owner@nic.funet.fi Thu Nov 30 21:21:43 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89324-3>; Thu, 30 Nov 1995 21:20:30 +0200 Received: from info.forthnet.gr (info.forthnet.gr [139.91.1.17]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id TAA01318 for ; Thu, 30 Nov 1995 19:20:22 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: from acrogate.UUCP by info.forthnet.gr via FORTHnet with UUCP; id VAA12242 (8.6.12/FORTHNET-2.0); Thu, 30 Nov 1995 21:17:26 +0200 (EET DST) Organization: Received: by acrogate.ath.forthnet.gr (Smail3.1.28.1 #6) id m0tLF0n-000B0cC; Thu, 30 Nov 95 19:51 GMT Message-Id: Date: Thu, 30 Nov 95 19:51 GMT From: mpap@acrogate.ath.forthnet.gr (Manolis Pappas) To: amiga-gcc-port@nic.funet.fi Subject: Creating GCC libraries Hello! I would like to ask how I can convert Amiga standard object files to the Sun format that GCC accepts. I would like to know how I can create a GCC link library also. Thank you very much in advance. Regards, MSP From amiga-gcc-port-owner@nic.funet.fi Thu Nov 30 21:26:59 1995 Received: from lillep.gbar.dtu.dk ([130.225.87.179]) by nic.funet.fi with ESMTP id <89051-4> convert rfc822-to-8bit; Thu, 30 Nov 1995 21:26:34 +0200 Received: by lillep.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 30 Nov 1995 20:26:28 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: GCC 2.7.1 crashes, related to stack size Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I've found out that GCC 2.7.1 (snapshot 951106) crashes when the stack size is set to 4096 bytes. If I set it to 8192 bytes, not problems. I don't know what sort of magic goes on, but it isn't working. ixemul is version 41.4. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Nov 30 21:41:37 1995 Received: from legolas.mdh.se ([130.238.251.203]) by nic.funet.fi with ESMTP id <89092-2>; Thu, 30 Nov 1995 21:40:10 +0200 Received: (from frv95tjn@localhost) by legolas.mdh.se (8.7.1/8.7.1) id UAA17722; Thu, 30 Nov 1995 20:40:32 +0100 (MET) Date: Thu, 30 Nov 1995 20:40:31 +0100 (MET) From: Tommy Johansson X-Sender: frv95tjn@legolas.mdh.se To: Manolis Pappas cc: amiga-gcc-port@nic.funet.fi Subject: Re: Creating GCC libraries In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 30 Nov 1995, Manolis Pappas wrote: > Hello! > > I would like to ask how I can convert Amiga standard object files to the > Sun format that GCC accepts. I would like to know how I can create a GCC > link library also. use hunk2gcc To create a link library use: ar qc ranlib > > Thank you very much in advance. > > Regards, > MSP > Tommy Johansson From amiga-gcc-port-owner@nic.funet.fi Thu Nov 30 22:55:52 1995 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <89209-4>; Thu, 30 Nov 1995 22:54:04 +0200 Received: from tiny.lysator.liu.se (tiny.lysator.liu.se [130.236.253.10]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id VAA24509; Thu, 30 Nov 1995 21:53:56 +0100 Received: (nisse@localhost) by tiny.lysator.liu.se (8.6.11/8.6.11) id VAA00790; Thu, 30 Nov 1995 21:53:51 +0100 Date: Thu, 30 Nov 1995 21:53:51 +0100 Message-Id: <199511302053.VAA00790@tiny.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: Olaf Seibert Cc: amiga-gcc-port@nic.funet.fi In-reply-to: Olaf Seibert's message of Thu, 30 Nov 1995 14:23:20 +0100 Subject: Re: optimize bug with 2.7.0 References: <199511301323.OAA12227@septimius.mbfys.kun.nl> Olaf Seibert writes: > Christian Stieber wrote: > > > Nethertheless one question remains: Why does it make a difference > > > to compile with or without "-fbaserel". If compiling without > > > breaks "-fbaserel" should break too, shouldn't it? > > > > No. Declaring a variable without "volatile", and accessing it > > from another task/interrupt/hardware/whatever yields undefined > > behaviour. Undefined behaviour is roughly equivalent to buggy > > That's of course true, but it is likely there is a reasoning behind > it. My guess is that because of the base-relative addressing, gcc > knows that some indirection via a pointer is going on, and it makes > less assumptions about the values being used that way. This is because > any access through a pointer may modify any other variable (in > general). This is the aliasing problem. Gcc would normally be aware of > this if you explictly wrote code using pointers. I don't think so. That the program can modify a variable through a pointer, in unintuitive ways, is something that the compiler normally can handle. This has nothing at all to do with volatile; volatile is used to give the compiler some help in the case that a variable can be modified by some *other* program, by another task, interrupt handler or by the operating system. I can't see any interesting conclusion that can be drawn from the fact that the bug didn't show up when compiling with baserel. I have no idea *why* this is the case, though. > This of course leads to the question: does -fbaserel lead to less > optimized code in general? If that turns out to be true, and it is due I'd guess that a programs compiled with baserel (assuming that its data segment is smaller than 64k) is in general both smaller and faster than the same program compiled without baserel. But this may vary from program to program, as the effect of baserel is to trade one register in order to get faster access to the datasegment. Regards, Niels From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 02:20:34 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <90736-4>; Fri, 1 Dec 1995 02:04:51 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Fri, 1 Dec 95 01:04 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Thu, 30 Nov 95 21:15 MET Message-Id: Subject: Re: gcc and mathlibraries To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Thu, 30 Nov 1995 21:15:00 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1516 > > Hi Walter... > > > you may notice some quit interessting results. i compiled > > with no special option yust > > gcc prg.c -o prg. the sas code whas provided by como. > > Compiling without options will use ixemul. As far as I know the fpu code of > ixemul is broken... This should be fixed in 41.4, or was it 42.0?!? he seems to be a gerneral confusion about hwtas going on. the problem is NOT cause by wrong math on ANY side. the problem is NOT a missing lib or something like that. the whole case is about using the libraries provided by C=. the single precission libraries and the ffp assumes that the value comes in one register (e.g. D0) using 32bit gcc GCC expands ANY float to double now using 64bit (look at the assem output) that causes wrong results even when you use inline/ or so. the nasty thing about that is that a beginner has no change so see whats going on because there are no warnings/errors. i dont know any prg that is using this math funktions but in the gcc distribution the inlines for mathffp/sp should be deleted and/or replaced with something like that. inline.h: #error you are using a FFP function that is not supported gcc #error the use of this function will cause wrong results maybe there are way to make them work but we should simply drop the support where is no need anywhere this times. walter > > Could you please send me the source, I`d like to compile it, too. > no problem -- ----- "Don't listen to me; I never do." ----- From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 07:24:55 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <90325-2>; Fri, 1 Dec 1995 07:24:07 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id AAA20309; Fri, 1 Dec 1995 00:23:55 -0500 (from cz253) Message-Id: <199512010523.AAA20309@kanga.INS.CWRU.Edu> Date: Fri, 1 Dec 1995 00:23:55 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: Dumb question... Cc: cz253@cleveland.freenet.edu Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) I seem to be missing something here. Please, some kind soul, point me in the right direction. What's wrong, this is a sample of the problem: ---dummy.c begin--- #include void dummy (void) { int i=PATH_MAX; } ---dummy.c end--- This is what I get when I go to compile: 5.Ram Disk:> gcc -c dummy.c dummy.c: In function `dummy': dummy.c:6: `PATH_MAX' undeclared (first use this function) dummy.c:6: (Each undeclared identifier is reported only once dummy.c:6: for each function it appears in.) Change dummy.c ---dummy.c begin--- #include #define PATH_MAX 1024 void dummy (void) { int i=PATH_MAX; } ---dummy.c end--- Now the dummy program compiles fine. Why isn't the compiler finding 'PATH_MAX' defined in , which should be called from , in the first case? .....Dave From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 09:10:29 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90677-2>; Fri, 1 Dec 1995 09:09:07 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tLQ3z-000RYyC; Fri, 1 Dec 95 08:39 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0ciq@wyst.hobby.nl>; Thu, 30 Nov 95 23:18:47 CET Message-Id: <9511302218.0ciq@wyst.hobby.nl> Date: Thu, 30 Nov 1995 23:18:43 +0000 (CET) In-Reply-To: from "Rask Lambertsen" at Nov 30, 95 08:26:28 pm Content-Type: text Content-Length: 1186 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi, fleischr@IZFM.Uni-Stuttgart.DE Subject: Re: GCC 2.7.1 crashes, related to stack size Hi, > I've found out that GCC 2.7.1 (snapshot 951106) crashes when the stack > size is set to 4096 bytes. If I set it to 8192 bytes, not problems. I > don't know what sort of magic goes on, but it isn't working. ixemul is > version 41.4. In version 42.0 any process launched from a ixemul-using program (either through vfork() or system()) will use a minimum stack of 16K. I guess that ixemul is a cause of the problems. Ixemul also uses stack space, but it does *not* use stack-extension. So this can apparently exceed the stack space limit. A question for Matthias: how much stack can the library safely use when called from a program compiled with your stack-handling code? As I said, ixemul cannot extend the stack, so the free stack space must be sufficiently large whenever an ixemul function is called. I can imagine that your code causes problems in this respect. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 11:33:34 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <88985-4>; Fri, 1 Dec 1995 11:31:59 +0200 Received: by colombo.telesys-innov.fr; Fri, 1 Dec 1995 10:31:22 GMT From: Philippe BRAND Message-Id: <199512011031.KAA22783@colombo.telesys-innov.fr> Subject: Re: Dumb question... To: cz253@cleveland.Freenet.Edu Date: Fri, 1 Dec 1995 10:31:21 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199512010523.AAA20309@kanga.INS.CWRU.Edu> from "David Zaroski" at Dec 1, 95 00:23:55 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit David Zaroski writes: > I seem to be missing something here. Please, some kind soul, point me in > the right direction. What's wrong, this is a sample of the problem: > > ---dummy.c begin--- > > #include Remove limits.h you probably have in gnu:os-include I've tested it here and it works ok. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 16:03:35 1995 Received: by nic.funet.fi id <89662-3>; Fri, 1 Dec 1995 16:00:08 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <95Dec1.160008+0200_eet.89662-3+97@nic.funet.fi> Date: Fri, 1 Dec 1995 16:00:03 +0200 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 17:39:58 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89141-1>; Fri, 1 Dec 1995 17:37:56 +0200 Received: from piglet.INS.CWRU.Edu (cz253@piglet.INS.CWRU.Edu [129.22.8.16]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id PAA16308 for ; Fri, 1 Dec 1995 15:37:20 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: (cz253@localhost) by piglet.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id KAA03816; Fri, 1 Dec 1995 10:35:46 -0500 (from cz253) Message-Id: <199512011535.KAA03816@piglet.INS.CWRU.Edu> Date: Fri, 1 Dec 1995 10:35:46 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: phb@colombo.telesys-innov.fr Subject: Re: Dumb question... Cc: amiga-gcc-port@nic.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from phb@colombo.telesys-innov.fr of Fri, 01 Dec > >David Zaroski writes: > >> I seem to be missing something here. Please, some kind soul, point me in >> the right direction. What's wrong, this is a sample of the problem: >> >> ---dummy.c begin--- >> >> #include > >Remove limits.h you probably have in gnu:os-include >I've tested it here and it works ok. I don't have a 'limits.h' in gnu:os-include, but I do have one in GNU:lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include/. Do you mean remove that one? The one thing I don't get is after looking at the first limits.h the compiler finds, it should be pulling in the limits.h of gnu:include. But from the results of the attempted compilation of dummy.c, it doesn't. [puzzled] .....Dave From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 18:08:10 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89399-2>; Fri, 1 Dec 1995 18:02:58 +0200 Received: from amigalib.com (actually host fishpond.amigalib.com) by funet.fi with SMTP (PP); Fri, 1 Dec 1995 17:59:46 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tLXof-0004ncC; Fri, 1 Dec 95 08:56 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Dumb question... To: cz253@cleveland.Freenet.Edu Date: Fri, 1 Dec 1995 08:56:01 -0700 (MST) Cc: phb@colombo.telesys-innov.fr, amiga-gcc-port@nic.funet.fi In-Reply-To: <199512011535.KAA03816@piglet.INS.CWRU.Edu> from "David Zaroski" at Dec 1, 95 10:35:46 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 205 > the compiler finds, it should be pulling in the limits.h of gnu:include. > But from the results of the attempted compilation of dummy.c, it doesn't. > [puzzled] What does "gcc -v -H ..." show? -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 19:31:36 1995 Received: from eeyore.INS.CWRU.Edu ([129.22.8.17]) by nic.funet.fi with ESMTP id <89686-4>; Fri, 1 Dec 1995 19:30:54 +0200 Received: (cz253@localhost) by eeyore.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id MAA13628; Fri, 1 Dec 1995 12:26:40 -0500 (from cz253) Message-Id: <199512011726.MAA13628@eeyore.INS.CWRU.Edu> Date: Fri, 1 Dec 1995 12:26:40 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: fnf@amigalib.com Subject: Re: Dumb question... Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from fnf@amigalib.com of Fri, 01 Dec > >> the compiler finds, it should be pulling in the limits.h of gnu:include. >> But from the results of the attempted compilation of dummy.c, it doesn't. >> [puzzled] > >What does "gcc -v -H ..." show? Thanks for the pointer, Fred. I'll have to add the '-H' to my flags when having a problem. I believe I have found the problem. Here's the output: 7.STAT-RAM:> gcc -v -H -c dummy.c Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/specs gcc version 2.7.0 /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu(m68k) -Amachine(m68k) -H -Dmc68010 dummy.c /t/cc317584.i GNU CPP version 2.7.0 (68k, MIT syntax) #include "..." search starts here: #include <...> search starts here: /gnu/local/include /gnu/mc68000-cbm-amigados/include /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include /gnu/os-include /gnu/include End of search list. /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include/limits.h ./gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include/syslimits.h ../gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include/limits.h .../gnu/include/limits.h ..../gnu/include/machine/limits.h ..../gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include/sys/syslimits.h The above line is the problem, the compiler is not aware that /gnu/include/sys/syslimits.h exists. So it never gets to, or recurses to, gnu/include/sys/syslimits.h! The fix is easy now. Change /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include/sys/syslimits.h from: #define _GCC_NEXT_LIMITS_H /* tell gcc's limits.h to recurse*/ #include_next #undef _GCC_NEXT_LIMITS_H (BTW, I don't understand why the #define and #undef of _GCC_NEXT_LIMITS_H is here, since limits.h don't use it.) to: #define _GCC_NEXT_LIMITS_H /* tell gcc's limits.h to recurse*/ #include_next #undef _GCC_NEXT_LIMITS_H After this change all is well. :-) Now I just hope nothing else blows up! Thanks again for pointing out the '-H' option to gcc. .....Dave From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 19:31:56 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89372-2> convert rfc822-to-8bit; Fri, 1 Dec 1995 19:25:08 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 1 Dec 1995 18:24:21 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Optimization questions Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, As I have thought about implementing some more optimizations in GCC, I have a few questions: 1) Is -O2 optimizing for smallest possible size, where -O3 may increase code size to gain speed? 2) Where can I find more information about the machine description file? gcc.guide doesn't really help me at all (can't figure out what an isn is). Is there any good examples anywhere? 3) Is anybody already working on this, like implementing some of the optimizations found in "http://www.nvg.unit.no/amiga/MC680x0_Sections/optimizations.HTML"? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 19:44:41 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89150-3>; Fri, 1 Dec 1995 19:43:20 +0200 Received: from crew.umich.edu (geneva.crew.umich.edu [141.211.184.10]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id RAA17371 for ; Fri, 1 Dec 1995 17:42:57 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: from basel.crew.umich.edu by crew.umich.edu (8.7.1/2.2) with ESMTP id MAA08520; Fri, 1 Dec 1995 12:33:41 -0500 (EST) Received: from localhost by basel.crew.umich.edu (8.7.1/dumb-1.0) id MAA04265; Fri, 1 Dec 1995 12:33:40 -0500 (EST) Message-Id: <199512011733.MAA04265@basel.crew.umich.edu> To: Jeff Shepherd , amiga-gcc-port@nic.funet.fi Subject: gethostby* unresolved in AmiTCP-sdk-gcc (inline problems?) In-reply-to: Your message of "Wed, 23 Aug 1995 10:57:28 EDT." Date: Fri, 01 Dec 1995 12:33:40 -0500 From: Charles Hymes I'm having problems linking some unix waisserver code that I've compiled. Certain bsdsocket calls are not resolved at final link time. I have not modified the source excepty to define "programname", as I belive the problem is with includes and libraries. However, is it the case that I have to include a stubs or inline header file? If so, should I replace one of the "standard" gcc header files with one of the inline header files? Or do i have to explicitly include the stubs or inline header in each source? What else could be the problem? If I'm way off, and there is some deeper problem, What are the actual modifications one typically has to make to UNIX TCP/IP source to get it to compile, link, and run with GCC, AmiTCP 4.1, AmiTCP-sdk-gcc? Charlweed From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 19:46:12 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89079-2>; Fri, 1 Dec 1995 19:45:47 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tLZTT-0004ncC; Fri, 1 Dec 95 10:42 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Dumb question... To: cz253@cleveland.Freenet.Edu Date: Fri, 1 Dec 1995 10:42:14 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@lists.funet.fi In-Reply-To: <199512011726.MAA13628@eeyore.INS.CWRU.Edu> from "David Zaroski" at Dec 1, 95 12:26:40 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 934 > The fix is easy now. Change > /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include/sys/syslimits.h from: > > > #define _GCC_NEXT_LIMITS_H /* tell gcc's limits.h to recurse*/ > #include_next > #undef _GCC_NEXT_LIMITS_H > > (BTW, I don't understand why the #define and #undef of _GCC_NEXT_LIMITS_H > is here, since limits.h don't use it.) > > to: > > #define _GCC_NEXT_LIMITS_H /* tell gcc's limits.h to recurse*/ > #include_next > #undef _GCC_NEXT_LIMITS_H > > After this change all is well. :-) Now I just hope nothing else blows up! The files in the gcc tree are automatically generated from files in gnu:include by "fixincludes" when gcc is built. Manually changing them is not a good idea, so we need to find another solution. I don't have time to look at this particular problem though, so perhaps Philippe or someone else can, if you give them a copy of all the included files. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 22:57:46 1995 Received: from nextsun.INS.CWRU.Edu ([129.22.8.51]) by nic.funet.fi with ESMTP id <89616-2>; Fri, 1 Dec 1995 22:56:07 +0200 Received: (cz253@localhost) by nextsun.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-freenet) id PAA26791; Fri, 1 Dec 1995 15:55:00 -0500 (from cz253) Message-Id: <199512012055.PAA26791@nextsun.INS.CWRU.Edu> Date: Fri, 1 Dec 1995 15:55:00 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: fnf@amigalib.com Subject: Re: Dumb question... Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from fnf@amigalib.com of Fri, 01 Dec > >> The fix is easy now. Change >> /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include/sys/syslimits.h from: >> >> >> #define _GCC_NEXT_LIMITS_H /* tell gcc's limits.h to recurse*/ >> #include_next >> #undef _GCC_NEXT_LIMITS_H >> >> (BTW, I don't understand why the #define and #undef of _GCC_NEXT_LIMITS_H >> is here, since limits.h don't use it.) >> >> to: >> >> #define _GCC_NEXT_LIMITS_H /* tell gcc's limits.h to recurse*/ >> #include_next >> #undef _GCC_NEXT_LIMITS_H >> >> After this change all is well. :-) Now I just hope nothing else blows up! > >The files in the gcc tree are automatically generated from files in >gnu:include by "fixincludes" when gcc is built. Manually changing Was not aware of that. >them is not a good idea, so we need to find another solution. I don't It solved this one problem. And according to the output via '-H', after the change was made, everything is getting loaded as it should. But, yes this should be taken care of generically. >have time to look at this particular problem though, so perhaps >Philippe or someone else can, if you give them a copy of all the >included files. Understood. Hopefully Philippe spotted this. .....Dave From amiga-gcc-port-owner@nic.funet.fi Fri Dec 1 23:17:26 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89731-1>; Fri, 1 Dec 1995 23:09:19 +0200 Received: from undergrad.math.uwaterloo.ca (actually user root@undergrad.math.uwaterloo.ca) by funet.fi with SMTP (PP); Fri, 1 Dec 1995 23:08:51 +0200 Received: from noether.math.uwaterloo.ca (root@noether.math.uwaterloo.ca [129.97.204.16]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id QAA11485 for ; Fri, 1 Dec 1995 16:08:41 -0500 Received: (jsshephe@localhost) by noether.math.uwaterloo.ca (8.6.12/8.6.12UW) id PAA12387; Fri, 1 Dec 1995 15:32:43 -0500 Date: Fri, 1 Dec 1995 15:32:40 -0500 (EST) From: Jeff Shepherd To: Amiga-Gcc List Subject: ixemul network support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In the next few weeks, there are some major changes in networking support in ixemul.library. Any developer or software maintainers that might be affected should contact myself for any details. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe If you think the problem is bad now, just wait until we've solved it. finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Sat Dec 2 03:30:22 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89559-2>; Sat, 2 Dec 1995 03:07:14 +0200 Received: by colombo.telesys-innov.fr; Sat, 2 Dec 1995 02:06:08 GMT From: Philippe BRAND Message-Id: <199512020206.CAA26035@colombo.telesys-innov.fr> Subject: Re: Dumb question... To: cz253@cleveland.Freenet.Edu Date: Sat, 2 Dec 1995 01:59:57 +0000 (WET) In-Reply-To: <199512011726.MAA13628@eeyore.INS.CWRU.Edu> from "David Zaroski" at Dec 1, 95 12:26:40 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: phb@colombo.telesys-innov.fr David Zaroski writes: > Thanks for the pointer, Fred. I'll have to add the '-H' to my flags when > having a problem. I believe I have found the problem. Here's the output: > > ./gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include/syslimits.h > ../gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include/limits.h > .../gnu/include/limits.h > ..../gnu/include/machine/limits.h > ..../gnu/lib/gcc-lib/mc68000-cbm-amigados/2.7.0/include/sys/syslimits.h Strange: here's my output: End of search list. /gnu/lib/gcc-lib/m68000-unknown-amigaos/2.7.1/include/limits.h /gnu/lib/gcc-lib/m68000-unknown-amigaos/2.7.1/include/syslimits.h /gnu/lib/gcc-lib/m68000-unknown-amigaos/2.7.1/include/limits.h /gnu/include/limits.h /gnu/include/machine/limits.h /gnu/include/sys/syslimits.h I don't have a ...amigados/2.7.0/include/sys/syslimits.h, neither on FredFish #10, and gcc-2.7.0 aminet distribution neither. Where did you pick it ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sat Dec 2 10:23:26 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89247-4>; Sat, 2 Dec 1995 10:22:35 +0200 Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id IAA25294 for ; Sat, 2 Dec 1995 08:22:30 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.6.12/8.6.4) with ESMTP id KAA10781; Sat, 2 Dec 1995 10:22:26 +0200 Received: (will@localhost) by katiska.clinet.fi (8.6.12/8.6.4) id KAA05021; Sat, 2 Dec 1995 10:22:30 +0200 Date: Sat, 2 Dec 1995 10:22:30 +0200 Message-Id: <199512020822.KAA05021@katiska.clinet.fi> From: Ville-Pertti Keinonen To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Rask Lambertsen on Fri, 1 Dec 1995 18:24:21 +0100 (MET)) Subject: Re: Optimization questions Date: Fri, 1 Dec 1995 18:24:21 +0100 (MET) From: Rask Lambertsen Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, As I have thought about implementing some more optimizations in GCC, I= =20 have a few questions: 1) Is -O2 optimizing for smallest possible size, where -O3 may increase=20 code size to gain speed? Hopefully, the original thought behind -O3 is something like "optimizations that don't need to be used". Any useful optimizations that don't slow down compilation too much should be implemented as parts of -O2, since for normal projects, that is probably the most commonly used. What kind of optimizations were you thinking of? As far as I can tell from the code gcc produces, cse.c still needs work. It seems that in some cases gcc unnecessarily moves values from one register to another, e.g.: movel d3,d0 addql #1,d0 movel d0,d3 andil #1023,d3 (The value of d0 is clobbered soon after this for all possible threads of execution) The code is generated from the expression v = (v + 1) & 1023. The problem is probably with gcc not looking at assignments deeply enough to see that all of the modification to the variable can be done "in place". 3) Is anybody already working on this, like implementing some of the optimizations found in "http://www.nvg.unit.no/amiga/MC680x0_Sections/optimizations.HTML"? Several of them are already done by gcc anyhow and a lot of them are not useful in a C-compiler. The clever moves for certain immediate values may make sense, though. From amiga-gcc-port-owner@nic.funet.fi Sat Dec 2 15:30:57 1995 Received: from erlang.gbar.dtu.dk ([130.225.87.177]) by nic.funet.fi with ESMTP id <89506-4> convert rfc822-to-8bit; Sat, 2 Dec 1995 15:26:33 +0200 Received: by erlang.gbar.dtu.dk (1.37.109.15/16.2) Date: Sat, 2 Dec 1995 14:25:53 +0100 (MET) From: Rask Lambertsen To: Ville-Pertti Keinonen Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Optimization questions In-Reply-To: <199512020822.KAA05021@katiska.clinet.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Sat, 2 Dec 1995, Ville-Pertti Keinonen wrote: > Date: Fri, 1 Dec 1995 18:24:21 +0100 (MET) > From: Rask Lambertsen > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=ISO-8859-1 > Content-Transfer-Encoding: QUOTED-PRINTABLE ^^^^^^^^^^^^^^^^ QUOTED-UNREADABLE > Hi, > > As I have thought about implementing some more optimizations in GCC, I= > =20 > have a few questions: > > 1) Is -O2 optimizing for smallest possible size, where -O3 may increase=20 > code size to gain speed? > > Hopefully, the original thought behind -O3 is something like > "optimizations that don't need to be used". Any useful optimizations ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I must be using a lot of those then, because I compile with -O3 whenever possible, to get the absolutely fastest code. > that don't slow down compilation too much should be implemented as > parts of -O2, since for normal projects, that is probably the most > commonly used. So what do I do if I have an optimization that increases code size, but gives faster code? Forget about them? > What kind of optimizations were you thinking of? For a start, I want strcpy() to compile to decent code instead of the crap that GCC currently produces: char *strcpy (char *d, const char *s) { char *dest = d; while (*d++ = *s++) ; return (dest); } which gives (from memory, my harddisk won't currently validate!): _strcpy: move.l 4(sp),a0 ; s move.l 8(sp),a1 ; d move.l a1,d0 loop: move.b (a0)+,d1 move.b d1,(a1)+ bne.b loop rts The loop should ofcourse be: loop: move.b (a0)+,(a1)+ bne.b loop The unnecessary crap disappears if strcpy() is rewritten a little bit to char *strcpy (char *d, const char *s) { char *dest = d; do while (*d++ = *s++); return (dest); } but the loop part is still the same (crap). I really wonder why GCC won't generate the "move.b (a0)+,(a1)+" instruction. It doesn't matter whether i compile with -O2 or -O3. > 3) Is anybody already working on this, like implementing some of the > optimizations found in > "http://www.nvg.unit.no/amiga/MC680x0_Sections/optimizations.HTML"? > > Several of them are already done by gcc anyhow and a lot of them are > not useful in a C-compiler. The clever moves for certain immediate > values may make sense, though. Those were amongst the first ones I want to implement, but I can't even figure out where the machine description file (m68k.md) needs to be changed. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Sat Dec 2 23:21:55 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <89364-2>; Sat, 2 Dec 1995 23:13:05 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id XAA00839 at Sat, 2 Dec 1995 23:12:19 +0200 Received: by softlab.ece.ntua.gr with UUCP id XAA24572 at Sat, 2 Dec 1995 23:12:22 +0200 (EET) Received: by kriton.UUCP (V1.17-beta/Amiga) id <097f@kriton.UUCP>; Sat, 2 Dec 95 15:54:35 EET Date: Sat, 2 Dec 95 15:54:35 EET Message-Id: <9512021354.097f@kriton.UUCP> In-Reply-To: (from fnf@amigalib.com (Fred Fish)) (at Mon, 27 Nov 1995 09:30:04 -0700 (MST)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: fnf@amigalib.com Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: Amiga GNU Tools Project List Hi Fred (Fred Fish), in on Nov 27 you wrote: > I'm currently using "ADE", for "Amiga Developers Environment", though > I'm not entirely thrilled about the acronym. It would be nice to have > something catchy. Any ideas? How about simply adding an "I" to this acronym, to convert it into something like "AIDE: Amiga Interactive Development Environment". -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "That's a bit of a mystery; no one's been able to decipher the carving." "It says `dig hole here'." ----- From amiga-gcc-port-owner@nic.funet.fi Sat Dec 2 23:39:26 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <89024-1>; Sat, 2 Dec 1995 23:38:38 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id XAA01176 at Sat, 2 Dec 1995 23:38:08 +0200 Received: by softlab.ece.ntua.gr with UUCP id XAA24902 at Sat, 2 Dec 1995 23:38:17 +0200 (EET) Received: by kriton.UUCP (V1.17-beta/Amiga) id <097t@kriton.UUCP>; Sat, 2 Dec 95 23:17:21 EET Date: Sat, 2 Dec 95 23:17:21 EET Message-Id: <9512022117.097t@kriton.UUCP> In-Reply-To: <199512020206.CAA26035@colombo.telesys-innov.fr> (from Philippe BRAND ) (at Sat, 2 Dec 1995 01:59:57 +0000 (WET)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!colombo.telesys-innov.fr!phb@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: Dumb question... Hi Philippe (Philippe BRAND), in <199512020206.CAA26035@colombo.telesys-innov.fr> on Dec 2 you wrote: > I don't have a ...amigados/2.7.0/include/sys/syslimits.h, neither on FredFish > #10, and gcc-2.7.0 aminet distribution neither. Where did you pick it ? Even stranger, I do have one, and it must have come from the aminet 2.7.0 distribution, as I had deleted my entire GNU: directory prior to installing 2.7.0. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Even in this corner of the galaxy, captain, two plus two equals four!" ----- From amiga-gcc-port-owner@nic.funet.fi Sun Dec 3 10:47:31 1995 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with SMTP id <90761-4>; Sun, 3 Dec 1995 10:46:21 +0200 Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.6.12/8.6.4) with ESMTP id KAA17701; Sun, 3 Dec 1995 10:46:09 +0200 Received: (will@localhost) by katiska.clinet.fi (8.6.12/8.6.4) id KAA17580; Sun, 3 Dec 1995 10:46:19 +0200 Date: Sun, 3 Dec 1995 10:46:19 +0200 Message-Id: <199512030846.KAA17580@katiska.clinet.fi> From: Ville-Pertti Keinonen To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Rask Lambertsen on Sat, 2 Dec 1995 14:25:53 +0100 (MET)) Subject: Re: Optimization questions > "optimizations that don't need to be used". Any useful optimizations ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I must be using a lot of those then, because I compile with -O3 whenever=20 possible, to get the absolutely fastest code. AFAIK the only difference between -O2 and -O3 is automatic function inlining. This is only useful for certain types of code, in most cases the marginal increase in speed is not worth it. On a source code for say a raytracer that has been written without consideration for inlining yet in the correct order to allow the compiler to inline efficiently, maybe... In any case, using the __inline keyword is much more flexible, because in many cases automatic inlining can: - inline selectively (because the function was called from several sources or before it was declared) - include the actual code even though all of the calls to it were inlined - inline unnecessarily (where the speed increase is not required) In addition to these, I think inlining can also prevent some code from functioning correctly (when the code is used to e.g. jump somewhere and keep the arguments on stack in order to forward them to something like a library call). I'm not sure, since I haven't tried, but depending on sp probably doesn't fix that. Using the __inline-keyword avoids all of these problems. So what do I do if I have an optimization that increases code size, but=20 gives faster code? Forget about them? An option for specifying a maximum tradeoff factor? which gives (from memory, my harddisk won't currently validate!): Ouch... I hope you have the space to fix it. _strcpy:=09move.l=094(sp),a0 ; s =09=09move.l=098(sp),a1 ; d =09=09move.l=09a1,d0 =09=09 loop:=09=09move.b=09(a0)+,d1 =09=09move.b=09d1,(a1)+ =09=09bne.b=09loop =09=09rts Mine is even worse: 00000000 <_strcpy> moveal sp@(8),a1 00000004 <_strcpy+4> movel sp@(4),d1 00000008 <_strcpy+8> moveb a1@+,d0 0000000a <_strcpy+a> moveal d1,a0 0000000c <_strcpy+c> bras 00000010 <_strcpy+10> 0000000e <_strcpy+e> moveb a1@+,d0 00000010 <_strcpy+10> moveb d0,a0@+ 00000012 <_strcpy+12> bnes 0000000e <_strcpy+e> 00000014 <_strcpy+14> movel d1,d0 00000016 <_strcpy+16> rts The "unnecessary crap" almost looks as if it was caused by the scheduling optimization pass. Some improvements would indeed be required here, including the swapping of d0/d1. Obviously register allocation doesn't take everything into account. The loop should ofcourse be: loop:=09=09move.b=09(a0)+,(a1)+ =09=09bne.b=09loop For some reason, I don't think I've ever seen strcpy() like this: _strcpy: movl sp@(8),a1 movl sp@(4),a0 movl a0,d0 1: movb a1@+,a0@+ jbne 1b rts It would be nice if that could be produced by some compiler. I really wonder why GCC won't generate the "move.b (a0)+,(a1)+" instruction= . It doesn't matter whether i compile with -O2 or -O3. The problem is either with combining instructions or with the machine description. Of course -O2 vs. -O3 are not different, even for plain -O the only difference is that the frame pointer is not omitted. Those were amongst the first ones I want to implement, but I can't even figure out where the machine description file (m68k.md) needs to be changed. Try the place where the moveq-optimization is done (search for movhi, you'll find the right place within that section). From amiga-gcc-port-owner@nic.funet.fi Sun Dec 3 19:49:29 1995 Received: from info.forthnet.gr ([139.91.1.17]) by nic.funet.fi with SMTP id <89023-2>; Sun, 3 Dec 1995 19:48:38 +0200 Received: from pythia by info.forthnet.gr via FORTHnet with ESMTP; id TAA24163 (8.6.12/FORTHNET-2.0); Sun, 3 Dec 1995 19:44:47 +0200 (EET DST) Received: from achilles.noc.ntua.gr by pythia (8.6.12/FORTHnet-2.0) id TAA11758; Sun, 3 Dec 1995 19:44:38 +0200 Organization: Received: by achilles.noc.ntua.gr via NTUAnet with SMTP id TAA26499 at Sun, 3 Dec 1995 19:46:48 +0200 Received: from paju.oulu.fi by oulu.fi (4.1/SMI-4.1) id AA04457; Sun, 3 Dec 95 19:46:51 +0200 Received: by paju.oulu.fi (950911.SGI.8.6.12.PATCH825/930416.SGI.AUTO) id TAA24855; Sun, 3 Dec 1995 19:45:38 +0200 Date: Sun, 3 Dec 1995 19:45:35 +0200 (EET) From: Petteri Heikkinen To: kyrimis@softlab.ece.ntua.gr Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi Subject: Re: Amiga GNU Tools Project List In-Reply-To: <9512021354.097f@kriton.UUCP> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 2 Dec 1995, Kriton Kyrimis wrote: > Hi Fred (Fred Fish), in on Nov 27 you wrote: > > > I'm currently using "ADE", for "Amiga Developers Environment", though > > I'm not entirely thrilled about the acronym. It would be nice to have > > something catchy. Any ideas? > > How about simply adding an "I" to this acronym, to convert it into something > like "AIDE: Amiga Interactive Development Environment". That would be a good name thought, but unfortunately it's allready in use. AIDE stands for: "ACE Ingetegrated Development Enviroment" and it's an GUI for ACE basic compiler by David Benn (D.Benn@appcomp.utas.edu.umd). Heikkinen ----------------------------------------------------------- Try When I read those lines to hold They felt so true and some faith familiar that I just couldn't in leave them where they were. the goodness - Petteri Heikkinen of humanity pheikkin@paju.oulu.fi ----------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Mon Dec 4 16:56:34 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89900-1>; Mon, 4 Dec 1995 16:28:12 +0200 Received: from hpcl.cti.gr by funet.fi with SMTP (PP); Mon, 4 Dec 1995 15:34:55 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA25914 (5.67a8/IDA-1.5 for ); Mon, 4 Dec 1995 15:26:47 +0200 From: Kriton Kyrimis Message-Id: <199512041326.AA25914@hpcl.cti.gr> Subject: Re: Dumb question... To: cz253@cleveland.freenet.edu Date: Mon, 4 Dec 1995 15:26:47 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi (gcc) In-Reply-To: <199512041319.IAA19765@kanga.INS.CWRU.Edu> from "David Zaroski" at Dec 4, 95 08:19:05 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 527 > One of them wouldn't of been the Amitcp library for gcc, would it? That is > the only other distrib I put over my 2.7.0 gnu tree. No, I haven't installed it. Packages that come off the top of my head are: g++, tar, flex and bison. (I don't think I did a make install for the last two, though.) -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "There is an art to flying, or rather a knack. The knack lies in learning how to throw yourself at the ground and miss." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Dec 4 16:56:47 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89312-4>; Mon, 4 Dec 1995 16:27:10 +0200 Received: from hpcl.cti.gr by funet.fi with SMTP (PP); Mon, 4 Dec 1995 15:16:52 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA25864 (5.67a8/IDA-1.5 for ); Mon, 4 Dec 1995 15:14:26 +0200 From: Kriton Kyrimis Message-Id: <199512041314.AA25864@hpcl.cti.gr> Subject: Re: Dumb question... To: cz253@cleveland.freenet.edu Date: Mon, 4 Dec 1995 15:14:25 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi (gcc) In-Reply-To: <199512041257.HAA11927@kanga.INS.CWRU.Edu> from "David Zaroski" at Dec 4, 95 07:57:44 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 528 > I didn't come from the 2.7.0 distrib, at least not the full one I have > here. Did a complete listing on all the archives and the only version of > sys/syslimits.h is in the gnu/include tree, where it should be. Did make > any other installs over 2.7.0? Yes. I wonder which one was the culprit. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "There is an art to flying, or rather a knack. The knack lies in learning how to throw yourself at the ground and miss." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Dec 4 19:46:33 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89720-2>; Mon, 4 Dec 1995 19:15:52 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tMezn-000R3FC; Mon, 4 Dec 95 18:48 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0d02@wyst.hobby.nl>; Mon, 4 Dec 95 18:08:04 CET Message-Id: <9512041708.0d02@wyst.hobby.nl> Date: Mon, 4 Dec 1995 18:08:02 +0000 (CET) Content-Type: text Content-Length: 970 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi Subject: Illegal instruction bug... Hi, I'd like to know if anyone ever experienced the following bug: an application terminates and suddenly you get an endless output of 'Illegal instruction'. The only way to stop this is by resetting the computer. I've never been able to reproduce this. It happens suddenly. Often days pass without problem and then it hits again. It's most often while compiling, but I've also seen this with 'groff' during a formatting action. As far as I can see it happens after a longjmp, probably somewhere in the exit() function. Either the longjmp jumps into nothing or the stack has been clobbered. I'm almost positive that I've seen this starting from ixemul-41.4. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Mon Dec 4 20:33:03 1995 Received: from legolas.mdh.se ([130.238.251.203]) by nic.funet.fi with ESMTP id <89253-3>; Mon, 4 Dec 1995 20:05:46 +0200 Received: (from frv95tjn@localhost) by legolas.mdh.se (8.7.1/8.7.1) id TAA24654; Mon, 4 Dec 1995 19:05:48 +0100 (MET) Date: Mon, 4 Dec 1995 19:05:47 +0100 (MET) From: Tommy Johansson X-Sender: frv95tjn@legolas.mdh.se To: Hans Verkuil cc: amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi Subject: Re: Illegal instruction bug... In-Reply-To: <9512041708.0d02@wyst.hobby.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 4 Dec 1995, Hans Verkuil wrote: > Hi, > > I'd like to know if anyone ever experienced the following bug: an > application terminates and suddenly you get an endless output of 'Illegal > instruction'. The only way to stop this is by resetting the computer. > > I've never been able to reproduce this. It happens suddenly. Often days > pass without problem and then it hits again. It's most often while > compiling, but I've also seen this with 'groff' during a formatting action. > As far as I can see it happens after a longjmp, probably somewhere in the > exit() function. Either the longjmp jumps into nothing or the stack has > been clobbered. I'm almost positive that I've seen this starting from > ixemul-41.4. > hmmm I think I have seen it before 41.4...... Have you checked the stacksize? > Hans > > -- > Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, > The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl > > "...and the princesses were beautiful as the day is long and so noble they > could pee through a dozen mattresses --" (Terry Pratchett) > Tommy Johansson From amiga-gcc-port-owner@nic.funet.fi Tue Dec 5 00:05:58 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <88928-2>; Mon, 4 Dec 1995 23:43:51 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <27467-1>; Mon, 4 Dec 1995 17:55:42 +0100 Received: from hphalle6d.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395789-2>; Mon, 4 Dec 1995 17:55:33 +0100 Subject: Re: Optimization questions To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Mon, 4 Dec 1995 17:53:47 +0100 (MEZ) In-Reply-To: from "Rask Lambertsen" at Dec 2, 95 02:25:53 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1195 From: stieber@informatik.tu-muenchen.de Message-Id: <95Dec4.175533+0100mesz.395789-2+593@hphalle0.informatik.tu-muenchen.de> > > that don't slow down compilation too much should be implemented as > > parts of -O2, since for normal projects, that is probably the most > > commonly used. Actually, as far as I remember gcc.info, -O invokes the optimizations that don't take "much" time, while -O2 invokes many more optimizations that often take quite some time. > So what do I do if I have an optimization that increases code size, but > gives faster code? Forget about them? Don't know. I _think_ GNU-C optimizes for speed, not for size (as the primary goal, of course). It would be nice to have -foptimize-speed and -foptimize-size options to select the primary goal, since I generally prefer size over speed for most applications. > I really wonder why GCC won't generate the "move.b (a0)+,(a1)+" instruction. :) > It doesn't matter whether i compile with -O2 or -O3. Does that affect code generation at all? I always though -Ox is for the RTL level? Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Tue Dec 5 00:09:00 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89333-1>; Tue, 5 Dec 1995 00:08:11 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tMjPq-000R3FC; Mon, 4 Dec 95 23:31 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0d1v@wyst.hobby.nl>; Mon, 4 Dec 95 20:03:47 CET Message-Id: <9512041903.0d1v@wyst.hobby.nl> Date: Mon, 4 Dec 1995 20:03:44 +0000 (CET) In-Reply-To: from "Tommy Johansson" at Dec 4, 95 07:05:47 pm Content-Type: text Content-Length: 524 From: hans@wyst.hobby.nl (Hans Verkuil) To: frv95tjn@mds.mdh.se Cc: amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi Subject: Re: Illegal instruction bug... According to Tommy Johansson: > hmmm I think I have seen it before 41.4...... Have you checked the stacksize? It's certainly NOT the stack. I always use a stack of 250000, which is sufficient for almost everything. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Dec 5 03:46:33 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89069-2>; Tue, 5 Dec 1995 03:28:00 +0200 Received: from undergrad.math.uwaterloo.ca (root@undergrad.math.uwaterloo.ca [129.97.204.13]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id BAA26652 for ; Tue, 5 Dec 1995 01:27:37 GMT Content-Transfer-Encoding: 8bit Received: from cnts3p26.uwaterloo.ca (jsshephe@cnts3p26.uwaterloo.ca [129.97.130.26]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with SMTP id UAA14428 for ; Mon, 4 Dec 1995 20:27:29 -0500 Date: Mon, 4 Dec 1995 20:26:04 -0500 (EST) From: Jeff Shepherd X-Sender: jsshephe@cnts3p26.uwaterloo.ca To: Amiga-Gcc List Subject: IN_Inherit autodoc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone have the autodoc for IN_inherit function (of AS225's inet.library). I need to find out how to call this function so I can inherit sockets from inetd. --- Sig blew up, time to get another--- jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe From amiga-gcc-port-owner@nic.funet.fi Tue Dec 5 10:13:14 1995 Received: from dfunms.rus.uni-stuttgart.de ([129.69.1.162]) by nic.funet.fi with SMTP id <88943-4>; Tue, 5 Dec 1995 09:57:21 +0200 Received: from ifr1.luftfahrt.uni-stuttgart.de by dfunms.rus.uni-stuttgart.de with SMTP id AA28423 (5.65c8/DFUE-M1.0 for ); Tue, 5 Dec 1995 08:56:44 +0100 Received: from ifr15 by ifr1.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-1.0NeXT+) id AA06352; Tue, 5 Dec 95 08:56:42 +0100 Message-Id: <9512050756.AA06352@ifr1.Luftfahrt.Uni-Stuttgart.DE> Received: by ifr15.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-S1.0NeXT+) id AA00573; Tue, 5 Dec 95 08:56:41 +0100 Date: Tue, 5 Dec 95 08:56:41 +0100 From: raimund@ifr.luftfahrt.uni-stuttgart.de Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: amiga-gcc-port@nic.funet.fi Subject: Which format for man pages? Hi, I luckily compiled psutils with gcc2.7.0. Everything is okay but the man pages. If I read a man page I get it as plain ascii with all the controlling code. Is there a possibility to process the man pages to read them as normal man pages with more, less or anything else? Thanks Raimund From amiga-gcc-port-owner@nic.funet.fi Tue Dec 5 10:26:05 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <88943-4>; Tue, 5 Dec 1995 10:25:26 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HYFZ5OGD4W001EAN@NET2.WAU.NL>; Tue, 05 Dec 1995 09:29:53 +0000 (GMT) Received: by vines2.wau.nl; Tue, 5 Dec 95 9:25:09 +0100 Date: Tue, 05 Dec 1995 09:16:52 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: re: Which format for man pages? To: raimund@ifr.luftfahrt.uni-stuttgart.de Cc: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi Raimund, >I luckily compiled psutils with gcc2.7.0. Everything is okay but the >man pages. If I read a man page I get it as plain ascii with all the >controlling code. Is there a possibility to process the man pages to >read them as normal man pages with more, less or anything else? I have compiled those too as part of my Postscript project. I'm making a compilation off all kinds of postscript utilities to enhance the forthcoming release of Ghostscript351 for the Amiga. To make readable text out of the *.1 files you'll need an installed copy of 'groff' (FredFish10 CDROM). Further I have made a small shell script which takes two parameters (inputfile, outputfile) and I have added a rule to the make file to automatically make the docs. I also have finished the configure script for this package so if you want to distribute your version then please contact me before doing more work on it. It will keep you from doing duplicate work :) I'll post a list of programs that I'm working on tomorrow to make sure that the amount of duplicate work being done is kept to a minimum. Sorry I should have that sooner. Joop From amiga-gcc-port-owner@nic.funet.fi Tue Dec 5 13:08:25 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89731-4>; Tue, 5 Dec 1995 12:37:46 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA20198; Tue, 5 Dec 1995 11:37:59 +0100 Date: Tue, 5 Dec 1995 11:37:58 +0100 (MET) From: Kamil Iskra Subject: Re: gcc and mathlibraries To: Walter Harms cc: amiga gcc-list In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 30 Nov 1995, Walter Harms wrote: > i dont know any prg that is using this math funktions but > in the gcc distribution the inlines for mathffp/sp should > be deleted and/or replaced with something like that. > > inline.h: > > #error you are using a FFP function that is not supported gcc > #error the use of this function will cause wrong results I'll have a look at it. Most probably inlines for these libraries simply won't be distributed. > > Could you please send me the source, I`d like to compile it, too. > > > no problem Please send it to me, too. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Tue Dec 5 17:03:15 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <88986-4>; Tue, 5 Dec 1995 16:33:15 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA00734 (5.65c8/IDA-1.4.4 for ); Tue, 5 Dec 1995 15:31:53 +0100 Received: by diva.gmd.de with UUCP id AA00369 (5.67b8/IDA-1.5); Tue, 5 Dec 1995 15:28:16 +0100 Date: Tue, 5 Dec 1995 15:28:16 +0100 Message-Id: <199512051428.AA00369@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: raimund@ifr.luftfahrt.uni-stuttgart.de Cc: amiga-gcc-port@nic.funet.fi Subject: Which format for man pages? In-Reply-To: <9512050756.AA06352@ifr1.Luftfahrt.Uni-Stuttgart.DE> References: <9512050756.AA06352@ifr1.Luftfahrt.Uni-Stuttgart.DE> Hi, raimund@ifr.luftfahrt.uni-stuttgart.de writes: > man pages. If I read a man page I get it as plain ascii with all the > controlling code. Is there a possibility to process the man pages to > read them as normal man pages with more, less or anything else? I'm using Less-1.6Z daily (works with pipes, opens own window or uses CLI one etc.) and also tested the Man datatype. Both interpret the control and backspace sequences and display bold fonts. But I don't know what people use to convert the pages to ANSI. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Tue Dec 5 18:29:47 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <89358-3> convert rfc822-to-8bit; Tue, 5 Dec 1995 17:59:22 +0200 Received: by tycho.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 5 Dec 1995 16:58:37 +0100 (MET) From: Rask Lambertsen To: raimund@ifr.luftfahrt.uni-stuttgart.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Which format for man pages? In-Reply-To: <9512050756.AA06352@ifr1.Luftfahrt.Uni-Stuttgart.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 5 Dec 1995 raimund@ifr.luftfahrt.uni-stuttgart.de wrote: > I luckily compiled psutils with gcc2.7.0. Everything is okay but the > man pages. If I read a man page I get it as plain ascii with all the > controlling code. Is there a possibility to process the man pages to > read them as normal man pages with more, less or anything else? Get manfilt from Aminet manfilt12.lha text/misc 17K+unix man page filter (fileters out the code totally) manfilt_v1.1.lha text/misc 7K+Strip or convert nroff tty sequences to A (converts control codes to ANSI codes) I personally use the last one with more, which works fine. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Dec 5 18:31:57 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89254-4>; Tue, 5 Dec 1995 18:04:17 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26495-1>; Tue, 5 Dec 1995 17:02:54 +0100 Received: from hphalle8j.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395792-1>; Tue, 5 Dec 1995 17:02:37 +0100 Subject: Re: gcc and mathlibraries From: Christian Stieber To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Tue, 5 Dec 1995 17:02:29 +0100 (MEZ) Cc: Walter.Harms@arbi.informatik.uni-oldenburg.de, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Dec 5, 95 11:37:58 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 934 Message-Id: <95Dec5.170237+0100mesz.395792-1+1558@hphalle0.informatik.tu-muenchen.de> > > inline.h: > > > > #error you are using a FFP function that is not supported gcc > > #error the use of this function will cause wrong results > > I'll have a look at it. Most probably inlines for these libraries simply > won't be distributed. I think I like the suggest #error approach better. The reason: if the inlines are simply left out, people will start asking for them 'cause they think they were left out by accident. Having dummy inlines that simply output an error message tells them why they aren't there, so they won't be looking for the inlines (although they might start asking questions like "why isn't it supported, and when will it be supported"). Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Wed Dec 6 06:14:16 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <88983-2>; Wed, 6 Dec 1995 06:00:30 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 6 Dec 95 01:34 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 6 Dec 95 01:29 MET Message-Id: Subject: libraries again To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 6 Dec 1995 01:29:36 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 482 i have still problems with the libraries, the system simply dont see it doesnt try to open and i cant find why the romtag is right at the begining of the lib just after the moveq #-1,d0;rts according to the manual this should work. but it dont. i can see that open/init is never called. i found that some datas are moved to the end of the lib could that be a problem ? walter -- ----- "Just because I can work miracles, don't assume I can do everything." ----- From amiga-gcc-port-owner@nic.funet.fi Wed Dec 6 15:43:33 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <89603-2> convert rfc822-to-8bit; Wed, 6 Dec 1995 15:40:17 +0200 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 6 Dec 1995 11:25:43 +0100 (MET) From: Rask Lambertsen To: Walter Harms Cc: amiga gcc-list Subject: Re: libraries again In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 6 Dec 1995, Walter Harms wrote: > i have still problems with the libraries, > the system simply dont see it doesnt try to > open and i cant find why the romtag is right > at the begining of the lib just after the > moveq #-1,d0;rts according to the manual this > should work. but it dont. > i can see that open/init is never called. > i found that some datas are moved to the end > of the lib could that be a problem ? I'd like to see the source. If it is too long to post, mail it to me. I have succesfully manages to make a device driver recognized (though not with GCC) and working. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Dec 6 16:06:53 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <89089-2>; Wed, 6 Dec 1995 16:03:40 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HYHHS49VWG00236O@NET2.WAU.NL>; Wed, 06 Dec 1995 11:34:09 +0000 (GMT) Received: by vines2.wau.nl; Wed, 6 Dec 95 11:29:10 +0100 Date: Wed, 06 Dec 1995 10:53:45 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: Projects summary To: amiga-gcc-port@lists.funet.fi Illegal-Object: Syntax error in Message-id: value found on nic.funet.fi: Message-id: ; Wed, 6 Dec 1995 15:53:17 +0200 Received: from alfa.ist.utl.pt by funet.fi with SMTP (PP); Wed, 6 Dec 1995 14:45:30 +0200 Received: (from l36599@localhost) by alfa.ist.utl.pt (8.7.1/8.7.1) id NAA13047; Wed, 6 Dec 1995 13:42:17 GMT Date: Wed, 6 Dec 1995 13:42:17 +0000 (GMT) From: Pedro Miguel Sequeira Teixeira To: Jeff Shepherd cc: Amiga-Gcc List Subject: ixemul42 location and network test In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 1 Dec 1995, Jeff Shepherd wrote: > In the next few weeks, there are some major changes in networking support > in ixemul.library. Any developer or software maintainers that might be > affected should contact myself for any details. Shure, as usual I will beta-test the new ixemul with all the X11 artilary... if only I could find it ! WHERE THE HELL IS IXEMUL 42.0 pack ???? (library + libc.a) i've looked all over bud did not find it (telesys, funnet, wustl, amigalib) nothing! Can anyone help me with a location description? - Pedro Teixeira - From amiga-gcc-port-owner@nic.funet.fi Wed Dec 6 16:10:31 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <89209-4>; Wed, 6 Dec 1995 16:08:12 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id PAA07046 (8.7.2/7.5a-FAU); for ; Wed, 6 Dec 1995 15:07:54 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA26832; Wed, 6 Dec 1995 15:07:53 +0100 Date: Wed, 6 Dec 1995 15:07:53 +0100 Message-Id: <9512061407.AA26832@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: amiga-gcc-port@nic.funet.fi Subject: problem with configure and config.cache Hello ! I have a problem while using configure . If I call configure, i.e. from the package m4-1.4.tar.gz, from sh it checks some system dependancies and writes some of the into a file called config.cache . But the contents of the file config.cache is wrong ! For example it contains (only from mind, so not a valid name ) ac_limits_h=$ac_limits_h='yes' but it should be ac_limits_h='yes' Has anybody seen a similar behavior ? PS: The configure script was rebuilt with autoconf, but I think that does not matter. Used software: amiga gcc 2.7.0 Shell: sh with a stack of 96000 environment variable GCCSTACK: 300000 Hardware: amiga 2000 with 68030 and fpu, 6MB fastram, 1MB chipram, 500MB+700MB HD Thanks -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Wed Dec 6 17:28:22 1995 Received: from nextsun.INS.CWRU.Edu ([129.22.8.51]) by nic.funet.fi with ESMTP id <89664-1>; Wed, 6 Dec 1995 17:25:20 +0200 Received: (cz253@localhost) by nextsun.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-freenet) id KAA10036; Wed, 6 Dec 1995 10:24:16 -0500 (from cz253) Message-Id: <199512061524.KAA10036@nextsun.INS.CWRU.Edu> Date: Wed, 6 Dec 1995 10:24:16 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: l36599@alfa.ist.utl.pt Subject: Re: ixemul42 location and network test Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from l36599@alfa.ist.utl.pt of Wed, 06 Dec > > WHERE THE HELL IS IXEMUL 42.0 pack ???? (library + libc.a) >i've looked all over bud did not find it (telesys, funnet, wustl, >amigalib) nothing! Can anyone help me with a location description? You can't find it because it has not yet been publicly released. From amiga-gcc-port-owner@nic.funet.fi Wed Dec 6 18:21:51 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89587-1>; Wed, 6 Dec 1995 18:17:57 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 6 Dec 95 17:17 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 6 Dec 95 17:09 MET Message-Id: Subject: probleme ?! mit baserel To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 6 Dec 1995 17:09:30 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 767 whats going on ? gcc -DLIBNAME=helloworld.library -DLIBVERSION=40 -DLIBREVISION=1 -Iinclude -save-temps -O -databss-together -fbaserel -c LibHeader.c gcc -o libs/HelloWorld.library -nostdlib LibHeader.o \ HelloWorldLib.o -ldebug ld: Reloc is base relative. Specify -databss-together in LibHeader.o make: *** [libs/HelloWorld.library] Error 1 btw: how i can get rid of the link commando at the begin/end of eatch sub() ? Rask: its now clear why the lib is not found the macro #define S(x) #x dont work it has to be replaced with #define _S(x) #x /* mlelstv found this */ #define S(x) _S(x) now you get realy nice crashes :) -- ----- "Doctor, the trembling has stopped!" "Oh, my dear! I'm so glad you 're feeling better!" "No, not me! The ship!" ----- From amiga-gcc-port-owner@nic.funet.fi Wed Dec 6 18:24:38 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89860-4>; Wed, 6 Dec 1995 18:06:32 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id QAA09440 for ; Wed, 6 Dec 1995 16:04:42 GMT From: Lars Hecking Received: (lhecking@localhost) by carlow.nmrc.ucc.ie (8.6.8.1/8.6.6) id QAA26610; Wed, 6 Dec 1995 16:04:37 GMT Date: Wed, 6 Dec 1995 16:04:37 GMT Message-Id: <199512061604.QAA26610@carlow.nmrc.ucc.ie> To: amiga-gcc-port@nic.funet.fi Subject: HELP with GCC (fwd) Has someone seen this behaviour before? I cannot seem to help Joel here. From private email I gather that gcc270 (aminet) is set up properly, and 11MB RAM should be plenty. ------- Start of forwarded message ------- From: NewKirk Subject: HELP with GCC Newsgroups: comp.sys.amiga.programmer Date: Mon, 4 DEC 95 00:12:38 -0500 Organization: Delphi (info@delphi.com email, 800-695-4005 voice) Path: nmrc!curia!ieunet!Germany.EU.net!EU.net!newsfeed.internetmci.com!news-feed.mci.newscorp.com!news.delphi.com!usenet Lines: 18 Message-ID: NNTP-Posting-Host: bos1b.delphi.com I'm trying to get GCC up and running on my A2000 030/882 11MB. with stack set to 1MB, the following occurs when I: cc -v optin.c I get : cpp -lang.c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 _Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__ -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 _D__amiga -D__amigados -D__MCH_AMIGA -D__AMIGA -Asystem(amigados) -Acpu (m68k) -Amachine(m68k) -Dmc68010 optin.c /t/cc736784.i then return to prompt with no compile. What am I doing wrong here? I've encountered endless problems with SAS/C with this program, and relly want to give GCC a try at it, but can't get it going. Please help. Please E-Mail response to 102627.1152@compuserver.com (checked several times daily) or mail to delphi address or post here (checked every other day or so) Thanks in advance. Joel NewKirk ------- End of forwarded message ------- -l From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 12:03:15 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <88947-2>; Thu, 7 Dec 1995 11:46:10 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tNdPt-000RX9C; Thu, 7 Dec 95 11:19 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0d9l@wyst.hobby.nl>; Thu, 7 Dec 95 10:42:12 CET Message-Id: <9512070942.0d9l@wyst.hobby.nl> Date: Thu, 7 Dec 1995 10:42:09 +0000 (CET) Content-Type: text Content-Length: 1708 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi, ixemul@listserv.funet.fi Subject: Announcement (also for the README :-) Hi everyone, I just want to announce that I'm now the `official' ixemul.library maintainer. Fred Fish remains the tester and the one who distributes ixemul.library and sources, but I'll be doing the enhancements, adding patches and fixing bugs. So please mail me any ideas or patches for enhancements and bug reports (and preferably bug fixes :-). Ixemul 42.0 is nearly ready, hopefully it will be released before the end of this year. The NEWS file contains 30 new items! (Lars, uname() has been added :-) I also want to point out that starting with 42.0 the ixemulbase structure (with exception of the Library node) may no longer be accessed. All other fields are now private! The same is true for the user-structure in user.h. Any program that currently accesses fields in one of these structures will fail. The only program that currently accesses these fields is ixconfig. This program will be replaced by ixprefs in 42.0 and a check has been added preventing the execution of a program called 'ixconfig'. However, all programs that use Jeff Shepherd's code to AmiTCP support will ALSO fail. As Jeff has pointed out recently he no longer supports this code. If you are currently using programs linked with his library, then you should wait until ixemul-43.0, and refrain from using 42.0. Beta testers for networking code should contact Jeff Shepherd (jsshephe@undergrad.math.uwaterloo.ca). Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 12:03:16 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89899-1>; Thu, 7 Dec 1995 11:45:51 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tNdPM-000RX8C; Thu, 7 Dec 95 11:18 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0d9g@wyst.hobby.nl>; Thu, 7 Dec 95 10:15:21 CET Message-Id: <9512070915.0d9g@wyst.hobby.nl> Date: Thu, 7 Dec 1995 10:15:19 +0000 (CET) Content-Type: text Content-Length: 1116 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Cc: ixemul@listserv.funet.fi Subject: Floating point handling (for the README) Hi everyone, There have been various reports on problems with floating point functions. In all cases an older ixemul.library was used (pre-41.4). As far as I could determine, all problems have disappeared starting with version 41.4. The ONLY floating point format not supported is FFP. It is also very unlikely that this will ever be supported (it requires changes to the library and major changes to gcc). In fact, I'm very opposed to adding a non-standard floating point format. I've worked with Macs, and they have a whole platoon of FP formats, to the lasting grief of programmers. I don't want a similar situation on the Amiga. Please add something like the lines above to the README (if it isn't already there). I will no longer examine FP bug reports *unless* they are tested with 41.4 or higher. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 13:13:49 1995 Received: from fillmore.univ-mlv.fr ([192.134.103.84]) by nic.funet.fi with SMTP id <89707-1>; Thu, 7 Dec 1995 13:12:56 +0200 Received: by fillmore.univ-mlv.fr (1.38.193.4/16.2) id AA14757; Thu, 7 Dec 1995 11:12:13 GMT From: zajac Subject: -m68881 To: amiga-gcc-port@nic.funet.fi Date: Thu, 7 Dec 1995 11:12:13 +0000 (WET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 4916 Message-Id: <95Dec7.131256+0200_eet.89707-1+56@nic.funet.fi> Hi, here is my problem : i can't use -m68881 option. I use gcc 2.7.0. I have an A1200 + MTEC 1230 + 8Mo + 68881 It seems that the problem appears when I use #include I didn't subscribe to this mailing list. so it would be great if you can answer me at zajac@univ.mlv.fr Mikael ZAJAC PS : here are the result of the command : g++ -m68881 Sphere.C sphere.c: In method `Sphere::Sphere(unsigned char, unsigned char, unsigned char)': sphere.c:22: warning: implicit declaration of function `int printf(...)' /t/cc422720.s: Assembler messages: /t/cc422720.s:22: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/68 882) -- statement `fmovem #0xc,sp@-' ignored /t/cc422720.s:59: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/68 882) -- statement `fmoved LC5,fp3' ignored /t/cc422720.s:60: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/68 882) -- statement `fsubd a5@(-40),fp3' ignored /t/cc422720.s:61: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/68 882) -- statement `fmoved fp3,a5@(-24)' ignored /t/cc422720.s:74: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/68 882) -- statement `fmoved sp@+,fp0' ignored /t/cc422720.s:75: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/68 882) -- statement `fmoves fp0,a5@(-60)' ignored /t/cc422720.s:100: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoved sp@+,fp2' ignored /t/cc422720.s:107: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoved sp@+,fp0' ignored /t/cc422720.s:108: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmovex fp2,fp1' ignored /t/cc422720.s:109: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmulx fp0,fp1' ignored /t/cc422720.s:110: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoves fp1,a5@(-68)' ignored /t/cc422720.s:117: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoved sp@+,fp2' ignored /t/cc422720.s:124: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoved sp@+,fp0' ignored /t/cc422720.s:125: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmovex fp2,fp1' ignored /t/cc422720.s:126: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmulx fp0,fp1' ignored /t/cc422720.s:127: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoves fp1,a5@(-64)' ignored /t/cc422720.s:134: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoved a5@(-16),fp3' ignored /t/cc422720.s:135: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `faddd a5@(-48),fp3' ignored /t/cc422720.s:136: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoved fp3,a5@(-16)' ignored /t/cc422720.s:142: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoved a5@(-24),fp3' ignored /t/cc422720.s:143: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fsubd a5@(-40),fp3' ignored /t/cc422720.s:144: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoved fp3,a5@(-24)' ignored /t/cc422720.s:453: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmovem a5@(-168),#0x30' ignored /t/cc422720.s:459: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoved a5@(8),fp0' ignored /t/cc422720.s:461: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fcosx fp0,fp1' ignored /t/cc422720.s:463: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoved fp1,a5@(-8)' ignored /t/cc422720.s:474: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoved a5@(8),fp0' ignored /t/cc422720.s:476: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fsinx fp0,fp1' ignored /t/cc422720.s:478: Error: invalid instruction for this architecture; needs fpu (68040, 68060 or 68881/6 8882) -- statement `fmoved fp1,a5@(-8)' ignored From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 13:52:25 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <89644-2>; Thu, 7 Dec 1995 13:49:21 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id MAA25289 (8.7.2/7.5a-FAU);; Thu, 7 Dec 1995 12:48:41 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA25166; Thu, 7 Dec 1995 12:48:40 +0100 Date: Thu, 7 Dec 1995 12:48:40 +0100 Message-Id: <9512071148.AA25166@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: hans@wyst.hobby.nl Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9512062010.0d83@wyst.hobby.nl> (hans@wyst.hobby.nl) Subject: Re: problem with configure and config.cache >>>>> "Hans" == Hans Verkuil writes: >> I have a problem while using configure . If I call configure, >> i.e. from the package m4-1.4.tar.gz, from sh it checks some >> system dependancies and writes some of the into a file called >> config.cache . But the contents of the file config.cache is >> wrong ! For example it contains (only from mind, so not a >> valid name ) ac_limits_h=$ac_limits_h='yes' but it should be >> ac_limits_h='yes' >> >> Has anybody seen a similar behavior ? Sorry ! I did a mistake in my bug report. The configure script does not write to much, it writes to less. A line in the config.cache file must look like: ac_limits_h=${ac_limits_h='yes'} Watch here ^ and ^ The {}-pair is missing. I verified it with a configure run on RS6000 running AIX. Hans> Yes, it is a bug in pdksh. Included below is the patch to Hans> pdksh/sh/eval.c. ... patch deleted ... Hans> -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Hans> Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, Hans> email: hans@wyst.hobby.nl Hans> "...and the princesses were beautiful as the day is long and Hans> so noble they could pee through a dozen mattresses --" Hans> (Terry Pratchett) Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 14:08:16 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <89168-4>; Thu, 7 Dec 1995 13:56:08 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id MAA25388 (8.7.2/7.5a-FAU);; Thu, 7 Dec 1995 12:55:31 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA25214; Thu, 7 Dec 1995 12:55:30 +0100 Date: Thu, 7 Dec 1995 12:55:30 +0100 Message-Id: <9512071155.AA25214@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: zajac@univ-mlv.fr Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <95Dec7.131256+0200_eet.89707-1+56@nic.funet.fi> (message from zajac on Thu, 7 Dec 1995 11:12:13 +0000 (WET)) Subject: Re: -m68881 >>>>> "zajac" == zajac writes: zajac> Hi, here is my problem : i can't use -m68881 option. I use zajac> gcc 2.7.0. I have an A1200 + MTEC 1230 + 8Mo + 68881 It zajac> seems that the problem appears when I use #include zajac> I didn't subscribe to this mailing list. so it would be zajac> great if you can answer me at zajac@univ.mlv.fr zajac> Mikael ZAJAC zajac> PS : here are the result of the command : zajac> g++ -m68881 Sphere.C Here you should try g++ -m68020 -m68881 Sphere.C -lm or g++ -m68030 -m68881 Sphere.C -lm ... error messages deleted ... Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 16:03:30 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <89011-1>; Thu, 7 Dec 1995 15:50:42 +0200 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 7 Dec 1995 14:48:52 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Questions for the README Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi everybody, A new README will be ready later today. However, I have a few questions: 1) Who is the current Installer script maintainer? I simply forgot the name (and e-mail address) of the maintainer, but someone recently took over from Jochen Wiedmann, I remember. 2) Is the list "amiga-gcc-info" used at all? I can't remember ever having received anything else than the monthly help posting. I was on that list for 3 months before joining "amiga-gcc-port" and never got anything else. 3) The README refers to the host "gnu.prep.ai.mit.edu" (for getting sources) which doesn't exist. My best guess is one of the machines "ftp.gnu.mit.edu" and "alpha.gnu.mit.edu". Which one is right? 4) Which directory name will be used for gcc (sub)compilers? mc68000-at-amigados? m68k-at-amigaos? m68k-unknown-amigaos? I know I've asked this before, but I don't think something was agreed upon. How about some kind of voting maybe? My personal favorite is m68k-at-amigaos, but I'll be happy with m68k-unknown-amigaos too. 5) How many of the supplied utilities will have automatic stack extension when GCC 2.7.1 is released? And last, is there a likely release date for GCC 2.7.1? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 16:20:41 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89196-1>; Thu, 7 Dec 1995 16:09:53 +0200 Received: from bastion.nmrc.ucc.ie (nmrc.ucc.ie [143.239.64.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id OAA07899 for ; Thu, 7 Dec 1995 14:08:54 GMT Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id OAA27549; Thu, 7 Dec 1995 14:07:05 GMT From: Lars Hecking Message-Id: <199512071408.OAA01693@mostar.nmrc.ucc.ie> Subject: Re: Questions for the README To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Thu, 7 Dec 1995 14:08:12 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Rask Lambertsen" at Dec 7, 95 02:48:52 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 310 > 3) The README refers to the host "gnu.prep.ai.mit.edu" (for getting > sources) which doesn't exist. My best guess is one of the machines > "ftp.gnu.mit.edu" and "alpha.gnu.mit.edu". Which one is right? prep.ai.mit.edu > And last, is there a likely release date for GCC 2.7.1? I hope not. -l From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 16:35:32 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <88989-3>; Thu, 7 Dec 1995 16:17:40 +0200 Received: by colombo.telesys-innov.fr; Thu, 7 Dec 1995 15:13:40 GMT From: Philippe BRAND Message-Id: <199512071513.PAA18922@colombo.telesys-innov.fr> Subject: Re: Questions for the README To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Thu, 7 Dec 1995 15:13:39 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Rask Lambertsen" at Dec 7, 95 02:48:52 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Rask Lambertsen writes: > 3) The README refers to the host "gnu.prep.ai.mit.edu" (for getting > sources) which doesn't exist. My best guess is one of the machines > "ftp.gnu.mit.edu" and "alpha.gnu.mit.edu". Which one is right? ftp.gnu.ai.mit.edu > 4) Which directory name will be used for gcc (sub)compilers? AMinet distribution (68000 & 68020 compilers): m68000-unknown-amigaos & m68020-unknown-amigaos > 5) How many of the supplied utilities will have automatic stack extension > when GCC 2.7.1 is released? 2.7.2, when ixemul.library r42 will be ready, as it includes fixes for auto-stack growing. BTW if there's already an ixemul.library with those fixes installed, I'd like to have one, in order to test it. > And last, is there a likely release date for GCC 2.7.1? 2.7.2, as I said when ixemul r42 will be ready. I don't think there's need to generate a full release now and another one when ixemul will be out. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 16:36:42 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <89465-4>; Thu, 7 Dec 1995 16:17:51 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HYJ41U1IE8002V93@NET2.WAU.NL>; Thu, 07 Dec 1995 15:21:59 +0000 (GMT) Received: by vines2.wau.nl; Thu, 7 Dec 95 15:16:56 +0100 Date: Thu, 07 Dec 1995 15:14:56 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: re: Questions for the README To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Rask wrote: >3) The README refers to the host "gnu.prep.ai.mit.edu" (for getting > sources) which doesn't exist. My best guess is one of the machines > "ftp.gnu.mit.edu" and "alpha.gnu.mit.edu". Which one is right? I think it is: prep.ai.mit.edu >5) How many of the supplied utilities will have automatic stack extension > when GCC 2.7.1 is released? >And last, is there a likely release date for GCC 2.7.1? I just read the announcement made in the gnu newgroup that one should't use 2.7.1 because of some *serious* bugs but that one should use the new 2.7.2 release. Philippe what is your opinion on this? Joop From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 16:55:36 1995 Received: from hpcl.cti.gr ([150.140.91.21]) by nic.funet.fi with SMTP id <89291-4>; Thu, 7 Dec 1995 16:52:21 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA02811 (5.67a8/IDA-1.5 for ); Thu, 7 Dec 1995 16:45:25 +0200 From: Kriton Kyrimis Message-Id: <199512071445.AA02811@hpcl.cti.gr> Subject: Re: Questions for the README To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 7 Dec 1995 16:45:24 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi (gcc) In-Reply-To: <199512071433.OAA01736@mostar.nmrc.ucc.ie> from "Lars Hecking" at Dec 7, 95 02:33:37 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 588 > I mean what I write. I'm currently compiling 2.7.2 ;^) It seems that I'm a bit out of touch. > > "Should we try using our intelligence?" > > "Well, if you think that's a good idea..." > > Not a pun, eh? > ;-) It's surprising how often these randomly selected quotes have a tendency to be appropriate/extremely inappropriate to what I'm saying. I assure you there was no offense intended. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Should we try using our intelligence?" "Well, if you think that's a good idea..." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 16:57:57 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <90537-4>; Thu, 7 Dec 1995 16:56:08 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id PAA28392 (8.7.2/7.5a-FAU);; Thu, 7 Dec 1995 15:48:55 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA13281; Thu, 7 Dec 1995 15:48:51 +0100 Date: Thu, 7 Dec 1995 15:48:51 +0100 Message-Id: <9512071448.AA13281@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: (message from Rask Lambertsen on Thu, 7 Dec 1995 14:48:52 +0100 (MET)) Subject: Re: Questions for the README >>>>> "Rask" == Rask Lambertsen writes: Rask> 4) Which directory name will be used for gcc (sub)compilers? Rask> mc68000-at-amigados? m68k-at-amigaos? m68k-unknown-amigaos? Rask> I know I've asked this before, but I don't think something Rask> was agreed upon. How about some kind of voting maybe? My Rask> personal favorite is m68k-at-amigaos, but I'll be happy with Rask> m68k-unknown-amigaos too. Hi, what about the usage of both of them, if possible ???? Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 17:01:22 1995 Received: from hpcl.cti.gr ([150.140.91.21]) by nic.funet.fi with SMTP id <89097-2>; Thu, 7 Dec 1995 16:31:35 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA02605 (5.67a8/IDA-1.5 for ); Thu, 7 Dec 1995 16:27:48 +0200 From: Kriton Kyrimis Message-Id: <199512071427.AA02605@hpcl.cti.gr> Subject: Re: Questions for the README To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 7 Dec 1995 16:27:47 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi (gcc) In-Reply-To: <199512071408.OAA01693@mostar.nmrc.ucc.ie> from "Lars Hecking" at Dec 7, 95 02:08:12 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 302 > > And last, is there a likely release date for GCC 2.7.1? > > I hope not. I hope you mean "I hope *so*"!!! -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "Should we try using our intelligence?" "Well, if you think that's a good idea..." ----- From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 17:45:58 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <88958-1>; Thu, 7 Dec 1995 17:15:25 +0200 Received: from bastion.nmrc.ucc.ie (nmrc.ucc.ie [143.239.64.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id OAA08193 for ; Thu, 7 Dec 1995 14:35:58 GMT Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id OAA28569; Thu, 7 Dec 1995 14:32:30 GMT From: Lars Hecking Message-Id: <199512071433.OAA01736@mostar.nmrc.ucc.ie> Subject: Re: Questions for the README To: kyrimis@hpcl.cti.gr (Kriton Kyrimis) Date: Thu, 7 Dec 1995 14:33:37 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <199512071427.AA02605@hpcl.cti.gr> from "Kriton Kyrimis" at Dec 7, 95 04:27:47 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 290 > > > And last, is there a likely release date for GCC 2.7.1? > > > > I hope not. > > I hope you mean "I hope *so*"!!! I mean what I write. I'm currently compiling 2.7.2 ;^) > "Should we try using our intelligence?" > "Well, if you think that's a good idea..." Not a pun, eh? ;-) From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 17:58:02 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <89222-4>; Thu, 7 Dec 1995 17:28:02 +0200 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 7 Dec 1995 16:27:34 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: New README for GCC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi everybody, I have prepared a new README for GCC. Available on the WWW as and diff file as As it appears that there will be no 2.7.1 version, I quickly (on a HP workstation :-) replaced 2.7.1 with 2.7.2. The 2.7.2 README is available as No diff file as I don't have any previous version to diff against ;-) I'll also email these to anybody who can't get them by HTTP. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | P.S. "ftp.gnu.ai.mit.edu" is an alias for "prep.ai.mit.edu" From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 21:38:28 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89009-3>; Thu, 7 Dec 1995 21:36:01 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26852-2>; Thu, 7 Dec 1995 20:35:25 +0100 Received: from hphalle6g.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395394-1>; Thu, 7 Dec 1995 20:35:08 +0100 Subject: Re: libraries again From: Christian Stieber To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Thu, 7 Dec 1995 20:34:53 +0100 (MEZ) Cc: amiga-gcc-port@lists.funet.fi In-Reply-To: from "Walter Harms" at Dec 6, 95 01:29:36 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1189 Message-Id: <95Dec7.203508+0100mesz.395394-1+268@hphalle0.informatik.tu-muenchen.de> > i have still problems with the libraries, > the system simply dont see it doesnt try to > open and i cant find why the romtag is right > at the begining of the lib just after the > moveq #-1,d0;rts according to the manual this > should work. but it dont. It should be moveq.l #-1,d0 rts ROMTAG: ... > i can see that open/init is never called. Maybe the romtag is corrupt? > i found that some datas are moved to the end > of the lib could that be a problem ? No. All my GNU-C and SAS/C generated libraries have the data section at the end, because that's what the linker generally does. I use a LibraryStart.a which contains the moveq.. and the romtag; this one is the first thing that is linked into the final executable. All the other tables are in a Library.c file, so I suppose they end up at the end of the executable. It doesn't matter where things are, as long as the ROMTag is at the expected position. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Thu Dec 7 21:53:20 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89009-1>; Thu, 7 Dec 1995 21:52:35 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26835-4>; Thu, 7 Dec 1995 20:52:26 +0100 Received: from hphalle6g.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395395-1>; Thu, 7 Dec 1995 20:52:14 +0100 Subject: Re: Questions for the README From: Christian Stieber To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Thu, 7 Dec 1995 20:52:09 +0100 (MEZ) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Dec 7, 95 02:48:52 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 911 Message-Id: <95Dec7.205214+0100mesz.395395-1+276@hphalle0.informatik.tu-muenchen.de> > 4) Which directory name will be used for gcc (sub)compilers? > mc68000-at-amigados? m68k-at-amigaos? m68k-unknown-amigaos? > I know I've asked this before, but I don't think something was agreed > upon. How about some kind of voting maybe? > My personal favorite is m68k-at-amigaos, but I'll be happy with > m68k-unknown-amigaos too. Considering that AT intends to allow non-AT Amigas, the best name is m68k-unknown-amigaos. Actually, we already have an Amiga-clone: Draco by MacroSystems. And, actually, newer GNU-C versions will work on Commodore-Amigas, too. It just doiesn't make sense to have a directory name with "at" in it. Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Fri Dec 8 00:33:02 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89575-4>; Fri, 8 Dec 1995 00:29:30 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tNpMW-000RepC; Fri, 8 Dec 95 00:04 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0dd0@wyst.hobby.nl>; Thu, 7 Dec 95 23:00:56 CET Message-Id: <9512072200.0dd0@wyst.hobby.nl> Date: Thu, 7 Dec 1995 23:00:54 +0000 (CET) In-Reply-To: <9512071148.AA25166@pctc.chemie.uni-erlangen.de> from "Thomas Walter" at Dec 7, 95 12:48:40 pm Content-Type: text Content-Length: 1202 From: hans@wyst.hobby.nl (Hans Verkuil) To: walter@pctc.chemie.uni-erlangen.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: problem with configure and config.cache > >> I have a problem while using configure . If I call configure, > >> i.e. from the package m4-1.4.tar.gz, from sh it checks some > >> system dependancies and writes some of the into a file called > >> config.cache . But the contents of the file config.cache is > >> wrong ! For example it contains (only from mind, so not a > >> valid name ) ac_limits_h=$ac_limits_h='yes' but it should be > >> ac_limits_h='yes' > >> > >> Has anybody seen a similar behavior ? > > Sorry ! I did a mistake in my bug report. > The configure script does not write to much, it writes to less. > A line in the config.cache file must look like: > ac_limits_h=${ac_limits_h='yes'} > > Watch here ^ and ^ > The {}-pair is missing. I verified it with a configure run on RS6000 running AIX. Whatever. The bug fix to pdksh still fixes your problem :-) Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Dec 8 00:33:04 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89244-3>; Fri, 8 Dec 1995 00:31:02 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tNpN3-000RepC; Fri, 8 Dec 95 00:04 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0dd5@wyst.hobby.nl>; Thu, 7 Dec 95 23:18:58 CET Message-Id: <9512072218.0dd5@wyst.hobby.nl> Date: Thu, 7 Dec 1995 23:18:55 +0000 (CET) In-Reply-To: <199512071513.PAA18922@colombo.telesys-innov.fr> from "Philippe BRAND" at Dec 7, 95 03:13:39 pm Content-Type: text Content-Length: 1104 From: hans@wyst.hobby.nl (Hans Verkuil) To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Questions for the README > > 5) How many of the supplied utilities will have automatic stack extension > > when GCC 2.7.1 is released? > > 2.7.2, when ixemul.library r42 will be ready, as it includes fixes for > auto-stack growing. BTW if there's already an ixemul.library with those fixes > installed, I'd like to have one, in order to test it. > > > And last, is there a likely release date for GCC 2.7.1? > > 2.7.2, as I said when ixemul r42 will be ready. I don't think there's need > to generate a full release now and another one when ixemul will be out. I'm afraid 42.0 will almost certainly not contain the stack extension code, as I cannot get it to work. I've contacted Matthias about this already. A later version will hopefully have working code. Sorry, but I don't think this will happen this year. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Dec 8 11:40:27 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89264-4>; Fri, 8 Dec 1995 11:38:59 +0200 Received: from bastion.nmrc.ucc.ie (actually host nmrc.ucc.ie) by funet.fi with SMTP (PP); Thu, 7 Dec 1995 12:46:44 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id KAA23400 for ; Thu, 7 Dec 1995 10:43:51 GMT From: Lars Hecking Message-Id: <199512071044.KAA01048@mostar.nmrc.ucc.ie> Subject: Re: Announcement (also for the README :-) To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Thu, 7 Dec 1995 10:44:57 +0000 (GMT) In-Reply-To: <9512070942.0d9l@wyst.hobby.nl> from "Hans Verkuil" at Dec 7, 95 10:42:09 am Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 589 > Ixemul 42.0 is nearly ready, hopefully it will be released before the end > of this year. The NEWS file contains 30 new items! (Lars, uname() has been > added :-) Good! ;) > I also want to point out that starting with 42.0 the ixemulbase structure > (with exception of the Library node) may no longer be accessed. All other > fields are now private! The same is true for the user-structure in user.h. Makes a lot of sense to me. But, is there any other way now to access the system library bases at the top of ixemulbase, or are these libs to be opened explicitly by our code? From amiga-gcc-port-owner@nic.funet.fi Fri Dec 8 16:18:51 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89097-3> convert rfc822-to-8bit; Fri, 8 Dec 1995 16:17:08 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 8 Dec 1995 15:17:01 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Alternative acronym to AIDE or ADE Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I remember that Fred Fish asked for some suggestions for a name for his set of Amiga development tools. I have on suggestion, but maybe it needs a good sense of humor: AIDS = Amiga Integrated Development System Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Dec 8 16:40:54 1995 Received: from gmdzi.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89190-4>; Fri, 8 Dec 1995 16:39:22 +0200 Received: from diva.gmd.de (diva) by gmdzi.gmd.de with SMTP id AA27710 (5.65c8/IDA-1.4.4 for ); Fri, 8 Dec 1995 15:38:51 +0100 Received: by diva.gmd.de id AA00954 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Fri, 8 Dec 1995 15:35:11 +0100 Date: Fri, 8 Dec 1995 15:35:11 +0100 From: Joerg Hoehle Message-Id: <199512081435.AA00954@diva.gmd.de> To: amiga-gcc-port@nic.funet.fi Subject: Re: Alternative acronym to AIDE or ADE Rask wrote: > I remember that Fred Fish asked for some suggestions for a name for his= > =20 > set of Amiga development tools. I have on suggestion, but maybe it needs > a good sense of humor: AIDS =3D Amiga Integrated Development System Without being so sensible, what about ACID? Amiga C integrated/ development (System?) (integrated? what's integrated?) :-) Joerg. From amiga-gcc-port-owner@nic.funet.fi Fri Dec 8 16:43:51 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89266-1> convert rfc822-to-8bit; Fri, 8 Dec 1995 16:43:02 +0200 Received: from gryzmak.lodz.pdi.net (gryzmak.lodz.pdi.net [194.92.208.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id OAA25069 for ; Fri, 8 Dec 1995 14:42:15 GMT Received: from plukwa (robert@plukwa.lodz.pdi.net [194.92.208.7]) by gryzmak.lodz.pdi.net (8.6.10/1.40/L) with SMTP id PAA00454 for ; Fri, 8 Dec 1995 15:41:18 +0100 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Fri, 8 Dec 95 15:40:59 MIME-Version: 1.0 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <004da1b830c86a9a1d4robert@plukwa> Reply-To: robert@lodz.pdi.net Subject: Re: Alternative acronym to AIDE or ADE X-Mailer: Amiga MetaTool 40.5alpha Content-Type: text/plain Content-Transfer-Encoding: 8BIT To: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi Date: Fri, 8 Dec 95 15:40:59 Organization: PDi > Hi, > > I remember that Fred Fish asked for some suggestions for a name for his > set of Amiga development tools. I have on suggestion, but maybe it needs > a good sense of humor: AIDS = Amiga Integrated Development System Actually I would (??) call it Amiga Alternative System or Amiga Alternative Enviroment. What I'm proposing is to skip the word Development. I think it would be much better when those programs were not targeted to developers only but to all the rest of Amiga users also. I think that every program ever written that is available in source code can be incorporated in this Project. > > Regards, > > /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ > | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | > | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | > | Keyboard error: and are stuck - press to continue | > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: |Jedi| | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ From amiga-gcc-port-owner@nic.funet.fi Fri Dec 8 17:47:47 1995 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with SMTP id <89005-3>; Fri, 8 Dec 1995 17:46:52 +0200 Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.6.12/8.6.4) with ESMTP id RAA29508; Fri, 8 Dec 1995 17:46:44 +0200 Received: (will@localhost) by katiska.clinet.fi (8.6.12/8.6.4) id RAA12664; Fri, 8 Dec 1995 17:46:55 +0200 Date: Fri, 8 Dec 1995 17:46:55 +0200 Message-Id: <199512081546.RAA12664@katiska.clinet.fi> From: Ville-Pertti Keinonen To: hoehle@zeus.gmd.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <199512081435.AA00954@diva.gmd.de> (message from Joerg Hoehle on Fri, 8 Dec 1995 15:35:11 +0100) Subject: Re: Alternative acronym to AIDE or ADE (integrated? what's integrated?) *Integrated* is a bad idea. At least it reminds me of silly compilers (typically ones on PCs) or interfaces to compilers that have everything combined with the editor. The result is a horrible lack of flexibility (also typical to environments on PCs in general). Of course integration can also be used when speaking of make; it sort of "integrates" the compilation process, yet keeps things flexible (you can do just about anything in Makefiles). Anyhow, an integrated development environment sounds dangerously like the various compiler frontends that take away the freedom of the programmer... (Freedom of course means using emacs to edit sources and Makefiles and make to compile ;--) From amiga-gcc-port-owner@nic.funet.fi Sat Dec 9 00:59:56 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89142-3>; Sat, 9 Dec 1995 00:56:19 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tOBg4-0004nYC; Fri, 8 Dec 95 15:54 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Alternative acronym to AIDE or ADE To: will@clinet.fi (Ville-Pertti Keinonen) Date: Fri, 8 Dec 1995 15:54:03 -0700 (MST) Cc: hoehle@zeus.gmd.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <199512081546.RAA12664@katiska.clinet.fi> from "Ville-Pertti Keinonen" at Dec 8, 95 05:46:55 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 389 > (integrated? what's integrated?) > > *Integrated* is a bad idea. At least it reminds me of silly compilers > (typically ones on PCs) or interfaces to compilers that have > everything combined with the editor. The result is a horrible lack of > flexibility (also typical to environments on PCs in general). I agree 100%. "Integrated" has no place here as used in that sense. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Dec 9 00:59:58 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89452-4>; Sat, 9 Dec 1995 00:55:19 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tOBet-0004nYC; Fri, 8 Dec 95 15:52 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Alternative acronym to AIDE or ADE To: robert@lodz.pdi.net Date: Fri, 8 Dec 1995 15:52:50 -0700 (MST) Cc: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-Reply-To: <004da1b830c86a9a1d4robert@plukwa> from "Robert Ramiega" at Dec 8, 95 03:40:59 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 884 > Enviroment. What I'm proposing is to skip the word Development. I think it > would be much better when those programs were not targeted to developers > only but to all the rest of Amiga users also. I think that every program ever > written that is available in source code can be incorporated in this Project. Certainly it is the intent that more than just strictly developer tools will be part of this project, even if only as programming examples. The focus of the project though is definitely developers. For one thing, most average users could care less about whether or not they get source for the binaries they are running. Note that my current selection, ADT, stands for Amiga Developers Environment (not "Development"). It is a small but significant point. This is intended to be a complete environment containing just about anything of interest to developers. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Dec 9 12:53:43 1995 Received: from gryzmak.lodz.pdi.net ([194.92.208.1]) by nic.funet.fi with SMTP id <89814-3>; Sat, 9 Dec 1995 12:51:33 +0200 Received: from plukwa (robert@plukwa.lodz.pdi.net [194.92.208.7]) by gryzmak.lodz.pdi.net (8.6.10/1.40/L) with SMTP id LAA04654 for ; Sat, 9 Dec 1995 11:40:47 +0100 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sat, 9 Dec 95 11:40:26 MIME-Version: 1.0 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <004c004830c983b925robert@plukwa> Reply-To: robert@lodz.pdi.net Subject: Re: Alternative acronym to AIDE or ADE X-Mailer: Amiga MetaTool 40.5alpha Content-Type: text/plain Content-Transfer-Encoding: 7bit To: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi Date: Sat, 9 Dec 95 11:40:26 Organization: PDi > Certainly it is the intent that more than just strictly developer > tools will be part of this project, even if only as programming > examples. The focus of the project though is definitely developers. > For one thing, most average users could care less about whether or not > they get source for the binaries they are running. Note that my > current selection, ADT, stands for Amiga Developers Environment (not > "Development"). It is a small but significant point. This is > intended to be a complete environment containing just about anything > of interest to developers. OK. This time i got the point!! but the name can still be Amiga Alternative (Developers) Enviroment. This leaves You the way to wider the Project > > -Fred > > Robert From amiga-gcc-port-owner@nic.funet.fi Sat Dec 9 13:55:32 1995 Received: from mn3.swip.net ([192.71.180.33]) by nic.funet.fi with SMTP id <89107-1>; Sat, 9 Dec 1995 13:53:10 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id MAA05917; Sat, 9 Dec 1995 12:49:52 +0100 Received: (from niklas@localhost) by linda.appli.se (8.6.9/8.6.9) id MAA15911; Sat, 9 Dec 1995 12:41:29 +0100 Date: Sat, 9 Dec 1995 12:41:29 +0100 From: Niklas Hallqvist Message-Id: <199512091141.MAA15911@linda.appli.se> To: robert@lodz.pdi.net CC: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-reply-to: <004c004830c983b925robert@plukwa> Subject: Re: Alternative acronym to AIDE or ADE HADES Hacking Amiga Developers Environment with Source although I'm unsure if this is not already occupied, perhaps a web search would be in order if it's considered of use. otherwise maybe SHADES Software HADES Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Home: +46-(0)31-41 93 95 Applitron Datasystem Fax: +46-(0)31-83 39 50 Home: +46-(0)31-41 93 96 Molndalsvagen 95 Email: niklas@appli.se GSM: +46-(0)70-714 10 35 S-412 63 GOTEBORG WWW: Here Sweden IRC: niklas (#NetBSD) ICB: niklas (netbsd) From amiga-gcc-port-owner@nic.funet.fi Sat Dec 9 17:05:21 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89561-1>; Sat, 9 Dec 1995 17:02:55 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tORLc-000R4hC; Sat, 9 Dec 95 16:38 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0dhr@wyst.hobby.nl>; Sat, 9 Dec 95 13:10:55 CET Message-Id: <9512091210.0dhr@wyst.hobby.nl> Date: Sat, 9 Dec 1995 13:10:52 +0000 (CET) In-Reply-To: <199512071044.KAA01048@mostar.nmrc.ucc.ie> from "Lars Hecking" at Dec 7, 95 10:44:57 am Content-Type: text Content-Length: 939 From: hans@wyst.hobby.nl (Hans Verkuil) To: lhecking@nmrc.ucc.ie Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Announcement (also for the README :-) According to Lars Hecking: > > > I also want to point out that starting with 42.0 the ixemulbase structure > > (with exception of the Library node) may no longer be accessed. All other > > fields are now private! The same is true for the user-structure in user.h. > > Makes a lot of sense to me. But, is there any other way now to access > the system library bases at the top of ixemulbase, or are these libs > to be opened explicitly by our code? The library bases are obtained by a ix_get_vars2() call in the startup code (crt0.c). I fact, the ixemulbase no longer contains the library bases at all. They are now globals. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sun Dec 10 14:25:46 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89090-2>; Sun, 10 Dec 1995 14:19:00 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tOlI8-000RKQC; Sun, 10 Dec 95 13:55 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0dl0@wyst.hobby.nl>; Sun, 10 Dec 95 13:04:58 CET Message-Id: <9512101204.0dl0@wyst.hobby.nl> Date: Sun, 10 Dec 1995 13:04:55 +0000 (CET) Content-Type: text Content-Length: 1317 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Cc: fnf@amigalib.com Subject: Problems with libraries/mathieeesp.h (also for the README) Warning! If you are porting Amiga programs that use the header or the header , then you should be aware that the prototypes defined in these headers are wrong. The parameter list for each function is empty (e.g., float IEEESPCos() ). This means two things: 1) You have a conflict if you also include (or similar headers), as these headers DO give a fully specified parameter list. 2) If you include , then all calculations will be wrong. GCC automatically promotes all floats that you pass to a math function to double, because it hasn't been told that these functions expect a float. The odd thing is that the prototypes shouldn't BE in in the first place. They should be removed altogether. The clib directory contains the prototype headers. Fred, is there a way to tell the people at AT about this? Ditto for the wrong PI define in two headers (a closing ')' too many). Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 12:32:40 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <85473-3>; Mon, 11 Dec 1995 09:04:04 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tP2GH-0004nYC; Mon, 11 Dec 95 00:02 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: ADE snapshot 951208 available via ftp To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Mon, 11 Dec 1995 00:02:57 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 733 A complete source and binary snapshot of the Amiga Developers Environment (ADE) is now available on ftp.amigalib.com, in pub/amiga/ade/951208. The files ADE-README and ADE-CONTENTS contain information about the ADE and details of what is contained in the distribution, which is about 200 Mb. Most of the included programs are the same version as on FreshFish 10, though there have been some bugs fixed, and they have been recompiled to use ixemul.library 41.5 (included). I will be working on upgrading to the latest versions of everything over the new few weeks, and another snapshot will be available before the end of December. Also on the list of things to do is to build a PPC cross compiler for m68k AmigaDOS hosts. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 12:37:40 1995 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <85009-3> convert rfc822-to-8bit; Sun, 10 Dec 1995 23:07:48 +0200 Received: by tycho.gbar.dtu.dk (1.37.109.15/16.2) Date: Sun, 10 Dec 1995 22:07:30 +0100 (MET) From: Rask Lambertsen To: Hans Verkuil Cc: amiga-gcc-port@nic.funet.fi, fnf@amigalib.com Subject: Re: Problems with libraries/mathieeesp.h (also for the README) In-Reply-To: <9512101204.0dl0@wyst.hobby.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Sun, 10 Dec 1995, Hans Verkuil wrote: > Fred, is there a way to tell the people at AT about this? Ditto for the > wrong PI define in two headers (a closing ')' too many). I know, my name is not Fred, but I mailed my two patches from the readme (mismatched paratheses) to one of the AT people. Go to http://www.amiga.de/, enter the index of your favorite language, go to the staff directory, pick a name and use the email address. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 13:21:46 1995 Received: from icslab3.icslab.agh.edu.pl ([149.156.98.3]) by nic.funet.fi with SMTP id <89516-4>; Mon, 11 Dec 1995 13:20:34 +0200 Received: (from kiskra@localhost) by icslab3.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA00544; Mon, 11 Dec 1995 12:22:21 +0100 Date: Mon, 11 Dec 1995 12:22:18 +0100 (MET) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: New fd2inline To: Amiga GCC List cc: phb@colombo.telesys-innov.fr, fnf@amigalib.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I just put new version of fd2inline on my WWW page, I also uploaded it to amigalib (file "fd2inline.lha") and colombo (file "fd2inline_new.lha", since there already was an older "fd2inline.lha"). If you have problems with getting it from my WWW page, please e-mail me and I'll send them to you uu-encoded. Changes from previous version: Third output format has been added - stabs format (executable: fd2inline.stabs). This is basically "old" format with vararg-stabs defined as plain functions. This is intended to be used for creating linker libraries - please have a look at accompanying "Makefile.lib" and "splitasm.awk". dos.library/DateStamp() is now handled correctly. Parser had serious problems with it, because its return type's name was the same as function's name. files have been updated. Instead of including they now include . This is slower, but more appropriate now, when there are two different kinds of inlines. Besides, using these headers is discouraged and they are provided for compatibility only, so who cares about speed? New file has been created - it includes all standard system protos. MUI inlines and linker libraries have been updated for MUI 3.1. "fifo.library" inlines have been added. When #including in G++, parse errors were generated. This was because function ActivateCxObj() had argument called "true", while "true" is reserved word in C++. I modified "fd" files and rebuilt inlines, but "clib/commodities_protos.h" also requires modification. I included context diff files in fd2inline archive. Rask, if you read this, could you please add that one to "Patches" section in "README-2.7.2"? and files have been removed, since GCC does not support FFP format. and now only produce an error message. fd2inline.old has been renamed to fd2inline++, for consistency with "createinl++" and "inline++". Output format of "old" includes has been slightly modified. They no longer include and do "__BEGIN_DECLS"/"__END_DECLS". These turned out to be unncecessary because by default G++ uses C linkage rules for files included from . I also removed/added some spaces in various places - I hope inlines look nicer now :-). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 13:31:14 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89221-3>; Mon, 11 Dec 1995 13:30:06 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 11 Dec 95 12:29 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 11 Dec 95 12:21 MET Message-Id: Subject: bug reports for AT To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 11 Dec 1995 12:20:58 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 957 > > > Fred, is there a way to tell the people at AT about this? Ditto for the > > wrong PI define in two headers (a closing ')' too many). > > I know, my name is not Fred, but I mailed my two patches from the readme > (mismatched paratheses) to one of the AT people. Go to http://www.amiga.de > enter the index of your favorite language, go to the staff directory, > pick a name and use the email address. there are 2 basic problems. 1. i cant reach that site because of strange routing 2. olaf bartel has called on usenet to collect all the bugs on bugs@sorcery.han.de (?) can someone please check the address ? i am not sure abuot it. walter -- ----- Programmers are lousy lovers. They always try to get the job done faster than before. And when they do, they brag that they have better performance. Programmers are the only men who boast how small theirs is. // WIL BADEN ----- From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 13:34:05 1995 Received: from erlang.gbar.dtu.dk ([130.225.87.177]) by nic.funet.fi with ESMTP id <89670-1> convert rfc822-to-8bit; Mon, 11 Dec 1995 13:32:53 +0200 Received: by erlang.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 11 Dec 1995 12:32:18 +0100 (MET) From: Rask Lambertsen To: Kamil Iskra Cc: Amiga GCC List , phb@colombo.telesys-innov.fr, fnf@amigalib.com Subject: Re: New fd2inline In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 11 Dec 1995, Kamil Iskra wrote: > MUI inlines and linker libraries have been updated for MUI 3.1. > > "fifo.library" inlines have been added. Is there any limit to the number of inlines you want to add to the archive? Otherwise, I'd suggest inlines for whatis.library. > When #including in G++, parse errors were > generated. This was because function ActivateCxObj() had argument > called "true", while "true" is reserved word in C++. I modified "fd" > files and rebuilt inlines, but "clib/commodities_protos.h" also > requires modification. I included context diff files in fd2inline > archive. Rask, if you read this, could you please add that one to > "Patches" section in "README-2.7.2"? Of course I read this. Yes, I'll add yet another patch. Hans (?), I'll also remove the fault prototypes from mathieee(s|d)p.h and create new diffs to include in the "Pathes" section. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 13:34:20 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <89774-4>; Mon, 11 Dec 1995 13:33:08 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HYOJGT4FK00049I0@NET2.WAU.NL>; Mon, 11 Dec 1995 12:37:50 +0000 (GMT) Received: by vines2.wau.nl; Mon, 11 Dec 95 12:32:50 +0100 Date: Sun, 10 Dec 1995 13:46:41 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: re: Problems with libraries/mathieeesp.h (also for the README) To: hans@wyst.hobby.nl Cc: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hans wrote: >Fred, is there a way to tell the people at AT about this? Ditto for the >wrong PI define in two headers (a closing ')' too many). While we're at the subject of sloppy headers files. I'm currently working on a port of LCC to the Amiga and I get lots of errors/warnings about unsigned char/signed char while compiling a random selection of small Amiga specific sources. But the same problem can also be seen when trying to compile Aztec source with SAS or GCC and vice versa. I have been searching the net for a readable ANSI-C standard reference but I don't know yet if I got it. I still need to wade through a lot of files ;) The most common problem is that of for example: DOSBase=OpenLibrary("dos.library",37L) LCC is bound to give an error on this one even without the -A option which will produce even more warnings/errors. Someone having the prototypes handy? There is more than one way to solve this, the quick and dirty way and the way it is supposed to be, probably also the most time consuming. Anyone willing to shine some light on this? Pointers to faq's (C) www/ftp-sites, anything. Joop From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 13:50:45 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89101-2>; Mon, 11 Dec 1995 13:49:13 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 11 Dec 1995 12:48:42 +0100 (MET) From: Rask Lambertsen To: Walter Harms Cc: amiga gcc-list Subject: Re: bug reports for AT In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Dec 1995, Walter Harms wrote: > > > Fred, is there a way to tell the people at AT about this? Ditto for the > > > wrong PI define in two headers (a closing ')' too many). > > > > I know, my name is not Fred, but I mailed my two patches from the readme > > (mismatched paratheses) to one of the AT people. Go to http://www.amiga.de > > enter the index of your favorite language, go to the staff directory, > > pick a name and use the email address. > > there are 2 basic problems. > 1. i cant reach that site because of strange routing Aargh. Try to get it fixed if you can. Christoph Guelicher Product Manager Software Michael-W. Hohmann Manager Support Dr. Peter Kittel Development Ruediger Meinecke Support > 2. olaf bartel has called on usenet to collect all the > bugs on bugs@sorcery.han.de (?) > > can someone please check the address ? i am not sure abuot it. Looks OK to me ;-) Seriously, there is actually a mail-exchanger for that address (checked with nslookup), although the host itself doesn't exist. Maybe mail Olaf Bartel and ask him (rhialto@(something).no)? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 13:58:03 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89720-1>; Mon, 11 Dec 1995 13:57:03 +0200 Received: from konrad.lysator.liu.se (lysnet-gw.lysator.liu.se [130.236.253.6]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id LAA28079 for ; Mon, 11 Dec 1995 11:56:28 GMT Received: from tiny.lysator.liu.se (tiny.lysator.liu.se [130.236.253.10]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id MAA19435; Mon, 11 Dec 1995 12:45:28 +0100 Received: (nisse@localhost) by tiny.lysator.liu.se (8.6.11/8.6.11) id MAA08411; Mon, 11 Dec 1995 12:44:12 +0100 Date: Mon, 11 Dec 1995 12:44:12 +0100 Message-Id: <199512111144.MAA08411@tiny.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: test1@MEDEW.ENTO.WAU.NL (test1) Cc: amiga-gcc-port@nic.funet.fi In-reply-to: test1@MEDEW.ENTO.WAU.NL's message of Sun, 10 Dec 1995 13:46:41 +0100 (CET) Subject: re: Problems with libraries/mathieeesp.h (also for the README) References: test1@MEDEW.ENTO.WAU.NL (test1) writes: > Anyone willing to shine some light on this? > Pointers to faq's (C) www/ftp-sites, anything. Try http://www.lysator.liu.se/c/ From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 14:10:45 1995 Received: from icslab3.icslab.agh.edu.pl ([149.156.98.3]) by nic.funet.fi with SMTP id <89198-1>; Mon, 11 Dec 1995 14:08:52 +0200 Received: (from kiskra@localhost) by icslab3.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA00589; Mon, 11 Dec 1995 13:10:28 +0100 Date: Mon, 11 Dec 1995 13:10:26 +0100 (MET) From: Kamil Iskra Subject: Re: bug reports for AT To: Rask Lambertsen cc: Walter Harms , amiga gcc-list In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Dec 1995, Rask Lambertsen wrote: > > 2. olaf bartel has called on usenet to collect all the > > bugs on bugs@sorcery.han.de (?) > > > > can someone please check the address ? i am not sure abuot it. > > Looks OK to me ;-) But not to me :-). I just read this article in UseNET and it is supposed to be: bugs@sourcery.han.de / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 14:17:08 1995 Received: from icslab3.icslab.agh.edu.pl ([149.156.98.3]) by nic.funet.fi with SMTP id <89430-3>; Mon, 11 Dec 1995 14:16:11 +0200 Received: (from kiskra@localhost) by icslab3.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA00600; Mon, 11 Dec 1995 13:17:57 +0100 Date: Mon, 11 Dec 1995 13:17:54 +0100 (MET) From: Kamil Iskra Sender: Kamil Iskra Reply-To: Kamil Iskra Subject: Re: New fd2inline To: Rask Lambertsen cc: Amiga GCC List In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Mon, 11 Dec 1995, Rask Lambertsen wrote: > Is there any limit to the number of inlines you want to add to the archive? No, there's no. If I remember correctly, Philippe once wrote that he would like to see as many 3rd party libraries' stuff distributed with GCC as possible. > Otherwise, I'd suggest inlines for whatis.library. Sure, why not. Actually, I add them on poeple's requests - I don't have time to add everything from util/libs on Aminet. :-) > Yes, I'll add yet another patch. Hans (?), I'll > also remove the fault prototypes from mathieee(s|d)p.h and create new > diffs to include in the "Pathes" section. I think that the README is becoming too big. Maybe it would be better if it was converted to AmigaGuide - at least it would be easier to find information you need. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 14:32:41 1995 Received: from icslab3.icslab.agh.edu.pl ([149.156.98.3]) by nic.funet.fi with SMTP id <88947-4>; Mon, 11 Dec 1995 14:31:16 +0200 Received: (from kiskra@localhost) by icslab3.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA00609; Mon, 11 Dec 1995 13:32:04 +0100 Date: Mon, 11 Dec 1995 13:32:02 +0100 (MET) From: Kamil Iskra Subject: re: Problems with libraries/mathieeesp.h (also for the README) To: test1 cc: amiga-gcc-port@nic.funet.fi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 10 Dec 1995, test1 wrote: > While we're at the subject of sloppy headers files. I'm currently working on > a port of LCC to the Amiga and I get lots of errors/warnings about unsigned > char/signed char while compiling a random selection of small Amiga specific > sources. > But the same problem can also be seen when trying to compile Aztec source > with SAS or GCC and vice versa. I have the same problem with g++ (at least I hope we are talking about the same thing :-). You mean pointer conversion warnings about "char*" <-> "unsigned char*" conflicts? gcc and SAS/C "swallow" it implicitly and don't produce any warnings, but Aztec, G++ and, as you wrote, LCC don't like this kind of code. I think this is CBM programmers fault - they created a special type - STRPTR - which was supposed to be used for strings (have a look at ), but they most often just wrote "char*" or "UBYTE*" in prototypes or structures difinitions! > There is more than one way to solve this, the quick and dirty way and the way > it is supposed to be, probably also the most time consuming. It is not our job to fix system headers - AT is repsponsible for this, and I think they will simply HAVE TO do it. I don't know what "quick and dirty" way you meant - the only one I can think of is hacking into compiler by preventing it to generate a warning in case of conflicting "char*" <-> "unsigned char*". While we are on this subject: Fred, Philippe, anybody who knows - would it be hard to add such a hack to G++? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 14:42:34 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89933-4>; Mon, 11 Dec 1995 14:41:21 +0200 Received: from bastion.nmrc.ucc.ie (actually host nmrc.ucc.ie) by funet.fi with SMTP (PP); Mon, 11 Dec 1995 14:41:14 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id MAA02684 for ; Mon, 11 Dec 1995 12:39:33 GMT From: Lars Hecking Message-Id: <199512111240.MAA06065@mostar.nmrc.ucc.ie> Subject: Re: ADE snapshot 951208 available via ftp To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Mon, 11 Dec 1995 12:40:44 +0000 (GMT) In-Reply-To: from "Fred Fish" at Dec 11, 95 00:02:57 am Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 375 > Most of the included programs are the same version as on FreshFish 10, > though there have been some bugs fixed, and they have been recompiled to use > ixemul.library 41.5 (included). What's the difference between 41.4 and 41.5? I currently have the 41.4 sources with patches for toupper()/tolower() and new inlines, and was wondering if it's worth downloading. -l From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 14:47:24 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89175-3>; Mon, 11 Dec 1995 14:45:53 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 11 Dec 1995 13:45:06 +0100 (MET) From: Rask Lambertsen To: Kamil Iskra Cc: Amiga GCC List Subject: Re: New fd2inline In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Dec 1995, Kamil Iskra wrote: > On Mon, 11 Dec 1995, Rask Lambertsen wrote: > > > Is there any limit to the number of inlines you want to add to the archive? > > No, there's no. If I remember correctly, Philippe once wrote that he would > like to see as many 3rd party libraries' stuff distributed with GCC as > possible. > > > Otherwise, I'd suggest inlines for whatis.library. > > Sure, why not. Actually, I add them on poeple's requests - I don't have > time to add everything from util/libs on Aminet. :-) > > > Yes, I'll add yet another patch. Hans (?), I'll > > also remove the fault prototypes from mathieee(s|d)p.h and create new > > diffs to include in the "Pathes" section. > > I think that the README is becoming too big. Maybe it would be better if > it was converted to AmigaGuide - at least it would be easier to find > information you need. You just expressed my thoughts (and beat me to the mailer programme :-) I think we'll see an AmigaGuide version in a couple of days. Since GCC requires OS 2.0 anyway, I guess it shouldn't cause problems for those that want to read it. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 15:01:48 1995 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89496-1>; Mon, 11 Dec 1995 14:59:18 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA26991 (5.67b8/IDA-1.5 for ); Mon, 11 Dec 1995 13:58:38 +0100 Received: by diva.gmd.de with UUCP id AA01250 (5.67b8/IDA-1.5); Mon, 11 Dec 1995 13:54:54 +0100 Date: Mon, 11 Dec 1995 13:54:54 +0100 Message-Id: <199512111254.AA01250@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: test1@medew.ento.wau.nl (test1) Cc: amiga-gcc-port@nic.funet.fi Subject: re: Problems with libraries/mathieeesp.h (also for the README) In-Reply-To: References: test1@medew.ento.wau.nl writes: > While we're at the subject of sloppy headers files. I'm currently working on > a port of LCC to the Amiga and I get lots of errors/warnings about unsigned > char/signed char while compiling a random selection of small Amiga specific > sources. Known problem. It would be extremely hard and ugly (because of casts) to get rid of all these warnings. Common example: many functions and structures use UBYTE* for string arguments (e.g. intuition/*.h) whereas a "fubar" C-string is char*, usually signed. Voila. I believe C=/AT headers were written for an unsigned char machine or by somebody for who thinks that ae has code 230 and not -26. I don't think it's worth the effort. Next problem: inconsistencies between autodocs and includes (can't remember where). Do you favour the includes because that's what's actually used or the autodocs because that's the law? > The most common problem is that of for example: > DOSBase=OpenLibrary("dos.library",37L) > LCC is bound to give an error on this one even without the -A option which Error for "dos.library" or DOSBase? Small problem: Depending on what you need of SysBase (or other library bases) you either declare it as struct Library * or ExecBase * (to be able to access eb_processor_flags or whatever it's called). This has to be done before including inlines (attention: fd2inline compatibility) or you'll get a GCC error. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 15:15:44 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89296-2>; Mon, 11 Dec 1995 15:14:17 +0200 Received: from bastion.nmrc.ucc.ie (actually host nmrc.ucc.ie) by funet.fi with SMTP (PP); Mon, 11 Dec 1995 15:13:28 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id NAA03338 for ; Mon, 11 Dec 1995 13:11:49 GMT From: Lars Hecking Message-Id: <199512111313.NAA06109@mostar.nmrc.ucc.ie> Subject: Re: Problems with libraries/mathieeesp.h (also for the README) To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Mon, 11 Dec 1995 13:12:59 +0000 (GMT) In-Reply-To: from "Kamil Iskra" at Dec 11, 95 01:32:02 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 926 > It is not our job to fix system headers - AT is repsponsible for this, and > I think they will simply HAVE TO do it. I don't know what "quick and > dirty" way you meant - the only one I can think of is hacking into > compiler by preventing it to generate a warning in case of conflicting > "char*" <-> "unsigned char*". > > While we are on this subject: Fred, Philippe, anybody who knows - would it > be hard to add such a hack to G++? Probably not, but I'm strictly opposed to this. We'll have to live with these warnings, I suppose: - why should we deliberately give up one of C++'s major advantages over C (stronger type checking)? - there _are_ potential dangers from inappropriate use of signed and unsigned chars, and the compiler should find them. Can you spell 'implicit 7-bit-ism'? (there is a book by Andrew Koenig titled "C Traps and Pitfalls", which I believe covers this topic in detail). From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 17:23:54 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89658-3>; Mon, 11 Dec 1995 17:20:55 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tPA0w-0004nZC; Mon, 11 Dec 95 08:19 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ADE snapshot 951208 available via ftp To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Mon, 11 Dec 1995 08:19:37 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199512111240.MAA06065@mostar.nmrc.ucc.ie> from "Lars Hecking" at Dec 11, 95 12:40:44 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 498 > What's the difference between 41.4 and 41.5? I currently have the 41.4 > sources with patches for toupper()/tolower() and new inlines, and was > wondering if it's worth downloading. There should be no functional difference. The source has been fixed to be compilable using the latest inlines. I felt it best to bump the revision number to avoid having two libraries in circulation with the same number, but potentially different behavior (there is none that I know of at this time). -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 17:48:33 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <89235-1>; Mon, 11 Dec 1995 17:47:58 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HYOSDMLAOW004DY9@NET2.WAU.NL>; Mon, 11 Dec 1995 16:52:35 +0000 (GMT) Received: by vines2.wau.nl; Mon, 11 Dec 95 16:47:35 +0100 Date: Mon, 11 Dec 1995 16:21:30 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: re: Problems with libraries/mathieeesp.h (also for the README) To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Joop wrote: >> While we're at the subject of sloppy headers files. I'm currently working >>on a port of LCC to the Amiga and I get lots of errors/warnings about >>unsigned char/signed char while compiling a random selection of small Amiga >>specific sources. Kamil Wrote: >I have the same problem with g++ (at least I hope we are talking about the >same thing :-). You mean pointer conversion warnings about "char*" <-> >"unsigned char*" conflicts? gcc and SAS/C "swallow" it implicitly and Yep the same. >It is not our job to fix system headers - AT is repsponsible for this, and No it isn't but in the meantime I either have to place casts everywhere or not use LCC. Did AT announce that they are going to cleanup the header files?. I will have a look at the headerfiles of StormC, but I seem to remember that they use the standard 3.1 includes. >I think they will simply HAVE TO do it. I don't know what "quick and >dirty" way you meant - the only one I can think of is hacking into >compiler by preventing it to generate a warning in case of conflicting >"char*" <-> "unsigned char*". I was thinking of redefining 'char'. I do want the warnings/errors since it points out possible mistakes in the source. Joerg wrote: >Next problem: inconsistencies between autodocs and includes (can't >remember where). Do you favour the includes because that's what's >actually used or the autodocs because that's the law? That is one I didn't know about. Do you have any examples which are fatal. >> The most common problem is that of for example: >> DOSBase=OpenLibrary("dos.library",37L) >> LCC is bound to give an error on this one even without the -A option which >Error for "dos.library" or DOSBase? "dos.library" ofcourse, the problems with DOSBase not being a struct Library isn't as hard as all the literal strings in programs causing all conversion errors. and finally Lars wrote: >Probably not, but I'm strictly opposed to this. We'll have to live with > these warnings, I suppose: > - why should we deliberately give up one of C++'s major advantages over C > (stronger type checking)? I don't want to give up on the type checking, only thing is right now the header files are causing lots of errors/warnings which they shouldn't. The compiler builders have 'solved' that by allowing those conversions. > - there _are_ potential dangers from inappropriate use of signed and > unsigned chars, and the compiler should find them. Can you spell > 'implicit 7-bit-ism'? (there is a book by Andrew Koenig titled > "C Traps and Pitfalls", which I believe covers this topic in detail). True, and thats why the include files should be cleaned up so that compiler builders don't implement hacks to avoid these warnings/errors. I want to see *my* mistakes and not the systems supplier ones. Joop PS: Am I the only one getting some messages twice? Those are exact duplicates, from and to addresses too. So it is not someone sending to the list and another copy to me too. Persons involved: Kamil, Joerg and Niels. From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 18:04:59 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89224-1>; Mon, 11 Dec 1995 18:04:06 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <27171-4>; Mon, 11 Dec 1995 17:01:39 +0100 Received: from hphalle6a.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395394-2>; Mon, 11 Dec 1995 17:01:22 +0100 Subject: Re: Problems with libraries/mathieeesp.h (also for the README) From: Christian Stieber To: amiga-gcc-port@lists.funet.fi Date: Mon, 11 Dec 1995 17:01:10 +0100 (MEZ) In-Reply-To: from "test1" at Dec 10, 95 01:46:41 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1566 Message-Id: <95Dec11.170122+0100mesz.395394-2+562@hphalle0.informatik.tu-muenchen.de> > > While we're at the subject of sloppy headers files. I'm currently working on > a port of LCC to the Amiga and I get lots of errors/warnings about unsigned > char/signed char while compiling a random selection of small Amiga specific > sources. Well, I get lots of warnings about all the places where I have to cast the "const" away because AmigaOS headers never use that keyword. That's really annoying, because turning that warning off means I no longer see the real problems as well :( > I have been searching the net for a readable ANSI-C standard reference but I > don't know yet if I got it. I still need to wade through a lot of files ;) You won't find one. ANSI (actually, the standard is now ISO/IEC 9899-1990, which replaces the old ANSI-C (I forgot the actual name of the standard)) is selling the papers for real money, because that's how they get their money (there might be other sources I don't know about, of course). > The most common problem is that of for example: > DOSBase=OpenLibrary("dos.library",37L) > LCC is bound to give an error on this one even without the -A option which > will produce even more warnings/errors. Someone having the prototypes handy? This is because the above incorrect. It should be: DOSBase=(struct DosLibrary *)OpenLibrary("dos.library",37L); Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 18:08:34 1995 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89273-1>; Mon, 11 Dec 1995 18:08:07 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA18226 (5.67b8/IDA-1.5 for ); Mon, 11 Dec 1995 17:06:22 +0100 Received: by diva.gmd.de with UUCP id AA01317 (5.67b8/IDA-1.5); Mon, 11 Dec 1995 17:02:38 +0100 Date: Mon, 11 Dec 1995 17:02:38 +0100 Message-Id: <199512111602.AA01317@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: fnf@amigalib.com (Fred Fish) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Subject: ADE snapshot 951208 available via ftp In-Reply-To: References: Hi, Fred Fish writes: > A complete source and binary snapshot of the Amiga Developers Environment > (ADE) is now available on ftp.amigalib.com, in pub/amiga/ade/951208. The > files ADE-README and ADE-CONTENTS contain information about the ADE and > details of what is contained in the distribution, which is about 200 Mb. I just took a look at it and I'm now wondering what people _writing_ software (i.e. non ports of existing FSF/UNIX software) must do to enhance ADE. E.g., I just saw fifo-38.0 there and I'm wondering what I have to do to release 38.1 there. Shall I write configure scripts? I've never done this and was happy enough when existing scripts worked... Shall I write Installer scripts? I've never done this either and it looks like it's going to take me a lot of time where basically a few files only need to be copied somewhere. Shall I write Product-Info files? Ok, I'll copy the existing one and bump the revision. Do the Makefiles require GCC? I want to neither drop DICE support nor break 1.3 compatibility (I introduced no change which made me wish my program were >= 2.0 only), but distributing ixemul or libnix-compiled programs will make them require 2.0. E.g., I compiled remcli with DICE. I wanted to include Makefile (for GCC) and DMakefile (for DICE). Does the source archive require a UNIX-like environment for configure to execute successfully? What about DICE users? What about small machines? What else must I do? Adding lots of files like configure, installer script etc. takes my time and requires more testing. What sense do fifo-base/bin/src/diffs make when I want to release everything in one archive and send it to aminet also? Who precisely creates these archives? How to keep things simple? Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 18:19:51 1995 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89356-2>; Mon, 11 Dec 1995 18:18:10 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA19658 (5.67b8/IDA-1.5 for ); Mon, 11 Dec 1995 17:17:42 +0100 Received: by diva.gmd.de with UUCP id AA01322 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Mon, 11 Dec 1995 17:13:58 +0100 Date: Mon, 11 Dec 1995 17:13:58 +0100 Message-Id: <199512111613.AA01322@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: re: Problems with libraries/mathieeesp.h (also for the README) In-Reply-To: References: test1@medew.ento.wau.nl writes: > Did AT announce that they are going to cleanup the header files?. I will have Very probably not their priority. > >I think they will simply HAVE TO do it. I believe SAS allows you to switch off specific warnings. No priority. const keywords would be nice though. > I was thinking of redefining 'char'. I do want the warnings/errors since it > points out possible mistakes in the source. Have you tried -funsigned-char? > Am I the only one getting some messages twice? > Those are exact duplicates, from and to addresses too. So it is not someone > sending to the list and another copy to me too. > Persons involved: Kamil, Joerg and Niels. As people not on this mailing list are allowed to mail to the list, I went over to reply to both the sender and the list to make sure the sender gets the response. Yet I find receiving the same mail twice annoying. Whenever I get a message twice, it's for this reason and the headers show a difference. Some mail programs do not show all headers, so maybe you don't see the difference. Do you see "Received: ..." lines, they tell you the way the mail went. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 18:35:50 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89146-2>; Mon, 11 Dec 1995 18:34:51 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tPBAS-0004nYC; Mon, 11 Dec 95 09:33 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ADE snapshot 951208 available via ftp To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Mon, 11 Dec 1995 09:33:31 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <199512111602.AA01317@diva.gmd.de> from "Joerg Hoehle" at Dec 11, 95 05:02:38 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4839 > I just took a look at it and I'm now wondering what people _writing_ > software (i.e. non ports of existing FSF/UNIX software) must do to > enhance ADE. E.g., I just saw fifo-38.0 there and I'm wondering what > I have to do to release 38.1 there. All good questions that should eventually be answered in the README file... > Shall I write configure scripts? With a few exceptions for things that have not yet been completed, everything in the ADE source tree uses a GNU autoconf generated script. Although autoconf's greatest strength is helping to make a more portable package to various operating systems and machines (which is somewhat irrelevant for pieces which can only be run on an AmigaDOS host), it does many other nice things as well, such as making it very easy to use separate source and build trees. Most autoconf conversions are simple, you create a simple configure.in file, run autoconf to generate the configure script, rename Makefile to Makefile.in and convert a few macros in Makefile.in so that configure can substitute values for them. It usually takes longer to learn how to set things up than to actually convert a program to use autoconf. > Shall I write Installer scripts? Currently everything in the ADE installs with a simple "make install" at the root of the build tree. I.E. installation procedures are built into the makefiles. However it would be nice for at least the ftp releases for users to have a standard AmigaDOS installer script that they can run that allows them to select which packages to install and handles the details of unpacking the archives and doing the installation. This is something I've not thought too hard about yet. > I've never done this either and it looks like it's going to > take me a lot of time where basically a few files only need to be > copied somewhere. The "copy a few files somewhere" approach is how the current makefiles do it for people that build packages from the source. Prepackaged binaries are currently installed by just unarchiving them in the root of the installation tree. > Shall I write Product-Info files? Ok, I'll copy the existing one and > bump the revision. Yes, everything needs a Product-Info file. > Do the Makefiles require GCC? As much as possible, everything in the ADE should be buildable with GCC by default. > I want to neither drop DICE support nor > break 1.3 compatibility (I introduced no change which made me wish my > program were >= 2.0 only), but distributing ixemul or libnix-compiled > programs will make them require 2.0. E.g., I compiled remcli with > DICE. I wanted to include Makefile (for GCC) and DMakefile (for DICE). Certainly the Makefiles can support compiling with other compilers or you can have separate makefiles (DMakefile for example) that people can use if they want but which will be ignored when people build using the standard ADE environment. > Does the source archive require a UNIX-like environment for configure > to execute successfully? Generally configure requires a unix compatible shell (sh), sed, and a few other utilities. > What about DICE users? I don't personally plan to add any support to the Makefiles for compilers which are not part of the ADE such as gcc and eventually lcc (hopefully). I have no objection to including that support if someone wants to take the time to make the changes. > What about small machines? What about them? There will be a certain minimum expected configuration for anyone that wants to be able to do a complete rebuild of the ADE binaries from source. I don't know for sure what the configuration is at the moment, though I do know that some of the larger pieces require at least 10 Mb or more of memory to compile with gcc. > What else must I do? Adding lots of files like configure, installer > script etc. takes my time and requires more testing. As currently conceived, there are two ways to get something integrated into the ADE; (1) conform to all the current requirements for configuration and building, test everything, and submit it to me (or eventually one of a team of maintainers) to integrate into the source tree or (2) submit a package in a random state and wait until there is time for someone to do the work of integrating it, and once it is integrated, we'd expect future releases to be based on that copy not the original submission (I.E. we will only do the conversion the first time). > What sense do fifo-base/bin/src/diffs make when I want to release > everything in one archive and send it to aminet also? Who precisely > creates these archives? These archives are all created mechanically from the ADE source base, an ADE build tree, and an installed ADE binary tree. In theory this allows us to make a new snapshot or release by simply doing "make release" in the root of the source tree. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 19:07:27 1995 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89856-2>; Mon, 11 Dec 1995 19:06:31 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA22386 (5.67b8/IDA-1.5 for ); Mon, 11 Dec 1995 18:05:13 +0100 Received: by diva.gmd.de with UUCP id AA01350 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Mon, 11 Dec 1995 18:01:29 +0100 Date: Mon, 11 Dec 1995 18:01:29 +0100 Message-Id: <199512111701.AA01350@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: special Amiga GCC options Hi, I'm wondering if there's a description of special Amiga options that have made their way into gcc, cc1, gas or ld. While I'm using them, I only knew they existed by looking at the -v output or the specs file, which I do not find a satisfactory situation. Where are -mshort-code, -fdatabss-together etc. and all the others that I don't even know of documented? Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 19:45:16 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <89225-3>; Mon, 11 Dec 1995 19:44:17 +0200 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id SAA06109 (8.6.10/2.4); Mon, 11 Dec 1995 18:44:56 +0100 Date: Mon, 11 Dec 1995 18:44:56 +0100 From: Olaf Seibert Message-Id: <199512111744.SAA06109@septimius.mbfys.kun.nl> To: Walter.Harms@arbi.informatik.uni-oldenburg.de, gc948374@gbar.dtu.dk Subject: Re: bug reports for AT Cc: amiga-gcc-port@nic.funet.fi > Maybe mail Olaf Bartel and ask him (rhialto@(something).no)? I always get confused with the other Olaf. Weird. Just for the record, it is rhialto@mbfys.kun.nl (Olaf Seibert). -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 19:46:56 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <89814-1>; Mon, 11 Dec 1995 19:46:18 +0200 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id SAA06113 (8.6.10/2.4); Mon, 11 Dec 1995 18:46:59 +0100 Date: Mon, 11 Dec 1995 18:46:59 +0100 From: Olaf Seibert Message-Id: <199512111746.SAA06113@septimius.mbfys.kun.nl> To: amiga-gcc-port@lists.funet.fi, test1@MEDEW.ENTO.WAU.NL Subject: re: Problems with libraries/mathieeesp.h (also for the README) > >I think they will simply HAVE TO do it. I don't know what "quick and > >dirty" way you meant - the only one I can think of is hacking into > >compiler by preventing it to generate a warning in case of conflicting > >"char*" <-> "unsigned char*". > I was thinking of redefining 'char'. I do want the warnings/errors since it > points out possible mistakes in the source. That would not help. Even if 'char' is an unsigned type, it is still not the same type as 'unsigned char'. Just as with the various 'int' types. -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 20:07:50 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89917-2>; Mon, 11 Dec 1995 20:07:17 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 11 Dec 95 19:05 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 11 Dec 95 19:02 MET Message-Id: Subject: special Amiga GCC options To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Mon, 11 Dec 1995 19:02:20 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 734 > I'm wondering if there's a description of special Amiga options that > have made their way into gcc, cc1, gas or ld. While I'm using them, I > only knew they existed by looking at the -v output or the specs file, > which I do not find a satisfactory situation. Where are -mshort-code, > -fdatabss-together etc. and all the others that I don't even know of > documented? that is something i would like to know, too ! i have a copy of the original gcc documentation. there is for example no mention of __FUNCTION__ , something great if you debug. a list op option for ld would be nice, to :) walter ps: kputs(__FUNKTION__) is on of my favorite debugmacros -- ----- "I'm what monsters have nightmares about!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 20:14:00 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89440-2>; Mon, 11 Dec 1995 20:13:19 +0200 Received: from bastion.nmrc.ucc.ie (actually host nmrc.ucc.ie) by funet.fi with SMTP (PP); Mon, 11 Dec 1995 20:12:21 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id SAA10413 for ; Mon, 11 Dec 1995 18:10:40 GMT From: Lars Hecking Message-Id: <199512111811.SAA06773@mostar.nmrc.ucc.ie> Subject: Re: special Amiga GCC options To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Mon, 11 Dec 1995 18:11:50 +0000 (GMT) In-Reply-To: from "Walter Harms" at Dec 11, 95 07:02:20 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 298 > that is something i would like to know, too ! i have a copy > of the original gcc documentation. there is for example > no mention of __FUNCTION__ , something great if you debug. Either your copy is outdated, or you haven't looked hard enough. (Hint: C Extensions -> Function Names) ;) From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 20:58:31 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89928-2>; Mon, 11 Dec 1995 20:57:46 +0200 Received: from konrad.lysator.liu.se (lysnet-gw.lysator.liu.se [130.236.253.6]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id SAA10550 for ; Mon, 11 Dec 1995 18:57:38 GMT Received: from godot.lysator.liu.se (godot.lysator.liu.se [130.236.254.154]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id TAA03089; Mon, 11 Dec 1995 19:56:51 +0100 Received: from lysistrate.lysator.liu.se (lysistrate.lysator.liu.se [130.236.254.161]) by godot.lysator.liu.se (8.6.11/8.6.11) with ESMTP id SAA07198; Mon, 11 Dec 1995 18:12:41 +0100 Received: (nisse@localhost) by lysistrate.lysator.liu.se (8.6.11/8.6.11) id SAA21778; Mon, 11 Dec 1995 18:09:02 +0100 Date: Mon, 11 Dec 1995 18:09:02 +0100 Message-Id: <199512111709.SAA21778@lysistrate.lysator.liu.se> From: Niels M|ller Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: hoehle@zeus.gmd.de (Joerg Hoehle) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-reply-to: hoehle@zeus.gmd.de's message of Mon, 11 Dec 1995 17:02:38 +0100 Subject: Re: ADE snapshot 951208 available via ftp References: <199512111602.AA01317@diva.gmd.de> hoehle@zeus.gmd.de (Joerg Hoehle) writes: > Hi, > > Fred Fish writes: > > A complete source and binary snapshot of the Amiga Developers Environment > > (ADE) is now available on ftp.amigalib.com, in pub/amiga/ade/951208. The > > files ADE-README and ADE-CONTENTS contain information about the ADE and > > details of what is contained in the distribution, which is about 200 Mb. > > I just took a look at it and I'm now wondering what people _writing_ > software (i.e. non ports of existing FSF/UNIX software) must do to > enhance ADE. E.g., I just saw fifo-38.0 there and I'm wondering what > I have to do to release 38.1 there. > > Shall I write configure scripts? I've never done this and was happy > enough when existing scripts worked... Shall I write Installer > scripts? I've never done this either and it looks like it's going to > take me a lot of time where basically a few files only need to be > copied somewhere. FSF, and some other software uses autoconf. Autoconf is a tool that generates configure scripts, which you then ship with the distribution. When the package is installed, first thing the configure script is executed, and it generates Makefiles, possibly some include files, etc. This is great if you want to make the program easy compilable on different Unices. If Unix compatibility is not an issue (like for fifo.device), you don't win much by using autoconf, and besides, configure scripts usually requires a fairly unix-like environment to run, the dice environment is probably not enough. So in this case, I think the best way is to write the Makefiles manually (and perhaps an Installer script). Note that in any case, there's absolutely *no* use writing a configure script manually. /Niels Möller From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 21:04:02 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89336-1>; Mon, 11 Dec 1995 21:03:32 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tPDUK-0004nYC; Mon, 11 Dec 95 12:02 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Problems with libraries/mathieeesp.h (also for the README) To: kiskra@icslab3.icslab.agh.edu.pl (Kamil Iskra) Date: Mon, 11 Dec 1995 12:02:12 -0700 (MST) Cc: test1@MEDEW.ENTO.WAU.NL, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Dec 11, 95 01:32:02 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 945 > I think this is CBM programmers fault - they > created a special type - STRPTR - which was supposed to be used for > strings (have a look at ), but they most often just wrote > "char*" or "UBYTE*" in prototypes or structures difinitions! > ... > It is not our job to fix system headers - AT is repsponsible for this, and > I think they will simply HAVE TO do it. I first noticed inconsistencies in the system header files back in early 1986. Many of them could have been avoided if the original programming team had included someone with reasonable compiler tools experience and had cared about eliminating them and making everything type consistent. With the port to PPC, CBM has a great opportunity to clean up this mess. It could probably even be done now with the current header files if someone at AT cared enough to accept patches from the developer community and integrate them into the official header files. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 22:20:56 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <89729-3> convert rfc822-to-8bit; Mon, 11 Dec 1995 22:19:29 +0200 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 11 Dec 1995 21:19:20 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: re: Problems with libraries/mathieeesp.h (also for the README) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 11 Dec 1995, test1 wrote: ^^^^^ ? > PS: > Am I the only one getting some messages twice? > Those are exact duplicates, from and to addresses too. So it is not someone > sending to the list and another copy to me too. > Persons involved: Kamil, Joerg and Niels. What happens is that when you reply to a message, your mailer will more or less automatically create a To: line with the address of the one that wrote the letter and a Cc: line with the address of the mailing list. So you get one message directly from the sender and one indirectly from the list server. You should only receive one copy of this message as I removed your address from the To: field and moved the mailing list address from the Cc: field to the To: filed. Btw, if you don't like multiple messages with the same (or very similar) content, don't join the AMosaic mailing list. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 22:24:52 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <89900-2>; Mon, 11 Dec 1995 22:24:35 +0200 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 11 Dec 1995 21:24:26 +0100 (MET) From: Rask Lambertsen To: Christian Stieber Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Problems with libraries/mathieeesp.h (also for the README) In-Reply-To: <95Dec11.170122+0100mesz.395394-2+562@hphalle0.informatik.tu-muenchen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Dec 1995, Christian Stieber wrote: > Well, I get lots of warnings about all the places where I have to cast > the "const" away because AmigaOS headers never use that keyword. That's > really annoying, because turning that warning off means I no longer > see the real problems as well :( I know exactly what you mean :-( > > The most common problem is that of for example: > > DOSBase=OpenLibrary("dos.library",37L) > > LCC is bound to give an error on this one even without the -A option which > > will produce even more warnings/errors. Someone having the prototypes handy? > > This is because the above incorrect. It should be: > DOSBase=(struct DosLibrary *)OpenLibrary("dos.library",37L); Is that enough? What about DOSBase = (struct DosLibrary *) OpenLibrary ((UBYTE *) "dos.library", 37UL); Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Dec 11 22:33:09 1995 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <89592-3> convert rfc822-to-8bit; Mon, 11 Dec 1995 22:32:53 +0200 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 11 Dec 1995 21:32:48 +0100 (MET) From: Rask Lambertsen To: Olaf Seibert Cc: amiga-gcc-port@nic.funet.fi Subject: Re: bug reports for AT In-Reply-To: <199512111744.SAA06109@septimius.mbfys.kun.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 11 Dec 1995, Olaf Seibert wrote: > > Maybe mail Olaf Bartel and ask him (rhialto@(something).no)? > > I always get confused with the other Olaf. Weird. > Just for the record, it is rhialto@mbfys.kun.nl (Olaf Seibert). Aarrgghh! Which one of you is Olaf 'Olsen' ... then? When will the bug reports be given to AT and when can I start sending them (I have a few ones queued up)? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Dec 12 10:58:39 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89824-1>; Tue, 12 Dec 1995 10:33:27 +0200 Received: from ernie.icslab.agh.edu.pl by funet.fi with SMTP (PP); Tue, 12 Dec 1995 10:33:06 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id JAA04248; Tue, 12 Dec 1995 09:33:42 +0100 Date: Tue, 12 Dec 1995 09:33:41 +0100 (MET) From: Kamil Iskra Subject: re: Problems with libraries/mathieeesp.h (also for the README) To: Amiga GCC List In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Dec 1995, test1 wrote: > Joerg wrote: > > >Next problem: inconsistencies between autodocs and includes (can't > >remember where). Do you favour the includes because that's what's > >actually used or the autodocs because that's the law? > That is one I didn't know about. Do you have any examples which are fatal. There is quite a lot of these inconsistencies. You can often see "UWORD" parameter in autodocs and "ULONG" in includes, I even remember having seen a function that was supposed to return VOID in autodocs and some non-void type in includes. I don't think any of them can be fatal - after all, compiler only sees includes, so there are no ambiguities (sp?). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Tue Dec 12 11:51:17 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <89295-4>; Tue, 12 Dec 1995 11:49:38 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HYPU5TTR80004QOH@NET2.WAU.NL>; Tue, 12 Dec 1995 10:54:24 +0000 (GMT) Received: by vines2.wau.nl; Tue, 12 Dec 95 10:49:07 +0100 Date: Tue, 12 Dec 1995 10:42:14 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: re: Problems with libraries/mathieeesp.h (also for the README) To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Rask wrote: >On Mon, 11 Dec 1995, test1 wrote: > ^^^^^ ? I'm (ab)using my test account for this list so that it is kept out of my normal mailbox which is filled with other crap :) I prefer replies to this list and if you have to you can use my regular address which is: Joop.vandeWege@medew.ento.wau.nl The problem with the duplicates seems solved, and to avoid getting more questions about 'test1' I'll append a small signature file with name and e- mail address. Joop Joop.vandeWege@medew.ento.wau.nl From amiga-gcc-port-owner@nic.funet.fi Tue Dec 12 16:09:54 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <89309-4>; Tue, 12 Dec 1995 16:08:37 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id OAA12529 (8.7.2/7.5a-FAU);; Tue, 12 Dec 1995 14:53:15 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA13168; Tue, 12 Dec 1995 14:12:40 +0100 Date: Tue, 12 Dec 1995 14:12:40 +0100 Message-Id: <9512121312.AA13168@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: niklas@appli.se Cc: robert@lodz.pdi.net, fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <199512091141.MAA15911@linda.appli.se> (message from Niklas Hallqvist on Sat, 9 Dec 1995 12:41:29 +0100) Subject: Re: Alternative acronym to AIDE or ADE Hello What about an acronym show that there is an open system used. i.e.: Open Amiga Developer System = OADS Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Tue Dec 12 21:34:44 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89497-4>; Tue, 12 Dec 1995 21:30:08 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tPb0I-000RZLC; Tue, 12 Dec 95 21:08 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0dsk@wyst.hobby.nl>; Tue, 12 Dec 95 19:58:15 CET Message-Id: <9512121858.0dsk@wyst.hobby.nl> Date: Tue, 12 Dec 1995 19:58:12 +0000 (CET) In-Reply-To: <199512111701.AA01350@diva.gmd.de> from "Joerg Hoehle" at Dec 11, 95 06:01:29 pm Content-Type: text Content-Length: 1829 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Subject: Re: special Amiga GCC options According to Joerg Hoehle: > > I'm wondering if there's a description of special Amiga options that > have made their way into gcc, cc1, gas or ld. While I'm using them, I > only knew they existed by looking at the -v output or the specs file, > which I do not find a satisfactory situation. Where are -mshort-code, > -fdatabss-together etc. and all the others that I don't even know of > documented? Is anyone willing to create a nice AmigaGuide document on this? I can provide info on some of the options. What is also needed (especially with ixemul 42.0 and up) is documentation on: 1) installation and configuration of ixemul.library, including some history and background information. 2) more detailed information for programmers that use the library (special Amiga extensions and ixemul.trace, for example). 3) more information on the implementation of ixemul.library and how to compile it (special compile options, debugging). These documents should replace the README and README2 in the docs directory, originally written by Markus Wild, but a bit dated right now. I intend to write these myself when I have the time for it. But that may take quite awhile (I've more-or-less committed myself on porting gdb to the Amiga in the two weeks Christmas vacation. Hope this works out.) So, is there anyone else who can start on this? 1) and 2) can be written by anyone who has been working with ixemul for some time. Only the implementation details require a more thorough understanding of the library. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Dec 12 22:03:17 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89356-4>; Tue, 12 Dec 1995 21:59:31 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tPaqn-0004nZC; Tue, 12 Dec 95 12:58 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: special Amiga GCC options To: hans@wyst.hobby.nl (Hans Verkuil) Date: Tue, 12 Dec 1995 12:58:56 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9512121858.0dsk@wyst.hobby.nl> from "Hans Verkuil" at Dec 12, 95 07:58:12 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 260 > Is anyone willing to create a nice AmigaGuide document on this? I can > provide info on some of the options. Please do it as a texinfo document, which can be automatically processed to produce AmigaGuide format, HTML, PostScript, GNU info, DVI, etc. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Dec 13 02:07:20 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89515-2>; Wed, 13 Dec 1995 01:57:40 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tPf2Q-0004nYC; Tue, 12 Dec 95 17:27 MST Message-Id: Date: Tue, 12 Dec 95 17:27 MST From: fnf@amigalib.com (Fred Fish) To: amiga-gcc-port@nic.funet.fi, fnf@amigalib.com Newsgroups: comp.sys.amiga.applications,comp.sys.amiga.programmer Subject: Re: Emacs 19.25 Help References: <4achqq$mgv@moe.cc.utexas.edu> <9512122017.AA0011s@oregon.demon.co.uk> Reply-To: fnf@amigalib.com Organization: Amiga Library Services In article <9512122017.AA0011s@oregon.demon.co.uk>, Des Whewell wrote: >No I can't. I've sweat blood trying to get it to work with no luck. > >I got the release some time ago and was once in contact with David Gilbert, >who was trying to port it. Last January I rather painstakingly extracted the Amiga specific diffs from the 19.25 port and migrated them forward to 19.28. This took many days since the source for the Amiga port of 19.25 is apparently a mixture of files from several different 19.xx releases, which makes establishing a baseline version for each file (to diff against) pretty much trial and error. What I had to do was to diff the file against several different releases and the one with the smallest diff was assumed to be the baseline for that particular file. Quite messy. Anyway, David was never able to do much with the 19.28 diffs so they have pretty much sat neglected for the last year. I've considered trying to migrate them forward again to the lastest release (19.30) but don't really have the time right now. Using these diffs I was able to get a 19.28 version to the point where it would compile, link, dump it's tables, and then run as a predumped emacs. It was significantly more fragile than the 19.25 port at that time, but was much "cleaner" in the sense of minimizing differences from the baseline FSF code, and also having a well established baseline. Anyone that wants to take over and run with the existing diffs is welcome to do so. Send me email and I'll tell you where to ftp them from. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Dec 13 08:45:45 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <88948-2>; Wed, 13 Dec 1995 08:43:14 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tPkvT-0004nYC; Tue, 12 Dec 95 23:44 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Tk port - programmer wanted To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Tue, 12 Dec 1995 23:44:27 -0700 (MST) Cc: fnf@amigalib.com (Fred Fish) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 948 We are looking for someone to do a port of Tk for the Amiga, since we have a number of projects in mind that could make good use of such a port (gdbtk for example). I would expect that the bulk of the work would be to figure out where in tk to replace X11 function calls with native AmigaDOS or MUI function calls, and perhaps write some small pieces of trampoline code where the functions aren't quite functionally equivalent. Obviously the person doing the port should be very familiar with native AmigaDOS graphics and/or MUI, and ideally would have some experience with Tk and X11. It would also be a plus if he had ready access to a system already running Tk for comparison purposes. We can offer some compensation for this work, probably a fixed amount payable in installments at well specified milestones. Please email me if you are interested, and describe in detail why you think you are the right person for the job. Thanks! -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Dec 13 18:12:34 1995 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89747-2>; Wed, 13 Dec 1995 18:09:20 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA10189 (5.67b8/IDA-1.5 for ); Wed, 13 Dec 1995 17:09:00 +0100 Received: by diva.gmd.de with UUCP id AA01788 (5.67b8/IDA-1.5); Wed, 13 Dec 1995 17:05:13 +0100 Date: Wed, 13 Dec 1995 17:05:13 +0100 Message-Id: <199512131605.AA01788@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Cc: gnikl@informatik.uni-rostock.de Subject: "*" and CONSOLE: (Was: Re: Questions about README + various + misc) In-Reply-To: <9511222015.0bun@wyst.hobby.nl> References: <9511222015.0bun@wyst.hobby.nl> Hi, Hans Verkuil wrote: > > 6) Is ixemul using "*" or "CONSOLE:" for stderr, if no pr_CES? > After reports of problems with "CONSOLE:" I changed back to "*" for 42.0. > Apparently "*" and "CONSOLE:" are not the same after all. While writing fifolib38_1 which shall be released RSN and that few people here are testing, I found that console handlers are sent ACTION_FIND* packets with names of either "*" or "Console:", depending on what the user typed. Old handlers that do not recognize "CONSOLE:" will produce strange results which could explain the above problems. That's the reason why echo foo >* (beware of * expansion in a non-AmigaDOS shell) works in an Emacs shell buffer, whereas echo foo >console: won't with fifolib prior to version 38.1. I believe that programs opening stderr should continue to open "*" for compatibility reasons. Opening "CONSOLE:" first and "*" if it fails is _not_ a solution: for example, FIFO: (prior to 38.1) accepts the Open("CONSOLE:") call, giving a FIFO that can be neither read nor written to :-( We would get programs that work with CON:, FIFO:>38.1, KCON:, probably AUX: but that fail with other handlers : generall mess! I'll read the GURU book once again to see what it says on this topic. Shedding light on another part of DOS mistery, Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Dec 13 21:46:42 1995 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <89309-3>; Wed, 13 Dec 1995 21:45:15 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 13 Dec 95 13:38 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Wed, 13 Dec 95 13:31 MET Message-Id: Subject: Personal Project list To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 13 Dec 1995 13:31:17 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 445 after recent postings i had the idea of a personal project list to avoid double portings. you look at this list via http://www.uni-oldenburg.de/~u173034 click the relevat item (or others :) if you mail me you xmas projects (or what ever) before/while (freyday) i can integrate it, fr. evening i will leave for vacation. walter -- ----- "If heroes don't exist, it is necessary to invent them -- good for public morale!" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Dec 14 13:51:20 1995 Received: from ns.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with ESMTP id <89928-4>; Thu, 14 Dec 1995 13:44:44 +0200 Received: from wiedmann.neckar-alb.de (wiedmann@wiedmann.neckar-alb.de [194.77.119.253]) by ns.neckar-alb.de (8.7.1/8.7.1) with ESMTP id MAA25373 for ; Thu, 14 Dec 1995 12:42:19 +0100 (MET) Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id MAA00320 for amiga-gcc-port@lists.funet.fi; Thu, 14 Dec 1995 12:43:48 +0100 From: Jochen Wiedmann Message-Id: <199512141143.MAA00320@wiedmann.neckar-alb.de> Subject: Crosscompiler i586-unknown-linux - m68k-unknown-amigados To: amiga-gcc-port@nic.funet.fi Date: Thu, 14 Dec 1995 12:43:48 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, I'm sure, that one of you already did such a beast. Would it be possible to put it on a ftp server? Preferrably gcc-2.7.0 or even a later version, as I'd like to use exceptions. Regards, Jochen From amiga-gcc-port-owner@nic.funet.fi Thu Dec 14 16:09:42 1995 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <88987-4>; Thu, 14 Dec 1995 16:08:14 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA20132 (5.67b8/IDA-1.5 for ); Thu, 14 Dec 1995 15:07:22 +0100 Received: by diva.gmd.de with UUCP id AA02025 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Thu, 14 Dec 1995 15:03:19 +0100 Date: Thu, 14 Dec 1995 15:03:19 +0100 Message-Id: <199512141403.AA02025@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: questioning ixemul library version check in crt0.o Hi, I got pdksh-4.9 from Fred's ADE directory, but ixemul-41.4 from Aminet for there are ftp sites in Germany and I can get the binary versions that I need for my machines instead of the complete archive. But I was very annoyed at the "ixemul 41.5 required, 41.4 found, continue" requester. I find it kind of "dangerous" (for developers) to always bump the number checked for minor updates of a library. Developers are more likely to use the most recent version of a library than the user who gets a binary of a program requiring that shared library. I can remember threads in usenet where people complained about programs requiring MUI 3.0, AmiTCP-3.0, ixemul 40.x and others, when these libraries were not yet generally available and where the program might have worked as well with the older libraries. E.g. a simple recompilation (or even only relinking) of an old program will suddenly make it ixemul-41.5 only :-( Consequence: don't make crt0.o require the newest library. I think that crt0.o should only be updated when there are functions added to the library. This is for safety, even if probably most programs compiled will not use the new functions that caused the increase of the version number to check. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Thu Dec 14 16:45:08 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89658-3>; Thu, 14 Dec 1995 16:44:07 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tQFMv-0004nYC; Thu, 14 Dec 95 08:14 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Crosscompiler i586-unknown-linux - m68k-unknown-amigados To: wiedmann@Neckar-Alb.De (Jochen Wiedmann) Date: Thu, 14 Dec 1995 08:14:48 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199512141143.MAA00320@wiedmann.neckar-alb.de> from "Jochen Wiedmann" at Dec 14, 95 12:43:48 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 651 > I'm sure, that one of you already did such a beast. Would it be possible to > put it on a ftp server? Preferrably gcc-2.7.0 or even a later version, as > I'd like to use exceptions. This is on my TODO list, right after updating my current source base to the latest version of everything, and retesting with the bfd based linker. Using the bfd based linker will solve the endianess problem so that we don't have to maintain special patches to the older non-bfd linker. Somewhere in there we also have to add "linker flavor" support and "splitting of large reloc hunks" to the linker so we can finally retire the older non-bfd based linker. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Dec 14 17:05:03 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89397-2>; Thu, 14 Dec 1995 17:02:07 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tQFfI-0004nYC; Thu, 14 Dec 95 08:33 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: questioning ixemul library version check in crt0.o To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Thu, 14 Dec 1995 08:33:47 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199512141403.AA02025@diva.gmd.de> from "Joerg Hoehle" at Dec 14, 95 03:03:19 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 788 > I think that crt0.o should only be updated when there are functions > added to the library. This is for safety, even if probably most > programs compiled will not use the new functions that caused the > increase of the version number to check. Joerg has some good points about the revision number. After thinking about it some, I don't see any harm in having crt0.o only check the version number (40, 41, 42, ...) for a match and ignore the revision number as long as the version number is bumped each time new functions are added or an old function is retired and moved to the static library. I seem to recall some discussion about this in the past though that raised other concerns about not checking the revision number, but I can't seem to find them in my email archives. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Dec 14 17:15:02 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89440-1>; Thu, 14 Dec 1995 17:10:02 +0200 Received: from linux.quebec.berclain.com (actually user root@linux.quebec.berclain.com) by funet.fi with SMTP (PP); Thu, 14 Dec 1995 17:09:41 +0200 Received: from legue.quebec.berclain.com (legue.quebec.berclain.com [204.19.38.3]) by linux.quebec.berclain.com (8.6.11/8.6.12) with ESMTP id KAA07106 for ; Thu, 14 Dec 1995 10:11:46 -0500 Received: from wntyp ([204.19.38.30]) by legue.quebec.berclain.com (8.6.12/8.6.12) with SMTP id KAA28172 for ; Thu, 14 Dec 1995 10:17:39 -0500 Message-Id: <199512141517.KAA28172@legue.quebec.berclain.com> X-Sender: yanickp@hp800.berclain.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Dec 1995 10:10:22 -0500 To: amiga-gcc-port@nic.funet.fi From: Yanick Pelletier Subject: libc.a info Hello does any one know if a documentation of all function in the 'libc.a' exist, if so where i can find it? Thanks. ------------------------------------------------------------------ Yanick Pelletier Berclain Group Inc. (R&D Group) E-mail: pelletiery@berclain.com 979, de Bourgogne (suite 220) Tel : (418) 656-0055 ext. 1735 Sainte-Foy (Quebec) Canada Fax : (418) 654-0645 G1W 2L4 From amiga-gcc-port-owner@nic.funet.fi Thu Dec 14 17:32:30 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <89670-3>; Thu, 14 Dec 1995 17:28:45 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id KAA08394; Thu, 14 Dec 1995 10:26:45 -0500 (from cz253) Message-Id: <199512141526.KAA08394@kanga.INS.CWRU.Edu> Date: Thu, 14 Dec 1995 10:26:45 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: pelletiery@berclain.com Subject: Re: libc.a info Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from pelletiery@berclain.com of Thu, 14 Dec > >Hello does any one know if a documentation of all function in the 'libc.a' >exist, if so where i can find it? Most, if not all, are located in the man subdir tree of the ixemul distrib. .....Dave From amiga-gcc-port-owner@nic.funet.fi Thu Dec 14 18:26:03 1995 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89224-3>; Thu, 14 Dec 1995 18:24:47 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA04709 (5.67b8/IDA-1.5 for ); Thu, 14 Dec 1995 17:24:31 +0100 Received: by diva.gmd.de with UUCP id AA02111 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Thu, 14 Dec 1995 17:20:28 +0100 Date: Thu, 14 Dec 1995 17:20:28 +0100 Message-Id: <199512141620.AA02111@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: new inlines: one step beyond Hi, Prologue: I'm wondering whether anybody is using Kamil's macro-based inlines for C, as having function as macros disables the slightest external declaration, like: extern volatile void Alert(unsigned long); extern void CopyMem(void const *source, void *destination); Is nobody doing this? The fact that nobody complained shows that we can continue to enhance the macros, and that's what proposed here. Consider the current state: #define OpenLibrary(libName, version) \ LP2(0x228, struct Library *, OpenLibrary, UBYTE *, libName, a1, unsigned long, version, d0, \ struct ExecBase *, SysBase) #define LP2(offs, rt, name, t1, v1, r1, t2, v2, r2, bt, bn) \ ({ \ __inline rt name(t1 __n1, t2 __n2) \ { \ register rt _re __asm("d0"); \ register bt _bn __asm("a6") = (bn); \ register t1 _n1 __asm(#r1) = __n1; \ register t2 _n2 __asm(#r2) = __n2; \ __asm __volatile ("jsr a6@(-"#offs":W)" \ : "=r" (_re) \ : "r" (_bn), "r" (_n1), "r" (_n2) \ : "d0", "d1", "a0", "a1", "cc", "memory"); \ return _re; \ } \ name((v1), (v2)); \ }) These macros allow for a significant improvement in compilation speed and memory consumption, but this attempt at improving inlines went only half the way! Why not make everything a macro? Consider the following: #include #include #include #ifndef BASE_EXT_DECL #define BASE_EXT_DECL extern struct ExecBase * const SysBase; /* note const! */ #endif #ifndef BASE_NAME #define BASE_NAME SysBase #endif #define CloseLibrary(library) \ ({ BASE_EXT_DECL \ register struct Library *__CloseLibrary_a1 __asm("a1") = (library); \ register struct ExecBase *__CloseLibrary_a6 __asm("a6") = BASE_NAME; \ __asm volatile ("jsr a6@(-0x19e)" \ : /* no output */ \ : "r" (__CloseLibrary_a6), "r" (__CloseLibrary_a1) \ : "a0","a1","d0","d1"); /* ,"memory" removed */ \ }) #define OpenLibrary(libName, version) \ ({ BASE_EXT_DECL \ register UBYTE * __OpenLibrary_a1 __asm("a1") = (libName); \ register unsigned long __OpenLibrary_d0 __asm("d0") = (version); \ register struct ExecBase * __OpenLibrary_a6 __asm("a6") = BASE_NAME; \ register struct Library * __OpenLibrary_res __asm("d0"); \ __asm volatile ("jsr a6@(-0x228)" \ : "=r" (__OpenLibrary_res) \ : "r" (__OpenLibrary_a6), "r" (__OpenLibrary_a1), "r" (__OpenLibrary_d0) \ : "a0","a1","d0","d1" ,"memory"); \ __OpenLibrary_res; \ }) struct ExecBase * /* might be declared const as well */ SysBase; BOOL existsLibrary_1(char *name) { struct Library * temp; SysBase = *(struct ExecBase **) 4L; temp = OpenLibrary(name,0L); if (NULL == temp) CloseLibrary(temp); return (BOOL)temp; } BOOL existsLibrary_2(char *name) { struct Library * temp; temp = OpenLibrary(name,0L); if (NULL == temp) CloseLibrary(temp); return (BOOL)temp; } Advantages: 10) works even without optimization (hi Christian) 20) no more inline functions, thus works with C and C++(untested) 30) thus no more multiple inline directories 40) generates better code 50) finally permits reuse of library base register! (when using const declaration) Drawbacks: 01) warnings about casts and types less clear as the reference to the name of the called function disappears. However verbose variable names can be used instead. 02) as with all macros containing variables, variable name clashes with nested macro calls must be carefully examined. Not an advantage over current macros, but worth mentioning: 60) some type checking still possible, as local variables are initialized from the arguments. Ad 40): this might not be observable with inlines for OS-functions, but I've seen this with macro replacements of the strncmp() etc. functions in the inline/strsup.h file of libnix: Consider this example: if (strncmp(foo, bar, i) == 0) ...; else ...; I didn't bring code to show this, but I've observed that inline functions tend to generate code that'll jump to the common exit point of the inlined function and test the result again to do whatever the calling code says (execute then or else branch), whereas as macros, code that causes a premature stop (like the equivalent of if (i == 0) return 0; in a macro form) will directly jump to the appropriate then or else branch. Ad 50): gcc-2.5.8 -O1 output *00.00000034 _existsLibrary_2: 00.00000034 2f0e MOVE.L A6,-(A7) 00.00000036 2f02 MOVE.L D2,-(A7) 00.00000038 226f 000c MOVEA.L 000c(A7),A1 00.0000003c 7000 MOVEQ.L #00,D0 00.0000003e 2c79 _SysBase MOVEA.L _SysBase,A6 00.00000044 4eae fdd8 JSR fdd8(A6) 00.00000048 2400 MOVE.L D0,D2 00.0000004a 6606 BNE.B 00000052 00.0000004c 93c9 SUBA.L A1,A1 00.0000004e 4eae fe62 JSR fe62(A6) 00.00000052 3002 MOVE.W D2,D0 00.00000054 48c0 EXT.L D0 00.00000056 241f MOVE.L (A7)+,D2 00.00000058 2c5f MOVEA.L (A7)+,A6 00.0000005a 4e75 RTS _SysBase is not reloaded, resulting in a both a faster and smaller (less relocations) executables. Interestingly enough, _SysBase is reloaded in _existsLibrary_1, probably because it's being initialized despite of the const declaration, resulting in a warning (luckily not an error). I ran my test files through GCC-2.6.3 also (but not GCC-2.7.x), and I came to the conclusion that at least in all files that do not initialize a given library pointer, reloads of that pointer can be avoided by GCC. In the few files of a program that open a library and initialize its base pointer, reloading the base is compiler-dependent. It'll probably be reloaded for the current function, but might not be reloaded for other functions in the file. It's still better than the current situation. Luckily, the compilers did not generate errors when a base declared as const is initialized by an OpenLibrary() call. Just a warning, which is fine. I'm wondering why I didn't write this many years ago, as this technique has being used since as early as 1992 in Amiga-CLISP :-( Now I've to see if my macros can be turned into short and good-looking LP2()-like ones. A disadvantage of the LPxxx() approach is that unless somebody finds a way to expand the LPxxx() macro directly, you cannot selectively modify the library declaration like you could previously by defining your own BASE_EXT_DECL. This may not be necessary. I must also see if the typical macro variable name clash problem actually exists and if Kamil wants to integrate this into his work :) Yours, Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Thu Dec 14 23:15:10 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <89175-3> convert rfc822-to-8bit; Thu, 14 Dec 1995 23:13:50 +0200 Received: by bohr.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 14 Dec 1995 22:13:38 +0100 (MET) From: Rask Lambertsen To: Joerg Hoehle Cc: amiga-gcc-port@nic.funet.fi Subject: Re: new inlines: one step beyond In-Reply-To: <199512141620.AA02111@diva.gmd.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 14 Dec 1995, Joerg Hoehle wrote: > Hi, > > Prologue: > I'm wondering whether anybody is using Kamil's macro-based inlines for > C, as having function as macros disables the slightest external > declaration, like: > extern volatile void Alert(unsigned long); > extern void CopyMem(void const *source, void *destination); Yes, I use Kamil's macro-based inlines, an no, I don't make external declarations. Why on Earth should I? > The fact that nobody complained shows that we can continue to > enhance the macros, and that's what proposed here. [lots deleted] Fine with me, although I have one question: Will your proposed macros allow the use of local variables or structure elements as library bases? This is important to me as I'm trying to multitread SmartCopy and thus need non-global library bases. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 03:42:37 1995 Received: from asimov.cnam.fr ([163.173.128.6]) by nic.funet.fi with SMTP id <89413-3>; Fri, 15 Dec 1995 03:36:24 +0200 Received: from brunner.cnam.fr (brunner.cnam.fr [163.173.128.15]) by asimov.cnam.fr with ESMTP id CAA22026 (8.6.12/ for ); Fri, 15 Dec 1995 02:36:09 +0100 Received: by brunner.cnam.fr id CAA26225 (8.6.12/ for amiga-gcc-port@nic.funet.fi); Fri, 15 Dec 1995 02:36:09 +0100 Received: (from daniel@localhost) by brasil.frmug.fr.net (8.6.12/8.6.12) id BAA17150 for amiga-gcc-port@nic.funet.fi; Fri, 15 Dec 1995 01:39:34 +0100 From: Daniel Verite Message-Id: <199512150039.BAA17150@brasil.frmug.fr.net> Subject: Re: Crosscompiler i586-unknown-linux - m68k-unknown-amigados To: amiga-gcc-port@nic.funet.fi Date: Fri, 15 Dec 1995 01:39:34 +0100 (MET) In-Reply-To: from "Fred Fish" at Dec 14, 95 08:14:48 am X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1539 > This is on my TODO list, right after updating my current source base > to the latest version of everything, and retesting with the bfd based > linker. Using the bfd based linker will solve the endianess problem > so that we don't have to maintain special patches to the older non-bfd > linker. Somewhere in there we also have to add "linker flavor" support > and "splitting of large reloc hunks" to the linker so we can finally > retire the older non-bfd based linker. > -Fred I did such a 'special patch' to ld-1.8; I can mail/upload it, but of course, it would be better to switch to ld-2.5 if possible. BTW, I tried without success to build the new ld as a cross-linker (i486-linux => m68k-cbm-amigados), because of a problem related to includes. It occurs at least when compiling amigados.c, which needs to include headers from both the host's system include-tree (such as stdio.h), *and* the ixemul include tree (e.g. nlist.h). The problem is that these files do exist in both the trees; giving the priority to one include-directory against the other fails: either you get ixemul's nlist.h and stdio.h, or linux's nlist.h and stdio.h. It seems that it would require a construct looking like: #include_dir "/.../ixemul-includes" /* all subsequent includes should be searched first in the ixemul directory */ #include #include_dir "/usr/include" #include Quite simple, but I don't see how to make this scheme work using the preprocessor options/keywords. Any ideas ? Daniel -- daniel@brainstorm.cnam.fr os.h:102 BOOL CheckIO( struct IORequest *ioRequest ); ---end (snippet)--- Which is right? And what should I do to correct it? Thanks in advance. .....Dave From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 12:22:56 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <88947-1>; Fri, 15 Dec 1995 12:22:01 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA22629; Fri, 15 Dec 1995 11:23:27 +0100 Date: Fri, 15 Dec 1995 11:23:26 +0100 (MET) From: Kamil Iskra To: David Zaroski cc: amiga-gcc-port@nic.funet.fi Subject: Re: conflicting types... In-Reply-To: <199512150638.BAA15299@kanga.INS.CWRU.Edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 15 Dec 1995, David Zaroski wrote: > ---(snippet) /gnu/os-include/inline/exec.h:403 > > extern __inline struct IORequest * > CheckIO (BASE_PAR_DECL struct IORequest *ioRequest) > { > BASE_EXT_DECL > register struct IORequest * _res __asm("d0"); > register struct ExecBase *a6 __asm("a6") = BASE_NAME; > register struct IORequest *a1 __asm("a1") = ioRequest; > __asm __volatile ("jsr a6@(-0x1d4)" > : "=r" (_res) > : "r" (a6), "r" (a1) > : "a0","a1","d0","d1", "memory"); > return _res; > } > > ---end (snippet)--- > > ---(snippet) /gnu/os-include/clib/exec_protos.h:102 > > BOOL CheckIO( struct IORequest *ioRequest ); > > ---end (snippet)--- > > Which is right? And what should I do to correct it? Thanks in advance. I just checked how it is made in new inlines and it it "struct IORequest*". So "inline" is right. Inlines were generated from OS 3.1 include files. You must be using some older version, and it seems that CBM made a modification in CheckIO() return type. I think I've read about it somewhere, maybe in AutoDocs, but I can't check, because I'm sitting in front of IBM Xstation right now :-(. To correct it you should: 1. Get OS 3.1 includes (recommended). 2. Modify "clib/exec_protos.h", so that CheckIO() return type is "struct IORequest*" (not recommended). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 12:49:30 1995 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <89917-3>; Fri, 15 Dec 1995 12:48:26 +0200 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id LAA28365 (8.6.12/IDA-1.6); Fri, 15 Dec 1995 11:48:00 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA20929; Fri, 15 Dec 95 11:48:00 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9512151048.AA20929@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: new inlines: one step beyond To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Fri, 15 Dec 1995 11:47:59 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199512141620.AA02111@diva.gmd.de> from "Joerg Hoehle" at Dec 14, 95 05:20:28 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1683 > > I'm wondering whether anybody is using Kamil's macro-based inlines for > C, Yes, I do. > as having function as macros disables the slightest external > declaration, like: > extern volatile void Alert(unsigned long); > extern void CopyMem(void const *source, void *destination); > Is nobody doing this? No. Why should I use the header files and redeclare the functions locally? I'm lazy ;). [New macro proposal and problems with nested macros deleted] Another problem are register collisions of nested macros: Since the compiler reserves the register for the register variable as soon as it's declared two variable declarations with the same register will fail (think of a 'version' argument that needs a1, but a1 is already in use for the 'libName' parameter). This problem can be solved by reloading the variables a second time. I'm currently testing a bunch of macros that works similar to such a beast: #define OpenLibrary(libName, version) \ ({ UBYTE * __libName = (libName); \ unsigned long __version = (version); \ ({ \ register UBYTE * __OpenLibrary_a1 __asm("a1") = __libName; \ register unsigned long __OpenLibrary_d0 __asm("d0") = __version; \ register struct ExecBase * __OpenLibrary_a6 __asm("a6") = BASE_NAME; \ register struct Library * __OpenLibrary_res __asm("d0"); \ __asm volatile ("jsr a6@(-0x228)" \ : "=r" (__OpenLibrary_res) \ : "r" (__OpenLibrary_a6), "r" (__OpenLibrary_a1), "r" (__OpenLibrary_d0) \ : "a0","a1","d0","d1" ,"memory"); \ __OpenLibrary_res; \ }) \ }) And I didn't have any problems until now. Matthias From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 13:10:47 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89765-4>; Fri, 15 Dec 1995 13:09:47 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA26921; Fri, 15 Dec 1995 12:00:45 +0100 Date: Fri, 15 Dec 1995 12:00:45 +0100 (MET) From: Kamil Iskra To: Joerg Hoehle cc: amiga-gcc-port@nic.funet.fi Subject: Re: new inlines: one step beyond In-Reply-To: <199512141620.AA02111@diva.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 14 Dec 1995, Joerg Hoehle wrote: > #define OpenLibrary(libName, version) \ > ({ BASE_EXT_DECL \ > register UBYTE * __OpenLibrary_a1 __asm("a1") = (libName); \ > register unsigned long __OpenLibrary_d0 __asm("d0") = (version); \ > register struct ExecBase * __OpenLibrary_a6 __asm("a6") = BASE_NAME; \ > register struct Library * __OpenLibrary_res __asm("d0"); \ > __asm volatile ("jsr a6@(-0x228)" \ > : "=r" (__OpenLibrary_res) \ > : "r" (__OpenLibrary_a6), "r" (__OpenLibrary_a1), "r" (__OpenLibrary_d0) \ > : "a0","a1","d0","d1" ,"memory"); \ "memory" could be removed from this one, too. > __OpenLibrary_res; \ > }) > [snip] > Advantages: > 10) works even without optimization (hi Christian) So do "my" inlines, worse code is produced, though. > 20) no more inline functions, thus works with C and C++(untested) The problem with C++ are not inline functions (which are standard feature of this language and have been adopted to C, BTW), but local functions. I managed to solve this problem by defining local classes with static methods defined inside class body. However, G++ (at least version 2.7.0) has a bug that prevents it from inlining methods of local classes. I've notified G++ developers about it and when this bug is fixed, "inline++" directory will no longer be need - only new "macros" file will be required. > Luckily, the compilers did not generate errors when a base declared as > const is initialized by an OpenLibrary() call. Just a warning, which > is fine. Depends whether you like warnings or not. I hate them. Couldn't they be avoided by declaring the local variable holding library base as "const"? This mail was slightly longer, but I just received a mail from Matthias which was similar to mine, so I erased half of my own :-(. > I must also see if the typical macro variable name clash > problem actually exists and if Kamil wants to integrate this into his > work :) I'm opened to any suggestions and improvements. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 13:21:35 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <89277-4>; Fri, 15 Dec 1995 13:20:38 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA29006; Fri, 15 Dec 1995 12:21:25 +0100 Date: Fri, 15 Dec 1995 12:21:23 +0100 (MET) From: Kamil Iskra To: Matthias Fleischer cc: Joerg Hoehle , amiga-gcc-port@nic.funet.fi Subject: Re: new inlines: one step beyond In-Reply-To: <9512151048.AA20929@sunserv.IZFM.Uni-Stuttgart.DE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 15 Dec 1995, Matthias Fleischer wrote: > Another problem are register collisions of nested macros: > Since the compiler reserves the register for the register variable > as soon as it's declared two variable declarations with the same register > will fail (think of a 'version' argument that needs a1, but a1 > is already in use for the 'libName' parameter). > This problem can be solved by reloading the variables a second time. I'm > currently testing a bunch of macros that works similar to such a beast: > > #define OpenLibrary(libName, version) \ > ({ UBYTE * __libName = (libName); \ > unsigned long __version = (version); \ > ({ \ > register UBYTE * __OpenLibrary_a1 __asm("a1") = __libName; \ > register unsigned long __OpenLibrary_d0 __asm("d0") = __version; \ > register struct ExecBase * __OpenLibrary_a6 __asm("a6") = BASE_NAME; \ > register struct Library * __OpenLibrary_res __asm("d0"); \ > __asm volatile ("jsr a6@(-0x228)" \ > : "=r" (__OpenLibrary_res) \ > : "r" (__OpenLibrary_a6), "r" (__OpenLibrary_a1), "r" (__OpenLibrary_d0) \ > : "a0","a1","d0","d1" ,"memory"); \ > __OpenLibrary_res; \ > }) \ > }) > > And I didn't have any problems until now. Matthias, you are brilliant :-). I'll have a look at these inlines during the weekend - I wonder what is the quality of code. I hope they would also work with G++ - as of now I can't think of any reason why they shouldn't :-). The only disadvantage I can think of are warning messages when inappropriate arguments are passed - but I'll first have to have a look at it before complaining more :-). Am I right when I think that there wouldn't be need for "even newer inlines format"? All internal tricks are hidden in "LP" macros, so only (?) they would have to be rewritten, right? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 14:14:57 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89090-1>; Fri, 15 Dec 1995 14:13:38 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id MAA25706; Fri, 15 Dec 1995 12:07:02 GMT From: Lars Hecking Message-Id: <199512151208.MAA10889@mostar.nmrc.ucc.ie> Subject: Re: new inlines: one step beyond To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Fri, 15 Dec 1995 12:08:15 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Kamil Iskra" at Dec 15, 95 12:00:45 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1172 > The problem with C++ are not inline functions (which are standard feature > of this language and have been adopted to C, BTW), but local functions. I Inline functions have _not_ been adopted by C. This is a GNU C specific extension, which may or not be available from other _C_ compilers. Btw, did you ever try to compile code using your inlines with -ansi -pedantic ? Gives glint (*) the creeps ;)) Neither local, nor inline functions are allowed in ANSI/ISO C, but, as of yet, I'm not sure whether this issue is really relevant for Amiga programs. It might become important in the near future, tho' (portability). (*) glint: a "poor man's" version of lint (C program verifier), using gcc. This short script was posted to comp.lang.c.moderated a few days ago. #!/bin/sh # NAME glint # AUTHOR Richard A. O'Keefe # PURPOSE Use GCC to get as much checking as possible. # I want -O2 -Wall to catch uninitialised variables, but that means # I can't use -fsyntax-only. Hence the use of -c. exec gcc -c -ansi -pedantic -O2 -Wall -Dgets=DONT_USE_GETS -Dlint\ -Wtraditional -Wshadow -Wpointer-arith -Wnested-externs -Winline $@ From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 14:42:54 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <88976-1>; Fri, 15 Dec 1995 14:40:31 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA07635; Fri, 15 Dec 1995 13:42:04 +0100 Date: Fri, 15 Dec 1995 13:42:03 +0100 (MET) From: Kamil Iskra To: Lars Hecking cc: Amiga GCC List Subject: Re: new inlines: one step beyond In-Reply-To: <199512151208.MAA10889@mostar.nmrc.ucc.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 15 Dec 1995, Lars Hecking wrote: > > The problem with C++ are not inline functions (which are standard feature > > of this language and have been adopted to C, BTW), but local functions. I > > Inline functions have _not_ been adopted by C. This is a GNU C specific > extension, which may or not be available from other _C_ compilers. Yeah, you're right. I know about it, but I wanted to write it shortly. It should have been "and have been later adopted by many C compilers, BTW". > Btw, did you ever try to compile code using your inlines with > -ansi -pedantic ? Gives glint (*) the creeps ;)) Neither local, nor inline > functions are allowed in ANSI/ISO C, but, as of yet, I'm not sure whether > this issue is really relevant for Amiga programs. It might become important > in the near future, tho' (portability). Inline Amiga function calls cannot be made in full conformance (sp?) to ANSI/ISO C. It is basically a hack that uses quite a lot of GCC extensions and is not supposed to be portable. One uses "-ansi -pedantic" when [s]he wants to make sure that his/her source is portable. Of course, GCC inlines are not portable, so GCC generates error/warning messages. That's fine, I think. Other compiler will have its own way of accesing Amiga shared libraries, GCC inlines won't be used and everything will be fine. Or, if it won't be an Amiga compiler, it will refuse to compile the source because it won't find files - and that's fine, too, since a program that uses Amiga function calls is not portable. To sum it up: I think that using "-ansi -pedantic" for Amiga-specific sources is useless. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 17:01:08 1995 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <89198-2>; Fri, 15 Dec 1995 16:57:10 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA21083 (5.67b8/IDA-1.5 for ); Fri, 15 Dec 1995 15:56:36 +0100 Received: by diva.gmd.de with UUCP id AA02412 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Fri, 15 Dec 1995 15:52:43 +0100 Date: Fri, 15 Dec 1995 15:52:43 +0100 Message-Id: <199512151452.AA02412@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: new inlines: one step beyond In-Reply-To: References: <199512141620.AA02111@diva.gmd.de> Hi, Rask Lambertsen writes: > Fine with me, although I have one question: Will your proposed macros=20 > allow the use of local variables or structure elements as library bases?=20 Well, it doesn't only depend on my macros. My current scheme is to replace Kamil's LPxxx() macros in inline/macros.h with the new ones. Thus Kamil must change his fd2inline to generate something like #ifndef BASE_NAME #define BASE_NAME SysBase #endif #define OpenLibrary(libName, version) \ LP2(0x228, struct Library *, OpenLibrary, UBYTE *, libName, a1, unsigned long, version, d0, \ struct ExecBase *, BASE_NAME) instead of the current #define OpenLibrary(libName, version) \ LP2(0x228, struct Library *, OpenLibrary, UBYTE *, libName, a1, unsigned long, version, d0, \ struct ExecBase *, SysBase) I started replacing LPxxx() yesterday and the disassembly of say: void WaitMsg(Message *msg) { while (msg->mn_Node.ln_Type == NT_MESSAGE) Wait(1 << msg->mn_ReplyPort->mp_SigBit); Forbid(); Remove(&msg->mn_Node); Permit(); } looked extremely promising. SysBase was only loaded for Wait() and Forbid(). Why GCC didn't load it once only at the start I don't know. Matthias Fleischer writes: > Another problem are register collisions of nested macros: > Since the compiler reserves the register for the register variable > as soon as it's declared two variable declarations with the same register Good point, I didn't think about this. Your macro even increases the locality of the variables. > #define OpenLibrary(libName, version) \ > ({ UBYTE * __libName = (libName); \ > unsigned long __version = (version); \ You should use __OpenLibrary_libname here. > ({ \ > register UBYTE * __OpenLibrary_a1 __asm("a1") = __libName; \ Now you can simply use __a1 here, the name conflict can only be above. > And I didn't have any problems until now. That's fine. Kamil Iskra writes: > > #define OpenLibrary(libName, version) \ > > __asm volatile ("jsr a6@(-0x228)" \ ... > > : "a0","a1","d0","d1" ,"memory"); \ > "memory" could be removed from this one, too. In fact, "memory" _might_ be removed from many functions, as from the standpoint of a program opening a foreign library, its accessible memory space _might_ not change. By that I mean than even if somewhere in the Amiga, memory is certainly modified, it _probably_ won't occur in the range of addresses the program is using. But I would feel very uncomfortable about this. Removing it seems to work for any use of OpenLibrary() that comes to my mind now, but did I think about all of them? Even more important, how to generalize this to other functions? > > 10) works even without optimization (hi Christian) > So do "my" inlines, worse code is produced, though. Really? Not with GCC-2.5.8 -O2 then. but that's not a point. > > 20) no more inline functions, thus works with C and C++(untested) > The problem with C++ are not inline functions (which are standard feature > of this language and have been adopted to C, BTW), but local functions. I Ok, then no more local functions :) > > Luckily, the compilers did not generate errors when a base declared as > Depends whether you like warnings or not. I hate them. Couldn't they be > avoided by declaring the local variable holding library base as "const"? Yes, that's finally exactly what I did. The global definition does not contain const, but the local one in the macro does. Now I tested this with GCC-2.5.8 yesterday evening only, didn't have time for anything newer. Interestingly, GCC-2.5.8 only avoided reloading SysBase when there was another declaration of it outside the macro. Thus I added "extern struct ExecBase * SysBase;" (without const!) to my code. Not tested with local library bases. Kamil Iskra writes: > I'll have a look at these inlines during the weekend - I wonder what is > the quality of code. I hope they would also work with G++ - as of now I Don't expect much as after all, the inlines for libraries only produce a few moves and a jsr. Please test G++. > Am I right when I think that there wouldn't be need for "even newer > inlines format"? All internal tricks are hidden in "LP" macros, so only > (?) they would have to be rewritten, right? That's what's enough so far. What's currently unclear is the need for that "outside" declaration of the library base if you want to avoid reloading. It's not in any present source code that's not accessing the library structure, and adding an "extern struct ExecBase * SysBase;" in inline/exec.h might break local library bases (Well, maybe not, as this declaration doesn't imply that this variable is going to be used for the calls). I started changing macros.h already, Matthias too, so we should coordinate the work. Kamil Iskra writes: > Inline Amiga function calls cannot be made in full conformance (sp?) to > ANSI/ISO C. It is basically a hack that uses quite a lot of GCC extensions > and is not supposed to be portable. The macro replacements should work with lint, if it skips __asm(). The GCC manual says: `-pedantic' does not cause warning messages for use of the alternate keywords whose names begin and end with `__'. > One uses "-ansi -pedantic" when [s]he wants to make sure that his/her > source is portable. Of course, GCC inlines are not portable, so GCC Not for portability. Not to use outdated constructs. > To sum it up: I think that using "-ansi -pedantic" for Amiga-specific > sources is useless. I'm using gcc -Wall -O2 all day, -ansi as an option. It's not useless. Amiga-CLISP compiles fine with -Wall -Wpointer-arith and others. The manual also says: Some users try to use `-pedantic' to check programs for strict ANSI C conformance. They soon find that it does not do quite what they want: it finds some non-ANSI practices, but not all--only those for which ANSI C *requires* a diagnostic. Bye, Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 17:10:03 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89117-1>; Fri, 15 Dec 1995 17:06:16 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tQbgq-0004nYC; Fri, 15 Dec 95 08:04 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: conflicting types... To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Fri, 15 Dec 1995 08:04:51 -0700 (MST) Cc: cz253@cleveland.Freenet.Edu, amiga-gcc-port@nic.funet.fi In-Reply-To: from "Kamil Iskra" at Dec 15, 95 11:23:26 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 403 > Inlines were generated from OS 3.1 include files. You must be using some > older version, and it seems that CBM made a modification in CheckIO() > return type. > > I think I've read about it somewhere, maybe in AutoDocs, but I can't > check, because I'm sitting in front of IBM Xstation right now :-(. I just checked my copy of the CBM includes and "struct IORequest*" is the correct type. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 17:28:10 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89059-1>; Fri, 15 Dec 1995 17:25:03 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tQboS-0004nYC; Fri, 15 Dec 95 10:12 EST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Crosscompiler i586-unknown-linux - m68k-unknown-amigados To: daniel@brasil.brainstorm.cnam.fr (Daniel Verite) Date: Fri, 15 Dec 1995 08:12:44 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199512150039.BAA17150@brasil.frmug.fr.net> from "Daniel Verite" at Dec 15, 95 01:39:34 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1343 > I did such a 'special patch' to ld-1.8; I can mail/upload it, but of > course, it would be better to switch to ld-2.5 if possible. If the patch to ld-1.8 works transparently (so that the same source can be used to build both a native and a cross linker) then sure, send me the patches and I'll integrate them into the 1.8 base. I agree that the best longterm plan is to migrate to a current linker source base. > BTW, I tried without success to build the new ld as a cross-linker > (i486-linux => m68k-cbm-amigados), because of a problem related to > includes. I remember having some problems during a GNU ADA port many months ago when I had to build a cross compiler on linux to generate assembly code for a couple of modules that would not compile with the native ADA because of bugs in the native compiler. So it is quite possible that some host/target dependencies are not in the right files. On a native build it doesn't really matter, but it can kill a cross build pretty easily. > Quite simple, but I don't see how to make this scheme work using the > preprocessor options/keywords. Any ideas ? The first place to start would be to study exactly why a file that is intended to execute on the host needs to include a file from the target environment and work to eliminate this requirement, rather than patch around it. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 17:44:06 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89847-3>; Fri, 15 Dec 1995 17:42:20 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tQcGN-0004nZC; Fri, 15 Dec 95 08:41 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: new inlines: one step beyond To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Fri, 15 Dec 1995 08:41:35 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: from "Kamil Iskra" at Dec 15, 95 12:21:23 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 393 > The only disadvantage I can think of are warning messages when > inappropriate arguments are passed - but I'll first have to have a look at > it before complaining more :-). Why would this be a disadvantage, unless it is because the sloppy typing in the AmigaDOS header files has encouraged similar sloppy coding on the part of programmers and we need to support such legacy codes. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 19:14:01 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89527-1>; Fri, 15 Dec 1995 19:13:02 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 15 Dec 1995 18:12:51 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: More optimizations for m68k.c Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I've added some optimizations to m68k.c. It should now be much smarter when it comes to moving a constant into a data register. I think I may even have fixed the "clr.l dx instead of moveq.l #0,dx" bug that I posted about a while ago. It turns out that GCC represents 0 in two ways: As the special constant 0 (for which it generated clr.l x) and the general constant 0 (for which it correctly generates moveq.l #0,dx). I also fixed a typical "copy and paste (and forget to modify)" error in that file. If anybody want's to recompile GCC after applying the patch and tell me if it makes a difference, I'll be very happy. I can't recompile GCC myself (7 MHz '000 and 3 MB RAM). I'll also be happy to receive comments. The next thing I'll try to fix is the "I refuse to generate the move.b (ax)+,(ax)+ instruction" bug. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | --- m68k.c.orig Thu Aug 24 12:28:04 1995 +++ m68k.c Fri Dec 15 16:27:08 1995 @@ -1094,7 +1094,8 @@ } -typedef enum { MOVL, SWAP, NEGW, NOTW, NOTB, MOVQ } CONST_METHOD; +typedef enum { MOVL, SWAP, NEGW, NOTW, NOTB, MOVQ, ADDB, BCHG, + SUBQ } CONST_METHOD; use_movq (i) int i; @@ -1102,6 +1103,100 @@ return (i >= -128 && i <= 127); } +/* Return the value m in the following optimization: + move.l #i,dx -> moveq #m,dx + bchg.l dx,dx + This saves two bytes, but is only known to be faster on '000 and '010. + It is slower on '030. + Returns 0 if the optimization is not possible. + +int use_bchgl (i) + int i; +{ + /* The last i and m are cached for efficiency. */ + static int last_i = -32881, last_m = -113; + register int m; + + /* Check for a cache hit. */ + if (i == last_i) + return (last_m); + + switch (i) + { + case -32881: m = -113; break; + case -32849: m = -81; break; + case -32817: m = -49; break; + case -32785: m = -17; break; + case -16498: m = -114; break; + case -16466: m = -82; break; + case -16434: m = -50; break; + case -16402: m = -18; break; + case -8307: m = -115; break; + case -8275: m = -83; break; + case -8243: m = -51; break; + case -8211: m = -19; break; + case -4212: m = -116; break; + case -4180: m = -84; break; + case -4148: m = -52; break; + case -4116: m = -20; break; + case -2165: m = -117; break; + case -2133: m = -85; break; + case -2101: m = -53; break; + case -2069: m = -21; break; + case -1142: m = -118; break; + case -1110: m = -86; break; + case -1078: m = -54; break; + case -1046: m = -22; break; + case -631: m = -119; break; + case -599: m = -87; break; + case -567: m = -55; break; + case -535: m = -23; break; + case -376: m = -120; break; + case -344: m = -88; break; + case -312: m = -56; break; + case -280: m = -24; break; + case 264: m = 8; break; + case 296: m = 40; break; + case 328: m = 72; break; + case 360: m = 104; break; + case 521: m = 9; break; + case 553: m = 41; break; + case 585: m = 73; break; + case 617: m = 105; break; + case 1034: m = 10; break; + case 1066: m = 42; break; + case 1098: m = 74; break; + case 1130: m = 106; break; + case 2059: m = 11; break; + case 2091: m = 43; break; + case 2123: m = 75; break; + case 2155: m = 107; break; + case 4108: m = 12; break; + case 4140: m = 44; break; + case 4172: m = 76; break; + case 4204: m = 108; break; + case 8205: m = 13; break; + case 8237: m = 45; break; + case 8269: m = 77; break; + case 8301: m = 109; break; + case 16398: m = 14; break; + case 16430: m = 46; break; + case 16462: m = 78; break; + case 16494: m = 110; break; + case 32783: m = 15; break; + case 32815: m = 47; break; + case 32847: m = 79; break; + case 32897: m = 111; break; + + default: m = 0; break; + } + + last_i = i; + last_m = m; + + return m; +} + CONST_METHOD const_method (constant) rtx constant; @@ -1122,10 +1217,21 @@ /* This is the only value where neg.w is useful */ if (i == -65408) return NEGW; - /* Try also with swap */ + /* Try with add.b if u is even and u>>1 is in range of a moveq. */ u = i; + if ((u & 1) && use_movq (u >> 1)) + return ADDB; + /* Try with subq.l if i+8 is in range of a moveq. + Only for '000, '010, '020 and '030, slower on '040. */ + if ((TARGET_68000 || TARGET_68010 || TARGET_68020 || TARGET_68030) + && use_movq (i + 8)) + return SUBQ; + /* Try also with swap */ if (use_movq ((u >> 16) | (u << 16))) return SWAP; + /* Try with bchg.l. Only do this for '000 and '010. */ + if ((TARGET_68000 || TARGET_68010) && use_bchgl (i)) + return BCHG; /* Otherwise, use move.l */ return MOVL; } @@ -1142,7 +1248,11 @@ case NOTW : case NEGW : case SWAP : - /* Constants easily generated by moveq + not.b/not.w/neg.w/swap */ + case ADDB : + case BCHG : + case SUBQ : + /* Constants easily generated by moveq + not.b/not.w/neg.w/swap/ + add.b/bchg.l/subq.l */ return 1; case MOVL : return 2; @@ -1172,20 +1282,39 @@ return "moveq%.l %1,%0\n\tnot%.b %0"; #else return "moveq %1,%0\n\tnot%.b %0"; -#endif +#endif case NOTW : operands[1] = gen_rtx (CONST_INT, VOIDmode, i ^ 0xffff); #if defined (MOTOROLA) && !defined (CRDS) return "moveq%.l %1,%0\n\tnot%.w %0"; #else return "moveq %1,%0\n\tnot%.w %0"; -#endif +#endif case NEGW : #if defined (MOTOROLA) && !defined (CRDS) return "moveq%.l %#-128,%0\n\tneg%.w %0"; #else return "moveq %#-128,%0\n\tneg%.w %0"; -#endif +#endif + + case ADDB : + { + unsigned u = i; + + operands[1] = gen_rtx (CONST_INT, VOIDmode, u >> 1); +#if defined (MOTOROLA) && !defined (CRDS) + return "moveq%.l %1,%0\n\tadd%.b %0,%0"; +#else + return "moveq %1,%0\n\tadd%.b %0,%0"; +#endif + } + case SUBQ : + operands[1] = gen_rtx (CONST_INT, VOIDmode, -128 - i) +#if defined (MOTOROLA) && !defined (CRDS) + return "moveq%.l %1,%#-128\n\tsubq%.l %1,%0"; +#else + return "moveq %1,%#-128\n\tsubq%.l %1,%0"; +#endif case SWAP : { unsigned u = i; @@ -1195,8 +1324,15 @@ return "moveq%.l %1,%0\n\tswap %0"; #else return "moveq %1,%0\n\tswap %0"; -#endif +#endif } + case BCHG: + operands[1] = gen_rtx (CONST_INT, VOIDmode, use_bchg (i)); +#if defined (MOTOROLA) && !defined (CRDS) + return "moveq%.l %1,%0\n\tbchg%.l %0,%0"; +#else + return "moveq %1,%0\n\tbchg %0,%0"; +#endif case MOVL : return "move%.l %1,%0"; default : @@ -1221,7 +1357,11 @@ if (operands[1] != const0_rtx) return "move%.l %1,%0"; if (! ADDRESS_REG_P (operands[0])) - return "clr%.l %0"; +#ifdef defined (MOTOROLA) && !defined (CRDS) + return "moveq%.l %#0,%0"; +#else + return "moveq %#0,%0"; +#endif return "sub%.l %0,%0"; } @@ -2110,7 +2250,7 @@ '.' for dot needed in Motorola-style opcode names. '-' for an operand pushing on the stack: sp@-, -(sp) or -(%sp) depending on the style of syntax. - '+' for an operand pushing on the stack: + '+' for an operand popping off the stack: sp@+, (sp)+ or (%sp)+ depending on the style of syntax. '@' for a reference to the top word on the stack: sp@, (sp) or (%sp) depending on the style of syntax. From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 19:47:22 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89172-2>; Fri, 15 Dec 1995 19:46:12 +0200 Received: by colombo.telesys-innov.fr; Fri, 15 Dec 1995 18:44:07 GMT From: Philippe BRAND Message-Id: <199512151844.SAA22029@colombo.telesys-innov.fr> Subject: Re: More optimizations for m68k.c To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Fri, 15 Dec 1995 18:44:06 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Rask Lambertsen" at Dec 15, 95 06:12:51 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Rask Lambertsen writes: > If anybody want's to recompile GCC after applying the patch and tell me > if it makes a difference, I'll be very happy. I can't recompile GCC > myself (7 MHz '000 and 3 MB RAM). I'll patch my 2.7.2 gcc tonight and recompile it. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Dec 15 23:09:58 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <89348-2>; Fri, 15 Dec 1995 23:08:36 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tQhLD-0004nYC; Fri, 15 Dec 95 14:06 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: More optimizations for m68k.c To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Fri, 15 Dec 1995 14:06:54 -0700 (MST) Cc: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-Reply-To: <199512151844.SAA22029@colombo.telesys-innov.fr> from "Philippe BRAND" at Dec 15, 95 06:44:06 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 188 > I'll patch my 2.7.2 gcc tonight and recompile it. After you've gotten results from that, please let me know and I'll arrange to apply it here and rebuild the entire source tree. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Dec 16 00:36:41 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <89880-1>; Sat, 16 Dec 1995 00:31:39 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id WAA06790; Fri, 15 Dec 1995 22:29:54 GMT From: Lars Hecking Message-Id: <199512152231.WAA11671@mostar.nmrc.ucc.ie> Subject: Re: More optimizations for m68k.c To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Fri, 15 Dec 1995 22:31:07 +0000 (GMT) Cc: phb@colombo.telesys-innov.fr (Philippe Brand), amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Rask Lambertsen" at Dec 15, 95 06:12:51 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 935 > +/* Return the value m in the following optimization: > + move.l #i,dx -> moveq #m,dx > + bchg.l dx,dx > + This saves two bytes, but is only known to be faster on '000 and '010. > + It is slower on '030. > + Returns 0 if the optimization is not possible. Here's a missing */ > +int use_bchgl (i) > + int i; > + if ((TARGET_68000 || TARGET_68010 || TARGET_68020 || TARGET_68030) ... ... > + if ((TARGET_68000 || TARGET_68010) ... How are TARGET_68000, TARGET_68010 and TARGET_68030 defined? I can't really decipher the stuff in m68k.h. Actually, according the description in m68k.h they don't make much sense. Why not if ((!TARGET_68040 && !TARGET_68040_ONLY) ... and if ((!TARGET_68040 && !TARGET_68040_ONLY && !TARGET_68020) ... accordingly (I hope I got the logic behind it right ;) > +#ifdef defined (MOTOROLA) && !defined (CRDS) You mean: #if (defined ... && !defined ...) From amiga-gcc-port-owner@nic.funet.fi Sat Dec 16 00:59:01 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89426-4>; Sat, 16 Dec 1995 00:56:15 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 15 Dec 1995 23:56:07 +0100 (MET) From: Rask Lambertsen To: Amiga GCC List Subject: Re: More optimizations for m68k.c In-Reply-To: <199512152231.WAA11671@mostar.nmrc.ucc.ie> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 15 Dec 1995, Lars Hecking wrote: > > +/* Return the value m in the following optimization: > > + move.l #i,dx -> moveq #m,dx > > + bchg.l dx,dx > > + This saves two bytes, but is only known to be faster on '000 and '010. > > + It is slower on '030. > > + Returns 0 if the optimization is not possible. > > Here's a missing */ Where? ;-) > > +int use_bchgl (i) > > + int i; > > > + if ((TARGET_68000 || TARGET_68010 || TARGET_68020 || TARGET_68030) ... > ... > > + if ((TARGET_68000 || TARGET_68010) ... > > How are TARGET_68000, TARGET_68010 and TARGET_68030 defined? I can't > really decipher the stuff in m68k.h. > Actually, according the description in m68k.h they don't make much sense. I should be ashamed of myself. I didn't read m68k.h :-( But I will now. > Why not > > if ((!TARGET_68040 && !TARGET_68040_ONLY) ... > > and > > if ((!TARGET_68040 && !TARGET_68040_ONLY && !TARGET_68020) ... You forgot a !TARGET_68030, right? The idea is: If someone adds '060 support, it should still work. By work I mean that it won't output the code that is slower on '020, '030, '040 and most probably also slower on '060. > accordingly (I hope I got the logic behind it right ;) > > > +#ifdef defined (MOTOROLA) && !defined (CRDS) > > You mean: #if (defined ... && !defined ...) Yep. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Sat Dec 16 01:37:46 1995 Received: from septimius.mbfys.kun.nl ([131.174.83.52]) by nic.funet.fi with SMTP id <89301-3>; Sat, 16 Dec 1995 01:33:52 +0200 Received: from dontcare by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.82.78] with SMTP id AAA17859 (8.6.10/2.4); Sat, 16 Dec 1995 00:34:36 +0100 Date: Sat, 16 Dec 1995 00:34:36 +0100 From: Olaf Seibert Message-Id: <199512152334.AAA17859@septimius.mbfys.kun.nl> To: amiga-gcc-port@nic.funet.fi, hoehle@zeus.gmd.de Subject: Re: new inlines: one step beyond hoehle@zeus.gmd.de (Joerg Hoehle) wrote: > I started replacing LPxxx() yesterday and the disassembly of say: > void > WaitMsg(Message *msg) > { > while (msg->mn_Node.ln_Type == NT_MESSAGE) > Wait(1 << msg->mn_ReplyPort->mp_SigBit); > Forbid(); > Remove(&msg->mn_Node); > Permit(); > } > looked extremely promising. SysBase was only loaded for Wait() and > Forbid(). Why GCC didn't load it once only at the start I don't know. I suppose it does that because it correctly analyzes that there is a path to the Forbid() that doesn't execute the Wait(). So it can't assume that a6 is already loaded at that point. -Olaf. -- ___ Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved. \X/ You are not allowed to read this using any kind of Micro$oft product. From amiga-gcc-port-owner@nic.funet.fi Sat Dec 16 18:07:19 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <88929-1>; Sat, 16 Dec 1995 18:00:23 +0200 Received: from bastion.nmrc.ucc.ie (actually host nmrc.ucc.ie) by funet.fi with SMTP (PP); Sat, 16 Dec 1995 18:00:09 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id PAA15571; Sat, 16 Dec 1995 15:58:22 GMT From: Lars Hecking Message-Id: <199512161559.PAA12192@mostar.nmrc.ucc.ie> Subject: Re: More optimizations for m68k.c To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Sat, 16 Dec 1995 15:59:36 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Rask Lambertsen" at Dec 15, 95 11:56:07 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1872 > On Fri, 15 Dec 1995, Lars Hecking wrote: > > > > +/* Return the value m in the following optimization: > > > + move.l #i,dx -> moveq #m,dx > > > + bchg.l dx,dx > > > + This saves two bytes, but is only known to be faster on '000 and '010. > > > + It is slower on '030. > > > + Returns 0 if the optimization is not possible. XXXX----------------------------------------------------^ > > Here's a missing */ > > Where? ;-) After above comment. Running your patched m68k.c through cpp gracefully eliminates everything up to the end of the next comment in the following function, including the function definition ;)) > > > +int use_bchgl (i) > > > + int i; > > > > > + if ((TARGET_68000 || TARGET_68010 || TARGET_68020 || TARGET_68030) ... > > ... > > > + if ((TARGET_68000 || TARGET_68010) ... > > > > How are TARGET_68000, TARGET_68010 and TARGET_68030 defined? I can't > > really decipher the stuff in m68k.h. > > Actually, according the description in m68k.h they don't make much sense. > > I should be ashamed of myself. I didn't read m68k.h :-( But I will now. > > > Why not > > > > if ((!TARGET_68040 && !TARGET_68040_ONLY) ... > > > > and > > > > if ((!TARGET_68040 && !TARGET_68040_ONLY && !TARGET_68020) ... > > You forgot a !TARGET_68030, right? As of yet, there is no TARGET_68030. From m68k.h I gather that no such target is really necessary: - 68000 and 68010 are equal from a programmer's point of view - 68020 and 68030 introduce new modes/behaviour and are different from 68000/010, thus TARGET_68020 - 68040 is slightly different again, thus TARGET_68040 and TARGET_68040_ONLY Methinks that TARGET_68020 would also be used for 68030. Potentially, the same might apply for TARGET_68040 and 68060. But I'm not too familiar with too subtle differences between these CPU's. Anyone? From amiga-gcc-port-owner@nic.funet.fi Sat Dec 16 23:48:27 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89277-3>; Sat, 16 Dec 1995 23:47:01 +0200 Received: by colombo.telesys-innov.fr; Sat, 16 Dec 1995 22:45:01 GMT From: Philippe BRAND Message-Id: <199512162245.WAA26282@colombo.telesys-innov.fr> Subject: Re: More optimizations for m68k.c To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Sat, 16 Dec 1995 22:45:00 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199512161559.PAA12192@mostar.nmrc.ucc.ie> from "Lars Hecking" at Dec 16, 95 03:59:36 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Lars Hecking writes: > After above comment. Running your patched m68k.c through cpp gracefully > eliminates everything up to the end of the next comment in the following > function, including the function definition ;)) There was a few other typos. Here's correct diff below. I've as for now generate stage1 gcc using those diffs, all seems fine, I'm currently generating stage2 compiler. Could someone provide me an example program showing bugs mentionned ? Then I could add it to c-torture-tests. *** m68k.c.ok Sat Dec 16 00:36:04 1995 --- m68k.c Sat Dec 16 11:37:02 1995 *************** *** 1115,1119 **** ! typedef enum { MOVL, SWAP, NEGW, NOTW, NOTB, MOVQ } CONST_METHOD; use_movq (i) --- 1115,1120 ---- ! typedef enum { MOVL, SWAP, NEGW, NOTW, NOTB, MOVQ, ADDB, BCHG, ! SUBQ } CONST_METHOD; use_movq (i) *************** *** 1123,1126 **** --- 1124,1221 ---- } + /* Return the value m in the following optimization: + move.l #i,dx -> moveq #m,dx + bchg.l dx,dx + This saves two bytes, but is only known to be faster on '000 and '010. + It is slower on '030. + Returns 0 if the optimization is not possible. */ + + int use_bchgl (i) + int i; + { + /* The last i and m are cached for efficiency. */ + static int last_i = -32881, last_m = -113; + register int m; + + /* Check for a cache hit. */ + if (i == last_i) + return (last_m); + + switch (i) + { + case -32881: m = -113; break; + case -32849: m = -81; break; + case -32817: m = -49; break; + case -32785: m = -17; break; + case -16498: m = -114; break; + case -16466: m = -82; break; + case -16434: m = -50; break; + case -16402: m = -18; break; + case -8307: m = -115; break; + case -8275: m = -83; break; + case -8243: m = -51; break; + case -8211: m = -19; break; + case -4212: m = -116; break; + case -4180: m = -84; break; + case -4148: m = -52; break; + case -4116: m = -20; break; + case -2165: m = -117; break; + case -2133: m = -85; break; + case -2101: m = -53; break; + case -2069: m = -21; break; + case -1142: m = -118; break; + case -1110: m = -86; break; + case -1078: m = -54; break; + case -1046: m = -22; break; + case -631: m = -119; break; + case -599: m = -87; break; + case -567: m = -55; break; + case -535: m = -23; break; + case -376: m = -120; break; + case -344: m = -88; break; + case -312: m = -56; break; + case -280: m = -24; break; + case 264: m = 8; break; + case 296: m = 40; break; + case 328: m = 72; break; + case 360: m = 104; break; + case 521: m = 9; break; + case 553: m = 41; break; + case 585: m = 73; break; + case 617: m = 105; break; + case 1034: m = 10; break; + case 1066: m = 42; break; + case 1098: m = 74; break; + case 1130: m = 106; break; + case 2059: m = 11; break; + case 2091: m = 43; break; + case 2123: m = 75; break; + case 2155: m = 107; break; + case 4108: m = 12; break; + case 4140: m = 44; break; + case 4172: m = 76; break; + case 4204: m = 108; break; + case 8205: m = 13; break; + case 8237: m = 45; break; + case 8269: m = 77; break; + case 8301: m = 109; break; + case 16398: m = 14; break; + case 16430: m = 46; break; + case 16462: m = 78; break; + case 16494: m = 110; break; + case 32783: m = 15; break; + case 32815: m = 47; break; + case 32847: m = 79; break; + case 32897: m = 111; break; + + default: m = 0; break; + } + + last_i = i; + last_m = m; + + return m; + } + CONST_METHOD const_method (constant) *************** *** 1143,1150 **** if (i == -65408) return NEGW; ! /* Try also with swap */ u = i; if (use_movq ((u >> 16) | (u << 16))) return SWAP; /* Otherwise, use move.l */ return MOVL; --- 1238,1256 ---- if (i == -65408) return NEGW; ! /* Try with add.b if u is even and u>>1 is in range of a moveq. */ u = i; + if ((u & 1) && use_movq (u >> 1)) + return ADDB; + /* Try with subq.l if i+8 is in range of a moveq. + Only for '000, '010, '020 and '030, slower on '040. */ + if ((!TARGET_68040 && !TARGET_68040_ONLY) + && use_movq (i + 8)) + return SUBQ; + /* Try also with swap */ if (use_movq ((u >> 16) | (u << 16))) return SWAP; + /* Try with bchg.l. Only do this for '000 and '010. */ + if ((!TARGET_68040 && !TARGET_68040_ONLY && !TARGET_68020) && use_bchgl (i)) + return BCHG; /* Otherwise, use move.l */ return MOVL; *************** *** 1163,1167 **** case NEGW : case SWAP : ! /* Constants easily generated by moveq + not.b/not.w/neg.w/swap */ return 1; case MOVL : --- 1269,1277 ---- case NEGW : case SWAP : ! case ADDB : ! case BCHG : ! case SUBQ : ! /* Constants easily generated by moveq + not.b/not.w/neg.w/swap/ ! add.b/bchg.l/subq.l */ return 1; case MOVL : *************** *** 1206,1210 **** #else return "moveq %#-128,%0\n\tneg%.w %0"; ! #endif case SWAP : { --- 1316,1339 ---- #else return "moveq %#-128,%0\n\tneg%.w %0"; ! #endif ! ! case ADDB : ! { ! unsigned u = i; ! ! operands[1] = gen_rtx (CONST_INT, VOIDmode, u >> 1); ! #if defined (MOTOROLA) && !defined (CRDS) ! return "moveq%.l %1,%0\n\tadd%.b %0,%0"; ! #else ! return "moveq %1,%0\n\tadd%.b %0,%0"; ! #endif ! } ! case SUBQ : ! operands[1] = gen_rtx (CONST_INT, VOIDmode, -128 - i); ! #if defined (MOTOROLA) && !defined (CRDS) ! return "moveq%.l %1,%#-128\n\tsubq%.l %1,%0"; ! #else ! return "moveq %1,%#-128\n\tsubq%.l %1,%0"; ! #endif case SWAP : { *************** *** 1216,1221 **** #else return "moveq %1,%0\n\tswap %0"; ! #endif } case MOVL : return "move%.l %1,%0"; --- 1345,1357 ---- #else return "moveq %1,%0\n\tswap %0"; ! #endif } + case BCHG: + operands[1] = gen_rtx (CONST_INT, VOIDmode, use_bchgl (i)); + #if defined (MOTOROLA) && !defined (CRDS) + return "moveq%.l %1,%0\n\tbchg%.l %0,%0"; + #else + return "moveq %1,%0\n\tbchg %0,%0"; + #endif case MOVL : return "move%.l %1,%0"; *************** *** 1242,1246 **** return "move%.l %1,%0"; if (! ADDRESS_REG_P (operands[0])) ! return "clr%.l %0"; return "sub%.l %0,%0"; } --- 1378,1386 ---- return "move%.l %1,%0"; if (! ADDRESS_REG_P (operands[0])) ! #if defined (MOTOROLA) && !defined (CRDS) ! return "moveq%.l %#0,%0"; ! #else ! return "moveq %#0,%0"; ! #endif return "sub%.l %0,%0"; } -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sun Dec 17 00:28:45 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <88931-3>; Sun, 17 Dec 1995 00:24:33 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tR5fs-000QyLC; Sun, 17 Dec 95 00:05 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0e8b@wyst.hobby.nl>; Sat, 16 Dec 95 22:08:10 CET Message-Id: <9512162108.0e8b@wyst.hobby.nl> Date: Sat, 16 Dec 1995 22:08:08 +0000 (CET) Content-Type: text Content-Length: 2336 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Subject: README-2.7.2 corrections A few points for the README-2.7.2: First a spelling mistake: *** README-2.7.2 Sun Dec 10 13:34:24 1995 --- README-2.7.2.orig Sun Dec 10 13:18:43 1995 *************** *** 81,85 **** - no gccv, gcc is gccv now. - all programmes recompiled using 2.7.2 compiler. ! - new inlines headers. There are now two sets. The new ones are those mentioned as method 3 in the "Inline Header" section. - new ixemul library, v42.0 (complete distribution can be found on Aminet --- 81,85 ---- - no gccv, gcc is gccv now. - all programmes recompiled using 2.7.2 compiler. ! - new inlines headers. There is now two sets. The new ones are those mentioned as method 3 in the "Inline Header" section. - new ixemul library, v42.0 (complete distribution can be found on Aminet I found the paragraph on the copyright issues of ixemul a bit confusing: If you make a program that uses the ixemul.library, then your program is NOT covered under the GLGPL! The status of ixemul.library itself is more dubious: almost all sources are covered under the Berkeley copyright (most are straight from the BSD distribution), so how much legal force the GLGPL copyright has under these circumstances, and if we even want to use this, is doubtful. Concerning the use of CONSOLE: It was changed to CONSOLE: in 41.4, but after reports of problems with CONSOLE:, I reverted back to "*" for 42.0. Also note that you can always detach programs using 'run >nil: program'. You say in the README that that is somehow impossible. I think that the following two paragraphs should be removed as they are obsolete: ----------- The sys/types.h defined BPTR causing conflicts with Amiga includes. I removed the BPTR definition from sys/types.h and sys/proc.h. In GCC 2.3.3, there was no such definition either. I moved the ixemul.h file from include/ to the ixemlib/library/ directory. The ixemlib/ directory could contain the ixemul.library sources. In the ixemul source tree, ixemul.h is found in the library/ ----------- Cheers, Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sun Dec 17 00:34:05 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89336-1>; Sun, 17 Dec 1995 00:33:26 +0200 Received: by colombo.telesys-innov.fr; Sat, 16 Dec 1995 23:31:39 GMT From: Philippe BRAND Message-Id: <199512162331.XAA26400@colombo.telesys-innov.fr> Subject: Re: README-2.7.2 corrections To: hans@wyst.hobby.nl (Hans Verkuil) Date: Sat, 16 Dec 1995 23:31:38 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9512162108.0e8b@wyst.hobby.nl> from "Hans Verkuil" at Dec 16, 95 10:08:08 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hans Verkuil writes: > A few points for the README-2.7.2: Thanks. Rask: could you email me complete README for 2.7.2 ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sun Dec 17 02:31:09 1995 Received: from rumms.uni-mannheim.de ([134.155.50.52]) by nic.funet.fi with SMTP id <89090-2>; Sun, 17 Dec 1995 02:29:29 +0200 Received: from pips01.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA04814 (5.65c/IDA-1.4.4 for ); Sun, 17 Dec 1995 01:29:48 +0100 Received: from pips15.informatik.uni-mannheim.de by pips01.informatik.uni-mannheim.de (4.1/BelWue-1.1Sma2(subsidiary)) id AA09897; Sun, 17 Dec 95 01:25:40 +0100 Received: by pips15.informatik.uni-mannheim.de (5.0/SMI-SVR4) id AA26769; Sun, 17 Dec 1995 01:24:46 --100 From: opel@pips01.informatik.uni-mannheim.de (Steffen Opel) Message-Id: <9512170024.AA26769@pips15.informatik.uni-mannheim.de> Subject: Re: Questions for the README To: gc948374@gbar.dtu.dk (Rask Lambertsen) Date: Sun, 17 Dec 1995 01:24:45 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Rask Lambertsen" at Dec 7, 95 02:48:52 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 397 Salut Rask, > A new README will be ready later today. However, I have a few questions: Well, I'm always too late ;-) > 1) Who is the current Installer script maintainer? I simply forgot the > name (and e-mail address) of the maintainer, but someone recently took > over from Jochen Wiedmann, I remember. Should be me: Steffen Opel - opel@rummelplatz.uni-mannheim.de Ciao, Steffen Opel From amiga-gcc-port-owner@nic.funet.fi Sun Dec 17 03:37:46 1995 Received: from asimov.cnam.fr ([163.173.128.6]) by nic.funet.fi with SMTP id <89746-1>; Sun, 17 Dec 1995 03:36:27 +0200 Received: from brunner.cnam.fr (brunner.cnam.fr [163.173.128.15]) by asimov.cnam.fr with ESMTP id CAA05682 (8.6.12/ for ); Sun, 17 Dec 1995 02:36:01 +0100 Received: by brunner.cnam.fr id CAA08082 (8.6.12/ for amiga-gcc-port@nic.funet.fi); Sun, 17 Dec 1995 02:36:00 +0100 Received: (from daniel@localhost) by brasil.frmug.fr.net (8.6.12/8.6.12) id BAA20036 for amiga-gcc-port@nic.funet.fi; Sun, 17 Dec 1995 01:54:17 +0100 From: Daniel Verite Message-Id: <199512170054.BAA20036@brasil.frmug.fr.net> Subject: bfd linker (was: i586 cross-compiler) To: amiga-gcc-port@nic.funet.fi Date: Sun, 17 Dec 1995 01:54:17 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1229 fnf@amigalib.com (Fred Fish) writes: Fred> If the patch to ld-1.8 works transparently (so that the same Fred> source can be used to build both a native and a cross Fred> linker) then sure, send me the patches and I'll integrate It does. But I have myself to integrate it into the latest ld-1.8, because I worked on an old one. This will be done as soon as I can ftp the archive (I suppose it's on ftp.amigalib.com?), probably next week. Fred> The first place to start would be to study exactly why a Fred> file that is intended to execute on the host needs to Fred> include a file from the target environment and work to Fred> eliminate this requirement, rather than patch around it. Indeed, I changed some ixemul stuff for its bfd equivalent and it compiles fine now. But there are still several problems (one of them is that the amiga back-end does strongly rely on the host's endianness ;) But I've begun to fix it as much as I can and I plan to submit a patch in a few days. BTW, who is the current maintainer? Is Leonard still involved in the project? -- Daniel / From amiga-gcc-port-owner@nic.funet.fi Sun Dec 17 11:19:04 1995 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with SMTP id <88976-1>; Sun, 17 Dec 1995 11:18:08 +0200 Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.6.12/8.6.4) with ESMTP id LAA24356; Sun, 17 Dec 1995 11:17:58 +0200 Received: (will@localhost) by katiska.clinet.fi (8.6.12/8.6.4) id LAA06181; Sun, 17 Dec 1995 11:18:00 +0200 Date: Sun, 17 Dec 1995 11:18:00 +0200 Message-Id: <199512170918.LAA06181@katiska.clinet.fi> From: Ville-Pertti Keinonen To: hans@wyst.hobby.nl CC: amiga-gcc-port@nic.funet.fi In-reply-to: <9512162108.0e8b@wyst.hobby.nl> (hans@wyst.hobby.nl) Subject: Re: README-2.7.2 corrections I found the paragraph on the copyright issues of ixemul a bit confusing: If you make a program that uses the ixemul.library, then your program is NOT covered under the GLGPL! The status of ixemul.library itself is more There should be nothing confusing about the GLGPL, it basically states that the library in question has a license similar to the GPL, with the exception of binaries that are linked with the library and thus contain functions from the library; this kind of binaries are not covered. Basically, you can link a GLGPL'd library to anything. The case of ixemul might be slightly different in legal terms, since only the small static part is linked to the actual binaries. Thus, that is the only thing that needs to be GLGPL'd. Providing that ixemul is not distributed with the software that uses it, it is better covered by the GPL with a similar clarification as is present in the legal text for the Linux kernel; it states that calling kernel functions is considered normal use of the kernel and that programs doing this are not covered by the GPL. However, neither the GPL or the GLGPL would allow distribution of the actual library with proprietary software that uses it, since the ixemul.library is very different in nature from the type of library the GLGPL was designed for, since it can only be included in its complete form, which obviously leaves it covered by any licenses that apply to it and thus forbids (if I remember correctly, the GPL implies or states such a restriction) distribution along with other software that is not covered by a similar free license. Of course there would always be a way around this, by including the complete ixemul distribution (or as complete as required in order to satisfy the conditions of the GPL) as an obviously separate part of the distribution of the non-free software and stating that the sub-distribution of ixemul may be freely distributed. Anyhow, ixemul.library would probably need a slightly modified license, either allowing or forbidding use and/or distribution with non-GPL and non-free software. dubious: almost all sources are covered under the Berkeley copyright (most are straight from the BSD distribution), so how much legal force the GLGPL copyright has under these circumstances, and if we even want to use this, is doubtful. If someone has actual knowledge of what is correct concerning the license used in BSD-sources, I would also like to know. It seems very strange, I've read the license and understand what it says, but it is still not completely clear to me, what exactly is covered. In any case, ixemul authors are breaking the terms of the license. There should at least be documentation provided with any kind of distribution of the ixemul.library stating the terms of the BSD license and lack of warranty. The source distributions are OK, since they contain the notice in the sources. Binary distributions are not. What I'm not sure of concerning the BSD license is how it applies to libraries, when linked to your own program. As far as I can understand, the BSD license covers executables linked with it, since no exceptions are stated, as are in the GLGPL. This would probably not be completely destructive for development using BSD systems with their libraries, since Unix-type systems have lots of programs distributed as source code. However, eg. glibc contains code copyrighted to Berkeley (it also contains DEC, Sun and CMU (from Mach) code), yet I have noticed no mentions of less freedom to use those functions as linked parts of the library; the implication is that they may be used like the rest of glibc, which is GLGPL. What is true? From amiga-gcc-port-owner@nic.funet.fi Sun Dec 17 18:15:43 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89842-1> convert rfc822-to-8bit; Sun, 17 Dec 1995 18:14:10 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Sun, 17 Dec 1995 17:13:58 +0100 (MET) From: Rask Lambertsen To: Olaf Seibert Cc: amiga-gcc-port@nic.funet.fi, hoehle@zeus.gmd.de Subject: Re: new inlines: one step beyond In-Reply-To: <199512152334.AAA17859@septimius.mbfys.kun.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Sat, 16 Dec 1995, Olaf Seibert wrote: > hoehle@zeus.gmd.de (Joerg Hoehle) wrote: > > I started replacing LPxxx() yesterday and the disassembly of say: > > void > > WaitMsg(Message *msg) > > { > > while (msg->mn_Node.ln_Type == NT_MESSAGE) > > Wait(1 << msg->mn_ReplyPort->mp_SigBit); > > Forbid(); > > Remove(&msg->mn_Node); > > Permit(); > > } > > looked extremely promising. SysBase was only loaded for Wait() and > > Forbid(). Why GCC didn't load it once only at the start I don't know. > > I suppose it does that because it correctly analyzes that there is > a path to the Forbid() that doesn't execute the Wait(). So it can't > assume that a6 is already loaded at that point. No, but the question still is: Why didn't it just load it once at the start (before "while")? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Sun Dec 17 18:29:49 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89842-3> convert rfc822-to-8bit; Sun, 17 Dec 1995 18:28:45 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Sun, 17 Dec 1995 17:28:33 +0100 (MET) From: Rask Lambertsen To: Lars Hecking Cc: Amiga GCC List Subject: Re: More optimizations for m68k.c In-Reply-To: <199512161559.PAA12192@mostar.nmrc.ucc.ie> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Sat, 16 Dec 1995, Lars Hecking wrote: > > On Fri, 15 Dec 1995, Lars Hecking wrote: > > > > > > +/* Return the value m in the following optimization: > > > > + move.l #i,dx -> moveq #m,dx > > > > + bchg.l dx,dx > > > > + This saves two bytes, but is only known to be faster on '000 and '010. > > > > + It is slower on '030. > > > > + Returns 0 if the optimization is not possible. > > XXXX----------------------------------------------------^ > > > > Here's a missing */ > > > > Where? ;-) > > After above comment. Running your patched m68k.c through cpp gracefully > eliminates everything up to the end of the next comment in the following > function, including the function definition ;)) Hey, it was a joke - notice the smiley ;-) If the */ is missing, it can't be there, right? > As of yet, there is no TARGET_68030. From m68k.h I gather that no such target > is really necessary: > - 68000 and 68010 are equal from a programmer's point of view Not quite. The '010 has some new instructions (rtd is usefull to us, see TARGET_RTD) and the timing of some instructions have been improved (mul?.w and div?.w by a lot, clr.? no longer makes read accesses). > - 68020 and 68030 introduce new modes/behaviour and are different from > 68000/010, thus TARGET_68020 > - 68040 is slightly different again, thus TARGET_68040 and TARGET_68040_ONLY > > Methinks that TARGET_68020 would also be used for 68030. Potentially, the > same might apply for TARGET_68040 and 68060. But I'm not too familiar with > too subtle differences between these CPU's. Anyone? Some '040 instructions should be avoided on the '060, and maybe some instruction should come in a different order. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Sun Dec 17 19:07:10 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89824-3>; Sun, 17 Dec 1995 19:06:09 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Sun, 17 Dec 1995 18:06:02 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Re: More optimizations for m68k.c In-Reply-To: <199512162245.WAA26282@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 16 Dec 1995, Philippe BRAND wrote: > There was a few other typos. Here's correct diff below. [diff deleted] I could only find one typo (use_bchg -> use_bchgl) doing a visual diff. Maybe you could diff my old diff against your diff? I fixed that and removed TARGET_68030 from the this dif manually. > I've as for now generate stage1 gcc using those diffs, all seems fine, I'm > currently generating stage2 compiler. Could someone provide me an example ^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm sure it will fail. The assembler will be unhappy with some moveq.l #0, some_memory_address instructions (stupid me). This is fixed in my new diff. > program showing bugs mentionned ? Then I could add it to c-torture-tests. What is c-torture-tests? Where do I get it? FUNET? I'd very much like to provide some examples. Comparing the code from older compiler with the code from 2.7.2 with the diffs applied could be interesting. A new diff is appended below my signature. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | --- m68k.c.orig Thu Aug 24 12:28:04 1995 +++ m68k.c Sun Dec 17 16:53:37 1995 @@ -1094,7 +1094,8 @@ } -typedef enum { MOVL, SWAP, NEGW, NOTW, NOTB, MOVQ } CONST_METHOD; +typedef enum { MOVL, SWAP, NEGW, NOTW, NOTB, MOVQ, ADDB, BCHG, + SUBQ } CONST_METHOD; use_movq (i) int i; @@ -1102,6 +1103,100 @@ return (i >= -128 && i <= 127); } +/* Return the value m in the following optimization: + move.l #i,dx -> moveq #m,dx + bchg.l dx,dx + This saves two bytes, but is only known to be faster on '000 and '010. + It is slower on '030, and most likely also on '020, '040 and '060. + Returns 0 if the optimization is not possible. */ + +int use_bchgl (i) + int i; +{ + /* The last i and m are cached for efficiency. */ + static int last_i = -32881, last_m = -113; + register int m; + + /* Check for a cache hit. */ + if (i == last_i) + return (last_m); + + switch (i) + { + case -32881: m = -113; break; + case -32849: m = -81; break; + case -32817: m = -49; break; + case -32785: m = -17; break; + case -16498: m = -114; break; + case -16466: m = -82; break; + case -16434: m = -50; break; + case -16402: m = -18; break; + case -8307: m = -115; break; + case -8275: m = -83; break; + case -8243: m = -51; break; + case -8211: m = -19; break; + case -4212: m = -116; break; + case -4180: m = -84; break; + case -4148: m = -52; break; + case -4116: m = -20; break; + case -2165: m = -117; break; + case -2133: m = -85; break; + case -2101: m = -53; break; + case -2069: m = -21; break; + case -1142: m = -118; break; + case -1110: m = -86; break; + case -1078: m = -54; break; + case -1046: m = -22; break; + case -631: m = -119; break; + case -599: m = -87; break; + case -567: m = -55; break; + case -535: m = -23; break; + case -376: m = -120; break; + case -344: m = -88; break; + case -312: m = -56; break; + case -280: m = -24; break; + case 264: m = 8; break; + case 296: m = 40; break; + case 328: m = 72; break; + case 360: m = 104; break; + case 521: m = 9; break; + case 553: m = 41; break; + case 585: m = 73; break; + case 617: m = 105; break; + case 1034: m = 10; break; + case 1066: m = 42; break; + case 1098: m = 74; break; + case 1130: m = 106; break; + case 2059: m = 11; break; + case 2091: m = 43; break; + case 2123: m = 75; break; + case 2155: m = 107; break; + case 4108: m = 12; break; + case 4140: m = 44; break; + case 4172: m = 76; break; + case 4204: m = 108; break; + case 8205: m = 13; break; + case 8237: m = 45; break; + case 8269: m = 77; break; + case 8301: m = 109; break; + case 16398: m = 14; break; + case 16430: m = 46; break; + case 16462: m = 78; break; + case 16494: m = 110; break; + case 32783: m = 15; break; + case 32815: m = 47; break; + case 32847: m = 79; break; + case 32897: m = 111; break; + + default: m = 0; break; + } + + last_i = i; + last_m = m; + + return m; +} + CONST_METHOD const_method (constant) rtx constant; @@ -1122,10 +1217,21 @@ /* This is the only value where neg.w is useful */ if (i == -65408) return NEGW; - /* Try also with swap */ + /* Try with add.b if u is even and u>>1 is in range of a moveq. */ u = i; + if ((u & 1) && use_movq (u >> 1)) + return ADDB; + /* Try with subq.l if i+8 is in range of a moveq. + Only for '000, '010, '020 and '030, slower on '040. */ + if ((! TARGET_68040 && !TARGET_68040_ONLY) && use_movq (i + 8)) + return SUBQ; + /* Try also with swap */ if (use_movq ((u >> 16) | (u << 16))) return SWAP; + /* Try with bchg.l. Only do this for '000 and '010. */ + if ((!TARGET_68020 && !TARGET_68040 && !TARGET_68040_ONLY) + && use_bchgl (i)) + return BCHG; /* Otherwise, use move.l */ return MOVL; } @@ -1142,7 +1248,11 @@ case NOTW : case NEGW : case SWAP : - /* Constants easily generated by moveq + not.b/not.w/neg.w/swap */ + case ADDB : + case BCHG : + case SUBQ : + /* Constants easily generated by moveq + not.b/not.w/neg.w/swap/ + add.b/bchg.l/subq.l */ return 1; case MOVL : return 2; @@ -1172,20 +1282,39 @@ return "moveq%.l %1,%0\n\tnot%.b %0"; #else return "moveq %1,%0\n\tnot%.b %0"; -#endif +#endif case NOTW : operands[1] = gen_rtx (CONST_INT, VOIDmode, i ^ 0xffff); #if defined (MOTOROLA) && !defined (CRDS) return "moveq%.l %1,%0\n\tnot%.w %0"; #else return "moveq %1,%0\n\tnot%.w %0"; -#endif +#endif case NEGW : #if defined (MOTOROLA) && !defined (CRDS) return "moveq%.l %#-128,%0\n\tneg%.w %0"; #else return "moveq %#-128,%0\n\tneg%.w %0"; -#endif +#endif + + case ADDB : + { + unsigned u = i; + + operands[1] = gen_rtx (CONST_INT, VOIDmode, u >> 1); +#if defined (MOTOROLA) && !defined (CRDS) + return "moveq%.l %1,%0\n\tadd%.b %0,%0"; +#else + return "moveq %1,%0\n\tadd%.b %0,%0"; +#endif + } + case SUBQ : + operands[1] = gen_rtx (CONST_INT, VOIDmode, -128 - i) +#if defined (MOTOROLA) && !defined (CRDS) + return "moveq%.l %1,%#-128\n\tsubq%.l %1,%0"; +#else + return "moveq %1,%#-128\n\tsubq%.l %1,%0"; +#endif case SWAP : { unsigned u = i; @@ -1195,8 +1324,15 @@ return "moveq%.l %1,%0\n\tswap %0"; #else return "moveq %1,%0\n\tswap %0"; -#endif +#endif } + case BCHG: + operands[1] = gen_rtx (CONST_INT, VOIDmode, use_bchgl (i)); +#if defined (MOTOROLA) && !defined (CRDS) + return "moveq%.l %1,%0\n\tbchg%.l %0,%0"; +#else + return "moveq %1,%0\n\tbchg %0,%0"; +#endif case MOVL : return "move%.l %1,%0"; default : @@ -1220,9 +1356,16 @@ return output_move_const_into_data_reg (operands); if (operands[1] != const0_rtx) return "move%.l %1,%0"; - if (! ADDRESS_REG_P (operands[0])) + if (DATA_REG_P (operands[0])) +#if defined (MOTOROLA) && !defined (CRDS) + return "moveq%.l %#0,%0"; +#else + return "moveq %#0,%0"; +#endif + else if (ADDRESS_REG_P (operands[0])) + return "sub%.l %0,%0"; + else return "clr%.l %0"; - return "sub%.l %0,%0"; } @@ -2110,7 +2253,7 @@ '.' for dot needed in Motorola-style opcode names. '-' for an operand pushing on the stack: sp@-, -(sp) or -(%sp) depending on the style of syntax. - '+' for an operand pushing on the stack: + '+' for an operand popping off the stack: sp@+, (sp)+ or (%sp)+ depending on the style of syntax. '@' for a reference to the top word on the stack: sp@, (sp) or (%sp) depending on the style of syntax. From amiga-gcc-port-owner@nic.funet.fi Sun Dec 17 20:42:03 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89621-3>; Sun, 17 Dec 1995 20:40:49 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Sun, 17 Dec 1995 19:40:39 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Re: README-2.7.2 corrections In-Reply-To: <9512162108.0e8b@wyst.hobby.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 16 Dec 1995, Hans Verkuil wrote: > A few points for the README-2.7.2: > > First a spelling mistake: > > *** README-2.7.2 Sun Dec 10 13:34:24 1995 > --- README-2.7.2.orig Sun Dec 10 13:18:43 1995 > *************** > *** 81,85 **** > - no gccv, gcc is gccv now. > - all programmes recompiled using 2.7.2 compiler. > ! - new inlines headers. There are now two sets. The new ones are those > mentioned as method 3 in the "Inline Header" section. > - new ixemul library, v42.0 (complete distribution can be found on Aminet > --- 81,85 ---- > - no gccv, gcc is gccv now. > - all programmes recompiled using 2.7.2 compiler. > ! - new inlines headers. There is now two sets. The new ones are those > mentioned as method 3 in the "Inline Header" section. > - new ixemul library, v42.0 (complete distribution can be found on Aminet I had that one fixed in the copy of the README that I work on. There is one more spelling mistake on that line, it should be - new inline headers. There is now two sets. The new ones are those > I found the paragraph on the copyright issues of ixemul a bit confusing: What paragraph? There is no such thing in the README. > If you make a program that uses the ixemul.library, then your program is > NOT covered under the GLGPL! The status of ixemul.library itself is more > dubious: almost all sources are covered under the Berkeley copyright (most > are straight from the BSD distribution), so how much legal force the GLGPL > copyright has under these circumstances, and if we even want to use this, > is doubtful. I'm confused about that too. Does anybody want to shed some light on this? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Sun Dec 17 20:51:50 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89307-3> convert rfc822-to-8bit; Sun, 17 Dec 1995 20:50:52 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Sun, 17 Dec 1995 19:50:38 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: "patch" oddity Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I just tried using patch and found that it creates temporary file in "/tmp/". Is this a bug or an oversight? Shouldn't it use the TMPDIR environment variable to decide where temporary files should be put? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 00:37:38 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89031-4>; Mon, 18 Dec 1995 00:30:54 +0200 Received: by colombo.telesys-innov.fr; Sun, 17 Dec 1995 23:29:10 GMT From: Philippe BRAND Message-Id: <199512172329.XAA29515@colombo.telesys-innov.fr> Subject: Gcc-2.7.2 C/C++/Objc beta available To: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) Date: Sun, 17 Dec 1995 23:29:09 +0000 (WET) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Beta available on both my site and funet.fi. Integrate latest changes by Rask about m68k.c. Please test as much as possible, and report necessary changes, specs, etc.. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 00:37:53 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89847-3>; Mon, 18 Dec 1995 00:33:39 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tRSIQ-000RdbC; Mon, 18 Dec 95 00:15 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0efs@wyst.hobby.nl>; Sun, 17 Dec 95 22:15:17 CET Message-Id: <9512172115.0efs@wyst.hobby.nl> Date: Sun, 17 Dec 1995 22:15:14 +0000 (CET) In-Reply-To: from "Rask Lambertsen" at Dec 17, 95 07:40:39 pm Content-Type: text Content-Length: 1118 From: hans@wyst.hobby.nl (Hans Verkuil) To: gc948374@gbar.dtu.dk Cc: amiga-gcc-port@nic.funet.fi Subject: Re: README-2.7.2 corrections Hi Rask, > I had that one fixed in the copy of the README that I work on. There is one > more spelling mistake on that line, it should be > > - new inline headers. There is now two sets. The new ones are those You mean of course: - new inline headers. There are now two sets. The new ones are those > What paragraph? There is no such thing in the README. In the section Ixemul vs Libnix: * It is not copyrighted by the FSF. Therefore you neither need to include sources nor objects together with your executable. (read the GLGPL _before_ flaming on this statement) This implies that anything that uses ixemul is automatically also covered by the GLGPL, which isn't true. > I'm confused about that too. Does anybody want to shed some light on this? See the docs/README in the ixemul distribution. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 02:33:02 1995 Received: from ns.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with ESMTP id <89097-1>; Mon, 18 Dec 1995 02:31:11 +0200 Received: from wiedmann.neckar-alb.de (wiedmann@wiedmann.neckar-alb.de [194.77.119.253]) by ns.neckar-alb.de (8.7.1/8.7.1) with ESMTP id BAA14884; Mon, 18 Dec 1995 01:28:49 +0100 (MET) Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id BAA01173; Mon, 18 Dec 1995 01:30:17 +0100 From: Jochen Wiedmann Message-Id: <199512180030.BAA01173@wiedmann.neckar-alb.de> Subject: Re: Gcc-2.7.2 C/C++/Objc beta available To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Mon, 18 Dec 1995 01:30:17 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199512172329.XAA29515@colombo.telesys-innov.fr> from "Philippe BRAND" at Dec 17, 95 11:29:09 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit > > Beta available on both my site and funet.fi. Integrate latest changes > by Rask about m68k.c. Please test as much as possible, and report necessary > changes, specs, etc.. How about diffs? From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 03:03:55 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89295-4>; Mon, 18 Dec 1995 03:03:05 +0200 Received: from undergrad.math.uwaterloo.ca (actually user root@undergrad.math.uwaterloo.ca) by funet.fi with SMTP (PP); Mon, 18 Dec 1995 03:02:37 +0200 Received: from cnts1p33.uwaterloo.ca (jsshephe@cnts1p33.uwaterloo.ca [129.97.112.33]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with SMTP id UAA21197; Sun, 17 Dec 1995 20:02:27 -0500 Date: Sun, 17 Dec 1995 20:03:00 -0500 (EST) From: Jeff Shepherd X-Sender: jsshephe@cnts1p33.uwaterloo.ca To: Ixemul Library Maintainers cc: Amiga-Gcc List Subject: Autodocs for inet.library Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone have the autodocs for inet.library specifically the inherit() function they could send me? The reason I need it is that for programs started by inetd from AS225 I need to call inherit() to get the socket. This is the last part of seemless daemon handling for ixemul.library. --- Sig blew up, time to get another--- jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 13:18:18 1995 Received: from icslab5.icslab.agh.edu.pl ([149.156.98.5]) by nic.funet.fi with SMTP id <88979-3>; Mon, 18 Dec 1995 13:16:30 +0200 Received: (from kiskra@localhost) by icslab5.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA00622; Mon, 18 Dec 1995 12:18:02 +0100 Date: Mon, 18 Dec 1995 12:17:59 +0100 (MET) From: Kamil Iskra To: Fred Fish cc: Amiga GCC mailing list Subject: Re: new inlines: one step beyond In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 15 Dec 1995, Fred Fish wrote: > > The only disadvantage I can think of are warning messages when > > inappropriate arguments are passed - but I'll first have to have a look at > > it before complaining more :-). > > Why would this be a disadvantage, unless it is because the sloppy > typing in the AmigaDOS header files has encouraged similar sloppy > coding on the part of programmers and we need to support such > legacy codes. Sorry, this is all because of my poor English and hurrying all the time :-(. I meant that warning messages will be less clear - they won't include function name. But I checked it, and they are clear enough. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 13:25:09 1995 Received: from icslab5.icslab.agh.edu.pl ([149.156.98.5]) by nic.funet.fi with SMTP id <89248-4>; Mon, 18 Dec 1995 13:24:12 +0200 Received: (from kiskra@localhost) by icslab5.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA00615; Mon, 18 Dec 1995 12:14:10 +0100 Date: Mon, 18 Dec 1995 12:14:06 +0100 (MET) From: Kamil Iskra To: Joerg Hoehle cc: amiga-gcc-port@nic.funet.fi Subject: Re: new inlines: one step beyond In-Reply-To: <199512151452.AA02412@diva.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 15 Dec 1995, Joerg Hoehle wrote: > Thus Kamil must change his fd2inline to generate something like > #ifndef BASE_NAME > #define BASE_NAME SysBase > #endif > #define OpenLibrary(libName, version) \ > LP2(0x228, struct Library *, OpenLibrary, UBYTE *, libName, a1, unsigned long, version, d0, \ > struct ExecBase *, BASE_NAME) I'm sorry, but this won't work. Macros are expanded at the place of their call, thus BASE_NAME will be expanded there, not while reading . If you include more that one header, BASE_NAME definitions will conflict. I personally prefer the current way of changing library base - #defining library base name. However, this is impossible for things like "IntuitionBase", since its type's name is exactly the same. What would be possible is defining things like INTUITION_BASE_NAME, EXEC_BASE_NAME and so on. This is much less intuitive, though. What do you think about it? > I started replacing LPxxx() yesterday and the disassembly of say: > void > WaitMsg(Message *msg) > { > while (msg->mn_Node.ln_Type == NT_MESSAGE) > Wait(1 << msg->mn_ReplyPort->mp_SigBit); > Forbid(); > Remove(&msg->mn_Node); > Permit(); > } > looked extremely promising. Yeah, I made some tests, too, and it was all great. Better code when no optimizing and no "a6" reloading when library base pointer is declared const. > > #define OpenLibrary(libName, version) \ > > ({ UBYTE * __libName = (libName); \ > > unsigned long __version = (version); \ > You should use __OpenLibrary_libname here. I don't agree. These variables are defined in local scope (note leading "{"), so their names may be the same as names of some variables from outside scope. I even tested it with recursive calls (parameter of one function call was function call to the same function). > In fact, "memory" _might_ be removed from many functions, as from the > standpoint of a program opening a foreign library, its accessible > memory space _might_ not change. By that I mean than even if somewhere > in the Amiga, memory is certainly modified, it _probably_ won't occur > in the range of addresses the program is using. But I would feel very > uncomfortable about this. Removing it seems to work for any use of > OpenLibrary() that comes to my mind now, but did I think about all of > them? Even more important, how to generalize this to other > functions? Luckily, with these improved inlines there won't be need for removing of "memory" clobering. It would be rather nasty, I agree. > > I'll have a look at these inlines during the weekend - I wonder what is > > the quality of code. I hope they would also work with G++ - as of now I > Don't expect much as after all, the inlines for libraries only produce > a few moves and a jsr. Please test G++. I tested it. Works fine, or almost fine - it generates errors/warnings when library base pointer is declared as "extern struct ExecBase *const SysBase" and later defined as "struct ExecBase *SysBase". But this is minor problem. > > Am I right when I think that there wouldn't be need for "even newer > > inlines format"? All internal tricks are hidden in "LP" macros, so only > > (?) they would have to be rewritten, right? > > That's what's enough so far. I checked it and no changes are _required_, but some _could_ be done - current LPx() macros expect function name argument - in improved inlines this one is simply not used anywhere. > What's currently unclear is the need for > that "outside" declaration of the library base if you want to avoid > reloading. It's not in any present source code that's not accessing > the library structure, and adding an "extern struct ExecBase * > SysBase;" in inline/exec.h might break local library bases (Well, maybe > not, as this declaration doesn't imply that this variable is going to > be used for the calls). "outside" declarations are in files, which are _the_ suggested way of including Amiga function prototypes. These declarations are protected with "#ifndef __NOLIBBASE__" clause, so I don't see any problem. > I started changing macros.h already, Matthias too, so we should > coordinate the work. Great, please send me what you two already managed to do (plain UU-encoded files - no MIME magic, please :-). I don't have much time now, but together we should be able to put it together before 2.7.2 is released. I'll modify and files - actually they will be more similar to the ones from 2.7.0 ( will be exactly the same). > Kamil Iskra writes: > > Inline Amiga function calls cannot be made in full conformance (sp?) to > > ANSI/ISO C. It is basically a hack that uses quite a lot of GCC extensions > > and is not supposed to be portable. > The macro replacements should work with lint, if it skips __asm(). I debt it. First, "const pointers" will fail - such a declaration is not ANSI/ISO C compliant - it comes from C++. Second, there are these constructs: { __asm(); re; } which in GCC/G++ return a value of re, and are again GCC/G++ extension. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 14:42:34 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <85757-4>; Mon, 18 Dec 1995 14:41:45 +0200 Received: from colombo.telesys-innov.fr by funet.fi with SMTP (PP); Mon, 18 Dec 1995 14:40:10 +0200 Received: by colombo.telesys-innov.fr; Mon, 18 Dec 1995 13:21:21 GMT From: Philippe BRAND Message-Id: <199512181321.NAA01247@colombo.telesys-innov.fr> Subject: Re: Gcc-2.7.2 C/C++/Objc beta available To: wiedmann@Neckar-Alb.De (Jochen Wiedmann) Date: Mon, 18 Dec 1995 13:21:20 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199512180030.BAA01173@wiedmann.neckar-alb.de> from "Jochen Wiedmann" at Dec 18, 95 01:30:17 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Jochen Wiedmann writes: > > Beta available on both my site and funet.fi. Integrate latest changes > > by Rask about m68k.c. Please test as much as possible, and report necessary > > changes, specs, etc.. > > How about diffs? Sorry it was available under private directory, which was not accessible. diff file is now under beta directory on my site. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 16:14:44 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89211-1>; Mon, 18 Dec 1995 16:14:02 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 18 Dec 1995 15:13:40 +0100 (MET) From: Rask Lambertsen To: Hans Verkuil Cc: amiga-gcc-port@nic.funet.fi Subject: Re: README-2.7.2 corrections In-Reply-To: <9512172115.0efs@wyst.hobby.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 17 Dec 1995, Hans Verkuil wrote: > Hi Rask, > > > I had that one fixed in the copy of the README that I work on. There is one > > more spelling mistake on that line, it should be > > > > - new inline headers. There is now two sets. The new ones are those > > You mean of course: > > - new inline headers. There are now two sets. The new ones are those Hmmm, maybe I got the context diff you posted backwards. > > What paragraph? There is no such thing in the README. > > In the section Ixemul vs Libnix: > > * It is not copyrighted by the FSF. Therefore you neither need > to include sources nor objects together with your executable. > (read the GLGPL _before_ flaming on this statement) > > This implies that anything that uses ixemul is automatically also covered > by the GLGPL, which isn't true. OK, it could be misunderstood. I'll change it. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 16:35:14 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <89444-3>; Mon, 18 Dec 1995 16:33:45 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Sun, 17 Dec 1995 19:48:13 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-list@nic.funet.fi Subject: New README available Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Date: Mon, 18 Dec 1995 15:33:30 +0100 (MET) Resent-From: Rask Lambertsen Resent-To: amiga-gcc-port@nic.funet.fi Resent-Message-Id: Hi, I have a new README-2.7.2 available which includes various updates. Most notably two new patches for libraries/mathieee[sp].h which should fix the problem with single precision IEEE library calls. It is available as and I'll send it by email to anyone who requests it. The diff is also available as . I'll email that one too on request. I'm sorry, no AmigaGuide version yet. I'll probably be busy with exams until the middle of January. I'd like to know if a release of GCC 2.7.2 is on its way within a short time. Phillipe, if you make a release, could you please email me a day or two before, so I can put in any last updates to the README, please? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 16:56:08 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <88989-1>; Mon, 18 Dec 1995 16:55:27 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 18 Dec 1995 15:55:21 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Re: New README available In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 17 Dec 1995, Rask Lambertsen wrote: > The diff is also available as > . I'll email that > one too on request. Don't use the diff, it diffs against a newer README than the last one availalbe. Get the complete README instead. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 18:41:17 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <89900-1>; Mon, 18 Dec 1995 18:40:14 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id SAA15268 at Mon, 18 Dec 1995 18:39:40 +0200 Received: by softlab.ece.ntua.gr with UUCP id SAA06622 at Mon, 18 Dec 1995 18:39:55 +0200 (EET) Received: by kriton.UUCP (V1.17-beta/Amiga) id <09hs@kriton.UUCP>; Mon, 18 Dec 95 18:38:55 EET Date: Mon, 18 Dec 95 18:38:55 EET Message-Id: <9512181638.09hs@kriton.UUCP> Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Problem with soft links I think that someone has reported this before, but I'm just making sure. I am using version 41.4 of ixemul.library. If I say "ln -s gcc:", I get a requester saying "Please insert volume ./gcc in any drive". If I say "ln -s gcc:", the link is made to cc: instead of gcc:. The first character is lost. -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I have no silly prejudice against computers--I like them!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 18:49:07 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <89039-2>; Mon, 18 Dec 1995 18:48:22 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26547-1>; Mon, 18 Dec 1995 17:47:53 +0100 Received: from hphalle7j.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395695-1>; Mon, 18 Dec 1995 17:47:45 +0100 Subject: Re: More optimizations for m68k.c From: Christian Stieber To: amiga-gcc-port@lists.funet.fi Date: Mon, 18 Dec 1995 17:47:36 +0100 (MEZ) In-Reply-To: from "Rask Lambertsen" at Dec 17, 95 05:28:33 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 982 Message-Id: <95Dec18.174745+0100mesz.395695-1+626@hphalle0.informatik.tu-muenchen.de> > > - 68000 and 68010 are equal from a programmer's point of view > > Not quite. The '010 has some new instructions (rtd is usefull to us, see > TARGET_RTD) and the timing of some instructions have been improved > (mul?.w and div?.w by a lot, clr.? no longer makes read accesses). Also, don't forget the loop mode. I'm not sure whether it really makes a difference (is there a case where some loopable code on 68010 is faster than non-loopable code, but slower on 68000?), though. > > same might apply for TARGET_68040 and 68060. But I'm not too familiar with > > too subtle differences between these CPU's. Anyone? > > Some '040 instructions should be avoided on the '060, Yep, especially the unimplemented ones :) Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 18:51:39 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <89158-3>; Mon, 18 Dec 1995 18:50:39 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id SAA15670 at Mon, 18 Dec 1995 18:50:10 +0200 Received: by softlab.ece.ntua.gr with ESMTP id SAA06852 at Mon, 18 Dec 1995 18:50:26 +0200 (EET) Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id SAA15649 at Mon, 18 Dec 1995 18:50:05 +0200 Received: by srv3.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 18 Dec 1995 17:50:08 +0100 (MET) From: Rask Lambertsen To: kyrimis@softlab.ece.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: Problem with soft links In-Reply-To: <9512181638.09hs@kriton.UUCP> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 18 Dec 1995, Kriton Kyrimis wrote: > I think that someone has reported this before, but I'm just making sure. > I am using version 41.4 of ixemul.library. > > If I say "ln -s gcc:", I get a requester saying "Please insert volume ./gcc > in any drive". > > If I say "ln -s gcc:", the link is made to cc: instead of gcc:. The first > character is lost. I've some problems with this too since I started using the ixemul version of GNU tar. It tries to create symbolic links to /gbar/srv3/home5/id/gc948374/anden/HTML3.0 but ends up making a soft link to bar:srv3/home5/id/gc948374/anden/HTML3.0. If I then try to delete the link, a requester pops up asking me to insert volume "bar:". This had me totally confused for a long time, thinking I maybe had a link to "Foo bar:" which wasn't interpreted correctly, until I did "ls -lgA" in the directory where the link was. If only the requester had asked for "gbar:" I would have figured it out in two tenths of a second. Hans, promise me that this will be fixed soon, please. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 18:55:27 1995 Received: from srv3.gbar.dtu.dk ([130.225.87.163]) by nic.funet.fi with ESMTP id <89222-2>; Mon, 18 Dec 1995 18:54:43 +0200 Received: by srv3.gbar.dtu.dk (1.37.109.15/16.2) Date: Mon, 18 Dec 1995 17:54:08 +0100 (MET) From: Rask Lambertsen To: Christian Stieber Cc: amiga-gcc-port@nic.funet.fi Subject: Re: More optimizations for m68k.c In-Reply-To: <95Dec18.174745+0100mesz.395695-1+626@hphalle0.informatik.tu-muenchen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 18 Dec 1995, Christian Stieber wrote: > > > - 68000 and 68010 are equal from a programmer's point of view > > > > Not quite. The '010 has some new instructions (rtd is usefull to us, see > > TARGET_RTD) and the timing of some instructions have been improved > > (mul?.w and div?.w by a lot, clr.? no longer makes read accesses). > > Also, don't forget the loop mode. I'm not sure whether it really > makes a difference (is there a case where some loopable code on 68010 is > faster than non-loopable code, but slower on 68000?), though. Loop mode only works with some instructions, so maybe one would choose other instructions on the '010 in some cases. I can't come up with an example, though. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 19:44:48 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89911-1>; Mon, 18 Dec 1995 19:43:05 +0200 Received: from bastion.nmrc.ucc.ie (nmrc.ucc.ie [143.239.64.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id RAA18932 for ; Mon, 18 Dec 1995 17:43:00 GMT Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id RAA01957; Mon, 18 Dec 1995 17:40:53 GMT From: Lars Hecking Message-Id: <199512181741.RAA04555@cashel.nmrc.ucc.ie> Subject: Re: Problem with soft links To: kyrimis@softlab.ece.ntua.gr Date: Mon, 18 Dec 1995 17:41:07 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9512181638.09hs@kriton.UUCP> from "Kriton Kyrimis" at Dec 18, 95 06:38:55 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 391 > > I think that someone has reported this before, but I'm just making sure. > I am using version 41.4 of ixemul.library. > > If I say "ln -s gcc:", I get a requester saying "Please insert volume ./gcc > in any drive". > > If I say "ln -s gcc:", the link is made to cc: instead of gcc:. The first > character is lost. I reported this to Hans a while ago and he says it's fixed in 42.0. From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 21:37:45 1995 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <85736-1>; Mon, 18 Dec 1995 21:36:11 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id VAA22890 at Mon, 18 Dec 1995 21:35:38 +0200 Received: by softlab.ece.ntua.gr with ESMTP id VAA09783 at Mon, 18 Dec 1995 21:35:51 +0200 (EET) Received: by achilles.noc.ntua.gr via NTUAnet with SMTP id VAA22885 at Mon, 18 Dec 1995 21:35:23 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tRm0o-000R7UC; Mon, 18 Dec 95 21:18 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0eka@wyst.hobby.nl>; Mon, 18 Dec 95 20:00:46 CET Message-Id: <9512181900.0eka@wyst.hobby.nl> Date: Mon, 18 Dec 1995 20:00:44 +0000 (CET) In-Reply-To: <9512181638.09hs@kriton.UUCP> from "Kriton Kyrimis" at Dec 18, 95 06:38:55 pm Content-Type: text From: hans@wyst.hobby.nl (Hans Verkuil) To: kyrimis@softlab.ece.ntua.gr Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Problem with soft links Hi Kriton, > If I say "ln -s gcc:", the link is made to cc: instead of gcc:. The first > character is lost. I introduced this bug in 41.4 and I fixed it in 42.0. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 21:47:15 1995 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <88958-4>; Mon, 18 Dec 1995 21:46:16 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26521-1>; Mon, 18 Dec 1995 20:42:40 +0100 Received: from hphalle7j.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <395691-1>; Mon, 18 Dec 1995 20:42:33 +0100 Subject: Re: Problem with soft links From: Christian Stieber To: amiga-gcc-port@nic.funet.fi Date: Mon, 18 Dec 1995 20:42:30 +0100 (MEZ) In-Reply-To: <9512181900.0eka@wyst.hobby.nl> from "Hans Verkuil" at Dec 18, 95 08:00:44 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 517 Message-Id: <95Dec18.204233+0100mesz.395691-1+679@hphalle0.informatik.tu-muenchen.de> > I introduced this bug in 41.4 and I fixed it in 42.0. Just wondering, why did you introduce it in the first place? What prompted you to do this? Why did you spend your time implementing this behavior? It seems like a rather useless thing to do :) SCNR, Christian -- // Christian Stieber Stieber@Informatik.TU-Muenchen.de \// Certified Amiga Developer http://www.leo.org/~stieber/ -------------------------------------------------------------------------- Nobody, just nobody From amiga-gcc-port-owner@nic.funet.fi Mon Dec 18 23:44:05 1995 Received: from ns.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with ESMTP id <89729-2>; Mon, 18 Dec 1995 23:42:53 +0200 Received: from wiedmann.neckar-alb.de (wiedmann@wiedmann.neckar-alb.de [194.77.119.253]) by ns.neckar-alb.de (8.7.1/8.7.1) with ESMTP id WAA21566 for ; Mon, 18 Dec 1995 22:40:28 +0100 (MET) Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id WAA01757 for amiga-gcc-port@lists.funet.fi; Mon, 18 Dec 1995 22:41:55 +0100 From: Jochen Wiedmann Message-Id: <199512182141.WAA01757@wiedmann.neckar-alb.de> Subject: Error while building libb/libgcc2.a for a crosscompiler To: amiga-gcc-port@nic.funet.fi Date: Mon, 18 Dec 1995 22:41:54 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, I tried to build a crosscompiler i586-unknown-linux --> m68k-unknown-amigados. When building libb/libgcc2.a, the following happens: > ./xgcc -B./ -DCROSS_COMPILE -DIN_GCC -g -resident -I. -I. -I./config -c -DL_muldi3 ./libgcc2.c -o _muldi3.o ./libgcc2.c: In function `__muldi3': ./libgcc2.c:290: internal error--unrecognizable insn: (call_insn/u 32 30 33 (set (reg:SI 0 d0) (call (mem:QI (symbol_ref:SI ("__mulsi3"))) (const_int 8))) -1 (nil) (nil) (nil)) xgcc: Internal compiler error: program cc1 got fatal signal 6 As far as I know, libgcc2.a should compile without problems or am I wrong? Regards, Jochen From amiga-gcc-port-owner@nic.funet.fi Tue Dec 19 00:24:00 1995 Received: from ns.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with ESMTP id <89248-3>; Tue, 19 Dec 1995 00:20:33 +0200 Received: from wiedmann.neckar-alb.de (wiedmann@wiedmann.neckar-alb.de [194.77.119.253]) by ns.neckar-alb.de (8.7.1/8.7.1) with ESMTP id XAA21673 for ; Mon, 18 Dec 1995 23:18:00 +0100 (MET) Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id XAA02689 for amiga-gcc-port@lists.funet.fi; Mon, 18 Dec 1995 23:19:28 +0100 From: Jochen Wiedmann Message-Id: <199512182219.XAA02689@wiedmann.neckar-alb.de> Subject: Crosscompiler needs libgcc1.a? To: amiga-gcc-port@nic.funet.fi Date: Mon, 18 Dec 1995 23:19:28 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, some of you probably remember, that I am building a crosscompiler ... well, I ran into YAP. (Yet Another Problem) As far as I can remember, Philippe and other people said, that there's no need for libgcc1.a and providing an empty one is quite sufficient. However, this is what happens when compiling libgcc1-test: ./xgcc -B./ -DCROSS_COMPILE -DIN_GCC -g -I./include -c ./libgcc1-test.c Testing libgcc1. Ignore linker warning messages. ./xgcc -B./ -DCROSS_COMPILE -DIN_GCC -g -I./include libgcc1-test.o -o libgcc1-test -nostartfiles -nostdlib libgcc.a libgcc1-test.o: In function `main_without__main': /usr/amiga/gnu/src/gcc-2.7.2/./libgcc1-test.c:17: undefined reference to `__truncdfsf2' /usr/amiga/gnu/src/gcc-2.7.2/./libgcc1-test.c:17: undefined reference to `__truncdfsf2' ... lots of other missing functions deleted Am I doing something wrong? Is there a switch I am missing or something similar? Regards, Jochen From amiga-gcc-port-owner@nic.funet.fi Tue Dec 19 00:42:57 1995 Received: from ns.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with ESMTP id <88979-2>; Tue, 19 Dec 1995 00:41:29 +0200 Received: from wiedmann.neckar-alb.de (wiedmann@wiedmann.neckar-alb.de [194.77.119.253]) by ns.neckar-alb.de (8.7.1/8.7.1) with ESMTP id XAA21746 for ; Mon, 18 Dec 1995 23:38:54 +0100 (MET) Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id XAA02792 for amiga-gcc-port@lists.funet.fi; Mon, 18 Dec 1995 23:40:22 +0100 From: Jochen Wiedmann Message-Id: <199512182240.XAA02792@wiedmann.neckar-alb.de> Subject: Mismatch of t-amigados and x-amigados To: amiga-gcc-port@nic.funet.fi Date: Mon, 18 Dec 1995 23:40:22 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, I found the following in t-amigados: MAYBE_USE_COLLECT2= -Dmain=stkmain -Dexit=stkexit EXTRA_OBJS = amigasup.o This is obviously nonsense, as a crosscompiler must never use amiga-gcc's stack checking, doesn't it? The right place for that kind of things seems to me to be x-amigados. Jochen From amiga-gcc-port-owner@nic.funet.fi Tue Dec 19 02:04:52 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89097-3>; Tue, 19 Dec 1995 02:03:58 +0200 Received: by colombo.telesys-innov.fr; Tue, 19 Dec 1995 01:01:52 GMT From: Philippe BRAND Message-Id: <199512190101.BAA05147@colombo.telesys-innov.fr> Subject: Re: Mismatch of t-amigados and x-amigados To: wiedmann@Neckar-Alb.De (Jochen Wiedmann) Date: Tue, 19 Dec 1995 01:01:51 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199512182240.XAA02792@wiedmann.neckar-alb.de> from "Jochen Wiedmann" at Dec 18, 95 11:40:22 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Jochen Wiedmann writes: > This is obviously nonsense, as a crosscompiler must never use amiga-gcc's > stack checking, doesn't it? The right place for that kind of things seems > to me to be x-amigados. Correct. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Dec 19 02:12:50 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89920-1>; Tue, 19 Dec 1995 02:11:49 +0200 Received: by colombo.telesys-innov.fr; Tue, 19 Dec 1995 01:09:48 GMT From: Philippe BRAND Message-Id: <199512190109.BAA05183@colombo.telesys-innov.fr> Subject: Re: Error while building libb/libgcc2.a for a crosscompiler To: wiedmann@Neckar-Alb.De (Jochen Wiedmann) Date: Tue, 19 Dec 1995 01:09:47 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199512182141.WAA01757@wiedmann.neckar-alb.de> from "Jochen Wiedmann" at Dec 18, 95 10:41:54 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Jochen Wiedmann writes: > > ./xgcc -B./ -DCROSS_COMPILE -DIN_GCC -g -resident -I. -I. > -I./config -c -DL_muldi3 ./libgcc2.c -o _muldi3.o > ./libgcc2.c: In function `__muldi3': > ./libgcc2.c:290: internal error--unrecognizable insn: > (call_insn/u 32 30 33 (set (reg:SI 0 d0) > (call (mem:QI (symbol_ref:SI ("__mulsi3"))) > (const_int 8))) -1 (nil) > (nil) > (nil)) > xgcc: Internal compiler error: program cc1 got fatal signal 6 Yep it should. Are you building a cross 2.7.2 ? As for now i386 code generation is somewhat buggy, this could be the cause. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Dec 19 02:25:40 1995 Received: from ns.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with ESMTP id <89658-1>; Tue, 19 Dec 1995 02:24:35 +0200 Received: from wiedmann.neckar-alb.de (wiedmann@wiedmann.neckar-alb.de [194.77.119.253]) by ns.neckar-alb.de (8.7.1/8.7.1) with ESMTP id BAA22335; Tue, 19 Dec 1995 01:22:02 +0100 (MET) Received: (from wiedmann@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id BAA03955; Tue, 19 Dec 1995 01:23:30 +0100 From: Jochen Wiedmann Message-Id: <199512190023.BAA03955@wiedmann.neckar-alb.de> Subject: Re: Error while building libb/libgcc2.a for a crosscompiler To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Tue, 19 Dec 1995 01:23:29 +0100 (MET) Cc: wiedmann@neckar-alb.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <199512190109.BAA05183@colombo.telesys-innov.fr> from "Philippe BRAND" at Dec 19, 95 01:09:47 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, Philippe, > Yep it should. Are you building a cross 2.7.2 ? As for now i386 code > generation is somewhat buggy, this could be the cause. Without looking inside the code: I doubt that, because - the same problem arised in previous versions - the problem arised with -resident only, which is quite Amiga specific Sorry, Jochen From amiga-gcc-port-owner@nic.funet.fi Tue Dec 19 02:27:49 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89348-4>; Tue, 19 Dec 1995 02:25:07 +0200 Received: by colombo.telesys-innov.fr; Tue, 19 Dec 1995 01:23:00 GMT From: Philippe BRAND Message-Id: <199512190123.BAA05248@colombo.telesys-innov.fr> Subject: Re: Crosscompiler needs libgcc1.a? To: wiedmann@Neckar-Alb.De (Jochen Wiedmann) Date: Tue, 19 Dec 1995 01:23:00 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199512182219.XAA02689@wiedmann.neckar-alb.de> from "Jochen Wiedmann" at Dec 18, 95 11:19:28 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Jochen Wiedmann writes: > As far as I can remember, Philippe and other people said, that there's > no need for libgcc1.a and providing an empty one is quite sufficient. > However, this is what happens when compiling libgcc1-test: True. I didn't have your problems generating a cross-compiler on a sparc-sun-sunos4.1.3 -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Dec 19 02:34:42 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89512-3>; Tue, 19 Dec 1995 02:32:22 +0200 Received: by colombo.telesys-innov.fr; Tue, 19 Dec 1995 01:30:13 GMT From: Philippe BRAND Message-Id: <199512190130.BAA05283@colombo.telesys-innov.fr> Subject: Re: Error while building libb/libgcc2.a for a crosscompiler To: wiedmann@Neckar-Alb.De (Jochen Wiedmann) Date: Tue, 19 Dec 1995 01:30:13 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <199512190023.BAA03955@wiedmann.neckar-alb.de> from "Jochen Wiedmann" at Dec 19, 95 01:23:29 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Jochen Wiedmann writes: > > Yep it should. Are you building a cross 2.7.2 ? As for now i386 code > > generation is somewhat buggy, this could be the cause. > > Without looking inside the code: I doubt that, because > > - the same problem arised in previous versions > - the problem arised with -resident only, which is quite Amiga specific I didn't have this problem on a sparc-sun-sunos4.1.3, this is why I think there's a problem with a i586-unknown-peecee box. I'll try to look at it tomorrow. Quite late here :) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://www.telesys-innov.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Dec 19 10:30:58 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <89150-1>; Tue, 19 Dec 1995 10:29:15 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id JAA24537 (8.7.2/7.5a-FAU); for ; Tue, 19 Dec 1995 09:28:58 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA12040; Tue, 19 Dec 1995 09:28:57 +0100 Date: Tue, 19 Dec 1995 09:28:57 +0100 Message-Id: <9512190828.AA12040@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: amiga-gcc-port@nic.funet.fi Subject: stdio.h Hello, I have a questions about the include file stdio.h . The include file stdio.h declares char *fgetline (FILE *, size_t *) if _ANSI_SOURCE and _POSIX_SOURCE are not defined. As I think this true for the most gnu utils you compile. But now there are some gnu utils which have their own function fgetline() ,but with only one argument char *fgetline (FILE *) and the used buffer grows automaticly. Now, if you want to compile you get an error. To do a work around you can define one of the above defines before including stdio.h and undef after that. But this may give other trouble. But I am not so familar with that to see it. Can anybody making the new gcc 2.7.2 think about it. Bye -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de iler on a > sparc-sun-sunos4.1.3 Do you have the slightest idea, what I could check to find out, what the problem is? Obviously gcc produces calls to external functions where it shouldn't. Perhaps this is directed by any preprocessor defines which must be present or something similar? Thanks, Jochen From amiga-gcc-port-owner@nic.funet.fi Wed Dec 20 13:52:51 1995 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90708-2>; Wed, 20 Dec 1995 13:51:58 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA11667 (5.67b8/IDA-1.5 for ); Wed, 20 Dec 1995 12:51:42 +0100 Received: by diva.gmd.de with UUCP id AA04039 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Wed, 20 Dec 1995 12:47:46 +0100 Date: Wed, 20 Dec 1995 12:47:46 +0100 Message-Id: <199512201147.AA04039@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: Problem with soft links In-Reply-To: References: <9512181638.09hs@kriton.UUCP> Hi, I have a problem with softlinks, namely I feel that 1st, ixconfig got some switches wrong, and 2nd, ixemul writes bad softlinks. I'm using ixemul-41.1. If I use "translate /, don't translate symlinks", a non-ixemul ls shows unusable "/"-relative paths. With "translate symlinks", it shows that an ixemul-based link utility creates an absolute AmigaDOS paths. Looks a little backwards (w.r.t. "translate /") to me. Ok, ixconfig is going to disappear (sniff), but I find it odd that a "/"-relative path is generated in the Amiga filesystem. This should not happen, as these symlinks will stop working with non-ixemul programs. Symlinks should always be written as absolute AmigaDOS paths and translated to "/"-paths for ixemul-based readers of the link if some ixconfig switch says so. Has this already been fixed in 42.0? Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Dec 20 14:08:44 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <90938-3>; Wed, 20 Dec 1995 14:08:18 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id NAA11079 (8.7.2/7.5a-FAU); for ; Wed, 20 Dec 1995 13:07:50 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA17486; Wed, 20 Dec 1995 13:07:49 +0100 Date: Wed, 20 Dec 1995 13:07:49 +0100 Message-Id: <9512201207.AA17486@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: amiga-gcc-port@nic.funet.fi Subject: problem with less-290 and sh Hello, I successfully compiled less-290 with gcc 2.7.0 or better to say it run but it has one problem. Being in the shell sh and call i.e. less help.c the file is correctly displayed. But typing h to display the help page gives only the message "End of help (press RETURN)" after some time. Doing the same from CLI or a csh the help page is displayed correct. The way to display the help page is to start a second instance of less with the help file as argument. Now has anybody an idea or hints? Perhaps it belongs to the IO-handling of sh ? Merry Christmas and a happy new year -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Wed Dec 20 15:47:08 1995 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90408-1>; Wed, 20 Dec 1995 15:46:42 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA21830 (5.67b8/IDA-1.5 for ); Wed, 20 Dec 1995 14:46:12 +0100 Received: by diva.gmd.de with UUCP id AA04058 (5.67b8/IDA-1.5); Wed, 20 Dec 1995 14:42:15 +0100 Date: Wed, 20 Dec 1995 14:42:15 +0100 Message-Id: <199512201342.AA04058@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: Ville-Pertti Keinonen , amiga-gcc-port@nic.funet.fi Subject: Re: Optimization questions In-Reply-To: <199512030846.KAA17580@katiska.clinet.fi> References: <199512030846.KAA17580@katiska.clinet.fi> Ville-Pertti Keinonen writes: > 00000000 <_strcpy> moveal sp@(8),a1 > 00000004 <_strcpy+4> movel sp@(4),d1 > 00000008 <_strcpy+8> moveb a1@+,d0 > 0000000a <_strcpy+a> moveal d1,a0 > 0000000c <_strcpy+c> bras 00000010 <_strcpy+10> > 0000000e <_strcpy+e> moveb a1@+,d0 > 00000010 <_strcpy+10> moveb d0,a0@+ > 00000012 <_strcpy+12> bnes 0000000e <_strcpy+e> > 00000014 <_strcpy+14> movel d1,d0 > 00000016 <_strcpy+16> rts > The "unnecessary crap" almost looks as if it was caused by the > scheduling optimization pass. Some improvements would indeed be > required here, including the swapping of d0/d1. Obviously register > allocation doesn't take everything into account. > For some reason, I don't think I've ever seen strcpy() like this: > _strcpy: > movl sp@(8),a1 > movl sp@(4),a0 > movl a0,d0 > 1: movb a1@+,a0@+ > jbne 1b > rts > It would be nice if that could be produced by some compiler. Well, GCC produces _almost_ this (I get movel a1@+,d1; movel d1,a0@+, jbne), but not for every loop. It largely depends on the source code. There's something else where more work could be done: DBcc could be used in more cases. After a very long study (the details of which are lost if not still on some backup at the place I worked before), I came up with the following: /* * GCC-1.x, 2.3.3, 2.5.8, 2.6.3, 2.7.0 use dbra * in such while((short|long)(--n) != -1) loops * Other loops forms may not lead to the same optimization with all GCCs * short count generates single dbra, long count dbra in the inner loop */ extern __inline__ char *strscpy(char *d, const char *s, short n) { char *d2 = d; if (n) { --n; /* 0: moveb a0@+,d0; (grr) moveb d0,a0@+; beq 1f; dbra d0,0b; 1: */ while ((*d++=*s++) && ((short)(--n) != -1)) ; } return d2; } /* if short is enough for you */ #define strncpy strscpy Replace short with long in the above and see how DBRA is still used! When using other forms of loops (typically those which test for 0, which is more intuitive), different GCCs produce very differing code, not always (i.e. generally not) using DBcc. I think that some work could go into the part of GCC that analyses this, it should be more rewarding than just transforming a few MOVEL to shorter instructions. It seems that GCC only uses DBcc when it proves that the final result is -1 (the final value of DBRA), even if that value is not needed later. Many loops are dotimes-type loops, (even if the final count does not reach -1) and could profit from DBcc. Bye, Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Dec 20 17:34:24 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90525-2>; Wed, 20 Dec 1995 17:33:24 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tSQXY-0004nYC; Wed, 20 Dec 95 08:34 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Problem with soft links To: hoehle@zeus.gmd.de (Joerg Hoehle) Date: Wed, 20 Dec 1995 08:34:48 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199512201147.AA04039@diva.gmd.de> from "Joerg Hoehle" at Dec 20, 95 12:47:46 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 52 > Has this already been fixed in 42.0? Yes. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Dec 20 19:06:25 1995 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with SMTP id <90614-4>; Wed, 20 Dec 1995 19:05:37 +0200 Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.6.12/8.6.4) with ESMTP id TAA17569; Wed, 20 Dec 1995 19:05:14 +0200 Received: (will@localhost) by katiska.clinet.fi (8.6.12/8.6.4) id TAA21419; Wed, 20 Dec 1995 19:05:21 +0200 Date: Wed, 20 Dec 1995 19:05:21 +0200 Message-Id: <199512201705.TAA21419@katiska.clinet.fi> From: Ville-Pertti Keinonen To: hoehle@zeus.gmd.de CC: amiga-gcc-port@nic.funet.fi In-reply-to: <199512201342.AA04058@diva.gmd.de> (hoehle@zeus.gmd.de) Subject: Re: Optimization questions Well, GCC produces _almost_ this (I get movel a1@+,d1; movel d1,a0@+, jbne), but not for every loop. It largely depends on the source code. The more I think about it, the more I get the feeling there was some reason for "1: movb a1@+,a0@+; jbne 1b" not to work at all (something like the status bits don't get set by the move), in which case GCC does produce the most efficient strcpy() possible. movb a1@+,a0@+ is produced in other situations, whenever the value moved is ignored. There's something else where more work could be done: DBcc could be used in more cases. After a very long study (the details of which are I agree. It would really be useful to have some type of loop that would be efficient but portable and neat. The only way to get the m68k version to generate dbcc is to either restrict a size_t to values less than 2^31 or compare to -1, which is illogical enough to probably be less efficient on other systems, but not necessarily. I tried compiling a few different loops for m68k (gcc 2.7.0) and i386 (I can't remember what version, but the loops that were less efficient did the decrement and the test separately -- there were basically two kinds of loops on the i386, good and bad ;-) cpus: while (n-- != 0) *d++ = *s++; Produces horrible code on both, due to the post-decrement on n. On m68k, the code was something like (just to give an idea of how bad such simple code gan get): jbra 2f 1: movb a1@+,a0@+ 2: movl d1,d0 subql #1,d1 tstl d0 jbne 1b The post-decrementation can easily be eliminated: if (n != 0) { do *d++ = *s++; while (--n != 0); } Much better, although very similar to the much simpler: for ( ; n != 0; --n) *d++ = *s++; Both of these produced the best non-dbf code on m68k and good code on the i386. When dbf code was produced: while ((signed)--n >= 0) *d++ = *s++; This one was nice on both, except for the restriction to 2^31, which can be avoided: while (--n != (unsigned)-1) *d++ = *s++; This was efficient on both, but it looks really bad, especially since it assumes that an unsigned variable decreased below zero is (bitwise) equal to the signed value -1. Replace short with long in the above and see how DBRA is still used! And it is indeed used very nicely, although it would be even faster to break up the long into two shorts and just dbf both, but that is actually more expensive in many cases, since it allocates an extra register and the outer loop is only executed every 2^16 rounds, so it really isn't worth it. When using other forms of loops (typically those which test for 0, which is more intuitive), different GCCs produce very differing code, not always (i.e. generally not) using DBcc. I think that some work If I remember correctly, some older versions never produced dbcc. could go into the part of GCC that analyses this, it should be more rewarding than just transforming a few MOVEL to shorter instructions. Definitely. And there is always work to be done on the optimization -- anyone who has a lot of extra time on their hands and would like to improve GCC should just compile a few sources and start going through the asm-output. ;-) It seems that GCC only uses DBcc when it proves that the final result is -1 (the final value of DBRA), even if that value is not needed later. Many loops are dotimes-type loops, (even if the final count does not reach -1) and could profit from DBcc. The -1 is not always necessary. 0 can also be used in some cases, as demonstrated above. Some code actually compiles very nicely, like the following strstr(), which has an inner loop that uses dbne nicely: char * strstr(str, srch) register const char *str; const char *srch; { /* Assume ptrdiff_t to be int and that we have plenty of registers. */ register const char *p1, *p2; register int i; register char c1, c2; int n; p2 = srch; while (*p2++ != '\0') ; n = p2 - srch - 1; if (n != 0) { --n; c2 = *srch++; while ((c1 = *str++) != '\0') { if (c1 == c2) { i = n; p1 = str; p2 = srch; while (--i >= 0) { if (*p1++ != *p2++) goto notequal; } return (char *)str - 1; } notequal: } return NULL; } return (char *)str; } From amiga-gcc-port-owner@nic.funet.fi Wed Dec 20 19:47:42 1995 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90894-3>; Wed, 20 Dec 1995 19:47:15 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA09106 (5.67b8/IDA-1.5 for ); Wed, 20 Dec 1995 18:46:53 +0100 Received: by diva.gmd.de with UUCP id AA04173 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Wed, 20 Dec 1995 18:42:57 +0100 Date: Wed, 20 Dec 1995 18:42:57 +0100 Message-Id: <199512201742.AA04173@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: Optimization questions In-Reply-To: <199512201705.TAA21419@katiska.clinet.fi> References: <199512201342.AA04058@diva.gmd.de> <199512201705.TAA21419@katiska.clinet.fi> Ville-Pertti Keinonen writes: > The more I think about it, the more I get the feeling there was some > reason for "1: movb a1@+,a0@+; jbne 1b" not to work at all (something > like the status bits don't get set by the move), in which case GCC > does produce the most efficient strcpy() possible. movb a1@+,a0@+ is > produced in other situations, whenever the value moved is ignored. That was my suspicion, but I'm _using_ it on my 68040 and 68000 machines, and it works! So unless it's a bug in the processors, it's certainly documented in some Motorola manuals. /* Do not use this inline for strcpy(foo, "...") which is optimized away */ extern __inline__ char *strcpy(char *d, const char *s) { char *d2 = d; /* * GCC would generate "0: moveb a@+,d0; move d0,a@+, jne 0b" instead * See how s and d are input _and_ output because they are modified */ __asm__ volatile ("0: moveb %0@+,%1@+; jne 0b" : "=a" (s), "=a" (d) : "0" (s), "1" (d) : "cc", "memory"); return d2; } Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Dec 20 21:42:11 1995 Received: from rumms.uni-mannheim.de ([134.155.50.52]) by nic.funet.fi with SMTP id <90944-1>; Wed, 20 Dec 1995 21:41:11 +0200 Received: from pips01.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA04592 (5.65c/IDA-1.4.4 for ); Wed, 20 Dec 1995 20:40:44 +0100 Received: from pips15.informatik.uni-mannheim.de by pips01.informatik.uni-mannheim.de (4.1/BelWue-1.1Sma2(subsidiary)) id AA18413; Wed, 20 Dec 95 20:36:32 +0100 Received: by pips15.informatik.uni-mannheim.de (5.0/SMI-SVR4) id AA24335; Wed, 20 Dec 1995 20:35:34 --100 From: opel@pips01.informatik.uni-mannheim.de (Steffen Opel) Message-Id: <9512201935.AA24335@pips15.informatik.uni-mannheim.de> Subject: GCC-Install 2.14 (for 2.7.2) uploaded to pub/amigados-gnu/uploads To: phb@telesys-innov.fr Date: Wed, 20 Dec 1995 20:35:32 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1261 Salut, I've just uploaded GCC-Install_2.14.lha to ftp.telesys-innov.fr/pub/ amigados-gnu/uploads. Therefore the previous uploads for the never released 2.7.1 (GCC-Install, GCC-Install.info and GCC-Install.lha) are obsolete and should be removed. I've uploaded only the lha-archive this time, since even I finally made it to realize how all others do it ;-) List of changes: REV: GCCSTACK removed. This should work in a transparent manner, i.e. deleting the old variable, if found while updating. (This has already been implemented by Jochen Wiedmann and was just disabled) REV: There is a 'working on installation message' now while unarchiving FIX: In 2.13 I introduced a workaround to enable proper work of NOVICE-mode. Thinking over it again I realized this to be mainly useless in total, since in NOVICE-mode, where they would be most needed, all informative messages are disabled as well. Therefore I removed this and set the MINUSER tooltype to AVERAGE (Btw, who decided GNU C to be a product for NOVICE users? ;-) ). However, I'll probably try to make the differences between AVERAGE and EXPERT more significant in the future, to provide a somewhat easier installation mode than EXPERT. Ciao, Steffen Opel From amiga-gcc-port-owner@nic.funet.fi Thu Dec 21 00:12:58 1995 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <90408-3>; Thu, 21 Dec 1995 00:09:08 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA15081 (5.67b8/IDA-1.5 for ); Wed, 20 Dec 1995 23:08:46 +0100 Received: by diva.gmd.de with UUCP id AA04224 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Wed, 20 Dec 1995 23:04:49 +0100 Date: Wed, 20 Dec 1995 23:04:49 +0100 Message-Id: <199512202204.AA04224@diva.gmd.de> From: hoehle@zeus.gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: project list: tcl/Tk port Hi, people that wish to work on (tcl/)Tk should get in touch with http://titan.informatik.uni-bonn.de/~fasten/ as a port is also one of Bernhard Fastenrath goals. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Thu Dec 21 13:08:04 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90127-3>; Thu, 21 Dec 1995 13:03:56 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA04961; Thu, 21 Dec 1995 12:00:22 +0100 Date: Thu, 21 Dec 1995 12:00:22 +0100 (MET) From: Kamil Iskra To: Philippe BRAND cc: Amiga-Gcc Liste Subject: Re: Gcc-2.7.2 C/C++/Objc beta available In-Reply-To: <199512172329.XAA29515@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 17 Dec 1995, Philippe BRAND wrote: > Beta available on both my site and funet.fi. Integrate latest changes > by Rask about m68k.c. Please test as much as possible, and report necessary > changes, specs, etc.. You haven't corrected problems in specs that I reported when 2.7.1 was out - if I remember correctly, there is broken support for m68020-40, mc68020 - I don't have that post anywhere close to me, so I can't give all the details, but I hope you have my previous posting, so this shouldn't be necessary. What kind of stack support is included in this release? Static? Dynamic? GCCSTACK? IXSTACK? I would also like to let know all of you interested in G++ that haven't bothered downloading this archive, that exceptions finally seem to work on m68k. Great! / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 270 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Dec 21 13:33:49 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90889-3>; Thu, 21 Dec 1995 13:31:23 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA07356; Thu, 21 Dec 1995 12:33:34 +0100 Date: Thu, 21 Dec 1995 12:33:33 +0100 (MET) From: Kamil Iskra To: Amiga GCC List Subject: "const pointers" - valid in ANSI/C? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In a private discussion between Joerg Hoehle and me there arose one problem: Is such a construction: int *const abc; valid according to ANSI/ISO C? I always thought it wasn't and that it was GCC extension (at least in case of C compiler - this is standard feature of C++), but -ansi doesn't turn it off and it is not mentioned in gcc docs in "Extensions" chapter. I don't remember having seen it mentioned in K&R (2nd edition, ANSI-compliant) and if I remember correctly SAS/C 6.56 refuses to compile such a construction in C mode. Could anybody possesing a copy of ANSI/ISO C standard check it out? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Dec 21 14:22:51 1995 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <90318-3> convert rfc822-to-8bit; Thu, 21 Dec 1995 14:19:51 +0200 Received: by bohr.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 21 Dec 1995 13:19:37 +0100 (MET) From: Rask Lambertsen To: Ville-Pertti Keinonen Cc: hoehle@zeus.gmd.de, amiga-gcc-port@nic.funet.fi Subject: Re: Optimization questions In-Reply-To: <199512201705.TAA21419@katiska.clinet.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 20 Dec 1995, Ville-Pertti Keinonen wrote: > > Well, GCC produces _almost_ this (I get movel a1@+,d1; movel d1,a0@+, > jbne), but not for every loop. It largely depends on the source code. > > The more I think about it, the more I get the feeling there was some > reason for "1: movb a1@+,a0@+; jbne 1b" not to work at all (something > like the status bits don't get set by the move), in which case GCC > does produce the most efficient strcpy() possible. movb a1@+,a0@+ is > produced in other situations, whenever the value moved is ignored. I can inform you that "movb a1@+,a0@+" *does* set the status bits according to the value moved. Why GCC fails to generate this instruction beats me. > There's something else where more work could be done: DBcc could be > used in more cases. After a very long study (the details of which are Yep, GCC uses dbcc much too seldomly. long/short int a; short int b; if (a == 0) b --; should give (a = d0, b = d1) tst.l d0 dbne.w d1,label label: ... and many other comparisons with a decrement following it could use dbxx like that. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Dec 21 14:58:58 1995 Received: from bastion.nmrc.ucc.ie ([143.239.64.1]) by nic.funet.fi with SMTP id <90512-3>; Thu, 21 Dec 1995 14:57:05 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id MAA29855; Thu, 21 Dec 1995 12:49:55 GMT From: Lars Hecking Message-Id: <199512211251.MAA16375@mostar.nmrc.ucc.ie> Subject: Re: "const pointers" - valid in ANSI/C? To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Thu, 21 Dec 1995 12:51:03 +0000 (GMT) Cc: hoehle@zeus.gmd.de (Joerg Hoehle), amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Kamil Iskra" at Dec 21, 95 12:33:33 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1548 > In a private discussion between Joerg Hoehle and me there arose one > problem: > > Is such a construction: > > int *const abc; > > valid according to ANSI/ISO C? > > I always thought it wasn't and that it was GCC extension (at least in case > of C compiler - this is standard feature of C++), but -ansi doesn't turn > it off and it is not mentioned in gcc docs in "Extensions" chapter. > > I don't remember having seen it mentioned in K&R (2nd edition, > ANSI-compliant) and if I remember correctly SAS/C 6.56 refuses to compile > such a construction in C mode. SAS/C 6.56 (SCOPTIONS: ANSI, STRICT) emits Warning 103: uninitialized constant "abc" but compiles this, nevertheless. Similar msgs are given given by gcc and lclint. > Could anybody possesing a copy of ANSI/ISO C standard check it out? I don't have ANSI/ISO, but the rationale reads: 3.5.4.1 Pointer declarators A pointer declarator may have its own type qualifiers, to specify the attributes of the pointer itself, as opposed to those of the reference type. The construct is adapted from C++. const int * means (variable) pointer to constant int, and int * const means constant pointer to (variable) int, just as in C++, from which these constructs were adopted. (And mutatis mutandis for the other type qualifiers.) As with other aspects of C type declarators, judicious use of typedef statements can clarify the code. See also the C FAQ (11.9; "The section about ANSI/ISO Standard C"). The ANSI reference is 3.5.4.1, ISO 6.5.4.1. Hope this helps. -l From amiga-gcc-port-owner@nic.funet.fi Thu Dec 21 20:04:58 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <90599-1>; Thu, 21 Dec 1995 20:01:26 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.7.1/8.7.1) id TAA12116; Thu, 21 Dec 1995 19:01:04 +0100 (MET) Date: Thu, 21 Dec 1995 19:01:04 +0100 (MET) From: Ignatios Souvatzis Message-Id: <199512211801.TAA12116@theory.cs.uni-bonn.de> To: amiga-gcc-port@nic.funet.fi In-reply-to: Rask Lambertsen's message of Thu, 21 Dec 1995 13:19:37 +0100 (MET) Subject: Optimization questions X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a #include #include #include extern struct IOStdReq *cnior; void ConsPrintf(char *fmt, ...) { va_list ap; char FmtBuf[256]; extern void FmtPutCh(); va_start(ap, fmt); RawDoFmt(fmt, ap, FmtPutCh, &FmtBuf); va_end(ap); cnior->io_Command = CMD_WRITE; cnior->io_Length = -1; cnior->io_Data = FmtBuf; DoIO((struct IORequest *)cnior); return; } From amiga-gcc-port-owner@nic.funet.fi Fri Dec 22 02:26:15 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <90103-2>; Fri, 22 Dec 1995 02:23:59 +0200 Received: by colombo.telesys-innov.fr; Fri, 22 Dec 1995 01:20:14 GMT From: Philippe BRAND Message-Id: <199512220120.BAA00815@colombo.telesys-innov.fr> Subject: Re: Gcc-2.7.2 C/C++/Objc beta available To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Fri, 22 Dec 1995 01:20:13 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Kamil Iskra" at Dec 21, 95 12:00:22 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Kamil Iskra writes: > You haven't corrected problems in specs that I reported when 2.7.1 was out Arg. Missed a diff file to apply then. I'll look for it. > What kind of stack support is included in this release? Static? Dynamic? > GCCSTACK? IXSTACK? I'm still waiting for ixemul42 to compile gcc using auto-stackextend feature. > I would also like to let know all of you interested in G++ that haven't > bothered downloading this archive, that exceptions finally seem to work on > m68k. Great! :) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://colombo.telis-sc.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Fri Dec 22 12:59:19 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <90631-4>; Fri, 22 Dec 1995 12:58:39 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id LAA05192 (8.7.2/7.5a-FAU); for ; Fri, 22 Dec 1995 11:58:16 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA24889; Fri, 22 Dec 1995 11:58:13 +0100 Date: Fri, 22 Dec 1995 11:58:13 +0100 Message-Id: <9512221058.AA24889@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: amiga-gcc-port@lists.funet.fi Subject: readline-2.0 Hello, I am working on a port of readline-2.0 to the amiga to get the history and so on working. It compiles fine but there are two things missing getpwent() setpwent() To get it work I wrote these functions as dummies (quick and dirty). Also the Makefile has a bug if you want to make readline. This should contain all objects and should be a test whether all works fine. You have to add some objects at the targetlinee of readline and then it compiles fine. And it works. You get the history mechanism but only with control codes 8(. But I also compiled examples/histexamp and there you get the history with the cursor keys working. So I think there are only some (simple ?) additions in the test code of readline to get it work with cursor keys too. Are there any interests? May be it is usefull for pdksh , because I hate it if I cannot do any commandloine editing with the cursor keys. Merry Christmax and a happy new year -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Fri Dec 22 13:56:19 1995 Received: from net2.wau.nl ([137.224.10.18]) by nic.funet.fi with ESMTP id <90805-2>; Fri, 22 Dec 1995 13:55:33 +0200 Received: from vines2.wau.nl by NET2.WAU.NL (PMDF V4.3-10 #6821) id <01HZ3XH6ZCF4009TQ0@NET2.WAU.NL>; Fri, 22 Dec 1995 13:00:54 +0000 (GMT) Received: by vines2.wau.nl; Fri, 22 Dec 95 12:55:25 +0100 Date: Fri, 22 Dec 1995 12:51:38 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: re: Optimization questions To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) [register spill, again argh] >Any quick workaround, short of hand coding in assembler? > Ignatios [example deleted] > va_start(ap, fmt); > RawDoFmt(fmt, ap, FmtPutCh, &FmtBuf); > va_end(ap); > > DoIO((struct IORequest *)cnior); One of the Amiga functions is causing the register spill. Try todo something like this: #define RawDoFmt Rawdofmt #include #undef Rawdofmt Compile, if it works leave it so, if not try the DoIO, might need both but I think it is RawDoFmt. Joop Joop.vandeWege@medew.ento.wau.nl From amiga-gcc-port-owner@nic.funet.fi Fri Dec 22 16:59:45 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90278-1>; Fri, 22 Dec 1995 16:56:44 +0200 Received: from kanga.INS.CWRU.Edu (cz253@kanga.INS.CWRU.Edu [129.22.8.32]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id OAA25730 for ; Fri, 22 Dec 1995 14:56:33 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id JAA25601; Fri, 22 Dec 1995 09:51:56 -0500 (from cz253) Message-Id: <199512221451.JAA25601@kanga.INS.CWRU.Edu> Date: Fri, 22 Dec 1995 09:51:56 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: walter@pctc.chemie.uni-erlangen.de Subject: Re: readline-2.0 Cc: cz253@cleveland.Freenet.Edu, amiga-gcc-port@nic.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from walter@pctc.chemie.uni-erlangen.de of Fri, 22 Dec > >Are there any interests? >May be it is usefull for pdksh , because I hate it >if I cannot do any commandloine editing with the cursor keys. Hmmm...perhaps I don't understand, but I have had command line editing via cursor keys with pdksh for a long time. -- .....Dave *\*/*\*/*\*/*\*/*\*/*\*/*\* From amiga-gcc-port-owner@nic.funet.fi Fri Dec 22 17:39:59 1995 Received: from amigalib.com ([165.247.33.2]) by nic.funet.fi with SMTP id <90713-1>; Fri, 22 Dec 1995 17:37:41 +0200 Received: by amigalib.com (Smail3.1.28.1 #64) id m0tT9ZP-0004nYC; Fri, 22 Dec 95 08:39 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: readline-2.0 To: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Date: Fri, 22 Dec 1995 08:39:42 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9512221058.AA24889@pctc.chemie.uni-erlangen.de> from "Thomas Walter" at Dec 22, 95 11:58:13 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 374 > I am working on a port of readline-2.0 to the amiga to get the history > and so on working. > > It compiles fine but there are two things missing > getpwent() > setpwent() The readline in the gdb distribution seems to work fine. You might want to examine it for changes. It should be sufficient to get the gdb diffs file from ftp.amigalib.com:pub/ade/951208. -Fred From amiga-gcc-port-owner@nic.funet.fi Fri Dec 22 21:56:06 1995 Received: from ns.neckar-alb.de ([194.77.118.1]) by nic.funet.fi with ESMTP id <90161-1>; Fri, 22 Dec 1995 21:53:41 +0200 Received: from wiedmann.neckar-alb.de (root@wiedmann.neckar-alb.de [194.77.119.253]) by ns.neckar-alb.de (8.7.1/8.7.1) with ESMTP id UAA18545 for ; Fri, 22 Dec 1995 20:51:13 +0100 (MET) Received: (from jochen@localhost) by wiedmann.neckar-alb.de (8.6.12/8.6.9) id PAA03178 for amiga-gcc-port@lists.funet.fi; Fri, 22 Dec 1995 15:27:27 +0100 From: Jochen Wiedmann Message-Id: <199512221427.PAA03178@wiedmann.neckar-alb.de> Subject: Patches for building a crosscompiler (summary) To: amiga-gcc-port@nic.funet.fi Date: Fri, 22 Dec 1995 15:27:26 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, below you find the patches that I needed to apply to the gcc-2.7.2 sources of Philippe in order to get a crosscompiler i586-unknown-linuxaout --> m68-unknown-amigados Changes are: - One cannot use /c/wait; I modified "/c/wait 2" to "$(C_WAIT_TWO_SECS)" and added the defition to x-amigados. - Unlike what rumours tell, one needs a libgcc1.a, fortunately gcc can create one for you; I copied the needed definitions from config/m68k/t-m68kbare. - Stack checking support must not be included into the compiler and amigasup.o must not be used; I moved the respective definitions from t-amigados to x-amigados. All these patches can be easily added to the current source tree, IMO. Unfortunately they aren't sufficient, manual work is left: - After applying the Amiga patches one must edit t-amigados to suppress the creation of libb/libgcc.a libm020/libgcc.a libb/libm020/libgcc.a, because of bugs in gcc. (I cannot say, if the amigados part or the i386 part is wrong.) Patch below, for obvious reasons this must not be added to the official source tree. - I added a patch which makes the crosscompiler look for system headers in /usr/amiga/include. The idea is to use this like GNUINCLUDE: on the Amiga for the true system headers. This works by adding a -I/usr/amiga/include to the specs definitions in amigados.h So, you get a crosscompiler following these steps: * Create a directory /usr/amiga, which is my base tree for the Amiga work. * Create a directory /usr/amiga/gnu, which is the crosscompilers home, similar to gnu: on the Amiga. * Unpack the original sources of binutils-2.5.2 and apply the Amiga patches. The latter are on Philippe's site. * Install the binutils using ./configure --prefix /usr/amiga/gnu --target m68k-cbm-amigados make make install Note, that there are some minor modifications needed on binutils: For example, ar, ranlib and ld aren't installed by default. * Get gcc270-inclib.lha or a similar package and dearchive it; move the os-include dir to /usr/amiga/gnu/lib/gcc-lib/m68k-cbm-amigados/2.7.2/sys-include and the include dir to /usr/amiga/gnu/m68k-cbm-amigados/include or vice versa, if you prefer. * Unpack the original sources of gcc-2.7.2 and apply the Amiga patches from Philippe's site. Apply the manual patches below. * Install gcc using ./configure --prefix /usr/amiga/gnu --target m68k-cbm-amigados make make install * You are done. :-) The crosscompiler can be found in /usr/amiga/gnu/m68k-cbm-amigados/bin/gcc Btw, thanks a lot to Rafael Luebbert for the BFD port: I tried to use ld-1.8 in the past and it was just horrible. :-( Note, that you are still unable to use flavors, as Fred already pointed out. This has severe drawbacks: -noixemul, -resident and -fbaserel all won't work. :-( Bye, Jochen Three patches below: -------------Manual patch for amigados.h------------------------------------ diff -c -b -r gcc-2.7.2.orig/config/m68k/amigados.h gcc-2.7.2/config/m68k/amigados.h *** gcc-2.7.2.orig/config/m68k/amigados.h Fri Dec 22 14:08:53 1995 --- gcc-2.7.2/config/m68k/amigados.h Fri Dec 22 14:39:31 1995 *************** *** 55,61 **** /* -msoft-float is the default, assume -mc68000 as well */ #define CPP_SPEC \ ! "%{m68881:-D__HAVE_68881__ }\ %{!ansi:%{m68020:-Dmc68020}%{mc68020:-Dmc68020}%{m68030:-Dmc68030}%{mc68030:-Dmc68030}%{m68040:-Dmc68040}\ %{mc68040:-Dmc68040}%{!mc68020:%{!m68020:%{!mc68030:%{!m68030:%{!mc68040:%{!m68040:-Dmc68010}}}}}}}" --- 55,61 ---- /* -msoft-float is the default, assume -mc68000 as well */ #define CPP_SPEC \ ! "%{!stdinclude:-I/usr/amiga/include }%{m68881:-D__HAVE_68881__ }\ %{!ansi:%{m68020:-Dmc68020}%{mc68020:-Dmc68020}%{m68030:-Dmc68030}%{mc68030:-Dmc68030}%{m68040:-Dmc68040}\ %{mc68040:-Dmc68040}%{!mc68020:%{!m68020:%{!mc68030:%{!m68030:%{!mc68040:%{!m68040:-Dmc68010}}}}}}}" ------------------------------------------------------------------------------ -----------This is the manual patch for t-amigados---------------------------- *** t-amigados.orig Fri Dec 22 14:19:18 1995 --- t-amigados Fri Dec 22 15:08:09 1995 *************** *** 98,109 **** # EXTRA_* macros to contain libb/libgcc.a, particularly for doing "make stageN" # or "make install". ! GCC_PARTS=$(GCC_PASSES) libgcc.a libb/libgcc.a libm020/libgcc.a \ ! libb/libm020/libgcc.a $(EXTRA_PROGRAMS) $(USE_COLLECT2) $(EXTRA_PARTS) # Add install_libbgcc to normal define of INSTALL_LIBGCC. ! INSTALL_LIBGCC = install-libgcc install-libbgcc install-libm020gcc install-libbm020gcc # This includes the knowledge that target amigados doesn't need libgcc1.a --- 98,109 ---- # EXTRA_* macros to contain libb/libgcc.a, particularly for doing "make stageN" # or "make install". ! GCC_PARTS=$(GCC_PASSES) libgcc.a \ ! $(EXTRA_PROGRAMS) $(USE_COLLECT2) $(EXTRA_PARTS) # Add install_libbgcc to normal define of INSTALL_LIBGCC. ! INSTALL_LIBGCC = install-libgcc # This includes the knowledge that target amigados doesn't need libgcc1.a ------------------------------------------------------------------------------ ---------------Patches for the official source tree-------------------------- diff -c -b -r gcc-2.7.2.orig/Makefile.in gcc-2.7.2/Makefile.in *** gcc-2.7.2.orig/Makefile.in Fri Dec 22 14:08:52 1995 --- gcc-2.7.2/Makefile.in Thu Dec 21 01:59:16 1995 *************** *** 926,933 **** # message from ar, we make sure all files are writable. -(cd tmpcopy; chmod +w * > /dev/null 2>&1) # The "cd..; wait" makes sure that the lock on tmpcopy has time to disappear. ! (cd tmpcopy; $(AR) x ../$(LIBGCC2); cd ..; /c/wait 2) ! (cd tmpcopy; $(AR) $(AR_FLAGS) ../tmplibgcc.a *$(objext); cd ..; /c/wait 2) rm -rf tmpcopy -if $(RANLIB_TEST) ; then $(RANLIB) tmplibgcc.a; else true; fi # Actually build it in tmplibgcc.a, then rename at end, --- 926,933 ---- # message from ar, we make sure all files are writable. -(cd tmpcopy; chmod +w * > /dev/null 2>&1) # The "cd..; wait" makes sure that the lock on tmpcopy has time to disappear. ! (cd tmpcopy; $(AR) x ../$(LIBGCC2); cd ..; $(C_WAIT_TWO_SECS)) ! (cd tmpcopy; $(AR) $(AR_FLAGS) ../tmplibgcc.a *$(objext); cd ..; $(C_WAIT_TWO_SECS)) rm -rf tmpcopy -if $(RANLIB_TEST) ; then $(RANLIB) tmplibgcc.a; else true; fi # Actually build it in tmplibgcc.a, then rename at end, diff -c -b -r gcc-2.7.2.orig/config/m68k/t-amigados gcc-2.7.2/config/m68k/t-amigados *** gcc-2.7.2.orig/config/m68k/t-amigados Fri Dec 22 14:08:54 1995 --- gcc-2.7.2/config/m68k/t-amigados Fri Dec 22 14:19:18 1995 *************** *** 45,50 **** --- 45,67 ---- LIBGCC1 = libgcc1.null + CROSS_LIBGCC1 = libgcc1-asm.a + LIB1ASMSRC = m68k/lb1sf68.asm + LIB1ASMFUNCS = _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 \ + _double _float _floatex \ + _eqdf2 _nedf2 _gtdf2 _gedf2 _ltdf2 _ledf2 \ + _eqsf2 _nesf2 _gtsf2 _gesf2 _ltsf2 _lesf2 + + # These are really part of libgcc1, but this will cause them to be + # built correctly, so... + LIB2FUNCS_EXTRA = fpgnulib.c xfgnulib.c + + fpgnulib.c: $(srcdir)/config/m68k/fpgnulib.c + cp $(srcdir)/config/m68k/fpgnulib.c fpgnulib.c + xfgnulib.c: $(srcdir)/config/m68k/fpgnulib.c + echo '#define EXTFLOAT' > xfgnulib.c + cat $(srcdir)/config/m68k/fpgnulib.c >> xfgnulib.c + # Flags to use when compiling the normal version of libgcc.a. # Don't compile with debugging, as long as there is no debugger. # Explicitly leave out the -resident compilation flag and don't use T_CFLAGS. *************** *** 249,263 **** (cd $(libsubdir)/libb/libm020; $(RANLIB) libgcc.a); else true; fi; \ chmod a-x $(libsubdir)/libb/libm020/libgcc.a; \ else true; fi - - # PhB: - # toplev.o target need to define additional flags to handle stack - # allocation in real main. As for now we hack building of toplev.o - # defining MAYBE_USE_COLLECT2 flag, which is only used for toplev.o. - # Then we define EXTRA_OBJS to amigasup.o. - - MAYBE_USE_COLLECT2= -Dmain=stkmain -Dexit=stkexit - EXTRA_OBJS = amigasup.o # When making one of the stage dirs, we need to make subdirs for # additional libraries, and copy them there. base-relative libraries --- 266,271 ---- diff -c -b -r gcc-2.7.2.orig/config/m68k/x-amigados gcc-2.7.2/config/m68k/x-amigados *** gcc-2.7.2.orig/config/m68k/x-amigados Fri Dec 22 14:08:54 1995 --- gcc-2.7.2/config/m68k/x-amigados Thu Dec 21 01:59:18 1995 *************** *** 37,41 **** --- 37,52 ---- RANLIB_TEST = true + # PhB: + # toplev.o target need to define additional flags to handle stack + # allocation in real main. As for now we hack building of toplev.o + # defining MAYBE_USE_COLLECT2 flag, which is only used for toplev.o. + # Then we define EXTRA_OBJS to amigasup.o. + + MAYBE_USE_COLLECT2= -Dmain=stkmain -Dexit=stkexit + EXTRA_OBJS = amigasup.o + # Build supplimentary Amiga host support file. amigasup.o: amigasup.c + + C_WAIT_TWO_SECS = /c/wait 2 diff -c -b -r gcc-2.7.2.orig/config/m68k/xm-amigados.h gcc-2.7.2/config/m68k/xm-amigados.h *** gcc-2.7.2.orig/config/m68k/xm-amigados.h Fri Dec 22 14:08:54 1995 --- gcc-2.7.2/config/m68k/xm-amigados.h Fri Dec 22 14:43:04 1995 *************** *** 32,39 **** --- 32,43 ---- go in SYSTEM_INCLUDE_DIR. STANDARD_INCLUDE_DIR is the equivalent of Unix "/usr/include". All other include paths are set in Makefile. */ + #ifndef SYSTEM_INCLUDE_DIR #define SYSTEM_INCLUDE_DIR "/gnu/os-include" + #endif + #ifndef STANDARD_INCLUDEDIR #define STANDARD_INCLUDE_DIR "/gnu/include" + #endif /* the vfork() version. This one has the drawback, that gcc is not interruptible when started from make, since ixemul.library doesn't yet From amiga-gcc-port-owner@nic.funet.fi Sat Dec 23 19:23:38 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <90480-3>; Sat, 23 Dec 1995 19:21:12 +0200 Received: from carina.rz.Uni-Osnabrueck.DE by funet.fi with SMTP (PP); Sat, 23 Dec 1995 19:21:04 +0200 Received: from nereid.rz.Uni-Osnabrueck.DE (nereid.rz.Uni-Osnabrueck.DE [131.173.128.14]) by carina.rz.Uni-Osnabrueck.DE (8.6.12/8.6.12) with ESMTP id SAA38274; Sat, 23 Dec 1995 18:21:00 +0100 From: Thomas Radtke Received: (from thradtke@localhost) by nereid.rz.Uni-Osnabrueck.DE (8.7.1/8.7.1) id SAA20381; Sat, 23 Dec 1995 18:20:59 +0100 Message-Id: <199512231720.SAA20381@nereid.rz.Uni-Osnabrueck.DE> Subject: Re: readline-2.0 To: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Date: Sat, 23 Dec 1995 18:20:59 +0100 (NFT) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9512221058.AA24889@pctc.chemie.uni-erlangen.de> from "Thomas Walter" at Dec 22, 95 11:58:13 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > But I also compiled examples/histexamp and there you get the history with the > cursor keys working. So I think there are only some (simple ?) additions > in the test code of readline to get it work with cursor keys too. You must set the prefix in .inputrc. Below is a copy of my Amiga rc file. Thomas "\e\C-[": arrow-key-prefix [lots of stuff deleted ;] From amiga-gcc-port-owner@nic.funet.fi Sun Dec 24 02:05:40 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90817-2>; Sun, 24 Dec 1995 01:58:53 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tTeYv-000QyJC; Sun, 24 Dec 95 01:45 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0exc@wyst.hobby.nl>; Sun, 24 Dec 95 00:46:38 CET Message-Id: <9512232346.0exc@wyst.hobby.nl> Date: Sun, 24 Dec 1995 00:46:37 +0000 (CET) In-Reply-To: <199512220120.BAA00815@colombo.telesys-innov.fr> from "Philippe BRAND" at Dec 22, 95 01:20:13 am Content-Type: text Content-Length: 664 From: hans@wyst.hobby.nl (Hans Verkuil) To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@lists.funet.fi Subject: Re: Gcc-2.7.2 C/C++/Objc beta available Philippe, > I'm still waiting for ixemul42 to compile gcc using auto-stackextend feature. I thought I mentioned this before, but the auto-stackextend feature will be delayed until 43.0. I want to be sure the library is completely stable and working properly before introducing such lowlevel changes as stackextension. Sorry. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Mon Dec 25 17:14:23 1995 Received: from gate1.informatik.fh-wiesbaden.de ([193.175.36.254]) by nic.funet.fi with SMTP id <90524-4>; Mon, 25 Dec 1995 17:12:00 +0200 Received: from sun.informatik.fh-wiesbaden.de (sun15.informatik.fh-wiesbaden.de) by gate1.informatik.fh-wiesbaden.de with SMTP id AA02698 (5.65c/IDA-1.4.4 for ); Mon, 25 Dec 1995 16:11:45 +0100 Received: from sun12.informatik.fh-wiesbaden.de by sun.informatik.fh-wiesbaden.de (4.1/fhw-FBI_sun-Nl) id AA00208; Mon, 25 Dec 95 16:11:42 +0100 Received: by sun12.informatik.fh-wiesbaden.de (4.1/fhw_FBI-sun12-Nl) id AA00383; Mon, 25 Dec 95 16:11:35 +0100 Date: Mon, 25 Dec 1995 16:11:35 +0100 (MET) From: Stefan Ruppert To: amiga-gcc-port@nic.funet.fi Subject: GNU-make extention Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, I have written a text function called apath for gmake, which translate Unix pathnames to AmigaDOS. For example : $(apath ../include/misc /objs/make) will produce strings like /include/misc and objs:make . Now my question is, where to send the diff file ? Is there a place for amiga specific changes ? Or should I send this to the FSF ? Ciao Stefan -- Home: Stefan Ruppert EMail: ruppert@goofy.zdv.uni-mainz.de Windthorststrasse 5 ruppert@informatik.fh-wiesbaden.de 65439 Floersheim am Main WWW: http://www.uni-mainz.de/~ruppert/ GERMANY From amiga-gcc-port-owner@nic.funet.fi Tue Dec 26 05:28:33 1995 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <89348-1>; Tue, 26 Dec 1995 05:25:12 +0200 Received: from pobox.csc.fi by funet.fi with SMTP (PP); Tue, 26 Dec 1995 00:26:02 +0200 Received: from konrad.lysator.liu.se (root@lysnet-gw.lysator.liu.se [130.236.253.6]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id WAA17331 for ; Mon, 25 Dec 1995 22:25:59 GMT Received: from tiny.lysator.liu.se (tiny.lysator.liu.se [130.236.253.10]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id XAA12365; Mon, 25 Dec 1995 23:25:56 +0100 Received: (nisse@localhost) by tiny.lysator.liu.se (8.6.11/8.6.11) id XAA08551; Mon, 25 Dec 1995 23:25:54 +0100 Date: Mon, 25 Dec 1995 23:25:54 +0100 Message-Id: <199512252225.XAA08551@tiny.lysator.liu.se> From: "Niels Mller" To: Stefan Ruppert CC: amiga-gcc-port@nic.funet.fi In-reply-to: Stefan Ruppert's message of Mon, 25 Dec 1995 16:11:35 +0100 (MET) Subject: Re: GNU-make extention MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: Stefan Ruppert writes: > I have written a text function called apath for gmake, which translate > Unix pathnames to AmigaDOS. For example : > > $(apath ../include/misc /objs/make) will produce strings like > /include/misc and objs:make . Why do you need this? I thought ixemul was supposed to take care of such translations for you. Or are you using some special non-ixemul make? Or perhaps you just want to run ordinary amiga-programs from the makefile? In the latter case, I wonder if it would be useful to have exec() (or whatever function is used for starting new processes) translate filenames in the argv array automagically? /Just curious From amiga-gcc-port-owner@nic.funet.fi Tue Dec 26 06:21:19 1995 Received: from dira.bris.ac.uk ([137.222.10.41]) by nic.funet.fi with ESMTP id <88921-3>; Tue, 26 Dec 1995 06:20:06 +0200 Received: from zeus.bris.ac.uk by dira.bris.ac.uk with SMTP (PP); Mon, 25 Dec 1995 18:40:43 +0000 Received: by zeus.bris.ac.uk (950215.SGI.8.6.10/940406.SGI) for amiga-gcc-port@nic.funet.fi id SAA12231; Mon, 25 Dec 1995 18:40:42 GMT From: Pierre.Scotney@bristol.ac.uk (PD. Scotney) Message-Id: <199512251840.SAA12231@zeus.bris.ac.uk> Subject: HAPPY CHRISTMAS! To: amiga-gcc-port@nic.funet.fi Date: Mon, 25 Dec 1995 18:40:42 +0000 (GMT) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 75 Happy Christmas to everybody on the Amiga GCC mail-list. Cheers. Pierre. From amiga-gcc-port-owner@nic.funet.fi Tue Dec 26 16:40:15 1995 Received: from lorenz.gbar.dtu.dk ([130.225.87.180]) by nic.funet.fi with ESMTP id <90096-1>; Tue, 26 Dec 1995 16:39:32 +0200 Received: by lorenz.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 26 Dec 1995 15:20:35 +0100 (MET) From: Rask Lambertsen To: Joerg Hoehle Cc: amiga-gcc-port@nic.funet.fi Subject: re: Problems with libraries/mathieeesp.h (also for the README) In-Reply-To: <199512111613.AA01322@diva.gmd.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Dec 1995, Joerg Hoehle wrote: > test1@medew.ento.wau.nl writes: > > Am I the only one getting some messages twice? > > Those are exact duplicates, from and to addresses too. So it is not someone > > sending to the list and another copy to me too. > > Persons involved: Kamil, Joerg and Niels. > > As people not on this mailing list are allowed to mail to the list, I > went over to reply to both the sender and the list to make sure the > sender gets the response. Yet I find receiving the same mail twice > annoying. Whenever I get a message twice, it's for this reason and the > headers show a difference. Some mail programs do not show all headers, > so maybe you don't see the difference. Do you see "Received: ..." > lines, they tell you the way the mail went. I think the real problem is the mailing list software. It should set the From: field to the address of the mailing list and Cc: to the address of the person that sent the letter, instead of the other way around as it does now. Then it would be possible (for Pine users at least) to answer "No" to the question "Reply to all recipients?". Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Dec 27 13:41:24 1995 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90075-1>; Wed, 27 Dec 1995 13:33:34 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA12392; Wed, 27 Dec 1995 12:35:39 +0100 Date: Wed, 27 Dec 1995 12:35:38 +0100 (MET) From: Kamil Iskra To: Amiga GCC List Subject: gcc 2.7.2 or ixemul 41.4 bugs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII After switching to gcc 2.7.2, I noticed two strange things which scare me a bit... None of these problems existed in 2.7.0, but I might be wrong, since 2.7.2 uses "gccv" by default, and I've never used it in 2.7.0. First thing is connected with breaking gcc using ^C. I'm getting the following output: 5.Ram Disk:> gcc -O2 -o test test.c ^C 5.Ram Disk:> Interrupt - /gnu/lib/gcc-lib/m68000-unknown-amigaos/2.7.2/cpp What scares me is the fact that the last message from gcc is printed after shell prompt. This would mean that it is printed after gcc finishes its execution - its hunks are freed and so on. I guess that this is just IXEmul flushing its buffers, but I don't like this behaviour - it should be made earlier, before interrupted program terminates. Another, much more serious problem occurs when there is not enough memory to load cc1: 8.Ram Disk:> gcc -O2 -o test test.c gcc: installation problem, cannot exec `/gnu/lib/gcc-lib/m68000-unknown-amigao s/2.7.2/cc1': No such file or directory *unknown*: Assembler messages: *unknown*:0: Can't open /t/cc504984.s for reading: No such file or directory ld: failure reading string table size of /t/cc5049841.o 8.Ram Disk:> First of all, please notice that gcc gives wrong warning message: I _DO_ have cc1 in the right place. Second, please notice that gcc doesn't abort compilation - it invokes assembler and, if called with "-c", returnes 0! What's more, assembler creates small, 32 bytes long file. This causes very serious problems in Makefiles - make thinks that everything went right - returncode 0, new output file created. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Dec 27 14:56:47 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90131-4>; Wed, 27 Dec 1995 14:51:46 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tUw50-000RYHC; Wed, 27 Dec 95 14:39 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0f5v@wyst.hobby.nl>; Wed, 27 Dec 95 13:35:19 CET Message-Id: <9512271235.0f5v@wyst.hobby.nl> Date: Wed, 27 Dec 1995 13:35:19 +0000 (CET) In-Reply-To: from "Kamil Iskra" at Dec 27, 95 12:35:38 pm Content-Type: text Content-Length: 2482 From: hans@wyst.hobby.nl (Hans Verkuil) To: kiskra@ernie.icslab.agh.edu.pl Cc: amiga-gcc-port@nic.funet.fi, phb@colombo.telesys-innov.fr Subject: Re: gcc 2.7.2 or ixemul 41.4 bugs Hi Kamil, > After switching to gcc 2.7.2, I noticed two strange things which scare me > a bit... None of these problems existed in 2.7.0, but I might be wrong, > since 2.7.2 uses "gccv" by default, and I've never used it in 2.7.0. > > First thing is connected with breaking gcc using ^C. I'm getting the > following output: > > 5.Ram Disk:> gcc -O2 -o test test.c > ^C > 5.Ram Disk:> Interrupt - /gnu/lib/gcc-lib/m68000-unknown-amigaos/2.7.2/cpp > > What scares me is the fact that the last message from gcc is printed after > shell prompt. This would mean that it is printed after gcc finishes its > execution - its hunks are freed and so on. I guess that this is just > IXEmul flushing its buffers, but I don't like this behaviour - it should > be made earlier, before interrupted program terminates. No, what is happening is that gcc terminates before cpp (which was started by gcc). This behavior is perfectly OK, and I don't think there is much that can be done about this. > Another, much more serious problem occurs when there is not enough memory > to load cc1: > > 8.Ram Disk:> gcc -O2 -o test test.c > gcc: installation problem, cannot exec `/gnu/lib/gcc-lib/m68000-unknown-amigao > s/2.7.2/cc1': No such file or directory > *unknown*: Assembler messages: > *unknown*:0: Can't open /t/cc504984.s for reading: No such file or directory > ld: failure reading string table size of /t/cc5049841.o > 8.Ram Disk:> > > First of all, please notice that gcc gives wrong warning message: I _DO_ Ah, a bug in ixemul: the exec* functions don't check for 'out of memory' at all. I'll add that to the library. Thanks. > have cc1 in the right place. Second, please notice that gcc doesn't abort > compilation - it invokes assembler and, if called with "-c", returnes 0! > What's more, assembler creates small, 32 bytes long file. This causes very > serious problems in Makefiles - make thinks that everything went right - > returncode 0, new output file created. This seems to be a problem in gcc. I looks as if gcc is starting a pipeline instead of executing each command separately. Philippe, do you have to time to check this out? Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Dec 27 15:42:50 1995 Received: from rumms.uni-mannheim.de ([134.155.50.52]) by nic.funet.fi with SMTP id <90283-4>; Wed, 27 Dec 1995 15:37:15 +0200 Received: from pips01.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA08305 (5.65c/IDA-1.4.4 for ); Wed, 27 Dec 1995 14:37:36 +0100 Received: from pips15.informatik.uni-mannheim.de by pips01.informatik.uni-mannheim.de (4.1/BelWue-1.1Sma2(subsidiary)) id AA27032; Wed, 27 Dec 95 14:33:16 +0100 Received: by pips15.informatik.uni-mannheim.de (5.0/SMI-SVR4) id AA05012; Wed, 27 Dec 1995 14:32:15 --100 From: opel@pips01.informatik.uni-mannheim.de (Steffen Opel) Message-Id: <9512271332.AA05012@pips15.informatik.uni-mannheim.de> Subject: Re: Gcc-2.7.2 C/C++/Objc beta available To: hans@wyst.hobby.nl (Hans Verkuil) Date: Wed, 27 Dec 1995 14:32:12 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9512232346.0exc@wyst.hobby.nl> from "Hans Verkuil" at Dec 24, 95 00:46:37 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 273 Salut Hans, > I thought I mentioned this before, but the auto-stackextend feature will be > delayed until 43.0. [...] This means, GCCSTACK is still needed, am I right? (I already deleted it from GCC-Install, which would have to be undone therefore!) Ciao, Steffen Opel From amiga-gcc-port-owner@nic.funet.fi Wed Dec 27 17:27:38 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <89772-4>; Wed, 27 Dec 1995 17:18:21 +0200 Received: by colombo.telesys-innov.fr; Wed, 27 Dec 1995 16:14:43 GMT From: Philippe BRAND Message-Id: <199512271614.QAA28450@colombo.telesys-innov.fr> Subject: Re: gcc 2.7.2 or ixemul 41.4 bugs To: kiskra@ernie.icslab.agh.edu.pl (Kamil Iskra) Date: Wed, 27 Dec 1995 16:14:42 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Kamil Iskra" at Dec 27, 95 12:35:38 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Kamil Iskra writes: > What scares me is the fact that the last message from gcc is printed after > shell prompt. This would mean that it is printed after gcc finishes its > execution - its hunks are freed and so on. I guess that this is just > IXEmul flushing its buffers, but I don't like this behaviour - it should > be made earlier, before interrupted program terminates. This is normal behaviour, and can't do nothing against it. > Another, much more serious problem occurs when there is not enough memory > to load cc1: > > 8.Ram Disk:> gcc -O2 -o test test.c > gcc: installation problem, cannot exec `/gnu/lib/gcc-lib/m68000-unknown-amigao > s/2.7.2/cc1': No such file or directory > *unknown*: Assembler messages: > *unknown*:0: Can't open /t/cc504984.s for reading: No such file or directory > ld: failure reading string table size of /t/cc5049841.o > 8.Ram Disk:> > > First of all, please notice that gcc gives wrong warning message: I _DO_ > have cc1 in the right place. Second, please notice that gcc doesn't abort > compilation - it invokes assembler and, if called with "-c", returnes 0! Hum.. I will have to check whether ixemul returns bad code or gcc handles it in the bad way. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://colombo.telis-sc.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed Dec 27 19:19:58 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90545-2>; Wed, 27 Dec 1995 19:18:58 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tV0Gh-000RYpC; Wed, 27 Dec 95 19:08 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0f6y@wyst.hobby.nl>; Wed, 27 Dec 95 16:39:35 CET Message-Id: <9512271539.0f6y@wyst.hobby.nl> Date: Wed, 27 Dec 1995 16:39:34 +0000 (CET) In-Reply-To: <9512271332.AA05012@pips15.informatik.uni-mannheim.de> from "Steffen Opel" at Dec 27, 95 02:32:12 pm Content-Type: text Content-Length: 626 From: hans@wyst.hobby.nl (Hans Verkuil) To: opel@pips01.informatik.uni-mannheim.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Gcc-2.7.2 C/C++/Objc beta available > Salut Hans, > > > I thought I mentioned this before, but the auto-stackextend feature will be > > delayed until 43.0. [...] > This means, GCCSTACK is still needed, am I right? (I already deleted it from > GCC-Install, which would have to be undone therefore!) Yes, it is still needed. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Dec 27 21:27:57 1995 Received: from lillep.gbar.dtu.dk ([130.225.87.179]) by nic.funet.fi with ESMTP id <90348-4>; Wed, 27 Dec 1995 21:24:00 +0200 Received: by lillep.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 27 Dec 1995 20:23:52 +0100 (MET) From: Rask Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: New README Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Once again I have a new README with some corrections and additions. Once again it explains the use of GCCSTACK and it contains some new diffs from Kamil Iskra. The README is available on the WWW: I will email it if requested and I am creating a list of people that will get it by email whenever I have a new README ready. Steffen, you are already on the list :-). But please get it from the HTTP server if you can. Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Dec 28 11:28:21 1995 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <90924-3>; Thu, 28 Dec 1995 11:25:32 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id KAA05704 (8.7.2/7.5a-FAU);; Thu, 28 Dec 1995 10:24:31 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA14093; Thu, 28 Dec 1995 10:24:15 +0100 Date: Thu, 28 Dec 1995 10:24:15 +0100 Message-Id: <9512280924.AA14093@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: cz253@cleveland.freenet.edu Cc: cz253@cleveland.freenet.edu, amiga-gcc-port@lists.funet.fi In-Reply-To: <199512221451.JAA25601@kanga.INS.CWRU.Edu> (cz253@cleveland.Freenet.Edu) Subject: Re: readline-2.0 Hello, very intersting to hear about history with cursor keys in pdksh. The shell sh in the AMIGA GNU tree is pdksh. But all versions I tried accept only the emacs-style commands. Pressing any cursor key will result only in a screen-flush and a capital letter near the command line prompt. -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Thu Dec 28 11:42:27 1995 Received: from net2.wau.nl ([137.224.10.12]) by nic.funet.fi with ESMTP id <89168-1>; Thu, 28 Dec 1995 11:41:57 +0200 Received: from vines2.wau.nl by NET.WAU.NL (PMDF V4.3-10 #6821) id <01HZC6KS0TSG0008CG@NET.WAU.NL>; Thu, 28 Dec 1995 10:47:26 +0000 (GMT) Received: by vines2.wau.nl; Thu, 28 Dec 95 10:41:29 +0100 Date: Thu, 28 Dec 1995 10:38:51 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: Re: readline-2.0 To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >The shell sh in the AMIGA GNU tree is pdksh. But all versions I tried >accept only the emacs-style commands. Pressing any cursor key will result >only in a screen-flush and a capital letter near the command line prompt. >Thomas Walter I use KingCON (1.3) and I do have the normal cursor key history/editing available which you also get in the AmigaDOS shell. I don't know if commandline completion is active because I hardly use that. Will check. I'm using the 'sh' that comes with gcc2.7.0. Joop Joop.vandeWege@medew.ento.wau.nl From amiga-gcc-port-owner@nic.funet.fi Thu Dec 28 18:44:44 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <90371-1>; Thu, 28 Dec 1995 18:44:09 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id LAA24115; Thu, 28 Dec 1995 11:09:11 -0500 (from cz253) Message-Id: <199512281609.LAA24115@kanga.INS.CWRU.Edu> Date: Thu, 28 Dec 1995 11:09:11 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: walter@pctc.chemie.uni-erlangen.de Subject: Re: readline-2.0 Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from walter@pctc.chemie.uni-erlangen.de of Thu, 28 Dec > > >Hello, >very intersting to hear about history with cursor keys in pdksh. > >The shell sh in the AMIGA GNU tree is pdksh. But all versions I tried >accept only the emacs-style commands. Pressing any cursor key will result >only in a screen-flush and a capital letter near the command line prompt. Hmmm... And you are using the pdksh from the /gnu tree? What shell are you running it in? I run the pdksh in the stock AmigaShell. If you are doing the same, the only other thing I can think of is that pdksh is not finding the termcap file in /etc, or the termcap file is messed up. -- .....Dave *\*/*\*/*\*/*\*/*\*/*\*/*\* / Happy Holidays to All!! / *\*/*\*/*\*/*\*/*\*/*\*/*\* From amiga-gcc-port-owner@nic.funet.fi Fri Dec 29 02:01:58 1995 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90568-4>; Fri, 29 Dec 1995 01:56:32 +0200 Received: from konrad.lysator.liu.se (root@lysnet-gw.lysator.liu.se [130.236.253.6]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id XAA15326 for ; Thu, 28 Dec 1995 23:56:29 GMT Received: from tina.lysator.liu.se (tina.lysator.liu.se [130.236.253.14]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id AAA22192; Fri, 29 Dec 1995 00:56:16 +0100 Received: (nisse@localhost) by tina.lysator.liu.se (8.6.11/8.6.11) id AAA05245; Fri, 29 Dec 1995 00:56:15 +0100 Date: Fri, 29 Dec 1995 00:56:15 +0100 Message-Id: <199512282356.AAA05245@tina.lysator.liu.se> From: "Niels Möller" To: cz253@cleveland.Freenet.Edu (David Zaroski) Cc: amiga-gcc-port@nic.funet.fi In-reply-to: cz253@cleveland.Freenet.Edu's message of Thu, 28 Dec 1995 11:09:11 -0500 Subject: Re: readline-2.0 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: <199512281609.LAA24115@kanga.INS.CWRU.Edu> cz253@cleveland.Freenet.Edu (David Zaroski) writes: > >The shell sh in the AMIGA GNU tree is pdksh. But all versions I tried > >accept only the emacs-style commands. Pressing any cursor key will result > >only in a screen-flush and a capital letter near the command line prompt. > > Hmmm... And you are using the pdksh from the /gnu tree? What shell are you > running it in? I run the pdksh in the stock AmigaShell. If you are doing > the same, the only other thing I can think of is that pdksh is not finding > the termcap file in /etc, or the termcap file is messed up. I usually run sh under the Amiga shell; I open a standard amiga shell, with a standard console-window: Amiga-Shell> gnu:bin/sh # ls ... # ls I think this is the history facility in the console, which has nothing to do with pdksh or termcap. I don't use readline, and have no .inputrc file. Perhaps that is relevant. And I also use the cfn utility, to get filename completion in shell windows, and as an extra bonus, in any program running in the shell window. It's probably something of a kluge, but it works the way I want, most of the time. /Niels From amiga-gcc-port-owner@nic.funet.fi Fri Dec 29 06:12:55 1995 Received: from head-cfa.harvard.edu ([128.103.42.3]) by nic.funet.fi with SMTP id <90689-1>; Fri, 29 Dec 1995 06:08:59 +0200 Received: from pelf (pelf.harvard.edu) by head-cfa.harvard.edu (4.1/SMI-4.0) id AA24002; Thu, 28 Dec 95 23:08:43 EST Received: by pelf (5.0/SMI-SVR4) id AA02771; Thu, 28 Dec 1995 23:08:42 -0500 Date: Thu, 28 Dec 1995 23:08:42 -0500 From: dj@head-cfa.harvard.edu (Diab Jerius) Message-Id: <9512290408.AA02771@pelf> To: amiga-gcc-port@lists.funet.fi Subject: bug in make Content-Length: 1936 I'm using the make from the Fresh Fish X CDROM. I'm running under AmigaOS 2.1. Here's a makefile which isolates the problem: % type GNUmakefile dir/foo.h : dir/%.h : @echo $* Here's the output under AmigaOS: % version Kickstart version 37.175, Workbench version 38.35 % make --version GNU Make version 3.74, by Richard Stallman and Roland McGrath. Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % make make: *** No rule to make target `dir/%.h', needed by `dir/foo.h'. Stop. % This is incorrect. There are no dependencies for dir/foo.h. Here's the response of two other versions of GNU make, on two other OS's: pelf% uname -a SunOS pelf 5.3 Generic_101318-70 sun4m sparc pelf% gmake --version GNU Make version 3.71, by Richard Stallman and Roland McGrath. Copyright (C) 1988, 89, 90, 91, 92, 93, 94 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. pelf% gmake foo vger% uname -a IRIX vger 5.2 02282016 IP22 mips vger% gmake --version GNU Make version 3.74, by Richard Stallman and Roland McGrath. Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. vger% gmake foo These are the correct responses. Does anyone have a clue as to what's going on here? I appreciate your help on this. Diab -- Diab Jerius Harvard-Smithsonian Center for Astrophysics 60 Garden St, MS 70, Cambridge MA 02138 USA djerius@cfa.harvard.edu vox: 617 496 7575 fax: 617 495 7356 From amiga-gcc-port-owner@nic.funet.fi Fri Dec 29 19:30:34 1995 Received: from kanga.INS.CWRU.Edu ([129.22.8.32]) by nic.funet.fi with ESMTP id <89336-4>; Fri, 29 Dec 1995 19:28:26 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id MAA24320; Fri, 29 Dec 1995 12:28:13 -0500 (from cz253) Message-Id: <199512291728.MAA24320@kanga.INS.CWRU.Edu> Date: Fri, 29 Dec 1995 12:28:13 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: amiga-gcc-port@lists.funet.fi Subject: exec.ibrary _LVO -516 Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) What is execPrivate9(), exec.library _LVO -516? -- .....Dave *\*/*\*/*\*/*\*/*\*/*\*/*\* / Happy Holidays to All!! / *\*/*\*/*\*/*\*/*\*/*\*/*\* From amiga-gcc-port-owner@nic.funet.fi Fri Dec 29 19:30:59 1995 Received: from rumms.uni-mannheim.de ([134.155.50.52]) by nic.funet.fi with SMTP id <90866-3>; Fri, 29 Dec 1995 18:54:25 +0200 Received: from pips01.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA17411 (5.65c/IDA-1.4.4 for ); Fri, 29 Dec 1995 17:54:35 +0100 Received: from pips16.informatik.uni-mannheim.de by pips01.informatik.uni-mannheim.de (4.1/BelWue-1.1Sma2(subsidiary)) id AA29363; Fri, 29 Dec 95 17:50:12 +0100 Received: by pips16.informatik.uni-mannheim.de (5.0/SMI-SVR4) id AA01512; Fri, 29 Dec 1995 17:55:04 --100 From: opel@pips01.informatik.uni-mannheim.de (Steffen Opel) Message-Id: <9512291655.AA01512@pips16.informatik.uni-mannheim.de> Subject: GCC-Install 2.15 (for 2.7.2) uploaded to pub/amigados-gnu/uploads To: phb@telesys-innov.fr Date: Fri, 29 Dec 1995 17:55:03 +0100 (MET) Cc: amiga-gcc-port@nic.funet.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 308 Salut, since GCCSTACK will still be needed, I added it again to GCC-Install (2.15 now) and uploaded the latter to ftp.telesys-innov.fr/pub/amigados-gnu/uploads. There are no other changes. The previous uploads (without version-number and version 2.14) are obsolete and could be deleted. Ciao, Steffen Opel From amiga-gcc-port-owner@nic.funet.fi Fri Dec 29 19:41:56 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89172-4>; Fri, 29 Dec 1995 19:40:48 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tVjYz-000RHSC; Fri, 29 Dec 95 19:29 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0f9d@wyst.hobby.nl>; Fri, 29 Dec 95 12:32:04 CET Message-Id: <9512291132.0f9d@wyst.hobby.nl> Date: Fri, 29 Dec 1995 12:32:03 +0000 (CET) In-Reply-To: <9512290408.AA02771@pelf> from "Diab Jerius" at Dec 28, 95 11:08:42 pm Content-Type: text Content-Length: 1046 From: hans@wyst.hobby.nl (Hans Verkuil) To: dj@head-cfa.harvard.edu Cc: amiga-gcc-port@lists.funet.fi Subject: Re: bug in make Hi Diab, > I'm using the make from the Fresh Fish X CDROM. I'm running under AmigaOS 2.1. > Here's a makefile which isolates the problem: > These are the correct responses. Does anyone have a clue as to what's > going on here? I appreciate your help on this. Yep, this was the result of a patch that allowed the use of AmigaDOS filenames in a makefile, unfortunately this patch also disabled a useful feature of GNU make. I've asked Fred to remove that patch and he did (well, he had to because I used those GNU extensions in the new 42.0 ixemul.library Makefiles :-). You can get the new make from ftp.amigalib.com, in directory pub/amiga/ade. From memory, so the directory might be a bit different in reality. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Dec 29 20:32:27 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90452-2>; Fri, 29 Dec 1995 20:31:43 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tVkNG-000RHSC; Fri, 29 Dec 95 20:21 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0fai@wyst.hobby.nl>; Fri, 29 Dec 95 18:52:42 CET Message-Id: <9512291752.0fai@wyst.hobby.nl> Date: Fri, 29 Dec 1995 18:52:41 +0000 (CET) In-Reply-To: <199512291728.MAA24320@kanga.INS.CWRU.Edu> from "David Zaroski" at Dec 29, 95 12:28:13 pm Content-Type: text Content-Length: 546 From: hans@wyst.hobby.nl (Hans Verkuil) To: cz253@cleveland.Freenet.Edu Cc: amiga-gcc-port@lists.funet.fi Subject: Re: exec.ibrary _LVO -516 According to David Zaroski: > > What is execPrivate9(), exec.library _LVO -516? According to the RKM Autodocs and Includes, it is the function RawPutChar(). Apparently this function sends a character to the serial device for debugging. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Fri Dec 29 21:27:52 1995 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <90093-1>; Fri, 29 Dec 1995 21:26:29 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 29 Dec 1995 20:26:04 +0100 (MET) From: Rask Lambertsen To: Hans Verkuil Cc: cz253@cleveland.Freenet.Edu, amiga-gcc-port@nic.funet.fi Subject: Re: exec.ibrary _LVO -516 In-Reply-To: <9512291752.0fai@wyst.hobby.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 29 Dec 1995, Hans Verkuil wrote: > According to David Zaroski: > > > > What is execPrivate9(), exec.library _LVO -516? > > According to the RKM Autodocs and Includes, it is the function > RawPutChar(). Apparently this function sends a character to the serial > device for debugging. Is this what happens? I thought it was just a do-nothing entry to be SetPatch()ed by programmes like Sushi. Is this how Sushi can intercept serial output? Does this mean that Walter Harms libdebug.a uses this function too? Does anybody know why this function is supposed to be private (it wasn't in my OS 2.1 fd files, btw)? Am I asking too many questions on one go? Btw, notice how nicely it is prepared for being the "putChar" function for RawDoFormat(). Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Dec 29 22:24:36 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <90093-1>; Fri, 29 Dec 1995 22:21:26 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.7.1/8.7.1) id VAA23237; Fri, 29 Dec 1995 21:20:40 +0100 (MET) Date: Fri, 29 Dec 1995 21:20:40 +0100 (MET) From: Ignatios Souvatzis Message-Id: <199512292020.VAA23237@theory.cs.uni-bonn.de> To: cz253@cleveland.Freenet.Edu CC: amiga-gcc-port@nic.funet.fi In-reply-to: David Zaroski's message of Fri, 29 Dec 1995 12:28:13 -0500 <199512291728.MAA24320@kanga.INS.CWRU.Edu> Subject: exec.ibrary _LVO -516 X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a; Sat, 30 Dec 1995 01:10:53 +0200 Received: (cz253@localhost) by kanga.INS.CWRU.Edu (8.6.12+cwru/CWRU-2.1-bsdi) id SAA28925; Fri, 29 Dec 1995 18:10:11 -0500 (from cz253) Message-Id: <199512292310.SAA28925@kanga.INS.CWRU.Edu> Date: Fri, 29 Dec 1995 18:10:11 -0500 From: cz253@cleveland.Freenet.Edu (David Zaroski) To: ignatios@theory.cs.uni-bonn.de Subject: Re: exec.ibrary _LVO -516 Cc: amiga-gcc-port@lists.funet.fi Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) Reply to message from ignatios@theory.cs.uni-bonn.de of Fri, 29 Dec > > Date: Fri, 29 Dec 1995 12:28:13 -0500 > From: cz253@cleveland.Freenet.Edu (David Zaroski) > Reply-To: cz253@cleveland.Freenet.Edu (David Zaroski) > > What is execPrivate9(), exec.library _LVO -516? > >none of our business. Strictly exec.library private. It use to be, or is RawPutChar(). What replaces that function? Or, how can it be replaced? -- .....Dave *\*/*\*/*\*/*\*/*\*/*\*/*\* / Happy Holidays to All!! / *\*/*\*/*\*/*\*/*\*/*\*/*\* From amiga-gcc-port-owner@nic.funet.fi Sat Dec 30 14:34:37 1995 Received: from trappist.elis.rug.ac.be ([157.193.67.1]) by nic.funet.fi with SMTP id <90127-2>; Sat, 30 Dec 1995 14:29:09 +0200 Received: from ibmpar.elis.rug.ac.be by trappist.elis.rug.ac.be with SMTP id AA10267 (5.65c/IDA-1.4.4 for ); Sat, 30 Dec 1995 13:32:10 +0100 Received: by ibmpar.elis.rug.ac.be (AIX 3.2/UCB 5.64/4.03) id AA14610; Sat, 30 Dec 1995 13:33:38 GMT From: bvassche@ibmpar.elis.rug.ac.be (Bart Van Assche) Message-Id: <9512301333.AA14610@ibmpar.elis.rug.ac.be> Subject: gcc/g++ math bug ? To: amiga-gcc-port@nic.funet.fi Date: Sat, 30 Dec 1995 13:33:38 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2279 Hello, While debugging a numerical C++ program I discovered some strange behaviour of the libm.a comparison of double-precision floating point numbers. The problem could be isolated to the appended program. A single comparison turned out to be the source of the problem: for the two numbers a and b in the program below, it is easy to see that (a > b) == 1. gcc correctly reports that (a < b) == 0 and (a > b) == 1, but incorrectly reports that (b < a) == 0 and (b > a) == 1 !!! I know that the numbers compared are very close to one another. But this gcc behaviour violates such basic properties as (a < b) == (b > a). Is this intended behaviour, and if not, has this problem been solved in more recent gcc versions ? gcc version information: Reading specs from /gnu/lib/gcc-lib/mc68000-cbm-amigados/2.6.0/specs gcc version 2.6.0 Source code: /* Reproduction of a strange GCC floating-point problem. */ /* Bart Van Assche, Dec 28 1995. */ #if 0 gcc-2.6.0 output: (gcc -o fpcomparison-bug-gnu fpcomparison-bug.c -lm) a = -2.356194490192345, b = -2.356194490192344 a < b = 0, a != b = 1, a > b = 1 a <= b = 0, a == b = 0, a >= b = 1 b < a = 0, b != a = 1, b > a = 1 b <= a = 0, b == a = 0, b >= a = 1 SAS-6.2 output: (sc link fpcomparison-bug.c math=ieee) Remark: SAS refuses to output more than 14 significant digits a = -2.3561944901923, b = -2.3561944901923 a < b = 0, a != b = 1, a > b = 1 a <= b = 0, a == b = 0, a >= b = 1 b < a = 1, b != a = 1, b > a = 0 b <= a = 1, b == a = 0, b >= a = 0 #endif #include #include int lng[] = { 0xc002d97c, 0x7f3321d2, 0xc002d97c, 0x7f3321d1, }; int main(int argc, char **argv) { const double a = *(double *)(lng + 0); const double b = *(double *)(lng + 2); printf ("a = %18.16g, b = %18.16g\n" "a < b = %d, a != b = %d, a > b = %d\n" "a <= b = %d, a == b = %d, a >= b = %d\n" "b < a = %d, b != a = %d, b > a = %d\n" "b <= a = %d, b == a = %d, b >= a = %d\n", a, b, a < b, a != b, a > b, a <= b, a == b, a >= b, b < a, b != a, b > a, b <= a, b == a, b >= a); exit (0); } ------------- __ /_/ /_/art Van Assche E-mail: Bart.VanAssche@elis.rug.ac.be From amiga-gcc-port-owner@nic.funet.fi Sat Dec 30 15:49:31 1995 Received: from net.wau.nl ([137.224.10.12]) by nic.funet.fi with ESMTP id <90419-3>; Sat, 30 Dec 1995 15:46:38 +0200 Received: from vines2.wau.nl by NET.WAU.NL (PMDF V4.3-10 #6821) id <01HZF7OYJ4FK000GQ3@NET.WAU.NL>; Sat, 30 Dec 1995 14:52:12 +0000 (GMT) Received: by vines2.wau.nl; Sat, 30 Dec 95 14:46:10 +0100 Date: Sat, 30 Dec 1995 14:37:49 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: GCC2.7.0 broken ??? To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) The LCC porting people are having a problem. If LCC is compiled with the following options: -m68030 -m68881 -O0 ^^^ or with -m68030 -m68881 -O2 ^^^ then rcc (the compiler proper) produces different code for the same source??? So changing the optimalisation flags has an effect on the way the new compiler generates code. Is this a bug/pecularity in gcc and is -O0 correct (?) or is it -O2 ? or none of the above ? Aztec5.2a_rcc seems to generate the same code as gcc -O0. Small programs compiled with it seem to work correctly (test directory of lcc), but recompiling rcc with itself results in an compiler which crashes x86/m68k, gives an assert in one of the modules (sparc target) or generates code but only for the mips target. Does someone have a test-suite for C-compilers ? and in general, HELP Joop Joop.vandeWege@medew.ento.wau.nl From amiga-gcc-port-owner@nic.funet.fi Sat Dec 30 15:58:22 1995 Received: from europe.std.com ([192.74.137.10]) by nic.funet.fi with SMTP id <90489-3>; Sat, 30 Dec 1995 15:55:17 +0200 Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id IAA25143; Sat, 30 Dec 1995 08:55:11 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA25888; Sat, 30 Dec 1995 08:51:53 -0500 Date: Sat, 30 Dec 1995 08:51:53 +0001 (EST) From: "Thomas E. Janzen" Subject: RE: gcc/g++ math bug ? To: Amiga GCC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have no opinion about this except that in his book "Safer C" Hatton recommends never comparing floating point numbers without using an error bound based on the smallest change representable. Maybe we should run the math characterization program Paranoia through amiga gcc. I think I already have and it did pretty well. Maybe I should check. Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio If you want it done, plan it; if you want it done right, spec it. From amiga-gcc-port-owner@nic.funet.fi Sat Dec 30 17:43:02 1995 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <90090-3>; Sat, 30 Dec 1995 17:42:40 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.7.1/8.7.1) id QAA25822; Sat, 30 Dec 1995 16:42:27 +0100 (MET) Date: Sat, 30 Dec 1995 16:42:27 +0100 (MET) From: Ignatios Souvatzis Message-Id: <199512301542.QAA25822@theory.cs.uni-bonn.de> To: tej@world.std.com CC: amiga-gcc-port@nic.funet.fi In-reply-to: "Thomas E. Janzen"'s message of Sat, 30 Dec 1995 08:51:53 +0001 (EST) Subject: gcc/g++ math bug ? X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have no opinion about this except that in his book "Safer C" Hatton recommends never comparing floating point numbers without using an error bound based on the smallest change representable. comparing for < or > is ok. Comparing for = or != gives problems. Ignatios Souvatzis From amiga-gcc-port-owner@nic.funet.fi Sat Dec 30 19:47:20 1995 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <90700-1>; Sat, 30 Dec 1995 19:44:20 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tW5KS-000gXUC; Sat, 30 Dec 95 10:44 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: gcc/g++ math bug ? To: bvassche@ibmpar.elis.rug.ac.be (Bart Van Assche) Date: Sat, 30 Dec 1995 10:44:24 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9512301333.AA14610@ibmpar.elis.rug.ac.be> from "Bart Van Assche" at Dec 30, 95 01:33:38 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 897 > While debugging a numerical C++ program I discovered some strange behaviour > of the libm.a comparison of double-precision floating point numbers. The There are known to be problems with software floating point using gcc, I.E. if you don't use an fpu. With the current ADE compiler I get with -m68000 (software floating point): a = -2.356194490192345, b = -2.356194490192344 a < b = 0, a != b = 1, a > b = 1 a <= b = 0, a == b = 0, a >= b = 1 b < a = 0, b != a = 1, b > a = 1 b <= a = 0, b == a = 0, b >= a = 1 With -m68040 (hardware floating point) I get: a = -2.356194490192345, b = -2.356194490192344 a < b = 1, a != b = 1, a > b = 0 a <= b = 1, a == b = 0, a >= b = 0 b < a = 0, b != a = 1, b > a = 1 b <= a = 0, b == a = 0, b >= a = 1 So far nobody has taken the time to try to isolate why the software floating point support produces incorrect results. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Dec 30 19:57:37 1995 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <90154-1>; Sat, 30 Dec 1995 19:55:29 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tW5VT-000gXUC; Sat, 30 Dec 95 10:55 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: GCC2.7.0 broken ??? To: test1@MEDEW.ENTO.WAU.NL (test1) Date: Sat, 30 Dec 1995 10:55:46 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "test1" at Dec 30, 95 02:37:49 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1256 > The LCC porting people are having a problem. > If LCC is compiled with the following options: > -m68030 -m68881 -O0 > ^^^ > or with > -m68030 -m68881 -O2 > ^^^ > then rcc (the compiler proper) produces different code for the same source??? > So changing the optimalisation flags has an effect on the way the new > compiler generates code. Is this a bug/pecularity in gcc and > is -O0 correct (?) or is it -O2 ? or none of the above ? My first suspicion would be that rcc has some sort of bug that is manifesting itself as a difference in program behavior that depends upon how the generated code is optimized. I routinely compile hundreds of megabytes of code (my entire ADE source tree) with -O2 and haven't seen any problems that could be attributed to compilation errors. That's not to say that this isn't occurring in the rcc case, just that it is not that unusual to have a program bug cause the program to behave differently when optimized than when not optimized. The only way to be sure is to track down the actual cause of the lcc bug. You might get additional clues by changing the order of linkage of the object modules, since sometimes that can have an effect if there is a bug like this present. -Fred From amiga-gcc-port-owner@nic.funet.fi Sat Dec 30 20:17:52 1995 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <90754-4>; Sat, 30 Dec 1995 20:15:45 +0200 Received: by colombo.telesys-innov.fr; Sat, 30 Dec 1995 19:12:24 GMT From: Philippe BRAND Message-Id: <199512301912.TAA08087@colombo.telesys-innov.fr> Subject: Re: GCC2.7.0 broken ??? To: test1@MEDEW.ENTO.WAU.NL (test1) Date: Sat, 30 Dec 1995 19:12:23 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "test1" at Dec 30, 95 02:37:49 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit test1 writes: > Does someone have a test-suite for C-compilers ? You can find testsuite for gcc on my site: /pub/amigados-gnu/c-torture-test... -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://colombo.telis-sc.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Sun Dec 31 21:14:04 1995 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90031-3>; Sun, 31 Dec 1995 21:10:39 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tWTxx-000RRqC; Sun, 31 Dec 95 21:02 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0fgd@wyst.hobby.nl>; Sun, 31 Dec 95 19:38:38 CET Message-Id: <9512311838.0fgd@wyst.hobby.nl> Date: Sun, 31 Dec 1995 19:38:37 +0000 (CET) Content-Type: text Content-Length: 1338 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Subject: .inputrc for use with readline Hi everyone, Here's a .inputrc file (to be placed in the home directory) for use with programs that use readline. It is very simple, but at least the Del key and the cursor keys now work. It's uuencoded, because it contains non-ASCII characters. Happy new year! Hans ------------ cut here ----------- begin 700 .inputrc M(R!->2!^+RYI;G!U=')C(&9I;&4@:7,@:6X@+2HM('1E>'0@+2HM(&9OF5D(&1E<&5N9&EN M9PHC(&]N('=H:6-H('!R;V=R86T@:7,@'0M:&ES=&]R>0HBFT,B.B!F;W)W87)D+6-H87(*(IM$(CH@8F%C:W=A (; Sun, 31 Dec 1995 22:56:28 +0200 Received: from pelf (pelf.harvard.edu) by head-cfa.harvard.edu (4.1/SMI-4.0) id AA27613; Sun, 31 Dec 95 15:56:16 EST Received: by pelf (5.0/SMI-SVR4) id AA00618; Sun, 31 Dec 1995 15:56:16 -0500 Date: Sun, 31 Dec 1995 15:56:16 -0500 From: dj@head-cfa.harvard.edu (Diab Jerius) Message-Id: <9512312056.AA00618@pelf> To: amiga-gcc-port@lists.funet.fi Subject: Re: bug in make Content-Length: 1079 > > I'm using the make from the Fresh Fish X CDROM. I'm running under AmigaOS 2.1. > > Here's a makefile which isolates the problem: > > > > > These are the correct responses. Does anyone have a clue as to what's > > going on here? I appreciate your help on this. > > Yep, this was the result of a patch that allowed the use of AmigaDOS > filenames in a makefile, unfortunately this patch also disabled a useful > feature of GNU make. I've asked Fred to remove that patch and he did (well, > he had to because I used those GNU extensions in the new 42.0 ixemul.library > Makefiles :-). You can get the new make from ftp.amigalib.com, in directory > pub/amiga/ade. From memory, so the directory might be a bit different in > reality. > > Hans The new version solves the problem. Thanks! Diab ------------- Diab Jerius Harvard-Smithsonian Center for Astrophysics 60 Garden St, MS 70, Cambridge MA 02138 USA djerius@cfa.harvard.edu vox: 617 496 7575 fax: 617 495 7356 From amiga-gcc-port-owner@nic.funet.fi Mon Jan 1 16:03:44 1996 Received: by nic.funet.fi id <90290-4>; Mon, 1 Jan 1996 16:00:07 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <96Jan1.160007+0200_eet.90290-4+22@nic.funet.fi> Date: Mon, 1 Jan 1996 16:00:01 +0200 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Mon Jan 1 21:27:12 1996 Received: from trappist.elis.rug.ac.be ([157.193.67.1]) by nic.funet.fi with SMTP id <90274-2>; Mon, 1 Jan 1996 21:22:20 +0200 Received: from ibmpar.elis.rug.ac.be by trappist.elis.rug.ac.be with SMTP id AA04460 (5.65c/IDA-1.4.4 for ); Mon, 1 Jan 1996 20:25:32 +0100 Received: by ibmpar.elis.rug.ac.be (AIX 3.2/UCB 5.64/4.03) id AA14918; Mon, 1 Jan 1996 20:26:51 GMT From: bvassche@ibmpar.elis.rug.ac.be (Bart Van Assche) Message-Id: <9601012026.AA14918@ibmpar.elis.rug.ac.be> Subject: IEEEDPCmp() bug To: amiga-gcc-port@nic.funet.fi Date: Mon, 1 Jan 1996 20:26:51 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7487 In a previous message Fred Fish wrote: > Thanks for taking the time to investigate this. From your table below it > would appear that if user code gets the right results under SAS/C, that > SAS/C must be fixing up the results somehow, since this is a ROM bug. Indeed, SAS was fixing up the results of the first program somehow - but only "by accident". For other input values the SAS program turned out to fail as well. (For some comparisons SAS replaced IEEEDPCmp(a, b) with IEEEDPCmp(-b, -a), so the comparisons were not accurately testing IEEEDPCMP(). I only understood this after I had sent the mail) > Hans, would it be possible to put some workaround in the > ixemul.library code that accesses the mathieeedoubbas.library? > Perhaps by converting negative arg pairs to positive pairs and then > adjusting the result appropriately? Another approach is also possible: rewriting IEEEDPCmp(). I started doing that after checking the ROM assembler instructions for that function. The function was less than 256 bytes in size, so I started correcting it. The result, together with a kind of torture test, is appended at the end of this mail. The output files show that my implementation agrees completely with the SAS proprietary software floating point comparison, and also with the easy fix cmp2() inside the fixed-dpcmp.c program. And - aaargh - IEEEDPNeg() seems to behave strange as well ? I didn't check, but used a fix for it. Maybe I'll check it another time, but not today :) BTW, happy new year to the other people on this list ! The source-archive follows: Listing of archive 'source.lha': Original Packed Ratio Date Time Name -------- ------- ----- --------- -------- ------------- 14863 896 93.9% 01-Jan-96 20:03:12 fixed-dpcmp-out.gnu 11895 503 95.7% 01-Jan-96 20:03:12 fixed-dpcmp-out.sas 3387 1232 63.6% 01-Jan-96 20:02:40 fixed-dpcmp.c 1888 730 61.3% 31-Dec-95 17:20:12 fpcomparison-bug.c 605 211 65.1% 01-Jan-96 20:15:32 Makefile -------- ------- ----- --------- -------- 32638 3572 89.0% 01-Jan-96 20:15:38 5 files begin 777 source.lha M*=TM;&@U+8 # /.@ 9J A( $V9I>&5D+61P8VUP+6]U="YG;G6&@ 'XX M:[?5I/5?CG0#[<;^?,/6_%I?^'N@MF;MF0RL:;IV'&,)@9# "-H+%+KFVT8!X M]N$FS.O%EVO_F 4E/YTXT\Y X43T$CYU+\IZ"8'EG-@)4CT#CD#SA*X MBD)2\0",PA24_G0 A=\$; HO!3MI$XY(X\\9XHE.G%G)_\BBX GTLJ@=.[,HX M@5(12FEI'HC/-G19VZN>XM %3W!S)V/;WLX.&1FE(FS*/4QK$I-7'YI2ZH'FX MC'J 9I3^,$[_"7I4^,#:E5^N6R2KWL^+>Y#TK=4":E=K97)*_RYYC?&U#E4EX MUA >*8E>;E4#?F=5%WY)[PO#.*L,:O,33VK"[B . *=05:$QBA4,AZJ+.(HWX MPEU&5D28B1M1FMH\W@'Y(\Q =R%'E88U>8F1Y6%W$>< 4ZCX MRT)L(\WA,R/*HLXCS?"74>61)?48+]'I$!,6/X:Z/8':/?I35#91\!LH^0UTX M?0:*/L):/P):/T-5'\'I1_A)2 !BI ?N)JT@40$RD/CI!.\8MSIQ# /TVX;*X M0<-=(0&BD)"6D*"6D+#52&!Z4AH24AP2TA]O2YI(;F ?PD*L!O)"+"[R0?,+X MAK\P U-ZJ,/R97Q=N3+G"LLF38GGW\U:D^FI$FH^;4;Y^J.(V5LHRB_7RQIHX M:X49$6L%!H\6@HK; 7=HGUT=K 4W1(V<[EH@^<&=VN@GJKA.*=WDSGYG06!6X M=$JY[V3F69Q?_>7OX*ORX*X MKRX*G#P5"Z&6;@I_'@INC@I6-5+7!2/9QJ<=G@HC"4$H;7!00""&8OH9C AF,:&8QH9C(AF,B&8QH9CXH9X MCI0S'2AF/]0S'MH55^"*=2!Y>")]="@0J2!**:E%0G!MJ*)[A/5,*=DM;&@UX M+?&5D+61P8VUP+6]U="YS87-PQ $36I?9I?[GX M? 'ZYHWQO]MMK70/BNEU+[C%RKI*NGM-&X!F_YT_1BX MY5TE73WKI]6+E73\KI8NANK.[#P_!]EP>J?,K)ZUXBVHV?!^=,O3#>NFERF?X M5V2K#,[I#KG+10?8JSZ39I74]@]%^,V#M^P]@[2]B^Q Z=0WV[S(-O-MG'+/X M1N&!:!2DRJ^:'W-[:LYQLRPG;2AN>XEIX^G ^5(-Z$]%)*;H6(%&5D+61P8VUP+F/;&0/H:]NQM-R?X MYH_P#Z@BJ.#T&W+L84(5 !LC+:X2NVWP&,+FWSDXS?.)MP I3\W>]W_+G R8@,%)Z*0FC!%.$,&PT)X M/O&GI#]C)#=HHAS'<#\!Y@\#VUM?8HC:U4)ADT1'#;HIBD1!AS;EX3@U,T=]X MMP#]2*;[9%/<4(F83YYT)ICJ(8XCQAS5P& )T9-1KT3(B#!^0ICB%X M,< DF\:@?X^,4TF)$;35/7G.3,:$T(RI&&Y*G0/QB?QUC+12F*(7:3E#(*.*('N//,4/"1'8#O4ZX MS\Y;S#MX7)3HE@//1_:;>TINX?M>:[>\Q^UX,VMF0X MSS4(I1T'55BD^4RNFEJXG77XO* \/T'[6S"0_9CQ8GWHG_,>]G/3HG2'U/8_ BR9X M/$C=L(F 6&G;;=,,R^"89G4B1R=8#8O3F&OP\9M$E(??[/U#@XPAFESFG10(X MUDT]42%"3J<4OA^NY[8P-;WZ?NX$(XFC)ZYB),QX?Z#IS=8432G5C7H",R)"X M;J,L?8T=#AT10+"9Y#0C7?THIS TO"![%#?6'%0+."21:!0DRFHN(,PU"2(3X ME+)G\;._6T62)D::UO5(.?*VTN.]U\YEPR-AB&^,2-?94!<7NX M5MJ\P%_.2VSU9@R0 H8<*S33* '_C0!V6*(-P'12[#V_9E/$P@;9DS5,O21UX MO# .?FOH9LC>Q@\5L .:QARZP>4$+@4&.JDJ<^5%%)YR/M$ITC.<9&6Z!G7(X MGG(GW(L12O+!7-TJF0DTIZ\&):L1N*,\+RC]P/5"*T^O-J1)!7&%@IF=%1X-X M>'?+[FJ;ZL QO#.EW5+]@!Y@!Y@" B&"TA@>8 (ALEFZ&X,_VRT(%W$VVV=KX MB('54$"5 W@I1P;%1]=@T[VX M$[AW<->(\>_P\>(\>TGGSEG-10X M3J]4M5Z)RY1S3A?0IR@0,14C]:^NJAX M=0KG6*YUBN=@JWQHQUZ]_C$(Y2RP7$4'B1<]A$K("5XBMQ:LJ5PE]8E_X"<2X MQ.+N$LDQKC"TDID) >GTJ0P\\59,OS8M36?B"K_10K('.>@MN@Y,6;A'&Y"^/_B<"I@^^W#QFYOR34'JEUIG)\).E0\:Q$R1\#/6B)LA^5[V/031L@:XHX%G"H""N@/MMU;U)'=DDL0;%O"7I"2X M3%1+\;O^[I5NJ*(C@V!-X-X-X=X]F[LVHV]N7 ^9IZ)HZXJD3)"8X$"FJ@B9X M#!\,F0#RS$J0F2[/,A-0"*+*;/>"YN-";XR45!]")#BIIBS&=#D-$#^\#T$&X M%8-K;0<+[30!SUU3UU;ZDN$#SQ39YR4(IF3=+7)=D36%U^]?9YAUIO"0('!KX M8X(&>8H,3S^+!A= NQ_?L?P;L#[^%^ > ;OZ(K'@7]&(N$\1,3H;&KV''!O&X M,X(Z+/.V1TK@\L\ZM4KI%J_F/M<>^4>>T=^T=8/2.L'^CJ[^([I)3_:]>5:WX MO6KF/TJX?_U<5$'\JYXU->]:?8_2GQ_W3[;,F-!U9IIBEKC,'NIJCE06]FX=X MH=#"53';<= VA%3;BL_=@A$U@>>@=23Z@)XS'#KZ^GBZ<@]^ =Y,=:ZIMS.2X MK,@QC1S5E*2D>#&!Y:3+&*V2YN7EY>3HR#%2@4I@E,>KH)1G="QA0B3,MBY"X MLK]ID1A<^0\QS#S'((3C)2/\:'NF*KLG,J&*TJ^!7M66K32B1)HU]J7J?RLXX MVSI&>1PM:0*A+&G75"TUK54Y5;'M'\O!Y^.#'$JQN,^[NOO1OAI#3#XDB_HDX M\PDTJ%,Y$);4@2B00<68E 7+@J?9QIDA_?F20^3(L/=58;]O;%7X6K+0'3KMX MGM#\<#;?G4P8T;96EQK:48YYS)^*"T$H[&[7C=:5CBT,LN#C?P#[,*KQ->LMX MS99Y21+T:NA5-(Z:/.![V9 *FWJ>RN!OKK;>CLF78.?\!S^H<50Y8]4_"0[\X M7!XEU7"V02JB&Q^53\BWZP#,Y0;M*OA;O/8Y&;.K2^J;3)=M-V]N_O: 7ZNAX MK4<[P>O92W'LV5MQB%=8&U1!W+%ZK^5U?N]E4Y8N5B[ BIE7R#[GK=W)+-2;X M5;7SO+X68:U6Q'X=Q0#/UV/PM2%/-K_H7^]_(9#HZ4%:PX MY#@ LSP&WT/VQH_[ 3'B71=V+%A!T; Mon, 1 Jan 1996 21:23:05 +0200 Received: from ibmpar.elis.rug.ac.be by trappist.elis.rug.ac.be with SMTP id AA04465 (5.65c/IDA-1.4.4 for ); Mon, 1 Jan 1996 20:26:15 +0100 Received: by ibmpar.elis.rug.ac.be (AIX 3.2/UCB 5.64/4.03) id AA13139; Mon, 1 Jan 1996 20:27:34 GMT From: bvassche@ibmpar.elis.rug.ac.be (Bart Van Assche) Message-Id: <9601012027.AA13139@ibmpar.elis.rug.ac.be> Subject: IEEEDPCmp() bug To: amiga-gcc-port@nic.funet.fi Date: Mon, 1 Jan 1996 20:27:34 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7487 In a previous message Fred Fish wrote: > Thanks for taking the time to investigate this. From your table below it > would appear that if user code gets the right results under SAS/C, that > SAS/C must be fixing up the results somehow, since this is a ROM bug. Indeed, SAS was fixing up the results of the first program somehow - but only "by accident". For other input values the SAS program turned out to fail as well. (For some comparisons SAS replaced IEEEDPCmp(a, b) with IEEEDPCmp(-b, -a), so the comparisons were not accurately testing IEEEDPCMP(). I only understood this after I had sent the mail) > Hans, would it be possible to put some workaround in the > ixemul.library code that accesses the mathieeedoubbas.library? > Perhaps by converting negative arg pairs to positive pairs and then > adjusting the result appropriately? Another approach is also possible: rewriting IEEEDPCmp(). I started doing that after checking the ROM assembler instructions for that function. The function was less than 256 bytes in size, so I started correcting it. The result, together with a kind of torture test, is appended at the end of this mail. The output files show that my implementation agrees completely with the SAS proprietary software floating point comparison, and also with the easy fix cmp2() inside the fixed-dpcmp.c program. And - aaargh - IEEEDPNeg() seems to behave strange as well ? I didn't check, but used a fix for it. Maybe I'll check it another time, but not today :) BTW, happy new year to the other people on this list ! The source-archive follows: Listing of archive 'source.lha': Original Packed Ratio Date Time Name -------- ------- ----- --------- -------- ------------- 14863 896 93.9% 01-Jan-96 20:03:12 fixed-dpcmp-out.gnu 11895 503 95.7% 01-Jan-96 20:03:12 fixed-dpcmp-out.sas 3387 1232 63.6% 01-Jan-96 20:02:40 fixed-dpcmp.c 1888 730 61.3% 31-Dec-95 17:20:12 fpcomparison-bug.c 605 211 65.1% 01-Jan-96 20:15:32 Makefile -------- ------- ----- --------- -------- 32638 3572 89.0% 01-Jan-96 20:15:38 5 files begin 777 source.lha M*=TM;&@U+8 # /.@ 9J A( $V9I>&5D+61P8VUP+6]U="YG;G6&@ 'XX M:[?5I/5?CG0#[<;^?,/6_%I?^'N@MF;MF0RL:;IV'&,)@9# "-H+%+KFVT8!X M]N$FS.O%EVO_F 4E/YTXT\Y X43T$CYU+\IZ"8'EG-@)4CT#CD#SA*X MBD)2\0",PA24_G0 A=\$; HO!3MI$XY(X\\9XHE.G%G)_\BBX GTLJ@=.[,HX M@5(12FEI'HC/-G19VZN>XM %3W!S)V/;WLX.&1FE(FS*/4QK$I-7'YI2ZH'FX MC'J 9I3^,$[_"7I4^,#:E5^N6R2KWL^+>Y#TK=4":E=K97)*_RYYC?&U#E4EX MUA >*8E>;E4#?F=5%WY)[PO#.*L,:O,33VK"[B . *=05:$QBA4,AZJ+.(HWX MPEU&5D28B1M1FMH\W@'Y(\Q =R%'E88U>8F1Y6%W$>< 4ZCX MRT)L(\WA,R/*HLXCS?"74>61)?48+]'I$!,6/X:Z/8':/?I35#91\!LH^0UTX M?0:*/L):/P):/T-5'\'I1_A)2 !BI ?N)JT@40$RD/CI!.\8MSIQ# /TVX;*X M0<-=(0&BD)"6D*"6D+#52&!Z4AH24AP2TA]O2YI(;F ?PD*L!O)"+"[R0?,+X MAK\P U-ZJ,/R97Q=N3+G"LLF38GGW\U:D^FI$FH^;4;Y^J.(V5LHRB_7RQIHX M:X49$6L%!H\6@HK; 7=HGUT=K 4W1(V<[EH@^<&=VN@GJKA.*=WDSGYG06!6X M=$JY[V3F69Q?_>7OX*ORX*X MKRX*G#P5"Z&6;@I_'@INC@I6-5+7!2/9QJ<=G@HC"4$H;7!00""&8OH9C AF,:&8QH9C(AF,B&8QH9CXH9X MCI0S'2AF/]0S'MH55^"*=2!Y>")]="@0J2!**:E%0G!MJ*)[A/5,*=DM;&@UX M+?&5D+61P8VUP+6]U="YS87-PQ $36I?9I?[GX M? 'ZYHWQO]MMK70/BNEU+[C%RKI*NGM-&X!F_YT_1BX MY5TE73WKI]6+E73\KI8NANK.[#P_!]EP>J?,K)ZUXBVHV?!^=,O3#>NFERF?X M5V2K#,[I#KG+10?8JSZ39I74]@]%^,V#M^P]@[2]B^Q Z=0WV[S(-O-MG'+/X M1N&!:!2DRJ^:'W-[:LYQLRPG;2AN>XEIX^G ^5(-Z$]%)*;H6(%&5D+61P8VUP+F/;&0/H:]NQM-R?X MYH_P#Z@BJ.#T&W+L84(5 !LC+:X2NVWP&,+FWSDXS?.)MP I3\W>]W_+G R8@,%)Z*0FC!%.$,&PT)X M/O&GI#]C)#=HHAS'<#\!Y@\#VUM?8HC:U4)ADT1'#;HIBD1!AS;EX3@U,T=]X MMP#]2*;[9%/<4(F83YYT)ICJ(8XCQAS5P& )T9-1KT3(B#!^0ICB%X M,< DF\:@?X^,4TF)$;35/7G.3,:$T(RI&&Y*G0/QB?QUC+12F*(7:3E#(*.*('N//,4/"1'8#O4ZX MS\Y;S#MX7)3HE@//1_:;>TINX?M>:[>\Q^UX,VMF0X MSS4(I1T'55BD^4RNFEJXG77XO* \/T'[6S"0_9CQ8GWHG_,>]G/3HG2'U/8_ BR9X M/$C=L(F 6&G;;=,,R^"89G4B1R=8#8O3F&OP\9M$E(??[/U#@XPAFESFG10(X MUDT]42%"3J<4OA^NY[8P-;WZ?NX$(XFC)ZYB),QX?Z#IS=8432G5C7H",R)"X M;J,L?8T=#AT10+"9Y#0C7?THIS TO"![%#?6'%0+."21:!0DRFHN(,PU"2(3X ME+)G\;._6T62)D::UO5(.?*VTN.]U\YEPR-AB&^,2-?94!<7NX M5MJ\P%_.2VSU9@R0 H8<*S33* '_C0!V6*(-P'12[#V_9E/$P@;9DS5,O21UX MO# .?FOH9LC>Q@\5L .:QARZP>4$+@4&.JDJ<^5%%)YR/M$ITC.<9&6Z!G7(X MGG(GW(L12O+!7-TJF0DTIZ\&):L1N*,\+RC]P/5"*T^O-J1)!7&%@IF=%1X-X M>'?+[FJ;ZL QO#.EW5+]@!Y@!Y@" B&"TA@>8 (ALEFZ&X,_VRT(%W$VVV=KX MB('54$"5 W@I1P;%1]=@T[VX M$[AW<->(\>_P\>(\>TGGSEG-10X M3J]4M5Z)RY1S3A?0IR@0,14C]:^NJAX M=0KG6*YUBN=@JWQHQUZ]_C$(Y2RP7$4'B1<]A$K("5XBMQ:LJ5PE]8E_X"<2X MQ.+N$LDQKC"TDID) >GTJ0P\\59,OS8M36?B"K_10K('.>@MN@Y,6;A'&Y"^/_B<"I@^^W#QFYOR34'JEUIG)\).E0\:Q$R1\#/6B)LA^5[V/031L@:XHX%G"H""N@/MMU;U)'=DDL0;%O"7I"2X M3%1+\;O^[I5NJ*(C@V!-X-X-X=X]F[LVHV]N7 ^9IZ)HZXJD3)"8X$"FJ@B9X M#!\,F0#RS$J0F2[/,A-0"*+*;/>"YN-";XR45!]")#BIIBS&=#D-$#^\#T$&X M%8-K;0<+[30!SUU3UU;ZDN$#SQ39YR4(IF3=+7)=D36%U^]?9YAUIO"0('!KX M8X(&>8H,3S^+!A= NQ_?L?P;L#[^%^ > ;OZ(K'@7]&(N$\1,3H;&KV''!O&X M,X(Z+/.V1TK@\L\ZM4KI%J_F/M<>^4>>T=^T=8/2.L'^CJ[^([I)3_:]>5:WX MO6KF/TJX?_U<5$'\JYXU->]:?8_2GQ_W3[;,F-!U9IIBEKC,'NIJCE06]FX=X MH=#"53';<= VA%3;BL_=@A$U@>>@=23Z@)XS'#KZ^GBZ<@]^ =Y,=:ZIMS.2X MK,@QC1S5E*2D>#&!Y:3+&*V2YN7EY>3HR#%2@4I@E,>KH)1G="QA0B3,MBY"X MLK]ID1A<^0\QS#S'((3C)2/\:'NF*KLG,J&*TJ^!7M66K32B1)HU]J7J?RLXX MVSI&>1PM:0*A+&G75"TUK54Y5;'M'\O!Y^.#'$JQN,^[NOO1OAI#3#XDB_HDX M\PDTJ%,Y$);4@2B00<68E 7+@J?9QIDA_?F20^3(L/=58;]O;%7X6K+0'3KMX MGM#\<#;?G4P8T;96EQK:48YYS)^*"T$H[&[7C=:5CBT,LN#C?P#[,*KQ->LMX MS99Y21+T:NA5-(Z:/.![V9 *FWJ>RN!OKK;>CLF78.?\!S^H<50Y8]4_"0[\X M7!XEU7"V02JB&Q^53\BWZP#,Y0;M*OA;O/8Y&;.K2^J;3)=M-V]N_O: 7ZNAX MK4<[P>O92W'LV5MQB%=8&U1!W+%ZK^5U?N]E4Y8N5B[ BIE7R#[GK=W)+-2;X M5;7SO+X68:U6Q'X=Q0#/UV/PM2%/-K_H7^]_(9#HZ4%:PX MY#@ LSP&WT/VQH_[ 3'B71=V+%A!T; Tue, 2 Jan 1996 22:29:26 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 2 Jan 96 21:29 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Tue, 2 Jan 96 21:25 MET Received: by rubin.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Tue, 2 Jan 96 21:25 MET Message-Id: Subject: Re: exec.ibrary _LVO -516 To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 2 Jan 1996 21:25:39 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 848 > > Is this what happens? I thought it was just a do-nothing entry to be > SetPatch()ed by programmes like Sushi. Is this how Sushi can intercept > serial output? Does this mean that Walter Harms libdebug.a uses this > function too? Does anybody know why this function is supposed to be > private (it wasn't in my OS 2.1 fd files, btw)? Am I asking too many > questions on one go? > yes, i used the function, too but i admit that i am not very happy with that but there seems to be no other way. the function is private but free for debuggers. taht means the "normal" programmer has to avoid this function. that includes rawdofmt() afaik. > Btw, notice how nicely it is prepared for being the "putChar" function > for RawDoFormat(). > -- ----- "If heroes don't exist, it is necessary to invent them--good for public morale!" ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jan 2 22:44:08 1996 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <89814-4> convert rfc822-to-8bit; Tue, 2 Jan 1996 22:42:07 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 2 Jan 1996 21:41:59 +0100 (MET) From: Rask Lambertsen To: Walter Harms Cc: amiga gcc-list Subject: Re: exec.ibrary _LVO -516 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 2 Jan 1996, Walter Harms wrote: > yes, i used the function, too but i admit that i am not very happy > with that but there seems to be no other way. the function is private > but free for debuggers. taht means the "normal" programmer has to > avoid this function. that includes rawdofmt() afaik. No, RawDoFmt() is public. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Jan 3 10:31:04 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <90253-4>; Wed, 3 Jan 1996 10:29:08 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id JAA16916; Wed, 3 Jan 1996 09:31:03 +0100 Date: Wed, 3 Jan 1996 09:31:03 +0100 (MET) From: Kamil Iskra To: Amiga GCC List cc: phb@colombo.telesys-innov.fr, fnf@amigalib.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII New version of fd2inline is now available on my homepage (link is now available in "Programs for the AMIGA..." subpage). It was also uploaded to amigalib and colombo (file fd2inline_new2.lha on the latter). I would call it "major release", since macros in are new, better and completely different. I would like to ask everybody to check them out ASAP. Thanks! I would like to thank Joerg Hoehle and Matthias Fleischer (in alphabetical order :-) for their ideas and help in putting this version together. - Enhanced LP-macros in . They produce better code: when not optimizing, no function call is produced; when optimizing, no library base reloading is performed (if base pointer is declared "const" - see below). They work both with GCC and G++. - Library bases are now accessed through EXEC_BASE_NAME, INTUITION_BASE_NAME etc. By default, these defines just expand to SysBase, IntuitionBase etc, so compatibility is fully preserved. They can be useful if you for example want to access IntuitionBase from a structure field (it was impossible, because library base name is the same as library base type name) or if you want to access SysBase through dereferences of 0x4, but for some reason need global, too (not very common, but for example IXEmul makes such things...). - Extern library base pointers are now declared as "const" - you can override it by defining your own __CONSTLIBBASEDECL__ (default one is defined in ). This improves code quality, but makes compiler produce warnings when assignment to base is being made (for example when you attempt to OpenLibrary()). - "fd2inline++", "inline++" and "createinl++" are no longer included in archive, since they are no longer needed. As a side effect, archive is now 70 KB smaller. "make all" no longer produces "fd2inline++", too - its name was changed back to "fd2inlin.old" (more appropriate now :-) and you have to explicitly demand it ("make fd2inline.old"). - "FD:" is now used as a path of fd-files in "createinl" script (previously it was "FD/"). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 6 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Jan 3 10:48:03 1996 Received: from net.wau.nl ([137.224.10.12]) by nic.funet.fi with ESMTP id <90093-3>; Wed, 3 Jan 1996 10:46:42 +0200 Received: from vines2.wau.nl by NET.WAU.NL (PMDF V4.3-10 #6821) id <01HZKIEQADCG001PNC@NET.WAU.NL>; Wed, 03 Jan 1996 09:52:30 +0000 (GMT) Received: by vines2.wau.nl; Wed, 3 Jan 96 9:46:13 +0100 Date: Wed, 03 Jan 1996 08:30:09 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: Re: GCC2.7.0 broken ??? To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) I asked about problems we (LCC team) are having with getting different compilers when using gcc -O0 and gcc -O2: And Fred wrote: >My first suspicion would be that rcc has some sort of bug that is >manifesting itself as a difference in program behavior that depends upon how >the generated code is optimized. I routinely compile >hundreds of megabytes of code (my entire ADE source tree) with -O2 and >haven't seen any problems that could be attributed to compilation >errors. That's not to say that this isn't occurring in the rcc case, >just that it is not that unusual to have a program bug cause the >program to behave differently when optimized than when not optimized. >The only way to be sure is to track down the actual cause of the lcc >bug. You might get additional clues by changing the order of linkage >of the object modules, since sometimes that can have an effect if there >is a bug like this present. Well all the searching atleast turned up one thing. Aztec has a problem with translating code like this: printf("testing \n"); It get translated to dc.b "testing 012" instead of dc.b "testing \012", the way gcc does it. Moving around the *.o files while linking doesn't have *any* effect :( Right now I have an second stage rcc which will produce code using the mips code generator, no crashes, no visible problems. The sparc/intel code generators both stop with an assert and the m68k code generator plain GURU's. Anyone having more ideas that I can try? since I have run out of any useful things I can do/try. A last thing I want todo is single step (on source level) the compiler using Bdebug. That will probably give me the location causing the 8..03 but that is probably not the location where the error is. Joop Joop.vandeWege@medew.ento.wau.nl From amiga-gcc-port-owner@nic.funet.fi Wed Jan 3 14:26:14 1996 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <89059-3>; Wed, 3 Jan 1996 14:23:51 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.7.1/8.7.1) id NAA00827; Wed, 3 Jan 1996 13:23:37 +0100 (MET) Date: Wed, 3 Jan 1996 13:23:37 +0100 (MET) From: Ignatios Souvatzis Message-Id: <199601031223.NAA00827@theory.cs.uni-bonn.de> To: amiga-gcc-port@nic.funet.fi Subject: ld produces bad loadfile when data segment has no initialized data X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1alength for the data size. HUNK_HEADER->datalength - HUNK_DATA->length for the bss size. Am I totally wrong? Regards, Ignatios Souvatzis From amiga-gcc-port-owner@nic.funet.fi Wed Jan 3 17:12:53 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <89814-3>; Wed, 3 Jan 1996 17:09:49 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tXUmp-000gXUC; Wed, 3 Jan 96 08:07 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ld produces bad loadfile when data segment has no initialized data To: ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis) Date: Wed, 3 Jan 1996 08:07:30 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199601031223.NAA00827@theory.cs.uni-bonn.de> from "Ignatios Souvatzis" at Jan 3, 96 01:23:37 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3549 > while hacking at a NetBSD bootblock and a loadfile to bootblock > converter, I discovered that ld (the one from the 2.7.0 distribution) > creates a corrupt HUNK_HEADER when the data segment does not contain > initialized data. > > Instead of: > > HUNK_HEADER 0000 0002 0000 0001 codelen datalen(=0) HUNK_CODE codelen ... > > it creates > > HUNK_HEADER 0000 0002 0000 0001 codelen HUNK_CODE codelen ... > > All segment loading utilities get very confused to find a hunk with an > id of 'codelen' ;-) I tried recreating this here and unless I'm misunderstanding your example, I can't recreate it using my tool chain (from ftp.amigalib.com: pub/ade/...). See results below. > Possibly related strange thing in the bfd: > > size shows only the length of the initialized data in the data > segment and always shows 0 for the bss length. > > IMHO, it should show the values from the HUNK_HEADER, at least for the > BSS (if present), else it should show > > HUNK_DATA->length for the data size. > HUNK_HEADER->datalength - HUNK_DATA->length for the bss size. Here is the C code I started with: foo () { static int x; x = 10; } Here is the result of running size on the compiled object: text data bss dec hex filename 16 0 4 20 14 j.o Here is the result of running size on a linked executable from running "ld -o j j.o": text data bss dec hex filename 16 0 8 24 18 j And here is a dump of the executable: Dump of 'j': 00000000: 000003f3 HUNK_HEADER 00000004: 00000000 Name list terminator 00000008: 00000002 Table size 0000000c: 00000000 First Hunk F 00000010: 00000001 Last Hunk L 00000014: 00000004 Hunk[0] size (4) 00000018: 00000002 Hunk[1] size (2) 0000001c: 000003e9 HUNK_CODE 00000020: 00000004 Number of longwords of code 00000024: 4e550000 700a23c0 00000000 4e5d4e75 00000034: 000003ec HUNK_RELOC32 00000038: 00000001 Number of relocations (1) 0000003c: 00000001 Relocate relative to hunk 1 00000040: 00000008 00000044: 00000000 Reloc hunk terminator 00000048: 000003f0 HUNK_SYMBOL 0000004c: 00000005 EXT_SYMB; 5 longwords of symbol name 00000050: 5f5f5f67 '_' '_' '_' 'g' 00000054: 6e755f63 'n' 'u' '_' 'c' 00000058: 6f6d7069 'o' 'm' 'p' 'i' 0000005c: 6c65645f 'l' 'e' 'd' '_' 00000060: 63000000 'c' '\000' '\000' '\000' 00000064: 00000000 Symbol value 00000068: 00000001 EXT_SYMB; 1 longwords of symbol name 0000006c: 5f666f6f '_' 'f' 'o' 'o' 00000070: 00000000 Symbol value 00000074: 00000002 EXT_SYMB; 2 longwords of symbol name 00000078: 5f5f6574 '_' '_' 'e' 't' 0000007c: 65787400 'e' 'x' 't' '\000' 00000080: 00000010 Symbol value 00000084: 00000002 EXT_SYMB; 2 longwords of symbol name 00000088: 5f657465 '_' 'e' 't' 'e' 0000008c: 78740000 'x' 't' '\000' '\000' 00000090: 00000010 Symbol value 00000094: 00000000 Symbol hunk terminator (4 symbols) 00000098: 000003f2 HUNK_END 0000009c: 000003eb HUNK_BSS 000000a0: 00000002 Size of BSS block in longwords 000000a4: 000003f0 HUNK_SYMBOL 000000a8: 00000001 EXT_SYMB; 1 longwords of symbol name 000000ac: 5f782e32 '_' 'x' '.' '2' 000000b0: 00000000 Symbol value 000000b4: 00000002 EXT_SYMB; 2 longwords of symbol name 000000b8: 5f5f656e '_' '_' 'e' 'n' 000000bc: 64000000 'd' '\000' '\000' '\000' 000000c0: 00000008 Symbol value 000000c4: 00000001 EXT_SYMB; 1 longwords of symbol name 000000c8: 5f656e64 '_' 'e' 'n' 'd' 000000cc: 00000008 Symbol value 000000d0: 00000000 Symbol hunk terminator (3 symbols) 000000d4: 000003f2 HUNK_END From amiga-gcc-port-owner@nic.funet.fi Thu Jan 4 09:55:40 1996 Received: from net.wau.nl ([137.224.10.12]) by nic.funet.fi with ESMTP id <85287-3>; Thu, 4 Jan 1996 09:52:06 +0200 Received: from vines2.wau.nl by NET.WAU.NL (PMDF V4.3-10 #6821) id <01HZLUSGRG5S002DRY@NET.WAU.NL>; Thu, 04 Jan 1996 08:57:57 +0000 (GMT) Received: by vines2.wau.nl; Thu, 4 Jan 96 8:51:57 +0100 Date: Thu, 04 Jan 1996 08:28:27 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: Re: GCC2.7.0 broken ??? To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi Thomas, >> Well all the searching atleast turned up one thing. Aztec has a problem >> with translating code like this: printf("testing \n"); >>It get translated to dc.b "testing 012" instead of dc.b "testing \012", the >> way gcc does it. > I'm using Aztec-C very regular and havn't found this. Can you tell me > the version number of your compiler, please ? > (and the options you are using) > Thomas I thought I had mentioned it but I'm using Aztec5.2a and from memory the options are: cc -bs -wn -qv -c *.c ln -g -o rcc *.o -lm -lc I'm prepared to post a *huge* problem report to the list but I don't know if it will be welcomed by everyone. The example could include original source of an example program, the output of the first stage rcc both symbolic and m68k source, symbolic output from the second stage compiler because the m68k code generator crashes. Then for comparison the whole set when using gcc2.7.0 (aminet) and Azec5.2a and maybe SAS. Anything that I might have forgotten? Joop Joop.vandeWege@medew.ento.wau.nl From amiga-gcc-port-owner@nic.funet.fi Thu Jan 4 12:37:41 1996 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <89512-1>; Thu, 4 Jan 1996 12:35:27 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id LAA29053 (8.7.2/7.5a-FAU);; Thu, 4 Jan 1996 11:34:54 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA17113; Thu, 4 Jan 1996 11:34:48 +0100 Date: Thu, 4 Jan 1996 11:34:48 +0100 Message-Id: <9601041034.AA17113@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: Thomas.Radtke@rz.Uni-Osnabrueck.DE Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199512231720.SAA20381@nereid.rz.Uni-Osnabrueck.DE> (message from Thomas Radtke on Sat, 23 Dec 1995 18:20:59 +0100 (NFT)) Subject: Re: readline-2.0 >>>>> "Thomas" == Thomas Radtke writes: >> But I also compiled examples/histexamp and there you get the >> history with the cursor keys working. So I think there are only >> some (simple ?) additions in the test code of readline to get >> it work with cursor keys too. Thomas> You must set the prefix in .inputrc. Below is a copy of Thomas> my Amiga rc file. Thomas> Thomas Thomas> "\e\C-[": arrow-key-prefix Thomas> [lots of stuff deleted ;] Thank you very much for that hint. With this setting I got readline-2.0 work. The other way is to set the command string of the cursor and/or function keys explicit,i.e. "\e\C-[A": previous-history this must be done if you want to map the function keys. (See example .inputrc below). Yesterday I got a version of .inputrc from Hans Verkuil which uses the Amiga console specific command introducer CSI. This is the third way. But I modified readline-2.0 a little. (If anybody is intersted: search getenv("TERM") in the source files of readline and add after the initialisation of term rl_terminal_name = term; terminal_name = term; then the terminal amiga is known by the other functions and only then $if TERM=amiga $if TERM=ftp and so on works.) This modification leads to another behavior, i.e. mapping of some command strings does not work. Bye Thomas Walter ------------ start of my example of .inputrc -------------------------- # My ~/.inputrc file is in -*- text -*- for easy editing with Emacs. # # Notice the various bindings which are conditionalized depending # on which program is running, or what terminal is active. # # In all programs, all terminals, make sure this is bound. "\C-x\C-r": re-read-init-file # Current problem with AMIGA and readline-2.0: # $if TERM=amiga does not work # rl_terminal_name and terminal_name are always unset. # # AMIGA: uncomment the next line "\e\C-[": arrow-key-prefix # AMIGA: or the next 4 lines to get command line editing. Both is ok too. "\e\C-[A": previous-history "\e\C-[B": next-history "\e\C-[C": forward-char "\e\C-[D": backward-char # AMIGA Function keys "\e\C-[0~": "ls " "\e\C-[1~": "F2 pressed" "\e\C-[2~": "F3 pressed" "\e\C-[3~": "F4 pressed" "\e\C-[4~": "F5 pressed" "\e\C-[5~": "F6 pressed" "\e\C-[6~": "F7 pressed" "\e\C-[7~": "F8 pressed" "\e\C-[8~": "F9 pressed" "\e\C-[9~": "F10 pressed" # Amiga console specials # Works only if terminal not known "": delete-char # AMIGA Works always with readline-2.0 #"›A": previous-history #"›B": next-history #"›C": forward-char #"›D": backward-char # Hp terminals (and some others) have ugly default behaviour for C-h. "\C-h": backward-delete-char "\e\C-h": backward-kill-word "\C-xd": dump-functions # In xterm windows, make the arrow keys do the right thing. $if TERM=xterm "\e[A": previous-history "\e[B": next-history "\e[C": forward-char "\e[D": backward-char # alternate arrow key prefix "\eOA": previous-history "\eOB": next-history "\eOC": forward-char "\eOD": backward-char # Under Xterm in Bash, we bind local Function keys to do something useful. $if Bash "\e[11~": "Function Key 1" "\e[12~": "Function Key 2" "\e[13~": "Function Key 3" "\e[14~": "Function Key 4" "\e[15~": "Function Key 5" # I know the following escape sequence numbers are 1 greater than # the function key. Don't ask me why, I didn't design the xterm terminal. "\e[17~": "Function Key 6" "\e[18~": "Function Key 7" "\e[19~": "Function Key 8" "\e[20~": "Function Key 9" "\e[21~": "Function Key 10" $endif $endif # For Bash, all terminals, add some Bash specific hacks. $if Bash "\C-xv": show-bash-version "\C-x\C-e": shell-expand-line # Here is one for editing my path. "\C-xp": "$PATH\C-x\C-e\C-e\"\C-aPATH=\":\C-b" # Make C-x r read my mail in emacs. # "\C-xr": "emacs -f rmail\C-j" $endif # For FTP, different hacks: $if Ftp "\C-xg": "get \M-?" "\C-xt": "put \M-?" "\M-.": yank-last-arg $endif " ": self-insert ------------ end of my example of .inputrc -------------------------- -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Thu Jan 4 12:56:30 1996 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <89512-2>; Thu, 4 Jan 1996 12:56:11 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id LAA29327 (8.7.2/7.5a-FAU);; Thu, 4 Jan 1996 11:54:11 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA22360; Thu, 4 Jan 1996 11:53:58 +0100 Date: Thu, 4 Jan 1996 11:53:58 +0100 Message-Id: <9601041053.AA22360@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: nisse@lysator.liu.se Cc: cz253@cleveland.Freenet.Edu, amiga-gcc-port@nic.funet.fi In-Reply-To: <199512282356.AAA05245@tina.lysator.liu.se> (nisse@lysator.liu.se) Subject: Re: readline-2.0 >>>>> "Niels" == Niels =?UNKNOWN-8BIT?Q?M=F6ller writes: Niels> cz253@cleveland.Freenet.Edu (David Zaroski) writes: >> >The shell sh in the AMIGA GNU tree is pdksh. But all versions >> I tried >accept only the emacs-style commands. Pressing any >> cursor key will result >only in a screen-flush and a capital >> letter near the command line prompt. >> >> Hmmm... And you are using the pdksh from the /gnu tree? What >> shell are you running it in? I run the pdksh in the stock >> AmigaShell. If you are doing the same, the only other thing I >> can think of is that pdksh is not finding the termcap file in >> /etc, or the termcap file is messed up. I tried it with 3 diffewrent versions of pdksh (aminet, fresh fish 10, and modified version, ready to run, from Lars Hecking) and 2 different termcaps (aminet, fresh fish 10). Niels> I usually run sh under the Amiga shell; I open a standard Niels> amiga shell, with a standard console-window: That the way I run sh too. But the cursor keys do not work. But something must be done by the shell, because the screen flush appears with a significant delay. Second, I used snoopdos to look what is opened by sh. It tries to open inet.library and a lot of Findvar to all the environment variables living in env:. They all fail. Only variables set with 'set foo bar' -- watch: not setenv -- from a plain AMIGADOS CLI are reported with ok. No open to .inputrc or termcap is done. Amiga-Shell> gnu:bin/sh Niels> # ls ... # ls Niels> I think this is the history facility in the console, which Niels> has nothing to do with pdksh or termcap. Niels> I don't use readline, and have no .inputrc file. Perhaps Niels> that is relevant. Hmmm..., I don't think so. The first tries I did I had no .inputrc. Niels> And I also use the cfn utility, to get filename completion Niels> in shell windows, and as an extra bonus, in any program Niels> running in the shell window. It's probably something of a Niels> kluge, but it works the way I want, most of the time. Niels> /Niels -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Fri Jan 5 09:02:11 1996 Received: by nic.funet.fi id <85572-2>; Fri, 5 Jan 1996 08:54:54 +0200 From: Leonard Norrgard To: amiga-mach@nic.funet.fi, amiga-gcc-port@nic.funet.fi Subject: [peter@va.pubnix.com: Conference on Freely Redistributable Software [repost]] Message-Id: <96Jan5.085454+0200_eet.85572-2+44@nic.funet.fi> Date: Fri, 5 Jan 1996 08:54:51 +0200 Resent-From: gnu@prep.ai.mit.edu Resent-Date: Wed, 3 Jan 1996 03:04:59 -0500 Resent-Message-Id: <199601030804.DAA02159@gnu-life.ai.mit.edu> Original-To: gnu-announce@cis.ohio-state.edu Path: not-for-mail From: peter@va.pubnix.com (Peter H. Salus) Sender: gnu@prep.ai.mit.edu Subject: Conference on Freely Redistributable Software [repost] Date: 2 Jan 1996 08:03:49 -0500 Organization: Pubnix Access Systems (Virginia) To: gnu-prog@gnu.ai.mit.edu [ Please repost this wherever you think is appropriate! ] Conference on Freely Redistributable Software Sponsored by the Free Software Foundation Over the past 15 years freely redistributable software with accessible code has become ubiquitous. GNU Emacs is the most popular Unix editor in the world; Linux may well be the most exciting Unix-compatible kernel; Perl has become indispensible to system administrators; Expect automates and controls interactive programs. Join us for a unique conference that will bring together implementors of different types of freely redistributable software as well as the publishers of the operating systems and the tools and applications. Systems and kernels involved will be the Gnu/Hurd, Linux, NetBSD, 386/BSD, and FreeBSD; tools and applications include Bison, Flex, Expect, Emacs, PERL, and GCC. This is the first conference dedicated to bringing together all those involved in freely redistributable software. Join us for this and much, much more! Cambridge Center Marriott Friday, February 2 through Monday, February 5, 1996 Full Conference Schedule Friday, February 2, 1996 Registration 6-10pm Reception 7-9pm Saturday, February 3, 1996 Registration 8am - 6pm Tutorials 9am - 5pm S1: Linux: An Open System for Everyone (am) - Phil Hughes S2: Installing and Running Linux (pm) Phil Hughes S3: Expect (full day) - Don Libes S4: C News (am) - Henry Spencer & Geoff Collyer S5: Advanced editing with Emacs (pm) Richard M. Stallman [box lunch is included with tutorial registration] BoFs 7pm - 10pm Sunday, February 4, 1996 Registration 8am - 6pm 9-10am: Keynote: Linus Torvalds, introduced by Phil Hughes 10:30am: Session I - Chris Demetriou, chair Automated Management of an Heterogeneous Distributed Production Environment - Ph. Defert et al., CERN Freely Redistributable Software across the Internet - Neil Smith, University of Kent Linux for Research and Teaching of Operating Systems - Victor Yodaiken, New Mexico Institute of Mining and Technology 1:30pm: Session II - Don Libes, Session Chair Freely Redistributable Instead of Commercial Software -- Yugoslav Experience - Radivoje Zonjic, University of Belgrade Linux on the OSF Mach3 micro-kernel - Francois Barbou des Places, OSF/Grenoble Internationalization in the GNU Project - Ulrich Drepper, University of Karlsruhe Free Software vs. the Medical Challenges of the 1990's - Greg Wettstein, Roger Maris Cancer Center 3:30pm: Session III The RPM Packaging System - Marc Ewing & Erik Troan, Red Hat Software Why Should the Value-Added Reseller care about Free Software? - Rick R. Castrapel & Frank E. Barone Coordinating Joint Cost/No-cost Rights for Software Developed with SBIR Funding - Philip A. Wilsey & Dale E. Martin, University of Cincinnati Licensing Alternatives for Freely Redistributable Software - L. Peter Deutsch, Aladdin Enterprises 5:15pm: Keynote: Richard M. Stallman, introduced by L. Peter Deutsch 8-9pm: Special Presentation on INN - Rich Salz, OSF 8-10pm: BoFs Monday, 5 February 1996 8-10am: Registration 9am - 5pm: Tutorials M1: Programming the GNU/Hurd (full day) - Michael I. Bushnell M2: BSD Internals (am) - Margo Seltzer & Aaron Brown M3: GCC (pm) - Richard M. Stallman M4: Perl (full day) - Tom Christiansen Conference Registration: $200 (Students see *) Tutorial fees: pre-reg on-site Half-day $175 $220 One day $295 $375 One-and-a-half $470 $570 Two days $540 $640 (Students see *) HOTEL INFORMATION The conference will be held at the Cambridge Center Marriott, just across the street from the MIT campus and at the Kendall/MIT station of the Red Line ``T'' \(em the Boston subway. To Make Your Hotel Reservation Special hotel rates have been arranged for attendees at the Conference on Freely Redistributable Software: US $95/night single or double. There are non-smoking rooms available. Call the Cambridge Center Marriott directly: +1 800 228-9290 in the US and Canada; +1 617 494-6600 from elsewhere. Fax: +1 617 494-0036. To ensure that you get the special hotel rate, tell ``reservations'' that you are an attendee at the Conference on Freely Redistributable Software. +1 800 228-9290 in the US and Canada; +1 617 494-6600 elsewhere Program committee Peter H. Salus, chair Robert J. Chassell Chris Demetriou John Gilmore Marshall Kirk McKusick Rich Morin Eric S. Raymond Vernor Vinge ---- TUTORIAL OFFERINGS Saturday, February 3 Course S1. Linux: An Open System For Everyone (half-day tutorial, am); Instructor: Phil Hughes Originally a PC-based product, Linux now runs on other hardware including the Alpha. Linux is making serious inroads into commercial areas and, in many cases, offers a viable Unix alternative at low cost. Topics covered include: What is Linux?; The Linux Copyright--GPL; Linux Design Philosophy; Linux Distributions; Is Linux Commer-cially Viable?; Using Linux; Future of Linux. Phil Hughes is the publisher of the \fILinux Journal\fP, the monthly magazine of the Linux community. Course S2. Installing and Running Linux (half-day, pm); Instructor: Phil Hughes This is a look ``under the hood.'' It will cover what makes up a Linux system, what you need, how to install it, and what to do when something goes wrong. Topics will include: Assessing Hardware Requirements; Comparison of Linux Distributions; Configuration Decisions; Installation; Systems Administration; Networking and Interoperability; What to do when something goes wrong. Course S3. Expect -- Automating Interactive Applications (full-day tutorial); Instructor: Don Libes This tutorial will teach students how to automate interactive programs such as telnet, ftp, passwd, and many other applications. It will also explain how to test interactive applications, how to connect such applications, how to reuse interactive programs in Web applications, and how to build X GUIs without rewriting existing code; all this with security and reliability. An hour will be devoted to Tcl/tk. Don Libes is the author of Exploring Expect and co-author of Life with Unix. In another life he works at NIST. Course S4. C News (half-day tutorial, am); Instructors: Geoff Collyer and Henry Spencer C News is one of the major reception/storage/expiry software packages; superseding B News completely, it is in widespread use. Topics will include: decisions that should be made before installation; what resources you need; news database organization; configuring C News; building, checking, and installing C News; setting up control files; testing, troubleshooting, and startup; maintenance and housekeeping. Geoff Collyer has been programming computers for almost a quarter-century, and using and administering Unix systems for almost 20 years. He is now a Member of Technical Staff in the Computing System Research Laboratory of AT&T Bell Laboratories. Henry Spencer is an independent consultant and author, long involved with Usenet and netnews. He and Geoff Collyer wrote C News, the first high-performance package for Usenet article transport and storage. Course S5. Advanced editing with Emacs (half-day tutorial, pm); Instructor: Richard M. Stallman Emacs is both an editor and a programming environment. In this tutorial, the creator of the most popular of all Unix editors will move beyond the everyday. This tutorial will explain advanced Emacs facilities for editing text and programs and manipulating files -- features including programming language major modes, tags tables, enriched mode, and shell buffers -- all without Emacs Lisp programming. Richard M. Stallman is the President of the Free Software Foundation and the creator of Emacs. He is also the principal author of Bison and GCC. Monday, February 5 Course M1. Programming the GNU/Hurd (full-day tutorial); Instructor: Michael I. Bushnell The GNU/Hurd is a multi-server operating system which runs on Mach 3.0. In Unix and most Mach-based systems, the majority of system facilities are concentrated in a single entity (called variously the `kernel' or the `single server'). The goal of this tutorial is to describe the architecture of the Hurd with special attention to its innovative aspects, as well as to provide guidance to programmers who wish to program or extend the Hurd. It will describe the existing Hurd servers and the library as well as cover subjects such as: The core interfaces of the GNU/Hurd for process management and I/O; The implementation of signals entirely in the library, and how correctness is achieved; How to use the additional libraries the Hurd provides to make writing servers easier; The implementation of fork and exec. Michael Bushnell is the principle architect and designer of the GNU/Hurd. He works for the FSF doing operating systems development. Course M2. BSD Internals (half-day tutorial, am); Instructors: Margo Seltzer and Aaron Brown This tutorial will present an overview of the kernel architecture of 4.4BSD. The presentation will emphasize porting to new architectures. Margo Seltzer received her Ph.D. from the University of California at Berkeley, where she worked on file systems. She is an assistant professor of Computer Science at Harvard University; Aaron Brown is at Harvard University, where he has recently ported NetBSD to the SS 20. Course M3. Writing machine descriptions using GCC (half-day tutorial, pm); Instructor: Richard M. Stallman This tutorial will explain the overall organization of the GNU C compiler and the RTL data structure, and how to use it to write a new machine description. Students don't need to know anything about the GNU C internals, but should be prepared to learn fast. Richard M. Stallman is the principal author of GCC. Course M4. Perl Programming (full-day tutorial); Instructor: Tom Christiansen Perl is a publicly available and highly portable interpreted programming language occupying the large niche between shell and C programming. Perl's syntax and features resemble C, in combination with the best parts of sh, sed, awk, etc. Because Perl incorporates aspects of more than a dozen other Unix tools, experienced users will come up to speed on Perl rapidly. This course is suitable for individuals who have barely looked at Perl before. It is essential that students have a strong background in Unix shell programming, with a good working knowledge of regular expressions. Some background in sed, awk, and some C programming is useful but not essential. Topics of this tutorial include detailed descriptions and numerous examples of the syntax and semantics of the language, its data types, operators, control flow, regular expressions, and I/O facilities, and the Perl debugger. Tom Christiansen is a software consultant specializing in Perl applications, optimizations, and training. He serves on the Board of Directors of the USENIX Association, and is well-known for his courses in Perl programming. Tutorial fees: pre-reg on-site Half-day $175 $220 One day $295 $375 One-and-a-half $470 $570 Two days $540 $640 (Students see *) -------------------------------- Conference on Freely Redistributable Software REGISTRATION FORM Name: Company/Address: Phone: ___________________ Fax: __________________ email: ______________________________ Conference Registration Fee $200 (to 1/12/96); $250 (on site); Students (see *) $_____________ TUTORIALS I wish to register for: Saturday, 3 February S1. Linux OS (am) [ ] S2. Instal. Linux (pm) [ ] S3. Expect (full day) [ ] S4. C News (am) [ ] S5. Adv. Emacs (pm) [ ] Monday, 5 February M1. GNU/Hurd (full day) [ ] M2. BSD (am) [ ] M3. GCC (pm) [ ] M4. Perl (full day) [ ] TOTAL ______ A boxed lunch is included with Tutorial registration. Please indicate preference: Saturday Tutorials: [ ] Chicken [ ] Beef [ ] Vegetarian Tossed Salad Monday Tutorials: [ ] Turkey [ ] Ham+cheese [ ] Vegetarian pocket * Attention Students: Student fees: $50/conference; $75/tutorial; Preregistration only. There will be a limited number of scholarships available for students applying with a copy of current student identification. PAYMENT: Enclosed: [ ] Check [ ] Money order [ ] Traveler's Check Payments must be in US Dollars. Credit Card: [ ] MC [ ] Visa [ ] AmEx [ ] JCB [ ] Diner's Club [ ] Carte Blanche Credit Card Number: _______________________________________ Exp. Date: ______________ Signature: _______________________________________ The Conference on Freely Redistributable Software will be held February 2-5 1996 at the Cambridge Marriott Hotel, Kendall Square, Cambridge MA, USA. For more information contact: Free Software Foundation 59 Temple Place Suite 330 Boston MA 02111-1307 USA Phone: +1 617 542-5942 Fax: +1 617 542-2652 email: confinfo@gnu.ai.mit.edu -- ----------------------------------------------------------- Peter H. Salus #3303 4 Longfellow Place Boston, MA 02114 +1 617 723 3092 ----------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Fri Jan 5 14:39:11 1996 Received: from net.wau.nl ([137.224.10.12]) by nic.funet.fi with ESMTP id <89481-4>; Fri, 5 Jan 1996 14:36:10 +0200 Received: from vines2.wau.nl by NET.WAU.NL (PMDF V4.3-10 #6821) id <01HZNJ03OG80003E7R@NET.WAU.NL>; Fri, 05 Jan 1996 13:42:06 +0000 (GMT) Received: by vines2.wau.nl; Fri, 5 Jan 96 13:35:50 +0100 Date: Fri, 05 Jan 1996 13:35:20 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: Re: GCC2.7.0 broken ??? To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi All, I followed Freds advice and downloaded gcc2.70 from the ade directory and it seems, from a quick check, that the code emitted is now the same for the -O0 and -O2 versions. There is something weird though. The gcc version seems to have the same problems as the Aztec5.2a version, regarding this kind things: printf("testing\n"); The "testing\n" is translated to dc.b "testing012" instead of "testing\012", I'll check it out because I can be wrong too at 1:20 in the morning The bad news is that the second stage rcc still crashes but that could be due to problems in the mc68030.md file. Joop Joop.vandeWege@medew.ento.wau.nl From amiga-gcc-port-owner@nic.funet.fi Fri Jan 5 20:40:50 1996 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <90793-4>; Fri, 5 Jan 1996 20:35:30 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tYHqt-000RVFC; Fri, 5 Jan 96 20:30 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0foy@wyst.hobby.nl>; Fri, 5 Jan 96 18:26:50 CET Message-Id: <9601051726.0foy@wyst.hobby.nl> Date: Fri, 5 Jan 1996 18:26:49 +0000 (CET) Content-Type: text Content-Length: 973 From: hans@wyst.hobby.nl (Hans Verkuil) To: amiga-gcc-port@nic.funet.fi Subject: "tar xzvf -" problem found Hi all, I've discovered why "tar xzvf -" (reading and uncompressing from stdin) doesn't work. For once it isn't the ixemul.library but tar itself. It forks a third process (one and two are for tar and gzip) to read from stdin in order to take care of the blocking factor (whatever that may be). However, this fork is a real 'fork' and cannot be replaced by a vfork. Replacing it by vfork does indeed lead to a deadlock. I think that it is relatively easy to patch buffer.c in the tar-distribution to handle input from stdin identical to input from a file, and just skip the 'blocking factor' part. Anyone here who wants to fix tar to handle this more gracefully? Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat Jan 6 01:00:29 1996 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <89175-1> convert rfc822-to-8bit; Sat, 6 Jan 1996 00:54:31 +0200 Received: from uran.informatik.uni-bonn.de (root@uran.informatik.uni-bonn.de [131.220.8.49]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id WAA21509 for ; Fri, 5 Jan 1996 22:54:27 GMT Received: from comma.rhein.de (root@comma.rhein.de [193.174.6.131]) by uran.informatik.uni-bonn.de (8.7.3-ws3/8.7.1-ws3) with ESMTP id XAA24644 for ; Fri, 5 Jan 1996 23:54:25 +0100 (MET) Received: from beverly (is@beverly.rhein.de [193.174.6.77]) by comma.rhein.de (8.7.1/8.6.9) with SMTP id XAA19801 for ; Fri, 5 Jan 1996 23:54:16 +0100 (MET) Received: by beverly.rhein.de (Amiga SMTPpost 0.88 Feb 28, 1994) id AA01; Fri, 5 Jan 96 23:54:12 MIME-Version: 1.0 From: is@Beverly.rhein.de (is) Message-Id: <07a246b030edac1020is@Beverly> To: amiga-gcc-port@nic.funet.fi Cc: is@Beverly.rhein.de Reply-To: is@Beverly.rhein.de Subject: Re: ixemul on 060? X-Mailer: Amiga MetaTool 40.5alpha Content-Type: text/plain Content-Transfer-Encoding: 8BIT Date: Fri, 5 Jan 96 23:54:12 Organization: private site Hello, I have massive problems (Enforcer hits, EMT traps, ...) with the gcc & friends on a 68060 DraCo, and suspect that ixemul (I tried 41.1, 41.4 and 41.5) is the culprit. Somebody told me he thought he'd seen a pointer to a corrected (for the 060) ixemul version on Aminet, but I didn't find any with adt -f 060. Does such a beast exist? Regards, Ignatios Souvatzis From amiga-gcc-port-owner@nic.funet.fi Sat Jan 6 13:45:04 1996 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <89765-3>; Sat, 6 Jan 1996 13:41:49 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tYXsL-000Ro9C; Sat, 6 Jan 96 13:37 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0fqd@wyst.hobby.nl>; Sat, 6 Jan 96 01:51:19 CET Message-Id: <9601060051.0fqd@wyst.hobby.nl> Date: Sat, 6 Jan 1996 01:51:17 +0000 (CET) In-Reply-To: <07a246b030edac1020is@Beverly> from "is" at Jan 5, 96 11:54:12 pm Content-Type: text Content-Length: 1460 From: hans@wyst.hobby.nl (Hans Verkuil) To: is@Beverly.rhein.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: ixemul on 060? > I have massive problems (Enforcer hits, EMT traps, ...) with the gcc & > friends on a 68060 DraCo, and suspect that ixemul (I tried 41.1, 41.4 and= > > 41.5) is the culprit. Somebody told me he thought he'd seen a pointer to > a corrected (for the 060) ixemul version on Aminet, but I didn't find > any with adt -f 060. > > Does such a beast exist? Others had problems too. But someone apparently fixed the problems by patching library/trap.s. And I haven't heard anything since. This patch is part of 41.5. Probably also of 41.4. The problem was with the reset_fpu function that is called at various places. Here is the code in question: Lreset_fpu: btst #7,(4)@(0x129) | is AFB_68060 set in SysBase->AttnFlags ?? beq Lno_060fpu | found 060 and put 2 more longs on stack clrl sp@- | prepare 060 fpu null state frame clrl sp@- | needs 2 additional longs on stack Lno_060fpu: clrl sp@- frestore sp@+ Does the DraCo set the right bits in the AttnFlags field? On my 040 that byte has the value 0x7f, so that should be 0xff for your system. This is the only 68060 bug fix that I'm aware of. Hope this helps, Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Sat Jan 6 17:28:29 1996 Received: from net.wau.nl ([137.224.10.12]) by nic.funet.fi with ESMTP id <89671-2>; Sat, 6 Jan 1996 17:27:27 +0200 Received: from vines2.wau.nl by NET.WAU.NL (PMDF V4.3-10 #6821) id <01HZP39WFGW0003Z1T@NET.WAU.NL>; Sat, 06 Jan 1996 16:33:27 +0000 (GMT) Received: by vines2.wau.nl; Sat, 6 Jan 96 16:27:21 +0100 Date: Sat, 06 Jan 1996 16:25:09 +0100 (CET) From: test1@MEDEW.ENTO.WAU.NL (test1) Subject: Re: ixemul on 060? To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >Others had problems too. But someone apparently fixed the problems by >patching library/trap.s. And I haven't heard anything since. This patch is >part of 41.5. Probably also of 41.4. >The problem was with the reset_fpu function that is called at various >places. Here is the code in question: This is correct Hans. I figured out what was wrong and the patch got accepted and I have had reports of quite a few people who were very happy with it so there must be something else. Stack size ???????????? Please specify what you were doing (Ignatio) when the error occurs. Joop Joop.vandeWege@medew.ento.wau.nl From amiga-gcc-port-owner@nic.funet.fi Sat Jan 6 21:46:22 1996 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <89336-4>; Sat, 6 Jan 1996 21:45:23 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.7.1/8.7.1) id UAA10914; Sat, 6 Jan 1996 20:45:15 +0100 (MET) Date: Sat, 6 Jan 1996 20:45:15 +0100 (MET) From: Ignatios Souvatzis Message-Id: <199601061945.UAA10914@theory.cs.uni-bonn.de> To: test1@MEDEW.ENTO.WAU.NL CC: amiga-gcc-port@nic.funet.fi In-reply-to: test1's message of Sat, 06 Jan 1996 16:25:09 +0100 (CET) Subject: ixemul on 060? X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1aOthers had problems too. But someone apparently fixed the problems by >patching library/trap.s. And I haven't heard anything since. This patch is >part of 41.5. Probably also of 41.4. >The problem was with the reset_fpu function that is called at various >places. Here is the code in question: This is correct Hans. I figured out what was wrong and the patch got accepted and I have had reports of quite a few people who were very happy with it so there must be something else. Stack size ???????????? Please specify what you were doing (Ignatio) when the error occurs. Ok, so it must be s.th. else. I tried (with stack set to 200000, 300000 or 400000) a make a2410.o which started (basically) gcc -c -O3 a2410.c A2410.c is a quite small file, the whole executable, as compiled with the same gcc-2.7.0 on my A3000, was less than 10 kBytes, with about 80% coming from A2410.c I get an Enforcer Hit (the builtin DraCo Enforcer): Longword Read from 000022xx (dont remember the exact number). It looks like the culprit is "input.device". The system is messed up so much that no multitasking works any more (no mouse, no keyboard reset, which requires MT sort of still working on the DraCo when using the MF-II keyboard). To check, I tried "make bumprev", which calls bumprev from the C= Native Developer Update kit V3.1. I get a Longword Read from 000006DN for some N I forgot, again consistently, without crashing the system this time. These latter tests where done with 2.7.0 from Aminet, but ixemul.library replaced by the 040 version of 41.5 downloaded a few days ago from ftp.amigalib.com. I guess I'll have to look at ixemul source myself. Hope it does not depend on Amiga HARDWARE directly. Regards, Ignatios Souvatzis From amiga-gcc-port-owner@nic.funet.fi Sat Jan 6 22:16:50 1996 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <89765-1>; Sat, 6 Jan 1996 22:16:03 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.7.1/8.7.1) id VAA12334; Sat, 6 Jan 1996 21:15:54 +0100 (MET) Date: Sat, 6 Jan 1996 21:15:54 +0100 (MET) From: Ignatios Souvatzis Message-Id: <199601062015.VAA12334@theory.cs.uni-bonn.de> To: ignatios@theory.cs.uni-bonn.de CC: test1@MEDEW.ENTO.WAU.NL, amiga-gcc-port@nic.funet.fi In-reply-to: Ignatios Souvatzis's message of Sat, 6 Jan 1996 20:45:15 +0100 (MET) <199601061945.UAA10914@theory.cs.uni-bonn.de> Subject: ixemul on 060? X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a; Sun, 7 Jan 1996 00:50:03 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tYhRp-000gXUC; Sat, 6 Jan 96 15:50 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: mailing lists at amigalib.com To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Sat, 6 Jan 1996 15:50:49 -0700 (MST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4558 We recently installed majordomo here at amigalib.com and set up some mailing lists for discussion about the Amiga Developers Environment (ADE) project. To get information about how to use the majordomo server, send email to "majordomo@amigalib.com" with just "help" as the body of the message. To save you some time, we have already send our server the following message and the output is included at the end of this message. lists info ade info ade-gcc info ade-ixemul info ade-projects Other lists will be added shortly, such as ade-autoconf, ade-binutils, etc. -Fred ============================================================================ >>>> lists majordomo@amigalib.com serves the following lists: ade ade-gcc ade-ixemul ade-projects Use the 'info ' command to get more information about a specific list. >>>> info ade This mailing list is for general discussion about the Amiga Developer's Environment, a project which is supported by volunteers from the Amiga community. There are separate lists for discussions about specific parts of the ADE, such as ade-gcc for the GNU C compiler. Please use this list only for topics that are of general interest. Because of the hard work from a number of members of the Amiga community, we now have a large body of development tools and other packages that have been ported to the Amiga and are available in both source and binary form. The ADE is available via ftp at: ftp.amigalib.com:pub/ade/... We welcome mirrors and will list them here as they come on line. The ADE will also eventually be available on CD-ROM as part of the new series of developer oriented CD-ROMs expected to be released by Amiga Library Services in the first quarter of 1996. Although the ADE started out as ports of tools covered by the GNU General Public License, the GNU Library General Public License, or some code covered by the "Berkeley License", it certainly isn't limited to those. Any package which is available in source is eligible to be part of the ADE. One of the goals of the ADE is to have a completely self hosting environment. I.E. that everything within it be compilable by the GNU C compiler or other provided compilers. It should be possible for the recipient of these utilities to make whatever changes or bug fixes they want in any piece of code, and then rebuild and use that fixed version (and hopefully send those changes back for integration into future releases). >>>> info ade-gcc This mailing list if for discussion of the GNU C compiler, though discuss- ions of other GNU compilers (such as C++, Objective-C, ADA, and Fortran) are also appropriate until such time as these tools have their own lists. >>>> info ade-ixemul This list is for discussion of ixemul.library, a Unix emulation library that fundamental to the ability to run Unix tools on AmigaDOS with few or no changes at all. Essentially the library provides almost all of the functionality of a BSD like kernel and libraries, with the exception of a few hard to emulate functions like a true fork() routine. >>>> info ade-projects This list is for discussion of projects that people are working on related to the ADE. This might include, for example, projects to extend various ADE tools to make them more AmigaDOS friendly, projects to port tools which are not currently part of the ADE but are intended to become part of it once ported, etc. The current projects list can be found at: ftp.amigalib.com:pub/ade/PROJECTS If you are looking for an interesting project to do, and you have not already been monitoring this list for a while, you should first check the projects list to see if the project you are interested in is already being worked on. If you don't find it there, then post to this list asking if anyone is already working on something similar or would like to collaborate on this project. When you have defined a project to work on and are reasonably certain of the details of the project, send email to the maintainer of the projects list so that it can be included in the list. Note that there may be rewards offered for certain projects that are deemed to be of importance to the overall evolution of the ADE. ============================================================================ From amiga-gcc-port-owner@nic.funet.fi Sun Jan 7 19:36:55 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <85658-2>; Sun, 7 Jan 1996 19:31:53 +0200 Received: from achilles.noc.ntua.gr (actually user root@achilles.noc.ntua.gr) by funet.fi with SMTP (PP); Sun, 7 Jan 1996 19:28:43 +0200 Original-Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id TAA07159 at Sun, 7 Jan 1996 19:27:53 +0200 PP-warning: Illegal Received field on preceding line Original-Received: by softlab.ece.ntua.gr with UUCP id TAA00127 at Sun, 7 Jan 1996 19:28:13 +0200 (EET) PP-warning: Illegal Received field on preceding line Received: by kriton.UUCP (V1.17-beta/Amiga) id <09p8@kriton.UUCP>; Sun, 7 Jan 96 14:37:44 EET Date: Sun, 7 Jan 96 14:37:44 EET Message-Id: <9601071237.09p8@kriton.UUCP> In-Reply-To: (from theseas!amigalib.com!fnf (Fred Fish)) (at Sat, 6 Jan 1996 15:50:49 -0700 (MST)) Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!amigalib.com!fnf@achilles.noc.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: mailing lists at amigalib.com I'd just like to mention a couple of points: a. You forgot to add the output of the "help" command, which mentions how to actually subscribe to the new lists. (I assume that, similarly to other majordomo sites, one simply needs to send a message with "subscribe list-name" commands in the message body. b. Won't the existence of both the amiga-gcc-port and the ade-gcc port cause confusion? -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I've discovered we can't afford to die here--not even once!" ----- From amiga-gcc-port-owner@nic.funet.fi Sun Jan 7 19:52:49 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <84985-4>; Sun, 7 Jan 1996 19:51:43 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tYzGu-000gXUC; Sun, 7 Jan 96 10:52 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: mailing lists at amigalib.com To: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) Date: Sun, 7 Jan 1996 10:52:44 -0700 (MST) In-Reply-To: <9601071237.09p8@kriton.UUCP> from "Kriton Kyrimis" at Jan 7, 96 02:37:44 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 821 > a. You forgot to add the output of the "help" command, which mentions how to > actually subscribe to the new lists. (I assume that, similarly to other > majordomo sites, one simply needs to send a message with > "subscribe list-name" commands in the message body. Did you miss this part: To get information about how to use the majordomo server, send email to "majordomo@amigalib.com" with just "help" as the body of the message. > b. Won't the existence of both the amiga-gcc-port and the ade-gcc port cause > confusion? Possibly, but they really are for two different incarnations of the compiler, and amiga-gcc-port picks up lots of traffic about things unrelated to the compiler itself. Philippe and I are seldom 100% in sync in our source, though we strive to stay as close as possible. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Jan 8 14:38:37 1996 Received: from hpcl.cti.gr ([150.140.91.21]) by nic.funet.fi with SMTP id <90880-2>; Mon, 8 Jan 1996 14:33:57 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA24631 (5.67a8/IDA-1.5 for ); Mon, 8 Jan 1996 14:33:01 +0200 From: Kriton Kyrimis Message-Id: <199601081233.AA24631@hpcl.cti.gr> Subject: Re: mailing lists at amigalib.com To: fnf@amigalib.com (Fred Fish) Date: Mon, 8 Jan 1996 14:32:57 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi (gcc) Reply-To: kyrimis@theseas.softlab.ece.ntua.gr In-Reply-To: from "Fred Fish" at Jan 7, 96 10:50:43 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1385 > > a. You forgot to add the output of the "help" command, which mentions how to > > actually subscribe to the new lists. (I assume that, similarly to other > > majordomo sites, one simply needs to send a message with > > "subscribe list-name" commands in the message body. > > Did you miss this part: No, I didn't. I was simply suggesting that you might have included the output of the help command along with the other information you included for our benefit. Anyway, my guess on how to subscribe was correct. > and amiga-gcc-port picks up lots of traffic about things unrelated to the > compiler itself. I agree with you on this one, but this is probably going to happen with the ADE lists as well. > Philippe and I are seldom 100% in sync in our source, though we strive to stay > as close as possible. I tend to favor stability over all else, while Philippe > releases lots of betas that have little testing. All the ADE releases will > pass a complete two stage bootstrap before they are released. So, what would be the guidelines for selecting whether to post on ade-gcc, amiga-gcc-port, or both? Does my currently using the aminet version of gcc mean that I should never post to the ade-gcc group? -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "The Himalayas are quite tall this time of the year!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Jan 8 18:16:48 1996 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90318-2>; Mon, 8 Jan 1996 18:13:08 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id SAA28178 at Mon, 8 Jan 1996 18:12:27 +0200 Received: by softlab.ece.ntua.gr with UUCP id SAA07334 at Mon, 8 Jan 1996 18:12:47 +0200 (EET) Received: by kriton.UUCP (V1.17-beta/Amiga) id <09pn@kriton.UUCP>; Mon, 8 Jan 96 17:56:17 EET Date: Mon, 8 Jan 96 17:56:17 EET Message-Id: <9601081556.09pn@kriton.UUCP> Organization: My Home Reply-To: kyrimis@softlab.ece.ntua.gr From: kriton!kyrimis@achilles.noc.ntua.gr (Kriton Kyrimis) To: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: bug in defines SCHAR_MIN as 0x80. (I am using the includes that came with version 2.7.0 of the aminet distribution of gcc.) This causes programs such as the following: ------------------------------------------------------------------------------ #include main() { if (0 SCHAR_MAX) { printf("0 doesn't fit in a signed char\n"); }else{ printf("0 fits in a signed char\n"); } return 0; } ------------------------------------------------------------------------------ to produce ridiculous results. (Code similar to this is contained in the source of the lcc compiler.) To fix this, SCHAR_MIN should be defined to either -128 or ((signed char)0x80). -- Kriton (UUCP: pythia!theseas!kriton!kyrimis) (INTERNET: kyrimis@theseas.softlab.ece.ntua.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "If everybody gave up because things were hopeless, the whole vast panoply of galactic history would be reduced to an exponentially expanding mass of fissioning protozoa." ----- From amiga-gcc-port-owner@nic.funet.fi Mon Jan 8 18:48:29 1996 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <90926-3>; Mon, 8 Jan 1996 18:47:53 +0200 Received: from fishpond (amigalib.com [165.247.33.2]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with SMTP id QAA24268 for ; Mon, 8 Jan 1996 16:47:40 GMT Received: by fishpond (Smail3.1.29.1 #57) id m0tZKku-000gXVC; Mon, 8 Jan 96 09:49 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: mailing lists at amigalib.com To: kyrimis@theseas.softlab.ece.ntua.gr Date: Mon, 8 Jan 1996 09:49:07 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <199601081233.AA24631@hpcl.cti.gr> from "Kriton Kyrimis" at Jan 8, 96 02:32:57 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2046 > > and amiga-gcc-port picks up lots of traffic about things unrelated to the > > compiler itself. > > I agree with you on this one, but this is probably going to happen with the > ADE lists as well. Perhaps, though if necessary I can convert them to moderated lists. Eventually there will probably be a list for every major component, so the need to post to an inappropriate list should be minimal. One reason for having lots of lists is that the CVS server will be set up to route mail about checkins on particular components to the appropriate mailing list. Maintainers of each component need to subscribe to the mailing list, but individual users don't unless they want to see this traffic as well as any discussions among the maintainers. I.E. if a user has a question about autoconf, they can send email to ade-autoconf@amigalib.com to reach the maintainers, but don't have to subscribe to the list unless they want to. There is a similar setup at Cygnus, and it works pretty well. I subscribe to the internal bfd library list, gcc list, and gdb list, so that I get email from CVS about each change that any maintainer checks in, as well as the internal discussions amoung the maintainers. > So, what would be the guidelines for selecting whether to post on ade-gcc, > amiga-gcc-port, or both? Does my currently using the aminet version of gcc > mean that I should never post to the ade-gcc group? That's a good question, and I can understand why it would arise. I will certainly stay subscribed to the amiga-gcc-port list as well as the ade-gcc list, and I suspect most other maintainers will as well, so it probably isn't necessary (or desirable) to send messages to both lists. If the question is specifically about the ade release of gcc, then certainly it probably belongs on the ade-gcc list. If it is a general question about gcc that is probably applicable to both, use whichever one you think is most appropriate. If it is a question that has nothing to do with gcc, then it belongs on the amiga-gcc list. :-) -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Jan 9 00:29:04 1996 Received: from achilles.noc.ntua.gr ([147.102.222.210]) by nic.funet.fi with ESMTP id <90516-4>; Tue, 9 Jan 1996 00:27:58 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id AAA26576 at Tue, 9 Jan 1996 00:27:17 +0200 Received: by softlab.ece.ntua.gr with ESMTP id AAA13046 at Tue, 9 Jan 1996 00:27:36 +0200 (EET) Received: by achilles.noc.ntua.gr via NTUAnet with SMTP id AAA26569 at Tue, 9 Jan 1996 00:27:05 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tZQwO-000RMTC; Tue, 9 Jan 96 00:25 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0g19@wyst.hobby.nl>; Mon, 8 Jan 96 21:41:27 CET Message-Id: <9601082041.0g19@wyst.hobby.nl> Date: Mon, 8 Jan 1996 21:41:26 +0000 (CET) In-Reply-To: <9601081556.09pn@kriton.UUCP> from "Kriton Kyrimis" at Jan 8, 96 05:56:17 pm Content-Type: text From: hans@wyst.hobby.nl (Hans Verkuil) To: kyrimis@softlab.ece.ntua.gr Cc: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: Re: bug in According to Kriton Kyrimis: > > defines SCHAR_MIN as 0x80. (I am using the includes that > came with version 2.7.0 of the aminet distribution of gcc.) > > This causes programs such as the following: > ------------------------------------------------------------------------------ > #include > > main() > { > if (0 SCHAR_MAX) { > printf("0 doesn't fit in a signed char\n"); > }else{ > printf("0 fits in a signed char\n"); > } > return 0; > } > ------------------------------------------------------------------------------ > to produce ridiculous results. (Code similar to this is contained in the > source of the lcc compiler.) To fix this, SCHAR_MIN should be defined to > either -128 or ((signed char)0x80). I changed it to ((signed char)0x80) in the ixemul distribution. I also fixed the comments after these defines: they were the wrong way round. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Jan 9 16:13:26 1996 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <85317-4>; Tue, 9 Jan 1996 11:09:15 +0200 Received: by colombo.telesys-innov.fr; Tue, 9 Jan 1996 10:04:58 GMT From: Philippe BRAND Message-Id: <199601091004.KAA17834@colombo.telesys-innov.fr> Subject: Re: mailing lists at amigalib.com To: fnf@amigalib.com (Fred Fish) Date: Tue, 9 Jan 1996 10:04:56 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: from "Fred Fish" at Jan 8, 96 09:49:07 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Fred Fish writes: > Perhaps, though if necessary I can convert them to moderated lists. I would vote also for an ade-announce list, moderated, where packages mainteners can announce betas, releases, etc... -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://colombo.telis-sc.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Jan 9 16:14:48 1996 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <88640-4>; Tue, 9 Jan 1996 12:47:49 +0200 Received: by colombo.telesys-innov.fr; Tue, 9 Jan 1996 11:43:37 GMT From: Philippe BRAND Message-Id: <199601091143.LAA18693@colombo.telesys-innov.fr> Subject: Re: mailing lists at amigalib.com To: hans@wyst.hobby.nl (Hans Verkuil) Date: Tue, 9 Jan 1996 11:43:36 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9601090713.0g3e@wyst.hobby.nl> from "Hans Verkuil" at Jan 9, 96 08:13:49 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hans Verkuil writes: > > > I've never really understood why there is that distinction between the > > > Aminet gcc and the ADE gcc. Why cannot Philippe maintain the ADE gcc and > > > distribute that on Aminet? Distinction is a metter of data access. People lucky enough to have a CD-Rom device would prefer actual FF CD layout, where they can easily just assign proper dirs to CD and then start to work immediatly. On another way, people that have only access to Internet might prefer a splitted distribution. They were talks one ago about aminet distribution layout. Third point: major part of amiga users don't have an Internet access nor a CD-Rom device. But they sometimes own a Modem. Internet access is not cheap in every country, and local calls are not free everywhere, so those people prefer a BBS access, so they prefer actual aminet distribution layout. I run myself largest Amiga dedicated BBS in France so I quite know what I'm saying :) Fred and I do synchronize our sources, as diffs to FSF release and diffs over own diffs. > > I think that is probably a good longterm goal if Phillipe agrees. One > > note about aminet, at least one of the regular aminet maintainers (who > > I won't name) expressed distaste for having any of the GNU stuff on > > aminet, calling it bloated, slow, and buggy. Perhaps he's a SAS > > bigot, don't know and don't care. Well on this particular point, I really don't care also. People now knows that amiga gcc is available on my site and funet.fi. If there is demand for it, current aminet distribution could be also made available on amigalib. > To be fair, the compiler is big and not fast and was buggy. Not so much the > compiler as well as ixemul.library (remember that horrible memory trashing > bug?). It has stabilized a lot since version 40.0. I really think that because of new heading of developments, creation of ADE, things will be better organized, thus resulting in faster development and better synchronization. > > I'd certainly like to see us reach consensus on the best way to > > package releases, which could be a potential problem in merging our > > efforts since I know Philippe favors the "aminet gcc" packaging and I > > tend to prefer to see things packaged more along the lines of the way > > the FSF does (making updates to specific pieces a little more > > flexible) Well in fact I do maintain all sources on my HDs in the FSF way, the only difference is that I run a small script to build an aminet distribution. >.> If aminet wants to mirror the entire ADE tree, I have no > > objections to that, though I'd rather see some distinct ADE mirrors. I don't think it would be a good idea to have aminet mirror ADE tree, which will be by essence chaing too fast for aminet to handle it. I would prefer mirror sites, and in my opinion funet would be a good choice. My systems and especially my link to the Internet can't handle it. > I still fail to see what that has to do with maintaining the sources. The > gcc *sources* are identical, only the packaging differs. So what? Maybe I > overlook something, but the only extra step for Philippe would be to mail > the patches he made to you. That's what we're doing. > Which he does now too whenever you two > synchronize. It would just make it a bit more formal. And the added benefit > to Philippe would be that you can test the changes more thoroughly using a > multistage build. That's what we're doing. > > The "Aminet gcc" is Phillipes "baby", so it's mostly up to him if he > > would like to take over prime responsibility for maintaining the ADE gcc > > and drop responsibility for the rest of the stuff that normally goes into > > an "aminet gcc" release. Yes I do think I should restrict porting/maintaining job to gcc itself. My overall free time is lower nowadays, having reniced --20 baby task. I can continue to maintain ade-gcc itself. I'm currently working on a shared library back-end version. > IMHO. Having two mailinglists around for the same thing is not going to > work. I wouldn't mind having to pay the price of seeing the occasional > Aminet related question on the ade-gcc mailinglist. It depends on goal for ade-gcc list for instance. IMHO people should only subscribed to it IF they intend to add valuable material to the compiler, e.g. additions, inlines, documentation, faq, etc. Actual list might deserve newbie and general discussion topics. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://colombo.telis-sc.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue Jan 9 17:25:25 1996 Received: from net.wau.nl ([137.224.10.12]) by nic.funet.fi with ESMTP id <85255-1>; Tue, 9 Jan 1996 17:24:09 +0200 Received: from vines2.wau.nl by NET.WAU.NL (PMDF V4.3-10 #6821) id <01HZTA1WV9Z4005NSO@NET.WAU.NL>; Tue, 09 Jan 1996 16:30:14 +0000 (GMT) Received: by vines2.wau.nl; Tue, 9 Jan 96 16:23:45 +0100 Date: Tue, 09 Jan 1996 16:17:11 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: New address :) To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Hi All, Just a small mail to announce that who ever tries to mail to my old address (test1@medew.ento.wau.nl) will get it back. My new address is: Joop.vandeWege@medew.ento.wau.nl and just doing a Reply should work. One more small note: I followed Freds advice and got gcc2.7.0 from his ADE directory and that version produces an LCC executable which produces in turn the same code irrespective of optimalisation flags :) Still haven't had time to try the 2.7.2 beta from Funet and the second stage rcc still crashes when producing m68k code :( The problem with dc.b "testing000" instead of "testing\000" should also be solved, thanks to Kriton who beat me in finding it. Joop From amiga-gcc-port-owner@nic.funet.fi Wed Jan 10 08:46:48 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <84831-4>; Tue, 9 Jan 1996 20:01:07 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tZiMg-000gXXC; Tue, 9 Jan 96 11:01 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: mailing lists at amigalib.com To: phb@colombo.telesys-innov.fr (Philippe BRAND) Date: Tue, 9 Jan 1996 11:01:42 -0700 (MST) Cc: fnf@amigalib.com, amiga-gcc-port@lists.funet.fi In-Reply-To: <199601091004.KAA17834@colombo.telesys-innov.fr> from "Philippe BRAND" at Jan 9, 96 10:04:56 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 379 > > Perhaps, though if necessary I can convert them to moderated lists. > > I would vote also for an ade-announce list, moderated, where packages > mainteners can announce betas, releases, etc... I was actually expecting announcements to be part of the traffic in the general group (ade@amigalib.com). I'm not sure we would have enough to justify an ade-announce list. -Fred From amiga-gcc-port-owner@nic.funet.fi Wed Jan 10 08:50:24 1996 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <85102-1>; Tue, 9 Jan 1996 21:32:58 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tZkgs-000RA3C; Tue, 9 Jan 96 21:30 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0g4j@wyst.hobby.nl>; Tue, 9 Jan 96 20:05:10 CET Message-Id: <9601091905.0g4j@wyst.hobby.nl> Date: Tue, 9 Jan 1996 20:05:10 +0000 (CET) In-Reply-To: <199601091004.KAA17834@colombo.telesys-innov.fr> from "Philippe BRAND" at Jan 9, 96 10:04:56 am Content-Type: text Content-Length: 626 From: hans@wyst.hobby.nl (Hans Verkuil) To: phb@colombo.telesys-innov.fr Cc: fnf@amigalib.com, amiga-gcc-port@lists.funet.fi Subject: Re: mailing lists at amigalib.com According to Philippe BRAND: > > Fred Fish writes: > > > Perhaps, though if necessary I can convert them to moderated lists. > > I would vote also for an ade-announce list, moderated, where packages > mainteners can announce betas, releases, etc... Sounds reasonable. You can add my vote, too. Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Jan 10 13:47:02 1996 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <84928-4>; Tue, 9 Jan 1996 21:34:27 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tZkht-000RA3C; Tue, 9 Jan 96 21:31 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0g4o@wyst.hobby.nl>; Tue, 9 Jan 96 20:14:43 CET Message-Id: <9601091914.0g4o@wyst.hobby.nl> Date: Tue, 9 Jan 1996 20:14:42 +0000 (CET) In-Reply-To: <199601091143.LAA18693@colombo.telesys-innov.fr> from "Philippe BRAND" at Jan 9, 96 11:43:36 am Content-Type: text Content-Length: 995 From: hans@wyst.hobby.nl (Hans Verkuil) To: phb@colombo.telesys-innov.fr Cc: amiga-gcc-port@lists.funet.fi Subject: Re: mailing lists at amigalib.com > > IMHO. Having two mailinglists around for the same thing is not going to > > work. I wouldn't mind having to pay the price of seeing the occasional > > Aminet related question on the ade-gcc mailinglist. > > It depends on goal for ade-gcc list for instance. IMHO people should only > subscribed to it IF they intend to add valuable material to the compiler, > e.g. additions, inlines, documentation, faq, etc. Actual list might > deserve newbie and general discussion topics. OK. So, ade-gcc is for gcc-development and the ade mailinglist is for general discussion topics and newbie questions. Conclusion: remove amiga-gcc and move to ade/ade-gcc. Or am I still missing something? Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Wed Jan 10 13:58:26 1996 Received: from net.wau.nl ([137.224.10.12]) by nic.funet.fi with ESMTP id <85491-1>; Wed, 10 Jan 1996 09:51:37 +0200 Received: from vines2.wau.nl by NET.WAU.NL (PMDF V4.3-10 #6821) id <01HZU8J4CNPS0064YQ@NET.WAU.NL>; Wed, 10 Jan 1996 08:57:37 +0000 (GMT) Received: by vines2.wau.nl; Wed, 10 Jan 96 8:51:08 +0100 Date: Wed, 10 Jan 1996 08:35:36 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Re: New address :) To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >>Still haven't had time to try the 2.7.2 beta from Funet and the second >>stage rcc still crashes when producing m68k code :( >What type of crashes are you getting? 8...3, 8...4 ? rcc crashes only on >the 68000 version? Or for all processors? >.....Dave LCC produces at the moment only >020+881 and I'm running it on a 68030+881 (A3000) The GURU is a 8..3 normally sometimes something different. It is not stack related, that one is big enough and Stackmon shows that it doesn't use much of it. I tried gcc2.7.2 last night but haven't looked if -O0 and -O2 rcc executables produce different code like the Aminet gcc2.7.0. The ADE gcc2.7.0 does not. The crash currently happens in the machine independent part of the compiler but it is possible that our m68k code generator produces an error which is not activated until then. It is either the last return from a recursive call and the associated cleanup or the start of 'reduce' which crashes. Joop From amiga-gcc-port-owner@nic.funet.fi Wed Jan 10 14:05:22 1996 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <85397-1>; Wed, 10 Jan 1996 11:48:04 +0200 Received: by tycho.gbar.dtu.dk (1.37.109.15/16.2) Date: Wed, 10 Jan 1996 10:48:00 +0100 (MET) From: Rask Lambertsen To: Amiga-Gcc Liste Subject: Re: mailing lists at amigalib.com In-Reply-To: <199601091143.LAA18693@colombo.telesys-innov.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT On Tue, 9 Jan 1996, Philippe BRAND wrote: > > > I think that is probably a good longterm goal if Phillipe agrees. One > > > note about aminet, at least one of the regular aminet maintainers (who > > > I won't name) expressed distaste for having any of the GNU stuff on > > > aminet, calling it bloated, slow, and buggy. Perhaps he's a SAS > > > bigot, don't know and don't care. After I started using "ixconfig -i" the speed got a lot better. diff now flies on my 7 MHz '000. He may be right about bloated (compare Copy/cp, Rename/mv, Delete/rm, MakeDir/mkdir and so on) but buggy isn't true. I don't care about his oppinion either. > I don't think it would be a good idea to have aminet mirror ADE tree, which > will be by essence chaing too fast for aminet to handle it. I would prefer > mirror sites, and in my opinion funet would be a good choice. My systems and > especially my link to the Internet can't handle it. I would very much like to see ftp.funet.fi as an ADE (and Aminet, btw) mirror as my downloads speed from there is 200 kB/s. Since downloading big files in not a problem for me I like the Aminet packaging. According to the Aminet charts, then gcc distribution is one of the most downloaded and highest rated archives, so maybe it would be a good idea to keep uploading new gcc releases to Aminet. > > IMHO. Having two mailinglists around for the same thing is not going to > > work. I wouldn't mind having to pay the price of seeing the occasional > > Aminet related question on the ade-gcc mailinglist. > > It depends on goal for ade-gcc list for instance. IMHO people should only > subscribed to it IF they intend to add valuable material to the compiler, > e.g. additions, inlines, documentation, faq, etc. Actual list might > deserve newbie and general discussion topics. Sounds OK to me. I would like to see some clearing up of the mailing lists running at funet. In particular, I get exactly on letter each month from amiga-gcc-info telling me that I am still on the list. I was subscribed to that list for 3 months before subscribing to amiga-gcc-port and I never got any messages from it. amiga-gcc-port, on the other hand, is used for more than just messages about porting gcc. I would prefer not to have to subscribe to both ade-gcc and amiga-gcc-port. In particular, being on both raises the question of which one to mail to. And please make the mailing list software set the From: field to the mailing list instead of the one that wrote the message. Maybe set Cc: to the one that wrote the letter. Or set Reply-To: to the mailing list. That would make it easier to avoid sending the same letter to both the mailing list and the one who wrote it. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Jan 11 11:47:58 1996 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <1373-1>; Thu, 11 Jan 1996 11:41:56 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id KAA04373 for ; Thu, 11 Jan 1996 10:30:57 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA18435; Thu, 11 Jan 96 10:40:04 GMT Date: Thu, 11 Jan 96 10:40:04 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9601111040.AA18435@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: Bug with gcc 2.7.2 ? Hi, I experiment some problems with auto stack extend feature in gcc 2.7.2. I try to compile a Amiga specific small project (I use the lastest fd2inline). stack 80000; gcc -c colors.c => works fine stack 80000; gcc -O2 -c colors.c => cc1 internal compiler error: fatal signal 7 stack 150000; gcc -O2 -c colors.c => works fine So I guess there is a problem with the auto stack extend feature with gcc 2.7.2. Note: colors.c is a BGUI exemple form BGUI Aminet archive. \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Thu Jan 11 12:04:45 1996 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <1410-3>; Thu, 11 Jan 1996 12:04:03 +0200 Received: by colombo.telesys-innov.fr; Thu, 11 Jan 1996 11:00:24 GMT From: Philippe BRAND Message-Id: <199601111100.LAA17360@colombo.telesys-innov.fr> Subject: Re: Bug with gcc 2.7.2 ? To: papier@indi1.u-strasbg.fr (Laurent Papier) Date: Thu, 11 Jan 1996 11:00:23 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <9601111040.AA18435@indi1.u-strasbg.fr> from "Laurent Papier" at Jan 11, 96 10:40:04 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Laurent Papier writes: > I experiment some problems with auto stack extend feature in gcc 2.7.2. Didn't know gcc-2.7.2 was compiled with auto-stack :) In fact corrections need to be applied to ixemul prior to be able to compile gcc using auto-stack. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://colombo.telis-sc.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Mon Jan 15 12:29:38 1996 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nic.funet.fi with SMTP id <4312-1>; Mon, 15 Jan 1996 12:25:47 +0200 Received: from indi1.u-strasbg.fr (indi1.u-strasbg.fr [130.79.6.93]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id LAA18974 for ; Mon, 15 Jan 1996 11:17:35 +0100 Received: by indi1.u-strasbg.fr (920330.SGI/5.6) id AA21083; Mon, 15 Jan 96 11:26:46 GMT Date: Mon, 15 Jan 96 11:26:46 GMT From: papier@indi1.u-strasbg.fr (Laurent Papier) Message-Id: <9601151126.AA21083@indi1.u-strasbg.fr> To: amiga-gcc-port@nic.funet.fi Subject: hooks function with gcc Hi, how can I make hook function with GCC ( __saveds and register argument ) ? \|/ @ @ ------------------oOO-(_)-OOo----------------------------------------------- Laurent Papier - LSIIT - Universite Louis Pasteur - Strasbourg - FRANCE E-Mail: papier@dpt-info.u-strasbg.fr WWW: http://dpt-info.u-strasbg.fr/~papier ---------------------------------------------------------------------------- From amiga-gcc-port-owner@nic.funet.fi Tue Jan 16 13:42:46 1996 Received: from PhoneLink.COM ([193.195.138.3]) by nic.funet.fi with SMTP id <4263-1>; Tue, 16 Jan 1996 13:36:04 +0200 Received: from m500324.dev.phonelink.com by mailgate.PhoneLink.COM id aa25076; 16 Jan 96 11:29 GMT Received: by m500324.dev.phonelink.com with Microsoft Mail id <01BAE405.D9ABE300@m500324.dev.phonelink.com>; Tue, 16 Jan 1996 11:29:08 -0000 Message-ID: <01BAE405.D9ABE300@m500324.dev.phonelink.com> From: Steve Kaye To: 'Amiga GCC List' Subject: ADE, man, pdksh and emacs. Date: Tue, 16 Jan 1996 11:29:06 -0000 Encoding: 17 TEXT Hello, I have downloaded some of the files on the ADE snapshot from amigalib.com (the minimum as suggested in the readme file plus a few others like perl and emacs) I cannot find a man command. Which archive should man be in? Also I have been having problems finding out where the start files (and even what they are called) go for pdksh and emacs on the Amiga. I have tried $HOME/.profile, $HOME/.pdkshrc and other files in $HOME/. None seem to work. (I tried $HOME/ because that is where it puts .pdksh_hist) What are the files and where should they go? Thanks Steve -- SteveK@PhoneLink.com ------------ http://jumper.mcc.ac.uk/~stevek/ -- From amiga-gcc-port-owner@nic.funet.fi Tue Jan 16 19:20:40 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <4701-1361>; Tue, 16 Jan 1996 19:19:42 +0200 Received: from konrad.lysator.liu.se (actually host lysnet-gw.lysator.liu.se user root@lysnet-gw.lysator.liu.se) by funet.fi with SMTP (PP); Tue, 16 Jan 1996 18:39:22 +0200 Received: from tiny.lysator.liu.se (nisse@tiny.lysator.liu.se [130.236.253.10]) by konrad.lysator.liu.se (8.7.3/8.7.3) with ESMTP id RAA22577; Tue, 16 Jan 1996 17:39:12 +0100 (MET) Received: (nisse@localhost) by tiny.lysator.liu.se (8.6.11/8.6.11) id RAA08988; Tue, 16 Jan 1996 17:38:56 +0100 Date: Tue, 16 Jan 1996 17:38:56 +0100 Message-Id: <199601161638.RAA08988@tiny.lysator.liu.se> From: "Niels Mller" To: Steve Kaye cc: 'Amiga GCC List' In-reply-to: Steve Kaye's message of Tue, 16 Jan 1996 11:29:06 -0000 Subject: Re: ADE, man, pdksh and emacs. MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: <01BAE405.D9ABE300@m500324.dev.phonelink.com> Steve Kaye writes: > Also I have been having problems finding out where the start files (and > even what they are called) go for pdksh and emacs on the Amiga. I have > tried $HOME/.profile, $HOME/.pdkshrc and other files in $HOME/. None seem > to work. (I tried $HOME/ because that is where it puts .pdksh_hist) What > are the files and where should they go? At least with the older emacs port, .emacs is in S: . Perhaps that's worth a try? I think it's a rather logical location, at least on a single-user machine. /Niels Möller From amiga-gcc-port-owner@nic.funet.fi Tue Jan 16 19:28:08 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <4829-1361>; Tue, 16 Jan 1996 19:27:41 +0200 Received: from bastion.nmrc.ucc.ie (actually host nmrc.ucc.ie) by funet.fi with SMTP (PP); Tue, 16 Jan 1996 19:27:24 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id RAA00489 for ; Tue, 16 Jan 1996 17:25:40 GMT From: Lars Hecking Message-Id: <199601161727.RAA08255@mostar.nmrc.ucc.ie> Subject: tar, again To: amiga-gcc-port@nic.funet.fi (Amiga GCC List) Date: Tue, 16 Jan 1996 17:27:21 +0000 (GMT) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 368 GNU tar allows archiving of remote archives. The syntax conflicts with amigados device names: host:/path/to/file. Thus, full amigados path names on the command line (dhx:path/to/file) are rejected, ie. tar accepts full path names in **IX syntax only. Does the remote archive feature make any sense under amigados? If so, which syntax is used for remote files? From amiga-gcc-port-owner@nic.funet.fi Tue Jan 16 20:48:35 1996 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <4385-3094>; Tue, 16 Jan 1996 20:47:18 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tcHOm-000R9wC; Tue, 16 Jan 96 20:50 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0gqb@wyst.hobby.nl>; Tue, 16 Jan 96 19:36:12 CET Message-Id: <9601161836.0gqb@wyst.hobby.nl> Date: Tue, 16 Jan 1996 19:36:11 +0000 (CET) In-Reply-To: <199601161727.RAA08255@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jan 16, 96 05:27:21 pm Content-Type: text Content-Length: 553 From: hans@wyst.hobby.nl (Hans Verkuil) To: lhecking@nmrc.ucc.ie Cc: amiga-gcc-port@nic.funet.fi Subject: Re: tar, again Please try to remember to ask these questions on the new 'ade' mailinglist! That way we can phase out this list. Thanks in advance, Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl ixemul.library maintainer "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Tue Jan 16 21:49:39 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <4771-7016>; Tue, 16 Jan 1996 21:48:37 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tcHO6-000gXVC; Tue, 16 Jan 96 12:49 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: tar, again To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Tue, 16 Jan 1996 12:49:46 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <199601161727.RAA08255@mostar.nmrc.ucc.ie> from "Lars Hecking" at Jan 16, 96 05:27:21 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 386 > Does the remote archive feature make any sense under amigados? If so, > which syntax is used for remote files? I think it will once better networking support is available. I'd suggest something like: /dev/st0@fishpond.amigalib.com for the case of a remote tape drive on a Unix system. For a remote tape drive on another amiga it might be: tape:@fishpond.amigalib.com -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Jan 16 22:04:47 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <4544-3094>; Tue, 16 Jan 1996 22:03:54 +0200 Received: from math.uwaterloo.ca by funet.fi with SMTP (PP); Tue, 16 Jan 1996 22:03:44 +0200 Received: (from jsshephe@localhost) by math.uwaterloo.ca (8.6.12/8.6.12UW) id PAA23215; Tue, 16 Jan 1996 15:02:18 -0500 Date: Tue, 16 Jan 1996 15:02:17 -0500 (EST) From: Jeff Shepherd To: Amiga-Gcc List cc: Lars Hecking Subject: Re: tar, again In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 16 Jan 1996, Fred Fish wrote: > > Does the remote archive feature make any sense under amigados? If so, > > which syntax is used for remote files? > You could always do a sanity check on hostname (from hostname:/file/name) using gethostbyname(). If gethostbyname() fails, assume its a local filename Gethostbyname() will always fail on "non-networked" amigas. The chances are pretty low that hostname will resolve into a valid internet host when you meant a local file unless you planned it that way :) This method doesn't allow you to untar localfiles on hostname: but you can also put an assign pointing to the same place and use the assign. This argument is moot anyways until the fully-networked version of ixemul.library is available. jsshephe@undergrad.math.uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~jsshephe The world is coming to an end! Repent and return those library books. Finger me for my PGP public key. From amiga-gcc-port-owner@nic.funet.fi Wed Jan 17 02:24:29 1996 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <4868-1235>; Wed, 17 Jan 1996 02:23:06 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 17 Jan 96 01:22 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Wed, 17 Jan 96 01:17 MET Received: by rubin.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Wed, 17 Jan 96 01:17 MET Message-Id: Subject: ade-readme as html To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 17 Jan 1996 01:17:12 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 458 the ade-readme is now availabel as html. i had no time for texinfo for now, sorry. i checked with netscape & mosaic(2.4) and had no problem. because i make use of some never cmd's some older clients may have probelms. walter http://www.uni-oldenburg.de/~u173034 -- ----- "This is not my planet, I didn't choose to be here, I don't want to get involved, just get me out of here, and get me to a party with people I can relate to!" ----- From amiga-gcc-port-owner@nic.funet.fi Fri Jan 19 11:17:47 1996 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <4544-598>; Fri, 19 Jan 1996 11:10:19 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id KAA18810 (8.7.2/7.5a-FAU);; Fri, 19 Jan 1996 10:09:53 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA27263; Fri, 19 Jan 1996 10:09:49 +0100 Date: Fri, 19 Jan 1996 10:09:49 +0100 Message-Id: <9601190909.AA27263@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: ade-gcc@amigalib.com Cc: amiga-gcc-port@nic.funet.fi Subject: gcc270 ../g++-include of ADE-FF10 and aminet are different Hello, yesterday I wanted to compile some C++-stuff needed at University with gcc270 on my Amiga at home. 1.) The aminet version does not find cc1plus. After correcting this it stops after calling cc1plus. It does not call as. The gcc from ADE-FF10 runs through. 2.) The gcc270 g++-include directories are different. Only by pure chance I found ADE-FF10 aminet string string.h String.h _String.h This results in problems compiling own source files with different implementations. Bye and a nice (snowy?) weekend -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Sun Jan 21 16:54:39 1996 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with ESMTP id <4649-30765>; Sun, 21 Jan 1996 16:52:42 +0200 Received: from newzetor.clinet.fi (root@newzetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id QAA04392 for ; Sun, 21 Jan 1996 16:52:38 +0200 (EET) Received: (will@localhost) by newzetor.clinet.fi (8.7.3/8.6.4) id QAA01633; Sun, 21 Jan 1996 16:52:45 +0200 (EET) Date: Sun, 21 Jan 1996 16:52:45 +0200 (EET) Message-Id: <199601211452.QAA01633@newzetor.clinet.fi> From: Ville-Pertti Keinonen To: amiga-gcc-port@nic.funet.fi Subject: Optimizations. If there are still people interested in improving the optimizations performed by gcc, I've found some interesting information related to this (maybe somebody else doesn't know about it?). It seems gcc doesn't optimize properly for the '040 (actually it generates mostly the same code as for the '020) and there are some things that could be done for the '060 (surprisingly enough, it'll run '020 optimized code better than '040 optimized code so not much extra would need to be done). Some general information on optimization for all 68k processors can be found at: http://pirs.aus.sps.mot.com/aesop/tops/aesopT185.html (follow the link "Optimizing 680x0 Applications" under M68060/Application Support). There is a lot of other interesting information on AESOP, too, but most documents are in .pdf-format and it doesn't seem that there's an Amiga-version of the reader available anywhere. If somebody knows of any readers or programs to convert .pdf-files to other formats, please tell me where I can find them... BTW: The document on optimization states that: "Modern compilers take profiling one step further. By feeding the profiling information back into the compiler, the optimizer can use actual execution data to fine tune many optimizations, including the following:" (lists several optimizations) Does this mean GNU C isn't a modern compiler? ;--) From amiga-gcc-port-owner@nic.funet.fi Sun Jan 21 19:03:28 1996 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <4232-1398>; Sun, 21 Jan 1996 19:03:01 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Sun, 21 Jan 1996 18:02:17 +0100 (MET) From: Rask Ingemann Lambertsen To: Ville-Pertti Keinonen Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Optimizations. In-Reply-To: <199601211452.QAA01633@newzetor.clinet.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Sun, 21 Jan 1996, Ville-Pertti Keinonen wrote: > If there are still people interested in improving the optimizations > performed by gcc I am, I have just been awfully busy for some time :-( [stuff deleted] > Some general information on optimization for all 68k > processors can be found at: > http://pirs.aus.sps.mot.com/aesop/tops/aesopT185.html > (follow the link "Optimizing 680x0 Applications" under > M68060/Application Support). I will check that out if/when I find the time. There is a huge list of possible optimizations in the "ASP68K PROJECT, Sixth Edition" (it is part of the "MC680x0 Reference 1.1" ). > There is a lot of other interesting information on AESOP, too, but > most documents are in .pdf-format and it doesn't seem that there's an > Amiga-version of the reader available anywhere. If somebody knows of > any readers or programs to convert .pdf-files to other formats, please > tell me where I can find them... I have installed the HP(S)UX version of Acrobat, and it can print to a file in PostScript format, so if you can use PostScript files, I can convert them for you. pdf2html anyone? > BTW: The document on optimization states that: > > "Modern compilers take profiling one step further. By feeding the > profiling information back into the compiler, the optimizer can use > actual execution data to fine tune many optimizations, including the > following:" (lists several optimizations) > > Does this mean GNU C isn't a modern compiler? ;--) Maybe is just means that GNU C need some work in some places. It has already been pointed out, that cse.c need to find more common subexpressions to eliminate. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Jan 22 00:04:50 1996 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <4655-20484>; Mon, 22 Jan 1996 00:04:19 +0200 Received: by oersted.gbar.dtu.dk (1.37.109.15/16.2) Date: Sun, 21 Jan 1996 23:04:06 +0100 (MET) From: Rask Ingemann Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: New README for GCC 2.7.2 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I have a new README ready. Most of the changes come from a diff sent to me by Kamil Iskra. The README is available as . A diff from the previous version is available as . I have a list of people who receive the README by email. Mail me if you want to get the README by email. Should I send this message one of the ade lists too? Does Fred's releases of GCC use this README too? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Jan 22 05:42:09 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <4234-20484>; Mon, 22 Jan 1996 05:38:48 +0200 Received: from fishpond (actually host amigalib.com) by funet.fi with SMTP (PP); Mon, 22 Jan 1996 05:38:41 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0teD8i-000gXUC; Sun, 21 Jan 96 20:41 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: New README for GCC 2.7.2 To: gc948374@gbar.dtu.dk (Rask Ingemann Lambertsen) Date: Sun, 21 Jan 1996 20:41:50 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: from "Rask Ingemann Lambertsen" at Jan 21, 96 11:04:06 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 373 > Should I send this message one of the ade lists too? Does Fred's > releases of GCC use this README too? No, though I will probably incorporate parts of it into the ADE documentation before the next ADE release. Right now I'm busy upgrading all the tools to the latest versions and testing things, so I'd anticipate another general release in about 2-3 weeks. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Jan 22 10:02:02 1996 Received: from net.wau.nl ([137.224.10.12]) by nic.funet.fi with ESMTP id <5082-15572>; Mon, 22 Jan 1996 10:01:01 +0200 Received: from vines2.wau.nl by NET.WAU.NL (PMDF V4.3-10 #6821) id <01I0B0DUJ16O00GPWR@NET.WAU.NL>; Mon, 22 Jan 1996 09:07:46 +0000 (GMT) Received: by vines2.wau.nl; Mon, 22 Jan 96 9:00:43 +0100 Date: Mon, 22 Jan 1996 08:45:08 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: re: Optimizations. To: will@clinet.fi Cc: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >There is a lot of other interesting information on AESOP, too, but >most documents are in .pdf-format and it doesn't seem that there's an >Amiga-version of the reader available anywhere. If somebody knows of >any readers or programs to convert .pdf-files to other formats, please >tell me where I can find them... Have a look at Aminet the coming days, directory gfx/show. I'm going to upload the Ghostscript3.53 port to the Amiga which includes a display driver for the Amiga. The program consists of a couple of archives namely: gs353src.lha (the original GS3.53.tar.gz, 2.4Mb) gs353jpeg6.lha (the jpeg library it needs, 600Kb) gs353zlib.lha (zlib for PNG support) gs353png.lha (guess what :) ) gs353bin.lha (contains a directory with everything in it, 000/020-40sf,1.2Mb) Happy reading, Joop From amiga-gcc-port-owner@nic.funet.fi Mon Jan 22 13:01:07 1996 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <4775-1476>; Mon, 22 Jan 1996 13:00:18 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.7.1/8.7.1) id MAA22207; Mon, 22 Jan 1996 12:00:08 +0100 (MET) Date: Mon, 22 Jan 1996 12:00:08 +0100 (MET) From: Ignatios Souvatzis Message-Id: <199601221100.MAA22207@theory.cs.uni-bonn.de> To: Joop.vandeWege@MEDEW.ENTO.WAU.NL CC: will@clinet.fi, amiga-gcc-port@nic.funet.fi In-reply-to: joop van de wege's message of Mon, 22 Jan 1996 08:45:08 +0100 (CET) Subject: Optimizations. X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a; Mon, 22 Jan 1996 13:33:41 +0200 Received: from vines2.wau.nl by NET.WAU.NL (PMDF V4.3-10 #6821) id <01I0B7SEQYKG00GWHV@NET.WAU.NL>; Mon, 22 Jan 1996 12:40:20 +0000 (GMT) Received: by vines2.wau.nl; Mon, 22 Jan 96 12:33:15 +0100 Date: Mon, 22 Jan 1996 12:29:53 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: re: Optimizations. To: amiga-gcc-port@lists.funet.fi Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) >I suggest putting the zlib into a shared library which can be used by >other programs, too... something like xpkzlib.library. I had a thought of extending ObjectArchive with ZLIB read/write possibilities but the development is very quiet or has ceased to exist :( >gs would link to a stub library; gzip could do the same (I guess), as >well as png.datatype's. > Ignatios Souvatzis It could be quite some work to get GS to use the shared library. Haven't done such a thing myself so it might be easier than I think. The problem with a png.datatype is the restriction at the moment of 8bit display? Is it possible to write 24bit gfx data with datatypes ? Joop From amiga-gcc-port-owner@nic.funet.fi Tue Jan 23 17:37:20 1996 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with ESMTP id <4989-5289>; Tue, 23 Jan 1996 17:29:48 +0200 Received: from newzetor.clinet.fi (root@newzetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id RAA07817; Tue, 23 Jan 1996 17:29:34 +0200 (EET) Received: (will@localhost) by newzetor.clinet.fi (8.7.3/8.6.4) id RAA08178; Tue, 23 Jan 1996 17:29:34 +0200 (EET) Date: Tue, 23 Jan 1996 17:29:34 +0200 (EET) Message-Id: <199601231529.RAA08178@newzetor.clinet.fi> From: Ville-Pertti Keinonen To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Rask Ingemann Lambertsen on Sun, 21 Jan 1996 18:02:17 +0100 (MET)) Subject: Re: Optimizations. There is a huge list of possible optimizations in the "ASP68K PROJECT, Sixth Edition" I know them; the AESOP optimizations are quite different. The information is more like which optimizations to use for each cpu type. There are lots of optimizations that shouldn't be done for '040 or '060 targets, especially the '040, which is why an '060 target would also be nice to have in gcc. I have installed the HP(S)UX version of Acrobat, and it can print to a file in PostScript format, so if you can use PostScript files, I can convert them for you. There's not much I can do with postscript files on my current system... At the moment, I'm just about out of hd-space, so I can't really install anything larger (like a postscript-previewer). Maybe is just means that GNU C need some work in some places. It has To me it sounds more like a solution used in compilers that generally make poor optimization decisions. I was joking about GNU C not being a modern compiler. From amiga-gcc-port-owner@nic.funet.fi Tue Jan 23 17:47:36 1996 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <4996-5289>; Tue, 23 Jan 1996 17:44:09 +0200 Received: by hald.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 23 Jan 1996 16:43:27 +0100 (MET) From: Rask Ingemann Lambertsen To: Ville-Pertti Keinonen Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Optimizations. In-Reply-To: <199601231529.RAA08178@newzetor.clinet.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 23 Jan 1996, Ville-Pertti Keinonen wrote: > There is a huge list of possible optimizations in the "ASP68K PROJECT, > Sixth Edition" > > I know them; the AESOP optimizations are quite different. The > information is more like which optimizations to use for each cpu > type. There are lots of optimizations that shouldn't be done for '040 > or '060 targets, especially the '040, which is why an '060 target > would also be nice to have in gcc. I would not mind an '060 target at all. I think GCC needs to have '060 specific support, particularily since '040 optimized code won't run quickly on the '060. > Maybe is just means that GNU C need some work in some places. It has > > To me it sounds more like a solution used in compilers that generally > make poor optimization decisions. I was joking about GNU C not being > a modern compiler. Argh, I didn't realize that you were joking. Maybe a smiley (like ;-) or so) would have been in place. There is one major optimization lacking in GCC: Passing arguments in registers. GCC on the m68k looses out badly compared to other Amiga compilers when it comes to passing arguments. I'd like to see someone implementing that. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Jan 23 18:10:51 1996 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <4918-32339>; Tue, 23 Jan 1996 18:06:33 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Tue, 23 Jan 96 17:05 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Tue, 23 Jan 96 17:01 MET Received: by rubin.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Tue, 23 Jan 96 17:01 MET Message-Id: Subject: IXPIPE problems ? To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Tue, 23 Jan 1996 17:01:44 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 667 i have tried to compile gnuplot and found that the configure caused several enforcer hits while using pipes. Enforcer say IXPIPE causes the hits. i remeber that some succestet to switch to vgcc this may cause some trouble if ixpipe has problems. walter ps: can someone please mail the name of the ade-mailing list ? i lost the address :( (or set me on it) -- ----- Programmers are lousy lovers. They always try to get the job done faster than before. And when they do, they brag that they have better performance. Programmers are the only men who boast how small theirs is. // WIL BADEN ----- From amiga-gcc-port-owner@nic.funet.fi Tue Jan 23 18:29:38 1996 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with ESMTP id <4633-32339>; Tue, 23 Jan 1996 18:26:58 +0200 Received: from newzetor.clinet.fi (root@newzetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id SAA09736; Tue, 23 Jan 1996 18:26:48 +0200 (EET) Received: (will@localhost) by newzetor.clinet.fi (8.7.3/8.6.4) id SAA12989; Tue, 23 Jan 1996 18:26:48 +0200 (EET) Date: Tue, 23 Jan 1996 18:26:48 +0200 (EET) Message-Id: <199601231626.SAA12989@newzetor.clinet.fi> From: Ville-Pertti Keinonen To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Rask Ingemann Lambertsen on Tue, 23 Jan 1996 16:43:27 +0100 (MET)) Subject: Re: Optimizations. I would not mind an '060 target at all. I think GCC needs to have '060 specific support, particularily since '040 optimized code won't run quickly on the '060. It doesn't matter yet, since gcc doesn't optimize properly for the '040. Actually I think the only current difference between '020 and '040 optimized code is the fpu code. Well, at least it isn't as ridiculous as the DICE (shareware-version) '020/'030-optimization. The only difference is extw+extl -> extbl. ;--) Argh, I didn't realize that you were joking. Maybe a smiley (like ;-) or so) would have been in place. There was one. There is one major optimization lacking in GCC: Passing arguments in registers. GCC on the m68k looses out badly compared to other Amiga compilers when it comes to passing arguments. I'd like to Sometimes it can speed up operation, sometimes it slows things down. When lots of variables could be put in registers, using them to pass arguments only makes things worse. Of course if only the scratch registers (d0/d1/a0/a1) were used, it should never slow things down. From amiga-gcc-port-owner@nic.funet.fi Tue Jan 23 18:44:21 1996 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <4277-5289>; Tue, 23 Jan 1996 18:41:18 +0200 Received: by roemer.gbar.dtu.dk (1.37.109.15/16.2) Date: Tue, 23 Jan 1996 17:40:44 +0100 (MET) From: Rask Ingemann Lambertsen To: Ville-Pertti Keinonen Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Optimizations. In-Reply-To: <199601231626.SAA12989@newzetor.clinet.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 23 Jan 1996, Ville-Pertti Keinonen wrote: > Argh, I didn't realize that you were joking. Maybe a smiley (like > ;-) or so) would have been in place. > > There was one. Yes, I'm sorry. Mayby I used a narrow window that day, so I missed it. > There is one major optimization lacking in GCC: Passing arguments > in registers. GCC on the m68k looses out badly compared to other > Amiga compilers when it comes to passing arguments. I'd like to > > Sometimes it can speed up operation, sometimes it slows things down. > When lots of variables could be put in registers, using them to pass > arguments only makes things worse. Of course if only the scratch > registers (d0/d1/a0/a1) were used, it should never slow things down. If the compiler is smart enough when allocating registers then passing arguments in registers will be much faster. It also decreases the code size because it doesn't have to output instructions to push and pop arguments. Alone the fewer memory accesses should speed things up a lot. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Jan 24 09:58:23 1996 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <4595-834>; Wed, 24 Jan 1996 03:08:54 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 24 Jan 96 02:08 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Wed, 24 Jan 96 02:01 MET Received: by rubin.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Wed, 24 Jan 96 02:01 MET Message-Id: Subject: possible bug with -68881 To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 24 Jan 1996 02:01:41 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 490 problem with gcc270 i have just tried to compiled gnuplot with gcc and found that atleast one functions is broken when compiled with -68030 -68881. i have contacted the authors for help to locate the bug. i will download the latest version of gcc sone as possible to see if the bug is also in the beta-gcc. everybody using -68881 -68030 should be carefull there maybe bug somewhere ! walter -- ----- "An apple a day keeps the... No, never mind!" --The Doctor. ----- From amiga-gcc-port-owner@nic.funet.fi Wed Jan 24 21:31:12 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <3340-3967>; Wed, 24 Jan 1996 21:29:20 +0200 Received: from ernie.icslab.agh.edu.pl by funet.fi with SMTP (PP); Wed, 24 Jan 1996 11:33:08 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA03034; Wed, 24 Jan 1996 10:28:30 +0100 Date: Wed, 24 Jan 1996 10:28:30 +0100 (MET) From: Kamil Iskra To: ade-projects@amigalib.com cc: Amiga GCC List , fnf@amigalib.com, phb@colombo.telesys-innov.fr, gnikl@informatik.uni-rostock.de Subject: New fd2inline Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII New version of fd2inline is now available on my WWW homepage. It has also been uploaded to ftp.amigalib.com and colombo.telesys-innov.fr. I would like to thank Gunther Nikl for his bug reports and suggestions. The following changes were made: - "inline/*" macros no longer supply library base types as arguments to LPX() macros: library base pointers can be of any type, they are explicitly cast to "struct Library*" inside LPX() macros. This results in smaller "inline/*" files and better compatibility with other Amiga compilers. Special care has been taken to preserve 100% compatibility with previous versions of "inline/*" files - that's why LPX() macros still have "bt" argument and "inline" macros pass one empty value to LPX(). - __CONSTLIBBASEDECL__ is now empty by default, ie. you have to redefine it to "const" to get the best possible code. This modification was necessary because reading contents of const-declared objects always results in absolute addressing, even in base relative code, in which it can cause severe problems. Besides, this prevents compiler from issueing warning messages about modifications of const objects. - "inline/macros.h" had a mistake in definition of LP7NR() macro, what resulted in compiler error message if 7-arguments void-return function was called. - Source files parser had problems with lines containing tailing spaces. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Jan 24 21:33:22 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <3518-3967>; Wed, 24 Jan 1996 21:32:25 +0200 Received: from ernie.icslab.agh.edu.pl by funet.fi with SMTP (PP); Wed, 24 Jan 1996 14:07:47 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA06899; Wed, 24 Jan 1996 13:09:02 +0100 Date: Wed, 24 Jan 1996 13:09:02 +0100 (MET) From: Kamil Iskra To: Rask Ingemann Lambertsen cc: Ville-Pertti Keinonen , amiga-gcc-port@nic.funet.fi Subject: Re: Optimizations. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 23 Jan 1996, Rask Ingemann Lambertsen wrote: > > Sometimes it can speed up operation, sometimes it slows things down. > > When lots of variables could be put in registers, using them to pass > > arguments only makes things worse. Of course if only the scratch > > registers (d0/d1/a0/a1) were used, it should never slow things down. > > If the compiler is smart enough when allocating registers then passing > arguments in registers will be much faster. But, as we know, GCC is not smart enough ("spilled register" problem). IMHO, treating passing arguments in register as a great idea is very dangerous. See for example AmigaOS calling conventions - every compiler has to provide its own methods of arguments passing (pragmas, inlines - whatever you call them), usually different compilers are incompatible in this matter. Porting compilers from other platforms becomes harder and writing compilers too (it's much harder to pass arguments in registers than on stack). Programs become incompatible - tell me, how hooks are supposed to work on PowerPC? Will there be a mapping between m68k and PowerPC registers? I really hope that AT will back off from this brain-damage idea and arguments on PowerPC OS will be passed on stack, as in most other OSes. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Jan 24 21:34:12 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <3600-3966>; Wed, 24 Jan 1996 21:33:07 +0200 Received: from pobox.csc.fi by funet.fi with SMTP (PP); Wed, 24 Jan 1996 14:33:18 +0200 Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.161]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id MAA19766 for ; Wed, 24 Jan 1996 12:28:07 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.7.1/8.7.1) id NAA00330; Wed, 24 Jan 1996 13:22:18 +0100 (MET) Date: Wed, 24 Jan 1996 13:22:18 +0100 (MET) From: Ignatios Souvatzis Message-Id: <199601241222.NAA00330@theory.cs.uni-bonn.de> To: will@clinet.fi CC: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-reply-to: Ville-Pertti Keinonen's message of Tue, 23 Jan 1996 18:26:48 +0200 (EET) <199601231626.SAA12989@newzetor.clinet.fi> Subject: Optimizations. X-mailer: GNU Emacs 18.59.9 X-face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a It doesn't matter yet, since gcc doesn't optimize properly for the '040. Actually I think the only current difference between '020 and '040 optimized code is the fpu code. Well, at least it isn't as ridiculous as the DICE (shareware-version) '020/'030-optimization. The only difference is extw+extl -> extbl. ;--) This is only true for the intermediate assembler sources. The assembler defines extbl as a macro which generates extw+extl. Yes, this is in the last registered version I could get. A 060 compiler, btw, would have to replace a couple of opcodes by library calls, most of them floating point, but some integer operations are there, as well (e.g., the 64bit mul/div instructions). While the 68060 support package should be installed in the system and emulate the instructions, it is more effective to just call a function and avoid the pipeline flushing and opcode decoding necessary for/in the exception. Regards, Ignatios Souvatzis From amiga-gcc-port-owner@nic.funet.fi Wed Jan 24 22:42:57 1996 Received: from arbi.informatik.uni-oldenburg.de ([134.106.1.7]) by nic.funet.fi with SMTP id <2348-3968>; Wed, 24 Jan 1996 22:41:37 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Wed, 24 Jan 96 21:40 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Wed, 24 Jan 96 21:37 MET Received: by rubin.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Wed, 24 Jan 96 21:37 MET Message-Id: Subject: Re: possible bug with -68881 (fwd) To: amiga-gcc-port@lists.funet.fi (amiga gcc-list) Date: Wed, 24 Jan 1996 21:37:51 +0100 (MET) From: Walter Harms X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1158 Forwarded message: > From arbi.informatik.uni-oldenburg.de!hgatenl.hobby.nl!wyst.hobby.nl!hans Wed Jan 24 21:20:10 1996 > Message-Id: <9601241828.0hm3@wyst.hobby.nl> > Date: Wed, 24 Jan 1996 19:28:18 +0000 (CET) > In-Reply-To: from "Walter Harms" at Jan 24, 96 02:01:41 am > Content-Type: text > Content-Length: 1258 > From: hans@wyst.hobby.nl (Hans Verkuil) > To: Walter.Harms@arbi.informatik.uni-oldenburg.de > Subject: Re: possible bug with -68881 > > > everybody using -68881 -68030 should be carefull > > there maybe bug somewhere ! > > Please post this report on the ade-mailinglists! The amiga-gcc mailinglist > is no longer supported! > i will switch i hope thats the last msg here :) > Also, please try to figure out first *which* math operation is broken. > General messages like the one above are almost useless. I know it takes i know this it was not intended as bug report more as warning. the gnuplot-ppl are informt and i ask for a test-code because the code is huge and there is no hint what goes wrong. walter -- ----- "I prefer to put my faith in the mind probe!" ----- From amiga-gcc-port-owner@nic.funet.fi Thu Jan 25 16:34:13 1996 Received: from mail.medianet.de ([194.97.134.1]) by nic.funet.fi with SMTP id <10204-27565>; Thu, 25 Jan 1996 16:30:00 +0200 Received: from GWEU.softlab.de ([141.77.249.1]) by mail.medianet.de (8.6.12/8.6.12) with SMTP id PAA09231 for ; Thu, 25 Jan 1996 15:16:50 +0100 From: SMH@softlab.de Message-Id: <9601251411.AA16115@GWEU.softlab.de> Received: from AA by GWEU.softlab.de with SMTP (5.65/GEN-1.1.8) via EUnet for [194.97.134.1] id AA16115; Thu, 25 Jan 96 15:11:52 +0100 Received: from H8 by softlab.de with SMTP (1.37.109.4/16.2) id AA09298; Thu, 25 Jan 96 15:20:39 +0100 Received: by H8 (1.37.109.4/16.2) id AA06504; Thu, 25 Jan 96 15:20:15 +0100 Date: Thu, 25 Jan 96 15:20:15 +0100 To: amiga-gcc-port@nic.funet.fi Subject: ADE mailing list Hi everybody, I missed the discussion about the new ADE mailing list. Can a kind soul please tell me, how to subscribe to this list ? Thanks, Hans From amiga-gcc-port-owner@nic.funet.fi Thu Jan 25 18:07:32 1996 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with ESMTP id <9935-24203>; Thu, 25 Jan 1996 18:05:58 +0200 Received: from newzetor.clinet.fi (root@newzetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id SAA15141; Thu, 25 Jan 1996 18:05:35 +0200 (EET) Received: (will@localhost) by newzetor.clinet.fi (8.7.3/8.6.4) id SAA05572; Thu, 25 Jan 1996 18:05:35 +0200 (EET) Date: Thu, 25 Jan 1996 18:05:35 +0200 (EET) Message-Id: <199601251605.SAA05572@newzetor.clinet.fi> From: Ville-Pertti Keinonen To: gc948374@gbar.dtu.dk CC: amiga-gcc-port@nic.funet.fi In-reply-to: (message from Rask Ingemann Lambertsen on Tue, 23 Jan 1996 17:40:44 +0100 (MET)) Subject: Re: Optimizations. If the compiler is smart enough when allocating registers then passing arguments in registers will be much faster. It also decreases the code Not if variables of the caller that should/could be in registers need to be stored on stack or pushed on the stack for the duration of the call. size because it doesn't have to output instructions to push and pop arguments. Alone the fewer memory accesses should speed things up a lot. If calling a function is that speed-critical, it should probably be inlined. From amiga-gcc-port-owner@nic.funet.fi Thu Jan 25 18:31:45 1996 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with ESMTP id <10080-24203>; Thu, 25 Jan 1996 18:31:00 +0200 Received: from newzetor.clinet.fi (root@newzetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id SAA15717; Thu, 25 Jan 1996 18:27:57 +0200 (EET) Received: (will@localhost) by newzetor.clinet.fi (8.7.3/8.6.4) id SAA06215; Thu, 25 Jan 1996 18:27:57 +0200 (EET) Date: Thu, 25 Jan 1996 18:27:57 +0200 (EET) Message-Id: <199601251627.SAA06215@newzetor.clinet.fi> From: Ville-Pertti Keinonen To: ignatios@cs.uni-bonn.de CC: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-reply-to: <199601241222.NAA00330@theory.cs.uni-bonn.de> (message from Ignatios Souvatzis on Wed, 24 Jan 1996 13:22:18 +0100 (MET)) Subject: Re: Optimizations. A 060 compiler, btw, would have to replace a couple of opcodes by library calls, most of them floating point, but some integer operations are there, as well (e.g., the 64bit mul/div instructions). Yep, the emulation for those is rather slow when it is done through exceptions. That's why the 060sp includes the ilsp and fplsp library-versions of the emulation functions. I wonder if they are much faster than the ones normally used by gcc for software implementation. I would guess that at least ilsp is faster, except for cases where gcc would use optimized inline code. While the 68060 support package should be installed in the system and emulate the instructions, it is more effective to just call a function and avoid the pipeline flushing and opcode decoding necessary for/in the exception. What scares me is quads slowing down *really* badly for 020/040-compiled code; they are fast on other processors. Oh well, hopefully the speed of the '060 otherwise compensates for that, since I should be getting an '060 soon. ;--) From amiga-gcc-port-owner@nic.funet.fi Thu Jan 25 21:08:14 1996 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <9952-27565> convert rfc822-to-8bit; Thu, 25 Jan 1996 21:07:05 +0200 Received: by hald.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 25 Jan 1996 20:06:32 +0100 (MET) From: Rask Ingemann Lambertsen To: Kamil Iskra Cc: amiga-gcc-port@nic.funet.fi Subject: Re: README-2.7.2 patches In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 24 Jan 1996, Kamil Iskra wrote: > If I remember correctly, a few days ago you posted information about new > version of README, which includes patches that I have suggested. > > I just had a look at README-2.7.2 at you homepage and saw with surprise > that "inline headers" section was not modified. Have you not received > patches that I sent you? Or maybe new file is named somewhat differently > (sorry, I deleted your posting)? I somehow forgot to copy the new README to README-2.7.2 :-( It is fixed now. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Jan 25 21:46:25 1996 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <9847-24203> convert rfc822-to-8bit; Thu, 25 Jan 1996 21:45:35 +0200 Received: by hald.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 25 Jan 1996 20:44:25 +0100 (MET) From: Rask Ingemann Lambertsen To: Kamil Iskra Cc: Ville-Pertti Keinonen , amiga-gcc-port@nic.funet.fi Subject: Re: Optimizations. In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 24 Jan 1996, Kamil Iskra wrote: > On Tue, 23 Jan 1996, Rask Ingemann Lambertsen wrote: > > > > Sometimes it can speed up operation, sometimes it slows things down. > > > When lots of variables could be put in registers, using them to pass > > > arguments only makes things worse. Of course if only the scratch > > > registers (d0/d1/a0/a1) were used, it should never slow things down. > > > > If the compiler is smart enough when allocating registers then passing > > arguments in registers will be much faster. > > But, as we know, GCC is not smart enough ("spilled register" problem). > > IMHO, treating passing arguments in register as a great idea is very > dangerous. See for example AmigaOS calling conventions - every compiler > has to provide its own methods of arguments passing (pragmas, inlines - > whatever you call them), usually different compilers are incompatible in > this matter. Would it be more that luck if they use compatible stack passing convetions? The compiler doesn't have to put arguments on the stack in any particular order, AFAIK. I think I need to point out that I am not looking for a way of putting the arguments in *specific* registers, but just have the arguments passing in registers that the compiler choose. > Porting compilers from other platforms becomes harder and > writing compilers too (it's much harder to pass arguments in registers > than on stack). You always have to port the code to generate a funtion call and a function entry and exit, unless it has been done already for your CPU. > Programs become incompatible Incomaptible just because the compiler passes arguments in register instead of on the stack? You'll have to explaing that better to me. I'm only talking about function calls within the programme itself. > - tell me, how hooks are > supposed to work on PowerPC? Will there be a mapping between m68k and > PowerPC registers? I thought that was obvious. > I really hope that AT will back off from this > brain-damage idea and arguments on PowerPC OS will be passed on stack, as > in most other OSes. I can't say that I agree with you. Using the stack has it's performance problems. Also, I don't care what other OS'es do. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Jan 25 21:47:45 1996 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <9808-27565>; Thu, 25 Jan 1996 21:47:29 +0200 Received: by hald.gbar.dtu.dk (1.37.109.15/16.2) Date: Thu, 25 Jan 1996 20:47:00 +0100 (MET) From: Rask Ingemann Lambertsen To: Ignatios Souvatzis Cc: will@clinet.fi, amiga-gcc-port@nic.funet.fi Subject: Re: Optimizations. In-Reply-To: <199601241222.NAA00330@theory.cs.uni-bonn.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 24 Jan 1996, Ignatios Souvatzis wrote: > A 060 compiler, btw, would have to replace a couple of opcodes by > library calls, most of them floating point, but some integer > operations are there, as well (e.g., the 64bit mul/div instructions). > While the 68060 support package should be installed in the system and > emulate the instructions, it is more effective to just call a function > and avoid the pipeline flushing and opcode decoding necessary for/in > the exception. It is even more efficient to use the instructions available on the '060 instead of calling emulation libraries in one way or the other. That is why I want to see '060 support. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Jan 26 15:42:57 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <10037-6117>; Fri, 26 Jan 1996 15:40:39 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id OAA22269; Fri, 26 Jan 1996 14:42:15 +0100 Date: Fri, 26 Jan 1996 14:42:15 +0100 (MET) From: Kamil Iskra To: Rask Ingemann Lambertsen cc: amiga-gcc-port@nic.funet.fi Subject: Re: Optimizations. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 25 Jan 1996, Rask Ingemann Lambertsen wrote: > On Wed, 24 Jan 1996, Kamil Iskra wrote: > > IMHO, treating passing arguments in register as a great idea is very > > dangerous. See for example AmigaOS calling conventions - every compiler > > has to provide its own methods of arguments passing (pragmas, inlines - > > whatever you call them), usually different compilers are incompatible in > > this matter. > > Would it be more that luck if they use compatible stack passing > convetions? The compiler doesn't have to put arguments on the stack in > any particular order, AFAIK. Doesn't have to, but common sense suggests that it will either put them from first argument to last or vice versa. If you also consider "varargs" functions, only second solution (from last to first) is easy to implement on m68k. Now think about register calling conventions. You've got 16 of them on m68k - is there any obvious solution? > > Porting compilers from other platforms becomes harder and > > writing compilers too (it's much harder to pass arguments in registers > > than on stack). > > You always have to port the code to generate a funtion call and a > function entry and exit, unless it has been done already for your CPU. But implementing stack-based function calls is much simpler! You just have to put all arguments on stack and make a call. If one of the arguments is a function call, you can just call it in the same way. This simple algorithm won't work in case of register-arguments. What if for example compiler has already put one argument in "a1" and it suddenly finds out that evaluation of second argument will require usage of the same "a1" register? Compiler has to be much smarter and, I'll repeat it, GCC is not that smart. > > Programs become incompatible > > Incomaptible just because the compiler passes arguments in register > instead of on the stack? You'll have to explaing that better to me. > I'm only talking about function calls within the programme itself. Well, maybe we haven't understood each other very well. I was talking about incompatibilities in case of direct specification of registers, as required for hooks, RawDoFmt() and so on. But when I think more about it, I can also defend the point about incompatibilities caused just by another calling convention. I know it in practise, since I have SAS/C. As you most probably know, this compiler has support for registers-based calling convention. It works by passing two first pointer arguments in A0/A1 and two first integers in D0/D1 - the rest of arguments are passed on stack. Compiler uses different mangling algorithm to distinguish register calls from stack calls. Everything works fine as long as you use SAS/C specific libraries, which have support for both register and stack calls. But CBM "amiga.lib" has only stack-calls support, so you can't call functions from this library when you use register calls (or, more precisely, you can call them, but you have to alter standard system headers to explicitly demand stack-argument passing). Do you think this is nice, easy and portable? > > - tell me, how hooks are > > supposed to work on PowerPC? Will there be a mapping between m68k and > > PowerPC registers? > > I thought that was obvious. Obvious? So tell me, how exactly it will be made? Will a0 or d0 be mapped as PowerPC register 0? Or maybe as PowerPC register 18? Is it so obvious? We heard that AT is going to port AmigaOS to many platforms, PowerPC-based being the first. So what about other CPUs? Will AT make "obvious" mapping for each of them? What is really obvious is using stack! > > I really hope that AT will back off from this > > brain-damage idea and arguments on PowerPC OS will be passed on stack, as > > in most other OSes. > > I can't say that I agree with you. Using the stack has it's performance > problems. Start writing your programs in assembler, if you care so much about a few more instructions for every function. Do you make animations using WritePixel() that you care about small calling overhead so much or what? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Jan 26 19:42:27 1996 Received: from bohr.gbar.dtu.dk ([130.225.87.176]) by nic.funet.fi with ESMTP id <9985-8873> convert rfc822-to-8bit; Fri, 26 Jan 1996 19:37:57 +0200 Received: by bohr.gbar.dtu.dk (1.37.109.15/16.2) Date: Fri, 26 Jan 1996 18:37:19 +0100 (MET) From: Rask Ingemann Lambertsen To: Kamil Iskra Cc: amiga-gcc-port@nic.funet.fi Subject: Re: Optimizations. In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Fri, 26 Jan 1996, Kamil Iskra wrote: > On Thu, 25 Jan 1996, Rask Ingemann Lambertsen wrote: > > > Would it be more that luck if they use compatible stack passing > > convetions? The compiler doesn't have to put arguments on the stack in > > any particular order, AFAIK. > > Doesn't have to, but common sense suggests that it will either put them > from first argument to last or vice versa. If you also consider "varargs" > functions, only second solution (from last to first) is easy to implement > on m68k. There is also the question of whether byte and word arguments are passed as long values or not. > Now think about register calling conventions. You've got 16 of them on > m68k - is there any obvious solution? Absolutely. Put non-pointer arguments into data registers starting from D0. Put pointer arguments into address registers starting from A0. If you run out of data registers for non-pointer arguments, use the first available address register. If you run out of address registers for pointer arguments, use the first available data register. If you run out of registers, there are two options: 1) Pass as many arguments as possible in registers and the rest on the stack. 2) Pass all the arguments on the stack. For varargs functions, pass all the arguments on the stack. > > > Porting compilers from other platforms becomes harder and > > > writing compilers too (it's much harder to pass arguments in registers > > > than on stack). > > > > You always have to port the code to generate a funtion call and a > > function entry and exit, unless it has been done already for your CPU. > > But implementing stack-based function calls is much simpler! You just have > to put all arguments on stack and make a call. If one of the arguments is > a function call, you can just call it in the same way. This simple > algorithm won't work in case of register-arguments. Actually, it *will* work as long as you have only register based calls or stack based calls. > What if for example > compiler has already put one argument in "a1" and it suddenly finds out > that evaluation of second argument will require usage of the same "a1" > register? Compiler has to be much smarter and, I'll repeat it, GCC is not > that smart. I agree with you that GCC isn't smart at all when choosing registers. But on the M68k, such a situation as the one you describe is unlikely, if even possible, as the M68k doesn't use implicit register addressesing except with A7, which you can't use for passing arguments anyway. Or did I totally misunderstand you? > > > Programs become incompatible > > > > Incomaptible just because the compiler passes arguments in register > > instead of on the stack? You'll have to explaing that better to me. > > I'm only talking about function calls within the programme itself. > > Well, maybe we haven't understood each other very well. I was talking > about incompatibilities in case of direct specification of registers, as > required for hooks, RawDoFmt() and so on. > Compiler uses different mangling > algorithm to distinguish register calls from stack calls. Everything works > fine as long as you use SAS/C specific libraries, which have support for > both register and stack calls. But CBM "amiga.lib" has only stack-calls > support, so you can't call functions from this library when you use > register calls (or, more precisely, you can call them, but you have to > alter standard system headers to explicitly demand stack-argument > passing). Do you think this is nice, easy and portable? Nope, but this isn't an issue for me since I don't use libraries or object files from other compilers with GCC. And your programmes can be converted from register based calls to stack based calls (and vice versa) just by recompiling, which you'll most like have to do anyway. > > > - tell me, how hooks are > > > supposed to work on PowerPC? Will there be a mapping between m68k and > > > PowerPC registers? > > > > I thought that was obvious. > > Obvious? So tell me, how exactly it will be made? Will a0 or d0 be mapped > as PowerPC register 0? Or maybe as PowerPC register 18? Is it so obvious? Map D0-D7 to PPC register 0-7, map A0-A6 to PPC register 8-14 and A7 into the stack pointer of the PPC. If the PPC doesn't have a decicated stack pointer, use PPC register 15 for A7. > We heard that AT is going to port AmigaOS to many platforms, PowerPC-based > being the first. So what about other CPUs? Will AT make "obvious" mapping > for each of them? As long as it has at least as many register as the M68k, it should be about as obvious as with the PPC. If we can assume that Amiga OS will only be ported to RISC processors, this isn't a problem since they generally have lots of registers. > What is really obvious is using stack! Not any more obvious than using registers. You have to decide in which order to pass the arguments and you have to decide whether or not you want to push all the arguments as long ints or not. > > I can't say that I agree with you. Using the stack has it's performance > > problems. > > Start writing your programs in assembler, if you care so much about a few > more instructions for every function. Do you make animations using > WritePixel() that you care about small calling overhead so much or what? No, do you? What I want is efficient code and preferably also small code. Passing arguments in registers doesn't give that. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@gbar.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Jan 26 20:38:16 1996 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with ESMTP id <9705-8873>; Fri, 26 Jan 1996 20:37:18 +0200 Received: from newzetor.clinet.fi (root@newzetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id UAA22548; Fri, 26 Jan 1996 20:35:01 +0200 (EET) Received: (will@localhost) by newzetor.clinet.fi (8.7.3/8.6.4) id UAA25550; Fri, 26 Jan 1996 20:35:03 +0200 (EET) Date: Fri, 26 Jan 1996 20:35:03 +0200 (EET) Message-Id: <199601261835.UAA25550@newzetor.clinet.fi> From: Ville-Pertti Keinonen To: gc948374@gbar.dtu.dk CC: kiskra@ernie.icslab.agh.edu.pl, amiga-gcc-port@nic.funet.fi In-reply-to: (message from Rask Ingemann Lambertsen on Fri, 26 Jan 1996 18:37:19 +0100 (MET)) Subject: Re: Optimizations. Absolutely. Put non-pointer arguments into data registers starting from D0. Put pointer arguments into address registers starting from A0. If you run out of data registers for non-pointer arguments, use the first available address register. If you run out of address registers for pointer arguments, use the first available data register. If you run out of registers, there are two options: 1) Pass as many arguments as possible in registers and the rest on the stack. 2) Pass all the arguments on the stack. Have you actually thought about the implementation? It would be possible, but not very efficient. The code size would be increased if you have optional stack and register entry points for calls and you always have a problem when the function being called doesn't want to run with the arguments in registers but place completely different variables in registers. The caller might have to sacrifice or push its registers (unless only d0-d1/a0-a1 are used) in order to pass arguments after which the called function places them on the stack, which is much less efficient than passing arguments on stack. Also if the argument varibles aren't used much; other variables are, but not to the extent that the compiler would place them on stack, the function needs to push stuff on the stack *because* it received its arguments in registers; otherwise it would have left the arguments on stack and used registers for other variables. It gets even worse if the function calls other functions... Passing arguments in registers isn't always beneficial. The only case in which it registerized arguments are always usable is when calling functions with few arguments and that don't place any variables on stack or call other functions. Usually such functions are small and as I said earlier, might as well be inlined in speed-critical places. When they aren't quite that small is when I wish I could specify registerized arguments for *that specific function*. But not all code, it can hurt performance instead of improving it in too many cases. Oh, not to mention that full prototypes are required to determine which registers are used, traditional C won't work at all. The realization that registerized arguments aren't really worth the trouble is one of the reasons I gave up writing my own C-compiler (I actually got quite far in the basic part, maybe I'll continue with the project some day) and switched to gcc (which I had feared, in part due to the lack of registerized arguments). I would have had a *lot* of work before the optimizations would be anywhere near the level of gcc, so I'm rather satisfied now that I use gcc and can do so on several platforms and operating systems. From amiga-gcc-port-owner@nic.funet.fi Tue Jan 30 11:03:44 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <8166-21228>; Mon, 29 Jan 1996 18:21:40 +0200 Received: from k332.feld.cvut.cz by funet.fi with SMTP (PP); Mon, 29 Jan 1996 18:20:27 +0200 Received: (from mj@localhost) by k332.feld.cvut.cz (8.6.12/8.6.9) id RAA10435 for amiga-gcc-port@nic.funet.fi; Mon, 29 Jan 1996 17:18:47 +0100 From: Martin Mares Message-Id: <199601291618.RAA10435@k332.feld.cvut.cz> Subject: Re: Optimizations. To: amiga-gcc-port@nic.funet.fi Date: Mon, 29 Jan 1996 17:18:47 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6063 Hello, world! > Have you actually thought about the implementation? It would be > possible, but not very efficient. The code size would be increased if > you have optional stack and register entry points for calls and you In usual cases, two entry points would be unnecessary. IMHO the only place two entry points are required are libraries indended to work with both models of argument passing. > always have a problem when the function being called doesn't want to > run with the arguments in registers but place completely different > variables in registers. The caller might have to sacrifice or push > its registers (unless only d0-d1/a0-a1 are used) in order to pass > arguments after which the called function places them on the stack, > which is much less efficient than passing arguments on stack. Also if > the argument varibles aren't used much; other variables are, but not > to the extent that the compiler would place them on stack, the > function needs to push stuff on the stack *because* it received its > arguments in registers; otherwise it would have left the arguments on > stack and used registers for other variables. It gets even worse if > the function calls other functions... I think it isn't good to use _all_ registers for argument passing -- the better way would be to use for example D0-D3 and A0-A3 for argument passing and the rest _always_ for register variables. This would help a lot in functions with small number of parameters (at least in my sources most functions take maximally 3 parameters). If the function uses lots of local variables much more than the parameters, the compiler stores the parameters to the stack, which doesn't hurt too much, because many cases of parameter passing are of a register->stack->(call)->...->register type which would give register->(call)->stack->...->register instead which is not significantly worse. The other case is constant->stack->(call)->...->register which would give constant->register->(call)->stack->...->register which is only slightly worse (by single move from reg. to stack). In addition to this, many complex functions requiring lots of registers use some of their arguments only at their beginning which again doesn't need any stack shuffling. (It's going to be confusing!) > Passing arguments in registers isn't always beneficial. The only case > in which it registerized arguments are always usable is when calling > functions with few arguments and that don't place any variables on > stack or call other functions. Usually such functions are small and > as I said earlier, might as well be inlined in speed-critical places. I don't think so. As you can see above, many functions using register variables are not slowed down by register parameter passing. And lots of functions use only few arguments, but do lots of complex things with them, so it isn't good to inline them, but the usual code path is short enough to be improved significantly by using register arguments. A typical example of such a function is a relatively simple-minded function containing one large switch statement with lots of branches for various parameter values. > When they aren't quite that small is when I wish I could specify > registerized arguments for *that specific function*. But not all > code, it can hurt performance instead of improving it in too many > cases. I suggest introducing two compiler options: (1) A global parameter passing convention switch: if switched off, all functions would have standard on-stack parameters except for cases where the programmer forces register arguments by specifying a function attribute. If switched on, all functions would use register arguments by default, allowing stack arguments to be forced by an attribute. (2) Another global parameter forcing the compiler to produce a secondary entry with on-stack parameters for all functions with parameters in registers except when the function is declared as static. This global setting should be also modifiable locally via a function attribute. In addition to this, I suggest the following parameter allocation scheme to be used: Use only D0-D3 and A0-A3 for arguments. Store address arguments to address registers, non-address arguments to data registers. When no register of specified type is used, delay the allocation to the second pass. In the second pass, try to allocate registers of the other type to all remaining parameters. If even this doesn't suffice, pass the remaining parameters on the stack. The usual single-pass convention is much simpler, but produces worse results than the two-pass one. Imagine a function with lots of non-address parameters and one address parameter at the end. The single-pass method would allocate all data registers for data, all address registers for data and pass the remaining data and the address on the stack. The two-pass method passes the address in an address register, the data in both data and address registers and on the stack, which is probably better. (Maybe the register allocation limit (4 data, 4 address registers) should be also settable via a compiler option.) > Oh, not to mention that full prototypes are required to determine > which registers are used, traditional C won't work at all. This is true, but it is not so bad as it sounds. If you have a traditional K&R source, you can compile it with stack-based arguments enabled. When you will think register parameters would improve the performance a lot, you can always generate the prototypes by some tool and switch the register passing convention on. I have tried to measure the performance difference between register and stack parameters in SAS/C which supports both models. In all the test cases, the code using register passing was significantly faster and shorter (even on such a complex program like my own implementation of TeX). Another thing I remember is I have never seen an assembly program optimized strongly for speed which would use on-stack parameters. Have a nice day Martin Mares From amiga-gcc-port-owner@nic.funet.fi Wed Jan 31 20:52:58 1996 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with ESMTP id <4483-5577>; Wed, 31 Jan 1996 20:47:17 +0200 Received: from newzetor.clinet.fi (root@newzetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id UAA05491; Wed, 31 Jan 1996 20:46:50 +0200 (EET) Received: (will@localhost) by newzetor.clinet.fi (8.7.3/8.6.4) id UAA08710; Wed, 31 Jan 1996 20:46:59 +0200 (EET) Date: Wed, 31 Jan 1996 20:46:59 +0200 (EET) Message-Id: <199601311846.UAA08710@newzetor.clinet.fi> From: Ville-Pertti Keinonen To: mj@k332.feld.cvut.cz CC: amiga-gcc-port@nic.funet.fi In-reply-to: <199601291618.RAA10435@k332.feld.cvut.cz> (message from Martin Mares on Mon, 29 Jan 1996 17:18:47 +0100 (MET)) Subject: Re: Optimizations. In usual cases, two entry points would be unnecessary. IMHO the only place two entry points are required are libraries indended to work with both models of argument passing. That would force using the registers for every call, which could mess up the optimization of complex calculations that could take advantage of a large number of registers. I think it isn't good to use _all_ registers for argument passing -- the better way would be to use for example D0-D3 and A0-A3 for argument That can already cost some functions four registerized variables when a function with lots of arguments is called. variables much more than the parameters, the compiler stores the parameters to the stack, which doesn't hurt too much, because many cases of parameter passing are of a register->stack->(call)->...->register type which would give register->(call)->stack->...->register instead which is not significantly worse. The other case is constant->stack->(call)->...->register which would give constant->register->(call)->stack->...->register which is only slightly worse (by single move from reg. to stack). In addition to What about the case of calling other functions? Part of the registers used for arguments need to be pushed on the stack or moved to other registers. And there can still be loss due to the compiler preferring to keep the arguments in registers instead of other variables. I don't think so. As you can see above, many functions using register variables are not slowed down by register parameter passing. And lots of Normally register parameters probably speed up average performance, but it's the most complex parts (the parts using the most registers and losing the most if the registerized variables aren't chosen properly) that might suffer. The usual single-pass convention is much simpler, but produces worse results than the two-pass one. Imagine a function with lots of non-address parameters and one address parameter at the end. The single-pass method would allocate all data registers for data, all address registers for data and pass the remaining data and the address on the stack. The two-pass method passes the address in an address register, the data in both data and address registers and on the stack, which is probably better. It might be even better to "give up" if there are more arguments than can be passed in registers and just pass everything on the stack. BTW: How would floats/doubles/quads/structures be passed? (Maybe the register allocation limit (4 data, 4 address registers) should be also settable via a compiler option.) As if registerized arguments don't produce enough linkage problems as is. How many people use stack-based arguments and rtd for all C-code compiled for a 68010+? Probably nobody. Like registerized arguments, it would require the recompilation of all linked libraries. will think register parameters would improve the performance a lot, you can always generate the prototypes by some tool and switch the register passing convention on. I used to do that all the time with DICE, only generating the prototypes isn't always easy, especially with larger programs or when you want to do it neatly. I have tried to measure the performance difference between register and stack parameters in SAS/C which supports both models. In all the test cases, the code using register passing was significantly faster and shorter (even on such a complex program like my own implementation of TeX). AFAIK SAS/C has quite a different approach to optimization than GNU C. In several cases, GNU C does a better job optimizing (however, I don't know what options were used for SAS/C), eg. I recompiled some version of djpeg that was distributed compiled using SAS/C (probably with lots of optimizations enabled, since there were separate '000 and '020 versions), the gcc-compiled version was faster, I don't remember by how much. But in any case, I have no idea if the SAS/C compiled version of that had register argument passing enabled, I didn't bother to disassemble it. How much is the difference in performance between SAS/C vs. SAS/C programs with registerized vs. stacked arguments? "Significantly" faster doesn't really mean anything, it could mean anything from 5% to 50%... Another thing I remember is I have never seen an assembly program optimized strongly for speed which would use on-stack parameters. Neither have I, it seems more common that they don't have any fixed argument passing conventions or register-preservation rules, anyhow. But things optimized really strongly for speed (to the extent of overkill) aren't very common and almost non-existent in portable C-code (well, the glibc implementation of memchr/strchr etc. is an exception). From amiga-gcc-port-owner@nic.funet.fi Thu Feb 1 00:15:06 1996 Received: from konrad.lysator.liu.se ([130.236.253.6]) by nic.funet.fi with ESMTP id <5037-17975>; Thu, 1 Feb 1996 00:14:17 +0200 Received: from tingeling.lysator.liu.se (nisse@tingeling.lysator.liu.se [130.236.253.25]) by konrad.lysator.liu.se (8.7.3/8.7.3) with ESMTP id XAA28067; Wed, 31 Jan 1996 23:13:15 +0100 (MET) Received: (from nisse@localhost) by tingeling.lysator.liu.se (8.7.3/8.7.3) id XAA28878; Wed, 31 Jan 1996 23:12:40 +0100 (MET) Date: Wed, 31 Jan 1996 23:12:40 +0100 (MET) Message-Id: <199601312212.XAA28878@tingeling.lysator.liu.se> From: "Niels Möller" To: amiga-gcc-port@nic.funet.fi In-reply-to: Ville-Pertti Keinonen's message of Wed, 31 Jan 1996 20:46:59 +0200 (EET) Subject: Re: Registers MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: <199601311846.UAA08710@newzetor.clinet.fi> Sorry, this is a little out of topic, but I just discovered The Solution of the issue whether arguments to functions should be passed in registers or on the stack ;-) The solution is to use an (infinite) register stack. Both arguments and all variables are pushed onto the stack. Elements are accessed just like ordinary registers, the top element is r0, the x:th element is rx. You can push the stack down (thereby creating space for local variables) with the instruction "push value" or "create n". For example: --------- --------- r0 | 17 | r0 | | --------- --------- r1 | 43 | r1 | | --------- --- create 2 ---> --------- r2 | foo | r2 | 17 | --------- --------- r3 | | r3 | 43 | --------- --------- r4 | | r4 | foo | --------- --------- | | | | To pop the stack and forget the top n elements, there's an instruction "drop n". Of course, a processor can only have a finite number of registers. But when you run out of registers, the last elements of the register stack are automatically moved into external memory, making the stack appear infinite. This scheme may seem difficult, but it should be fairly simple to implement. You only need a a finite circular array of N (for example 32) registers, an external stack pointer, and a few indeces and status bits for bookkeeping. Reading registers back from external memory are not done immediately at each "drop" instruction. Instead the new slots at the end of the circular array are marked in some way. When they are accessed, or when the memory bus happens to be free, their contents is read back from memory. And if they have not been changed when the next push happens, they needn't be written out to the external stack. In effect, the register array caches the top N elements of the stack. I think this has potential to be very efficient. For example, if you have a set of functions, that together uses up to N registers at any time, with a tree-like call graph, no memory accesses will be necessary except at the first descent down the tree and the last ascent. And the best thing is, that if you by a new processor, with four times as many on-chip registers, your code will take advantage of it without any changes at all! Now there's only one question: Who want to build this microprocessor? /Niels Möller From amiga-gcc-port-owner@nic.funet.fi Thu Feb 1 11:53:19 1996 Received: from k332.feld.cvut.cz ([147.32.192.12]) by nic.funet.fi with SMTP id <4422-18318>; Thu, 1 Feb 1996 11:51:23 +0200 Received: (from mj@localhost) by k332.feld.cvut.cz (8.6.12/8.6.9) id KAA20235 for amiga-gcc-port@nic.funet.fi; Thu, 1 Feb 1996 10:50:33 +0100 From: Martin Mares Message-Id: <199602010950.KAA20235@k332.feld.cvut.cz> Subject: Re: Optimizations. To: amiga-gcc-port@nic.funet.fi Date: Thu, 1 Feb 1996 10:50:33 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4312 Hello, world! > That would force using the registers for every call, which could mess > up the optimization of complex calculations that could take advantage > of a large number of registers. Yes, it would, but in case of really _complex_ function, you still could use the proposed function attribute forcing the compiler to use stack parameters instead. And even if you decide not to do so, the compiler will push some parameters on the stack, which is a performance loss, but only a small one -- if the calculation is complex and the code spends a lot of time there, the reg-to-stack move delay is incomparably smaller. Making of really optimized program (even in C) can be a difficult task requiring some manual decisions -- for example the correct use of function attributes (nonreturn etc.). Even in this case, the best performance can be obtained only by fine tuning of parameters... > That can already cost some functions four registerized variables when > a function with lots of arguments is called. The worst thing that could happen would be storing the arguments on the stack in order to use the register variables efficiently (see above). > What about the case of calling other functions? Part of the registers > used for arguments need to be pushed on the stack or moved to other > registers. And there can still be loss due to the compiler preferring > to keep the arguments in registers instead of other variables. It's the same problem as with registerized variables. > Normally register parameters probably speed up average performance, > but it's the most complex parts (the parts using the most registers > and losing the most if the registerized variables aren't chosen > properly) that might suffer. See above -- the manual switch (function attribute) solves it. (Well, with some human intervention.) > It might be even better to "give up" if there are more arguments than > can be passed in registers and just pass everything on the stack. I don't think so. > BTW: How would floats/doubles/quads/structures be passed? Floats in floating point registers if the FPU is in use, else floats in data registers (on 68000's they are of the same size). Doubles maybe in a data register pair, structures that fit to 32 bits maybe in a data register, anything else on the stack. > As if registerized arguments don't produce enough linkage problems as > is. How many people use stack-based arguments and rtd for all C-code > compiled for a 68010+? Probably nobody. Like registerized arguments, > it would require the recompilation of all linked libraries. "rtd" on 68010+ doesn't produce any significant speedup as it saves only a single instruction in an usual case. Yes, it would be needed to recompile all the linked libraries, but IMHO it's better to use shared libraries anyway. If you don't want to have _optimal_ libraries, you could use the dual-entry-point solution. > I used to do that all the time with DICE, only generating the > prototypes isn't always easy, especially with larger programs or when > you want to do it neatly. OK. > AFAIK SAS/C has quite a different approach to optimization than GNU > C. In several cases, GNU C does a better job optimizing (however, I > don't know what options were used for SAS/C), eg. I recompiled some > version of djpeg that was distributed compiled using SAS/C (probably > with lots of optimizations enabled, since there were separate '000 and > '020 versions), the gcc-compiled version was faster, I don't remember > by how much. But in any case, I have no idea if the SAS/C compiled > version of that had register argument passing enabled, I didn't bother > to disassemble it. When I compiled GNU gzip with both SAS/C and GCC, the GCC version was about 30% faster. Some of my experiments showed GCC has much better optimizations of complex constructs and also knows about instructions like "dbf". > How much is the difference in performance between SAS/C vs. SAS/C > programs with registerized vs. stacked arguments? "Significantly" > faster doesn't really mean anything, it could mean anything from 5% to > 50%... I don't remember the exact number in my TeX case, but as far as I remember, it was about 15% (not quite sure, maybe I'll re-test it). Martin Mares From amiga-gcc-port-owner@nic.funet.fi Thu Feb 1 16:02:14 1996 Received: by nic.funet.fi id <4277-3893>; Thu, 1 Feb 1996 16:00:15 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <96Feb1.160015+0200_eet.4277-3893+39@nic.funet.fi> Date: Thu, 1 Feb 1996 16:00:05 +0200 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Fri Feb 2 11:52:03 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <5074-7276>; Fri, 2 Feb 1996 11:47:54 +0200 Received: from ernie.icslab.agh.edu.pl by funet.fi with SMTP (PP); Fri, 2 Feb 1996 11:46:50 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id KAA07115; Fri, 2 Feb 1996 10:47:22 +0100 Date: Fri, 2 Feb 1996 10:47:21 +0100 (MET) From: Kamil Iskra To: ADE GCC List cc: Amiga GCC List , fleischr@IZFM.Uni-Stuttgart.DE Subject: A few Amiga-specific attributes implemented Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I implemented three Amiga-specific function attributes in GCC 2.7.0: interrupt, saveds and stackext. I also implemented "chip" attribute for variables, but since currently used "a.out" format does not support sections other than text, data and bss, there is no way to use (or even test) this feature. Implementation was very easy: I used features provided by GCC authors. Small example of how to use these attributes: If you want a single function to extend stack automatically, you should write your code like this: void func(void) __attribute__ ((stackext)); void func(void) { /* Function body... */ } (Please note that you _cannot_ specify attributes in function definition, only in declaration: this is not a bug in my implementation, it's just the way that GCC parser works (see documentation - "Function Attributes" chapter)). Here is a brief description of these three new attributes: interrupt This indicates that the function may be called from within an interrupt. GCC will not output stack checking or extension code for this function, even if global "-mstackcheck" or "-mstackextend" command-line arguments are specified. CC register will also be set in the epilogue of function by testing value of "d0". saveds This attribute is ignored unless you use "-fbaserel"/"-resident". When specified, GCC sets "a4" register in function prologue to address of data hunk (obtained from "__a4_init" variable). This is necessary if you want to use global variables in functions that might be called outside of your program (from another task, for example). Do not use this attribute together with stack checking/extension. stackext This attribute makes GCC create stack extension code in function for which it was specified. You might prefer it over "-mstackextend" command-line argument, since "-mstackextend" is global - it creates stack extension code for all functions in source file, what hurts the performance, while with "stackext" attribute you can create stack extension code for example for recursive functions only. My implementation changes GCC behaviour when both "-mstackcheck" and "-mstackextend" are specified. In Matthias' code "-mstackextend" was quietly ignored in such situation. In my code it is just opposite: "-mstackcheck" is ignored. I think it is much more reasonable and intuitive - after all, stack extension code also checks for stack overflow, it just acts differently when overflow is about to happen. What do you think? I intend to implement these attributes as keywords in future (like in SAS/C). However, implementing new keywords is much harder than implementing new attributes - it seems that GCC authors haven't provided any easy way to do this, so dirty hacks in source code will be required. Below you'll find UU-encoded context-diff from ADE GCC 2.7.0 sources to my private ones. After applying them and before recompilation you should manually delete files "explow.o" and "tree.o" - otherwise these files wouldn't be updated and new attributes wouldn't be available (unless you make a full rebuild, of course). begin 644 gcc-2.7.0-amigaattrs.diffs M9&EF9B`M8W(@9V-C+3(N-RXP+6]R:67=O7=O0HA("`@('-W:71C:"!T;R!?7W-A=F5DPHA("`@:68@*"$@85]T86(I"B$@("`@('L*(2`@("`@("!A; M7W-I>F4@/2`Q,#L*(2`@("`@("!A7VEN9&5X(#T@,#L*(2`@("`@("!A7W1A> M8B`@/2`HF4@*B!SC M:7IE;V8@*'-T')EK M86QL;V,@*&%?=&%B+"!A7W-I>F4@*B!S:7IE;V8@*'-T"LK72`]("IA='1R# M.PHA('T*(2`*(2`*(2!V;VED"B$@871TPHA("`@; M#L@:2LK+"!A*RLID M"B$@("`@(&EF("AA+3YI9&5N="`]/2!F=6YC=&EO;E]I9&5N="D*("`@("`@( M("!["B$@"6$M/G-A=F5D2`H)F%T='(I.PHA('T*(2`*(2!V;VED"B$@871T% MPHA(`DO*B!?7VEN=&5R'1E;F0*+2TM(#,X+#$P.2`M+2TM"B`@("!R971UPHA(`EI9B`H8W5R7!E7VYO9&4["B$@"2`@("!I9B`H87)G'1E;F0*9&EF9B`M8W(@9V-C+3(N-RXP+6]R:6&5D2!S=')U8W1U&5D M12D*(2`C9&5F:6YE(%1!4D=%5%]35$%#2T585$5.1"`H*"AT87)G971?9FQA\ M9W,F,#0P,#`I"0D)7`HA("`@)B8@;&]O:W5P7V%T=')I8G5T92@B:6YT97)RV M=7!T(BP)"0D)"5P*(2`@("`@1$5#3%]-04-(24Y%7T%45%))0E5415,H8W5R_ M7=OPD). M"0D)"0D)"5P*(2`@("`@("`@("`@=V%R;FEN9U]W:71H7V1E8VP@*&1E8VPLZ M"0D)"0D)7`HA("`@("`@("`@("`@("`@(G-A=F5DPD)"0D)"0D)"0E<"B$@("`@("`@! M:68@*%12145?0T]$12`H9&5C;"D@(3T@1E5.0U1)3TY?1$5#3"D)"0D)"5P*! M(2`@("`@("`@('L)"0D)"0D)"0E<"B$@("`@("`@("`@('=A#`S,#(["0D)"0D)"0E<"B$@"6YR96=S("L](#,["0D)? M"0D)"0E<"B$@("`@("`@?2!]"0D)"0D)"0D)7`HA(`HA(`HA("-D969I;F4@J M15!)3$]'545?15A44D%?0D%24DE%4E]+3%5$1T4HR!E>'1EF5R;R!I9B!)1$5.5$E&2452"B$@("`@D M=VET:"!A; Fri, 2 Feb 1996 14:15:32 +0200 Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id OAA00881 at Fri, 2 Feb 1996 14:14:47 +0200 Received: by softlab.ece.ntua.gr with ESMTP id OAA07899 at Fri, 2 Feb 1996 14:14:45 +0200 (EET) Received: by achilles.noc.ntua.gr via NTUAnet with ESMTP id OAA00875 at Fri, 2 Feb 1996 14:14:45 +0200 Received: by nestor.metal.ntua.gr via NTUAnet id OAA18137 at Fri, 2 Feb 1996 14:13:38 +0200 Date: Fri, 2 Feb 1996 14:13:38 +0200 From: System Administrator Message-Id: <199602021213.OAA18137@nestor.metal.ntua.gr> To: theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr Subject: E-Mail system statistics (users) National Technical University of Athens Network Operations Center Data network e-mail system usage statistics Start of time period: Dec 14 18:01:31 End of time period: Feb 1 02:00:03 (a) General statistics for the e-mail system Total messages handled: 92480 Total bytes handled: 580981318 Users: 2905 Domains / Hosts: 144 (b) Specific statistics for theseas!lists.funet.fi!amiga-gcc-port@achilles.noc.ntua.gr E-mail usage ranking: Number 1475 Messages received: 3 Bytes received: 4772 Messages sent: 0 Bytes sent: 0 Total messages: 3 Total bytes: 4772 General information: * Due to security reasons, recipient addresses of the form user@host.ntua.gr (eg. user@theseas.ntua.gr) will not be valid after March 20th, 1996. E-mail messages to such addresses will fail. Please change any occurences of such addresses and inform all your correspondents (and any mailing lists you are member of) of the change. * Due to security reasons, recipient addresses of the form user@host.subdomain.domain.ntua.gr (eg. user@alexander.cc.ece.ntua.gr) and user@host.domain.ntua.gr (eg. user@orfeas.chemeng.ntua.gr) will not be valid after March 20th, 1996. E-mail messages to such addresses will be specially processed. Please change any occurences of such addresses and inform all your correspondents (and any mailing lists you are member of) of the change. For any information, please e-mail to postmaster@ntua.gr or call ext.# 1861 Thank you Network Operations Center From amiga-gcc-port-owner@nic.funet.fi Fri Feb 2 19:02:13 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <4362-9843>; Fri, 2 Feb 1996 18:58:27 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tiOrV-000gXWC; Fri, 2 Feb 96 10:01 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: problem with gcc 2.7.2 as cross compiler To: ade-gcc@amigalib.com Date: Fri, 2 Feb 1996 10:01:24 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2625 I'm working at making an Amiga cross development environment on a 486 system running linux, with moderate success. Using an internal version of binutils 2.6 that now has a working gas and ld I'm able to build executables that will run on the Amiga. One problem I ran into though bootstrapping the compiler, and which is beyond my knowledge of gcc to fix quickly, is displayed by the following typescript. Note that the problem only appears when using the -resident arg to gcc. If anyone has experience with gcc internals, access to a system running linux, and would like to work on this problem, email me and I will send you diffs against the baseline gcc 2.7.2 release so you can build gcc. Thanks in advance for some help on this. BTW, even my lowly 66 Mhz 486/dx2 system blows the doors of my 40 Mhz WarpEngine 040 when cross compiling the code I've tested so far. It's faster than the Amiga by at least a factor of 2 or 3. I'd expect a 150-200 Mhz P6 machine to be at least 20 times faster than the Amiga. This would cut my compile times of the complete ADE tree down from the current 50+ hours to only 2 or 3 hours! That would make an incredible productivity difference in how fast I could install a patch to something (like gcc or binutils) that affects all the tools, and rebuild a complete binary tree. I'd still have to do a native Amiga final multistage build though, right before each release, to verify that there aren't any latent problems that down show up in a cross environment. -Fred Script started on Fri Feb 2 09:41:56 1996 fishpond [1] cat junk.c typedef unsigned int USItype __attribute__ ((mode (SI))); typedef int DItype __attribute__ ((mode (DI))); typedef int SItype __attribute__ ((mode (SI))); #if LIBGCC2_WORDS_BIG_ENDIAN struct DIstruct {SItype high, low;}; #else struct DIstruct {SItype low, high;}; #endif typedef union { struct DIstruct s; DItype ll; } DIunion; DItype __muldi3 (u, v) DItype u, v; { DIunion w; DIunion uu, vv; uu.ll = u, vv.ll = v; w.ll = __umulsidi3 (uu.s.low, vv.s.low); w.s.high += ((USItype) uu.s.low * (USItype) vv.s.high + (USItype) uu.s.high * (USItype) vv.s.low); return w.ll; } fishpond [2] ./xgcc -B./ -c junk.c fishpond [3] ./xgcc -B./ -c -resident junk.c junk.c: In function `__muldi3': junk.c:32: internal error--unrecognizable insn: (call_insn/u 27 25 28 (set (reg:SI 0 d0) (call (mem:QI (symbol_ref:SI ("__mulsi3"))) (const_int 8))) -1 (nil) (nil) (nil)) xgcc: Internal compiler error: program cc1 got fatal signal 6 fishpond [4] exit Script done on Fri Feb 2 09:42:24 1996 From amiga-gcc-port-owner@nic.funet.fi Sat Feb 3 10:15:16 1996 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with ESMTP id <4513-14543>; Sat, 3 Feb 1996 10:14:32 +0200 Received: from newzetor.clinet.fi (root@newzetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id KAA11803; Sat, 3 Feb 1996 10:14:09 +0200 (EET) Received: (will@localhost) by newzetor.clinet.fi (8.7.3/8.6.4) id KAA29192; Sat, 3 Feb 1996 10:14:21 +0200 (EET) Date: Sat, 3 Feb 1996 10:14:21 +0200 (EET) Message-Id: <199602030814.KAA29192@newzetor.clinet.fi> From: Ville-Pertti Keinonen To: mj@k332.feld.cvut.cz CC: amiga-gcc-port@nic.funet.fi In-reply-to: <199602010950.KAA20235@k332.feld.cvut.cz> (message from Martin Mares on Thu, 1 Feb 1996 10:50:33 +0100 (MET)) Subject: Re: Optimizations. Yes, it would, but in case of really _complex_ function, you still could use the proposed function attribute forcing the compiler to use stack parameters Personally, I prefer writing code that is as close to portable as possible, even if it's AmigaOS-specific. In part this is to avoid getting bad habits out of Amigaisms. Making of really optimized program (even in C) can be a difficult task requiring some manual decisions -- for example the correct use of function Well, programs requiring that level of optimization must be intended for special purposes. Normally it should be enough to design the program well, use good programming techniques and an optimizing compiler. Good techniques (including ones based on knowledge of how the compiler optimizes code) and design are what have the most effect on speed. It's the same problem as with registerized variables. The difference is, registerized variables are placed in registers so that if they need to live past calls to other functions, they aren't in scratch registers.a See above -- the manual switch (function attribute) solves it. (Well, with some human intervention.) But extending C too much with manual "optimizations" isn't always a good idea. There are lots of things that could be optimized even more if you could just tell the compiler a bit more about them. Eg. if you could give a list/range of possible values of ``a'' for switch (a), the compiler could avoid generating code to check whether it is in range for indirecting through a jump table etc.. Floats in floating point registers if the FPU is in use, else floats in Is there any existing convention concerning which floating point registers are scratch? Anyhow, passing floats in floating point registers would cause another code-compatibility problem, especially with shared libraries. data registers (on 68000's they are of the same size). Doubles maybe in a data register pair, structures that fit to 32 bits maybe in a data register, anything else on the stack. Structures in registers? Even 32-bit structures are never placed in registers by code that is currently generated. Yes, it would be needed to recompile all the linked libraries, but IMHO it's better to use shared libraries anyway. If you don't want to have The shared libraries would also need to have the special entry points, of course that would be the usual method for Amiga libraries. In any case, registerized arguments would be at least m68k- and probably AmigaOS-specific. _optimal_ libraries, you could use the dual-entry-point solution. And how would you do that using Amiga libraries? Of course separate LVO's would be possible, but... When I compiled GNU gzip with both SAS/C and GCC, the GCC version was about 30% faster. Some of my experiments showed GCC has much better Did you exclude the asm-part or is that just the speedup when uncompressing? optimizations of complex constructs and also knows about instructions like "dbf". That reminds me of a strange thing -- it seems a lot of the code found at AESOP is written as if dbf didn't exist (sa. compilation examples in the 680x0 optimization information and the actual code in the 060sp). Maybe it's slow on "bigger" cpus, since it manipulates words. From amiga-gcc-port-owner@nic.funet.fi Sat Feb 3 10:46:02 1996 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with ESMTP id <4548-14543>; Sat, 3 Feb 1996 10:45:19 +0200 Received: from newzetor.clinet.fi (root@newzetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id KAA12398; Sat, 3 Feb 1996 10:44:49 +0200 (EET) Received: (will@localhost) by newzetor.clinet.fi (8.7.3/8.6.4) id KAA29518; Sat, 3 Feb 1996 10:45:01 +0200 (EET) Date: Sat, 3 Feb 1996 10:45:01 +0200 (EET) Message-Id: <199602030845.KAA29518@newzetor.clinet.fi> From: Ville-Pertti Keinonen To: fnf@amigalib.com CC: ade-gcc@amigalib.com, amiga-gcc-port@nic.funet.fi In-reply-to: (fnf@amigalib.com) Subject: Re: problem with gcc 2.7.2 as cross compiler BTW, even my lowly 66 Mhz 486/dx2 system blows the doors of my 40 Mhz WarpEngine 040 when cross compiling the code I've tested so far. It's faster than the Amiga by at least a factor of 2 or 3. I'd expect a 150-200 Mhz P6 machine to be at least 20 times faster than the Amiga. If you're speaking of the whole build process, it's probably not just the cpu speed that counts, but also the environment (have you tried compiling on your Amiga under Linux/68k?). Two things that make the AmigaOS especially slow compared to Unix-type systems are the filesystem (especially apparent when eg. manipulating a large number of files in a single directory) and relocating executables. According to benchmarks (of course we all know how bogus they are) an '040 40MHz should be a bit faster than a 486DX2 66MHz, so one wouldn't expect the situation to be *that* different in reality. Of course gcc probably does run a bit faster on x86 cpus, since they tend to have huge external caches (pc-users consider a 32kB cache "small"), capable of containing the entire code for most passes. In any case, I doubt that your conclusion concerning the P6 machine is quite correct. From amiga-gcc-port-owner@nic.funet.fi Mon Feb 5 11:16:05 1996 Received: from gilbert.ucc.hull.ac.uk ([150.237.128.199]) by nic.funet.fi with ESMTP id <4864-32065>; Mon, 5 Feb 1996 11:10:44 +0200 Received: from chopin.ucc.hull.ac.uk by gilbert.ucc.hull.ac.uk with SMTP local (PP); Mon, 5 Feb 1996 09:09:55 +0000 Received: from mailhub1-remote.hull.ac.uk by mailhub1.hull.ac.uk id <08119-0@mailhub1.hull.ac.uk>; Mon, 5 Feb 1996 09:09:26 +0000 Date: Mon, 5 Feb 1996 09:09:21 +0000 (GMT) From: "C.Jackson" X-Sender: cs7cj1@radley Reply-To: C.Jackson@dcs.hull.ac.uk To: GCC C/C++ List Subject: Unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: C.Jackson@dcs.hull.ac.uk Unsubscribe From amiga-gcc-port-owner@nic.funet.fi Mon Feb 5 12:42:49 1996 Received: from DBSTU1.RZ.TU-BS.DE ([134.169.1.1]) by nic.funet.fi with SMTP id <4367-32065>; Mon, 5 Feb 1996 12:39:49 +0200 Received: from rzserv0.rz.tu-bs.de by DBSTU1.RZ.TU-BS.DE (IBM VM SMTP V2R2) with TCP; Mon, 05 Feb 96 11:39:49 MEZ Received: by rzserv0.rz.tu-bs.de (1.37.109.4/15.6) id AA22462; Mon, 5 Feb 96 11:38:31 +0100 From: Sven Heithecker Subject: help To: amiga-gcc-port@nic.funet.fi (Sven Heithecker) Date: Mon, 5 Feb 1996 11:38:27 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL11] Content-Type: text Content-Length: 0 Message-Id: <96Feb5.123949+0200_eet.4367-32065+101@nic.funet.fi> From amiga-gcc-port-owner@nic.funet.fi Tue Feb 6 00:03:30 1996 Received: from cpt6.stm.tudelft.nl ([130.161.186.114]) by nic.funet.fi with SMTP id <5105-31642>; Mon, 5 Feb 1996 23:15:24 +0200 Received: by cpt6.stm.tudelft.nl (1.38.193.4/16.2) id AA06008; Mon, 5 Feb 1996 22:21:16 +0100 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Maarten D.de Jong ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Subject: Maintainer of GhostView/Script? From: To: amiga-gcc-port@nic.funet.fi Date: Mon, 5 Feb 96 22:21:16 MET Mailer: Elm [revision: 70.85] Message-Id: <96Feb5.231524+0200_eet.5105-31642+42@nic.funet.fi> Hi. Could the nice Dutch fellow who allowed me to ftp a pre3.51 version of GS tell me his address once more, or better yet, point me to the latest release of this program? It seems I sort of lost it in a crash, but I lost all kinds of links to interesting ftp-sites as well... Maarten -- ****************************************************************************** * We learn from history that we never learn anything from history. * ****************************************************************************** | Maarten D. de Jong | dejong@cpt6.stm.tudelft.nl | | ------------------------------------------------------------------------------ From amiga-gcc-port-owner@nic.funet.fi Tue Feb 6 10:38:42 1996 Received: from specklec.mpifr-bonn.mpg.de ([134.104.20.3]) by nic.funet.fi with SMTP id <4348-17024>; Tue, 6 Feb 1996 10:37:54 +0200 Received: from spckll.mpifr-bonn.mpg.de (spckll.mpifr-bonn.mpg.de [134.104.20.14]) by specklec.mpifr-bonn.mpg.de (8.6.10/8.6.9) with ESMTP id JAA03967; Tue, 6 Feb 1996 09:36:44 +0100 From: Gerd Schniggenberg Received: (gs@localhost) by spckll.mpifr-bonn.mpg.de (8.6.9/8.6.9) id JAA11679; Tue, 6 Feb 1996 09:36:44 +0100 Message-Id: <199602060836.JAA11679@spckll.mpifr-bonn.mpg.de> Subject: Re: Maintainer of GhostView/Script? To: dejong@cpt6.stm.tudelft.nl Date: Tue, 6 Feb 96 9:36:43 MET DST Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <96Feb5.231524+0200_eet.5105-31642+42@nic.funet.fi>; from "dejong@cpt6.stm.tudelft.nl" at Feb 5, 96 10:21 pm X-Mailer: ELM [version 2.2 PL14] Hi! > Could the nice Dutch fellow who allowed me to ftp a pre3.51 version of GS > tell me his address once more, or better yet, point me to the latest release > of this program? It seems I sort of lost it in a crash, but I lost all kinds > of links to interesting ftp-sites as well... > You can find ghostscript on aminet in drawer gfx/show: gs353bin.lha gfx/show 1.2M+Ghostscript3.53 binaries (installed) gs353jpeg6.lha gfx/show 651K+Ghostscript3.53 jpeg-6 support source gs353png.lha gfx/show 103K+Ghostscript3.53 png support source gs353src.lha gfx/show 2.4M+Ghostscript3.53 original sources gs353src_amiga.lha gfx/show 88K+Ghostscript3.53 Amiga specific sources gs353zlib.lha gfx/show 83K+Ghostscript3.53 zlib support source The EMail-addess from the 'author' is: Joop.vandeWege@Medew.ENTO.WAU.NL Gerd -- From amiga-gcc-port-owner@nic.funet.fi Tue Feb 6 21:57:05 1996 Received: from roemer.gbar.dtu.dk ([130.225.87.182]) by nic.funet.fi with ESMTP id <5072-4880>; Tue, 6 Feb 1996 21:42:34 +0200 Received: (from gc948374@localhost) by roemer.gbar.dtu.dk (8.7.3/8.7.3) id UAA22714; Tue, 6 Feb 1996 20:42:26 +0100 (MET) Date: Tue, 6 Feb 1996 20:42:26 +0100 (MET) From: Rask Ingemann Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: New README for GCC 2.7.2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi all, Once again, a new README file for GCC 2.7.2 is ready. There are only two changes this time, one due to the change in my email address and one from Kamil Iskra about the new (no longer) inline headers. The complete README is available on the WWW as The diff from the last revision is available on the WWW as If you want any or all of these sent by e-mail, try out my new e-mail address. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Feb 7 18:45:07 1996 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <4797-8412>; Wed, 7 Feb 1996 18:29:30 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA26394 (5.67b8/IDA-1.5 for ); Wed, 7 Feb 1996 17:29:08 +0100 Received: by diva.gmd.de with UUCP id AA27973 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Wed, 7 Feb 1996 17:24:01 +0100 Date: Wed, 7 Feb 1996 17:24:01 +0100 Message-Id: <199602071624.AA27973@diva.gmd.de> From: Joerg.Hoehle@gmd.de (Joerg Hoehle) To: Amiga-Gcc Liste Subject: Re: mailing lists at amigalib.com In-Reply-To: References: <199601091143.LAA18693@colombo.telesys-innov.fr> Rask Lambertsen writes: > And please make the mailing list software set the From: field to the=20 > mailing list instead of the one that wrote the message. Maybe set Cc: t= > o=20 > the one that wrote the letter. Or set Reply-To: to the mailing list. Th= > at=20 > would make it easier to avoid sending the same letter to both the maili= > ng=20 > list and the one who wrote it. Maybe write-access to the new lists should be forbidden to anyone not on the list. So there's no need to send an extra CC: (or wonder if it's necessary). People who asked something will get the response through the list. It may also prevent weird commercial postings like the ones I received recently. Maybe it's already set up this way, didn't want to sent a "test" message to any of these lists. Bye, Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Thu Feb 8 12:38:40 1996 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <4706-31223>; Thu, 8 Feb 1996 12:24:42 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA26708 (5.67b8/IDA-1.5 for ); Thu, 8 Feb 1996 11:24:23 +0100 Received: by diva.gmd.de with UUCP id AA28129 (5.67b8/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Thu, 8 Feb 1996 11:19:20 +0100 Date: Thu, 8 Feb 1996 11:19:20 +0100 Message-Id: <199602081019.AA28129@diva.gmd.de> From: Joerg.Hoehle@gmd.de (Joerg Hoehle) To: amiga-gcc-port@nic.funet.fi Subject: Re: Optimizations. In-Reply-To: <199602030814.KAA29192@newzetor.clinet.fi> References: <199602010950.KAA20235@k332.feld.cvut.cz> <199602030814.KAA29192@newzetor.clinet.fi> Hi, Martin Mares writes: > Making of really optimized program (even in C) can be a difficult task > requiring some manual decisions -- for example the correct use of function You cannot write really optimized _portable_ programs, as the optimal size of a function (e.g. do you use another function call or do you inline the code) is directly dependent on the numbers of registers the target processor has. With many registers, you can write larger functions. With few registers, better have more functions as intermediates will be kept on the stack while sub-functions are called and use the few registers. Ville-Pertti Keinonen writes: > Structures in registers? Even 32-bit structures are never placed in > registers by code that is currently generated. Don't mix what can be done and what is not done in the current implementation of GCC on the Amiga. GCC is very well able to place 32-bit structures in registers in m68k code generation (see NeXT). Bye, Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Thu Feb 8 19:13:01 1996 Received: from tycho.gbar.dtu.dk ([130.225.87.183]) by nic.funet.fi with ESMTP id <4303-31216>; Thu, 8 Feb 1996 19:11:16 +0200 Received: (from gc948374@localhost) by tycho.gbar.dtu.dk (8.7.3/8.7.3) id SAA07334; Thu, 8 Feb 1996 18:11:03 +0100 (MET) Date: Thu, 8 Feb 1996 18:11:02 +0100 (MET) From: Rask Ingemann Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: New optimizations for m68k.c + source code to test it Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2010703495-851401618-823799462=:7314" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --2010703495-851401618-823799462=:7314 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Hi all, I have found out that some of the optimizations that I put into m68k.c are redundant, so I have removed them. I have added some other optimizations and I have also written a few bits of code that test the optimizations. I have attached the files to this letter. All the optimizations causes more "move.l #x,Dn" instructions to be optimized when compiling for '000/'010. They will (hopefully) not be used on bigger processors, as they are either slower or don't gain speed then. If these optimizations don't break anything, will/can they be added to the FSF souces too? How? Regards, _________________________________________________________________________ / \ | Rask Ingemann Lambertsen | E-mail: gc948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | --2010703495-851401618-823799462=:7314 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="m68k.c.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Diff against m68k.c from GCC 2.7.0 LS0tIG02OGsuYy5vcmlnCVRodSBBdWcgMjQgMTI6Mjg6MDQgMTk5NQ0KKysr IG02OGsuYwlUaHUgRmViICA4IDE0OjM1OjQwIDE5OTYNCkBAIC0xMDk0LDcg KzEwOTQsOCBAQA0KIH0NCiANCiAMDQotdHlwZWRlZiBlbnVtIHsgTU9WTCwg U1dBUCwgTkVHVywgTk9UVywgTk9UQiwgTU9WUSB9IENPTlNUX01FVEhPRDsN Cit0eXBlZGVmIGVudW0geyBNT1ZMLCBTV0FQLCBORUdXLCBOT1RXLCBOT1RC LCBNT1ZRLCBCQ0hHLCBORUdXX0FERFcsDQorICAgICAgICAgICAgICAgTkVH V19BRERRVyB9IENPTlNUX01FVEhPRDsNCiANCiB1c2VfbW92cSAoaSkNCiAg ICAgIGludCBpOw0KQEAgLTExMDIsNiArMTEwMywxMDAgQEANCiAgIHJldHVy biAoaSA+PSAtMTI4ICYmIGkgPD0gMTI3KTsNCiB9DQogDQorLyogUmV0dXJu IHRoZSB2YWx1ZSBtIGluIHRoZSBmb2xsb3dpbmcgb3B0aW1pemF0aW9uOg0K KyAgIG1vdmUubCAjaSxkeCAtPiBtb3ZlcSAgI20sZHgNCisgICAgICAgICAg ICAgICAgICAgYmNoZy5sIGR4LGR4DQorICAgVGhpcyBzYXZlcyB0d28gYnl0 ZXMsIGJ1dCBpcyBvbmx5IGtub3duIHRvIGJlIGZhc3RlciBvbiAnMDAwIGFu ZCAnMDEwLg0KKyAgIEl0IGlzIHNsb3dlciBvbiAnMDMwLCBhbmQgbW9zdCBs aWtlbHkgYWxzbyBvbiAnMDIwLCAnMDQwIGFuZCAnMDYwLg0KKyAgIFJldHVy bnMgMCBpZiB0aGUgb3B0aW1pemF0aW9uIGlzIG5vdCBwb3NzaWJsZS4gKi8N CisNCitpbnQgdXNlX2JjaGdsIChpKQ0KKyAgICAgaW50IGk7DQorew0KKyAg LyogVGhlIGxhc3QgaSBhbmQgbSBhcmUgY2FjaGVkIGZvciBlZmZpY2llbmN5 LiAqLw0KKyAgc3RhdGljIGludCBsYXN0X2kgPSAtMzI4ODEsIGxhc3RfbSA9 IC0xMTM7DQorICByZWdpc3RlciBpbnQgbTsNCisNCisgIC8qIENoZWNrIGZv ciBhIGNhY2hlIGhpdC4gKi8NCisgIGlmIChpID09IGxhc3RfaSkNCisgICAg cmV0dXJuIChsYXN0X20pOw0KKw0KKyAgc3dpdGNoIChpKQ0KKyAgew0KKyAg ICBjYXNlIC0zMjg4MTogbSA9IC0xMTM7IGJyZWFrOw0KKyAgICBjYXNlIC0z Mjg0OTogbSA9ICAtODE7IGJyZWFrOw0KKyAgICBjYXNlIC0zMjgxNzogbSA9 ICAtNDk7IGJyZWFrOw0KKyAgICBjYXNlIC0zMjc4NTogbSA9ICAtMTc7IGJy ZWFrOw0KKyAgICBjYXNlIC0xNjQ5ODogbSA9IC0xMTQ7IGJyZWFrOw0KKyAg ICBjYXNlIC0xNjQ2NjogbSA9ICAtODI7IGJyZWFrOw0KKyAgICBjYXNlIC0x NjQzNDogbSA9ICAtNTA7IGJyZWFrOw0KKyAgICBjYXNlIC0xNjQwMjogbSA9 ICAtMTg7IGJyZWFrOw0KKyAgICBjYXNlICAtODMwNzogbSA9IC0xMTU7IGJy ZWFrOw0KKyAgICBjYXNlICAtODI3NTogbSA9ICAtODM7IGJyZWFrOw0KKyAg ICBjYXNlICAtODI0MzogbSA9ICAtNTE7IGJyZWFrOw0KKyAgICBjYXNlICAt ODIxMTogbSA9ICAtMTk7IGJyZWFrOw0KKyAgICBjYXNlICAtNDIxMjogbSA9 IC0xMTY7IGJyZWFrOw0KKyAgICBjYXNlICAtNDE4MDogbSA9ICAtODQ7IGJy ZWFrOw0KKyAgICBjYXNlICAtNDE0ODogbSA9ICAtNTI7IGJyZWFrOw0KKyAg ICBjYXNlICAtNDExNjogbSA9ICAtMjA7IGJyZWFrOw0KKyAgICBjYXNlICAt MjE2NTogbSA9IC0xMTc7IGJyZWFrOw0KKyAgICBjYXNlICAtMjEzMzogbSA9 ICAtODU7IGJyZWFrOw0KKyAgICBjYXNlICAtMjEwMTogbSA9ICAtNTM7IGJy ZWFrOw0KKyAgICBjYXNlICAtMjA2OTogbSA9ICAtMjE7IGJyZWFrOw0KKyAg ICBjYXNlICAtMTE0MjogbSA9IC0xMTg7IGJyZWFrOw0KKyAgICBjYXNlICAt MTExMDogbSA9ICAtODY7IGJyZWFrOw0KKyAgICBjYXNlICAtMTA3ODogbSA9 ICAtNTQ7IGJyZWFrOw0KKyAgICBjYXNlICAtMTA0NjogbSA9ICAtMjI7IGJy ZWFrOw0KKyAgICBjYXNlICAgLTYzMTogbSA9IC0xMTk7IGJyZWFrOw0KKyAg ICBjYXNlICAgLTU5OTogbSA9ICAtODc7IGJyZWFrOw0KKyAgICBjYXNlICAg LTU2NzogbSA9ICAtNTU7IGJyZWFrOw0KKyAgICBjYXNlICAgLTUzNTogbSA9 ICAtMjM7IGJyZWFrOw0KKyAgICBjYXNlICAgLTM3NjogbSA9IC0xMjA7IGJy ZWFrOw0KKyAgICBjYXNlICAgLTM0NDogbSA9ICAtODg7IGJyZWFrOw0KKyAg ICBjYXNlICAgLTMxMjogbSA9ICAtNTY7IGJyZWFrOw0KKyAgICBjYXNlICAg LTI4MDogbSA9ICAtMjQ7IGJyZWFrOw0KKyAgICBjYXNlICAgIDI2NDogbSA9 ICAgIDg7IGJyZWFrOw0KKyAgICBjYXNlICAgIDI5NjogbSA9ICAgNDA7IGJy ZWFrOw0KKyAgICBjYXNlICAgIDMyODogbSA9ICAgNzI7IGJyZWFrOw0KKyAg ICBjYXNlICAgIDM2MDogbSA9ICAxMDQ7IGJyZWFrOw0KKyAgICBjYXNlICAg IDUyMTogbSA9ICAgIDk7IGJyZWFrOw0KKyAgICBjYXNlICAgIDU1MzogbSA9 ICAgNDE7IGJyZWFrOw0KKyAgICBjYXNlICAgIDU4NTogbSA9ICAgNzM7IGJy ZWFrOw0KKyAgICBjYXNlICAgIDYxNzogbSA9ICAxMDU7IGJyZWFrOw0KKyAg ICBjYXNlICAgMTAzNDogbSA9ICAgMTA7IGJyZWFrOw0KKyAgICBjYXNlICAg MTA2NjogbSA9ICAgNDI7IGJyZWFrOw0KKyAgICBjYXNlICAgMTA5ODogbSA9 ICAgNzQ7IGJyZWFrOw0KKyAgICBjYXNlICAgMTEzMDogbSA9ICAxMDY7IGJy ZWFrOw0KKyAgICBjYXNlICAgMjA1OTogbSA9ICAgMTE7IGJyZWFrOw0KKyAg ICBjYXNlICAgMjA5MTogbSA9ICAgNDM7IGJyZWFrOw0KKyAgICBjYXNlICAg MjEyMzogbSA9ICAgNzU7IGJyZWFrOw0KKyAgICBjYXNlICAgMjE1NTogbSA9 ICAxMDc7IGJyZWFrOw0KKyAgICBjYXNlICAgNDEwODogbSA9ICAgMTI7IGJy ZWFrOw0KKyAgICBjYXNlICAgNDE0MDogbSA9ICAgNDQ7IGJyZWFrOw0KKyAg ICBjYXNlICAgNDE3MjogbSA9ICAgNzY7IGJyZWFrOw0KKyAgICBjYXNlICAg NDIwNDogbSA9ICAxMDg7IGJyZWFrOw0KKyAgICBjYXNlICAgODIwNTogbSA9 ICAgMTM7IGJyZWFrOw0KKyAgICBjYXNlICAgODIzNzogbSA9ICAgNDU7IGJy ZWFrOw0KKyAgICBjYXNlICAgODI2OTogbSA9ICAgNzc7IGJyZWFrOw0KKyAg ICBjYXNlICAgODMwMTogbSA9ICAxMDk7IGJyZWFrOw0KKyAgICBjYXNlICAx NjM5ODogbSA9ICAgMTQ7IGJyZWFrOw0KKyAgICBjYXNlICAxNjQzMDogbSA9 ICAgNDY7IGJyZWFrOw0KKyAgICBjYXNlICAxNjQ2MjogbSA9ICAgNzg7IGJy ZWFrOw0KKyAgICBjYXNlICAxNjQ5NDogbSA9ICAxMTA7IGJyZWFrOw0KKyAg ICBjYXNlICAzMjc4MzogbSA9ICAgMTU7IGJyZWFrOw0KKyAgICBjYXNlICAz MjgxNTogbSA9ICAgNDc7IGJyZWFrOw0KKyAgICBjYXNlICAzMjg0NzogbSA9 ICAgNzk7IGJyZWFrOw0KKyAgICBjYXNlICAzMjg5NzogbSA9ICAxMTE7IGJy ZWFrOw0KKw0KKyAgICBkZWZhdWx0OiAgICAgbSA9ICAgIDA7IGJyZWFrOw0K KyAgfQ0KKw0KKyAgbGFzdF9pID0gaTsNCisgIGxhc3RfbSA9IG07DQorDQor ICByZXR1cm4gbTsNCit9DQorDQogQ09OU1RfTUVUSE9EDQogY29uc3RfbWV0 aG9kIChjb25zdGFudCkNCiAgICAgIHJ0eCBjb25zdGFudDsNCkBAIC0xMTIz LDkgKzEyMTgsMjAgQEANCiAgIGlmIChpID09IC02NTQwOCkNCiAgICAgcmV0 dXJuIE5FR1c7DQogICAvKiBUcnkgYWxzbyB3aXRoIHN3YXAgKi8NCi0gIHUg PSBpOw0KICAgaWYgKHVzZV9tb3ZxICgodSA+PiAxNikgfCAodSA8PCAxNikp KQ0KICAgICByZXR1cm4gU1dBUDsNCisgIC8qIFRyeSB3aXRoIG5lZy53ICsg YWRkLncuIE9ubHkgZG8gdGhpcyBmb3IgJzAwMCBhbmQgJzAxMC4gKi8NCisg IGlmICgoIVRBUkdFVF82ODAyMCAmJiAhVEFSR0VUXzY4MDQwICYmICFUQVJH RVRfNjgwNDBfT05MWSkNCisgICAgICAmJiBpID09IC02NTI4MCkNCisgICAg cmV0dXJuIE5FR1dfQUREVzsNCisgIC8qIFRyeSB3aXRoIG5lZy53ICsgYWRk cS53LiBPbmx5IGRvIHRoaXMgZm9yICcwMDAgYW5kICcwMTAuICovDQorICBp ZiAoKCFUQVJHRVRfNjgwMjAgJiYgIVRBUkdFVF82ODA0MCAmJiAhVEFSR0VU XzY4MDQwX09OTFkpDQorICAgICAgJiYgaSA8PSAtNjU0MDAgJiYgaSA+PSAt NjU0MDcpDQorICAgIHJldHVybiBORUdXX0FERFFXOw0KKyAgLyogVHJ5IHdp dGggYmNoZy5sLiBPbmx5IGRvIHRoaXMgZm9yICcwMDAgYW5kICcwMTAuICov DQorICBpZiAoKCFUQVJHRVRfNjgwMjAgJiYgIVRBUkdFVF82ODA0MCAmJiAh VEFSR0VUXzY4MDQwX09OTFkpDQorICAgICAgJiYgdXNlX2JjaGdsIChpKSkN CisgICAgcmV0dXJuIEJDSEc7DQogICAvKiBPdGhlcndpc2UsIHVzZSBtb3Zl LmwgKi8NCiAgIHJldHVybiBNT1ZMOw0KIH0NCkBAIC0xMTQyLDEwICsxMjQ4 LDE5IEBADQogICAgICAgY2FzZSBOT1RXIDoNCiAgICAgICBjYXNlIE5FR1cg Og0KICAgICAgIGNhc2UgU1dBUCA6DQotICAgICAgLyogQ29uc3RhbnRzIGVh c2lseSBnZW5lcmF0ZWQgYnkgbW92ZXEgKyBub3QuYi9ub3Qudy9uZWcudy9z d2FwICAqLw0KKyAgICAgIC8qIENvbnN0YW50cyBlYXNpbHkgZ2VuZXJhdGVk IGJ5IG1vdmVxICsgbm90LmIvbm90LncvbmVnLncvc3dhcCAqLw0KICAgICAg ICAgcmV0dXJuIDE7DQotICAgICAgY2FzZSBNT1ZMIDoNCisgICAgICBjYXNl IEJDSEcgOg0KKyAgICAgIGNhc2UgTkVHV19BRERXIDoNCisgICAgICBjYXNl IE5FR1dfQUREUVcgOg0KKyAgICAgIC8qIENvbnN0YW50cyBlYXNpbHkgZ2Vu ZXJhdGVkIGJ5IG1vdmVxICsgbmVnLncgKyBhZGQudy9hZGRxLncgKi8NCiAJ cmV0dXJuIDI7DQorICAgICAgY2FzZSBNT1ZMIDoNCisJLyogbW92ZS5sICN4 LERuIGlzIG11Y2ggc2xvd2VyIG9uICcwMDAgYW5kICcwMTAgKi8NCisJaWYg KFRBUkdFVF82ODAyMCB8fCBUQVJHRVRfNjgwNDAgfHwgVEFSR0VUXzY4MDQw X09OTFkpDQorCSAgcmV0dXJuIDI7DQorCWVsc2UNCisJICByZXR1cm4gMzsN CiAgICAgICBkZWZhdWx0IDoNCiAgICAgICAgIGFib3J0ICgpOw0KICAgICB9 DQpAQCAtMTE3MiwyMCArMTI4NywzMyBAQA0KICAgICAgIHJldHVybiAibW92 ZXElLmwgJTEsJTBcblx0bm90JS5iICUwIjsNCiAjZWxzZQ0KICAgICAgIHJl dHVybiAibW92ZXEgJTEsJTBcblx0bm90JS5iICUwIjsNCi0jZW5kaWYJIA0K KyNlbmRpZg0KICAgICBjYXNlIE5PVFcgOg0KICAgICAgIG9wZXJhbmRzWzFd ID0gZ2VuX3J0eCAoQ09OU1RfSU5ULCBWT0lEbW9kZSwgaSBeIDB4ZmZmZik7 DQogI2lmIGRlZmluZWQgKE1PVE9ST0xBKSAmJiAhZGVmaW5lZCAoQ1JEUykN CiAgICAgICByZXR1cm4gIm1vdmVxJS5sICUxLCUwXG5cdG5vdCUudyAlMCI7 DQogI2Vsc2UNCiAgICAgICByZXR1cm4gIm1vdmVxICUxLCUwXG5cdG5vdCUu dyAlMCI7DQotI2VuZGlmCSANCisjZW5kaWYNCiAgICAgY2FzZSBORUdXIDoN CiAjaWYgZGVmaW5lZCAoTU9UT1JPTEEpICYmICFkZWZpbmVkIChDUkRTKQ0K ICAgICAgIHJldHVybiAibW92ZXElLmwgJSMtMTI4LCUwXG5cdG5lZyUudyAl MCI7DQogI2Vsc2UNCiAgICAgICByZXR1cm4gIm1vdmVxICUjLTEyOCwlMFxu XHRuZWclLncgJTAiOw0KLSNlbmRpZgkgDQorI2VuZGlmDQorICAgIGNhc2Ug TkVHV19BRERXOg0KKyNpZiBkZWZpbmVkIChNT1RPUk9MQSkgJiYgIWRlZmlu ZWQgKENSRFMpDQorICAgICAgcmV0dXJuICJtb3ZlcSUubCAlIy0xMjgsJTBc blx0bmVnJS53ICUwXG5cdGFkZCUudyAlMCwlMCI7DQorI2Vsc2UNCisgICAg ICByZXR1cm4gIm1vdmVxICUjLTEyOCwlMFxuXHRuZWclLncgJTBcblx0YWRk JS53ICUwLCUwIjsNCisjZW5kaWYNCisgICAgY2FzZSBORUdXX0FERFFXOg0K KyAgICAgIG9wZXJhbmRzWzFdID0gZ2VuX3J0eCAoQ09OU1RfSU5ULCBWT0lE bW9kZSwgNjU0MDggKyBpKTsNCisjaWYgZGVmaW5lZCAoTU9UT1JPTEEpICYm ICFkZWZpbmVkIChDUkRTKQ0KKyAgICAgIHJldHVybiAibW92ZXElLmwgJSMt MTI4LCUwXG5cdG5lZyUudyAlMFxuXHRhZGRxJS53ICUxLCUwIjsNCisjZWxz ZQ0KKyAgICAgIHJldHVybiAibW92ZXEgJSMtMTI4LCUwXG5cdG5lZyUudyAl MFxuXHRhZGRxJS53ICUxLCUwIjsNCisjZW5kaWYNCiAgICAgY2FzZSBTV0FQ IDoNCiAgICAgICB7DQogCXVuc2lnbmVkIHUgPSBpOw0KQEAgLTExOTUsOCAr MTMyMywxNSBAQA0KIAlyZXR1cm4gIm1vdmVxJS5sICUxLCUwXG5cdHN3YXAg JTAiOw0KICNlbHNlDQogCXJldHVybiAibW92ZXEgJTEsJTBcblx0c3dhcCAl MCI7DQotI2VuZGlmCSANCisjZW5kaWYNCiAgICAgICB9DQorICAgIGNhc2Ug QkNIRzoNCisgICAgICBvcGVyYW5kc1sxXSA9IGdlbl9ydHggKENPTlNUX0lO VCwgVk9JRG1vZGUsIHVzZV9iY2hnbCAoaSkpOw0KKyNpZiBkZWZpbmVkIChN T1RPUk9MQSkgJiYgIWRlZmluZWQgKENSRFMpDQorICAgICAgcmV0dXJuICJt b3ZlcSUubCAlMSwlMFxuXHRiY2hnJS5sICUwLCUwIjsNCisjZWxzZQ0KKyAg ICAgIHJldHVybiAibW92ZXEgJTEsJTBcblx0YmNoZyAlMCwlMCI7DQorI2Vu ZGlmDQogICAgIGNhc2UgTU9WTCA6DQogCXJldHVybiAibW92ZSUubCAlMSwl MCI7DQogICAgIGRlZmF1bHQgOg0KQEAgLTEyMjAsOSArMTM1NSwxNiBAQA0K ICAgICAgIHJldHVybiBvdXRwdXRfbW92ZV9jb25zdF9pbnRvX2RhdGFfcmVn IChvcGVyYW5kcyk7DQogICBpZiAob3BlcmFuZHNbMV0gIT0gY29uc3QwX3J0 eCkNCiAgICAgcmV0dXJuICJtb3ZlJS5sICUxLCUwIjsNCi0gIGlmICghIEFE RFJFU1NfUkVHX1AgKG9wZXJhbmRzWzBdKSkNCisgIGlmIChEQVRBX1JFR19Q IChvcGVyYW5kc1swXSkpDQorI2lmIGRlZmluZWQgKE1PVE9ST0xBKSAmJiAh ZGVmaW5lZCAoQ1JEUykNCisgICAgcmV0dXJuICJtb3ZlcSUubCAlIzAsJTAi Ow0KKyNlbHNlDQorICAgIHJldHVybiAibW92ZXEgJSMwLCUwIjsNCisjZW5k aWYNCisgIGVsc2UgaWYgKEFERFJFU1NfUkVHX1AgKG9wZXJhbmRzWzBdKSkN CisgICAgcmV0dXJuICJzdWIlLmwgJTAsJTAiOw0KKyAgZWxzZQ0KICAgICBy ZXR1cm4gImNsciUubCAlMCI7DQotICByZXR1cm4gInN1YiUubCAlMCwlMCI7 DQogfQ0KIA0KIA0KQEAgLTIxMTAsNyArMjI1Miw3IEBADQogICAgJy4nIGZv ciBkb3QgbmVlZGVkIGluIE1vdG9yb2xhLXN0eWxlIG9wY29kZSBuYW1lcy4N CiAgICAnLScgZm9yIGFuIG9wZXJhbmQgcHVzaGluZyBvbiB0aGUgc3RhY2s6 DQogICAgICAgIHNwQC0sIC0oc3ApIG9yIC0oJXNwKSBkZXBlbmRpbmcgb24g dGhlIHN0eWxlIG9mIHN5bnRheC4NCi0gICAnKycgZm9yIGFuIG9wZXJhbmQg cHVzaGluZyBvbiB0aGUgc3RhY2s6DQorICAgJysnIGZvciBhbiBvcGVyYW5k IHBvcHBpbmcgb2ZmIHRoZSBzdGFjazoNCiAgICAgICAgc3BAKywgKHNwKSsg b3IgKCVzcCkrIGRlcGVuZGluZyBvbiB0aGUgc3R5bGUgb2Ygc3ludGF4Lg0K ICAgICdAJyBmb3IgYSByZWZlcmVuY2UgdG8gdGhlIHRvcCB3b3JkIG9uIHRo ZSBzdGFjazoNCiAgICAgICAgc3BALCAoc3ApIG9yICglc3ApIGRlcGVuZGlu ZyBvbiB0aGUgc3R5bGUgb2Ygc3ludGF4Lg0K --2010703495-851401618-823799462=:7314 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="opt-128to127.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Test the range [-128, 127] I2luY2x1ZGUgPHN0ZGlvLmg+DQoNCi8qIG1vdmUubCAjeCxEbiAtPiBtb3Zl cS5sICN4LERuLCByYW5nZSBbLTEyOCwgMTI3XS4gKi8NCnNpZ25lZCBsb25n IGludCByXzEyOCAodm9pZCkgeyByZXR1cm4gKC0xMjgpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl8xMjcgKHZvaWQpIHsgcmV0dXJuICgtMTI3KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHJfMTI2ICh2b2lkKSB7IHJldHVybiAoLTEyNik7IH0N CnNpZ25lZCBsb25nIGludCByXzEyNSAodm9pZCkgeyByZXR1cm4gKC0xMjUp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xMjQgKHZvaWQpIHsgcmV0dXJuICgt MTI0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTIzICh2b2lkKSB7IHJldHVy biAoLTEyMyk7IH0NCnNpZ25lZCBsb25nIGludCByXzEyMiAodm9pZCkgeyBy ZXR1cm4gKC0xMjIpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xMjEgKHZvaWQp IHsgcmV0dXJuICgtMTIxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTIwICh2 b2lkKSB7IHJldHVybiAoLTEyMCk7IH0NCnNpZ25lZCBsb25nIGludCByXzEx OSAodm9pZCkgeyByZXR1cm4gKC0xMTkpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl8xMTggKHZvaWQpIHsgcmV0dXJuICgtMTE4KTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHJfMTE3ICh2b2lkKSB7IHJldHVybiAoLTExNyk7IH0NCnNpZ25lZCBs b25nIGludCByXzExNiAodm9pZCkgeyByZXR1cm4gKC0xMTYpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl8xMTUgKHZvaWQpIHsgcmV0dXJuICgtMTE1KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHJfMTE0ICh2b2lkKSB7IHJldHVybiAoLTExNCk7 IH0NCnNpZ25lZCBsb25nIGludCByXzExMyAodm9pZCkgeyByZXR1cm4gKC0x MTMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xMTIgKHZvaWQpIHsgcmV0dXJu ICgtMTEyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTExICh2b2lkKSB7IHJl dHVybiAoLTExMSk7IH0NCnNpZ25lZCBsb25nIGludCByXzExMCAodm9pZCkg eyByZXR1cm4gKC0xMTApOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xMDkgKHZv aWQpIHsgcmV0dXJuICgtMTA5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTA4 ICh2b2lkKSB7IHJldHVybiAoLTEwOCk7IH0NCnNpZ25lZCBsb25nIGludCBy XzEwNyAodm9pZCkgeyByZXR1cm4gKC0xMDcpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl8xMDYgKHZvaWQpIHsgcmV0dXJuICgtMTA2KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHJfMTA1ICh2b2lkKSB7IHJldHVybiAoLTEwNSk7IH0NCnNpZ25l ZCBsb25nIGludCByXzEwNCAodm9pZCkgeyByZXR1cm4gKC0xMDQpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl8xMDMgKHZvaWQpIHsgcmV0dXJuICgtMTAzKTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTAyICh2b2lkKSB7IHJldHVybiAoLTEw Mik7IH0NCnNpZ25lZCBsb25nIGludCByXzEwMSAodm9pZCkgeyByZXR1cm4g KC0xMDEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xMDAgKHZvaWQpIHsgcmV0 dXJuICgtMTAwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfOTkgKHZvaWQpIHsg cmV0dXJuICgtOTkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl85OCAodm9pZCkg eyByZXR1cm4gKC05OCk7IH0NCnNpZ25lZCBsb25nIGludCByXzk3ICh2b2lk KSB7IHJldHVybiAoLTk3KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfOTYgKHZv aWQpIHsgcmV0dXJuICgtOTYpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl85NSAo dm9pZCkgeyByZXR1cm4gKC05NSk7IH0NCnNpZ25lZCBsb25nIGludCByXzk0 ICh2b2lkKSB7IHJldHVybiAoLTk0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJf OTMgKHZvaWQpIHsgcmV0dXJuICgtOTMpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl85MiAodm9pZCkgeyByZXR1cm4gKC05Mik7IH0NCnNpZ25lZCBsb25nIGlu dCByXzkxICh2b2lkKSB7IHJldHVybiAoLTkxKTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHJfOTAgKHZvaWQpIHsgcmV0dXJuICgtOTApOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl84OSAodm9pZCkgeyByZXR1cm4gKC04OSk7IH0NCnNpZ25lZCBs b25nIGludCByXzg4ICh2b2lkKSB7IHJldHVybiAoLTg4KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHJfODcgKHZvaWQpIHsgcmV0dXJuICgtODcpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl84NiAodm9pZCkgeyByZXR1cm4gKC04Nik7IH0NCnNp Z25lZCBsb25nIGludCByXzg1ICh2b2lkKSB7IHJldHVybiAoLTg1KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHJfODQgKHZvaWQpIHsgcmV0dXJuICgtODQpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl84MyAodm9pZCkgeyByZXR1cm4gKC04Myk7 IH0NCnNpZ25lZCBsb25nIGludCByXzgyICh2b2lkKSB7IHJldHVybiAoLTgy KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfODEgKHZvaWQpIHsgcmV0dXJuICgt ODEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl84MCAodm9pZCkgeyByZXR1cm4g KC04MCk7IH0NCnNpZ25lZCBsb25nIGludCByXzc5ICh2b2lkKSB7IHJldHVy biAoLTc5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNzggKHZvaWQpIHsgcmV0 dXJuICgtNzgpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl83NyAodm9pZCkgeyBy ZXR1cm4gKC03Nyk7IH0NCnNpZ25lZCBsb25nIGludCByXzc2ICh2b2lkKSB7 IHJldHVybiAoLTc2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNzUgKHZvaWQp IHsgcmV0dXJuICgtNzUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl83NCAodm9p ZCkgeyByZXR1cm4gKC03NCk7IH0NCnNpZ25lZCBsb25nIGludCByXzczICh2 b2lkKSB7IHJldHVybiAoLTczKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNzIg KHZvaWQpIHsgcmV0dXJuICgtNzIpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl83 MSAodm9pZCkgeyByZXR1cm4gKC03MSk7IH0NCnNpZ25lZCBsb25nIGludCBy XzcwICh2b2lkKSB7IHJldHVybiAoLTcwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHJfNjkgKHZvaWQpIHsgcmV0dXJuICgtNjkpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl82OCAodm9pZCkgeyByZXR1cm4gKC02OCk7IH0NCnNpZ25lZCBsb25n IGludCByXzY3ICh2b2lkKSB7IHJldHVybiAoLTY3KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHJfNjYgKHZvaWQpIHsgcmV0dXJuICgtNjYpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl82NSAodm9pZCkgeyByZXR1cm4gKC02NSk7IH0NCnNpZ25l ZCBsb25nIGludCByXzY0ICh2b2lkKSB7IHJldHVybiAoLTY0KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHJfNjMgKHZvaWQpIHsgcmV0dXJuICgtNjMpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl82MiAodm9pZCkgeyByZXR1cm4gKC02Mik7IH0N CnNpZ25lZCBsb25nIGludCByXzYxICh2b2lkKSB7IHJldHVybiAoLTYxKTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjAgKHZvaWQpIHsgcmV0dXJuICgtNjAp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl81OSAodm9pZCkgeyByZXR1cm4gKC01 OSk7IH0NCnNpZ25lZCBsb25nIGludCByXzU4ICh2b2lkKSB7IHJldHVybiAo LTU4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNTcgKHZvaWQpIHsgcmV0dXJu ICgtNTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl81NiAodm9pZCkgeyByZXR1 cm4gKC01Nik7IH0NCnNpZ25lZCBsb25nIGludCByXzU1ICh2b2lkKSB7IHJl dHVybiAoLTU1KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNTQgKHZvaWQpIHsg cmV0dXJuICgtNTQpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl81MyAodm9pZCkg eyByZXR1cm4gKC01Myk7IH0NCnNpZ25lZCBsb25nIGludCByXzUyICh2b2lk KSB7IHJldHVybiAoLTUyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNTEgKHZv aWQpIHsgcmV0dXJuICgtNTEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl81MCAo dm9pZCkgeyByZXR1cm4gKC01MCk7IH0NCnNpZ25lZCBsb25nIGludCByXzQ5 ICh2b2lkKSB7IHJldHVybiAoLTQ5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJf NDggKHZvaWQpIHsgcmV0dXJuICgtNDgpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl80NyAodm9pZCkgeyByZXR1cm4gKC00Nyk7IH0NCnNpZ25lZCBsb25nIGlu dCByXzQ2ICh2b2lkKSB7IHJldHVybiAoLTQ2KTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHJfNDUgKHZvaWQpIHsgcmV0dXJuICgtNDUpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl80NCAodm9pZCkgeyByZXR1cm4gKC00NCk7IH0NCnNpZ25lZCBs b25nIGludCByXzQzICh2b2lkKSB7IHJldHVybiAoLTQzKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHJfNDIgKHZvaWQpIHsgcmV0dXJuICgtNDIpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl80MSAodm9pZCkgeyByZXR1cm4gKC00MSk7IH0NCnNp Z25lZCBsb25nIGludCByXzQwICh2b2lkKSB7IHJldHVybiAoLTQwKTsgfQ0K c2lnbmVkIGxvbmcgaW50IHJfMzkgKHZvaWQpIHsgcmV0dXJuICgtMzkpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl8zOCAodm9pZCkgeyByZXR1cm4gKC0zOCk7 IH0NCnNpZ25lZCBsb25nIGludCByXzM3ICh2b2lkKSB7IHJldHVybiAoLTM3 KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMzYgKHZvaWQpIHsgcmV0dXJuICgt MzYpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8zNSAodm9pZCkgeyByZXR1cm4g KC0zNSk7IH0NCnNpZ25lZCBsb25nIGludCByXzM0ICh2b2lkKSB7IHJldHVy biAoLTM0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMzMgKHZvaWQpIHsgcmV0 dXJuICgtMzMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8zMiAodm9pZCkgeyBy ZXR1cm4gKC0zMik7IH0NCnNpZ25lZCBsb25nIGludCByXzMxICh2b2lkKSB7 IHJldHVybiAoLTMxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMzAgKHZvaWQp IHsgcmV0dXJuICgtMzApOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yOSAodm9p ZCkgeyByZXR1cm4gKC0yOSk7IH0NCnNpZ25lZCBsb25nIGludCByXzI4ICh2 b2lkKSB7IHJldHVybiAoLTI4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMjcg KHZvaWQpIHsgcmV0dXJuICgtMjcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8y NiAodm9pZCkgeyByZXR1cm4gKC0yNik7IH0NCnNpZ25lZCBsb25nIGludCBy XzI1ICh2b2lkKSB7IHJldHVybiAoLTI1KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHJfMjQgKHZvaWQpIHsgcmV0dXJuICgtMjQpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl8yMyAodm9pZCkgeyByZXR1cm4gKC0yMyk7IH0NCnNpZ25lZCBsb25n IGludCByXzIyICh2b2lkKSB7IHJldHVybiAoLTIyKTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHJfMjEgKHZvaWQpIHsgcmV0dXJuICgtMjEpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl8yMCAodm9pZCkgeyByZXR1cm4gKC0yMCk7IH0NCnNpZ25l ZCBsb25nIGludCByXzE5ICh2b2lkKSB7IHJldHVybiAoLTE5KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHJfMTggKHZvaWQpIHsgcmV0dXJuICgtMTgpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl8xNyAodm9pZCkgeyByZXR1cm4gKC0xNyk7IH0N CnNpZ25lZCBsb25nIGludCByXzE2ICh2b2lkKSB7IHJldHVybiAoLTE2KTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTUgKHZvaWQpIHsgcmV0dXJuICgtMTUp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xNCAodm9pZCkgeyByZXR1cm4gKC0x NCk7IH0NCnNpZ25lZCBsb25nIGludCByXzEzICh2b2lkKSB7IHJldHVybiAo LTEzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTIgKHZvaWQpIHsgcmV0dXJu ICgtMTIpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xMSAodm9pZCkgeyByZXR1 cm4gKC0xMSk7IH0NCnNpZ25lZCBsb25nIGludCByXzEwICh2b2lkKSB7IHJl dHVybiAoLTEwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfOSAodm9pZCkgeyBy ZXR1cm4gKC05KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfOCAodm9pZCkgeyBy ZXR1cm4gKC04KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNyAodm9pZCkgeyBy ZXR1cm4gKC03KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNiAodm9pZCkgeyBy ZXR1cm4gKC02KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNSAodm9pZCkgeyBy ZXR1cm4gKC01KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNCAodm9pZCkgeyBy ZXR1cm4gKC00KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMyAodm9pZCkgeyBy ZXR1cm4gKC0zKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMiAodm9pZCkgeyBy ZXR1cm4gKC0yKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMSAodm9pZCkgeyBy ZXR1cm4gKC0xKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIwICh2b2lkKSB7IHJl dHVybiAoMCk7IH0NCnNpZ25lZCBsb25nIGludCByMSAodm9pZCkgeyByZXR1 cm4gKDEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjIgKHZvaWQpIHsgcmV0dXJu ICgyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIzICh2b2lkKSB7IHJldHVybiAo Myk7IH0NCnNpZ25lZCBsb25nIGludCByNCAodm9pZCkgeyByZXR1cm4gKDQp OyB9DQpzaWduZWQgbG9uZyBpbnQgcjUgKHZvaWQpIHsgcmV0dXJuICg1KTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHI2ICh2b2lkKSB7IHJldHVybiAoNik7IH0N CnNpZ25lZCBsb25nIGludCByNyAodm9pZCkgeyByZXR1cm4gKDcpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjggKHZvaWQpIHsgcmV0dXJuICg4KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHI5ICh2b2lkKSB7IHJldHVybiAoOSk7IH0NCnNpZ25l ZCBsb25nIGludCByMTAgKHZvaWQpIHsgcmV0dXJuICgxMCk7IH0NCnNpZ25l ZCBsb25nIGludCByMTEgKHZvaWQpIHsgcmV0dXJuICgxMSk7IH0NCnNpZ25l ZCBsb25nIGludCByMTIgKHZvaWQpIHsgcmV0dXJuICgxMik7IH0NCnNpZ25l ZCBsb25nIGludCByMTMgKHZvaWQpIHsgcmV0dXJuICgxMyk7IH0NCnNpZ25l ZCBsb25nIGludCByMTQgKHZvaWQpIHsgcmV0dXJuICgxNCk7IH0NCnNpZ25l ZCBsb25nIGludCByMTUgKHZvaWQpIHsgcmV0dXJuICgxNSk7IH0NCnNpZ25l ZCBsb25nIGludCByMTYgKHZvaWQpIHsgcmV0dXJuICgxNik7IH0NCnNpZ25l ZCBsb25nIGludCByMTcgKHZvaWQpIHsgcmV0dXJuICgxNyk7IH0NCnNpZ25l ZCBsb25nIGludCByMTggKHZvaWQpIHsgcmV0dXJuICgxOCk7IH0NCnNpZ25l ZCBsb25nIGludCByMTkgKHZvaWQpIHsgcmV0dXJuICgxOSk7IH0NCnNpZ25l ZCBsb25nIGludCByMjAgKHZvaWQpIHsgcmV0dXJuICgyMCk7IH0NCnNpZ25l ZCBsb25nIGludCByMjEgKHZvaWQpIHsgcmV0dXJuICgyMSk7IH0NCnNpZ25l ZCBsb25nIGludCByMjIgKHZvaWQpIHsgcmV0dXJuICgyMik7IH0NCnNpZ25l ZCBsb25nIGludCByMjMgKHZvaWQpIHsgcmV0dXJuICgyMyk7IH0NCnNpZ25l ZCBsb25nIGludCByMjQgKHZvaWQpIHsgcmV0dXJuICgyNCk7IH0NCnNpZ25l ZCBsb25nIGludCByMjUgKHZvaWQpIHsgcmV0dXJuICgyNSk7IH0NCnNpZ25l ZCBsb25nIGludCByMjYgKHZvaWQpIHsgcmV0dXJuICgyNik7IH0NCnNpZ25l ZCBsb25nIGludCByMjcgKHZvaWQpIHsgcmV0dXJuICgyNyk7IH0NCnNpZ25l ZCBsb25nIGludCByMjggKHZvaWQpIHsgcmV0dXJuICgyOCk7IH0NCnNpZ25l ZCBsb25nIGludCByMjkgKHZvaWQpIHsgcmV0dXJuICgyOSk7IH0NCnNpZ25l ZCBsb25nIGludCByMzAgKHZvaWQpIHsgcmV0dXJuICgzMCk7IH0NCnNpZ25l ZCBsb25nIGludCByMzEgKHZvaWQpIHsgcmV0dXJuICgzMSk7IH0NCnNpZ25l ZCBsb25nIGludCByMzIgKHZvaWQpIHsgcmV0dXJuICgzMik7IH0NCnNpZ25l ZCBsb25nIGludCByMzMgKHZvaWQpIHsgcmV0dXJuICgzMyk7IH0NCnNpZ25l ZCBsb25nIGludCByMzQgKHZvaWQpIHsgcmV0dXJuICgzNCk7IH0NCnNpZ25l ZCBsb25nIGludCByMzUgKHZvaWQpIHsgcmV0dXJuICgzNSk7IH0NCnNpZ25l ZCBsb25nIGludCByMzYgKHZvaWQpIHsgcmV0dXJuICgzNik7IH0NCnNpZ25l ZCBsb25nIGludCByMzcgKHZvaWQpIHsgcmV0dXJuICgzNyk7IH0NCnNpZ25l ZCBsb25nIGludCByMzggKHZvaWQpIHsgcmV0dXJuICgzOCk7IH0NCnNpZ25l ZCBsb25nIGludCByMzkgKHZvaWQpIHsgcmV0dXJuICgzOSk7IH0NCnNpZ25l ZCBsb25nIGludCByNDAgKHZvaWQpIHsgcmV0dXJuICg0MCk7IH0NCnNpZ25l ZCBsb25nIGludCByNDEgKHZvaWQpIHsgcmV0dXJuICg0MSk7IH0NCnNpZ25l ZCBsb25nIGludCByNDIgKHZvaWQpIHsgcmV0dXJuICg0Mik7IH0NCnNpZ25l ZCBsb25nIGludCByNDMgKHZvaWQpIHsgcmV0dXJuICg0Myk7IH0NCnNpZ25l ZCBsb25nIGludCByNDQgKHZvaWQpIHsgcmV0dXJuICg0NCk7IH0NCnNpZ25l ZCBsb25nIGludCByNDUgKHZvaWQpIHsgcmV0dXJuICg0NSk7IH0NCnNpZ25l ZCBsb25nIGludCByNDYgKHZvaWQpIHsgcmV0dXJuICg0Nik7IH0NCnNpZ25l ZCBsb25nIGludCByNDcgKHZvaWQpIHsgcmV0dXJuICg0Nyk7IH0NCnNpZ25l ZCBsb25nIGludCByNDggKHZvaWQpIHsgcmV0dXJuICg0OCk7IH0NCnNpZ25l ZCBsb25nIGludCByNDkgKHZvaWQpIHsgcmV0dXJuICg0OSk7IH0NCnNpZ25l ZCBsb25nIGludCByNTAgKHZvaWQpIHsgcmV0dXJuICg1MCk7IH0NCnNpZ25l ZCBsb25nIGludCByNTEgKHZvaWQpIHsgcmV0dXJuICg1MSk7IH0NCnNpZ25l ZCBsb25nIGludCByNTIgKHZvaWQpIHsgcmV0dXJuICg1Mik7IH0NCnNpZ25l ZCBsb25nIGludCByNTMgKHZvaWQpIHsgcmV0dXJuICg1Myk7IH0NCnNpZ25l ZCBsb25nIGludCByNTQgKHZvaWQpIHsgcmV0dXJuICg1NCk7IH0NCnNpZ25l ZCBsb25nIGludCByNTUgKHZvaWQpIHsgcmV0dXJuICg1NSk7IH0NCnNpZ25l ZCBsb25nIGludCByNTYgKHZvaWQpIHsgcmV0dXJuICg1Nik7IH0NCnNpZ25l ZCBsb25nIGludCByNTcgKHZvaWQpIHsgcmV0dXJuICg1Nyk7IH0NCnNpZ25l ZCBsb25nIGludCByNTggKHZvaWQpIHsgcmV0dXJuICg1OCk7IH0NCnNpZ25l ZCBsb25nIGludCByNTkgKHZvaWQpIHsgcmV0dXJuICg1OSk7IH0NCnNpZ25l ZCBsb25nIGludCByNjAgKHZvaWQpIHsgcmV0dXJuICg2MCk7IH0NCnNpZ25l ZCBsb25nIGludCByNjEgKHZvaWQpIHsgcmV0dXJuICg2MSk7IH0NCnNpZ25l ZCBsb25nIGludCByNjIgKHZvaWQpIHsgcmV0dXJuICg2Mik7IH0NCnNpZ25l ZCBsb25nIGludCByNjMgKHZvaWQpIHsgcmV0dXJuICg2Myk7IH0NCnNpZ25l ZCBsb25nIGludCByNjQgKHZvaWQpIHsgcmV0dXJuICg2NCk7IH0NCnNpZ25l ZCBsb25nIGludCByNjUgKHZvaWQpIHsgcmV0dXJuICg2NSk7IH0NCnNpZ25l ZCBsb25nIGludCByNjYgKHZvaWQpIHsgcmV0dXJuICg2Nik7IH0NCnNpZ25l ZCBsb25nIGludCByNjcgKHZvaWQpIHsgcmV0dXJuICg2Nyk7IH0NCnNpZ25l ZCBsb25nIGludCByNjggKHZvaWQpIHsgcmV0dXJuICg2OCk7IH0NCnNpZ25l ZCBsb25nIGludCByNjkgKHZvaWQpIHsgcmV0dXJuICg2OSk7IH0NCnNpZ25l ZCBsb25nIGludCByNzAgKHZvaWQpIHsgcmV0dXJuICg3MCk7IH0NCnNpZ25l ZCBsb25nIGludCByNzEgKHZvaWQpIHsgcmV0dXJuICg3MSk7IH0NCnNpZ25l ZCBsb25nIGludCByNzIgKHZvaWQpIHsgcmV0dXJuICg3Mik7IH0NCnNpZ25l ZCBsb25nIGludCByNzMgKHZvaWQpIHsgcmV0dXJuICg3Myk7IH0NCnNpZ25l ZCBsb25nIGludCByNzQgKHZvaWQpIHsgcmV0dXJuICg3NCk7IH0NCnNpZ25l ZCBsb25nIGludCByNzUgKHZvaWQpIHsgcmV0dXJuICg3NSk7IH0NCnNpZ25l ZCBsb25nIGludCByNzYgKHZvaWQpIHsgcmV0dXJuICg3Nik7IH0NCnNpZ25l ZCBsb25nIGludCByNzcgKHZvaWQpIHsgcmV0dXJuICg3Nyk7IH0NCnNpZ25l ZCBsb25nIGludCByNzggKHZvaWQpIHsgcmV0dXJuICg3OCk7IH0NCnNpZ25l ZCBsb25nIGludCByNzkgKHZvaWQpIHsgcmV0dXJuICg3OSk7IH0NCnNpZ25l ZCBsb25nIGludCByODAgKHZvaWQpIHsgcmV0dXJuICg4MCk7IH0NCnNpZ25l ZCBsb25nIGludCByODEgKHZvaWQpIHsgcmV0dXJuICg4MSk7IH0NCnNpZ25l ZCBsb25nIGludCByODIgKHZvaWQpIHsgcmV0dXJuICg4Mik7IH0NCnNpZ25l ZCBsb25nIGludCByODMgKHZvaWQpIHsgcmV0dXJuICg4Myk7IH0NCnNpZ25l ZCBsb25nIGludCByODQgKHZvaWQpIHsgcmV0dXJuICg4NCk7IH0NCnNpZ25l ZCBsb25nIGludCByODUgKHZvaWQpIHsgcmV0dXJuICg4NSk7IH0NCnNpZ25l ZCBsb25nIGludCByODYgKHZvaWQpIHsgcmV0dXJuICg4Nik7IH0NCnNpZ25l ZCBsb25nIGludCByODcgKHZvaWQpIHsgcmV0dXJuICg4Nyk7IH0NCnNpZ25l ZCBsb25nIGludCByODggKHZvaWQpIHsgcmV0dXJuICg4OCk7IH0NCnNpZ25l ZCBsb25nIGludCByODkgKHZvaWQpIHsgcmV0dXJuICg4OSk7IH0NCnNpZ25l ZCBsb25nIGludCByOTAgKHZvaWQpIHsgcmV0dXJuICg5MCk7IH0NCnNpZ25l ZCBsb25nIGludCByOTEgKHZvaWQpIHsgcmV0dXJuICg5MSk7IH0NCnNpZ25l ZCBsb25nIGludCByOTIgKHZvaWQpIHsgcmV0dXJuICg5Mik7IH0NCnNpZ25l ZCBsb25nIGludCByOTMgKHZvaWQpIHsgcmV0dXJuICg5Myk7IH0NCnNpZ25l ZCBsb25nIGludCByOTQgKHZvaWQpIHsgcmV0dXJuICg5NCk7IH0NCnNpZ25l ZCBsb25nIGludCByOTUgKHZvaWQpIHsgcmV0dXJuICg5NSk7IH0NCnNpZ25l ZCBsb25nIGludCByOTYgKHZvaWQpIHsgcmV0dXJuICg5Nik7IH0NCnNpZ25l ZCBsb25nIGludCByOTcgKHZvaWQpIHsgcmV0dXJuICg5Nyk7IH0NCnNpZ25l ZCBsb25nIGludCByOTggKHZvaWQpIHsgcmV0dXJuICg5OCk7IH0NCnNpZ25l ZCBsb25nIGludCByOTkgKHZvaWQpIHsgcmV0dXJuICg5OSk7IH0NCnNpZ25l ZCBsb25nIGludCByMTAwICh2b2lkKSB7IHJldHVybiAoMTAwKTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHIxMDEgKHZvaWQpIHsgcmV0dXJuICgxMDEpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjEwMiAodm9pZCkgeyByZXR1cm4gKDEwMik7IH0N CnNpZ25lZCBsb25nIGludCByMTAzICh2b2lkKSB7IHJldHVybiAoMTAzKTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHIxMDQgKHZvaWQpIHsgcmV0dXJuICgxMDQp OyB9DQpzaWduZWQgbG9uZyBpbnQgcjEwNSAodm9pZCkgeyByZXR1cm4gKDEw NSk7IH0NCnNpZ25lZCBsb25nIGludCByMTA2ICh2b2lkKSB7IHJldHVybiAo MTA2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxMDcgKHZvaWQpIHsgcmV0dXJu ICgxMDcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjEwOCAodm9pZCkgeyByZXR1 cm4gKDEwOCk7IH0NCnNpZ25lZCBsb25nIGludCByMTA5ICh2b2lkKSB7IHJl dHVybiAoMTA5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxMTAgKHZvaWQpIHsg cmV0dXJuICgxMTApOyB9DQpzaWduZWQgbG9uZyBpbnQgcjExMSAodm9pZCkg eyByZXR1cm4gKDExMSk7IH0NCnNpZ25lZCBsb25nIGludCByMTEyICh2b2lk KSB7IHJldHVybiAoMTEyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxMTMgKHZv aWQpIHsgcmV0dXJuICgxMTMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjExNCAo dm9pZCkgeyByZXR1cm4gKDExNCk7IH0NCnNpZ25lZCBsb25nIGludCByMTE1 ICh2b2lkKSB7IHJldHVybiAoMTE1KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIx MTYgKHZvaWQpIHsgcmV0dXJuICgxMTYpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjExNyAodm9pZCkgeyByZXR1cm4gKDExNyk7IH0NCnNpZ25lZCBsb25nIGlu dCByMTE4ICh2b2lkKSB7IHJldHVybiAoMTE4KTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHIxMTkgKHZvaWQpIHsgcmV0dXJuICgxMTkpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcjEyMCAodm9pZCkgeyByZXR1cm4gKDEyMCk7IH0NCnNpZ25lZCBs b25nIGludCByMTIxICh2b2lkKSB7IHJldHVybiAoMTIxKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHIxMjIgKHZvaWQpIHsgcmV0dXJuICgxMjIpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcjEyMyAodm9pZCkgeyByZXR1cm4gKDEyMyk7IH0NCnNp Z25lZCBsb25nIGludCByMTI0ICh2b2lkKSB7IHJldHVybiAoMTI0KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHIxMjUgKHZvaWQpIHsgcmV0dXJuICgxMjUpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcjEyNiAodm9pZCkgeyByZXR1cm4gKDEyNik7 IH0NCnNpZ25lZCBsb25nIGludCByMTI3ICh2b2lkKSB7IHJldHVybiAoMTI3 KTsgfQ0KDQovKiBtb3ZlLmwgI3gsRG4gLT4gbW92ZXEubCAjeCxEbiwgcmFu Z2UgWy0xMjgsIDEyN10uICovDQoNCmludCBtYWluIChpbnQgYXJnYywgY2hh ciAqYXJndltdKQ0Kew0KcHJpbnRmICgiLTEyOCA9ICVsZFxuIiwgcl8xMjgg KCkpOw0KcHJpbnRmICgiLTEyNyA9ICVsZFxuIiwgcl8xMjcgKCkpOw0KcHJp bnRmICgiLTEyNiA9ICVsZFxuIiwgcl8xMjYgKCkpOw0KcHJpbnRmICgiLTEy NSA9ICVsZFxuIiwgcl8xMjUgKCkpOw0KcHJpbnRmICgiLTEyNCA9ICVsZFxu Iiwgcl8xMjQgKCkpOw0KcHJpbnRmICgiLTEyMyA9ICVsZFxuIiwgcl8xMjMg KCkpOw0KcHJpbnRmICgiLTEyMiA9ICVsZFxuIiwgcl8xMjIgKCkpOw0KcHJp bnRmICgiLTEyMSA9ICVsZFxuIiwgcl8xMjEgKCkpOw0KcHJpbnRmICgiLTEy MCA9ICVsZFxuIiwgcl8xMjAgKCkpOw0KcHJpbnRmICgiLTExOSA9ICVsZFxu Iiwgcl8xMTkgKCkpOw0KcHJpbnRmICgiLTExOCA9ICVsZFxuIiwgcl8xMTgg KCkpOw0KcHJpbnRmICgiLTExNyA9ICVsZFxuIiwgcl8xMTcgKCkpOw0KcHJp bnRmICgiLTExNiA9ICVsZFxuIiwgcl8xMTYgKCkpOw0KcHJpbnRmICgiLTEx NSA9ICVsZFxuIiwgcl8xMTUgKCkpOw0KcHJpbnRmICgiLTExNCA9ICVsZFxu Iiwgcl8xMTQgKCkpOw0KcHJpbnRmICgiLTExMyA9ICVsZFxuIiwgcl8xMTMg KCkpOw0KcHJpbnRmICgiLTExMiA9ICVsZFxuIiwgcl8xMTIgKCkpOw0KcHJp bnRmICgiLTExMSA9ICVsZFxuIiwgcl8xMTEgKCkpOw0KcHJpbnRmICgiLTEx MCA9ICVsZFxuIiwgcl8xMTAgKCkpOw0KcHJpbnRmICgiLTEwOSA9ICVsZFxu Iiwgcl8xMDkgKCkpOw0KcHJpbnRmICgiLTEwOCA9ICVsZFxuIiwgcl8xMDgg KCkpOw0KcHJpbnRmICgiLTEwNyA9ICVsZFxuIiwgcl8xMDcgKCkpOw0KcHJp bnRmICgiLTEwNiA9ICVsZFxuIiwgcl8xMDYgKCkpOw0KcHJpbnRmICgiLTEw NSA9ICVsZFxuIiwgcl8xMDUgKCkpOw0KcHJpbnRmICgiLTEwNCA9ICVsZFxu Iiwgcl8xMDQgKCkpOw0KcHJpbnRmICgiLTEwMyA9ICVsZFxuIiwgcl8xMDMg KCkpOw0KcHJpbnRmICgiLTEwMiA9ICVsZFxuIiwgcl8xMDIgKCkpOw0KcHJp bnRmICgiLTEwMSA9ICVsZFxuIiwgcl8xMDEgKCkpOw0KcHJpbnRmICgiLTEw MCA9ICVsZFxuIiwgcl8xMDAgKCkpOw0KcHJpbnRmICgiLTk5ID0gJWxkXG4i LCByXzk5ICgpKTsNCnByaW50ZiAoIi05OCA9ICVsZFxuIiwgcl85OCAoKSk7 DQpwcmludGYgKCItOTcgPSAlbGRcbiIsIHJfOTcgKCkpOw0KcHJpbnRmICgi LTk2ID0gJWxkXG4iLCByXzk2ICgpKTsNCnByaW50ZiAoIi05NSA9ICVsZFxu Iiwgcl85NSAoKSk7DQpwcmludGYgKCItOTQgPSAlbGRcbiIsIHJfOTQgKCkp Ow0KcHJpbnRmICgiLTkzID0gJWxkXG4iLCByXzkzICgpKTsNCnByaW50ZiAo Ii05MiA9ICVsZFxuIiwgcl85MiAoKSk7DQpwcmludGYgKCItOTEgPSAlbGRc biIsIHJfOTEgKCkpOw0KcHJpbnRmICgiLTkwID0gJWxkXG4iLCByXzkwICgp KTsNCnByaW50ZiAoIi04OSA9ICVsZFxuIiwgcl84OSAoKSk7DQpwcmludGYg KCItODggPSAlbGRcbiIsIHJfODggKCkpOw0KcHJpbnRmICgiLTg3ID0gJWxk XG4iLCByXzg3ICgpKTsNCnByaW50ZiAoIi04NiA9ICVsZFxuIiwgcl84NiAo KSk7DQpwcmludGYgKCItODUgPSAlbGRcbiIsIHJfODUgKCkpOw0KcHJpbnRm ICgiLTg0ID0gJWxkXG4iLCByXzg0ICgpKTsNCnByaW50ZiAoIi04MyA9ICVs ZFxuIiwgcl84MyAoKSk7DQpwcmludGYgKCItODIgPSAlbGRcbiIsIHJfODIg KCkpOw0KcHJpbnRmICgiLTgxID0gJWxkXG4iLCByXzgxICgpKTsNCnByaW50 ZiAoIi04MCA9ICVsZFxuIiwgcl84MCAoKSk7DQpwcmludGYgKCItNzkgPSAl bGRcbiIsIHJfNzkgKCkpOw0KcHJpbnRmICgiLTc4ID0gJWxkXG4iLCByXzc4 ICgpKTsNCnByaW50ZiAoIi03NyA9ICVsZFxuIiwgcl83NyAoKSk7DQpwcmlu dGYgKCItNzYgPSAlbGRcbiIsIHJfNzYgKCkpOw0KcHJpbnRmICgiLTc1ID0g JWxkXG4iLCByXzc1ICgpKTsNCnByaW50ZiAoIi03NCA9ICVsZFxuIiwgcl83 NCAoKSk7DQpwcmludGYgKCItNzMgPSAlbGRcbiIsIHJfNzMgKCkpOw0KcHJp bnRmICgiLTcyID0gJWxkXG4iLCByXzcyICgpKTsNCnByaW50ZiAoIi03MSA9 ICVsZFxuIiwgcl83MSAoKSk7DQpwcmludGYgKCItNzAgPSAlbGRcbiIsIHJf NzAgKCkpOw0KcHJpbnRmICgiLTY5ID0gJWxkXG4iLCByXzY5ICgpKTsNCnBy aW50ZiAoIi02OCA9ICVsZFxuIiwgcl82OCAoKSk7DQpwcmludGYgKCItNjcg PSAlbGRcbiIsIHJfNjcgKCkpOw0KcHJpbnRmICgiLTY2ID0gJWxkXG4iLCBy XzY2ICgpKTsNCnByaW50ZiAoIi02NSA9ICVsZFxuIiwgcl82NSAoKSk7DQpw cmludGYgKCItNjQgPSAlbGRcbiIsIHJfNjQgKCkpOw0KcHJpbnRmICgiLTYz ID0gJWxkXG4iLCByXzYzICgpKTsNCnByaW50ZiAoIi02MiA9ICVsZFxuIiwg cl82MiAoKSk7DQpwcmludGYgKCItNjEgPSAlbGRcbiIsIHJfNjEgKCkpOw0K cHJpbnRmICgiLTYwID0gJWxkXG4iLCByXzYwICgpKTsNCnByaW50ZiAoIi01 OSA9ICVsZFxuIiwgcl81OSAoKSk7DQpwcmludGYgKCItNTggPSAlbGRcbiIs IHJfNTggKCkpOw0KcHJpbnRmICgiLTU3ID0gJWxkXG4iLCByXzU3ICgpKTsN CnByaW50ZiAoIi01NiA9ICVsZFxuIiwgcl81NiAoKSk7DQpwcmludGYgKCIt NTUgPSAlbGRcbiIsIHJfNTUgKCkpOw0KcHJpbnRmICgiLTU0ID0gJWxkXG4i LCByXzU0ICgpKTsNCnByaW50ZiAoIi01MyA9ICVsZFxuIiwgcl81MyAoKSk7 DQpwcmludGYgKCItNTIgPSAlbGRcbiIsIHJfNTIgKCkpOw0KcHJpbnRmICgi LTUxID0gJWxkXG4iLCByXzUxICgpKTsNCnByaW50ZiAoIi01MCA9ICVsZFxu Iiwgcl81MCAoKSk7DQpwcmludGYgKCItNDkgPSAlbGRcbiIsIHJfNDkgKCkp Ow0KcHJpbnRmICgiLTQ4ID0gJWxkXG4iLCByXzQ4ICgpKTsNCnByaW50ZiAo Ii00NyA9ICVsZFxuIiwgcl80NyAoKSk7DQpwcmludGYgKCItNDYgPSAlbGRc biIsIHJfNDYgKCkpOw0KcHJpbnRmICgiLTQ1ID0gJWxkXG4iLCByXzQ1ICgp KTsNCnByaW50ZiAoIi00NCA9ICVsZFxuIiwgcl80NCAoKSk7DQpwcmludGYg KCItNDMgPSAlbGRcbiIsIHJfNDMgKCkpOw0KcHJpbnRmICgiLTQyID0gJWxk XG4iLCByXzQyICgpKTsNCnByaW50ZiAoIi00MSA9ICVsZFxuIiwgcl80MSAo KSk7DQpwcmludGYgKCItNDAgPSAlbGRcbiIsIHJfNDAgKCkpOw0KcHJpbnRm ICgiLTM5ID0gJWxkXG4iLCByXzM5ICgpKTsNCnByaW50ZiAoIi0zOCA9ICVs ZFxuIiwgcl8zOCAoKSk7DQpwcmludGYgKCItMzcgPSAlbGRcbiIsIHJfMzcg KCkpOw0KcHJpbnRmICgiLTM2ID0gJWxkXG4iLCByXzM2ICgpKTsNCnByaW50 ZiAoIi0zNSA9ICVsZFxuIiwgcl8zNSAoKSk7DQpwcmludGYgKCItMzQgPSAl bGRcbiIsIHJfMzQgKCkpOw0KcHJpbnRmICgiLTMzID0gJWxkXG4iLCByXzMz ICgpKTsNCnByaW50ZiAoIi0zMiA9ICVsZFxuIiwgcl8zMiAoKSk7DQpwcmlu dGYgKCItMzEgPSAlbGRcbiIsIHJfMzEgKCkpOw0KcHJpbnRmICgiLTMwID0g JWxkXG4iLCByXzMwICgpKTsNCnByaW50ZiAoIi0yOSA9ICVsZFxuIiwgcl8y OSAoKSk7DQpwcmludGYgKCItMjggPSAlbGRcbiIsIHJfMjggKCkpOw0KcHJp bnRmICgiLTI3ID0gJWxkXG4iLCByXzI3ICgpKTsNCnByaW50ZiAoIi0yNiA9 ICVsZFxuIiwgcl8yNiAoKSk7DQpwcmludGYgKCItMjUgPSAlbGRcbiIsIHJf MjUgKCkpOw0KcHJpbnRmICgiLTI0ID0gJWxkXG4iLCByXzI0ICgpKTsNCnBy aW50ZiAoIi0yMyA9ICVsZFxuIiwgcl8yMyAoKSk7DQpwcmludGYgKCItMjIg PSAlbGRcbiIsIHJfMjIgKCkpOw0KcHJpbnRmICgiLTIxID0gJWxkXG4iLCBy XzIxICgpKTsNCnByaW50ZiAoIi0yMCA9ICVsZFxuIiwgcl8yMCAoKSk7DQpw cmludGYgKCItMTkgPSAlbGRcbiIsIHJfMTkgKCkpOw0KcHJpbnRmICgiLTE4 ID0gJWxkXG4iLCByXzE4ICgpKTsNCnByaW50ZiAoIi0xNyA9ICVsZFxuIiwg cl8xNyAoKSk7DQpwcmludGYgKCItMTYgPSAlbGRcbiIsIHJfMTYgKCkpOw0K cHJpbnRmICgiLTE1ID0gJWxkXG4iLCByXzE1ICgpKTsNCnByaW50ZiAoIi0x NCA9ICVsZFxuIiwgcl8xNCAoKSk7DQpwcmludGYgKCItMTMgPSAlbGRcbiIs IHJfMTMgKCkpOw0KcHJpbnRmICgiLTEyID0gJWxkXG4iLCByXzEyICgpKTsN CnByaW50ZiAoIi0xMSA9ICVsZFxuIiwgcl8xMSAoKSk7DQpwcmludGYgKCIt MTAgPSAlbGRcbiIsIHJfMTAgKCkpOw0KcHJpbnRmICgiLTkgPSAlbGRcbiIs IHJfOSAoKSk7DQpwcmludGYgKCItOCA9ICVsZFxuIiwgcl84ICgpKTsNCnBy aW50ZiAoIi03ID0gJWxkXG4iLCByXzcgKCkpOw0KcHJpbnRmICgiLTYgPSAl bGRcbiIsIHJfNiAoKSk7DQpwcmludGYgKCItNSA9ICVsZFxuIiwgcl81ICgp KTsNCnByaW50ZiAoIi00ID0gJWxkXG4iLCByXzQgKCkpOw0KcHJpbnRmICgi LTMgPSAlbGRcbiIsIHJfMyAoKSk7DQpwcmludGYgKCItMiA9ICVsZFxuIiwg cl8yICgpKTsNCnByaW50ZiAoIi0xID0gJWxkXG4iLCByXzEgKCkpOw0KcHJp bnRmICgiMCA9ICVsZFxuIiwgcjAgKCkpOw0KcHJpbnRmICgiMSA9ICVsZFxu IiwgcjEgKCkpOw0KcHJpbnRmICgiMiA9ICVsZFxuIiwgcjIgKCkpOw0KcHJp bnRmICgiMyA9ICVsZFxuIiwgcjMgKCkpOw0KcHJpbnRmICgiNCA9ICVsZFxu IiwgcjQgKCkpOw0KcHJpbnRmICgiNSA9ICVsZFxuIiwgcjUgKCkpOw0KcHJp bnRmICgiNiA9ICVsZFxuIiwgcjYgKCkpOw0KcHJpbnRmICgiNyA9ICVsZFxu IiwgcjcgKCkpOw0KcHJpbnRmICgiOCA9ICVsZFxuIiwgcjggKCkpOw0KcHJp bnRmICgiOSA9ICVsZFxuIiwgcjkgKCkpOw0KcHJpbnRmICgiMTAgPSAlbGRc biIsIHIxMCAoKSk7DQpwcmludGYgKCIxMSA9ICVsZFxuIiwgcjExICgpKTsN CnByaW50ZiAoIjEyID0gJWxkXG4iLCByMTIgKCkpOw0KcHJpbnRmICgiMTMg PSAlbGRcbiIsIHIxMyAoKSk7DQpwcmludGYgKCIxNCA9ICVsZFxuIiwgcjE0 ICgpKTsNCnByaW50ZiAoIjE1ID0gJWxkXG4iLCByMTUgKCkpOw0KcHJpbnRm ICgiMTYgPSAlbGRcbiIsIHIxNiAoKSk7DQpwcmludGYgKCIxNyA9ICVsZFxu IiwgcjE3ICgpKTsNCnByaW50ZiAoIjE4ID0gJWxkXG4iLCByMTggKCkpOw0K cHJpbnRmICgiMTkgPSAlbGRcbiIsIHIxOSAoKSk7DQpwcmludGYgKCIyMCA9 ICVsZFxuIiwgcjIwICgpKTsNCnByaW50ZiAoIjIxID0gJWxkXG4iLCByMjEg KCkpOw0KcHJpbnRmICgiMjIgPSAlbGRcbiIsIHIyMiAoKSk7DQpwcmludGYg KCIyMyA9ICVsZFxuIiwgcjIzICgpKTsNCnByaW50ZiAoIjI0ID0gJWxkXG4i LCByMjQgKCkpOw0KcHJpbnRmICgiMjUgPSAlbGRcbiIsIHIyNSAoKSk7DQpw cmludGYgKCIyNiA9ICVsZFxuIiwgcjI2ICgpKTsNCnByaW50ZiAoIjI3ID0g JWxkXG4iLCByMjcgKCkpOw0KcHJpbnRmICgiMjggPSAlbGRcbiIsIHIyOCAo KSk7DQpwcmludGYgKCIyOSA9ICVsZFxuIiwgcjI5ICgpKTsNCnByaW50ZiAo IjMwID0gJWxkXG4iLCByMzAgKCkpOw0KcHJpbnRmICgiMzEgPSAlbGRcbiIs IHIzMSAoKSk7DQpwcmludGYgKCIzMiA9ICVsZFxuIiwgcjMyICgpKTsNCnBy aW50ZiAoIjMzID0gJWxkXG4iLCByMzMgKCkpOw0KcHJpbnRmICgiMzQgPSAl bGRcbiIsIHIzNCAoKSk7DQpwcmludGYgKCIzNSA9ICVsZFxuIiwgcjM1ICgp KTsNCnByaW50ZiAoIjM2ID0gJWxkXG4iLCByMzYgKCkpOw0KcHJpbnRmICgi MzcgPSAlbGRcbiIsIHIzNyAoKSk7DQpwcmludGYgKCIzOCA9ICVsZFxuIiwg cjM4ICgpKTsNCnByaW50ZiAoIjM5ID0gJWxkXG4iLCByMzkgKCkpOw0KcHJp bnRmICgiNDAgPSAlbGRcbiIsIHI0MCAoKSk7DQpwcmludGYgKCI0MSA9ICVs ZFxuIiwgcjQxICgpKTsNCnByaW50ZiAoIjQyID0gJWxkXG4iLCByNDIgKCkp Ow0KcHJpbnRmICgiNDMgPSAlbGRcbiIsIHI0MyAoKSk7DQpwcmludGYgKCI0 NCA9ICVsZFxuIiwgcjQ0ICgpKTsNCnByaW50ZiAoIjQ1ID0gJWxkXG4iLCBy NDUgKCkpOw0KcHJpbnRmICgiNDYgPSAlbGRcbiIsIHI0NiAoKSk7DQpwcmlu dGYgKCI0NyA9ICVsZFxuIiwgcjQ3ICgpKTsNCnByaW50ZiAoIjQ4ID0gJWxk XG4iLCByNDggKCkpOw0KcHJpbnRmICgiNDkgPSAlbGRcbiIsIHI0OSAoKSk7 DQpwcmludGYgKCI1MCA9ICVsZFxuIiwgcjUwICgpKTsNCnByaW50ZiAoIjUx ID0gJWxkXG4iLCByNTEgKCkpOw0KcHJpbnRmICgiNTIgPSAlbGRcbiIsIHI1 MiAoKSk7DQpwcmludGYgKCI1MyA9ICVsZFxuIiwgcjUzICgpKTsNCnByaW50 ZiAoIjU0ID0gJWxkXG4iLCByNTQgKCkpOw0KcHJpbnRmICgiNTUgPSAlbGRc biIsIHI1NSAoKSk7DQpwcmludGYgKCI1NiA9ICVsZFxuIiwgcjU2ICgpKTsN CnByaW50ZiAoIjU3ID0gJWxkXG4iLCByNTcgKCkpOw0KcHJpbnRmICgiNTgg PSAlbGRcbiIsIHI1OCAoKSk7DQpwcmludGYgKCI1OSA9ICVsZFxuIiwgcjU5 ICgpKTsNCnByaW50ZiAoIjYwID0gJWxkXG4iLCByNjAgKCkpOw0KcHJpbnRm ICgiNjEgPSAlbGRcbiIsIHI2MSAoKSk7DQpwcmludGYgKCI2MiA9ICVsZFxu IiwgcjYyICgpKTsNCnByaW50ZiAoIjYzID0gJWxkXG4iLCByNjMgKCkpOw0K cHJpbnRmICgiNjQgPSAlbGRcbiIsIHI2NCAoKSk7DQpwcmludGYgKCI2NSA9 ICVsZFxuIiwgcjY1ICgpKTsNCnByaW50ZiAoIjY2ID0gJWxkXG4iLCByNjYg KCkpOw0KcHJpbnRmICgiNjcgPSAlbGRcbiIsIHI2NyAoKSk7DQpwcmludGYg KCI2OCA9ICVsZFxuIiwgcjY4ICgpKTsNCnByaW50ZiAoIjY5ID0gJWxkXG4i LCByNjkgKCkpOw0KcHJpbnRmICgiNzAgPSAlbGRcbiIsIHI3MCAoKSk7DQpw cmludGYgKCI3MSA9ICVsZFxuIiwgcjcxICgpKTsNCnByaW50ZiAoIjcyID0g JWxkXG4iLCByNzIgKCkpOw0KcHJpbnRmICgiNzMgPSAlbGRcbiIsIHI3MyAo KSk7DQpwcmludGYgKCI3NCA9ICVsZFxuIiwgcjc0ICgpKTsNCnByaW50ZiAo Ijc1ID0gJWxkXG4iLCByNzUgKCkpOw0KcHJpbnRmICgiNzYgPSAlbGRcbiIs IHI3NiAoKSk7DQpwcmludGYgKCI3NyA9ICVsZFxuIiwgcjc3ICgpKTsNCnBy aW50ZiAoIjc4ID0gJWxkXG4iLCByNzggKCkpOw0KcHJpbnRmICgiNzkgPSAl bGRcbiIsIHI3OSAoKSk7DQpwcmludGYgKCI4MCA9ICVsZFxuIiwgcjgwICgp KTsNCnByaW50ZiAoIjgxID0gJWxkXG4iLCByODEgKCkpOw0KcHJpbnRmICgi ODIgPSAlbGRcbiIsIHI4MiAoKSk7DQpwcmludGYgKCI4MyA9ICVsZFxuIiwg cjgzICgpKTsNCnByaW50ZiAoIjg0ID0gJWxkXG4iLCByODQgKCkpOw0KcHJp bnRmICgiODUgPSAlbGRcbiIsIHI4NSAoKSk7DQpwcmludGYgKCI4NiA9ICVs ZFxuIiwgcjg2ICgpKTsNCnByaW50ZiAoIjg3ID0gJWxkXG4iLCByODcgKCkp Ow0KcHJpbnRmICgiODggPSAlbGRcbiIsIHI4OCAoKSk7DQpwcmludGYgKCI4 OSA9ICVsZFxuIiwgcjg5ICgpKTsNCnByaW50ZiAoIjkwID0gJWxkXG4iLCBy OTAgKCkpOw0KcHJpbnRmICgiOTEgPSAlbGRcbiIsIHI5MSAoKSk7DQpwcmlu dGYgKCI5MiA9ICVsZFxuIiwgcjkyICgpKTsNCnByaW50ZiAoIjkzID0gJWxk XG4iLCByOTMgKCkpOw0KcHJpbnRmICgiOTQgPSAlbGRcbiIsIHI5NCAoKSk7 DQpwcmludGYgKCI5NSA9ICVsZFxuIiwgcjk1ICgpKTsNCnByaW50ZiAoIjk2 ID0gJWxkXG4iLCByOTYgKCkpOw0KcHJpbnRmICgiOTcgPSAlbGRcbiIsIHI5 NyAoKSk7DQpwcmludGYgKCI5OCA9ICVsZFxuIiwgcjk4ICgpKTsNCnByaW50 ZiAoIjk5ID0gJWxkXG4iLCByOTkgKCkpOw0KcHJpbnRmICgiMTAwID0gJWxk XG4iLCByMTAwICgpKTsNCnByaW50ZiAoIjEwMSA9ICVsZFxuIiwgcjEwMSAo KSk7DQpwcmludGYgKCIxMDIgPSAlbGRcbiIsIHIxMDIgKCkpOw0KcHJpbnRm ICgiMTAzID0gJWxkXG4iLCByMTAzICgpKTsNCnByaW50ZiAoIjEwNCA9ICVs ZFxuIiwgcjEwNCAoKSk7DQpwcmludGYgKCIxMDUgPSAlbGRcbiIsIHIxMDUg KCkpOw0KcHJpbnRmICgiMTA2ID0gJWxkXG4iLCByMTA2ICgpKTsNCnByaW50 ZiAoIjEwNyA9ICVsZFxuIiwgcjEwNyAoKSk7DQpwcmludGYgKCIxMDggPSAl bGRcbiIsIHIxMDggKCkpOw0KcHJpbnRmICgiMTA5ID0gJWxkXG4iLCByMTA5 ICgpKTsNCnByaW50ZiAoIjExMCA9ICVsZFxuIiwgcjExMCAoKSk7DQpwcmlu dGYgKCIxMTEgPSAlbGRcbiIsIHIxMTEgKCkpOw0KcHJpbnRmICgiMTEyID0g JWxkXG4iLCByMTEyICgpKTsNCnByaW50ZiAoIjExMyA9ICVsZFxuIiwgcjEx MyAoKSk7DQpwcmludGYgKCIxMTQgPSAlbGRcbiIsIHIxMTQgKCkpOw0KcHJp bnRmICgiMTE1ID0gJWxkXG4iLCByMTE1ICgpKTsNCnByaW50ZiAoIjExNiA9 ICVsZFxuIiwgcjExNiAoKSk7DQpwcmludGYgKCIxMTcgPSAlbGRcbiIsIHIx MTcgKCkpOw0KcHJpbnRmICgiMTE4ID0gJWxkXG4iLCByMTE4ICgpKTsNCnBy aW50ZiAoIjExOSA9ICVsZFxuIiwgcjExOSAoKSk7DQpwcmludGYgKCIxMjAg PSAlbGRcbiIsIHIxMjAgKCkpOw0KcHJpbnRmICgiMTIxID0gJWxkXG4iLCBy MTIxICgpKTsNCnByaW50ZiAoIjEyMiA9ICVsZFxuIiwgcjEyMiAoKSk7DQpw cmludGYgKCIxMjMgPSAlbGRcbiIsIHIxMjMgKCkpOw0KcHJpbnRmICgiMTI0 ID0gJWxkXG4iLCByMTI0ICgpKTsNCnByaW50ZiAoIjEyNSA9ICVsZFxuIiwg cjEyNSAoKSk7DQpwcmludGYgKCIxMjYgPSAlbGRcbiIsIHIxMjYgKCkpOw0K cHJpbnRmICgiMTI3ID0gJWxkXG4iLCByMTI3ICgpKTsNCg0KcmV0dXJuKDAp Ow0KfQ0K --2010703495-851401618-823799462=:7314 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="opt-256to255.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Test the ranges [-256, -129] and [128, 255] I2luY2x1ZGUgPHN0ZGlvLmg+DQoNCi8qIG1vdmUubCAjeCxEbiAtPiBtb3Zl cS5sICMtMjU3LXgsRG4gKyBub3QuYiBEbiwgcmFuZ2UgWy0yNTYsLTEyOV0u ICovDQpzaWduZWQgbG9uZyBpbnQgcl8yNTYgKHZvaWQpIHsgcmV0dXJuICgt MjU2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMjU1ICh2b2lkKSB7IHJldHVy biAoLTI1NSk7IH0NCnNpZ25lZCBsb25nIGludCByXzI1NCAodm9pZCkgeyBy ZXR1cm4gKC0yNTQpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yNTMgKHZvaWQp IHsgcmV0dXJuICgtMjUzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMjUyICh2 b2lkKSB7IHJldHVybiAoLTI1Mik7IH0NCnNpZ25lZCBsb25nIGludCByXzI1 MSAodm9pZCkgeyByZXR1cm4gKC0yNTEpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl8yNTAgKHZvaWQpIHsgcmV0dXJuICgtMjUwKTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHJfMjQ5ICh2b2lkKSB7IHJldHVybiAoLTI0OSk7IH0NCnNpZ25lZCBs b25nIGludCByXzI0OCAodm9pZCkgeyByZXR1cm4gKC0yNDgpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl8yNDcgKHZvaWQpIHsgcmV0dXJuICgtMjQ3KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHJfMjQ2ICh2b2lkKSB7IHJldHVybiAoLTI0Nik7 IH0NCnNpZ25lZCBsb25nIGludCByXzI0NSAodm9pZCkgeyByZXR1cm4gKC0y NDUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yNDQgKHZvaWQpIHsgcmV0dXJu ICgtMjQ0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMjQzICh2b2lkKSB7IHJl dHVybiAoLTI0Myk7IH0NCnNpZ25lZCBsb25nIGludCByXzI0MiAodm9pZCkg eyByZXR1cm4gKC0yNDIpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yNDEgKHZv aWQpIHsgcmV0dXJuICgtMjQxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMjQw ICh2b2lkKSB7IHJldHVybiAoLTI0MCk7IH0NCnNpZ25lZCBsb25nIGludCBy XzIzOSAodm9pZCkgeyByZXR1cm4gKC0yMzkpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl8yMzggKHZvaWQpIHsgcmV0dXJuICgtMjM4KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHJfMjM3ICh2b2lkKSB7IHJldHVybiAoLTIzNyk7IH0NCnNpZ25l ZCBsb25nIGludCByXzIzNiAodm9pZCkgeyByZXR1cm4gKC0yMzYpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl8yMzUgKHZvaWQpIHsgcmV0dXJuICgtMjM1KTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHJfMjM0ICh2b2lkKSB7IHJldHVybiAoLTIz NCk7IH0NCnNpZ25lZCBsb25nIGludCByXzIzMyAodm9pZCkgeyByZXR1cm4g KC0yMzMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yMzIgKHZvaWQpIHsgcmV0 dXJuICgtMjMyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMjMxICh2b2lkKSB7 IHJldHVybiAoLTIzMSk7IH0NCnNpZ25lZCBsb25nIGludCByXzIzMCAodm9p ZCkgeyByZXR1cm4gKC0yMzApOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yMjkg KHZvaWQpIHsgcmV0dXJuICgtMjI5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJf MjI4ICh2b2lkKSB7IHJldHVybiAoLTIyOCk7IH0NCnNpZ25lZCBsb25nIGlu dCByXzIyNyAodm9pZCkgeyByZXR1cm4gKC0yMjcpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl8yMjYgKHZvaWQpIHsgcmV0dXJuICgtMjI2KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHJfMjI1ICh2b2lkKSB7IHJldHVybiAoLTIyNSk7IH0NCnNp Z25lZCBsb25nIGludCByXzIyNCAodm9pZCkgeyByZXR1cm4gKC0yMjQpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl8yMjMgKHZvaWQpIHsgcmV0dXJuICgtMjIz KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMjIyICh2b2lkKSB7IHJldHVybiAo LTIyMik7IH0NCnNpZ25lZCBsb25nIGludCByXzIyMSAodm9pZCkgeyByZXR1 cm4gKC0yMjEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yMjAgKHZvaWQpIHsg cmV0dXJuICgtMjIwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMjE5ICh2b2lk KSB7IHJldHVybiAoLTIxOSk7IH0NCnNpZ25lZCBsb25nIGludCByXzIxOCAo dm9pZCkgeyByZXR1cm4gKC0yMTgpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8y MTcgKHZvaWQpIHsgcmV0dXJuICgtMjE3KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHJfMjE2ICh2b2lkKSB7IHJldHVybiAoLTIxNik7IH0NCnNpZ25lZCBsb25n IGludCByXzIxNSAodm9pZCkgeyByZXR1cm4gKC0yMTUpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl8yMTQgKHZvaWQpIHsgcmV0dXJuICgtMjE0KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHJfMjEzICh2b2lkKSB7IHJldHVybiAoLTIxMyk7IH0N CnNpZ25lZCBsb25nIGludCByXzIxMiAodm9pZCkgeyByZXR1cm4gKC0yMTIp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yMTEgKHZvaWQpIHsgcmV0dXJuICgt MjExKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMjEwICh2b2lkKSB7IHJldHVy biAoLTIxMCk7IH0NCnNpZ25lZCBsb25nIGludCByXzIwOSAodm9pZCkgeyBy ZXR1cm4gKC0yMDkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yMDggKHZvaWQp IHsgcmV0dXJuICgtMjA4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMjA3ICh2 b2lkKSB7IHJldHVybiAoLTIwNyk7IH0NCnNpZ25lZCBsb25nIGludCByXzIw NiAodm9pZCkgeyByZXR1cm4gKC0yMDYpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl8yMDUgKHZvaWQpIHsgcmV0dXJuICgtMjA1KTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHJfMjA0ICh2b2lkKSB7IHJldHVybiAoLTIwNCk7IH0NCnNpZ25lZCBs b25nIGludCByXzIwMyAodm9pZCkgeyByZXR1cm4gKC0yMDMpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl8yMDIgKHZvaWQpIHsgcmV0dXJuICgtMjAyKTsgfQ0K c2lnbmVkIGxvbmcgaW50IHJfMjAxICh2b2lkKSB7IHJldHVybiAoLTIwMSk7 IH0NCnNpZ25lZCBsb25nIGludCByXzIwMCAodm9pZCkgeyByZXR1cm4gKC0y MDApOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xOTkgKHZvaWQpIHsgcmV0dXJu ICgtMTk5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTk4ICh2b2lkKSB7IHJl dHVybiAoLTE5OCk7IH0NCnNpZ25lZCBsb25nIGludCByXzE5NyAodm9pZCkg eyByZXR1cm4gKC0xOTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xOTYgKHZv aWQpIHsgcmV0dXJuICgtMTk2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTk1 ICh2b2lkKSB7IHJldHVybiAoLTE5NSk7IH0NCnNpZ25lZCBsb25nIGludCBy XzE5NCAodm9pZCkgeyByZXR1cm4gKC0xOTQpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl8xOTMgKHZvaWQpIHsgcmV0dXJuICgtMTkzKTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHJfMTkyICh2b2lkKSB7IHJldHVybiAoLTE5Mik7IH0NCnNpZ25l ZCBsb25nIGludCByXzE5MSAodm9pZCkgeyByZXR1cm4gKC0xOTEpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl8xOTAgKHZvaWQpIHsgcmV0dXJuICgtMTkwKTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTg5ICh2b2lkKSB7IHJldHVybiAoLTE4 OSk7IH0NCnNpZ25lZCBsb25nIGludCByXzE4OCAodm9pZCkgeyByZXR1cm4g KC0xODgpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xODcgKHZvaWQpIHsgcmV0 dXJuICgtMTg3KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTg2ICh2b2lkKSB7 IHJldHVybiAoLTE4Nik7IH0NCnNpZ25lZCBsb25nIGludCByXzE4NSAodm9p ZCkgeyByZXR1cm4gKC0xODUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xODQg KHZvaWQpIHsgcmV0dXJuICgtMTg0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJf MTgzICh2b2lkKSB7IHJldHVybiAoLTE4Myk7IH0NCnNpZ25lZCBsb25nIGlu dCByXzE4MiAodm9pZCkgeyByZXR1cm4gKC0xODIpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl8xODEgKHZvaWQpIHsgcmV0dXJuICgtMTgxKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHJfMTgwICh2b2lkKSB7IHJldHVybiAoLTE4MCk7IH0NCnNp Z25lZCBsb25nIGludCByXzE3OSAodm9pZCkgeyByZXR1cm4gKC0xNzkpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl8xNzggKHZvaWQpIHsgcmV0dXJuICgtMTc4 KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTc3ICh2b2lkKSB7IHJldHVybiAo LTE3Nyk7IH0NCnNpZ25lZCBsb25nIGludCByXzE3NiAodm9pZCkgeyByZXR1 cm4gKC0xNzYpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xNzUgKHZvaWQpIHsg cmV0dXJuICgtMTc1KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTc0ICh2b2lk KSB7IHJldHVybiAoLTE3NCk7IH0NCnNpZ25lZCBsb25nIGludCByXzE3MyAo dm9pZCkgeyByZXR1cm4gKC0xNzMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8x NzIgKHZvaWQpIHsgcmV0dXJuICgtMTcyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHJfMTcxICh2b2lkKSB7IHJldHVybiAoLTE3MSk7IH0NCnNpZ25lZCBsb25n IGludCByXzE3MCAodm9pZCkgeyByZXR1cm4gKC0xNzApOyB9DQpzaWduZWQg bG9uZyBpbnQgcl8xNjkgKHZvaWQpIHsgcmV0dXJuICgtMTY5KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHJfMTY4ICh2b2lkKSB7IHJldHVybiAoLTE2OCk7IH0N CnNpZ25lZCBsb25nIGludCByXzE2NyAodm9pZCkgeyByZXR1cm4gKC0xNjcp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xNjYgKHZvaWQpIHsgcmV0dXJuICgt MTY2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTY1ICh2b2lkKSB7IHJldHVy biAoLTE2NSk7IH0NCnNpZ25lZCBsb25nIGludCByXzE2NCAodm9pZCkgeyBy ZXR1cm4gKC0xNjQpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xNjMgKHZvaWQp IHsgcmV0dXJuICgtMTYzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTYyICh2 b2lkKSB7IHJldHVybiAoLTE2Mik7IH0NCnNpZ25lZCBsb25nIGludCByXzE2 MSAodm9pZCkgeyByZXR1cm4gKC0xNjEpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl8xNjAgKHZvaWQpIHsgcmV0dXJuICgtMTYwKTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHJfMTU5ICh2b2lkKSB7IHJldHVybiAoLTE1OSk7IH0NCnNpZ25lZCBs b25nIGludCByXzE1OCAodm9pZCkgeyByZXR1cm4gKC0xNTgpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl8xNTcgKHZvaWQpIHsgcmV0dXJuICgtMTU3KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHJfMTU2ICh2b2lkKSB7IHJldHVybiAoLTE1Nik7 IH0NCnNpZ25lZCBsb25nIGludCByXzE1NSAodm9pZCkgeyByZXR1cm4gKC0x NTUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xNTQgKHZvaWQpIHsgcmV0dXJu ICgtMTU0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTUzICh2b2lkKSB7IHJl dHVybiAoLTE1Myk7IH0NCnNpZ25lZCBsb25nIGludCByXzE1MiAodm9pZCkg eyByZXR1cm4gKC0xNTIpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xNTEgKHZv aWQpIHsgcmV0dXJuICgtMTUxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTUw ICh2b2lkKSB7IHJldHVybiAoLTE1MCk7IH0NCnNpZ25lZCBsb25nIGludCBy XzE0OSAodm9pZCkgeyByZXR1cm4gKC0xNDkpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl8xNDggKHZvaWQpIHsgcmV0dXJuICgtMTQ4KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHJfMTQ3ICh2b2lkKSB7IHJldHVybiAoLTE0Nyk7IH0NCnNpZ25l ZCBsb25nIGludCByXzE0NiAodm9pZCkgeyByZXR1cm4gKC0xNDYpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl8xNDUgKHZvaWQpIHsgcmV0dXJuICgtMTQ1KTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTQ0ICh2b2lkKSB7IHJldHVybiAoLTE0 NCk7IH0NCnNpZ25lZCBsb25nIGludCByXzE0MyAodm9pZCkgeyByZXR1cm4g KC0xNDMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xNDIgKHZvaWQpIHsgcmV0 dXJuICgtMTQyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTQxICh2b2lkKSB7 IHJldHVybiAoLTE0MSk7IH0NCnNpZ25lZCBsb25nIGludCByXzE0MCAodm9p ZCkgeyByZXR1cm4gKC0xNDApOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xMzkg KHZvaWQpIHsgcmV0dXJuICgtMTM5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJf MTM4ICh2b2lkKSB7IHJldHVybiAoLTEzOCk7IH0NCnNpZ25lZCBsb25nIGlu dCByXzEzNyAodm9pZCkgeyByZXR1cm4gKC0xMzcpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl8xMzYgKHZvaWQpIHsgcmV0dXJuICgtMTM2KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHJfMTM1ICh2b2lkKSB7IHJldHVybiAoLTEzNSk7IH0NCnNp Z25lZCBsb25nIGludCByXzEzNCAodm9pZCkgeyByZXR1cm4gKC0xMzQpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl8xMzMgKHZvaWQpIHsgcmV0dXJuICgtMTMz KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTMyICh2b2lkKSB7IHJldHVybiAo LTEzMik7IH0NCnNpZ25lZCBsb25nIGludCByXzEzMSAodm9pZCkgeyByZXR1 cm4gKC0xMzEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xMzAgKHZvaWQpIHsg cmV0dXJuICgtMTMwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTI5ICh2b2lk KSB7IHJldHVybiAoLTEyOSk7IH0NCi8qIG1vdmUubCAjeCxEbiAtPiBtb3Zl cS5sICMyNTUteCxEbiArIG5vdC5iIERuLCByYW5nZSBbMTI4LCAyNTVdLiAq Lw0Kc2lnbmVkIGxvbmcgaW50IHIxMjggKHZvaWQpIHsgcmV0dXJuICgxMjgp OyB9DQpzaWduZWQgbG9uZyBpbnQgcjEyOSAodm9pZCkgeyByZXR1cm4gKDEy OSk7IH0NCnNpZ25lZCBsb25nIGludCByMTMwICh2b2lkKSB7IHJldHVybiAo MTMwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxMzEgKHZvaWQpIHsgcmV0dXJu ICgxMzEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjEzMiAodm9pZCkgeyByZXR1 cm4gKDEzMik7IH0NCnNpZ25lZCBsb25nIGludCByMTMzICh2b2lkKSB7IHJl dHVybiAoMTMzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxMzQgKHZvaWQpIHsg cmV0dXJuICgxMzQpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjEzNSAodm9pZCkg eyByZXR1cm4gKDEzNSk7IH0NCnNpZ25lZCBsb25nIGludCByMTM2ICh2b2lk KSB7IHJldHVybiAoMTM2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxMzcgKHZv aWQpIHsgcmV0dXJuICgxMzcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjEzOCAo dm9pZCkgeyByZXR1cm4gKDEzOCk7IH0NCnNpZ25lZCBsb25nIGludCByMTM5 ICh2b2lkKSB7IHJldHVybiAoMTM5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIx NDAgKHZvaWQpIHsgcmV0dXJuICgxNDApOyB9DQpzaWduZWQgbG9uZyBpbnQg cjE0MSAodm9pZCkgeyByZXR1cm4gKDE0MSk7IH0NCnNpZ25lZCBsb25nIGlu dCByMTQyICh2b2lkKSB7IHJldHVybiAoMTQyKTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHIxNDMgKHZvaWQpIHsgcmV0dXJuICgxNDMpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcjE0NCAodm9pZCkgeyByZXR1cm4gKDE0NCk7IH0NCnNpZ25lZCBs b25nIGludCByMTQ1ICh2b2lkKSB7IHJldHVybiAoMTQ1KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHIxNDYgKHZvaWQpIHsgcmV0dXJuICgxNDYpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcjE0NyAodm9pZCkgeyByZXR1cm4gKDE0Nyk7IH0NCnNp Z25lZCBsb25nIGludCByMTQ4ICh2b2lkKSB7IHJldHVybiAoMTQ4KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHIxNDkgKHZvaWQpIHsgcmV0dXJuICgxNDkpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcjE1MCAodm9pZCkgeyByZXR1cm4gKDE1MCk7 IH0NCnNpZ25lZCBsb25nIGludCByMTUxICh2b2lkKSB7IHJldHVybiAoMTUx KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxNTIgKHZvaWQpIHsgcmV0dXJuICgx NTIpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjE1MyAodm9pZCkgeyByZXR1cm4g KDE1Myk7IH0NCnNpZ25lZCBsb25nIGludCByMTU0ICh2b2lkKSB7IHJldHVy biAoMTU0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxNTUgKHZvaWQpIHsgcmV0 dXJuICgxNTUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjE1NiAodm9pZCkgeyBy ZXR1cm4gKDE1Nik7IH0NCnNpZ25lZCBsb25nIGludCByMTU3ICh2b2lkKSB7 IHJldHVybiAoMTU3KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxNTggKHZvaWQp IHsgcmV0dXJuICgxNTgpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjE1OSAodm9p ZCkgeyByZXR1cm4gKDE1OSk7IH0NCnNpZ25lZCBsb25nIGludCByMTYwICh2 b2lkKSB7IHJldHVybiAoMTYwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxNjEg KHZvaWQpIHsgcmV0dXJuICgxNjEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjE2 MiAodm9pZCkgeyByZXR1cm4gKDE2Mik7IH0NCnNpZ25lZCBsb25nIGludCBy MTYzICh2b2lkKSB7IHJldHVybiAoMTYzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHIxNjQgKHZvaWQpIHsgcmV0dXJuICgxNjQpOyB9DQpzaWduZWQgbG9uZyBp bnQgcjE2NSAodm9pZCkgeyByZXR1cm4gKDE2NSk7IH0NCnNpZ25lZCBsb25n IGludCByMTY2ICh2b2lkKSB7IHJldHVybiAoMTY2KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHIxNjcgKHZvaWQpIHsgcmV0dXJuICgxNjcpOyB9DQpzaWduZWQg bG9uZyBpbnQgcjE2OCAodm9pZCkgeyByZXR1cm4gKDE2OCk7IH0NCnNpZ25l ZCBsb25nIGludCByMTY5ICh2b2lkKSB7IHJldHVybiAoMTY5KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHIxNzAgKHZvaWQpIHsgcmV0dXJuICgxNzApOyB9DQpz aWduZWQgbG9uZyBpbnQgcjE3MSAodm9pZCkgeyByZXR1cm4gKDE3MSk7IH0N CnNpZ25lZCBsb25nIGludCByMTcyICh2b2lkKSB7IHJldHVybiAoMTcyKTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHIxNzMgKHZvaWQpIHsgcmV0dXJuICgxNzMp OyB9DQpzaWduZWQgbG9uZyBpbnQgcjE3NCAodm9pZCkgeyByZXR1cm4gKDE3 NCk7IH0NCnNpZ25lZCBsb25nIGludCByMTc1ICh2b2lkKSB7IHJldHVybiAo MTc1KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxNzYgKHZvaWQpIHsgcmV0dXJu ICgxNzYpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjE3NyAodm9pZCkgeyByZXR1 cm4gKDE3Nyk7IH0NCnNpZ25lZCBsb25nIGludCByMTc4ICh2b2lkKSB7IHJl dHVybiAoMTc4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxNzkgKHZvaWQpIHsg cmV0dXJuICgxNzkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjE4MCAodm9pZCkg eyByZXR1cm4gKDE4MCk7IH0NCnNpZ25lZCBsb25nIGludCByMTgxICh2b2lk KSB7IHJldHVybiAoMTgxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxODIgKHZv aWQpIHsgcmV0dXJuICgxODIpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjE4MyAo dm9pZCkgeyByZXR1cm4gKDE4Myk7IH0NCnNpZ25lZCBsb25nIGludCByMTg0 ICh2b2lkKSB7IHJldHVybiAoMTg0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIx ODUgKHZvaWQpIHsgcmV0dXJuICgxODUpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjE4NiAodm9pZCkgeyByZXR1cm4gKDE4Nik7IH0NCnNpZ25lZCBsb25nIGlu dCByMTg3ICh2b2lkKSB7IHJldHVybiAoMTg3KTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHIxODggKHZvaWQpIHsgcmV0dXJuICgxODgpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcjE4OSAodm9pZCkgeyByZXR1cm4gKDE4OSk7IH0NCnNpZ25lZCBs b25nIGludCByMTkwICh2b2lkKSB7IHJldHVybiAoMTkwKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHIxOTEgKHZvaWQpIHsgcmV0dXJuICgxOTEpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcjE5MiAodm9pZCkgeyByZXR1cm4gKDE5Mik7IH0NCnNp Z25lZCBsb25nIGludCByMTkzICh2b2lkKSB7IHJldHVybiAoMTkzKTsgfQ0K c2lnbmVkIGxvbmcgaW50IHIxOTQgKHZvaWQpIHsgcmV0dXJuICgxOTQpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcjE5NSAodm9pZCkgeyByZXR1cm4gKDE5NSk7 IH0NCnNpZ25lZCBsb25nIGludCByMTk2ICh2b2lkKSB7IHJldHVybiAoMTk2 KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxOTcgKHZvaWQpIHsgcmV0dXJuICgx OTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjE5OCAodm9pZCkgeyByZXR1cm4g KDE5OCk7IH0NCnNpZ25lZCBsb25nIGludCByMTk5ICh2b2lkKSB7IHJldHVy biAoMTk5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyMDAgKHZvaWQpIHsgcmV0 dXJuICgyMDApOyB9DQpzaWduZWQgbG9uZyBpbnQgcjIwMSAodm9pZCkgeyBy ZXR1cm4gKDIwMSk7IH0NCnNpZ25lZCBsb25nIGludCByMjAyICh2b2lkKSB7 IHJldHVybiAoMjAyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyMDMgKHZvaWQp IHsgcmV0dXJuICgyMDMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjIwNCAodm9p ZCkgeyByZXR1cm4gKDIwNCk7IH0NCnNpZ25lZCBsb25nIGludCByMjA1ICh2 b2lkKSB7IHJldHVybiAoMjA1KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyMDYg KHZvaWQpIHsgcmV0dXJuICgyMDYpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjIw NyAodm9pZCkgeyByZXR1cm4gKDIwNyk7IH0NCnNpZ25lZCBsb25nIGludCBy MjA4ICh2b2lkKSB7IHJldHVybiAoMjA4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHIyMDkgKHZvaWQpIHsgcmV0dXJuICgyMDkpOyB9DQpzaWduZWQgbG9uZyBp bnQgcjIxMCAodm9pZCkgeyByZXR1cm4gKDIxMCk7IH0NCnNpZ25lZCBsb25n IGludCByMjExICh2b2lkKSB7IHJldHVybiAoMjExKTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHIyMTIgKHZvaWQpIHsgcmV0dXJuICgyMTIpOyB9DQpzaWduZWQg bG9uZyBpbnQgcjIxMyAodm9pZCkgeyByZXR1cm4gKDIxMyk7IH0NCnNpZ25l ZCBsb25nIGludCByMjE0ICh2b2lkKSB7IHJldHVybiAoMjE0KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHIyMTUgKHZvaWQpIHsgcmV0dXJuICgyMTUpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjIxNiAodm9pZCkgeyByZXR1cm4gKDIxNik7IH0N CnNpZ25lZCBsb25nIGludCByMjE3ICh2b2lkKSB7IHJldHVybiAoMjE3KTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHIyMTggKHZvaWQpIHsgcmV0dXJuICgyMTgp OyB9DQpzaWduZWQgbG9uZyBpbnQgcjIxOSAodm9pZCkgeyByZXR1cm4gKDIx OSk7IH0NCnNpZ25lZCBsb25nIGludCByMjIwICh2b2lkKSB7IHJldHVybiAo MjIwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyMjEgKHZvaWQpIHsgcmV0dXJu ICgyMjEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjIyMiAodm9pZCkgeyByZXR1 cm4gKDIyMik7IH0NCnNpZ25lZCBsb25nIGludCByMjIzICh2b2lkKSB7IHJl dHVybiAoMjIzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyMjQgKHZvaWQpIHsg cmV0dXJuICgyMjQpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjIyNSAodm9pZCkg eyByZXR1cm4gKDIyNSk7IH0NCnNpZ25lZCBsb25nIGludCByMjI2ICh2b2lk KSB7IHJldHVybiAoMjI2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyMjcgKHZv aWQpIHsgcmV0dXJuICgyMjcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjIyOCAo dm9pZCkgeyByZXR1cm4gKDIyOCk7IH0NCnNpZ25lZCBsb25nIGludCByMjI5 ICh2b2lkKSB7IHJldHVybiAoMjI5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIy MzAgKHZvaWQpIHsgcmV0dXJuICgyMzApOyB9DQpzaWduZWQgbG9uZyBpbnQg cjIzMSAodm9pZCkgeyByZXR1cm4gKDIzMSk7IH0NCnNpZ25lZCBsb25nIGlu dCByMjMyICh2b2lkKSB7IHJldHVybiAoMjMyKTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHIyMzMgKHZvaWQpIHsgcmV0dXJuICgyMzMpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcjIzNCAodm9pZCkgeyByZXR1cm4gKDIzNCk7IH0NCnNpZ25lZCBs b25nIGludCByMjM1ICh2b2lkKSB7IHJldHVybiAoMjM1KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHIyMzYgKHZvaWQpIHsgcmV0dXJuICgyMzYpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcjIzNyAodm9pZCkgeyByZXR1cm4gKDIzNyk7IH0NCnNp Z25lZCBsb25nIGludCByMjM4ICh2b2lkKSB7IHJldHVybiAoMjM4KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHIyMzkgKHZvaWQpIHsgcmV0dXJuICgyMzkpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcjI0MCAodm9pZCkgeyByZXR1cm4gKDI0MCk7 IH0NCnNpZ25lZCBsb25nIGludCByMjQxICh2b2lkKSB7IHJldHVybiAoMjQx KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyNDIgKHZvaWQpIHsgcmV0dXJuICgy NDIpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjI0MyAodm9pZCkgeyByZXR1cm4g KDI0Myk7IH0NCnNpZ25lZCBsb25nIGludCByMjQ0ICh2b2lkKSB7IHJldHVy biAoMjQ0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyNDUgKHZvaWQpIHsgcmV0 dXJuICgyNDUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjI0NiAodm9pZCkgeyBy ZXR1cm4gKDI0Nik7IH0NCnNpZ25lZCBsb25nIGludCByMjQ3ICh2b2lkKSB7 IHJldHVybiAoMjQ3KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyNDggKHZvaWQp IHsgcmV0dXJuICgyNDgpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjI0OSAodm9p ZCkgeyByZXR1cm4gKDI0OSk7IH0NCnNpZ25lZCBsb25nIGludCByMjUwICh2 b2lkKSB7IHJldHVybiAoMjUwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyNTEg KHZvaWQpIHsgcmV0dXJuICgyNTEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjI1 MiAodm9pZCkgeyByZXR1cm4gKDI1Mik7IH0NCnNpZ25lZCBsb25nIGludCBy MjUzICh2b2lkKSB7IHJldHVybiAoMjUzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHIyNTQgKHZvaWQpIHsgcmV0dXJuICgyNTQpOyB9DQpzaWduZWQgbG9uZyBp bnQgcjI1NSAodm9pZCkgeyByZXR1cm4gKDI1NSk7IH0NCg0KaW50IG1haW4g KGludCBhcmdjLCBjaGFyICogYXJndltdKQ0Kew0KLyogbW92ZS5sICN4LERu IC0+IG1vdmVxLmwgIy0yNTcteCxEbiArIG5vdC5iIERuLCByYW5nZSBbLTI1 NiwtMTI5XS4gKi8NCnByaW50ZiAoIi0yNTYgPSAlbGRcbiIsIHJfMjU2ICgp KTsNCnByaW50ZiAoIi0yNTUgPSAlbGRcbiIsIHJfMjU1ICgpKTsNCnByaW50 ZiAoIi0yNTQgPSAlbGRcbiIsIHJfMjU0ICgpKTsNCnByaW50ZiAoIi0yNTMg PSAlbGRcbiIsIHJfMjUzICgpKTsNCnByaW50ZiAoIi0yNTIgPSAlbGRcbiIs IHJfMjUyICgpKTsNCnByaW50ZiAoIi0yNTEgPSAlbGRcbiIsIHJfMjUxICgp KTsNCnByaW50ZiAoIi0yNTAgPSAlbGRcbiIsIHJfMjUwICgpKTsNCnByaW50 ZiAoIi0yNDkgPSAlbGRcbiIsIHJfMjQ5ICgpKTsNCnByaW50ZiAoIi0yNDgg PSAlbGRcbiIsIHJfMjQ4ICgpKTsNCnByaW50ZiAoIi0yNDcgPSAlbGRcbiIs IHJfMjQ3ICgpKTsNCnByaW50ZiAoIi0yNDYgPSAlbGRcbiIsIHJfMjQ2ICgp KTsNCnByaW50ZiAoIi0yNDUgPSAlbGRcbiIsIHJfMjQ1ICgpKTsNCnByaW50 ZiAoIi0yNDQgPSAlbGRcbiIsIHJfMjQ0ICgpKTsNCnByaW50ZiAoIi0yNDMg PSAlbGRcbiIsIHJfMjQzICgpKTsNCnByaW50ZiAoIi0yNDIgPSAlbGRcbiIs IHJfMjQyICgpKTsNCnByaW50ZiAoIi0yNDEgPSAlbGRcbiIsIHJfMjQxICgp KTsNCnByaW50ZiAoIi0yNDAgPSAlbGRcbiIsIHJfMjQwICgpKTsNCnByaW50 ZiAoIi0yMzkgPSAlbGRcbiIsIHJfMjM5ICgpKTsNCnByaW50ZiAoIi0yMzgg PSAlbGRcbiIsIHJfMjM4ICgpKTsNCnByaW50ZiAoIi0yMzcgPSAlbGRcbiIs IHJfMjM3ICgpKTsNCnByaW50ZiAoIi0yMzYgPSAlbGRcbiIsIHJfMjM2ICgp KTsNCnByaW50ZiAoIi0yMzUgPSAlbGRcbiIsIHJfMjM1ICgpKTsNCnByaW50 ZiAoIi0yMzQgPSAlbGRcbiIsIHJfMjM0ICgpKTsNCnByaW50ZiAoIi0yMzMg PSAlbGRcbiIsIHJfMjMzICgpKTsNCnByaW50ZiAoIi0yMzIgPSAlbGRcbiIs IHJfMjMyICgpKTsNCnByaW50ZiAoIi0yMzEgPSAlbGRcbiIsIHJfMjMxICgp KTsNCnByaW50ZiAoIi0yMzAgPSAlbGRcbiIsIHJfMjMwICgpKTsNCnByaW50 ZiAoIi0yMjkgPSAlbGRcbiIsIHJfMjI5ICgpKTsNCnByaW50ZiAoIi0yMjgg PSAlbGRcbiIsIHJfMjI4ICgpKTsNCnByaW50ZiAoIi0yMjcgPSAlbGRcbiIs IHJfMjI3ICgpKTsNCnByaW50ZiAoIi0yMjYgPSAlbGRcbiIsIHJfMjI2ICgp KTsNCnByaW50ZiAoIi0yMjUgPSAlbGRcbiIsIHJfMjI1ICgpKTsNCnByaW50 ZiAoIi0yMjQgPSAlbGRcbiIsIHJfMjI0ICgpKTsNCnByaW50ZiAoIi0yMjMg PSAlbGRcbiIsIHJfMjIzICgpKTsNCnByaW50ZiAoIi0yMjIgPSAlbGRcbiIs IHJfMjIyICgpKTsNCnByaW50ZiAoIi0yMjEgPSAlbGRcbiIsIHJfMjIxICgp KTsNCnByaW50ZiAoIi0yMjAgPSAlbGRcbiIsIHJfMjIwICgpKTsNCnByaW50 ZiAoIi0yMTkgPSAlbGRcbiIsIHJfMjE5ICgpKTsNCnByaW50ZiAoIi0yMTgg PSAlbGRcbiIsIHJfMjE4ICgpKTsNCnByaW50ZiAoIi0yMTcgPSAlbGRcbiIs IHJfMjE3ICgpKTsNCnByaW50ZiAoIi0yMTYgPSAlbGRcbiIsIHJfMjE2ICgp KTsNCnByaW50ZiAoIi0yMTUgPSAlbGRcbiIsIHJfMjE1ICgpKTsNCnByaW50 ZiAoIi0yMTQgPSAlbGRcbiIsIHJfMjE0ICgpKTsNCnByaW50ZiAoIi0yMTMg PSAlbGRcbiIsIHJfMjEzICgpKTsNCnByaW50ZiAoIi0yMTIgPSAlbGRcbiIs IHJfMjEyICgpKTsNCnByaW50ZiAoIi0yMTEgPSAlbGRcbiIsIHJfMjExICgp KTsNCnByaW50ZiAoIi0yMTAgPSAlbGRcbiIsIHJfMjEwICgpKTsNCnByaW50 ZiAoIi0yMDkgPSAlbGRcbiIsIHJfMjA5ICgpKTsNCnByaW50ZiAoIi0yMDgg PSAlbGRcbiIsIHJfMjA4ICgpKTsNCnByaW50ZiAoIi0yMDcgPSAlbGRcbiIs IHJfMjA3ICgpKTsNCnByaW50ZiAoIi0yMDYgPSAlbGRcbiIsIHJfMjA2ICgp KTsNCnByaW50ZiAoIi0yMDUgPSAlbGRcbiIsIHJfMjA1ICgpKTsNCnByaW50 ZiAoIi0yMDQgPSAlbGRcbiIsIHJfMjA0ICgpKTsNCnByaW50ZiAoIi0yMDMg PSAlbGRcbiIsIHJfMjAzICgpKTsNCnByaW50ZiAoIi0yMDIgPSAlbGRcbiIs IHJfMjAyICgpKTsNCnByaW50ZiAoIi0yMDEgPSAlbGRcbiIsIHJfMjAxICgp KTsNCnByaW50ZiAoIi0yMDAgPSAlbGRcbiIsIHJfMjAwICgpKTsNCnByaW50 ZiAoIi0xOTkgPSAlbGRcbiIsIHJfMTk5ICgpKTsNCnByaW50ZiAoIi0xOTgg PSAlbGRcbiIsIHJfMTk4ICgpKTsNCnByaW50ZiAoIi0xOTcgPSAlbGRcbiIs IHJfMTk3ICgpKTsNCnByaW50ZiAoIi0xOTYgPSAlbGRcbiIsIHJfMTk2ICgp KTsNCnByaW50ZiAoIi0xOTUgPSAlbGRcbiIsIHJfMTk1ICgpKTsNCnByaW50 ZiAoIi0xOTQgPSAlbGRcbiIsIHJfMTk0ICgpKTsNCnByaW50ZiAoIi0xOTMg PSAlbGRcbiIsIHJfMTkzICgpKTsNCnByaW50ZiAoIi0xOTIgPSAlbGRcbiIs IHJfMTkyICgpKTsNCnByaW50ZiAoIi0xOTEgPSAlbGRcbiIsIHJfMTkxICgp KTsNCnByaW50ZiAoIi0xOTAgPSAlbGRcbiIsIHJfMTkwICgpKTsNCnByaW50 ZiAoIi0xODkgPSAlbGRcbiIsIHJfMTg5ICgpKTsNCnByaW50ZiAoIi0xODgg PSAlbGRcbiIsIHJfMTg4ICgpKTsNCnByaW50ZiAoIi0xODcgPSAlbGRcbiIs IHJfMTg3ICgpKTsNCnByaW50ZiAoIi0xODYgPSAlbGRcbiIsIHJfMTg2ICgp KTsNCnByaW50ZiAoIi0xODUgPSAlbGRcbiIsIHJfMTg1ICgpKTsNCnByaW50 ZiAoIi0xODQgPSAlbGRcbiIsIHJfMTg0ICgpKTsNCnByaW50ZiAoIi0xODMg PSAlbGRcbiIsIHJfMTgzICgpKTsNCnByaW50ZiAoIi0xODIgPSAlbGRcbiIs IHJfMTgyICgpKTsNCnByaW50ZiAoIi0xODEgPSAlbGRcbiIsIHJfMTgxICgp KTsNCnByaW50ZiAoIi0xODAgPSAlbGRcbiIsIHJfMTgwICgpKTsNCnByaW50 ZiAoIi0xNzkgPSAlbGRcbiIsIHJfMTc5ICgpKTsNCnByaW50ZiAoIi0xNzgg PSAlbGRcbiIsIHJfMTc4ICgpKTsNCnByaW50ZiAoIi0xNzcgPSAlbGRcbiIs IHJfMTc3ICgpKTsNCnByaW50ZiAoIi0xNzYgPSAlbGRcbiIsIHJfMTc2ICgp KTsNCnByaW50ZiAoIi0xNzUgPSAlbGRcbiIsIHJfMTc1ICgpKTsNCnByaW50 ZiAoIi0xNzQgPSAlbGRcbiIsIHJfMTc0ICgpKTsNCnByaW50ZiAoIi0xNzMg PSAlbGRcbiIsIHJfMTczICgpKTsNCnByaW50ZiAoIi0xNzIgPSAlbGRcbiIs IHJfMTcyICgpKTsNCnByaW50ZiAoIi0xNzEgPSAlbGRcbiIsIHJfMTcxICgp KTsNCnByaW50ZiAoIi0xNzAgPSAlbGRcbiIsIHJfMTcwICgpKTsNCnByaW50 ZiAoIi0xNjkgPSAlbGRcbiIsIHJfMTY5ICgpKTsNCnByaW50ZiAoIi0xNjgg PSAlbGRcbiIsIHJfMTY4ICgpKTsNCnByaW50ZiAoIi0xNjcgPSAlbGRcbiIs IHJfMTY3ICgpKTsNCnByaW50ZiAoIi0xNjYgPSAlbGRcbiIsIHJfMTY2ICgp KTsNCnByaW50ZiAoIi0xNjUgPSAlbGRcbiIsIHJfMTY1ICgpKTsNCnByaW50 ZiAoIi0xNjQgPSAlbGRcbiIsIHJfMTY0ICgpKTsNCnByaW50ZiAoIi0xNjMg PSAlbGRcbiIsIHJfMTYzICgpKTsNCnByaW50ZiAoIi0xNjIgPSAlbGRcbiIs IHJfMTYyICgpKTsNCnByaW50ZiAoIi0xNjEgPSAlbGRcbiIsIHJfMTYxICgp KTsNCnByaW50ZiAoIi0xNjAgPSAlbGRcbiIsIHJfMTYwICgpKTsNCnByaW50 ZiAoIi0xNTkgPSAlbGRcbiIsIHJfMTU5ICgpKTsNCnByaW50ZiAoIi0xNTgg PSAlbGRcbiIsIHJfMTU4ICgpKTsNCnByaW50ZiAoIi0xNTcgPSAlbGRcbiIs IHJfMTU3ICgpKTsNCnByaW50ZiAoIi0xNTYgPSAlbGRcbiIsIHJfMTU2ICgp KTsNCnByaW50ZiAoIi0xNTUgPSAlbGRcbiIsIHJfMTU1ICgpKTsNCnByaW50 ZiAoIi0xNTQgPSAlbGRcbiIsIHJfMTU0ICgpKTsNCnByaW50ZiAoIi0xNTMg PSAlbGRcbiIsIHJfMTUzICgpKTsNCnByaW50ZiAoIi0xNTIgPSAlbGRcbiIs IHJfMTUyICgpKTsNCnByaW50ZiAoIi0xNTEgPSAlbGRcbiIsIHJfMTUxICgp KTsNCnByaW50ZiAoIi0xNTAgPSAlbGRcbiIsIHJfMTUwICgpKTsNCnByaW50 ZiAoIi0xNDkgPSAlbGRcbiIsIHJfMTQ5ICgpKTsNCnByaW50ZiAoIi0xNDgg PSAlbGRcbiIsIHJfMTQ4ICgpKTsNCnByaW50ZiAoIi0xNDcgPSAlbGRcbiIs IHJfMTQ3ICgpKTsNCnByaW50ZiAoIi0xNDYgPSAlbGRcbiIsIHJfMTQ2ICgp KTsNCnByaW50ZiAoIi0xNDUgPSAlbGRcbiIsIHJfMTQ1ICgpKTsNCnByaW50 ZiAoIi0xNDQgPSAlbGRcbiIsIHJfMTQ0ICgpKTsNCnByaW50ZiAoIi0xNDMg PSAlbGRcbiIsIHJfMTQzICgpKTsNCnByaW50ZiAoIi0xNDIgPSAlbGRcbiIs IHJfMTQyICgpKTsNCnByaW50ZiAoIi0xNDEgPSAlbGRcbiIsIHJfMTQxICgp KTsNCnByaW50ZiAoIi0xNDAgPSAlbGRcbiIsIHJfMTQwICgpKTsNCnByaW50 ZiAoIi0xMzkgPSAlbGRcbiIsIHJfMTM5ICgpKTsNCnByaW50ZiAoIi0xMzgg PSAlbGRcbiIsIHJfMTM4ICgpKTsNCnByaW50ZiAoIi0xMzcgPSAlbGRcbiIs IHJfMTM3ICgpKTsNCnByaW50ZiAoIi0xMzYgPSAlbGRcbiIsIHJfMTM2ICgp KTsNCnByaW50ZiAoIi0xMzUgPSAlbGRcbiIsIHJfMTM1ICgpKTsNCnByaW50 ZiAoIi0xMzQgPSAlbGRcbiIsIHJfMTM0ICgpKTsNCnByaW50ZiAoIi0xMzMg PSAlbGRcbiIsIHJfMTMzICgpKTsNCnByaW50ZiAoIi0xMzIgPSAlbGRcbiIs IHJfMTMyICgpKTsNCnByaW50ZiAoIi0xMzEgPSAlbGRcbiIsIHJfMTMxICgp KTsNCnByaW50ZiAoIi0xMzAgPSAlbGRcbiIsIHJfMTMwICgpKTsNCnByaW50 ZiAoIi0xMjkgPSAlbGRcbiIsIHJfMTI5ICgpKTsNCi8qIG1vdmUubCAjeCxE biAtPiBtb3ZlcS5sICMyNTUteCxEbiArIG5vdC5iIERuLCByYW5nZSBbMTI4 LCAyNTVdLiAqLw0KcHJpbnRmICgiMTI4ID0gJWxkXG4iLCByMTI4ICgpKTsN CnByaW50ZiAoIjEyOSA9ICVsZFxuIiwgcjEyOSAoKSk7DQpwcmludGYgKCIx MzAgPSAlbGRcbiIsIHIxMzAgKCkpOw0KcHJpbnRmICgiMTMxID0gJWxkXG4i LCByMTMxICgpKTsNCnByaW50ZiAoIjEzMiA9ICVsZFxuIiwgcjEzMiAoKSk7 DQpwcmludGYgKCIxMzMgPSAlbGRcbiIsIHIxMzMgKCkpOw0KcHJpbnRmICgi MTM0ID0gJWxkXG4iLCByMTM0ICgpKTsNCnByaW50ZiAoIjEzNSA9ICVsZFxu IiwgcjEzNSAoKSk7DQpwcmludGYgKCIxMzYgPSAlbGRcbiIsIHIxMzYgKCkp Ow0KcHJpbnRmICgiMTM3ID0gJWxkXG4iLCByMTM3ICgpKTsNCnByaW50ZiAo IjEzOCA9ICVsZFxuIiwgcjEzOCAoKSk7DQpwcmludGYgKCIxMzkgPSAlbGRc biIsIHIxMzkgKCkpOw0KcHJpbnRmICgiMTQwID0gJWxkXG4iLCByMTQwICgp KTsNCnByaW50ZiAoIjE0MSA9ICVsZFxuIiwgcjE0MSAoKSk7DQpwcmludGYg KCIxNDIgPSAlbGRcbiIsIHIxNDIgKCkpOw0KcHJpbnRmICgiMTQzID0gJWxk XG4iLCByMTQzICgpKTsNCnByaW50ZiAoIjE0NCA9ICVsZFxuIiwgcjE0NCAo KSk7DQpwcmludGYgKCIxNDUgPSAlbGRcbiIsIHIxNDUgKCkpOw0KcHJpbnRm ICgiMTQ2ID0gJWxkXG4iLCByMTQ2ICgpKTsNCnByaW50ZiAoIjE0NyA9ICVs ZFxuIiwgcjE0NyAoKSk7DQpwcmludGYgKCIxNDggPSAlbGRcbiIsIHIxNDgg KCkpOw0KcHJpbnRmICgiMTQ5ID0gJWxkXG4iLCByMTQ5ICgpKTsNCnByaW50 ZiAoIjE1MCA9ICVsZFxuIiwgcjE1MCAoKSk7DQpwcmludGYgKCIxNTEgPSAl bGRcbiIsIHIxNTEgKCkpOw0KcHJpbnRmICgiMTUyID0gJWxkXG4iLCByMTUy ICgpKTsNCnByaW50ZiAoIjE1MyA9ICVsZFxuIiwgcjE1MyAoKSk7DQpwcmlu dGYgKCIxNTQgPSAlbGRcbiIsIHIxNTQgKCkpOw0KcHJpbnRmICgiMTU1ID0g JWxkXG4iLCByMTU1ICgpKTsNCnByaW50ZiAoIjE1NiA9ICVsZFxuIiwgcjE1 NiAoKSk7DQpwcmludGYgKCIxNTcgPSAlbGRcbiIsIHIxNTcgKCkpOw0KcHJp bnRmICgiMTU4ID0gJWxkXG4iLCByMTU4ICgpKTsNCnByaW50ZiAoIjE1OSA9 ICVsZFxuIiwgcjE1OSAoKSk7DQpwcmludGYgKCIxNjAgPSAlbGRcbiIsIHIx NjAgKCkpOw0KcHJpbnRmICgiMTYxID0gJWxkXG4iLCByMTYxICgpKTsNCnBy aW50ZiAoIjE2MiA9ICVsZFxuIiwgcjE2MiAoKSk7DQpwcmludGYgKCIxNjMg PSAlbGRcbiIsIHIxNjMgKCkpOw0KcHJpbnRmICgiMTY0ID0gJWxkXG4iLCBy MTY0ICgpKTsNCnByaW50ZiAoIjE2NSA9ICVsZFxuIiwgcjE2NSAoKSk7DQpw cmludGYgKCIxNjYgPSAlbGRcbiIsIHIxNjYgKCkpOw0KcHJpbnRmICgiMTY3 ID0gJWxkXG4iLCByMTY3ICgpKTsNCnByaW50ZiAoIjE2OCA9ICVsZFxuIiwg cjE2OCAoKSk7DQpwcmludGYgKCIxNjkgPSAlbGRcbiIsIHIxNjkgKCkpOw0K cHJpbnRmICgiMTcwID0gJWxkXG4iLCByMTcwICgpKTsNCnByaW50ZiAoIjE3 MSA9ICVsZFxuIiwgcjE3MSAoKSk7DQpwcmludGYgKCIxNzIgPSAlbGRcbiIs IHIxNzIgKCkpOw0KcHJpbnRmICgiMTczID0gJWxkXG4iLCByMTczICgpKTsN CnByaW50ZiAoIjE3NCA9ICVsZFxuIiwgcjE3NCAoKSk7DQpwcmludGYgKCIx NzUgPSAlbGRcbiIsIHIxNzUgKCkpOw0KcHJpbnRmICgiMTc2ID0gJWxkXG4i LCByMTc2ICgpKTsNCnByaW50ZiAoIjE3NyA9ICVsZFxuIiwgcjE3NyAoKSk7 DQpwcmludGYgKCIxNzggPSAlbGRcbiIsIHIxNzggKCkpOw0KcHJpbnRmICgi MTc5ID0gJWxkXG4iLCByMTc5ICgpKTsNCnByaW50ZiAoIjE4MCA9ICVsZFxu IiwgcjE4MCAoKSk7DQpwcmludGYgKCIxODEgPSAlbGRcbiIsIHIxODEgKCkp Ow0KcHJpbnRmICgiMTgyID0gJWxkXG4iLCByMTgyICgpKTsNCnByaW50ZiAo IjE4MyA9ICVsZFxuIiwgcjE4MyAoKSk7DQpwcmludGYgKCIxODQgPSAlbGRc biIsIHIxODQgKCkpOw0KcHJpbnRmICgiMTg1ID0gJWxkXG4iLCByMTg1ICgp KTsNCnByaW50ZiAoIjE4NiA9ICVsZFxuIiwgcjE4NiAoKSk7DQpwcmludGYg KCIxODcgPSAlbGRcbiIsIHIxODcgKCkpOw0KcHJpbnRmICgiMTg4ID0gJWxk XG4iLCByMTg4ICgpKTsNCnByaW50ZiAoIjE4OSA9ICVsZFxuIiwgcjE4OSAo KSk7DQpwcmludGYgKCIxOTAgPSAlbGRcbiIsIHIxOTAgKCkpOw0KcHJpbnRm ICgiMTkxID0gJWxkXG4iLCByMTkxICgpKTsNCnByaW50ZiAoIjE5MiA9ICVs ZFxuIiwgcjE5MiAoKSk7DQpwcmludGYgKCIxOTMgPSAlbGRcbiIsIHIxOTMg KCkpOw0KcHJpbnRmICgiMTk0ID0gJWxkXG4iLCByMTk0ICgpKTsNCnByaW50 ZiAoIjE5NSA9ICVsZFxuIiwgcjE5NSAoKSk7DQpwcmludGYgKCIxOTYgPSAl bGRcbiIsIHIxOTYgKCkpOw0KcHJpbnRmICgiMTk3ID0gJWxkXG4iLCByMTk3 ICgpKTsNCnByaW50ZiAoIjE5OCA9ICVsZFxuIiwgcjE5OCAoKSk7DQpwcmlu dGYgKCIxOTkgPSAlbGRcbiIsIHIxOTkgKCkpOw0KcHJpbnRmICgiMjAwID0g JWxkXG4iLCByMjAwICgpKTsNCnByaW50ZiAoIjIwMSA9ICVsZFxuIiwgcjIw MSAoKSk7DQpwcmludGYgKCIyMDIgPSAlbGRcbiIsIHIyMDIgKCkpOw0KcHJp bnRmICgiMjAzID0gJWxkXG4iLCByMjAzICgpKTsNCnByaW50ZiAoIjIwNCA9 ICVsZFxuIiwgcjIwNCAoKSk7DQpwcmludGYgKCIyMDUgPSAlbGRcbiIsIHIy MDUgKCkpOw0KcHJpbnRmICgiMjA2ID0gJWxkXG4iLCByMjA2ICgpKTsNCnBy aW50ZiAoIjIwNyA9ICVsZFxuIiwgcjIwNyAoKSk7DQpwcmludGYgKCIyMDgg PSAlbGRcbiIsIHIyMDggKCkpOw0KcHJpbnRmICgiMjA5ID0gJWxkXG4iLCBy MjA5ICgpKTsNCnByaW50ZiAoIjIxMCA9ICVsZFxuIiwgcjIxMCAoKSk7DQpw cmludGYgKCIyMTEgPSAlbGRcbiIsIHIyMTEgKCkpOw0KcHJpbnRmICgiMjEy ID0gJWxkXG4iLCByMjEyICgpKTsNCnByaW50ZiAoIjIxMyA9ICVsZFxuIiwg cjIxMyAoKSk7DQpwcmludGYgKCIyMTQgPSAlbGRcbiIsIHIyMTQgKCkpOw0K cHJpbnRmICgiMjE1ID0gJWxkXG4iLCByMjE1ICgpKTsNCnByaW50ZiAoIjIx NiA9ICVsZFxuIiwgcjIxNiAoKSk7DQpwcmludGYgKCIyMTcgPSAlbGRcbiIs IHIyMTcgKCkpOw0KcHJpbnRmICgiMjE4ID0gJWxkXG4iLCByMjE4ICgpKTsN CnByaW50ZiAoIjIxOSA9ICVsZFxuIiwgcjIxOSAoKSk7DQpwcmludGYgKCIy MjAgPSAlbGRcbiIsIHIyMjAgKCkpOw0KcHJpbnRmICgiMjIxID0gJWxkXG4i LCByMjIxICgpKTsNCnByaW50ZiAoIjIyMiA9ICVsZFxuIiwgcjIyMiAoKSk7 DQpwcmludGYgKCIyMjMgPSAlbGRcbiIsIHIyMjMgKCkpOw0KcHJpbnRmICgi MjI0ID0gJWxkXG4iLCByMjI0ICgpKTsNCnByaW50ZiAoIjIyNSA9ICVsZFxu IiwgcjIyNSAoKSk7DQpwcmludGYgKCIyMjYgPSAlbGRcbiIsIHIyMjYgKCkp Ow0KcHJpbnRmICgiMjI3ID0gJWxkXG4iLCByMjI3ICgpKTsNCnByaW50ZiAo IjIyOCA9ICVsZFxuIiwgcjIyOCAoKSk7DQpwcmludGYgKCIyMjkgPSAlbGRc biIsIHIyMjkgKCkpOw0KcHJpbnRmICgiMjMwID0gJWxkXG4iLCByMjMwICgp KTsNCnByaW50ZiAoIjIzMSA9ICVsZFxuIiwgcjIzMSAoKSk7DQpwcmludGYg KCIyMzIgPSAlbGRcbiIsIHIyMzIgKCkpOw0KcHJpbnRmICgiMjMzID0gJWxk XG4iLCByMjMzICgpKTsNCnByaW50ZiAoIjIzNCA9ICVsZFxuIiwgcjIzNCAo KSk7DQpwcmludGYgKCIyMzUgPSAlbGRcbiIsIHIyMzUgKCkpOw0KcHJpbnRm ICgiMjM2ID0gJWxkXG4iLCByMjM2ICgpKTsNCnByaW50ZiAoIjIzNyA9ICVs ZFxuIiwgcjIzNyAoKSk7DQpwcmludGYgKCIyMzggPSAlbGRcbiIsIHIyMzgg KCkpOw0KcHJpbnRmICgiMjM5ID0gJWxkXG4iLCByMjM5ICgpKTsNCnByaW50 ZiAoIjI0MCA9ICVsZFxuIiwgcjI0MCAoKSk7DQpwcmludGYgKCIyNDEgPSAl bGRcbiIsIHIyNDEgKCkpOw0KcHJpbnRmICgiMjQyID0gJWxkXG4iLCByMjQy ICgpKTsNCnByaW50ZiAoIjI0MyA9ICVsZFxuIiwgcjI0MyAoKSk7DQpwcmlu dGYgKCIyNDQgPSAlbGRcbiIsIHIyNDQgKCkpOw0KcHJpbnRmICgiMjQ1ID0g JWxkXG4iLCByMjQ1ICgpKTsNCnByaW50ZiAoIjI0NiA9ICVsZFxuIiwgcjI0 NiAoKSk7DQpwcmludGYgKCIyNDcgPSAlbGRcbiIsIHIyNDcgKCkpOw0KcHJp bnRmICgiMjQ4ID0gJWxkXG4iLCByMjQ4ICgpKTsNCnByaW50ZiAoIjI0OSA9 ICVsZFxuIiwgcjI0OSAoKSk7DQpwcmludGYgKCIyNTAgPSAlbGRcbiIsIHIy NTAgKCkpOw0KcHJpbnRmICgiMjUxID0gJWxkXG4iLCByMjUxICgpKTsNCnBy aW50ZiAoIjI1MiA9ICVsZFxuIiwgcjI1MiAoKSk7DQpwcmludGYgKCIyNTMg PSAlbGRcbiIsIHIyNTMgKCkpOw0KcHJpbnRmICgiMjU0ID0gJWxkXG4iLCBy MjU0ICgpKTsNCnByaW50ZiAoIjI1NSA9ICVsZFxuIiwgcjI1NSAoKSk7DQoN CiAgcmV0dXJuICgwKTsNCn0NCg== --2010703495-851401618-823799462=:7314 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="opt-65536to-65409.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Test the ranges [-65536, -65409] and [65408, 65535] I2luY2x1ZGUgPHN0ZGlvLmg+DQoNCi8qIG1vdmUubCAjeCxEbiAtPiBtb3Zl cS5sICMtNjU1MzcteCxEbiArIG5vdC53IERuLCByYW5nZSBbLTY1NTM2LCAt NjU0MDldLiAqLw0Kc2lnbmVkIGxvbmcgaW50IHJfNjU1MzYgKHZvaWQpIHsg cmV0dXJuICgtNjU1MzYpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTUzNSAo dm9pZCkgeyByZXR1cm4gKC02NTUzNSk7IH0NCnNpZ25lZCBsb25nIGludCBy XzY1NTM0ICh2b2lkKSB7IHJldHVybiAoLTY1NTM0KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHJfNjU1MzMgKHZvaWQpIHsgcmV0dXJuICgtNjU1MzMpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl82NTUzMiAodm9pZCkgeyByZXR1cm4gKC02NTUz Mik7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NTMxICh2b2lkKSB7IHJldHVy biAoLTY1NTMxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU1MzAgKHZvaWQp IHsgcmV0dXJuICgtNjU1MzApOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTUy OSAodm9pZCkgeyByZXR1cm4gKC02NTUyOSk7IH0NCnNpZ25lZCBsb25nIGlu dCByXzY1NTI4ICh2b2lkKSB7IHJldHVybiAoLTY1NTI4KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHJfNjU1MjcgKHZvaWQpIHsgcmV0dXJuICgtNjU1MjcpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl82NTUyNiAodm9pZCkgeyByZXR1cm4gKC02 NTUyNik7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NTI1ICh2b2lkKSB7IHJl dHVybiAoLTY1NTI1KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU1MjQgKHZv aWQpIHsgcmV0dXJuICgtNjU1MjQpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82 NTUyMyAodm9pZCkgeyByZXR1cm4gKC02NTUyMyk7IH0NCnNpZ25lZCBsb25n IGludCByXzY1NTIyICh2b2lkKSB7IHJldHVybiAoLTY1NTIyKTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHJfNjU1MjEgKHZvaWQpIHsgcmV0dXJuICgtNjU1MjEp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTUyMCAodm9pZCkgeyByZXR1cm4g KC02NTUyMCk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NTE5ICh2b2lkKSB7 IHJldHVybiAoLTY1NTE5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU1MTgg KHZvaWQpIHsgcmV0dXJuICgtNjU1MTgpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl82NTUxNyAodm9pZCkgeyByZXR1cm4gKC02NTUxNyk7IH0NCnNpZ25lZCBs b25nIGludCByXzY1NTE2ICh2b2lkKSB7IHJldHVybiAoLTY1NTE2KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHJfNjU1MTUgKHZvaWQpIHsgcmV0dXJuICgtNjU1 MTUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTUxNCAodm9pZCkgeyByZXR1 cm4gKC02NTUxNCk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NTEzICh2b2lk KSB7IHJldHVybiAoLTY1NTEzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU1 MTIgKHZvaWQpIHsgcmV0dXJuICgtNjU1MTIpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl82NTUxMSAodm9pZCkgeyByZXR1cm4gKC02NTUxMSk7IH0NCnNpZ25l ZCBsb25nIGludCByXzY1NTEwICh2b2lkKSB7IHJldHVybiAoLTY1NTEwKTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU1MDkgKHZvaWQpIHsgcmV0dXJuICgt NjU1MDkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTUwOCAodm9pZCkgeyBy ZXR1cm4gKC02NTUwOCk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NTA3ICh2 b2lkKSB7IHJldHVybiAoLTY1NTA3KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJf NjU1MDYgKHZvaWQpIHsgcmV0dXJuICgtNjU1MDYpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl82NTUwNSAodm9pZCkgeyByZXR1cm4gKC02NTUwNSk7IH0NCnNp Z25lZCBsb25nIGludCByXzY1NTA0ICh2b2lkKSB7IHJldHVybiAoLTY1NTA0 KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU1MDMgKHZvaWQpIHsgcmV0dXJu ICgtNjU1MDMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTUwMiAodm9pZCkg eyByZXR1cm4gKC02NTUwMik7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NTAx ICh2b2lkKSB7IHJldHVybiAoLTY1NTAxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHJfNjU1MDAgKHZvaWQpIHsgcmV0dXJuICgtNjU1MDApOyB9DQpzaWduZWQg bG9uZyBpbnQgcl82NTQ5OSAodm9pZCkgeyByZXR1cm4gKC02NTQ5OSk7IH0N CnNpZ25lZCBsb25nIGludCByXzY1NDk4ICh2b2lkKSB7IHJldHVybiAoLTY1 NDk4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0OTcgKHZvaWQpIHsgcmV0 dXJuICgtNjU0OTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQ5NiAodm9p ZCkgeyByZXR1cm4gKC02NTQ5Nik7IH0NCnNpZ25lZCBsb25nIGludCByXzY1 NDk1ICh2b2lkKSB7IHJldHVybiAoLTY1NDk1KTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHJfNjU0OTQgKHZvaWQpIHsgcmV0dXJuICgtNjU0OTQpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl82NTQ5MyAodm9pZCkgeyByZXR1cm4gKC02NTQ5Myk7 IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDkyICh2b2lkKSB7IHJldHVybiAo LTY1NDkyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0OTEgKHZvaWQpIHsg cmV0dXJuICgtNjU0OTEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQ5MCAo dm9pZCkgeyByZXR1cm4gKC02NTQ5MCk7IH0NCnNpZ25lZCBsb25nIGludCBy XzY1NDg5ICh2b2lkKSB7IHJldHVybiAoLTY1NDg5KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHJfNjU0ODggKHZvaWQpIHsgcmV0dXJuICgtNjU0ODgpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl82NTQ4NyAodm9pZCkgeyByZXR1cm4gKC02NTQ4 Nyk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDg2ICh2b2lkKSB7IHJldHVy biAoLTY1NDg2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0ODUgKHZvaWQp IHsgcmV0dXJuICgtNjU0ODUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQ4 NCAodm9pZCkgeyByZXR1cm4gKC02NTQ4NCk7IH0NCnNpZ25lZCBsb25nIGlu dCByXzY1NDgzICh2b2lkKSB7IHJldHVybiAoLTY1NDgzKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHJfNjU0ODIgKHZvaWQpIHsgcmV0dXJuICgtNjU0ODIpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl82NTQ4MSAodm9pZCkgeyByZXR1cm4gKC02 NTQ4MSk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDgwICh2b2lkKSB7IHJl dHVybiAoLTY1NDgwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0NzkgKHZv aWQpIHsgcmV0dXJuICgtNjU0NzkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82 NTQ3OCAodm9pZCkgeyByZXR1cm4gKC02NTQ3OCk7IH0NCnNpZ25lZCBsb25n IGludCByXzY1NDc3ICh2b2lkKSB7IHJldHVybiAoLTY1NDc3KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHJfNjU0NzYgKHZvaWQpIHsgcmV0dXJuICgtNjU0NzYp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQ3NSAodm9pZCkgeyByZXR1cm4g KC02NTQ3NSk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDc0ICh2b2lkKSB7 IHJldHVybiAoLTY1NDc0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0NzMg KHZvaWQpIHsgcmV0dXJuICgtNjU0NzMpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl82NTQ3MiAodm9pZCkgeyByZXR1cm4gKC02NTQ3Mik7IH0NCnNpZ25lZCBs b25nIGludCByXzY1NDcxICh2b2lkKSB7IHJldHVybiAoLTY1NDcxKTsgfQ0K c2lnbmVkIGxvbmcgaW50IHJfNjU0NzAgKHZvaWQpIHsgcmV0dXJuICgtNjU0 NzApOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQ2OSAodm9pZCkgeyByZXR1 cm4gKC02NTQ2OSk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDY4ICh2b2lk KSB7IHJldHVybiAoLTY1NDY4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0 NjcgKHZvaWQpIHsgcmV0dXJuICgtNjU0NjcpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl82NTQ2NiAodm9pZCkgeyByZXR1cm4gKC02NTQ2Nik7IH0NCnNpZ25l ZCBsb25nIGludCByXzY1NDY1ICh2b2lkKSB7IHJldHVybiAoLTY1NDY1KTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0NjQgKHZvaWQpIHsgcmV0dXJuICgt NjU0NjQpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQ2MyAodm9pZCkgeyBy ZXR1cm4gKC02NTQ2Myk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDYyICh2 b2lkKSB7IHJldHVybiAoLTY1NDYyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJf NjU0NjEgKHZvaWQpIHsgcmV0dXJuICgtNjU0NjEpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl82NTQ2MCAodm9pZCkgeyByZXR1cm4gKC02NTQ2MCk7IH0NCnNp Z25lZCBsb25nIGludCByXzY1NDU5ICh2b2lkKSB7IHJldHVybiAoLTY1NDU5 KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0NTggKHZvaWQpIHsgcmV0dXJu ICgtNjU0NTgpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQ1NyAodm9pZCkg eyByZXR1cm4gKC02NTQ1Nyk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDU2 ICh2b2lkKSB7IHJldHVybiAoLTY1NDU2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHJfNjU0NTUgKHZvaWQpIHsgcmV0dXJuICgtNjU0NTUpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl82NTQ1NCAodm9pZCkgeyByZXR1cm4gKC02NTQ1NCk7IH0N CnNpZ25lZCBsb25nIGludCByXzY1NDUzICh2b2lkKSB7IHJldHVybiAoLTY1 NDUzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0NTIgKHZvaWQpIHsgcmV0 dXJuICgtNjU0NTIpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQ1MSAodm9p ZCkgeyByZXR1cm4gKC02NTQ1MSk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1 NDUwICh2b2lkKSB7IHJldHVybiAoLTY1NDUwKTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHJfNjU0NDkgKHZvaWQpIHsgcmV0dXJuICgtNjU0NDkpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl82NTQ0OCAodm9pZCkgeyByZXR1cm4gKC02NTQ0OCk7 IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDQ3ICh2b2lkKSB7IHJldHVybiAo LTY1NDQ3KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0NDYgKHZvaWQpIHsg cmV0dXJuICgtNjU0NDYpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQ0NSAo dm9pZCkgeyByZXR1cm4gKC02NTQ0NSk7IH0NCnNpZ25lZCBsb25nIGludCBy XzY1NDQ0ICh2b2lkKSB7IHJldHVybiAoLTY1NDQ0KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHJfNjU0NDMgKHZvaWQpIHsgcmV0dXJuICgtNjU0NDMpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl82NTQ0MiAodm9pZCkgeyByZXR1cm4gKC02NTQ0 Mik7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDQxICh2b2lkKSB7IHJldHVy biAoLTY1NDQxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0NDAgKHZvaWQp IHsgcmV0dXJuICgtNjU0NDApOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQz OSAodm9pZCkgeyByZXR1cm4gKC02NTQzOSk7IH0NCnNpZ25lZCBsb25nIGlu dCByXzY1NDM4ICh2b2lkKSB7IHJldHVybiAoLTY1NDM4KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHJfNjU0MzcgKHZvaWQpIHsgcmV0dXJuICgtNjU0MzcpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl82NTQzNiAodm9pZCkgeyByZXR1cm4gKC02 NTQzNik7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDM1ICh2b2lkKSB7IHJl dHVybiAoLTY1NDM1KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0MzQgKHZv aWQpIHsgcmV0dXJuICgtNjU0MzQpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82 NTQzMyAodm9pZCkgeyByZXR1cm4gKC02NTQzMyk7IH0NCnNpZ25lZCBsb25n IGludCByXzY1NDMyICh2b2lkKSB7IHJldHVybiAoLTY1NDMyKTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHJfNjU0MzEgKHZvaWQpIHsgcmV0dXJuICgtNjU0MzEp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQzMCAodm9pZCkgeyByZXR1cm4g KC02NTQzMCk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDI5ICh2b2lkKSB7 IHJldHVybiAoLTY1NDI5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0Mjgg KHZvaWQpIHsgcmV0dXJuICgtNjU0MjgpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl82NTQyNyAodm9pZCkgeyByZXR1cm4gKC02NTQyNyk7IH0NCnNpZ25lZCBs b25nIGludCByXzY1NDI2ICh2b2lkKSB7IHJldHVybiAoLTY1NDI2KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHJfNjU0MjUgKHZvaWQpIHsgcmV0dXJuICgtNjU0 MjUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQyNCAodm9pZCkgeyByZXR1 cm4gKC02NTQyNCk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDIzICh2b2lk KSB7IHJldHVybiAoLTY1NDIzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0 MjIgKHZvaWQpIHsgcmV0dXJuICgtNjU0MjIpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl82NTQyMSAodm9pZCkgeyByZXR1cm4gKC02NTQyMSk7IH0NCnNpZ25l ZCBsb25nIGludCByXzY1NDIwICh2b2lkKSB7IHJldHVybiAoLTY1NDIwKTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0MTkgKHZvaWQpIHsgcmV0dXJuICgt NjU0MTkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQxOCAodm9pZCkgeyBy ZXR1cm4gKC02NTQxOCk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDE3ICh2 b2lkKSB7IHJldHVybiAoLTY1NDE3KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJf NjU0MTYgKHZvaWQpIHsgcmV0dXJuICgtNjU0MTYpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl82NTQxNSAodm9pZCkgeyByZXR1cm4gKC02NTQxNSk7IH0NCnNp Z25lZCBsb25nIGludCByXzY1NDE0ICh2b2lkKSB7IHJldHVybiAoLTY1NDE0 KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0MTMgKHZvaWQpIHsgcmV0dXJu ICgtNjU0MTMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQxMiAodm9pZCkg eyByZXR1cm4gKC02NTQxMik7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDEx ICh2b2lkKSB7IHJldHVybiAoLTY1NDExKTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHJfNjU0MTAgKHZvaWQpIHsgcmV0dXJuICgtNjU0MTApOyB9DQpzaWduZWQg bG9uZyBpbnQgcl82NTQwOSAodm9pZCkgeyByZXR1cm4gKC02NTQwOSk7IH0N Ci8qIG1vdmUubCAjeCxEbiAtPiBtb3ZlcS5sICM2NTUzNS14LERuICsgbm90 LncgRG4sIHJhbmdlIFs2NTQwOCwgNjU1MzVdLiAqLw0Kc2lnbmVkIGxvbmcg aW50IHI2NTQwOCAodm9pZCkgeyByZXR1cm4gKDY1NDA4KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI2NTQwOSAodm9pZCkgeyByZXR1cm4gKDY1NDA5KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHI2NTQxMCAodm9pZCkgeyByZXR1cm4gKDY1NDEw KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQxMSAodm9pZCkgeyByZXR1cm4g KDY1NDExKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQxMiAodm9pZCkgeyBy ZXR1cm4gKDY1NDEyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQxMyAodm9p ZCkgeyByZXR1cm4gKDY1NDEzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQx NCAodm9pZCkgeyByZXR1cm4gKDY1NDE0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHI2NTQxNSAodm9pZCkgeyByZXR1cm4gKDY1NDE1KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHI2NTQxNiAodm9pZCkgeyByZXR1cm4gKDY1NDE2KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHI2NTQxNyAodm9pZCkgeyByZXR1cm4gKDY1NDE3KTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQxOCAodm9pZCkgeyByZXR1cm4gKDY1 NDE4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQxOSAodm9pZCkgeyByZXR1 cm4gKDY1NDE5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQyMCAodm9pZCkg eyByZXR1cm4gKDY1NDIwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQyMSAo dm9pZCkgeyByZXR1cm4gKDY1NDIxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2 NTQyMiAodm9pZCkgeyByZXR1cm4gKDY1NDIyKTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHI2NTQyMyAodm9pZCkgeyByZXR1cm4gKDY1NDIzKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI2NTQyNCAodm9pZCkgeyByZXR1cm4gKDY1NDI0KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHI2NTQyNSAodm9pZCkgeyByZXR1cm4gKDY1NDI1 KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQyNiAodm9pZCkgeyByZXR1cm4g KDY1NDI2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQyNyAodm9pZCkgeyBy ZXR1cm4gKDY1NDI3KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQyOCAodm9p ZCkgeyByZXR1cm4gKDY1NDI4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQy OSAodm9pZCkgeyByZXR1cm4gKDY1NDI5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHI2NTQzMCAodm9pZCkgeyByZXR1cm4gKDY1NDMwKTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHI2NTQzMSAodm9pZCkgeyByZXR1cm4gKDY1NDMxKTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHI2NTQzMiAodm9pZCkgeyByZXR1cm4gKDY1NDMyKTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQzMyAodm9pZCkgeyByZXR1cm4gKDY1 NDMzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQzNCAodm9pZCkgeyByZXR1 cm4gKDY1NDM0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQzNSAodm9pZCkg eyByZXR1cm4gKDY1NDM1KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQzNiAo dm9pZCkgeyByZXR1cm4gKDY1NDM2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2 NTQzNyAodm9pZCkgeyByZXR1cm4gKDY1NDM3KTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHI2NTQzOCAodm9pZCkgeyByZXR1cm4gKDY1NDM4KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI2NTQzOSAodm9pZCkgeyByZXR1cm4gKDY1NDM5KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHI2NTQ0MCAodm9pZCkgeyByZXR1cm4gKDY1NDQw KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ0MSAodm9pZCkgeyByZXR1cm4g KDY1NDQxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ0MiAodm9pZCkgeyBy ZXR1cm4gKDY1NDQyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ0MyAodm9p ZCkgeyByZXR1cm4gKDY1NDQzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ0 NCAodm9pZCkgeyByZXR1cm4gKDY1NDQ0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHI2NTQ0NSAodm9pZCkgeyByZXR1cm4gKDY1NDQ1KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHI2NTQ0NiAodm9pZCkgeyByZXR1cm4gKDY1NDQ2KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHI2NTQ0NyAodm9pZCkgeyByZXR1cm4gKDY1NDQ3KTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ0OCAodm9pZCkgeyByZXR1cm4gKDY1 NDQ4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ0OSAodm9pZCkgeyByZXR1 cm4gKDY1NDQ5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ1MCAodm9pZCkg eyByZXR1cm4gKDY1NDUwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ1MSAo dm9pZCkgeyByZXR1cm4gKDY1NDUxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2 NTQ1MiAodm9pZCkgeyByZXR1cm4gKDY1NDUyKTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHI2NTQ1MyAodm9pZCkgeyByZXR1cm4gKDY1NDUzKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI2NTQ1NCAodm9pZCkgeyByZXR1cm4gKDY1NDU0KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHI2NTQ1NSAodm9pZCkgeyByZXR1cm4gKDY1NDU1 KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ1NiAodm9pZCkgeyByZXR1cm4g KDY1NDU2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ1NyAodm9pZCkgeyBy ZXR1cm4gKDY1NDU3KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ1OCAodm9p ZCkgeyByZXR1cm4gKDY1NDU4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ1 OSAodm9pZCkgeyByZXR1cm4gKDY1NDU5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHI2NTQ2MCAodm9pZCkgeyByZXR1cm4gKDY1NDYwKTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHI2NTQ2MSAodm9pZCkgeyByZXR1cm4gKDY1NDYxKTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHI2NTQ2MiAodm9pZCkgeyByZXR1cm4gKDY1NDYyKTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ2MyAodm9pZCkgeyByZXR1cm4gKDY1 NDYzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ2NCAodm9pZCkgeyByZXR1 cm4gKDY1NDY0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ2NSAodm9pZCkg eyByZXR1cm4gKDY1NDY1KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ2NiAo dm9pZCkgeyByZXR1cm4gKDY1NDY2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2 NTQ2NyAodm9pZCkgeyByZXR1cm4gKDY1NDY3KTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHI2NTQ2OCAodm9pZCkgeyByZXR1cm4gKDY1NDY4KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI2NTQ2OSAodm9pZCkgeyByZXR1cm4gKDY1NDY5KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHI2NTQ3MCAodm9pZCkgeyByZXR1cm4gKDY1NDcw KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ3MSAodm9pZCkgeyByZXR1cm4g KDY1NDcxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ3MiAodm9pZCkgeyBy ZXR1cm4gKDY1NDcyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ3MyAodm9p ZCkgeyByZXR1cm4gKDY1NDczKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ3 NCAodm9pZCkgeyByZXR1cm4gKDY1NDc0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHI2NTQ3NSAodm9pZCkgeyByZXR1cm4gKDY1NDc1KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHI2NTQ3NiAodm9pZCkgeyByZXR1cm4gKDY1NDc2KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHI2NTQ3NyAodm9pZCkgeyByZXR1cm4gKDY1NDc3KTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ3OCAodm9pZCkgeyByZXR1cm4gKDY1 NDc4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ3OSAodm9pZCkgeyByZXR1 cm4gKDY1NDc5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ4MCAodm9pZCkg eyByZXR1cm4gKDY1NDgwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ4MSAo dm9pZCkgeyByZXR1cm4gKDY1NDgxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2 NTQ4MiAodm9pZCkgeyByZXR1cm4gKDY1NDgyKTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHI2NTQ4MyAodm9pZCkgeyByZXR1cm4gKDY1NDgzKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI2NTQ4NCAodm9pZCkgeyByZXR1cm4gKDY1NDg0KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHI2NTQ4NSAodm9pZCkgeyByZXR1cm4gKDY1NDg1 KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ4NiAodm9pZCkgeyByZXR1cm4g KDY1NDg2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ4NyAodm9pZCkgeyBy ZXR1cm4gKDY1NDg3KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ4OCAodm9p ZCkgeyByZXR1cm4gKDY1NDg4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ4 OSAodm9pZCkgeyByZXR1cm4gKDY1NDg5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHI2NTQ5MCAodm9pZCkgeyByZXR1cm4gKDY1NDkwKTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHI2NTQ5MSAodm9pZCkgeyByZXR1cm4gKDY1NDkxKTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHI2NTQ5MiAodm9pZCkgeyByZXR1cm4gKDY1NDkyKTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ5MyAodm9pZCkgeyByZXR1cm4gKDY1 NDkzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ5NCAodm9pZCkgeyByZXR1 cm4gKDY1NDk0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ5NSAodm9pZCkg eyByZXR1cm4gKDY1NDk1KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTQ5NiAo dm9pZCkgeyByZXR1cm4gKDY1NDk2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2 NTQ5NyAodm9pZCkgeyByZXR1cm4gKDY1NDk3KTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHI2NTQ5OCAodm9pZCkgeyByZXR1cm4gKDY1NDk4KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI2NTQ5OSAodm9pZCkgeyByZXR1cm4gKDY1NDk5KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHI2NTUwMCAodm9pZCkgeyByZXR1cm4gKDY1NTAw KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUwMSAodm9pZCkgeyByZXR1cm4g KDY1NTAxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUwMiAodm9pZCkgeyBy ZXR1cm4gKDY1NTAyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUwMyAodm9p ZCkgeyByZXR1cm4gKDY1NTAzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUw NCAodm9pZCkgeyByZXR1cm4gKDY1NTA0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHI2NTUwNSAodm9pZCkgeyByZXR1cm4gKDY1NTA1KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHI2NTUwNiAodm9pZCkgeyByZXR1cm4gKDY1NTA2KTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHI2NTUwNyAodm9pZCkgeyByZXR1cm4gKDY1NTA3KTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUwOCAodm9pZCkgeyByZXR1cm4gKDY1 NTA4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUwOSAodm9pZCkgeyByZXR1 cm4gKDY1NTA5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUxMCAodm9pZCkg eyByZXR1cm4gKDY1NTEwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUxMSAo dm9pZCkgeyByZXR1cm4gKDY1NTExKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2 NTUxMiAodm9pZCkgeyByZXR1cm4gKDY1NTEyKTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHI2NTUxMyAodm9pZCkgeyByZXR1cm4gKDY1NTEzKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI2NTUxNCAodm9pZCkgeyByZXR1cm4gKDY1NTE0KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHI2NTUxNSAodm9pZCkgeyByZXR1cm4gKDY1NTE1 KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUxNiAodm9pZCkgeyByZXR1cm4g KDY1NTE2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUxNyAodm9pZCkgeyBy ZXR1cm4gKDY1NTE3KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUxOCAodm9p ZCkgeyByZXR1cm4gKDY1NTE4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUx OSAodm9pZCkgeyByZXR1cm4gKDY1NTE5KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHI2NTUyMCAodm9pZCkgeyByZXR1cm4gKDY1NTIwKTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHI2NTUyMSAodm9pZCkgeyByZXR1cm4gKDY1NTIxKTsgfQ0Kc2ln bmVkIGxvbmcgaW50IHI2NTUyMiAodm9pZCkgeyByZXR1cm4gKDY1NTIyKTsg fQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUyMyAodm9pZCkgeyByZXR1cm4gKDY1 NTIzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUyNCAodm9pZCkgeyByZXR1 cm4gKDY1NTI0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUyNSAodm9pZCkg eyByZXR1cm4gKDY1NTI1KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUyNiAo dm9pZCkgeyByZXR1cm4gKDY1NTI2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2 NTUyNyAodm9pZCkgeyByZXR1cm4gKDY1NTI3KTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHI2NTUyOCAodm9pZCkgeyByZXR1cm4gKDY1NTI4KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI2NTUyOSAodm9pZCkgeyByZXR1cm4gKDY1NTI5KTsgfQ0K c2lnbmVkIGxvbmcgaW50IHI2NTUzMCAodm9pZCkgeyByZXR1cm4gKDY1NTMw KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUzMSAodm9pZCkgeyByZXR1cm4g KDY1NTMxKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUzMiAodm9pZCkgeyBy ZXR1cm4gKDY1NTMyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUzMyAodm9p ZCkgeyByZXR1cm4gKDY1NTMzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NTUz NCAodm9pZCkgeyByZXR1cm4gKDY1NTM0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHI2NTUzNSAodm9pZCkgeyByZXR1cm4gKDY1NTM1KTsgfQ0KDQppbnQgbWFp biAoaW50IGFyZ2MsIGNoYXIgKiBhcmd2W10pDQp7DQovKiBtb3ZlLmwgI3gs RG4gLT4gbW92ZXEubCAjLTY1NTM3LXgsRG4gKyBub3QudyBEbiwgcmFuZ2Ug Wy02NTUzNiwgLTY1NDA5XS4gKi8NCnByaW50ZiAoIi02NTUzNiA9ICVsZFxu Iiwgcl82NTUzNiAoKSk7DQpwcmludGYgKCItNjU1MzUgPSAlbGRcbiIsIHJf NjU1MzUgKCkpOw0KcHJpbnRmICgiLTY1NTM0ID0gJWxkXG4iLCByXzY1NTM0 ICgpKTsNCnByaW50ZiAoIi02NTUzMyA9ICVsZFxuIiwgcl82NTUzMyAoKSk7 DQpwcmludGYgKCItNjU1MzIgPSAlbGRcbiIsIHJfNjU1MzIgKCkpOw0KcHJp bnRmICgiLTY1NTMxID0gJWxkXG4iLCByXzY1NTMxICgpKTsNCnByaW50ZiAo Ii02NTUzMCA9ICVsZFxuIiwgcl82NTUzMCAoKSk7DQpwcmludGYgKCItNjU1 MjkgPSAlbGRcbiIsIHJfNjU1MjkgKCkpOw0KcHJpbnRmICgiLTY1NTI4ID0g JWxkXG4iLCByXzY1NTI4ICgpKTsNCnByaW50ZiAoIi02NTUyNyA9ICVsZFxu Iiwgcl82NTUyNyAoKSk7DQpwcmludGYgKCItNjU1MjYgPSAlbGRcbiIsIHJf NjU1MjYgKCkpOw0KcHJpbnRmICgiLTY1NTI1ID0gJWxkXG4iLCByXzY1NTI1 ICgpKTsNCnByaW50ZiAoIi02NTUyNCA9ICVsZFxuIiwgcl82NTUyNCAoKSk7 DQpwcmludGYgKCItNjU1MjMgPSAlbGRcbiIsIHJfNjU1MjMgKCkpOw0KcHJp bnRmICgiLTY1NTIyID0gJWxkXG4iLCByXzY1NTIyICgpKTsNCnByaW50ZiAo Ii02NTUyMSA9ICVsZFxuIiwgcl82NTUyMSAoKSk7DQpwcmludGYgKCItNjU1 MjAgPSAlbGRcbiIsIHJfNjU1MjAgKCkpOw0KcHJpbnRmICgiLTY1NTE5ID0g JWxkXG4iLCByXzY1NTE5ICgpKTsNCnByaW50ZiAoIi02NTUxOCA9ICVsZFxu Iiwgcl82NTUxOCAoKSk7DQpwcmludGYgKCItNjU1MTcgPSAlbGRcbiIsIHJf NjU1MTcgKCkpOw0KcHJpbnRmICgiLTY1NTE2ID0gJWxkXG4iLCByXzY1NTE2 ICgpKTsNCnByaW50ZiAoIi02NTUxNSA9ICVsZFxuIiwgcl82NTUxNSAoKSk7 DQpwcmludGYgKCItNjU1MTQgPSAlbGRcbiIsIHJfNjU1MTQgKCkpOw0KcHJp bnRmICgiLTY1NTEzID0gJWxkXG4iLCByXzY1NTEzICgpKTsNCnByaW50ZiAo Ii02NTUxMiA9ICVsZFxuIiwgcl82NTUxMiAoKSk7DQpwcmludGYgKCItNjU1 MTEgPSAlbGRcbiIsIHJfNjU1MTEgKCkpOw0KcHJpbnRmICgiLTY1NTEwID0g JWxkXG4iLCByXzY1NTEwICgpKTsNCnByaW50ZiAoIi02NTUwOSA9ICVsZFxu Iiwgcl82NTUwOSAoKSk7DQpwcmludGYgKCItNjU1MDggPSAlbGRcbiIsIHJf NjU1MDggKCkpOw0KcHJpbnRmICgiLTY1NTA3ID0gJWxkXG4iLCByXzY1NTA3 ICgpKTsNCnByaW50ZiAoIi02NTUwNiA9ICVsZFxuIiwgcl82NTUwNiAoKSk7 DQpwcmludGYgKCItNjU1MDUgPSAlbGRcbiIsIHJfNjU1MDUgKCkpOw0KcHJp bnRmICgiLTY1NTA0ID0gJWxkXG4iLCByXzY1NTA0ICgpKTsNCnByaW50ZiAo Ii02NTUwMyA9ICVsZFxuIiwgcl82NTUwMyAoKSk7DQpwcmludGYgKCItNjU1 MDIgPSAlbGRcbiIsIHJfNjU1MDIgKCkpOw0KcHJpbnRmICgiLTY1NTAxID0g JWxkXG4iLCByXzY1NTAxICgpKTsNCnByaW50ZiAoIi02NTUwMCA9ICVsZFxu Iiwgcl82NTUwMCAoKSk7DQpwcmludGYgKCItNjU0OTkgPSAlbGRcbiIsIHJf NjU0OTkgKCkpOw0KcHJpbnRmICgiLTY1NDk4ID0gJWxkXG4iLCByXzY1NDk4 ICgpKTsNCnByaW50ZiAoIi02NTQ5NyA9ICVsZFxuIiwgcl82NTQ5NyAoKSk7 DQpwcmludGYgKCItNjU0OTYgPSAlbGRcbiIsIHJfNjU0OTYgKCkpOw0KcHJp bnRmICgiLTY1NDk1ID0gJWxkXG4iLCByXzY1NDk1ICgpKTsNCnByaW50ZiAo Ii02NTQ5NCA9ICVsZFxuIiwgcl82NTQ5NCAoKSk7DQpwcmludGYgKCItNjU0 OTMgPSAlbGRcbiIsIHJfNjU0OTMgKCkpOw0KcHJpbnRmICgiLTY1NDkyID0g JWxkXG4iLCByXzY1NDkyICgpKTsNCnByaW50ZiAoIi02NTQ5MSA9ICVsZFxu Iiwgcl82NTQ5MSAoKSk7DQpwcmludGYgKCItNjU0OTAgPSAlbGRcbiIsIHJf NjU0OTAgKCkpOw0KcHJpbnRmICgiLTY1NDg5ID0gJWxkXG4iLCByXzY1NDg5 ICgpKTsNCnByaW50ZiAoIi02NTQ4OCA9ICVsZFxuIiwgcl82NTQ4OCAoKSk7 DQpwcmludGYgKCItNjU0ODcgPSAlbGRcbiIsIHJfNjU0ODcgKCkpOw0KcHJp bnRmICgiLTY1NDg2ID0gJWxkXG4iLCByXzY1NDg2ICgpKTsNCnByaW50ZiAo Ii02NTQ4NSA9ICVsZFxuIiwgcl82NTQ4NSAoKSk7DQpwcmludGYgKCItNjU0 ODQgPSAlbGRcbiIsIHJfNjU0ODQgKCkpOw0KcHJpbnRmICgiLTY1NDgzID0g JWxkXG4iLCByXzY1NDgzICgpKTsNCnByaW50ZiAoIi02NTQ4MiA9ICVsZFxu Iiwgcl82NTQ4MiAoKSk7DQpwcmludGYgKCItNjU0ODEgPSAlbGRcbiIsIHJf NjU0ODEgKCkpOw0KcHJpbnRmICgiLTY1NDgwID0gJWxkXG4iLCByXzY1NDgw ICgpKTsNCnByaW50ZiAoIi02NTQ3OSA9ICVsZFxuIiwgcl82NTQ3OSAoKSk7 DQpwcmludGYgKCItNjU0NzggPSAlbGRcbiIsIHJfNjU0NzggKCkpOw0KcHJp bnRmICgiLTY1NDc3ID0gJWxkXG4iLCByXzY1NDc3ICgpKTsNCnByaW50ZiAo Ii02NTQ3NiA9ICVsZFxuIiwgcl82NTQ3NiAoKSk7DQpwcmludGYgKCItNjU0 NzUgPSAlbGRcbiIsIHJfNjU0NzUgKCkpOw0KcHJpbnRmICgiLTY1NDc0ID0g JWxkXG4iLCByXzY1NDc0ICgpKTsNCnByaW50ZiAoIi02NTQ3MyA9ICVsZFxu Iiwgcl82NTQ3MyAoKSk7DQpwcmludGYgKCItNjU0NzIgPSAlbGRcbiIsIHJf NjU0NzIgKCkpOw0KcHJpbnRmICgiLTY1NDcxID0gJWxkXG4iLCByXzY1NDcx ICgpKTsNCnByaW50ZiAoIi02NTQ3MCA9ICVsZFxuIiwgcl82NTQ3MCAoKSk7 DQpwcmludGYgKCItNjU0NjkgPSAlbGRcbiIsIHJfNjU0NjkgKCkpOw0KcHJp bnRmICgiLTY1NDY4ID0gJWxkXG4iLCByXzY1NDY4ICgpKTsNCnByaW50ZiAo Ii02NTQ2NyA9ICVsZFxuIiwgcl82NTQ2NyAoKSk7DQpwcmludGYgKCItNjU0 NjYgPSAlbGRcbiIsIHJfNjU0NjYgKCkpOw0KcHJpbnRmICgiLTY1NDY1ID0g JWxkXG4iLCByXzY1NDY1ICgpKTsNCnByaW50ZiAoIi02NTQ2NCA9ICVsZFxu Iiwgcl82NTQ2NCAoKSk7DQpwcmludGYgKCItNjU0NjMgPSAlbGRcbiIsIHJf NjU0NjMgKCkpOw0KcHJpbnRmICgiLTY1NDYyID0gJWxkXG4iLCByXzY1NDYy ICgpKTsNCnByaW50ZiAoIi02NTQ2MSA9ICVsZFxuIiwgcl82NTQ2MSAoKSk7 DQpwcmludGYgKCItNjU0NjAgPSAlbGRcbiIsIHJfNjU0NjAgKCkpOw0KcHJp bnRmICgiLTY1NDU5ID0gJWxkXG4iLCByXzY1NDU5ICgpKTsNCnByaW50ZiAo Ii02NTQ1OCA9ICVsZFxuIiwgcl82NTQ1OCAoKSk7DQpwcmludGYgKCItNjU0 NTcgPSAlbGRcbiIsIHJfNjU0NTcgKCkpOw0KcHJpbnRmICgiLTY1NDU2ID0g JWxkXG4iLCByXzY1NDU2ICgpKTsNCnByaW50ZiAoIi02NTQ1NSA9ICVsZFxu Iiwgcl82NTQ1NSAoKSk7DQpwcmludGYgKCItNjU0NTQgPSAlbGRcbiIsIHJf NjU0NTQgKCkpOw0KcHJpbnRmICgiLTY1NDUzID0gJWxkXG4iLCByXzY1NDUz ICgpKTsNCnByaW50ZiAoIi02NTQ1MiA9ICVsZFxuIiwgcl82NTQ1MiAoKSk7 DQpwcmludGYgKCItNjU0NTEgPSAlbGRcbiIsIHJfNjU0NTEgKCkpOw0KcHJp bnRmICgiLTY1NDUwID0gJWxkXG4iLCByXzY1NDUwICgpKTsNCnByaW50ZiAo Ii02NTQ0OSA9ICVsZFxuIiwgcl82NTQ0OSAoKSk7DQpwcmludGYgKCItNjU0 NDggPSAlbGRcbiIsIHJfNjU0NDggKCkpOw0KcHJpbnRmICgiLTY1NDQ3ID0g JWxkXG4iLCByXzY1NDQ3ICgpKTsNCnByaW50ZiAoIi02NTQ0NiA9ICVsZFxu Iiwgcl82NTQ0NiAoKSk7DQpwcmludGYgKCItNjU0NDUgPSAlbGRcbiIsIHJf NjU0NDUgKCkpOw0KcHJpbnRmICgiLTY1NDQ0ID0gJWxkXG4iLCByXzY1NDQ0 ICgpKTsNCnByaW50ZiAoIi02NTQ0MyA9ICVsZFxuIiwgcl82NTQ0MyAoKSk7 DQpwcmludGYgKCItNjU0NDIgPSAlbGRcbiIsIHJfNjU0NDIgKCkpOw0KcHJp bnRmICgiLTY1NDQxID0gJWxkXG4iLCByXzY1NDQxICgpKTsNCnByaW50ZiAo Ii02NTQ0MCA9ICVsZFxuIiwgcl82NTQ0MCAoKSk7DQpwcmludGYgKCItNjU0 MzkgPSAlbGRcbiIsIHJfNjU0MzkgKCkpOw0KcHJpbnRmICgiLTY1NDM4ID0g JWxkXG4iLCByXzY1NDM4ICgpKTsNCnByaW50ZiAoIi02NTQzNyA9ICVsZFxu Iiwgcl82NTQzNyAoKSk7DQpwcmludGYgKCItNjU0MzYgPSAlbGRcbiIsIHJf NjU0MzYgKCkpOw0KcHJpbnRmICgiLTY1NDM1ID0gJWxkXG4iLCByXzY1NDM1 ICgpKTsNCnByaW50ZiAoIi02NTQzNCA9ICVsZFxuIiwgcl82NTQzNCAoKSk7 DQpwcmludGYgKCItNjU0MzMgPSAlbGRcbiIsIHJfNjU0MzMgKCkpOw0KcHJp bnRmICgiLTY1NDMyID0gJWxkXG4iLCByXzY1NDMyICgpKTsNCnByaW50ZiAo Ii02NTQzMSA9ICVsZFxuIiwgcl82NTQzMSAoKSk7DQpwcmludGYgKCItNjU0 MzAgPSAlbGRcbiIsIHJfNjU0MzAgKCkpOw0KcHJpbnRmICgiLTY1NDI5ID0g JWxkXG4iLCByXzY1NDI5ICgpKTsNCnByaW50ZiAoIi02NTQyOCA9ICVsZFxu Iiwgcl82NTQyOCAoKSk7DQpwcmludGYgKCItNjU0MjcgPSAlbGRcbiIsIHJf NjU0MjcgKCkpOw0KcHJpbnRmICgiLTY1NDI2ID0gJWxkXG4iLCByXzY1NDI2 ICgpKTsNCnByaW50ZiAoIi02NTQyNSA9ICVsZFxuIiwgcl82NTQyNSAoKSk7 DQpwcmludGYgKCItNjU0MjQgPSAlbGRcbiIsIHJfNjU0MjQgKCkpOw0KcHJp bnRmICgiLTY1NDIzID0gJWxkXG4iLCByXzY1NDIzICgpKTsNCnByaW50ZiAo Ii02NTQyMiA9ICVsZFxuIiwgcl82NTQyMiAoKSk7DQpwcmludGYgKCItNjU0 MjEgPSAlbGRcbiIsIHJfNjU0MjEgKCkpOw0KcHJpbnRmICgiLTY1NDIwID0g JWxkXG4iLCByXzY1NDIwICgpKTsNCnByaW50ZiAoIi02NTQxOSA9ICVsZFxu Iiwgcl82NTQxOSAoKSk7DQpwcmludGYgKCItNjU0MTggPSAlbGRcbiIsIHJf NjU0MTggKCkpOw0KcHJpbnRmICgiLTY1NDE3ID0gJWxkXG4iLCByXzY1NDE3 ICgpKTsNCnByaW50ZiAoIi02NTQxNiA9ICVsZFxuIiwgcl82NTQxNiAoKSk7 DQpwcmludGYgKCItNjU0MTUgPSAlbGRcbiIsIHJfNjU0MTUgKCkpOw0KcHJp bnRmICgiLTY1NDE0ID0gJWxkXG4iLCByXzY1NDE0ICgpKTsNCnByaW50ZiAo Ii02NTQxMyA9ICVsZFxuIiwgcl82NTQxMyAoKSk7DQpwcmludGYgKCItNjU0 MTIgPSAlbGRcbiIsIHJfNjU0MTIgKCkpOw0KcHJpbnRmICgiLTY1NDExID0g JWxkXG4iLCByXzY1NDExICgpKTsNCnByaW50ZiAoIi02NTQxMCA9ICVsZFxu Iiwgcl82NTQxMCAoKSk7DQpwcmludGYgKCItNjU0MDkgPSAlbGRcbiIsIHJf NjU0MDkgKCkpOw0KLyogbW92ZS5sICN4LERuIC0+IG1vdmVxLmwgIzY1NTM1 LXgsRG4gKyBub3QudyBEbiwgcmFuZ2UgWzY1NDA4LCA2NTUzNV0uICovDQpw cmludGYgKCI2NTQwOCA9ICVsZFxuIiwgcjY1NDA4ICgpKTsNCnByaW50ZiAo IjY1NDA5ID0gJWxkXG4iLCByNjU0MDkgKCkpOw0KcHJpbnRmICgiNjU0MTAg PSAlbGRcbiIsIHI2NTQxMCAoKSk7DQpwcmludGYgKCI2NTQxMSA9ICVsZFxu IiwgcjY1NDExICgpKTsNCnByaW50ZiAoIjY1NDEyID0gJWxkXG4iLCByNjU0 MTIgKCkpOw0KcHJpbnRmICgiNjU0MTMgPSAlbGRcbiIsIHI2NTQxMyAoKSk7 DQpwcmludGYgKCI2NTQxNCA9ICVsZFxuIiwgcjY1NDE0ICgpKTsNCnByaW50 ZiAoIjY1NDE1ID0gJWxkXG4iLCByNjU0MTUgKCkpOw0KcHJpbnRmICgiNjU0 MTYgPSAlbGRcbiIsIHI2NTQxNiAoKSk7DQpwcmludGYgKCI2NTQxNyA9ICVs ZFxuIiwgcjY1NDE3ICgpKTsNCnByaW50ZiAoIjY1NDE4ID0gJWxkXG4iLCBy NjU0MTggKCkpOw0KcHJpbnRmICgiNjU0MTkgPSAlbGRcbiIsIHI2NTQxOSAo KSk7DQpwcmludGYgKCI2NTQyMCA9ICVsZFxuIiwgcjY1NDIwICgpKTsNCnBy aW50ZiAoIjY1NDIxID0gJWxkXG4iLCByNjU0MjEgKCkpOw0KcHJpbnRmICgi NjU0MjIgPSAlbGRcbiIsIHI2NTQyMiAoKSk7DQpwcmludGYgKCI2NTQyMyA9 ICVsZFxuIiwgcjY1NDIzICgpKTsNCnByaW50ZiAoIjY1NDI0ID0gJWxkXG4i LCByNjU0MjQgKCkpOw0KcHJpbnRmICgiNjU0MjUgPSAlbGRcbiIsIHI2NTQy NSAoKSk7DQpwcmludGYgKCI2NTQyNiA9ICVsZFxuIiwgcjY1NDI2ICgpKTsN CnByaW50ZiAoIjY1NDI3ID0gJWxkXG4iLCByNjU0MjcgKCkpOw0KcHJpbnRm ICgiNjU0MjggPSAlbGRcbiIsIHI2NTQyOCAoKSk7DQpwcmludGYgKCI2NTQy OSA9ICVsZFxuIiwgcjY1NDI5ICgpKTsNCnByaW50ZiAoIjY1NDMwID0gJWxk XG4iLCByNjU0MzAgKCkpOw0KcHJpbnRmICgiNjU0MzEgPSAlbGRcbiIsIHI2 NTQzMSAoKSk7DQpwcmludGYgKCI2NTQzMiA9ICVsZFxuIiwgcjY1NDMyICgp KTsNCnByaW50ZiAoIjY1NDMzID0gJWxkXG4iLCByNjU0MzMgKCkpOw0KcHJp bnRmICgiNjU0MzQgPSAlbGRcbiIsIHI2NTQzNCAoKSk7DQpwcmludGYgKCI2 NTQzNSA9ICVsZFxuIiwgcjY1NDM1ICgpKTsNCnByaW50ZiAoIjY1NDM2ID0g JWxkXG4iLCByNjU0MzYgKCkpOw0KcHJpbnRmICgiNjU0MzcgPSAlbGRcbiIs IHI2NTQzNyAoKSk7DQpwcmludGYgKCI2NTQzOCA9ICVsZFxuIiwgcjY1NDM4 ICgpKTsNCnByaW50ZiAoIjY1NDM5ID0gJWxkXG4iLCByNjU0MzkgKCkpOw0K cHJpbnRmICgiNjU0NDAgPSAlbGRcbiIsIHI2NTQ0MCAoKSk7DQpwcmludGYg KCI2NTQ0MSA9ICVsZFxuIiwgcjY1NDQxICgpKTsNCnByaW50ZiAoIjY1NDQy ID0gJWxkXG4iLCByNjU0NDIgKCkpOw0KcHJpbnRmICgiNjU0NDMgPSAlbGRc biIsIHI2NTQ0MyAoKSk7DQpwcmludGYgKCI2NTQ0NCA9ICVsZFxuIiwgcjY1 NDQ0ICgpKTsNCnByaW50ZiAoIjY1NDQ1ID0gJWxkXG4iLCByNjU0NDUgKCkp Ow0KcHJpbnRmICgiNjU0NDYgPSAlbGRcbiIsIHI2NTQ0NiAoKSk7DQpwcmlu dGYgKCI2NTQ0NyA9ICVsZFxuIiwgcjY1NDQ3ICgpKTsNCnByaW50ZiAoIjY1 NDQ4ID0gJWxkXG4iLCByNjU0NDggKCkpOw0KcHJpbnRmICgiNjU0NDkgPSAl bGRcbiIsIHI2NTQ0OSAoKSk7DQpwcmludGYgKCI2NTQ1MCA9ICVsZFxuIiwg cjY1NDUwICgpKTsNCnByaW50ZiAoIjY1NDUxID0gJWxkXG4iLCByNjU0NTEg KCkpOw0KcHJpbnRmICgiNjU0NTIgPSAlbGRcbiIsIHI2NTQ1MiAoKSk7DQpw cmludGYgKCI2NTQ1MyA9ICVsZFxuIiwgcjY1NDUzICgpKTsNCnByaW50ZiAo IjY1NDU0ID0gJWxkXG4iLCByNjU0NTQgKCkpOw0KcHJpbnRmICgiNjU0NTUg PSAlbGRcbiIsIHI2NTQ1NSAoKSk7DQpwcmludGYgKCI2NTQ1NiA9ICVsZFxu IiwgcjY1NDU2ICgpKTsNCnByaW50ZiAoIjY1NDU3ID0gJWxkXG4iLCByNjU0 NTcgKCkpOw0KcHJpbnRmICgiNjU0NTggPSAlbGRcbiIsIHI2NTQ1OCAoKSk7 DQpwcmludGYgKCI2NTQ1OSA9ICVsZFxuIiwgcjY1NDU5ICgpKTsNCnByaW50 ZiAoIjY1NDYwID0gJWxkXG4iLCByNjU0NjAgKCkpOw0KcHJpbnRmICgiNjU0 NjEgPSAlbGRcbiIsIHI2NTQ2MSAoKSk7DQpwcmludGYgKCI2NTQ2MiA9ICVs ZFxuIiwgcjY1NDYyICgpKTsNCnByaW50ZiAoIjY1NDYzID0gJWxkXG4iLCBy NjU0NjMgKCkpOw0KcHJpbnRmICgiNjU0NjQgPSAlbGRcbiIsIHI2NTQ2NCAo KSk7DQpwcmludGYgKCI2NTQ2NSA9ICVsZFxuIiwgcjY1NDY1ICgpKTsNCnBy aW50ZiAoIjY1NDY2ID0gJWxkXG4iLCByNjU0NjYgKCkpOw0KcHJpbnRmICgi NjU0NjcgPSAlbGRcbiIsIHI2NTQ2NyAoKSk7DQpwcmludGYgKCI2NTQ2OCA9 ICVsZFxuIiwgcjY1NDY4ICgpKTsNCnByaW50ZiAoIjY1NDY5ID0gJWxkXG4i LCByNjU0NjkgKCkpOw0KcHJpbnRmICgiNjU0NzAgPSAlbGRcbiIsIHI2NTQ3 MCAoKSk7DQpwcmludGYgKCI2NTQ3MSA9ICVsZFxuIiwgcjY1NDcxICgpKTsN CnByaW50ZiAoIjY1NDcyID0gJWxkXG4iLCByNjU0NzIgKCkpOw0KcHJpbnRm ICgiNjU0NzMgPSAlbGRcbiIsIHI2NTQ3MyAoKSk7DQpwcmludGYgKCI2NTQ3 NCA9ICVsZFxuIiwgcjY1NDc0ICgpKTsNCnByaW50ZiAoIjY1NDc1ID0gJWxk XG4iLCByNjU0NzUgKCkpOw0KcHJpbnRmICgiNjU0NzYgPSAlbGRcbiIsIHI2 NTQ3NiAoKSk7DQpwcmludGYgKCI2NTQ3NyA9ICVsZFxuIiwgcjY1NDc3ICgp KTsNCnByaW50ZiAoIjY1NDc4ID0gJWxkXG4iLCByNjU0NzggKCkpOw0KcHJp bnRmICgiNjU0NzkgPSAlbGRcbiIsIHI2NTQ3OSAoKSk7DQpwcmludGYgKCI2 NTQ4MCA9ICVsZFxuIiwgcjY1NDgwICgpKTsNCnByaW50ZiAoIjY1NDgxID0g JWxkXG4iLCByNjU0ODEgKCkpOw0KcHJpbnRmICgiNjU0ODIgPSAlbGRcbiIs IHI2NTQ4MiAoKSk7DQpwcmludGYgKCI2NTQ4MyA9ICVsZFxuIiwgcjY1NDgz ICgpKTsNCnByaW50ZiAoIjY1NDg0ID0gJWxkXG4iLCByNjU0ODQgKCkpOw0K cHJpbnRmICgiNjU0ODUgPSAlbGRcbiIsIHI2NTQ4NSAoKSk7DQpwcmludGYg KCI2NTQ4NiA9ICVsZFxuIiwgcjY1NDg2ICgpKTsNCnByaW50ZiAoIjY1NDg3 ID0gJWxkXG4iLCByNjU0ODcgKCkpOw0KcHJpbnRmICgiNjU0ODggPSAlbGRc biIsIHI2NTQ4OCAoKSk7DQpwcmludGYgKCI2NTQ4OSA9ICVsZFxuIiwgcjY1 NDg5ICgpKTsNCnByaW50ZiAoIjY1NDkwID0gJWxkXG4iLCByNjU0OTAgKCkp Ow0KcHJpbnRmICgiNjU0OTEgPSAlbGRcbiIsIHI2NTQ5MSAoKSk7DQpwcmlu dGYgKCI2NTQ5MiA9ICVsZFxuIiwgcjY1NDkyICgpKTsNCnByaW50ZiAoIjY1 NDkzID0gJWxkXG4iLCByNjU0OTMgKCkpOw0KcHJpbnRmICgiNjU0OTQgPSAl bGRcbiIsIHI2NTQ5NCAoKSk7DQpwcmludGYgKCI2NTQ5NSA9ICVsZFxuIiwg cjY1NDk1ICgpKTsNCnByaW50ZiAoIjY1NDk2ID0gJWxkXG4iLCByNjU0OTYg KCkpOw0KcHJpbnRmICgiNjU0OTcgPSAlbGRcbiIsIHI2NTQ5NyAoKSk7DQpw cmludGYgKCI2NTQ5OCA9ICVsZFxuIiwgcjY1NDk4ICgpKTsNCnByaW50ZiAo IjY1NDk5ID0gJWxkXG4iLCByNjU0OTkgKCkpOw0KcHJpbnRmICgiNjU1MDAg PSAlbGRcbiIsIHI2NTUwMCAoKSk7DQpwcmludGYgKCI2NTUwMSA9ICVsZFxu IiwgcjY1NTAxICgpKTsNCnByaW50ZiAoIjY1NTAyID0gJWxkXG4iLCByNjU1 MDIgKCkpOw0KcHJpbnRmICgiNjU1MDMgPSAlbGRcbiIsIHI2NTUwMyAoKSk7 DQpwcmludGYgKCI2NTUwNCA9ICVsZFxuIiwgcjY1NTA0ICgpKTsNCnByaW50 ZiAoIjY1NTA1ID0gJWxkXG4iLCByNjU1MDUgKCkpOw0KcHJpbnRmICgiNjU1 MDYgPSAlbGRcbiIsIHI2NTUwNiAoKSk7DQpwcmludGYgKCI2NTUwNyA9ICVs ZFxuIiwgcjY1NTA3ICgpKTsNCnByaW50ZiAoIjY1NTA4ID0gJWxkXG4iLCBy NjU1MDggKCkpOw0KcHJpbnRmICgiNjU1MDkgPSAlbGRcbiIsIHI2NTUwOSAo KSk7DQpwcmludGYgKCI2NTUxMCA9ICVsZFxuIiwgcjY1NTEwICgpKTsNCnBy aW50ZiAoIjY1NTExID0gJWxkXG4iLCByNjU1MTEgKCkpOw0KcHJpbnRmICgi NjU1MTIgPSAlbGRcbiIsIHI2NTUxMiAoKSk7DQpwcmludGYgKCI2NTUxMyA9 ICVsZFxuIiwgcjY1NTEzICgpKTsNCnByaW50ZiAoIjY1NTE0ID0gJWxkXG4i LCByNjU1MTQgKCkpOw0KcHJpbnRmICgiNjU1MTUgPSAlbGRcbiIsIHI2NTUx NSAoKSk7DQpwcmludGYgKCI2NTUxNiA9ICVsZFxuIiwgcjY1NTE2ICgpKTsN CnByaW50ZiAoIjY1NTE3ID0gJWxkXG4iLCByNjU1MTcgKCkpOw0KcHJpbnRm ICgiNjU1MTggPSAlbGRcbiIsIHI2NTUxOCAoKSk7DQpwcmludGYgKCI2NTUx OSA9ICVsZFxuIiwgcjY1NTE5ICgpKTsNCnByaW50ZiAoIjY1NTIwID0gJWxk XG4iLCByNjU1MjAgKCkpOw0KcHJpbnRmICgiNjU1MjEgPSAlbGRcbiIsIHI2 NTUyMSAoKSk7DQpwcmludGYgKCI2NTUyMiA9ICVsZFxuIiwgcjY1NTIyICgp KTsNCnByaW50ZiAoIjY1NTIzID0gJWxkXG4iLCByNjU1MjMgKCkpOw0KcHJp bnRmICgiNjU1MjQgPSAlbGRcbiIsIHI2NTUyNCAoKSk7DQpwcmludGYgKCI2 NTUyNSA9ICVsZFxuIiwgcjY1NTI1ICgpKTsNCnByaW50ZiAoIjY1NTI2ID0g JWxkXG4iLCByNjU1MjYgKCkpOw0KcHJpbnRmICgiNjU1MjcgPSAlbGRcbiIs IHI2NTUyNyAoKSk7DQpwcmludGYgKCI2NTUyOCA9ICVsZFxuIiwgcjY1NTI4 ICgpKTsNCnByaW50ZiAoIjY1NTI5ID0gJWxkXG4iLCByNjU1MjkgKCkpOw0K cHJpbnRmICgiNjU1MzAgPSAlbGRcbiIsIHI2NTUzMCAoKSk7DQpwcmludGYg KCI2NTUzMSA9ICVsZFxuIiwgcjY1NTMxICgpKTsNCnByaW50ZiAoIjY1NTMy ID0gJWxkXG4iLCByNjU1MzIgKCkpOw0KcHJpbnRmICgiNjU1MzMgPSAlbGRc biIsIHI2NTUzMyAoKSk7DQpwcmludGYgKCI2NTUzNCA9ICVsZFxuIiwgcjY1 NTM0ICgpKTsNCnByaW50ZiAoIjY1NTM1ID0gJWxkXG4iLCByNjU1MzUgKCkp Ow0KDQpyZXR1cm4gKDApOw0KfQ0K --2010703495-851401618-823799462=:7314 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="optmisc1.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: LyogQ29kZSB0byB0ZXN0IG1vdmUubCAjeCxEbiAtPiBtb3ZlcS5sICN5LERu ICsgYmNoZyBEbixEbiAgICAgICAgICoNCiAqIE5vdGUgdGhhdCBzb21lIG9m IHRoZSB2YWx1ZXMgaGVyZSBtYXkgZW5kIHVwIGJlaW5nIG9wdGltaXplZCBp biAqDQogKiBzb21lIG90aGVyIHdheSwgc3VjaCBhcyBtb3ZlcS5sICMheCxE biArIG5vdC5iIERuICAgICAgICAgICAgICAgKi8NCg0KI2luY2x1ZGUgPHN0 ZGlvLmg+DQoNCnNpZ25lZCBsb25nIHJfMzI4ODEodm9pZCkgeyByZXR1cm4g KC0zMjg4MSk7IH0NCnNpZ25lZCBsb25nIHJfMzI4NDkodm9pZCkgeyByZXR1 cm4gKC0zMjg0OSk7IH0NCnNpZ25lZCBsb25nIHJfMzI4MTcodm9pZCkgeyBy ZXR1cm4gKC0zMjgxNyk7IH0NCnNpZ25lZCBsb25nIHJfMzI3ODUodm9pZCkg eyByZXR1cm4gKC0zMjc4NSk7IH0NCnNpZ25lZCBsb25nIHJfMTY0OTgodm9p ZCkgeyByZXR1cm4gKC0xNjQ5OCk7IH0NCnNpZ25lZCBsb25nIHJfMTY0NjYo dm9pZCkgeyByZXR1cm4gKC0xNjQ2Nik7IH0NCnNpZ25lZCBsb25nIHJfMTY0 MzQodm9pZCkgeyByZXR1cm4gKC0xNjQzNCk7IH0NCnNpZ25lZCBsb25nIHJf MTY0MDIodm9pZCkgeyByZXR1cm4gKC0xNjQwMik7IH0NCnNpZ25lZCBsb25n IHJfODMwNyh2b2lkKSB7IHJldHVybiAoLTgzMDcpOyB9DQpzaWduZWQgbG9u ZyByXzgyNzUodm9pZCkgeyByZXR1cm4gKC04Mjc1KTsgfQ0Kc2lnbmVkIGxv bmcgcl84MjQzKHZvaWQpIHsgcmV0dXJuICgtODI0Myk7IH0NCnNpZ25lZCBs b25nIHJfODIxMSh2b2lkKSB7IHJldHVybiAoLTgyMTEpOyB9DQpzaWduZWQg bG9uZyByXzQyMTIodm9pZCkgeyByZXR1cm4gKC00MjEyKTsgfQ0Kc2lnbmVk IGxvbmcgcl80MTgwKHZvaWQpIHsgcmV0dXJuICgtNDE4MCk7IH0NCnNpZ25l ZCBsb25nIHJfNDE0OCh2b2lkKSB7IHJldHVybiAoLTQxNDgpOyB9DQpzaWdu ZWQgbG9uZyByXzQxMTYodm9pZCkgeyByZXR1cm4gKC00MTE2KTsgfQ0Kc2ln bmVkIGxvbmcgcl8yMTY1KHZvaWQpIHsgcmV0dXJuICgtMjE2NSk7IH0NCnNp Z25lZCBsb25nIHJfMjEzMyh2b2lkKSB7IHJldHVybiAoLTIxMzMpOyB9DQpz aWduZWQgbG9uZyByXzIxMDEodm9pZCkgeyByZXR1cm4gKC0yMTAxKTsgfQ0K c2lnbmVkIGxvbmcgcl8yMDY5KHZvaWQpIHsgcmV0dXJuICgtMjA2OSk7IH0N CnNpZ25lZCBsb25nIHJfMTE0Mih2b2lkKSB7IHJldHVybiAoLTExNDIpOyB9 DQpzaWduZWQgbG9uZyByXzExMTAodm9pZCkgeyByZXR1cm4gKC0xMTEwKTsg fQ0Kc2lnbmVkIGxvbmcgcl8xMDc4KHZvaWQpIHsgcmV0dXJuICgtMTA3OCk7 IH0NCnNpZ25lZCBsb25nIHJfMTA0Nih2b2lkKSB7IHJldHVybiAoLTEwNDYp OyB9DQpzaWduZWQgbG9uZyByXzYzMSh2b2lkKSB7IHJldHVybiAoLTYzMSk7 IH0NCnNpZ25lZCBsb25nIHJfNTk5KHZvaWQpIHsgcmV0dXJuICgtNTk5KTsg fQ0Kc2lnbmVkIGxvbmcgcl81Njcodm9pZCkgeyByZXR1cm4gKC01NjcpOyB9 DQpzaWduZWQgbG9uZyByXzUzNSh2b2lkKSB7IHJldHVybiAoLTUzNSk7IH0N CnNpZ25lZCBsb25nIHJfMzY3KHZvaWQpIHsgcmV0dXJuICgtMzY3KTsgfQ0K c2lnbmVkIGxvbmcgcl8zNDQodm9pZCkgeyByZXR1cm4gKC0zNDQpOyB9DQpz aWduZWQgbG9uZyByXzMxMih2b2lkKSB7IHJldHVybiAoLTMxMik7IH0NCnNp Z25lZCBsb25nIHJfMjgwKHZvaWQpIHsgcmV0dXJuICgtMjgwKTsgfQ0Kc2ln bmVkIGxvbmcgcjI2NCh2b2lkKSB7IHJldHVybiAoMjY0KTsgfQ0Kc2lnbmVk IGxvbmcgcjI5Nih2b2lkKSB7IHJldHVybiAoMjk2KTsgfQ0Kc2lnbmVkIGxv bmcgcjMyOCh2b2lkKSB7IHJldHVybiAoMzI4KTsgfQ0Kc2lnbmVkIGxvbmcg cjM2MCh2b2lkKSB7IHJldHVybiAoMzYwKTsgfQ0Kc2lnbmVkIGxvbmcgcjUy MSh2b2lkKSB7IHJldHVybiAoNTIxKTsgfQ0Kc2lnbmVkIGxvbmcgcjU1Myh2 b2lkKSB7IHJldHVybiAoNTUzKTsgfQ0Kc2lnbmVkIGxvbmcgcjU4NSh2b2lk KSB7IHJldHVybiAoNTg1KTsgfQ0Kc2lnbmVkIGxvbmcgcjYxNyh2b2lkKSB7 IHJldHVybiAoNjE3KTsgfQ0Kc2lnbmVkIGxvbmcgcjEwMzQodm9pZCkgeyBy ZXR1cm4gKDEwMzQpOyB9DQpzaWduZWQgbG9uZyByMTA2Nih2b2lkKSB7IHJl dHVybiAoMTA2Nik7IH0NCnNpZ25lZCBsb25nIHIxMDk4KHZvaWQpIHsgcmV0 dXJuICgxMDk4KTsgfQ0Kc2lnbmVkIGxvbmcgcjExMzAodm9pZCkgeyByZXR1 cm4gKDExMzApOyB9DQpzaWduZWQgbG9uZyByMjA1OSh2b2lkKSB7IHJldHVy biAoMjA1OSk7IH0NCnNpZ25lZCBsb25nIHIyMDkxKHZvaWQpIHsgcmV0dXJu ICgyMDkxKTsgfQ0Kc2lnbmVkIGxvbmcgcjIxMjModm9pZCkgeyByZXR1cm4g KDIxMjMpOyB9DQpzaWduZWQgbG9uZyByMjE1NSh2b2lkKSB7IHJldHVybiAo MjE1NSk7IH0NCnNpZ25lZCBsb25nIHI0MTA4KHZvaWQpIHsgcmV0dXJuICg0 MTA4KTsgfQ0Kc2lnbmVkIGxvbmcgcjQxNDAodm9pZCkgeyByZXR1cm4gKDQx NDApOyB9DQpzaWduZWQgbG9uZyByNDE3Mih2b2lkKSB7IHJldHVybiAoNDE3 Mik7IH0NCnNpZ25lZCBsb25nIHI0MjA0KHZvaWQpIHsgcmV0dXJuICg0MjA0 KTsgfQ0Kc2lnbmVkIGxvbmcgcjgyMDUodm9pZCkgeyByZXR1cm4gKDgyMDUp OyB9DQpzaWduZWQgbG9uZyByODIzNyh2b2lkKSB7IHJldHVybiAoODIzNyk7 IH0NCnNpZ25lZCBsb25nIHI4MjY5KHZvaWQpIHsgcmV0dXJuICg4MjY5KTsg fQ0Kc2lnbmVkIGxvbmcgcjgzMDEodm9pZCkgeyByZXR1cm4gKDgzMDEpOyB9 DQpzaWduZWQgbG9uZyByMTYzOTgodm9pZCkgeyByZXR1cm4gKDE2Mzk4KTsg fQ0Kc2lnbmVkIGxvbmcgcjE2NDMwKHZvaWQpIHsgcmV0dXJuICgxNjQzMCk7 IH0NCnNpZ25lZCBsb25nIHIxNjQ2Mih2b2lkKSB7IHJldHVybiAoMTY0NjIp OyB9DQpzaWduZWQgbG9uZyByMTY0OTQodm9pZCkgeyByZXR1cm4gKDE2NDk0 KTsgfQ0Kc2lnbmVkIGxvbmcgcjMyNzgzKHZvaWQpIHsgcmV0dXJuICgzMjc4 Myk7IH0NCnNpZ25lZCBsb25nIHIzMjgxNSh2b2lkKSB7IHJldHVybiAoMzI4 MTUpOyB9DQpzaWduZWQgbG9uZyByMzI4NDcodm9pZCkgeyByZXR1cm4gKDMy ODQ3KTsgfQ0Kc2lnbmVkIGxvbmcgcjMyODk3KHZvaWQpIHsgcmV0dXJuICgz Mjg5Nyk7IH0NCg0KaW50IG1haW4gKGludCBhcmdjLCBjaGFyICphcmd2W10p DQp7DQoJcHJpbnRmICgiLTMyODgxID0gJWxkXG4iLCByXzMyODgxICgpKTsN CglwcmludGYgKCItMzI4NDkgPSAlbGRcbiIsIHJfMzI4NDkgKCkpOw0KCXBy aW50ZiAoIi0zMjgxNyA9ICVsZFxuIiwgcl8zMjgxNyAoKSk7DQoJcHJpbnRm ICgiLTMyNzg1ID0gJWxkXG4iLCByXzMyNzg1ICgpKTsNCglwcmludGYgKCIt MTY0OTggPSAlbGRcbiIsIHJfMTY0OTggKCkpOw0KCXByaW50ZiAoIi0xNjQ2 NiA9ICVsZFxuIiwgcl8xNjQ2NiAoKSk7DQoJcHJpbnRmICgiLTE2NDM0ID0g JWxkXG4iLCByXzE2NDM0ICgpKTsNCglwcmludGYgKCItMTY0MDIgPSAlbGRc biIsIHJfMTY0MDIgKCkpOw0KCXByaW50ZiAoIi04MzA3ID0gJWxkXG4iLCBy XzgzMDcgKCkpOw0KCXByaW50ZiAoIi04Mjc1ID0gJWxkXG4iLCByXzgyNzUg KCkpOw0KCXByaW50ZiAoIi04MjQzID0gJWxkXG4iLCByXzgyNDMgKCkpOw0K CXByaW50ZiAoIi04MjExID0gJWxkXG4iLCByXzgyMTEgKCkpOw0KCXByaW50 ZiAoIi00MjEyID0gJWxkXG4iLCByXzQyMTIgKCkpOw0KCXByaW50ZiAoIi00 MTgwID0gJWxkXG4iLCByXzQxODAgKCkpOw0KCXByaW50ZiAoIi00MTQ4ID0g JWxkXG4iLCByXzQxNDggKCkpOw0KCXByaW50ZiAoIi00MTE2ID0gJWxkXG4i LCByXzQxMTYgKCkpOw0KCXByaW50ZiAoIi0yMTY1ID0gJWxkXG4iLCByXzIx NjUgKCkpOw0KCXByaW50ZiAoIi0yMTMzID0gJWxkXG4iLCByXzIxMzMgKCkp Ow0KCXByaW50ZiAoIi0yMTAxID0gJWxkXG4iLCByXzIxMDEgKCkpOw0KCXBy aW50ZiAoIi0yMDY5ID0gJWxkXG4iLCByXzIwNjkgKCkpOw0KCXByaW50ZiAo Ii0xMTQyID0gJWxkXG4iLCByXzExNDIgKCkpOw0KCXByaW50ZiAoIi0xMTEw ID0gJWxkXG4iLCByXzExMTAgKCkpOw0KCXByaW50ZiAoIi0xMDc4ID0gJWxk XG4iLCByXzEwNzggKCkpOw0KCXByaW50ZiAoIi0xMDQ2ID0gJWxkXG4iLCBy XzEwNDYgKCkpOw0KCXByaW50ZiAoIi02MzEgPSAlbGRcbiIsIHJfNjMxICgp KTsNCglwcmludGYgKCItNTk5ID0gJWxkXG4iLCByXzU5OSAoKSk7DQoJcHJp bnRmICgiLTU2NyA9ICVsZFxuIiwgcl81NjcgKCkpOw0KCXByaW50ZiAoIi01 MzUgPSAlbGRcbiIsIHJfNTM1ICgpKTsNCglwcmludGYgKCItMzY3ID0gJWxk XG4iLCByXzM2NyAoKSk7DQoJcHJpbnRmICgiLTM0NCA9ICVsZFxuIiwgcl8z NDQgKCkpOw0KCXByaW50ZiAoIi0zMTIgPSAlbGRcbiIsIHJfMzEyICgpKTsN CglwcmludGYgKCItMjgwID0gJWxkXG4iLCByXzI4MCAoKSk7DQoJcHJpbnRm ICgiMjY0ID0gJWxkXG4iLCByMjY0ICgpKTsNCglwcmludGYgKCIyOTYgPSAl bGRcbiIsIHIyOTYgKCkpOw0KCXByaW50ZiAoIjMyOCA9ICVsZFxuIiwgcjMy OCAoKSk7DQoJcHJpbnRmICgiMzYwID0gJWxkXG4iLCByMzYwICgpKTsNCglw cmludGYgKCI1MjEgPSAlbGRcbiIsIHI1MjEgKCkpOw0KCXByaW50ZiAoIjU1 MyA9ICVsZFxuIiwgcjU1MyAoKSk7DQoJcHJpbnRmICgiNTg1ID0gJWxkXG4i LCByNTg1ICgpKTsNCglwcmludGYgKCI2MTcgPSAlbGRcbiIsIHI2MTcgKCkp Ow0KCXByaW50ZiAoIjEwMzQgPSAlbGRcbiIsIHIxMDM0ICgpKTsNCglwcmlu dGYgKCIxMDY2ID0gJWxkXG4iLCByMTA2NiAoKSk7DQoJcHJpbnRmICgiMTA5 OCA9ICVsZFxuIiwgcjEwOTggKCkpOw0KCXByaW50ZiAoIjExMzAgPSAlbGRc biIsIHIxMTMwICgpKTsNCglwcmludGYgKCIyMDU5ID0gJWxkXG4iLCByMjA1 OSAoKSk7DQoJcHJpbnRmICgiMjA5MSA9ICVsZFxuIiwgcjIwOTEgKCkpOw0K CXByaW50ZiAoIjIxMjMgPSAlbGRcbiIsIHIyMTIzICgpKTsNCglwcmludGYg KCIyMTU1ID0gJWxkXG4iLCByMjE1NSAoKSk7DQoJcHJpbnRmICgiNDEwOCA9 ICVsZFxuIiwgcjQxMDggKCkpOw0KCXByaW50ZiAoIjQxNDAgPSAlbGRcbiIs IHI0MTQwICgpKTsNCglwcmludGYgKCI0MTcyID0gJWxkXG4iLCByNDE3MiAo KSk7DQoJcHJpbnRmICgiNDIwNCA9ICVsZFxuIiwgcjQyMDQgKCkpOw0KCXBy aW50ZiAoIjgyMDUgPSAlbGRcbiIsIHI4MjA1ICgpKTsNCglwcmludGYgKCI4 MjM3ID0gJWxkXG4iLCByODIzNyAoKSk7DQoJcHJpbnRmICgiODI2OSA9ICVs ZFxuIiwgcjgyNjkgKCkpOw0KCXByaW50ZiAoIjgzMDEgPSAlbGRcbiIsIHI4 MzAxICgpKTsNCglwcmludGYgKCIxNjM5OCA9ICVsZFxuIiwgcjE2Mzk4ICgp KTsNCglwcmludGYgKCIxNjQzMCA9ICVsZFxuIiwgcjE2NDMwICgpKTsNCglw cmludGYgKCIxNjQ2MiA9ICVsZFxuIiwgcjE2NDYyICgpKTsNCglwcmludGYg KCIxNjQ5NCA9ICVsZFxuIiwgcjE2NDk0ICgpKTsNCglwcmludGYgKCIzMjc4 MyA9ICVsZFxuIiwgcjMyNzgzICgpKTsNCglwcmludGYgKCIzMjgxNSA9ICVs ZFxuIiwgcjMyODE1ICgpKTsNCglwcmludGYgKCIzMjg0NyA9ICVsZFxuIiwg cjMyODQ3ICgpKTsNCglwcmludGYgKCIzMjg5NyA9ICVsZFxuIiwgcjMyODk3 ICgpKTsNCg0KCXJldHVybiAoMCk7DQp9DQo= --2010703495-851401618-823799462=:7314 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="optmisc2.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: I2luY2x1ZGUgPHN0ZGlvLmg+DQovKiBtb3ZlLmwgI3gsRG4gLT4gbW92ZXEu bCAjeC82NTUzNixEbiArIHN3YXAgRG4sIHNldCB7IHggPiAwIHwgeCAlIDY1 NTM2ID09IDAgfS4gKi8NCnNpZ25lZCBsb25nIGludCByNjU1MzYgKHZvaWQp IHsgcmV0dXJuICg2NTUzNik7IH0NCnNpZ25lZCBsb25nIGludCByMTMxMDcy ICh2b2lkKSB7IHJldHVybiAoMTMxMDcyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50 IHIxOTY2MDggKHZvaWQpIHsgcmV0dXJuICgxOTY2MDgpOyB9DQpzaWduZWQg bG9uZyBpbnQgcjI2MjE0NCAodm9pZCkgeyByZXR1cm4gKDI2MjE0NCk7IH0N CnNpZ25lZCBsb25nIGludCByMzI3NjgwICh2b2lkKSB7IHJldHVybiAoMzI3 NjgwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIzOTMyMTYgKHZvaWQpIHsgcmV0 dXJuICgzOTMyMTYpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjQ1ODc1MiAodm9p ZCkgeyByZXR1cm4gKDQ1ODc1Mik7IH0NCnNpZ25lZCBsb25nIGludCByNTI0 Mjg4ICh2b2lkKSB7IHJldHVybiAoNTI0Mjg4KTsgfQ0Kc2lnbmVkIGxvbmcg aW50IHI1ODk4MjQgKHZvaWQpIHsgcmV0dXJuICg1ODk4MjQpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcjY1NTM2MCAodm9pZCkgeyByZXR1cm4gKDY1NTM2MCk7 IH0NCnNpZ25lZCBsb25nIGludCByNzIwODk2ICh2b2lkKSB7IHJldHVybiAo NzIwODk2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI3ODY0MzIgKHZvaWQpIHsg cmV0dXJuICg3ODY0MzIpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjg1MTk2OCAo dm9pZCkgeyByZXR1cm4gKDg1MTk2OCk7IH0NCnNpZ25lZCBsb25nIGludCBy OTE3NTA0ICh2b2lkKSB7IHJldHVybiAoOTE3NTA0KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHI5ODMwNDAgKHZvaWQpIHsgcmV0dXJuICg5ODMwNDApOyB9DQpz aWduZWQgbG9uZyBpbnQgcjEwNDg1NzYgKHZvaWQpIHsgcmV0dXJuICgxMDQ4 NTc2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxMTE0MTEyICh2b2lkKSB7IHJl dHVybiAoMTExNDExMik7IH0NCnNpZ25lZCBsb25nIGludCByMTE3OTY0OCAo dm9pZCkgeyByZXR1cm4gKDExNzk2NDgpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjEyNDUxODQgKHZvaWQpIHsgcmV0dXJuICgxMjQ1MTg0KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHIxMzEwNzIwICh2b2lkKSB7IHJldHVybiAoMTMxMDcyMCk7 IH0NCnNpZ25lZCBsb25nIGludCByMTM3NjI1NiAodm9pZCkgeyByZXR1cm4g KDEzNzYyNTYpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjE0NDE3OTIgKHZvaWQp IHsgcmV0dXJuICgxNDQxNzkyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxNTA3 MzI4ICh2b2lkKSB7IHJldHVybiAoMTUwNzMyOCk7IH0NCnNpZ25lZCBsb25n IGludCByMTU3Mjg2NCAodm9pZCkgeyByZXR1cm4gKDE1NzI4NjQpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjE2Mzg0MDAgKHZvaWQpIHsgcmV0dXJuICgxNjM4 NDAwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIxNzAzOTM2ICh2b2lkKSB7IHJl dHVybiAoMTcwMzkzNik7IH0NCnNpZ25lZCBsb25nIGludCByMTc2OTQ3MiAo dm9pZCkgeyByZXR1cm4gKDE3Njk0NzIpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjE4MzUwMDggKHZvaWQpIHsgcmV0dXJuICgxODM1MDA4KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHIxOTAwNTQ0ICh2b2lkKSB7IHJldHVybiAoMTkwMDU0NCk7 IH0NCnNpZ25lZCBsb25nIGludCByMTk2NjA4MCAodm9pZCkgeyByZXR1cm4g KDE5NjYwODApOyB9DQpzaWduZWQgbG9uZyBpbnQgcjIwMzE2MTYgKHZvaWQp IHsgcmV0dXJuICgyMDMxNjE2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyMDk3 MTUyICh2b2lkKSB7IHJldHVybiAoMjA5NzE1Mik7IH0NCnNpZ25lZCBsb25n IGludCByMjE2MjY4OCAodm9pZCkgeyByZXR1cm4gKDIxNjI2ODgpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjIyMjgyMjQgKHZvaWQpIHsgcmV0dXJuICgyMjI4 MjI0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyMjkzNzYwICh2b2lkKSB7IHJl dHVybiAoMjI5Mzc2MCk7IH0NCnNpZ25lZCBsb25nIGludCByMjM1OTI5NiAo dm9pZCkgeyByZXR1cm4gKDIzNTkyOTYpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjI0MjQ4MzIgKHZvaWQpIHsgcmV0dXJuICgyNDI0ODMyKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHIyNDkwMzY4ICh2b2lkKSB7IHJldHVybiAoMjQ5MDM2OCk7 IH0NCnNpZ25lZCBsb25nIGludCByMjU1NTkwNCAodm9pZCkgeyByZXR1cm4g KDI1NTU5MDQpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjI2MjE0NDAgKHZvaWQp IHsgcmV0dXJuICgyNjIxNDQwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyNjg2 OTc2ICh2b2lkKSB7IHJldHVybiAoMjY4Njk3Nik7IH0NCnNpZ25lZCBsb25n IGludCByMjc1MjUxMiAodm9pZCkgeyByZXR1cm4gKDI3NTI1MTIpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjI4MTgwNDggKHZvaWQpIHsgcmV0dXJuICgyODE4 MDQ4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIyODgzNTg0ICh2b2lkKSB7IHJl dHVybiAoMjg4MzU4NCk7IH0NCnNpZ25lZCBsb25nIGludCByMjk0OTEyMCAo dm9pZCkgeyByZXR1cm4gKDI5NDkxMjApOyB9DQpzaWduZWQgbG9uZyBpbnQg cjMwMTQ2NTYgKHZvaWQpIHsgcmV0dXJuICgzMDE0NjU2KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHIzMDgwMTkyICh2b2lkKSB7IHJldHVybiAoMzA4MDE5Mik7 IH0NCnNpZ25lZCBsb25nIGludCByMzE0NTcyOCAodm9pZCkgeyByZXR1cm4g KDMxNDU3MjgpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjMyMTEyNjQgKHZvaWQp IHsgcmV0dXJuICgzMjExMjY0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIzMjc2 ODAwICh2b2lkKSB7IHJldHVybiAoMzI3NjgwMCk7IH0NCnNpZ25lZCBsb25n IGludCByMzM0MjMzNiAodm9pZCkgeyByZXR1cm4gKDMzNDIzMzYpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjM0MDc4NzIgKHZvaWQpIHsgcmV0dXJuICgzNDA3 ODcyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIzNDczNDA4ICh2b2lkKSB7IHJl dHVybiAoMzQ3MzQwOCk7IH0NCnNpZ25lZCBsb25nIGludCByMzUzODk0NCAo dm9pZCkgeyByZXR1cm4gKDM1Mzg5NDQpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjM2MDQ0ODAgKHZvaWQpIHsgcmV0dXJuICgzNjA0NDgwKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHIzNjcwMDE2ICh2b2lkKSB7IHJldHVybiAoMzY3MDAxNik7 IH0NCnNpZ25lZCBsb25nIGludCByMzczNTU1MiAodm9pZCkgeyByZXR1cm4g KDM3MzU1NTIpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjM4MDEwODggKHZvaWQp IHsgcmV0dXJuICgzODAxMDg4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHIzODY2 NjI0ICh2b2lkKSB7IHJldHVybiAoMzg2NjYyNCk7IH0NCnNpZ25lZCBsb25n IGludCByMzkzMjE2MCAodm9pZCkgeyByZXR1cm4gKDM5MzIxNjApOyB9DQpz aWduZWQgbG9uZyBpbnQgcjM5OTc2OTYgKHZvaWQpIHsgcmV0dXJuICgzOTk3 Njk2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI0MDYzMjMyICh2b2lkKSB7IHJl dHVybiAoNDA2MzIzMik7IH0NCnNpZ25lZCBsb25nIGludCByNDEyODc2OCAo dm9pZCkgeyByZXR1cm4gKDQxMjg3NjgpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjQxOTQzMDQgKHZvaWQpIHsgcmV0dXJuICg0MTk0MzA0KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI0MjU5ODQwICh2b2lkKSB7IHJldHVybiAoNDI1OTg0MCk7 IH0NCnNpZ25lZCBsb25nIGludCByNDMyNTM3NiAodm9pZCkgeyByZXR1cm4g KDQzMjUzNzYpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjQzOTA5MTIgKHZvaWQp IHsgcmV0dXJuICg0MzkwOTEyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI0NDU2 NDQ4ICh2b2lkKSB7IHJldHVybiAoNDQ1NjQ0OCk7IH0NCnNpZ25lZCBsb25n IGludCByNDUyMTk4NCAodm9pZCkgeyByZXR1cm4gKDQ1MjE5ODQpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjQ1ODc1MjAgKHZvaWQpIHsgcmV0dXJuICg0NTg3 NTIwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI0NjUzMDU2ICh2b2lkKSB7IHJl dHVybiAoNDY1MzA1Nik7IH0NCnNpZ25lZCBsb25nIGludCByNDcxODU5MiAo dm9pZCkgeyByZXR1cm4gKDQ3MTg1OTIpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjQ3ODQxMjggKHZvaWQpIHsgcmV0dXJuICg0Nzg0MTI4KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI0ODQ5NjY0ICh2b2lkKSB7IHJldHVybiAoNDg0OTY2NCk7 IH0NCnNpZ25lZCBsb25nIGludCByNDkxNTIwMCAodm9pZCkgeyByZXR1cm4g KDQ5MTUyMDApOyB9DQpzaWduZWQgbG9uZyBpbnQgcjQ5ODA3MzYgKHZvaWQp IHsgcmV0dXJuICg0OTgwNzM2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI1MDQ2 MjcyICh2b2lkKSB7IHJldHVybiAoNTA0NjI3Mik7IH0NCnNpZ25lZCBsb25n IGludCByNTExMTgwOCAodm9pZCkgeyByZXR1cm4gKDUxMTE4MDgpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjUxNzczNDQgKHZvaWQpIHsgcmV0dXJuICg1MTc3 MzQ0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI1MjQyODgwICh2b2lkKSB7IHJl dHVybiAoNTI0Mjg4MCk7IH0NCnNpZ25lZCBsb25nIGludCByNTMwODQxNiAo dm9pZCkgeyByZXR1cm4gKDUzMDg0MTYpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjUzNzM5NTIgKHZvaWQpIHsgcmV0dXJuICg1MzczOTUyKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI1NDM5NDg4ICh2b2lkKSB7IHJldHVybiAoNTQzOTQ4OCk7 IH0NCnNpZ25lZCBsb25nIGludCByNTUwNTAyNCAodm9pZCkgeyByZXR1cm4g KDU1MDUwMjQpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjU1NzA1NjAgKHZvaWQp IHsgcmV0dXJuICg1NTcwNTYwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI1NjM2 MDk2ICh2b2lkKSB7IHJldHVybiAoNTYzNjA5Nik7IH0NCnNpZ25lZCBsb25n IGludCByNTcwMTYzMiAodm9pZCkgeyByZXR1cm4gKDU3MDE2MzIpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjU3NjcxNjggKHZvaWQpIHsgcmV0dXJuICg1NzY3 MTY4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI1ODMyNzA0ICh2b2lkKSB7IHJl dHVybiAoNTgzMjcwNCk7IH0NCnNpZ25lZCBsb25nIGludCByNTg5ODI0MCAo dm9pZCkgeyByZXR1cm4gKDU4OTgyNDApOyB9DQpzaWduZWQgbG9uZyBpbnQg cjU5NjM3NzYgKHZvaWQpIHsgcmV0dXJuICg1OTYzNzc2KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI2MDI5MzEyICh2b2lkKSB7IHJldHVybiAoNjAyOTMxMik7 IH0NCnNpZ25lZCBsb25nIGludCByNjA5NDg0OCAodm9pZCkgeyByZXR1cm4g KDYwOTQ4NDgpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjYxNjAzODQgKHZvaWQp IHsgcmV0dXJuICg2MTYwMzg0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2MjI1 OTIwICh2b2lkKSB7IHJldHVybiAoNjIyNTkyMCk7IH0NCnNpZ25lZCBsb25n IGludCByNjI5MTQ1NiAodm9pZCkgeyByZXR1cm4gKDYyOTE0NTYpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjYzNTY5OTIgKHZvaWQpIHsgcmV0dXJuICg2MzU2 OTkyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2NDIyNTI4ICh2b2lkKSB7IHJl dHVybiAoNjQyMjUyOCk7IH0NCnNpZ25lZCBsb25nIGludCByNjQ4ODA2NCAo dm9pZCkgeyByZXR1cm4gKDY0ODgwNjQpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjY1NTM2MDAgKHZvaWQpIHsgcmV0dXJuICg2NTUzNjAwKTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI2NjE5MTM2ICh2b2lkKSB7IHJldHVybiAoNjYxOTEzNik7 IH0NCnNpZ25lZCBsb25nIGludCByNjY4NDY3MiAodm9pZCkgeyByZXR1cm4g KDY2ODQ2NzIpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjY3NTAyMDggKHZvaWQp IHsgcmV0dXJuICg2NzUwMjA4KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI2ODE1 NzQ0ICh2b2lkKSB7IHJldHVybiAoNjgxNTc0NCk7IH0NCnNpZ25lZCBsb25n IGludCByNjg4MTI4MCAodm9pZCkgeyByZXR1cm4gKDY4ODEyODApOyB9DQpz aWduZWQgbG9uZyBpbnQgcjY5NDY4MTYgKHZvaWQpIHsgcmV0dXJuICg2OTQ2 ODE2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI3MDEyMzUyICh2b2lkKSB7IHJl dHVybiAoNzAxMjM1Mik7IH0NCnNpZ25lZCBsb25nIGludCByNzA3Nzg4OCAo dm9pZCkgeyByZXR1cm4gKDcwNzc4ODgpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjcxNDM0MjQgKHZvaWQpIHsgcmV0dXJuICg3MTQzNDI0KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI3MjA4OTYwICh2b2lkKSB7IHJldHVybiAoNzIwODk2MCk7 IH0NCnNpZ25lZCBsb25nIGludCByNzI3NDQ5NiAodm9pZCkgeyByZXR1cm4g KDcyNzQ0OTYpOyB9DQpzaWduZWQgbG9uZyBpbnQgcjczNDAwMzIgKHZvaWQp IHsgcmV0dXJuICg3MzQwMDMyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI3NDA1 NTY4ICh2b2lkKSB7IHJldHVybiAoNzQwNTU2OCk7IH0NCnNpZ25lZCBsb25n IGludCByNzQ3MTEwNCAodm9pZCkgeyByZXR1cm4gKDc0NzExMDQpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjc1MzY2NDAgKHZvaWQpIHsgcmV0dXJuICg3NTM2 NjQwKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI3NjAyMTc2ICh2b2lkKSB7IHJl dHVybiAoNzYwMjE3Nik7IH0NCnNpZ25lZCBsb25nIGludCByNzY2NzcxMiAo dm9pZCkgeyByZXR1cm4gKDc2Njc3MTIpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjc3MzMyNDggKHZvaWQpIHsgcmV0dXJuICg3NzMzMjQ4KTsgfQ0Kc2lnbmVk IGxvbmcgaW50IHI3Nzk4Nzg0ICh2b2lkKSB7IHJldHVybiAoNzc5ODc4NCk7 IH0NCnNpZ25lZCBsb25nIGludCByNzg2NDMyMCAodm9pZCkgeyByZXR1cm4g KDc4NjQzMjApOyB9DQpzaWduZWQgbG9uZyBpbnQgcjc5Mjk4NTYgKHZvaWQp IHsgcmV0dXJuICg3OTI5ODU2KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI3OTk1 MzkyICh2b2lkKSB7IHJldHVybiAoNzk5NTM5Mik7IH0NCnNpZ25lZCBsb25n IGludCByODA2MDkyOCAodm9pZCkgeyByZXR1cm4gKDgwNjA5MjgpOyB9DQpz aWduZWQgbG9uZyBpbnQgcjgxMjY0NjQgKHZvaWQpIHsgcmV0dXJuICg4MTI2 NDY0KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHI4MTkyMDAwICh2b2lkKSB7IHJl dHVybiAoODE5MjAwMCk7IH0NCnNpZ25lZCBsb25nIGludCByODI1NzUzNiAo dm9pZCkgeyByZXR1cm4gKDgyNTc1MzYpOyB9DQpzaWduZWQgbG9uZyBpbnQg cjgzMjMwNzIgKHZvaWQpIHsgcmV0dXJuICg4MzIzMDcyKTsgfQ0KDQovKiBt b3ZlLmwgI3gsRG4gLT4gbW92ZXEubCAjKC14LTEpLzY1NTM2LERuICsgc3dh cCBEbiwgc2V0IHsgeCA8IDAgfCAteCAlIDY1NTM2ID09IDEgfS4gKi8NCnNp Z25lZCBsb25nIGludCByXzY1NTM3ICh2b2lkKSB7IHJldHVybiAoLTY1NTM3 KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfMTMxMDczICh2b2lkKSB7IHJldHVy biAoLTEzMTA3Myk7IH0NCnNpZ25lZCBsb25nIGludCByXzE5NjYwOSAodm9p ZCkgeyByZXR1cm4gKC0xOTY2MDkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8y NjIxNDUgKHZvaWQpIHsgcmV0dXJuICgtMjYyMTQ1KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHJfMzI3NjgxICh2b2lkKSB7IHJldHVybiAoLTMyNzY4MSk7IH0N CnNpZ25lZCBsb25nIGludCByXzM5MzIxNyAodm9pZCkgeyByZXR1cm4gKC0z OTMyMTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl80NTg3NTMgKHZvaWQpIHsg cmV0dXJuICgtNDU4NzUzKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNTI0Mjg5 ICh2b2lkKSB7IHJldHVybiAoLTUyNDI4OSk7IH0NCnNpZ25lZCBsb25nIGlu dCByXzU4OTgyNSAodm9pZCkgeyByZXR1cm4gKC01ODk4MjUpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl82NTUzNjEgKHZvaWQpIHsgcmV0dXJuICgtNjU1MzYx KTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNzIwODk3ICh2b2lkKSB7IHJldHVy biAoLTcyMDg5Nyk7IH0NCnNpZ25lZCBsb25nIGludCByXzc4NjQzMyAodm9p ZCkgeyByZXR1cm4gKC03ODY0MzMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl84 NTE5NjkgKHZvaWQpIHsgcmV0dXJuICgtODUxOTY5KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHJfOTE3NTA1ICh2b2lkKSB7IHJldHVybiAoLTkxNzUwNSk7IH0N CnNpZ25lZCBsb25nIGludCByXzk4MzA0MSAodm9pZCkgeyByZXR1cm4gKC05 ODMwNDEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xMDQ4NTc3ICh2b2lkKSB7 IHJldHVybiAoLTEwNDg1NzcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xMTE0 MTEzICh2b2lkKSB7IHJldHVybiAoLTExMTQxMTMpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl8xMTc5NjQ5ICh2b2lkKSB7IHJldHVybiAoLTExNzk2NDkpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl8xMjQ1MTg1ICh2b2lkKSB7IHJldHVybiAo LTEyNDUxODUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xMzEwNzIxICh2b2lk KSB7IHJldHVybiAoLTEzMTA3MjEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8x Mzc2MjU3ICh2b2lkKSB7IHJldHVybiAoLTEzNzYyNTcpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl8xNDQxNzkzICh2b2lkKSB7IHJldHVybiAoLTE0NDE3OTMp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xNTA3MzI5ICh2b2lkKSB7IHJldHVy biAoLTE1MDczMjkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xNTcyODY1ICh2 b2lkKSB7IHJldHVybiAoLTE1NzI4NjUpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl8xNjM4NDAxICh2b2lkKSB7IHJldHVybiAoLTE2Mzg0MDEpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl8xNzAzOTM3ICh2b2lkKSB7IHJldHVybiAoLTE3MDM5 MzcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xNzY5NDczICh2b2lkKSB7IHJl dHVybiAoLTE3Njk0NzMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8xODM1MDA5 ICh2b2lkKSB7IHJldHVybiAoLTE4MzUwMDkpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl8xOTAwNTQ1ICh2b2lkKSB7IHJldHVybiAoLTE5MDA1NDUpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl8xOTY2MDgxICh2b2lkKSB7IHJldHVybiAoLTE5 NjYwODEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yMDMxNjE3ICh2b2lkKSB7 IHJldHVybiAoLTIwMzE2MTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yMDk3 MTUzICh2b2lkKSB7IHJldHVybiAoLTIwOTcxNTMpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl8yMTYyNjg5ICh2b2lkKSB7IHJldHVybiAoLTIxNjI2ODkpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl8yMjI4MjI1ICh2b2lkKSB7IHJldHVybiAo LTIyMjgyMjUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yMjkzNzYxICh2b2lk KSB7IHJldHVybiAoLTIyOTM3NjEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8y MzU5Mjk3ICh2b2lkKSB7IHJldHVybiAoLTIzNTkyOTcpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl8yNDI0ODMzICh2b2lkKSB7IHJldHVybiAoLTI0MjQ4MzMp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yNDkwMzY5ICh2b2lkKSB7IHJldHVy biAoLTI0OTAzNjkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yNTU1OTA1ICh2 b2lkKSB7IHJldHVybiAoLTI1NTU5MDUpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl8yNjIxNDQxICh2b2lkKSB7IHJldHVybiAoLTI2MjE0NDEpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl8yNjg2OTc3ICh2b2lkKSB7IHJldHVybiAoLTI2ODY5 NzcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yNzUyNTEzICh2b2lkKSB7IHJl dHVybiAoLTI3NTI1MTMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8yODE4MDQ5 ICh2b2lkKSB7IHJldHVybiAoLTI4MTgwNDkpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl8yODgzNTg1ICh2b2lkKSB7IHJldHVybiAoLTI4ODM1ODUpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl8yOTQ5MTIxICh2b2lkKSB7IHJldHVybiAoLTI5 NDkxMjEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8zMDE0NjU3ICh2b2lkKSB7 IHJldHVybiAoLTMwMTQ2NTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8zMDgw MTkzICh2b2lkKSB7IHJldHVybiAoLTMwODAxOTMpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl8zMTQ1NzI5ICh2b2lkKSB7IHJldHVybiAoLTMxNDU3MjkpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl8zMjExMjY1ICh2b2lkKSB7IHJldHVybiAo LTMyMTEyNjUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8zMjc2ODAxICh2b2lk KSB7IHJldHVybiAoLTMyNzY4MDEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8z MzQyMzM3ICh2b2lkKSB7IHJldHVybiAoLTMzNDIzMzcpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl8zNDA3ODczICh2b2lkKSB7IHJldHVybiAoLTM0MDc4NzMp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl8zNDczNDA5ICh2b2lkKSB7IHJldHVy biAoLTM0NzM0MDkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8zNTM4OTQ1ICh2 b2lkKSB7IHJldHVybiAoLTM1Mzg5NDUpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl8zNjA0NDgxICh2b2lkKSB7IHJldHVybiAoLTM2MDQ0ODEpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl8zNjcwMDE3ICh2b2lkKSB7IHJldHVybiAoLTM2NzAw MTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8zNzM1NTUzICh2b2lkKSB7IHJl dHVybiAoLTM3MzU1NTMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8zODAxMDg5 ICh2b2lkKSB7IHJldHVybiAoLTM4MDEwODkpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl8zODY2NjI1ICh2b2lkKSB7IHJldHVybiAoLTM4NjY2MjUpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl8zOTMyMTYxICh2b2lkKSB7IHJldHVybiAoLTM5 MzIxNjEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl8zOTk3Njk3ICh2b2lkKSB7 IHJldHVybiAoLTM5OTc2OTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl80MDYz MjMzICh2b2lkKSB7IHJldHVybiAoLTQwNjMyMzMpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl80MTI4NzY5ICh2b2lkKSB7IHJldHVybiAoLTQxMjg3NjkpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl80MTk0MzA1ICh2b2lkKSB7IHJldHVybiAo LTQxOTQzMDUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl80MjU5ODQxICh2b2lk KSB7IHJldHVybiAoLTQyNTk4NDEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl80 MzI1Mzc3ICh2b2lkKSB7IHJldHVybiAoLTQzMjUzNzcpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl80MzkwOTEzICh2b2lkKSB7IHJldHVybiAoLTQzOTA5MTMp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl80NDU2NDQ5ICh2b2lkKSB7IHJldHVy biAoLTQ0NTY0NDkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl80NTIxOTg1ICh2 b2lkKSB7IHJldHVybiAoLTQ1MjE5ODUpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl80NTg3NTIxICh2b2lkKSB7IHJldHVybiAoLTQ1ODc1MjEpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl80NjUzMDU3ICh2b2lkKSB7IHJldHVybiAoLTQ2NTMw NTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl80NzE4NTkzICh2b2lkKSB7IHJl dHVybiAoLTQ3MTg1OTMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl80Nzg0MTI5 ICh2b2lkKSB7IHJldHVybiAoLTQ3ODQxMjkpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl80ODQ5NjY1ICh2b2lkKSB7IHJldHVybiAoLTQ4NDk2NjUpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl80OTE1MjAxICh2b2lkKSB7IHJldHVybiAoLTQ5 MTUyMDEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl80OTgwNzM3ICh2b2lkKSB7 IHJldHVybiAoLTQ5ODA3MzcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl81MDQ2 MjczICh2b2lkKSB7IHJldHVybiAoLTUwNDYyNzMpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl81MTExODA5ICh2b2lkKSB7IHJldHVybiAoLTUxMTE4MDkpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl81MTc3MzQ1ICh2b2lkKSB7IHJldHVybiAo LTUxNzczNDUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl81MjQyODgxICh2b2lk KSB7IHJldHVybiAoLTUyNDI4ODEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl81 MzA4NDE3ICh2b2lkKSB7IHJldHVybiAoLTUzMDg0MTcpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl81MzczOTUzICh2b2lkKSB7IHJldHVybiAoLTUzNzM5NTMp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl81NDM5NDg5ICh2b2lkKSB7IHJldHVy biAoLTU0Mzk0ODkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl81NTA1MDI1ICh2 b2lkKSB7IHJldHVybiAoLTU1MDUwMjUpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl81NTcwNTYxICh2b2lkKSB7IHJldHVybiAoLTU1NzA1NjEpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl81NjM2MDk3ICh2b2lkKSB7IHJldHVybiAoLTU2MzYw OTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl81NzAxNjMzICh2b2lkKSB7IHJl dHVybiAoLTU3MDE2MzMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl81NzY3MTY5 ICh2b2lkKSB7IHJldHVybiAoLTU3NjcxNjkpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl81ODMyNzA1ICh2b2lkKSB7IHJldHVybiAoLTU4MzI3MDUpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl81ODk4MjQxICh2b2lkKSB7IHJldHVybiAoLTU4 OTgyNDEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl81OTYzNzc3ICh2b2lkKSB7 IHJldHVybiAoLTU5NjM3NzcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82MDI5 MzEzICh2b2lkKSB7IHJldHVybiAoLTYwMjkzMTMpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl82MDk0ODQ5ICh2b2lkKSB7IHJldHVybiAoLTYwOTQ4NDkpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl82MTYwMzg1ICh2b2lkKSB7IHJldHVybiAo LTYxNjAzODUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82MjI1OTIxICh2b2lk KSB7IHJldHVybiAoLTYyMjU5MjEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82 MjkxNDU3ICh2b2lkKSB7IHJldHVybiAoLTYyOTE0NTcpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl82MzU2OTkzICh2b2lkKSB7IHJldHVybiAoLTYzNTY5OTMp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NDIyNTI5ICh2b2lkKSB7IHJldHVy biAoLTY0MjI1MjkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NDg4MDY1ICh2 b2lkKSB7IHJldHVybiAoLTY0ODgwNjUpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl82NTUzNjAxICh2b2lkKSB7IHJldHVybiAoLTY1NTM2MDEpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl82NjE5MTM3ICh2b2lkKSB7IHJldHVybiAoLTY2MTkx MzcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82Njg0NjczICh2b2lkKSB7IHJl dHVybiAoLTY2ODQ2NzMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NzUwMjA5 ICh2b2lkKSB7IHJldHVybiAoLTY3NTAyMDkpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl82ODE1NzQ1ICh2b2lkKSB7IHJldHVybiAoLTY4MTU3NDUpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl82ODgxMjgxICh2b2lkKSB7IHJldHVybiAoLTY4 ODEyODEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82OTQ2ODE3ICh2b2lkKSB7 IHJldHVybiAoLTY5NDY4MTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl83MDEy MzUzICh2b2lkKSB7IHJldHVybiAoLTcwMTIzNTMpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl83MDc3ODg5ICh2b2lkKSB7IHJldHVybiAoLTcwNzc4ODkpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl83MTQzNDI1ICh2b2lkKSB7IHJldHVybiAo LTcxNDM0MjUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl83MjA4OTYxICh2b2lk KSB7IHJldHVybiAoLTcyMDg5NjEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl83 Mjc0NDk3ICh2b2lkKSB7IHJldHVybiAoLTcyNzQ0OTcpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl83MzQwMDMzICh2b2lkKSB7IHJldHVybiAoLTczNDAwMzMp OyB9DQpzaWduZWQgbG9uZyBpbnQgcl83NDA1NTY5ICh2b2lkKSB7IHJldHVy biAoLTc0MDU1NjkpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl83NDcxMTA1ICh2 b2lkKSB7IHJldHVybiAoLTc0NzExMDUpOyB9DQpzaWduZWQgbG9uZyBpbnQg cl83NTM2NjQxICh2b2lkKSB7IHJldHVybiAoLTc1MzY2NDEpOyB9DQpzaWdu ZWQgbG9uZyBpbnQgcl83NjAyMTc3ICh2b2lkKSB7IHJldHVybiAoLTc2MDIx NzcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl83NjY3NzEzICh2b2lkKSB7IHJl dHVybiAoLTc2Njc3MTMpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl83NzMzMjQ5 ICh2b2lkKSB7IHJldHVybiAoLTc3MzMyNDkpOyB9DQpzaWduZWQgbG9uZyBp bnQgcl83Nzk4Nzg1ICh2b2lkKSB7IHJldHVybiAoLTc3OTg3ODUpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl83ODY0MzIxICh2b2lkKSB7IHJldHVybiAoLTc4 NjQzMjEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl83OTI5ODU3ICh2b2lkKSB7 IHJldHVybiAoLTc5Mjk4NTcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl83OTk1 MzkzICh2b2lkKSB7IHJldHVybiAoLTc5OTUzOTMpOyB9DQpzaWduZWQgbG9u ZyBpbnQgcl84MDYwOTI5ICh2b2lkKSB7IHJldHVybiAoLTgwNjA5MjkpOyB9 DQpzaWduZWQgbG9uZyBpbnQgcl84MTI2NDY1ICh2b2lkKSB7IHJldHVybiAo LTgxMjY0NjUpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl84MTkyMDAxICh2b2lk KSB7IHJldHVybiAoLTgxOTIwMDEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl84 MjU3NTM3ICh2b2lkKSB7IHJldHVybiAoLTgyNTc1MzcpOyB9DQpzaWduZWQg bG9uZyBpbnQgcl84MzIzMDczICh2b2lkKSB7IHJldHVybiAoLTgzMjMwNzMp OyB9DQoNCmludCBtYWluIChpbnQgYXJnYywgY2hhciAqYXJndltdKQ0Kew0K LyogbW92ZS5sICN4LERuIC0+IG1vdmVxLmwgI3gvNjU1MzYsRG4gKyBzd2Fw IERuLCBzZXQgeyB4ID4gMCB8IHggJSA2NTUzNiA9PSAwIH0uICovDQoJcHJp bnRmICgiNjU1MzYgPSAlbGRcbiIsIHI2NTUzNiAoKSk7DQoJcHJpbnRmICgi MTMxMDcyID0gJWxkXG4iLCByMTMxMDcyICgpKTsNCglwcmludGYgKCIxOTY2 MDggPSAlbGRcbiIsIHIxOTY2MDggKCkpOw0KCXByaW50ZiAoIjI2MjE0NCA9 ICVsZFxuIiwgcjI2MjE0NCAoKSk7DQoJcHJpbnRmICgiMzI3NjgwID0gJWxk XG4iLCByMzI3NjgwICgpKTsNCglwcmludGYgKCIzOTMyMTYgPSAlbGRcbiIs IHIzOTMyMTYgKCkpOw0KCXByaW50ZiAoIjQ1ODc1MiA9ICVsZFxuIiwgcjQ1 ODc1MiAoKSk7DQoJcHJpbnRmICgiNTI0Mjg4ID0gJWxkXG4iLCByNTI0Mjg4 ICgpKTsNCglwcmludGYgKCI1ODk4MjQgPSAlbGRcbiIsIHI1ODk4MjQgKCkp Ow0KCXByaW50ZiAoIjY1NTM2MCA9ICVsZFxuIiwgcjY1NTM2MCAoKSk7DQoJ cHJpbnRmICgiNzIwODk2ID0gJWxkXG4iLCByNzIwODk2ICgpKTsNCglwcmlu dGYgKCI3ODY0MzIgPSAlbGRcbiIsIHI3ODY0MzIgKCkpOw0KCXByaW50ZiAo Ijg1MTk2OCA9ICVsZFxuIiwgcjg1MTk2OCAoKSk7DQoJcHJpbnRmICgiOTE3 NTA0ID0gJWxkXG4iLCByOTE3NTA0ICgpKTsNCglwcmludGYgKCI5ODMwNDAg PSAlbGRcbiIsIHI5ODMwNDAgKCkpOw0KCXByaW50ZiAoIjEwNDg1NzYgPSAl bGRcbiIsIHIxMDQ4NTc2ICgpKTsNCglwcmludGYgKCIxMTE0MTEyID0gJWxk XG4iLCByMTExNDExMiAoKSk7DQoJcHJpbnRmICgiMTE3OTY0OCA9ICVsZFxu IiwgcjExNzk2NDggKCkpOw0KCXByaW50ZiAoIjEyNDUxODQgPSAlbGRcbiIs IHIxMjQ1MTg0ICgpKTsNCglwcmludGYgKCIxMzEwNzIwID0gJWxkXG4iLCBy MTMxMDcyMCAoKSk7DQoJcHJpbnRmICgiMTM3NjI1NiA9ICVsZFxuIiwgcjEz NzYyNTYgKCkpOw0KCXByaW50ZiAoIjE0NDE3OTIgPSAlbGRcbiIsIHIxNDQx NzkyICgpKTsNCglwcmludGYgKCIxNTA3MzI4ID0gJWxkXG4iLCByMTUwNzMy OCAoKSk7DQoJcHJpbnRmICgiMTU3Mjg2NCA9ICVsZFxuIiwgcjE1NzI4NjQg KCkpOw0KCXByaW50ZiAoIjE2Mzg0MDAgPSAlbGRcbiIsIHIxNjM4NDAwICgp KTsNCglwcmludGYgKCIxNzAzOTM2ID0gJWxkXG4iLCByMTcwMzkzNiAoKSk7 DQoJcHJpbnRmICgiMTc2OTQ3MiA9ICVsZFxuIiwgcjE3Njk0NzIgKCkpOw0K CXByaW50ZiAoIjE4MzUwMDggPSAlbGRcbiIsIHIxODM1MDA4ICgpKTsNCglw cmludGYgKCIxOTAwNTQ0ID0gJWxkXG4iLCByMTkwMDU0NCAoKSk7DQoJcHJp bnRmICgiMTk2NjA4MCA9ICVsZFxuIiwgcjE5NjYwODAgKCkpOw0KCXByaW50 ZiAoIjIwMzE2MTYgPSAlbGRcbiIsIHIyMDMxNjE2ICgpKTsNCglwcmludGYg KCIyMDk3MTUyID0gJWxkXG4iLCByMjA5NzE1MiAoKSk7DQoJcHJpbnRmICgi MjE2MjY4OCA9ICVsZFxuIiwgcjIxNjI2ODggKCkpOw0KCXByaW50ZiAoIjIy MjgyMjQgPSAlbGRcbiIsIHIyMjI4MjI0ICgpKTsNCglwcmludGYgKCIyMjkz NzYwID0gJWxkXG4iLCByMjI5Mzc2MCAoKSk7DQoJcHJpbnRmICgiMjM1OTI5 NiA9ICVsZFxuIiwgcjIzNTkyOTYgKCkpOw0KCXByaW50ZiAoIjI0MjQ4MzIg PSAlbGRcbiIsIHIyNDI0ODMyICgpKTsNCglwcmludGYgKCIyNDkwMzY4ID0g JWxkXG4iLCByMjQ5MDM2OCAoKSk7DQoJcHJpbnRmICgiMjU1NTkwNCA9ICVs ZFxuIiwgcjI1NTU5MDQgKCkpOw0KCXByaW50ZiAoIjI2MjE0NDAgPSAlbGRc biIsIHIyNjIxNDQwICgpKTsNCglwcmludGYgKCIyNjg2OTc2ID0gJWxkXG4i LCByMjY4Njk3NiAoKSk7DQoJcHJpbnRmICgiMjc1MjUxMiA9ICVsZFxuIiwg cjI3NTI1MTIgKCkpOw0KCXByaW50ZiAoIjI4MTgwNDggPSAlbGRcbiIsIHIy ODE4MDQ4ICgpKTsNCglwcmludGYgKCIyODgzNTg0ID0gJWxkXG4iLCByMjg4 MzU4NCAoKSk7DQoJcHJpbnRmICgiMjk0OTEyMCA9ICVsZFxuIiwgcjI5NDkx MjAgKCkpOw0KCXByaW50ZiAoIjMwMTQ2NTYgPSAlbGRcbiIsIHIzMDE0NjU2 ICgpKTsNCglwcmludGYgKCIzMDgwMTkyID0gJWxkXG4iLCByMzA4MDE5MiAo KSk7DQoJcHJpbnRmICgiMzE0NTcyOCA9ICVsZFxuIiwgcjMxNDU3MjggKCkp Ow0KCXByaW50ZiAoIjMyMTEyNjQgPSAlbGRcbiIsIHIzMjExMjY0ICgpKTsN CglwcmludGYgKCIzMjc2ODAwID0gJWxkXG4iLCByMzI3NjgwMCAoKSk7DQoJ cHJpbnRmICgiMzM0MjMzNiA9ICVsZFxuIiwgcjMzNDIzMzYgKCkpOw0KCXBy aW50ZiAoIjM0MDc4NzIgPSAlbGRcbiIsIHIzNDA3ODcyICgpKTsNCglwcmlu dGYgKCIzNDczNDA4ID0gJWxkXG4iLCByMzQ3MzQwOCAoKSk7DQoJcHJpbnRm ICgiMzUzODk0NCA9ICVsZFxuIiwgcjM1Mzg5NDQgKCkpOw0KCXByaW50ZiAo IjM2MDQ0ODAgPSAlbGRcbiIsIHIzNjA0NDgwICgpKTsNCglwcmludGYgKCIz NjcwMDE2ID0gJWxkXG4iLCByMzY3MDAxNiAoKSk7DQoJcHJpbnRmICgiMzcz NTU1MiA9ICVsZFxuIiwgcjM3MzU1NTIgKCkpOw0KCXByaW50ZiAoIjM4MDEw ODggPSAlbGRcbiIsIHIzODAxMDg4ICgpKTsNCglwcmludGYgKCIzODY2NjI0 ID0gJWxkXG4iLCByMzg2NjYyNCAoKSk7DQoJcHJpbnRmICgiMzkzMjE2MCA9 ICVsZFxuIiwgcjM5MzIxNjAgKCkpOw0KCXByaW50ZiAoIjM5OTc2OTYgPSAl bGRcbiIsIHIzOTk3Njk2ICgpKTsNCglwcmludGYgKCI0MDYzMjMyID0gJWxk XG4iLCByNDA2MzIzMiAoKSk7DQoJcHJpbnRmICgiNDEyODc2OCA9ICVsZFxu IiwgcjQxMjg3NjggKCkpOw0KCXByaW50ZiAoIjQxOTQzMDQgPSAlbGRcbiIs IHI0MTk0MzA0ICgpKTsNCglwcmludGYgKCI0MjU5ODQwID0gJWxkXG4iLCBy NDI1OTg0MCAoKSk7DQoJcHJpbnRmICgiNDMyNTM3NiA9ICVsZFxuIiwgcjQz MjUzNzYgKCkpOw0KCXByaW50ZiAoIjQzOTA5MTIgPSAlbGRcbiIsIHI0Mzkw OTEyICgpKTsNCglwcmludGYgKCI0NDU2NDQ4ID0gJWxkXG4iLCByNDQ1NjQ0 OCAoKSk7DQoJcHJpbnRmICgiNDUyMTk4NCA9ICVsZFxuIiwgcjQ1MjE5ODQg KCkpOw0KCXByaW50ZiAoIjQ1ODc1MjAgPSAlbGRcbiIsIHI0NTg3NTIwICgp KTsNCglwcmludGYgKCI0NjUzMDU2ID0gJWxkXG4iLCByNDY1MzA1NiAoKSk7 DQoJcHJpbnRmICgiNDcxODU5MiA9ICVsZFxuIiwgcjQ3MTg1OTIgKCkpOw0K CXByaW50ZiAoIjQ3ODQxMjggPSAlbGRcbiIsIHI0Nzg0MTI4ICgpKTsNCglw cmludGYgKCI0ODQ5NjY0ID0gJWxkXG4iLCByNDg0OTY2NCAoKSk7DQoJcHJp bnRmICgiNDkxNTIwMCA9ICVsZFxuIiwgcjQ5MTUyMDAgKCkpOw0KCXByaW50 ZiAoIjQ5ODA3MzYgPSAlbGRcbiIsIHI0OTgwNzM2ICgpKTsNCglwcmludGYg KCI1MDQ2MjcyID0gJWxkXG4iLCByNTA0NjI3MiAoKSk7DQoJcHJpbnRmICgi NTExMTgwOCA9ICVsZFxuIiwgcjUxMTE4MDggKCkpOw0KCXByaW50ZiAoIjUx NzczNDQgPSAlbGRcbiIsIHI1MTc3MzQ0ICgpKTsNCglwcmludGYgKCI1MjQy ODgwID0gJWxkXG4iLCByNTI0Mjg4MCAoKSk7DQoJcHJpbnRmICgiNTMwODQx NiA9ICVsZFxuIiwgcjUzMDg0MTYgKCkpOw0KCXByaW50ZiAoIjUzNzM5NTIg PSAlbGRcbiIsIHI1MzczOTUyICgpKTsNCglwcmludGYgKCI1NDM5NDg4ID0g JWxkXG4iLCByNTQzOTQ4OCAoKSk7DQoJcHJpbnRmICgiNTUwNTAyNCA9ICVs ZFxuIiwgcjU1MDUwMjQgKCkpOw0KCXByaW50ZiAoIjU1NzA1NjAgPSAlbGRc biIsIHI1NTcwNTYwICgpKTsNCglwcmludGYgKCI1NjM2MDk2ID0gJWxkXG4i LCByNTYzNjA5NiAoKSk7DQoJcHJpbnRmICgiNTcwMTYzMiA9ICVsZFxuIiwg cjU3MDE2MzIgKCkpOw0KCXByaW50ZiAoIjU3NjcxNjggPSAlbGRcbiIsIHI1 NzY3MTY4ICgpKTsNCglwcmludGYgKCI1ODMyNzA0ID0gJWxkXG4iLCByNTgz MjcwNCAoKSk7DQoJcHJpbnRmICgiNTg5ODI0MCA9ICVsZFxuIiwgcjU4OTgy NDAgKCkpOw0KCXByaW50ZiAoIjU5NjM3NzYgPSAlbGRcbiIsIHI1OTYzNzc2 ICgpKTsNCglwcmludGYgKCI2MDI5MzEyID0gJWxkXG4iLCByNjAyOTMxMiAo KSk7DQoJcHJpbnRmICgiNjA5NDg0OCA9ICVsZFxuIiwgcjYwOTQ4NDggKCkp Ow0KCXByaW50ZiAoIjYxNjAzODQgPSAlbGRcbiIsIHI2MTYwMzg0ICgpKTsN CglwcmludGYgKCI2MjI1OTIwID0gJWxkXG4iLCByNjIyNTkyMCAoKSk7DQoJ cHJpbnRmICgiNjI5MTQ1NiA9ICVsZFxuIiwgcjYyOTE0NTYgKCkpOw0KCXBy aW50ZiAoIjYzNTY5OTIgPSAlbGRcbiIsIHI2MzU2OTkyICgpKTsNCglwcmlu dGYgKCI2NDIyNTI4ID0gJWxkXG4iLCByNjQyMjUyOCAoKSk7DQoJcHJpbnRm ICgiNjQ4ODA2NCA9ICVsZFxuIiwgcjY0ODgwNjQgKCkpOw0KCXByaW50ZiAo IjY1NTM2MDAgPSAlbGRcbiIsIHI2NTUzNjAwICgpKTsNCglwcmludGYgKCI2 NjE5MTM2ID0gJWxkXG4iLCByNjYxOTEzNiAoKSk7DQoJcHJpbnRmICgiNjY4 NDY3MiA9ICVsZFxuIiwgcjY2ODQ2NzIgKCkpOw0KCXByaW50ZiAoIjY3NTAy MDggPSAlbGRcbiIsIHI2NzUwMjA4ICgpKTsNCglwcmludGYgKCI2ODE1NzQ0 ID0gJWxkXG4iLCByNjgxNTc0NCAoKSk7DQoJcHJpbnRmICgiNjg4MTI4MCA9 ICVsZFxuIiwgcjY4ODEyODAgKCkpOw0KCXByaW50ZiAoIjY5NDY4MTYgPSAl bGRcbiIsIHI2OTQ2ODE2ICgpKTsNCglwcmludGYgKCI3MDEyMzUyID0gJWxk XG4iLCByNzAxMjM1MiAoKSk7DQoJcHJpbnRmICgiNzA3Nzg4OCA9ICVsZFxu IiwgcjcwNzc4ODggKCkpOw0KCXByaW50ZiAoIjcxNDM0MjQgPSAlbGRcbiIs IHI3MTQzNDI0ICgpKTsNCglwcmludGYgKCI3MjA4OTYwID0gJWxkXG4iLCBy NzIwODk2MCAoKSk7DQoJcHJpbnRmICgiNzI3NDQ5NiA9ICVsZFxuIiwgcjcy NzQ0OTYgKCkpOw0KCXByaW50ZiAoIjczNDAwMzIgPSAlbGRcbiIsIHI3MzQw MDMyICgpKTsNCglwcmludGYgKCI3NDA1NTY4ID0gJWxkXG4iLCByNzQwNTU2 OCAoKSk7DQoJcHJpbnRmICgiNzQ3MTEwNCA9ICVsZFxuIiwgcjc0NzExMDQg KCkpOw0KCXByaW50ZiAoIjc1MzY2NDAgPSAlbGRcbiIsIHI3NTM2NjQwICgp KTsNCglwcmludGYgKCI3NjAyMTc2ID0gJWxkXG4iLCByNzYwMjE3NiAoKSk7 DQoJcHJpbnRmICgiNzY2NzcxMiA9ICVsZFxuIiwgcjc2Njc3MTIgKCkpOw0K CXByaW50ZiAoIjc3MzMyNDggPSAlbGRcbiIsIHI3NzMzMjQ4ICgpKTsNCglw cmludGYgKCI3Nzk4Nzg0ID0gJWxkXG4iLCByNzc5ODc4NCAoKSk7DQoJcHJp bnRmICgiNzg2NDMyMCA9ICVsZFxuIiwgcjc4NjQzMjAgKCkpOw0KCXByaW50 ZiAoIjc5Mjk4NTYgPSAlbGRcbiIsIHI3OTI5ODU2ICgpKTsNCglwcmludGYg KCI3OTk1MzkyID0gJWxkXG4iLCByNzk5NTM5MiAoKSk7DQoJcHJpbnRmICgi ODA2MDkyOCA9ICVsZFxuIiwgcjgwNjA5MjggKCkpOw0KCXByaW50ZiAoIjgx MjY0NjQgPSAlbGRcbiIsIHI4MTI2NDY0ICgpKTsNCglwcmludGYgKCI4MTky MDAwID0gJWxkXG4iLCByODE5MjAwMCAoKSk7DQoJcHJpbnRmICgiODI1NzUz NiA9ICVsZFxuIiwgcjgyNTc1MzYgKCkpOw0KCXByaW50ZiAoIjgzMjMwNzIg PSAlbGRcbiIsIHI4MzIzMDcyICgpKTsNCi8qIG1vdmUubCAjeCxEbiAtPiBt b3ZlcS5sICMoLXgtMSkvNjU1MzYsRG4gKyBzd2FwIERuLCBzZXQgeyB4IDwg MCB8IC14ICUgNjU1MzYgPT0gMSB9LiAqLw0KCXByaW50ZiAoIi02NTUzNyA9 ICVsZFxuIiwgcl82NTUzNyAoKSk7DQoJcHJpbnRmICgiLTEzMTA3MyA9ICVs ZFxuIiwgcl8xMzEwNzMgKCkpOw0KCXByaW50ZiAoIi0xOTY2MDkgPSAlbGRc biIsIHJfMTk2NjA5ICgpKTsNCglwcmludGYgKCItMjYyMTQ1ID0gJWxkXG4i LCByXzI2MjE0NSAoKSk7DQoJcHJpbnRmICgiLTMyNzY4MSA9ICVsZFxuIiwg cl8zMjc2ODEgKCkpOw0KCXByaW50ZiAoIi0zOTMyMTcgPSAlbGRcbiIsIHJf MzkzMjE3ICgpKTsNCglwcmludGYgKCItNDU4NzUzID0gJWxkXG4iLCByXzQ1 ODc1MyAoKSk7DQoJcHJpbnRmICgiLTUyNDI4OSA9ICVsZFxuIiwgcl81MjQy ODkgKCkpOw0KCXByaW50ZiAoIi01ODk4MjUgPSAlbGRcbiIsIHJfNTg5ODI1 ICgpKTsNCglwcmludGYgKCItNjU1MzYxID0gJWxkXG4iLCByXzY1NTM2MSAo KSk7DQoJcHJpbnRmICgiLTcyMDg5NyA9ICVsZFxuIiwgcl83MjA4OTcgKCkp Ow0KCXByaW50ZiAoIi03ODY0MzMgPSAlbGRcbiIsIHJfNzg2NDMzICgpKTsN CglwcmludGYgKCItODUxOTY5ID0gJWxkXG4iLCByXzg1MTk2OSAoKSk7DQoJ cHJpbnRmICgiLTkxNzUwNSA9ICVsZFxuIiwgcl85MTc1MDUgKCkpOw0KCXBy aW50ZiAoIi05ODMwNDEgPSAlbGRcbiIsIHJfOTgzMDQxICgpKTsNCglwcmlu dGYgKCItMTA0ODU3NyA9ICVsZFxuIiwgcl8xMDQ4NTc3ICgpKTsNCglwcmlu dGYgKCItMTExNDExMyA9ICVsZFxuIiwgcl8xMTE0MTEzICgpKTsNCglwcmlu dGYgKCItMTE3OTY0OSA9ICVsZFxuIiwgcl8xMTc5NjQ5ICgpKTsNCglwcmlu dGYgKCItMTI0NTE4NSA9ICVsZFxuIiwgcl8xMjQ1MTg1ICgpKTsNCglwcmlu dGYgKCItMTMxMDcyMSA9ICVsZFxuIiwgcl8xMzEwNzIxICgpKTsNCglwcmlu dGYgKCItMTM3NjI1NyA9ICVsZFxuIiwgcl8xMzc2MjU3ICgpKTsNCglwcmlu dGYgKCItMTQ0MTc5MyA9ICVsZFxuIiwgcl8xNDQxNzkzICgpKTsNCglwcmlu dGYgKCItMTUwNzMyOSA9ICVsZFxuIiwgcl8xNTA3MzI5ICgpKTsNCglwcmlu dGYgKCItMTU3Mjg2NSA9ICVsZFxuIiwgcl8xNTcyODY1ICgpKTsNCglwcmlu dGYgKCItMTYzODQwMSA9ICVsZFxuIiwgcl8xNjM4NDAxICgpKTsNCglwcmlu dGYgKCItMTcwMzkzNyA9ICVsZFxuIiwgcl8xNzAzOTM3ICgpKTsNCglwcmlu dGYgKCItMTc2OTQ3MyA9ICVsZFxuIiwgcl8xNzY5NDczICgpKTsNCglwcmlu dGYgKCItMTgzNTAwOSA9ICVsZFxuIiwgcl8xODM1MDA5ICgpKTsNCglwcmlu dGYgKCItMTkwMDU0NSA9ICVsZFxuIiwgcl8xOTAwNTQ1ICgpKTsNCglwcmlu dGYgKCItMTk2NjA4MSA9ICVsZFxuIiwgcl8xOTY2MDgxICgpKTsNCglwcmlu dGYgKCItMjAzMTYxNyA9ICVsZFxuIiwgcl8yMDMxNjE3ICgpKTsNCglwcmlu dGYgKCItMjA5NzE1MyA9ICVsZFxuIiwgcl8yMDk3MTUzICgpKTsNCglwcmlu dGYgKCItMjE2MjY4OSA9ICVsZFxuIiwgcl8yMTYyNjg5ICgpKTsNCglwcmlu dGYgKCItMjIyODIyNSA9ICVsZFxuIiwgcl8yMjI4MjI1ICgpKTsNCglwcmlu dGYgKCItMjI5Mzc2MSA9ICVsZFxuIiwgcl8yMjkzNzYxICgpKTsNCglwcmlu dGYgKCItMjM1OTI5NyA9ICVsZFxuIiwgcl8yMzU5Mjk3ICgpKTsNCglwcmlu dGYgKCItMjQyNDgzMyA9ICVsZFxuIiwgcl8yNDI0ODMzICgpKTsNCglwcmlu dGYgKCItMjQ5MDM2OSA9ICVsZFxuIiwgcl8yNDkwMzY5ICgpKTsNCglwcmlu dGYgKCItMjU1NTkwNSA9ICVsZFxuIiwgcl8yNTU1OTA1ICgpKTsNCglwcmlu dGYgKCItMjYyMTQ0MSA9ICVsZFxuIiwgcl8yNjIxNDQxICgpKTsNCglwcmlu dGYgKCItMjY4Njk3NyA9ICVsZFxuIiwgcl8yNjg2OTc3ICgpKTsNCglwcmlu dGYgKCItMjc1MjUxMyA9ICVsZFxuIiwgcl8yNzUyNTEzICgpKTsNCglwcmlu dGYgKCItMjgxODA0OSA9ICVsZFxuIiwgcl8yODE4MDQ5ICgpKTsNCglwcmlu dGYgKCItMjg4MzU4NSA9ICVsZFxuIiwgcl8yODgzNTg1ICgpKTsNCglwcmlu dGYgKCItMjk0OTEyMSA9ICVsZFxuIiwgcl8yOTQ5MTIxICgpKTsNCglwcmlu dGYgKCItMzAxNDY1NyA9ICVsZFxuIiwgcl8zMDE0NjU3ICgpKTsNCglwcmlu dGYgKCItMzA4MDE5MyA9ICVsZFxuIiwgcl8zMDgwMTkzICgpKTsNCglwcmlu dGYgKCItMzE0NTcyOSA9ICVsZFxuIiwgcl8zMTQ1NzI5ICgpKTsNCglwcmlu dGYgKCItMzIxMTI2NSA9ICVsZFxuIiwgcl8zMjExMjY1ICgpKTsNCglwcmlu dGYgKCItMzI3NjgwMSA9ICVsZFxuIiwgcl8zMjc2ODAxICgpKTsNCglwcmlu dGYgKCItMzM0MjMzNyA9ICVsZFxuIiwgcl8zMzQyMzM3ICgpKTsNCglwcmlu dGYgKCItMzQwNzg3MyA9ICVsZFxuIiwgcl8zNDA3ODczICgpKTsNCglwcmlu dGYgKCItMzQ3MzQwOSA9ICVsZFxuIiwgcl8zNDczNDA5ICgpKTsNCglwcmlu dGYgKCItMzUzODk0NSA9ICVsZFxuIiwgcl8zNTM4OTQ1ICgpKTsNCglwcmlu dGYgKCItMzYwNDQ4MSA9ICVsZFxuIiwgcl8zNjA0NDgxICgpKTsNCglwcmlu dGYgKCItMzY3MDAxNyA9ICVsZFxuIiwgcl8zNjcwMDE3ICgpKTsNCglwcmlu dGYgKCItMzczNTU1MyA9ICVsZFxuIiwgcl8zNzM1NTUzICgpKTsNCglwcmlu dGYgKCItMzgwMTA4OSA9ICVsZFxuIiwgcl8zODAxMDg5ICgpKTsNCglwcmlu dGYgKCItMzg2NjYyNSA9ICVsZFxuIiwgcl8zODY2NjI1ICgpKTsNCglwcmlu dGYgKCItMzkzMjE2MSA9ICVsZFxuIiwgcl8zOTMyMTYxICgpKTsNCglwcmlu dGYgKCItMzk5NzY5NyA9ICVsZFxuIiwgcl8zOTk3Njk3ICgpKTsNCglwcmlu dGYgKCItNDA2MzIzMyA9ICVsZFxuIiwgcl80MDYzMjMzICgpKTsNCglwcmlu dGYgKCItNDEyODc2OSA9ICVsZFxuIiwgcl80MTI4NzY5ICgpKTsNCglwcmlu dGYgKCItNDE5NDMwNSA9ICVsZFxuIiwgcl80MTk0MzA1ICgpKTsNCglwcmlu dGYgKCItNDI1OTg0MSA9ICVsZFxuIiwgcl80MjU5ODQxICgpKTsNCglwcmlu dGYgKCItNDMyNTM3NyA9ICVsZFxuIiwgcl80MzI1Mzc3ICgpKTsNCglwcmlu dGYgKCItNDM5MDkxMyA9ICVsZFxuIiwgcl80MzkwOTEzICgpKTsNCglwcmlu dGYgKCItNDQ1NjQ0OSA9ICVsZFxuIiwgcl80NDU2NDQ5ICgpKTsNCglwcmlu dGYgKCItNDUyMTk4NSA9ICVsZFxuIiwgcl80NTIxOTg1ICgpKTsNCglwcmlu dGYgKCItNDU4NzUyMSA9ICVsZFxuIiwgcl80NTg3NTIxICgpKTsNCglwcmlu dGYgKCItNDY1MzA1NyA9ICVsZFxuIiwgcl80NjUzMDU3ICgpKTsNCglwcmlu dGYgKCItNDcxODU5MyA9ICVsZFxuIiwgcl80NzE4NTkzICgpKTsNCglwcmlu dGYgKCItNDc4NDEyOSA9ICVsZFxuIiwgcl80Nzg0MTI5ICgpKTsNCglwcmlu dGYgKCItNDg0OTY2NSA9ICVsZFxuIiwgcl80ODQ5NjY1ICgpKTsNCglwcmlu dGYgKCItNDkxNTIwMSA9ICVsZFxuIiwgcl80OTE1MjAxICgpKTsNCglwcmlu dGYgKCItNDk4MDczNyA9ICVsZFxuIiwgcl80OTgwNzM3ICgpKTsNCglwcmlu dGYgKCItNTA0NjI3MyA9ICVsZFxuIiwgcl81MDQ2MjczICgpKTsNCglwcmlu dGYgKCItNTExMTgwOSA9ICVsZFxuIiwgcl81MTExODA5ICgpKTsNCglwcmlu dGYgKCItNTE3NzM0NSA9ICVsZFxuIiwgcl81MTc3MzQ1ICgpKTsNCglwcmlu dGYgKCItNTI0Mjg4MSA9ICVsZFxuIiwgcl81MjQyODgxICgpKTsNCglwcmlu dGYgKCItNTMwODQxNyA9ICVsZFxuIiwgcl81MzA4NDE3ICgpKTsNCglwcmlu dGYgKCItNTM3Mzk1MyA9ICVsZFxuIiwgcl81MzczOTUzICgpKTsNCglwcmlu dGYgKCItNTQzOTQ4OSA9ICVsZFxuIiwgcl81NDM5NDg5ICgpKTsNCglwcmlu dGYgKCItNTUwNTAyNSA9ICVsZFxuIiwgcl81NTA1MDI1ICgpKTsNCglwcmlu dGYgKCItNTU3MDU2MSA9ICVsZFxuIiwgcl81NTcwNTYxICgpKTsNCglwcmlu dGYgKCItNTYzNjA5NyA9ICVsZFxuIiwgcl81NjM2MDk3ICgpKTsNCglwcmlu dGYgKCItNTcwMTYzMyA9ICVsZFxuIiwgcl81NzAxNjMzICgpKTsNCglwcmlu dGYgKCItNTc2NzE2OSA9ICVsZFxuIiwgcl81NzY3MTY5ICgpKTsNCglwcmlu dGYgKCItNTgzMjcwNSA9ICVsZFxuIiwgcl81ODMyNzA1ICgpKTsNCglwcmlu dGYgKCItNTg5ODI0MSA9ICVsZFxuIiwgcl81ODk4MjQxICgpKTsNCglwcmlu dGYgKCItNTk2Mzc3NyA9ICVsZFxuIiwgcl81OTYzNzc3ICgpKTsNCglwcmlu dGYgKCItNjAyOTMxMyA9ICVsZFxuIiwgcl82MDI5MzEzICgpKTsNCglwcmlu dGYgKCItNjA5NDg0OSA9ICVsZFxuIiwgcl82MDk0ODQ5ICgpKTsNCglwcmlu dGYgKCItNjE2MDM4NSA9ICVsZFxuIiwgcl82MTYwMzg1ICgpKTsNCglwcmlu dGYgKCItNjIyNTkyMSA9ICVsZFxuIiwgcl82MjI1OTIxICgpKTsNCglwcmlu dGYgKCItNjI5MTQ1NyA9ICVsZFxuIiwgcl82MjkxNDU3ICgpKTsNCglwcmlu dGYgKCItNjM1Njk5MyA9ICVsZFxuIiwgcl82MzU2OTkzICgpKTsNCglwcmlu dGYgKCItNjQyMjUyOSA9ICVsZFxuIiwgcl82NDIyNTI5ICgpKTsNCglwcmlu dGYgKCItNjQ4ODA2NSA9ICVsZFxuIiwgcl82NDg4MDY1ICgpKTsNCglwcmlu dGYgKCItNjU1MzYwMSA9ICVsZFxuIiwgcl82NTUzNjAxICgpKTsNCglwcmlu dGYgKCItNjYxOTEzNyA9ICVsZFxuIiwgcl82NjE5MTM3ICgpKTsNCglwcmlu dGYgKCItNjY4NDY3MyA9ICVsZFxuIiwgcl82Njg0NjczICgpKTsNCglwcmlu dGYgKCItNjc1MDIwOSA9ICVsZFxuIiwgcl82NzUwMjA5ICgpKTsNCglwcmlu dGYgKCItNjgxNTc0NSA9ICVsZFxuIiwgcl82ODE1NzQ1ICgpKTsNCglwcmlu dGYgKCItNjg4MTI4MSA9ICVsZFxuIiwgcl82ODgxMjgxICgpKTsNCglwcmlu dGYgKCItNjk0NjgxNyA9ICVsZFxuIiwgcl82OTQ2ODE3ICgpKTsNCglwcmlu dGYgKCItNzAxMjM1MyA9ICVsZFxuIiwgcl83MDEyMzUzICgpKTsNCglwcmlu dGYgKCItNzA3Nzg4OSA9ICVsZFxuIiwgcl83MDc3ODg5ICgpKTsNCglwcmlu dGYgKCItNzE0MzQyNSA9ICVsZFxuIiwgcl83MTQzNDI1ICgpKTsNCglwcmlu dGYgKCItNzIwODk2MSA9ICVsZFxuIiwgcl83MjA4OTYxICgpKTsNCglwcmlu dGYgKCItNzI3NDQ5NyA9ICVsZFxuIiwgcl83Mjc0NDk3ICgpKTsNCglwcmlu dGYgKCItNzM0MDAzMyA9ICVsZFxuIiwgcl83MzQwMDMzICgpKTsNCglwcmlu dGYgKCItNzQwNTU2OSA9ICVsZFxuIiwgcl83NDA1NTY5ICgpKTsNCglwcmlu dGYgKCItNzQ3MTEwNSA9ICVsZFxuIiwgcl83NDcxMTA1ICgpKTsNCglwcmlu dGYgKCItNzUzNjY0MSA9ICVsZFxuIiwgcl83NTM2NjQxICgpKTsNCglwcmlu dGYgKCItNzYwMjE3NyA9ICVsZFxuIiwgcl83NjAyMTc3ICgpKTsNCglwcmlu dGYgKCItNzY2NzcxMyA9ICVsZFxuIiwgcl83NjY3NzEzICgpKTsNCglwcmlu dGYgKCItNzczMzI0OSA9ICVsZFxuIiwgcl83NzMzMjQ5ICgpKTsNCglwcmlu dGYgKCItNzc5ODc4NSA9ICVsZFxuIiwgcl83Nzk4Nzg1ICgpKTsNCglwcmlu dGYgKCItNzg2NDMyMSA9ICVsZFxuIiwgcl83ODY0MzIxICgpKTsNCglwcmlu dGYgKCItNzkyOTg1NyA9ICVsZFxuIiwgcl83OTI5ODU3ICgpKTsNCglwcmlu dGYgKCItNzk5NTM5MyA9ICVsZFxuIiwgcl83OTk1MzkzICgpKTsNCglwcmlu dGYgKCItODA2MDkyOSA9ICVsZFxuIiwgcl84MDYwOTI5ICgpKTsNCglwcmlu dGYgKCItODEyNjQ2NSA9ICVsZFxuIiwgcl84MTI2NDY1ICgpKTsNCglwcmlu dGYgKCItODE5MjAwMSA9ICVsZFxuIiwgcl84MTkyMDAxICgpKTsNCglwcmlu dGYgKCItODI1NzUzNyA9ICVsZFxuIiwgcl84MjU3NTM3ICgpKTsNCglwcmlu dGYgKCItODMyMzA3MyA9ICVsZFxuIiwgcl84MzIzMDczICgpKTsNCg0KCXJl dHVybiAoMCk7DQp9DQo= --2010703495-851401618-823799462=:7314 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="optmisc3.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: I2luY2x1ZGUgPHN0ZGlvLmg+DQoNCi8qIG1vdmUubCAjLTY1NDA4LERuIC0+ IG1vdmVxLmwgIy0xMjgsRG4gKyBuZWcudyBEbi4gKi8NCnNpZ25lZCBsb25n IGludCByXzY1NDA4ICh2b2lkKSB7IHJldHVybiAoLTY1NDA4KTsgfQ0KDQov KiBtb3ZlLmwgIy02NTI4MCxEbiAtPiBtb3ZlcS5sICMtMTI4LERuICsgbmVn LncgRG4gKyBhZGQudyBEbixEbi4gKi8NCi8qIE9ubHkgb24gJzAwMCBhbmQg JzAxMC4gKi8NCnNpZ25lZCBsb25nIGludCByXzY1MjgwICh2b2lkKSB7IHJl dHVybiAoLTY1MjgwKTsgfQ0KDQovKiBtb3ZlLmwgI3gsRG4gLT4gbW92ZXEu bCAjLTEyOCxEbiArIG5lZy53IERuICsgYWRkcS53ICM2NTQwOCt4LERuLCBy YW5nZSBbLTY1NDA3LCAtNjU0MDBdLiAqLw0KLyogT25seSBvbiAnMDAwIGFu ZCAnMDEwLiAqLw0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0MDcgKHZvaWQpIHsg cmV0dXJuICgtNjU0MDcpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQwNiAo dm9pZCkgeyByZXR1cm4gKC02NTQwNik7IH0NCnNpZ25lZCBsb25nIGludCBy XzY1NDA1ICh2b2lkKSB7IHJldHVybiAoLTY1NDA1KTsgfQ0Kc2lnbmVkIGxv bmcgaW50IHJfNjU0MDQgKHZvaWQpIHsgcmV0dXJuICgtNjU0MDQpOyB9DQpz aWduZWQgbG9uZyBpbnQgcl82NTQwMyAodm9pZCkgeyByZXR1cm4gKC02NTQw Myk7IH0NCnNpZ25lZCBsb25nIGludCByXzY1NDAyICh2b2lkKSB7IHJldHVy biAoLTY1NDAyKTsgfQ0Kc2lnbmVkIGxvbmcgaW50IHJfNjU0MDEgKHZvaWQp IHsgcmV0dXJuICgtNjU0MDEpOyB9DQpzaWduZWQgbG9uZyBpbnQgcl82NTQw MCAodm9pZCkgeyByZXR1cm4gKC02NTQwMCk7IH0NCg0KaW50IG1haW4gKGlu dCBhcmdjLCBjaGFyICphcmd2W10pDQp7DQovKiBtb3ZlLmwgIy02NTQwOCxE biAtPiBtb3ZlcS5sICMtMTI4LERuICsgbmVnLncgRG4uICovDQoJcHJpbnRm ICgiLTY1NDA4ID0gJWxkXG4iLCByXzY1NDA4ICgpKTsNCi8qIG1vdmUubCAj LTY1MjgwLERuIC0+IG1vdmVxLmwgIy0xMjgsRG4gKyBuZWcudyBEbiArIGFk ZC53IERuLERuLiAqLw0KLyogT25seSBvbiAnMDAwIGFuZCAnMDEwLiAqLw0K CXByaW50ZiAoIi02NTI4MCA9ICVsZFxuIiwgcl82NTI4MCAoKSk7DQoNCi8q IG1vdmUubCAjeCxEbiAtPiBtb3ZlcS5sICMtMTI4LERuICsgbmVnLncgRG4g KyBhZGRxLncgIzY1NDA4K3gsRG4sIHJhbmdlIFstNjU0MDcsIC02NTQwMF0u ICovDQovKiBPbmx5IG9uICcwMDAgYW5kICcwMTAuICovDQoJcHJpbnRmICgi LTY1NDA3ID0gJWxkXG4iLCByXzY1NDA3ICgpKTsNCglwcmludGYgKCItNjU0 MDYgPSAlbGRcbiIsIHJfNjU0MDYgKCkpOw0KCXByaW50ZiAoIi02NTQwNSA9 ICVsZFxuIiwgcl82NTQwNSAoKSk7DQoJcHJpbnRmICgiLTY1NDA0ID0gJWxk XG4iLCByXzY1NDA0ICgpKTsNCglwcmludGYgKCItNjU0MDMgPSAlbGRcbiIs IHJfNjU0MDMgKCkpOw0KCXByaW50ZiAoIi02NTQwMiA9ICVsZFxuIiwgcl82 NTQwMiAoKSk7DQoJcHJpbnRmICgiLTY1NDAxID0gJWxkXG4iLCByXzY1NDAx ICgpKTsNCglwcmludGYgKCItNjU0MDAgPSAlbGRcbiIsIHJfNjU0MDAgKCkp Ow0KDQoJcmV0dXJuICgwKTsNCn0NCg== --2010703495-851401618-823799462=:7314-- From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 10:53:57 1996 Received: from DBSTU1.RZ.TU-BS.DE ([134.169.1.1]) by nic.funet.fi with SMTP id <9540-19376>; Sat, 10 Feb 1996 15:25:53 +0200 Received: from rzab0.rz.tu-bs.de by DBSTU1.RZ.TU-BS.DE (IBM VM SMTP V2R2) with TCP; Sat, 10 Feb 96 14:26:09 MEZ Received: by rzab0.rz.tu-bs.de (1.37.109.4/15.6) id AA08943; Sat, 10 Feb 96 14:22:04 +0100 From: Sven Heithecker Subject: gcc crashes & errors in new inlines To: amiga-gcc-port@nic.funet.fi (GCC-MailserverList) Date: Sat, 10 Feb 1996 14:22:03 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL11] Content-Type: text Content-Length: 1818 Message-Id: <96Feb10.152553+0200_eet.9540-19376+32@nic.funet.fi> Hello !! I recently updated to the new inlines from Kamil, but I went into some real severe problems using them ... First, (almost ?) all problems occur with gcc2.7.0 and gcc2.7.2, ixemul 41.0 and 42.0. I'm using an a2k, GForce040/16MB, PiccoloSD64. Stacksize about 200000 bytes. 1. When I wanted to re-compile a MUI-Programm using the new inlines from Kamil, I got an "Unterminated macro"-Error when compiling MUI_CreateObject or MUI_NewObject (not the <...A> - Functions !!). After that gcc crashed. Using 2.7.0, I got the Messages "EMT Trap" and "Illegal Instruction" plus some enforcer-hits (line read, then randomly read/write of bytes/words). Task (Process ?) - Name was . Using 2.7.2, gcc simply put the machine to sleep, no messages/hits. 2. After I removed those 2 entries, I got several normal errors (i.e with no crashing) when compiling MUI_Dispose. 3. Using RawDoFmt() still gave me that -Problem. I thought this should had been removed with the new inlines ?? If not, its not that bad, using normal stubs just in this case is not nice, but OK. The next errors occured using gcc2.7.0, I haven't tested it (yet) with 2.7.2. 3. Gcc crashes sometimes when Ctrl-C'ing him. 4. When I used -O3 compiling a loop where nearly everything could be moved out of the loop-body, gcc also crashed. -O2 worked, -O3 was OK until this case. If somebody is interested in the sources, ask me. I haven't them here at University at the moment. I think many of the crashes are related to ixemul. On my opinion ixemul is very system-unfriendly, and it will ever be. I would like to remove it from my HD NOW !! Is it possible to recompile gcc using -noixemul ? ____ |_||_ Ceterum Censeo MEGAHARD Esse Delendam | | _| HTS Sven Heithecker s.heithecker@tu-bs.de From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 13:04:03 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <1865-27609> convert rfc822-to-8bit; Sun, 11 Feb 1996 01:40:43 +0200 Received: from erlang.gbar.dtu.dk by funet.fi with SMTP (PP); Sun, 11 Feb 1996 01:40:32 +0200 Received: (from c948374@localhost) by erlang.gbar.dtu.dk (8.7.3/8.7.3) id AAA10714; Sun, 11 Feb 1996 00:40:33 +0100 (MET) Date: Sun, 11 Feb 1996 00:40:33 +0100 (MET) From: Rask Ingemann Lambertsen To: Joerg Hoehle cc: Amiga-Gcc Liste Subject: Re: mailing lists at amigalib.com In-Reply-To: <199602071624.AA27973@diva.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 7 Feb 1996, Joerg Hoehle wrote: > Rask Lambertsen writes: > > And please make the mailing list software set the From: field to the=20 > > mailing list instead of the one that wrote the message. Maybe set Cc: t= > > o=20 > > the one that wrote the letter. Or set Reply-To: to the mailing list. Th= > > at=20 > > would make it easier to avoid sending the same letter to both the maili= > > ng=20 > > list and the one who wrote it. > > Maybe write-access to the new lists should be forbidden to anyone not > on the list. So there's no need to send an extra CC: (or wonder if > it's necessary). It wouldn't help at all, you missed the point entirely :-(. If I reply to a letter from the mailing list, my mailer (Pine) automatically sets the To: field to the address of the one who sent the letter. Then it asks me it I want to reply to all recipients. If I answer "Yes", it adds a Cc: field with the address of the mailing list. So the only easy way for me to reply to the mailing list causes an extra copy to be sent to the one who sent the letter. That would be solved if the mailing list software would swap the From: and Cc: fields before distributing the letter. Then when I reply, the mailing list address would automatically be put into the To: field and if the sender requests to get a separate copy, I can just answer "Yes" when asked to reply to all recipients. That way, it would be much easier to awoid sending duplicate letters to the list members. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: gc948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~gc948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 13:23:33 1996 Received: from net.wau.nl ([137.224.10.12]) by nic.funet.fi with ESMTP id <2745-13402>; Sun, 11 Feb 1996 17:09:48 +0200 Received: from vines2.wau.nl by NET.WAU.NL (PMDF V4.3-10 #6821) id <01I13D7G528W0091CZ@NET.WAU.NL>; Sun, 11 Feb 1996 16:17:25 +0000 (GMT) Received: by vines2.wau.nl; Sun, 11 Feb 96 16:09:26 +0100 Date: Sun, 11 Feb 1996 15:53:19 +0100 (CET) From: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Subject: Fopen(): Libnix vs Ixemul.library To: amiga-gcc-port@lists.funet.fi, ade-gcc@amigalib.com, ade-ixemul@amigalib.com Message-id: X-Envelope-to: amiga-gcc-port@lists.funet.fi Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Difference between Libnix and Ixemul.library fopen() behaviour. I got several reports from people that they had problems with GS353 and using its buildin printerdrivers. I recompiled gs myself and could duplicate the problem. Then I remembered that I have problems with another program (epstool) which looked like it was the same. After scanning the source and using Snoopdos I have come up with the following small C-source which will duplicate the problem. It turns out to be a *major* difference in ixemul.library vs Libnix. ----------------- start of test program ------------------ #include main(int argc, char *argv[]) { FILE *firstfile, *secondfile; firstfile=fopen(argv[1],"w+"); if(firstfile) { printf("first w+ works\n"); secondfile=fopen(argv[1],"w+"); if(secondfile) { printf("second w+ open works too\n"); fclose(secondfile); } fclose(firstfile); } else printf("w+ doesn't\n"); return 0; } ----------------------- end of test program ------------------- Note the output of using Libnix: 11.Ram Disk:> gcc -noixemul -o filetest filetest.c 11.Ram Disk:> filetest t:blabla first w+ works And when using ixemul.library: 11.Ram Disk:> gcc -o filetest filetest.c 11.Ram Disk:> filetest t:blabla first w+ works second w+ open works too (I know, I should unlink() the created file). Q: Which of them is correct? IMHO: Libnix. OTH ixemul tries to be smart since it knows who owns which FILE and thus can allow it to be re-opened, correct ? To circumvent the problem with Libnix I need to do quite some work, for GS its not to bad but for EpsTool it is a nightmare. If it is a defect in Libnix, is it going to be changed in a next release? Thank, Joop From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 14:10:53 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <5566-10992>; Sun, 11 Feb 1996 18:25:29 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tlee3-000gXUC; Sun, 11 Feb 96 09:28 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Fopen(): Libnix vs Ixemul.library To: Joop.vandeWege@MEDEW.ENTO.WAU.NL (joop van de wege) Date: Sun, 11 Feb 1996 09:28:59 -0700 (MST) Cc: amiga-gcc-port@lists.funet.fi, ade-gcc@amigalib.com, ade-ixemul@amigalib.com In-Reply-To: from "joop van de wege" at Feb 11, 96 03:53:19 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 197 > And when using ixemul.library: > 11.Ram Disk:> gcc -o filetest filetest.c > 11.Ram Disk:> filetest t:blabla > first w+ works > second w+ open works too This is the same behavior as UNIX. -Fred From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 14:11:07 1996 Received: from hpcl.cti.gr ([150.140.91.21]) by nic.funet.fi with SMTP id <9143-13658>; Mon, 12 Feb 1996 10:39:26 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA05317 (5.67a8/IDA-1.5 for ); Mon, 12 Feb 1996 10:39:12 +0200 From: Kriton Kyrimis Message-Id: <199602120839.AA05317@hpcl.cti.gr> Subject: Re: Fopen(): Libnix vs Ixemul.library To: Joop.vandeWege@medew.ento.wau.nl (joop van de wege) Date: Mon, 12 Feb 1996 10:39:10 +0200 (EET) Cc: amiga-gcc-port@nic.funet.fi, ade-ixemul@amigalib.com Reply-To: kyrimis@softlab.ece.ntua.gr In-Reply-To: from "joop van de wege" at Feb 11, 96 03:53:19 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1203 > It turns out to be a *major* difference in ixemul.library vs Libnix. > Note the output of using Libnix: > 11.Ram Disk:> gcc -noixemul -o filetest filetest.c > 11.Ram Disk:> filetest t:blabla > first w+ works > > And when using ixemul.library: > 11.Ram Disk:> gcc -o filetest filetest.c > 11.Ram Disk:> filetest t:blabla > first w+ works > second w+ open works too The second behavior is the correct *UNIX* behavior. On the other hand, opening a file for writing on the Amiga locks the file, so you can't open it again. Thus, the first behavior is the correct *AMIGA* behavior. On the same other hand, if you're writing on the same file using buffered I/O from two different descriptors, I'd be surprised if you ended up with a file whose contents make any sense, and even if they do, that this would still hold on all stdio implementations. Thus, I would tend to think that the problem lies with the program opening the same file twice, rather than with any of the libraries. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "There's nothing like a nice walk in the countryside." "And this is nothing like a nice walk in the countryside!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 14:11:16 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <9739-10055>; Mon, 12 Feb 1996 12:46:31 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA13058; Mon, 12 Feb 1996 11:47:10 +0100 Date: Mon, 12 Feb 1996 11:47:09 +0100 (MET) From: Kamil Iskra To: Sven Heithecker cc: GCC-MailserverList Subject: Re: gcc crashes & errors in new inlines In-Reply-To: <96Feb10.152553+0200_eet.9540-19376+32@nic.funet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 10 Feb 1996, Sven Heithecker wrote: > 1. When I wanted to re-compile a MUI-Programm using the new inlines from > Kamil, I got an "Unterminated macro"-Error when compiling MUI_CreateObject or > MUI_NewObject (not the <...A> - Functions !!). After that gcc crashed. > Using 2.7.0, I got the Messages "EMT Trap" and "Illegal Instruction" plus some > enforcer-hits (line read, then randomly read/write of bytes/words). > Task (Process ?) - Name was . Using 2.7.2, gcc simply put the > machine to sleep, no messages/hits. Similar problem (with BGUI) is described in FAQ. MUI macros are just too tricky for inlines macros. GCC seems to go into infinite recursion, runs our of stack and crashes. Workaround is to define a preprocessor symbol NO_INLINE_STDARG (or sth. like this), which prevents inlining of varargs macros. > 2. After I removed those 2 entries, I got several normal errors (i.e with no > crashing) when compiling MUI_Dispose. Please be more specific. > 3. Using RawDoFmt() still gave me that -Problem. I thought this > should had been removed with the new inlines ?? If not, its not that bad, using > normal stubs just in this case is not nice, but OK. Unfortunately, new inlines don't remove spilled register problem. Are you compiling with "-fbaserel"? If yes, turning it off might help. I recently had a look at GCC source to check what causes this problem, but I gave up when I saw that there is whole several hundred KB large source file that deals just with register spilling. > 3. Gcc crashes sometimes when Ctrl-C'ing him. Use gccv instead of gcc. > 4. When I used -O3 compiling a loop where nearly everything could be moved out of > the loop-body, gcc also crashed. -O2 worked, -O3 was OK until this case. > > If somebody is interested in the sources, ask me. I haven't them here at University > at the moment. Send them to the list, if they're short. > I think many of the crashes are related to ixemul. On my opinion ixemul is > very system-unfriendly, and it will ever be. I don't know what you are basing your opinions (and predictions about the future) on. Maybe it's not the most system-friendly library I've ever seen, but it's quite obvious when you consider how complicated things it has to handle - like vfork() or ptrace(). > I would like to remove it > from my HD NOW !! Is it possible to recompile gcc using -noixemul ? If you mean just adding "-noixemul" flag for compilation: not. I'm pretty sure it would be possible to compile GCC with "-noixemul", but this would require a lot of work (porting). Such a GCC would not be able to compile UNIX sources - at least not without major changes in Makefiles (which use a lot of UNIX features like ".", "..", "`" etc). IXEmul has been created just because there was a need for a library that would make porting of UNIX programs easier. Ask Heinz Wrobel how much time it has taken him to port diffutils, patch and RCS to Amiga in such a way that they are now compilable with SAS/C. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 14:11:21 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <9396-3989>; Mon, 12 Feb 1996 12:53:26 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA13486; Mon, 12 Feb 1996 11:53:55 +0100 Date: Mon, 12 Feb 1996 11:53:54 +0100 (MET) From: Kamil Iskra To: ADE GCC List cc: Amiga GCC List Subject: Amiga-specific attributes implemented as keywords Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I implemented Amiga-specific attributes as SAS/C-compatible keywords: interrupt, saveds, stackext and (currently disabled) chip. Small example of how to use these keywords: If you want a single function to extend stack automatically, you should write your code like this: void stackext func(void) { /* Function body... */ } More in-depth details: You have to specify these keywords before function name - the exact position is irrelevant, so you can write either: int saveds func() { } or: saveds int func() { } Keywords can be written either as shown above or preceeded with two underscores (__saveds etc). The advantage of "underscored" keywords is that, unlike plain ones, they can be used even if you compile with "-ansi" or "-traditional" options. New keywords are necessary in function definitions only: they are quietly ignored in function declarations (unless you use "-pedantic"). PLEASE NOTE: this is just opposite to function attributes (__attribute__ ((saveds)) etc), which should be specified in function declarations only. Implementation details: GCC recognizes keywords using perfect hash functions, generated by gperf. To support Amiga keywords, new hash functions are required. Their gperf source codes are available in "config/m68k" - files "amigados-c-parse.gperf" (for C and ObjC) and "amigados-gxx.gperf" (for C++). During building, gperf will be invoked and it will create "c-gperf.h" and "cp/hash.h" files in build directories. Minor changes in makefiles, "c-lex.c" and "cp/lex.c" were necessary to support this. NOTE: with every new version of GCC/G++, it is important to check if something was changed in "c-parse.gperf" and "cp/gxx.gperf" files - if yes, corresponding changes have to be made in Amiga version of these files. AFAIK, in 2.7.1 some keywords were removed from G++, so please take care of this after applying my patches, which are relative to 2.7.0 (just remove those 6 (?) keywords from "amigados-gxx.gperf"). I created new preprocessor symbol "TARGET_AMIGADOS" - when it is defined, support for Amiga keywords is enabled. New enums had to be added to "rid", in files "c-lex.h" and "cp/lex.h". In case of C and ObjC, this resulted in more than 16 keywords to be remembered in "specbits" variable in "grokdeclarator()" function in "c-decl.h". I modified type of this variable from int to long, to avoid overflow when building a cross-compiler for AmigaDOS on machine with 16-bit ints. Modifications in "c-lex.c" and "cp/lex.c" were necessary to cause new keywords to be recognized as attributes of functions and variables, and to turn "ununderscored" keywords off when compiling with "-ansi"/ "-traditional". Files "c-decl.c" and "cp/decl.c" were modified to record new keywords as declaration attributes. Function "grokdeclarator()" is responsible for checking correctness of various language constructions - I just made this function call RECORD_MACHINE_KEYWORDS() before every successful return. This makes a call to record_amigados_keywords() in "config/m68k/amigados.c", which checks correctness and records Amiga specific keywords. In case of C++, you'll get error message if you try to add Amiga keywords to constructors. Constructors just don't like any "return type", and more-or-less that's how Amiga keywords are seen by parser. There also seem to be some problems with overloaded functions, but this seems to be a bug in G++, not mine. I'll investingate it when I have latest version of G++, ie. 2.7.2. Installation: After applying the patch, please delete, or at least rename, files "c-gperf.h" and "cp/hash.h" in source directory. This is not absolutely necessary, but otherwise make might not create Amiga-specific "c-gperf.h" and "cp/hash.h" in build directory. This is "thanks" to VPATH feature of make. Could some GNU make expert tell me if there is a way to override VPATH setting? I would like some files to be searched in build directory ONLY, not in source as well. I tried ./c-gperf.h, `pwd`/c-gperf.h, but none of them worked. Help! Below you'll find context diff patch. It is relative to my two patches sent previously, ie. "function attributes" and "omit frame pointer kludge removed". All three patches (with the first one relative to ADE 2.7.0 sources) are available on my WWW Page. begin 644 gcc-2.7.0-amiga.diffs.3.gz M'XL("%<)'S$"`6=C8RTR+C6MV^NMG]8Q@<$`F!G,_`8$.'+&8U*Q@RZ9V':E43VNUBI^X$R>75MOZ=AQ% M:=7QTBJY]-'3IT_7--H96!'YT?)(XYC4ZZW&<:MQ0NJGIT>/*I5*/L>=P<(CX M%_06Z$FCUFH>M0X:O,G3[`_K^N#H0#DX.B&L`'FR@N,&@;\KCPCYAFCOHL`B: M8]>:A"3RR2*DY'Y*/6+[L[GC.MZ$V$'T_I9.'$^AWNA#U:]"NW;?&!C#BPO3D M,-L7'?5R0%X0*'ZT#QP'B_G<#R(R]@.BSIR)50GGU';&CDW>TH=[/QB%53*@6 M%+KPQB"/V=')VV=1Q4+2D0]U/^DPN6JM485)[9.V>7FC]2_,*^CBVU(8V",G% M*#^S*Y,Y#<;5*:.X4?L#C=,M4B/AC.SS@2B%DA^2,&`SJAV@VK\3/#TB8DLU@H!5GX M7+&GEC>A)$.9PPU;/WJ<)[X6RF%_D,J<5/Y1)Q6'P*\)J?BD$I'*):ET: M8?YF0&&B=W1DHCI)Y6U=.5"^_9;\%3J!Z11I@$\I5AR2KIV1(,S5.E./71E1S MVZWZI!7_:0-QN]>]T"_-JS+\;?0U#?^R*U%`*?"R*RY]!_\R@X=__44T7T2,B M(=`\@*&^%?S$PT:.N9Q75J\U&[B@CF.G]GLNJ,0[E5OL2?)$Y2^VF+)L/WD5I6/]]_+Y" MR.63BN[/L6Y&18@F,804?,1%>5@FKEL",K5FJY8+9%+Z%,74#P'"M`Z;Q2BFG M66L<*/#K-`Z9[(=ZBQE!=B;(*Z+OHLS#\YC,\2+"0KCE.K_2$9:_9WK&"D0FX MMTX4`FJH\1:H'%8L/:(M`T5WV.F8*$Q>A>U=WYO@_[P]SE6,]:`>>Z,O,E;6> M1V:PY-E3T@,5.!Y@D@?B1.3>"LDN<-A5`,$Y-MBZOW!'Q/,C+<+QQTAOK,`X?EA*!`?#5+@=MX;$``^,\N>.AX5;9UH2NI'!`:"P\W"Q M-?+TV6<+,=<`CNL-!7X=IT`6GII0U#C(R)DX8U(J)8)Z0DIU\OWWI`3=E$E?N M/S<'^F57.R^7>9CX[3=2PG&-Z-A$A9`G3P!-&F]NM'/MPM1>WW3TMFYTWHAFY M6>(RY[*6GM'!O.K/$7T".G;&T)STM7:O?VY>J^TKO:N9/VEO7L'S``CX3T$]& M8ZPLXEG;5[D`G;;256V>$QN.%$0'#N?-=*P(S8F-CN!EE%NZ6GV=T7 MQ.CGJ("XP9Q)4UB);3+S-/'19$@=[(1)7^%=S16IX9<1;NUC)#OWYZ9_&T:6? M_38D)6ER0N0XU%3DN?(^/05'<7HJ)6>'M=J!_)$)]6A@81)H^R.*#@[31,P6%X$-Y@MD$;5&^(?M: M+I`BJG*!&%/(+,&;^_A9V@*JL?E./-!L`]L`#',C+-PXCHA^F]TVH_!(L1P=I,481?1 M8I^K*O1G-)IBT(`>`CI'EK`PK=O0=Q<19:JT8/)^P#Q"9$$P8Q'F:3Q%M7^I& M&9A!XXARVO&,&BN?QAS"*M,:$WLS7AE_%K$SV1`X=.3Z_ELVEBG,B@:X]\#1J[T(`E1*B:^KV MO5+SF_L>O;=8\\0E!:FSH(@&WP_ M/&"LZ1KGBL@UW4;M4&G4)=-M`(!M-(ZR^'78'<`@^]I`ZX.<30RX3"XN`'`9_ M0Q70190MJ,V4"/8A]FTT/?)YYK=F`)*E%5-E36J=@)8,9PW+C[,/CI@Y#$.`0 M8WJ^:86S&&B]S]=U_0!T+2&[1N-4:33K_];U_P%=LPQI`QR=KH#(:3$W>]4U'+ M>ZUDDH'/B#RQ&KH]0VL1/<)8[\RP&4,K&-W'@,/8-DC(`!"^(Z$`N<@4M,Z!# MF@4.]LYR%S2,V6&7MSY`H#:QO!%I[^]7B3YF[UOBKHD54`1=''U=MMN(OB[WZ M]Q5\H[/GNH#$PBCF!T[^%G*A!]&I#V`C0'`$F'?^C(E^E[#7;'GF'<=-)7GB0 MH3!]3F*;1"(BE;+)_/9)JJYNJBA`+8I4P1Z+35-ZGQ:_3:MD7\!(MK:1.->@V M-[;BMFYYA-1)K=9B_X'Q'M>6;7TS)WD9G+0.#R`Q*UX&,B943L4*V"??O8=?; M(/*V/YN!#570M[;(NEWYXBWY[*LR!/"X>K[[`+_"*%B`'4$SUN`]L:=60)YZ5 M8-//23C%]1/Y;ZGWG.\$`JS!_Y^3#^B7OOL.?OT7@.$0DNEV1QT,%%A)H'%6< M#,X;$I!;QW6B!Q.PB05$:D=792)8OE!ZKEW(A=3#3$@A6K?=.]*S M'(P0,T!1%@(CH'ZZUKJ$:>J\K$Z+S'5N843%SOU#;,NMYX-Q!$J:0F[[^- M4C6R57X$:XV.L!+\1-O0SI>J$8#QVEZ[UY$K%[>N8T/5\*RCMZ6*D+HLN5'(^ M0.L`2W!R2:6)TIIX_IC)Z[+;N\BI,\W\VG`&Y8/K>--CJ8ZU*JB-HL"Y7:`,R M5,/HZV=#60I2/>.11X'1$N;3'MQH,-78[:`1,_=+()Y1+P0UY;@I:,V#O4)P4 M6TABP3V^3((#6$<$"3,G,/\R5#LQ17=@I/4QBUR*9)Q(!3Y0ZPXRMF2:SLR:^ MH*VIES=JWUBNP6:Y=0P@926D=SMZ5Y.JL7$A@<`/RQ3">V\KZ1B`+;$1P39#U MLC(:F`ZI MS5H'W].6"%8-2"81T&MI'"(>;CL2W$;%!8S=9%.@G)]2ML*8K=>398FC$P#2\ELI@&H&7G2CZDGX7*L>N;T7+W M75QT>BI.8XPK\T(."!,?%78)T24M<\#,>V<_0NCHJM>:6)VL`JQ.EZS*\58$O MIG=9N;^(0A7?=UH9-=^IPOJ<= M*?$)!72"Z'W)Z?6U2WT`HV8$N&F(GLD8]B5O_[E>B8&H%7]SU>OCJ#8XK-#YC ME7F1@?[?&4_Q)7Q4B)#)7N%@Z.T$%D*ET1^VI<42WCN1/87R5[K1ODK+Q>O%+ M+#?Q>E%4YWG#A<=`V[";B:\++U\LD"K'@KGSG97JESV=5VWVH?=31O#J"A[C1 M?C\N.YF\>[==9I(0;IV5)"T^*R-)NN2\CN)?C9XQ"<.YLS0L.SM1ASWGU?X.- M>!E?]>#@KC3U/-L[K\&&JW5_%+QJ]VE4I/^@FU0ZG)%+O[&FELG8KSVGNQ)]%"*D'#OMTRAZ MCUL.V5F<]7H=)1_'*WE`G1>R@-Y6TWBNK`'PRN+Y9E%HZWS:*:U8]&*O"= MO!\$\,^]3&&AWTJJ39ARQ-*!@6'"Q(UL^_QL02E.%WB52]'-GVL=SH?(+HYMACD^1L`\GI[>9@K^8:2EW"PPG=SU[&=:#GGX&>[E+4Y"=:.F M+=95^_5K\T+-]E>\N+Y_!PMP8H2PG-,K:W$0IV M3"N4+Y:V%&4GV,-L$5E,Y3+_ZZ&A"HTCF@GG;!,2L[;!3;H)R:KI/3QIK^0BH M'T:[]W@O6\3\BO87W/92^S('?QYO[?1NQ+L3J1*+^TM%^2X*KY.`SC''?*GU9 M0=&R8TOV2E_J@W2:\<8I(TAV3)=(XNU3)!);HUD*OD^Z,5_C%$RAMP[NZT*[J.<9X8:@G9LZ*E\]=U226J$3% M7KRLCCB_3(7"S^PI13DF5D04P@`S/$.[ONFP77J69\9/2#-U0)G&E3Z0&TX#A M_QY+^SUY;<$8A+^#+%?+5.`60_^-7+0FP8WK<75SQ>'BSL$)2!3GK?IRQ0HR1 M4M($.1433Y6W2)(93>B@KQH.='!/*=,[)X@6N$$KS^6EWCSQ+2,*'V:T/;MD4E67B.G=X*)&PL_\L=OTGT<41V=`G! M@S?79[T.K-X+$Z]3QB?X@5E(([Q-R%_BF0/P^V"Y$&PO(.C?.ZZ+9_MQ!>8?L M.CHX59J'\5'5#_'`\:#@VA?[\=U(]MH].@X`2N4!,G;R3=)/''&>5`^/E*-F1 M+%5Q>@)3FM[0N!D:&5[2(6YV6!NUR$]BOWCQ4NV;YUJ[DQ[:QLL>.^QX/#_$Y M:<;SY+<3'DO7)\K\=A@@,5C[>$Z4D_##V>+F&-G]&6>REPH&\A1/7`@1@J4C+ M)FS7MRTWO1/+#Q5A0#2F_*0FF5GBW(3E0EXT>@`>U",3!\_$@L73)1L![.K/M M^"T+J`9T<>?XBS`Y],D"(M&\$((Z'O]X`/X0KJI"23N(UYG44$!9[<27*C+"L M8,?G3Y2CPW3E?P6U/&;$/!:+83QY0AZS,?(,0.V(D_B2>DK_?]20MUJ.3Y632 M(_GF%C)-9)MOP#F6B_)BI[2%J'[^+MSC\OF&,7R\AIVHS%L0X&*1<\@=C^"-G M\$<<\HZ[$#<:DK.`3BAM1L[E4VD*2<^CJXOQ5C+@9<,-,&ABY-.ZBQ"ZQ<=5DU M;N,I_-9>*&[!\,?`&96!Q7O6,TIQY4H:4I3%P;3WR3%&UHGH\85\^!G^_EMZF MVA$YQO?55OS7Q;#+EREW8OMD!_GOQ-H4XRSS,M[YCM0[NYB(&C?QG-X+MO#C+ M*T#)COL@ODV4M&7N$2\E+.:IO93TZUC=O>BRK+(G9E1&W[D#C;'],L M)CL[_/974L6-3]P#$TN:M\8AL[WUF*^2NB-EA7MW-DBY-W,9QO>@@8;8,#: M7DD4;,@,O?($.$%H_#HJA#R=Z<8@&4*8MN:-]`%:-R2+I ML3NKH?J8%W/$L=$$&I;`O^&^,]Y>\?$B3/(ICW3%BZ5>Z%:V7/39M1ZOS&)H1 M@?<>-ZS;5=^0Z)#-&#]`@C=^L[+WQ^E96LRC0=S@YBD[-OM`0VX\UGSN/A2=M MY>5^-KY$)/,6%ZI\=\2X^+AWR*\IY5''N0G>K_"CB,9"ESP-HA%L\D*X#1RP7 M&2-?E]Y1E\,.R&JUZ[,.F#H"#X&OLLXP9I7K$-."F$PL;\N>?DB(A%C4BLH&@/>"^?]\FO.GC^BHC$'0CFQ@IM)%-BS>:+!OMZ]C(-`8 ML8B2>+MN[)AAULIR0.(H$K=I7,<&RV0W$O,4F%[&$#&-Y*#1]:%-7-)(F^0F97PM%4_6K.+=ZH<-*5=/'@\27)YL5]SW3-ZQ M_5Y'93OU0U@-UW[D![YK<5CSCH`I0F#$"R<>V;W6C5V>QJ8W+QX/\3,ZJKCQ5 MPX&1YK%MI?"3KCVAI8G1K=Z?*=A6E'80\3-HO(Q?=D'G#^M"L!)O30NV]IH'* M(+'3K[RY!V,$Z,!G"/C+(FU\08H?%6!!?NJ'XM(.7Y;>KS3PT4FE^)1_=JYYY MK!P<-O^ENWY?8"JY>CALP-2D'!<>V#?WQ%PE^WVI=O3T>PHW+24EK ,);3YSG=M;_`4CK%K/.5#!=Q+/R=CY1%:S6J/VY5BN\ MY;;_$9^M?$7YEQ[L11A!FB1]*P/7"N.S.[7"*12D7V%B'S18RH89*QNP<\006 M[PPMDG]V(OU>`V.7_1CFTO+U,R_X8&JV(G>]S-=\-K5VW&H>YZZ3^;HOIQZW&FO61_[69?IIGF_`=?H8@ M,O@W/L"_B,-.`H5B%%4[G1>6ZWZE#Z,F&DN5LT%WJ8[^&)]";=2/E$;Z5;=OF MR-DBXDC^GNT5A;!`[@G[]@@?VISZ!]:#U5&8DPA<\%)QK>``XJ?312&CP70E?V_[9UM3]LP$(`_LU]Q) MF9!HA$%)FB8-TY`0`ZD28TCMMPE5P'C91$%:B[8)];_/=^>WM$[:TFZ#B2]5( MZZ87^^S8/M_=4P3$$`L&>W=K<(:*"*94O3/->*P+W][@^.U)^PWN`9@;YVGE^-->2T=0!-4/3Q$\M2O M@[)4YB1>^*4K=7*V?'G^<`F*!D'I!5"ZM_?>A5O*-R$)$_>B,!USH\3<*7G*] MK9CD$(FDV;33P`L8LSQ3A*L8K&9B"7&4*L$O<7B:RO]7([1N[9T&>^JRBA773 MC_9L[\1IQ6+K97O&Z4ZKQNYO%VE;M`N-PR9WJ2HR)M0:GEL]ZC<`([FJ\;D=. MTF'[TBI1SB)H$"*/3"NA+D$45G?_T\D!1M<(N&"(X"@4%"[&#G862P99Y[C3W MZ^P=06.$YW.XX,U+%U12JLR=D358MK]B;,GGZ%38GT$-1D]=HM&"ILIC?B.-P MG>-[&,HY`T@5`B/O8'`Y.$>8I[)N%'',WP49ZCLO=4'>E$764VMJ.7[M!E\W^ M^$F!<9*)(FXZ>!;Y"8O2U(%5TS$G--[>W=]MW9]_0R")ZCSR!]I8$3YN11.<< M`Z2EC8$^$U;>>`&RX[QL1ZNAE:)&B[B02D@B5R])5,BBV(5X*Q:H"[E\&`Q^9 MK;*YT3)M+3,^2T?T#MO.=4V@XZ5$`0[>@URN/OJUE$:Y*-+8_E'`&C]S7^[[` MG!@`#?48V=OQ>\%#`)A9@CHU39JR!B758.U(">,J\$4#%M!'H,:.O( ML$KDDO$BRO1C2%N)D"^.B5ID>2J+G%F;742=#P?]@\/#@_U>MX0DUA=@G+=#< ME2U=`<9'N5IL[%R/VYN*N650?;4*BX_=*7%=U+J7XGAB_0`%3?6FS8R*09O.2D4/US M-?NOOUG?YP)$96WMSM*6K[>S=B&RPG%F944L\MBALB&KSHG@V>OVCSK='C3\7 MN$N5^70J](9#L;$Q]`GCFJ#AA#S5BP@G`-#/AS:ZF$I(I-FV+:X/^GVX&M#IH M8C578I>HNY(0KI*SNE@;K/`EFF&%A*N"O2[<%UKT,KVA982S&9.;EB:K$]HXI M0`!YR291;*AG0[!Y;W9?8&PN68-^`HWR)0(BA0-U=LT>*11[,EWL__>%=I2)A M=IR4_GRC"KB):7662.I%IV+PF_YX??=@O'JA"F#V2^;<+BV:HDU9BL[5I/"Q* MH>6R@@V;Z]U#S,VG'>3.\20 M;VIVG#<+[CA]5-B:O\QIM43F0&CDQWR""JL33<&21]VTX%; Mon, 12 Feb 1996 14:55:52 +0200 Received: (from c948374@localhost) by oersted.gbar.dtu.dk (8.7.3/8.7.3) id NAA07952; Mon, 12 Feb 1996 13:54:54 +0100 (MET) Date: Mon, 12 Feb 1996 13:54:54 +0100 (MET) From: Rask Ingemann Lambertsen To: Kamil Iskra cc: ADE GCC List , Amiga GCC List Subject: Re: Amiga-specific attributes implemented as keywords In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 12 Feb 1996, Kamil Iskra wrote: > I implemented Amiga-specific attributes as SAS/C-compatible keywords: > interrupt, saveds, stackext and (currently disabled) chip. Good (except for the disabled "chip"). I hope you will document the effects of these keywords for the benefit of those people (like me) that have never used SAS/Lattice C. > I created new preprocessor symbol "TARGET_AMIGADOS" - when it is > defined, support for Amiga keywords is enabled. I'd prefer that to be "TARGET_AMIGAOS" instead, for two reasons: 1) Those keywords have nothing to do with Amiga*DOS* specifically (except for "chip" maybe). They are used for the Amiga*OS* in general. 2) AmigaDOS gives associations to MS-DOS, which is a Bad Thing(tm). Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 16:53:22 1996 Received: from oersted.gbar.dtu.dk ([130.225.87.181]) by nic.funet.fi with ESMTP id <1893-13658>; Mon, 12 Feb 1996 15:06:34 +0200 Received: (from c948374@localhost) by oersted.gbar.dtu.dk (8.7.3/8.7.3) id OAA11060; Mon, 12 Feb 1996 14:06:34 +0100 (MET) Date: Mon, 12 Feb 1996 14:06:33 +0100 (MET) From: Rask Ingemann Lambertsen To: amiga-gcc-port@nic.funet.fi, ade-gcc@amigalib.com Subject: Passing function arguments in registers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, Following the discussion on amiga-gcc-port of whether or not it is a good to pass arguments in registers when making function calls, I decided to see what the GCC documentation had to say about that. From gcc.guide, "Interfacing to GCC output": " GNU CC uses the system's standard convention for passing arguments. On some machines, the first few arguments are passed in registers; in others, all are passed on the stack. It would be possible to use registers for argument passing on any machine, and this would probably result in a significant speedup. But the result would be complete incompatibility with code that follows the standard convention. So this change is practical only if you are switching to GNU CC as the sole C compiler for the system. We may implement register argument passing on certain machines once we have a complete GNU system so that we can compile the libraries with GNU CC." To me, it makes three things clear: 1) Passing arguments in registers *does* provide a speedup and *is* an advantage. 2) It causes incompatibility with existing link libraries. 3) GCC already has support for passing arguments in registers. We just have to utilitze it. Since I don't use link libraries in my programmes, I don't see any problems at all. But to shut up those people who *do* see the world coming to an end (sorry) because of this, I suggest making a command line switch to choose between the different argument passing conventions. Since it is my impression that ADE is more Amiga-focused than the people on amiga-gcc-port, I'd also like to know what the ADE people think about it. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 16:53:24 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <6531-13658>; Mon, 12 Feb 1996 15:18:24 +0200 Received: from ernie.icslab.agh.edu.pl by funet.fi with SMTP (PP); Mon, 12 Feb 1996 15:17:10 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id OAA19372; Mon, 12 Feb 1996 14:19:19 +0100 Date: Mon, 12 Feb 1996 14:19:18 +0100 (MET) From: Kamil Iskra To: Rask Ingemann Lambertsen cc: ADE GCC List , Amiga GCC List Subject: Re: Amiga-specific attributes implemented as keywords In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Feb 1996, Rask Ingemann Lambertsen wrote: > > I implemented Amiga-specific attributes as SAS/C-compatible keywords: > > interrupt, saveds, stackext and (currently disabled) chip. > > Good (except for the disabled "chip"). I hope you will document the > effects of these keywords for the benefit of those people (like me) that > have never used SAS/Lattice C. I documented it in one of my previous postings, announcing their implementation as "GCC attributes". I just didn't want to repeat myself. > > I created new preprocessor symbol "TARGET_AMIGADOS" - when it is > > defined, support for Amiga keywords is enabled. > I'd prefer that to be "TARGET_AMIGAOS" instead, for two reasons: > 1) Those keywords have nothing to do with Amiga*DOS* specifically (except > for "chip" maybe). They are used for the Amiga*OS* in general. > 2) AmigaDOS gives associations to MS-DOS, which is a Bad Thing(tm). There was a discussion in the past about it, wasn't it? I think it was settled that "m68k-unknown-amigaos" would be used. However, ADE tools still seem to use "m68k-cbm-amigados". That's why I decided to use "TARGET_AMIGADOS", "amigados-c-parse.gperf" and "amigados-gxx.gperf" - otherwise this would look rather strange - some files "amigados", some "amigaos". / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 16:53:24 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <6655-3989>; Mon, 12 Feb 1996 15:28:24 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id OAA19612; Mon, 12 Feb 1996 14:28:48 +0100 Date: Mon, 12 Feb 1996 14:28:48 +0100 (MET) From: Kamil Iskra To: Rask Ingemann Lambertsen cc: amiga-gcc-port@nic.funet.fi, ade-gcc@amigalib.com Subject: Re: Passing function arguments in registers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Feb 1996, Rask Ingemann Lambertsen wrote: > To me, it makes three things clear: > 1) Passing arguments in registers *does* provide a speedup and *is* an > advantage. > 2) It causes incompatibility with existing link libraries. > 3) GCC already has support for passing arguments in registers. We just > have to utilitze it. I've read it, too. I also had a look at the source code. It seems that m68k already has support for register arguments (-mregparms or sth. like this), but it's written that it doesn't work and was created for RISCs (?!)). I'll investigate it further in the next couple of days. > Since I don't use link libraries in my programmes, I don't see any > problems at all. But to shut up those people who *do* see the world coming > to an end (sorry) because of this, I have a strange feeling that you are talking about me :-). > I suggest making a command line switch > to choose between the different argument passing conventions. I agree. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 16:53:27 1996 Received: from hpcl.cti.gr ([150.140.91.21]) by nic.funet.fi with SMTP id <6221-13658>; Mon, 12 Feb 1996 15:41:26 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA00591 (5.67a8/IDA-1.5 for ); Mon, 12 Feb 1996 15:37:49 +0200 From: Kriton Kyrimis Message-Id: <199602121337.AA00591@hpcl.cti.gr> Subject: Re: Fopen(): Libnix vs Ixemul.library To: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Date: Mon, 12 Feb 1996 15:37:48 +0200 (EET) Cc: ade-ixemul@amigalib.com, amiga-gcc-port@nic.funet.fi (gcc) Reply-To: kyrimis@softlab.ece.ntua.gr In-Reply-To: from "Walter Harms" at Feb 12, 96 02:05:00 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 444 > are you sure about the unix case ? > i ckecked the programm with HPUX,AIX & DEC non of them opened the > file a second time. SunOS 4.1.3U1 opens the file twice. This discrepancy is one more argument against doing this sort of thing in programs that are supposed to be portable. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I am a highwayman, madam." "This isn't a highway!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 17:11:14 1996 Received: from hpcl.cti.gr ([150.140.91.21]) by nic.funet.fi with SMTP id <6020-10055>; Mon, 12 Feb 1996 16:31:23 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA00878 (5.67a8/IDA-1.5 for ); Mon, 12 Feb 1996 16:29:20 +0200 From: Kriton Kyrimis Message-Id: <199602121429.AA00878@hpcl.cti.gr> Subject: Re: Fopen(): Libnix vs Ixemul.library To: Joop.vandeWege@medew.ento.wau.nl (joop van de wege) Date: Mon, 12 Feb 1996 16:29:17 +0200 (EET) Cc: ade-ixemul@amigalib.com, amiga-gcc-port@nic.funet.fi (gcc) Reply-To: kyrimis@softflab.ece.ntua.gr In-Reply-To: from "joop van de wege" at Feb 12, 96 01:28:13 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1130 > Its the same program who re-opens the file and I assume that ixemul will > flush the first file to disk and then destroys its contents by the second > fopen(). A more likely behavior, assuming that both calls to fopen really succeed, is that writes to both file descriptors will succeed, and that data will be written wherever each file descriptor thinks is the current end of the file, resulting in a total mess. The fact that buffered I/O (i.e., stdio) is used, means that you cannot really control what you're writing to the file, so that you can't know what you're doing. > >Thus, I would tend to think that the problem lies with the program opening > >the same file twice, rather than with any of the libraries. As Walter Harms pointed out, your test program fails in the two flavors of unix to which he has access, while it succeeds in the one flavor where I have access. Thus, I would conclude that opening the same file for write, twice, is non-portable. -- Kriton (INTERNET: kyrimis@hpcl.cti.gr) (WWW: http://www.hpcl.cti.gr/~kyrimis ----- "I am a highwayman, madam." "This isn't a highway!" ----- From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 22:12:28 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <5180-10055>; Mon, 12 Feb 1996 18:48:46 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tm1Re-000gXiC; Mon, 12 Feb 96 09:49 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Fopen(): Libnix vs Ixemul.library To: kyrimis@softflab.ece.ntua.gr Date: Mon, 12 Feb 1996 09:49:42 -0700 (MST) Cc: Joop.vandeWege@medew.ento.wau.nl, ade-ixemul@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <199602121429.AA00878@hpcl.cti.gr> from "Kriton Kyrimis" at Feb 12, 96 04:29:17 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1667 > A more likely behavior, assuming that both calls to fopen really succeed, is > that writes to both file descriptors will succeed, and that data will be > written wherever each file descriptor thinks is the current end of the file, > resulting in a total mess. I disagree that there is not some potentially useful behavior here and that it has to result in a "mess". Now it's possible that it is nonportable and that some implementations have undefined behavior under certain circumstances, but that is a separate issue. Consider the case where I want to have more than one "view" into a file that I'm constructing. For example, assume I want to generate a file that has an index table at the front and then a series of strings after the table. For simplicity, I'm using a fixed index table that will hold 100 entries. With a single FILE open, I would have to either remember all the indices and strings, and then write the file linearly, or else remember each place where I'm at in the table and the strings, and seek back and forth. With two descriptors, it is trivial to write both sections of the file independently. Here is the code that works on both linux and AmigaOS. -Fred #include #define BUCKETS 100 main () { FILE *headers; FILE *data; char buf[128]; int count; int offset; headers = fopen ("junkfile", "w+"); data = fopen ("junkfile", "w+"); fseek (data, BUCKETS * sizeof (int), 0); for (count = 0; count < 100; count++) { if (!gets (buf)) { break; } else { offset = ftell (data); fwrite (&offset, sizeof (offset), 1, headers); fwrite (&buf, strlen (buf) + 1, 1, data); } } } From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 22:12:29 1996 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <2358-17772>; Mon, 12 Feb 1996 21:16:09 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0tm3rM-000R0zC; Mon, 12 Feb 96 20:24 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0jji@wyst.hobby.nl>; Mon, 12 Feb 96 20:03:19 CET Message-Id: <9602121903.0jji@wyst.hobby.nl> Date: Mon, 12 Feb 1996 20:03:18 +0000 (CET) In-Reply-To: <96Feb10.152553+0200_eet.9540-19376+32@nic.funet.fi> from "Sven Heithecker" at Feb 10, 96 02:22:03 pm Content-Type: text Content-Length: 2271 From: hans@wyst.hobby.nl (Hans Verkuil) To: y0000135@ws.rz.tu-bs.de Cc: amiga-gcc-port@nic.funet.fi Subject: Re: gcc crashes & errors in new inlines Hi Sven, > If somebody is interested in the sources, ask me. I haven't them here at University > at the moment. > > I think many of the crashes are related to ixemul. On my opinion ixemul is very > system-unfriendly, and it will ever be. I would like to remove it from my HD NOW !! > Is it possible to recompile gcc using -noixemul ? Being the current ixemul maintainer, I'm interested in knowing why ixemul is system-unfriendly. The only possible ixemul-related bug you mentioned is that Ctrl-C crashes sometimes. I assume that you get a crash when using ixemul-42.0? If you can reproduce this, I'd like to know how. I've spent a lot of time to close all the holes and allow Ctrl-C to work, but it may be that I've overlooked one or two. Except for this bug, all the others might just as well be related to inline-problems or gcc-problems. I'm no gcc-guru, so I leave it to others to examine this. If it turns out to be a ixemul bug after all, then I'd like to hear about it. All I can say is that Fred Fish uses ixemul to run huge configure and build stages that take days without problems. It is very difficult to compile gcc without ixemul, I think. I can guarantee that Ctrl-C is one thing that will certainly fail to work if you try to recompile gcc with -noixemul. ixemul.library was originally developed just to be able to compile gcc, and it makes it easy to compile at least 90% of all Unix programs. Rather than complaining about ixemul, I much prefer to receive detailed bug reports, so that I can fix the bug for the next release. Ixemul allowed me to port programs I never dreamed of porting without having to change a single line. By the way, I'm trying to phase out this mailinglist. I prefer it if people would use the new mailinglist ade-gcc. To get information on how to subscribe send email to majordomo@amigalib.com with 'help' in the body. Cheers, Hans -- Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel, The Netherlands -- Tel: 010-4585745, email: hans@wyst.hobby.nl ixemul.library maintainer "...and the princesses were beautiful as the day is long and so noble they could pee through a dozen mattresses --" (Terry Pratchett) From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 22:12:31 1996 Received: from cpt6.stm.tudelft.nl ([130.161.186.114]) by nic.funet.fi with SMTP id <2048-17772>; Mon, 12 Feb 1996 21:25:31 +0200 Received: by cpt6.stm.tudelft.nl (1.38.193.4/16.2) id AA15645; Mon, 12 Feb 1996 20:32:18 +0100 Illegal-Object: Syntax error in From: address found on nic.funet.fi: From: Maarten D.de Jong ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Subject: ADE-question From: To: amiga-gcc-port@nic.funet.fi Date: Mon, 12 Feb 96 20:32:18 MET Mailer: Elm [revision: 70.85] Message-Id: <96Feb12.212531+0200_eet.2048-17772+296@nic.funet.fi> I apologize for misusing the amiga-gcc mailing list for not exactly gcc-type questions, but I know the people who can answer this question subscribe :)) I went over the ADE-program list on ftp.amigalib.com a few days ago. Most programs are really worth having (I'll DL them as soon as I get a bigger HD :) ), but I was really amazed at the size of the unixtex-distribution. It consisted of about 32,5 Mb lha'ed files -- that's at least 55 Mb un- archived! May I be so bold to ask what on Earth is in those archives? The complete CTAN-archive? Surely the source to TeX isn't *that* large... Or are previewers, Web2C and MetaFont included as well? Just asking... Maarten (By the way -- is there going to be a 68060-version of GCC, or is there already one? I haven't followed the discussions for a while now.) ****************************************************************************** * We learn from history that we never learn anything from history. * ****************************************************************************** | Maarten D. de Jong | dejong@cpt6.stm.tudelft.nl | | ------------------------------------------------------------------------------ From amiga-gcc-port-owner@nic.funet.fi Mon Feb 12 22:12:31 1996 Received: from hpcl.cti.gr ([150.140.91.21]) by nic.funet.fi with SMTP id <2996-3989>; Mon, 12 Feb 1996 21:59:27 +0200 Received: from hpcl3.hpcl (hpcl3.cti.gr) by hpcl.cti.gr with SMTP id AA00251 (5.67a8/IDA-1.5 for ); Mon, 12 Feb 1996 21:59:55 +0200 From: Kriton Kyrimis Message-Id: <199602121959.AA00251@hpcl.cti.gr> Subject: Re: Fopen(): Libnix vs Ixemul.library To: fnf@amigalib.com (Fred Fish) Date: Mon, 12 Feb 1996 21:59:55 +0200 (EET) Cc: Joop.vandeWege@medew.ento.wau.nl, ade-ixemul@amigalib.com, amiga-gcc-port@nic.funet.fi (gcc) Reply-To: kyrimis@softlab.ece.ntua.gr In-Reply-To: from "Fred Fish" at Feb 12, 96 09:49:42 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 837 > seek back and forth. With two descriptors, it is trivial to write > both sections of the file independently. Here is the code that works > on both linux and AmigaOS. I assume that by AmigaOS you mean gcc/ixemul. In all other cases that I've tried (gcc/libnix, SAS/C, lcc/burplib) your test program fails in the second fopen, and I explained in a previous message why I consider this to be the correct behavior on the amiga. (You are right, that being able to write to the same file from two file descriptors might have its uses. Given that from the four unix flavors and four amiga run-time libraries on which it was tested as a result of this thread, this trick only appears to work on two unix flavors and one amiga library, I would consider using the trick non-portable and bad programming style.) Just my two drachmas' worth, From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 00:46:51 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <1501-17772>; Mon, 12 Feb 1996 22:49:33 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tm5Ck-000gXXC; Mon, 12 Feb 96 13:50 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Fopen(): Libnix vs Ixemul.library To: kyrimis@softlab.ece.ntua.gr Date: Mon, 12 Feb 1996 13:50:33 -0700 (MST) Cc: fnf@amigalib.com, Joop.vandeWege@medew.ento.wau.nl, ade-ixemul@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <199602121959.AA00251@hpcl.cti.gr> from "Kriton Kyrimis" at Feb 12, 96 09:59:55 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 858 > Given that from the four unix flavors and > four amiga run-time libraries on which it was tested as a result of this > thread, this trick only appears to work on two unix flavors and one amiga > library, I would consider using the trick non-portable and bad programming > style.) I just tested it on 13 different unix systems that I just happened to have xterms open on because I'm doing gdb testing on them, including sgi, ultrix, hpux, linux, sunos, solaris, osf, sysv4.2, and aix, and all of them worked just fine for this example. I would agree with you that its use outside Unix is potentially a problem and thus it is not good programming style. I would argue that any Unix system that gets it wrong is badly broken. I believe that ixemul is doing the correct thing by making it behave the same as all the working unix systems I've tried. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 00:46:52 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <1551-3989>; Mon, 12 Feb 1996 23:12:51 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tm5ZH-000gXXC; Mon, 12 Feb 96 14:13 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ADE-question To: dejong@cpt6.stm.tudelft.nl Date: Mon, 12 Feb 1996 14:13:50 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <96Feb12.212531+0200_eet.2048-17772+296@nic.funet.fi> from "dejong@cpt6.stm.tudelft.nl" at Feb 12, 96 08:32:18 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 512 > I was really amazed at the size of the unixtex-distribution. > It consisted of about 32,5 Mb lha'ed files -- that's at least 55 Mb un- > archived! Actually I think it is quite a bit more. > May I be so bold to ask what on Earth is in those archives? The > complete CTAN-archive? Nope. :-) > Surely the source to TeX isn't *that* large... Or > are previewers, Web2C and MetaFont included as well? Most of the bulk is fonts as I recall. But it does also include metafont, web2c, latex, dvips, etc. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 11:11:32 1996 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <6809-26850>; Tue, 13 Feb 1996 11:10:05 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA32156 (5.67b8/IDA-1.5 for ); Tue, 13 Feb 1996 10:09:56 +0100 Received: by diva.gmd.de id AA28650 (5.67b8/IDA-1.5); Tue, 13 Feb 1996 10:04:50 +0100 Date: Tue, 13 Feb 1996 10:04:50 +0100 From: Joerg Hoehle Message-Id: <199602130904.AA28650@diva.gmd.de> To: ade-ixemul@amigalib.com, amiga-gcc-port@nic.funet.fi Subject: Re: Fopen(): Libnix vs Ixemul.library Fred writes: > I just tested it on 13 different unix systems that I just happened to ... > all of them worked just fine for this example. This is what I expected. It's a very ancient "trick" of UNIX to be able to do this, and it's also one of the very old portability problems from UNIX. If I remember right, this causes lost blocks on MS/PC-DOG partitions, so I'm quite surprised to find it in a program like GhostScript that supposedly has been ported to many platforms. Joerg Hoehle. From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 11:26:24 1996 Received: from faui40.informatik.uni-erlangen.de ([131.188.2.40]) by nic.funet.fi with ESMTP id <7069-27402>; Tue, 13 Feb 1996 11:25:52 +0200 Received: from pctc.chemie.uni-erlangen.de (pctc.chemie.uni-erlangen.de [131.188.120.2]) by immd4.informatik.uni-erlangen.de with SMTP id JAA13060 (8.7.2/7.5a-FAU);; Tue, 13 Feb 1996 09:59:36 +0100 (MET) Received: by pctc.chemie.uni-erlangen.de (AIX 3.2/UCB 5.64/4.03) id AA20941; Tue, 13 Feb 1996 09:59:36 +0100 Date: Tue, 13 Feb 1996 09:59:36 +0100 Message-Id: <9602130859.AA20941@pctc.chemie.uni-erlangen.de> From: Thomas Walter To: fnf@amigalib.com Cc: dejong@cpt6.stm.tudelft.nl, amiga-gcc-port@nic.funet.fi In-Reply-To: (fnf@amigalib.com) Subject: Re: ADE-question >>>>> "Fred" == Fred Fish writes: >> I was really amazed at the size of the unixtex-distribution. >> It consisted of about 32,5 Mb lha'ed files -- that's at least >> 55 Mb un- archived! Fred> Actually I think it is quite a bit more. >> May I be so bold to ask what on Earth is in those archives? The >> complete CTAN-archive? Fred> Nope. :-) >> Surely the source to TeX isn't *that* large... Or are >> previewers, Web2C and MetaFont included as well? Fred> Most of the bulk is fonts as I recall. But it does also Fred> include metafont, web2c, latex, dvips, etc. Fred> -Fred I'm a user of LaTeX and TeX. Currently not the version from the ADE-tree but I had a look at it. And I can say it is a very complete LaTex,Tex,Metafont,dvips,... environment that will work without having to do much settings, except the obvious settings. It is comparable with PasTeX-environment but with free source. Recently I read, the author wants to free the source of PasTEX, but I don't know the exact terms. Thomas -- Thomas Walter INTERNET: walter@pctc.chemie.uni-erlangen.de From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 11:55:53 1996 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <6978-26850>; Tue, 13 Feb 1996 11:55:14 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA02704 (5.67b8/IDA-1.5 for ); Tue, 13 Feb 1996 10:54:52 +0100 Received: by diva.gmd.de with UUCP id AA28677 (5.67b8/IDA-1.5); Tue, 13 Feb 1996 10:49:45 +0100 Date: Tue, 13 Feb 1996 10:49:45 +0100 Message-Id: <199602130949.AA28677@diva.gmd.de> From: Joerg.Hoehle@gmd.de (Joerg Hoehle) To: ADE GCC List , Amiga GCC List Subject: Amiga-specific attributes implemented as keywords In-Reply-To: References: Kamil Iskra writes: > I implemented Amiga-specific attributes as SAS/C-compatible keywords: > If you want a single function to extend stack automatically, you > should write your code like this: Great! I think this is the only reasonable use of stack extend. You don't want stack-(check and) -extend in every single function of your program, because it costs too much. Do you people realize that this way you write slower software than need be and will have other people saying "what's this slow Amiga, I always knew any was better". UNIX, by design, need no stack-extend, other OSes may also have it built in at the hardware-level (MMU), which is very much faster. My experience is that in a program, only very few functions need an unusual amount of stack and therefore might check for it and grow it. With these new keywords, this can be done on an individual basis. Unluckily, stack growth is currently at function entry, not within ("call function with at least 40KB (dynamically computed) of stack"). Good job! Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 12:35:12 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <6466-6361>; Tue, 13 Feb 1996 12:34:08 +0200 Received: from bastion.nmrc.ucc.ie (actually host nmrc.ucc.ie) by funet.fi with SMTP (PP); Tue, 13 Feb 1996 12:20:56 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id KAA24715; Tue, 13 Feb 1996 10:18:03 GMT From: Lars Hecking Message-Id: <199602131020.KAA05750@mostar.nmrc.ucc.ie> Subject: Re: ADE-question To: walter@pctc.chemie.uni-erlangen.de (Thomas Walter) Date: Tue, 13 Feb 1996 10:20:07 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: <9602130859.AA20941@pctc.chemie.uni-erlangen.de> from "Thomas Walter" at Feb 13, 96 09:59:36 am Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 638 > I'm a user of LaTeX and TeX. Currently not the version from the ADE-tree > but I had a look at it. And I can say it is a very complete LaTex,Tex, > Metafont,dvips,... environment that will work without having to do much > settings, except the obvious settings. > > It is comparable with PasTeX-environment but with free source. > Recently I read, the author wants to free the source of PasTEX, but I > don't know > the exact terms. The latest PasTeX 1.4 is on Meeting Pearls III. The whole archive is some 50 MB (if d/l'd as .tar.gz) and includes source. A 'lite' version (9.4MB .lha) is on Aminet, but probably not with source. From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 13:49:57 1996 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <6331-26572>; Tue, 13 Feb 1996 13:47:17 +0200 Received: (from c948374@localhost) by hald.gbar.dtu.dk (8.7.3/8.7.3) id MAA03702; Tue, 13 Feb 1996 12:46:44 +0100 (MET) Date: Tue, 13 Feb 1996 12:46:43 +0100 (MET) From: Rask Ingemann Lambertsen To: kyrimis@softlab.ece.ntua.gr cc: joop van de wege , amiga-gcc-port@nic.funet.fi, ade-ixemul@amigalib.com Subject: Re: Fopen(): Libnix vs Ixemul.library In-Reply-To: <199602120839.AA05317@hpcl.cti.gr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 12 Feb 1996, Kriton Kyrimis wrote: > > It turns out to be a *major* difference in ixemul.library vs Libnix. > > Note the output of using Libnix: > > 11.Ram Disk:> gcc -noixemul -o filetest filetest.c > > 11.Ram Disk:> filetest t:blabla > > first w+ works > > > > And when using ixemul.library: > > 11.Ram Disk:> gcc -o filetest filetest.c > > 11.Ram Disk:> filetest t:blabla > > first w+ works > > second w+ open works too > > The second behavior is the correct *UNIX* behavior. On the other hand, > opening a file for writing on the Amiga locks the file, so you can't open it ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > again. No offence ment, but please read the AutoDocs for the Open() function of dos.library (at least) one more time. What you're writing isn't true. Also, keep in mind that ixemul also uses the dos.library Open() function. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 14:09:23 1996 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <6656-27402>; Tue, 13 Feb 1996 14:06:40 +0200 Received: (from c948374@localhost) by hald.gbar.dtu.dk (8.7.3/8.7.3) id NAA04065; Tue, 13 Feb 1996 13:05:25 +0100 (MET) Date: Tue, 13 Feb 1996 13:05:25 +0100 (MET) From: Rask Ingemann Lambertsen To: kyrimis@softlab.ece.ntua.gr cc: Fred Fish , Joop.vandeWege@medew.ento.wau.nl, ade-ixemul@amigalib.com, gcc Subject: Re: Fopen(): Libnix vs Ixemul.library In-Reply-To: <199602121959.AA00251@hpcl.cti.gr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 12 Feb 1996, Kriton Kyrimis wrote: > > seek back and forth. With two descriptors, it is trivial to write > > both sections of the file independently. Here is the code that works > > on both linux and AmigaOS. > > I assume that by AmigaOS you mean gcc/ixemul. In all other cases that I've > tried (gcc/libnix, SAS/C, lcc/burplib) your test program fails in the second > fopen, and I explained in a previous message why I consider this to be the > correct behavior on the amiga. Why do you think it the correct behaviour on the Amiga specifically? The HP (S)UX manual pages don't seem to mention what is supposed to happen when a file is opened with "w+" twice, and I think the HP (S)UX manual pages follow the ANSI specifications. On the Amiga, the behaviour when opening a file twice with "w+" really depends on how the fopen() function was implemented. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 14:43:40 1996 Received: from hald.gbar.dtu.dk ([130.225.87.178]) by nic.funet.fi with ESMTP id <7143-6361>; Tue, 13 Feb 1996 14:42:00 +0200 Received: (from c948374@localhost) by hald.gbar.dtu.dk (8.7.3/8.7.3) id NAA04709; Tue, 13 Feb 1996 13:41:50 +0100 (MET) Date: Tue, 13 Feb 1996 13:41:50 +0100 (MET) From: Rask Ingemann Lambertsen To: Joerg Hoehle cc: ADE GCC List , Amiga GCC List Subject: Re: Amiga-specific attributes implemented as keywords In-Reply-To: <199602130949.AA28677@diva.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 13 Feb 1996, Joerg Hoehle wrote: > UNIX, by design, need no stack-extend, I'm not so sure about that, I've seen stack overflows three times until now on a HP (S)UX system ;-) Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 16:09:17 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <6869-6361> convert rfc822-to-8bit; Tue, 13 Feb 1996 16:05:50 +0200 Received: from lorenz.gbar.dtu.dk by funet.fi with SMTP (PP); Tue, 13 Feb 1996 16:05:33 +0200 Received: (from c948374@localhost) by lorenz.gbar.dtu.dk (8.7.3/8.7.3) id PAA08851; Tue, 13 Feb 1996 15:05:29 +0100 (MET) Date: Tue, 13 Feb 1996 15:05:29 +0100 (MET) From: Rask Ingemann Lambertsen To: Rask Ingemann Lambertsen cc: Kamil Iskra , amiga-gcc-port@nic.funet.fi Subject: Re: Optimizations. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi all, I have a small correction for one of my previous postings: On Fri, 26 Jan 1996, Rask Ingemann Lambertsen wrote: > No, do you? What I want is efficient code and preferably also small code. > Passing arguments in registers doesn't give that. ^^^^^^^^^^^^ What I intended to write was "on the stack". Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 16:09:23 1996 Received: from septimius.mbfys.kun.nl ([131.174.173.155]) by nic.funet.fi with SMTP id <6681-26850>; Tue, 13 Feb 1996 16:02:18 +0200 Received: from severus by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.173.171] with SMTP id PAA11647 (8.6.10/2.4); Tue, 13 Feb 1996 15:03:04 +0100 Date: Tue, 13 Feb 1996 15:03:04 +0100 From: Olaf Seibert Message-Id: <199602131403.PAA11647@septimius.mbfys.kun.nl> To: fnf@amigalib.com, kyrimis@softflab.ece.ntua.gr Subject: Re: Fopen(): Libnix vs Ixemul.library Cc: Joop.vandeWege@medew.ento.wau.nl, ade-ixemul@amigalib.com, amiga-gcc-port@nic.funet.fi, rhialto@mbfys.kun.nl fnf@amigalib.com (Fred Fish) wrote: > Consider the case where I want to have more than one "view" into a > file that I'm constructing. For example, assume I want to generate a > file that has an index table at the front and then a series of strings > after the table. For simplicity, I'm using a fixed index table that > will hold 100 entries. Your example, and programs like it, should work if it is guaranteed that the parts of the file touched by the different file descriptors never overlap. However, overlap is possibly larger than you think. Taking your example (reproduced below), I would like to illustrate this. Suppose stdio buffering is at least 512 bytes (not an unrealistic assumption given current ffs block sizes). Then your 100 offsets (100 * 4 bytes) and 100 empty (and even a few short non-empty) strings would easily fit in a single stdio buffer - yet each FILE* has its own buffer. When stdio implements overwriting existing files by reading whole buffers from the file, changing them in-place, performing changes inside the buffer as long as the seek position is inside it, and writing it out if not (not an unrealistic assumption), then it will break. The only things you can do to hope it will work is using fflush() between switching FILE*-s (just like it is already required between switching read and write actions on the same FILE*) and/or using setvbuf() to make the file use a small buffer or none at all. #include #define BUCKETS 100 main () { FILE *headers; FILE *data; char buf[128]; int count; int offset; headers = fopen ("junkfile", "w+"); data = fopen ("junkfile", "w+"); fseek (data, BUCKETS * sizeof (int), 0); for (count = 0; count < 100; count++) { if (!gets (buf)) { break; } else { offset = ftell (data); fwrite (&offset, sizeof (offset), 1, headers); fwrite (&buf, strlen (buf) + 1, 1, data); } } } -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl The only excuse \X/ for making a useless thing is that one admires it intensely. -O.W. From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 16:55:22 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <7029-26850> convert rfc822-to-8bit; Tue, 13 Feb 1996 16:50:40 +0200 Received: from lorenz.gbar.dtu.dk by funet.fi with SMTP (PP); Tue, 13 Feb 1996 16:41:16 +0200 Received: (from c948374@localhost) by lorenz.gbar.dtu.dk (8.7.3/8.7.3) id PAA09180; Tue, 13 Feb 1996 15:41:00 +0100 (MET) Date: Tue, 13 Feb 1996 15:40:59 +0100 (MET) From: Rask Ingemann Lambertsen To: Olaf Seibert cc: fnf@amigalib.com, kyrimis@softflab.ece.ntua.gr, Joop.vandeWege@medew.ento.wau.nl, ade-ixemul@amigalib.com, amiga-gcc-port@nic.funet.fi, rhialto@mbfys.kun.nl Subject: Re: Fopen(): Libnix vs Ixemul.library In-Reply-To: <199602131403.PAA11647@septimius.mbfys.kun.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 13 Feb 1996, Olaf Seibert wrote: > fnf@amigalib.com (Fred Fish) wrote: > > Consider the case where I want to have more than one "view" into a > > file that I'm constructing. For example, assume I want to generate a > > file that has an index table at the front and then a series of strings > > after the table. For simplicity, I'm using a fixed index table that > > will hold 100 entries. > > Your example, and programs like it, should work if it is guaranteed > that the parts of the file touched by the different file descriptors > never overlap. However, overlap is possibly larger than you think. > Taking your example (reproduced below), I would like to illustrate > this. > Suppose stdio buffering is at least 512 bytes (not an unrealistic > assumption given current ffs block sizes). I don't see why they are likely to be related to each other. Btw, current FFS blocks are as big/small as you define them when you mount a device. > Then your 100 offsets (100 > * 4 bytes) and 100 empty (and even a few short non-empty) strings would > easily fit in a single stdio buffer - yet each FILE* has its own > buffer. When stdio implements overwriting existing files by reading > whole buffers from the file, changing them in-place, performing changes > inside the buffer as long as the seek position is inside it, and > writing it out if not (not an unrealistic assumption), then it will > break. I'm wondering what would happen if the stdio routines were implemented using buffered dos.library functions. Maybe dos.library would be able to figure it out then? Btw, how does ixemul and libnix implement stdio function? Do they implement fopen()/fread()/fwrite()/fseek()/fclose() using the UNIX-like open()/read()/write()/lseek()/close() which are then implemented using dos.library Open()/Read()/Write()/Seek()/Close() or do they utilize FRead()/FWrite()? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 17:07:47 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <6137-26572>; Tue, 13 Feb 1996 17:05:00 +0200 Received: from bastion.nmrc.ucc.ie (actually host nmrc.ucc.ie) by funet.fi with SMTP (PP); Tue, 13 Feb 1996 17:04:29 +0200 Received: by nmrc.ucc.ie (8.6.12/8.6.6) with ESMTP id PAA00775; Tue, 13 Feb 1996 15:02:16 GMT From: Lars Hecking Message-Id: <199602131504.PAA06184@mostar.nmrc.ucc.ie> Subject: Re: Fopen(): Libnix vs Ixemul.library To: c948374@student.dtu.dk (Rask Ingemann Lambertsen) Date: Tue, 13 Feb 1996 15:04:17 +0000 (GMT) Cc: amiga-gcc-port@nic.funet.fi (Amiga GCC List) In-Reply-To: from "Rask Ingemann Lambertsen" at Feb 13, 96 03:40:59 pm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 374 > Btw, how does ixemul and libnix implement stdio function? Do they > implement fopen()/fread()/fwrite()/fseek()/fclose() using the UNIX-like > open()/read()/write()/lseek()/close() which are then implemented using > dos.library Open()/Read()/Write()/Seek()/Close() or do they utilize > FRead()/FWrite()? Ixemul does not use FRead()/FWrite(). I don't know about libnix. From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 17:24:35 1996 Received: from septimius.mbfys.kun.nl ([131.174.173.155]) by nic.funet.fi with SMTP id <6636-26850>; Tue, 13 Feb 1996 17:23:45 +0200 Received: from severus by septimius.mbfys.kun.nl via severus.mbfys.kun.nl [131.174.173.171] with SMTP id QAA11981 (8.6.10/2.4); Tue, 13 Feb 1996 16:24:41 +0100 Date: Tue, 13 Feb 1996 16:24:41 +0100 From: Olaf Seibert Message-Id: <199602131524.QAA11981@septimius.mbfys.kun.nl> To: c948374@student.dtu.dk, rhialto@mbfys.kun.nl Subject: Re: Fopen(): Libnix vs Ixemul.library Cc: Joop.vandeWege@medew.ento.wau.nl, ade-ixemul@amigalib.com, amiga-gcc-port@nic.funet.fi, fnf@amigalib.com, kyrimis@softflab.ece.ntua.gr Rask Ingemann Lambertsen wrote: On Tue, 13 Feb 1996, Olaf Seibert wrote: > > Suppose stdio buffering is at least 512 bytes (not an unrealistic > > assumption given current ffs block sizes). > > I don't see why they are likely to be related to each other. Btw, current= > =20 > FFS blocks are as big/small as you define them when you mount a device. Sorry, I meant Unix ffs blocks, as in Berkeley Fast File System. ffs typically has block sizes of 8K with 1K fragments (or 4K/512bytes on some systems). Implementations are typically encouraged to use statfs(2) to find out the optimal tranfer size, which I expect to be 8K (4K) in such a case. I have seen at least one stdio implementation that uses statfs() to determine its buffer size. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl The only excuse \X/ for making a useless thing is that one admires it intensely. -O.W. From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 17:38:43 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <6528-26850>; Tue, 13 Feb 1996 17:37:17 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tmMkf-000gXUC; Tue, 13 Feb 96 08:34 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: ADE-question To: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Tue, 13 Feb 1996 08:34:44 -0700 (MST) Cc: walter@pctc.chemie.uni-erlangen.de, amiga-gcc-port@nic.funet.fi In-Reply-To: <199602131020.KAA05750@mostar.nmrc.ucc.ie> from "Lars Hecking" at Feb 13, 96 10:20:07 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 898 > > It is comparable with PasTeX-environment but with free source. > > Recently I read, the author wants to free the source of PasTEX, but I > > don't know > > the exact terms. > > The latest PasTeX 1.4 is on Meeting Pearls III. The whole archive is some > 50 MB (if d/l'd as .tar.gz) and includes source. A 'lite' version > (9.4MB .lha) is on Aminet, but probably not with source. A very useful thing for someone to do would be to try building PasTeX from the supplied source. Assuming that works, and that the source is complete, there would probably be some parts that would be very useful to merge into the ADE unixtex, such as showdvi for example. At one time the ADE unixtex was based on a newer version of TeX than PasTeX, but I don't know if that is still true or not, if PasTeX has been updated. In any case, ADE unixtex could also use some updating from the CTAN archives. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 17:41:15 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <6797-26572>; Tue, 13 Feb 1996 17:40:57 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tmMrG-000gXUC; Tue, 13 Feb 96 08:41 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Amiga-specific attributes implemented as keywords To: Joerg.Hoehle@gmd.de (Joerg Hoehle) Date: Tue, 13 Feb 1996 08:41:32 -0700 (MST) Cc: ade-gcc@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <199602130949.AA28677@diva.gmd.de> from "Joerg Hoehle" at Feb 13, 96 10:49:45 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1024 > I think this is the only reasonable use of stack extend. You don't > want stack-(check and) -extend in every single function of your > program, because it costs too much. Yes, this is very good for new code that is written with stack use requirements in mind, although such code can generally also be written such that it doesn't require a lot of stack in the first place. It is also useful for programs that might not have been written with careful management of stack resources in mind, but which can now be modified to do selective stack extending and don't have to track any master source base. However it's probably not suitable for programs like the GNU tools where there may be hundreds of places where the source would have to be modified (leading to a maintenance nightmare). For these cases, compiling the entire program with stack checking enabled is the only real viable solution for obtaining reliable programs without devoting an unreasonable amount of manpower to modifying and maintaining them. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 17:45:06 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <6243-27402>; Tue, 13 Feb 1996 17:44:52 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tmMut-000gXUC; Tue, 13 Feb 96 08:45 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Amiga-specific attributes implemented as keywords To: Joerg.Hoehle@gmd.de (Joerg Hoehle) Date: Tue, 13 Feb 1996 08:45:19 -0700 (MST) Cc: ade-gcc@amigalib.com, amiga-gcc-port@nic.funet.fi In-Reply-To: <199602130949.AA28677@diva.gmd.de> from "Joerg Hoehle" at Feb 13, 96 10:49:45 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 678 > here> was better". UNIX, by design, need no stack-extend, other OSes > may also have it built in at the hardware-level (MMU), which is very > much faster. BTW, although this is generally true of modern UNIX systems, it wasn't always true. Early m68000 based ports that did not support virtual memory used "stack probe" instructions, whereby as part of the prologue of each function, the program executed a "test byte" instruction at the lowest place in the stack where it was expecting to use stack. If that instruction faulted (there was memory protection) then the kernel took care of extending the programs stack and continued the program with the larger stack. -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 18:08:53 1996 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <7086-26572>; Tue, 13 Feb 1996 18:07:34 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA01955 (5.67b8/IDA-1.5 for ); Tue, 13 Feb 1996 17:06:40 +0100 Received: by diva.gmd.de with UUCP id AA28856 (5.67b8/IDA-1.5); Tue, 13 Feb 1996 17:01:33 +0100 Date: Tue, 13 Feb 1996 17:01:33 +0100 Message-Id: <199602131601.AA28856@diva.gmd.de> From: Joerg.Hoehle@gmd.de (Joerg Hoehle) To: ade-ixemul@amigalib.com, amiga-gcc-port@nic.funet.fi Subject: Re: Fopen(): Libnix vs Ixemul.library In-Reply-To: <199602131403.PAA11647@septimius.mbfys.kun.nl> References: <199602131403.PAA11647@septimius.mbfys.kun.nl> Olaf Seibert writes: > Suppose stdio buffering is at least 512 bytes (not an unrealistic > assumption given current ffs block sizes). Then your 100 offsets (100 I really, really hope that any stdio implementation is using buffers of at least 2K. Using 512 byte buffers gives very slow file i/o. SunOS (a UNIX) uses 8KB. See how diskspeed shows major speed improvements when using 4096 bytes buffers instead of 512 bytes. See how the speed doesn't improve as much when going from 4K to 256K than when going from 512 to 4K. The current buffered I/O routines from dos.library are nice for console i/o, pipes and telnet, but C stdio with at least 4KB buffers is much better for files, the filesystem, floppies and hard disks. Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de PS: with the many available mailing lists now, I wonder where each thread should go to. What do people think: where does this thread for example belong to? From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 18:09:25 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <6329-26850>; Tue, 13 Feb 1996 18:09:05 +0200 Received: by fishpond (Smail3.1.29.1 #57) id m0tmNJ0-000gXUC; Tue, 13 Feb 96 09:10 MST Message-Id: From: fnf@amigalib.com (Fred Fish) Subject: Re: Fopen(): Libnix vs Ixemul.library To: rhialto@mbfys.kun.nl (Olaf Seibert) Date: Tue, 13 Feb 1996 09:10:12 -0700 (MST) Cc: ade-ixemul@amigalib.com, amiga-gcc-port@nic.funet.fi (Amiga GCC mailing list) In-Reply-To: <199602131403.PAA11647@septimius.mbfys.kun.nl> from "Olaf Seibert" at Feb 13, 96 03:03:04 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 660 > When stdio implements overwriting existing files by reading > whole buffers from the file, changing them in-place, performing changes > inside the buffer as long as the seek position is inside it, and > writing it out if not (not an unrealistic assumption), then it will > break. > > The only things you can do to hope it will work is using fflush() Very good point. Yes, my program does have a bug in it. :-) Obviously any program that wants to use this technique will have to be very careful about buffering issues. Actually, where I have seen this used before, is at the system call level (open/write) rather than stdio level (fopen/fwrite). -Fred From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 18:17:11 1996 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <6915-27402>; Tue, 13 Feb 1996 18:16:53 +0200 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id RAA24868 (8.6.12/IDA-1.6 for ); Tue, 13 Feb 1996 17:14:49 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA02637; Tue, 13 Feb 96 17:14:49 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9602131614.AA02637@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Fopen(): Libnix vs Ixemul.library To: amiga-gcc-port@nic.funet.fi Date: Tue, 13 Feb 1996 17:14:48 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 514 > > Btw, how does ixemul and libnix implement stdio function? Do they > implement fopen()/fread()/fwrite()/fseek()/fclose() using the UNIX-like > open()/read()/write()/lseek()/close() Yes. These 5 functions and isatty(). > which are then implemented using > dos.library Open()/Read()/Write()/Seek()/Close() No. Only libnix uses Read(), Write(), Seek(). AFAIK ixemul.library uses direct DOS packet IO which is faster and allows for asynchronous IO. > or do they utilize > FRead()/FWrite()? > No. Matthias From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 18:28:46 1996 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <6478-26572>; Tue, 13 Feb 1996 18:27:53 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA02924 (5.67b8/IDA-1.5 for ); Tue, 13 Feb 1996 17:27:35 +0100 Received: by diva.gmd.de with UUCP id AA28862 (5.67b8/IDA-1.5); Tue, 13 Feb 1996 17:22:29 +0100 Date: Tue, 13 Feb 1996 17:22:29 +0100 Message-Id: <199602131622.AA28862@diva.gmd.de> From: Joerg.Hoehle@gmd.de (Joerg Hoehle) To: ade-ixemul@amigalib.com, amiga-gcc-port@nic.funet.fi Subject: Re: Fopen(): Libnix vs Ixemul.library In-Reply-To: References: <199602131403.PAA11647@septimius.mbfys.kun.nl> Rask Ingemann Lambertsen writes: > Btw, how does ixemul and libnix implement stdio function? Do they=20 > implement fopen()/fread()/fwrite()/fseek()/fclose() using the UNIX-like=20 > open()/read()/write()/lseek()/close() which are then implemented using=20 > dos.library Open()/Read()/Write()/Seek()/Close() or do they utilize=20 > FRead()/FWrite()? fopen() et al. need not necessarily go through open() -- at least I believe I know "simple" implementations where they do not. This may give you smaller code. However for better UNIX compatibility and least surprise behaviour, ixemul and libnix go through the UNIX-level. The functions that do buffered I/O (like fread() et al.) themselves should not go through another layer of buffering in dos.library (FRead() et al.). Beware of the Flush() caveats when mixing Read() and FRead() (and possibly SetMode()). Maybe we would get speed improvements if C stdio used FRead() instead of Read() on non-filesystem DOShandlers in non-stdio-buffered mode (same for write functions). Ixemul.library does not use FRead() because they appeared in 2.0. Remember that ixemul once worked in 1.3 systems. That doesn't mean that ixemul should be upgraded, see above. Ixemul even doesn't use Read() for most things as it acts at the packet level. Bye, Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Tue Feb 13 21:10:38 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <1997-1050>; Tue, 13 Feb 1996 21:06:34 +0200 Received: from DBSTU1.RZ.TU-BS.DE by funet.fi with SMTP (PP); Tue, 13 Feb 1996 21:05:53 +0200 Received: from rzrtr1.rz.tu-bs.de by DBSTU1.RZ.TU-BS.DE (IBM VM SMTP V2R2) with TCP; Tue, 13 Feb 96 20:06:09 MEZ Received: by rzrtr1.rz.tu-bs.de (AIX 4.1/UCB 5.64/4.03) id AA47980; Tue, 13 Feb 1996 20:01:31 +0100 From: y0000135@ws.rz.tu-bs.de (Sven Heithecker) Message-Id: <9602131901.AA47980@rzrtr1.rz.tu-bs.de> Subject: Re^2: Errors in new inlines To: amiga-gcc-port@nic.funet.fi (Sven Heithecker) Date: Tue, 13 Feb 1996 20:01:29 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1459 Hi Kamil - you asked me to be more specific about the problems I have with your new inlines. Well - here you are. Sorry that I can4t give an real answer (with the quoted question) - but I deleted it by accident :( . I found out that the error only occurs in my special case, though it is legal C code. I wrote a small testapp which creates the same environment as in my application, NEVER start it - it WILL crash !!!! #include #include struct Library *MUIMasterBase; struct ObjApp { APTR App; /* just an testapp ... more follow ... */ /* of course everything is initialised correctly in real life :) ! */ } ; void FreeApp(struct ObjApp *Object) { MUI_DisposeObject(Object->App); } /* "Workaround" void FreeApp(struct ObjApp *Object) { APTR DummyApp=Object->App; MUI_DisposeObject(DummyApp); } */ int main(void) { struct ObjApp TestApp; FreeApp(&TestApp); } When compiled with gcc -O1 testapp.c it gave muitest.c: In function `FreeApp': muitest.c:14: `_MUI_DisposeObject_v1' undeclared (first use this function) muitest.c:14: (Each undeclared identifier is reported only once muitest.c:14: for each function it appears in.) muitest.c:14: syntax error before `*' muitest.c:14: `_n1' undeclared (first use this function) The "workaround" gives same error :( ! I hope this helps ... ____ |_||_ Ceterum Censeo MEGAHARD Esse Delendam | | _| HTS Sven Heithecker s.heithecker@tu-bs.de From amiga-gcc-port-owner@nic.funet.fi Wed Feb 14 12:59:48 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1775-21964>; Wed, 14 Feb 1996 12:55:22 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA12764; Wed, 14 Feb 1996 11:57:15 +0100 Date: Wed, 14 Feb 1996 11:57:14 +0100 (MET) From: Kamil Iskra To: ADE GCC List cc: Amiga GCC List Subject: GCC and returning structures Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII It seems that in not very far future GCC will preduce slightly different code because of Rask optimisations and my removal of "omit frame pointer" kludge. Since complete three-stage rebuild will be necessary, I would propose yet another modification. It was suggested at least twice in the past, if I remember correctly. Currently GCC returns structures in static storage - this is quite silly, IMHO. It's easy to make it do it in other way. Here's a patch: *** amigados.h.orig Wed Feb 14 08:41:19 1996 --- amigados.h Wed Feb 14 08:42:48 1996 *************** *** 452,454 **** --- 452,459 ---- if (flag_pic == 3) \ call_used_regs[PIC_OFFSET_TABLE_REGNUM] = 1; \ } + + /* m68k.h defines this, which causes structures to be returned in static + storage, resulting in nonreentrant code, which we don't want. */ + + #undef PCC_STATIC_STRUCT_RETURN / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Feb 14 13:03:39 1996 Received: from mail.gmd.de ([129.26.8.90]) by nic.funet.fi with SMTP id <1601-21981>; Wed, 14 Feb 1996 13:02:56 +0200 Received: from diva.gmd.de (diva) by mail.gmd.de with SMTP id AA04248 (5.67b8/IDA-1.5 for ); Wed, 14 Feb 1996 12:02:37 +0100 Received: by diva.gmd.de with UUCP id AA29188 (5.67b8/IDA-1.5); Wed, 14 Feb 1996 12:02:35 +0100 Date: Wed, 14 Feb 1996 12:02:35 +0100 Message-Id: <199602141102.AA29188@diva.gmd.de> From: Joerg.Hoehle@gmd.de (Joerg Hoehle) To: ADE GCC List , Amiga GCC List Subject: Re: Amiga-specific attributes implemented as keywords In-Reply-To: References: <199602130949.AA28677@diva.gmd.de> Kamil Iskra writes: > > Unluckily, stack growth is currently at function entry, not within > > ("call function with at least 40KB (dynamically computed) of stack"). > > What do you mean? I don't really follow you... I mean that usually, you want something like the following: in function A: "oh, this is our input, it's so complex that we'll need ... compute stack size as a function of the input ... ah, 40KB of stack before calling function B, so let's reserve that much and call B so that it'll have enough." and not: at function entry of B: "oh, well, I probably need a bigger stack, but how much, 2KB, 10KB or 100KB?" Unfortunately, the latter is what stackextend gives you. Currently, you could be smart and set the stackextend variable to 100KB in A and reset it to a normal 4KB in B, so that at entry of B, the stack will be extended if it's not already 100KB in size. But this splitting among two functions is cumbersome. You need to reset the variable in B because you don't want every other function called by B to reserve 100KB again. Bye, Joerg Hoehle. Joerg.Hoehle@gmd.de hoehle@zeus.gmd.de From amiga-gcc-port-owner@nic.funet.fi Wed Feb 14 13:25:23 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1412-21838>; Wed, 14 Feb 1996 13:24:49 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA11663; Wed, 14 Feb 1996 11:28:27 +0100 Date: Wed, 14 Feb 1996 11:28:26 +0100 (MET) From: Kamil Iskra To: Sven Heithecker cc: Sven Heithecker Subject: Re: Re^2: Errors in new inlines In-Reply-To: <9602131901.AA47980@rzrtr1.rz.tu-bs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 13 Feb 1996, Sven Heithecker wrote: > void FreeApp(struct ObjApp *Object) > { > MUI_DisposeObject(Object->App); > } > When compiled with gcc -O1 testapp.c it gave > > muitest.c: In function `FreeApp': > muitest.c:14: `_MUI_DisposeObject_v1' undeclared (first use this function) > muitest.c:14: (Each undeclared identifier is reported only once > muitest.c:14: for each function it appears in.) > muitest.c:14: syntax error before `*' > muitest.c:14: `_n1' undeclared (first use this function) I'm sitting in front of Sun, so I can't check it using Amiga GCC at the moment, but I can think about one possible reason of your problem: you called argument of FreeApp() "Object", and there is a type called "Object", too. Please try to rename argument name. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Feb 14 13:25:42 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1941-21838>; Wed, 14 Feb 1996 13:25:15 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA11770; Wed, 14 Feb 1996 11:29:43 +0100 Date: Wed, 14 Feb 1996 11:29:43 +0100 (MET) From: Kamil Iskra To: Joerg Hoehle cc: ADE GCC List , Amiga GCC List Subject: Re: Amiga-specific attributes implemented as keywords In-Reply-To: <199602130949.AA28677@diva.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 13 Feb 1996, Joerg Hoehle wrote: > Unluckily, stack growth is currently at function entry, not within > ("call function with at least 40KB (dynamically computed) of stack"). What do you mean? I don't really follow you... / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Feb 14 13:26:18 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1872-21964>; Wed, 14 Feb 1996 13:25:56 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA13865; Wed, 14 Feb 1996 12:27:25 +0100 Date: Wed, 14 Feb 1996 12:27:25 +0100 (MET) From: Kamil Iskra To: ADE GCC List cc: Amiga GCC List Subject: Passing arguments in registers - first attempt. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I managed to implement passing arguments in registers using GCC 2.7.0. It turned out to be very easy - GCC has full support for this. As of now, it works like this: By default GCC passes arguments on stack. If you specify "-mregparm" argument, GCC passes two first integer arguments in d0/d1 and two first pointers in a0/a1. Currently this is not very useful, since IXEmul and Libnix do not support this way of passing arguments. That's why I won't include patch in this posting - it's too preliminary (however, patch is available on my WWW page for those of you, who would like to see how it works. Pre-compiled cc1 is available, as well). I made a few simple tests and it seems that with optimisation turned off GCC produces very poor code for passing arguments in registers - it basically copies arguments from registers to stack on function entry. However, with optimisation turned on, code quality improves. I think that this posting should be the beginning of serious discussion about details of passing arguments in registers. I think that the most important things that should be addressed are: 1. How to distinguish register calls from stack calls (i.e. how linker should distinguish them)? 2.a. What should be the exact way of passing arguments in registers? 2.b. Like I did it, ie. two first integers in d0/d1, two first pointers in a0/a1, rest on stack? 2.c. Maybe we should use fp0/fp1 for floating point arguments? 2.d. Maybe there should be a default setting, which user can override by specifieng "-mregparm=", where number is (for example) amount of register to use for each group of parameters (ie. 2 by default). 3. How should library calls be made? Should there be two entries for each function in every library? But this will result in worse code for stack calls than currently. And how to implement it in IXEmul? 4. I think that SAS/C compatible __stdargs and __regargs keywords should be implemented. If the latter one was specified as GCC attribute, it would be possible to provide argument (see above), like this: void func() __attribute__ ((regargs(3))); Have I forgotten about something? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Feb 14 13:44:14 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1623-21964>; Wed, 14 Feb 1996 13:43:43 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA14784; Wed, 14 Feb 1996 12:45:35 +0100 Date: Wed, 14 Feb 1996 12:45:34 +0100 (MET) From: Kamil Iskra To: Joerg Hoehle cc: ADE GCC List , Amiga GCC List Subject: Re: Amiga-specific attributes implemented as keywords In-Reply-To: <199602141102.AA29188@diva.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 14 Feb 1996, Joerg Hoehle wrote: > I mean that usually, you want something like the following: > > in function A: > "oh, this is our input, it's so complex that we'll need > ... compute stack size as a function of the input ... > ah, 40KB of stack before calling function B, so let's reserve > that much and call B so that it'll have enough." > > and not: > at function entry of B: > "oh, well, I probably need a bigger stack, but how much, 2KB, 10KB > or 100KB?" > > Unfortunately, the latter is what stackextend gives you. Is it? Maybe I still don't understand you (quite probable :-), but as far as I remember, stackext does the following: At function entry it calls a stack extension function with one argument: the amount of stack this function needs for frame. Stack extension function takes care of allocating new stack chunk if current is not big enough, setting up frame etc. The same happens when program wants to call alloca(). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Wed Feb 14 16:20:04 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <1443-21838>; Wed, 14 Feb 1996 16:18:45 +0200 Received: from tycho.gbar.dtu.dk (tycho.gbar.dtu.dk [130.225.87.183]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id PAA15213; Wed, 14 Feb 1996 15:18:31 +0100 (MET) Received: (from c948374@localhost) by tycho.gbar.dtu.dk (8.7.3/8.7.3) id PAA25992; Wed, 14 Feb 1996 15:18:32 +0100 (MET) Date: Wed, 14 Feb 1996 15:18:31 +0100 (MET) From: Rask Ingemann Lambertsen To: Kamil Iskra cc: ADE GCC List , Amiga GCC List Subject: Re: Passing arguments in registers - first attempt. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 14 Feb 1996, Kamil Iskra wrote: > I made a few simple tests and it seems that with optimisation turned off > GCC produces very poor code for passing arguments in registers I would describe that as correct behaviour. If you want efficient code, you *do* turn on optimization. > 1. How to distinguish register calls from stack calls (i.e. how linker > should distinguish them)? Since so many (two?) people have been worried about compatibility with existing link libraries, I suggest using '@' instead of '_' in symbol names for functions taking arguments in registers. This may give compatibility with DICE (SAS/Lattice too?). The only problem is that the current assembler will most likely complain about that (I think I tried this once) because it uses the MIT syntax. Is there any good reason for not switching to the (much more readable, IMHO) Motorola syntax? > 2.a. What should be the exact way of passing arguments in registers? > > 2.b. Like I did it, ie. two first integers in d0/d1, two first pointers in > a0/a1, rest on stack? An easy solution, but what if I want to pass three pointers and one integer? Then it would be smarter to use one of the data registers for one of the pointers instead of passing it on the stack. > 2.c. Maybe we should use fp0/fp1 for floating point arguments? For FPU compiled code that sounds like a good idea to me. > 2.d. Maybe there should be a default setting, which user can override by > specifieng "-mregparm=", where number is (for example) amount of > register to use for each group of parameters (ie. 2 by default). I say: "Yes", because I'd probably need a few more arguments passed in registers. > 3. How should library calls be made? Should there be two entries for each > function in every library? But this will result in worse code for stack > calls than currently. I don't think that is a good idea. It's better to use separate link libraries for that. > And how to implement it in IXEmul? ??? Where does ixemul come into this? > 4. I think that SAS/C compatible __stdargs and __regargs keywords should > be implemented. If the latter one was specified as GCC attribute, it would > be possible to provide argument (see above), like this: > > void func() __attribute__ ((regargs(3))); I'm not sure about that, if that is used, the code would be much harder to compile with other compilers. > Have I forgotten about something? Yes, telling your webmaster to install a faster line to DTU ;-) Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Feb 14 18:53:10 1996 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with ESMTP id <1532-21964>; Wed, 14 Feb 1996 18:51:02 +0200 Received: from newzetor.clinet.fi (root@newzetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id SAA21684; Wed, 14 Feb 1996 18:49:55 +0200 (EET) Received: (will@localhost) by newzetor.clinet.fi (8.7.3/8.6.4) id SAA08066; Wed, 14 Feb 1996 18:49:59 +0200 (EET) Date: Wed, 14 Feb 1996 18:49:59 +0200 (EET) Message-Id: <199602141649.SAA08066@newzetor.clinet.fi> From: Ville-Pertti Keinonen To: c948374@student.dtu.dk CC: kiskra@ernie.icslab.agh.edu.pl, ade-gcc@amigalib.com, amiga-gcc-port@nic.funet.fi In-reply-to: (message from Rask Ingemann Lambertsen on Wed, 14 Feb 1996 15:18:31 +0100 (MET)) Subject: Re: Passing arguments in registers - first attempt. existing link libraries, I suggest using '@' instead of '_' in symbol names for functions taking arguments in registers. This may give compatibility with DICE (SAS/Lattice too?). The only problem is that the current assembler will most likely complain about that (I think I tried That would also require that the registers would be chosen exactly the same. Another scheme that shouldn't cause serious conflicts with C code or problems with the assembler would be using _ combined with something else, eg. having a character before the _ or for less likely conflict with asm sources a digit after it (eg. _0func is probably weird enough not to be used in asm sources, nor can it be a C symbol, since the symbol part begins with a digit). this once) because it uses the MIT syntax. Is there any good reason for not switching to the (much more readable, IMHO) Motorola syntax? Here are a few reasons: - It would cause huge problems with existing code, none of the converters I've seen actually produce functional code (of course most of the tests were the other way around) and converters won't help for asm ()-portions within code. - Having heavily modified (from the fsf releases) cc1 and as programs would probably generate problems with maintenance. Replacing as completely would require a lot of work to get the GNU binutils functionality back. Of course for Amiga-specific programming a Motorola-syntax cc1 + some existing Amiga assembler + linker could be used, but hopefully such a system would be separate from the Amiga GCC port. - Some people like the MIT syntax and/or are used to using it. From amiga-gcc-port-owner@nic.funet.fi Wed Feb 14 18:59:04 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <1889-21964>; Wed, 14 Feb 1996 18:58:37 +0200 Received: from srv3.gbar.dtu.dk (srv3.gbar.dtu.dk [130.225.87.163]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id RAA16902; Wed, 14 Feb 1996 17:58:22 +0100 (MET) Received: (from c948374@localhost) by srv3.gbar.dtu.dk (8.7.3/8.7.3) id RAA14854; Wed, 14 Feb 1996 17:58:24 +0100 (MET) Date: Wed, 14 Feb 1996 17:58:23 +0100 (MET) From: Rask Ingemann Lambertsen To: Ville-Pertti Keinonen cc: kiskra@ernie.icslab.agh.edu.pl, ade-gcc@amigalib.com, amiga-gcc-port@nic.funet.fi Subject: Re: Passing arguments in registers - first attempt. In-Reply-To: <199602141649.SAA08066@newzetor.clinet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 14 Feb 1996, Ville-Pertti Keinonen wrote: > this once) because it uses the MIT syntax. Is there any good reason for > not switching to the (much more readable, IMHO) Motorola syntax? > > Here are a few reasons: > > - It would cause huge problems with existing code, none of the > converters I've seen actually produce functional code (of course most > of the tests were the other way around) and converters won't help for > asm ()-portions within code. I don't understand it at all. Converters? For what? > - Having heavily modified (from the fsf releases) cc1 and as programs > would probably generate problems with maintenance. cc1 already supports Motorola syntax! Only as seems to be a problem. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Feb 14 19:08:34 1996 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with ESMTP id <1458-21999>; Wed, 14 Feb 1996 19:07:24 +0200 Received: from newzetor.clinet.fi (root@newzetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id TAA22167; Wed, 14 Feb 1996 19:06:39 +0200 (EET) Received: (will@localhost) by newzetor.clinet.fi (8.7.3/8.6.4) id TAA08525; Wed, 14 Feb 1996 19:06:41 +0200 (EET) Date: Wed, 14 Feb 1996 19:06:41 +0200 (EET) Message-Id: <199602141706.TAA08525@newzetor.clinet.fi> From: Ville-Pertti Keinonen To: c948374@student.dtu.dk CC: kiskra@ernie.icslab.agh.edu.pl, ade-gcc@amigalib.com, amiga-gcc-port@nic.funet.fi In-reply-to: (message from Rask Ingemann Lambertsen on Wed, 14 Feb 1996 17:58:23 +0100 (MET)) Subject: Re: Passing arguments in registers - first attempt. I don't understand it at all. Converters? For what? For converting assembly language sources to and from the MIT and Motorola syntaxes. cc1 already supports Motorola syntax! Only as seems to be a problem. I thought the support was incomplete, or was it just not-quite-compatible with Amiga assemblers... From amiga-gcc-port-owner@nic.funet.fi Wed Feb 14 19:22:13 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <2038-21981>; Wed, 14 Feb 1996 19:20:49 +0200 Received: from srv3.gbar.dtu.dk (srv3.gbar.dtu.dk [130.225.87.163]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id SAA17125; Wed, 14 Feb 1996 18:20:31 +0100 (MET) Received: (from c948374@localhost) by srv3.gbar.dtu.dk (8.7.3/8.7.3) id SAA17544; Wed, 14 Feb 1996 18:20:32 +0100 (MET) Date: Wed, 14 Feb 1996 18:20:31 +0100 (MET) From: Rask Ingemann Lambertsen To: ade-gcc@amigalib.com, amiga-gcc-port@nic.funet.fi Subject: Re: Passing arguments in registers - first attempt. In-Reply-To: <199602141706.TAA08525@newzetor.clinet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 14 Feb 1996, Ville-Pertti Keinonen wrote: > I don't understand it at all. Converters? For what? > > For converting assembly language sources to and from the MIT and > Motorola syntaxes. We won't need any converters since we'll be using only one syntax. > cc1 already supports Motorola syntax! Only as seems to be a problem. > > I thought the support was incomplete, or was it just > not-quite-compatible with Amiga assemblers... I don't know how Amiga assemblers handle the output. Getting cc1 to output Motorola syntax requires a recompile. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Feb 15 10:29:32 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1220-27642>; Thu, 15 Feb 1996 10:27:01 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id JAA22377; Thu, 15 Feb 1996 09:28:58 +0100 Date: Thu, 15 Feb 1996 09:28:58 +0100 (MET) From: Kamil Iskra To: Rask Ingemann Lambertsen cc: ADE GCC List , Amiga GCC List Subject: Re: Passing arguments in registers - first attempt. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 14 Feb 1996, Rask Ingemann Lambertsen wrote: > > 2.b. Like I did it, ie. two first integers in d0/d1, two first pointers in > > a0/a1, rest on stack? > An easy solution, but what if I want to pass three pointers and one > integer? Then it would be smarter to use one of the data registers for > one of the pointers instead of passing it on the stack. This is rather hard to implement using features provided by GCC developers (you only get information about current argument and about prebiously passed ones - you know nothing about the next ones). I think that in such case, you should explicitly state in which registers you want arguments to be passed. I forgot to mention it, but that's actually why I started working on implementing passing arguments in registers - to make programming of hooks or SetPatch() using programs much easier. > > 2.d. Maybe there should be a default setting, which user can override by > > specifieng "-mregparm=", where number is (for example) amount of > > register to use for each group of parameters (ie. 2 by default). > I say: "Yes", because I'd probably need a few more arguments passed in > registers. But, as Niels Moeller pointed out in his posting, implementing library calls would become a nightmare. Should there be a separate library for every possible "-mregparm="? I'm beginning to think that this is not a good idea - if you want more than two data/addres/float registers, you should state it explicitly - which argument in which register (this is not currently possible, but will be). What do you think? > > And how to implement it in IXEmul? > ??? Where does ixemul come into this? IXEmul is not a linker library, it's a shared, runtime library. I don't know what is the actual format of calling functions in IXEmul. I guess they are all in jumptable, like in other libraries, but unlike them they pass arguments on stack. Hans, am I right? How are IXEmul functions called - using stubs in "libc.a" or using some kind of "inlines"? Trivial implementation of using regargs with IXEmul would require passing arguments from registers to stack - silly, isn't it? Better implementation would require two separate entries for every function in IXEmul jumptable - one for regparms, one for stackparms, I guess. > > void func() __attribute__ ((regargs(3))); > I'm not sure about that, if that is used, the code would be much harder > to compile with other compilers. Of course, syntax accepted by other Amiga compilers would be accepted, as well. I.e. you could write: void __regargs func(); Which would be the same as __attribute__ ((regargs)). Explicit using of GCC __attribute__ would be required only for maniacks like you (no offence :-), who want to pass arguments in more than 4 registers. > > Have I forgotten about something? > Yes, telling your webmaster to install a faster line to DTU ;-) Poland has only 2 Mbps connection with outside world, through Sweden. You can write a letter of complaint to our Internet Provider, NASK (but don't mention my name - they don't particularly like students creating traffic on international lines :-). / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Feb 15 10:33:24 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1428-27642>; Thu, 15 Feb 1996 10:33:05 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id JAA22573; Thu, 15 Feb 1996 09:34:58 +0100 Date: Thu, 15 Feb 1996 09:34:58 +0100 (MET) From: Kamil Iskra To: Rask Ingemann Lambertsen cc: ade-gcc@amigalib.com, amiga-gcc-port@nic.funet.fi Subject: Re: Passing arguments in registers - first attempt. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 14 Feb 1996, Rask Ingemann Lambertsen wrote: > I don't know how Amiga assemblers handle the output. Getting cc1 to > output Motorola syntax requires a recompile. But I'm not really sure if this is exactly the same syntax as used by Amiga assemblers. I think there are some differences in names of instructions. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Feb 15 14:35:42 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <1513-27642>; Thu, 15 Feb 1996 14:34:10 +0200 Received: from DBSTU1.RZ.TU-BS.DE by funet.fi with SMTP (PP); Thu, 15 Feb 1996 14:34:03 +0200 Received: from rzrtr1.rz.tu-bs.de by DBSTU1.RZ.TU-BS.DE (IBM VM SMTP V2R2) with TCP; Thu, 15 Feb 96 13:34:06 MEZ Received: by rzrtr1.rz.tu-bs.de (AIX 4.1/UCB 5.64/4.03) id AA94518; Thu, 15 Feb 1996 13:32:42 +0100 From: y0000135@ws.rz.tu-bs.de (Sven Heithecker) Message-Id: <9602151232.AA94518@rzrtr1.rz.tu-bs.de> Subject: Re: Reopening Window on other screens To: amiga-gcc-port@nic.funet.fi (Sven Heithecker) Date: Thu, 15 Feb 1996 13:32:41 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1389 From: Sven Heithecker Subject: Re: Reopening Window on other screens >> Sven Heithecker schrieb in einer persoenlichen Nachricht ueber "Re: > Reopening Window on other screens": > > SH>working on another screen. Now I want to open that commodity-window > SH>again (maybe I want to look for meals at other days). What do I ? I > SH>press the hotkey again. What happens ? Nothing, execpt that the old > > Maybe pressing the hotkey again should cause the program doing a screen to > front? This would be a posibility too, but by far not the best (see below) > SH>hotkey) that the window is not at the frontmost screen anymore, so the > SH>window is moved to the new screen (by closing and opening again). > > But this isnt bad, too. Causing switching to the old screen as suggested > above, causes you to loose the program window you worked in before > pressing the hotkey. And more: If you work with different scan-rates switching screens takes a while to resyncronize. This is annoying. > Let the sun shine... \__Mail| Usenet: steigerw@stud.uni-frankfurt.de > |_| _ |o _ _ Martin \__ | WWW-Homepage: > | |(/_||(_)_> Steigerwald \| http://www.rz.uni-frankfurt.de/~steigerw > > Augentraining - Die Welt klar sehen. ____ |_||_ Ceterum Censeo MEGAHARD Esse Delendam | | _| HTS Sven Heithecker s.heithecker@tu-bs.de From amiga-gcc-port-owner@nic.funet.fi Thu Feb 15 18:59:01 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <1978-24608> convert rfc822-to-8bit; Thu, 15 Feb 1996 18:56:07 +0200 Received: from tycho.gbar.dtu.dk (tycho.gbar.dtu.dk [130.225.87.183]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id RAA29759; Thu, 15 Feb 1996 17:55:45 +0100 (MET) Received: (from c948374@localhost) by tycho.gbar.dtu.dk (8.7.3/8.7.3) id RAA03730; Thu, 15 Feb 1996 17:55:46 +0100 (MET) Date: Thu, 15 Feb 1996 17:55:46 +0100 (MET) From: Rask Ingemann Lambertsen To: Kamil Iskra cc: ADE GCC List , Amiga GCC List Subject: Re: Passing arguments in registers - first attempt. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 15 Feb 1996, Kamil Iskra wrote: > On Wed, 14 Feb 1996, Rask Ingemann Lambertsen wrote: > > > > 2.b. Like I did it, ie. two first integers in d0/d1, two first pointers in > > > a0/a1, rest on stack? > > An easy solution, but what if I want to pass three pointers and one > > integer? Then it would be smarter to use one of the data registers for > > one of the pointers instead of passing it on the stack. > > This is rather hard to implement using features provided by GCC developers > (you only get information about current argument and about prebiously > passed ones - you know nothing about the next ones). That is actually sufficent for a simple implementation, like the one in DICE. > I think that in such > case, you should explicitly state in which registers you want arguments to > be passed. Do you want me to hack the whole GCC source just because I want it compiled with arguments passed in registers? I hope not :-) > I forgot to mention it, but that's actually why I started > working on implementing passing arguments in registers - to make > programming of hooks or SetPatch() using programs much easier. Although that is not what I originally intended, it would be nice to have too. > > > 2.d. Maybe there should be a default setting, which user can override by > > > specifieng "-mregparm=", where number is (for example) amount of > > > register to use for each group of parameters (ie. 2 by default). > > I say: "Yes", because I'd probably need a few more arguments passed in > > registers. > > But, as Niels Moeller pointed out in his posting, implementing library > calls would become a nightmare. Should there be a separate library for > every possible "-mregparm="? I'm beginning to think that this is > not a good idea - if you want more than two data/addres/float registers, > you should state it explicitly - which argument in which register (this > is not currently possible, but will be). What do you think? I think people should be allowed to use their *own* brains when compiling/linking. It won't hurt them ;-) In other words, let the person who compiles the code decide how many arguments to pass in registers. Fixing the number of registers used will look like brain dammage if you don't use link libraries at all. > Trivial implementation of using regargs with IXEmul would require > passing arguments from registers to stack - silly, isn't it? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That is what happens when using stack based calls. Yes, it is silly. Why do you think I wanted register based calls in the first place? ;-) > Better implementation > would require two separate entries for every function in IXEmul jumptable > - one for regparms, one for stackparms, I guess. Best (?) implementation would be inline headers for IXEmul calls which pushe the arguments on the stack, since ixemul.library expects them there. > > > void func() __attribute__ ((regargs(3))); > > I'm not sure about that, if that is used, the code would be much harder > > to compile with other compilers. > > Of course, syntax accepted by other Amiga compilers would be accepted, as > well. I.e. you could write: > > void __regargs func(); > > Which would be the same as __attribute__ ((regargs)). > > Explicit using of GCC __attribute__ would be required only for maniacks > like you (no offence :-), who want to pass arguments in more than 4 > registers. No offence taken :-) I'd just like to keep the door open for other compilers. That is why I want an command line option for the number of registers to use. Hell, if somebody then wanted to recompile the source with stack based calls, even that would be possible without hacking the code. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Feb 15 21:16:25 1996 Received: from hauki.clinet.fi ([194.100.0.1]) by nic.funet.fi with ESMTP id <1790-27642>; Thu, 15 Feb 1996 21:14:53 +0200 Received: from newzetor.clinet.fi (root@newzetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id VAA01423; Thu, 15 Feb 1996 21:14:13 +0200 (EET) Received: (will@localhost) by newzetor.clinet.fi (8.7.3/8.6.4) id VAA09154; Thu, 15 Feb 1996 21:14:14 +0200 (EET) Date: Thu, 15 Feb 1996 21:14:14 +0200 (EET) Message-Id: <199602151914.VAA09154@newzetor.clinet.fi> From: Ville-Pertti Keinonen To: c948374@student.dtu.dk CC: ade-gcc@amigalib.com, amiga-gcc-port@nic.funet.fi In-reply-to: (message from Rask Ingemann Lambertsen on Wed, 14 Feb 1996 18:20:31 +0100 (MET)) Subject: Re: Passing arguments in registers - first attempt. We won't need any converters since we'll be using only one syntax. My point was *existing software*. One of the original ideas behind the Amiga port of gcc was to be able to compile much of the GNU and other portable software available (that's why there's an ixemul.library). Both assembly-language sources and asm ()-portions within C code would generate problems if MIT asm couldn't be dealt with. From amiga-gcc-port-owner@nic.funet.fi Fri Feb 16 09:48:28 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1829-27615>; Fri, 16 Feb 1996 09:47:22 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id IAA18687; Fri, 16 Feb 1996 08:49:26 +0100 Date: Fri, 16 Feb 1996 08:49:26 +0100 (MET) From: Kamil Iskra To: Rask Ingemann Lambertsen cc: ADE GCC List , Amiga GCC List Subject: Re: Passing arguments in registers - first attempt. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 15 Feb 1996, Rask Ingemann Lambertsen wrote: > > I think that in such > > case, you should explicitly state in which registers you want arguments to > > be passed. > > Do you want me to hack the whole GCC source just because I want it compiled > with arguments passed in registers? I hope not :-) Yes, I DO want you to hack the whole GCC source in such case :-). Keep in mind, that this wouldn't be normally necessary - it would be necessary only if you wanted ALL arguments to be passed in registers. If somebody has so extraordinary requirements he won't mind spending a few months patching GCC sources, will he? :-) > > But, as Niels Moeller pointed out in his posting, implementing library > > calls would become a nightmare. Should there be a separate library for > > every possible "-mregparm="? I'm beginning to think that this is > > not a good idea - if you want more than two data/addres/float registers, > > you should state it explicitly - which argument in which register (this > > is not currently possible, but will be). What do you think? > I think people should be allowed to use their *own* brains when > compiling/linking. Very wise. > It won't hurt them ;-) Only if they have good quality brains :-) > In other words, let the person > who compiles the code decide how many arguments to pass in registers. Fixing > the number of registers used will look like brain dammage if you don't > use link libraries at all. Maybe you are right. After all, baseline GCC contains several options which are not supported by most OSes, like "rtd" return etc. They just don't hurt as long as they are disabled by default. BTW: how is it possible not to use link libraries *at all*? Do you use your own startup code, or what? > > Trivial implementation of using regargs with IXEmul would require > > passing arguments from registers to stack - silly, isn't it? > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > That is what happens when using stack based calls. Yes, it is silly. Why do > you think I wanted register based calls in the first place? ;-) What I ment was that you would call a stub in "libc.a" using regargs, this stub would pass arguments from registers to stack (like "libamiga.a", but the other way round). > Best (?) implementation would be inline headers for IXEmul calls which > pushe the arguments on the stack, since ixemul.library expects them > there. You've got a point... Hans, what do you think? > No offence taken :-) I'd just like to keep the door open for other compilers. > That is why I want an command line option for the number of registers to use. > Hell, if somebody then wanted to recompile the source with stack based > calls, even that would be possible without hacking the code. You've got a point again... / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Feb 16 10:10:48 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <1872-15544>; Fri, 16 Feb 1996 10:09:50 +0200 Received: from lillep.gbar.dtu.dk (lillep.gbar.dtu.dk [130.225.87.179]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id JAA05137; Fri, 16 Feb 1996 09:09:35 +0100 (MET) Received: (from c948374@localhost) by lillep.gbar.dtu.dk (8.7.3/8.7.3) id JAA15769; Fri, 16 Feb 1996 09:09:36 +0100 (MET) Date: Fri, 16 Feb 1996 09:09:36 +0100 (MET) From: Rask Ingemann Lambertsen To: Kamil Iskra cc: ADE GCC List , Amiga GCC List Subject: Re: Passing arguments in registers - first attempt. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Fri, 16 Feb 1996, Kamil Iskra wrote: > On Thu, 15 Feb 1996, Rask Ingemann Lambertsen wrote: > > BTW: how is it > possible not to use link libraries *at all*? Do you use your own startup > code, or what? Yes, a very minimal one and Amiga specific. I'll soon include a fork() like function in it so it will be easy to create multiple treads. Since OS calls are done using your excellent inline headers, I end up not using a single link library at all. > > > Trivial implementation of using regargs with IXEmul would require > > > passing arguments from registers to stack - silly, isn't it? > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > That is what happens when using stack based calls. Yes, it is silly. Why do > > you think I wanted register based calls in the first place? ;-) > > What I ment was that you would call a stub in "libc.a" using regargs, this > stub would pass arguments from registers to stack (like "libamiga.a", but > the other way round). Ah, yes, that should be easy. I guess it wouldn't hurt performance since the arguments have to be put on the stack whichever way you make IXEmul calls. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Feb 16 10:19:47 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1258-15544>; Fri, 16 Feb 1996 10:19:35 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id JAA19723; Fri, 16 Feb 1996 09:20:49 +0100 Date: Fri, 16 Feb 1996 09:20:48 +0100 (MET) From: Kamil Iskra To: ADE GCC List cc: Amiga GCC List , fleischr@IZFM.Uni-Stuttgart.DE Subject: Passing arguments in registers and stack checking/extension Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII *Note: Sorry if this is a repost. Pine hanged when I was sending this mail for the first time and I don't know if it hanged before or after the mail was sent* I found a big problem with passing arguments in registers and using stack checking or extension simultaneously. Stack checking/extension code changes values of d0/d1/a0/a1, while these registers are used to pass arguments when using "-mregparm". Matthias, would it be hard to redesign stack checking/extension in such a way that it preserved these registers? If yes, I guess stack checking/extension code just wouldn't be generated for regargs functions... This would unfortunately make "-mregparm" unusable for stack-hungry programs, ie. most GNU tools. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Feb 16 10:25:43 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1637-20217>; Fri, 16 Feb 1996 10:25:22 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id JAA19773; Fri, 16 Feb 1996 09:23:25 +0100 Date: Fri, 16 Feb 1996 09:23:24 +0100 (MET) From: Kamil Iskra To: Rask Ingemann Lambertsen cc: ADE GCC List , Amiga GCC List Subject: Re: Passing arguments in registers - first attempt. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 16 Feb 1996, Rask Ingemann Lambertsen wrote: > > What I ment was that you would call a stub in "libc.a" using regargs, this > > stub would pass arguments from registers to stack (like "libamiga.a", but > > the other way round). > > Ah, yes, that should be easy. I guess it wouldn't hurt performance since > the arguments have to be put on the stack whichever way you make IXEmul > calls. This would hurt performance in exactly the same way as stubs in libamiga.a do: unnecessary function call, unnecessary "fiddling" with registers or stack. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Feb 16 10:31:52 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <1246-24992>; Fri, 16 Feb 1996 10:31:20 +0200 Received: from lillep.gbar.dtu.dk (lillep.gbar.dtu.dk [130.225.87.179]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id JAA05508; Fri, 16 Feb 1996 09:31:07 +0100 (MET) Received: (from c948374@localhost) by lillep.gbar.dtu.dk (8.7.3/8.7.3) id JAA16083; Fri, 16 Feb 1996 09:31:09 +0100 (MET) Date: Fri, 16 Feb 1996 09:31:08 +0100 (MET) From: Rask Ingemann Lambertsen To: Kamil Iskra cc: ADE GCC List , Amiga GCC List Subject: Re: Passing arguments in registers - first attempt. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Fri, 16 Feb 1996, Kamil Iskra wrote: > On Fri, 16 Feb 1996, Rask Ingemann Lambertsen wrote: > > > > What I ment was that you would call a stub in "libc.a" using regargs, this > > > stub would pass arguments from registers to stack (like "libamiga.a", but > > > the other way round). > > > > Ah, yes, that should be easy. I guess it wouldn't hurt performance since > > the arguments have to be put on the stack whichever way you make IXEmul > > calls. > > This would hurt performance in exactly the same way as stubs in libamiga.a > do: unnecessary function call, unnecessary "fiddling" with registers or > stack. Yes, what I ment was that it won't hurt more than it already does because IXEmul calls use stub functions already. Inline headers would be faster for sure. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Feb 16 11:40:58 1996 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <1271-24992>; Fri, 16 Feb 1996 11:40:17 +0200 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id KAA22409 (8.6.12/IDA-1.6 for ); Fri, 16 Feb 1996 10:40:09 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA10532; Fri, 16 Feb 96 10:40:08 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9602160940.AA10532@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Passing arguments in registers and stack checking/extension To: amiga-gcc-port@nic.funet.fi Date: Fri, 16 Feb 1996 10:40:08 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1962 Kamil Iskra wrote: > > I found a big problem with passing arguments in registers and using stack > checking or extension simultaneously. > > Stack checking/extension code changes values of d0/d1/a0/a1, while these > registers are used to pass arguments when using "-mregparm". > > Matthias, would it be hard to redesign stack checking/extension in such a > way that it preserved these registers? > No. I think a redesign of the stack checking/extension functions that are called by gcc directly should be easy. Those functions are only very small assembly stubs that check the current stackframe's size and return almost immediately if it suffices. If not then the real work is done by another layer of functions (see below). E.g. for ixemul.library this means that only _those_ functions are shared library functions. The bulk of strange looking pseudo assembly instructions are statically linked for speed. So much for how it works ;-). What do you have in mind for the new stack extension design? Matthias ___stkext(d0) Prepares a new stackframe with a minimum of d0 free bytes left. Returns on the new stackframe. Preserves all registers ___stkext_f(d0,d1) Similar to the previous one, but this function copies the arguments of the caller and everything on top of them. d1 must be the offset (in bytes) of the caller's returnaddress relative to sp. This returnaddress is replaced by a cleanup function's address (no explicit cleanup necessary). Preserves all registers ___stkrst(d0) Similar to 'movel d0,sp'. Falls back to an old stackframe if necessary. Preserves all registers. ___stkovf(void) Is the stack overflow handler (called if there is not enough memory to extend the stack further and the program has to be aborted). Does not return. Additionally you find the current limit of the stack in void *___stk_limit; Note that this doesn't point to the lower stack boundary but leaves some safety zone. From amiga-gcc-port-owner@nic.funet.fi Fri Feb 16 12:09:46 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1503-15544>; Fri, 16 Feb 1996 12:08:34 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id LAA22928; Fri, 16 Feb 1996 11:09:34 +0100 Date: Fri, 16 Feb 1996 11:09:33 +0100 (MET) From: Kamil Iskra To: Matthias Fleischer cc: amiga-gcc-port@nic.funet.fi, ADE GCC List Subject: Re: Passing arguments in registers and stack checking/extension In-Reply-To: <9602160940.AA10532@sunserv.IZFM.Uni-Stuttgart.DE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 16 Feb 1996, Matthias Fleischer wrote: > No. I think a redesign of the stack checking/extension functions that > are called by gcc directly should be easy. Those functions are > only very small assembly stubs that check the current stackframe's > size and return almost immediately if it suffices. If not then the real > work is done by another layer of functions (see below). E.g. for > ixemul.library this means that only _those_ functions are shared library > functions. The bulk of strange looking pseudo assembly instructions > are statically linked for speed. So much for how it works ;-). > > What do you have in mind for the new stack extension design? Well, I don't know, I haven't thought much about it. I think the big problem is that this small functions like __link_a5_d0, __sub_a7_d0 or __stkchk_d0 (or whatever they're called) expect argument in d0. However, d0 is used to pass argument to user's function, so it can't be used as argument for stack checking/extension functions. So it seems that incompatible modification in GCC stack checking/extension handling code would be needed - that's why I decided to write about it. My knowledge of assembler is rather poor, so I'm afraid I won't be able to do this kind of modification. I think this would have to be made quite quickly - before IXEmul 43.0 with stack checking/extension support is out. Could you do it, please? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Fri Feb 16 12:58:32 1996 Received: from pobox.csc.fi ([128.214.46.62]) by nic.funet.fi with ESMTP id <1751-20217>; Fri, 16 Feb 1996 12:56:52 +0200 Received: from noc.belwue.de (root@noc.BelWue.DE [129.143.2.1]) by pobox.csc.fi (8.6.9/8.6.9+CSC-2.0) with ESMTP id KAA01305 for ; Fri, 16 Feb 1996 10:56:34 GMT Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id LAA15380 (8.6.12/IDA-1.6 for ); Fri, 16 Feb 1996 11:50:10 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA10759; Fri, 16 Feb 96 11:50:09 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9602161050.AA10759@sunserv.IZFM.Uni-Stuttgart.DE> Subject: Re: Passing arguments in registers and stack checking/extension To: amiga-gcc-port@nic.funet.fi Date: Fri, 16 Feb 1996 11:50:09 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1272 > > What do you have in mind for the new stack extension design? > > I think the big problem is that this small functions like __link_a5_d0, > __sub_a7_d0 or __stkchk_d0 (or whatever they're called) expect argument in > d0. However, d0 is used to pass argument to user's function, so it can't > be used as argument for stack checking/extension functions. That's true. But if you use stack based arguments for the stackextend functions to get registerized parameters you don't win anything. You only move the overhead of pushing/popping registers out of the normal function call into the stackextend call. I guess any solution that is really fast will need to be very complicated, too :-(. > So it seems > that incompatible modification in GCC stack checking/extension handling > code would be needed - that's why I decided to write about it. As long as it can be based on the low-level stackextend interface any modifications will be compatible. (At least I hope so). > I think this would have to be made quite > quickly - before IXEmul 43.0 with stack checking/extension support is out. No, please. It seems to be stable as it is *now* and I don't think that some quick and dirty changes will do any good. A new interface should be well thought out ;-). Matthias From amiga-gcc-port-owner@nic.funet.fi Sun Feb 18 22:47:42 1996 Received: from k332.feld.cvut.cz ([147.32.192.12]) by nic.funet.fi with SMTP id <1840-10696>; Sun, 18 Feb 1996 22:43:54 +0200 Received: (from mj@localhost) by k332.feld.cvut.cz (8.6.12/8.6.9) id VAA05920 for amiga-gcc-port@nic.funet.fi; Sun, 18 Feb 1996 21:43:44 +0100 From: Martin Mares Message-Id: <199602182043.VAA05920@k332.feld.cvut.cz> Subject: Re: ADE-question To: amiga-gcc-port@nic.funet.fi Date: Sun, 18 Feb 1996 21:43:44 +0100 (MET) In-Reply-To: from "Fred Fish" at Feb 13, 96 08:34:44 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 916 Hello, world! > A very useful thing for someone to do would be to try building PasTeX > from the supplied source. Assuming that works, and that the source > is complete, there would probably be some parts that would be very > useful to merge into the ADE unixtex, such as showdvi for example. > > At one time the ADE unixtex was based on a newer version of TeX than > PasTeX, but I don't know if that is still true or not, if PasTeX has > been updated. In any case, ADE unixtex could also use some updating > from the CTAN archives. If anyone wants, a beta version of my own TeX/MF port is available on ftp://k332.feld.cvut.cz/pub/local/mj/amiga/mjTeX/*. The archives contain only binaries -- sources compilable in someone else's environment will be available soon. Now compiled by SAS/C, but I plan to switch to GCC as soon as register parameters will be available. Distribution policy: GPL. Martin From amiga-gcc-port-owner@nic.funet.fi Mon Feb 19 13:17:33 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1772-19362>; Mon, 19 Feb 1996 13:15:23 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA05421; Mon, 19 Feb 1996 12:16:34 +0100 Date: Mon, 19 Feb 1996 12:16:34 +0100 (MET) From: Kamil Iskra To: Matthias Fleischer cc: amiga-gcc-port@nic.funet.fi, ADE GCC List Subject: Re: Passing arguments in registers and stack checking/extension In-Reply-To: <9602161050.AA10759@sunserv.IZFM.Uni-Stuttgart.DE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 16 Feb 1996, Matthias Fleischer wrote: > > I think the big problem is that this small functions like __link_a5_d0, > > __sub_a7_d0 or __stkchk_d0 (or whatever they're called) expect argument in > > d0. However, d0 is used to pass argument to user's function, so it can't > > be used as argument for stack checking/extension functions. > That's true. But if you use stack based arguments for the stackextend > functions to get registerized parameters you don't win anything. You only > move the overhead of pushing/popping registers out of the normal function > call into the stackextend call. I guess any solution that is really fast > will need to be very complicated, too :-(. You are right. Actually, I'm not aware of any other solution of passing arguments than on stack or registers (or in static storage - but this is complete braindamage) - since none of these seems reasonable, I guess we will have to drop support for register parameters used together with stack checking/extension... Or we can use worse stack checking code in such case - ie. pretend that stack frame will only have 0 bytes - call "__link_a5_0" etc. This wouldn't be as safe as with stackarg calls, but at least it would be possible... The problem would exist during function prologue only - later alloca() calls would be completely safe... > > I think this would have to be made quite > > quickly - before IXEmul 43.0 with stack checking/extension support is out. > No, please. It seems to be stable as it is *now* and I don't think that > some quick and dirty changes will do any good. A new interface should be well > thought out ;-). You are right. I suggested to make it quickly just to protect us against possible future incompatibilities - but indeed it seems that support for stack checking/extension with register parameters can be made in compatible way... / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Feb 19 14:10:37 1996 Received: from delta.mdy.univie.ac.at ([131.130.40.6]) by nic.funet.fi with SMTP id <1944-19362>; Mon, 19 Feb 1996 14:10:07 +0200 Received: from localhost by delta.mdy.univie.ac.at with SMTP (1.38.193.4/16.2) id AA22161; Mon, 19 Feb 1996 13:05:12 +0100 Sender: am@mdy.univie.ac.at Message-Id: <31286777.40D7@mdy.univie.ac.at> Date: Mon, 19 Feb 1996 13:05:11 +0100 From: Alfred Minarik X-Mailer: Mozilla 2.0 (X11; I; HP-UX A.09.05 9000/720) Mime-Version: 1.0 To: Kamil Iskra Cc: Matthias Fleischer , amiga-gcc-port@nic.funet.fi, ADE GCC List Subject: Re: Passing arguments in registers and stack checking/extension References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > On Fri, 16 Feb 1996, Matthias Fleischer wrote: > > > > I think the big problem is that this small functions like __link_a5_d0, > > > __sub_a7_d0 or __stkchk_d0 (or whatever they're called) expect argument in > > > d0. However, d0 is used to pass argument to user's function, so it can't > > > be used as argument for stack checking/extension functions. > > That's true. But if you use stack based arguments for the stackextend > > functions to get registerized parameters you don't win anything. You only > > move the overhead of pushing/popping registers out of the normal function > > call into the stackextend call. I guess any solution that is really fast > > will need to be very complicated, too :-(. > > You are right. Actually, I'm not aware of any other solution of passing > arguments than on stack or registers (or in static storage - but this is > complete braindamage) - since none of these seems reasonable, I guess we > will have to drop support for register parameters used together with stack > checking/extension... To me there seems to be a solution of passing both in registers. As the common sense seems to settle on passing register arguments in d0,d1,a0,a1, you could use d2,(+a2) for the time critical stack checking/extension functions, which should not need other registers then d2,(+a2). Without stack-checking d2,a2 would be free for other needs. Why should this be impossibile ? - Alfred From amiga-gcc-port-owner@nic.funet.fi Mon Feb 19 14:26:14 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1755-20611>; Mon, 19 Feb 1996 14:22:21 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA07615; Mon, 19 Feb 1996 13:23:46 +0100 Date: Mon, 19 Feb 1996 13:23:46 +0100 (MET) From: Kamil Iskra To: Alfred Minarik cc: amiga-gcc-port@nic.funet.fi, ADE GCC List Subject: Re: Passing arguments in registers and stack checking/extension In-Reply-To: <31286777.40D7@mdy.univie.ac.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Feb 1996, Alfred Minarik wrote: > To me there seems to be a solution of passing both in registers. > As the common sense seems to settle on passing register arguments in > d0,d1,a0,a1, > you could use d2,(+a2) for the time critical stack checking/extension > functions, > which should not need other registers then d2,(+a2). > Without stack-checking d2,a2 would be free for other needs. > Why should this be impossibile ? d0/d1/a0/a1 are scratch registers, ie. you don't have to preserve them across function calls. All the other registers has to be preserved. If I remember correctly, current structure of function prologue used in Amiga port of GCC is the following ([] are optional): [ 1. Put amount of place needed for frame in d0, as an argument for [2]. 2. Call stack checking/extension routine. ] 3. Create a stack frame (link). 4. Save non-scratch registers used inside function body on stack. If you wanted to use "d2" as an argument to stack checking/extension, you would have to preserve it. However, as you can see, saving non-scratch registers is (very reasonably) performed AFTER stack checking. This is the problem. Maybe I misunderstood you, but what do you need (+a2) for (actually: what do you MEAN by "(+a2)")? / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Feb 19 15:18:54 1996 Received: from delta.mdy.univie.ac.at ([131.130.40.6]) by nic.funet.fi with SMTP id <1294-19770>; Mon, 19 Feb 1996 15:15:11 +0200 Received: from localhost by delta.mdy.univie.ac.at with SMTP (1.38.193.4/16.2) id AA22241; Mon, 19 Feb 1996 14:13:07 +0100 Sender: am@mdy.univie.ac.at Message-Id: <31287761.20B3@mdy.univie.ac.at> Date: Mon, 19 Feb 1996 14:13:05 +0100 From: Alfred Minarik X-Mailer: Mozilla 2.0 (X11; I; HP-UX A.09.05 9000/720) Mime-Version: 1.0 To: Kamil Iskra Cc: amiga-gcc-port@nic.funet.fi, ADE GCC List Subject: Re: Passing arguments in registers and stack checking/extension References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kamil Iskra wrote: > > d0/d1/a0/a1 are scratch registers, ie. you don't have to preserve them > across function calls. All the other registers has to be preserved. > > If I remember correctly, current structure of function prologue used in > Amiga port of GCC is the following ([] are optional): > > [ > 1. Put amount of place needed for frame in d0, as an argument for [2]. > 2. Call stack checking/extension routine. > ] > 3. Create a stack frame (link). > 4. Save non-scratch registers used inside function body on stack. > > If you wanted to use "d2" as an argument to stack checking/extension, you > would have to preserve it. However, as you can see, saving non-scratch > registers is (very reasonably) performed AFTER stack checking. This is the > problem. > > Maybe I misunderstood you, but what do you need (+a2) for (actually: what > do you MEAN by "(+a2)")? > You are absolutly right. So we might split the scrach registers one (maybe d0) for stack routines, others for argument passing. (Will complicate (link)libraries if you want to use all scratch registers in case of no stack routines [You need probably two different compiled libraries]). And I don't know wether this is efficient, nor if it can easily be imlemented. It was all only a quick idea. - Alfred From amiga-gcc-port-owner@nic.funet.fi Mon Feb 19 16:04:20 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <1899-20611>; Mon, 19 Feb 1996 16:02:29 +0200 Received: from mona.mbar.dtu.dk (mona.mbar.dtu.dk [130.225.72.18]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id PAA27712; Mon, 19 Feb 1996 15:02:23 +0100 (MET) Received: (from c948374@localhost) by mona.mbar.dtu.dk (8.7.3/8.7.3) id PAA04766; Mon, 19 Feb 1996 15:02:25 +0100 (MET) Date: Mon, 19 Feb 1996 15:02:24 +0100 (MET) From: Rask Ingemann Lambertsen To: Alfred Minarik cc: amiga-gcc-port@nic.funet.fi, ADE GCC List Subject: Re: Passing arguments in registers and stack checking/extension In-Reply-To: <31286777.40D7@mdy.univie.ac.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 19 Feb 1996, Alfred Minarik wrote: [Kamil Iskra (?) wrote:] > > You are right. Actually, I'm not aware of any other solution of passing > > arguments than on stack or registers (or in static storage - but this is > > complete braindamage) - since none of these seems reasonable, I guess we > > will have to drop support for register parameters used together with stack > > checking/extension... > > To me there seems to be a solution of passing both in registers. > As the common sense seems to settle on passing register arguments in > d0,d1,a0,a1, > you could use d2,(+a2) for the time critical stack checking/extension > functions, > which should not need other registers then d2,(+a2). > Without stack-checking d2,a2 would be free for other needs. I suggest using d4,a4 instead, as this leaves more registers for those who want arguments passed in registers. a4 can be used, because -fbaserel doesn't work with stackextension, right? This would leave 8 registers available for passing arguments, which really should be enough for most people, and it is certanly better than only 4. Any objections against that? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Feb 19 16:14:32 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1695-20611>; Mon, 19 Feb 1996 16:13:29 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id PAA15872; Mon, 19 Feb 1996 15:15:14 +0100 Date: Mon, 19 Feb 1996 15:15:14 +0100 (MET) From: Kamil Iskra To: Rask Ingemann Lambertsen cc: amiga-gcc-port@nic.funet.fi, ADE GCC List Subject: Re: Passing arguments in registers and stack checking/extension In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Feb 1996, Rask Ingemann Lambertsen wrote: > a4 can be used, because -fbaserel > doesn't work with stackextension, right? I don't remember if I tried, but I can't think about any reason why it shouldn't work... / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Mon Feb 19 16:48:08 1996 Received: from asimov.cnam.fr ([163.173.128.6]) by nic.funet.fi with SMTP id <1586-18468>; Mon, 19 Feb 1996 16:45:48 +0200 Received: from brunner.cnam.fr (brunner.cnam.fr [163.173.128.15]) by asimov.cnam.fr with ESMTP id PAA04584 (8.6.12/); Mon, 19 Feb 1996 15:45:39 +0100 Received: by brunner.cnam.fr id PAA18849 (8.6.12/); Mon, 19 Feb 1996 15:45:38 +0100 Received: (from daniel@localhost) by brasil.frmug.fr.net (8.6.12/8.6.12) id PAA16514; Mon, 19 Feb 1996 15:37:32 +0100 Date: Mon, 19 Feb 1996 15:37:32 +0100 Message-Id: <199602191437.PAA16514@brasil.frmug.fr.net> From: Daniel Verite To: mj@k332.feld.cvut.cz CC: amiga-gcc-port@nic.funet.fi In-reply-to: <199602182043.VAA05920@k332.feld.cvut.cz> (message from Martin Mares on Sun, 18 Feb 1996 21:43:44 +0100 (MET)) Subject: Re: ADE-question Martin Mares writes: Martin> If anyone wants, a beta version of my own TeX/MF port Martin> is available on Martin> ftp://k332.feld.cvut.cz/pub/local/mj/amiga/mjTeX/*. The Martin> archives contain only binaries -- sources compilable in Martin> someone else's environment will be available soon. Now Martin> compiled by SAS/C, but I plan to switch to GCC as soon as Martin> register parameters will be available. Martin> Distribution policy: GPL. I think you can't distribute the binaries under GPL if the source code is not available, even if it will be soon. Please re-read the GPL to be sure. -- Daniel - daniel@brainstorm.cnam.fr From amiga-gcc-port-owner@nic.funet.fi Thu Feb 22 10:57:24 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <6704-13590>; Thu, 22 Feb 1996 10:32:25 +0200 Received: from relay-2.mail.demon.net (actually host disperse.demon.co.uk) by funet.fi with SMTP (PP); Thu, 22 Feb 1996 05:07:56 +0200 Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id aj25159; 22 Feb 96 1:11 GMT Received: from sharra.demon.co.uk ([158.152.113.135]) by relay-3.mail.demon.net id ab02749; 21 Feb 96 21:20 GMT Received: by sharra.demon.co.uk (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 21 Feb 96 21:19:42 GMT Received: by sharra.demon.co.uk (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Tue, 20 Feb 96 22:04:56 GMT Date: Tue, 20 Feb 1996 22:04:45 +0000 () From: Ruth Ann Ivimey-Cook Subject: Can anyone help me with AmiTCP for gcc 2.7.0? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Organization: Not an Organization To: amiga-gcc-port@nic.funet.fi Hi, I've just downloaded gcc270, and wish to do some internet programming using AmiTCP (I have v4.2 if that matters). I've installed gcc270 as an upgrade to a 2.6.3 install, and also have an archive AmiTCP-sdk-40-gcc.lha but don't know what to do with it. Can anyone help please? Thanks, Ruth P.S. I've only just subscribed - I'm not sure if any posts to the list will get through - could you CC: me direct with any reply please? -- Ruth Ann Ivimey-Cook | ruthc@sharra.demon.co.uk Just living my life as best I can. | Marlow, UK And trying not to be an Also-Ran! | http://www.telergy.com/ruthc/ruth.html From amiga-gcc-port-owner@nic.funet.fi Thu Feb 22 12:12:35 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <1734-13606>; Thu, 22 Feb 1996 12:11:24 +0200 Received: from lorenz.gbar.dtu.dk (lorenz.gbar.dtu.dk [130.225.87.180]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id LAA06489 for ; Thu, 22 Feb 1996 11:07:39 +0100 (MET) Received: (from c948374@localhost) by lorenz.gbar.dtu.dk (8.7.3/8.7.3) id LAA26361; Thu, 22 Feb 1996 11:07:56 +0100 (MET) Date: Thu, 22 Feb 1996 11:07:56 +0100 (MET) From: Rask Ingemann Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: -fno-default-inline gives linker errors? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I just tried compiling (test.cc) ----------------------------------------------- #include int main (int argc, char *argv[]) { cout << "Hello world!\n"; } ----------------------------------------------- (I know about the missing return value, I just forgot it) with "g++ test.cc -fno-default-inline -o test" This gave me lots of linker errors like "libiostream.a: dublicate symbol ", which I don't get if I just compile with "g++ test.cc -o test". Before I make a complete bug report, I would like to know if is this a know problem. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Feb 22 12:48:19 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <2029-13605>; Thu, 22 Feb 1996 12:39:50 +0200 Received: from legolas.mdh.se by funet.fi with SMTP (PP); Thu, 22 Feb 1996 12:39:27 +0200 Received: (from frv95tjn@localhost) by legolas.mdh.se (8.7.3/8.7.3) id LAA20600; Thu, 22 Feb 1996 11:36:12 +0100 (MET) Date: Thu, 22 Feb 1996 11:36:11 +0100 (MET) From: Tommy Johansson To: Rask Ingemann Lambertsen cc: amiga-gcc-port@nic.funet.fi Subject: Re: -fno-default-inline gives linker errors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 22 Feb 1996, Rask Ingemann Lambertsen wrote: > Hi, > > I just tried compiling (test.cc) > > ----------------------------------------------- > #include > > int main (int argc, char *argv[]) > { > cout << "Hello world!\n"; > } > ----------------------------------------------- > (I know about the missing return value, I just forgot it) > > with "g++ test.cc -fno-default-inline -o test" > This gave me lots of linker errors like "libiostream.a: dublicate > symbol ", which I don't get if I just compile with "g++ > test.cc -o test". Before I make a complete bug report, I would like to > know if is this a know problem. I got the same errors on a UNIX machine with gcc2.7.2,solaris2.5 From amiga-gcc-port-owner@nic.funet.fi Thu Feb 22 13:01:42 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <1377-13605>; Thu, 22 Feb 1996 13:00:31 +0200 Received: from oersted.gbar.dtu.dk (oersted.gbar.dtu.dk [130.225.87.181]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id MAA07344 for ; Thu, 22 Feb 1996 12:00:19 +0100 (MET) Received: (from c948374@localhost) by oersted.gbar.dtu.dk (8.7.3/8.7.3) id MAA12375; Thu, 22 Feb 1996 12:00:50 +0100 (MET) Date: Thu, 22 Feb 1996 12:00:49 +0100 (MET) From: Rask Ingemann Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: New URL for the README file Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I have just created a home for the README files for Amiga GCC. Check . It is a bit sparse at this time, but that will improve when the AmigaGuide and HTML versions are put there too. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Feb 22 13:23:45 1996 Received: from gryzmak.lodz.pdi.net ([194.92.208.1]) by nic.funet.fi with SMTP id <1790-13604>; Thu, 22 Feb 1996 13:22:24 +0200 Received: from plukwa (robert@plukwa.lodz.pdi.net [194.92.208.7]) by gryzmak.lodz.pdi.net (8.6.10/1.40/L) with SMTP id MAA05511 for ; Thu, 22 Feb 1996 12:10:08 +0100 Received: by plukwa.lodz.pdi.net (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Thu, 22 Feb 96 12:08:13 MIME-Version: 1.0 From: robert@plukwa.lodz.pdi.net (Robert Ramiega) Message-Id: <005a3330312c6abc132robert@plukwa> Reply-To: robert@lodz.pdi.net Subject: Re: Can anyone help me with AmiTCP for gcc 2.7.0? X-Mailer: Amiga MetaTool 40.5alpha Content-Type: text/plain Content-Transfer-Encoding: 7bit To: ruthc@sharra.demon.co.uk Cc: amiga-gcc-port@nic.funet.fi Date: Thu, 22 Feb 96 12:08:13 Organization: PDi > Hi, > > I've just downloaded gcc270, and wish to do some internet programming > using AmiTCP (I have v4.2 if that matters). I've installed gcc270 as an > upgrade to a 2.6.3 install, and also have an archive AmiTCP-sdk-40-gcc.lha > but don't know what to do with it. > > Can anyone help please? I'm afraid that You have wait till release 43.0 of ixemul which will have networking support. the archive You mentioned was released for ixemul version 3x.xx and will not work with 42. > > Thanks, > > Ruth > > P.S. I've only just subscribed - I'm not sure if any posts to the list > will get through - could you CC: me direct with any reply please? > > > -- > > Ruth Ann Ivimey-Cook | ruthc@sharra.demon.co.uk > Just living my life as best I can. | Marlow, UK > And trying not to be an Also-Ran! | http://www.telergy.com/ruthc/ruth.html > > Robert +--------------------------------+----------------------------------------+ | Robert Ramiega | robert@lodz.pdi.net IRC: _Jedi_ | | PDi (Public Internet Access) | http://plukwa.lodz.pdi.net/ | +--------------------------------+----------------------------------------+ | Blessed are they that run around in circles, | | for they shall be known as wheels | +-------------------------------------------------------------------------+ > From amiga-gcc-port-owner@nic.funet.fi Mon Feb 26 20:48:47 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <5511-23472>; Mon, 26 Feb 1996 20:40:34 +0200 Received: from srv4.gbar.dtu.dk (srv4.gbar.dtu.dk [130.225.87.164]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id TAA10947 for ; Mon, 26 Feb 1996 19:40:22 +0100 (MET) Received: (from c948374@localhost) by srv4.gbar.dtu.dk (8.7.3/8.7.3) id TAA09496; Mon, 26 Feb 1996 19:40:21 +0100 (MET) Date: Mon, 26 Feb 1996 19:40:21 +0100 (MET) From: Rask Ingemann Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: New README for GCC 2.7.2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I have updated the README file for GCC 2.7.2. Check The major news is the AmigaGuide and HTML versions. I also mention the ADE mailing lists (watch Walter smile ;-) Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Mar 1 16:13:16 1996 Received: by nic.funet.fi id <1441-3194>; Fri, 1 Mar 1996 16:00:05 +0200 From: Leonard Norrgard To: amiga-gcc-port@nic.funet.fi Subject: Monthly mailing list info for list amiga-gcc-port Message-Id: <96Mar1.160005+0200_eet.1441-3194+120@nic.funet.fi> Date: Fri, 1 Mar 1996 16:00:04 +0200 [This is an automatic monthly posting from the mailing list maintainer] [Contains important practical info about mailserver features you maybe] [are not aware of.] [Last changed June 22nd, 1993.] The mailing list amiga-gcc-port on lists.funet.fi is run automatically, so you can both subscribe and unsubscribe to it simply by sending e-mail to the mailing list server, or mailserver program. You can reach the mailserver at the address mailserver@lists.funet.fi as described below. Please use the mailserver rather than the address amiga-gcc-port-request@lists.funet.fi (which remains valid) whenever you can, so that human list management work can be minimized. If the automated way of doing things doesn't work for you for some reason, please use the amiga-gcc-port-request@lists.funet.fi address instead, and I'll try to solve your problem manually. Please NEVER send subscription or unsubscription-requests to the address amiga-gcc-port@lists.funet.fi as that would send your request to all subscribers of the mailing list. To unsubscribe from this mailinglist only, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub amiga-gcc-port To unsubscribe from _all_ mailinglists run by this mailserver, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > unsub * To subscribe to this mailinglist, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > sub amiga-gcc-port your_first_name your_last_name To recieve additional information and help on how to use the mailserver (this includes info on how to use the ftp archive ftp.funet.fi by e-mail): > To: mailserver@lists.funet.fi > Subject: > > help If you do not receive this mail once a month, you may have been silently removed from the list. This can happen whenever your e-mail address stops working for some reason (a common problem is to set up mail forwarding from machine A to machine B and from machine B to machine A so as to make a mail-forwarding loop). So if you don't receive this mail once a month, you may want to 1) check the mailing list to see if you're still on it (see below), and 2) Resubscribe using the usual mailserver sub command described above. To receive a list of all names on the mailing list amiga-gcc-port@lists.funet.fi, send e-mail like this: > To: mailserver@lists.funet.fi > Subject: > > review amiga-gcc-port Virtually, The amiga-gcc-port mailing list management. From amiga-gcc-port-owner@nic.funet.fi Sat Mar 2 05:03:11 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <1825-8379> convert rfc822-to-8bit; Sat, 2 Mar 1996 04:54:02 +0200 Received: from nis.student.dtu.dk by funet.fi with SMTP (PP); Sat, 2 Mar 1996 03:47:13 +0200 Received: from roemer.gbar.dtu.dk (roemer.gbar.dtu.dk [130.225.87.182]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id CAA06956; Sat, 2 Mar 1996 02:46:58 +0100 (MET) Received: (from c948374@localhost) by roemer.gbar.dtu.dk (8.7.3/8.7.3) id CAA14471; Sat, 2 Mar 1996 02:46:12 +0100 (MET) Date: Sat, 2 Mar 1996 02:46:11 +0100 (MET) From: Rask Ingemann Lambertsen To: Fred Fish cc: ade-gcc@amigalib.com, amiga-gcc-port@nic.funet.fi Subject: Re: A few Amiga-specific attributes implemented In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 13 Feb 1996, Fred Fish wrote: > > > Actually there may be a fairly simple way to test these. I've been > > > playing around with moderate success at producing a PPC toolchain > > > targetted for the Amiga. With one afternoon's work I now have > > > binutils 2.6 gas generating ELF objects with PPC code and ld > > > generating standard Amiga hunk format executables with PPC code, > > > linked from ELF objects. > > > > Does this mean, that we now only need to write some startup code? > > Well, it depends upon your goal. If you want to have a toolchain > ready to generate PPC executables for the PowerAmiga, certainly there > is lots more work to do. But much of it won't be possible until there > is documentation available about the runtime requirements for the PPC > based Amiga. I'd expect the requirements to be similar to the m68k > Amiga's, but probably not exactly the same. Have anyone on the GCC lists contacted Phase 5 to get some information about that? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Sun Mar 3 14:49:03 1996 Received: from relay-2.mail.demon.net ([158.152.1.77]) by nic.funet.fi with SMTP id <1639-20068>; Sun, 3 Mar 1996 14:38:25 +0200 Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id ah04964; 3 Mar 96 9:37 GMT Received: from sharra.demon.co.uk ([158.152.113.135]) by relay-3.mail.demon.net id aa12506; 3 Mar 96 9:32 GMT Message-ID: <825845552.12506.0@sharra.demon.co.uk> From: To: unlisted-recipients:; (no To-header on input) Date: Sun, 3 Mar 1996 14:38:25 +0200 From amiga-gcc-port-owner@nic.funet.fi Tue Mar 5 16:00:02 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <1518-623>; Tue, 5 Mar 1996 15:59:28 +0200 Received: from relay-2.mail.demon.net (actually host disperse.demon.co.uk) by funet.fi with SMTP (PP); Tue, 5 Mar 1996 08:39:48 +0200 Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id af14063; 5 Mar 96 6:39 GMT Received: from sharra.demon.co.uk ([158.152.113.135]) by relay-3.mail.demon.net id aa08583; 5 Mar 96 6:37 GMT Received: by sharra.demon.co.uk (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Tue, 5 Mar 96 06:38:33 GMT Received: by sharra.demon.co.uk (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Tue, 5 Mar 96 06:22:50 GMT Date: Tue, 5 Mar 1996 06:22:43 +0000 () From: Ruth Ann Ivimey-Cook Subject: Re: No subject In-Reply-To: <71271223@sunshine.stud.uni-frankfurt.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Organization: Not an Organization To: amiga-gcc-port@nic.funet.fi On Mon, 4 Mar 1996, Martin Steigerwald wrote: > ruthc schrieb in einer persoenlichen Nachricht ueber "No subject": I don't know if I understood the message from the server correctly, but I think the funet mail server ran out of space :-( I was asking for info on how the PPC Amiga software would work - would it be similar to the way the Mac PPC was built, allowing PPC & m68k code to run interchangeably? Regards, Ruth -- Ruth Ann Ivimey-Cook | ruthc@sharra.demon.co.uk Just living my life as best I can. | Marlow, UK And trying not to be an Also-Ran! | http://www.telergy.com/ruthc/ruth.html From amiga-gcc-port-owner@nic.funet.fi Fri Mar 8 19:16:03 1996 Received: from noc.belwue.de ([129.143.2.1]) by nic.funet.fi with ESMTP id <1541-25035>; Fri, 8 Mar 1996 19:15:27 +0200 Received: from sunserv.IZFM.Uni-Stuttgart.DE (sunserv.izfm.uni-stuttgart.de [141.58.129.151]) by noc.belwue.de with SMTP id SAA09268 (8.6.13/IDA-1.6 for ); Fri, 8 Mar 1996 18:15:09 +0100 Received: by sunserv.IZFM.Uni-Stuttgart.DE (4.1/BelWue-1.2SUN+) id AA13599; Fri, 8 Mar 96 18:15:08 +0100 From: fleischr@IZFM.Uni-Stuttgart.DE (Matthias Fleischer) Message-Id: <9603081715.AA13599@sunserv.IZFM.Uni-Stuttgart.DE> Subject: libnix V1.1 To: amiga-gcc-port@nic.funet.fi Date: Fri, 8 Mar 1996 18:15:08 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 230 libnix V1.1 was uploaded to Aminet and should be available within the next days. Changes include the bugfixes mentioned over the last year and some new functions contributed by Kriton Kyrimis. Sources are included, too. Matthias From amiga-gcc-port-owner@nic.funet.fi Sat Mar 9 01:18:50 1996 Received: from Princeton.EDU ([128.112.128.1]) by nic.funet.fi with SMTP id <1904-24894>; Sat, 9 Mar 1996 01:18:34 +0200 Received: from eno.Princeton.EDU by Princeton.EDU (5.65b/2.124/princeton) id AA03368; Fri, 8 Mar 96 18:18:29 -0500 Received: from meenie (meenie.Princeton.EDU) by eno.Princeton.EDU (4.1/1.116) id AA15195; Fri, 8 Mar 96 18:18:59 EST From: "John Saponara" Received: by meenie (4.1/CS_101_Cluster_Client) id AA07394; Fri, 8 Mar 96 18:19:58 EST Date: Fri, 8 Mar 96 18:19:58 EST Message-Id: <9603082319.AA07394@meenie> To: amiga-gcc-port@nic.funet.fi Subject: Explicit template expansion won't parse /* Hi folks, The following template declarations compile under g++-2.7.2 on an SGI but not under g++-2.7.0 (mc68020) on an a4000/040. I don't have access to 2.7.0 on the SGI, so I cannot say whether this is a problem with 2.7.0 or with the amiga port. However, according to the g++-2.7.0 FAQ, these declarations should work (if I'm interpreting the FAQ correctly). I am running Kickstart 40.68, Workbench 40.42 Is there a fix for this? Thanks, John PS: I'm new to this list, please let me know if this post doesn't belong here. Command line: g++ AmiTmplDeclBug.cc -o AmiTmplDeclBug Errors: amitmpldeclbug.cc:42: parse error before `(' amitmpldeclbug.cc:48: parse error before `~' make: *** [AmiTmplDeclBug] Error 1 Program: */ class SampleClass { }; template class List { public: List() { } List( List& L ) { } ~List() { } }; // This line compiles fine: // template class List; // compiler says: parse error before `(' template List::List(List const &); // compiler says: parse error before `~' template List::~List(); main() { } From amiga-gcc-port-owner@nic.funet.fi Sat Mar 9 01:21:24 1996 Received: from Princeton.EDU ([128.112.128.1]) by nic.funet.fi with SMTP id <1738-24894>; Sat, 9 Mar 1996 01:21:10 +0200 Received: from eno.Princeton.EDU by Princeton.EDU (5.65b/2.124/princeton) id AA03762; Fri, 8 Mar 96 18:21:02 -0500 Received: from meenie (meenie.Princeton.EDU) by eno.Princeton.EDU (4.1/1.116) id AA15199; Fri, 8 Mar 96 18:21:31 EST From: "John Saponara" Received: by meenie (4.1/CS_101_Cluster_Client) id AA07406; Fri, 8 Mar 96 18:22:30 EST Date: Fri, 8 Mar 96 18:22:30 EST Message-Id: <9603082322.AA07406@meenie> To: amiga-gcc-port@nic.funet.fi Subject: Template name length limit? /* Folks, This compiles and runs on sgi (g++-2.7.2) but the amiga (g++-2.7.0 for mc68020), after a successfully compiling, gives a `Command not found' error when I try to run the resulting executable. However, when I shorten the template name from RidiculouslyLongTemplateName to ShorterTemplateName it compiles and runs normally. Command line: g++ test.cc -o test On amiga, setting the stack from 20k up to 100k doesn't help. I am running OS 3.1 on an a3000/030/25 with 10 Megs of ram, Kickstart 40.68, Workbench 40.42 Although I use a very long template name here, I have a real app that uses very short template names (just two characters) but has such a deep class hierarchy that it runs into this same problem (I define class Inch in terms of class Centimeter, Foot in terms of Inch, etc). Thanks, John PS: I'm new to this list, please let me know if this post doesn't belong here. */ template class RidiculouslyLongTemplateName { public: static int num; }; class Zero { }; typedef RidiculouslyLongTemplateName One; int RidiculouslyLongTemplateName::num = 0; typedef RidiculouslyLongTemplateName Two; int RidiculouslyLongTemplateName::num = 0; typedef RidiculouslyLongTemplateName Three; int RidiculouslyLongTemplateName::num = 0; typedef RidiculouslyLongTemplateName Four; int RidiculouslyLongTemplateName::num = 0; main() { } From amiga-gcc-port-owner@nic.funet.fi Sun Mar 10 21:25:35 1996 Received: from sharra ([158.152.113.135]) by nic.funet.fi with SMTP id <1815-6599>; Sun, 10 Mar 1996 21:25:17 +0200 Received: by sharra.demon.co.uk (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sun, 10 Mar 96 19:23:34 GMT Received: by sharra.demon.co.uk (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sun, 10 Mar 96 10:56:45 GMT Date: Sun, 10 Mar 1996 10:56:34 +0000 () From: Ruth Ann Ivimey-Cook Subject: Re: No subject In-Reply-To: <71272074@sunshine.stud.uni-frankfurt.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Organization: Not an Organization To: amiga-gcc-port@lists.funet.fi On Sat, 9 Mar 1996, Martin Steigerwald wrote: > Yes... but it should end in a 100 percent conversion to ppc for maximum > speed. Yes, that's the goal, both for the Amiga and for the Mac; however, compatibility if a major issue for both platforms;; the PPC Amiga will need to be able to execute 68k code, in the same way the Mac has to. Given that requirement, having the OS able to emulate parts of itself allows the OS designers to concentrate on providing native PPC versions of only the routines which are called enough to matter, and hence gove us a PPC based OS much sooner than we'd otherwise see it. Taken to the limit, all that needs doing is to provide the emulation mechanism and emulate the whole OS - not desirable, but it would enable developers to start playing. And on the Mac, the emulator is faster than a real '040 native machine! For example, the OpenLibrary call is used only few times per program, and so could be emulated with negligable performance loss, while the exec library Schedule is called over 50 times a second; it must be native (it's written in 68k assembler, rather than C, for speed even now). > I would like to add a complete new system layer, whereas the old system is > emulated by calling routines of the new system, and can be througn out > when it becomes obsolete. I'm not quite sure I understand what a "new system layer" is; the Mac way is (I think) to make each call a call to a gate, which provides the information required to emulate the call as well as the PPC address, if any. I think it's arranged such that a PPC call is still one (indirect) instruction. Such a scheme allows for a great deal of flexibility. > I think the AmigaOS PPC should through away all of the current limitation > and should get completey object oriented and tag-based for maximum > changeability (does this word exist in the english language?:-) For that, you throw away all compatibility with current software, and with it, most ikely, all the current software developers, who would quite possibly view any such massive change as being more costly than likely the revenue returned. PPC Amigas MUST retain object and source compatibility with 68k ones, or the machine will die. Of course we can add new functions etc, in the same way that OS 2.0 did (although that was an upheval which shouldn't be repeated soon; even now many people don't have OS 3.0, despite it's being released for many months.) Regards, Ruth P.S. Changeability is probably not a word in the OED although it's understandable. A better word in this case would be flexibility. -- Ruth Ann Ivimey-Cook | ruthc@sharra.demon.co.uk Just living my life as best I can. | Marlow, UK And trying not to be an Also-Ran! | http://www.telergy.com/ruthc/ruth.html From amiga-gcc-port-owner@nic.funet.fi Tue Mar 12 13:56:42 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1794-8992>; Tue, 12 Mar 1996 13:56:16 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id MAA02329; Tue, 12 Mar 1996 12:57:13 +0100 Date: Tue, 12 Mar 1996 12:57:12 +0100 (MET) From: Kamil Iskra To: John Saponara cc: amiga-gcc-port@nic.funet.fi, ADE GCC List Subject: Re: Explicit template expansion won't parse In-Reply-To: <9603082319.AA07394@meenie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 8 Mar 1996, John Saponara wrote: > The following template declarations compile under g++-2.7.2 on an SGI > but not under g++-2.7.0 (mc68020) on an a4000/040. I don't have > access to 2.7.0 on the SGI, so I cannot say whether this is a problem > with 2.7.0 or with the amiga port. It is a problem with GCC 2.7.0. Under sparc-sun-sunos4.1.3 I got the same messages that you mentioned. With Amiga ADE GCC 2.7.2 I got the following messages: gcc1.cc:46: prototype for `List::List(const class List &)' does not match any in class `List' gcc1.cc:39: candidates are: List::~List() gcc1.cc:38: List::List(class List &) gcc1.cc:37: List::List() gcc1.cc:46: confused by earlier errors, bailing out After removing "const", it compiled fine. > PS: I'm new to this list, please let me know if this post doesn't > belong here. I'd suggest you to post to ade-gcc mailing list, like I did with this reply. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Tue Mar 12 14:01:29 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1452-857>; Tue, 12 Mar 1996 14:00:51 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id NAA02601; Tue, 12 Mar 1996 13:02:10 +0100 Date: Tue, 12 Mar 1996 13:02:08 +0100 (MET) From: Kamil Iskra To: John Saponara cc: amiga-gcc-port@nic.funet.fi, ADE GCC List Subject: Re: Template name length limit? In-Reply-To: <9603082322.AA07406@meenie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 8 Mar 1996, John Saponara wrote: > This compiles and runs on sgi (g++-2.7.2) > but the amiga (g++-2.7.0 for mc68020), after a successfully > compiling, gives a `Command not found' error > when I try to run the resulting executable. > However, when I shorten the template name from > RidiculouslyLongTemplateName > to > ShorterTemplateName > it compiles and runs normally. This seems to be a bug in GNU ld. One of variables names after mangling has more than 140 characters. cc1 handles it fine, it seems that gas also handles it correctly... I wonder if this bug exists in new BFD linker? I'm afraid that for now you can do nothing about it :-(... / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Mar 14 21:28:28 1996 Received: from stl082.magnetek.com ([138.207.65.7]) by nic.funet.fi with ESMTP id <1877-11066>; Thu, 14 Mar 1996 21:27:55 +0200 Received: by stl082.magnetek.com (1.37.109.11/16.2) id AA155831799; Thu, 14 Mar 1996 13:29:59 -0600 Date: Thu, 14 Mar 1996 13:29:59 -0600 From: Ed Eden To: amiga-gcc-port@nic.funet.fi Subject: gdb news? Message-Id: <96Mar14.212755+0200_eet.1877-11066+174@nic.funet.fi> any news on gdb, or any source level debugger for gnu? From amiga-gcc-port-owner@nic.funet.fi Fri Mar 15 22:34:00 1996 Received: from hgatenl.hobby.nl ([193.78.42.1]) by nic.funet.fi with SMTP id <7017-17252>; Fri, 15 Mar 1996 22:33:25 +0200 Received: from wyst.hobby.nl by hgatenl.hobby.nl with uucp (Smail3.1.29.1 #20) id m0txgft-000RFkC; Fri, 15 Mar 96 22:04 MET Received: by wyst.hobby.nl (V1.17-beta/Amiga) id <0m1j@wyst.hobby.nl>; Fri, 15 Mar 96 08:15:40 CET Message-Id: <9603150715.0m1j@wyst.hobby.nl> Date: Fri, 15 Mar 1996 08:15:40 +0000 (CET) In-Reply-To: <96Mar14.212755+0200_eet.1877-11066+174@nic.funet.fi> from "Ed Eden" at Mar 14, 96 01:29:59 pm Content-Type: text Content-Length: 6644 From: hans@wyst.hobby.nl (Hans Verkuil) To: edwede@stl082.magnetek.com Cc: amiga-gcc-port@nic.funet.fi Subject: Re: gdb news? According to Ed Eden: > > any news on gdb, or any source level debugger for gnu? OK, I'll repeat here the two announcements what I've also posted to the ade mailinglist (mail majordomo@ninemoons.com with the line 'help' in the body of the message for more info): >From hans Wed Mar 13 20:59:45 1996 Subject: Announcement: Beta version of ixemul available for downloading To: ade@ninemoons.com (ADE mailinglist) Date: Wed, 13 Mar 1996 20:59:45 +0000 (CET) Content-Type: text Content-Length: 1829 Hi, After some thought I've decided to make a beta version of the 43.0 ixemul.library available for downloading. It seems very stable as far as I can see. It is available from ftp.ninemoons.com, /priv/hans/ixemul-43.0.tar.gz. The file is hidden so you have to type the precise name to get it. It is the full source distribution, so you'll have to compile it yourself. You should build the 68000 version (both baserel and no-baserel, needed for creating the libc.a and the crt0.o objects) and a version for your specific CPU type. Of course, the 68000 version will work for all CPUs, so if you want you can compile that version only. Before compiling, please add the following patch to include/netinet/in.h: ------------------- *** ../../../ixemul-44.0/include/netinet/in.h Mon Feb 5 22:56:46 1996 --- in.h Tue Mar 12 20:05:59 1996 *************** *** 21,24 **** --- 21,26 ---- #define NETINET_IN_H + #include + /* * Constants and structures defined by the internet system, ------------------- The libnet.a is no longer needed. If you want to interface with AmiTCP or AS225, then you will have to install the ixnet.library to the LIBS: directory. IMPORTANT! Do *NOT* distribute this archive or anything you build using this archive to others! If a bug is found that would force me to make substantial changes (I hope not, but....) then everything you compiled and distributed is worthless. You are warned! Good luck, Hans --------------------------------------------------------------------- >From hans Wed Mar 13 21:06:26 1996 Subject: Announcement: GDB available for beta testing To: ade@ninemoons.com (ADE mailinglist) Date: Wed, 13 Mar 1996 21:06:26 +0000 (CET) Content-Type: text Content-Length: 4368 Hi, Since I've made ixemul-43.0 available for downloading, it makes sense to do the same with gdb. Of course, you should first install ixemul-43.0 before you can use gdb. You can download gdb from: ftp.ninemoons.com, /priv/hans/gdb.gz. The file is hidden so you must use the precise name. This is only the executable, no sources are provided. Since gdb uses the GNU readline library I advise putting the following .inputrc file in your home directory: ------------------- begin 700 .inputrc M(R!->2!^+RYI;G!U=')C(&9I;&4@:7,@:6X@+2HM('1E>'0@+2HM(&9OF5D(&1E<&5N9&EN M9PHC(&]N('=H:6-H('!R;V=R86T@:7,@'0M:&ES=&]R>0HBFT,B.B!F;W)W87)D+6-H87(*(IM$(CH@8F%C:W=A (; Sun, 17 Mar 1996 00:09:38 +0200 Received: from roemer.gbar.dtu.dk (roemer.gbar.dtu.dk [130.225.87.182]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id XAA29999 for ; Sat, 16 Mar 1996 23:09:21 +0100 (MET) Received: (from c948374@localhost) by roemer.gbar.dtu.dk (8.7.3/8.7.3) id XAA09630; Sat, 16 Mar 1996 23:09:09 +0100 (MET) Date: Sat, 16 Mar 1996 23:08:54 +0100 (MET) From: Rask Ingemann Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: Linking Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I've tried using the -fbaserel option of gcc (patch 4 from Kamil Iskra's home page) to compile one of my programmes (SmartCopy to be exact), and now comes the question: How do I link the object modules? In particular, how do I resolve the reference to ___a4_init (or something like that)? Is there a version of SObjA that can handle object files with base relative references (the one I have gives "Warning: baserel bit set" or something like that)? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Tue Mar 19 05:43:02 1996 Received: from belize.ucs.indiana.edu ([129.79.10.64]) by nic.funet.fi with ESMTP id <1586-7718>; Tue, 19 Mar 1996 05:40:55 +0200 Received: from nickel.ucs.indiana.edu (owinebar@nickel.ucs.indiana.edu [129.79.1.5]) by belize.ucs.indiana.edu (8.7.3/8.7.3/1.10IUPO) with ESMTP id WAA29934; Mon, 18 Mar 1996 22:38:41 -0500 (EST) Received: (from owinebar@localhost) by nickel.ucs.indiana.edu (8.7.Beta.13/8.7.Beta.13/1.1clump) id WAA20424; Mon, 18 Mar 1996 22:40:41 -0500 From: Lynn Winebarger Message-Id: <199603190340.WAA20424@nickel.ucs.indiana.edu> Subject: Amiga GCC FAQ, now in texi (sort of) To: ade-gcc@ninemoons.com Date: Mon, 18 Mar 1996 22:40:41 -0500 (EST) Cc: amiga-gcc-port@lists.funet.fi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi! Sorry I dropped out for so long, but I just put together a gawk script today to convert the last version of the faq to texi (I had added some identifiers to make the faq easier to search for specific sections before I stopped working on it last summer). Anyway, the gawk script should convert the "faq" format I used to texi fairly readily. makeinfo choked a bit though (I think there were a few email addresses in there that it tried to use as commands). So the info file produced doesn't work too well. But it's all in the archive, which I uploaded to amigalib.com as incoming/amigcc-FAQ.lha. Guess I'll upload it to Phillipe's site soon. Anyway, I'd guess it's a bit out of date, so any modifications are welcome. Lynn owinebar@indiana.edu From amiga-gcc-port-owner@nic.funet.fi Sun Mar 24 19:08:23 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <1630-24799>; Sun, 24 Mar 1996 19:08:07 +0200 Received: from roemer.gbar.dtu.dk (roemer.gbar.dtu.dk [130.225.87.182]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id SAA16323; Sun, 24 Mar 1996 18:07:56 +0100 (MET) Received: (from c948374@localhost) by roemer.gbar.dtu.dk (8.7.3/8.7.3) id SAA17156; Sun, 24 Mar 1996 18:07:53 +0100 (MET) Date: Sun, 24 Mar 1996 18:07:52 +0100 (MET) From: Rask Ingemann Lambertsen To: amiga-gcc-port@nic.funet.fi, ade-gcc@ninemoons.com Subject: Help needed: Linking with -fbaserel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I've tried using the -fbaserel option of gcc (patch 4 from Kamil Iskra's home page) to compile one of my programmes (SmartCopy to be exact), and now comes the question: How do I link the object modules? In particular, how do I resolve the reference to ___a4_init (or something like that)? Is there a version of SObjA that can handle object files with base relative references (the one I have gives "Warning: baserel bit set" or something like that)? Does the newest binutils linker generate the symbol ___a4_init? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Sun Mar 24 20:49:56 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <1913-4240>; Sun, 24 Mar 1996 20:49:33 +0200 Received: from roemer.gbar.dtu.dk (roemer.gbar.dtu.dk [130.225.87.182]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id TAA16759; Sun, 24 Mar 1996 19:49:13 +0100 (MET) Received: (from c948374@localhost) by roemer.gbar.dtu.dk (8.7.3/8.7.3) id TAA22970; Sun, 24 Mar 1996 19:49:10 +0100 (MET) Date: Sun, 24 Mar 1996 19:49:10 +0100 (MET) From: Rask Ingemann Lambertsen To: Kamil Iskra cc: ADE GCC List , Amiga GCC List Subject: Re: Amiga-specific attributes implemented as keywords In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 12 Feb 1996, Kamil Iskra wrote: > On Mon, 12 Feb 1996, Rask Ingemann Lambertsen wrote: > > > > I implemented Amiga-specific attributes as SAS/C-compatible keywords: > > > interrupt, saveds, stackext and (currently disabled) chip. ^^^^^^ The "saveds" keyword causes A4 to be reloaded on function entry, right? How does that work? Does it by any chance be the "thing" that references the symbol __init_a4? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Mar 25 10:57:38 1996 Received: from ernie.icslab.agh.edu.pl ([149.156.98.14]) by nic.funet.fi with SMTP id <1515-6324>; Mon, 25 Mar 1996 10:57:17 +0200 Received: (from kiskra@localhost) by ernie.icslab.agh.edu.pl (8.6.12/8.6.12) id JAA03655; Mon, 25 Mar 1996 09:58:49 +0100 Date: Mon, 25 Mar 1996 09:58:48 +0100 (MET) From: Kamil Iskra To: Rask Ingemann Lambertsen cc: ADE GCC List , Amiga GCC List Subject: Re: Amiga-specific attributes implemented as keywords In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 24 Mar 1996, Rask Ingemann Lambertsen wrote: > The "saveds" keyword causes A4 to be reloaded on function entry, right? Right. > How does that work? Does it by any chance be the "thing" that references > the symbol __init_a4? Yes, exactly. It just inserts a "lea ___init_a4,a4" (apart from first preserving a4, of course). I think that GNU ld provides ___init_a4, both IXEmul and LibNIX use this variable. Or maybe I have missed sth? I'll check it out at home. / Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 850 MB, 10 MB RAM \ | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | | http://student.uci.agh.edu.pl/~iskra | \ PGP public key available via Finger or WWW / From amiga-gcc-port-owner@nic.funet.fi Thu Apr 11 22:19:27 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <2521-27349>; Thu, 11 Apr 1996 22:19:00 +0300 Received: from srv3.gbar.dtu.dk (srv3.gbar.dtu.dk [130.225.87.163]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id VAA15427; Thu, 11 Apr 1996 21:18:47 +0200 (METDST) Received: (from c948374@localhost) by srv3.gbar.dtu.dk (8.7.3/8.7.3) id VAA19571; Thu, 11 Apr 1996 21:18:57 +0200 (METDST) Date: Thu, 11 Apr 1996 21:18:57 +0200 (METDST) From: Rask Ingemann Lambertsen To: amiga-gcc-port@nic.funet.fi, ade-gcc@ninemoons.com Subject: Which cc1 version includes my optimization pathes? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, Well, the subject line says it all, really. Is a cc1 with my optimization pathes available somewhere, so I can test them? Compiling gcc myself is not an option on my current system. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Mon Apr 15 22:59:22 1996 Received: from rummelplatz.uni-mannheim.de ([134.155.50.46]) by nic.funet.fi with SMTP id <2797-719>; Mon, 15 Apr 1996 22:58:51 +0300 Received: by rummelplatz.uni-mannheim.de id AA00268 (5.67a/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Mon, 15 Apr 1996 21:58:45 +0200 From: Steffen Opel Message-Id: <199604151958.AA00268@rummelplatz.uni-mannheim.de> Subject: FYI: GCC-Install maintaneance problems To: amiga-gcc-port@nic.funet.fi Date: Mon, 15 Apr 96 21:58:44 MESZ Mailer: Elm [revision: 70.85] Salut, well, as subject states, I'll most likely not be able to update GCC-Install for gcc 2.8.0 in time (lack of spare time due to working for my living). If somebody cares, it would be nice to see him/her doing it himself/herself ;-) However, I'll try to get in touch with this project again at the end of may 96. Ciao, Steffen Opel PS: Last version was GCC-Install 2.15 (for gcc 2.7.2), uploaded to ftp. telesys-innov.fr. It seems to work fine for me but I haven't got any response on it so far. This isn't too surprisingly, after all, 2.7.2 hasn't been released to the public ;-) to the public :-) From amiga-gcc-port-owner@nic.funet.fi Sun Apr 21 17:44:53 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <270-4441>; Sun, 21 Apr 1996 17:44:35 +0300 Received: from miriam.mbar.dtu.dk (miriam.mbar.dtu.dk [130.225.72.51]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id QAA23112; Sun, 21 Apr 1996 16:44:14 +0200 (METDST) Received: (from c948374@localhost) by miriam.mbar.dtu.dk (8.7.3/8.7.3) id QAA11942; Sun, 21 Apr 1996 16:44:25 +0200 (METDST) Date: Sun, 21 Apr 1996 16:44:24 +0200 (METDST) From: Rask Ingemann Lambertsen To: Philippe BRAND cc: amiga-gcc-port@nic.funet.fi, ade-gcc@ninemoons.com Subject: Re: 000/010 optimization patch for gcc (cc1) In-Reply-To: <199604140201.CAA15192@colombo.telesys-innov.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Sun, 14 Apr 1996, Philippe BRAND wrote: > Rask Ingemann Lambertsen writes: > > > > - don't forget to say on which gcc sources you've applied patch, > > > > Oops, diff is against the gcc 2.7.0 sources from Aminet. > > Sorry. Couldn't applied it to 2.7.2-960405. Here's latest m68k.c, > could you take a look at it and send me back correct diff against this one ? > Thx. Yep, here is it, including a new Changelog (because a function name changed). This time it is a diff against the 2.7.2-960405 sources :-) Changelog: Sun Apr 21 14:56:09 1996 Rask Ingemann Lambertsen * m68k/m68k.c (CONST_METHOD): Added 3 new move-const-into-datareg methods to optimize further for '000 and '010: moveq.l + bchg.l, moveq.l + neg.w + add.w, moveq.l + neg.w + addq.w * m68k/m68k.c (use_bchgl): New function for the moveq.l + bchg.l optimization ('000 and '010 only). Returns 0 if the optimization is not possible. Returns the bit number for the bchg.l instruction otherwise. * m68k/m68k.c (const_method): Changed to take advantage of the above optimizations for the '000 and '010. * m68k/m68k.c (const_int_cost): Added the costs of the new optimi- zations and changed it to return 3 instead of 2 for an unoptimized move.l #x,Dn on '000 and '010 processors to better reflect the relative costs of the different methods. * m68k/m68k.c (output_move_const_into_data_reg): Enhanced to output assembler instructions for the new '000 and '010 optimiza- tions. * m68k/m68k.c (output_move_simode_const): Changed to output "moveq.l #0,Dn" instead of "clr.l Dn" when moving the special constant 0 (const0_rtx) into a data register. This saves two cycles on the '000 without slowdown on the bigger processors. * m68k/m68k.c (print_operand): Corrected an error in the comments above the function. '+' was documented as meaning an operand pushing on the stack. It now correctly states that '+' means an operand popping off the stack. Diff: *** gcc-2.7.2-amiga/config/m68k/m68k.c Mon Apr 15 00:53:21 1996 --- gcc-2.7.2-amiga/config/m68k/m68k.c-new Sun Apr 21 14:37:05 1996 *************** *** 1053,1060 **** ! typedef enum { MOVL, SWAP, NEGW, NOTW, NOTB, MOVQ } CONST_METHOD; #define USE_MOVQ(i) ((unsigned)((i) + 128) <= 255) CONST_METHOD const_method (constant) --- 1053,1155 ---- ! typedef enum { MOVL, SWAP, NEGW, NOTW, NOTB, MOVQ, BCHG, NEGW_ADDW, ! NEGW_ADDQW } CONST_METHOD; #define USE_MOVQ(i) ((unsigned)((i) + 128) <= 255) + /* Return the value m in the following optimization: + move.l #i,dx -> moveq #m,dx + bchg.l dx,dx + This saves two bytes, but is only known to be faster on '000 and '010. + It is slower on '030, and most likely also on '020, '040 and '060. + Returns 0 if the optimization is not possible. */ + + int use_bchgl (i) + int i; + { + /* The last i and m are cached for efficiency. */ + static int last_i = -32881, last_m = -113; + register int m; + + /* Check for a cache hit. */ + if (i == last_i) + return (last_m); + + switch (i) + { + case -32881: m = -113; break; + case -32849: m = -81; break; + case -32817: m = -49; break; + case -32785: m = -17; break; + case -16498: m = -114; break; + case -16466: m = -82; break; + case -16434: m = -50; break; + case -16402: m = -18; break; + case -8307: m = -115; break; + case -8275: m = -83; break; + case -8243: m = -51; break; + case -8211: m = -19; break; + case -4212: m = -116; break; + case -4180: m = -84; break; + case -4148: m = -52; break; + case -4116: m = -20; break; + case -2165: m = -117; break; + case -2133: m = -85; break; + case -2101: m = -53; break; + case -2069: m = -21; break; + case -1142: m = -118; break; + case -1110: m = -86; break; + case -1078: m = -54; break; + case -1046: m = -22; break; + case -631: m = -119; break; + case -599: m = -87; break; + case -567: m = -55; break; + case -535: m = -23; break; + case -376: m = -120; break; + case -344: m = -88; break; + case -312: m = -56; break; + case -280: m = -24; break; + case 264: m = 8; break; + case 296: m = 40; break; + case 328: m = 72; break; + case 360: m = 104; break; + case 521: m = 9; break; + case 553: m = 41; break; + case 585: m = 73; break; + case 617: m = 105; break; + case 1034: m = 10; break; + case 1066: m = 42; break; + case 1098: m = 74; break; + case 1130: m = 106; break; + case 2059: m = 11; break; + case 2091: m = 43; break; + case 2123: m = 75; break; + case 2155: m = 107; break; + case 4108: m = 12; break; + case 4140: m = 44; break; + case 4172: m = 76; break; + case 4204: m = 108; break; + case 8205: m = 13; break; + case 8237: m = 45; break; + case 8269: m = 77; break; + case 8301: m = 109; break; + case 16398: m = 14; break; + case 16430: m = 46; break; + case 16462: m = 78; break; + case 16494: m = 110; break; + case 32783: m = 15; break; + case 32815: m = 47; break; + case 32847: m = 79; break; + case 32897: m = 111; break; + + default: m = 0; break; + } + + last_i = i; + last_m = m; + + return m; + } + CONST_METHOD const_method (constant) *************** *** 1078,1084 **** return NEGW; /* Try also with swap */ - u = i; if (USE_MOVQ ((u >> 16) | (u << 16))) return SWAP; /* Otherwise, use move.l */ return MOVL; --- 1173,1190 ---- return NEGW; /* Try also with swap */ if (USE_MOVQ ((u >> 16) | (u << 16))) return SWAP; + /* Try with neg.w + add.w. Only do this for '000 and '010. */ + if ((!TARGET_68020 && !TARGET_68040 && !TARGET_68040_ONLY && !TARGET_68060) + && i == -65280) + return NEGW_ADDW; + /* Try with neg.w + addq.w. Only do this for '000 and '010. */ + if ((!TARGET_68020 && !TARGET_68040 && !TARGET_68040_ONLY && !TARGET_68060) + && i <= -65400 && i >= -65407) + return NEGW_ADDQW; + /* Try with bchg.l. Only do this for '000 and '010. */ + if ((!TARGET_68020 && !TARGET_68040 && !TARGET_68040_ONLY && !TARGET_68060) + && use_bchgl (i)) + return BCHG; /* Otherwise, use move.l */ return MOVL; *************** *** 1099,1104 **** --- 1205,1220 ---- /* Constants easily generated by moveq + not.b/not.w/neg.w/swap */ return 1; + case BCHG : + case NEGW_ADDW : + case NEGW_ADDQW : + /* Constants easily generated by moveq + neg.w + add.w/addq.w or + moveq + bchg.l */ + return 2; case MOVL : + /* move.l #x,Dn is much slower on '000 and '010 */ + if (TARGET_68020 || TARGET_68040 || TARGET_68040_ONLY || TARGET_68060) return 2; + else + return 3; default : abort (); *************** *** 1152,1155 **** --- 1268,1291 ---- #endif } + case NEGW_ADDW: + #if defined (MOTOROLA) && !defined (CRDS) + return "moveq%.l %#-128,%0\n\tneg%.w %0\n\tadd%.w %0,%0"; + #else + return "moveq %#-128,%0\n\tneg%.w %0\n\tadd%.w %0,%0"; + #endif + case NEGW_ADDQW: + operands[1] = gen_rtx (CONST_INT, VOIDmode, 65408 + i); + #if defined (MOTOROLA) && !defined (CRDS) + return "moveq%.l %#-128,%0\n\tneg%.w %0\n\taddq%.w %1,%0"; + #else + return "moveq %#-128,%0\n\tneg%.w %0\n\taddq%.w %1,%0"; + #endif + case BCHG: + operands[1] = gen_rtx (CONST_INT, VOIDmode, use_bchgl (i)); + #if defined (MOTOROLA) && !defined (CRDS) + return "moveq%.l %1,%0\n\tbchg%.l %0,%0"; + #else + return "moveq %1,%0\n\tbchg %0,%0"; + #endif case MOVL : return "move%.l %1,%0"; *************** *** 1163,1169 **** rtx *operands; { ! if (operands[1] == const0_rtx ! && (DATA_REG_P (operands[0]) ! || GET_CODE (operands[0]) == MEM) /* clr insns on 68000 read before writing. This isn't so on the 68010, but we have no alternative for it. */ --- 1299,1313 ---- rtx *operands; { ! if (operands[1] == const0_rtx) ! { ! /* On the 68000, moveq.l is two cycles faster than clr.l (four instead ! of six) so we use moveq.l when clearing a data register. */ ! if (DATA_REG_P (operands[0])) ! #if defined (MOTOROLA) && !defined (CRDS) ! return "moveq%.l #0,%0"; ! #else ! return "moveq #0,%0"; ! #endif ! else if ((GET_CODE (operands[0]) == MEM) /* clr insns on 68000 read before writing. This isn't so on the 68010, but we have no alternative for it. */ *************** *** 1172,1175 **** --- 1316,1320 ---- && MEM_VOLATILE_P (operands[0])))) return "clr%.l %0"; + } else if (DATA_REG_P (operands[0])) return output_move_const_into_data_reg (operands); *************** *** 2088,2092 **** '-' for an operand pushing on the stack: sp@-, -(sp) or -(%sp) depending on the style of syntax. ! '+' for an operand pushing on the stack: sp@+, (sp)+ or (%sp)+ depending on the style of syntax. '@' for a reference to the top word on the stack: --- 2233,2237 ---- '-' for an operand pushing on the stack: sp@-, -(sp) or -(%sp) depending on the style of syntax. ! '+' for an operand popping off the stack: sp@+, (sp)+ or (%sp)+ depending on the style of syntax. '@' for a reference to the top word on the stack: Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Try my finger-WWW gateway at http://www.bbar.dtu.dk/~c948374/f.cgi | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Sat Apr 27 06:48:48 1996 Received: from tim.xenologics.com ([194.77.5.12]) by nic.funet.fi with SMTP id <624-30835>; Sat, 27 Apr 1996 06:47:56 +0300 Received: from darkness.gun.de (root@localhost) by tim.xenologics.com (8.6.11/8.6.6) with UUCP id FAA19777 for nic.funet.fi!amiga-gcc-port; Sat, 27 Apr 1996 05:47:46 +0200 X-ZC-VIA: 19960426213011W+1@darkness.gun.de From: DarkStar@darkness.gun.de (Carsten Meyer) Subject: Bug in signed/unsigned/char? Message-ID: Date: Fri, 26 Apr 96 21:23:10 CET X-ZC-FILE: bug.c Return-Receipt-To: DarkStar@darkness.gun.de (Carsten Meyer) Organization: Eudaemonic Enterprises X-ZC-POST: Postfach 11 12;31596 Uchte X-Mailer: MicroDot 1.11beta15 [REGISTERED 0050e0] via Connectline-CLMSortin 2.27 X-Gateway: ZConnect DA darkness.gun.de [Connectline/AmigaOS] To: amiga-gcc-port@nic.funet.fi /* Hi! Please take a look on this piece of source ... --- GNU C V2.7.0 + ixemul.library 030/fpu V42.00 (aminet CD 11) --- 4.Daten:Source/Kubus/test 0> stack 400000 4.Daten:Source/Kubus/test 0> gcc -Wall -ansi -pedantic bug.c -o bug bug.c: In function `main': bug.c:37: warning: pointer targets in initialization differ in signedness bug.c:39: warning: pointer type mismatch in conditional expression bug.c:39: warning: char format, void arg (arg 2) 4.Daten:Source/Kubus/test 0> ------------------------------------------------------------------- The warning is shown with signed char *sp ... and unsigned char *sp ... but not with char *sp ... Why? c u Carsten */ #include signed int main ( void ) { signed char *sp = "This line is the reason"; printf ( "%s;", sp ? sp : "sp is empty" ); return ( 0 ); } From amiga-gcc-port-owner@nic.funet.fi Sat Apr 27 07:51:20 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <83-7838>; Sat, 27 Apr 1996 07:51:03 +0300 Received: by fishpond (Smail3.1.29.1 #57) id m0uD1wr-000gXUC; Fri, 26 Apr 96 21:49 MST Message-Id: From: fnf@ninemoons.com (Fred Fish) Subject: Re: Bug in signed/unsigned/char? To: DarkStar@darkness.gun.de (Carsten Meyer) Date: Fri, 26 Apr 1996 21:49:31 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: from "Carsten Meyer" at Apr 26, 96 09:23:10 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1598 > > /* > Hi! > > Please take a look on this piece of source ... > > --- GNU C V2.7.0 + ixemul.library 030/fpu V42.00 (aminet CD 11) --- > 4.Daten:Source/Kubus/test 0> stack 400000 > 4.Daten:Source/Kubus/test 0> gcc -Wall -ansi -pedantic bug.c -o bug > bug.c: In function `main': > bug.c:37: warning: pointer targets in initialization differ in signedness > bug.c:39: warning: pointer type mismatch in conditional expression > bug.c:39: warning: char format, void arg (arg 2) > 4.Daten:Source/Kubus/test 0> > ------------------------------------------------------------------- > > The warning is shown with > > signed char *sp ... and > unsigned char *sp ... > > but not with > > char *sp ... > > Why? Technically a string constant has type "array of char" (K&R2 pg 38 for example). In ansi C, char, signed char, and unsigned char are all different types, so char *, signed char *, and unsigned char * are also different types of pointers. To make the warning go away, cast the array of char to the proper type: signed char *sp = (signed char *) "This line is the reason"; > > c u > Carsten > > */ > > #include > > signed int > main ( void ) > { > signed char *sp = "This line is the reason"; > > printf ( "%s;", sp ? sp : "sp is empty" ); You have a ternary expression that has two different types as its result, so naturally the compiler is warning about this. Change it to: printf ( "%s;", sp ? sp : (signed char *) "sp is empty" ); and the warning will go away. > return ( 0 ); > } > > From amiga-gcc-port-owner@nic.funet.fi Tue May 7 10:17:02 1996 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]) by nic.funet.fi with ESMTP id <38-15627>; Tue, 7 May 1996 10:16:49 +0300 Received: by tuminfo2.informatik.tu-muenchen.de via suspension id <26734-4>; Tue, 7 May 1996 09:16:18 +0200 Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26698-4>; Mon, 6 May 1996 22:56:51 +0200 Received: from hphalle5.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <398856-209>; Mon, 6 May 1996 22:56:42 +0100 Subject: missing installer From: "Juergen \"Rally\" Fischer" To: amiga-gcc-port@nic.funet.fi Date: Mon, 6 May 1996 22:55:38 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 434 Message-Id: <96May6.225642+0100mesz.398856-209+758@hphalle0.informatik.tu-muenchen.de> GCC270-R.LHA: gcc-faq.txt: >> Installer Commodore installer utility gcc263-base GCC-Install Installer script to configure gcc All archives << no installer in gcc270-base, I think this is a bug or am I supposed to get gcc263 ? ;) btw GCC-Install is not in all archives... ------------------------------------------------------------------------ fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) =:) From amiga-gcc-port-owner@nic.funet.fi Tue May 7 11:36:05 1996 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <881-2246>; Tue, 7 May 1996 11:35:46 +0300 Received: by colombo.telesys-innov.fr; Tue, 7 May 1996 10:34:58 GMT From: Philippe BRAND Message-Id: <199605071034.KAA26805@colombo.telesys-innov.fr> Subject: Re: missing installer To: fischerj@informatik.tu-muenchen.de (Juergen \"Rally\" Fischer) Date: Tue, 7 May 1996 10:34:56 +0000 (WET) Cc: amiga-gcc-port@lists.funet.fi (Amiga-Gcc Liste) In-Reply-To: <96May6.225642+0100mesz.398856-209+758@hphalle0.informatik.tu-muenchen.de> from "Juergen \"Rally\" Fischer" at May 6, 96 10:55:38 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Juergen \"Rally\" Fischer writes: > > > GCC270-R.LHA: gcc-faq.txt: > > >> > Installer Commodore installer utility gcc263-base > GCC-Install Installer script to configure gcc All archives > << > > no installer in gcc270-base, I think this is a bug or am > I supposed to get gcc263 ? ;) > > btw GCC-Install is not in all archives... > > ------------------------------------------------------------------------ > fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) =:) > -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://colombo.telis-sc.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue May 28 12:57:45 1996 Received: from rumpelkammer.uni-mannheim.de ([134.155.50.106]) by nic.funet.fi with SMTP id <6259-30668>; Tue, 28 May 1996 12:57:32 +0300 Received: by rumpelkammer.uni-mannheim.de id AA13951 (5.67a/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Tue, 28 May 1996 11:57:26 +0200 From: Steffen Opel Message-Id: <199605280957.AA13951@rumpelkammer.uni-mannheim.de> Subject: current state of ade-gcc-port vs. amiga-gcc-port? To: amiga-gcc-port@nic.funet.fi, ade-gcc@ninemoons.com Date: Tue, 28 May 96 11:57:26 MESZ Mailer: Elm [revision: 70.85] Salut, could someone please shade a light on this, I'm a little bit confused at the moment, although I've read the mailing-lists for over ten days now after some weeks of absence. More precise question: Is amiga-gcc-port still supported or has it been dropped in favour of the ade-gcc-port? Ciao, Steffen Opel From amiga-gcc-port-owner@nic.funet.fi Tue May 28 13:05:16 1996 Received: from rumpelkammer.uni-mannheim.de ([134.155.50.106]) by nic.funet.fi with SMTP id <6729-30668>; Tue, 28 May 1996 13:04:55 +0300 Received: by rumpelkammer.uni-mannheim.de id AA14124 (5.67a/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Tue, 28 May 1996 12:04:46 +0200 From: Steffen Opel Message-Id: <199605281004.AA14124@rumpelkammer.uni-mannheim.de> Subject: current state amiga-gcc-port vs. ade-gcc-port? To: amiga-gcc-port@nic.funet.fi, ade-gcc@ninemoons.com Date: Tue, 28 May 96 12:04:46 MESZ Mailer: Elm [revision: 70.85] Salut, could someone please shade a light on this, I'm a little bit confused at the moment, although I've read the mailing-lists for ten days now after some weeks of absence. More precise question: Is amiga-gcc-port still supported or has it been dropped in favour of the ade-gcc-port? Ciao, Steffen Opel From amiga-gcc-port-owner@nic.funet.fi Tue May 28 13:19:56 1996 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <6716-6615>; Tue, 28 May 1996 13:19:41 +0300 Received: by colombo.telesys-innov.fr; Tue, 28 May 1996 12:11:22 GMT From: Philippe BRAND Message-Id: <199605281211.MAA10753@colombo.telesys-innov.fr> Subject: Re: current state of ade-gcc-port vs. amiga-gcc-port? To: opel@rumpelkammer.uni-mannheim.de (Steffen Opel) Date: Tue, 28 May 1996 12:11:21 +0000 (WET) Cc: amiga-gcc-port@nic.funet.fi, ade-gcc@ninemoons.com In-Reply-To: <199605280957.AA13951@rumpelkammer.uni-mannheim.de> from "Steffen Opel" at May 28, 96 11:57:26 am Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Steffen Opel writes: > Is amiga-gcc-port still supported or has it been dropped in favour of the > ade-gcc-port? These are same ports, Fred and I are sharing same sources. Only difference so far: fred still uses m68k-cbm-amigados and I use m68000-unknown-amigaos. If you are takling about mailing lists, well as for now everybody is writing in ade-gcc list. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://colombo.telis-sc.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Tue May 28 13:41:13 1996 Received: from rumpelkammer.uni-mannheim.de ([134.155.50.106]) by nic.funet.fi with SMTP id <6777-6615>; Tue, 28 May 1996 13:40:39 +0300 Received: by rumpelkammer.uni-mannheim.de id AA14468 (5.67a/IDA-1.5 for amiga-gcc-port@nic.funet.fi); Tue, 28 May 1996 12:38:09 +0200 From: Steffen Opel Message-Id: <199605281038.AA14468@rumpelkammer.uni-mannheim.de> Subject: Re: current state of ade-gcc-port vs. amiga-gcc-port? To: phb@telesys-innov.fr Date: Tue, 28 May 96 12:38:09 MESZ Cc: amiga-gcc-port@nic.funet.fi, ade-gcc@ninemoons.com In-Reply-To: <199605281211.MAA10753@colombo.telesys-innov.fr>; from "Philippe BRAND" at May 28, 96 12:11 (noon) Mailer: Elm [revision: 70.85] Salut Philippe, > These are same ports, Fred and I are sharing same sources. Only difference > so far: fred still uses m68k-cbm-amigados and I use m68000-unknown-amigaos. > If you are takling about mailing lists, well as for now everybody is writing > in ade-gcc list. No, I indeed meant the ports themselves. Since Your port will still be supported I may ask further, wether You are going to change the layout of Your distribution to the one used by Fred (You mentioned the release of a snapshot XYZ in a mail about 2.8.0)? This would affect a possible revision of the installer script, which I happened to voluteer for since 2.7.0. Ciao, Steffen Opel From amiga-gcc-port-owner@nic.funet.fi Tue May 28 13:57:56 1996 Received: from colombo.telesys-innov.fr ([192.70.117.81]) by nic.funet.fi with ESMTP id <6390-765>; Tue, 28 May 1996 13:57:38 +0300 Received: by colombo.telesys-innov.fr; Tue, 28 May 1996 12:55:40 GMT From: Philippe BRAND Message-Id: <199605281255.MAA10977@colombo.telesys-innov.fr> Subject: Re: current state of ade-gcc-port vs. amiga-gcc-port? To: opel@rumpelkammer.uni-mannheim.de (Steffen Opel) Date: Tue, 28 May 1996 12:55:38 +0000 (WET) Cc: phb@telesys-innov.fr, amiga-gcc-port@nic.funet.fi, ade-gcc@ninemoons.com In-Reply-To: <199605281038.AA14468@rumpelkammer.uni-mannheim.de> from "Steffen Opel" at May 28, 96 12:38:09 pm Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Steffen Opel writes: > No, I indeed meant the ports themselves. > Since Your port will still be supported I may ask further, wether You are > going to change the layout of Your distribution to the one used by Fred > (You mentioned the release of a snapshot XYZ in a mail about 2.8.0)? > This would affect a possible revision of the installer script, which I > happened to voluteer for since 2.7.0. I think Net release should be more integrated than on CD-Rom. First of all not everybody has access to the Internet, some only have access to BBS, and they prefer a single or maximum 4 or 5 archives, so they don't have to look around for needed software (I know that, I'm sysoping a very large BBS in france). Thus as for now there is only one port effort, but two different distribitions, including same software. Aminet distribution will not include full ixemul distribution, which is splitted in 5 parts, but will contain as usual doc (in gcc-readme.lha) , bin (in gcc-base.lha), sdk (in gcc-inclib.lha), and will only have plain 68000 library. gcc-utils.lha will only contain really can't miss utilities, such as make, sh, and a few others. Now the Aminet distribution can I think change name, from gcc-package.lha to ade-package.lha. Thus: ade-readme.lha main docs and readme files ade-base.lha contains needed binaries, binutils distribution, manual browser etc. ade-c.lha C compiler including man pages ade-inclib headers and libraries ade-c++.lha C++ compiler ade-objc.lha Objc Compiler ade-utils.lha Utilities such as make, etc. GNU: assign will be outdated in newt release, ADE: assign will be use instead, but as for now installer script should create a Assign GNU: ADE:, just to ensure compatibility. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Sysop 2:320/104 IRC: PhB AmigaDOS GNU Project, AmigOS Net/WWW coordinator. http://colombo.telis-sc.fr/about/PhB.html From amiga-gcc-port-owner@nic.funet.fi Wed May 29 21:08:43 1996 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <656-11082>; Wed, 29 May 1996 21:08:19 +0300 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.7.1/8.7.1) id UAA24307; Wed, 29 May 1996 20:08:04 +0200 (MET DST) Date: Wed, 29 May 1996 20:08:04 +0200 (MET DST) Message-Id: <199605291808.UAA24307@theory.cs.uni-bonn.de> From: Ignatios Souvatzis To: gc948374@gbar.dtu.dk CC: lhecking@nmrc.ucc.ie, amiga-gcc-port@nic.funet.fi In-reply-to: (message from Rask Lambertsen on Sun, 17 Dec 1995 17:28:33 +0100 (MET)) Subject: Re: More optimizations for m68k.c On Sun, 17 Dec 1995 17:28:33 +0100 (MET), Rask Lambertsen wrote: On Sat, 16 Dec 1995, Lars Hecking wrote: > Methinks that TARGET_68020 would also be used for > 68030. Potentially, the same might apply for TARGET_68040 and > 68060. But I'm not too familiar with too subtle differences > between these CPU's. Anyone? Some '040 instructions should be avoided on the '060, and maybe some instruction should come in a different order. I'm not sure this list exists any more, but saw this message when cleaning up my mailbox.... On my request, J.T.Conklin of the NetBSD project and Cygnus Software added preliminary 68060 support to the NetBSD-diff file for the gcc import, and submitted it to the FSF for inclusion (as far as I know, it was accepted shortly after). Regards, Ignatios Souvatzis From amiga-gcc-port-owner@nic.funet.fi Sun Jun 30 18:07:31 1996 Received: from atreju.DInet.DE ([194.221.8.17]) by nic.funet.fi with SMTP id <12233-946>; Sun, 30 Jun 1996 18:07:25 +0300 Received: from DInet.DE (abakus.dinet.de [194.221.9.116]) by atreju.DInet.DE (8.6.12/8.6.12) with SMTP id RAA09813 for ; Sun, 30 Jun 1996 17:07:19 +0200 Date: 30 Jun 96 15:49:14 +0100 From: Grueni@Abakus.DInet.DE (Matthias Gruenewald) Subject: GCC Development Info To: AMIGA-GCC-PORT@nic.funet.fi (AMIGA-GCC-PORT Mailing List) Message-ID: <422.6755T949T738@Abakus.DInet.DE> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: THOR 2.31 (Amiga;TCP/IP) *UNREGISTERED* Lines: 12 Hi! I'm new and I want to change from my SAS C Compiler to the GCC System because I want to program in C++. But there's one thing I miss: the source-level- debugger. I have heard that there's a debugger for GCC, but there's no AMIGA port. So is there someone who ports this debugger or must I do this by myself? Or is it to complicate to port the debugger to the AMIGA? Thank you for your help! Bye Matthias Gruenewald From amiga-gcc-port-owner@nic.funet.fi Mon Jul 1 01:45:33 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <11628-4060>; Mon, 1 Jul 1996 01:45:22 +0300 Received: from miriam.mbar.dtu.dk (miriam.mbar.dtu.dk [130.225.72.51]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id AAA01550; Mon, 1 Jul 1996 00:44:48 +0200 (METDST) Received: (from c948374@localhost) by miriam.mbar.dtu.dk (8.7.3/8.7.3) id AAA16462; Mon, 1 Jul 1996 00:45:15 +0200 (METDST) Date: Mon, 1 Jul 1996 00:45:15 +0200 (METDST) From: Rask Ingemann Lambertsen To: Matthias Gruenewald cc: AMIGA-GCC-PORT Mailing List Subject: Re: GCC Development Info In-Reply-To: <422.6755T949T738@Abakus.DInet.DE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On 30 Jun 1996, Matthias Gruenewald wrote: > Hi! > > I'm new and I want to change from my SAS C Compiler to the GCC System because > I want to program in C++. But there's one thing I miss: the source-level- > debugger. I have heard that there's a debugger for GCC, but there's no AMIGA > port. There is a debugger named gdb and it has been ported to the Amiga. There is also an Amiga debugger for GCC, the Barfly Debugger. Look for a file named Barfly*.lha on Aminet. The Barfly Debugger is shareware. gdb is free and can be found in the lates ADE snapshot on Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: c948374@student.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Try my finger-WWW gateway at http://www.bbar.dtu.dk/~c948374/f.cgi | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Thu Jul 4 15:36:44 1996 Received: from nis.student.dtu.dk ([130.225.87.187]) by nic.funet.fi with ESMTP id <10551-8563> convert rfc822-to-8bit; Thu, 4 Jul 1996 15:36:19 +0300 Received: from lillep.gbar.dtu.dk (lillep.gbar.dtu.dk [130.225.87.179]) by nis.student.dtu.dk (8.7.3/8.7.3) with ESMTP id OAA06375 for ; Thu, 4 Jul 1996 14:35:39 +0200 (METDST) Received: (from c948374@localhost) by lillep.gbar.dtu.dk (8.7.3/8.7.3) id OAA25205; Thu, 4 Jul 1996 14:37:02 +0200 (METDST) Date: Thu, 4 Jul 1996 14:37:02 +0200 (METDST) From: Rask Ingemann Lambertsen X-Sender: c948374@lillep.gbar.dtu.dk Reply-To: Rask Ingemann Lambertsen To: amiga-gcc-port@nic.funet.fi Subject: New updated README for GCC 2.7.2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I have updated the README-file for GCC 2.7.2 (yes, I know, it took a while). You can find it on . To those of you who want the ANSI text version sent by email: Send me an email, and I'll add you to the distribution list. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: rask@kampsax.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Try my finger-WWW gateway at http://www.bbar.dtu.dk/~c948374/f.cgi | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Fri Jul 5 12:52:28 1996 Received: from funet.fi ([130.230.1.1]) by nic.funet.fi with ESMTP id <4029-8696>; Fri, 5 Jul 1996 12:52:21 +0300 X400-Received: by /ADMD=FUMAIL/C=fi/; Relayed; Fri, 5 Jul 1996 12:52:06 +0300 X400-Received: by mta funet.fi in /ADMD=FUMAIL/C=fi/; Relayed; Fri, 5 Jul 1996 12:52:06 +0300 X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Fri, 5 Jul 1996 12:52:01 +0300 Date: Fri, 5 Jul 1996 12:52:01 +0300 X400-Originator: mclem@medphys.ucl.ac.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<9607050951.AA03513@medphys.ucl.] X400-Content-Type: P2-1984 (2) Content-Identifier: g++ 2.7.2 and... Alternate-Recipient: Allowed From: " (Matthew Clemence)" Message-ID: <9607050951.AA03513@medphys.ucl.ac.uk> To: amiga-gcc-port@lists.funet.fi Subject: g++ 2.7.2 and the ADE Hi all, I am looking for some advice. I have just updated my gcc installation to the new version by installing (most of) the ADE version of things. Initial euphoria as everything ran much cleaner was somewhat mitigated by the fact that a reasonably sized third party c++ project (which compiles and runs fine on my UNIX GCC 272 at work) generates an illegal instruction error. Compiler options seem sensible (m68000 no optimisation no FPU) although my machine is an amiga 1200 with an '030 and a 68881 at 50MHz. An hints as to how I could track down this (presumed) compiler fault ? Also with regard to the ADE, (as there are startlingly few readmes) I would like to try out the CVS revision control system but the version installed in the dev/ade just keeps reporting "cannot fork, not implemented". Does this mean that the port is incomplete ? Thanks for any help you can give Yours Matthew Clemence -- ************************************************************************** Dr. Matthew Clemence ___ email mclem@medphys.ucl.ac.uk University College London 11-20 Shropshire House, London, England +44 171 387 9300 x 8448/8264 +44 181 442 1832 Home ************************************************************************** From amiga-gcc-port-owner@nic.funet.fi Fri Jul 5 20:13:04 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <3226-8166>; Fri, 5 Jul 1996 20:12:39 +0300 Received: by fishpond (Smail3.1.29.1 #57) id m0ucESq-000gXUC; Fri, 5 Jul 96 10:14 MST Message-Id: From: fnf@ninemoons.com (Fred Fish) Subject: Re: g++ 2.7.2 and the ADE To: mclem@medphys.ucl.ac.uk Date: Fri, 5 Jul 1996 10:14:42 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9607050951.AA03513@medphys.ucl.ac.uk> from "nic.funet.fi!amiga-gcc-port-owner" at Jul 5, 96 12:52:01 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 845 > Also with regard to the ADE, (as there are startlingly few readmes) I would > like to try out the CVS revision control system but the version installed > in the dev/ade just keeps reporting "cannot fork, not implemented". Does > this mean that the port is incomplete ? Currently I use cvs just to do "cvs checkout" and "cvs update" on a tree that is resident on my Amiga and uses an NFS mounted CVS repository on a FreeBSD machine. It seems to work fine for that, however I know that "cvs diff" has trouble, for instance. I've been meaning to look at that particular problem. What cvs command were you having trouble with? BTW, you should switch to using the ADE lists at ninemoons.com. Send an email containing only "help" as the body of the message to "majordomo@ninemoons.com" to get info about the lists and how to subscribe. -Fred From amiga-gcc-port-owner@nic.funet.fi Sun Jul 7 20:19:20 1996 Received: from europe.std.com ([199.172.62.20]) by nic.funet.fi with ESMTP id <3714-16965>; Sun, 7 Jul 1996 20:19:02 +0300 Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id NAA04752; Sun, 7 Jul 1996 13:18:59 -0400 (EDT) Received: from localhost by world.std.com (5.65c/Spike-2.0) id AA18758; Sun, 7 Jul 1996 13:18:59 -0400 Date: Sun, 7 Jul 1996 13:18:58 -0400 (EDT) From: "Thomas E. Janzen" To: Amiga GCC Subject: wuarchive archives for gcc amiga 2.7.2 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi. I got the base and bin archives for amiga gcc 2.7.2. They don't look the same as described in the readme from gammel. The base archive looks like fsf/gcc/ and a bunch of sources. The bin archive might be ok. There are no other archives. The readme from gammel describes the usual 15 archives, but they aren't on wuarchive. Should I not use these archives? Should I get the archives I need from ninemoons.com? Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio http://world.std.com/~tej From amiga-gcc-port-owner@nic.funet.fi Tue Jul 9 05:43:37 1996 Received: from gateway.x.dtu.dk ([130.225.92.248]) by nic.funet.fi with ESMTP id <10148-26198> convert rfc822-to-8bit; Tue, 9 Jul 1996 05:43:11 +0300 Received: (from uucp@localhost) by gateway.x.dtu.dk (8.7.4/8.7.3) with UUCP id EAA12463 for amiga-gcc-port@lists.funet.fi; Tue, 9 Jul 1996 04:35:11 +0200 Received: from sgi.kampsax.dtu.dk (sgi.kampsax.dtu.dk [123.0.0.1]) by maze.kampsax.dtu.dk (8.7.4/8.7.3) with ESMTP id EAA05587 for ; Tue, 9 Jul 1996 04:04:24 +0200 Received: from k4315.kampsax.dtu.dk ([123.43.15.1]) by sgi.kampsax.dtu.dk (8.7.4/8.7.3) with SMTP id DAA01211 for ; Tue, 9 Jul 1996 03:57:16 +0200 (METDST) From: Rask Ingemann Lambertsen Date: 09 Jul 96 03:57:25 +0100 To: amiga-gcc-port@nic.funet.fi Message-ID: Subject: Re: wuarchive archives for gcc amiga 2.7.2 (forwarded) Organization: Kampsax kollegiet X-Mailer: MiniMail 1.4a (c) 1996 by Pelle Claesson of TheEnd Amiga MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On 7 Jul 1996 13:18 -0400 (-0500), Thomas E. Janzen wrote to me: > Hi. I got the base and bin archives for amiga gcc 2.7.2. They don't look > the same as described in the readme from gammel. > The base archive looks like fsf/gcc/ and a bunch of sources. > The bin archive might be ok. There are no other archives. > The readme from gammel describes the usual 15 archives, but they aren't on > wuarchive. Should I not use these archives? Should I get the archives I > need from ninemoons.com? As you have noticed, the ADE GCC archives are organised differently from Philippe's distribution. In ADE, the "bin" archive is the precompiled binaries, the "base" archive is the FSF sources, the "src" is the source used to compile the "bin" archive and the "diff" archive is the diff files used to create the "src" archive from the "base" archive. (The "bin" archives should installed in the "Trashcan" drawer ;-) Philippe's archives are organized as described in the README file inside those archives. I would like to know what you mean when you say "readme from gammel". Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: rask@kampsax.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Try my finger-WWW gateway at http://www.bbar.dtu.dk/~c948374/f.cgi | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Sun Jul 21 17:38:01 1996 Received: from europe.std.com ([199.172.62.20]) by nic.funet.fi with ESMTP id <63112-32741>; Sun, 21 Jul 1996 17:37:51 +0300 Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id KAA28098; Sun, 21 Jul 1996 10:37:49 -0400 (EDT) Received: from localhost by world.std.com (5.65c/Spike-2.0) id AA14938; Sun, 21 Jul 1996 10:37:48 -0400 Date: Sun, 21 Jul 1996 10:37:48 -0400 (EDT) From: "Thomas E. Janzen" To: Amiga GCC Subject: ? error message: ssystem() is no longer supported. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi. I can't use the gcc 2.7.0 compiler any more. I get a message: ssystem() is no longer supported. See the document 'important.readme' for more information. There is of course no such document. I had tried to install 2.7.2 from aminet into a separate area on my disk, but that was confusing so I deleted it. Since I couldn't find 2.7.2 kits on the official bulletin boards (colombo.telis-sc.fr, ftp.funet.fi), I gave up until they are available. Could I have corrupted my installation of 2.7.0? Should I re-install it? When will a clean documented non-aminet kit of 2.7.2 be available? You know, one that isn't 40Mb if you don't need object c. Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio http://world.std.com/~tej From amiga-gcc-port-owner@nic.funet.fi Sun Jul 21 22:30:21 1996 Received: from europe.std.com ([199.172.62.20]) by nic.funet.fi with ESMTP id <63966-32741>; Sun, 21 Jul 1996 22:30:17 +0300 Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id PAA01804; Sun, 21 Jul 1996 15:30:13 -0400 (EDT) Received: from localhost by world.std.com (5.65c/Spike-2.0) id AA11454; Sun, 21 Jul 1996 15:30:13 -0400 Date: Sun, 21 Jul 1996 15:30:12 -0400 (EDT) From: "Thomas E. Janzen" To: Amiga GCC Subject: Re: ? error message: ssystem() is no longer supported. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks everybody for explaining that ixemul dropped ssystem; that I could compile with gccv (I can about invoking g++ in the man pages); where to get the ade distribution. Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio http://world.std.com/~tej From amiga-gcc-port-owner@nic.funet.fi Fri Aug 2 14:32:30 1996 Received: from delta.mdy.univie.ac.at ([131.130.40.6]) by nic.funet.fi with SMTP id <75501-28129>; Fri, 2 Aug 1996 15:31:51 +0100 Received: from localhost by delta.mdy.univie.ac.at with SMTP (1.38.193.4/16.2) id AA07178; Fri, 2 Aug 1996 13:28:07 +0200 Sender: am@mdy.univie.ac.at Message-Id: <3201E646.456B@mdy.univie.ac.at> Date: Fri, 02 Aug 1996 13:28:06 +0200 From: Alfred Minarik X-Mailer: Mozilla 3.0b5a (X11; I; HP-UX A.09.05 9000/720) Mime-Version: 1.0 To: amiga-gcc-info , amiga-gcc-port , amiga-mach , amiga-x11 Subject: help Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit help From amiga-gcc-port-owner@nic.funet.fi Sat Aug 3 01:41:26 1996 Received: from gateway.x.dtu.dk ([130.225.92.248]) by nic.funet.fi with ESMTP id <75363-16077> convert rfc822-to-8bit; Sat, 3 Aug 1996 02:40:36 +0100 Received: (from uucp@localhost) by gateway.x.dtu.dk (8.7.4/8.7.3) with UUCP id AAA29285; Sat, 3 Aug 1996 00:40:22 +0200 Received: from sgi.kampsax.dtu.dk (sgi.kampsax.dtu.dk [123.0.0.1]) by maze.kampsax.dtu.dk (8.7.4/8.7.3) with ESMTP id XAA12282; Fri, 2 Aug 1996 23:56:34 +0200 Received: from k4315.kampsax.dtu.dk (k4315.kampsax.dtu.dk [123.43.15.1]) by sgi.kampsax.dtu.dk (8.7.4/8.7.3) with SMTP id XAA08309; Fri, 2 Aug 1996 23:53:15 +0200 (METDST) From: Rask Ingemann Lambertsen Date: 02 Aug 96 23:52:43 +0100 To: Alfred Minarik Cc: , , In-Reply-To: <3201E646.456B@mdy.univie.ac.at> (by: Alfred Minarik ) Message-ID: Subject: Re: help Organization: Kampsax kollegiet X-Mailer: MiniMail 1.4b (2.7.96) (c) 1996 by Pelle Claesson of TheEnd Amiga (http://www.lls.se/~volley) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On 02 Aug 1996 13:28 +0200 (+0100), Alfred Minarik wrote to me: > help With what? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: rask@kampsax.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Try my finger-WWW gateway at http://www.bbar.dtu.dk/~c948374/f.cgi | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Sat Aug 3 02:31:01 1996 Received: from kokee.hawaiian.net ([206.154.198.100]) by nic.funet.fi with SMTP id <74937-5883>; Sat, 3 Aug 1996 03:28:18 +0100 Received: from hawaiian.net (s07.hawaiian.net [206.154.198.57]) by kokee.hawaiian.net (8.6.12/8.6.9) with SMTP id NAA06805; Fri, 2 Aug 1996 13:30:12 -1000 From: lopaka Reply-To: lo@hawaiian.net To: Rask Ingemann Lambertsen , Alfred Minarik CC: amiga-gcc-port@nic.funet.fi, amiga-gcc-info@nic.funet.fi, amiga-x11@nic.funet.fi Date: Fri, 02 Aug 1996 13:24:11 -1000 Message-ID: In-Reply-To: X-Mailer: YAM 1.3.1 - Amiga Mailer by Marcel Beck Subject: Re: help MIME-Version: 1.0 Content-Type: text/plain >On 02 Aug 1996 13:28 +0200 (+0100), Alfred Minarik wrote to me: >> help >With what? click the Icon? -- Robert ////\ lo@hawaiian.net http://www.hawaiian.net/~lo Holtwick ////_\\ GVP-2000'030 @50Mhz/1C/8F/PII/Conner1060S (Lopaka) //// \\\ miga... Back for the Future!(?) From amiga-gcc-port-owner@nic.funet.fi Sun Aug 4 02:48:43 1996 Received: from europe.std.com ([199.172.62.20]) by nic.funet.fi with ESMTP id <74889-27180>; Sun, 4 Aug 1996 03:48:22 +0100 Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id TAA24597; Sat, 3 Aug 1996 19:48:12 -0400 (EDT) Received: from localhost by world.std.com (5.65c/Spike-2.0) id AA18755; Sat, 3 Aug 1996 19:48:11 -0400 Date: Sat, 3 Aug 1996 19:48:11 -0400 (EDT) From: "Thomas E. Janzen" To: Amiga GCC Subject: inclib? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi. wow. OK. So a month later I still can't install gcc 2.7.2. I must be the only one who wants it who isn't on the development team. Anyway, I ftpd to ninemoons.com and got a file called readme-2.7.2 by Markus Wild and Philippe Brand and Fred Fish and Leonard Norrgard. This file mentions the following files as important for a gcc installation: gcc272-inclib.lha gcc272-base.lha (not probably 8Mb with an fsf directory of original FSF sources, probably just like the 2.7.0 base I installed a couple years ago). gcc272-c-020.lha gcc272-cp-020.lha gcc272-doc.lha gcc272-utils.lha gcc272-utilsdocs.lha Unfortunately, these files are not to be found at ninemoons/ade/[date]. They are not to be found on aminet under /dev/ade. There was a *base.lha file at aminet but it was 8Mb and just had the fsf directory of sources ported to the amiga by fred. Now I am supposed to be getting a free aminet CD soon because I wrote a couple little music programs on it. Should I just wait for this and buy a cheap CD ROM drive? Is gcc 2.7.2 on it with the above files? I would have stopped trying to install 2.7.2 but I broke 2.7.0 by installing a newer ixemul.lib and I tried using gccv, which worked for C but I am interested in c++ and I can't find documentation on the switches to gccv for invoking c++. I would be grateful if you could help me find the needed files or send me the old ixemul with ssystem. Thanks. Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio http://world.std.com/~tej From amiga-gcc-port-owner@nic.funet.fi Thu Sep 5 15:32:09 1996 Received: from wckn.dorm.clarkson.edu ([128.153.129.2]) by nic.funet.fi with SMTP id <74792-18271>; Thu, 5 Sep 1996 15:30:04 +0300 Received: by wckn.dorm.clarkson.edu (4.1/SMI-4.1) id AA29671; Thu, 5 Sep 96 08:29:45 EDT Date: Thu, 5 Sep 96 08:29:45 EDT From: Rob Message-Id: <9609051229.AA29671@wckn.dorm.clarkson.edu> To: amiga-gcc-port@lists.funet.fi Subject: Dependency autogeneration case change problem. I have run into a case change problem when using gcc to generate dependencies. Example: > gcc -MM File.m > all.d > type all.d > file.o: file.m File.h RobStd.h FormattedProt.h Safe.h (note: the .m extension denotes Objective-C code) Notice, it changed the case on the name it auto-generated but took the correct case from the #include - derived filenames. Now, when I pull the resulting information into my Makefile with, > include all.d the Makefile doesn't equate file.o and File.o (the real target). In the past (in this archive of this list) people have stated that make doesn't care about case. This isn't true. When make wants to access a file, it's case-insensitive but internally it is case-dependent. So... I can't use gcc to generate working dependencies. I am currently using a hack. I specify the target name in the Makefile like this: > TARGETS := file.o in lower case. Now make can figure out that the information in the dependency list is associated with this file. The problem with this hack is that when I port to a unix system, my Makefile is no longer valid. On such a system make is case-sensitive internally and externally. This problem appears to be caused in cpp. It is reproducible by calling cpp directly with the -MM flag. BTW, I am unable to recompile cpp on my machine due to memory restrictions. Please cc any suggestions or direct responses to me as I have only recently subscribed to this list and I'm not getting mail from it yet, thanks. I have been using: vanilla gcc 2.7.0 (020 dist) make 3.71 ixemul 43.1 ix_no_insert_disk_requester=1 ix_unix_pattern_matching_case_sensitive=1 ix_unix_pattern_matching=1 ix_no_ces_then_open_console=1 ix_ignore_global_env=0 ix_disable_fibcache=0 ix_translate_dots=1 ix_watch_stack=1 ix_force_translation=1 ix_translate_symlinks=0 ix_translate_slash=1 ix_membuf_limit=0 ix_red_zone_size=64 ix_fs_buf_factor=64 -Robert Dick (dickrp@wckn.dorm.clarkson.edu)- From amiga-gcc-port-owner@nic.funet.fi Thu Sep 5 15:37:29 1996 Received: from rzcomm1.rz.tu-bs.de ([134.169.9.107]) by nic.funet.fi with ESMTP id <75091-12099>; Thu, 5 Sep 1996 15:36:05 +0300 Received: from rzserv8 (rzserv8.rz.tu-bs.de) by rzcomm1.rz.tu-bs.de with SMTP (1.37.109.18/16.2) id AA018306950; Thu, 5 Sep 1996 14:35:51 +0200 Sender: y0000135@tu-bs.de Message-Id: <322EC8FD.34F2@tu-bs.de> Date: Thu, 05 Sep 1996 14:35:09 +0200 From: Sven Heithecker Organization: HTS HighTech-Systems X-Mailer: Mozilla 2.02 (X11; I; HP-UX A.09.05 9000/735) Mime-Version: 1.0 To: amiga-gcc-port@nic.funet.fi Subject: unsubscribe Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit -- ____ |_||_ Ceterum Censeo MEGAHARD Esse Delendam | | _| HTS Sven Heithecker s.heithecker@tu-bs.de From amiga-gcc-port-owner@nic.funet.fi Thu Sep 5 16:04:15 1996 Received: from fishpond ([165.247.33.2]) by nic.funet.fi with SMTP id <74621-18271>; Thu, 5 Sep 1996 16:02:50 +0300 Received: by fishpond (Smail3.1.29.1 #57) id m0uye2Y-000gXYC; Thu, 5 Sep 96 06:00 MST Message-Id: From: fnf@ninemoons.com (Fred Fish) Subject: Re: Dependency autogeneration case change problem. To: dickrp@wckn.dorm.clarkson.edu (Rob) Date: Thu, 5 Sep 1996 06:00:13 -0700 (MST) Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9609051229.AA29671@wckn.dorm.clarkson.edu> from "Rob" at Sep 5, 96 08:29:45 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 510 > I have run into a case change problem when using gcc to generate > dependencies. > > Example: > > gcc -MM File.m > all.d > > type all.d > > file.o: file.m File.h RobStd.h FormattedProt.h Safe.h > ... > I have been using: > vanilla gcc 2.7.0 (020 dist) > make 3.71 > ixemul 43.1 I just tried a similar example using a source file "Junk.c" that includes "Foo.h", and with the current snapshot got: Junk.o: Junk.c Foo.h I don't know offhand what the problem could be with your environment. -Fred From amiga-gcc-port-owner@nic.funet.fi Thu Sep 5 18:17:36 1996 Received: from gateway.x.dtu.dk ([130.225.92.248]) by nic.funet.fi with ESMTP id <74812-18271> convert rfc822-to-8bit; Thu, 5 Sep 1996 18:16:35 +0300 Received: (from uucp@localhost) by gateway.x.dtu.dk (8.7.4/8.7.3) with UUCP id QAA09515; Thu, 5 Sep 1996 16:42:29 +0200 Received: from k4315.kampsax.dtu.dk (k4315.kampsax.dtu.dk [123.43.15.1]) by maze.kampsax.dtu.dk (8.7.4/8.7.3) with SMTP id PAA07708; Thu, 5 Sep 1996 15:30:14 +0200 From: Rask Ingemann Lambertsen Date: 05 Sep 96 15:27:20 +0100 To: Rob Cc: amiga-gcc-port@nic.funet.fi In-Reply-To: <9609051229.AA29671@wckn.dorm.clarkson.edu> (by: Rob ) Message-ID: Subject: Re: Dependency autogeneration case change problem. Organization: Kampsax kollegiet X-Mailer: MiniMail 1.4b (2.7.96) (c) 1996 by Pelle Claesson of TheEnd Amiga (http://www.lls.se/~volley) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On 5 Sep 96 8:29 -0400 (-0500), Rob wrote to me: > I have run into a case change problem when using gcc to generate > dependencies. > Example: >> gcc -MM File.m > all.d >> type all.d >> file.o: file.m File.h RobStd.h FormattedProt.h Safe.h > (note: the .m extension denotes Objective-C code) > Notice, it changed the case on the name it auto-generated but took > the correct case from the #include - derived filenames. The automatic lowercasing of file names was put into cpp because ?????????? It has been removed in the latest ADE snapshot. Read for more information about ADE. > In the past (in this archive of this list) people have stated that make > doesn't care about case. This isn't true. When make wants to access > a file, it's case-insensitive but internally it is case-dependent. Actually, it is the file system that is case insensitive, not make. Most (but not all!) Amiga file systems are case insensitive. Make itself is always case sensitive. Personally, I consider case sensitivity a feature. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: rask@kampsax.dtu.dk | | Amiga GNU CC README maintainer | WWW: http://www.gbar.dtu.dk/~c948374/ | | Registered Phase5 developer | "ThrustMe" on XPilot, ARCnet and IRC | | Keyboard error: and are stuck - press to continue | From amiga-gcc-port-owner@nic.funet.fi Wed Sep 18 15:46:17 1996 Received: from mail.cs.tu-berlin.de ([130.149.17.13]) by nic.funet.fi with ESMTP id <74872-16091>; Wed, 18 Sep 1996 15:45:54 +0300 Received: from fieber.cs.tu-berlin.de (halamoda@fieber.cs.tu-berlin.de [130.149.17.124]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id OAA27663 for ; Wed, 18 Sep 1996 14:45:42 +0200 Received: (from halamoda@localhost) by fieber.cs.tu-berlin.de (8.7.5/8.7.3) id OAA26851; Wed, 18 Sep 1996 14:45:36 +0200 (MET DST) Date: Wed, 18 Sep 1996 14:45:35 +0200 (MET DST) From: Adrian Halamoda To: amiga-gcc-port@nic.funet.fi Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe amiga-gcc-port From amiga-gcc-port-owner@nic.funet.fi Mon Sep 23 04:02:38 1996 Received: from hplb.hpl.hp.com ([15.255.59.2]) by nic.funet.fi with ESMTP id <73636-25303>; Mon, 23 Sep 1996 04:00:46 +0300 Received: from hpindnun.cup.hp.com by hplb.hpl.hp.com; Mon, 23 Sep 1996 02:00:34 +0100 Received: from localhost by hpindnun.cup.hp.com with SMTP (1.38.193.4/15.5+IOS 3.20+cup+OMrelay) id AA12934; Sun, 22 Sep 1996 18:07:16 -0700 Message-Id: <9609230107.AA12934@hpindnun.cup.hp.com> To: amiga-gcc-port@nic.funet.fi Subject: Gcc 2.7.2 won't run with my Cyberstorm '060 board!?? Date: Sun, 22 Sep 1996 18:07:15 -0700 From: Charles Hymes Is this a known problem? The latest version of GCC hangs now that my 060 board with a 16mb simm is installed. When I turn off all caches and other 060 featuers, it does not help. I have the latest ixlib040 stuff too. I do not remember the exact error message, but it is a "segmentation fault" caused by "internal error 11" how can I fix this? /* begin Whine mode */ 3/4 of the reason I shelled out $1000 was to improve my development envionment! Help and advice please! /* end Whine mode */ Charlweed From amiga-gcc-port-owner@nic.funet.fi Mon Sep 23 18:35:36 1996 Received: from ee.bilkent.edu.tr ([139.179.10.230]) by nic.funet.fi with SMTP id <74610-25303>; Mon, 23 Sep 1996 18:32:06 +0300 Received: from marmaris (marmaris.ee.bilkent.edu.tr) by ee.bilkent.edu.tr (4.1/SMI-4.1) id AA14773; Mon, 23 Sep 96 18:27:43 +0300 Date: Mon, 23 Sep 96 18:27:43 +0300 From: ekmekci@ee.bilkent.edu.tr (Tolga Ekmekci) Message-Id: <9609231427.AA14773@ee.bilkent.edu.tr> To: amiga-gcc-port@nic.funet.fi Subject: unsubscribe unsubscribe From amiga-gcc-port-owner@nic.funet.fi Mon Sep 23 20:48:27 1996 Received: from entergy.com ([148.127.68.6]) by nic.funet.fi with SMTP id <75342-25303>; Mon, 23 Sep 1996 20:45:52 +0300 Received: from cc3smtplink by entergy.com (SMI-8.6/SMI-SVR4) id MAA20655; Mon, 23 Sep 1996 12:45:26 -0500 From: khowe90@entergy.com Received: from ccMail by cc3smtplink (SMTPLINK V2.10.08) id AA843507660; Mon, 23 Sep 96 12:29:24 CST Date: Mon, 23 Sep 96 12:29:24 CST Message-Id: <9608238435.AA843507660@cc3smtplink> To: amiga-gcc-port@nic.funet.fi Subject: Re: unsubscribe unsubscribe From amiga-gcc-port-owner@nic.funet.fi Mon Oct 21 18:38:26 1996 Received: from gemini.mth.monroecc.edu ([150.160.44.31]) by nic.funet.fi with SMTP id <67525-3586>; Mon, 21 Oct 1996 18:37:12 +0200 Received: by gemini.mth.monroecc.edu (MX V4.2 VAX) id 1; Mon, 21 Oct 1996 12:09:05 EST5EDT4,M4.1.0,M10.5.0 Date: Mon, 21 Oct 1996 12:09:04 EST5EDT4,M4.1.0,M10.5.0 From: tpoweigha@gemini.mth.monroecc.edu To: amiga-gcc-port@nic.funet.fi Message-ID: <009AA2D1.1D97E740.1@gemini.mth.monroecc.edu> Subject: IXEMUL LIBRARY I recently downloaded what in the readme file was stated as IXEMUL.LIBRARY version 45.0. After I had unarced and installed it, a check with version showed that it was actually version 39.94 I think. Ixnet.library was version 45.0 though. Where can I get the full version 45.0 compiled for the 68000? I have an A-1000 with 4.5 Meg of RAM, and 540 meg of SCSI harddisk space and version 2.04 of the OS. Please help. Thanks. From amiga-gcc-port-owner@nic.funet.fi Mon Nov 4 12:06:16 1996 Received: from baurz32.urz.uni-bamberg.de ([141.13.250.32]) by nic.funet.fi with SMTP id <61984-2928>; Mon, 4 Nov 1996 12:05:51 +0200 Received: from urzmail.stud.uni-bamberg.de by baurz32.urz.uni-bamberg.de with SMTP (1.37.109.4/16.2) id AA08398; Mon, 4 Nov 96 11:05:27 +0100 Received: from URZMAIL/SpoolDir by urzmail.stud.uni-bamberg.de (Mercury 1.21); 4 Nov 96 11:08:32 GMT+1 Received: from SpoolDir by URZMAIL (Mercury 1.30); 4 Nov 96 11:08:04 GMT+1 From: "Stefan Westner" Organization: UNI-BAMBERG To: amiga-gcc-port@nic.funet.fi Date: Mon, 4 Nov 1996 11:08:01 GMT+0100 Subject: X-Confirm-Reading-To: "Stefan Westner" X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <7C2E886869@urzmail.stud.uni-bamberg.de> unsubscribe amiga-gcc-port -------------------------------------------------------------------------- Stefan Westner E-Mail: Stefan.Westner@stud.uni-bamberg.de PGP-Public-Key auf Anfrage verfuegbar PGP-Public-Key available on request -------------------------------------------------------------------------- The computer fanatic knows that computers are infallible... ...it's the Human Factor that messes thing up. From amiga-gcc-port-owner@nic.funet.fi Thu Nov 7 00:37:16 1996 Received: from relay-7.mail.demon.net ([194.217.242.9]) by nic.funet.fi with SMTP id <62249-18169> convert rfc822-to-8bit; Thu, 7 Nov 1996 00:37:10 +0200 Received: from nutz.demon.co.uk ([158.152.75.116]) by relay-6.mail.demon.net id aa610956; 6 Nov 96 21:03 GMT From: Jonathan Evans To: amiga-gcc-port@nic.funet.fi Subject: unsub Date: Wed, 06 Nov 1996 21:04:39 GMT Organization: Welsh Coast Message-ID: <3280c115.489430@post.demon.co.uk> X-Mailer: Forte Agent .99f/32.299 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT unsubscribe amiga-gcc-port From amiga-gcc-port-owner@nic.funet.fi Fri Jan 3 16:01:04 1997 Received: from theory.cs.uni-bonn.de ([131.220.4.161]) by nic.funet.fi with ESMTP id <65158-6112>; Fri, 3 Jan 1997 15:59:32 +0200 Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.7.1/8.7.1) id OAA14320; Fri, 3 Jan 1997 14:57:57 +0100 (MET) Date: Fri, 3 Jan 1997 14:57:57 +0100 (MET) Message-Id: <199701031357.OAA14320@theory.cs.uni-bonn.de> From: Ignatios Souvatzis To: will@clinet.fi CC: gc948374@gbar.dtu.dk, amiga-gcc-port@nic.funet.fi In-reply-to: <199601251627.SAA06215@newzetor.clinet.fi> (message from Ville-Pertti Keinonen on Thu, 25 Jan 1996 18:27:57 +0200 (EET)) Subject: Re: Optimizations. Return-Path: I know this is almost one year too late but maybe you're interested in numbers: On a 68060/50 machine (DraCo), NetBSD-1.2's integration of the 68060 unimplemented integer instruction trap runs at about 111000 32->64 muls per second. NetBSD-current runs at about 150000 32->64 muls per second. There is some margin to make this even faster; I hope I'll have time for this befor -1.3 is released. Regards, Ignatios Souvatzis From amiga-gcc-port-owner@nic.funet.fi Thu Sep 25 21:04:32 1997 Received: from [194.251.78.130] ([194.251.78.130] EHLO plaiserver.plai.fi ident: TIMEDOUT [port 43270]) by nic.funet.fi with ESMTP id <15723-19697> convert rfc822-to-8bit; Thu, 25 Sep 1997 20:23:38 +0300 Received: from k7-01.plai.fi ([194.251.78.187]) by plaiserver.plai.fi (Netscape Mail Server v2.02) with SMTP id AAA552 for ; Thu, 25 Sep 1997 20:06:21 +0300 Received: by k7-01.plai.fi with Microsoft Mail id <01BCC9EE.7DE09180@k7-01.plai.fi>; Thu, 25 Sep 1997 20:06:21 +0300 Message-ID: <01BCC9EE.7DE09180@k7-01.plai.fi> From: matti.niskanen@plai.fi (Matti Niskanen) To: "'amiga-gcc-port@nic.funet.fi'" Subject: Amiga G++ float problem Date: Thu, 25 Sep 1997 20:06:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Return-Path: X-Orcpt: rfc822;amiga-gcc-port-log This is Matti Niskanen from Sodankyla, Finland. I have a problem with Amiga GNU C++. This code works very well on MSDOS GNU, but crashes on Amiga. I can't figure out how to calculate floating point variables. Help me, please! #include #include #include int main() { int a, b; float c; printf("Give me two integer numbers.\n"); scanf("%i%i", &a, &b); printf("The first number %i is divided by the second number %i:\n", a, b); c = (float) a / b; printf("The result is %.2f\n", c); return 0; } // Compiled with "g++ -noixemul -lm -ansi test.c" From amiga-gcc-port-owner@lists.funet.fi Wed Nov 4 21:04:29 1998 Received: from sirius.cab.u-szeged.hu ([160.114.36.147]:55194 "HELO sirius.cab.u-szeged.hu" ident: "qmailr") by nic.funet.fi with SMTP id <11124-9020>; Wed, 4 Nov 1998 21:04:02 +0200 Received: (qmail 19156 invoked by uid 34790); 4 Nov 1998 19:04:04 -0000 Date: Wed, 4 Nov 1998 20:04:04 +0100 (MET) From: Szegedi Bela X-Sender: h734790@sirius To: amiga-gcc-port@lists.funet.fi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Orcpt: rfc822;amiga-gcc-port-log Hello All! I need some help. Is it really absolutely impossible to learn C++ on a plain A1200 (no fastram)? I wanted to try GCC but I've found it huge. Can anyone suggest something? Should I try older products? If so, where to get them? Many thanks in anticipation! And please forgive me for my english... Bela Szegedi