MADS Knowledge-Base

[+JAC!]

Is it possible to generate a warning, if a branch destination crosses a page boundary? (needs one extra cycle)

 

.proc example

.proc critical_loop
lda some,x
sta stuff,x
inx
bne critical_loop
.endp

m_assert_same_page critical_loop

.endp

 

using the macros I've posted here http://www.atariage.com/forums/topic/179559-mads-knowledge-base/page__st__25#entry2682395

 

Edited February 9, 2013 by JAC!

[phaeron]

The .fl command seems broken in 1.9.5 and up -- it is giving me value out of range errors for any numbers less than 1.0:

1>source\Shared\mathpack.s (1321) ERROR: Value out of range
1> .fl 0.0050139288

 

I was trying to upgrade to 1.9.6b7 to see if it would fix a code generation issue I'm hitting with my custom OS, but I had to back down to 1.9.3 again because the math pack won't assemble due to the above error.

[phaeron]

Found the code generation problem. If you're doing tricky indexing and using postincrement/decrement, make sure your base address doesn't underflow into a negative number:

 

ldy #$f4
copy_iocb:
lda ichid,x+
sta ziocb-$f4,y+
bne copy_iocb

 

The underflow causes MADS to screw up generating the postincrement for the STA opcode, generating a $C7 opcode instead of $C8 for INY.

[tebe]

Is it possible to generate a warning, if a branch destination crosses a page boundary? (needs one extra cycle)

 

.pages [number]

.endpg

[tebe]

The .fl command seems broken in 1.9.5 and up -- it is giving me value out of range errors for any numbers less than 1.0:

1>source\Shared\mathpack.s (1321) ERROR: Value out of range
1> .fl 0.0050139288

 

I was trying to upgrade to 1.9.6b7 to see if it would fix a code generation issue I'm hitting with my custom OS, but I had to back down to 1.9.3 again because the math pack won't assemble due to the above error.

 

procedure SAVE_FL convert string to Atari FP, but it's not perfect

[tebe]

Found the code generation problem. If you're doing tricky indexing and using postincrement/decrement, make sure your base address doesn't underflow into a negative number:

 

ldy #$f4
copy_iocb:
lda ichid,x+
sta ziocb-$f4,y+
bne copy_iocb

 

The underflow causes MADS to screw up generating the postincrement for the STA opcode, generating a $C7 opcode instead of $C8 for INY.

 

lda -1,y+

 

bug fixed (mads 1.9.6 build 15)

mads_12.02.2013.zip

[phaeron]

Thanks, that did the trick.

 

I think I may have found what's causing the .fl regression. A diff on mads.pas shows this change in SAVE_FL between 1.9.3 and 1.9.5:

 

-   e:=e div 2
+   e:=e shr 1

 

I don't know Delphi, but apparently shr is an unsigned shift in Delphi:

http://galfar.vevb.net/wp/2009/shift-right-delphi-vs-c/

 

The exponent would be negative for numbers less than 1.0 in magnitude, which shr would turn into a very large positive number.

[phaeron]

I started writing some 65816 tests today and ended up doing some investigation into how MADS handles 65816 assembly:

• By default, in 816 mode (OPT C+), you can assemble either 8-bit or 16-bit immediate arguments. This depends on the size of the argument, so LDA #$0080 will generate A9 80, and LDA #$8000 will generate A9 00 80. That means with OPT C+ you have to be more careful to force a byte argument with < when appropriate or you will assemble garbage.
  
• You can force a word argument with a .w prefix, i.e. LDA.w $0080.
  
• MADS does not appear to have a way to change the default encoding for index and accumulator immediate mode instructions, like LONGA/LONGI.
  
• OPT T+ enables REP/SEP tracking. What this means is that it maintains internal flags for the width of A/X/Y and updates them whenever it sees REP/SEP. This does not affect the instruction encoding, but instead checks if the encoded instruction matches the tracked state and throws an error instead; you're still responsible for specifying the right encoding. This is only marginally useful as without LONGA/LONGI style commands you can't set the default state without actually emitting a REP/SEP. PHP/PLP are not tracked.
  
• REP/SEP tracking is incomplete as it only checks the magic values $10, $20, and $30. REP #$28, for instance, is ignored.
  

[tebe]

Thanks, that did the trick.

 

I think I may have found what's causing the .fl regression. A diff on mads.pas shows this change in SAVE_FL between 1.9.3 and 1.9.5:

 

- e:=e div 2
+ e:=e shr 1

 

I don't know Delphi, but apparently shr is an unsigned shift in Delphi:

http://galfar.vevb.n...ht-delphi-vs-c/

 

The exponent would be negative for numbers less than 1.0 in magnitude, which shr would turn into a very large positive number.

 

wow, this is it, my last optimization, replace slower DIV by faster SHR, but SHR is dangerous for INTEGER

 

thx, Phaeron, bug fixed (mads 1.9.6 build 16)

mads_13.02.2013.zip

[phaeron]

Thanks, that fix worked -- I now have my OS kernel assembling with MADS 1.9.6b16 and the only diff in the listings is that some \'s changed to /'s in the filenames.

[tebe]

i remove SYSUTILS and add CONST for PathDelim (from SysUtils source code)

 

const
 PathDelim  = {$IFDEF MSWINDOWS} '\'; {$ELSE} '/'; {$ENDIF}

 

procedure NormalizePath replace chars '/','\' by current PathDelim char

 

procedure NormalizePath(var a: string);
var i: integer;
begin

if a<>'' then
 for i := 1 to length(a) do
  if a[i] in ['/','\'] then a[i]:=PathDelim;

end;

[phaeron]

Sorry, the diff was in the other direction -- the 1.9.3 output contains the mixed slashes, and the 1.9.6 output is all backslashes, so 1.9.6 is fine.

 

I have another real bug to report, though: 65816 mode doesn't understand the PEI ($D4) and PER ($62) instructions.

Edited February 14, 2013 by phaeron

[drac030]

IIRC:

 

PEA $xxxx > PEA #$xxxx

PEI ($xx) > PEA ($xx)

PER rrrr > PEA rrrr

[phaeron]

That explains the behavior I was seeing, but that's quite non-standard form for those opcodes. PEA stands for Push Effective Address -- it doesn't make sense for that to take an immediate argument.

[drac030]

I know that PEA stands for "push effective address", but in fact only the last instance (aka PER) does something like that (still the "address" calculated is only 16-bit) The first one just pushes the value being its argument, just like LDA # loads. So the argument is in fact immediate. The second one simply pushes the contents of the word specified, so in fact it is a memory-to-stack move. MADS simply sees all three as one instruction in three addressing modes, not three separate instructions. Maybe the choice of the mnemonic is not the happiest, I agree.

[+JAC!]

I am still reworking the docs (line 2426 meanwhile :-). Seems like ".SIZEOF" was introduced in 1.9.3. Is it fully the same as ".LEN" or are there differences?

[tebe]

I am still reworking the docs (line 2426 meanwhile :-). Seems like ".SIZEOF" was introduced in 1.9.3. Is it fully the same as ".LEN" or are there differences?

 

.LEN = .FILESIZE = .SIZEOF (something for everyone)

[tebe]

mads 1.9.6 build 38

 

- add PER (PEA rell), PEI (PEA (zp))

- add DTA M (high 24 bit LONG)

- add DTA G (high 32 bit DWORD)

mads_16.02.2013.zip

[phaeron]

This was a fun one to track down. If you have label case sensitivity (-c) enabled, structure field names only work if they are declared in uppercase. That is, this:

.struct fcb
secbuf    .byte
.ends

data dta fcb [1] (0)

   lda    data[0].secbuf

 

...will fail to build with "Bad parameter type SECBUF", but this will assemble:

 

.struct fcb
SECBUF    .byte
.ends

data dta fcb [1] (0)

   lda    data[0].secbuf

[Heaven/TQA]

can someone build an OSX version of the latest build`?

[tebe]

This was a fun one to track down. If you have label case sensitivity (-c) enabled, structure field names only work if they are declared in uppercase. That is, this:

.struct fcb
secbuf .byte
.ends

data dta fcb [1] (0)

lda data[0].secbuf

 

mads 1.9.6 build 88, fixed case sensitive bug (thx Phaeron), block .REPT rewritten, nesting are supported

 

.rept 2,#*2+1

.print '1 - ',#

.rept :1
.print '2 - ',.r
.endr

.endr 

1 - $0000
2 - $0000
1 - $0001
2 - $0000
2 - $0001
2 - $0002

mads_196_build88.zip

[flashjazzcat]

I recall mentioning this before but I can't seem to find the emails / messages...

 

Regarding the .RELOC statement: the manual discusses relocatable blocks in the plural (using the MADS relocatable format, not SDX), and yet it appears impossible to have more than a single block in any project.

 

Now the reason this is going to be a problem for me is that I intend to use the MADS relocatable format for drivers in the GUI. Tebe has already sent me example code for a dynamic linker (which I just rediscovered today, so that's going to be really useful). However, it's clear that drivers will need to follow a common SDX approach, namely:

• Non-relocatable (short) init block (jettisoned after execution)
  
• Relocatable main block
  
• Relocatable extended block
  

 

If there's extended RAM available, the idea is that the extended block is moved into an extended bank and explicitly banked in by the main block. If there's no extended RAM, the extended block is simply relocated to main memory, and the main block's banking calls do nothing (since the code being called is in main memory).

 

I don't much fancy using the SDX relocatable format (it has limitations, for one thing), but this three-segment model is going to be pivotal to the whole kernel / driver model of the GUI. I wonder, then, if (assuming I'm not doing anything wrong), there's any hope of extending the proprietary relocatable format to allow multiple relocatable blocks (as well as a non-relocatable init block), which provision for explicitly specifying whether said block is to be relocated into conventional memory or extended RAM???

[flashjazzcat]

Perhaps SDX relocatable binaries will be a better bet...

[phaeron]

Regression between MADS 1.9.5 and 1.9.6 build 88: 65816 mode no longer allows ROR abs instruction:

 

   opt    c+
   org    $2000
   ror    $0100

 

ror.s (3) ERROR: Illegal addressing mode (CPU 65816)

[snicklin]

Regression between MADS 1.9.5 ...

 

Phaeron, Avery, I'd like to thank you (probably on the behalf of a great many people) for translating the MADS instructions for 1.9.5 to English, it has transformed my usage of MADS.

 

Since I've converted my project from pretty plain 6502 to using more of MADS functionality, I've found that it is much shorter, easier to read and therefore easier to understand. As I don't code every day, I tend to forget where my project was at and have to relearn my own code, now that is much easier as I've cut it all down. I couldn't have done this without your translation (albeit with some help from Google!).