FAQ

Back to OpenSource page

Q: When I assemble the Asm-Pro source and try to run it from inside Asm-Pro
   with 'j' Asm-Pro hangs. What am I doing wrong?
A: Nothing. You just can't run it from within Asm-Pro but have to write it
   as an executable and run it from the shell (or icon).

Q: When I assemble the source it gives me an Illegal opperator error and stops.
A: You have the 'Label:' switch turned on in the assembler prefs. Turn it off
   an all should work fine..


Not realy a FAQ yet.. It is my reply on a bug report send to me by bluebery
with some references to the source code.. might be helpfull to others trying
to locate stuff..

Buglist:

> - Changing source with F1-F10 while on the command line does not work
>  until the editor has been entered at least once.

I know :) if i didn't do it that way Asm-Pro would just crash.. I think that
the swap source buffers are not initialised on startup but on the first time
the editor is activated.. the swap source routines are a bit buggy and I havent
had time to look at them..

> - The EL (extend labels) command does not extend references of local
>  labels outside the local area. And it does not extend inside AUTO
>  statements.

EL never does what I want when i use it.. i think the code was never changed
when support for local labels was added..

> - In the debugger, when debugging longword mul or div, the extension
>  word is not checked as strictly as it should. Bits 15 and 9-3 must
>  all be 0. They are ignored (actually bit 3 is treated as part of the
>  high register number, so that e.g. $4C40580F is disassembled into
>  DIVSL.L D0,D?:D5).

hmm could be.. I added a lot of 68040 and 060 instructions but forgot to add
them to the disassembler.. should be easely fixed though..

> - Asm-Pro makes strange output and sometimes even crashes when
>  disassembling a floating point instruction with bit 6 of the second
>  instruction word set (e.g. $F2000EE3).

same problem as above but this time i think it is the disassemble jumptable..
if i remember right its to short and that could cause strange jumps to
seamingly random code (crash)..

2de word is disassambled around line 56747 (.CALC_OPERAND:)

.CALC_OPERAND:
        tst.b   d0
        bmi.b   .NEGATIVE
        move    (a0),d5 ;BIT_0_2        ;source register
        move    (2,a0),d6       ;BIT_3_5        ;source mode
        br.b    .GO_PRINT

.NEGATIVE:
        move    (12,a0),d5      ;BIT_9_B        ;dest reg
        move    (4,a0),d6       ;BIT_6_8        ;dest mode
.GO_PRINT:
        lsr.w   #1,d5
        add.b   d0,d0
        ext.w   d0
        tst     d0
        bpl.b   .pos
        and     #$00FF,d0
.pos:
        add     (.JUMP_TABEL,pc,d0.w),d0
        jmp     (.JUMP_TABEL,pc,d0.w)

I see the problem is that the jump table is just 72 entries and, looking at
the jump routine, it could get up to 127..

your instruction with byte value E3 will result in a jump to entrie nr 99
(add.b $E3,$E3 = $63 = 99)

you can easily check it by adding (128-72)

    dc.w    LEN_NONE-*

statements to the table and see if it still crashes..

> - When using constants in a floating point expression (in an immediate
>  floating point instruction or a dc.(s/d/x/p)), the constant will be
>  regarded as having the value of the last evaluated floating point
>  expression instead of its real value.
> - The space between a label and an opcode is colored as opcode. This
>  looks awkward. It should be colored as label.

hmm should be colored as rest o/t source you mean.. else the labels would
look awkward..

> - An instruction like fmove.s fp0,fp1 generates the error
>  '** Illegal floating point size, should be B,W,L,S,D,Q or P' which
>  is a bit misleading.

indeed :)

> - The PFLUSHA instruction always assembles to the 68030/68851
>  instruction ($F0002400). If 68040 or 68060 is selected as CPU, it
>  should assemble to the 68040/68060 instruction ($F518).

hmm i though it did that.. routine looks ok.. did you check it with the
68851 present switch off?

(line 19218)
Asm_PFLUSHA:
        move.w  #PB_851|PB_030|PB_ONLY,d0
        bsr     Processor_warning

        tst.b   PR_MMU
        bne.s   Asm_PFLUSH_851
        cmp.w   #PB_040,(CPU_type-DT,a4)
        blo.s   Asm_PFLUSH_851

        move.l  #$0000F518,d6
        bsr     Asm_SkipInstructionHead
        br      ASM_STORE_INSTRUCTION_HEAD

Asm_PFLUSH_851:
        move.l  #$F0002400,d6
        bsr     asm_4bytes_OpperantSize
        br      ASM_STORE_LONG


> - When 68060 is selected as CPU and Processor Warn is on, 68060-
>  unknown instructions like mulu.l d0,d1:d2 and fdbeq d7,loop should
>  give a warning.

you can find asm mulu around line 18190

;CA576:  
asm_MU:
        move    (a3)+,d0
        and     d4,d0
        cmp     #$CC55,d0
        beq.b   CA5BE
        cmp     #$CC53,d0
        beq.b   CA5D4
        cmp     #'LU',d0        ;muLU
        beq.b   CA596
        cmp     #'LS',d0        ;muLS
        beq.b   CA5AA
        br      HandleMacroos

CA596:
        move    (a3)+,d0
        and     d4,d0
        cmp     #$C057,d0       ;mulu.W
        beq.b   CA5BE
        cmp     #$C04C,d0       ;mulu.L
        beq.b   CA5C8
        br      HandleMacroos


and the processor warning for this size at:

Asm_ImmOpperantLong:
        moveq   #2,d0        ;PB_020
        bsr     Processor_warning

which means 68020 or higher so indeed there is no check on 060

> - When 'Show Source' is off, the AD command does not assemble the
>  source. This is in fact very useful, since it makes it possible
>  to single step an executable read with RO. (I do this a lot when
>  I am debugging my executable file cruncher, for example.) If you
>  intend to fix this, please make it possible some way to enter the
>  debugger without reassembling the source.

hehe where bugs can help you out :)

> I also have some suggestions for improvements, most important first.
> Some should be quite simple to implement others not...

well most of it is easily implemented so feel free to do so :)

> - When an 'Undefined symbol' or 'Double symbol' error occurs, tell which
> symbol is the faulty one. Figuring this out can be a real pain when the
> error occurs inside a macro.
> - Allow @ in label names. This is needed for linking regargs functions
> into C programs.
> - Make an undo facility in the editor. Multistep, of course, and with
> redo. I often miss this one.
> - Make a hotkey, or some other means, for stopping the execution of the
> program. When a program enters an infinite loop, I usually freeze it and
> finds the SP with ARTM, open another Asm-Pro, finds the PC on the stack
> and insert an ILLEGAL instruction. This works most of the time, but it
> is rather clumsy. Being able to break from within Asm-Pro would be nice.
> - When debugging code in 'include'd sources, show the source of the
> included file. The text is in memory anyway.

yep.. could be done..

> - Switch 'Show Source' automatically on and off during debugging,
> depending on whether the address could be found in a source.
> - Floating point constants (that works).
> - Folds in editor (I have mentioned this before).

I did start working on it.. (see Folding:) 

> - Longer commandline buffer (only 63 characters per line and not many
> lines remembered now).
> - Noncyclic commandline buffer. Instead of cycling through the lines
> when arrow up is held, stop when the top of the rememberred lines is
> reached.

Some ideas from this side:

The disassembler section of the source stands
almost on itself.. it has just a few referenes from other sections... a nice
idea would be to take this part and turn it into a library.. this way if we
dont use the disassambler it doesn't use any memory and if we want a, for
example, ppc disassembler we just write a new library (good idea or not?)
same should be for the assembler but this one is still a bit of a mess i'm
afraight..


We need a code clean-up..
The idea is to split the source up in several modules (objects?) with their
own specific task.. these would be:

- editor
- assembler
- disassembler
- preferences
- linker
- etc.

one other part, i can think of now, that is pretty much on its own are the prefs windows.. 

(we might have to rewrite the code to C or C++ to be able to port it to new
amiga platforms in the future and it will be better if we can do this one module at the time
iso do everything at once and have bugs all over the place.. but this is
for the future..)