Interactive Spin to Pasm or C converter

12467

Comments

  • Rsadeika wrote: »
    I installed spin2cpp for linux, and was testing the --binary part. I believe this is supposed to be the way you would get an LMM of a Spin program if you were not using the new GUI program.

    ./spin2cpp.linux --asm --binary led.spin, does not work, it just comes up with the notice as to the correct way of using spn2cpp.
    $ /opt/spin2cpp/bin/spin2cpp |& head -1
    Spin to C++ converter version 3.0.1
    $ /opt/spin2cpp/bin/spin2cpp --asm --binary led.spin
    (yeti@aurora:13)~/wrk/propeller/spinsim/tmp$ # no output
    (yeti@aurora:13)~/wrk/propeller/spinsim/tmp$ ls
    led.binary  led.pasm  led.spin
    

    If you want LMM add "--code=hub".
    $ cat Hello.spin 
    CON
      _clkmode = xtal1 + pll16x
      _clkfreq = 80_000_000
    
    OBJ
      fds : "FullDuplexSerial.spin"
    
    PUB demo | i
    
      '' start up the serial port
      fds.start(31, 30, 0, 115200)
    
      '' and say hello
      repeat 3
        fds.str(string("Hello, world!", 13, 10))
    
    $ # FullDuplexSerial is in the same directory
    $ /opt/spin2cpp/bin/spin2cpp --asm --binary --code=hub Hello.spin 
    (yeti@aurora:12)~/wrk/propeller/spinsim/tmp$ ls
    FullDuplexSerial.spin  Hello.binary  Hello.pasm  Hello.spin
    $ /opt/spin2cpp/bin/spin2cpp --asm --binary --code=hub Hello.spin 
    $ ls
    FullDuplexSerial.spin  Hello.binary  Hello.pasm  Hello.spin
    $ /opt/spinsim/bin/spinsim Hello.binary -b
    Hello, world!
    
    Hello, world!
    
    Hello, world!
    
    
    Rsadeika wrote: »
    Using the command line also grates on my nerves, even after a short time.
    That's not the commandline's fault.
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ No Source – No Go! ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷ ◁ Stop slavery! Free all mitochondria! ▷
  • Presumably you need to have prop-gcc installed on your machine. Which provides propeller-elf-gcc.

    You can get that by installing SimpleIDE or straight from the prop-gcc repository.
  • yetiyeti Posts: 597
    edited 2016-03-29 - 13:23:45
    No... LMM works without PropGcc...
    I don't have it in the path, so my example would have failed if propeller-elf-gcc would be needed...

    PropGcc comes into the game if you translate Spin-->C(++)-->binary.

    Spin-->LMM-PASM-->binary works using spin2cpp alone...


    Spin-->C++-->binary example failing first when propgcc is not in PATH
    $ ls -l
    total 32
    -rw-r--r-- 1 yeti yeti 24962 Mär 29 15:20 FullDuplexSerial.spin
    -rw-r--r-- 1 yeti yeti   772 Mär 29 15:20 mandelbrot-20140623-fds-80x25.spin
    $ echo $PATH
    ~/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
    $ /opt/spin2cpp/bin/spin2cpp --binary mandelbrot-20140623-fds-80x25.spin 
    sh: 1: propeller-elf-gcc: not found
    $ PATH=/opt/parallax/bin:$PATH /opt/spin2cpp/bin/spin2cpp --binary mandelbrot-20140623-fds-80x25.spin 
    $ ls -l
    total 60
    -rw-r--r-- 1 yeti yeti  7798 Mär 29 15:23 FullDuplexSerial.cpp
    -rw-r--r-- 1 yeti yeti  1029 Mär 29 15:23 FullDuplexSerial.h
    -rw-r--r-- 1 yeti yeti 24962 Mär 29 15:20 FullDuplexSerial.spin
    -rwxr-xr-x 1 yeti yeti  5104 Mär 29 15:23 mandelbrot-20140623-fds-80x25.binary
    -rw-r--r-- 1 yeti yeti  1215 Mär 29 15:23 mandelbrot-20140623-fds-80x25.cpp
    -rw-r--r-- 1 yeti yeti   746 Mär 29 15:23 mandelbrot-20140623-fds-80x25.h
    -rw-r--r-- 1 yeti yeti   772 Mär 29 15:20 mandelbrot-20140623-fds-80x25.spin
    $ /opt/spinsim/bin/spinsim mandelbrot-20140623-fds-80x25.binary -b
    !!!!!!!!!!!!!!!"""""""""""""####################################""""""""""""""""
    !!!!!!!!!!!!!"""""""""#######################$$$$$$$%'+)%%%$$$$$#####"""""""""""
    !!!!!!!!!!!"""""""#######################$$$$$$$$%%%&&(+,)++&%$$$$$$######""""""
    !!!!!!!!!"""""#######################$$$$$$$$$$%%%%&')*4:/+('&%%$$$$$$#######"""
    !!!!!!!!""""#####################$$$$$$$$$$%%%&&&''),:::::::,'&%%%%%$$$$########
    !!!!!!!"""####################$$$$$$$$%%%&'())((())*,::::::/+))('&&&&)'%$$######
    !!!!!!""###################$$$$$%%%%%%&&&'+.:::/::::::::::::::::/++:..9:%%$#####
    !!!!!"################$$$%%%%%%%%%%&&&&'),+1:::::::::::::::::::::::::1(&&%$$####
    !!!!"##########$$$$$%%&(-(''''''''''''(*,5::::::::::::::::::::::::::::+)-&%$$###
    !!!!####$$$$$$$$%%%%%&'(*-:1.+.:-4+))**:::::::::::::::::::::::::::::::4-(&%$$$##
    !!!!#$$$$$$$$$%%%%%%'''++.6:::::::::8/0::::::::::::::::::::::::::::::::3(%%$$$$#
    !!!#$$$$$$$%&&&&''()/-3.5::::::::::::::::::::::::::::::::::::::::::::::'&%%$$$$#
    !!!(**+/+:523/:0/46::::::::::::::::::::::::::::::::::::::::::::::::4+)'&&%%$$$$#
    !!!#$$$$$$$%&&&&''().-2.:::::::::::::::::::::::::::::::::::::::::::::::'&%%$$$$#
    !!!!#$$$$$$$$$%%%%%&'''/,.7::::::::::/0::::::::::::::::::::::::::::::::0'%%$$$$#
    !!!!####$$$$$$$$%%%%%&'(*-:2.,/:-5+))**:::::::::::::::::::::::::::::::4+(&%$$$##
    !!!!"##########$$$$$%%&(,(''''(''''''((*,4:::::::::::::::::::::::::::4+)-&%$$###
    !!!!!"################$$$%%%%%%%%%%&&&&'):,4:::::::::::::::::::::::::/('&%%$####
    !!!!!!""##################$$$$$$%%%%%%&&&'*.:::0::::::::::::::::1,,://:)%%$#####
    !!!!!!!"""####################$$$$$$$$%%%&(())((()**-::::::/+)))'&&&')'%$$######
    !!!!!!!!""""#####################$$$$$$$$$$%%%&&&''(,:::::::+'&&%%%%%$$$########
    !!!!!!!!!"""""#######################$$$$$$$$$$%%%%&')*7:0+('&%%%$$$$$#######"""
    !!!!!!!!!!!"""""""######################$$$$$$$$$%%%&&(+-).*&%$$$$$$######""""""
    !!!!!!!!!!!!!"""""""""#######################$$$$$$%%'7(%%%$$$$$######""""""""""
    !!!!!!!!!!!!!!!""""""""""""#####################################""""""""""""""""
    
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ No Source – No Go! ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷ ◁ Stop slavery! Free all mitochondria! ▷
  • Ah, gotcha. I have to play with this some more.
  • Rsadeika wrote: »
    Back on topic. I installed spin2cpp for linux, and was testing the --binary part. I believe this is supposed to be the way you would get an LMM of a Spin program if you were not using the new GUI program.

    ./spin2cpp.linux --asm --binary led.spin, does not work, it just comes up with the notice as to the correct way of using spn2cpp.

    Aargh! Sorry, it appears that when I created the .zip file it built fresh versions of the Windows and Linux32 binaries, and then used the old ones :(. So the v3.0.0 zip file actually had v1.94 binaries in it, which of course did not work. This was only a problem for the command line tools, the spincvt.zip file with the GUI had the right binary.

    I've uploaded a new .zip file that has the correct binaries in it, and v3.0.1. Thanks for catching this.
    Using the command line also grates on my nerves, even after a short time.

    You said you had the GUI working under Wine (and I've verified that it works as well), so why not use that? Just check the "Make Binary" menu item under "Options" and it will produce a .binary file for you in the same directory as the original .spin.

    You can also check out the spin2cpp source code from git and then use spinconvert.tcl (with "wish spinconvert.tcl") as a native GUI, but that's not something I test a whole lot -- most Linux users seem to prefer the command line.

    Thanks,
    Eric
  • Heater. wrote: »
    Presumably you need to have prop-gcc installed on your machine. Which provides propeller-elf-gcc.

    You can get that by installing SimpleIDE or straight from the prop-gcc repository.

    As Yeti has already mentioned, for Spin -> C/C++ -> binary we need propeller-elf-gcc, but for Spin -> PASM -> binary spin2cpp is all you need (since spin2cpp is able to translate PASM to binary on its own, and with the new changes it's also able to translate Spin to PASM). So there are basically two paths for creating LMM binaries from Spin now: the PropGCC code generator and the spin2cpp built in code generator. PropGCC is generally going to produce better code, but on a few examples spin2cpp does better on its own. spin2cpp does whole program analysis (so it can inline better) and has a slightly better peephole code generator, but of course PropGCC has a whole lot of optimizations that spin2cpp lacks.

    The main advantages of spin2cpp over PropGCC are simplicity (not much to install) and transparency (the generated PASM is easier to read).

    Eric
  • Sounds brilliant Eric. Sadly I forgot to pack a Propeller on my current trip. Grrr...
  • yetiyeti Posts: 597
    edited 2016-03-29 - 14:02:58
    Heater. wrote: »
    Sounds brilliant Eric. Sadly I forgot to pack a Propeller on my current trip. Grrr...
    <jedi hypno trick> You want to build/use spinsim... </jedi hypno trick>
    ;-)
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ No Source – No Go! ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷ ◁ Stop slavery! Free all mitochondria! ▷
  • Yeti,

    Mono tone voice "Want spin2cpp, want spin2cpp, ... brainz"

    No chance whilst I'm travelling though.


  • You said you had the GUI working under Wine (and I've verified that it works as well), so why not use that? Just check the "Make Binary" menu item under "Options" and it will produce a .binary file for you in the same directory as the original .spin.
    There was a strong suggestion, by someone, to just do it in a command line with a script file. I have gedit, plus I added the plugin to able to use the commands option, now I will see how long it takes before I completely lose interest in working with these tools.

    Since my intention was to see how a Spin LMM program works, I also downloaded BSTC and BSTL, so obviously you need those to test this thing out. I am getting fidgety(start of grate) just thinking about implementing this already, not sure how long I will last.

    Ray
  • I just downloaded spin2cpp_v3.0.1.zip, and it only contains spin2cpp.exe, no linux version.

    Ray
  • Rsadeika wrote: »
    I just downloaded spin2cpp_v3.0.1.zip, and it only contains spin2cpp.exe, no linux version.

    Ray

    If you don't want the full package that Eric provides, you can download just the Linux executable from here (this link will always provide most up-to-date version from the master branch)
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • Rsadeika wrote: »
    I just downloaded spin2cpp_v3.0.1.zip, and it only contains spin2cpp.exe, no linux version.

    Man, today is not my day for making releases.

    Well, let's try again. Just for you, Ray, I've made a Linux GUI version (uploaded as spincvt_3.0.2_linux.zip in
    https://github.com/totalspectrum/spin2cpp/releases/tag/v3.0.2). In fact this is a Linux only release, Windows users should keep using 3.0.1 for now. I've also added a "Run on device" option to the GUI, so this package should have everything you need to compile and run -- do not try to use bstc or bstl. If you do want to try out the command line, use propeller-load and spin2cpp from the bin directory.

    Some caveats:

    (1) You'll need tcl/tk to be installed on your system. For Debian this is done with "apt-get install tk", if you don't already have it.
    (2) The "Run on device" only supports having one Propeller plugged into your system at a time.
    (3) The terminal is fixed to 115200 baud.
    (4) I really don't want to support a GUI, so this is probably as much of an IDE as spin2cpp is likely to develop :).

  • I am playing around with the latest release (Windows GUI) and what a freaking wonderful thing this is. I can't wait to actually do some useful work with it! Thank you for your efforts on this very useful software.

    Mekkatronix@yahoo.com
  • Thank You Eric.
    General observations on spincvt for Linux:
    Since I am running Ubuntu 15.10, Tk is already installed, but in order to run spincvt(spinconvert) you also need Tklib(sudo apt-get install Tklib), otherwise you get a ctext error. Since this is a script file you will have to start it in a command line, ./spinconvert.

    One little item is really missing, burn it to the eeprom. I figure once you have a little program the way you like it, chances are you will want it on the eeprom.

    I noticed that the left side of window has a very minimal editing capability, meaning you could create a spin file, and then save it. This is a very good minimalist approach, and it did work as expected on all of the Spin programs that were in the examples folder. I also tried the programs with the LMM setting, which also worked as expected.

    As an aside, I did not know you could program with Tk in a bash script file. So, the spinconvert script file would be a good example to use if you wanted to create a quick? GUI program, I think. WOW, learn something new everyday here.

    Ray
  • I have been playing around with spincvt for linux, and I am finding this program very interesting. I think that this could be a better option than PropBasic, for the new and old users.

    Since I already stated that one of the more interesting parts about this is the LMM component, I guess I need some more info about this. When you have the settings set to PASM and LMM, and you RUN the code, is the program running 4 times slower, than what? Because the resulting code is now PASM, my assumption would be that the LMM part would only have an affect on the length of the program, lines of code, and not necessarily slow things down, or am I all wet on this point.

    Will spincvt be able to handle the big programs, as an example, maybe something like femtoBasic, this is only one that I could think of that everybody is familiar with. Or something like the code that is available for the Hackable Badge. I have always had the fear of using Spin with the Hackable Badge because of the memory issues, now with the LMM component available, it seems like that could alleviate some concerns about running out of memory space.

    Not sure if this would be feasible, since spincvt has two windows, one with the original Spin program, and the other with the converted program, is there a way of having a code size shown for the programs? For me, it would be interesting to see what the code size differences are when you choose the differnt conversion choices, especially when you use the LMM mode.

    As I use this program more, I will probably have more questions. Oh man, C is starting to slip away as my main programming language choice.

    Ray

  • PASM generally refers to the assembly language code that runs inside a COG, at full speed. A Cog can only hold 512 instructions, so such full speed programs are very limited in size.

    One approach to allowing PASM programs to be bigger is to use overlays. The idea of an overlay is that you reserve an area of COG into which your PASM program will fetch other PASM code, usually from HUB memory, and execute it. This way one can load many different bits of PASM code into that reserved buffer as and when required. Some versions of my Z80 emulation used overlays to implement lesser used Z80 instructions.

    In the extreme one can shrink the overlay buffer to a single LONG and have a tight PASM loop that fetches one instruction at a time from HUB and executes it. Bill Henning was the first to so this and called it Large Memory Model (LMM).

    With LMM your PASM programs can now be the full size of HUB.

    Except it's not quite PASM. One has to take care in handling jumps, calls and returns.

    The LMM fetch execute is very small so max execution speed of LMM instructions is at most one quarter of native PASM speed.

    Compiling Spin to LMM will result in faster execution than Spin byte code but LMM code is bigger.




  • PASM generally refers to the assembly language code that runs inside a COG, at full speed. A Cog can only hold 512 instructions, so such full speed programs are very limited in size.

    One approach to allowing PASM programs to be bigger is to use overlays. The idea of an overlay is that you reserve an area of COG into which your PASM program will fetch other PASM code, usually from HUB memory, and execute it. This way one can load many different bits of PASM code into that reserved buffer as and when required. Some versions of my Z80 emulation used overlays to implement lesser used Z80 instructions.
    Interesting, if you think in terms of how a Spin program is designed, you would have a main PUB, which would contain your buffer mechanism, and all of support PUBs could be set up as subroutine's that would fit in the buffer zone when converted to PASM and used with LMM. WOW, that would be one heck of a conversion program, your program, the essential part would be running full tilt in the small COG space. I do not think that I have seen any Spin programs set up that way.

    I guess you could have the best of both, a large program running in a limited COG space. So, with spincvt, I wonder if there is a specific programming model that should be considered, in order to take real advantage of this conversion program?

    Ray
  • Not sure what to think of this.

    In the spincvt examples folder I have three files: hello.spin (221 bytes), hello.binary (1.7 kB), and hello.pasm (27.4 kB). Glancing at this, I would think, hello.spin (221 bytes), would be the choice too run, very small code size, so surely it would RUN much faster than the other two versions, right? So, we know that is not the case, but the PASM version is so much bigger, byte size. When you start getting to the nitty gritty, this all starts to get very confusing. When you start thinking about using Spin, in these terms, it should take a very long time to get a decent program that you should be using.

    Ray
  • Rsadeika wrote: »
    Since I already stated that one of the more interesting parts about this is the LMM component, I guess I need some more info about this. When you have the settings set to PASM and LMM, and you RUN the code, is the program running 4 times slower, than what? Because the resulting code is now PASM, my assumption would be that the LMM part would only have an affect on the length of the program, lines of code, and not necessarily slow things down, or am I all wet on this point.
    Instructions can only be run in COG memory. With LMM mode (i.e. when code is placed in hub memory) we have to fetch each PASM instruction from hub in order to run it. You can actually see the LMM loop in the generated code, it looks like:
    LMM_LOOP
        rdlong LMM_i1, pc
        add    pc, #4
    LMM_i1
        nop
        rdlong LMM_i2, pc
        add    pc, #4
    LMM_i2
        nop
        rdlong LMM_i3, pc
        add    pc, #4
    LMM_i3
        nop
        rdlong LMM_i4, pc
        add    pc, #4
    LMM_i4
        nop
        jmp    #LMM_LOOP
    
    To improve the speed it's been unrolled four times, but the basic idea is: read the instruction in from the hub (pc points to the instruction) into cog, increment the pc, execute the instruction.
    Will spincvt be able to handle the big programs, as an example, maybe something like femtoBasic, this is only one that I could think of that everybody is familiar with.
    It looks like FemtoBasic is too big for the PASM code generator (it produces too many variables in COG memory). FemtoBasic also exposed a bug in the C++ code generator. After fixing it the resulting binary is 31K long when compiled with -Os and -mcmm, so it fits but just.

    The big advantage of the original Spin bytecodes is that they are small, but they are slow. spinconvert offers the choice to switch this and have a much faster program, but one that takes up quite a bit more room.
    Not sure if this would be feasible, since spincvt has two windows, one with the original Spin program, and the other with the converted program, is there a way of having a code size shown for the programs?
    That would be interesting, but at present I have no way to tell the original Spin bytecode size. I could show the size of the compiled PASM code I guess. Note that LMM mode doesn't make much difference to the size of the PASM output. It's a little bit bigger because we need the LMM interpreter and some branches need an extra instruction, but otherwise the code is the same, just placed in hub instead of cog.

    Regards,
    Eric
  • Rsadeika wrote: »
    One approach to allowing PASM programs to be bigger is to use overlays. The idea of an overlay is that you reserve an area of COG into which your PASM program will fetch other PASM code, usually from HUB memory, and execute it. This way one can load many different bits of PASM code into that reserved buffer as and when required. Some versions of my Z80 emulation used overlays to implement lesser used Z80 instructions.
    Interesting, if you think in terms of how a Spin program is designed, you would have a main PUB, which would contain your buffer mechanism, and all of support PUBs could be set up as subroutine's that would fit in the buffer zone when converted to PASM and used with LMM. WOW, that would be one heck of a conversion program, your program, the essential part would be running full tilt in the small COG space. I do not think that I have seen any Spin programs set up that way.

    I guess you could have the best of both, a large program running in a limited COG space. So, with spincvt, I wonder if there is a specific programming model that should be considered, in order to take real advantage of this conversion program?

    Actually the scheme above would be slower than LMM in some (perhaps many) cases. For example, if your overlay contains any kind of conditional execution (if/else or case) then in an overlay you'd be spending cycles loading the unused portion of the code from hub. LMM has the advantage that if only loads code that is actually about to be executed. Even for straight line code LMM is faster than an overlay load plus execute, because LMM interleaves the loading and execution; this allows code to execute while we're waiting for the hub access window to come around again.

    The one place where an overlay would be significantly faster would be for loops, since in that case the hub load cost is amortized over the loop executions. PropGCC has a mechanism called FCACHE that effectively turns small loops into overlays that are loaded into cog memory from hub and then run from there. I plan to do something similar for spin2cpp.

    Regards,
    Eric
  • Rsadeika wrote: »
    Not sure what to think of this.

    In the spincvt examples folder I have three files: hello.spin (221 bytes), hello.binary (1.7 kB), and hello.pasm (27.4 kB). Glancing at this, I would think, hello.spin (221 bytes), would be the choice too run, very small code size, so surely it would RUN much faster than the other two versions, right? So, we know that is not the case, but the PASM version is so much bigger, byte size. When you start getting to the nitty gritty, this all starts to get very confusing. When you start thinking about using Spin, in these terms, it should take a very long time to get a decent program that you should be using.

    Ray

    Comparing hello.spin to the .bin and .pasm versions is not valid. Hello.spin is the text file and includes objects, typically at least a serial object or tv/vga object to display the output. Code for those objects get added to hello.bin and hello.pasm. In spite of being much larger hello.pasm would probably run the fastest as long as the speed of I/O (outputting "hello world") did not limit the overall speed.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • Further testing, I downloaded CreateOI.spin from the OBEX, and when I ran it with spinconvert I get:
    ...DynamicMathLib_short: No such file or directory
    child process exited abnormally
    Another suggestion, maybe a cut and paste in the window that lists the errors. I am not sure if the problem is the '_' in the name, or something else. The other thing that I noticed is that the object name is 'DynamicMathLib_Short.spin', in the CreateOI.spin program OBJ -> d : "DynamicMathLib_short", is there a case sensitivity issue here? I do not want to change the original program just yet to test it out, maybe it is something else.

    Ray
  • Rsadeika wrote: »
    In the spincvt examples folder I have three files: hello.spin (221 bytes), hello.binary (1.7 kB), and hello.pasm (27.4 kB). Glancing at this, I would think, hello.spin (221 bytes), would be the choice too run, very small code size, so surely it would RUN much faster than the other two versions, right?

    You're getting off on the wrong foot. The *only* thing the Propeller can run is a .binary file. hello.spin is source code, which must be translated to binary, either by openspin or the Propeller Tool (which will translate the spin to byte codes which are then interpreted by the ROM spin interpreter) or by spincvt (which will translate the spin to pasm, and then translate the pasm to instructions executed by the COG). Both hello.spin and hello.pasm are source code, intended to be read by humans but not usable directly by the hardware.

    So for an apples to apples size comparison you have to compile hello.spin with openspin. You'll get a 320 byte hello.binary which could be run on the hardware, but which will not work properly (the spin bytecode file executes too slowly to keep up with the 115200 baud output that we requested).

    Compiled with spincvt with --code=cog the binary is 528 bytes; in LMM mode (--code=hub) the binary is 724 bytes.
  • If you want to get a feel for relative speed and size, change fibo.spin so that it uses FullDuplexSerial.spin instead of SimpleSerial.spin. This will allow us to use the same source code for openspin and spincvt (as mentioned, the SimpleSerial object cannot keep up at 115200 baud when compiled by openspin). We can then compile it 3 ways and compare the results:
    compiled with openspin (ROM bytecode interpreter):
    fibo.binary is 960 bytes
    fibo(20) = 6765  time taken: 44832912 cycles (560 ms)
    
    compiled with spincvt COG mode (directly executed in COG):
    fibo.binary is 2132 bytes
    fibo(20) = 6765  time taken: 2977168 cycles (37 ms)
    
    compiled with spincvt LMM mode (executed by LMM interpreter):
    fibo.binary is 2396 bytes
    fibo(20) = 6765  time taken: 10507664 cycles (131 ms)
    

    We can also convert the spin code to C and compile it with PropGCC:
    converted to C and compiled with PropGCC in LMM mode:
    fibo.binary is 3960 bytes
    fibo(20) = 6765  time taken: 6830256 cycles (85 ms)
    
  • Rsadeika wrote: »
    Further testing, I downloaded CreateOI.spin from the OBEX, and when I ran it with spinconvert I get:
    ...DynamicMathLib_short: No such file or directory
    child process exited abnormally
    Another suggestion, maybe a cut and paste in the window that lists the errors.

    I'm pretty sure cut and paste should work for all the windows; just select the text and use ^C, ^X, and ^V (or use the Edit menu).
    The other thing that I noticed is that the object name is 'DynamicMathLib_Short.spin', in the CreateOI.spin program OBJ -> d : "DynamicMathLib_short", is there a case sensitivity issue here?
    Yes, Linux file systems are case sensitive, so on Linux the names have to match exactly. That's a common issue with things from the OBEX, and affects every Linux compiler (bst, spin2cpp, openspin, etc.).

    Thanks,
    Eric
  • I'm pretty sure cut and paste should work for all the windows; just select the text and use ^C, ^X, and ^V (or use the Edit menu).
    Yes, it works, I just used highlite, and then right click copy... I guess I missed a step. :-)

    Yep, if you are working in a Linux setting, and downloading an object from the OBEX, you have to be very careful about the case issue. On the larger more complex object programs, you would spend a lot of time editing the complete program, and then not really sure if it is making subtle changes which would make it not to work as expected.

    I just tried the CreateOI.spin program with PropellerIDE, after fixing the obvious case issues, and using 'Build', PropellerIDE crashed, not sure what went wrong there.

    Ray
  • jmgjmg Posts: 13,993
    ersmith wrote: »

    We can also convert the spin code to C and compile it with PropGCC:

    Interesting numbers - is there a fcache/COG mode possible in PropGCC, that you could add ?

  • ersmith wrote: »
    Rsadeika wrote: »
    Further testing, I downloaded CreateOI.spin from the OBEX, and when I ran it with spinconvert I get:
    ...DynamicMathLib_short: No such file or directory
    child process exited abnormally
    Another suggestion, maybe a cut and paste in the window that lists the errors.

    I'm pretty sure cut and paste should work for all the windows; just select the text and use ^C, ^X, and ^V (or use the Edit menu).
    The other thing that I noticed is that the object name is 'DynamicMathLib_Short.spin', in the CreateOI.spin program OBJ -> d : "DynamicMathLib_short", is there a case sensitivity issue here?
    Yes, Linux file systems are case sensitive, so on Linux the names have to match exactly. That's a common issue with things from the OBEX, and affects every Linux compiler (bst, spin2cpp, openspin, etc.).

    Thanks,
    Eric

    BST on Linux doesn't require cases of OBJ filenames to match. Openspin does seem to, though. It probably wouldn't be a bad idea for you to fix this in spincvt, for compatibility reasons.
  • I decided to try spincvt on some more likely type of conversions. I am using the code provided by Jon McPhalen, specifically jm_ebadge_2015-07-01b.spin and associated objects. Did not work as expected.

    In the options, I have PASM and Binary, but I noticed in my folder that it only contains .pasm file but no .binary file.

    spincvt produced a PASM file, with this:
    ./bin/spin2cpp --noheader -g --asm --code=cog --data=hub --binary -o /home/ray/Downloads/work/spincvt/examples/work/jm_ebadge_2015-07-01b.binary /home/ray/Downloads/work/spincvt/examples/work/jm_ebadge_2015-07-01b.spin
    /home/ray/Downloads/work/spincvt/examples/work/jm_ebadge_2015-07-01b.pasm:3111: error: fit 496 failed: pc is 1257

    When you try to RUN, it comes up with an Application error:
    Propeller Version 1 on /dev/ttyUSB0
    error: failed to open '/home/ray/Downloads/work/spincvt/examples/work/jm_ebadge_2015-07-01b.binary'
    error: load failed
    child process exited abnormally
    Propeller Version 1 on /dev/ttyUSB0
    error: failed to open '/home/ray/Downloads/work/spincvt/examples/work/jm_ebadge_2015-07-01b.binary'
    error: load failed
    child process exited abnormally
    while executing
    "exec bin/propeller-load -r $binfile"
    (procedure "doRun" line 19)
    invoked from within
    "doRun "
    invoked from within
    ".#mbar.#mbar#run invoke active"
    ("uplevel" body line 1)
    invoked from within
    "uplevel #0
      " (procedure "tk::MenuInvoke" line 50) invoked from within "tk::MenuInvoke .#mbar.#mbar#run 1" (command bound to event)
    I thought I would just start by showing this preliminary error stuff, before I start to attach any files. I have not tried this program using the normal methods, like the Propeller Tool, but, I know that Jon only provides fully tested and working programs.

    Ray
Sign In or Register to comment.