airmailed Posted February 5, 2006 Report Share Posted February 5, 2006 i just read this, it sounded kind of relevant, in the sense that some people might be writing c code that they want as fast as possible.http://www.cs.indiana.edu/~jsobel/c455-c511.updated.txti've been playing with scheme a little bit, after reading a lot of articles on http://paulgraham.com about lisp, it sounds pretty interesting though some of it is above me... also of interest is lush.... http://lush.sf.netlush is a lisp style language which can be translated into c by the software.... the documentation is a little dense though Quote Link to comment Share on other sites More sharing options...
moebius Posted February 5, 2006 Report Share Posted February 5, 2006 Hi!I doubt these are relevant for MIOS C programming.The C option is nice to have - more people have programmed C than assembler and some things are just easier in C. I luv assembler - basicly playing directly in the hardware bit, byte level. But it gets damn complex, when working with software like any bigger MB project for MIOS.C code is always bloated when compiled! I say!! (My teacher who TRIED to teach me embedded C programming (AVR uCs) said that current C compilers are advanced enough that it doesn't do any difference) I doubt. TK?Moebius(p.s. When are we in the level of standardization, When we have just a Java applet, where we can create setup for our midiboxes - standard libraries for I/O, UI, ect. - just drawing wires between the software components?) Quote Link to comment Share on other sites More sharing options...
TK. Posted February 5, 2006 Report Share Posted February 5, 2006 C code is always bloated when compiled! I say!! (My teacher who TRIED to teach me embedded C programming (AVR uCs) said that current C compilers are advanced enough that it doesn't do any difference) I doubt.TK?me too... for all 8bit processors I know this statement is not true. E.g. assembly language allows a totally different use of data memory, the code can store and access informations much more efficiently than a C compiler would ever allow. A more explicit example: C stores temporary variables on a stack, and stack operations consume a lot of cycles. In assembler, you can define your own set of temporary variables, and you have to manage resource conflicts by yourself. This also means, that such optimized data structures are mostly not relocatable, and hard to modify - but they are powerful!On the other hand: the architectures of modern 32bit CPUs provide a huge instruction set to support C compilers. There are so many possible variations for different situations, that on large projects a C compiler mostly creates a better/faster code than you could ever program in assembly language (within the same time).And another point: for finding new algorithms the use of high level languages definitely makes sense to save time, but if CPU load and memory consumption does matter, the job is not finished once the algorithm is working - the next step is to translate it into handwritten assembly code.Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.