Preprocessing Assembly

Preprocessing Assembly

[Johann Oskarsson]

Hi,

I've been doing a little assembly on my playstation2 running linux 
(actually writing a little tutorial as I go along) and was wandering 
what you ppl use to preprocess the source (if you do)?  I've tried a 
little gasp, but that's depricated.  Do you generally use cpp, or is 
there a better tool out there?

For more info on ps2 and linux see, http://playstation2-linux.com/
My little howto is at http://cosmos.raunvis.hi.is/~johannos/


Johann

Re: Preprocessing Assembly

[hp]

Johann Oskarsson am Samstag, 26. April 2003 16:16:
> Hi,
>
> I've been doing a little assembly on my playstation2 running linux
> (actually writing a little tutorial as I go along) and was wandering
> what you ppl use to preprocess the source (if you do)?  I've tried a
> little gasp, but that's depricated.
		^^^^^^^^^^^^
not really. GASP enables a few features which are often required but not 
implemented with any other part of the binutils.
besides, the binutils' authors only _state_ that all GASP features are 
implemented with AS, which is not true. and, there is still some development 
on GASP going on, not documented but, a "diff" shows. and, the GASP is 
included in the binutils sources, with AS, in the directory of which it can 
be compiled, separately ("make gasp-new").


>  Do you generally use cpp, or is there a better tool out there?

I don't know of any such tool which wouldn't be worse - or self-made.


best,,
	hp

-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de
  pse, reply to << lx -at- lxhp -dot- in-berlin -dot- de >>

Re: Preprocessing Assembly

[Johann Oskarsson]

Hi,

hp a écrit:

>Johann Oskarsson am Samstag, 26. April 2003 16:16:
>  
>
>>I've been doing a little assembly on my playstation2 running linux
>>(actually writing a little tutorial as I go along) and was wandering
>>what you ppl use to preprocess the source (if you do)?  I've tried a
>>little gasp, but that's depricated.
>>    
>>
>not really. GASP enables a few features which are often required but not 
>implemented with any other part of the binutils.
>besides, the binutils' authors only _state_ that all GASP features are 
>implemented with AS, which is not true. and, there is still some development 
>on GASP going on, not documented but, a "diff" shows. and, the GASP is 
>included in the binutils sources, with AS, in the directory of which it can 
>be compiled, separately ("make gasp-new").
>
Well, I'm not using the latest binutils package, and I've had to make 
some changes to gasp in order for it to work for me.  It has a rather 
nasty feature that treats .end as eof, but .end means end-of-function 
(incidentally eof too) in mips assembly.  I've made a crude hack to fix 
this, but am thinking of a more general solution.  What I'd like to do 
is to take gasp and create a separate tool called masp.  It'll be 
platform independent and therefore not backwards compatible with gasp, 
but will of course include the same functionality.  An added bonus will 
be that it'll be officially supported :)  Now is anyone interested in 
this?  I may need a little encouragement in order to go through with this.

>> Do you generally use cpp, or is there a better tool out there?
>>    
>>
>I don't know of any such tool which wouldn't be worse - or self-made.
>
Worse than what, please be a little more specific?


Johann

P.S. I was basically thinking of changing gasp directives from 
.something to /something, any comments on that?


-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Preprocessing Assembly

[hp]

Johann Oskarsson am Sonntag, 27. April 2003 03:51:
	[...]
> this, but am thinking of a more general solution.  What I'd like to do
> is to take gasp and create a separate tool called masp.  It'll be
> platform independent and therefore not backwards compatible with gasp,
				^^^^^^^^^^^^^^^^^^^^^^^^^^^^
not a problem, i.e. almost nobody seems to care about the gasp...

note also, that there are incompatibilities between binutils' versions and 
cpp/cc. e.g, the quite annoying different treatment of blank spaces which 
leads to unmangeable false evaluation of parameter lists to a '.macro' by 
GASP after praeprocessing w. CPP; I had to catch those arbitrarily inserted 
blanks with some short SED code in the makefile to overcome that silly 
'feature' (example: http://www.lxhp.in-berlin.de/lhpf4.html). 

> but will of course include the same functionality.  An added bonus will
> be that it'll be officially supported :)  Now is anyone interested in
					^^^^^^^^^^^^^^
	ME!

single objection: binutils is available in any(?) linux distribution, thus 
gasp could at least be compiled by a rsp. user - while 'masp' won't -?-


> this?  I may need a little encouragement in order to go through with this.
		^^^^^^^^^^^^^^^^
which?

> >> Do you generally use cpp, or is there a better tool out there?
> >
> >I don't know of any such tool which wouldn't be worse - or self-made.
>
> Worse than what, please be a little more specific?

'worse' than CPP; because, I'd resist to writing 'better' since CPP is some 
useable, even helpful tool, but I wouldn't call it 'good', so 'better' was 
not applicable.

'self made' because eventually I saw several helper sripts (bash, perl) for 
some partial  praeprocessing - GASP un-useability seems a common problem.

>
> Johann
>
> P.S. I was basically thinking of changing gasp directives from
> .something to /something, any comments on that?

why? the leading dot is so common to many tools for internal commands.
particularly, "/" might conflict with the linux file-path names' delimiter.
anyway, this should not impose any serious problems, with a proper keywords 
interpreter. only conversion of other sources might be a bit annoying.

imo, an assembly praeprocessor should leave as much as possible to the rsp. 
programmer, it can not assume any 'common' convention wrt the asm text!
reserved keywords and related required conventions may be un-avoidable but, 
_any_ other imposed ones are just bad (inadequate) design.

thus, a similar question which comes out of my Forth experiences: why not 
leave the entire naming to the user, w.o. _any_ 'special' or 'forbidden' 
characters (some more thaught required because of "C"-ish kewords decoding by 
testing for the rsp. leading chars)?
not easily implemented within the limitations of "C"-ish (etc) conventions 
but more conevenient to use(?) - or not worth the effort?

I gave up because I got my Forth systems which by definition of the language 
know no 'special' characters. thaught of a praeprocessor in ANS-Forth - which 
would be even more 'portable' than "C" and _very_ easy to handle. then, why 
not be consequent and do the complete assembler in Forth? I'd experiment with 
a Forth assembler but the source is not ANS, thus not a public project, yet.
currently, I'm back to rf hardware design which is so different and time (& 
interest) consuming that the asm projects won't be done, soon.


regards,
	hp
-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de
   pse, reply to << lxhp -at- lxhp -dot- in-berlin -dot- de >>

Re: Preprocessing Assembly

[Johann Oskarsson]

Hi,

hp wrote:

>note also, that there are incompatibilities between binutils' versions and 
>cpp/cc. e.g, the quite annoying different treatment of blank spaces which 
>leads to unmangeable false evaluation of parameter lists to a '.macro' by 
>GASP after praeprocessing w. CPP; I had to catch those arbitrarily inserted 
>blanks with some short SED code in the makefile to overcome that silly 
>'feature' (example: http://www.lxhp.in-berlin.de/lhpf4.html). 
>
I'll try to look at this later.  Can you be a little more specific?

>single objection: binutils is available in any(?) linux distribution, thus 
>gasp could at least be compiled by a rsp. user - while 'masp' won't -?-
>
I'm using the autoconf tools and can build rpms, so I guess that won't 
be a problem.  Just a matter of down loading the package.  Although I 
may have damaged some of the portability.

>[...]
>
>some partial  praeprocessing - GASP un-useability seems a common problem.
>  
>
That's what masp is meant for :)

>>P.S. I was basically thinking of changing gasp directives from
>>.something to /something, any comments on that?
>>    
>>
>
>why? the leading dot is so common to many tools for internal commands.
>
My original need for something else than gasp is becouse it's directives 
conflict with mips directives. For example .end is eof in gasp but is 
used on mips systems to mark end of functions.  Cutting off the rest of 
the file at the end of the first function (not to mention making the 
object file undebuggable) is *not a nice thing*.

>particularly, "/" might conflict with the linux file-path names' delimiter.
>anyway, this should not impose any serious problems, with a proper keywords 
>interpreter. only conversion of other sources might be a bit annoying.
>
I've opted for \ now, should make life a little easier for some ppl. 
 I'll be adding a parameter to specify this character.  I've just made 
my first version and a release is on the way soon.

I'm not entirely understanding the following, what do you mean by 'rsp' 
and 'wrt' ??  (and I've got a headace and want to finish this email 
before going to sleep or something).

>imo, an assembly praeprocessor should leave as much as possible to the rsp. 
>programmer, it can not assume any 'common' convention wrt the asm text!
>reserved keywords and related required conventions may be un-avoidable but, 
>_any_ other imposed ones are just bad (inadequate) design.
>
>thus, a similar question which comes out of my Forth experiences: why not 
>leave the entire naming to the user, w.o. _any_ 'special' or 'forbidden' 
>characters (some more thaught required because of "C"-ish kewords decoding by 
>testing for the rsp. leading chars)?
>not easily implemented within the limitations of "C"-ish (etc) conventions 
>but more conevenient to use(?) - or not worth the effort?
>
>I gave up because I got my Forth systems which by definition of the language 
>know no 'special' characters. thaught of a praeprocessor in ANS-Forth - which 
>would be even more 'portable' than "C" and _very_ easy to handle. then, why 
>not be consequent and do the complete assembler in Forth? I'd experiment with 
>a Forth assembler but the source is not ANS, thus not a public project, yet.
>currently, I'm back to rf hardware design which is so different and time (& 
>interest) consuming that the asm projects won't be done, soon.
>
>
>regards,
>	hp
>  
>

Re: Preprocessing Assembly

[hp]

nachricht  vom Mittwoch, 30. April 2003 01:08:

Hi,

> hp wrote:
> >note also, that there are incompatibilities between binutils' versions and
> >cpp/cc. e.g, the quite annoying different treatment of blank spaces which
> >leads to unmangeable false evaluation of parameter lists to a '.macro' by
> >GASP after praeprocessing w. CPP; I had to catch those arbitrarily
> > inserted blanks with some short SED code in the makefile to overcome that
> > silly 'feature' (example: http://www.lxhp.in-berlin.de/lhpf4.html).
>
> I'll try to look at this later.  Can you be a little more specific?

simple example:

#define page_shift 12
#define page_size 1<<page_shift

some versions of CPP insert a blank after "<<".
thus you can't use a '#define'd string which contains multiple text elements 
as a macro argument w. GASP because of it's  (imho) very silly delimiting 
convention which takes a comma as well as a blank space for the .macro 
arguments delimiter but provides no means to pass a parameter which consists 
of more than a single piece of text. NO way round! no bracees, brackets... 

or, 
defined in the Makefile and passed with the CFLAGS-variable:

ifneq ($(ILIBDIR),)
CCFLGS          +=      -Dilibdir="$(ILIBDIR)"
endif 

and used, for instance, as:

libdirc: .sdatac ilibdir
        .byte 0                                                               

blank space will be inserted immediately after the expanded variable, before 
the <nul>-byte - probably by CC because CPP called via execution of the 
c-compiler ?


which can be 'fixed' with the additional the piece of text '%NWSP%' (or any 
other which will not coincide with a defined keyword &c) and, in Makefile:

---
# the <sed> command eliminates blanks after #defined operations
# without which # pre-2.12 binutils or gcc 2.95 or gasp won't 
# orderly evaluate the AS macroes!                                        
%.s:    %.S scdata $(wildcard a/*)
	$(CC) $(CCFLGS) $(SRCDIR)/$< |sed -e 's| *%NWSP% *||g' >$(BINDIR)/$@
---
then the modified lines read:
	#define page_size 1<<%NWSP%page_shift
and:
	libdirc: .sdatac ilibdir%NWSP%

>
> I'm not entirely understanding the following, what do you mean by 'rsp'
> and 'wrt' ??  (and I've got a headace and want to finish this email
> before going to sleep or something).
	^^^^^^^^^^^^^^^^^^^^^^^^ ...good luck!

sorry if I bothered you with my laziness:
	rsp	respective(ly)
	wrt	with respect to


further, the temporary radix setting of GASP is un-useable. 
	movl $H'12345,eax	(I tried any possible variant)
either, it works with cpp and gasp but triggers an error with AS or, cpp 
enamates the error message or gasp or... (stupid thing!)

similar errors result if a single character is passed as a numeric value, e.g.
	movb 'X,al

also, the string functions won't do anything useful, because they work on 
explicite arguments but not on variables, i.e. can't be processed afterwards.

variables defined by the assembler within/outside of macroes are handled 
inconsistently, often can't be used for calculations or arguments passing.

imho, due to bad design:
macro args can't be addressed by their numeric position in the arguments list.
no means to analyzing the addressing mode of an argument.
no cross-ref listing (something similar, which most often is quite useless).

...(more in the list included in the F4 archive)...

just mentioned. I'll leave that for later...


best,
	hp
-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de
  pse, reply to << lxhp -at- lxhp -dot- in-berlin -dot- de >>

Re: Preprocessing Assembly

[Johann Oskarsson]

Hi,

MASP can now be found on the web: 
http://cosmos.raunvis.hi.is/~johannos/masp/
This is just a trial version so far.  The only changes are that 
directives now start with \ instead of ., so this no longer conflicts 
with the underlying assembler.  And mips directives in particular.  I've 
yet to add a command line parameter to change this char, but it can be 
done easily.

hp wrote:

>[snip]
>
>some versions of CPP insert a blank after "<<".
>thus you can't use a '#define'd string which contains multiple text elements 
>as a macro argument w. GASP because of it's  (imho) very silly delimiting 
>convention which takes a comma as well as a blank space for the .macro 
>arguments delimiter but provides no means to pass a parameter which consists 
>of more than a single piece of text. NO way round! no bracees, brackets... 
>  
>
I'll try to fix this one day, don't know if it'll be soon though.

>[snip]
>
>further, the temporary radix setting of GASP is un-useable. 
>	movl $H'12345,eax	(I tried any possible variant)
>
I've changed the base syntax in masp, it now uses 0[bhqd]<number> for 
strange bases instead of the ugly [BHQD]'<number> syntax.  Although I 
haven't released that version yet, I can do so now and/or emailed it if 
anyone asks.  This also means that 'c' character constants can now be 
passed to the assembler.

>[snip]
>
>imho, due to bad design:
>macro args can't be addressed by their numeric position in the arguments list.
>no means to analyzing the addressing mode of an argument.
>no cross-ref listing (something similar, which most often is quite useless).
>
I'm not sure if/when I can address this, most of the changes I make, is 
to fix something that simply pisses me off!

>[snip]
>
>...(more in the list included in the F4 archive)...
>
>just mentioned. I'll leave that for later...
>
I haven't had a close look on the F4 but I will perhaps in the future.


Johann


P.S. You've mentioned a lot of stuff, and I wish I could fix them all 
but I'm still familiarizing myself with the code and capabilities of 
gasp.  I can perhaps do more if you try masp and send me some bug reports.