<<>> <> <> <> <> <<>> 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]C2CDoc.tioga See also [PCedar2.0]C2CInterLanguageDoc.tioga Describes how to do inter language procedure calls See also [Ivy]C2C>Dealer.tioga See also [PCedar2.0]MimosaDoc.tioga See also [PCedar2.0]LanguageChangesSummary.tioga See also [PCedar2.0]InstallationNotes.tioga See also [PCedar2.0]InstallationSupport.mesa See also [PCedar2.0]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.