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.
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
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?
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.
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
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: 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?
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 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 .
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.
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
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
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.
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.
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.
Comments
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:
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.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) loopRon
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?
Default base 0 is what I prefer because I grew up with MBASIC and siblings. 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.
The problem is in the last two releases it was fine before that.
Thanks
Ron
So it does with 3.9.10, 3.9.11 and 3.9.12 (here on Debian9).
Ron
build from git, maybe that's the problem
Ron
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.
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
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):
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
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
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".
[steps back in amazement]
Had OPTION BASE since mid-80s
http://code.wikia.com/wiki/QuickBASIC/Index
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
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.
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.
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!
Not quite, as then you have a lottery, smarter to follow the existing standard of freebasic’s default.
Then, pasted code gives no surprises.