From: "Oliver Schmidt"; on Sunday, August 23, 2009; at 04:01 AM -0400 > > > From my perspective, it seems reasonable to presume that the linker, > > together with the C/run-time library, does "somehow make sure" that > > main() is referred. > > I understand that the linker, for sure, isn't limited to C programs; > > so, it doesn't make sense to hard-code such a reference. But, what > > about extending the linker config. syntax/functionality to allow > > something analogous to .forceimport (being kind of the "opposite" of > > SYMBOLS {}, maybe called IMPORT {}). The built-in linker configs. > > then could use that functionality for the symbol _main. > > Just imagine forgetting or misspelling main(). Wouldn't you expect the > linker (called with -t <target>) to complain about not being able to > resolve the symbol '_main'? 2) No, because the built-in configure-code _is_ "hard-wiring". We do not want the "-t" option to force people to stuff an artificial "_main:" label into their purely assembly-coded programs. But, it is a nice idea for custom configure-files. 1) Look at the FORMAT section of "lunix.cfg"; it shows a hint of this idea. And, the beginning of "atari.cfg" shows the export part of this idea. Instead of IMPORT {}, an "import" attribute can be added to the SYMBOLS section. It would be the opposite of the "value" attribute. SYMBOLS { __STACKSIZE__: value = $800; _main: import; } ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Mon Aug 24 19:14:05 2009
This archive was generated by hypermail 2.1.8 : 2009-08-24 19:14:08 CEST