bryce@eris (Bryce Nesbitt) (03/12/88)
In article <> ahg@k.cc.purdue.edu (Allen Braunsdorf) writes: > >What I need from the Amiga community: > > Libraries: I've been told I can't give away amiga.lib, so I'm looking > for a replacement(s?). Most of amiga.lib is dumb stub routines that can be generated programatically. You will need to write a program to convert the "fd.files" into assembly language stubs, then assemble that. The C libraries are really the "crown jewels" of a C compiler company. I doubt you fill find much in the way of free help here. > Help with the assembler: sometimes the compiler outputs stuff that > the assembler (from FF110) chokes on. Post *small* examples, edit it down to a line or two and ask the net. > Include files: what are the status of these? They're listed in the > RKM, so can they be freely distributed? Mail cbmvax!amiga!carolyn and ask for a licence. Under certain circumstances, you can get a licence to distribute these with your program. See a message by a cbmvax person for a better path. > editor: a >free< one, not shareware (or worse). I suggest DME. Available in the j.cc.purdue.EDU archives. Only real problem is the author reversed the cursor keys from the accepted standard :-). > Any other development tools that people think are useful. In order: ASDG recoverable ram disk (*if* it is legal to distribute in your manner)!! MemWatch morerows Conman V1.1 AmigaLine 1-X ClickToFront :-) arc The first four are essential. |\_/| . ACK!, NAK!, EOT!, SOH! {O_o} . Bryce Nesbitt (") BIX: mleeds (temporarily) U USENET: bryce@eris.berkeley.EDU -or- ucbvax!eris!bryce
peter@nuchat.UUCP (Peter da Silva) (03/13/88)
In article <7626@agate.BERKELEY.EDU>, bryce@eris (Bryce Nesbitt) writes: > In article <> ahg@k.cc.purdue.edu (Allen Braunsdorf) writes: > > Any other development tools that people think are useful. > In order: > ASDG recoverable ram disk (*if* it is legal to distribute in your manner)!! > MemWatch > morerows > Conman V1.1 > The first four are essential. Really? I think "arc", "uudecode", and "unshar" should be right up there. And what about "Browser 1.3"? :->/2 -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
ahg@k.cc.purdue.edu (Allen Braunsdorf) (03/14/88)
In article <7626@agate.BERKELEY.EDU> bryce@eris (Bryce Nesbitt) writes: >Post *small* examples, edit it down to a line or two and ask the net. I don't have my notes here, but one problem that I remember turning up a lot is "dotted constants": DS.l .0 The assembler doesn't like that at all because of the dot. I don't know what putting a dot before a constant is supposed to mean. Is this a convention I don't know about? Maybe a way to denote a long constant? Additionally: DS.l .0,.1,.2,.3,.4,.5,.6,.7 The assembler really hates this one. Apparently, DS wants just one argument and it shouldn't have a dot on it. If this makes no sense at all, then the compiler's probably belching out garbage, but if this is just not OK for this assembler, I'd like to know the equivalent in this one (it's Metacomco compatible, I think). Allen Braunsdorf WORK k.cc.purdue.edu!ahg General Consultant SCHOOL ei.ecn.purdue.edu!braunsdo Purdue University Computing Center HOME ee.ecn.purdue.edu!gawk!akb
hamilton@uxc.cso.uiuc.edu (03/14/88)
bryce@eris saya: >In article <> ahg@k.cc.purdue.edu (Allen Braunsdorf) writes: >>What I need from the Amiga community: >> >> Libraries: I've been told I can't give away amiga.lib, so I'm looking >> for a replacement(s?). > >Most of amiga.lib is dumb stub routines that can be generated programatically. >You will need to write a program to convert the "fd.files" into assembly >language stubs, then assemble that. better yet, since we have the compiler sources, imitate lattice 4.0's "builtin" glue-routine technique. our user group (champaign-urbana commodore user's group) is looking at fish110 as the basis for an amiga/C programming course. we're waiting for word from CA about a sort of user-group "site-license" for the Native Developer's Toolkit, which includes amiga.lib, the include files, and the AutoDocs. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,seismo,pur-ee,convex}!uiucuxc!hamilton ARPA: hamilton@uxc.cso.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton
jlydiatt@jlami.van-bc.UUCP (Jeff Lydiatt) (03/15/88)
I am pleasantly suprised at the interest shown in a free C compiler
for the Amiga. There is a real good one on the way RSN :-) - read on -
A fellow from Holland, Olaf Seibert, and myself have independently
been working on the compiler from FF #110 throughout the winter.
In mid-February, he mailed me his version, and I spent three weeks
merging his with mine. The result is a greatly enhanced compiler:
o macros now fully supported by Cpp (Decus C preprocessor).
o more friendly error diagnostics.
o typedef and void now fully supported.
o casts handled correctly.
o parameter passing problems fixed.
o compile time constant expressions supported.
o initialization of static and auto variables.
o handles unsigned char, short and long.
o better register allocation and tracking algorithm.
o gets rid of a lot of the "magic numbers" in the code.
o somewhat better code optimization.
In addition to the changes to the compiler, there are also a number of
good support programs and library functions that has either been developed,
or have been discovered:
o a good PD assembler with source. The same as on FF #110
but with a few fixes.
o a good PD make (not the one on FF #110).
o a cc-like front end that integrates the cpp preprocessor,
compiler, assembler, and Blink. IE "cc -o hello hello.c" is all
the typing required to produce a runnable hello world program.
o a rudimentary I/O support library for getc, putchar,
fprintf, read, write etc.
o a pretty comprehensive string library (strlen, strcpy) etc.
The compiler is not yet fully functional however. Some of the missing
features and/or problems are outlined below:
o no long multiply, divide and mod functions. Int's are 32 bit
longs, but these operations are done with the native instructions
and a warning is printed.
o no floating point support.
o The standard i/o library and functions needs fleshing out.
o Seems to have run into a bug with Blink for the larger programs -
if we can't solve that by altering the compiler generated code,
we may be faced with writing a linker. Wonder what the chances
of the Software Distillery Boys releasing the source to the
PD version of Blink?
Assuming Olaf has no objections, it is my intention to release the compiler
and whatever source code I have when the compiler has been tested out. In
order for the compiler to be useful however, you will need the Native
Developers kit available from Commodore for $20. This will give you the
include files and the Amiga.lib C-stub glue support to the Amiga operating
system. I have noted Bryce's suggestion that Commodore may be willing
to grant a distribution licence with the compiler and will follow that up.
The compiler would be much more useful if the include files could be
distributed on the same disk.
I don't plan to have any restrictions on the redistribution of the compiler
other than the copyright notices remain intact, that the compiler be made
available for only a nominal distribution fee, and all commercial rights
not claimed by Matt Brandt (the original compiler author) are also reserved.
The compiler is really close to releasing. I've sucessfully compiled
assembled and linked the assembler source code and used the result to
assemble a couple of large programs. The object code generated by
the PDC-assembler and the Manx-assembler compares the same!
I'll keep you all updated on it's status.
--
// Jeff Lydiatt UUCP: uunet!van-bc!jlami!jlydiatt
\X/ or : {ihnp4!alberta!ubc-vision,uunet}!van-bc!jlami!jlydiattcmcmanis%pepper@Sun.COM (Chuck McManis) (03/16/88)
In article <1692@van-bc.UUCP> jlydiatt@jlami.van-bc.UUCP (Jeff Lydiatt) writes:
->I am pleasantly suprised at the interest shown in a free C compiler
->for the Amiga. There is a real good one on the way RSN :-) - read on -
-> o no long multiply, divide and mod functions. Int's are 32 bit
-> longs, but these operations are done with the native instructions
-> and a warning is printed.
-> o no floating point support.
May I suggest you consider inline calls to the mathieeedoubas.library? It
has been enhanced in 1.3 to be nearly as fast as FFP and takes advantage
of an '881 or '882 if present automatically. That might also allow you
to do 32 bit integer arithmetic.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.cks@radio.toronto.edu (Chris Siebenmann) (03/16/88)
In article <7626@agate.BERKELEY.EDU> bryce@eris (Bryce Nesbitt) writes: >In article <> ahg@k.cc.purdue.edu (Allen Braunsdorf) writes: >> >>What I need from the Amiga community: >> >> Libraries: I've been told I can't give away amiga.lib, so I'm looking >> for a replacement(s?). > >Most of amiga.lib is dumb stub routines that can be generated programatically. >You will need to write a program to convert the "fd.files" into assembly >language stubs, then assemble that. Someone has already written a program to do this, called bind. I saw it on Bix; if there's a demand, I'll send it off to the comp.binaries.amiga moderators. I had to use it once (to get RawDoFmt() for 1.2) and it worked fine. >> editor: a >free< one, not shareware (or worse). > >I suggest DME. Available in the j.cc.purdue.EDU archives. Only real >problem is the author reversed the cursor keys from the accepted standard :-). MG is also quite good, especially if you improve it a bit (window iconification is very easy to do, and is a big win). > >> Any other development tools that people think are useful. > >In order: > >ASDG recoverable ram disk (*if* it is legal to distribute in your manner)!! >MemWatch >morerows >Conman V1.1 You can substitute Matt Dillon/Steve Drew's shell (with the titlebar hack ideally) for Conman V1.1. I actually prefer csh to Conman because I can always get a stock CLI. csh also has quite a few built in commands, understands wildcards, and does some other Unix-like things. Of course, if people want a really good free C compiler, there's always GNU C. Has anyone managed to port this? I've gotten as far as a tm-amiga.h file, but am currently hung up on making it emit xrefs for external symbols (Manx's as doesn't like undefined symbols). I'd be very grateful if anyone has already fixed this problem, or made it use 16-bit ints. -- You're a prisoner of the dark sky/The propeller blades are still And the evil eye of the hurricane's/Coming in for the kill Chris Siebenmann {allegra,mnetor,decvax,pyramid}!utgpu!radio!cks cks@radio.toronto.edu or ...!utgpu!{chp!hak!ziebmef,ontmoh}!cks
haitex@pnet01.cts.com (Wade Bickel) (03/16/88)
peter@nuchat.UUCP (Peter da Silva) writes: >In article <7626@agate.BERKELEY.EDU>, bryce@eris (Bryce Nesbitt) writes: >> In article <> ahg@k.cc.purdue.edu (Allen Braunsdorf) writes: >> > Any other development tools that people think are useful. > >> In order: > >> ASDG recoverable ram disk (*if* it is legal to distribute in your manner)!! >> MemWatch >> morerows >> Conman V1.1 > >> The first four are essential. > >Really? I think "arc", "uudecode", and "unshar" should be right up there. > >And what about "Browser 1.3"? :->/2 Most of these are great PD programs, but do not really "need" to be included, do they? After all, uuencode really has nothing to do with a C compiler, and would hopefully be included with PD communications packages.}ir?];?>*D |Xl If this compiler is going to be PD, why laden the disks (or .binary) with duplications of readily available PD software? Of course if it is going out on disk and there is extra space that is a different story. To be honest, PD compilers make me nervous. There OK for play, but not for serious work. If I run into a serious bug, I don't wan't to hear "sorry, I'm doing spacial relations work for General Dynamics right now, maybe in a few months...". Thanks, Wade. PS: would someone please tell me something about "Browser"? UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
bmacintyre@watsol.waterloo.edu (Blair MacIntyre) (03/17/88)
In article <1692@van-bc.UUCP> jlydiatt@jlami.van-bc.UUCP (Jeff Lydiatt) writes: >I am pleasantly suprised at the interest shown in a free C compiler >for the Amiga. There is a real good one on the way RSN :-) - read on - > >The compiler is not yet fully functional however. Some of the missing >features and/or problems are outlined below: > > o no floating point support. This is the second time I've read something like this ... why not use the Fast Floating Point Libray's??? ( or am I being blatantly stupid and missing something? :-) -- ===========================================================================///= Blair MacIntyre (bmacintyre@watsol.waterloo.edu) ( Long live the Amiga!! )/// "Violence is the last resort of the incompetent" - Harry Seldon \\\/// =Have you hugged your dragon today??=(how about your SO??)=============\XX/====
walker@sas.UUCP (Doug Walker) (03/19/88)
In article <1692@van-bc.UUCP> jlydiatt@jlami.van-bc.UUCP (Jeff Lydiatt) writes: > o Seems to have run into a bug with Blink for the larger programs - > if we can't solve that by altering the compiler generated code, > we may be faced with writing a linker. Wonder what the chances > of the Software Distillery Boys releasing the source to the > PD version of Blink? Several points (as a Software Distiller): 1. Why haven't you tried to let us know what the bug in BLink is? No offense, but I suspect the bug may not be in BLink, since BLink has had a lot more use and testing than your compiler. 2. The chances of releasing the source are nil, since we no longer control it. However, we may be allowed to release one more PD version solely to fix bugs.
jlydiatt@jlami.van-bc.UUCP (Jeff Lydiatt) (03/20/88)
> In article <1692@van-bc.UUCP> jlydiatt@jlami.van-bc.UUCP (Jeff Lydiatt) > > o Seems to have run into a bug with Blink for the larger programs - > > if we can't solve that by altering the compiler generated code, > > we may be faced with writing a linker. Wonder what the chances > > of the Software Distillery Boys releasing the source to the > > PD version of Blink? > > Several points (as a Software Distiller): > > 1. Why haven't you tried to let us know what the bug in BLink is? > No offense, but I suspect the bug may not be in BLink, since BLink has > had a lot more use and testing than your compiler. > > 2. The chances of releasing the source are nil, since we no longer > control it. However, we may be allowed to release one more PD > version solely to fix bugs. > With regards to point 1, Doug. I guess the answer is that my efforts to date have been directed at whipping the compiler and library routines into shape, and the problem I was having with BLink wasn't holding up progress since Alink worked fine. We also know there are problems with the PD assembler we are using, and hoped that when we had those ironed out that the BLink problem would go away. While the problem is no doubt due to some bad or totally-strange input to BLink, I do think there is a bug in BLink somewhere. With BLink 6.7 which I believe is the last PD version you released, the symptoms of the bug are either: a) The linker generates an invalid load module, without any accompanying error message. When you try to run the linked program, the AmigaDos loader thinks it's not a valid program and won't run it. - or - b) BLink gurus. With regards to point 2 - no suprise, I really didn't expect a different answer but it never hurts to ask :-). However, if you could release one final version that fixes a few bugs, that would be more than I hoped for. If the offer stands, could you let me know by Email, and I will do a some analysis on the problem to narrow it down. I wasn't looking forward to writing a linker, and BLink is widely regarded by everyone (including me) as one of the best PD programs around for the Amiga. -- // Jeff Lydiatt UUCP: uunet!van-bc!jlami!jlydiatt \X/ or : {ihnp4!alberta!ubc-vision,uunet}!van-bc!jlami!jlydiatt
cks@radio.toronto.edu (Chris Siebenmann) (03/22/88)
In article <2687@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: ... > To be honest, PD compilers make me nervous. There OK for play, but >not for serious work. If I run into a serious bug, I don't wan't to hear >"sorry, I'm doing spacial relations work for General Dynamics right now, >maybe in a few months...". Serious PD compilers with source scare me far less than commercial compilers. When I'm doing serious work, I don't want to be at the mercy of anyone for bugfixes; I want to be able to fix/patch it myself. I feel the same way about libraries and library sources; I've fixed too many problems in various people's libraries to really trust something I don't have source for (which is one reason I bought the commercial Aztec C package, and not the developer's). [By 'serious' I mean a compiler that is H&S compliant and able to compile, say, MG.] -- You're a prisoner of the dark sky/The propeller blades are still And the evil eye of the hurricane's/Coming in for the kill Chris Siebenmann {allegra,mnetor,decvax,pyramid}!utgpu!radio!cks cks@radio.toronto.edu or ...!utgpu!{chp!hak!ziebmef,ontmoh}!cks