New BASIC compiler for Prop1 and Prop2

1121314151618»

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: 9,234
    edited 2019-02-18 - 16:35:08
    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
    
    Prop Info and Apps: http://www.rayslogic.com/
  • 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?
    Prop Info and Apps: http://www.rayslogic.com/
  • 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
    
    Prop Info and Apps: http://www.rayslogic.com/
  • ersmithersmith Posts: 2,760
    edited 2019-02-18 - 21:40:19
    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).
  • 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...
    Prop Info and Apps: http://www.rayslogic.com/
  • New fastspin does compile without crashing, thanks.
    Prop Info and Apps: http://www.rayslogic.com/
  • RaymanRayman Posts: 9,234
    edited 2019-02-18 - 22:11:48
    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
    
    Prop Info and Apps: http://www.rayslogic.com/
  • 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: 13,108
    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.
Sign In or Register to comment.