Cross Platform Propeller Macro Assembler and Loader
Tom Bampton
Posts: 29
This is something that I've been wanting to talk about since Gary and I started work on it a month or so ago, but it just felt far too lame to announce with nothing to show.
It is very early days, but attached is the first stable build of our macro assembler and loader tool for Windows and OS X. Currently the loader only runs on Windows, so on OS X you will need to use the existing Python script to get stuff onto the prop. We will eventually have a Linux build as well, but for various reasons it is unlikely to be until we reach alpha.
The main purpose of this build is to provide a stable base on which to build the full production version, and to highlight any wonky areas in the code. We have already learnt a lot of lessons from this build and have started fixing them, so this build serves more as a preview of what's to come then as something that needs testing. We are, however, still interested in any feedback. This build is also on a separate branch of the repo and so we can fix bugs and upload a new build if it makes sense to do so.
It is worth pointing out that although have included some basic docs, knowledge of Propeller assembly and other macro assemblers is probably a requirement to get anything out of this build. The docs are very much a draft and are unfinished, but should cover the main points that you need to know.
There is also not that much in the way of examples yet. However, converting existing Propeller assembly code written for the prop tool is not all that tricky. It's mostly a matter of removing the SPIN related stuff (e.g. no DAT block), search/replace of ' to ; and fixing any expressions that use Parallax operators. We have had the TV driver running on ucasm for a while, but that is not currently included in the zip. The main reason for that is the assembler has changed a bit since we last looked at it and I don't know if it still works.
To "install", unzip somewhere and add the Bin directory to your path. As long as the directory structure remains as it is in the zip, include files will be found automatically regardless of working directory or how you run ucasm.
Finally, I would just like to take a moment to thank Cliff L. Biffle for his work on propasm. In the early days it was an extremely useful reference when something wasn't clear from the Propeller manual. We are also using his minimal SPIN bootloader to kick everything off, and I think the LED example was based on his test code too. The Gear emulator (sorry, I forget who wrote it) has also been extremely useful for figuring out what was going wrong.
Regards,
Tom.
It is very early days, but attached is the first stable build of our macro assembler and loader tool for Windows and OS X. Currently the loader only runs on Windows, so on OS X you will need to use the existing Python script to get stuff onto the prop. We will eventually have a Linux build as well, but for various reasons it is unlikely to be until we reach alpha.
The main purpose of this build is to provide a stable base on which to build the full production version, and to highlight any wonky areas in the code. We have already learnt a lot of lessons from this build and have started fixing them, so this build serves more as a preview of what's to come then as something that needs testing. We are, however, still interested in any feedback. This build is also on a separate branch of the repo and so we can fix bugs and upload a new build if it makes sense to do so.
It is worth pointing out that although have included some basic docs, knowledge of Propeller assembly and other macro assemblers is probably a requirement to get anything out of this build. The docs are very much a draft and are unfinished, but should cover the main points that you need to know.
There is also not that much in the way of examples yet. However, converting existing Propeller assembly code written for the prop tool is not all that tricky. It's mostly a matter of removing the SPIN related stuff (e.g. no DAT block), search/replace of ' to ; and fixing any expressions that use Parallax operators. We have had the TV driver running on ucasm for a while, but that is not currently included in the zip. The main reason for that is the assembler has changed a bit since we last looked at it and I don't know if it still works.
To "install", unzip somewhere and add the Bin directory to your path. As long as the directory structure remains as it is in the zip, include files will be found automatically regardless of working directory or how you run ucasm.
Finally, I would just like to take a moment to thank Cliff L. Biffle for his work on propasm. In the early days it was an extremely useful reference when something wasn't clear from the Propeller manual. We are also using his minimal SPIN bootloader to kick everything off, and I think the LED example was based on his test code too. The Gear emulator (sorry, I forget who wrote it) has also been extremely useful for figuring out what was going wrong.
Regards,
Tom.
Comments
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
I have read the manual and have found that block comments are not supported. I want to have such one, so I could be easily to comment out blocks of code for safety reason when I try to find a better solution of code.
Did you have plans to provide any kind of block comment?
Post Edited (Kaio) : 4/17/2007 3:58:35 PM GMT
In the mean time, if you want to entirely disable a block of code, just use conditional assembly ... e.g.
if 0 ; ... disabled code ... endT.
Edit: hmm ... or ...
; Start of file ... ENABLE_TEST_CODE equ 0 ; ... More code ... if ENABLE_TEST_CODE ; ... disabled code ... endThen you can just change the constant and not have to worry about digging through the code to find the if.
About OSX... they are late to the party and a dollar short. Let's call a strike until Apple weighs in with some real engineering support.
... and that is from a Jobs loyalist.
Rich
Can't wait to try it this weekend.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
I'd just finished cleaning up the tv driver when Tom pointed out your post, coincidence huh [noparse]:)[/noparse]
Attached is the Parallax TV Driver ported to UCAsm as well as a small demo that uses it to display "UC".
-
Gary
sources at some point in time (if yes, under what license) ?
- Werner
As we've been quiet for some time now, a quick update:
The current stable version is up to 0.7.2, but the changes from the version posted here are mostly bug fixes and one or two small things that we needed through using it. The bulk of the work has gone into 0.8 which will be the first alpha production ready version. 0.8 is significantly and vastly improves usability and reliability, but it is not yet ready for use so we're currently still using 0.7.2 for our own projects. The day job has been getting in the way a bit lately so progress on 0.8 is slower then I would have liked.
If there's some interest we can probably upload the 0.7.2 build next week sometime, though there's at least one semi serious bug I don't remember if we got around to fixing yet so that would need to be checked/fixed first.
T.
I have also been working on an assembler for the Propeller (as have a few others) in Python a few weeks ago, but had to stop due to lack of spare time. I was able to assemble a few Parallax demo files (e.g. the VGA-Text demo) with minimal changes to the files. If I ever finish it (and that's a big if), it will be released under the GPL. Don't hold your breath, though.
-- Remy
m8cas has expressions, macros, includes, and all sorts of symbols, but no loops or object files. It can
assemble multiple sources into a common binary, with global and file-local scope for symbols, though,
i.e., it supports the type of scoping a C compiler needs. The Propeller-isms need extra work, of course.
I looked at the documentation of UCAsm, and most of the differences to the Parallax syntax look quite
reasonable to me, so I think we can have a high degree of syntax compatibility. It may make sense to
have a more Parallax-compatible mode (let's call this "parallax" vs. "old school") which supports those
constructs that aren't too onerous, though.
I think changing the semantics of "=" is inviting trouble, though, just like the IMHO quite vicious
semantics of "<=" in Spin.
It may also make sense to support multiple sections ("areas" in M8C-lingo), again because that's what
compilers like to use. But I think the COG, COGBASE, etc. approach is nice for hand-written assembler.
Not sure on the ETA, though. I don't really have time to play with this. Yet it's so tempting ...
- Werner
ucasm 0.8 already supports all of that including loops and object files. We also support types, both native and complex (e.g. structures), and a few other things that are not in 0.7.
Our target audience is game developers who are familiar with existing compilers and assemblers, and so our decisions favor that audience first and foremost. The biggest affect that has is on operators, as any Spin operators that clash with the standard C style operators will be the C version, and not Spin. We will however be supporting any Spin operators that it makes sense to support where there is no clash.
That said, the expression parser/evaluator can handle any set of operators we care to throw at it, so there is a possibility that we can support both with a command line switch to toggle between them. It's unlikely that will happen before 1.0, but that is not set in stone.
We will definately be supporting sections. I am not sure that I like the cog/cogbase approach since it can lead to some subtle errors and it complicates a number of things. However, this is something that we are constantly evaluating and in any case we will always support both absolute and relocatable code/data. I suspect that we will end up supporting sections primarily and faking the cog/hub directives with sections.
Thank you for your comments, they are much appreciated [noparse]:)[/noparse]
Tom.
Yup, my goal is to have the assembler reasonably feature-rich (at least macros and include files), modular (that
is, you can call it from a Makefile, no need to learn yet another mandatory IDE), written in an established
non-proprietary language (e.g., C), and Open Source (GPLv2, as far as I'm concerned). I guess you wrote ucasm
in C or C++, so it fulfills my first three goals, but unfortunately not the last one.
You aren't writing a compiler in the end, are you ?
I'm after the functionality you would want in order to, say, port the Linux kernel. Now, I don't want to do *that*,
but the requirements resulting from this framework are that the assembler be a good base for a compiler, also
allows tight but not necessarily very complex inline assembler to be written, and is good for writing optimized
runtime support functions. So I think we have a large overlap there, with the main difference that I'd expect
people to switch to a higher-level language when the data structures get complicated.
By the way, object files aren't much of a goal for me, because they hide lots of nice optimizations from the
compiler. People are adding this sort of information to the object file formats of "big" compilers, but it doesn't
exactly sound like fun. You'd basically want to dump your entire intermediate representation, along with
everything you found out about the call graph, etc. And do this in a language-independent and possibly even
tool-independent way. I think that one can conveniently get away with just compiling/assembling the whole
source of everything for relatively small systems, as the ones using a Propeller, so separate
compilation/assembly wouldn't be necessary for performance reasons.
I think that's the most elegant approach. That way, existing Propeller can be reused and at the same time, people
with a C/Unix background can be given an environment without too many surprises. Shouldn't be hard to implement,
but the grammar may end up looking a bit peculiar.
Hmm yes, particularly in such a self-modifying-code-happy environment, being able to send data and instructions either
way might be quite handy.
- Werner
It does sound like we have very similar goals. And you are correct, ucasm is C++.
A large part of the reason behind us rolling our own assembler was to allow us to make it work the way we wanted, and for that we needed source. I am not against collaborating to get it done quicker, but I'm not really sure how to work that at the moment. If you're interested I can run it by Gary. Email me at fos2k4 at gmail.com if you want to talk about it privately, though be aware my day job keeps me really busy so I can be slow to answer emails [noparse]:)[/noparse]
Well, yes [noparse];)[/noparse] Though the types/structs thing is mainly to make coding purely in asm easier rather then specifically for a compiler.
We are thinking along similar lines, and in fact I joked about running Linux on the Prop just yesterday [noparse]:)[/noparse] As our main target is games, we are thinking of using a high level language (undecided exactly which one) for game logic and asm for speed critical stuff. Initially everything will be purely in asm, of course.
Yeh, I am not entirely sold on using object files either for much the same reasons. My current plan is to just implement them and see how it goes. All the data required for them is already there anyway, it's just not persisted to disk yet.
The other big one is dealing with symbols that resolve to a cog address versus symbols that resolve to a hub address. Using sections, the label can resolve directly to whatever is correct for where that label is defined. e.g. define it in a hub section and you can resolve it directly to the hub address without need for the @ operator, and define it in a cog section and it resolves directly to a cog address. This was something that proved to be a big pain in the Smile to deal with from the assembler's point of view with the cogbase approach. My only concern is that then you don't know what address the label will resolve to just by looking at the code that uses label. I guess that's just the price you pay for having an architecture with two completely independant memory spaces, and can be solved with coding standards rather then technology.
T.