Well, the examples. Maybe a bit lengthy, but the issue is not simple, either.

One of our "gadgets", where cost was an issue, is networked in a RS485-based network, master-slave, master is a PC, fancy Win software. Slaves are of various types. A packetizing protocol is made, adressing, polling system, etc.etc. I started off with a 2051, but ended up with a 4051 and 2 bytes left in RAM (additional features were required when the hardware was already in place).
There is a requirement to set a couple of parameters (both in RAM and an external serial FRAM) via the "net", and also some variables are read back from the gadget to the PC.
With the "smarter" devices, for each parameter or set of parameters and each transmitted variable, a separate type of packet is added to the protocol stack. But for this little one, this approach increases the required code space beyond a tolerable limit (4kB in this case); so we implemented a single "write/read directly into/from RAM/FRAM" couple of request/response. Of course, this implies either to keep the position of the parameters/variables absolute for each modification/upgrade of the gadget, or to have a "relocation table" on the PC for each modification/upgrade. The second approach requires to permanently upgrade the table on the PC, with dramatic effects if e.g. the version number would be improperly set or detected. No thanks, the first option is more straightforward.
Btw. in the above example, I think nobody would object if I place the FRAM (or I2C EEPROM) parameters/variables into a fixed place, as there is no direct support for variable (re)location in the assembler.


An another example, now for some speed/space tricks, a little bit simpler.
I have three circular buffers in IRAM to process - two source and one target - and only two pointers to use - @r0 and @r1. Besides, one of the buffers is only 4 bytes long (a scrambling value) and the source and destination are both 32 bytes long (the scrambled and the unscrambled data). I need to preserve the original message (for retransmission with a different scrambling value). Remember, my RAM budget is so tight that I have only 2 bytes left, so I don't want to spend an extra memory not even register for the counter (in fact, it is so tight, that I set SP to #4 initially... and those registers are desperately needed...). But I have B register unused. And I need it make as fast as possible. So I do it this way:

Scramble EQU   030h   ;-33h
;... other variables here
SrcBuf   EQU   040h   ;-5Fh
DstBuf   EQU   060h   ;-7Fh

;at start, r0 contains pointer to SrcBuf
;          b  contains message length
   mov   r1,0
   anl   r1,#03h          ;first, calculate pointer into Scramble
   orl   r1,#Scramble
Loop:
   mov   a,@r0            ;get data from SrcBuf
   xrl   a,@r1            ;perform scramble
   xrl   0,#SrcBuf XOR DstBuf     ;get pointer to DstBuf
   mov   @r0,a            ;store scrambled data
   xrl   0,#SrcBuf XOR DstBuf     ;restore pointer to SrcBuf
   inc   r1               ;increment Scramble pointer
   anl   1,#0FBh          ;wrap around Scramble pointer
   inc   r0               ;increment SrcBuf pointer
   anl   0,#0DFh          ;wrap around SrcBuf pointer
   djnz  b,loop

This is not to say that it is necessary to use absolute variable positioning, or that this is a proper way of general programming. Sure, this is perhaps the most dirty programming I did. But it works and cost me only a bit of thinking - and I enjoy thinking.

Each method/tool has its right place and shall be used so. But, never say never.

Jan Waclawek