Shop OBEX P1 Docs P2 Docs Learn Events
New BASIC compiler for Prop1 and Prop2 - Page 10 — Parallax Forums

New BASIC compiler for Prop1 and Prop2

17810121320

Comments

  • yetiyeti Posts: 818
    edited 2018-10-27 19:09
    Is the "Spin1"-FDS source Spin2 compatible?
  • RaymanRayman Posts: 13,767
    edited 2018-10-27 19:43
    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..
  • 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/

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

  • jmgjmg Posts: 15,140
    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.
  • jmgjmg Posts: 15,140
    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.
  • jmgjmg Posts: 15,140
    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 ?
  • RaymanRayman Posts: 13,767
    This sounds really nice ersmith!
  • 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: 13,767
    edited 2018-11-08 16:19
    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?
  • RaymanRayman Posts: 13,767
    BTW: When compiling Spin for P2... Does this use the Spin1 syntax?
    I think Chip is changing some things like ">=" for Spin2...
  • 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...
  • jmgjmg Posts: 15,140
    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 ?
  • Cluso99Cluso99 Posts: 18,066
    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.
  • MicksterMickster Posts: 2,582
    edited 2018-11-09 02:14
    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.

  • 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

Sign In or Register to comment.