On Sat, Nov 29, 2014 at 02:41:23PM +0000, smplx wrote:
>    * FORTH -> kind of like assembler but harder to optimise

I know the above is intended as a joke ... but for me the joke is in
how easy it is to optimise Forth code.

Capture instruction or other clock samples at critical points, such as
the start of a word (function), to find the hot spots, then change the
critical code from Forth to assembly using the usually built-in
assembler.

Or, since usually everything can be executed manually over the serial
port to your application, use a feature that measures execution time
of a function interactively; e.g.

ok : t( get-usecs ;
ok : )t get-usecs swap d- d. ." us" ;
ok t( part-of-my-app )t
3325 us
ok=20

Then do it again a few times (up arrow, enter) to get an idea of
variance.

Then do it again and bracket the things that part-of-my-app calls.

I've done COBOL.  Great money spinner.  Hard to do in a team though,
'cause my code was often slightly FORTH or C like.  Writing a FORTH
bytecode execution environment in COBOL can raise eyebrows.

--=20
James Cameron
http://quozl.linux.org.au/
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.