From amigappc-dev-owner@amiga.com.pl Thu Jul 2 15:54:20 1998 Received: from biff.stud.ntnu.no (biff.stud.ntnu.no [129.241.56.18]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id PAA27456 for ; Thu, 2 Jul 1998 15:49:29 +0200 (CEST) Received: from triumph.no (meh@ti10a95-0171.dialup.online.no [130.67.83.171]) by biff.stud.ntnu.no (8.8.8/8.8.8) with SMTP id PAA05368 for ; Thu, 2 Jul 1998 15:47:53 +0200 (MET DST) From: Mats Eirik Hansen To: "AmigaPPC developers' mailing list" Date: Thu, 02 Jul 1998 14:53:48 +0100 Message-ID: In-Reply-To: <358BA615.MD-0.198.jmarcet@pobox.com> Subject: Re: inline/ppc.h MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: On 20-Jun-98, Javier Marcet wrote: > How can I create the PPC inlines needed by GCC? > I can't find the fd files to generate them with fd2inline. There is a fd file in the new 46 distribution. > -- > Javier Marcet E-MAIL: jmarcet@pobox.com > Pizarro 81 7th D WWW : http://pobox.com/~jmarcet > Vigo, 36204 IRC : Boludo > SPAIN PGP key available on request. > -- WFMH AmigaPPC-Dev ------------------------------------------------------- > http://amiga.com.pl/lists/ Regards -- Mats Eirik Hansen mats.hansen@triumph.no http://www.stud.ntnu.no/~matsha From amigappc-dev-owner@amiga.com.pl Fri Jul 3 00:34:19 1998 Received: from ikp.ikp.pl (ikp.ikp.pl [157.25.5.3]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id AAA29105 for ; Fri, 3 Jul 1998 00:24:34 +0200 (CEST) Received: from union.org.pl (ppp3-cst46.warszawa.tpnet.pl [195.116.251.46]) by ikp.ikp.pl (8.8.6/8.8.6) with SMTP id AAA01925 for ; Fri, 3 Jul 1998 00:36:18 +0200 (CEST) From: Artur Muszynski To: "AmigaPPC developers' mailing list" Date: Fri, 03 Jul 1998 00:22:02 +0100 Message-ID: Subject: DoMethod MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: How to implement or replace DoMethodA() call form amiga.lib for ELF code? I have tried DoDTMethodA() but it makes crash (even compiled for M68K). -- // Artur Muszynski (AMST/UNION) A4000/040/EGS \// e-mail: amst@union.org.pl From amigappc-dev-owner@amiga.com.pl Fri Jul 3 01:54:23 1998 Received: from union.art.pl (szymon.supermedia.pl [195.116.168.93]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id BAA29312 for ; Fri, 3 Jul 1998 01:39:12 +0200 (CEST) Received: from union.org.pl [195.116.251.245] by union.art.pl [127.0.0.1] with SMTP (MDaemon.v2.7.SP2.R) for ; Fri, 03 Jul 1998 01:40:05 +0200 From: Peter Drapich To: "AmigaPPC developers' mailing list" Date: Fri, 03 Jul 1998 01:34:52 +0100 Message-ID: In-Reply-To: Subject: Re: DoMethod MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: On 03-Jul-98, Artur Muszynski wrote: >How to implement or replace DoMethodA() call form amiga.lib for ELF code? I >have tried DoDTMethodA() but it makes crash (even compiled for M68K). You can't - the only solution is to call a 68k routine in a 68k loader which calls this func, linked with this loader. Or you can write the replacement fuction for ppc - good luck..:) regards, Peter -- "Very funny Scotty, now beam down my clothes!" From amigappc-dev-owner@amiga.com.pl Fri Jul 3 23:15:18 1998 Received: from mail.cityweb.de (mail0.cityweb.de [193.189.224.209]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id XAA04609 for ; Fri, 3 Jul 1998 23:06:42 +0200 (CEST) Received: from dsdf-m99-96.pool.cww.de (dsdf-m99-96.pool.cww.de [195.71.99.96]) by mail.cityweb.de (8.8.7/8.8.7/powered by Telemedia) with SMTP id XAA25580 for ; Fri, 3 Jul 1998 23:05:00 +0200 (MET DST) Date: 03 Jul 98 22:33:26 +0100 From: "Markus Adamski" Subject: Re: DoMethod To: "AmigaPPC developers' mailing list" In-Reply-To: Message-ID: <641.488T1322T13534266@cityweb.de> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: On 03-Jul-98 01:34:52 Peter Drapich wrote about "Re: DoMethod": >On 03-Jul-98, Artur Muszynski wrote: >>How to implement or replace DoMethodA() call form amiga.lib for ELF code? I >>have tried DoDTMethodA() but it makes crash (even compiled for M68K). >You can't - the only solution is to call a 68k routine in a 68k loader which >calls this func, linked with this loader. Or you can write the replacement >fuction for ppc - good luck..:) The new ppc.library has a DoMethod()-like function. --Markus A4000T/060@50/604@150/OS3.1/2+96MB RAM/3.2GB HD/CV64-3D Using THOR 2.5a -- Make it idiot proof and someone will make a better idiot. From amigappc-dev-owner@amiga.com.pl Fri Jul 10 00:35:28 1998 Received: from ikp.ikp.pl (ikp.ikp.pl [157.25.5.3]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id AAA09042 for ; Fri, 10 Jul 1998 00:24:10 +0200 (CEST) Received: from union.org.pl (ppp-cst250.warszawa.tpnet.pl [194.204.131.250]) by ikp.ikp.pl (8.8.6/8.8.6) with SMTP id AAA03800 for ; Fri, 10 Jul 1998 00:36:16 +0200 (CEST) From: Artur Muszynski To: "AmigaPPC developers' mailing list" Date: Fri, 10 Jul 1998 00:20:24 +0100 Message-ID: Subject: optimizations in sas/c MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hello, Does scppc optimize anything? Such simple loop as follows compiles to very awful code (for me at least). I turned on all optimizations in scopts. This is my loop: ; 78: for(y=0; ysy; y++) ; 79: for(x=0; xsx; x++) ; 80: vp->zbuf[x+y*vp->sx] = MAXZ; This is dissassembly of the most nested loop: ___ClearZbuffer__11: LHZ r11,r31,0 ; a17f0000 ADDIS r8,r0,74 ; 3d000000 ANDI. r11,r11,ffff ; 716bffff MULLW r12,r30,r11 ; 7d9e59d6 LFS fr1,r8,74 ; c0280074 LWZ r6,r31,10 ; 80df0010 ADD r4,r29,r12 ; 7c9d6214 RLWINM r5,r4,2,0,1d ; 5485103a ADD r7,r5,r6 ; 7ce53214 STFS fr1,r7,0 ; d0270000 ADDI r29,r29,1 ; 3bbd0001 ___ClearZbuffer__12: ORI r9,r26,0 ; 63490000 ANDI. r9,r9,ffff ; 7129ffff CMP cr0,r29,r9 ; 7c1d4800 BC c,0,ffffffc8 ; 4180ffc8 ___ClearZbuffer__11 -- // Artur Muszynski (AMST/UNION) A4000/040/EGS \// e-mail: amst@union.org.pl From amigappc-dev-owner@amiga.com.pl Fri Jul 10 02:55:16 1998 Received: from raleigh7-014.dyn.interpath.net (raleigh7-014.dyn.interpath.net [207.59.134.14]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id CAA11265 for ; Fri, 10 Jul 1998 02:41:54 +0200 (CEST) Received: by raleigh7-014.dyn.interpath.net (Interworks_SMTPpost 8.102 February 12, 1997) id AA01; Thu, 9 Jul 1998 20:36:16 Received: by raleigh7-014.dyn.interpath.net (Interworks_SMTPpost 8.102 February 12, 1997) id AA01; Thu, 9 Jul 1998 20:36:04 From: Jim Cooper MIME-Version: 1.0 In-Reply-To: Subject: Re: optimizations in sas/c Date: Thu, 9 Jul 1998 20:36:04 (+0500) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit To: amigappc-dev@AMIGA.COM.PL Message-ID: <19980709.836A640.1229E@raleigh7-014.dyn.interpath.net> Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: In "optimizations in sas/c", Artur Muszynski wrote: > Does scppc optimize anything? Such simple loop as follows compiles to very > awful code (for me at least). I turned on all optimizations in scopts. > > This is my loop: > > ; 78: for(y=0; ysy; y++) > ; 79: for(x=0; xsx; x++) > ; 80: vp->zbuf[x+y*vp->sx] = MAXZ; > > This is dissassembly of the most nested loop: > > ___ClearZbuffer__11: > LHZ r11,r31,0 ; a17f0000 > ADDIS r8,r0,74 ; 3d000000 > ANDI. r11,r11,ffff ; 716bffff > MULLW r12,r30,r11 ; 7d9e59d6 > LFS fr1,r8,74 ; c0280074 > LWZ r6,r31,10 ; 80df0010 > ADD r4,r29,r12 ; 7c9d6214 > RLWINM r5,r4,2,0,1d ; 5485103a > ADD r7,r5,r6 ; 7ce53214 > STFS fr1,r7,0 ; d0270000 > ADDI r29,r29,1 ; 3bbd0001 > ___ClearZbuffer__12: > ORI r9,r26,0 ; 63490000 > ANDI. r9,r9,ffff ; 7129ffff > CMP cr0,r29,r9 ; 7c1d4800 > BC c,0,ffffffc8 ; 4180ffc8 > ___ClearZbuffer__11 How are 'x', 'y', 'vp', etc. declared? I hope you're not using SHORT variables... the compiler has _always_ done crappy code for those. From amigappc-dev-owner@amiga.com.pl Fri Jul 10 10:56:29 1998 Received: from ikp.ikp.pl (ikp.ikp.pl [157.25.5.3]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id KAA12030 for ; Fri, 10 Jul 1998 10:46:42 +0200 (CEST) Received: from union.org.pl (ppp4-162.warszawa.tpnet.pl [195.205.246.162]) by ikp.ikp.pl (8.8.6/8.8.6) with SMTP id KAA18315 for ; Fri, 10 Jul 1998 10:58:48 +0200 (CEST) From: Artur Muszynski To: "AmigaPPC developers' mailing list" Date: Fri, 10 Jul 1998 10:38:50 +0100 Message-ID: In-Reply-To: <19980709.836A640.1229E@raleigh7-014.dyn.interpath.net> Subject: Re[2]: optimizations in sas/c MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: On 09-Jul-98, Jim Cooper wrote: > In "optimizations in sas/c", Artur Muszynski wrote: > > Does scppc optimize anything? Such simple loop as follows compiles to very > > awful code (for me at least). I turned on all optimizations in scopts. > > > > This is my loop: > > > > ; 78: for(y=0; ysy; y++) > > ; 79: for(x=0; xsx; x++) > > ; 80: vp->zbuf[x+y*vp->sx] = MAXZ; > How are 'x', 'y', 'vp', etc. declared? I hope you're not using SHORT > variables... the compiler has _always_ done crappy code for those. Sorry, I forgot. int x,y UWORD vp->sx,sy FLOAT zbuf[] MAXZ is #define Loop simply clears z-buffer (floating point :-) I am not sure but I think internal loop could have just 2 instructions (stfsu and bdnz). I wonder that my engine is quite fast despite such crap code - 604e rulez :-) -- // Artur Muszynski (AMST/UNION) A4000/040/EGS \// e-mail: amst@union.org.pl From amigappc-dev-owner@amiga.com.pl Fri Jul 10 11:55:07 1998 Received: from mail.onlineloop.com (root@maerz.vbs.at [194.152.167.73]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id LAA12241 for ; Fri, 10 Jul 1998 11:51:47 +0200 (CEST) Received: from onlineloop.com (artline.onlineloop.com [194.152.178.66]) by mail.onlineloop.com (8.8.5/8.7.3) with SMTP id LAA25356 for ; Fri, 10 Jul 1998 11:48:23 +0200 From: Guenter Erhart To: "AmigaPPC developers' mailing list" Date: Fri, 10 Jul 1998 11:45:33 +0100 Message-ID: In-Reply-To: Subject: Re: optimizations in sas/c MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hi !!!!! > Does scppc optimize anything? Such simple loop as follows compiles to v= ery > awful code (for me at least). I turned on all optimizations in scopts. Compiling WolfPac optimization works and makes the program noticeable fas= ter but it is nevertheless by far not as fast as the WarpOS version compiled with StormC (it is more then 30% faster based on the same code). I don=B4= t know so, whether this is because of the compiler or the PPC kernel (or ma= ybe both). I assume scppc uses the same global optimizations as sc but probab= ly does not a very good job on the cpu specific peephole stuff. G=FCnter -- = G=FCnter Erhart, M=E4rzstr. 52/5, A-1150 Vienna, Austria www: http://www.onlineloop.com e-mail: erhart@onlineloop.com Phone: ++43 1 9825314 ******************** *************** ********* ****** *** * From amigappc-dev-owner@amiga.com.pl Fri Jul 10 12:55:16 1998 Received: from EURE.de (geul.eure.de [194.180.228.1]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id MAA12362 for ; Fri, 10 Jul 1998 12:37:53 +0200 (CEST) Received: from eure.de 194.180.228.105 by EURE.de; Fri, 10 Jul 1998 12:34:37 From: Andreas Kuessner To: amigappc-dev@amiga.com.pl Date: Fri, 10 Jul 1998 12:28:53 +0100 Message-ID: Subject: WF PPC Update Error MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hello! Important message for the PPC users the have Wildfire installed and want = to use the second Update. The wf_image2.elf file is buggy so the preview and the storyboard do no= t work. Just replace this file after updating with the file from the cd. copy Wildfire5:English/ppc/system/wf_image2.elf to wf:system/ppc/wf_image= 2.elf Bye, Andreas. =2EoO---------------------------------------------------------------Oo. Andreas K=FCssner (Eksec/Infect!) E-Mail: eksec@eure.de homepage: http://www.oberland.com/amiga/wildfire/ Wildfire Project Manager, Infect! Amiga Entertainment Organizer =2EoO---------------------------------------------------------------Oo. From amigappc-dev-owner@amiga.com.pl Sat Jul 11 02:15:06 1998 Received: from promix.shiny.it (promix.shiny.it [194.20.245.130]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id CAA14565 for ; Sat, 11 Jul 1998 02:00:13 +0200 (CEST) Received: from iol-mail (asy2.recco.shiny.it [194.20.245.11] (may be forged)) by promix.shiny.it (8.8.7/8.8.7) with SMTP id BAA28113 for ; Sat, 11 Jul 1998 01:56:59 +0200 Received: by iol-mail.iol.it (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sat, 11 Jul 98 01:54:01 From: ggreco@iol.it (Gabriele Greco) Message-ID: <85587B77@iol.it> Subject: Re: optimizations in sas/c Date: 11 Jul 98 01:48:04 CET In-Reply-To: <19980709.836A640.1229E@raleigh7-014.dyn.interpath.net> To: amigappc-dev@amiga.com.pl Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hello Jim, In a message dated 09 Jul 98 you wrote to All : >> ___ClearZbuffer__11 JC> How are 'x', 'y', 'vp', etc. declared? I hope you're not using SHORT JC> variables... the compiler has _always_ done crappy code for those. Are these so slow? I use a lot of SHORT (WORD in amiga terms) variables on my soccer game, do you think that making them long will make me gain some speed? Ciao, Gabry (gabry@promix.it) From amigappc-dev-owner@amiga.com.pl Sat Jul 11 03:35:11 1998 Received: from raleigh7-008.dyn.interpath.net (raleigh7-008.dyn.interpath.net [207.59.134.8]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id DAA16584 for ; Sat, 11 Jul 1998 03:25:15 +0200 (CEST) Received: by raleigh7-008.dyn.interpath.net (Interworks_SMTPpost 8.102 February 12, 1997) id AA01; Fri, 10 Jul 1998 21:19:27 Received: by raleigh7-008.dyn.interpath.net (Interworks_SMTPpost 8.102 February 12, 1997) id AA01; Fri, 10 Jul 1998 21:19:14 From: Jim Cooper MIME-Version: 1.0 In-Reply-To: <85587B77@iol.it> Subject: Re: optimizations in sas/c Date: Fri, 10 Jul 1998 21:19:14 (+0500) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit To: amigappc-dev@amiga.com.pl Message-ID: <19980710.82D5730.12EA3@raleigh7-008.dyn.interpath.net> Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: In "Re: optimizations in sas/c", ggreco@iol.it (Gabriele Greco) wrote: > Hello Jim, > In a message dated 09 Jul 98 you wrote to All : > > >> ___ClearZbuffer__11 > JC> How are 'x', 'y', 'vp', etc. declared? I hope you're not using SHORT > JC> variables... the compiler has _always_ done crappy code for those. > > Are these so slow? I use a lot of SHORT (WORD in amiga terms) variables on my > soccer game, do you think that making them long will make me gain some speed? Almost all the time spent on making the compiler do optimizations was spent on 32 bit code. Hardly any time at all was spent on 16 bit code. The "natural" size of the 68K registers/memory/etc. is 32 bits, after all... So yes, you will almost certainly see an improvement by switching to long variables. Whether you will get a LOT of speedup depends on the algorithms you use, etc. From amigappc-dev-owner@amiga.com.pl Mon Jul 13 14:37:52 1998 Received: from nottingham.ac.uk (pat.ccc.nottingham.ac.uk [128.243.40.194]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id OAA28573 for ; Mon, 13 Jul 1998 14:33:12 +0200 (CEST) Received: from granby.ccc.nottingham.ac.uk ([128.243.40.43] helo=unix.ccc.nottingham.ac.uk) by nottingham.ac.uk with esmtp (Exim 1.92 #1) for amigappc-dev@amiga.com.pl id 0yvhjx-0002Aq-00; Mon, 13 Jul 1998 13:29:57 +0100 Received: from [128.243.121.236] (helo=PPCJMZ.chemistry) by unix.ccc.nottingham.ac.uk with smtp (Exim 1.92 #1) for amigappc-dev@amiga.com.pl id 0yvhjw-00019o-00; Mon, 13 Jul 1998 13:29:56 +0100 Message-Id: <3.0.1.32.19980713133157.00c29fc4@unix.ccc.nottingham.ac.uk> Date: Mon, 13 Jul 1998 13:31:57 +0100 To: "AmigaPPC developers' mailing list" From: Mark Howson Subject: Optimising PPC code... In-Reply-To: References: <358BA615.MD-0.198.jmarcet@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hi Right, I've just compiled a fairly major chunk of 68k code for PPC, and after a lot of debugging, etc, it seems to work well. However, I've made efforts to remove all the processor-switches (mainly from the C library), but I'd still like more speed... Problem is, my main loop is more or less like this: 1. plot character (usually one char, and note it's ASCII, not gfx) 2. decide where to move (fairly processor intensive) 3. check for keypress Step 2 flies on the PPC, but obviously steps 1 and 3 aren't so good. BTW, I'm doing several hundred thousand (at least) iterations of this loop, and the more speed the better. I can replace step 3 with a check for the firebutton, which is hacky but much quicker, but I don't know what to do about step 1. It's effectively a Text() call, with the odd SetAPen() thrown in, but the switch to 68k kills performance. So, does anyone know if there is a way of improving this? I know I'm always going to get a penalty from processor-switching, but I wonder if synchronous processing might help? On my AGA system I can of course write directly to memory, but I can't do this on gfx boards :( Could I have a 68k task that watches the PPC one and does the screen update on 68k, or is that likely to be slower than a switch? Has anyone done similar things in the past? If I wanted to be *really* poisonous...is there some equivalent of Forbid() for the PPC system? I have no idea how the multi-tasking system works with ppc.library (if anyone does, please let me know :) , but I guess the 68k side is busy doing things while my PPC program runs away? So can I shut (temporarily) the 68k side down until I need it? Would this help?? If I'm speaking nonsense, forgive me ;) I'm using ADE PPC with ppc.library 46.15, etc. Mark From amigappc-dev-owner@amiga.com.pl Mon Jul 13 18:35:09 1998 Received: from pasanda.cygnus.co.uk (dns.cygnus.co.uk [194.130.39.3]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id SAA00254 for ; Mon, 13 Jul 1998 18:20:08 +0200 (CEST) Received: (qmail 26901 invoked by alias); 13 Jul 1998 16:16:58 -0000 Received: (qmail 26897 invoked from network); 13 Jul 1998 16:16:58 -0000 Received: from lassi.cygnus.co.uk (jskov@194.130.39.9) by dns.cygnus.co.uk with SMTP; 13 Jul 1998 16:16:58 -0000 Received: by lassi.cygnus.co.uk (UUNET PIPEX simple 1.30) id RAA22764; Mon, 13 Jul 1998 17:16:57 +0100 To: "AmigaPPC developers' mailing list" Subject: Re: Optimising PPC code... References: <358BA615.MD-0.198.jmarcet@pobox.com> <3.0.1.32.19980713133157.00c29fc4@unix.ccc.nottingham.ac.uk> From: Jesper Skov Date: 13 Jul 1998 17:16:57 +0100 In-Reply-To: Mark Howson's message of Mon, 13 Jul 1998 13:31:57 +0100 Message-ID: Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Mark Howson writes: > Problem is, my main loop is more or less like this: > > 1. plot character (usually one char, and note it's ASCII, not gfx) > 2. decide where to move (fairly processor intensive) > 3. check for keypress If you can process more than one character at a time (i.e., no user interaction is required for each individual characters) why not write to a character buffer and update it periodically using the m68k? JEsper From amigappc-dev-owner@amiga.com.pl Tue Jul 14 20:15:13 1998 Received: from ikp.ikp.pl (ikp.ikp.pl [157.25.5.3]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id UAA06497 for ; Tue, 14 Jul 1998 20:08:44 +0200 (CEST) Received: from union.org.pl (ppp2-cst47.warszawa.tpnet.pl [195.116.250.47]) by ikp.ikp.pl (8.8.6/8.8.6) with SMTP id UAA25177 for ; Tue, 14 Jul 1998 20:21:07 +0200 (CEST) From: Artur Muszynski To: "AmigaPPC developers' mailing list" Date: Tue, 14 Jul 1998 19:35:58 +0100 Message-ID: Subject: TBR MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hello, What clock is used for TBR timer? I have CS604e/233MHz. -- // Artur Muszynski (AMST/UNION) A4000/040/EGS \// e-mail: amst@union.org.pl From amigappc-dev-owner@amiga.com.pl Wed Jul 15 07:15:00 1998 Received: from pmc.ru (pmcserv.pmc.ru [195.19.14.3]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id HAA10468 for ; Wed, 15 Jul 1998 07:05:38 +0200 (CEST) Received: from cch.pmc.ru (ave@[195.208.204.190]) by pmc.ru (8.8.7/8.8.7) with SMTP id JAA18652 for ; Wed, 15 Jul 1998 09:01:47 +0400 (MSD) (envelope-from ave@cch.pmc.ru) From: Alexey Emelyanov To: "AmigaPPC developers' mailing list" Date: Wed, 15 Jul 1998 09:03:02 +0300 Message-ID: In-Reply-To: Subject: Re: TBR MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: On 14-Jul-98, Artur Muszynski wrote: >Hello, >What clock is used for TBR timer? I have CS604e/233MHz. What is the TBR timer ? I have Cs604e/200 >-- > // Artur Muszynski (AMST/UNION) A4000/040/EGS > \// e-mail: amst@union.org.pl >-- WFMH AmigaPPC-Dev ------------------------------------------------------- > http://amiga.com.pl/lists/ -- With best regards, Amiganet: 39:241/1.0 E-mail: ave@cch.pmc.ru Alexey Emelyanov. Internet: iris.cch.pmc.ru __ Amiga A4000/040 /\ /// *************************** -------------------- \/ __/// *** Member Team Amiga *** SGI Indy/R5000 \XX/ *************************** From amigappc-dev-owner@amiga.com.pl Wed Jul 15 12:15:07 1998 Received: from pasanda.cygnus.co.uk (dns.cygnus.co.uk [194.130.39.3]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id MAA11315 for ; Wed, 15 Jul 1998 12:11:00 +0200 (CEST) Received: (qmail 28067 invoked by alias); 15 Jul 1998 10:07:40 -0000 Received: (qmail 28061 invoked from network); 15 Jul 1998 10:07:39 -0000 Received: from lassi.cygnus.co.uk (jskov@194.130.39.9) by dns.cygnus.co.uk with SMTP; 15 Jul 1998 10:07:39 -0000 Received: by lassi.cygnus.co.uk (UUNET PIPEX simple 1.30) id LAA04665; Wed, 15 Jul 1998 11:07:38 +0100 To: "AmigaPPC developers' mailing list" Subject: Re: TBR References: From: Jesper Skov Date: 15 Jul 1998 11:07:38 +0100 In-Reply-To: Artur Muszynski's message of Tue, 14 Jul 1998 19:35:58 +0100 Message-ID: Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Artur Muszynski writes: > > Hello, > > What clock is used for TBR timer? I have CS604e/233MHz. Reading the CPU manual you will find that the clock used for the TBR is 1/4 of the bus clock. That is 66/4MHz in your case I believe. Jesper From amigappc-dev-owner@amiga.com.pl Wed Jul 15 13:14:57 1998 Received: from matej.cerge.cuni.cz (matej.cerge.cuni.cz [195.113.12.40]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id MAA11466 for ; Wed, 15 Jul 1998 12:57:34 +0200 (CEST) Received: from email.cerge.cuni.cz (hpserver.cerge.cuni.cz) by matej.cerge.cuni.cz (5.67a8/Ultrix4.2a) id AA22104; Wed, 15 Jul 1998 12:52:57 +0200 Received: by email.cerge.cuni.cz with NT SMTP Gateway ver 31 id <35AC8A00@email.cerge.cuni.cz>; Wed, 15 Jul 98 12:52:48 C From: Cizek Pavel To: "amigappc-dev@amiga.com.pl" Subject: Re: Optimising PPC code... Date: Wed, 15 Jul 98 13:50:00 C Message-Id: <35AC8A00@email.cerge.cuni.cz> Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Mark Howson wrote: > Problem is, my main loop is more or less like this: > > 1. plot character (usually one char, and note it's ASCII, not gfx) > 2. decide where to move (fairly processor intensive) > 3. check for keypress > Step1. It's effectively a Text() call, with the odd SetAPen() thrown in, > but the switch to 68k kills performance. If you really need to do it char-by-char and very frequently, then check whether your system calls Text() a SetAPen() do not flush the whole caches of PPC and M68k (except for the string or char you are printing) as is the standard case for machine generated include proto-files - the complete flush of data and instruction cache can be as harmful as processor switching. Also, you can pool these two switches into one by calling short M68k code for the two functions. Finally, you can try calling M68k asynchronously if step 2 takes comparable amount of time to step 1 (but this probably will not be supported in the future releases of ppc software???). Pavel Cizek From amigappc-dev-owner@amiga.com.pl Thu Jul 16 00:35:45 1998 Received: from ikp.ikp.pl (ikp.ikp.pl [157.25.5.3]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id AAA13764 for ; Thu, 16 Jul 1998 00:14:48 +0200 (CEST) Received: from union.org.pl (ppp4-216.warszawa.tpnet.pl [195.205.246.216]) by ikp.ikp.pl (8.8.6/8.8.6) with SMTP id AAA10588 for ; Thu, 16 Jul 1998 00:27:14 +0200 (CEST) From: Artur Muszynski To: "AmigaPPC developers' mailing list" Date: Thu, 16 Jul 1998 00:09:20 +0100 Message-ID: Subject: How to write fast? MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hello! I tried the following loop to clear my buffer. I measured this with TBR and found that it's twice slower to max bus speed (about 75MB/s). Is there a way to make it faster? BTW: Completely non optimized C loop (I have shown it on this list about week ago) does it with the same speed. li r5,32 .loop: dcbtst r3,r5 stw r6,0(r3) stw r6,4(r3) stw r6,8(r3) stw r6,12(r3) stw r6,16(r3) stw r6,20(r3) stw r6,24(r3) stw r6,28(r3) add r3,r3,r5 bdnz .loop -- // Artur Muszynski (AMST/UNION) A4000/040/EGS \// e-mail: amst@union.org.pl From amigappc-dev-owner@amiga.com.pl Thu Jul 16 11:35:10 1998 Received: from mail1.isdnet.net (root@mail1.hol.fr [194.149.160.35]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id LAA17380 for ; Thu, 16 Jul 1998 11:17:10 +0200 (CEST) Received: from hol.fr (ppp53.hol.fr [195.154.2.154]) by mail1.isdnet.net (8.8.5/8.8.5) with SMTP id LAA27380 for ; Thu, 16 Jul 1998 11:13:18 +0200 (CEST) From: Brice Allenbrand To: amigappc-dev@amiga.com.pl Date: Thu, 16 Jul 1998 11:01:28 +0200 Message-ID: Subject: SAS =?iso-8859-1?Q?=DF22?= MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hello, I've some problems using Taglist functions. (OpenScreenTags...) My program crashes!! In the DoomPPC source it seems to be no problem using them. Did you ever had a similar problem? BTW, should I use malloc or AllocVec? I heard the PPC needs to have its m= emory allocated with PPCAlloc. Should I use the ANSI memory function so that SA= S can replace it with the adapted one? = I use SAS/C =DF22 CU -- = Brice Allenbrand. <--------------------------------------> Ringard' Production Web : www.mygale.org/~allenbra Internet : brice.allenbrand@hol.fr IRCnet : Brice (#Artbas) Fidonet : 2:325/3.15 = Amiga OnLine Magazine (AOLM) = www.adac-com.com/amiga <-------------------------------------->= From amigappc-dev-owner@amiga.com.pl Thu Jul 16 13:15:21 1998 Received: from server.fiber.net.pl (server.fiber.net.pl [195.117.208.101]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id MAA17648 for ; Thu, 16 Jul 1998 12:55:44 +0200 (CEST) Received: from nevald.k-net.dk (nevald.k-net.dtu.dk [130.225.71.226]) by server.fiber.net.pl (Netscape Messaging Server 3.52) with SMTP id AAA3F7C for ; Thu, 16 Jul 1998 12:54:48 +0200 Received: (qmail 11981 invoked from network); 16 Jul 1998 10:51:08 -0000 Received: from carlsberg.kampsax.dtu.dk (qmailr@192.38.212.2) by nevald.k-net.dtu.dk with SMTP; 16 Jul 1998 10:51:08 -0000 Received: (qmail 11486 invoked from network); 16 Jul 1998 10:51:07 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by carlsberg.kampsax.dtu.dk with SMTP; 16 Jul 1998 10:51:07 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by k4315.kampsax.dtu.dk with SMTP; 16 Jul 1998 10:51:02 -0000 Date: 16 Jul 98 12:50:56 +0200 From: "Rask Ingemann Lambertsen" Subject: libRILc v0.25 released (PowerUp + m68k) To: "Amiga PowerPC developer mailing list" Message-ID: <2299.501T2816T7706244@kampsax.k-net.dk> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hi. Version 0.25 of libRILc is now available for download: LibRILc is a standard C library for GCC, written with the purpose of providing PowerUp boards with a runtime environment which is good enough to port many existing m68k programs relatively easily. Thus, it also includes some commonly used functions from the Unix environment in additions to the ones defined by ANSI C. As of version 0.20, there is also an m68k version. The library requires OS 3.0 or better. In addition, the PowerUp version needs ppc.library v45.8 or better. Major changes since v0.20: -------------------------- Found a work around for pre v45.19 PPCCreateTask() that works with GCC 2.7.2.1 as well as EGCS release 1.0.2 (2.90.23). ppc.library v45.8 or later ought to be sufficient now. Fixed read()/write() alignment problems. Cache optimised fread()/fwrite(). Fixed the undefined reference to __strtod. Added feof(), ferror(), clearerr(), assert() and dtoa(). Added macros for getchar()/putchar() and functions for getc()/putc(). Updated the Makefile dependencies to include the header files. Reworked the errno/__ioerr system. Fixed clock() return value (wrong "sign"), vscanf(), sscanf(), ungetc(). Added libnix's isnan() until I figure out why it won't link in from the math lib. Added qsort() (libnix). Implemented access(). Changed malloc() and friends to use pooled memory allocation functions. Reorganised the structure of the library's files. Fixed stat()/fstat(). They were just about completely broken. Fixed open(..., O_TRUNC, ...). Fixed freopen(). Added resource tracking to opendir()/closedir(). Sped up memcpy()/bcopy() a lot. Fixed strerror() (wrong value passed to Fault()). Fixed the libRILc.a dependencies and a few other things. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | | "Compatible": Gracefully accepts erroneous data from any source. | From amigappc-dev-owner@amiga.com.pl Fri Jul 17 09:35:38 1998 Received: from mail.easynet.fr (mail.easynet.fr [195.114.64.207]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id JAA23018 for ; Fri, 17 Jul 1998 09:23:03 +0200 (CEST) Received: (qmail 21631 invoked from network); 17 Jul 1998 06:59:02 -0000 Received: from pop-bordeaux-13.pops.easynet.fr (HELO easynet.fr) (195.114.95.13) by mail.easynet.fr with SMTP; 17 Jul 1998 06:59:02 -0000 From: Robin de KAT To: PPC Date: Thu, 16 Jul 1998 19:40:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Most of my ppc applications don't work with the new ppc.library. I must launch ppctools before!??! (after that, applications work fine) The same problem appears with UAE 0.8.5 What's the matter? From amigappc-dev-owner@amiga.com.pl Fri Jul 17 11:35:24 1998 Received: from nottingham.ac.uk (pat.ccc.nottingham.ac.uk [128.243.40.194]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id LAA23261 for ; Fri, 17 Jul 1998 11:20:21 +0200 (CEST) Received: from granby.ccc.nottingham.ac.uk ([128.243.40.43] helo=unix.ccc.nottingham.ac.uk) by nottingham.ac.uk with esmtp (Exim 1.92 #1) for amigappc-dev@amiga.com.pl id 0yx6d6-0002UQ-00; Fri, 17 Jul 1998 10:16:40 +0100 Received: from [128.243.121.236] (helo=PPCJMZ.chemistry) by unix.ccc.nottingham.ac.uk with smtp (Exim 1.92 #1) for amigappc-dev@amiga.com.pl id 0yx6cy-00011Q-00; Fri, 17 Jul 1998 10:16:39 +0100 Message-Id: <3.0.1.32.19980717102004.00ccc444@unix.ccc.nottingham.ac.uk> Date: Fri, 17 Jul 1998 10:20:04 +0100 To: "AmigaPPC developers' mailing list" From: Mark Howson Subject: Re: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: At 07:40 PM 7/16/98 +0200, you wrote: >Most of my ppc applications don't work with the new ppc.library. >I must launch ppctools before!??! (after that, applications work fine) Have you put PPCInstall in the startup-sequence? Mark From amigappc-dev-owner@amiga.com.pl Fri Jul 17 12:55:11 1998 Received: from matej.cerge.cuni.cz (matej.cerge.cuni.cz [195.113.12.40]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id MAA23446 for ; Fri, 17 Jul 1998 12:38:40 +0200 (CEST) Received: from email.cerge.cuni.cz (hpserver.cerge.cuni.cz) by matej.cerge.cuni.cz (5.67a8/Ultrix4.2a) id AA00401; Fri, 17 Jul 1998 12:20:31 +0200 Received: by email.cerge.cuni.cz with NT SMTP Gateway ver 31 id <35AF2564@email.cerge.cuni.cz>; Fri, 17 Jul 98 12:20:20 C From: Cizek Pavel To: "amigappc-dev@amiga.com.pl" Subject: RE: Date: Fri, 17 Jul 98 13:21:00 C Message-Id: <35AF2564@email.cerge.cuni.cz> Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: > Most of my ppc applications don't work with the new ppc.library. > I must launch ppctools before!??! (after that, applications work fine) When have you tried it? I had the same problem (even worse) immediately after the installation of the new ppc.library into the flash ROM of BlizzardPPC. These problems disapeared after I TURNED OFF my computer for several night hours - from the next morning there have not been any. Pavel Cizek From amigappc-dev-owner@amiga.com.pl Fri Jul 17 18:35:10 1998 Received: from ikp.ikp.pl (ikp.ikp.pl [157.25.5.3]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id SAA24201 for ; Fri, 17 Jul 1998 18:22:53 +0200 (CEST) Received: from union.org.pl (ppp4-249.warszawa.tpnet.pl [195.205.246.249]) by ikp.ikp.pl (8.8.6/8.8.6) with SMTP id SAA15655 for ; Fri, 17 Jul 1998 18:35:25 +0200 (CEST) From: Artur Muszynski To: "AmigaPPC developers' mailing list" Date: Fri, 17 Jul 1998 18:17:46 +0100 Message-ID: Subject: inlines MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hello all, Sorry, it's little off-topic: Does __inline directive may work if inlined function is defined in one object ("vecmath.c" in my case) and caller function is defined in another one (eg. "engine.c")? I wrote some simple math routines and I want to use them everywhere in my program. It's stupid to call function if it's only vector addition and worse that it cannot optimize using loads and stores. I use SAS/C PPC 7.0 and it doesn't work in this way. -- // Artur Muszynski (AMST/UNION) A4000/040/EGS \// e-mail: amst@union.org.pl From amigappc-dev-owner@amiga.com.pl Fri Jul 17 22:55:31 1998 Received: from raleigh7-055.dyn.interpath.net (raleigh7-055.dyn.interpath.net [207.59.134.55]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id WAA24860 for ; Fri, 17 Jul 1998 22:48:47 +0200 (CEST) Received: by raleigh7-055.dyn.interpath.net (Interworks_SMTPpost 8.102 February 12, 1997) id AA01; Fri, 17 Jul 1998 16:41:30 Received: by raleigh7-055.dyn.interpath.net (Interworks_SMTPpost 8.102 February 12, 1997) id AA01; Fri, 17 Jul 1998 16:41:19 From: Jim Cooper MIME-Version: 1.0 In-Reply-To: Subject: Re: inlines Date: Fri, 17 Jul 1998 16:41:19 (+0500) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit To: amigappc-dev@AMIGA.COM.PL Message-ID: <19980717.8369240.EE7B@raleigh7-055.dyn.interpath.net> Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: In "inlines", Artur Muszynski wrote: > Hello all, > > Sorry, it's little off-topic: Does __inline directive may work if inlined > function is defined in one object ("vecmath.c" in my case) and caller > function is defined in another one (eg. "engine.c")? I wrote some simple > math routines and I want to use them everywhere in my program. It's stupid > to call function if it's only vector addition and worse that it cannot > optimize using loads and stores. I use SAS/C PPC 7.0 and it doesn't work in > this way. No, it can't work this way, since GO does the inlining, not the LINKER. Just put it in a common header file, if you're sure you'll always be using GO (OPTIMIZE OPTIMIZEGLOBAL). If you _don't_ use GO, nothing gets inlined anyway, so... From amigappc-dev-owner@amiga.com.pl Sat Jul 18 03:55:19 1998 Received: from mail-r2.shlink.de (mail-r2.shlink.de [194.64.6.19]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id DAA27710 for ; Sat, 18 Jul 1998 03:41:02 +0200 (CEST) Received: from mail-r1.shlink.de (194.64.6.3) by mail-r2.shlink.de with esmtp id m0yxLww-0000Y6C; Sat, 18 Jul 1998 03:38:10 +0200 (MEST) To: amigappc-dev@amiga.com.pl Message-ID: <1rlOOMD5131asz2@ark.news.wwbnet.de> From: ARK@News.wwbnet.de (Andreas R. Kleinert) Subject: =?ISO-8859-1?Q?Re=3A=20SAS=20=DF22?= Date: Thu, 16 Jul 1998 02:00:00 +0200 References: Received: by News.wwbnet.de ; Fri, 17 Jul 1998 09:06:55 +0100 Received: by apg.wwbnet.de ; Fri, 17 Jul 1998 19:16:32 +0100 Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: You wrote at 16.07.1998/13:01:28: > BTW, should I use malloc or AllocVec? I heard the PPC needs to have its memory > allocated with PPCAlloc. Should I use the ANSI memory function so that SAS can > replace it with the adapted one? You could as well use #ifdef __PPC__ #define MyAllocVec PPCAllocVec #else #define MyAllocVec AllocVec #endif -- Andreas_Kleinert@t-online.de | ARK@amigaworld.com | ARK@News.wwbnet.de Conservative ? Try FidoNet 2:2457/350.18 --- *SuperView* development PerSuaSiVe SoftWorX - Software Engineering Amiga/Wintel and more Visit http://wdo.de/ark/ for information, free downloads, registration WWW - Waiting World Wide -- MicroDot 1.17beta3 registered From amigappc-dev-owner@amiga.com.pl Sat Jul 18 16:55:13 1998 Received: from ikp.ikp.pl (ikp.ikp.pl [157.25.5.3]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id QAA29151 for ; Sat, 18 Jul 1998 16:43:38 +0200 (CEST) Received: from union.org.pl (ppp4-84.warszawa.tpnet.pl [195.205.246.84]) by ikp.ikp.pl (8.8.6/8.8.6) with SMTP id QAA00142 for ; Sat, 18 Jul 1998 16:56:13 +0200 (CEST) From: Artur Muszynski To: "AmigaPPC developers' mailing list" Date: Sat, 18 Jul 1998 00:34:52 +0100 Message-ID: In-Reply-To: <19980717.8369240.EE7B@raleigh7-055.dyn.interpath.net> Subject: Re[2]: inlines MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: On 17-Jul-98, Jim Cooper wrote: > > Sorry, it's little off-topic: Does __inline directive may work if inlined > > function is defined in one object ("vecmath.c" in my case) and caller > > function is defined in another one (eg. "engine.c")? I wrote some simple > > math routines and I want to use them everywhere in my program. It's stupid > > to call function if it's only vector addition and worse that it cannot > > optimize using loads and stores. I use SAS/C PPC 7.0 and it doesn't work in > > this way. > No, it can't work this way, since GO does the inlining, not the LINKER. Thanks. > Just put it in a common header file, if you're sure you'll always be using GO > (OPTIMIZE OPTIMIZEGLOBAL). > If you _don't_ use GO, nothing gets inlined anyway, so... I suppose to declare functions as static, otherwise linker could have problem with resolving the names. Well, anyway I don't think it's good programming technique :-) -- // Artur Muszynski (AMST/UNION) A4000/040/EGS \// e-mail: amst@union.org.pl From amigappc-dev-owner@amiga.com.pl Sun Jul 19 02:56:01 1998 Received: from promix.shiny.it (promix.shiny.it [194.20.245.130]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id CAA02577 for ; Sun, 19 Jul 1998 02:36:53 +0200 (CEST) Received: from iol-mail (asy14.recco.shiny.it [194.20.245.23] (may be forged)) by promix.shiny.it (8.8.7/8.8.7) with SMTP id CAA17289 for ; Sun, 19 Jul 1998 02:32:23 +0200 Received: by iol-mail.iol.it (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Sun, 19 Jul 98 02:29:01 From: ggreco@iol.it (Gabriele Greco) Message-ID: <5F107CBD@iol.it> Subject: inlines Date: 18 Jul 98 13:07:23 CET In-Reply-To: To: amigappc-dev@amiga.com.pl Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hello Artur, In a message dated 17 Jul 98 you wrote to All : AM> Hello all, AM> Sorry, it's little off-topic: Does __inline directive may work if AM> inlined function is defined in one object ("vecmath.c" in my case) and No, I suggest you to use a #define in that case, the result is the same of inline and it works as you want. Ciao, Gabry (gabry@promix.it) From amigappc-dev-owner@amiga.com.pl Mon Jul 20 01:55:27 1998 Received: from topaz.auran.com ([203.29.190.2]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id BAA05698 for ; Mon, 20 Jul 1998 01:48:18 +0200 (CEST) Received: from CWARD by topaz.auran.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1458.49) id 3S1VPQMG; Mon, 20 Jul 1998 09:51:51 +1000 Message-ID: <35B284E3.13711260@auran.com> Date: Mon, 20 Jul 1998 09:44:35 +1000 From: Colin Ward MIME-Version: 1.0 To: "AmigaPPC developers' mailing list" Subject: Re: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Robin de KAT wrote: > > Most of my ppc applications don't work with the new ppc.library. > I must launch ppctools before!??! (after that, applications work fine) > > The same problem appears with UAE 0.8.5 Did you also install the l8est version of 68060.library (v44 I think). You *must* install this in order for the new ppc.library to work. /--------------------------------------------------------------\ [Hitman/Code HQ - 6502/68000/604e coder - Long live the Amiga! ] [VZ-200/Vic-20/c64*6/+4/c128/c128D*2/Amiga CD32/500/2000/1200*2] [3000UX/A4000/CV64-3D/060-50/604e-200/66 Meg. 6581 rulez! ] [After three days without coding, life becomes meaningless. ] \--------------------------------------------------------------/ From amigappc-dev-owner@amiga.com.pl Mon Jul 20 22:15:44 1998 Received: from server.fiber.net.pl (server.fiber.net.pl [195.117.208.101]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id VAA10593 for ; Mon, 20 Jul 1998 21:56:17 +0200 (CEST) Received: from smtp.solutions.fi (tolppa.solutions.fi [194.89.17.8]) by server.fiber.net.pl (Netscape Messaging Server 3.52) with ESMTP id AAA4B32 for ; Mon, 20 Jul 1998 21:54:46 +0200 Received: from solutions.fi (iti@isr1at.dial.solutions.fi [194.197.177.20]) by smtp.solutions.fi with SMTP id WAA01312 for ; Mon, 20 Jul 1998 22:47:05 +0300 From: Ilkka Lehtoranta To: amigappc-dev@amiga.com.pl Date: Mon, 20 Jul 1998 22:48:04 +0200 Message-ID: Subject: playsid.library problem MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: After installing BPPC I noted that playsid.library can't play SIDs anymor= e :( After discussing about problem on powerup-mailinglist I decided to disassemble the library and finally found that damn "bug". PlaySID allocates succesfully ciab.resource. Ok, it is quite normal. But I noted that AddICRVector() is partially broken on my system. = Example: moveq #0,d0 lea interrupt,a1 jsr _LVOAddICRVector(a6) When succesful, that should return NULL. But I *never* get NULL. Instead: moveq #1,d0 lea interrupt,a1 jsr _LVOAddICRVector(a6) This works properly and returns NULL. Why? Before installing BPPC playsid.library was usable but now it seems to be useless because it can't allocate that damn interrupt. I haven't installed any new patches after installing BPPC. So there is some bugs left on ppc.library??? What I can do for that? -- = Ilkka Lehtoranta =B7 iti@solutions.fi =B7 http://webclub.solutions.fi/~it= i/ From amigappc-dev-owner@amiga.com.pl Wed Jul 22 08:35:46 1998 Received: from mail-r2.shlink.de (mail-r2.shlink.de [194.64.6.19]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id IAA19807 for ; Wed, 22 Jul 1998 08:22:51 +0200 (CEST) Received: from mail-r1.shlink.de (194.64.6.3) by mail-r2.shlink.de with esmtp id m0yysFH-0004hbC; Wed, 22 Jul 1998 08:19:23 +0200 (MEST) To: amigappc-dev@amiga.com.pl Message-ID: <1tHEiMD5131aUz1@ark.news.wwbnet.de> From: ARK@News.wwbnet.de (Andreas R. Kleinert) Subject: Re: playsid.library problem Date: Tue, 21 Jul 1998 02:00:00 +0200 References: Received: by News.wwbnet.de ; Tue, 21 Jul 1998 13:31:09 +0100 Received: by apg.wwbnet.de ; Tue, 21 Jul 1998 19:09:13 +0100 Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: You wrote at 20.07.1998/00:48:04: > left on ppc.library??? What I can do for that? Forward your report to Ralph... -- Andreas_Kleinert@t-online.de | ARK@amigaworld.com | ARK@News.wwbnet.de Conservative ? Try FidoNet 2:2457/350.18 --- *SuperView* development PerSuaSiVe SoftWorX - Software Engineering Amiga/Wintel and more Visit http://wdo.de/ark/ for information, free downloads, registration -- MicroDot 1.17beta3 registered From amigappc-dev-owner@amiga.com.pl Wed Jul 22 10:56:10 1998 Received: from nevald.k-net.dk (nevald.k-net.dtu.dk [130.225.71.226]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id KAA20133 for ; Wed, 22 Jul 1998 10:51:22 +0200 (CEST) Received: (qmail 32546 invoked from network); 22 Jul 1998 08:46:56 -0000 Received: from carlsberg.kampsax.dtu.dk (192.38.212.2) by nevald.k-net.dtu.dk with SMTP; 22 Jul 1998 08:46:56 -0000 Received: (qmail 27920 invoked from network); 22 Jul 1998 08:46:56 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by carlsberg.kampsax.dtu.dk with SMTP; 22 Jul 1998 08:46:56 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by k4315.kampsax.dtu.dk with SMTP; 22 Jul 1998 08:34:21 -0000 Date: 22 Jul 98 10:34:11 +0200 From: "Rask Ingemann Lambertsen" Subject: libRILc v0.26 released (PowerUp + m68k) To: ""amigappc-dev@amiga.com.pl, PowerUp@lists.best.com Message-ID: <1464.507T587T6343747@kampsax.k-net.dk> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hi. Version 0.26 of libRILc is now available for download: LibRILc is a standard C library for GCC, written with the purpose of providing PowerUp boards with a runtime environment which is good enough to port many existing m68k programs relatively easily. Thus, it also includes some commonly used functions from the Unix environment in additions to the ones defined by ANSI C. As of version 0.20, there is also an m68k version. The library requires OS 3.0 or better. In addition, the PowerUp version needs ppc.library v45.8 or better. This is a bug fix release. The last many changes for the v0.25 release went untested because I made a mistake that caused them to be installed into the wrong directory. Notably, the makefile failed to find all the object modules that should have gone into the library. This caused unresolved references. I apologise for not finding these problems before the v0.25 release. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | | LOAD "emacs",8,1 | From amigappc-dev-owner@amiga.com.pl Thu Jul 23 14:43:47 1998 Received: from mail-r2.shlink.de (mail-r2.shlink.de [194.64.6.19]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id OAA00398 for ; Thu, 23 Jul 1998 14:36:10 +0200 (CEST) Received: from mail-r1.shlink.de (194.64.6.3) by mail-r2.shlink.de with esmtp id m0yzKZM-0000YkC; Thu, 23 Jul 1998 14:34:00 +0200 (MEST) To: amigappc-dev@amiga.com.pl Message-ID: <1tuztMD5131aoz5@ark.news.wwbnet.de> From: ARK@News.wwbnet.de (Andreas R. Kleinert) Subject: Request for Testing Date: Thu, 23 Jul 1998 02:00:00 +0200 Received: by News.wwbnet.de ; Thu, 23 Jul 1998 08:07:59 +0100 Received: by apg.wwbnet.de ; Thu, 23 Jul 1998 09:49:38 +0100 Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: I'd like to ask everyone whose system matches the following description to do some small test for me: - Picasso96 - pic-dt V43 of Picasso96 - PPC [ the problem may be limited to PicassoIV owners, but I do need reports from other gfxcard or AGA owners for comparision ] -------------------- cut ---8<--- here ------------------------- Additional questions: - version of Picasso96 ? [ try >= v1.40 ] - version of pic-dt V43 of Picasso96 ? [ try >= v43.33 ] - version of ppc-lib [ try >= v46.19 ] - version of IPrefs ? and/or version of FastIPrefs ? [ try latest ] ====================================================== akDatatypes Checklist: akPNG akJFIF Works ok ? MV WBP DO DOBP | MV WBP DO DOBP ------------------------------------------------------ 68k/V40 mode 68k/V43 mode ------------------------------------------------------ PPC/V40 mode PPC/V43 mode ====================================================== -------------------- cut ---8<--- here ------------------------- Use the following letters: MV/DO: - Y: Works without problems - W: Wrong colors - D: Distorted display - C: Crash (system held requester, alert or guru) WBP/DOBP: - S: Use + Save work without problems - U: Use works, Save crashes - 1: Both only do work if datatype has been initialized before (e.g. by MultiView), thus we are not the 1st caller - otherwise crashes - W: Wrong colors - D: Distorted display - C: Crash (system held requester, alert or guru) MV: MultiView WBP: WBPattern ("Use" or "Save + Reboot") DO: DOpus Display DOB: DOpus background pattern ("Use" or "Save + Reboot") >> If you don't own DOpus, let the fields empty. << >> If you do own DOPus, feel free to test WBPattern << >> nevertheless, but only with the original Workbench. << Thanks for your help ! -- Andreas_Kleinert@t-online.de | ARK@amigaworld.com | ARK@News.wwbnet.de Conservative ? Try FidoNet 2:2457/350.18 --- *SuperView* development PerSuaSiVe SoftWorX - Software Engineering Amiga/Wintel and more Visit http://wdo.de/ark/ for information, free downloads, registration -- MicroDot 1.17beta3 registered From amigappc-dev-owner@amiga.com.pl Mon Jul 27 01:43:59 1998 Received: from rock101.genie.net (genie.com [199.164.140.11]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id BAA18579 for ; Mon, 27 Jul 1998 01:34:01 +0200 (CEST) From: k.barkley@genie.com Received: from rock103.genie.net (rock103.is.ge.com [204.90.131.103]) by rock101.genie.net (8.8.8/8.8.8) with ESMTP id XAA14655 for ; Sun, 26 Jul 1998 23:30:56 GMT Received: (from uucp@localhost) by rock103.genie.net (8.8.8/8.8.8) id XAA12792 for amigappc-dev@amiga.com.pl; Sun, 26 Jul 1998 23:30:54 GMT Message-Id: <199807262330.XAA12792@rock103.genie.net> Received: by (genie.)rock103.genie.net ( 2rem/1.44 ) ; Sun, 26 Jul 98 23:30:54 GMT ( from INTERNET# ; Sun, 26 Jul 98 23:30:52 GMT ) Date: Sun, 26 Jul 98 23:25:00 GMT To: amigappc-dev@amiga.com.pl Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Subject: CXERR in sasppc Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Hi: I have justed started getting CXERR 390296 during phase 2 of a compilation. If I chop out source code things are fine, but I can compile the chopped code without problems. Can anybody give me a clue as to what is happening. Sigh. This has me stumped. I suspect it may have to do with my stack, but i am not sure. I am running the latest PPC library on my 68040 CyberStorm PPC K.barkley@genie.com From amigappc-dev-owner@amiga.com.pl Mon Jul 27 03:44:04 1998 Received: from topaz.auran.com ([203.29.190.2]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id DAA20753 for ; Mon, 27 Jul 1998 03:29:47 +0200 (CEST) Received: from CWARD by topaz.auran.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1458.49) id 3S1VPWB7; Mon, 27 Jul 1998 11:34:31 +1000 Message-ID: <35BBD782.7BEE2614@auran.com> Date: Mon, 27 Jul 1998 11:27:30 +1000 From: Colin Ward MIME-Version: 1.0 To: "AmigaPPC developers' mailing list" Subject: Re: CXERR in sasppc References: <199807262330.XAA12792@rock103.genie.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: k.barkley@genie.com wrote: > > Hi: > I have justed started getting CXERR 390296 during phase 2 of > a compilation. If I chop out source code things are fine, but > I can compile the chopped code without problems. > > Can anybody give me a clue as to what is happening. > > Sigh. This has me stumped. > I suspect it may have to do with my stack, but i am not sure. I > am running the latest PPC library on my 68040 CyberStorm PPC Unfortunately, this has to do with the fact that the PPC version of SAS/C is only experimental, and that for some unknown and bizarre reason, the author suddenly dropped support for it. :-( My guess is that he got a new boss at SAS who didn't like what he was doing. You will either have to change the code slightly so that it doesn't blow up, or if you really can't do that, use GCC to compile that particular module. PPC GCC and SAS/C are compatible to call into one another and produce the same format object modules. The only thing is that you can't pass parameters by reference as they are stored differently. It is a real shame because SAS/C was shaping up to be the slickest compiler on the PPC. :-( /--------------------------------------------------------------\ [Hitman/Code HQ - 6502/68000/604e coder - Long live the Amiga! ] [VZ-200/Vic-20/c64*6/+4/c128/c128D*2/Amiga CD32/500/2000/1200*2] [3000UX/A4000/CV64-3D/060-50/604e-200/66 Meg. 6581 rulez! ] [After three days without coding, life becomes meaningless. ] \--------------------------------------------------------------/ From amigappc-dev-owner@amiga.com.pl Mon Jul 27 18:05:13 1998 Received: from nevald.k-net.dk (nevald.k-net.dtu.dk [130.225.71.226]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id RAA22797 for ; Mon, 27 Jul 1998 17:54:00 +0200 (CEST) Received: (qmail 30882 invoked from network); 27 Jul 1998 15:50:54 -0000 Received: from carlsberg.kampsax.dtu.dk (qmailr@192.38.212.2) by nevald.k-net.dtu.dk with SMTP; 27 Jul 1998 15:50:54 -0000 Received: (qmail 5461 invoked from network); 27 Jul 1998 15:50:53 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by carlsberg.kampsax.dtu.dk with SMTP; 27 Jul 1998 15:50:53 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by k4315.kampsax.dtu.dk with SMTP; 27 Jul 1998 15:50:08 -0000 Date: 27 Jul 98 17:49:37 +0200 From: "Rask Ingemann Lambertsen" Subject: Re: CXERR in sasppc To: "Amiga PowerPC developer mailing list" In-Reply-To: <35BBD782.7BEE2614@auran.com> Message-ID: <808.512T1870T10694454@kampsax.k-net.dk> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Den 27-Jul-98 03:27:30 skrev Colin Ward fĝlgende om "Re: CXERR in sasppc": [cut] > PPC GCC and SAS/C are compatible to call into one > another and produce the same format object modules. The only thing is > that you can't pass parameters by reference as they are stored > differently. Can you provide a short description of the differences? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | | If a train station is where a train stops, what is a workstation then? | From amigappc-dev-owner@amiga.com.pl Mon Jul 27 18:05:22 1998 Received: from nevald.k-net.dk (nevald.k-net.dtu.dk [130.225.71.226]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id RAA22787 for ; Mon, 27 Jul 1998 17:53:44 +0200 (CEST) Received: (qmail 30863 invoked from network); 27 Jul 1998 15:50:38 -0000 Received: from carlsberg.kampsax.dtu.dk (qmailr@192.38.212.2) by nevald.k-net.dtu.dk with SMTP; 27 Jul 1998 15:50:38 -0000 Received: (qmail 5422 invoked from network); 27 Jul 1998 15:50:37 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by carlsberg.kampsax.dtu.dk with SMTP; 27 Jul 1998 15:50:37 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by k4315.kampsax.dtu.dk with SMTP; 27 Jul 1998 15:50:00 -0000 Date: 27 Jul 98 16:09:02 +0200 From: "Rask Ingemann Lambertsen" Subject: Re: inlines To: "Amiga PowerPC developer mailing list" In-Reply-To: <5F107CBD@iol.it> Message-ID: <977.512T115T9693375@kampsax.k-net.dk> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Den 18-Jul-98 14:07:23 skrev Gabriele Greco fĝlgende om "inlines": > Hello Artur, > In a message dated 17 Jul 98 you wrote to All : AM>> Hello all, AM>> Sorry, it's little off-topic: Does __inline directive may work if AM>> inlined function is defined in one object ("vecmath.c" in my case) and > No, I suggest you to use a #define in that case, the result is the same of > inline and it works as you want. Not quite since arguments with side effects may be evaluated more than once if you use a #define. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | | To err is human, but to really mess things up you need a computer. | From amigappc-dev-owner@amiga.com.pl Mon Jul 27 18:05:24 1998 Received: from nevald.k-net.dk (nevald.k-net.dtu.dk [130.225.71.226]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id RAA22793 for ; Mon, 27 Jul 1998 17:53:54 +0200 (CEST) Received: (qmail 30874 invoked from network); 27 Jul 1998 15:50:49 -0000 Received: from carlsberg.kampsax.dtu.dk (qmailr@192.38.212.2) by nevald.k-net.dtu.dk with SMTP; 27 Jul 1998 15:50:49 -0000 Received: (qmail 5443 invoked from network); 27 Jul 1998 15:50:47 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by carlsberg.kampsax.dtu.dk with SMTP; 27 Jul 1998 15:50:47 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by k4315.kampsax.dtu.dk with SMTP; 27 Jul 1998 15:50:05 -0000 Date: 27 Jul 98 16:39:28 +0200 From: "Rask Ingemann Lambertsen" Subject: Re: New ppc.library ! To: "Amiga PowerPC developer mailing list" In-Reply-To: <3598276D.224BA783@auran.com> Message-ID: <1001.512T1448T9994804@kampsax.k-net.dk> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Den 30-Jun-98 01:46:53 skrev Colin Ward fĝlgende om "Re: New ppc.library !": > Keith Blakemore-Noble wrote: >> >> > It doesn't take 1/50 of a second to call a 68k OS function? >> >> Indeed this is true. >> OTOH, nor does ppc.library, so I am not quite sure what the relevance of >> that was though? > Unfortunately, ppc.library *does* take this long. [snip] No, it really doesn't. libRILc's printf() currently calls FPutC() for each character output, and it sure as h*ll does not take a whole second to print a 50 character line. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | | If you had an off switch, Doctor, would you not keep it secret? | From amigappc-dev-owner@amiga.com.pl Mon Jul 27 18:05:27 1998 Received: from nevald.k-net.dk (nevald.k-net.dtu.dk [130.225.71.226]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id RAA22790 for ; Mon, 27 Jul 1998 17:53:52 +0200 (CEST) Received: (qmail 30870 invoked from network); 27 Jul 1998 15:50:46 -0000 Received: from carlsberg.kampsax.dtu.dk (qmailr@192.38.212.2) by nevald.k-net.dtu.dk with SMTP; 27 Jul 1998 15:50:46 -0000 Received: (qmail 5438 invoked from network); 27 Jul 1998 15:50:45 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by carlsberg.kampsax.dtu.dk with SMTP; 27 Jul 1998 15:50:45 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by k4315.kampsax.dtu.dk with SMTP; 27 Jul 1998 15:50:04 -0000 Date: 27 Jul 98 16:30:10 +0200 From: "Rask Ingemann Lambertsen" Subject: Re: Problem linking with libRILc.a To: "Amiga PowerPC developer mailing list" In-Reply-To: <3590ABD2.MD-0.198.jmarcet@pobox.com> Message-ID: <1305.512T538T9903062@kampsax.k-net.dk> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Den 24-Jun-98 07:33:38 skrev Javier Marcet fĝlgende om "Problem linking with libRILc.a": > I've been trying to compile some ANSI C code for PPC and linking with > this library, when doing it I get no errors, but when I run the elf > object I always get this error: > ELF Object Resolve Error > Symbol Ğsetjmpğ > Reloc Type R_PPC_REL24 > not found > I don't know what the problem can be, because it seems the setjmp > function is included in the library. It's a RTFM case, but anyway: > By the way, I copied the includes, libRILc.a as libc.a, libgcc.a > and crt0.o to their respective places. And I link with these options: > ppc-amigaos-ld -r -lc /gg/ppc-amigaos/lib/crt0.o ^^^ That option goes at the _end_ of the command line (or at least _after_ the object modules that need it). Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | | Packet radio - a true Ether net | From amigappc-dev-owner@amiga.com.pl Mon Jul 27 18:05:30 1998 Received: from nevald.k-net.dk (nevald.k-net.dtu.dk [130.225.71.226]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id RAA22795 for ; Mon, 27 Jul 1998 17:53:58 +0200 (CEST) Received: (qmail 30867 invoked from network); 27 Jul 1998 15:50:43 -0000 Received: from carlsberg.kampsax.dtu.dk (qmailr@192.38.212.2) by nevald.k-net.dtu.dk with SMTP; 27 Jul 1998 15:50:43 -0000 Received: (qmail 5432 invoked from network); 27 Jul 1998 15:50:42 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by carlsberg.kampsax.dtu.dk with SMTP; 27 Jul 1998 15:50:42 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by k4315.kampsax.dtu.dk with SMTP; 27 Jul 1998 15:50:03 -0000 Date: 27 Jul 98 16:25:45 +0200 From: "Rask Ingemann Lambertsen" Subject: Re: Optimising PPC code... To: "Amiga PowerPC developer mailing list" In-Reply-To: <3.0.1.32.19980713133157.00c29fc4@unix.ccc.nottingham.ac.uk> Message-ID: <2367.512T2282T9854958@kampsax.k-net.dk> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Den 13-Jul-98 14:31:57 skrev Mark Howson fĝlgende om "Optimising PPC code...": > Problem is, my main loop is more or less like this: > 1. plot character (usually one char, and note it's ASCII, not gfx) > 2. decide where to move (fairly processor intensive) > 3. check for keypress > Step 2 flies on the PPC, but obviously steps 1 and 3 aren't so good. BTW, > I'm doing several hundred thousand (at least) iterations of this loop, and > the more speed the better. > I can replace step 3 with a check for the firebutton, which is hacky but > much quicker, Don't even think about it. Enough people have written buggy software already. > but I don't know what to do about step 1. It's effectively a > Text() call, with the odd SetAPen() thrown in, but the switch to 68k kills > performance. So, does anyone know if there is a way of improving this? I > know I'm always going to get a penalty from processor-switching, but I > wonder if synchronous processing might help? No, it is already synchronous, and that is the problem. Try creating an m68k task and send it a message (asynchronously, i.e. without waiting for a repply) when it should plot a character. > On my AGA system I can of > course write directly to memory, but I can't do this on gfx boards :( Don't even think about it. Enough people have written buggy software already. > If I wanted to be *really* poisonous...is there some equivalent of Forbid() > for the PPC system? The presence of Forbid() and Disable() in AmigaOS is a bug. Any need for one of the two is a major design flaw. > I have no idea how the multi-tasking system works with > ppc.library (if anyone does, please let me know :) , but I guess the 68k > side is busy doing things while my PPC program runs away? So can I shut > (temporarily) the 68k side down until I need it? Would this help?? If I'm > speaking nonsense, forgive me ;) I forgive you. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | | STICK \'stik\ n. 1: A boomerang that doesn't work. | From amigappc-dev-owner@amiga.com.pl Mon Jul 27 18:05:31 1998 Received: from nevald.k-net.dk (nevald.k-net.dtu.dk [130.225.71.226]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id RAA22794 for ; Mon, 27 Jul 1998 17:53:55 +0200 (CEST) Received: (qmail 30876 invoked from network); 27 Jul 1998 15:50:49 -0000 Received: from carlsberg.kampsax.dtu.dk (qmailr@192.38.212.2) by nevald.k-net.dtu.dk with SMTP; 27 Jul 1998 15:50:49 -0000 Received: (qmail 5449 invoked from network); 27 Jul 1998 15:50:48 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by carlsberg.kampsax.dtu.dk with SMTP; 27 Jul 1998 15:50:48 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by k4315.kampsax.dtu.dk with SMTP; 27 Jul 1998 15:50:06 -0000 Date: 27 Jul 98 17:37:35 +0200 From: "Rask Ingemann Lambertsen" Subject: Re: optimizations in sas/c To: "Amiga PowerPC developer mailing list" In-Reply-To: Message-ID: <3467.512T1751T10574731@kampsax.k-net.dk> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Den 10-Jul-98 01:20:24 skrev Artur Muszynski fĝlgende om "optimizations in sas/c": > Hello, > Does scppc optimize anything? Such simple loop as follows compiles to very > awful code (for me at least). I turned on all optimizations in scopts. > This is my loop: > ; 78: for(y=0; ysy; y++) > ; 79: for(x=0; xsx; x++) > ; 80: vp->zbuf[x+y*vp->sx] = MAXZ; A compilable source with that loop and the declarations from your other message in it: ---------- #include #define MAXZ -1.3e12 struct vpthing { UWORD sx,sy; FLOAT zbuf[3000]; }; void ClearZbuffer (struct vpthing *vp) { int x,y; for(y=0; ysy; y++) for(x=0; xsx; x++) vp->zbuf[x+y*vp->sx] = MAXZ; } ---------- > This is dissassembly of the most nested loop: > ___ClearZbuffer__11: > LHZ r11,r31,0 ; a17f0000 > ADDIS r8,r0,74 ; 3d000000 > ANDI. r11,r11,ffff ; 716bffff > MULLW r12,r30,r11 ; 7d9e59d6 > LFS fr1,r8,74 ; c0280074 > LWZ r6,r31,10 ; 80df0010 > ADD r4,r29,r12 ; 7c9d6214 > RLWINM r5,r4,2,0,1d ; 5485103a > ADD r7,r5,r6 ; 7ce53214 > STFS fr1,r7,0 ; d0270000 > ADDI r29,r29,1 ; 3bbd0001 > ___ClearZbuffer__12: > ORI r9,r26,0 ; 63490000 > ANDI. r9,r9,ffff ; 7129ffff > CMP cr0,r29,r9 ; 7c1d4800 > BC c,0,ffffffc8 ; 4180ffc8 > ___ClearZbuffer__11 With -O3 -mcpu=604 -mregnames, GCC (egcs-1.0.2 release) produces ---------- .section ".rodata" .align 2 .LC1: .float 0d-1.30000001433600000000e12 .section ".text" .align 2 .globl ClearZbuffer .type ClearZbuffer,@function ClearZbuffer: lhz %r0,2(%r3) li %r11,0 cmpw %cr1,%r11,%r0 bclr 4,4 addis %r9,0,.LC1@ha lfs %f0,.LC1@l(%r9) .L5: lhz %r9,0(%r3) li %r0,0 cmpw %cr1,%r0,%r9 bc 4,4,.L4 .L9: mullw %r9,%r9,%r11 ; r9 = vp->sx * y; add %r9,%r0,%r9 ; r9 = x + {vp->sx*y}; slwi %r9,%r9,2 add %r9,%r3,%r9 stfs %f0,4(%r9) lhz %r9,0(%r3) ; <--- argh! Should be moved out of loop. addic %r0,%r0,1 cmpw %cr1,%r0,%r9 bc 12,4,.L9 .L4: lhz %r0,2(%r3) ; <--- argh! Should be moved out of loop. addi %r11,%r11,1 cmpw %cr1,%r11,%r0 bc 12,4,.L5 blr ---------- The code is difficult to compare for me since SAS/C and GCC seem to produce very different code, but I think the SAS/C section you posted corresponds to the part between .L9 and .L4. While GCC's code isn't quite perfect either, it is not good that SAS/C keeps reloading the floating point constant, and it shows the "short int" problems that Jim Cooper mentioned. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | | Hard work may not kill me, but why take chances? | From amigappc-dev-owner@amiga.com.pl Tue Jul 28 01:24:31 1998 Received: from topaz.auran.com ([203.29.190.2]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id BAA24584 for ; Tue, 28 Jul 1998 01:21:26 +0200 (CEST) Received: from CWARD by topaz.auran.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1458.49) id 3S1VPW8L; Tue, 28 Jul 1998 09:26:09 +1000 Message-ID: <35BD0AEE.EB1147DC@auran.com> Date: Tue, 28 Jul 1998 09:19:10 +1000 From: Colin Ward MIME-Version: 1.0 To: "AmigaPPC developers' mailing list" Subject: Re: CXERR in sasppc References: <808.512T1870T10694454@kampsax.k-net.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Rask Ingemann Lambertsen wrote: > > > PPC GCC and SAS/C are compatible to call into one > > another and produce the same format object modules. The only thing is > > that you can't pass parameters by reference as they are stored > > differently. > > Can you provide a short description of the differences? I can't remember as it was a month or so ago, and I've got a shocking memory, but it's in the read.me for the last PPC SAS/C update that came out. If you don't use SAS/C then I can have a look at home and tell you... /--------------------------------------------------------------\ [Hitman/Code HQ - 6502/68000/604e coder - Long live the Amiga! ] [VZ-200/Vic-20/c64*6/+4/c128/c128D*2/Amiga CD32/500/2000/1200*2] [3000UX/A4000/CV64-3D/060-50/604e-200/66 Meg. 6581 rulez! ] [After three days without coding, life becomes meaningless. ] \--------------------------------------------------------------/ From amigappc-dev-owner@amiga.com.pl Tue Jul 28 01:24:35 1998 Received: from mailhub2.ncal.verio.com (mailhub2.ncal.verio.net [204.247.247.54]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id BAA24550 for ; Tue, 28 Jul 1998 01:09:25 +0200 (CEST) Received: from paix-alg-gw1-13.ncal.verio.com (fw@paix-alg-gw1-13.ncal.verio.com [207.21.130.204]) by mailhub2.ncal.verio.com (8.8.7/8.8.7) with SMTP id QAA18884 for ; Mon, 27 Jul 1998 16:06:05 -0700 (PDT) Date: Mon, 27 Jul 1998 16:06:12 -0700 (PDT) From: Fred Wright To: "AmigaPPC developers' mailing list" Subject: Re: Optimising PPC code... In-Reply-To: <2367.512T2282T9854958@kampsax.k-net.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: On 27 Jul 1998, Rask Ingemann Lambertsen wrote: > The presence of Forbid() and Disable() in AmigaOS is a bug. Any need for > one of the two is a major design flaw. Forbid() is needed for two reasons: 1) For short-duration exclusive operations (e.g. just a few instructions) it's more efficient to use the simplest possible exclusion mechanism. The fact that the scope of exclusion is large isn't terribly important in the "quick" case. 2) In order to implement a mechanism like semaphores, it's necessary to have some form of exclusion while manipulating the semaphores themselves (unless this can be done with an atomic operation, which is usually not the case). While this could be done by disabling interrupts, *that's* a form of unnecessary exclusion. Thus the semaphore mechanism itself needs some form of Forbid()/Permit() for its internal use. Some form of Disable()/Enable() is absolutely essential for code that interacts with interrupt code, such as hardware device drivers. Note that the 060 removed the one instruction that might have made this requirement avoidable. What I *do* regard as a bug is the automatic Permit() that happens as a result of a Wait(). A program which does a Forbid() to gain exclusive access to data structures and then turns around and calls a function which blocks *could be* specifically expecting that, but may also may be just plain confused. The latter case tends to lead to things that work "most of the time". Better to require that the Permit() be done explicitly where appropriate, and otherwise crash any program that does a Wait() during a Forbid() or Disable(). In a multi-processor system things get more complicated, and generally these sorts of things need to involve suitable memory-based interlocks, which is more difficult (but not impossible) without proper bus locking. Disable()/Enable() need to come in two flavors - the system-wide version and the single-CPU-version. The latter is adequate for device drivers running on the same CPU that has the hardware. The former is needed in connection with system-wide data that may also be accessed at interrupt level and hence can't use semaphores (possibly including cross-CPU device drivers). A CPU-specific Forbid() is pretty meaningless, except for something like the PowerUP where the PPC isn't a full participant in the OS. Fred Wright From amigappc-dev-owner@amiga.com.pl Tue Jul 28 01:44:23 1998 Received: from raleigh6-193.dyn.interpath.net (raleigh6-193.dyn.interpath.net [207.59.126.193]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id BAA24625 for ; Tue, 28 Jul 1998 01:28:02 +0200 (CEST) Received: by raleigh6-193.dyn.interpath.net (Interworks_SMTPpost 8.102 February 12, 1997) id AA01; Mon, 27 Jul 1998 19:20:48 Received: by raleigh6-193.dyn.interpath.net (Interworks_SMTPpost 8.102 February 12, 1997) id AA01; Mon, 27 Jul 1998 19:20:36 From: Jim Cooper MIME-Version: 1.0 In-Reply-To: <199807262330.XAA12792@rock103.genie.net> Subject: Re: CXERR in sasppc Date: Mon, 27 Jul 1998 19:20:36 (+0500) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit To: amigappc-dev@amiga.com.pl Message-ID: <19980727.8380020.11717@raleigh6-193.dyn.interpath.net> Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: In "CXERR in sasppc", k.barkley@genie.com wrote: > Hi: > I have justed started getting CXERR 390296 during phase 2 of > a compilation. If I chop out source code things are fine, but > I can compile the chopped code without problems. > > Can anybody give me a clue as to what is happening. > > Sigh. This has me stumped. > I suspect it may have to do with my stack, but i am not sure. I > am running the latest PPC library on my 68040 CyberStorm PPC I forwarded this to Steve Krueger (no, he is NOT still working on the compiler, but he'll answer questions about it if you ask nicely), and here's his response: > That CXERR comes out when processing the global inititialized data > section. I can't provide any more info than that without having the > source. > > sk So, if you want to send me source that triggers the problem, I'll see if Steve can get a moment to take a look at it... From amigappc-dev-owner@amiga.com.pl Tue Jul 28 04:24:06 1998 Received: from oak (joesera@oak.liii.com [198.207.193.1]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id EAA27125 for ; Tue, 28 Jul 1998 04:10:10 +0200 (CEST) Received: from localhost by oak with SMTP (8.8.6/8.8.5) id CAA19122; Tue, 28 Jul 1998 02:06:59 GMT Date: Mon, 27 Jul 1998 22:06:58 -0400 (EDT) From: Joe Sera To: "AmigaPPC developers' mailing list" Subject: Re: Optimising PPC code... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: On Mon, 27 Jul 1998, Fred Wright wrote: > What I *do* regard as a bug is the automatic Permit() that happens as a > result of a Wait(). A program which does a Forbid() to gain exclusive > access to data structures and then turns around and calls a function which > blocks *could be* specifically expecting that, but may also may be just > plain confused. The latter case tends to lead to things that work "most > of the time". Better to require that the Permit() be done explicitly > where appropriate, and otherwise crash any program that does a Wait() > during a Forbid() or Disable(). This is absolutly necessary since chances are that if you call something that causes a Wait(), it's doing I/O (such as accessing a resource or device) which requiers multi-tasking, since resources and devices are processes/tasks.. There are only 2 conditions a programmer needs to use Forbid()/Permit(): 1) access to system Task/Process lists. If you need to do I/O (such as in a task viewer, you should clone the necessary nodes and Permit() before doing I/O. 2) Removal of public structures such as message ports. The only time you should use Disable()/Enable() is when installing interupt handlers. This pair of functions can screw up critical system timing, so the code must be shot and quick. Any other use for either Forbid()/Permit() and Disable()/Enable() has been, is , and will always be considered bad programming style. > In a multi-processor system things get more complicated, and generally > these sorts of things need to involve suitable memory-based interlocks, > which is more difficult (but not impossible) without proper bus locking. > Disable()/Enable() need to come in two flavors - the system-wide version > and the single-CPU-version. The latter is adequate for device drivers > running on the same CPU that has the hardware. The former is needed in > connection with system-wide data that may also be accessed at interrupt > level and hence can't use semaphores (possibly including cross-CPU device > drivers). A CPU-specific Forbid() is pretty meaningless, except for > something like the PowerUP where the PPC isn't a full participant in the > OS. actually, a dedicated signaling and management system would work much better. On a multitasking and multiprocessing system, there is alot that goes on behind the scenes and the use ofexclusion functions would cause lots of problems since they would intereupt normal system functioning. we would be alot better off with memory protection/management schemes and completely do away with low-level lockout functions. Imagin runing a high-load program (such as high-speed serial communication) and then a utility goes and does an exclusion. The implications include loss and corruption of data, freezes, and software failure. Thius is _NOT_ a good thing. Joe From amigappc-dev-owner@amiga.com.pl Tue Jul 28 10:24:16 1998 Received: from server.fiber.net.pl (server.fiber.net.pl [195.117.208.101]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id KAA27792 for ; Tue, 28 Jul 1998 10:11:27 +0200 (CEST) Received: from nottingham.ac.uk (pat.ccc.nottingham.ac.uk [128.243.40.194]) by server.fiber.net.pl (Netscape Messaging Server 3.52) with ESMTP id AAAA78 for ; Tue, 28 Jul 1998 10:10:55 +0200 Received: from granby.ccc.nottingham.ac.uk ([128.243.40.43] helo=unix.ccc.nottingham.ac.uk) by nottingham.ac.uk with esmtp (Exim 1.92 #1) for amigappc-dev@amiga.com.pl id 0z14if-00038S-00; Tue, 28 Jul 1998 09:02:49 +0100 Received: from [128.243.121.236] (helo=PPCJMZ.chemistry) by unix.ccc.nottingham.ac.uk with smtp (Exim 1.92 #1) for amigappc-dev@amiga.com.pl id 0z14if-0007ir-00; Tue, 28 Jul 1998 09:02:49 +0100 Message-Id: <3.0.1.32.19980728091058.00de39d8@unix.ccc.nottingham.ac.uk> Date: Tue, 28 Jul 1998 09:10:58 +0100 To: "AmigaPPC developers' mailing list" From: Mark Howson Subject: Re: Optimising PPC code... In-Reply-To: <2367.512T2282T9854958@kampsax.k-net.dk> References: <3.0.1.32.19980713133157.00c29fc4@unix.ccc.nottingham.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: At 04:25 PM 7/27/98 +0200, you wrote: >> I can replace step 3 with a check for the firebutton, which is hacky but >> much quicker, > > Don't even think about it. Enough people have written buggy software >already. Hey, it works :) It used to (and still can) use the usual GetMsg()/RAWKEY stuff, but that is *slow*. If I keep this in I slow the PPC version down to 040/40 level or so, which seems to make the whole thing pointless :( Presumably putting this in a 68k call would help too...yep, I guess it would :) BTW, I have a normal 'PPC' version that uses all the proper methods (which works fine), but there are certain cases where it makes sense to get all the speed possible, which is why I'm doing all this evil stuff. > No, it is already synchronous, and that is the problem. Try creating an >m68k task and send it a message (asynchronously, i.e. without waiting for a >repply) when it should plot a character. Yep, I meant async before, sorry. I'm now doing what you recommend - thanks to everyone who suggested it. >> On my AGA system I can of >> course write directly to memory, but I can't do this on gfx boards :( > > Don't even think about it. Enough people have written buggy software >already. But it's so much *faster* that way ;) I stress this is an option, and by default it's turned off. >> If I wanted to be *really* poisonous...is there some equivalent of Forbid() >> for the PPC system? > > The presence of Forbid() and Disable() in AmigaOS is a bug. Any need for >one of the two is a major design flaw. Well, IMHO it's a design flaw in AmigaOS (rather than a program that uses them). Maybe that's what you mean :) >> I have no idea how the multi-tasking system works with >> ppc.library (if anyone does, please let me know :) , but I guess the 68k >> side is busy doing things while my PPC program runs away? So can I shut >> (temporarily) the 68k side down until I need it? Would this help?? If I'm >> speaking nonsense, forgive me ;) > > I forgive you. I'm still learning. Thanks to everyone who replied :) Mark From amigappc-dev-owner@amiga.com.pl Tue Jul 28 11:04:11 1998 Received: from ikp.ikp.pl (ikp.ikp.pl [157.25.5.3]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id KAA27896 for ; Tue, 28 Jul 1998 10:46:40 +0200 (CEST) Received: from union.org.pl (ppp-cst32.warszawa.tpnet.pl [194.204.131.32]) by ikp.ikp.pl (8.8.6/8.8.6) with SMTP id LAA08995 for ; Tue, 28 Jul 1998 11:01:48 +0200 (CEST) From: Artur Muszynski To: "AmigaPPC developers' mailing list" Date: Tue, 28 Jul 1998 10:23:22 +0100 Message-ID: In-Reply-To: <3467.512T1751T10574731@kampsax.k-net.dk> Subject: Re[2]: optimizations in sas/c MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: On 27-Jul-98, Rask Ingemann Lambertsen wrote: > void ClearZbuffer (struct vpthing *vp) > { > int x,y; > > for(y=0; ysy; y++) > for(x=0; xsx; x++) > vp->zbuf[x+y*vp->sx] = MAXZ; > } > > > This is dissassembly of the most nested loop: [...] I have played a little with this and found that I must 'help' compiler to produce good code by creating some temporary variables and using pointers. Anyway as I wrote, speed this loop is limited by bus not cpu speed (under 3ms to clear 320x200x32 z-buffer, so it gives 75MB/s). Regards, -- // Artur Muszynski (AMST/UNION) A4000/040/EGS \// e-mail: amst@union.org.pl From amigappc-dev-owner@amiga.com.pl Tue Jul 28 17:04:23 1998 Received: from server.fiber.net.pl (server.fiber.net.pl [195.117.208.101]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id QAA29152 for ; Tue, 28 Jul 1998 16:52:34 +0200 (CEST) Received: from vesuri.Helsinki.FI ([128.214.205.10]) by server.fiber.net.pl (Netscape Messaging Server 3.52) with ESMTP id AAA14A8 for ; Tue, 28 Jul 1998 16:52:01 +0200 Received: from localhost (jxsaarin@localhost) by vesuri.Helsinki.FI (8.8.8/8.8.0) with SMTP id RAA13430 for ; Tue, 28 Jul 1998 17:43:30 +0300 (EET DST) Date: Tue, 28 Jul 1998 17:43:29 +0300 (EET DST) From: Jyrki O Saarinen To: "AmigaPPC developers' mailing list" Subject: Re: Re[2]: optimizations in sas/c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: > On 27-Jul-98, Rask Ingemann Lambertsen wrote: > > void ClearZbuffer (struct vpthing *vp) > > { > > int x,y; > > > > for(y=0; ysy; y++) > > for(x=0; xsx; x++) > > vp->zbuf[x+y*vp->sx] = MAXZ; > > } > > > > > This is dissassembly of the most nested loop: > > [...] > > I have played a little with this and found that I must 'help' compiler to > produce good code by creating some temporary variables and using pointers. > Anyway as I wrote, speed this loop is limited by bus not cpu speed (under > 3ms to clear 320x200x32 z-buffer, so it gives 75MB/s). The problem is likely that you used shorts and you dig all counters etc. from a struct. Another thing is, zbuffering is not a good alternative IMHO in software rendering. It depends though what you are doing, but there are faster alternatives if you are doing a game perhaps. From amigappc-dev-owner@amiga.com.pl Tue Jul 28 21:24:15 1998 Received: from rostock.netsurf.de (root@rostock.netsurf.de [194.64.189.20]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id VAA00117 for ; Tue, 28 Jul 1998 21:20:15 +0200 (CEST) From: Frank Pagels To: "AmigaPPC developers' mailing list" Date: Tue, 28 Jul 1998 21:00:53 +0100 Message-ID: In-Reply-To: <1305.512T538T9903062@kampsax.k-net.dk> Subject: Re: Problem linking with libRILc.a MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: Am 27-Jul-98 schrieb Rask Ingemann Lambertsen: >> I've been trying to compile some ANSI C code for PPC and linking with >> this library, when doing it I get no errors, but when I run the elf >> object I always get this error: > = >> ELF Object Resolve Error > = >> Symbol =ABsetjmp=BB >> Reloc Type R_PPC_REL24 >> not found > = >> I don't know what the problem can be, because it seems the setjmp >> function is included in the library. > = > It's a RTFM case, but anyway: > = >> By the way, I copied the includes, libRILc.a as libc.a, libgcc.a >> and crt0.o to their respective places. And I link with these options: > = >> ppc-amigaos-ld -r -lc /gg/ppc-amigaos/lib/crt0.o > ^^^ > = > That option goes at the _end_ of the command line (or at least _after= _ the > object modules that need it). Hmm, i'm new on this list and i got a similary problem: ELF Object Resolve Error Symbol =ABp96PIP_GetTags=BB Reloc Type 0x0000000A not found I had compiled with SAS. Interesting is that i got only resolv errors for= function of self created pragma files. E.g. Picasso96 and Render.library.= ppc-amigaos-ld -r -o Ripley.elf LIB:c_ppc.o $(OBJS) LIB:scppc.a lib:end.o= Any hints ? thanks Frank -- = Frank (Copper) Pagels / Defect Softworks E-Mail: fp0001@rostock.netsurf.de Copper@Hysteria.dssd.sub.org IRC: Copper@#amigager and #rostock WWW: http://copper.home.pages.de/ <-- ArtPRO support = From amigappc-dev-owner@amiga.com.pl Wed Jul 29 03:44:07 1998 Received: from mail-r2.shlink.de (mail-r2.shlink.de [194.64.6.19]) by amiga.com.pl (8.8.8/8.7.3) with SMTP id DAA03183 for ; Wed, 29 Jul 1998 03:37:52 +0200 (CEST) Received: from mail-r1.shlink.de (194.64.6.3) by mail-r2.shlink.de with esmtp id m0z1L9I-0000XxC; Wed, 29 Jul 1998 03:35:24 +0200 (MEST) To: amigappc-dev@amiga.com.pl Message-ID: <1vb6nMD5131aUz1@ark.news.wwbnet.de> From: ARK@News.wwbnet.de (Andreas R. Kleinert) Subject: Re: Optimising PPC code... Date: Tue, 28 Jul 1998 02:00:00 +0200 References: Received: by News.wwbnet.de ; Tue, 28 Jul 1998 14:29:21 +0100 Received: by apg.wwbnet.de ; Tue, 28 Jul 1998 19:09:45 +0100 Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: You wrote at 28.07.1998/-6:06:12: > 2) In order to implement a mechanism like semaphores, it's necessary to > have some form of exclusion while manipulating the semaphores themselves > (unless this can be done with an atomic operation, which is usually not > the case). While this could be done by disabling interrupts, *that's* a > form of unnecessary exclusion. Thus the semaphore mechanism itself needs > some form of Forbid()/Permit() for its internal use. Well - what the OS does internally is completely irrelevant. Forbid/Permit were private to Exec and not part of the API, then. > Some form of Disable()/Enable() is absolutely essential for code that > interacts with interrupt code, such as hardware device drivers. Note that > the 060 removed the one instruction that might have made this requirement > avoidable. Interrupts are a different field - a better API would have helped there, too. So that Enable/Disable not actually were available for user-mode *applications*... > What I *do* regard as a bug is the automatic Permit() that happens as a > result of a Wait(). A program which does a Forbid() to gain exclusive > access to data structures and then turns around and calls a function which > blocks *could be* specifically expecting that, but may also may be just > plain confused. The latter case tends to lead to things that work "most > of the time". Better to require that the Permit() be done explicitly > where appropriate, and otherwise crash any program that does a Wait() > during a Forbid() or Disable(). The automatic Permit partially may be compensated by using nested Forbid/Permit pairs, e.g. as follows: Forbid Forbid Forbid Permit Permit Permit However, this does not help most of the time - since those case where it would help usually actually match those, where one easily could have used a semaphore instead... -- Andreas_Kleinert@t-online.de or via @gmx.de | ARK@News.wwbnet.de Or try good, old: FidoNet 2:2457/350.18 --- *SuperView* development PerSuaSiVe SoftWorX - Software Engineering Amiga/Wintel and more Visit http://wdo.de/ark/ for information, free downloads, registration -- MicroDot 1.17beta3 registered From amigappc-dev-owner@amiga.com.pl Wed Jul 29 13:05:12 1998 Received: from server.fiber.net.pl (server.fiber.net.pl [195.117.208.101]) by amiga.com.pl (8.8.8/8.7.3) with ESMTP id MAA04399; Wed, 29 Jul 1998 12:55:55 +0200 (CEST) Received: from server.fiber.net.pl (pppa230.szczecin.tpnet.pl [194.204.141.230]) by server.fiber.net.pl (Netscape Messaging Server 3.52) with SMTP id AAB2A7E; Wed, 29 Jul 1998 12:55:13 +0200 From: Marcin Orlowski To: "[WFMH] Lista uzytkownikow Amigi" , "[WFMH] AmigaPPC-Dev ML" Date: Wed, 29 Jul 1998 09:14:13 +0100 Message-ID: Subject: Phase5 Mirror report (fwd) MIME-Version: 1.0 Content-Type: text/plain Reply-To: AmigaPPC developers' mailing list Sender: amigappc-dev-owner@amiga.com.pl Precedence: list Status: O X-Status: ftp://amiga.com.pl/pub/phase5/ *** Begin of forwarded message *** Date: 29-Lip-98 02:00:57 From: Phase5.Mirror.script Subject: Phase5 Mirror report --- Forwarded message follows --- 03:00:30 (4.11 KB/s) - `pub/phase5/cgx3/cv3d216b3.lha' saved [30380] 03:00:31 (132.72 KB/s) - `pub/phase5/cgx3/cv3d216b3.readme' saved [2854] *** End of forwarded message *** -- Programmers don't die, they just GOSUB without RETURN. Marcin http://wfmh.org.pl/~carlos/ mailto:carlos@wfmh.org.pl