[comp.sys.amiga.tech] Free C Compiler? Almost!

ahg@k.cc.purdue.edu (Allen Braunsdorf) (03/12/88)

I have been working on the public domain C compiler from FF110.  So far, my
progress has been pretty good.  It has successfully compiled many programs
(including most of itself), but still has some problems.

My main breakthroughs so far:

	Lobotomized preproc.c and installed the Decus CPP from the
	comp.sources.unix archives.  CPP troubles are >over<!

	Fixed problem with character constants in case statements.

	Have reorganized the source and am trying to make it lint clean.

	Generates good code!  I didn't have anything to do with this, but
	it sure seems to work well- when it works.

	Have fixed most of the casting problems.

	void declarations now work properly.

Some known bugs remaining:

	typedefs

	cast constant to enum type (people shouldn't do that anyway!)

	Some screwy argument problems (will be fixed soon, I hope).

	The default case problem (as in logic.c on the FF disk)

Shortcomings:

	Doesn't do float stuff yet.

	No PD library :-(.

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?).  I've got the ones from the comp.sources.amiga
	archives, and the string functions on FF110.

	Help with the assembler!  The compiler compiles all of its files but
	four (one, if I cheat) down to assembly.  The assembler then chokes
	on ten of them.  In half these cases, I think I see the problem.  In
	the others, however, I am clueless.

	Include files: what are the status of these?  They're listed in the
	RKM, so can they be freely distributed?

	make: the one on FF110 sucks rocks.  I'm using Manx here, that
	obviously will not go out with the compiler!

	editor: a >free< one, not shareware (or worse).

	Any other development tools that people think are useful.  What I'm
	shooting for here is a bunch of free programs that together make a
	useful (admittedly UNIX(tm) influenced) development environment.

Here we have Lattice 3.10 and Manx Aztec C 3.4a (Commercial).  These compilers
are wonderful, but a free compiler would be excellent, and what I have so far
looks promising.  Any help or suggestions would be greatly appreciated.

Replies by email will be answered much more quickly than those posted.

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

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

erd@tut.cis.ohio-state.edu (Ethan R. Dicks) (03/12/88)

In article <2437@k.cc.purdue.edu> ahg@k.cc.purdue.edu (Allen Braunsdorf) writes:
.I have been working on the public domain C compiler from FF110.  So far, my
.progress has been pretty good.  It has successfully compiled many programs
.(including most of itself), but still has some problems.
.
.
.What I need from the Amiga community:
.
.	editor: a >free< one, not shareware (or worse).
.
.
.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

Personally, I like the MicroEMACS on the Extras disk.  It has most of the
functions I need, and is _small_ (compared to other full function editors; ed
does not count).  Also, all Amiga owners should have it, since it comes
with WB1.2.

-ethan




-- 
Ethan R. Dicks      | ######  This signifies that the poster is a member in
Specialized Software|   ##    good sitting of Inertia House: Bodies at rest.
2101 Iuka Ave.      |   ##
Columbus OH 43201   | ######  "You get it, you're closer."

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

haitex@pnet01.cts.com (Wade Bickel) (03/14/88)

   Why don't you sell this?  I think people would appreciate something like
a $40 C compiler with reasonable documentation that has some potential for 
support more than a freeware compiler.

   A good C compiler for beginners would sell pretty well.  It would not have
to come with a huge library, rather with one suited to novices.k

   A good C++ compiler would really be appreciated (and people would pay big
bucks for that :^)) but I guess that's a dream huh?  Until then I'll use
Modula-2.

                                                        Good Luck,


                                                                Wade.


UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COM

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

cks@radio.toronto.edu (Chris Siebenmann) (03/19/88)

In article <2679@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes:
...
>   A good C++ compiler would really be appreciated (and people would pay big
>bucks for that :^)) but I guess that's a dream huh?  Until then I'll use
>Modula-2.

 You could always port GNU C++ (as an extra bonus, you also get GNU C
since they use the same backend). GNU C++ is real C++ (just like GNU C
is real C); the only problem is that it's probably going to be a
monster program.

-- 
	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

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