« Return to Thread: SPASM - a MPASM behave alike
Re: SPASM - a MPASM behave alike
by Holger Rapp
::
Rate this Message:
Hello,
Am 07.06.2009 um 12:05 schrieb Tamas Rudnai:
> On Sun, Jun 7, 2009 at 7:57 AM, Peter Keller <psilord@...>
> wrote:
>
>> What would the challenges be in writing a completely standalone
>> preprocessor which just emits the processed assembly to be then fed
>> into gpasm?
>>
>
> Why would write the #define / #include style preprocessor at all? This
> should be done by existing tools like the cpp instead of reinventing
> the
> wheel. The "other preprocessor" used by MPASM which is involved by the
> equ/macro style could be written as a separated preprocessor which
> would
> make the remaining compiler fairly trivial in my opinion.I do not want to sound rude, but I think many people are not really
aware of what they
are talking about in case of MPASM (the language, not the program).
#include #define and so
on are not defined as preprocessor directives, they are part of the
language definition. Using a preprocessor
like CPP is out of the game for example for this reason
#define B 10
A = 3 * B ; this is not a preprocessor variable; it must evaluate
expressions and know about the current radix (for example)
while A > 0
#if A > 2
data A
#endif
A--
endw
Label#v(A*10+1) ; this will become Label1
The "preprocessor" must know about a lot of the current assembly state
like for example the current radix or the minimal or maximal values.
It is therefore not a preprocessor in the C like sense, it is more an
integrated component of the assembler.
SPASM has to do a lot of error checking in the preprocessor too (for
example it gets handed down a list of opcode and pseudo opcode names
to check for opcodes in the first colum and so on). Also it has to
check because some tokens must be interpreted from the context.
This can't be avoided with MPASM. For example:
data abcdh ; will write 0xabcd; the h suffix is a valid identifier
for hex values
abcdh equ 0x1 ; abcdh is also a valid identifier
data abcdh ; will write 0x1
Now what? The lexer can't decide if it should return an identifer or a
hex-constant token. It therefore returns an "either-this-or-that"
token and the preprocessor
decides from context before handing stuff to the parser.
<rant>
Long story short: MPASM is a very undesigned language; it is not
trivial to write a "correct" assembler for it; people who consider it
"fairly trivial" should please make
sure they know what they are talking about; most programmers are quite
lazy; we would not reinvent the wheel if there were tools who could do
our job in our environment.
</rant>
>
>
> Is there a linker implemented in this SPASM with the MPASM style
> linker
> scripts?
No, as mentioned SPASM does not do relocatable code. I have never
worked with relocatable code on PICs and I doubt it is very useful to
have a macro assembler
(as SPASM is) for that. That is, I only see the scenario of a c
compiler creating objects that need to be linked. You do not need
MACRO, #v() or #ifdefs for that. You would prefer a clever linker,
which is another cup of coffee.
Cheers,
Holger
---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...
Am 07.06.2009 um 12:05 schrieb Tamas Rudnai:
> On Sun, Jun 7, 2009 at 7:57 AM, Peter Keller <psilord@...>
> wrote:
>
>> What would the challenges be in writing a completely standalone
>> preprocessor which just emits the processed assembly to be then fed
>> into gpasm?
>>
>
> Why would write the #define / #include style preprocessor at all? This
> should be done by existing tools like the cpp instead of reinventing
> the
> wheel. The "other preprocessor" used by MPASM which is involved by the
> equ/macro style could be written as a separated preprocessor which
> would
> make the remaining compiler fairly trivial in my opinion.
aware of what they
are talking about in case of MPASM (the language, not the program).
#include #define and so
on are not defined as preprocessor directives, they are part of the
language definition. Using a preprocessor
like CPP is out of the game for example for this reason
#define B 10
A = 3 * B ; this is not a preprocessor variable; it must evaluate
expressions and know about the current radix (for example)
while A > 0
#if A > 2
data A
#endif
A--
endw
Label#v(A*10+1) ; this will become Label1
The "preprocessor" must know about a lot of the current assembly state
like for example the current radix or the minimal or maximal values.
It is therefore not a preprocessor in the C like sense, it is more an
integrated component of the assembler.
SPASM has to do a lot of error checking in the preprocessor too (for
example it gets handed down a list of opcode and pseudo opcode names
to check for opcodes in the first colum and so on). Also it has to
check because some tokens must be interpreted from the context.
This can't be avoided with MPASM. For example:
data abcdh ; will write 0xabcd; the h suffix is a valid identifier
for hex values
abcdh equ 0x1 ; abcdh is also a valid identifier
data abcdh ; will write 0x1
Now what? The lexer can't decide if it should return an identifer or a
hex-constant token. It therefore returns an "either-this-or-that"
token and the preprocessor
decides from context before handing stuff to the parser.
<rant>
Long story short: MPASM is a very undesigned language; it is not
trivial to write a "correct" assembler for it; people who consider it
"fairly trivial" should please make
sure they know what they are talking about; most programmers are quite
lazy; we would not reinvent the wheel if there were tools who could do
our job in our environment.
</rant>
>
>
> Is there a linker implemented in this SPASM with the MPASM style
> linker
> scripts?
No, as mentioned SPASM does not do relocatable code. I have never
worked with relocatable code on PICs and I doubt it is very useful to
have a macro assembler
(as SPASM is) for that. That is, I only see the scenario of a c
compiler creating objects that need to be linked. You do not need
MACRO, #v() or #ifdefs for that. You would prefer a clever linker,
which is another cup of coffee.
Cheers,
Holger
---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...
« Return to Thread: SPASM - a MPASM behave alike
| Free embeddable forum powered by Nabble | Forum Help |
