The forth system Taqoz Reloaded includes a PASM2 assembler. This can either be:-
1. Compiled as part of the system and the whole stored on flash or sdcard
2. Stored on sdcard as source code and compiled when needed
Haven't seen the like for any other programming languages
Sadly, mentioning forth makes most programmers groan, so you may be out of luck. I like forth, but agree it isn't a panacea. I also use Spin2 with assembler.
Cheers, Bob, SW U.K.
It looks the FORTH programmers are lonely wolfs. But wolfs team up to chase successfully. Peter laid the foundations and went away in frustration, as he also has to fill the fridge. I personally wrote only a few lines of code and struggled with a bug in P1 Forth, so I missed the timeline. But I'm willing to step by step go forward, as the propeller allows to run TAQOZ in parallel with other software, if only a unified interface exists.
The unified interface I also miss in SPIN and ASM applications for both P1 and P2. I make use of it for years, now moving my app to the P2 I'll improve it.
We talk to much about the HOW and not about WHY. Switching over to FORTH would enable us to use 8th to build a uniform controller/PC solution, which the world is asking for.
@bob_g4bby said:
The forth system Taqoz Reloaded includes a PASM2 assembler. This can either be:-
1. Compiled as part of the system and the whole stored on flash or sdcard
2. Stored on sdcard as source code and compiled when needed
Haven't seen the like for any other programming languages
Sadly, mentioning forth makes most programmers groan, so you may be out of luck. I like forth, but agree it isn't a panacea. I also use Spin2 with assembler.
Cheers, Bob, SW U.K.
Perhaps we should mention, that the assembler included in Taqoz does accept input, which is quite normal. Not like Forth assemblers used to be.
Catalina includes Dave Hein's p2asm assembler. It compiles and runs fine from SD on the P2. It is really quite independent of Catalina, but it does require a suitable P2 development environment (Catalina uses Catalyst) to be able to run it.
Wow, this is awesome. Thank you all so much. I'm taking a look at not just the assembler now but some of the other bits of Taqoz and Catalina's code. Just the code itself is a good learning tool. Do these assembler also allow for p2 assembly only files without the need of spin? Currently I am, using FlexProp for learning but was not sure if this was a feature central to FlexProp or not.
@proppy said:
Wow, this is awesome. Thank you all so much. I'm taking a look at not just the assembler now but some of the other bits of Taqoz and Catalina's code. Just the code itself is a good learning tool. Do these assembler also allow for p2 assembly only files without the need of spin? Currently I am, using FlexProp for learning but was not sure if this was a feature central to FlexProp or not.
P2asm is a pure assembler - it does not include support for or use any Spin. It outputs binary files that can be executed directly, but of course you need to do everything - including setting up your own clock etc.
For example, the Catalyst Reference Manual includes this example of a trivial PASM program that can be compiled and executed under Catalyst on the P2:
CON
LED_PIN = 38 ' Pin 38 is LED on the P2 EDGE
TIME = 180000000/2 ' 1/2 second @180 Mhz
DAT
org 0
Loop
drvnot #LED_PIN
waitx ##TIME ' Toggle pin every half second
jmp #Loop
This works, but it is actually too trivial - it assumes the clock frequency is 180Mhz, but it does not actually set it - so it will only toggle the LED every half a second if it is started from a version of Catalyst that is compiled at 180Mhz (because when loaded from Catalyst it inherits the Catalyst clock frequency). If your version of Catalyst is compiled for a different frequency, the rate the LED blinks will change accordingly. And if you instead compile the program on your PC and load it serially, the clock will be set at the default (RCFAST) and the LED will blink much more slowly (about once every 10 seconds).
I really should add clock setting code to the example.
Pnut introduced a special case macro called ASMCLK fairly early on for this, but after p2asm was written.
From the Spin2 Google Doc:
ASMCLK will assemble to one or six PASM instructions, depending upon the clock mode.
Depends on the user CON settings. The one-instruction variant will be a HUBSET for either _rcfast or _rcslow.
The six-instruction variant is for external clock source, presumably with the PLL engaged, ie using _xtlfreq, _xinfreq, _clkfreq, will be the following (Note: Each instruction has a prefixing instruction to make six in total):
HUBSET ##clkmode_ & !3 'start crystal/PLL, stay in RCFAST
WAITX ##20_000_000/100 'wait 10ms
HUBSET ##clkmode_ 'switch to crystal/PLL
@evanh said:
Pnut introduced a special case macro called ASMCLK fairly early on for this, but after p2asm was written.
Thanks, I'll take a look. I've not used Pnut or Spin2 since I adopted p2asm. It is probably time I checked that Catalina still uses the same symbol names and low Hub RAM locations.
Nobody else uses the same absolute addresses as Pnut. There was a drawn out discussion at one stage where Chip eventually agreed to follow what had been established by others ... but he then forgot about it.
User software shouldn't care anyway. The symbol names of the system variables are well documented, so compilers can place them where suitable and the user program is none the wiser.
PS: The system variables don't exist in pure pasm2 mode unless the user code explicitly does WRLONG to those symbols.
proppy
Posts: 18
Comments
The forth system Taqoz Reloaded includes a PASM2 assembler. This can either be:-
1. Compiled as part of the system and the whole stored on flash or sdcard
2. Stored on sdcard as source code and compiled when needed
Haven't seen the like for any other programming languages
Sadly, mentioning forth makes most programmers groan, so you may be out of luck. I like forth, but agree it isn't a panacea. I also use Spin2 with assembler.
Cheers, Bob, SW U.K.
It looks the FORTH programmers are lonely wolfs. But wolfs team up to chase successfully. Peter laid the foundations and went away in frustration, as he also has to fill the fridge. I personally wrote only a few lines of code and struggled with a bug in P1 Forth, so I missed the timeline. But I'm willing to step by step go forward, as the propeller allows to run TAQOZ in parallel with other software, if only a unified interface exists.
The unified interface I also miss in SPIN and ASM applications for both P1 and P2. I make use of it for years, now moving my app to the P2 I'll improve it.
We talk to much about the HOW and not about WHY. Switching over to FORTH would enable us to use 8th to build a uniform controller/PC solution, which the world is asking for.
Perhaps we should mention, that the assembler included in Taqoz does accept input, which is quite normal. Not like Forth assemblers used to be.
Catalina includes Dave Hein's p2asm assembler. It compiles and runs fine from SD on the P2. It is really quite independent of Catalina, but it does require a suitable P2 development environment (Catalina uses Catalyst) to be able to run it.
Ross.
Wow, this is awesome. Thank you all so much. I'm taking a look at not just the assembler now but some of the other bits of Taqoz and Catalina's code. Just the code itself is a good learning tool. Do these assembler also allow for p2 assembly only files without the need of spin? Currently I am, using FlexProp for learning but was not sure if this was a feature central to FlexProp or not.
P2asm is a pure assembler - it does not include support for or use any Spin. It outputs binary files that can be executed directly, but of course you need to do everything - including setting up your own clock etc.
For example, the Catalyst Reference Manual includes this example of a trivial PASM program that can be compiled and executed under Catalyst on the P2:
CON LED_PIN = 38 ' Pin 38 is LED on the P2 EDGE TIME = 180000000/2 ' 1/2 second @180 Mhz DAT org 0 Loop drvnot #LED_PIN waitx ##TIME ' Toggle pin every half second jmp #LoopThis works, but it is actually too trivial - it assumes the clock frequency is 180Mhz, but it does not actually set it - so it will only toggle the LED every half a second if it is started from a version of Catalyst that is compiled at 180Mhz (because when loaded from Catalyst it inherits the Catalyst clock frequency). If your version of Catalyst is compiled for a different frequency, the rate the LED blinks will change accordingly. And if you instead compile the program on your PC and load it serially, the clock will be set at the default (RCFAST) and the LED will blink much more slowly (about once every 10 seconds).
I really should add clock setting code to the example.
Ross.
Pnut introduced a special case macro called ASMCLK fairly early on for this, but after p2asm was written.
From the Spin2 Google Doc:
Depends on the user CON settings. The one-instruction variant will be a HUBSET for either
_rcfastor_rcslow.The six-instruction variant is for external clock source, presumably with the PLL engaged, ie using
_xtlfreq, _xinfreq, _clkfreq, will be the following (Note: Each instruction has a prefixing instruction to make six in total):HUBSET ##clkmode_ & !3 'start crystal/PLL, stay in RCFAST WAITX ##20_000_000/100 'wait 10ms HUBSET ##clkmode_ 'switch to crystal/PLLThanks, I'll take a look. I've not used Pnut or Spin2 since I adopted p2asm. It is probably time I checked that Catalina still uses the same symbol names and low Hub RAM locations.
Ross.
Nobody else uses the same absolute addresses as Pnut. There was a drawn out discussion at one stage where Chip eventually agreed to follow what had been established by others ... but he then forgot about it.
User software shouldn't care anyway. The symbol names of the system variables are well documented, so compilers can place them where suitable and the user program is none the wiser.
PS: The system variables don't exist in pure pasm2 mode unless the user code explicitly does WRLONG to those symbols.