From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <463D5F3D.5090405@conducive.org> Date: Sun, 6 May 2007 12:53:17 +0800 From: W B Hacker User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] speaking of kenc References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 5b070176-ead2-11e9-9d60-3106f5b1d025 erik quanstrom wrote: >> 1 and 3 are not really that different, so you're down to two examples. >> C is OK for newer embedded systems (microcontrollers), older ones are >> what they are and ASM may well be the way to go. But even there, ASM >> is often just the lazy way rather than the more economical way. > > perhaps you haven't programmed many microcontrollers. usually the > volumes are high and the per unit cost is very important so you end up > with very simple parts with very little ram/flash. the one i worked on > earlier this year had low speed usb interface, 2 gp registers, 256 bytes of ram > and 4k of flash. > > i found it easy enough to program in assembly, but i don't think you'd > get very far with c. i just don't think you could fit things into memory. Well 'C compiler hosted on a larger machine, and with that one as a binary target' will no doubt come back from someone. And that isn't wrong. But unless it has to be done over and over in may ways, such a setup can take longer to set up, test, and option for a given run than to JFDI the app in machine code. Less than 5K bytes total fits on a page or two of A4 in hex, or one modern LCD display. How 'lost' can you get in a teacup? And how many op codes will you actually need to use from what must be a rather small set anyway? Bill > >> I have a feeling brucee will point out that the gain in efficiency in >> using ASM is insufficient to justify the additional costs in >> complexity and error potential. > > i don't understand the assumption that the only reason to use assembly is > cycle efficiency. Actually it often has *less* of that efficiency than a highly optimizing 'C' (or 'D') compiler. Especially if the coder is not well and truly au fait with a specific CISC machine's op codes, architecture, cycle 'cost'. > > also, could you explain why this is "lazy"? or why assembly is more > complicated? > "Tedious" might be more accurate than "complicated". ;-) > clearly, an assembly is more difficult to wield than c. but you don't > use them for the same thing. > Some of us try hard not to use either of them at all.... > this absolutist argument that c is teh bomb. asm suks is silly. it's like > arguing bicycles and ferraris. which one you need (and which one gets > you there faster) depends on what you're doing. > > - erik > ACK. Hong Kongs 100+ year-old tram system beats the modern underground on cost, the undergrond beats a taxi on speed at rush hour, but not otherwise, buses have a wider route choice than either, and the taxi *always* rules on assuredly getting a place to sit down. IF you can get the taxi in the first place - which is NOT assured. 'puters are not so different. Glad to have choices, and we can never stop making them without giving up *something* of value. Bill