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

New BASIC compiler for Prop1 and Prop2

1101113151620

Comments

  • Ah, the dim shared. Very cool! :cool:
  • As a suggestion, could you support "option base 0" so that array indexing starts at 0?

    I am having difficultly giving an initialization list to the dim statement. The manual gives this example:
    dim as integer a(5) = { _
    1, 2, 3, _
    4, 5 _
    }
    
    print a(2)
    

    which does not compile.

    it gives the error:
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
    Version 3.9.11 Compiled on: Dec  5 2018
    arraycheck.bas
    C:/Propeller/spin2gui/test/arraycheck.bas(4) error: Internal error: bad AST value 7
    child process exited abnormally
    
  • "option base 0" is an excellent idea, thank you for reminding me about it. I think it shouldn't be too hard to generalize to allow arrays to start at any (constant) base.

    Sorry about the typo in the manual (and the bug in fastspin). The error message should have said that initialization of member variables is not allowed, and the example should have had a "shared" after the "dim":
    dim shared as integer a(5) = { _
    1, 2, 3, _
    4, 5 _
    }
    
    print a(2)
    
    The reason is a little obscure: an ordinary "dim" declares a member variable, which will be different in each instance of a class (even the top level program is really embedded in a class). These cannot be initialized because they're not in a fixed place in memory and there are many copies. "shared" variables though *can* be initialized because there is only one copy.
  • Thanks for the good explanation and workaround!
  • For me, the most important advantage of fastspin basic is the support for spin objects. I would still prefer to use
    the FDS spin objects rather the IO input and print The simple typo.bas below worked fine until recently. The last two releases no longer seem to support fds.spin

    'Simple typewriter program  
    'class fullduplex using "FullDuplexSerial.spin"
    dim ser as class using "FullDuplexSerial.spin"
    dim chr as any
    ser.start(31, 30, 0, 115_200)
    pausems(1000)
    
    do
       chr=ser.rx()                            
        ser.tx(chr)
    loop
    

    Ron
  • What problem are you having with typo.bas, Ron? I just compiled it with fastspin 3.9.12 and it seems to work OK for me.
  • I've added "option base N" (for any integer N) to the version of fastspin in github, so it'll make it's way to a binary release soon.

    Which raises a question: "option base 1" is the current default, but should it be switched to "option base 0". Personally I like 1 as the base, but C and Spin both use 0, as does FreeBasic by default, so there's a pretty strong argument for switching. Opinions?
  • yetiyeti Posts: 818
    edited 2018-12-14 14:13
    Personally I like 1 as the base, but C and Spin both use 0, as does FreeBasic by default, so there's a pretty strong argument for switching. Opinions?

    Default base 0 is what I prefer because I grew up with MBASIC and siblings.
    
    Altair 8800 (Z80) simulator V3.9-0 build 1000 (scp created Jun 20 2017 at 15:02:55 with gcc 6.3.0 20170516)
    
    
    64K CP/M Version 2.2 (SIMH ALTAIR 8800, BIOS V1.27, 2 HD, 02-May-2009)
    
    A>mbasic
    BASIC-80 Rev. 5.21
    [CP/M Version]
    Copyright 1977-1981 (C) by Microsoft
    Created: 28-Jul-81
    32824 Bytes free
    Ok
    dim a(10)
    Ok
    a(0)=1
    Ok
    a(11)=1
    Subscript out of range
    Ok
    █
    
    Maybe having no default would even better. Every reader would know what's the setting if each program would need "option base something" before the 1st declaration of an array.

    Bingo... I just changed my mind: I want no default at all. Error as long as "option base" was not used.
  • It compiles OK, but ser.rx should wait for a character. Rx.byte is different. Did you try running it.

    The problem is in the last two releases it was fine before that.



    Thanks


    Ron
  • rsut wrote: »
    It compiles OK, but ser.rx should wait for a character. Rx.byte is different. Did you try running it.
    Compiled with the freshest FastSpin from Git (3.9.13-beta-22261a8) "ser.rx()" waits...
    So it does with 3.9.10, 3.9.11 and 3.9.12 (here on Debian9).
  • It complies Ok, but does it run. Does ser.rx wait for a keyboard, it does in Spin


    Ron
  • yetiyeti Posts: 818
    edited 2018-12-14 14:58
    rsut wrote: »
    Does ser.rx wait for a keyboard, it does in Spin
    I compiled your FlexBASIC example in the 4 FastSpin versions I mentioned, ran it and "ser.rx()" was waiting in all of them.
  • Ok well, I downloaded the latest version from the link in this thread and not from Git, so I will download the windows
    build from git, maybe that's the problem

    Ron
  • When I load

    propeller-load typo.binary -r -t

    from the windows 10 command line,
    ser.tx(chr) streams chrs to the Command line console, but with theTera Term console. it's fine.

    Problem is that I have to load to eeprom because when
    I start Tera Term it resets the P1

    Pity cos I like Geany(window version) but going to a serial console without resetting the p1 is a problem at this stage.

    I still don't understand why the windows command line problem is streaming a character
  • rsut wrote: »
    When I load

    propeller-load typo.binary -r -t

    from the windows 10 command line,
    ser.tx(chr) streams chrs to the Command line console, but with theTera Term console. it's fine.

    Problem is that I have to load to eeprom because when
    I start Tera Term it resets the P1

    Pity cos I like Geany(window version) but going to a serial console without resetting the p1 is a problem at this stage.

    I still don't understand why the windows command line problem is streaming a character

    You could try proploader.exe instead of propeller-load. I just tried spin2gui, which uses the Windows 10 command line and proploader, and typo.binary seems to run fine.
  • Eric I modified ser.rx to ser.bin(chr,2) and found that it is returning $01 whilst waiting for input.
    I don't see that on tera term because it ignores none printable charcters.


    I looked closely at the Tere term console and I can see a definite flicker of the cursor so Tera Tera is seeing the $01
    but it does not print it. I prints a stream of h01 with ser.hex(chr,2)

    Ron

  • Ron: there must be something different with your setup than mine, because I've tried fastspin 3.9.11 and 3.9.12 under both Windows and Linux, and the compiled typo.binary runs just fine.

    I've attached a .zip file containing the sources I used, the fastspin.exe that I used, and the output typo.binary. Could you try the typo.binary first and see if it works for you? If it does, then could you try re-running "fastspin.exe typo.bas" and see if the new binary matches the old?

    Here's a transcript of exactly what I did (on Windows 10):
    C:\Users\Eric_Smith\Documents\spin2gui>fastspin typo.bas
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
    Version 3.9.12 Compiled on: Dec  9 2018
    typo.bas
    |-FullDuplexSerial.spin
    typo.pasm
    Done.
    Program size is 2748 bytes
    
    C:\Users\Eric_Smith\Documents\spin2gui>bin\proploader.exe typo.binary -r -t
    Opening file 'typo.binary'
    Downloading file to port COM3
    2748 bytes sent
    Verifying RAM
    Download successful!
    [ Entering terminal mode. Type ESC or Control-C to exit. ]
    I am typing this now
    it seems to work OK!
    

    Some things that would be helpful to check:

    Are you sure you have fastspin version 3.9.12? (Check the message that it gives when running.)

    Is your version of FullDuplexSerial.spin the same as mine?

    Does using proploader.exe instead of propeller-load.exe make a difference?

    Thanks,
    Eric
  • Eric

    It worked with your version of FDS.spin.
    All my versions are the same has in your post, even the fds.spin file
    It can only be a corrupt spin file.

    I used the old propeller loader in exactly the same way.
    I did not change the fastspin files, just the FDS,spin file. It worked, what a bummer!

    Thanks for the zip file I am going to compare the two spin files later.
    It's weird, the old spin file works with some older versions of fastspin
    Crazy !

    Thanks for the time spent.

    Ron






  • Thanks for helping to debug this Ron. I think there are two versions of FullDuplexSerial.spin floating around. One of them has "rxbyte := -1" as the first line of rxcheck; the other has "rxbyte--" as the first line. Both versions should produce the same code (since the return value, rxbyte, is implicitly initialized to 0 by Spin) but in recent versions of fastspin an optimizer bug crept in which caused the "rxbyte--" version to generate incorrect code. I've fixed that in github and added a test case so it won't happen again :).
  • jmgjmg Posts: 15,140
    ersmith wrote: »

    Which raises a question: "option base 1" is the current default, but should it be switched to "option base 0". Personally I like 1 as the base, but C and Spin both use 0, as does FreeBasic by default, so there's a pretty strong argument for switching. Opinions?
    There is your answer - follow the freebasic default, which allows code paste & run.

  • David BetzDavid Betz Posts: 14,511
    edited 2018-12-14 20:58
    Does DIM work like the old versions of BASIC I used ages ago? When I used a statement like this:

    DIM foo(10)

    it would actually allocate an array of 11 elements starting at zero.
  • David Betz wrote: »
    Does DIM work like the old versions of BASIC I used ages ago? When I used a statement like this:

    DIM foo(10)

    it would actually allocate an array of 11 elements starting at zero.

    If you use "option base 0" it works that way. With "option base 1" (the current default) it allocates an array of 10 elements starting at 1.

    It sounds like the default should be "option base 0".
  • ersmith wrote: »
    David Betz wrote: »
    Does DIM work like the old versions of BASIC I used ages ago? When I used a statement like this:

    DIM foo(10)

    it would actually allocate an array of 11 elements starting at zero.

    If you use "option base 0" it works that way. With "option base 1" (the current default) it allocates an array of 10 elements starting at 1.

    It sounds like the default should be "option base 0".
    I always thought that was an annoying feature of BASIC. If I give a size of 10 I expect the array to be 10 elements long. However, maybe that's one more reason why I'm not a BASIC programmer anymore :smile:


  • David Betz wrote: »
    ersmith wrote: »
    David Betz wrote: »
    Does DIM work like the old versions of BASIC I used ages ago? When I used a statement like this:

    DIM foo(10)

    it would actually allocate an array of 11 elements starting at zero.

    If you use "option base 0" it works that way. With "option base 1" (the current default) it allocates an array of 10 elements starting at 1.

    It sounds like the default should be "option base 0".
    I always thought that was an annoying feature of BASIC. If I give a size of 10 I expect the array to be 10 elements long. However, maybe that's one more reason why I'm not a BASIC programmer anymore :smile:

    [steps back in amazement]

    Had OPTION BASE since mid-80s

    http://code.wikia.com/wiki/QuickBASIC/Index

  • Seems like I was programming in BASIC in the early 70's.
  • I would assume that a dim x(10) will result in 10 elements from 0 to 9. Not 11.

    After 60 years of programming languages, still those constant hick-ups, no wonder buffer overflows are so common.

    Currently working with C# since a couple of years I have a strong urge to convert the whole system to a COBOL backend with some simple Web-frontend.

    I feel like a cat chasing my own tail. New Net-Frameworks every 2 years, new Windows Versions, new SQL versions, gosh I spend more time upgrading the code as writing new one.

    The COBOL source I had to maintain/change a couple of years ago was over 30 years old but would compile and run on any platform I could throw it on, original from running on IBM/360 it runs fine under Windows and Linux, even on ARM.

    There is a project named GnuCOBOL transpiling COBOL source to C and then use GCC to compile. I really would like that for the P2, but currently it needs some POSIX support, not sure yet how much.

    But it generates C code so I hope flexC will be able to handle this at some time.

    Enjoy!

    Mike
  • Cluso99Cluso99 Posts: 18,066
    Yes. Had the same for assembler on the Friden/Singer/ICL System Ten and System 25.
    Same code ran from 1969 to 1999 and with additional instructions from 1981 to 1999. Year 2K broke some things, but otherwise some customers were using that hardware, or emulation, long after 1999.
    The O/S didn't change much either, apart from some extra features.

    We spend so much time upgrading PCs and Servers now, and the changes to the software is never-ending. I feel many of the changes are so suppliers can continue to charge.
  • ersmith wrote: »
    David Betz wrote: »
    Does DIM work like the old versions of BASIC I used ages ago? When I used a statement like this:

    DIM foo(10)

    it would actually allocate an array of 11 elements starting at zero.

    If you use "option base 0" it works that way. With "option base 1" (the current default) it allocates an array of 10 elements starting at 1.

    It sounds like the default should be "option base 0".

    Yes. After much thinking, better to error on the side of being too large, than too small.

    Then all of the "FOR I=1 TO 10" kind of code still works for those not aware that foo( 0 ) exists.
  • whicker wrote: »
    Yes. After much thinking, better to error on the side of being too large, than too small.

    Then all of the "FOR I=1 TO 10" kind of code still works for those not aware that foo( 0 ) exists.
    That's why having no default may be the best solution.

    Would needing an "option base" line before the 1st "dim array(...)" really hurt?

    It forces you to think about what you need in which program and in program from others that definitely run with FlexBASIC, there already will be an "option baser" command then which tells you what this program needs.

    No chance for being "correct by accident".

    Let's make BASIC greatsafer again!
  • jmgjmg Posts: 15,140
    yeti wrote: »
    That's why having no default may be the best solution.

    Not quite, as then you have a lottery, smarter to follow the existing standard of freebasic’s default.
    Then, pasted code gives no surprises.
Sign In or Register to comment.