On Wednesday 13 February 2013, you wrote: > > Having said this, I think this is the biggest disadvantage of your > > approach. I would assume that most projects would not have problems with > > the available RAM of the cc65 compiler. > > You see, I have sort of the opposite perspective: Each and every > project I did so far with/for cc65 hit sooner or later the "memory > barrier". The only exception so far was NanoVM, which was just way too > slow to grew. i have to agree with that. cc65 is especially useful for large projects, where you'd typically want as much (linear) memory as possible. it should also get optimized for the worst case, not the optimal case. it doesnt really matter at all if hello world is 100ms slower, or 100 bytes longer. > Regarding the memory: You could as well argue that for a small program > it is only a marginal issue to be a little bigger while for large > programs it is a showstopper to not fit into memory. on top of that, speed is almost never an issue. (once you hit a speed critical path using a few bits of assembler will likely do more good than any compiler optimization could ever do) -- http://www.hitmen-console.org http://magicdisk.untergrund.net http://www.pokefinder.org http://ftp.pokefinder.org Liberals by nature look for information and conservatives look for ammunition. <Al Franken> ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Wed Feb 13 23:45:04 2013
This archive was generated by hypermail 2.1.8 : 2013-02-13 23:45:08 CET