New BASIC compiler for Prop1 and Prop2

1567810

Comments

  • yetiyeti Posts: 436
    edited October 27 Vote Up0Vote Down
    Is the "Spin1"-FDS source Spin2 compatible?
    ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Please help: http://rosettacode.org/wiki/Category:Spin ▷ ◁ Why Asimov's Laws of Robotics Don't Work - Computerphile ▷ ◁ DNA is a four letter word. ▷
  • RaymanRayman Posts: 8,825
    edited October 27 Vote Up0Vote Down
    Uh oh... My code toggles the pin for P2, but not for P1... What's wrong?

    I think this doesn't work:
    output(pin) = not output(pin)
    

    Oops, have too many Props connected to my PC..
    Prop Info and Apps: http://www.rayslogic.com/
  • Rsadeika wrote: »
    My setup, for now is, using spin2gui to compile, and from the command line, use the propeller-load.exe to run the program.

    You could also use "Configure Commands..." to change the Run command to use propeller-load instead of proploader.
    Below is my test_temp program and the values that are being printed are way off. Did something happen to the '#' floating point variable, in the last update of fastspin?
    I'm not sure what's going on there. I haven't changed anything in the floating point code lately that I'm aware of. You're not passing the --fixedreal option to fastspin by any chance are you? That would change BASIC to use fixed point for single variables, but the Spin part would still be using FloatMath and the two wouldn't be able to communicate properly.
    I also tried using '%' integer variable in place of '#', to see what would happen, still was getting some way off results. I also noticed that by using '%' integer variable, it increased the size of the program by ~4000. I thought it would be the other way around.

    The integer print code has a bunch of formatting code (for PRINT USING) that the floating point doesn't have yet. I need to find a way to remove most of that when PRINT USING doesn't actually get used.

    Thanks,
    Eric
  • Rayman wrote: »
    I think I'm close to having a decent colorizer for FastBasic in SpinEdit (see attached).

    @Rayman: that looks very nice!
    I think I see some keywords not in documentation's list:
    waitcnt getcnt clkfreq waitpeq waitpne const heapsize new delete chr$
    Whoops! "const", "new", and "delete" definitely should have been in that list!

    waitcnt, getcnt, waitpeq, waitpne, and chr$ are built-in functions, rather than keywords. You can redefine them (although it's probably better not to). heapsize is kind of an odd case in that syntactically it's a constant identifier, but redefining it to anything other than an integer is probably a very very bad idea, so maybe it should be treated as a keyword as well.
    Also, what is with "mscycles"?
    Do you need to define it to use "pausems"? 
    
    No, I think it's appearance in source code is just a leftover from the time when we were defining "pausems" ourselves. "pausems" is in the standard library now, so we don't have to define it (it's another predefined function).

    Thanks for your comments!

    Eric
  • Rayman wrote: »
    Thanks! that does work for P1.
    For P2, I think there's a bug because I get this:
    error: Unknown symbol _rx
    

    Yes, I forgot to implement _rx in the P2 runtime code. I'll fix that ASAP.

    Thanks!
    Eric
  • There's a new release in the usual places:

    GUI+fastspin: https://github.com/totalspectrum/spin2gui/releases
    just fastspin: https://github.com/totalspectrum/spin2cpp/releases

    The changelog reads:
    Version 3.9.8
    - Added __propeller__ symbol to preprocessor
    - Added SELECT CASE to BASIC
    - Fixed a nasty buffer overflow in integer prints
    - Fixed close #n (it was losing the object pointer)
    - Fixed an optimizer bug in replacing registers
    - Fixed an assembly output bug when the input contains only leaf
      functions
    - Made for loops with float variables work
    - Fixed missing _rx function for P2
    

    There's also an undocumented feature which will be obvious to those who've read the source, but isn't ready for prime-time yet so I've left it as an "easter egg". :) (Hint: .bas is no longer the only file extension that's handled specially).
  • ersmith wrote: »
    There's also an undocumented feature which will be obvious to those who've read the source, but isn't ready for prime-time yet so I've left it as an "easter egg". :) (Hint: .bas is no longer the only file extension that's handled specially).
    That's the kind of (text) adventure I love to play!
    \o/

    ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Please help: http://rosettacode.org/wiki/Category:Spin ▷ ◁ Why Asimov's Laws of Robotics Don't Work - Computerphile ▷ ◁ DNA is a four letter word. ▷
  • ersmith wrote: »
    There's a new release in the usual places:

    GUI+fastspin: https://github.com/totalspectrum/spin2gui/releases
    just fastspin: https://github.com/totalspectrum/spin2cpp/releases

    The changelog reads:
    Version 3.9.8
    - Added __propeller__ symbol to preprocessor
    - Added SELECT CASE to BASIC
    - Fixed a nasty buffer overflow in integer prints
    - Fixed close #n (it was losing the object pointer)
    - Fixed an optimizer bug in replacing registers
    - Fixed an assembly output bug when the input contains only leaf
      functions
    - Made for loops with float variables work
    - Fixed missing _rx function for P2
    

    There's also an undocumented feature which will be obvious to those who've read the source, but isn't ready for prime-time yet so I've left it as an "easter egg". :) (Hint: .bas is no longer the only file extension that's handled specially).
    I know! You've implemented a LISP compiler! :smile:

  • ersmith wrote: »
    There's a new release in the usual places:
    Seems to have rapid progress :)
    In another thread, there are P2 fft comments and tests, is fastspin basic able to run fft yet ?
    Over in FreeBASIC , Search found 21 matches: Fast Fourier Transform

    A single source file that can use the new __propeller__ symbol in preprocessor, to run/report on either P2 or PC would make a great example ...

  • jmg wrote: »
    In another thread, there are P2 fft comments and tests, is fastspin basic able to run fft yet ?
    Over in FreeBASIC , Search found 21 matches: Fast Fourier Transform

    I'm sure it could, but I don't have a FreeBASIC version of the fftbench benchmark and I haven't had the time to port it from Spin or C yet. The performance of a BASIC version would be very similar to that of the fastspin compiled Spin version, I think, since the underlying compiler is the same. I can't think of anything in BASIC or in Spin that would give either language an edge in this benchmark.


  • The sources compiled on my Mac without problems. The compiled applications seem to run ok. Thanks.
  • David Betz wrote: »
    I know! You've implemented a LISP compiler! :smile:

    You don't know how much I wish that were true :). Any chance we might see an xlisp for P2?

  • ersmith wrote: »
    David Betz wrote: »
    I know! You've implemented a LISP compiler! :smile:

    You don't know how much I wish that were true :). Any chance we might see an xlisp for P2?
    If we have a C compiler for P2 then we can have XLISP. I guess it would even be possible to use XBYTE to make a fast XLISP VM. Who would actually use it though is a good question. At one point MIT was using Scheme in their introductory programming class and some students used XLISP because it was a superset of the version of Scheme that they were using at the time. That MIT class now uses Python. It might be more productive to look into what would be required to implement the Python VM using XBYTE.
  • David Betz wrote: »
    If we have a C compiler for P2 then we can have XLISP. I guess it would even be possible to use XBYTE to make a fast XLISP VM. Who would actually use it though is a good question. At one point MIT was using Scheme in their introductory programming class and some students used XLISP because it was a superset of the version of Scheme that they were using at the time. That MIT class now uses Python. It might be more productive to look into what would be required to implement the Python VM using XBYTE.
    Yes, I'd expect Python to be more widely accepted. There are already Pythons on other moderately large MCUs, so the industry already expects that.

  • Mike Green wrote: »
    The sources compiled on my Mac without problems. The compiled applications seem to run ok. Thanks.

    Cool, that's great to hear. Thanks for trying it on the Mac!
  • There is a new release in the usual places:

    fastspin compiler: https://github.com/totalspectrum/spin2cpp/releases
    spin2gui GUI: https://github.com/totalspectrum/spin2gui/releases

    spin2gui has everything you need for development, but it's a pretty bare bones GUI; something like @rayman's Spin tool would be nicer. If you just want the command line version of fastspin you can get it from the first link.

    This release is mainly a bug fix release and is intended to provide a reasonably stable baseline. The underlying compiler is probably going to change a lot for the next release in order to provide better support for C input. C isn't officially supported yet because the compiler is still case insensitive and there are some other missing features (like structures and unions), but fastspin is capable of compiling very simple C programs even now, for example:
    #define PIN 26
    
    void main(void)
    {
        unsigned long pinmask = 1<<PIN;
    
        DIRA |= pinmask;
        while(1) {
            OUTA ^= pinmask;
            waitcnt(40000000 + CNT);
        }
    }
    

    The ultimate goal is that the fastspin engine will allow mixing of code from Spin, BASIC, and C, with output for either P1 or P2.
  • C support? That's cool! It will be interesting to try this with BlocklyProp when it is fleshed about a bit more. How much effort will be required to make it able to compile the Simple Libraries?
  • David Betz wrote: »
    C support? That's cool! It will be interesting to try this with BlocklyProp when it is fleshed about a bit more. How much effort will be required to make it able to compile the Simple Libraries?

    I haven't looked yet, but if the Simple Libraries are plain C89 (which at a first glance they generally seem to be) then it should be pretty straightforward to support them.
  • Spin2gui on the Mac: When first started, the text in the buttons doesn't show. If you grab the lower right corner of the window and make it a little bigger or smaller, when the window is re-drawn, the button labels are properly shown.
  • ersmith wrote: »
    The ultimate goal is that the fastspin engine will allow mixing of code from Spin, BASIC, and C, with output for either P1 or P2.

    ... and Assembler ...

    that's sounding quite compelling. Does this have Debug support ?

    David Betz wrote: »
    C support? That's cool! It will be interesting to try this with BlocklyProp when it is fleshed about a bit more. How much effort will be required to make it able to compile the Simple Libraries?

    BlocklyProp should emit a consistent C style, so that should be easy to test and cover too ?
  • This sounds really nice ersmith!
    Prop Info and Apps: http://www.rayslogic.com/
  • jmg wrote: »
    ersmith wrote: »
    The ultimate goal is that the fastspin engine will allow mixing of code from Spin, BASIC, and C, with output for either P1 or P2.

    ... and Assembler ...

    that's sounding quite compelling. Does this have Debug support ?
    I would like to include/support a debugger. Any suggestions?

  • RaymanRayman Posts: 8,825
    edited November 8 Vote Up0Vote Down
    I guess I'd copy the way ViewPort does it:
    http://onerobot.org/#ViewPort

    More of a monitor... But, something to see the value of HUB variables over serial port.


    Actually, if you are compiling the code, can't you insert breakpoints that jumps to a serial interface routine before resuming?
    Prop Info and Apps: http://www.rayslogic.com/
  • BTW: When compiling Spin for P2... Does this use the Spin1 syntax?
    I think Chip is changing some things like ">=" for Spin2...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    BTW: When compiling Spin for P2... Does this use the Spin1 syntax?
    I think Chip is changing some things like ">=" for Spin2...

    It's kind of a Spin 1.5 syntax. It's compatible with Spin1 (so ">=" is still an assignment) but has many of the Spin2 operators.
  • Rayman wrote: »
    I guess I'd copy the way ViewPort does it:
    http://onerobot.org/#ViewPort

    More of a monitor... But, something to see the value of HUB variables over serial port.


    Actually, if you are compiling the code, can't you insert breakpoints that jumps to a serial interface routine before resuming?

    And recompile the code every time the user changes breakpoints? An interesting idea, but I don't think it's practical -- for one thing it would cause variables to move around in memory, which could cause a lot of trouble at run time.

    I was hoping that someone else already had a debugger that I could interface with. I'm not really an expert at writing GUIs, and the compiler itself will be plenty of work for me...
  • ersmith wrote: »
    jmg wrote: »
    ersmith wrote: »
    The ultimate goal is that the fastspin engine will allow mixing of code from Spin, BASIC, and C, with output for either P1 or P2.

    ... and Assembler ...

    that's sounding quite compelling. Does this have Debug support ?
    I would like to include/support a debugger. Any suggestions?

    I think some work has already been done in this thread, in at least looking at Object file formats and Linkers.
    http://forums.parallax.com/discussion/168535/pnut-and-p2asm-and-other-p2-tools/p1

    ELF appears well documented https://wiki.osdev.org/ELF_Tutorial
    DWARF info https://en.wikipedia.org/wiki/DWARF says
    "Version 5 of the DWARF format was published in February 2017.[4][5] It "incorporates improvements in many areas: better data compression, separation of debugging data from executable files, improved description of macros and source files, faster searching for symbols, improved debugging of optimized code, as well as numerous improvements in functionality and performance.""

    Maybe Debug and Link support for P2 needs a separate thread ?
  • Depends on what you want/expect from a debugger.

    I wrote a Zero Footprint Debugger for P1 (search for similar named thread). It lives in the shadow RAM and uses LMM HUBEXEC to execute the debug instructions. It works for both PASM and the SPIN Interpreter.

    This may be of some use to you.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • MicksterMickster Posts: 1,217
    edited November 9 Vote Up0Vote Down
    Rayman wrote: »
    I guess I'd copy the way ViewPort does it:
    http://onerobot.org/#ViewPort

    +1

    So nice just to Watch <var> and have it show up on the terminal.

    Failure is not an option...it's bundled with the software.
  • I used Viewport a lot, some years ago, but lost my key somehow and Hanno is awol. I do not need it anymore but it was nice to use.

    Since Fastspin can include Spin-Objects I see no problem in just using ViewPort, It just needs one object (conduit) to do the communication between Prop and ViewPort.

    So it will even work with FastSpin(Basic)

    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.
Sign In or Register to comment.