C2CDoc.tioga
Copyright Ó 1987, 1988, 1990 by Xerox Corporation. All rights reserved.
Christian Jacobi, March 14, 1988 6:00:37 pm PST
Christian Jacobi, October 11, 1990 12:38:19 pm PDT
Normal users of C2C will NOT use it excplicitely but simply use Mimosa. The Mimosa doc should have all the necessary information for such users.
Magic switches for manual compilation

For Mimosa in DCedar, probably no switches needed.

For Cinder in DCedar, use:
 cinder -l Package

To copy the C file to an NFS server while running in DCedar, use:
 copy -u -c /server-ux/path/ ← XXX.c

To compile a C file for debugging while on Unix:
 cc -c -g XXX.c

To make a bound version of several files (optional) while on Unix, use:
 ld -r -o Output Input1 Input2 ... InputN -lxrc -lm

More information
This is [PCedar2.0]<C2C>C2CDoc.tioga
See also [PCedar2.0]<C2C>C2CInterLanguageDoc.tioga
Describes how to do inter language procedure calls
See also [Ivy]<Jacobi>C2C>Dealer.tioga
See also [PCedar2.0]<Documentation>MimosaDoc.tioga
See also [PCedar2.0]<Documentation>LanguageChangesSummary.tioga
See also [PCedar2.0]<Documentation>InstallationNotes.tioga
See also [PCedar2.0]<Documentation>InstallationSupport.mesa
See also [PCedar2.0]<Documentation>MimosaOverview.tioga
C2C and Mimosa separate
Use -i switch of mimosa to generate names and icd files.
Use the C2COnly command to execute C2C allone.
This mode is maintained for the benefit of C2C developpment. Normal user should avoid it.
Type help C2COnly to a commandtool to get documentation of the switches for C2C in C2C-alone-mode.
Here some detail about floating point implementation
Solution to the following problem: "Given a value of "word" type, what's the best way to convert it to a float?"
Approach 1
Use macros for floating point operations; never ever generate the word "float"
The macros will do the right thing for you
a) They might expand in procedure calls with loophole parameter passing semantics
b) They might use machine dependent assembly code inline magic
c) They might use same trick as approach 2
Approach 2
Take the address, cast it and then dereference again (Use special switch in cc to get single word floating point operation)
*(float*)&z = *(float*)&x + *(float*)&y;
C2C uses either approach 1) or 2) depending on compile time switches; In case of approach 1) I don't know (care) what the runtime does. Which approach is better depends on availability of hardware floating point:
If floating point hardware is available 2) or 1b) might be good. Experiment showed that for sparc, suns cc and O3 optimization level 2) makes better code than 1c).
If floating point hardware is not available it might depend on how the c compiler deals with floating point: It might generate floating point operations anyway and let them trap; or, it might know and generate procedure calls. In both these cases approach 1a) is best.
If you dont know whether floating point hardware is available... Would you consider 1) and expanding the macros and recompiling the c after you know? Then chose 1) otherwise ?.
If you dont know whether you know if floating point hardware is available ... Invent switches and let the users struggle
The compiler switch in C2C lets the user worry and gives two options; most users don't really think through and set the switches to what they have heard. Happily it usually doesn't matter because floating point operations occur rarely in cedar programs.
Compiler Switches of C2COnly
c:  generate .c2c.c extension. Instead of just .c. I'm really pissed of by this switch! I would prefer C2C not to have a switch but generate c2c.c always. For more than a year I can't change this behaviour because it would cause problems to SSU.
d:  debugging the compiler [T]
 [T] only in C2C-alone mode; [F] with mimosa
f: generate inline floating point operations [F]
r: exteRnal procedure name file [F]
See C2CInterLanguageDoc.tioga
I would prefer it if this feature would NOT be used any more.