Shop OBEX P1 Docs P2 Docs Learn Events
Embedded Basic Requirements (was Prop II: Too little, too late ???) — Parallax Forums

Embedded Basic Requirements (was Prop II: Too little, too late ???)

David BetzDavid Betz Posts: 14,516
edited 2011-05-12 10:21 in Propeller 1
(I've started this new thread to avoid hijacking the Propeller 2 thread)
davidsaunders wrote: »
Leon:
No it is not, though neither is this old school thing (VB) that you keep mentioning. Unfortunately I am not aware of any complete BASIC compilers that are good for embedded development. Perhaps PropBASIC could become one if the effort is put into it to make it a complete BASIC Compiler.

Please define "complete BASIC Compiler". 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.

Thanks,
David
«13

Comments

  • LeonLeon Posts: 7,620
    edited 2011-05-11 07:47
    Turing-complete? :)
  • David BetzDavid Betz Posts: 14,516
    edited 2011-05-11 07:55
    Leon wrote: »
    Turing-complete? :)

    In that case I'm sure PropBasic already qualifies! :-)

    Seriously, I'd like this thing that I'm building to be useful. Can you suggest what features it needs to have beyond the normal variables, assignment statements, if/then/else, loops, functions with parameters, etc? Obviously, it will need some equivilent to waitcnt, waitpne, waitpeq to be useful on the Propeller and also access to the COG registers like dira, ina, outa, etc. What else?
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-05-11 08:01
    It needs to be capable of running startrek.bas. :)
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-11 08:03
    David-Betz:
    A complete BASIC by modern standards (to the way I understand) would be as fallows:
    1) Generation 2 Structured BASIC structure and syntax.
    2) Includes all the ANSI BASIC keywords.
    3) Has minimally the types:
    3.A) LONG
    3.B) SHORT
    3.C) BYTE
    3.D) STRING
    3.E) UNSIGNED (modifier)
    3.F) INTEGER
    3.G) FLOAT (some use REAL instead).
    3.H) User types (Array, TYPE...END TYPE, etc).
    3.G) Pointer types, for all types (including FUNCTION/SUB, and ANY PTR).
    4) Typed, all variables must be declared.
    5) Scope declaration for all variables and pointers.
    6) Dynamic memory allocation.
    7) Compiled language.

    Some would say that the OO features are needed, I disagree, BASIC does not have to be OO.

    The above list represents what appears to be standard for modern BASICs, as far as I am aware.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-11 08:05
    Dave Hein:
    We are not talking about a early generation BASIC here.

    Leon:
    I think that all BASICs are Turing complete.
  • ctwardellctwardell Posts: 1,716
    edited 2011-05-11 08:05
    @David, I'd like to suggest that you add a comment to the top post asking others to stay on focus:

    1) No BASIC bashing
    2) No arguments over Open Source, Eclipse, Microsoft...

    that said...

    It should support different memory models, at least the following:

    PASM Only, code fits in a cog, all native PASM
    LMM
    XMM

    The ability to have inline PASM,LMM,XMM code would be nice.

    Defines: #ifdef, etc.

    I'm sure there is more.

    C.W.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-11 08:10
    I had forgot:
    Ideally (not required), it should be self compiling.

    ctwardell:
    Thank You.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-05-11 08:11
    davidsaunders wrote: »
    3.D) STRING
    3.E) UNSIGNED (modifier)
    3.G) FLOAT (some use REAL instead).
    6) Dynamic memory allocation.

    Okay, this is getting at what I'm looking for. In particular, do people think that dynamic strings are necessary in an embedded Basic? While it isn't that hard to implement a heap manager, it complicates the runtime significantly for possibly litte benefit (other than being able to run startrek.bas!). I tried this in an earlier version of my compiler but later realized that adding functions with parameters makes having dynamically allocated objects much harder. You have to be able to locate all "live" objects when the garbage collector is called and that requires that you know the type of every item on the stack. Maybe there is a simple way to handle this but I couldn't think of anything other than having a type tag associated with every stack entry or some sort of arguments/locals type map associated with every function.

    So my question is, are dynamic strings really necessary? If so, does someone have a good idea of how to handle them in an embedded runtime environment?
  • Bill HenningBill Henning Posts: 6,445
    edited 2011-05-11 08:14
    Personally, I'd skip dynamic strings, and have a declaration like:

    STRING(80) line_buff, args

    and I'd probably just use plain null-terminated strings

    This would allow string overruns, however we are talking about a small microcontroller with limited resources - trying to shoehorn some big system features is contra-indicated if the plain 32K hub model is to be well supported.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-11 08:15
    I do not think that Dynamic strings are needed.

    Though Dynamic memory with ALLOCATE, FREE keywords is needed. Also there is no reason to track every type (except in the case of using Dynamic Strings [not needed]).
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-05-11 08:18
    davidsaunders wrote: »
    Dave Hein:
    We are not talking about a early generation BASIC here.
    Oh, that's too bad. So what basic are you talking about? Post a link to the language definition. It would be foolish to invent yet another basic language when there are so many out there to choose from. Any Prop-specific stuff should be done in a standard way. In C, they would just be instrisic functions that look like library functions.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-11 08:18
    Bill:
    I think you mean:
    DIM MyStr AS STRING 80

    Is this correct? Remember this is BASIC.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-11 08:20
    I think that Most would agree that FreeBASIC is representative of the definition of Modern BASIC. See the Wiki documentation on freebasic.org.
  • PublisonPublison Posts: 12,366
    edited 2011-05-11 08:21
    Completely OT, but since your both here:

    Happy Birthday Leon and davidsaunders!
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-11 08:24
    Publison:
    Thank You.
  • Bill HenningBill Henning Posts: 6,445
    edited 2011-05-11 08:28
    I agree ...

    Happy Birthday Leon and David Saunders!
  • Bill HenningBill Henning Posts: 6,445
    edited 2011-05-11 08:30
    Hi David,

    I was thinking early generation basic, as that is a closer fit to the size of a Prop board... you are entirely correct with regards to the syntax of more modern basic's declaration of fixed length strings :-)
    davidsaunders wrote: »
    Bill:
    I think you mean:
    DIM MyStr AS STRING 80

    Is this correct? Remember this is BASIC.
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-05-11 08:31
    davidsaunders wrote: »
    I think that Most would agree that FreeBASIC is representative of the definition of Modern BASIC. See the Wiki documentation on freebasic.org.
    OK, I looked at the Wikipedia entry for FreeBASIC, which says it's based on QuickBASIC, which I guess was the basis for MS VisualBASIC. It looks a lot like C++, so why not just do C++?
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-11 08:35
    Yes it was based on QB, though has evolved to include the features that we now rely on. As to it looking a lot like C/C++, the same could be said for just about any structured language looking a lot like just about any other structured language. I would note that most do not use the OO extensions.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-11 08:38
    While much of it probably does not apply to embedded development the documentation for the FreeBASIC language can be found at:
    http://www.freebasic.net/wiki/wikka.php?wakka=DocToc
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-05-11 08:43
    So it seems like you won't be able to avoid dynamic memory allocation. Objects will need to be created and destroyed. I did a linked-list malloc in 80 longs in Spin -- it's not that hard to implement. I don't know what dynamic strings are, but I would guess that they grow and shrink in size as string operations are performed. That's not hard to do either. I'm doing that in the VI editor I'm working on, which is written for both C and Spin.
  • RsadeikaRsadeika Posts: 3,837
    edited 2011-05-11 08:48
    I would have to agree, with using freeBASIC as the model. Since I have used freeBASIC, this would work for me. There is a programing feature in freebASIC that allows you to use threads, which would work quite well for the use of the cogs, I think?

    Ray
  • David BetzDavid Betz Posts: 14,516
    edited 2011-05-11 09:14
    Dave Hein wrote: »
    So it seems like you won't be able to avoid dynamic memory allocation. Objects will need to be created and destroyed. I did a linked-list malloc in 80 longs in Spin -- it's not that hard to implement. I don't know what dynamic strings are, but I would guess that they grow and shrink in size as string operations are performed. That's not hard to do either. I'm doing that in the VI editor I'm working on, which is written for both C and Spin.

    Explicit memory allocation isn't a problem. It's automatic garbage collection that is difficult. You have to know the type of every value.
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-05-11 09:22
    So you tag each variable. I clearly don't understand the problem. I'll probably bow out of this thread since I have no interest in object oriented Basic. It seems like the people who like to program in this flavor of Basic should get together and write a compiler for the Prop.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-05-11 09:29
    Dave Hein wrote: »
    So you tag each variable. I clearly don't understand the problem. I'll probably bow out of this thread since I have no interest in object oriented Basic. It seems like the people who like to program in this flavor of Basic should get together and write a compiler for the Prop.
    There isn't a problem conceptually. It's just that if you are compiling the Basic code down into bytecodes and you want the bytecode engine to run on a COG you run out of space rapidly for features l like tag checking and garbage collection. If you're willing to write the bytecode engine in C and run it out of external memory then everything becomes easy to implement and very slow to execute.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-11 09:34
    If all allocation is explicit, then leave it to the programmer to remember to free the memory they allocate. I do not see any reason for needing automatic garbage collection. just as we do for C/C++ if we do not free something that we allocate that is on us (and one heck of a leek).
  • David BetzDavid Betz Posts: 14,516
    edited 2011-05-11 09:40
    davidsaunders wrote: »
    If all allocation is explicit, then leave it to the programmer to remember to free the memory they allocate. I do not see any reason for needing automatic garbage collection. just as we do for C/C++ if we do not free something that we allocate that is on us (and one heck of a leek).
    Yes, that is very possible.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-11 09:42
    It would seem most logical to compile to PASM and use a LMM model where in you feed in 4 or 8 longs at a time (using a specific routine in the LMM kernel to call SUB/FUNCTIONS and another to do any JMPS). I do not understand the reason to slow it down any more than this by using Bytecode interpreters.

    Not to mention that you would probably want to be able to compile somethings to fit entirely in cog memory, for time critical applications. Though for stuff that must fit entirely in a COG I would omit the dynamic allocation functions.

    Heap management is not that difficult. Just tag the length of the block of memory so that when the block is explicitly freed you know how much is freed, also keep it as a linked list (with all this in the 3 WORDS right before the block).
  • LeonLeon Posts: 7,620
    edited 2011-05-11 09:43
    Publison wrote: »
    Completely OT, but since your both here:

    Happy Birthday Leon and davidsaunders!

    Thanks!

    I'm 69, BTW.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-05-11 09:46
    davidsaunders wrote: »
    It would seem most logical to compile to PASM and use a LMM model where in you feed in 4 or 8 longs at a time (using a specific routine in the LMM kernel to call SUB/FUNCTIONS and another to do any JMPS). I do not understand the reason to slow it down any more than this by using Bytecode interpreters.

    Not to mention that you would probably want to be able to compile somethings to fit entirely in cog memory, for time critical applications. Though for stuff that must fit entirely in a COG I would omit the dynamic allocation functions.

    Heap management is not that difficult. Just tag the length of the block of memory so that when the block is explicitly freed you know how much is freed, also keep it as a linked list (with all this in the 3 WORDS right before the block).

    I suspect what you describe is perfectly possible. It's just that it would take far more effort than I'm able to put into it at the moment. I'll wait for your implementation! :-)
Sign In or Register to comment.