[PD] code and compilers
matju at artengine.ca
Sat Dec 8 21:08:29 CET 2007
On Sat, 8 Dec 2007, Andrew Brouse wrote:
> An old-school hacker (poet turned progammer, classic!) once told me that
> he used to debug his programmes (on mainframes, with not even 1M of
> memory) by actually just watching a display of activity in all memory
> locations. After a while, he just subconsciously internalised what was
> going on and managed to debug the code.
This can't possibly be used nowadays, but there are better ways of
visualising code. Because C values are typed, you can (to a certain
extent), view the data topologically, by following pointers, which get
drawn like arrows that are connecting boxes containing data. This is what
DDD does (it's a GDB wrapper). This is more useful because the positions
in memory are somewhat meaningless, because the connectedness of the data
happens because the program follows pointers rather than using any
arithmetic other than for a single array or struct.
> On a fundamental level, any code we run is just changing patterns of
> electrons bouncing about on a wafer of impure silicon. Thus, when our
> high-level tools fail us or don't give the expected result, we sometimes
> have to dig down a little deeper. Maybe there is a chunk of code, like
> that block of 68k assembly, which is just churning electrons around,
> basicaly doing nothing.
On a different fundamental level, any code we run is for ourselves, it's
for communicating us back a result. Many possible programs fulfill the
requirements that we have in writing a program. Trying out several
strategies giving the same results in different times helps us figure out
efficient solutions. If you have enough RAM, there's always a long enough
list that will be sorted faster with a quicksort in BASH than with a
bubblesort in assembly language. (And it doesn't even take that much RAM).
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
More information about the Pd-list