cagney@chook.ua.oz (Andrew Cagney - aka Noid,285,5585,3362395) (09/11/89)
From article <3196@ast.cs.vu.nl>, by ast@cs.vu.nl (Andy Tanenbaum): > On a related note, we have converte the ACK compiler to be ANSI standard > and it is too big to fit in 64K + 64K. Such is life. What about just changing the cpp section to comply with ANSI C input while producing old K&R C output? The ACK compiler could then be extended to handle a few extra features (eg void* & const ...) The hacky changes to the language are mostly in the #defines and how they behave. Modifying just cpp should cover this. I say hacky because people have a habit of using old K&R features with defines that are not formally specified eg #SYMB instead of "SYMB" A ## B instead of A/**/B (Read an ansi C manual) Umm this should not be taken as an offer to do this just a suggestion for a 'cheap' solution. Andrew Cagney (noid) cagney@cs.ua.oz.au
matsl@nada.kth.se (Mats Luthman) (09/12/89)
From article <3196@ast.cs.vu.nl>, by ast@cs.vu.nl (Andy Tanenbaum): > On a related note, we have converte the ACK compiler to be ANSI standard > and it is too big to fit in 64K + 64K. Such is life. What about releasing it for the ATARI?
ast@cs.vu.nl (Andy Tanenbaum) (09/14/89)
In article <1613@draken.nada.kth.se> matsl@nada.kth.se (Mats Luthman) writes: >What about releasing it (ANSI C) for the ATARI? You want me to maintain two separate compilers, one for the PC and one for the ATARI, with different input languages? :-) I may be crazy, but I'm not stark raving mad. The present PC and Atari compilers accept exactly the same language--they have to--it is the same front end. Maybe we could have the current compiler at least accept the new keywords const, volatile, and maybe a couple of others, and ignore them. This would at least eliminate -DCONST= etc. Comments? Andy Tanenbaum
n62@nikhefh.nikhef.nl (Klamer Schutte) (09/14/89)
In article <3249@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: ... >Maybe we could have the current compiler at least accept the new keywords > const, volatile, and maybe a couple of others, and ignore them. This >would at least eliminate -DCONST= etc. ... >Andy Tanenbaum I think this will be a reasonable compromise (but i like a full ANSI compiler more :-( ). But i think that besides these semantic isues (which should include acceptance of prototyping) there should be a tool which checkes whether the input is really ANSI compatible. This one can be incorporated in the ATARI compiler; but perhaps this will break the symmetry between the two frontends. This tool should allow us to write proper ANSI code; this will keep us up with the rest of the world. Comments? Klamer. -- ____________________Yes, mail address changed again :-(_________________________ Klamer Schutte mcvax!nikhefh!{n62,Schutte} {Schutte,n62}@nikhef.nl
lyle@ogccse.ogc.edu (Lyle Cool) (09/15/89)
In article <3249@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >Maybe we could have the current compiler at least accept the new keywords > const, volatile, and maybe a couple of others, and ignore them. This >would at least eliminate -DCONST= etc. > >Comments? > >Andy Tanenbaum You mentioned in an earlier message that there is a "full" ANSI compiler but that it is too big for the current Minix-PC. Are you looking for volunteers to try and pare it down? If it is not possible to cram the full ANSI compiler into Minix-PC, I would like to see, in addition to what you mentioned: - support for prototypes - support for long global identifiers Lyle Cool (lyle@ogc.cse.edu)
desyoung@thoreau.nsc.com (Des Young) (09/18/89)
> include acceptance of prototyping) there should be a tool which checkes > whether the input is really ANSI compatible. This one can be incorporated > in the ATARI compiler; but perhaps this will break the symmetry between the > two frontends. > This tool should allow us to write proper ANSI code; this will keep us up > with the rest of the world. > Klamer Schutte mcvax!nikhefh!{n62,Schutte} {Schutte,n62}@nikhef.nl A while ago, someone posted a program that checked a c source file to verify that it was not violating ANSI syntax (or was that it checked to see it conformed?). Anyway, I think it was posted to this group, or to comp.sources.atari. If the author (or distributor) is reading this, can he please stand up. I am away on the other side of the country, so I cannot check my archives. If I find it, I will repost. That will be a few weeks away. Cheers, Des Young. Des Young. des@dtg.nsc.com National Semiconductor, Santa Clara, CA.
evans@ditsyda.oz (Bruce Evans) (09/18/89)
In article <3249@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >Maybe we could have the current compiler at least accept the new keywords > const, volatile, and maybe a couple of others, and ignore them. This >would at least eliminate -DCONST= etc. If you don't do a complete job on them, it is misleading to pretend they are implemented, not much better than putting -Dconst= etc. in the cc driver. What about the front end to the ANSI compiler, does it fit in 64K + 64K? How big are all the passes exactly? -- Bruce Evans evans@ditsyda.oz.au
ast@cs.vu.nl (Andy Tanenbaum) (09/30/89)
In article <2217@ditsyda.oz> evans@ditsyda.oz (Bruce Evans) writes: >If you don't do a complete job on them, it is misleading to pretend they >are implemented, not much better than putting -Dconst= etc. in the cc >driver. You are probably right. It may be convenient to have const etc recognized, so if the ANSI compiler is too big, we will probably put in a flag to enable/disable recognizing non K&R constructions. I'll think about it. Andy Tanenbaum (ast@cs.vu.nl)