fastspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

191012141529

Comments

  • Thanks for the update! You're making great progress on this.
  • I downloaded 1.39 and the LIB folder is gone. I assume, from the notes, that this was because the serial routines were updated. Can you please let me know what I have to do to use them? AdThanksVance
    Re-inventing the wheel is not a waste of time if, when you are done, you understand why it is round.
  • Ah, I seem to have a problem with 1.3.9 setting up serial connection on MacOS - I get this:
    Z:/Users/markt/Propeller2/adc_test.binary failed to load
    Error response was ""
    Press enter to continue...
    

    the code loads and runs, its just the serial setup that has issue - I've copied my config from 1.3.6
    which has compile config as:
    runcmd	{cmd.exe /c start "Propeller Output" "%D/bin/loadp2" -p COM1 -SINGLE -l230400 -b230400 "%B" -t -k}
    

    I think the issue is that loadp2 or its options have changed (since fastspin 1.3.6), and the runcmd config is not longer valid?

    [ yes its something to do with loadp2, switching in the version from release 1.3.6 works ]
  • I downloaded 1.39 and the LIB folder is gone. I assume, from the notes, that this was because the serial routines were updated. Can you please let me know what I have to do to use them? AdThanksVance

    The serial routines are in include/spin/ now. The default library path is "include", so you can (for example) refer to the SmartSerial routine as "spin/SmartSerial". See the code in samples/ for some examples.

    The PrintfSerial code is gone because all of the serial versions (even P1 FullDuplexSerial) have a printf method now.
  • Mark_T wrote: »
    Ah, I seem to have a problem with 1.3.9 setting up serial connection on MacOS - I get this:
    Z:/Users/markt/Propeller2/adc_test.binary failed to load
    Error response was ""
    Press enter to continue...
    

    the code loads and runs, its just the serial setup that has issue - I've copied my config from 1.3.6
    which has compile config as:
    runcmd	{cmd.exe /c start "Propeller Output" "%D/bin/loadp2" -p COM1 -SINGLE -l230400 -b230400 "%B" -t -k}
    

    I think the issue is that loadp2 or its options have changed (since fastspin 1.3.6), and the runcmd config is not longer valid?
    loadp2 has changed, but I'm not aware of any changes that should have broken the loading. I'll try to take a look later at Wine under Linux and see if I can reproduce it. In the meantime using the older loadp2 probably makes sense; the new loadp2 has some nice additions, but nothing critical.
  • David Betz wrote: »
    Thanks for the update! You're making great progress on this.

    Thanks, David, and thanks for your help with debugging the C compiler!

  • Ooh, an odd one I've just noticed - fastspin opens source files in read-write mode, so fails on a read-only file,
    and changes the last-modify timestamp which interacts badly with external editors. This is under wine on a Mac.
  • yetiyeti Posts: 585
    edited 2019-02-24 - 03:27:39
    @Mark_T ... I cannot confirm this for the Linux version (using Debian9):
    $ chmod 444 rndtest-vga.spin 
    $ ls -l rndtest-vga.spin 
    -r--r--r-- 1 yeti yeti 525 Feb 23 19:57 rndtest-vga.spin
    $ fastspin -O2 rndtest-vga.spin -L /opt/parallax.spin.src/spin
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 3.9.21 Compiled on: Feb 23 2019
    rndtest-vga.spin
    |-VGA_512x384_Bitmap.spin
    rndtest-vga.pasm
    Done.
    Program size is 1488 bytes
    $ ls -l rndtest-vga.spin 
    -r--r--r-- 1 yeti yeti 525 Feb 23 19:57 rndtest-vga.spin
    
    Here FastSpin neither coughs on the source being read-only, nor did it change the timestamp.
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ No Source – No Go! ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷ ◁ Stop slavery! Free all mitochondria! ▷
  • Mark_T wrote: »
    Ah, I seem to have a problem with 1.3.9 setting up serial connection on MacOS - I get this:
    Z:/Users/markt/Propeller2/adc_test.binary failed to load
    Error response was ""
    Press enter to continue...
    

    the code loads and runs, its just the serial setup that has issue - I've copied my config from 1.3.6
    which has compile config as:
    runcmd	{cmd.exe /c start "Propeller Output" "%D/bin/loadp2" -p COM1 -SINGLE -l230400 -b230400 "%B" -t -k}
    

    I think the issue is that loadp2 or its options have changed (since fastspin 1.3.6), and the runcmd config is not longer valid?

    [ yes its something to do with loadp2, switching in the version from release 1.3.6 works ]

    spin2gui 1.3.9 uses the latest version of loadp2, which uses a checksum in the -SINGLE mode. Earlier versions of loadp2 did not use a checksum. The NULL response indicates that loadp2 didn't wait long enough for the response. I call a waitdrain function that is suppose to return after the tx buffer is empty. On Linux and the Mac waitdrain calls tcdrain. This worked on another Mac, but some things that work on one Mac don't work on other Macs. On Windows waitdrain calls msleep(100) instead of tcdrain. Maybe I should use msleep(100) on all systems.
  • jmgjmg Posts: 13,917
    edited 2019-02-24 - 05:43:06
    Dave Hein wrote: »
    spin2gui 1.3.9 uses the latest version of loadp2, which uses a checksum in the -SINGLE mode....

    Maybe Checksum choice, and even delay options, need to be command line explicit options ?

  • I'm thinking of just eliminating the waitdrain, and using a long delay like 200ms with rx_timeout when reading back the response. It seems like that should work for all platforms.
  • Mark_T wrote: »
    Ooh, an odd one I've just noticed - fastspin opens source files in read-write mode, so fails on a read-only file,
    and changes the last-modify timestamp which interacts badly with external editors. This is under wine on a Mac.

    The fastspin compiler itself (fastspin.exe) opens files read-only, as @yeti verified. The spin2gui IDE does open them read-write, since it is an editor, and in fact it saves the file before every compilation to make sure what you're compiling matches what you're editing.

    I don't particularly recommend spin2gui; it more or less works, but it's something that I threw together fairly quickly just to give an IDE to people who really dislike the command line. There are better IDEs, like @Rayman's SpinEdit or one of the many IDEs like Geany or NotePad++ that can run external programs for compiling.

    If you already have an external editor that you're using, I suggest that you use that and use a command line to compile your programs with fastspin. Usage is just:
      fastspin -2 myfile.spin
    
    to produce a P2 binary "myfile.binary" from "myfile.spin". spin2gui prints the exact command line it's using too, if you want to mimic it for things like finding library files or changing optimization options.
  • Dave Hein wrote: »
    spin2gui 1.3.9 uses the latest version of loadp2, which uses a checksum in the -SINGLE mode. Earlier versions of loadp2 did not use a checksum. The NULL response indicates that loadp2 didn't wait long enough for the response. I call a waitdrain function that is suppose to return after the tx buffer is empty. On Linux and the Mac waitdrain calls tcdrain. This worked on another Mac, but some things that work on one Mac don't work on other Macs. On Windows waitdrain calls msleep(100) instead of tcdrain. Maybe I should use msleep(100) on all systems.

    I think he's running loadp2 on the Mac, but using Wine to run the Windows version, which probably adds a whole new layer of uncertainty. Using tcdrain and msleep both seems like it would probably be the safest bet.
  • The behaviour I'd ideally expect from an unselfish editor is open file for reading only, saving the last-modify
    timestamp on reading.

    When the editor wants to save/auto-save it checks if the timestamp has changed and prompts for
    confirmation if so, only then opening for writing. This means it doesn't clobber external modifications,
    nor does it change the last-modify timestamp if it hasn't actually modified the file, and of course it can work
    on read-only files and file systems.

    A nice feature to have is a reload option to pick up external modifications, which only proceeds without
    comfirmation if no local unsaved modifications have been made. Its useful to save a backup copy before
    doing this so that this can be reverted if the external modification proves to be unwanted.

    With all these precautions its intuitive to interwork with several editors on the same file, or with SCM tools
    like git, without too much pain.

    I've no idea if there's going to be any further work on spin2gui, so this is likely all academic :)
  • Mark_T wrote: »
    I've no idea if there's going to be any further work on spin2gui, so this is likely all academic :)

    The source code for spin2gui is freely available, and I encourage those who are interested to contribute. I'm not averse to seeing it improved, I just don't have the cycles to do it myself right now. :)


  • jmgjmg Posts: 13,917
    ersmith wrote: »
    The fastspin compiler itself (fastspin.exe) opens files read-only, as @yeti verified. The spin2gui IDE does open them read-write, since it is an editor, and in fact it saves the file before every compilation to make sure what you're compiling matches what you're editing.

    Does it save-only-if-changed, or simply always save ?
  • jmg wrote: »
    ersmith wrote: »
    The fastspin compiler itself (fastspin.exe) opens files read-only, as @yeti verified. The spin2gui IDE does open them read-write, since it is an editor, and in fact it saves the file before every compilation to make sure what you're compiling matches what you're editing.

    Does it save-only-if-changed, or simply always save ?

    It simply always saves. Yes, that's probably not the best way to do it. I really would encourage others to contribute better GUI/IDE code, or to use something like Geany or SpinEdit.
  • Well, I really like spin2gui like it is. It is simple, does its job and does not need a 150 pages documentation to use it.

    Please leave it as simple as it is now, and do not try to make a 'better IDE' out of it. It is good as it is.

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • I wish the editor indicated (in a spin program at least) the indentation like Prop Tools does.
    Re-inventing the wheel is not a waste of time if, when you are done, you understand why it is round.
  • I wish the editor indicated (in a spin program at least) the indentation like Prop Tools does.

    I don't know how to do that in Tcl. I think @Rayman 's SpinEdit program does that though, it's probably worth checking it out -- I think he's made the interface similar to PropTool, which will be much nicer than spin2gui.
  • I've created a new release, 3.9.22, of both spin2gui and fastspin (I've changed the version numbering of spin2gui to match fastspin to simplify things a bit). Links are:

    fastspin
    spin2gui

    If you're not familiar with fastspin, it's a compiler for PASM, Spin, BASIC, and C which can produce code for P1 or P2. The main language features are:

    PASM: should be compatible with PNut, but adds #define and #ifdef and has warnings for some things like forgetting "wcz" on a "cmp" instruction.

    Spin: a superset of Spin1, adding many Spin2 features like new operators, object pointers, and multiple return values, and a few other features like inline assembly and calling other languages. Documentation is in doc/spin.md or doc/spin.pdf.

    BASIC: not PropBasic compatible, but rather more like QBasic or FreeBasic. It'll actually compile old school Basic programs with line numbers and GOTO / GOSUB, but it also has more modern features like lambdas. Able to use Spin objects directly. Documentation is in doc/basic.md or doc/basic.pdf.

    C: The C compiler in fastspin is still under heavy development, and is still very incomplete. Eventually it should support all of C99, with extensions for calling out to BASIC and Spin functions, and inline assembly.
  • @Mark_T : the new spin2gui does not save unless the file is changed, and it checks for external changes before saving and before compiling. Use with caution, I'm not sure I caught all the possibilities, but it does seem to work when I edit a file with an external editor like emacs.

  • jmgjmg Posts: 13,917
    ersmith wrote: »
    @Mark_T : the new spin2gui does not save unless the file is changed, and it checks for external changes before saving and before compiling. Use with caution, I'm not sure I caught all the possibilities, but it does seem to work when I edit a file with an external editor like emacs.

    Great, that's really nice to have :) as it allows users to slip into their favorite editor for heavy editing code & it allows auto-generated files too.
    Having this also eases pressure on adding new features in the spin2gui, as it cooperates well with other programs.
    Does it have an option to silently auto-reload ? (useful for viewing generated files)
  • ersmith wrote: »
    @Mark_T : the new spin2gui does not save unless the file is changed, and it checks for external changes before saving and before compiling. Use with caution, I'm not sure I caught all the possibilities, but it does seem to work when I edit a file with an external editor like emacs.

    Excellent - I look forward to trying it out soon.
  • jmg wrote: »
    Does it have an option to silently auto-reload ? (useful for viewing generated files)

    No, it doesn't have a silent re-load option, it always prompts. It does sound like an auto-reload option would be handy, thanks for the suggestion. (It's not too critical though because the compilation is done externally, so we'll always get the generated file; the prompt for reload only comes into play in the editor if you have one of the files open, and even if you don't reload the compiler will use the version on disk.)

  • Prompt to reload is fine.
    What if the answer needs to be No?
  • jmgjmg Posts: 13,917
    whicker wrote: »
    Prompt to reload is fine.
    What if the answer needs to be No?

    Auto-reload is usually used for listing files, ie those that are created by the compiler where you want to scan to check code generated for example. You want that to be the newest copy, and there is no reason to say 'no'
    The prompts ersmith mentions are needed when you have an Edited file, which changed inside spin2gui, and also changed on the disk - what to do then ? Usually due to a user oops...
  • twm47099twm47099 Posts: 816
    edited 2019-03-06 - 04:13:17
    Eric,

    edit -- Never mind. In the run command I used -PCOM9 instead of the correct -pCOM9.
    I downloaded spin2gui v 3.9.22 and unzipped it and set my com port in the configure run command. I tried running some of the samples. When I click on compile & run the screen quickly shows and closes a black window (looks like a command window) with some white text, (closes too quickly to read). Programs that flash leds don't flash anything.

    I tried v 1.3.9 running the samples in the v 3.9.22 folder and they work.

    Any ideas?


    Thanks
    Tom
  • ersmithersmith Posts: 3,385
    edited 2019-03-06 - 12:02:06
    Tom: glad you got the -pCOM9 sorted out. Just out of curiousity, does the "Port" menu and %P substitution work for you? That is, %P should put -pCOM9 in for you if you've selected COM9 in the Port menu.
  • ersmith wrote: »
    Tom: glad you got the -pCOM9 sorted out. Just out of curiousity, does the "Port" menu and %P substitution work for you? That is, %P should put -pCOM9 in for you if you've selected COM9 in the Port menu.

    Eric,
    I tried using the port menu. I changed the configure run command back from -pCOM9 to %P. Then I clicked on port and checked my port (COM9). Clicked on compile & run and the program and terminal output worked.

    When I then looked at the configure run command I saw that the %P was still there. No -pCOM9 had been added. That's great so it will be a lot easier to run programs on other boards (once we get them) without having to edit the configure.

    Tom
Sign In or Register to comment.