Is it normal to have to at $10 to labels when using LMM ?

Bean · 2010-02-05 01:26

I have been working on my implementation of LMM, but it seems I must add $10 to all the labels.
I tried using ORG $10, but that didn't work either.

I wanted to implement CALL the same way the propeller does (where it changes the return instruction).

Anyway by putting in a bunch of LONG values I was able to see that all the "LONG @label" values where off by $10 but I don't know why.

Is there an easier way to do this without having to add $10 all the time ?

''***************************************
''*  Propeller LMM Experiments          *
''*  Author: Terry Hitt                 *
''***************************************
CON
  _ClkMode = xtal1 + pll16x
  _XInFreq = 5_000_000

PUB Main
  CogNew(@_LMM_Entry, @My_LMM_Code)

DAT
  ORG $0
' -------------------------------------------------------------------------------------------
' LMM Program
' -------------------------------------------------------------------------------------------
My_LMM_Code
  or DIRA,Mask ' Make pin an output
  mov Wait,CNT ' Setup wait variable
  add Wait,Delay
 
Again
  or OUTA,Mask
 
  jmp #_LMM_CALL         ' call #Pause    
  LONG @Pause_RET + $10
  LONG @Pause + $10
 
  andn OUTA,Mask
 
  jmp #_LMM_CALL         ' call #Pause
  LONG @Pause_RET + $10
  LONG @Pause + $10
 
  rdlong _LMM_PC,_LMM_PC ' jmp #Again
  LONG @Again + $10        
 
' Subroutine Pause

Pause
  waitcnt wait,delay
  rdlong _LMM_PC,_LMM_PC
Pause_RET
  LONG 0-0
 
DAT
' -------------------------------------------------------------------------------------------
' LMM Execution code
' -------------------------------------------------------------------------------------------
  ORG 0
_LMM_Entry
  mov _LMM_PC,PAR
 
_LMM_LOOP
  rdlong _LMM_INSTR1,_LMM_PC
  add _LMM_PC,#4
 
_LMM_INSTR1
  nop   ' Placeholder for LMM instruction
  jmp #_LMM_LOOP

_LMM_CALL
  rdlong _LMM_TEMP,_LMM_PC
  add _LMM_PC,#8
  wrlong _LMM_PC,_LMM_TEMP
  sub _LMM_PC,#4
  rdlong _LMM_PC,_LMM_PC
  jmp #_LMM_LOOP
   

  ' Variables for LMM execution code
_LMM_PC     LONG 0  ' Program counter
_LMM_TEMP   LONG 0
 
' Constants/Variables for My_LMM_Code
Mask   LONG %0000_0000_1111_1111_0000_0000_0000_0000
Delay  LONG 40_000_000
 
' Variables for My_LMM_Code
Wait   RES 1

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.

PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

RossH · 2010-02-05 02:51

Hi Bean,

Yes - this is quite normal. Calculating where your DAT segment actually ends up in the binary can be complex (and as far as I know, undocumented). There probably is a "proper" way to do it, but in Catalina I just use various constant values - the value $10 crops up quite a lot.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Bean · 2010-02-05 02:59

Okay so I'm not crazy.

Thanks Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.

PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

kuroneko · 2010-02-05 03:02

Note that $10 is only valid for the top object (its offset in the resulting binary). Sub-objects have obviously different offsets.

Post Edited (kuroneko) : 2/5/2010 3:07:56 AM GMT

Cluso99 · 2010-02-05 03:08

$10 is because all code is referenced to this hub location when compiled. See the homespun listing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Mike Green · 2010-02-05 03:16

Bean,
The Spin compiler doesn't know where it's going to put the DAT section until after the code is compiled, so you either have to modify _LMM_CALL and _LMM_JUMP to use relative addresses or to add an offset that's set during the LMM initialization from the address of the start of the DAT section and all the jump and call addresses in the DAT section are relative to this offset. Homespun has another operator (@@@) that allows you to put absolute addresses into compiled constants, but the Propeller Tool doesn't have this and I'm not sure if BST has it.

VIRAND · 2010-02-05 23:21

I have been stumped by this many times and tend to recall using STACK as a relative reference.
$10 does seem to be the most likely error offset for DAT variables when I finally get SPIN to locate them directly.
I should look at the programs that use $10 to see if I ever found a rarely encountered fix.
An unelegant idea recently is to invent an unlikely LONG and search for it at the beginning of the spin.

PUB  start_main_spin  '***untested idea***
  PDAT:=0
  repeat until long[noparse][[/noparse]PDAT]==$D15C07EC"
    PDAT:=PDAT+1
' now do something with BYTE[noparse][[/noparse]PDAT+something]    
DAT
PDAT long $D15C07EC"    'true address of DAT to search for

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I should be typing in Spin now.

Fred Hawkins · 2010-02-06 15:32

That $10 offset is to skip over the hub's initialization information used by the Loader and Interpreter. See page 31 of the manual.
So I figure the Loader actually subtracts $10 from every one of these address values when a program is put into a cog. It does seem a bit of a kludge to force asembly writers to add an offset that will get removed when the code is actually used·compiled*. We're probably stuck with that choice, which might not be a dimbulb moment. Perhaps Chip will explain.

By the way, is there a reference table to those initialization values? Page 31 just explains the first two. Answer: never mind. See http://propeller.wikispaces.com/Hub+Memory+Map

* I think the IDE's compiler forces these offsets.

Post Edited (Fred Hawkins) : 2/6/2010 4:24:36 PM GMT

heater · 2010-02-06 15:55

Quite normal, and annoying. Seems the @operator does different things depending on what section the target is in and possibly where you are using it. To be honest I've never managed to remember how it works in each case.

Ariba or someone pointed out that if you don't like to have the magic number $10 in your code and are worried it may be different in different cases then the base offset can be got using @[noparse][[/noparse]0]. If I remember correctly.

I can't for the life of me understand how or why @[noparse][[/noparse]0] should work.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

BradC · 2010-02-06 17:14

heater said...
I can't for the life of me understand how or why @[noparse][[/noparse]0] should work.

It forces the spin interpreter to give the hub address of byte 0 of the object.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.

Is it normal to have to at $10 to labels when using LMM ?

Comments