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

New BASIC compiler for Prop1 and Prop2

11415161820

Comments

  • I've posted a new version of fastspin (see link in the fastspin for P2 thread, although of course it still works on P1). Since this is the BASIC thread, I'll just highlight some of the changes to the BASIC language support:

    (1) Support for DATA/READ/RESTORE and INPUT

    (2) Support for old-school BASIC programs with line numbers and GOSUB. I was able to easily port some games from classicbasicgames.org by adding:
      defsng a-z  ' default to floating point
      option implicit ' allow implicit variable declarations
    
    and tweaking some PRINT statements

    (3) At the other extreme, better support for functional programming, in the form of a much more compact lambda function notation. For example:
    sub myrepeat(n as integer, proc as sub(x as integer))
      for i = 1 to n
        proc(i)
      next
    end sub
    
    myrepeat 4, [x: print "the number is: "; x]
    
    Prints:
    the number is: 1
    the number is: 2
    the number is: 3
    the number is: 4
    

    Similarly, a function to produce a function to add n to x can be written as:
    type intfunc as function(x as integer) as integer
    
    function incn(n) as intfunc
      return [x:=>x+n]
    end function
    
    var f = incn(3)
    
    print f(2)  ' prints 2+3, i.e. 5
    

    The general syntax is an opening "[", followed by optional parameters, then ":", then the statements to execute, and finally a "=>" and the expression to return; this latter may also have an "as type" clause to explicitly specify the return type.
  • Here's an example that can produce a counting function. It illustrates that this BASIC has proper closures (the local variables that are captured have persistent values):
    type countfunc as function(x as integer) as integer
    
    function make_counter(curval) as countfunc
      
      return [n:var t=curval: curval = curval+n: =>t]
    end function
    
    var c = make_counter(0) ' initial counter value is 0
    
    print c(1) ' prints 0, new value is 1
    print c(5) ' prints 1, new value is 6
    print c(4) ' prints 6, new value is 10
    
  • RaymanRayman Posts: 13,797
    edited 2019-02-18 16:35
    DEC in simpleserial.spin doesn't seem to work on P2...
    Getting nothing out...

    Actually, it's probably a tab issue. I think I can fix it...
    It was a tab issue. Might have to revisit this in SpinEdit…
    Had to adjust spaces on these two lines:
    val := -val
    buf[i++] := digit
    
  • RaymanRayman Posts: 13,797
    I'm not understanding something with this attempted adaptation of the VGA demo from pure ASM to ASM+Spin using Fastspin.

    The bitmap seems to wind up at the wrong place in memory. I'm telling it to be at $1000-$436, but it winds up at $10AA instead...

    Is this a bug, or am I doing something wrong?
  • RaymanRayman Posts: 13,797
    I've got another problem as well (sorry)…

    I'm trying to add in my spin only FSRW to the above.
    With "go" commented out, it compiles.
    But, uncomment "go" and it won't compile (appears to crash with no error messages).
    PUB main
        clkset(_SETFREQ, _CLOCKFREQ) 
        params[0]:=@bitmap
        cognew(@entry,@params)
        'go
    
  • ersmithersmith Posts: 5,900
    edited 2019-02-18 21:40
    Rayman wrote: »
    I'm not understanding something with this attempted adaptation of the VGA demo from pure ASM to ASM+Spin using Fastspin.

    The bitmap seems to wind up at the wrong place in memory. I'm telling it to be at $1000-$436, but it winds up at $10AA instead...

    Is this a bug, or am I doing something wrong?

    It's a bug. Basically ORGH does not work in Spin programs, only pure PASM programs. I'll try to fix that, but for now I would suggest leaving out the ORGH and using @ @ @ buffer to get the address of the buffer where the FILE is.
  • Not sure what's going on with your "go" crash; I can't reproduce it here, although I'm using my fsrw.spin2 because you only posted your main program, so maybe there's a difference there? It seems unlikely though. It's possible that it's a stack overflow in Windows, similar to what you ran into in the other VGA thread. Do you know how to increase the stack size allocated to a .exe in Windows? I think there's a tool that can change an existing .exe to give it a bigger stack, but I can't remember what it is.
  • @Rayman: Could you try the fastspin.exe in this .zip? It won't fix your ORGH problem, but it might fix the crash -- it's been recompiled with a bigger stack for Windows (8MB instead of the default 1MB).
  • RaymanRayman Posts: 13,797
    thanks, I'll try it. Here's another thing I just noticed...
    garryj's USB code uses conditions like this:
    if_10 that generate an error..

    if_00 seems to be OK, but not the others...
  • RaymanRayman Posts: 13,797
    New fastspin does compile without crashing, thanks.
  • RaymanRayman Posts: 13,797
    edited 2019-02-18 22:11
    I tried this (without spaces between #s and @s and it's in the right area, but a bit off:
    mov     ptra,# # @ @ @ bitmap
    

    and
    DAT' Bitmap
            org
            'orgh    $1000 - $436    'justify pixels at $1000, pallete at $1000-$400
    bitmap
            file    "bitmap2.bmp"'combined1.bmp" 
            'bitmap2.bmp   '640 x 480, 8pbb-lut
    
  • Rayman wrote: »
    thanks, I'll try it. Here's another thing I just noticed...
    garryj's USB code uses conditions like this:
    if_10 that generate an error..

    if_00 seems to be OK, but not the others...

    Ah, I missed those. We already have if_nc_and_nz and if_nz_and_nc (and all the similar variants). I didn't realize Chip had added so many aliases for the if conditions. I'll add them, although personally I think it's just adding more ways for newbies to be confused.
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    Rayman wrote: »
    thanks, I'll try it. Here's another thing I just noticed...
    garryj's USB code uses conditions like this:
    if_10 that generate an error..

    if_00 seems to be OK, but not the others...

    Ah, I missed those. We already have if_nc_and_nz and if_nz_and_nc (and all the similar variants). I didn't realize Chip had added so many aliases for the if conditions. I'll add them, although personally I think it's just adding more ways for newbies to be confused.

    Used properly, they make sense to me. With the ability to rotate a pair of bits into C,Z, the matching conditionals of

    if_00
    if_01
    if_10
    if_11
    are easier to follow than the unrelated C,Z - allows for simpler 4-choice case statements.
  • On the topic of BASIC for P1: is anyone using the fastspin BASIC interpreter? I've recently updated fastspin and spin2gui to support some additional BASIC features like ON x GOTO and 2 dimensional arrays. I've also been thinking of adding something like a DAT section to hold large blocks of assembly and data together. The syntax would be something like:
    ASM SHARED
       org 0
    entry
       mov DIRA, mask
       ...
    mask
       long $010
    END ASM
    
    Unlike regular inline assembly this would not allow access to any BASIC variables, but it would make it easy to define code to load into COGs (just like DAT in Spin).

    But I'm not sure if anyone is actually using BASIC in P1 or P2 (both would be supported), so not sure if this would be of interest?
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    On the topic of BASIC for P1: is anyone using the fastspin BASIC interpreter? I've recently updated fastspin and spin2gui to support some additional BASIC features like ON x GOTO and 2 dimensional arrays. I've also been thinking of adding something like a DAT section to hold large blocks of assembly and data together. The syntax would be something like:
    ASM SHARED
       org 0
    entry
       mov DIRA, mask
       ...
    mask
       long $010
    END ASM
    
    Unlike regular inline assembly this would not allow access to any BASIC variables, but it would make it easy to define code to load into COGs (just like DAT in Spin).
    I'm unclear here, does that mean the more usual inline assembler, cannot define code to load into COGs ?

    ersmith wrote: »
    But I'm not sure if anyone is actually using BASIC in P1 or P2 (both would be supported), so not sure if this would be of interest?

    PropBASIC is certainly used, and I'm not sure how different your version is ?

    An excellent example of PropBASIC is this code - does that compile in fastspin BASIC ? (with minimal edits maybe ?)
    http://forums.parallax.com/discussion/123170/propbasic-reciprocal-frequency-counter-0-5hz-to-40mhz-40mhz-now
  • twm47099twm47099 Posts: 867
    edited 2019-04-15 01:32
    I use fastspin BASIC a lot. So far only on the P2, but I'll probably use it on the P1 also.

    Tom
  • jmg wrote: »
    I'm unclear here, does that mean the more usual inline assembler, cannot define code to load into COGs ?
    Yes. The usual inline assembler is, well, inline, i.e. it defines code as part of a function. So you can write snippets of ASM code that get executed inline or called directly, but not a whole program to take over another COG. (You could write inline ASM in a function and run it in another COG, but that would still drag the usual BASIC runtime along with it, so it wouldn't really take over the entire COG.)
    ersmith wrote: »
    But I'm not sure if anyone is actually using BASIC in P1 or P2 (both would be supported), so not sure if this would be of interest?

    PropBASIC is certainly used, and I'm not sure how different your version is ?
    Very different. Mine is more like FreeBASIC, remember? And I think we already ported the reciprocal frequency counter earlier in this thread (back on page 3, in fact).
  • twm47099 wrote: »
    I use fastspin BASIC a lot. So far only on the P2, but I'll probably use it on the P1 also.

    Tom

    Glad to know someone is finding it useful :). Are there any glitches or missing features that you'd like to see added to the BASIC?

    Thanks,
    Eric
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    ... So you can write snippets of ASM code that get executed inline or called directly, but not a whole program to take over another COG. (You could write inline ASM in a function and run it in another COG, but that would still drag the usual BASIC runtime along with it, so it wouldn't really take over the entire COG.)
    What stops there being 'full elasticity', so you can have any mix of BASIC (or any HLL) and in-line ASM, including 100% of ASM in another COG ? (so making an external assembler less required)
    If nothing in 'usual BASIC runtime' is called, is that then discarded entirely ?
    ersmith wrote: »
    Very different. Mine is more like FreeBASIC, remember? And I think we already ported the reciprocal frequency counter earlier in this thread (back on page 3, in fact).
    Ah, great, thanks.. Dunno if I missed that, or forgot, but I do not see any comment by me, so maybe that slipped past.

  • ersmith wrote: »

    Glad to know someone is finding it useful :). Are there any glitches or missing features that you'd like to see added to the BASIC?

    Thanks,
    Eric
    Nothing jumps out at me. One thing I want to try is running some classic Basic programs.

    Some of my old Basic programs output graphics based on poking ascii values into a memory mapped video. I've never thought about doing that on a VGA terminal. Would there be any (library) functions that would be able to do that?

    Thanks
    Tom

  • twm47099 wrote: »
    Some of my old Basic programs output graphics based on poking ascii values into a memory mapped video. I've never thought about doing that on a VGA terminal. Would there be any (library) functions that would be able to do that?
    https://forums.parallax.com/discussion/comment/1453189/#Comment_1453189 and following are some graphics examples.

    If you use a textmode "VGA driver", writing ASCII values into the related buffer will display characters. Maybe an example for this would be nice too...
  • I am starting to believe that Parallax wants to stop supporting SimpleIDE , in favor of BlocklyProp. So, now I have to really start thinking about some other way of programming the Propeller x.

    From the last time I did use fastspin Basic, I ran into some problems, for my projects at least, because fastspin Basic is LMM. The other problem that I need to overcome is when using the AB WiFi, I use the C function for interacting with the WiFi to work with an .html file that shows up in a WEB page. Also The other thing that I do like about SimpleIDE C, is that it has an extensive library, which I do use for different things like the ADC, CM2302, …, etc.

    The last thing I want to mention is the SimpleIDE UI, it is very user friendly and easy to use. I think I got spoiled by using SimpleIDE. But, since Parallax is dumping support for SimpleIDE, I really have to start moving in another direction.

    So, I guess I have to start fresh with fastspin Basic again to see how some of the things I just mentioned could be overcome.

    Ray
  • When did Parallax announce they were dumping SimpleIDE?
  • Dave Hein wrote: »
    When did Parallax announce they were dumping SimpleIDE?
    They haven't as far as I know.
  • PublisonPublison Posts: 12,366
    edited 2019-04-15 18:32
    SimpleIDE was updated less than a year ago. It's just getting mature.
    https://www.parallax.com/downloads/simpleide-software-windows-propeller-c
  • yetiyeti Posts: 818
    edited 2019-04-15 19:09
    Publison wrote: »
    SimpleIDE was updated less than a year ago. It's just getting mature.
    https://www.parallax.com/downloads/simpleide-software-windows-propeller-c
    —▷ https://github.com/parallaxinc/SimpleIDE/tree/qt5side
    Latest commit 91674fa on 26 Jul 2017
  • Just an idea Eric, for dealing with the SimpleIDE C libs, to be used with fastspin Basic.

    Since this is based on FreeBasic, for FreeBasic, somebody created a program called "leapfrog". What that program does is it takes a C library or some C code and turns it into a '.bi' file. The created '.bi' can then be included within the FreeBasic program to make use of the C functions that are now within the '.bi' file.

    I remember a few years back I wanted to use some C code within a FreeBasic program, so I used the "leapfrog" program to do the "conversion" and then used the created '.bi' file within my program, it worked as expected. Not sure who created the "leapfrog" program, or even if there is existing code that could be looked at.

    I think maybe something like a "leapfrog" program for fastspin Basic could be a helpful solution for Fastspin Basic to reuse the existing SimpleIDE C library. Just my 2 cents.

    Ray
  • Thanks for the suggestion, Ray, it sounds interesting.

    Roy Eltham is porting the Simple Libraries to fastspin's C compiler. That will allow us to access those libraries from BASIC and Spin as well, since fastspin supports all 3 languages. There's also all the OBEX Spin code too, of course, which is easy to call from BASIC.
  • I am trying to figure out how run a Linux version of spin2gui. In the src dir I used the gui.tcl, made it executable, but no luck in getting it to run. I am using a Debian version of Linux. Any suggestions as to what I can do to make it work.

    Ray
  • Rsadeika wrote: »
    I am trying to figure out how run a Linux version of spin2gui. In the src dir I used the gui.tcl, made it executable, but no luck in getting it to run. I am using a Debian version of Linux. Any suggestions as to what I can do to make it work.

    You'll need to run spin2gui.tcl. "wish spin2gui.tcl" will usually do it. You can get spin2gui.tcl from the source repository, or use this:
    #!/usr/bin/wish
    #
    # Simple GUI for Spin
    # Copyright 2018 Total Spectrum Software
    # Distributed under the terms of the MIT license;
    # see License.txt for details.
    #
    # Top level program
    
    package require Tk
    package require autoscroll
    #package require ctext
    
    source src/ctext/ctext.tcl
    source src/checkserial.tcl
    source src/gui.tcl
    
Sign In or Register to comment.