[erledigt] Ich "blick" die Propeller Speicherbelegung nicht

[DJLinux]

Ich versuche eine Speichermap zu simulieren die das komplette HUBRAM belegt den Spin Interpreter Cog beendet und 8 Cogs mit $1F0 longs belegt.

Eigentlich dürfte Spin das garnicht kompelieren dar 32K + 8*COGRAM nicht in 32K passen kann.

Entweder ist das ein BUG oder ich verstehe nicht wie man für 8 Cogs den Code in einer Quelldatei packt.

Warum läst sich dieser Code ohne Fehlermeldung kompelieren?

Danke und Grüsse

Joshy

Code: Alles auswählen

CON
  _CLKMODE = XTAL1 + PLL16X
  _XINFREQ = 5_000_000
  _STACK   = 0

HEADER   =  16
SPINCODE = 103
RESERVED = HEADER  + SPINCODE
HUBSIZE  = 1024*32 - RESERVED

VAR
   Byte HUBRAM[HUBSIZE-1] ' <32K bytes
      
PUB Main
   CogNew(@AIOS_Entry,@HUBRAM)
   CogStop(CogID)   
   
DAT             ORG  0
AIOS_Entry      waitcnt delay,0         ' wait ~one second to kill SPIN
                mov     outa,_OUT_INIT  ' /SDCS and LED high
                mov     dira,_DIR_INIT
                coginit @dummy2
                coginit @dummy3
                coginit @dummy4
                coginit @dummy5
                coginit @dummy6
                coginit @dummy7
                coginit @dummy8
dummy1          jmp dummy1                     
                 
' I/O port init
_DIR_Init       long %01_01_11110_0000_01011_1011_11_00000000
_OUT_Init       long %00_00_00010_0000_00000_0001_00_00000000
delay           long 80_000_000
                res $1EF-13 ' why -13 there are only 10 PASM instructions 
                FIT 496
                
DAT             ORG  0
dummy2          jmp dummy2
COG2            Res $1EF '$1F0 - 1 x jmp
                FIT 496
                
DAT             ORG 0
dummy3          jmp dummy3
COG3            Res $1EF '$1F0 - 1 x jmp
                FIT 496
                
DAT             ORG 0
dummy4          jmp dummy4
COG4            Res $1EF '$1F0 - 1 x jmp
                FIT 496
                
DAT             ORG  0
dummy5          jmp dummy5
COG5            Res $1EF '$1F0 - 1 x jmp
                FIT 496
                
DAT             ORG
dummy6          jmp dummy6
COG6            Res $1EF '$1F0 - 1 x jmp
                FIT 496
                
DAT             ORG 0
dummy7          jmp dummy7
COG7            Res $1EF '$1F0 - 1 x jmp
                FIT 496
                
DAT             ORG 0
dummy8          jmp dummy8
COG8            Res $1EF '$1F0 - 1 x jmp
                FIT 496

[drohne235]

Ich glaube es liegt an der RES-Direktive. Sie belegt den Speicher im HubRAM nicht, sondern wirkt quasi nur "virtuell" beim Assemblieren, indem sie einen internen Compilerzeiger beeinflusst.

"The RES (reserve) directive effectively reserves one or more longs of Cog RAM by incrementing the compile-time assembly pointer by Count."

Das ist ein wenig verwirrend. Wenn man folgendes macht

Code: Alles auswählen

...
SPINCODE = 107
...

DAT             ORG  0
dummy2          jmp dummy2
COG2            Res $1EB '$1F0 - 2 x jmp
dummy2x         jmp dummy2
                FIT 496

...dann wird durch die Assemblerroutine statt 4 halt 8 Byte belegt. Also wird der RES-Bereich immer HINTEN angehängt, er gefindet sich in dem Beispiel nicht zwischen den jmp-Befehlen. Letztlich wird wohl assembliert, und beim Laden der Cogs werden die fehlenden Longs aufgefüllt, ohne das sie real im HubRAM abgebildet werden. Denk ich...

Edit: Einen Sinn macht die RES-Anweisung - man kann ohne HubRAM zu belegen Speicher reservieren, kann aber letztlich trotzdem mit FIT prüfen ob alles noch schön in den CogRAM passt.

[DJLinux]

"Jo man"
RES zählt den virtuellen PC hoch ohne wirklich Speicher zu belegen das macht Sinn.
War wohl doch noch zu früh am Morgen und ein par Synapsen waren noch anderwertig beschäftigt.

Grüsse und Danke

Joshy