Rev-Ed's estimate of 40 lines in 128 bytes of program memory, 80 lines in 256 and 600 lines in 2048 has been fairly accurate for all programs I've measured metrics on, but some particular programs won't fit that norm at all.
Every statement is made up of a series of 'tokens', which are of various sizes, and you are quite right, with optimisation / different coding you can save quite a bit of code. In general you'll find the following token sizes ...
Commands ( LET, IF, HIGH etc ) are 5 bits
Numbers 0..1 are 4 bits
Numbers 2..15 are 7 bits
Numbers 16..255 are 11 bits
Numbers >= 256 are 19 bits
Variables are 6 bits
Labels ( after THEN, GOTO, GOSUB ) are 11 bits
Operators ( + - * / etc ) are 4 bits
There are also various 'bit flags' which indicate when something more follows ( or not ); think of them as representing the commas and end of line in such statements. Some statements also use additional bits.
The LOOKUP and LOOKDOWN commands can be particularly memory intensive ...
- LOOKUP b0,($A0,$B0,$C0),b1
Every 8-bit value within (...) needs 12 bits, so if you are only looking-up 8-bit values, using EPROM and READ commands can be much more memory efficient, although if many of your looked-up values are less than 16, then that may not be true.
- LOOKUP b0,($A0,$B0,$C0),b1
uses 53 bits, whereas the following uses 41 bits, a 22% saving ...
- READ b0,b1
- EEPROM 0,($A0,$B0,$C0)
As you can see, optimisation is not just about using the statement which use the smallest size of tokens, but also designs which minimise program memory as a whole. A program which uses HIGH/LOW statements on an Output Pin ten times uses 30 bits more than it needs to if it references pins 2 to 7 instead of referencing pin 0 or 1.
There are many places where optimisations may not be obvious; 'LET b0=b0+b1' uses less code space than 'LET b0=b1+b0'.
Optimisation is an art form which can also be hit and miss, not helped by the fact that you are trying to save bits, but only get told how many bytes or part bytes you've used. A one bit increase can appear as a one byte increase and a seven bit reduction may not show at all.
One trick to find out how much memory you need to save is to compile for a PICAXE with greater program memory and see how much is used compared to what your desired target has. Optimising to remove more than 20% of the code is unlikely to be achievable if it's already well designed ( my personal opinion ), and removing 10% can be hard.
Take a look at http://www.hippy.freeserve.co.uk/picaxeop.htm for a few hints on PICAXE optimisation.
