IDE Compiler suggestion - Indirect Call/Jumps

Cluso99

I've just been burnt and yes I was warned (I've seen lots of posts) - but still I wasted more than a day.

The problem:
······ jmp···· #goto1···· 'jumps directly to the location
······ jmp·····indirect1·· 'jumps to the address stored at indirect - BUT this catches a lot of assembler people because they forget the "#"

The proposed solution:
······ option· indirect=1 (or whatever)·· 'compiler option
this will use the following formats
······ jmp···· #goto1···· 'jumps directly to the location
······ jmp·····@indirect1·'jumps to the address stored at indirect (or preceed with another character like "^", "&" or whatever)
this instruction will force an error
······ jmp·····indirect1·· 'illegal (by the option) and forces an error

The same applies to other forms of jumps and calls.


······

hippy

My prefered choice would be "jmp [noparse][[/noparse]reg]", and I'd like to see "jmpret lab,#lab" change to "jmpret #lab,#lab" because that inconsistency makes me go "grrr"

Phil Pilgrim (PhiPi)

That one catches me all the time, too — still. Although it's consistent with the rest of the syntax, it's inconsitent with every other assembler I've ever used, and I've wasted hours due to the resulting bugs in my code. I really like Cluso99's compiler option idea, and I'd vote to have it apply to all indirect references, not just jumps. It would add enormously to the clarity of every assembly program. In fact, I'd even write a Perl program to change all my Propeller code to the new syntax.

-Phil

Ale

I'd prefer if a listing of the compiled source is provided (in PropTool), much better to spot oddities imho. I think I asked for it some one year ago, but still nothing on the horizon :-/

Phil Pilgrim (PhiPi)

Ale,

Ditto that request! Not so much for spotting indirect jumps, but just for seeing whether the assembler interpreted what I wrote the way I did. This is the first assembler I've ever used that doesn't provide the option for a listing file.

(Since the compiler proper is written in x86 assembly and is not part of the IDE per se, both these requests may be in the limbo queue for awhile.)

-Phil

Cluso99

A listing would have saved my bacon too !!! I agree with all indirect references also.

Maybe we need a program that reads the binaries and spin and put's it into a form of listing (if parallax won't alter the compiler) ??

Phil: What's the problem/implication of x86 ??

hippy

I'm not as convinced a listing is the panacea to solving missing # and other typo problems but does have a lot of uses.

What I think is the underlying problem ( beyond typo ) is that many PASM programmers come from other assemblers where the default varies with the opcode, for loads and math an operand with a # is a constant, without a # a register, with an @ an indirect of register, while for branches, without a # it's a destination label ( a constant ), @ being added for a jump indirect via register, # not having any place at all in those opcodes.

If one were creating a constant pointer to a destination in PASM one should for consistency with PASM be using "long #lab", but it's "long lab" ( likewise with org ). It's inconsistency of # use which I think is partly what initially confuses programmers unfamiliar with PASM.

I can understand the logic of the choice for PASM but I still sometimes get bitten by my old habits.

@ Phil : Re x86, is the compiler written in x86 or is it just the IDE ? I know x86 is cited as the reason PropTool won't work on Win98 but Propellent works okay AFAICT except for downloading where it cannot enumerate serial ports.

Phil Pilgrim (PhiPi)

hippy said...
What I think is the underlying problem ( beyond typo ) is that many PASM programmers come from other assemblers where the default varies with the opcode, for loads and math an operand with a # is a constant, without a # a register, with an @ an indirect of register, while for branches, without a # it's a destination label ( a constant ), @ being added for a jump indirect via register, # not having any place at all in those opcodes.

Correct. The expected defaults that we're all comfortable with are inconsistent.

I'd vote against using the immediate flag in longs, though, since those are declarations, not instructions (most of the time). The immediate bit is only used in instructions and with data that doesn't exceed 9 bits.

BTW, it's my understanding that the compiler was written by Chip in x86 assembly, and the IDE was written by Jeff in Delphi, a variant of Pascal.

-Phil

Ariba

Cluso99 said...

Maybe we need a program that reads the binaries and spin and put's it into a form of listing (if parallax won't alter the compiler) ??

PASD does exatly this to show a listing. It works not always perfect, especially with byte, word long statements, but almost:
http://forums.parallax.com/showpost.php?p=0
You need the actual version 0.3 from:
www.insonix.ch/propeller/prop_pasd.html

Andy

ImageCraft

For the Propeller, since it only support either literal or register mode, it doesn't really matter and it's purely an assembler syntax issue how to treat "jmp dest." OT speaking though, this is one of the pet peeve of mine, the TI MSP430 provides loads of addressing mode, and they came *this close* in providing simple, easy, position independent code because they allow PC relative addressing, e.g.

.... label(PC)...

This refers to the content of label offset from PC, which is what you want EXCEPT in jump/call. For those, you want the instructions to treat the operand as the actual destination, not containing the destination. Sadly, the MSP430 does the wrong thing and it take multi-instructions to support position independent code. So close, yet so far.

Phil Pilgrim (PhiPi)

'Just had an idea. Since a change in the language's syntax isn't likely to happen, why not change the highlighting? It would be easy enough for the IDE to highlight the source name of an indirect jump in boldface red, say. If I saw that while I was typing code, I'd immediately change it unless it's what I really meant. Like this:

········jmp #direct_label
········jmp indirect_label

This has the additional "benefit" of moving the solution from the compiler to the IDE ... um right, Jeff?

-Phil

Cluso99

Great - that would work for me ..... yes please??