Jump to content

Photo

xdt99: New TI 99 cross-development tools available


257 replies to this topic

#251 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 635 posts
  • Location:Germany

Posted Thu Mar 7, 2019 12:27 PM

I've just updated xas99.py on GitHub.  Embarrassingly, there aren't really any brand new features, but most work was done to consolidate two diverged branches of xas99 on two different machines. 

 

Anyway, I already mentioned # for cross-bank access.  The # goes after the label in the different bank, so you'd write

.

B @FARAWAY#(R1)
B @NOTHERE# + OFFSET

.

Yes, I could think of worse address expressions and I'm not sure # will work in those cases.  :)   But I had no time for "relocatable" all over again.  ;)

 

Second, instead of AORG >6000, 1, write

.

AORG >6000
BANK 1

.

and 

.

BANK ALL

.

for a shared code segment.  In the old notation, which still works, you'd have to keep up with addresses if you wanted to change to a bank after a shared segment.

 

Third, the -t option now has an argument which consist of a, b or c to generate "DATA" expressions for assembly, BASIC, or C, and 2 or 4 for BYTE or DATA, resp.

.

$ xas99.py -t a4 someprg.a99
->
  DATA >1234, >5678, >ABCD, >1234
  DATA >4567

$ xas99.py -t c2 someprg.99
->
  0x12, 0x34, 0x56, 0x78,
  0xab, 0xcd, 0x12, 0x34,
  ...

.

:arrow:  I use this for example to include my SDD99 assembly DSR into the C kernel.  But I'm sure there are already tons of tools to do this.

 

Fourth, I reverted a new parser I had built that would not be so strict about whitespace.  The downside was that it couldn't assemble old-style files with "flying comments" any more.  A few months back it still seemed like a good idea, but now I thought it's a solution to a problem no one really has.  :P

 

EDIT: Oops, I forgot Five, xas99 will now check if B statements could be replaced by a JMP, and will issue a warning if so.

 

I think I will spend more time on xdt99, in fact, I already have some improvements for xda99 and xdg99, and a large todo list.  :)


Edited by ralphb, Thu Mar 7, 2019 12:47 PM.


#252 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 3,093 posts
  • Location:Denmark

Posted Thu Mar 7, 2019 2:12 PM

Excellent. I'm already up and running with the new features. I now have 36 bytes more scratchpad available because I could move my trampoline code to the shared ROM segment.

 

If you make more improvements, please also consider my old suggestion to automatically optimize @field(rx) to *rx if field equ 0.



#253 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,572 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Mar 7, 2019 11:26 PM

If you make more improvements, please also consider my old suggestion to automatically optimize @field(rx) to *rx if field equ 0.


If you do that, please make it an option that must be explicitly turned on.

@field(rx) adds a two byte absolute value into the output assembly code - I've used it in the past for padding and for self-modifying code. An assembler that automatically changes the assembly code you write violates the Principle of Least Surprise. ;)

#254 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 3,093 posts
  • Location:Denmark

Posted Fri Mar 8, 2019 12:20 AM

Having an optimize flag sounds good to me. It could also replace those b instructions with jmp automatically instead of producing a warning.



#255 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 635 posts
  • Location:Germany

Posted Sun Mar 10, 2019 3:24 AM

I had to do another update, because my displacement computation in the B/JMP warning was wrong by a factor of 2.  :ponder:   For a while, I was frightened that my JMP displacement computation was also wrong, but it wasn't.  This is as far as JMP can jump:

.

      jmp l1
      bss 254
l1    nop
      bss 252
      jmp l1

.

It just looks weird, since the backwards displacement can be -128, but the forward displacement can only be 127.  But the displacement is applied to LC + 2, so it actually becomes -127 to 128.  And the displacement is for words, not bytes, hence the address delta is -254 to 256.

 

Besides, I also added warnings for @0(Rn) and missing R's when assembling with -R.  There's also a new '-w' option to disable warnings.

 

I still have to do the optimization -O at some point.  In general I'd prefer that people fix their code themselves, but in the case of Rasmus' @0(Rn) I understand that it cannot be fixed manually.  (Although, have you tried using macros for that?  :idea:   A bit ugly though.)

 

EDIT: Layout


Edited by ralphb, Sun Mar 10, 2019 3:25 AM.


#256 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,560 posts
  • Location:Germany

Posted Sun Mar 10, 2019 7:30 AM

I learned that in the MIPS architecture, the branch offset is calculated from the instruction following the branch instruction, that is pretty much the same as with the TMS architecture. The reason seems to be that the program counter has already advanced after getting the instruction.

 

Accordingly, the NOP pseudo-instruction is >1000 (JMP $+2).



#257 FarmerPotato ONLINE  

FarmerPotato

    Moonsweeper

  • 308 posts
  • Location:Austin, TX

Posted Sun Mar 17, 2019 1:26 PM

Feature request: issue a warning for this syntax:

ci   r1,r2

I know it's legal, but the 'r' indicates the real intention.

 

my bug was introduced when I rewrote a CI, putting the constant in R2.

 

; random number bits, modulo 20
    andi r1,>3f       
    li   r2,>14
mod0:
    ci   r1,r2
    jl   mod1
    s    r2,r1        ; 64 modulo 20 makes the first 4 more likely
    jmp  mod0
mod1:

Edited by FarmerPotato, Sun Mar 17, 2019 1:27 PM.


#258 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 635 posts
  • Location:Germany

Posted Sun Mar 17, 2019 2:09 PM

 

Feature request: issue a warning for this syntax:

ci   r1,r2

 

Yes, I like that, we should also cover this combination.

 

The reason you can do all this dates back to the original E/A, where R0 ... R15 were just pre-defined EQU's with values 0 ... 15.  xas99 kept that handy short-cut, but of course we can issue warnings during parsing of a register when we find no 'R'.

 

This way around might be slightly more complicated/ugly to implement, but I'll get going.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users