Return-Path: gnupic-return-7143-ralph=inputplus.co.uk@linuxhacker.org
Delivery-Date: Sun Jun  7 12:29:16 2009
Return-Path: <gnupic-return-7143-ralph=inputplus.co.uk@linuxhacker.org>
X-Original-To: ralph@localhost
Delivered-To: ralph@localhost
Received: from blake.inputplus.co.uk (localhost.localdomain [127.0.0.1])
    by blake.inputplus.co.uk (Postfix) with ESMTP id 2EA55449D
    for <ralph@localhost>; Sun,  7 Jun 2009 12:29:16 +0100 (BST)
Delivered-To: inputplu-inputplus:co:uk-ralph@inputplus.co.uk
X-Envelope-To: ralph@inputplus.co.uk
Received: from ruis.pair.com [209.68.1.63]
    by blake.inputplus.co.uk with IMAP (fetchmail-6.3.8)
    for <ralph@localhost> (single-drop); Sun, 07 Jun 2009 12:29:16 +0100 (BST)
Received: (qmail 76788 invoked from network); 7 Jun 2009 11:26:51 -0000
Received: from mailwash26.pair.com (66.39.2.26)
  by ruis.pair.com with SMTP; 7 Jun 2009 11:26:51 -0000
Received: from localhost (localhost [127.0.0.1])
    by mailwash26.pair.com (Postfix) with SMTP id 8A60AFFA33
    for <ralph@inputplus.co.uk>; Sun,  7 Jun 2009 07:26:51 -0400 (EDT)
X-Spam-Check-By: mailwash26.pair.com
X-Spam-Status: No, hits=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.002005
X-Spam-Flag: NO
X-Spam-Level:
X-Spam-Filtered: 52d0813afd638bc4ffa68db06ca49a29
Received: from linuxhacker.org (troy.alexholden.net [82.70.130.131])
    by mailwash26.pair.com (Postfix) with ESMTP id BD38DFFA53
    for <ralph@inputplus.co.uk>; Sun,  7 Jun 2009 07:26:42 -0400 (EDT)
Received: (qmail 20215 invoked by uid 101); 7 Jun 2009 12:25:30 +0100
Received: from 192.168.43.2 by troy (envelope-from <gnupic-return-7143-ralph=inputplus.co.uk@linuxhacker.org>, uid 0) with qmail-scanner-1.25
 (clamdscan: 0.87.1/1168.
 Clear:RC:1(192.168.43.2):.
 Processed in 0.556871 secs); 07 Jun 2009 11:25:30 -0000
X-Qmail-Scanner-Mail-From: gnupic-return-7143-ralph=inputplus.co.uk@linuxhacker.org via troy
X-Qmail-Scanner: 1.25 (Clear:RC:1(192.168.43.2):. Processed in 0.556871 secs)
Received: from bender.nelson (192.168.43.2)
  by troy.alexholden.net with SMTP; 7 Jun 2009 12:25:29 +0100
Received: (qmail 864 invoked by alias); 7 Jun 2009 11:25:13 -0000
Mailing-List: contact gnupic-help@linuxhacker.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
list-help: <mailto:gnupic-help@linuxhacker.org>
list-unsubscribe: <mailto:gnupic-unsubscribe@linuxhacker.org>
list-post: <mailto:gnupic@linuxhacker.org>
Reply-To: gnupic@linuxhacker.org
Delivered-To: mailing list gnupic@linuxhacker.org
Received: (qmail 852 invoked by uid 0); 7 Jun 2009 11:25:13 -0000
X-Qmail-Scanner-Mail-From: HolgerRapp@gmx.net via troy
X-Qmail-Scanner: 1.25 (Clear:RC:0(213.165.64.20):. Processed in 0.064161 secs)
X-Authenticated: #565844
X-Provags-ID: V01U2FsdGVkX18+WARH7fg+BL9+leE/EnVAcS2xUxKx1+5WWQKVFv
    XHqyJ56qY+QeSz
Message-Id: <705B9F99-3E7C-40DF-A9BA-36210557F430@gmx.net>
From: Holger Rapp <HolgerRapp@gmx.net>
To: gnupic@linuxhacker.org
In-Reply-To: <492f1420906070305x3887424cy780dbced35c0010@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Sun, 7 Jun 2009 13:25:09 +0200
References: <3AE07D7E-6D3B-4942-B404-54A0B1F20343@gmx.net> <4d52f78b0906061403w1d09b7f0i1d48630bd92cca72@mail.gmail.com> <20090606235836.GA29373@cs.wisc.edu> <4d52f78b0906061720heeced6bnb14d1ed62034c660@mail.gmail.com> <20090607065700.GA4598@cs.wisc.edu> <492f1420906070305x3887424cy780dbced35c0010@mail.gmail.com>
X-Mailer: Apple Mail (2.935.3)
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.53
Subject: Re: [gnupic] SPASM - a MPASM behave alike

Hello,

Am 07.06.2009 um 12:05 schrieb Tamas Rudnai:

> On Sun, Jun 7, 2009 at 7:57 AM, Peter Keller <psilord@cs.wisc.edu>
> 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@linuxhacker.org
For additional commands, e-mail: gnupic-help@linuxhacker.org