There is currently no language definition of Spin2 that I know of.
The current implementation of Spin for the P2 (FastSpin) is mostly a native code compiler for the P1 version of Spin targeting the P2 instruction set.
We don't really know yet what ideas Chip has for his Spin2.
I thought that already had moved (somewhat?) along the Spin2 features path, that Chip has mentioned before ?
Sure, not a formal language definition, but certainly new features ?
It also seems sensible to track a P1 Spin improvement, even if that needs a not-from-ROM load step ?
Yes there have been ideas floated but I'm not sure we know yet what Chip has in mind. He has expressed interest in some of the suggestions but we won't know what Spin2 is really going to be like until he starts building it.
p2asm also has a mode where it generates a relocatable object file. In that mode it also supports a small number of GAS pseudo-ops. Since these pseudo-ops start with a "." character I had to disable the use of local labels in this mode.
Can an alternative means be used for local labels, that is compatible with GAS ?
It seems avoiding direct conflicts with GAS is a smarter thing to be doing ?
p2asm supports all of the opcodes that are supported by the PNut assembler. Anytime I update p2asm I test it against a suite of assembly programs to ensure that it produces exactly the same binary output that PNut produces. I am aware of an issue with supporting extended pointer ranges using the ## operator, which I haven't fixed yet. Once I fix that problem I will add another program to the test suite to ensure that this works just like PNut.
So that means PNut (x86 asm?) can be retired ?
I could add an option to p2asm to allow the use of the ":" character for local labels. Or I could allow "." for local labels as long as they don't conflict with GAS pseudo-ops, but there's also the problem that the C compiler generates labels that are prefixed by ".".
At the time when Chip changed the local label character from ":" to "." I expressed concern that this would conflict with C. However, my concerns didn't seem to make much of an impact. Maybe it's not too late to change back to using ":".
As far as retiring PNut, eventually it will include Spin2. It will be a while before OpenSpin can catch up to PNut. Once that happens, then PNut can be retired.
As far as retiring PNut, eventually it will include Spin2. It will be a while before OpenSpin can catch up to PNut. Once that happens, then PNut can be retired.
Maybe although the current OpenSpin hasn't yet replaced the x86 version of Spin1. Parallax has never modified the Propeller Tool to use it and it's really the only currently supported IDE for Spin/PASM.
I could add an option to p2asm to allow the use of the ":" character for local labels. Or I could allow "." for local labels as long as they don't conflict with GAS pseudo-ops, but there's also the problem that the C compiler generates labels that are prefixed by ".".
At the time when Chip changed the local label character from ":" to "." I expressed concern that this would conflict with C. However, my concerns didn't seem to make much of an impact. Maybe it's not too late to change back to using ":".
Google finds other Assemblers allow user define of a local prefix - maybe that's another solution ?
LOCALS enables TASM to generate local symbols (see LOCAL). LOCAL
symbols usually begin with @@, but by substituting another string
for prefix, you can use any prefix you want.
and I also find $LOCALPREFIX "__"
and within MACROs there is mSpi_Slow MACRO mSCK, mMOSI, mMISO
LOCAL _SpiSlowE, _SpiSlowL
_SpiSlowE:
I agree with Brian. Keep it simple and gitterdone.
But I also think that C++ is absolutely required. I personally can't do C++, it's a religious thing... But it does seems that almost all of the Python wrappers are written in C++.
At the hacker level I looked at trying to add a serial port to a mostly nice piece of source code.. in C++. It didn't happen. Days of looking, pecking on my laptop and nothing. Just the development environment to get everything set up is a nightmare... unless you use it all of the time, which I don't.
Python on the other hand is pure fun. Google: Python serial port. pip install the module and you are on your way... hours of effort, not days, weeks and months... and Python talks serial almost as good as the P2. I did this so that the P2 could tell Python what it was doing and accept suggestion.
SO... a Python wrapper that would let me use Spin2 to program the P2 sounds entirely wonderful.
If you tell a room full of people..."AND it can be programmed in C++," you will get mostly a look of "....and?" Tell the same room that you can program the P2 using Python 2.7 and they will buy one for all of their kids' kids. There are a lot of grandkids out there.
Brian was also right about COMMAND LINE CONTROL. We have to have it.
If we don't get it, I will personally shoot myself in the foot.
I agree with Brian. Keep it simple and gitterdone.
But I also think that C++ is absolutely required. I personally can't do C++, it's a religious thing... But it does seems that almost all of the Python wrappers are written in C++.
At the hacker level I looked at trying to add a serial port to a mostly nice piece of source code.. in C++. It didn't happen. Days of looking, pecking on my laptop and nothing. Just the development environment to get everything set up is a nightmare... unless you use it all of the time, which I don't.
Python on the other hand is pure fun. Google: Python serial port. pip install the module and you are on your way... hours of effort, not days, weeks and months... and Python talks serial almost as good as the P2. I did this so that the P2 could tell Python what it was doing and accept suggestion.
SO... a Python wrapper that would let me use Spin2 to program the P2 sounds entirely wonderful.
If you tell a room full of people..."AND it can be programmed in C++," you will get mostly a look of "....and?" Tell the same room that you can program the P2 using Python 2.7 and they will buy one for all of their kids' kids. There are a lot of grandkids out there.
Brian was also right about COMMAND LINE CONTROL. We have to have it.
If we don't get it, I will personally shoot myself in the foot.
I see. So C++ is only needed on the P2 so we can run Python?
Of course, there are actual programmers out there... C++ all day, every day.
EDU: For computer scientists you have C++. For everyone else, Python would be a hit and a major market maker.
I personally think Spin is about it when it comes to user friendliness. If anyone asked me, I'd say do it in Spin and PASM. No development environment to deal with... you can put your files anywhere you want. You don't have to upgrade it. No class paths... on and on and on.
You would have to be an idiot to want to do it any other way... unless you already have your work environment all set up and it is easier to do it that way. In that case... C++ is the big dog, why fight it?
AMD is raising the bar on embedded solutions again... They now have their 12nm cpu's working at low wattages ... you can get 4 2GHz cores on a board the size of a P1 Board of Education, with tons of RAM, built in graphics and a couple of 10GHz USB 3.1.
I've never used Python but I'm guessing rjo is meaning performance code will get written in C++ which then is called from a Python stub. Much of said C++ is likely plain C, as a guess.
Not unlike what I've been doing with the random number testing except I'm using Bash and C instead.
I should say that I can do everything I want in Python without a Python wrapper, but my experience of Python has been so positive, I thought I would throw my two cents in from a typical user point of view. I have also been slowly adding Spin2 comands to NotePad++, so that the editing process for PNUT is easier and more fun. Add some command line control to PNUT and it is ready to go... as far as I'm concerned.
I should say that I can do everything I want in Python without a Python wrapper, but my experience of Python has been so positive, I thought I would throw my two cents in from a typical user point of view. I have also been slowly adding Spin2 comands to NotePad++, so that the editing process for PNUT is easier and more fun. Add some command line control to PNUT and it is ready to go... as far as I'm concerned.
Yes, but here you are talking about Python on the PC/Host side, and Spin2/Pasm2 on the P2 Side - not Python on the P2 ?
To make that flow easier, it may be possible to have something along the lines of 'a python-like assembler', but I'm still digging for real usable examples of something there...
eg this one is in Embedded space, targets Xilinx Picoblaze, ( and has some nice P1V -useful utilities) and claims to be quite fast compared with other PicoBlaze offerings. https://github.com/kevinpt/opbasm
but their .psm4 example files are not assembler I'm use to looking at..
That is correct, it is just serial communications between a compiled P2 program and Python over serial...and it ends up looking rather Rube Goldberg-esk.
Python reminds me a great deal of Spin... indentation counts.
If you removed the line endings of a Spin program and told someone that it was Python... they would probably believe that it came from an imported module and looked fine.
With your permission... I'm going to use words that I have read... but don't fully understand:)
What ends up happening is an "API," such as opencv, written entirely in C++ is given a python wrapper... sort of a translator between Python and the API. The final execution is actually in C++. I have no idea how this happens, magic I think. Somehow the wrapper makes it's way into a "module" and presto you are there.
For this incarnation the "module" would sort of "pre-assemble" a file by transliterating the Python file into Spin2.txt and send it along to PNUT through the command line.
In my imagination, I see PNUT in a headless mode waiting to receive the command line prompt to open, compile, and load to ram... do what it does... and put any error messages into a convenient place where Python waits for it and then imports it.
This sounds like cheating, but I think that is all that is necessary.... and finding someone who can actually do it:)
I looked at the link... that's the idea, but getting there....hmmm.
For this incarnation the "module" would sort of "pre-assemble" a file by transliterating the Python file into Spin2.txt and send it along to PNUT through the command line.
I found some PDFs around the Assembler morphed toward Python approach, you may find useful to read ?
and that may have morphed by more that most Assembler Programmers would be used to. - but macros and conditionals are managed as native Python.
The Prop Assembler usage of prefix and suffix field does not mesh too well here, either.
All the .lasm files in the directory are assembled and then linked into an executable image (the entry point for the user's code is the global asm_main symbol which must be defined by one of the source files).
This image is loaded into the simulator and the simulator is started
The simulator stops running when a HALT instruction has been encountered.
At this point, the _test.py file is loaded and all the functions starting with test_ in it are executed. All are expected to return True. If some function returns False, it's an error in the full test.
run_full_tests.py: Runs all the full tests
and running that gives me
Test .\exception_simple...OK
Test .\link_files...OK
Test .\loop_simple...OK
Test .\loop_simple_debugqueue...OK
Test .\prime_sieve...OK
Test .\procedure_call_stack_convention...OK
Test .\single_file_simple...OK
Test .\stack_manip...OK
However, trying to manually compile .\link_files, coughs with linker errors, so some params are missing ?
The ability to AsmLink and then run a simulate pass, and verify against a _test.py is looking quite powerful.
Python reminds me a great deal of Spin... indentation counts.
Yes they both use indentation for block delimiting but it's hard to imagine two languages that are more different than Python and Spin.
That syntactic similarity is about all they have in common.
It's like saying that a Concorde reminds one of a paper aeroplane. Well, yeah, they are white and delta shaped and fly in some way.
I'm rather depressed at the clamoring for Python on the Propeller 2. It's not even a standardized language. Performance is terrible. That white space block delimiting is horrendous.
I'd love to see Javascript for the Propeller. At least that has a language standard. JS handles the events one gets in embedded systems much better. But I don't think I have the chops to get the Espruino JS engine running on the Prop.
Anyway, all of this is dependent on having a C++ compiler for the P2 to build them with.
Python is really far too huge for the P2 (or most MCUs really, the RPi is NOT an MCU really). MicroPython is the best you could hope for, and even then it would perform like Smile.
I'm with Heater, let's stick to languages that have a standard definition. I think this is the order we'll see things: Forth (in the rom), Spin (already via fastspin), Spin2, C/C++, PropBASIC. Then people can dive into other things.
Parallax wants C/C++ asap to support customer demand, and blocklyprop (since they have gone all in on that (which is good imho)).
Wow!
It seems we have run off the rails here people.
I suggested an open source Python tool chain and/or Pnut with command line support.
Now we have the old language war again.
Dissapointing.
BTW. My language of choice for the P2 is SPIN2 even though we don't know anything about it yet.
Can GCC make C code that runs in hubexec mode?
Seems like that would be the fastest way...
GCC does not know how to generate P2 code at all at present. However, Dave Hein has a program that takes the output of the P1 GCC compiler and translates it to run on P2.
Rayman, check out the "Can't Wait for PropGCC on the P2?" thread. It contains a suite of tools that are used to compile a C program into a P2 binary. The code runs in the hubexec mode except for a few routines that are in cog memory. The P1 GCC compiler is used in the cog mode to generate P1 assembly. This is then converted in to p2 assembly, and assembled by p2asm to produce an object file. The object files are linked with library files to produce a P2 binary file. The whole process is automated with a script file named p2gcc.
But rather than making an exception in the syntax, you could just issue a warning for JMPs lacking the #.
I'd expand the warning to include constants:
label add itemcnt, 1 ' Issue compiler warning; I probably meant #1 rather than the indirect cog location 1 reference
pragmas would be nice for this also (I apologize for the poor example):
pragma constantwarning off ' Turn off warning
label add itemcnt, 1 ' I really do want to use cog location 1 for the addition
pragma constantwarning on ' Restore warning
I suggested an open source Python tool chain and/or Pnut with command line support.
Yes, so I went looking for examples of Python-coded Assemblers, as you ( & others) suggested.
That Python-hosting-Assembler discussion could be moved into another thread ?
Wow!
It seems we have run off the rails here people.
Getting back to the heading of "Assembler mnemonics and syntax", so far I think we have suggestions of
* Change COG to CORE etc, HUB to ?? to 'mainstream' the P2 semantics.
* Improve the labels and immediate usage to reduce user errors
* Reduce conflicts with C/GAS
* macros and conditional assembly (already in some offerings?)
Maybe a simple table of existing P2 Assembler paths/tools, and what they support, and their source urls, would help ?
I suggested an open source Python tool chain and/or Pnut with command line support.
Yes, so I went looking for examples of Python-coded Assemblers, as you ( & others) suggested.
That Python-hosting-Assembler discussion could be moved into another thread ?
Wow!
It seems we have run off the rails here people.
Getting back to the heading of "Assembler mnemonics and syntax", so far I think we have suggestions of
* Change COG to CORE etc, HUB to ?? to 'mainstream' the P2 semantics.
* Improve the labels and immediate usage to reduce user errors
* Reduce conflicts with C/GAS
* macros and conditional assembly (already in some offerings?)
Maybe a simple table of existing P2 Assembler paths/tools, and what they support, and their source urls, would help ?
AFAIK what Parallax calls HUB has generally been referred to as SHARED MEMORY or SHARED RAM on computers with more than one CPU. While I have no problem with the current COG/HUB nomenclature, using CORE/SHARED RAM would probably mean more to someone who is not familiar with the Prop.
I suggested an open source Python tool chain and/or Pnut with command line support.
Yes, so I went looking for examples of Python-coded Assemblers, as you ( & others) suggested.
That Python-hosting-Assembler discussion could be moved into another thread ?
Wow!
It seems we have run off the rails here people.
Getting back to the heading of "Assembler mnemonics and syntax", so far I think we have suggestions of
* Change COG to CORE etc, HUB to ?? to 'mainstream' the P2 semantics.
* Improve the labels and immediate usage to reduce user errors
* Reduce conflicts with C/GAS
* macros and conditional assembly (already in some offerings?)
Maybe a simple table of existing P2 Assembler paths/tools, and what they support, and their source urls, would help ?
AFAIK what Parallax calls HUB has generally been referred to as SHARED MEMORY or SHARED RAM on computers with more than one CPU. While I have no problem with the current COG/HUB nomenclature, using CORE/SHARED RAM would probably mean more to someone who is not familiar with the Prop.
But there is more to the hub than just shared RAM.
But there is more to the hub than just shared RAM.
What do you mean ? HUB is 512K Bytes of SRAM, accessible by all COGs, so Shared RAM seems to be quite a good banner description ?
All shared RAM has rules, so those details can come later. The Streamer also shares the RAM, as do the FIFOs, but none of that conflicts with the 'Shared RAM' banner ?
Comments
At the time when Chip changed the local label character from ":" to "." I expressed concern that this would conflict with C. However, my concerns didn't seem to make much of an impact. Maybe it's not too late to change back to using ":".
As far as retiring PNut, eventually it will include Spin2. It will be a while before OpenSpin can catch up to PNut. Once that happens, then PNut can be retired.
Google finds other Assemblers allow user define of a local prefix - maybe that's another solution ?
http://www.ousob.com/ng/masm/ng54fa6.php
LOCALS [prefix]
LOCALS enables TASM to generate local symbols (see LOCAL). LOCAL
symbols usually begin with @@, but by substituting another string
for prefix, you can use any prefix you want.
and I also find
$LOCALPREFIX "__"
and within MACROs there is
mSpi_Slow MACRO mSCK, mMOSI, mMISO
LOCAL _SpiSlowE, _SpiSlowL
_SpiSlowE:
But I also think that C++ is absolutely required. I personally can't do C++, it's a religious thing... But it does seems that almost all of the Python wrappers are written in C++.
At the hacker level I looked at trying to add a serial port to a mostly nice piece of source code.. in C++. It didn't happen. Days of looking, pecking on my laptop and nothing. Just the development environment to get everything set up is a nightmare... unless you use it all of the time, which I don't.
Python on the other hand is pure fun. Google: Python serial port. pip install the module and you are on your way... hours of effort, not days, weeks and months... and Python talks serial almost as good as the P2. I did this so that the P2 could tell Python what it was doing and accept suggestion.
SO... a Python wrapper that would let me use Spin2 to program the P2 sounds entirely wonderful.
If you tell a room full of people..."AND it can be programmed in C++," you will get mostly a look of "....and?" Tell the same room that you can program the P2 using Python 2.7 and they will buy one for all of their kids' kids. There are a lot of grandkids out there.
Brian was also right about COMMAND LINE CONTROL. We have to have it.
If we don't get it, I will personally shoot myself in the foot.
Of course, there are actual programmers out there... C++ all day, every day.
EDU: For computer scientists you have C++. For everyone else, Python would be a hit and a major market maker.
I personally think Spin is about it when it comes to user friendliness. If anyone asked me, I'd say do it in Spin and PASM. No development environment to deal with... you can put your files anywhere you want. You don't have to upgrade it. No class paths... on and on and on.
You would have to be an idiot to want to do it any other way... unless you already have your work environment all set up and it is easier to do it that way. In that case... C++ is the big dog, why fight it?
AMD is raising the bar on embedded solutions again... They now have their 12nm cpu's working at low wattages ... you can get 4 2GHz cores on a board the size of a P1 Board of Education, with tons of RAM, built in graphics and a couple of 10GHz USB 3.1.
Put a P2 on that... really. Put a P2 on that.
Not unlike what I've been doing with the random number testing except I'm using Bash and C instead.
Yes, but here you are talking about Python on the PC/Host side, and Spin2/Pasm2 on the P2 Side - not Python on the P2 ?
To make that flow easier, it may be possible to have something along the lines of 'a python-like assembler', but I'm still digging for real usable examples of something there...
eg this one is in Embedded space, targets Xilinx Picoblaze, ( and has some nice P1V -useful utilities) and claims to be quite fast compared with other PicoBlaze offerings.
https://github.com/kevinpt/opbasm
but their .psm4 example files are not assembler I'm use to looking at..
Python reminds me a great deal of Spin... indentation counts.
If you removed the line endings of a Spin program and told someone that it was Python... they would probably believe that it came from an imported module and looked fine.
With your permission... I'm going to use words that I have read... but don't fully understand:)
What ends up happening is an "API," such as opencv, written entirely in C++ is given a python wrapper... sort of a translator between Python and the API. The final execution is actually in C++. I have no idea how this happens, magic I think. Somehow the wrapper makes it's way into a "module" and presto you are there.
For this incarnation the "module" would sort of "pre-assemble" a file by transliterating the Python file into Spin2.txt and send it along to PNUT through the command line.
In my imagination, I see PNUT in a headless mode waiting to receive the command line prompt to open, compile, and load to ram... do what it does... and put any error messages into a convenient place where Python waits for it and then imports it.
This sounds like cheating, but I think that is all that is necessary.... and finding someone who can actually do it:)
I looked at the link... that's the idea, but getting there....hmmm.
I found some PDFs around the Assembler morphed toward Python approach, you may find useful to read ?
A simpler overview
http://osdc.org.il/2006/html/rapid_development_of_an_assembler_using_python.pdf
PeachPy I linked earlier has this DOC
https://www.dlr.de/sc/Portaldata/15/Resources/dokumente/PyHPC2013/submissions/pyhpc2013_submission_10.pdf
The Starting Source code, let's call it Py-Assembler, looks like this
# First pdf MEM1 = 0x200 add(r0, r2, r3) sub(r2, r4, r4) load(r2, MEM1) label('L1') move(r2, r7) jmp(L1) # PeachPy pdf LABEL( "next_batch" ) xmm_x = SSERegister() VMOVDQU( xmm_x, [xPtr] ) for ptr in [xPtr, yPtr, zPtr]: ADD( ptr, 16 ) SUB( length, 16 / data_size ) JNZ( "next_batch" )and also this example
http://codeflow.org/entries/2009/jul/31/pyasm-python-x86-assembler/
and that may have morphed by more that most Assembler Programmers would be used to. - but macros and conditionals are managed as native Python.
The Prop Assembler usage of prefix and suffix field does not mesh too well here, either.
A little more digging finds what is a more classic Asm/Link/Load/Simu
https://github.com/eliben/luz-cpu
and this https://github.com/eliben/luz-cpu/blob/master/luz_asm_sim/tests_full/README.rst
says
To run a full test:
All the .lasm files in the directory are assembled and then linked into an executable image (the entry point for the user's code is the global asm_main symbol which must be defined by one of the source files).
This image is loaded into the simulator and the simulator is started
The simulator stops running when a HALT instruction has been encountered.
At this point, the _test.py file is loaded and all the functions starting with test_ in it are executed. All are expected to return True. If some function returns False, it's an error in the full test.
run_full_tests.py: Runs all the full tests
and running that gives me However, trying to manually compile .\link_files, coughs with linker errors, so some params are missing ?
The ability to AsmLink and then run a simulate pass, and verify against a _test.py is looking quite powerful.
That syntactic similarity is about all they have in common.
It's like saying that a Concorde reminds one of a paper aeroplane. Well, yeah, they are white and delta shaped and fly in some way.
I'm rather depressed at the clamoring for Python on the Propeller 2. It's not even a standardized language. Performance is terrible. That white space block delimiting is horrendous.
I guess if it's going to happen it will happen by way of some brave soul porting MicroPython to the Propeller: http://docs.micropython.org/en/latest/pyboard/reference/index.html
I'd love to see Javascript for the Propeller. At least that has a language standard. JS handles the events one gets in embedded systems much better. But I don't think I have the chops to get the Espruino JS engine running on the Prop.
Anyway, all of this is dependent on having a C++ compiler for the P2 to build them with.
I'm with Heater, let's stick to languages that have a standard definition. I think this is the order we'll see things: Forth (in the rom), Spin (already via fastspin), Spin2, C/C++, PropBASIC. Then people can dive into other things.
Parallax wants C/C++ asap to support customer demand, and blocklyprop (since they have gone all in on that (which is good imho)).
It seems we have run off the rails here people.
I suggested an open source Python tool chain and/or Pnut with command line support.
Now we have the old language war again.
Dissapointing.
BTW. My language of choice for the P2 is SPIN2 even though we don't know anything about it yet.
Seems like that would be the fastest way...
I assume that would be through hubexec…
I think people were waiting (was it you?) until the instruction set was finalized and I think it is now...
I'd expand the warning to include constants: pragmas would be nice for this also (I apologize for the poor example):
Walter
That Python-hosting-Assembler discussion could be moved into another thread ?
Getting back to the heading of "Assembler mnemonics and syntax", so far I think we have suggestions of
* Change COG to CORE etc, HUB to ?? to 'mainstream' the P2 semantics.
* Improve the labels and immediate usage to reduce user errors
* Reduce conflicts with C/GAS
* macros and conditional assembly (already in some offerings?)
Maybe a simple table of existing P2 Assembler paths/tools, and what they support, and their source urls, would help ?
AFAIK what Parallax calls HUB has generally been referred to as SHARED MEMORY or SHARED RAM on computers with more than one CPU. While I have no problem with the current COG/HUB nomenclature, using CORE/SHARED RAM would probably mean more to someone who is not familiar with the Prop.
All shared RAM has rules, so those details can come later. The Streamer also shares the RAM, as do the FIFOs, but none of that conflicts with the 'Shared RAM' banner ?