FlexProp: Inline PASM doesn't like 'rdlong Var, #@clkfreq', is this expected?
Francis Bauer
Posts: 383
in Propeller 2
The following simplified example code works fine in PNUT and Prop_Tool, but FlexProp complains about hub memory access from within Inline PASM, but does work in a PASM cog. I assume that this is expected, but I haven't found any mention about this limitation.
con { timing }
CLK_FREQ = 200_000_000 ' system freq as a constant
_clkfreq = CLK_FREQ ' set system clock
pub main() | cog
ipasm() ' start inline PASM
cog := coginit(cogexec_new,@pasm,0) ' start PASM cog
waitms(5)
cogstop(cog) ' stop PASM cog
debug("main() finished")
pub ipasm | freq
debug("Debug start: ipasm()")
freq := clkfreq
debug("Spin Clock Freq: ",udec_long_(freq))
org
rdlong pr2, #@clkfreq ' get current clock frequency of cog
'mov pr2, freq
debug("PASM Clock Freq: ", udec_long_(pr2))
end
debug("Debug end: ipasm()")
dat
org
pasm debug("Debug start: pasm()")
rdlong cfreq, #@clkfreq
debug("PASM Clock Freq: ", udec_long_(cfreq))
ret
cfreq long 0
When I do a 'Compile & Run' I get the following error:
"C:/flexprop-6.9.10/bin/flexspin" -2 -l --tabs=8 -D_BAUD=230400 -O1 -gbrk --charset=utf8 -I "C:/flexprop-6.6.2/include" "C:/Experiments/ClkFreq.spin2" Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2024 Total Spectrum Software Inc. and contributors Version 6.9.10 Compiled on: Jun 19 2024 ClkFreq.spin2 C:/Experiments/ClkFreq.spin2:20: error: Variable __clkfreq_var is placed in hub memory and hence cannot be accessed in inline assembly C:/Experiments/ClkFreq.spin2:20: warning: Using # on registers in inline assembly may confuse the optimizer child process exited abnormally Finished at Tue Nov 5 18:48:53 2024

Comments
That probably should get fixed in Flexspin. What I've done in the past is store a copy of its address.
eg:
dat org pasm debug("Debug start: pasm()") rdlong pa, clkfrqadr debug("PASM Clock Freq: ", udec_long_(pa)) ret clkfrqadr long @clkfreqIsn’t clkfreq actually $14 or something?
Maybe just use that?
Think the general rule is that all variables have to be local…
Bad idea. The symbol's address is not agreed upon ... and could even be shifted in the future.
PS: Chip did at one point agree to change Pnut/Proptool to use address $14 but it never happened.