Development:Checkered Flag (Jaguar)/TXT Files

This is a sub-page of Development:Checkered Flag (Jaguar).

BUGREP.TXT

Bug report for new TT version of madmac ...


1. labels in macros are not detected (details and example sent to 
	Normen Kowalewski @ Atari US BBS.

2. 'offset' is allowed as a macro name when it should be reserved
	and no warning is given

3. Why do I get warnings about data segment not being phrase multiple
	when surely it doesn't matter because I have used .phrase
	at the start of each piece which needs to be aligned ?

4. Also why is a .ABS (or now .offset) section considered to be a .data
	segment ?  I get the same 'data segment not a phrase multiple' 
	warning on my .offset section.

5. Using 'set' as a label gives a 'syntax error' but surely it should
	say that it is either reserved or allow it as a label ?

6. The symbol * is not implemented - defined as follows in my MADMAC reference manual

::: MADMAC reference manual pages 15/16 (Section : Expressions)

The pseudo-symbol "*" (star) has the value thatthe current section's location
counter had at the beginning of the current source line.  For example, these two
statements deposit three pointers to the label "bar" :

	foo:	dc.l	*+4
	bar:	dc.l	*, *

Similarly, the pseudo_symbol "$" has the value that the current section's loca-
tion counter has, and it is kept up to date as the assembler deposits information
"across" a line of source code.

::::

I haven't tried the symbol $ as I have never needed it, and I have stopped using
* because I only used it before for alignment checks. 


7. Word fixups are VERY unreliable. For example, I have a large set of data which 
uses word fixups to save me having to recompile over 100 files each time a colour
value (16 bit) is changed.  By mistake, I placed an extra data file in the middle 
of my main text file.  This resulted (correctly) in errors about 16 bit fixups for
bsr's in my code, but also produced errors relating to 16 bit equate fixups which
hadn't changed.

This problem gets worse if I attempt to use -fb, to the extent that I cannot get
my code to compile at all with -fb because it claims (wrongly) to have over a 
thousand 16 bit fixup errors.  I cannot give you a short sample because it never 
happens to short files.

8. -fb also has problems with long symbol names.  I successfully compiled some
sections of my code using -fb, but couldn't get the first symbol which was longer 
than 8 characters to resolve.  Taking out references to this first symbol allowed
that part (the symbol resolving phase) of the link to finish, but then the problem
listed in 7. stopped any further progress.

9. There is no means of getting help from mac - could you implement mac -h for help
or mac -? like aln ?  Also, doing mac -h at the moment makes my TT crash.  Oh, and
aln -? gives a nice helpful list of options which is now rather out of date.

10. You have very sensibly stopped duplicate local symbols from being output in the
abs file, but you seem to have applied the logic to the global symbols as well.  I
have a number of local symbols which are used in macros for generating 3d data, but
they are never required outside the process of generating that data.  I use the same
names for symbols in my .offset segment, and now find that the fixup values which have
been placed in to my code are wrong, and that the symbol doesn't even contain the wrong
value that has been fixed up, but a different wrong value !

[ Specifically, symbol Xoffset is a global label in my .offset segment, and should
  contain $4094.  It is also used as temporary storage as a local variable in each
  of my 100 3d object definition files.  
  The command :- move.l d1,Xoffset.w     in my source has produced
		 move.l d1,$7010.w       in the actual code, and yet the
  symbol Xoffset holds the value 0  - je ne comprends pas !			]



I hope this will help remove some of the small problems from what is otherwise a very
nice product - or will be, if I can ever get source level working !


By the way, why can't we have proper versions of .long, .phrase etc ?

It wouldn't be very difficult to code, and would mean that you would only need to 
realign those files which really needed to be aligned, rather than everything ! 

Alternatively, why not add an option to allow automatic alignment of segments to
a particular size, eg 

aln -z <text> <data> <bss>
where the alternatives are :	0 no align
				E even
				L long
				P phrase
				D double phrase

Then you could align all your data segments to phrase addresses and not mess up the rest,
using aln -z 0 P 0.

Surely something like this is better than having page after page of warnings which are 
not needed ??

Sorry if I seem to be just putting this all down - I think you're doing a really good job
of re-writing these utilities, and I can't wait for the next update !

Regards,

Robert Dibley
Rebellion Software
Oxford (England)
+44 865 784555    phone
+44 865 784556	  fax

Please elaborate. Having more detail is always a good thing.

This text can tell us that Robert Dibley was explaining basics to Normen Kowalewski.