minow@decvax.UUCP (05/19/84)
I have written and (mostly) debugged a C pre-processor which is intended to replace the MP program in the Decus C library. It seems to work ok on Vax/VMS and 4.2 BSD, but a program such as this requires a lot of testing. I am willing to send copies out to four or five sites who can help catch nits and other confusions. I would especially appreciate a site with a system such that sizeof (int) != sizeof (char *). The preprocessor is intended to implement the Draft Ansi C standard and contact with a site actively working the standard would also be appreciated. When I'm happy with the quality of the code, I'll post the whole thing to net.sources. Martin Minow decvax!minow
fred@mot.UUCP (Fred Christiansen) (10/30/84)
{}
Within Motorola, M68000 refers to the family of microprocessors, of
which the MC68000, MC68010, and MC68020 are instances. Other M68000 suppliers,
such as Mostek (e.g., MK68000), Signetics, Thomson-CSF, and Hitachi, have their
own unique prefix.
In our development of the SGS 68000 C compiler for UNIX System V/M68000
with AT&T Bell Labs, we sought an #ifdef predefine which would indicate the
hardware family architecture (such as 'vax' for all vaxen, 'pdp11' for all
pdp11's), and decided on 'm68k'. We specifically avoided an 'mc' prefix as
that smacked of parochialism. We also avoided 'm68000' as that suggests
specificity over generality.
In the event that an #ifdef is needed for something very processor
specific (handling stack faults, for instance), our practice has been to
add an #ifdef (or extend an #if) with M68000, M68010, or M68020, making
the definition (-D) in the makefile. The capital M is arbitrary but consistent
with the mechanism we recommend for identifying the target processor to the
compiler (via an environment variable PROCESSOR), to enable specific code
generation, and to makefiles.
(P.S. To Guy Harris and others: Version 8 is an AT&T Bell Labs internal
version worked on by the Research Group. It is not known as System 8.
Future releases from AT&T Tech will continue to have System V in the name.
At least, this is what I have gleaned from Usenix and from the trade shows.)rb@ccird1.UUCP (Rex Ballard) (06/07/86)
In article <2600061@ccvaxa> aglew@ccvaxa.UUCP writes: > >>/* Written 3:49 pm May 28, 1986 by chris@umcp-cs.UUCP */ >>In article <2786@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >>>... having a separate pre-processor will slow the compiler down >>>considerably, but is it an advantage?????? It only gives you a >>>certain amount of convenience in implementing the compiler. >> >>Not so! There is another advantage. The preprocessor can be used >>alone, or in combination with programs other than the C compiler. >>This is the `software tools' philosophy: if you can make a clean >>conceptual break in a task, make that break programmatically; you >>then have a set of tools that may be useful in surprising ways. > >Unfortunately, there is no longer a clean conceptual break between >the C pre-processor and the compiler: `sizeof' can be used in >pre-processor constant-expressions. > >I very much doubt that a cpp that parses enough of C to understand >sizeof will be useful in non-C-related applications. > What? You don't have lint?, cflow?,...? We even have a few that you've never heard of. If CPP were integrated into the compiler, it would be bad news! Anyone got "macro assembler pre-processors" that are 100% compatible with DEC or Microbench (8085) and written in a portable language? Even 80%? (I'm serious, if you have one, send mail). Writing the assembler is easy, but the pre-processor is a killer! We still have to put our Vaxen in "emulation mode" (yawn) to build for certain targets. Conversion to m4 is progressing rather slowly, thank you :-). Microbench is a trademark of Virtual Systems Inc.