Shop OBEX P1 Docs P2 Docs Learn Events
Porting OpenSpin, and Proploader to RISC OS — Parallax Forums

Porting OpenSpin, and Proploader to RISC OS

davidsaundersdavidsaunders Posts: 1,559
edited 2015-04-27 11:01 in Propeller 1
I have successfuly compiled OpenSpin on RISC OS, I still need to test it.

I do not yet know how well it works, though it compiles, and it displays the help message. I have attached the source as modified to successfuly build openspin on RISC OS.
attachment.php?attachmentid=113994&d=1429896386


I am taking some time to attempt to port OpenSpin and the propeller loader to RISC OS, as I am tired of dealing with Linux (Linux is a great OS for some things, just not what I do).

I have began looking through the source, and I have a couple of questions to aid in the porting process:
1: Does anyone know where all the file IO is located (I am sure I will find it soon, though it would help)?
2: What is the minimum version of GCC for a succesful compile??
3: Are there any other simi OS-Specific things I should know of (anything that is not part of the CPP standard)?
4:What is the worste case total memory usage?

Same questions about the loader.

Once I get OpenSpin working on RISC OS:
I intend to add spin, PASM, and PropBASIC highlighting to !Zap (Programmers Text Editor), as well as implementing RISC OS ToolBox throwbacks for OpenSpin (allows the editor to identify the line of an error, and such).

Then I will make a RISC OS WIMP front end for OpenSpin.

A good syntax highlighting text editor plus good front ends for the compiler(s), assembler(s), resource editor(s), etc, make for a programming enviroment on RISC OS that is easier to use than traditional IDE's, and creats a faster development cycle.
«1

Comments

  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-23 18:59
    I am back at my RPi with a little time to spend on this, and was hoping someone would know some of this before I get started digging through the source code.

    Oh well I will let people know what I find on this subject.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-23 19:15
    As they say you have to begin somewhere, so I began with make and the results were somewhat dissapointing (a missing file).

    attachment.php?attachmentid=113990&d=1429841713
    644 x 387 - 9K
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-24 06:58
    I have half way gotten it to compile, still likely to be some FS errors.

    attachment.php?attachmentid=113991&d=1429883852
    644 x 726 - 16K
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-24 07:04
    I have gotten it to compile as far as a.libopenspin. Now just to get it to compile the rest of the way.

    Then I will have to find any and all fs format errors in the code. RISC OS uses the "." as a dirrectory sepperator, and one of two means of extensions, either a forward slash or putting it in a dir of the name of the extension (hence a.libopenspin instead of libopenspin.a, openspin is in the directory a).

    Though I am one third of the way to a usable compile :) .
  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-24 07:07
    I have half way gotten it to compile, still likely to be some FS errors.

    attachment.php?attachmentid=113991&d=1429883852
    This is very odd. One of the errors complains about a "narrowing conversion" from unsigned int to int. Do they really have different sizes for signed and unsigned int?
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-24 07:10
    David Betz wrote: »
    This is very odd. One of the errors complains about a "narrowing conversion" from unsigned int to int. Do they really have different sizes for signed and unsigned int?

    No they are the same size (32 bit), if you look at the C++11 standard this is a correct warning, as you are narrowing in that you loose the sign.
  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-24 07:14
    No they are the same size (32 bit), if you look at the C++11 standard this is a correct warning, as you are narrowing in that you loose the sign.
    I guess that makes sense. I haven't tried using C++11 yet. I'm beginning to dislike C and C++ given the number of warnings and errors they are adding to try to avoid things like buffer overrun errors. Maybe it's time to admit that C isn't up to modern programming needs and pick a new "default language'.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-24 07:19
    David Betz wrote: »
    I guess that makes sense. I haven't tried using C++11 yet. I'm beginning to dislike C and C++ given the number of warnings and errors they are adding to try to avoid things like buffer overrun errors. Maybe it's time to admit that C isn't up to modern programming needs and pick a new "default language'.

    Yea it seems that way for sure, even Object Pascal is better suited it seems to me (heck even compiled BBC BASIC V [the version in RISC OS] seems better than modern C).

    Though most things are written in either C or C++ so we often have to deal with it.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-24 07:22
    I am so accustomed to using the Norcroft C amd C++ compiler on RISC OS that I did not know of one big advantage of GCC:

    GCC uses UnixLib by default for its shared C lib. That means that the pathnames are not an issue (other than using a directory for the extension as described above), so I am happy :).

    So I should be able to compile the OpenSpin compiler with out having to change the source :) .
  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-24 07:27
    Yea it seems that way for sure, even Object Pascal is better suited it seems to me (heck even compiled BBC BASIC V [the version in RISC OS] seems better than modern C).

    Though most things are written in either C or C++ so we often have to deal with it.
    Yes, the biggest reason to use C or C++ is that they are available everywhere. It will be a long time before they get replaced by anything new I think. However, I would not want to move to any language that doesn't have a modern standard and that rules out any form of BASIC. I don't know about Pascal standards because I haven't used Pascal in ages. I would think there must be better than Pascal though. I guess I should look at some of the more modern languages like maybe D.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-24 07:31
    I am doing this by writing a simple build script, after coppying all the files into the extension dirrectory eg BlockNestStackRoutines/cpp is coppied to cpp.BlockNestStackRoutines.

    echo Compile openspin
    dir PropellerCompiler
    
    g++ -DGCC -Wall -g -static -o BlockNestStackRoutines.o -c BlockNestStackRoutines.cpp
    ECHO BlockNestStackRoputines.o DONE
    g++ -DGCC -Wall -g -static -o CompileDatBlocks.o -c CompileDatBlocks.cpp
    ECHO CompileDatBlocks.o DONE
    g++ -DGCC -Wall -g -static -o CompileExpression.o -c CompileExpression.cpp
    ECHO CompileExpresion.o DONE
    g++ -DGCC -Wall -g -static -o CompileInstruction.o -c CompileInstruction.cpp
    ECHO CompileInstruction DONE
    g++ -DGCC -Wall -g -static -o CompileUtilities.o -c CompileUtilities.cpp
    ECHO CompileUtilities.o DONE
    g++ -DGCC -Wall -g -static -o DistillObjects.o -c DistillObjects.cpp
    ECHO DistillObjects.o DONE
    g++ -DGCC -Wall -g -static -o Elementizer.o -c Elementizer.cpp
    ECHO Elementizer.o DONE
    g++ -DGCC -Wall -g -static -o ErrorStrings.o -c ErrorStrings.cpp
    ECHO ErrorStrings.o DONE
    g++ -DGCC -Wall -g -static -o ExpressionResolver.o -c ExpressionResolver.cpp
    ECHO ExpresionResolver.o DONE
    g++ -DGCC -Wall -g -static -o InstructionBlockCompiler.o -c InstructionBlockCompiler.cpp
    ECHO InstructionBlockCompiler.o DONE
    g++ -DGCC -Wall -g -static -o StringConstantRoutines.o -c StringConstantRoutines.cpp
    ECHO StringConstantRoutines.o DONE
    g++ -DGCC -Wall -g -static -o SymbolEngine.o -c SymbolEngine.cpp
    ECHO SymbolEngine.o DONE
    g++ -DGCC -Wall -g -static -o Utilities.o -c Utilities.cpp
    ECHO Utilities.o DONE
    g++ -DGCC -Wall -g -static -o PropellerCompiler.o -c Propellercompiler.cpp
    ECHO PropellerCompiler.o DONE
    
    ar rs libopenspin.a BlockNestStackRoutines.o CompileDatBlocks.o CompileExpression.o Comp
    eInstruction.o CompileUtilities.o DistillObjects.o Elementizer.o ErrorStrings.o Expressi
    Resolver.o InstructionBlockCompiler.o StringConstantRoutines.o SymbolEngine.o Utilities.
    PropellerCompiler.o
    
    COPY libopenspin/a a.libopenspin ~C F
    ECHO libopenspin.a DONE
    UP
    

    A few notes for those that are not familiar with RISC OS Star Commands:
    1: the dirrectory sepperator is "."
    2: UP is used to go up one directory (like CD .. in Unix).
    3: [DIR] is used to change directories to a specified relitive path (like cd [pathname] in Unix).
    4: The ~C option in COPY is used to copy with out asking confirmation.
    5: the F option in COPY is used to force overwriting if there is an exesting file of the same name at the destination.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2015-04-24 08:03
    A few notes for those that are not familiar with RISC OS Star Commands:
    1: the dirrectory sepperator is "."
    2: UP is used to go up one directory (like CD .. in Unix).
    3: [DIR] is used to change directories to a specified relitive path (like cd [pathname] in Unix).
    4: The ~C option in COPY is used to copy with out asking confirmation.
    5: the F option in COPY is used to force overwriting if there is an exesting file of the same name at the destination.

    You've just made me feel really good about being too lazy to ever download RISC OS for my pi.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-24 08:55
    You've just made me feel really good about being too lazy to ever download RISC OS for my pi.

    How so?

    It is easier to learn for the first time than it is to learn CMD.exe in Windows, or sh/bash/tcsh in *NiX.

    Ok so it is different than them, it is still easier overall :).

    Remember that the choice of dirrectory seperators ("/", "\", ":", ",", "_", etc depending on OS) is completely arbitrary, and even though the most common two today are "\" and "/", there is no standard for that, and in 1986 when RISC OS came out there was less push to use one particular seperator, so they kept the seperator used in Acorn MOS.

    RISC OS has many advantages over other OSes (especialy on the RPi). Speed, I am running it on my RPi at 500MHz, and it is still faster than Linux at 1000MHz (1GHz) even for FireFox. True universal drag and drop (save a text file dirrectly to a text field in the web browser, or save a sprite file dirrectly to a conversion utility to get a different output format, of save a text file dirrectly to the compiler (bad idea though doable), etc. The ability to run a true single tasking application. And many more.

    Of course the others have big advantages as well.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-24 09:07
    Ok it looks as if I have some work to do. There are some compile errors in openspin.cpp, and being the nature of the errors I am surprized that it can compile on any system.

    Here is the last command output:
    *G++ -DGCC -Wall -static -o openspin openspin.cpp flexbuf.c preprocess.c a.libop
    enspin
    openspin.cpp:76:26: error: 'PATH_MAX' was not declared in this scope
    openspin.cpp:79:38: error: 'PATH_MAX' was not declared in this scope
    openspin.cpp: In function 'const char* MakePath(PathEntry*, const char*)':
    openspin.cpp:83:13: error: 'lastfullpath' was not declared in this scope
    openspin.cpp: In function 'FILE* OpenFileInPath(const char*, const char*)':
    openspin.cpp:142:28: error: 'lastfullpath' was not declared in this scope
    openspin.cpp:149:12: error: 'filesAccessed' was not declared in this scope
    openspin.cpp:149:47: error: 'lastfullpath' was not declared in this scope
    openspin.cpp: In function 'int main(int, char**)':
    openspin.cpp:507:28: error: 'filesAccessed' was not declared in this scope
    openspin.cpp:516:17: error: 'filesAccessed' was not declared in this scope
    openspin.cpp: In function 'const char* MakePath(PathEntry*, const char*)':
    openspin.cpp:85:1: warning: control reaches end of non-void function [-Wreturn-type]
    
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-24 09:19
    I am guessing that PATH_MAX is supposed to be a constant defined with a #define PATH_MAX value statement, though I do not know for sure what it is supposed to represent.

    And what are filesAccessed and lastfullpath supposed to be?

    While I will be looking through the code to figure it out, it would speed things up if someone already knows.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-24 09:53
    GREAT NEWS:
    I got a sucessful compile :):) .

    I have not yet attempted to compile any spin code, though we will see how that goes.
    attachment.php?attachmentid=113992&d=1429894322
    644 x 432 - 9K
  • idbruceidbruce Posts: 6,197
    edited 2015-04-24 10:31
    David

    You surely know how to spit out code and get stuff done :) Go David Go :)
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-24 10:33
    I updated the first post to include an archive with the source in a form that can be dirrectly compiled on RISC OS. I still have to test it with some actual spin code to make sure it is working well.

    NOTE:
    If you wish to compile it, and do so under WIMP in a task window, you will have to make sure to give it enough memory (10MB should be enough, though I give it 100MB for GCC).

    To run openspin also requires a couple of MB
  • Heater.Heater. Posts: 21,230
    edited 2015-04-24 23:04
    I would suggest that you fork the openspin repository on github and make any changes you need for RISC OS in your fork rather than just dumping source code here on the forum.

    That way it's easy for people to find in the future. Your changes may get pulled back into the original repo if they are up to snuff. Being able to see what you have changed becomes much easier for others.

    Besides, version control is a good idea anyway.

    What machine are you running this on that you have to worry about the handful of megabytes it occupies?
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-25 04:19
    Heater. wrote: »
    I would suggest that you fork the openspin repository on github and make any changes you need for RISC OS in your fork rather than just dumping source code here on the forum.

    That way it's easy for people to find in the future. Your changes may get pulled back into the original repo if they are up to snuff. Being able to see what you have changed becomes much easier for others.

    Besides, version control is a good idea anyway.

    What machine are you running this on that you have to worry about the handful of megabytes it occupies?

    I do not have to worry about the hand full of megabytes of memory. In RISC OS, there is a certain amount of memory initialy allocated to programs running in a TASK window, that defaults to 640KB (I do not know why it is 640KB), so it is a good idea to allocate more ram to the task window before runing. Now that will not be an issue at all once I update the build script with a WimpSlot command at the begining to give it enough RAM for its task, and write a drag and drop front end for the OpenSpin compiler thus allowing for normal RISC OS usage (rather than purely commandline).

    So there is some work to be done.

    As to github, I do not think there is a git client for RISC OS, so making a fork is an issue. That and using the web interface would require using a WebBrowser that supports more JS than NetSurf, and on RISC OS at the moment that would mean FireFox and FireFox is very very slow.

    Though to answer your question I am running on a RaspberryPi Model B board Rev 2 (it is 3 years old, as are all my Rasperry Pi).
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-25 04:22
    MORE GOOD NEWS:
    OpenSpin seems to be compiling SPIN source with out any trouble on RISC OS.

    Now if someone would do me a favor and take the archives that I will post on this thread, extract them and put a fork on github, I would apreciate it much.

    I just wish I could port PropGCC, though not having Python on my RISC OS system makes that a NO GO.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-25 08:36
    Now I need to make a loader, and I will be able to do a lot with out Linux.
  • Heater.Heater. Posts: 21,230
    edited 2015-04-25 12:10
    All you have to do is fork propeller-gcc from github and hack on https://github.com/dbetz/propeller-load

    Basically most of your changes should be in a new file called osint_riscos.c

    If you make a good job such changes could be pulled back to the upstream propeller-gcc.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-25 12:29
    Heater. wrote: »
    All you have to do is fork propeller-gcc from github and hack on https://github.com/dbetz/propeller-load

    Basically most of your changes should be in a new file called osint_riscos.c

    If you make a good job such changes could be pulled back to the upstream propeller-gcc.

    How do I fork it on github with out using a JS complete browser, and with out having a git client???
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-25 12:33
    Heater. wrote: »
    All you have to do is fork propeller-gcc from github and hack on https://github.com/dbetz/propeller-load

    Basically most of your changes should be in a new file called osint_riscos.c

    If you make a good job such changes could be pulled back to the upstream propeller-gcc.
    The only changes that ended up being needed were correct the Directory structure for compiling on RISC OS and add a missing constant to opemspin.cpp, so it is effectly the same exact source as before porting.
  • Heater.Heater. Posts: 21,230
    edited 2015-04-25 12:49
    davidsaunders,
    How do I fork it on github with out using a JS complete browser, and with out having a git client???
    The flippant answer might be "Wake up, smell the coffee, it's 2015, use the tools that are available, even on the Rasperry Pi"

    More realistically one does not need a JS complete browser to use git. Or any browser. Just clone the repo to your machine and let it be known to the project maintainer when you have something useful to pull. All git repos are peers after all.

    If your OS cannot run git then you have a problem. Either:

    a) Get git running on your OS.

    b) Consider it as a target machine, like an Arduino or whatever, and maintain your source code on something more suitable for that task.

    As you have Raspberry Pi available that can do the job the course is clear.
  • Heater.Heater. Posts: 21,230
    edited 2015-04-25 12:53
    Are you saying that RISC OS understands the POSIX/UNIX/LINUX serial interface API that is used in Linux ?

    In which case I am amazed.

    Have you tested this loader yet?
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-25 13:37
    Heater. wrote: »
    Are you saying that RISC OS understands the POSIX/UNIX/LINUX serial interface API that is used in Linux ?

    In which case I am amazed.

    Have you tested this loader yet?
    NO NO, RISC OS does not have that part of the POSIX API (even though UnixLib is fairly complete, not that complete).

    I meant for openspin :).
  • KeithEKeithE Posts: 957
    edited 2015-04-25 13:40
    Can these pages help? Use SVN on RISC OS to access github?

    svn for RISC OS - http://www.cp15.org/versioncontrol/
    Github page discussing svn - https://github.com/blog/1178-collaborating-on-github-with-subversion
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-25 13:42
    Heater. wrote: »
    davidsaunders,

    The flippant answer might be "Wake up, smell the coffee, it's 2015, use the tools that are available, even on the Rasperry Pi"

    More realistically one does not need a JS complete browser to use git. Or any browser. Just clone the repo to your machine and let it be known to the project maintainer when you have something useful to pull. All git repos are peers after all.

    If your OS cannot run git then you have a problem. Either:

    a) Get git running on your OS.

    b) Consider it as a target machine, like an Arduino or whatever, and maintain your source code on something more suitable for that task.

    As you have Raspberry Pi available that can do the job the course is clear.
    I would like to just have git on RISC OS. Otherwize I am wasting my effort attempting to get away from Linux, which is the entire reason for this port of openspin and the todo attempt to get a loader working on RISC OS.

    There is a RISC OS port of git out there somewhere, it is a matter of finding it.

    And just because it is 2015 does not mean I am going to fall into the trap of use the most bloated possibility, I will not contribute to the repeat of the unmaintainable that killed Multix (with good riddens).

    I could use FireFox if I want to take forever to do anything, though I would rather not. Unfortunately there is not yet a port of a lean WebKit browser for RISC OS.
Sign In or Register to comment.