Forum Update - Announcement about May 10th, 2018 update and your password.

Assembler mnemonics and syntax

This discussion was created from comments split from: Possible P2 Logos.
«13

Comments

  • 84 Comments sorted by Date Added Votes
  • P2

    No appar
    jmg wrote: »
    David Betz wrote: »
    Maybe this is the time to start creating a library of peripheral implementations with consistent interfaces so they are available when the chip hits the market. It's all well and good to say you can make any peripheral you want with smart pins but customers shouldn't have to do that for standard interfaces like UART, SPI, I2C, etc. There should be off-the-shelf implementations of these standard peripherals at day one.

    Yes, libraries and examples are going to be needed.
    The examples should include minimal (hello world) type use, and maximal ( 'I can have HOW many UARTS ?!'), as the minimal ones show how easy it is to use one, and the maximal ones show just how many you could have.

    It is that second example, that will grab peoples attention.
    There seems to be no attention going into a clean up pass on opcodes and assembler, in this quiet time. Not sure what Chip is working on right now ?

    What kinds of improvements do you guys think are needed on assembler mnemonics and syntax?
  • I think Spin2 should have built in commands/functions for doing I2C and SPI and UART serial. I also think that whatever C/C++ effort should have from day one libs with easy to use includes for doing those standard protocols as well.
    Make it so that anyone just picking up the chip can start using standard ports to interface to things easily.

    I know you can include whatever objects you want to get those now on P1, but it should just be built in. The way things are on the P@ those protocols can all be included in the runtime as needed by the compiler. In fact, one Core(cog) can run Spin, do the serial, and/or I2C, and still be fine.

  • jmgjmg Posts: 11,778
    cgracey wrote: »
    What kinds of improvements do you guys think are needed on assembler mnemonics and syntax?

    Above I think there was mention of change COGINIT to COREINIT, (ie a COG to CORE sweep) for example, and in another thread for another Assembler there was mention of 'auto-promote' of immediates to 32b
    - all things designed to reduce the times any user has to reach for the manual...
    Is it worth standardising on a single assembler, on github ?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 21,990
    edited August 12 Vote Up0Vote Down
    I've gotten used to JMP #label, but it's still a source of programming bugs when the # is left off accidentally. But rather than making an exception in the syntax, you could just issue a warning for JMPs lacking the #. Better, perhaps, might be to change the syntax of indirect JMPs to JMPI and flag an actual error for things like JMP label without the #.

    Same applies to CALL and the generic JMPRET, obviously. Of course, this assumes that the jump commands mimic those of the P1. Maybe they don't; I haven't studied them.

    Otherwise, I wouldn't change a thing. But add macros if it fits your time budget.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Peter JakackiPeter Jakacki Posts: 7,577
    edited August 12 Vote Up0Vote Down
    Perhaps rather than laser etching we could have a real prop beanie on top of the chip and it could keep it cool at the same time while we overclock it as well :)

    Perhaps again the stickers
    I've gotten used to JMP #label, but it's still a source of programming bugs when the # is left off accidentally. But rather than making an exception in the syntax, you could just issue a warning for JMPs lacking the #. Better, perhaps, might be to change the syntax of indirect JMPs to JMPI and flag an actual error for things like JMP label without the #.

    Same applies to CALL and the generic JMPRET, obviously. Of course, this assumes that the jump commands mimic those of the P1. Maybe they don't; I haven't studied them.

    Otherwise, I wouldn't change a thing. But add macros if it fits your time budget.

    -Phil

    +1
    Macros are very handy indeed and make quite a bit of difference. It's the difference between programming with assembly language or programming in assembly language.
    Same with the jmp/call #label and while I do appreciate why it's done that way it would certainly help new ones to adapt if they could code "jmp label" rather than "jmp #label" and also "jmp (label)" for when the code needs to use the register for the indirect address.

    btw Chip - do you want to start a new thread then?

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • Chip
    I'd like to see Pnut have full command line support for use with other editors and other language tools.
    Macros would be nice too.

    Pushing my luck and being a bit cheeky, maybe the source code be OPENED for Pnut so it can be ported to all platforms.
    Melbourne, Australia
  • Isn't Pnut written in x86 assembler? Getting that running on all platforms would be more of a multiple rewriting exercise than simply porting.
  • Heater. wrote: »
    Isn't Pnut written in x86 assembler? Getting that running on all platforms would be more of a multiple rewriting exercise than simply porting.
    I should of said rewritten instead of ported.
    Anyhow wasn't Openspin created from rewriting X86 code to C?
    The same could be done again maybe this time to Python.



    Melbourne, Australia
  • As far as I can tell yes, OpenSpin is derived from the ASM source code.

    Having spent an inordinate amount of time recreating the functionality of ASM projects in C, for which there was no design documentation, I'm convinced that is not the best way to proceed. A compiler should be built from a formal language specification.
  • Speaking of PNut, I wonder how Chip is doing with Spin2? At the moment I think PNut only does PASM2, right?
  • Yeah, OpenSpin was made by taking Chip's 386 ASM file and porting it to C/C++ (along with some stuff from the delphi source for propellent, since the ASM compiler needs to be called in certain ways and be fed the processed into PASCII files). I have a semi recent P2 version of that same ASM file, and large amounts of it are the same or very similar. My intention is to make a P2 version of OpenSpin using that, but I haven't really done much yet since it doesn't have working Spin yet, just some minimal stuff to get the PASM going.

    PNut is a "wrapper" is written in Delphi that talks to that ASM code to do the compiles, similar to how PropTool (and Propellent) did for the P1 version.

    There is no formal language spec for Spin or Spin2, and I doubt Chip will do that. I'm not even sure it's really possible with how the PASM syntax conflicts with the Spin syntax and they are in the same file together.
  • I would not change a thing, and second Phils suggestion.

    The rest is an excellent syntax. Would hate to see it get cluttered up and harder to read.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • jmgjmg Posts: 11,778
    cgracey wrote: »
    What kinds of improvements do you guys think are needed on assembler mnemonics and syntax?

    The MCU Assembler I'm using here supports
    FSIN(x), FCOS(x), FTAN(x), FATAN(x), FLN(x), FEXP(x), FSQR(x) and FSQRT(x)
    which could be nice to see in a P2-ASM ?

    there are also these works

    https://github.com/davehein

    https://github.com/totalspectrum

    https://github.com/parallaxinc/OpenSpin

    ozpropdev wrote: »
    ..
    The same could be done again maybe this time to Python.
    I've never used a Python-coded Assembler - does anyone have any speed benchmarks for Python as Assembler ?
    I did dabble in fasmg, which is a script-based assembler, and that's very powerful, but not especially fast.


  • jmg wrote: »
    I've never used a Python-coded Assembler - does anyone have any speed benchmarks for Python as Assembler ?
    I did dabble in fasmg, which is a script-based assembler, and that's very powerful, but not especially fast.
    If the assembler has all the advanced features i'm happy to wait.
    After waiting for FPGA tools, a minute is a snap. :)
    Melbourne, Australia
  • I'm still working on the analog test code that will run on the wafer prober. it's been going slowly, and I'm still sort of in summer mode. Kids start school on Wednesday, which will be the needed change.
  • I favor using Python (3.x?) to code the (macro)assembler as it is well supported plus I like it. The problem I see is, how to get Chip to go along with it. Of course it could be done independently but having polished tools that are maintained by many rather than one will ensure that Parallax and their customers are advantaged (plus we get what we want and need).

    But once again, we need to move this to its own thread.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • ozpropdev wrote: »
    Chip
    I'd like to see Pnut have full command line support for use with other editors and other language tools.
    Macros would be nice too.

    Pushing my luck and being a bit cheeky, maybe the source code be OPENED for Pnut so it can be ported to all platforms.

    Well, there are already p2asm and fastspin which are both portable and run on lots of platforms.

  • As for assembler mnemonics changes, the only one I really feel is needed is changing the way we specify relative vs. absolute branches. It's been a common source of confusion, so I would suggest that different mnemonics be used for absolute branches (jmp) and relative branches (br).
  • jmgjmg Posts: 11,778
    In the Python sphere, there is also this
    https://blog.gopheracademy.com/advent-2016/peachpy/

    Claims : PeachPy is a Python-based framework for writing modules in assembly. It automates away some of the details and allows you to use Python to generate repetitive assembly code sequences.

    https://github.com/Maratyszcza/PeachPy
    PeachPy x86-64 assembler embedded in Python - with 362 commits and 11 contributors, that's quite well supported.

    Currently x86 centric, still getting my head around if this makes sense as a Prop2 centric variant ?


    Another search leads to
    http://dman95.github.io/SASM/english.html
    Looks to be an ASM-centric IDE, with Debug support built in,
    https://github.com/Dman95/SASM 272 commits, 9 contributors
  • evanhevanh Posts: 5,125
    edited August 13 Vote Up0Vote Down
    ersmith wrote: »
    ozpropdev wrote: »
    Chip
    I'd like to see Pnut have full command line support for use with other editors and other language tools.
    Macros would be nice too.

    Pushing my luck and being a bit cheeky, maybe the source code be OPENED for Pnut so it can be ported to all platforms.

    Well, there are already p2asm and fastspin which are both portable and run on lots of platforms.
    Correct me if I'm wrong, but they aren't complete though are they. I love the work done and actually use loadp2 all the time but still rely on PNut for completeness of opcode support. I'd like to see these tools get full support going forward.

    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • All I want for Chipmas is a real P2 and Pasm and Spin2 and a new bike and …...
    Melbourne, Australia
  • ozpropdev wrote: »
    All I want for Chipmas is a real P2 and Pasm and Spin2 and a new bike and …...

    and conditional assembly. ;)
    Melbourne, Australia
  • ... and a C compiler ...
  • evanh wrote: »
    ersmith wrote: »
    ozpropdev wrote: »
    Chip
    I'd like to see Pnut have full command line support for use with other editors and other language tools.
    Macros would be nice too.

    Pushing my luck and being a bit cheeky, maybe the source code be OPENED for Pnut so it can be ported to all platforms.

    Well, there are already p2asm and fastspin which are both portable and run on lots of platforms.
    Correct me if I'm wrong, but they aren't complete though are they. I love the work done and actually use loadp2 all the time but still rely on PNut for completeness of opcode support. I'd like to see these tools get full support going forward.

    As far as I know they are both complete -- at least, I'm not aware of any opcodes not supported by either, and I think they can both compile all the major samples (including the ROM). I can't speak for Dave Hein, but certainly I would regard any missing opcodes in fastspin as a bug and fix them if reported.

    Eric
  • ozpropdev wrote: »
    ozpropdev wrote: »
    All I want for Chipmas is a real P2 and Pasm and Spin2 and a new bike and …...

    and conditional assembly. ;)

    Use fastspin :). Or openspin, although I don't think that has full P2 support yet.

  • 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.

    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. However, local labels are still available when not in the object mode, and generating a binary file. Eventually, I may add GAS macros and conditional assembly features in the future if there is enough interest.
  • I should give p2asm a whirl when I get back to that side of things. There was something about programming the Prop2 that came up in another topic that I wanted to check out ...
    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • jmgjmg Posts: 11,778
    Dave Hein wrote: »
    ...

    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 ?

    Dave Hein wrote: »
    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 ?

  • David BetzDavid Betz Posts: 12,330
    edited August 13 Vote Up0Vote Down
    jmg wrote: »
    Dave Hein wrote: »
    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 doubt it. That will be the basis of Chip's implementation of Spin2. 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.

  • jmgjmg Posts: 11,778
    David Betz wrote: »
    I doubt it. That will be the basis of Chip's implementation of Spin2.
    but surely Spin2 is not going to pivot off x86 assembler base ?

    David Betz wrote: »
    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 ?

Sign In or Register to comment.