pointers to code space, library optimisation

[free_electron_2]

instead of the compiler copying everything to ram and then passing into a function it should be possible to pass a pointer to either RAM or ROM.
I
f a string is declared as a literal it should reside in rom. the compiler should pass by reference into rom. Current compiler does not do that. it makes a bulky copy routine to store the string in ram (it seeds an index , performs a MOV of the hardcoded character and then increments r0.
This eats rom space... either do this with a loop or, since you hardcode the characters you can hardcode the target addresses as well and avoid the increment. This would already double the speed and halve ROM space.

Passing a pointer to handling function is most efficient. the function implements a loop searching for the null character on the string.

I have played with the compilers for a couple of days and studied the output. It looks like you use the same core compiler no matter what cpu. You don't take advantage of cpu features in the libraries. the libraries are slow and bulky because they need to be able to run on any cpu.

Code: Select all

Lcd.mbas,40 :: 		q = "hello world"
	MOV R0, #_q+0
	MOV @R0, #104
	INC R0
	MOV @R0, #101
	INC R0
	MOV @R0, #108
	INC R0
	MOV @R0, #108
	INC R0
	MOV @R0, #111
	INC R0
	MOV @R0, #32
	INC R0
	MOV @R0, #119
	INC R0
	MOV @R0, #111
	INC R0
	MOV @R0, #114
	INC R0
	MOV @R0, #108
	INC R0
	MOV @R0, #100
	INC R0
	MOV @R0, #0

the above code comes form the ASM listing. this is just plain ugly !
this wuld halve size and double speed :

Code: Select all

Lcd.mbas,40 :: 		q = "hello world"
	MOV q+0, #104
	MOV q+1, #101
	MOV q+2, #108
	MOV q+3, #108
	MOV q+4, #111
	MOV q+5, #32
	MOV q+6, #119
	MOV q+7, #111
	MOV q+8, #114
	MOV q+9, #108
	MOV q+10, #100
	MOV q+11, #0

the post processor can resolve the physicall addresses and store them directly. but even those direct addresses each take a stupid byte.

the above should be stored as a db chain. and a pointer should be passed.
q = some rom location
org q
db "hello world",0
call 'somefunction'

function gets pointer to Q ( rom address)

s=q^
while s <>0
p1 = s
incr(q)
s=q^
wend

there is endless data shuffling that is totally unnecessary.

Other food for thought : Why is there no 8 bit lcd library ? Also the feature of having every bit in the data path on the 4 bit assignable eats cpu cycles.

[free_electron_2]

essentially you should have overloading capabilties for functions (same function but once with arguments from rom , once from ram)

this is usefull to make print-like handlers
actually the compiler should be smart enough to detect : its a literal use the rom flavor.

[free_electron_2]

here is more info :

Code: Select all

program  Lcd_Test
const pp as string[16]="hello wrold"
sub procedure my_lcd_print (dim x as word)
 dim p as ^word ' create pointer
 dim s as char
 p = x         ' attach to x
while p^ <>0
 P0 = p^
 p1.B4 = 1
 p1.B4 = 0
 inc(p)
wend
 end sub

 main:
  my_lcd_print (@pp)
' this should also be valid code :
' my_lcd-print (@"hello world") ' pointer to a hard literal
  while TRUE
  wend
end.

this is getting close. it shaves from 128 bytes to 109 bytes of rom. but the machine language is still not optimal. the compiler uses generic registers to emulate a data pointer. the CPu HAS a data pointer ! and it even has a dedicate dinstruction to increment the dptr. you don't need to shuffle the virutal datapointer back and forth to the accumulator and perform the addition there.

the machine language should be this :

Code: Select all

:print_lcd
  MOV DPH, x       ; store high address byte of string in DPTH
  MOV DPL, x+1   ; store low address byte of string in DPTH
:loop
  MOVC A, @DPTR  ; copy contents of location pointed at by DPTR to accumulator
  JC done              ; if zero : go to label 'done
  P1 = A                ; throw accumaltor on i/o port
  P31 =  0             ; jiggle pin
  P31 = 1              ; jiggle pin
  INC                    ; increment DPTR
  SJMP loop           ; jump to loop
:done
  RET                    ; return to caller

the calling code would only store the address of the string in X

Code: Select all

MOV x, addressof_string_high_byte
MOV x+1,address_of_string_low_byte
LCALL print_lcd

and even that could be optimised. the caller could directly load the DPTR ( in case of a context swap the caller can preserve DPTR and restore upon return 0 or the storing could be done in the lcd-print code. that way this code would exit with DPTR intact.

the above code is 28 or 29 bytes in ROM + zero ram locations + 11 for the string 'hello world'

We just went from 128 bytes of ROM code to barely 40 bytes. that is more than 300% memory and speed improvement.