Re: [comphist] Lost arts from the 8 bit days.

[Rob L. <la...@tr...>]

On Wednesday 02 October 2002 05:16 pm, Thomas Dodd wrote:

> But, you learned a lot from that. Sure, it would be overboard today,
> except in embeded devices, but the skills are still usefull. Instead
> bits in a byte, it could be bytes in a structure. Or accounting for
> cache line length. Also important is knowing *when* to use it, and
> documenting it, since comments in the source don't take up space
> in the object code.
>
> But it's good to know how to trim the code when needed. Like a few K
> from fitting in one ROM, and the next size up is 2x the cost. Ignoring
> the memory footprint is not a good thing. Should I always allocate the
> biggest structure I might need, or should I use only what I do need. In
> the bloated world today, no consideration of memory is given.

For performance, the cache stuff is far more important than most people 
realise.  Modern processors are clock multiplied by almost 20 times the speed 
of the memory bus.  The difference between something that fits in cache and 
something that doesn't is an order of magnitude.

it's also something that desperately needs to be documented, yes.  Writing 
something this way for purposes of cache coherence is NOT obvious.  (For 
example, the linux-kernel guys are starting to learn that many of their 
inlines are counter-productive, and they're still mostly the original guys 
who wrote them...)

> Should I use if-else or case? Do I these the most common case first or
> last. Can I reduce the number of branches by changing the tests? Knowing
> the hardware (and compiler) are impoortant there.

Forest for the trees.  I don't optimize to my compiler.  Not even GCC, 
switching from 2.7 to egcs to 3.2 makes all that go totally out the window...

> Documenting what is done is even more important when you use non-obvious
> methods. But the methods have valid uses. Look at perl code.

Oh please let's not. :)

> It can be effecient and understandable.

But not for long.

> It can be ineffecient and impossible to follow.

The default case. :)

>
> And we've all seen bloated code that is neither effecient nor
> maintainable. Having looked at OO.org and Mozilla, I would have
> nightmares if I ever saw Windows98/Me/XP or MS-Office.

Often, the best way forward is to isolate a subsystem, document the 
interfaces between it and the rest of the system, and then rip it out by the 
roots and write a fresh implementation to those interfaces.

Often you have to clean up the code a bit before there ARE anything similar 
to interfaces between subsystems.  But that's a pretty important skill...

> 	-Thomas

Rob