Shop OBEX P1 Docs P2 Docs Learn Events
PropellerForth Help — Parallax Forums

PropellerForth Help

rpraverrpraver Posts: 19
edited 2007-07-25 05:56 in Propeller 1
I recently downloaded the PropellerForth from Parallax and can't seem
to get it to execute on my Hydra. I then tried to get access to the source
code and that can't be located either at Parallax or the developers home page.
Has anyone gotten it to execute on the Hydra and if so can I get a copy
of your? Also if anyone has the source I would appreciate that also.

Thanx

Post Edited (rpraver) : 7/22/2007 4:33:49 AM GMT

Comments

  • LeonLeon Posts: 7,620
    edited 2007-07-22 16:28
    Where is it? I'd like to try it.

    Leon

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Amateur radio callsign: G1HSM
    Suzuki SV1000S motorcycle
  • rpraverrpraver Posts: 19
    edited 2007-07-23 06:54
    Goto following location:
    http://www.cliff.biffle.org/software/propeller/forth/sources.php
    and follow the prompts
  • mirrormirror Posts: 322
    edited 2007-07-23 07:42
    rpraver said...
    Goto following location:
    http://www.cliff.biffle.org/software/propeller/forth/sources.php
    and follow the prompts
    Many of us have tried it. Many times. Have you?
  • simonlsimonl Posts: 866
    edited 2007-07-23 12:55
    Yeah, I don't think the binary was setup for the Hydra, and Cliffe's not posted any source.

    It looks like Cliffe's given-up on it; he says this in his tech blog "PropellerForth has stalled due to profound lack of interest from the Propeller community".

    That's a real shame. I was following his thread with interest, but as he was having issues with his comm's implementation I was waiting for his next release.

    COME BACK CLIFFE - PropellerForth IS being followed yeah.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheers,

    Simon
    www.norfolkhelicopterclub.co.uk
    You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
    BTW: I type as I'm thinking, so please don't take any offense at my writing style smile.gif
  • rpraverrpraver Posts: 19
    edited 2007-07-23 14:38
    Are there any people out there interested in Forth for the Propeller.
    I am now completeing a version for Briel Replica Apple that works.
    If someone can convince Cliff to release the code I would be happy
    to take a crack at completeing it.
    BTW, I would be targeting the Hydra.
    See that I am new to the Propeller, it would be a big help.
    I also just about completed a tcc version to Briel Apple also.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2007-07-23 15:37
    If you haven't read this thread then read it -> "Multitasking token threaded Forth" http://forums.parallax.com/showthread.php?p=607346

    Cliff did do a 'demo' Forth but it was not compiled using the Propeller IDE tool so therefore it could not benefit from being able to use contributed objects.

    RP, trying to work from somebody else's custom tools and source can be a lot harder than starting from scratch so don't think getting source will make it easier. Writing a Forth for the Propeller is very different to writing a Forth for conventional processors so it does require some work.

    Anyway, besides myself it seems like deSilva&Co are coming out with a Forth implementation too so no need to beat a dead horse when there are two live ones in the starting gate.

    *Peter*
  • rpraverrpraver Posts: 19
    edited 2007-07-23 16:20
    Well, I can appreciate that, but seeing that there is no viable anything
    yet pertaining to forth on the Propeller and that only 2 maybes exist,
    then possibly more might help creating a succesful release of atleast one
    instead of multiple still borns.
    Off hand just for the PC, Apple etc I beleive there were multiple flavours
    out there, MVP, Fig, Miller, Atlast .... etc
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2007-07-23 22:53
    rp, the word stillborn means dead before it was born which is what has become of Cliff's PropForth as it was never properly birthed. Meanwhile you have at least two experienced chefs with all the ingredients busy in the kitchen preparing up a feast, do you really think you are going to miss out on dinner so that you are going to microwave some frozen leftovers?

    BTW, in regards to the Apple Forth I've written "industrial strength" Forths for a variety of 6502ish architectures including the 65C816 and the Mitsubishi M37702 amongst many other architectures.

    *Peter*
  • rpraverrpraver Posts: 19
    edited 2007-07-24 00:27
    Well apparently you seem to be the one and only. Yet people like myself that
    have been in the business since 1978, both hardware and software might be able
    to cobble out a functional thingy that may work. It has been my experience that
    if there is enough people interested and motivated that some things may come to
    fruition .
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2007-07-24 00:56
    Ok rp, my point was really then why don't you look at writing you own version seeing you have the experience rather then trying to work with some unobtainable and limited source? I could offer to share source with you if you wanted to contribute but I'm still at the stage where I am getting a feel for way it should be so I don't want to get bogged down in spec'ing and being locked into it. Think of this as an IRON CHEF opportunity.

    I appreciate your experience concerning both interest and motivation and it is also your interest as well as others which is motivating me to put more time into the Forth that will, not may work.

    *Peter*
  • rpraverrpraver Posts: 19
    edited 2007-07-24 01:22
    I am pretty much the same place as you. I was hoping to see how someone had approached
    an implementation so I could use that as jumping off platform. I want to try a small single cog
    version first to play with the stack issues and base it on a minimal cross of Loeliger, MVP and Fig
    ie. 79 standard. Then see where that may land me.
  • Fred HawkinsFred Hawkins Posts: 997
    edited 2007-07-24 05:48
    The big problem with Forth on the Propeller is everything. A 496 long assembly environment. A hub memory that can be addressed by bytes, words and longs but is ruled by a compiler whose directive set is yoked to object programming. A RISC machine language that lacks auto increments, decrements, byte and word access in the cogs but 9 bit writing ability here and there. Address spaces that fit comfortably in words but must be addressed by longs (hub) or as 9 bits (cog). No stacks that aren't hand coded.

    A nice puzzle. My fig forth source has 41 primitives of which a subset might fit into a cog. My thinking these days is to have the name fields separate from the code fields, a 16 bit implementation, and the TIB in hub memory. The io words KEY, EMIT, BLOCK, all are complicated by the variety of input/output devices or lack thereof -- making provisions for someone else's hardware (2x40 lcd here, what's your flavor?) will be problematic. The assembler looks simpler than making a 68000 version.

    Deciding on how much the inner interpreter looks like another FORTH is a big choice. Yes, it could be made familiar but the propeller suggests almost from the first bit of work that it will be unlike any other. Self-modifying code! worries the hell out of me. And it might be inescapable.

    Ah well. I reread some notes on FORTH tonight that I wrote 21 years ago. Who could imagine that a propeller would provoke such archaeology? What fun!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2007-07-24 06:27
    Problem? Nahhhh [noparse]:)[/noparse]

    The cog memory is sufficient for the core words, a bit MISCish but not overly. However, other than pointers all buffers need to be in hub memory and even the stacks in my current model. 16bit implementation? That usually refers to the word size that is handled natively by the Forth VM and on 32-bit machines it will always be 32-bits at least. But I think you mean 16-bit indirect-threaded address model which is limited to 64K normally. My ARM Forth OS uses byte tokens very successfully and efficiently and I have seen no reason not to do so in Propeller Forth.

    As to I/O there should be no problem as objects can be wrapped to accept in/out data from Forth and Forth I/O vectors are just that, vectors that can be changed. In Forth I could easily say:
    LCD CR ." LCD test "PrintDate PrintTime 
    VGA CR ." VGA test " PrintDate PrintTime
    COM1 CR ." COM1 test " PrintDate PrintTime
    



    BLOCK is a real throwback although I have something similar for virtual memory control but I try and keep that transparent.

    I just had a forum member on the phone saying quote "who uses Forth?". Of course I had to laugh as us Forthers just "use the Forth" and I myself have it embedded in a plethora of products over the years. But once again if you prefer strict syntax and prefix rather than stack based postfix you will always compare Forth with your compiler when in fact there can be no such comparison. The Forth resides on the target whereas a language only exists in the development environment. Interestingly Spin generates byte tokens and runs a VM (Virtual Machine) from what I can see so at least at the runtime level it is more akin to Forth than normal compiled code.

    I never really liked Forth on PCs as it really makes a lot more sense on embedded systems so I don't take part in all those boring discussions on language refinements etc. Forth gets my job done pronto and it's fun to work with otherwise I would go to sleep working with a "compile/syntax errors/keep the compiler happy/repeat/download/run and then figure out what just didn't happen" environment. The Propeller itself is fun and teamed up with Forth it's even more fun. Notice I keep using the word "fun" because I don't treat this as work and when it's fun it also stimulates the brain into coming up with better ways of doing things.


    *Peter*
  • SkogsgurraSkogsgurra Posts: 231
    edited 2007-07-24 07:39
    Peter,

    If people wonder "Who uses Forth?" then tell them that Forth programmers do. Simple as that.

    "And, who migt that be?" is the possible next question. "Lots of people" I would say. People that write code for embedded systems. People that want an efficient environment instead of anxiously trying to keep syntax correct (which seems to be a main goal in academia) and people that like to have fun at work.

    I would very much welcome a stable Forth for the Prop. It doesn't need to be a full Forth. But full enough to do bit banging, 16 bit arithmetic and some text/number I/O. That would go a long way. Any bonus material is welcome. And I think there are quite a few of us that are willing to pay enough to make it worth while.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2007-07-24 08:12
    Skogsgurra said...
    there are quite a few of us that are willing to pay enough to make it worth while

    Cough..... In the spirit of the Propeller community CogForth (PropForth was taken I think) will be compilable by anyone and free. I benefit because I have a Forth to use with my now favorite chip and I also benefit from all the work from contributed objects and forum expertise. What beta testers can do is to help test and document all the little bits and pieces though and extend the kernel with application code when a beta is released. Gee, I really have to get a move on with this Forth, the pressure's on.

    *Peter*
  • SkogsgurraSkogsgurra Posts: 231
    edited 2007-07-24 09:15
    Of course, there are even more of us willing not to pay smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • Fred HawkinsFred Hawkins Posts: 997
    edited 2007-07-24 13:58
    Peter Jakacki said...
    Problem? Nahhhh [noparse]:)[/noparse]

    The cog memory is sufficient for the core words, a bit MISCish but not overly. However, other than pointers all buffers need to be in hub memory and even the stacks in my current model. 16bit implementation? That usually refers to the word size that is handled natively by the Forth VM and on 32-bit machines it will always be 32-bits at least. But I think you mean 16-bit indirect-threaded address model which is limited to 64K normally. My ARM Forth OS uses byte tokens very successfully and efficiently and I have seen no reason not to do so in Propeller Forth.

    As to I/O there should be no problem as objects can be wrapped to accept in/out data from Forth and Forth I/O vectors are just that, vectors that can be changed. In Forth I could easily say:
    LCD CR ." LCD test "PrintDate PrintTime 
    VGA CR ." VGA test " PrintDate PrintTime
    COM1 CR ." COM1 test " PrintDate PrintTime
    



    BLOCK is a real throwback although I have something similar for virtual memory control but I try and keep that transparent.

    I just had a forum member on the phone saying quote "who uses Forth?". Of course I had to laugh as us Forthers just "use the Forth" and I myself have it embedded in a plethora of products over the years. But once again if you prefer strict syntax and prefix rather than stack based postfix you will always compare Forth with your compiler when in fact there can be no such comparison. The Forth resides on the target whereas a language only exists in the development environment. Interestingly Spin generates byte tokens and runs a VM (Virtual Machine) from what I can see so at least at the runtime level it is more akin to Forth than normal compiled code.

    I never really liked Forth on PCs as it really makes a lot more sense on embedded systems so I don't take part in all those boring discussions on language refinements etc. Forth gets my job done pronto and it's fun to work with otherwise I would go to sleep working with a "compile/syntax errors/keep the compiler happy/repeat/download/run and then figure out what just didn't happen" environment. The Propeller itself is fun and teamed up with Forth it's even more fun. Notice I keep using the word "fun" because I don't treat this as work and when it's fun it also stimulates the brain into coming up with better ways of doing things.


    *Peter*

    Throwback, eh? I'll sic my '79 dog on you! We are not old, merely been down the road a bit.

    Seriously, thanks for the advice. (Relaxing about stuff that I don't know enough about). Is that MISCellaneous?

    Fred
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2007-07-24 15:25
    Hi Fred,
    That's MISC, as in Minimal Instruction Set Computer. en.wikipedia.org/wiki/Minimal_instruction_set_computer

    BLOCK was a great word when floppies were around as it was tied in with Forth screens which were simply 1K blocks of virtual memory running off the disk drive. With my SD memory I do something similar in that I treat the SD memory as flat virtual memory and build the file system on top of that again. So virtual memory is handled just like normal memory and uses similar words such as XC@ in place of C@ to fetch a byte and so on. The filesystem is normally setup as FAT16 not that this is a good thing, especially for SD cards but because it is readable by PCs. So if I was looking up a filename in the root directory it would use the virtual memory access words as in this simple example. Notice XADR which actually translates a virtual memory address into a hub memory address by reading in the sector if necessary and returning with the corresponding address.

    : FindFile$    ( str -- dir.addr|FALSE )
        @fhandle 20d ERASE        \ clear all file ptrs
        fname$ $!                       \ save the file name
        MOUNT? DUP 0EXIT        \ skip if there is no card mounted - return with FALSE
        DROP                            \ discard flag
        @ROOT                           \ start from root directory
          BEGIN
          DUP XC@                       \ check 1st byte of directory entry if non-zero
          WHILE
          DUP XADR fname$ 11d COMPARE$    \ compare the dir string with the input fname$ over 11 characters
          ?EXIT                \ Exit with the dir address if there was a match
          BL +                \ jump to next entry assuming 8.3 names on 32 byte boundaries
          REPEAT
        DROP 0                 \ null terminated directory
        ;
    
    : BackupLogFile ( rename the current log file and close )
        LOG.TXT ?OPEN$                \ open current log file
        DIR@ XADR StampFileName XFLUSH
        CloseLogFile            \ set file size and close
        NewLogFile
        ;
    
    



    With Forth you can define words and actions such as PLAY to accept a name and find and play that if it is a WAV audio file.
    : PLAY ( <name> -- )    | $" WAV" defext$ $! || OPEN |> ;
    
    


    Having defined PLAY it can now be compiled into another definition or simply interpreted from the command line thus:
    PLAY PACABEL

    So words don't have to be letters and numbers as the word |> is the symbol for PLAY vs || as the symbol for PAUSE/STOP.

    But enough of this for now as I need to get the kernel up and running.

    *Peter*
  • rpraverrpraver Posts: 19
    edited 2007-07-25 04:48
    I can't seem to find the equivalent instruction of

    $+2 ' current address + 2 bytes

    in the assembler instruction set.
    Any help?
  • deSilvadeSilva Posts: 2,967
    edited 2007-07-25 04:57
    To what assembler do you refer to??
  • rpraverrpraver Posts: 19
    edited 2007-07-25 05:04
    In the Propeller Tool IDE under the DAT section
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2007-07-25 05:17
    I know that has to be a trick question as well as a new thread. Assembler instructions only compile into cog memory which is not byte accessible. Address+2 is 8 bytes difference. If you start a new thread and rephrase your question, maybe be more specific, I'm sure you will receive a suitable answer.

    *Peter*
  • deSilvadeSilva Posts: 2,967
    edited 2007-07-25 05:20
    o.k.: No, there no such thing as $+2.
    IMO there are four reasons for needing that kind of expression:
    (a) aligning to some address:
    ORG ($+3)/4*4
    This will rarely be needed within COG code, but is sometimes useful in SPIN (i.e. 64 byte alignment for video tiles)
    In fact there is no org except ORG 0 (which indeed is needed for multi COGs code within one object!

    (b) reducing the size of the load object
    As the COG loader just copies 2k of the HUB RAM, there is no way of utilizing gaps inbetween; you can only avoid HUB space allocation AT THE END of the COG code (RES-directive)

    (c) saving labels, i.e.
    JMP $ ' endless loop
    Never a good practice...

    (d) checking address overflows
    IF ($>$100) ABORT
    The last application will need more features of a macroassembler to be useful

    ---
    But maybe this it OT in this thread...

    Post Edited (deSilva) : 7/25/2007 5:31:29 AM GMT
  • rpraverrpraver Posts: 19
    edited 2007-07-25 05:35
    Here is my problem, if you look at the psuedo code


    PSUEDO FORTH (ala R. G. Loeliger)
    @A->B       The contents of the memory location word whose address is in 
                register A are loaded into register B.(a 16 bit indirect fetch
                from A to B)
    A=A+n       The contents of register A are incremented by the constant n
    POP S->A    The S push down stack top entry is loaded into the A register 
                and the stack pointer is adjusted.
    PSH A->S    The register A contents are loaded in the S push down stack and 
                the stack pointer is adjusted.
    A->PC       The contents of the A register are loaded into the PC register. 
                The processor will fetch its next instruction from this location.
    JMP ##      Unconditional jump to the address contained in the word 
                following the JMP instruction. (specific address or label)
    ##->A       Load register A with either a number or label value
    
    REGISTERS
    IP      Instruction Pointer, point to next instruction to executed
    WP      Word Pointer, current word being executed
    RP      Return Stack
    SP      Stack
    PC      Program counter, current machine instruction that CPU executes
    CA
    
    COLON   PSH IP->RS
            WP->IP
            JMP NEXT
    SEMI    $+2
            POP RS->IP
    NEXT    @IP->WP
            IP=IP+2
    RUN     @WP->CA
            WP=WP+2
            CA->PC
            3, 'DUP'        ; NFA   4 Bytes
            0000            ; LFA   2 Bytes
    DUP     $+2             ; CFA   2 Bytes
            POP SP->CA      ; PFA   2 Bytes
            PSH CA->SP      ;       2 Bytes
            PSH CA->SP      ;       2 Bytes
            JMP NEXT        ;       3 Bytes
            4, 'DROP'       ; NFA   5 Bytes
            DUP             ; LFA   2 Bytes
    DROP    $+2             ; CFA   2 Bytes
            POP SP->CA      ; PFA   2 Bytes
            JMP NEXT        ;       3 Bytes
    
    



    As can be seen I am trying to implement the inner interpreter and I am
    new to the Propeler environment. I am having a real problem in finding
    the equivilent op code to accomplish the above.
    Any info?

    Post Edited (rpraver) : 7/25/2007 5:43:42 AM GMT
  • Fred HawkinsFred Hawkins Posts: 997
    edited 2007-07-25 05:47
    Put a label on the line and then use operator arithmetic.

    here long #here+2
  • Mike GreenMike Green Posts: 23,101
    edited 2007-07-25 05:51
    I think first you need to learn the Propeller architecture and instruction set. For example, there are no indexed instructions ... all array access to local memory (the 512 long words) within a processor is done using instruction modification and it's only long word addressable. Shared memory (the 32K bytes) works a bit like an I/O device ... there are special instructions to read and write this shared memory as bytes, words, and long words.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2007-07-25 05:56
    Study the architecture, this is not a conventional processor, there are no "registers", just 9-bit addresses which you could treat as registers or whatever so no need to think of accumulators etc. Trouble is you are trying to do this lego style and as much as they are nicely colored none of the bricks you have fit the Propeller. Solution? Make your own bricks.

    *Peter*
Sign In or Register to comment.