PASM to SPIN

Humanoido

How to convert it automatically?

Often times I look at Propeller Assembler code and have no idea what it's doing. An automatic conversion to SPIN code would be very helpful.

Humanoido

Heater.

Pretty much impossible to do automatically I would think.

Spin can't easily represent even just "jmp". In PASM jumps can take you to any place in the code, Spin is block structured and has no GOTO.

How would one handle converting self-modifying code into Spin?

Spin uses signed ints, PASM you can work with unsigned.

And so on.

I would imagine that any conversion of PASM to Spin, done by human or machine, would be so structurally different from the original code that it would not help understand the operation of the original.

Any machine conversion would probably produce an output that is less intelligable than the input.

Still this is Propeller land where all theses impossible things have a habit to get done anyway:)

Leon

Proper commenting of PASM code would help, it's inadequate in much of the code I've seen. Here is an example:

        org

entry   mov     t1,par                'get first parameter
        rdlong  value, t1
         
        add     t1,#4                 
        rdlong  pinOut, t1
        or      dira, pinOut         ' set pinOut to output      

        add     t1, #4
        rdlong  ctraval, t1
        mov ctra, ctraval              'establish counter A mode and APIN

        add     t1, #4
        rdlong  period, t1

For some reason obvious statements like "or dira, pinOut" are commented whilst the less obvious ones like "add t1, #4" aren't.

Heater.

Humanoido,

My own assembler code confuses the socks of me if don't look at it for more than a day or two.

Helpful variable names and code labels would be a good start. Half decent comments is always recommended.

Fortunately PASM is about the easiest assembler language I have ever come across and not having to worry about interrupts is a boon.

Graham Stabler

1. Firstly learn assembly and then do some coding.
2. Then go through the code line by line working out what is going on with a pad of paper.

The comments are definitely an issue. Leon's example is an interesting one because as a frequent user of rdlong I understand instantly what the "add t1, #4" means and why it is there so the experienced programmer might easily not bother commenting it assuming that anyone who can code assembly will think the same. Personally I like to comment my assembly quite heavily so it is readable by the beginner however it is worth learning some assembly before hand rather than expecting the comments to teach you everything.

Just be glad there is no working register and pages and no need to emulate 16bit/32bit, propeller assembly is really neat!

Graham

Heater.

Oh good, we can have an unresolvable argument about commenting styles:)

I think Leon's code snippet above is a classic example of a coding idiom which you will see around a lot and is not made any clearer by excessive commenting. Except perhaps when see it in a tutorial for beginners.

In general an overdose of commenting can have a negative effect on.

ErNa

We need a tool to write comments and create code from it. Not to create code automatically, but to write down what we want to have in macros

ericball

There are three types of comments:
1. no comment
2. comments which tell you what the instruction does
3. comments which tell you why the instruction was used

With decent labels comments of type #2 shouldn't be necessary. Type 3 comments are what you need when you have to back and modify code you wrote last year.

Graham Stabler

Heater, no arguments from me, just my personal way. Actually in the case of Leon's example I might fully comment the first case in terms of the specific commands and then go for more general program flow type comments for further cases.

Graham

potatohead

Great discussion.

There is a type 4 comment: The wrong one, just saying. I got tripped up last week, with one of my own $(%*^$% type 4 comments.

Beau Schwabe

Gee Whiz, that looks like some of my commented code :-)

In cases like that, typically the comment is meant to include the whole group and not just a single line of code. Where the groups are separated by a blank space or some kind of page break.

On topic however, only as a learning tool I think it could be possible to create a SPIN-->PASM but not the other way around. Typically though when you do this sort of thing, each and every instruction gets 'encapsulated' in a way that you have a common mode input/output structures with the assembly program. This extra program padding can take up a lot of extra space within the program and should only be used for the learning experience. With observation, practice, and efficiency you will be able to combine the encapsulations into larger modules by understanding how they need to interact , eventually migrating to witting a complete PASM code. Progressing further you can take advantage of the specialized things you can do in PASM that SPIN won't allow.

Invent-O-Doc

In Harpit's new SPIN book, he wrote that he considered a beginner's guide to propeller assembly. I wish he would write that.

On the SX side of the house, there is a good book and Bean's SX/B, a non-optimizing basic compiler, was intended to ease the transition to assembly. Given that SX/B lives on as PropBASIC - you could use the PropBASIC tool to see the compilation results and look at how things get done in assembly by example. Just a thought.