David Betz:
I eagerly await your implementation, i think it will be quite good. My implementation is not even going to be in the works until I finish my Pascal compiler for the Prop (and by then I may be focusing on the Prop II).
boolean expressions --> x=x+(y>5) [if y > 5 then add "true" to X]
fixed length strings with simple numeric indexing of them b$(50) = a$(60); a$(30)="hello", which would just write the chars for "hello" into A$ at index 30, etc..
if, then, else
goto, on x goto (for simple, math based case statements)
byte, word, long variables
fixed point
peek, poke, memcopy x, y
print, print@x,y, perhaps with some rough formatting capability, though the minimum would be to just allow: print a;b;c
serial I/O for console operation, and use with whatever video drivers people come up with, that can do TV_text type I/O
gosub, return
no line numbers, use labels, if line numbers, provide for renumber somehow, maybe externally
bsave, bload, save, load (to / from serial and or SD card)
some autorun capability for programmed EEPROM image, SD card binary kind of thing
basic string compare A$=B$
adr(A$), adr(X), type(X), where "adr" returns the HUB address of that variable, and type returns the type, 0-string, 1 byte, 2, word, 3, long, etc...
on err goto
A whole lot can be done with that, particularly if it's fast.
Forgot: char(A$(30)), get numeric character value of string element, A$=str(50), return string from character value, though both of those could be subroutines easily enough.
Patatohead:
I would use FUNCTION and SUB declarations instead of GOSUB/RETURN. I do not think that GOSUB is really even needed or used in modern BASIC as every just uses FUNCTION and SUB to define and declare subroutines.
And BASIC has not even used line numbers in a long time.
David Betz:
Could I request that the name of this thread be modified from:
Embedded Basic Requirements (was Prop II: Too little, too late ???)
to:
Embedded BASIC Requirements (was Prop II: Too little, too late ???)
David Betz:
I eagerly await your implementation, i think it will be quite good. My implementation is not even going to be in the works until I finish my Pascal compiler for the Prop (and by then I may be focusing on the Prop II).
That's cheating! :-)
Pascal doesn't support dynamic strings or any kind of automatic garbage collection so I won't be able to steal your code!
David Betz:
Could I request that the name of this thread be modified from:
Embedded Basic Requirements (was Prop II: Too little, too late ???)
to:
Embedded BASIC Requirements (was Prop II: Too little, too late ???)
Yeah, I know "BASIC" is an acronym but I think it might be best to forget that aspect of its history. After all, "IBM" doesn't mean "International Business Machines" anymore either.
Thanks for giving this thread a more positive title (and direction). I'm not sure when it switched to a discussion about Embedded Basic, but I'd like to second everything that potatohead said.
To get a bit of a start, I would like to suggest a list of KeyWords for this BASIC varient. All keywords listed are sugested in the form they take in FreeBASIC. Then someone will have to define the operaters code the parser and assembler.
Here is a list of BASIC keywords I would suggest implementing in a Propeller based compiler:
#DEFINE
#ELSE
#ELSEIF
#IF
#IFDEF
#IFNDEF
ABS
ALLOCATE
AND
ANY
AS
ASC
ASIN
ASM
ATN
BLOAD
BSAVE
BYTE
CALL
CASE
CAST
CLOSE
CLS
COLOR
CONTINUE
DATA
DIM
DECLARE
DO..LOOP
DO..WHILE
DO..UNTIL
DRAW
ELSE
ELSEIF
END
END IF
ENUM
EOF
EOL
EXEC
FOR
FOR..NEXT
FUNCTION
GET#
GETKEY
GOTO
HEX
IF..THEN
INKEY
INPUT
INPUT#
INT
INTEGER
IS
LCASE
LEFT
LEN
LONG
LOOP
MID
MOD
NEXT
NEW
NOT
OCT
ON ERROR
OPEN
OR
PEEK
POINTER
POKE
POS
PRINT
PRINT#
PROCPTR
PTR
PUT#
RANDOMIZE
RANDOM
READ#
REM
RESET
RETURN
RND
SCREENSET
SEEK
SETMOUSE
SGN
SHL
SHR
SHORT
SLEEP
SPACE
SQR
STEP
STOP
STR
STRING
SUB
SWAP
TAB
TAN
THEN
THREADCREATE
THREADWAIT
TIMER
TO
TYPE
USIGNED
VAL
VAR
VARPTR
WAIT
WHILE
WEND
WITH
XOR
ZSTRING
I've used VB6 quite a bit and have written several PBASIC programs.
Generally I'm not a BASIC user, but I would be a Propeller BASIC user if I could use external memory such as Flash and/or RAM (SRAM,SDRAM,etc....) for larger programs.
There is no external memory usability on any stand alone Propeller BASIC today. That's a shame to me at least.
David Betz XBASIC project would use external memory or just HUB memory. It is compiled basic and would run on any Propeller from HUB memory and platforms with external memory such as C3, SpinSocket-Flash, Gadget Gangster SDRAM, and DracBlade boards.
While I don't really think an embedded propeller language is so important, it should be possible to achieve with enough resources. Having the option to 1) build a program off-chip and download it or 2) edit and compile it on-chip would be nice. Right now it seems like an either/or situation. XBASIC can do it but maybe not in the first release.
To me some type of off-chip storage would be required for an "embedded" basic for decent sized programs. That would make it less "system on a chip embedded," but would be more useful in the long run for Propeller 1. If all you want to do is blink LEDs, then it doesn't really matter and something like femtoBasic should be suitable.
I guess hard core BASIC programmers have similar feelings about languages as C programmers. There is value in being practical though.
For me I think getting something that works well for many is a practical and fair target. From what I've seen so far, David Betz's XBASIC project offers quality (from a very smart and experienced developer) in a modern language variation. The project fits the goal of practical support for large external memory (and smaller HUB only) programs very nicely.
Embedded development is possible with XBASIC with SDCard, but it is unclear how valuable embedded development really is.
@David: On a micro, I think it's best to keep it simple and fast. Was only trying to communicate what is "complete". With that set of stuff, most things that need to get done, can get done, given the scope of functionality is micro-controlling, not computing.
I think there is a tension here between the "embedded" part and the "modern" part.
Basic was originally invented to be a small, lean, simple language which could run on a computer with 4K of RAM. Since the Propeller has more than 4K of RAM it's a good candidate for a Prop language, but since cogs only have 512 Longs it is going to require some compromise even if we provide external memory support.
As an aside, VB was intended as a simple, robust, and very capable language to make a very difficult OS environment more accessible to less skilled programmers. They chose Basic syntax because most of the less skilled (e.g. not college educated in CS) programmers in 1990 had learned on platforms like the Apple ][ and Commodore 64 then QBasic and QuickBasic. VB was meant to be an easy migration path for them that would hide the complexity of the Windows environment and API and prevent the kind of obscure crash bugs that are possible when buffers are allowed to overrun and pointers are misused.
But any Propeller basic has to deal with the whole 2K cog + 32K hub thing even if there is XMM. I am working on a system which sorts a similar set of challenges, and while I chose Forth as my starting point instead of Basic (because I wanted to be able to compile new code on the Prop) many of the compromise decisions are made in the same design space. With this in mind may I suggest a peek at the blog post I wrote about the Windmill byte code interpreter: http://forums.parallax.com/entry.php?39-Windmill-Byte-Code-Interpreter
What I did there was sacrifice a little bit of code density over Spin by implementing a LMM-like scheme that essentially creates one-byte LMM versions of most PASM instructions, and using the 400 or so Longs this saves to implement more complex helper functions. It would be a trivial matter to compile BASIC source to this interpreter. One big win is that I was able to implement a full complement of random buffer and Pascal-style string functions. The cog has functions for string comparison, moving strings around, and even a code that can with the right parameters do things like UCASE, LCASE, or ASCII-Hex conversion. The importance is that these loopy functions are in the Cog written in PASM, so they are far faster than even optimized LMM library routines would be.
String manipulation is the single biggest weakness I see in Spin, and that is one reason for so much difficulty with things like filesystems and ethernet stacks, which are very heavily string oriented. You need PASM multiply and divide, which take maybe 20 longs and perform almost as well as hardware mul and div would in such an interpreter. Floating point is a crutch whose use should be discouraged, because it is very expensive both in time and memory terms. In order to make XMM transparent I decided to devote a second cog to that. (I got that cog back in my reference system by making it also implement the default TTY serial port.)
You are not going to have room to deal with any workable real-time garbage collection scheme either for random length strings or more abstract variables. For that matter dealing with var types other than string and Long will overcomplicate what is already a tight system. With XMM code you can afford to use Longs for all data. You distinguish between signed and unsigned by using appropriate operators.
Another issue is caching code that really has to run faster than it can from XMM. My experience is that most systems of this scale have a relatively small but important fraction of such routines. There needs to be a way to either move these to Hub RAM or temporarily cache them. (Windmill will permit both.) With an external compiler such a system can get pretty elaborate without straining the runtime environment.
Ultimately, there will be many compromises to make and many decisions which are more optimal for some projects than others; I'm targeting both my hardware selection and software environment at a particular class of instruments which require a limited but critical amount of time critical processing combined with some complex decision making and user interface maintenance that doesn't have to happen quite so fast. Other people however will have different needs; some will really need floating point, others might need the buffer overrun protection I decided to ditch. For the same reason that Propeller hardware solutions proliferate, I imagine Propeller development solutions will continue to do so as well.
The easiest way to try it is to use "TELNET 173.67.187.91" this will allow you to program my spinneret at my house.
Bean
I just tried this but got the following results:
list
UNKNOWN COMMAND IN LINE 0
OK
list
Syntax Error IN LINE 0
OK
LIST
Syntax Error IN LINE 0
OK
10 for x=1 to 10
UNKNOWN COMMAND IN LINE 0
OK
help
Syntax Error IN LINE 0
OK
new
Syntax Error IN LINE 0
OK
OK, a simple revision of my list of ops. This is in consideration of the (quite valid) arguments made.
PRINT on TV/VGA/Terminal no extra formatting.
INKEY For PS/2 or Terminal.
INPUT
GOTO
SUB With RETURN for function like functionality (Possibly limit to 6 Parameters).
COLOR
DRAW
FOR..NEXT
WHILE..WEND
Math functions.
+ - * / MOD XOR OR AND NOT
COGNEW
COGINIT
PININ
PINOUT
David,
I'm not sure. I just reset it, try it again.
What type of computer are you using ? I know it works with windows telnet, I haven't tested it on any other OS.
David,
I'm not sure. I just reset it, try it again.
What type of computer are you using ? I know it works with windows telnet, I haven't tested it on any other OS.
Bean
I'm still getting the same result. I'm using a MacBook Pro under Mac OS X.
Clearly, it fails on a UNIX Bean. Just tried it with OS X, and after connecting, I input a single line "10 for i = 1 to 1000"[enter], got unknown command in line 0.
Any combination of entries appears to result in the same error. Maybe it wants both CR/LF?
Potatohead,
Yeah something is happening. I get the same error now.
I reset it again, but I don't have the time right now to diagnose the problem.
Something must be getting the input buffer messed up.
It works well with my Linux box, the telnet client set to CR/LF EOL and local ECHO disabled (even though this means not seeing what I type [thankfully there is a list command])
There is no external memory usability on any stand alone Propeller BASIC today. That's a shame to me at least.
RossH and I have been quietly working on something like this. We have Basic running with XMM using a subset of the BCX to C translator http://www.bcxgurus.com/help/index.html
There is a catch and that is that BCX outputs a syntax that is not quite C89 C. But with a lot of behind the scenes modification, it is possible to have a Basic program, hit F12 and have it compiled and downloaded into external ram on a propeller.
Simple demo
Dim Mystring$ As String * 80 ' dim with 80 bytes
Mystring = "Hello World" ' put Hello World in a string
Print Mystring$ ' print out the string
This works, but with the command line for catalina being rather critical, there is an argument for making this command line part of the program. So add
$COMMAND
catalina -lcx -lm -x5 -M 128k -D DRACBLADE -D VGA_HIRES
' library cx, library maths (slow, doesn't use a cog), memory size, board, high res vga, mouse, keyboard
$COMMAND
And then the Basic purists might not like this, but there needs to be a way of including or not including modules which C needs, and so though this looks a bit like C, we add this at the beginning
And then it is a matter of testing every single command and to see if Catalina can handle the output. This is the test program so far
' Big Basic For external memory on the Propeller using BCX Basic To C converter And Catalina
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include <ctype.h>
#include <errno.h>
#include <float.h>
#include <inttypes.h>
#include <limits.h>
'#include <mathconst.h>
' mathconst.h upsets tinyc
$COMMAND
catalina -lcx -lm -x5 -M 128k -D DRACBLADE -D VGA_HIRES
' library cx, library maths (slow, Doesn't use a cog), memory size, board, high res vga, mouse, keyboard
$COMMAND
Call WhiteOnBlue
Dim a As integer
Dim i As integer
For a=1 To 3
Print "hello world";
Print a
Next a
$COMMENT
' file test copied from bcx examples - Files work - commented Out For speed
Print "Opening file For output"
Dim MyFileHandle@ ' BCX Reserves @ For "C" FILE* Data types
Open "new.txt" For OUTPUT AS FP1
MyFileHandle@ = FP1
FPrint MyFileHandle@, "This is a test"
Close FP1
Print "Closing file"
$COMMENT
' ASC Function
Dim Mystring$ As String * 80 ' 80 characters
Dim RetVal%
Mystring$="A"
Print Mystring$
RetVal% = ASC(Mystring$)
Print RetVal%
'CHR$ Function - opposite Of ASC
a=65
Mystring$=Chr$(a) ' declared in asc
Print "Character should be A: ";Mystring$
'VAL Function - converts string To Double number. From the BCX help file
Dim StringNum$ As String * 20
Dim RetDub#
StringNum$="3.1415927"
RetDub#=Val(StringNum$)
Print RetDub#
'STR$ Function - opposite Of VAL. Converts number To string
Dim RetStr$ As String * 20
Dim DoubleNumber#
DoubleNumber# = 1.23456789
RetStr$ = Str$(DoubleNumber#)
Print RetStr$
' Test some inLine C code - pass a value in myarray, C changes it, Print the return value
Dim myarray[5] As integer ' this can be much bigger If you like, eg 50000
myarray[1]=100
Print myarray[1]
Call TestCCode
Print myarray[1]
' test some string functions
Dim lineoftext1$ As String * 80 ' strings must End in $ otherwise compiler Doesn't copy properly
Dim lineoftext2$ As String * 80
lineoftext1$="Hello World" ' string name is Case sensitive
lineoftext2$=Left$(lineoftext1$,4) ' left characters
Print "Left$ test ";lineoftext2$
lineoftext2$=Mid$(lineoftext1$,5,4) ' mid characters
Print "Mid$ test ";lineoftext2$
lineoftext2$=ucase$(lineoftext1$) ' upper case
Print "Upper Case test ";lineoftext2$
lineoftext2$=Right$(lineoftext1$,3) ' right characters
Print "Right$ test ";lineoftext2$
lineoftext1$="Hello"
lineoftext2$="World"
Concat(lineoftext1$,lineoftext2$) ' add two strings - same as + Or & in vb.net
Print "String concat test ";lineoftext1$
lineoftext1$="ABCDEFG"
lineoftext2$=lcase$(lineoftext1$) ' lower case
Print "Lower Case test ";lineoftext2$
a=1000
lineoftext1$=Hex$(a) ' hex$ working
Print lineoftext1$
Dim retval% ' hex2dec = two errors, DWORD (which I think can be changed To unsigned long) And CharLowerA which instr also is unhappy about
retval%=hex2dec("0xFFFF") ' reverse Of hex$, can use 0x Or &H syntax Or even FFFF
Print "Hex2Dec test ";retval%
lineoftext1$="12345abc6789"
lineoftext2$="abc"
a=Instr(lineoftext1$,lineoftext2$,3,0) ' instr search For characters. Last value is needed, use dummy 0 (matches case)
Print "Instr test, string is at position ";a
a=255
lineoftext1$=bin$(a) ' test Binary
lineoftext1$=lpad$(lineoftext1$,32,48) ' test adding leading zeros with lpad so is always 32 char long
Print "Binary value is ";lineoftext1$ ' test Binary To strings And back again
lineoftext1$="0000000001010101"
Print "Binary string To decimal ";Bin2dec(lineoftext1$) ' Binary
lineoftext1$=String$(10,65)
Print "String Function ";lineoftext1$' n characters Of ascii value m
lineoftext1$=" trim test " ' trim off leading zeros, spaces etc
lineoftext1$=trim$(lineoftext1$)
Print "Trim test:";lineoftext1$
' test a string array
Dim Stringarray[5] As String * 80 ' 80 characters
Stringarray[1]="Hello"
Stringarray[2]="World"
Print Stringarray[2]
' bitwise operators - there are many more Of these but they all seem To work ok withOut code changes
a=1
a=a << 10
Print "bitwise shift left";a
a=a >> 4
Print "bitwise shift right";a
a=1
a=a And 0xFF
Print "logical and";a
a=a Or 0xFF
Print "logical or";a
Print "test starting with a Binary string And shifting"; bin2dec("00000001") << 4
' test program control Loops - For is already tested above
a=1
Do
Print a
a=a+1
Loop Until a=3
Print "Do Loop finished"
a=1
While a <3
Print a
Incr(a)' translates To a++ in C
Wend
Print "Wend Loop finished"
a=5
Select Case a
Case 1
Print "1"
Case > 1 And < 6
Print "more than 1 And less than six"
Case Else
Print "something Else"
End select
' test functions
Print addnumbers(5,6)
' test some maths with floating point numbers
Dim number1 As Double
number1=1.2345
Print number1
Print Sin(number1)
Print Log(number1)
$CCODE
while(1); // Loop instead Of finishing
$CCODE
' And exitprocess Does Not work on the propeller. So Don't use End For the moment
' Subroutines And functions
Function addnumbers(a As integer, b As integer)
Dim returnvalue As uint
returnvalue = a + b
function=returnvalue
End Function
Sub TestCCode
$CCODE
// declare the variables:
int nNumber;
int *pPointer;
// now, give a value To them:
nNumber = 15;
pPointer = &nNumber;
// Print Out the value Of nNumber:
printf("nNumber is equal To : %d\n", nNumber);
// now, alter nNumber through pPointer:
*pPointer = 25;
// prove that nNumber has changed as a result Of the above
// by Printing its value again:
printf("nNumber is equal To : %d\n", nNumber);
myarray[1]=110;
$CCODE
End Sub
Sub WhiteOnBlue() ' white text on blue background
$CCODE
int i;
for (i=0;i<40;i++)
{
t_setpos(0,0,i); // move cursOr To Next line
t_color(0,0x08FC); // RRGGBBxx eg dark blue background 00001000 white text 11111100
}
$CCODE
End Sub
I am not sure if this would be useful or not. I got sidetracked with getting plugins working on catalina, but if there is enough interest maybe this could be useful?
David Betz:
I eagerly await your implementation, i think it will be quite good. My implementation is not even going to be in the works until I finish my Pascal compiler for the Prop (and by then I may be focusing on the Prop II).
. I'm working on a version of basic for the Propeller and I'd be interested to know what you think is needed for it to be complete.
1) Given the Prop's memory mix, one item I'd place high in the list, is the ability to run(fetch byte codes) from QuadSPI memory, in a choice of counts. ( some call this execute in place )
QuadSPI are SO8, so are small, and cheap and a single device can hit 52MBytes/sec, two give 104Mbytes/sec (etc).
The choice of chip counts works like this :
One reads a nibble at a time, Two streams a Byte, Three Streams 12 bits, 4 streams 16 bits, (etc)
Also, this memory has a jump cost, so a skip(0..5) type byte-code 'fits' well, with the streaming data
2) The source code should have 'linking' options, to allow placing/preloading of (small) sections of code into Prop on-chip memory.
3) In line ASM - it's ok if this has caveats, but variable access should be implicit.
4) Block comments, and nested comments and clone the // as line comment.
5) Simple Source Debug Pin-tag commands, so that users can map a Pin for CRO/Counter debug, then use commands like
DIM DebugPinQE AS Boolean AT PinNumber ' allocates Pin, If PinNumber is illegal, Debug is Off, and Debug lines are skipped.
DebugPinQE = True ' Sets Pin
DebugPinQE = False ' clears pin
DebugPinQE = NOT DebugPinQE ' Toggles Pin
DebugPinQE = BooleanVar 'copies BooleanVar to the pin
6) and since I am on a roll, a choice of code generation
a) byte code intended to be interpreted
b) machine code, intended to be placed in a cog. This would typically include in-line-asm, and code b) would have a size ceiling, and a destination specified.
Thanks for the pointer. This looks very interesting. You've made very clever use of the unique features of the Propeller instruction set. I skimmed through your blog and I think I get the gist of what you're proposing but I was wondering if you had a summary of the bytecodes you ended up with. Is the code available for this VM?
1) Given the Prop's memory mix, one item I'd place high in the list, is the ability to run(fetch byte codes) from QuadSPI memory, in a choice of counts. ( some call this execute in place )
QuadSPI are SO8, so are small, and cheap and a single device can hit 52MBytes/sec, two give 104Mbytes/sec (etc).
I have two QuadSPI chips on upcoming GameBaby and SpinSocket-Flash.
jmg:
The Pascal compiler is quite simple. Basically supporting standard variable types, arrays, structures, simple expressions (only limit is no more than 8 operators in an expression), and most of the standard language. It should be fairly simple to modify to compile a different language (once it is done). Though I have not yet even announced this project (do not wish to get peoples hopes up), my mention of it above was just to tell David Betz that it will be a while before I can even think about making a BASIC compiler (besides the other projects that I am working on, and getting a bit behind on some of).
Comments
I eagerly await your implementation, i think it will be quite good. My implementation is not even going to be in the works until I finish my Pascal compiler for the Prop (and by then I may be focusing on the Prop II).
boolean expressions --> x=x+(y>5) [if y > 5 then add "true" to X]
fixed length strings with simple numeric indexing of them b$(50) = a$(60); a$(30)="hello", which would just write the chars for "hello" into A$ at index 30, etc..
if, then, else
goto, on x goto (for simple, math based case statements)
byte, word, long variables
fixed point
peek, poke, memcopy x, y
print, print@x,y, perhaps with some rough formatting capability, though the minimum would be to just allow: print a;b;c
serial I/O for console operation, and use with whatever video drivers people come up with, that can do TV_text type I/O
gosub, return
no line numbers, use labels, if line numbers, provide for renumber somehow, maybe externally
bsave, bload, save, load (to / from serial and or SD card)
some autorun capability for programmed EEPROM image, SD card binary kind of thing
basic string compare A$=B$
adr(A$), adr(X), type(X), where "adr" returns the HUB address of that variable, and type returns the type, 0-string, 1 byte, 2, word, 3, long, etc...
on err goto
A whole lot can be done with that, particularly if it's fast.
Forgot: char(A$(30)), get numeric character value of string element, A$=str(50), return string from character value, though both of those could be subroutines easily enough.
I would use FUNCTION and SUB declarations instead of GOSUB/RETURN. I do not think that GOSUB is really even needed or used in modern BASIC as every just uses FUNCTION and SUB to define and declare subroutines.
And BASIC has not even used line numbers in a long time.
Could I request that the name of this thread be modified from:
Embedded Basic Requirements (was Prop II: Too little, too late ???)
to:
Embedded BASIC Requirements (was Prop II: Too little, too late ???)
That's cheating! :-)
Pascal doesn't support dynamic strings or any kind of automatic garbage collection so I won't be able to steal your code!
Yeah, I know "BASIC" is an acronym but I think it might be best to forget that aspect of its history. After all, "IBM" doesn't mean "International Business Machines" anymore either.
Thanks for giving this thread a more positive title (and direction). I'm not sure when it switched to a discussion about Embedded Basic, but I'd like to second everything that potatohead said.
OBC
Here is a list of BASIC keywords I would suggest implementing in a Propeller based compiler:
#DEFINE
#ELSE
#ELSEIF
#IF
#IFDEF
#IFNDEF
ABS
ALLOCATE
AND
ANY
AS
ASC
ASIN
ASM
ATN
BLOAD
BSAVE
BYTE
CALL
CASE
CAST
CLOSE
CLS
COLOR
CONTINUE
DATA
DIM
DECLARE
DO..LOOP
DO..WHILE
DO..UNTIL
DRAW
ELSE
ELSEIF
END
END IF
ENUM
EOF
EOL
EXEC
FOR
FOR..NEXT
FUNCTION
GET#
GETKEY
GOTO
HEX
IF..THEN
INKEY
INPUT
INPUT#
INT
INTEGER
IS
LCASE
LEFT
LEN
LONG
LOOP
MID
MOD
NEXT
NEW
NOT
OCT
ON ERROR
OPEN
OR
PEEK
POINTER
POKE
POS
PRINT
PRINT#
PROCPTR
PTR
PUT#
RANDOMIZE
RANDOM
READ#
REM
RESET
RETURN
RND
SCREENSET
SEEK
SETMOUSE
SGN
SHL
SHR
SHORT
SLEEP
SPACE
SQR
STEP
STOP
STR
STRING
SUB
SWAP
TAB
TAN
THEN
THREADCREATE
THREADWAIT
TIMER
TO
TYPE
USIGNED
VAL
VAR
VARPTR
WAIT
WHILE
WEND
WITH
XOR
ZSTRING
Generally I'm not a BASIC user, but I would be a Propeller BASIC user if I could use external memory such as Flash and/or RAM (SRAM,SDRAM,etc....) for larger programs.
There is no external memory usability on any stand alone Propeller BASIC today. That's a shame to me at least.
David Betz XBASIC project would use external memory or just HUB memory. It is compiled basic and would run on any Propeller from HUB memory and platforms with external memory such as C3, SpinSocket-Flash, Gadget Gangster SDRAM, and DracBlade boards.
While I don't really think an embedded propeller language is so important, it should be possible to achieve with enough resources. Having the option to 1) build a program off-chip and download it or 2) edit and compile it on-chip would be nice. Right now it seems like an either/or situation. XBASIC can do it but maybe not in the first release.
To me some type of off-chip storage would be required for an "embedded" basic for decent sized programs. That would make it less "system on a chip embedded," but would be more useful in the long run for Propeller 1. If all you want to do is blink LEDs, then it doesn't really matter and something like femtoBasic should be suitable.
I guess hard core BASIC programmers have similar feelings about languages as C programmers. There is value in being practical though.
For me I think getting something that works well for many is a practical and fair target. From what I've seen so far, David Betz's XBASIC project offers quality (from a very smart and experienced developer) in a modern language variation. The project fits the goal of practical support for large external memory (and smaller HUB only) programs very nicely.
Embedded development is possible with XBASIC with SDCard, but it is unclear how valuable embedded development really is.
Bit operators and comparison operators.
AND, OR, NOT, XOR for both bit-wise masking, etc... and for comparisons.
Shift and rotate too.
Basic was originally invented to be a small, lean, simple language which could run on a computer with 4K of RAM. Since the Propeller has more than 4K of RAM it's a good candidate for a Prop language, but since cogs only have 512 Longs it is going to require some compromise even if we provide external memory support.
As an aside, VB was intended as a simple, robust, and very capable language to make a very difficult OS environment more accessible to less skilled programmers. They chose Basic syntax because most of the less skilled (e.g. not college educated in CS) programmers in 1990 had learned on platforms like the Apple ][ and Commodore 64 then QBasic and QuickBasic. VB was meant to be an easy migration path for them that would hide the complexity of the Windows environment and API and prevent the kind of obscure crash bugs that are possible when buffers are allowed to overrun and pointers are misused.
But any Propeller basic has to deal with the whole 2K cog + 32K hub thing even if there is XMM. I am working on a system which sorts a similar set of challenges, and while I chose Forth as my starting point instead of Basic (because I wanted to be able to compile new code on the Prop) many of the compromise decisions are made in the same design space. With this in mind may I suggest a peek at the blog post I wrote about the Windmill byte code interpreter: http://forums.parallax.com/entry.php?39-Windmill-Byte-Code-Interpreter
What I did there was sacrifice a little bit of code density over Spin by implementing a LMM-like scheme that essentially creates one-byte LMM versions of most PASM instructions, and using the 400 or so Longs this saves to implement more complex helper functions. It would be a trivial matter to compile BASIC source to this interpreter. One big win is that I was able to implement a full complement of random buffer and Pascal-style string functions. The cog has functions for string comparison, moving strings around, and even a code that can with the right parameters do things like UCASE, LCASE, or ASCII-Hex conversion. The importance is that these loopy functions are in the Cog written in PASM, so they are far faster than even optimized LMM library routines would be.
String manipulation is the single biggest weakness I see in Spin, and that is one reason for so much difficulty with things like filesystems and ethernet stacks, which are very heavily string oriented. You need PASM multiply and divide, which take maybe 20 longs and perform almost as well as hardware mul and div would in such an interpreter. Floating point is a crutch whose use should be discouraged, because it is very expensive both in time and memory terms. In order to make XMM transparent I decided to devote a second cog to that. (I got that cog back in my reference system by making it also implement the default TTY serial port.)
You are not going to have room to deal with any workable real-time garbage collection scheme either for random length strings or more abstract variables. For that matter dealing with var types other than string and Long will overcomplicate what is already a tight system. With XMM code you can afford to use Longs for all data. You distinguish between signed and unsigned by using appropriate operators.
Another issue is caching code that really has to run faster than it can from XMM. My experience is that most systems of this scale have a relatively small but important fraction of such routines. There needs to be a way to either move these to Hub RAM or temporarily cache them. (Windmill will permit both.) With an external compiler such a system can get pretty elaborate without straining the runtime environment.
Ultimately, there will be many compromises to make and many decisions which are more optimal for some projects than others; I'm targeting both my hardware selection and software environment at a particular class of instruments which require a limited but critical amount of time critical processing combined with some complex decision making and user interface maintenance that doesn't have to happen quite so fast. Other people however will have different needs; some will really need floating point, others might need the buffer overrun protection I decided to ditch. For the same reason that Propeller hardware solutions proliferate, I imagine Propeller development solutions will continue to do so as well.
I have attached the documentation.
The easiest way to try it is to use "TELNET 173.67.187.91" this will allow you to program my spinneret at my house.
Bean
I just tried this but got the following results:
What am I doing wrong?
PRINT on TV/VGA/Terminal no extra formatting.
INKEY For PS/2 or Terminal.
INPUT
GOTO
SUB With RETURN for function like functionality (Possibly limit to 6 Parameters).
COLOR
DRAW
FOR..NEXT
WHILE..WEND
Math functions.
+ - * / MOD XOR OR AND NOT
COGNEW
COGINIT
PININ
PINOUT
I'm not sure. I just reset it, try it again.
What type of computer are you using ? I know it works with windows telnet, I haven't tested it on any other OS.
Bean
I'm still getting the same result. I'm using a MacBook Pro under Mac OS X.
Whatever it's doing, it locks up the spinneret. I have reset it again.
I'll investigate and see if I can figure out what is happening.
Bean
Any combination of entries appears to result in the same error. Maybe it wants both CR/LF?
Yeah something is happening. I get the same error now.
I reset it again, but I don't have the time right now to diagnose the problem.
Something must be getting the input buffer messed up.
Bean
RossH and I have been quietly working on something like this. We have Basic running with XMM using a subset of the BCX to C translator http://www.bcxgurus.com/help/index.html
There is a catch and that is that BCX outputs a syntax that is not quite C89 C. But with a lot of behind the scenes modification, it is possible to have a Basic program, hit F12 and have it compiled and downloaded into external ram on a propeller.
Simple demo
This works, but with the command line for catalina being rather critical, there is an argument for making this command line part of the program. So add
And then the Basic purists might not like this, but there needs to be a way of including or not including modules which C needs, and so though this looks a bit like C, we add this at the beginning
And then it is a matter of testing every single command and to see if Catalina can handle the output. This is the test program so far
' Big Basic For external memory on the Propeller using BCX Basic To C converter And Catalina #include <stdio.h> #include <stdlib.h> #include <string.h> #include <math.h> #include <ctype.h> #include <errno.h> #include <float.h> #include <inttypes.h> #include <limits.h> '#include <mathconst.h> ' mathconst.h upsets tinyc $COMMAND catalina -lcx -lm -x5 -M 128k -D DRACBLADE -D VGA_HIRES ' library cx, library maths (slow, Doesn't use a cog), memory size, board, high res vga, mouse, keyboard $COMMAND Call WhiteOnBlue Dim a As integer Dim i As integer For a=1 To 3 Print "hello world"; Print a Next a $COMMENT ' file test copied from bcx examples - Files work - commented Out For speed Print "Opening file For output" Dim MyFileHandle@ ' BCX Reserves @ For "C" FILE* Data types Open "new.txt" For OUTPUT AS FP1 MyFileHandle@ = FP1 FPrint MyFileHandle@, "This is a test" Close FP1 Print "Closing file" $COMMENT ' ASC Function Dim Mystring$ As String * 80 ' 80 characters Dim RetVal% Mystring$="A" Print Mystring$ RetVal% = ASC(Mystring$) Print RetVal% 'CHR$ Function - opposite Of ASC a=65 Mystring$=Chr$(a) ' declared in asc Print "Character should be A: ";Mystring$ 'VAL Function - converts string To Double number. From the BCX help file Dim StringNum$ As String * 20 Dim RetDub# StringNum$="3.1415927" RetDub#=Val(StringNum$) Print RetDub# 'STR$ Function - opposite Of VAL. Converts number To string Dim RetStr$ As String * 20 Dim DoubleNumber# DoubleNumber# = 1.23456789 RetStr$ = Str$(DoubleNumber#) Print RetStr$ ' Test some inLine C code - pass a value in myarray, C changes it, Print the return value Dim myarray[5] As integer ' this can be much bigger If you like, eg 50000 myarray[1]=100 Print myarray[1] Call TestCCode Print myarray[1] ' test some string functions Dim lineoftext1$ As String * 80 ' strings must End in $ otherwise compiler Doesn't copy properly Dim lineoftext2$ As String * 80 lineoftext1$="Hello World" ' string name is Case sensitive lineoftext2$=Left$(lineoftext1$,4) ' left characters Print "Left$ test ";lineoftext2$ lineoftext2$=Mid$(lineoftext1$,5,4) ' mid characters Print "Mid$ test ";lineoftext2$ lineoftext2$=ucase$(lineoftext1$) ' upper case Print "Upper Case test ";lineoftext2$ lineoftext2$=Right$(lineoftext1$,3) ' right characters Print "Right$ test ";lineoftext2$ lineoftext1$="Hello" lineoftext2$="World" Concat(lineoftext1$,lineoftext2$) ' add two strings - same as + Or & in vb.net Print "String concat test ";lineoftext1$ lineoftext1$="ABCDEFG" lineoftext2$=lcase$(lineoftext1$) ' lower case Print "Lower Case test ";lineoftext2$ a=1000 lineoftext1$=Hex$(a) ' hex$ working Print lineoftext1$ Dim retval% ' hex2dec = two errors, DWORD (which I think can be changed To unsigned long) And CharLowerA which instr also is unhappy about retval%=hex2dec("0xFFFF") ' reverse Of hex$, can use 0x Or &H syntax Or even FFFF Print "Hex2Dec test ";retval% lineoftext1$="12345abc6789" lineoftext2$="abc" a=Instr(lineoftext1$,lineoftext2$,3,0) ' instr search For characters. Last value is needed, use dummy 0 (matches case) Print "Instr test, string is at position ";a a=255 lineoftext1$=bin$(a) ' test Binary lineoftext1$=lpad$(lineoftext1$,32,48) ' test adding leading zeros with lpad so is always 32 char long Print "Binary value is ";lineoftext1$ ' test Binary To strings And back again lineoftext1$="0000000001010101" Print "Binary string To decimal ";Bin2dec(lineoftext1$) ' Binary lineoftext1$=String$(10,65) Print "String Function ";lineoftext1$' n characters Of ascii value m lineoftext1$=" trim test " ' trim off leading zeros, spaces etc lineoftext1$=trim$(lineoftext1$) Print "Trim test:";lineoftext1$ ' test a string array Dim Stringarray[5] As String * 80 ' 80 characters Stringarray[1]="Hello" Stringarray[2]="World" Print Stringarray[2] ' bitwise operators - there are many more Of these but they all seem To work ok withOut code changes a=1 a=a << 10 Print "bitwise shift left";a a=a >> 4 Print "bitwise shift right";a a=1 a=a And 0xFF Print "logical and";a a=a Or 0xFF Print "logical or";a Print "test starting with a Binary string And shifting"; bin2dec("00000001") << 4 ' test program control Loops - For is already tested above a=1 Do Print a a=a+1 Loop Until a=3 Print "Do Loop finished" a=1 While a <3 Print a Incr(a)' translates To a++ in C Wend Print "Wend Loop finished" a=5 Select Case a Case 1 Print "1" Case > 1 And < 6 Print "more than 1 And less than six" Case Else Print "something Else" End select ' test functions Print addnumbers(5,6) ' test some maths with floating point numbers Dim number1 As Double number1=1.2345 Print number1 Print Sin(number1) Print Log(number1) $CCODE while(1); // Loop instead Of finishing $CCODE ' And exitprocess Does Not work on the propeller. So Don't use End For the moment ' Subroutines And functions Function addnumbers(a As integer, b As integer) Dim returnvalue As uint returnvalue = a + b function=returnvalue End Function Sub TestCCode $CCODE // declare the variables: int nNumber; int *pPointer; // now, give a value To them: nNumber = 15; pPointer = &nNumber; // Print Out the value Of nNumber: printf("nNumber is equal To : %d\n", nNumber); // now, alter nNumber through pPointer: *pPointer = 25; // prove that nNumber has changed as a result Of the above // by Printing its value again: printf("nNumber is equal To : %d\n", nNumber); myarray[1]=110; $CCODE End Sub Sub WhiteOnBlue() ' white text on blue background $CCODE int i; for (i=0;i<40;i++) { t_setpos(0,0,i); // move cursOr To Next line t_color(0,0x08FC); // RRGGBBxx eg dark blue background 00001000 white text 11111100 } $CCODE End SubI am not sure if this would be useful or not. I got sidetracked with getting plugins working on catalina, but if there is enough interest maybe this could be useful?
How advanced is your Pascal Compiler ?
1) Given the Prop's memory mix, one item I'd place high in the list, is the ability to run(fetch byte codes) from QuadSPI memory, in a choice of counts. ( some call this execute in place )
QuadSPI are SO8, so are small, and cheap and a single device can hit 52MBytes/sec, two give 104Mbytes/sec (etc).
The choice of chip counts works like this :
One reads a nibble at a time, Two streams a Byte, Three Streams 12 bits, 4 streams 16 bits, (etc)
Also, this memory has a jump cost, so a skip(0..5) type byte-code 'fits' well, with the streaming data
2) The source code should have 'linking' options, to allow placing/preloading of (small) sections of code into Prop on-chip memory.
3) In line ASM - it's ok if this has caveats, but variable access should be implicit.
4) Block comments, and nested comments and clone the // as line comment.
5) Simple Source Debug Pin-tag commands, so that users can map a Pin for CRO/Counter debug, then use commands like
6) and since I am on a roll, a choice of code generation
a) byte code intended to be interpreted
b) machine code, intended to be placed in a cog. This would typically include in-line-asm, and code b) would have a size ceiling, and a destination specified.
Thanks for the pointer. This looks very interesting. You've made very clever use of the unique features of the Propeller instruction set. I skimmed through your blog and I think I get the gist of what you're proposing but I was wondering if you had a summary of the bytecodes you ended up with. Is the code available for this VM?
The Pascal compiler is quite simple. Basically supporting standard variable types, arrays, structures, simple expressions (only limit is no more than 8 operators in an expression), and most of the standard language. It should be fairly simple to modify to compile a different language (once it is done). Though I have not yet even announced this project (do not wish to get peoples hopes up), my mention of it above was just to tell David Betz that it will be a while before I can even think about making a BASIC compiler (besides the other projects that I am working on, and getting a bit behind on some of).