Shop OBEX P1 Docs P2 Docs Learn Events
Compiler for generating PASM code — Parallax Forums

Compiler for generating PASM code

Peter VerkaikPeter Verkaik Posts: 3,956
edited 2008-10-31 08:25 in Propeller 1
Hi,
I have lost track of all the available compiler tools presently available or developed.
Is there a compiler that could generate PASM code that we·subsequently can call
from spin code?
As an example,·the compiler should be able to generate PASM code·like
the pasm code in the FullDuplexSerial object,·but the source would be a·high level language.
Once compiled, the pasm code can be pasted into a DAT section.
This compiler should·make the task of writing drivers much easier and hide all
the assembly difficulties like selfmodifying code. Code needs to be generated
for a single cog only.

regards peter

Comments

  • hippyhippy Posts: 1,981
    edited 2008-10-30 17:12
    Funnily enough I was thinking along the same lines a few days back; something which is an intermediate step between Spin and raw PASM. The question though is what is the problem one is trying to solve, what abilities would this higher-level-than-assembler language need, why not simply use PASM ?

    The currently best candidate would seem to be ImageCraft C but that doesn't quite fit with generating raw PASM.
  • Mike GreenMike Green Posts: 23,101
    edited 2008-10-30 17:44
    Peter,
    I have my doubts. We're talking about a very limited amount of memory (496 instructions max.) shared with data. For simple drivers, it might make sense, but it wouldn't take much code complexity or tight timing constraints for this scheme to be useless because either the code wouldn't fit or would require so much hand editing for the timing to come out right (or both) that you might as well code it from the beginning in assembly. For complicated drivers, you'd already be up against the space limitation from the beginning.

    For simple code sequences that require high speed execution, it would make sense. Carl Jacob's Forth compiler has provisions for this sort of thing (I'm not sure if they're in there yet) and ImageCraft's C compiler should be able to do this soon as well, compiling short sections of C code to Propeller instructions that are copied into a cog buffer alongside the LMM interpreter and executed directly.
  • ImageCraftImageCraft Posts: 348
    edited 2008-10-30 20:10
    @Mike

    ImageCraft Propeller C already supports FCACHE, so small loop runs at near native speed.
  • Carl JacobsCarl Jacobs Posts: 41
    edited 2008-10-30 22:06
    Mike Green said...
    For simple code sequences that require high speed execution, it would make sense. Carl Jacob's Forth compiler has provisions for this sort of thing (I'm not sure if they're in there yet) and ImageCraft's C compiler should be able to do this soon as well, compiling short sections of C code to Propeller instructions that are copied into a cog buffer alongside the LMM interpreter and executed directly.
    I hadn't thought of JDForth as an answer to this question, but it certainly would work for including snippets (or more) of assembly code.

    I think that a *lot* of people have thought that JDForth is a forth compiler and that's it. They don't want to get stuck with it because it's forth. But, it can also be used in quite a different way. JDForth makes it relatively easy to write function engines which get called from spin. I believe the most commonly used·function engine is the float32lib object. The typical calling pattern from spin is something like:
      func_ptr := _sin_func         ' func_ptr gets read by assembly cog 
      repeat while func_ptr         ' func_ptr gets set to 0 once complete
    

    Using JDForth you can do something very similar. It allows you to write assembly words that get included dynamically at run time. There are a number of examples that utilise this features, most notably SimplexSerial (which is like SimpleSerial but can handle 2M baud) and the FAT16 demo·(which is a combination of fsrw.spin and sdspifasm.spin)

    Mike, the dynamic PASM functionality has been present from day 1. What hasn't been there was the ability to compile an interactive forth environment - which will be released on Saturday (1 Nov 08).


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Carl Jacobs


    JDForth - Forth to Spin Compiler http://www.jacobsdesign.com.au/software/jdforth/jdforth.php
    Includes: FAT16 support for SD cards. Bit-bash Serial at 2M baud. 32-bit floating point maths.·Fib(28) in 0.86 seconds. ~3x faster than spin, ~40% larger than spin.
  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2008-10-31 08:25
    Thanks for the responses. I don't know Forth so I will give an example using C syntax.
    Since a cog assembly program accepts only 1 long parameter this can be passed to main().
    The assembly program starts at main. We can only declare long variables.

    #pragma COGONLY //Set the target to COG generated assembly only
    long myVarArray[noparse][[/noparse]5]; //just some example variables
    long index;

    void main(long address_or_value) { //execution starts here, address_or_value is passed from spin
    · //code to retrieve table from hubmemory in case of passed address
    · //initialize additional variables and set I/O pins
    · while (true) { //mainloop
    · }
    }

    @ImageCraft,
    Is it possible to set the target environment to COG only for example,
    meaning FCACHE size is set to 512 longs (or 496 longs)·and just filled with assembly instructions, no LMM·kernel.
    I used #pragma to declare that target (I don't know if you use·#pragma but you get the idea).
    If your C compiler could support this that would be really great.
    Since memory resources are low calling subroutines with local variables should be limited
    or at least use static assigned memory areas for local variables.

    regards peter
Sign In or Register to comment.