Searching \ for '[PIC] A/D Issues' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=a%2Fd
Search entire site for: 'A/D Issues'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] A/D Issues'
2005\02\09@153937 by Ale[x] Garbino

picon face
I'm getting the following error:

MPLINK 3.90, Linker
Copyright (c) 2004 Microchip Technology Inc.
Error - section '.org_0' can not fit the absolute section. Section '.org_0'
start=0x00000000, length=0x00000046
Errors    : 1

On my code. Can anyone help? (Also, feel free to make suggestions on the
code, it's my first attempt).

Thanks!
Alex

Code:



;******************************************************************************
; Assuming clock speed = 10 MHz
; Structure:
;  Initialize
;   Main Loop:
;    Setup A/D Channel
;    Wait to settle (15uS)
;    Sample (20uS)
;    Wait to finish sample
;    Label results with channel #
;    Poll UART until it's RTS
;    Send A/D Value
;        Restart Loop

;******************************************************************************

       LIST P=18F452                ;directive to define processor
       #include <P18F452.INC>        ;processor specific variable definitions

;******************************************************************************
;Configuration bits
; The __CONFIG directive defines configuration data within the .ASM file.
; The labels following the directive are defined in the P18F452.INC file.
; The PIC18FXX2 Data Sheet explains the functions of the configuration bits.

       __CONFIG        _CONFIG1H, _OSCS_OFF_1H & _HS_OSC_1H
       __CONFIG        _CONFIG2L, _BOR_OFF_2L & _PWRT_OFF_2L
       __CONFIG        _CONFIG2H, _WDT_OFF_2H
       __CONFIG        _CONFIG3H, _CCP2MX_OFF_3H
       __CONFIG        _CONFIG4L, _STVR_OFF_4L & _LVP_OFF_4L & _DEBUG_OFF_4L
       __CONFIG        _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L
       __CONFIG        _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H
       __CONFIG        _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L &
_WRT3_OFF_6L
       __CONFIG        _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H
       __CONFIG        _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L &
_EBTR3_OFF_7L
       __CONFIG        _CONFIG7H, _EBTRB_OFF_7H

;******************************************************************************
;Variable definitions

               CBLOCK        0x000
               EXAMPLE                ;example of a variable in access RAM
               ENDC

;******************************************************************************
;Macros

MOVLF macro literal,dest
         movlw literal
         movwf dest
         endm

;******************************************************************************
;Reset vector
; This code will start executing when a reset occurs.

               ORG        0x0000
               goto        Main                ;go to start of main code

;******************************************************************************
;Start of main program

Main:
       rcall Initial
Loop

       ; A/D Conversion - still missing channel increment routine
       MOVLF B'01000001',ADCON0        ; Select Channel 0
       ; "Wait 15uS to settle" missing here
       bsf ADCON0,2                                ; Start conversion
       Check_Done
               btfsc ADCON0,2
               bra Check_Done                        ; Loop till done (~20uS)

       ; Label results
       movlw ADCON0                ;Load setup
       andlw B'00111000'        ;Mask all but channel #
       iorwf ADRESH,F                ;Add channel # to unused bits

       ; UART - usually still transmitting previous results
       Check_TXREG1
               btfss PIR1,TXIF        ;TXIF is set if ready to transmit
               bra Check_TXREG1
       movff ADRESL,TXREG        ;Transmit first byte
       Check_again
               btfss PIR1,TXIF        ;TXIF is set if ready
               bra Check_again
       movff ADRESH,TXREG        ;Transmit second byte

       ;Start with next channel
       bra Loop

;******************************************************************************
; Initialize
Initial
       ; A/D & Ports
       MOVLF B'11001000',ADCON1
       MOVLF B'11111111',TRISA
       ; UART
       MOVLF B'10000000',TRISC
       MOVLF D'10',SPBRG                ;Set Baud rate = 57.6k
       MOVLF B'00100100',TXSTA ;Enable Transmission
       MOVLF B'10000000',RCSTA ;Disable Reception
       MOVLF B'00000000',PIE1  ;Disable Interrupts
       return
;******************************************************************************
;End of program
       END


2005\02\09@160220 by Jan-Erik Soderholm

face picon face
Ale[x] Garbino wrote :

> I'm getting the following error:
>
> MPLINK 3.90, Linker
> Copyright (c) 2004 Microchip Technology Inc.
> Error - section '.org_0' can not fit the absolute section.
....
....

>       ORG     0x0000

I'm not 100% sure, but try with "CODE 0x0000" instead

(Now, since you are linking relocatable code, you could/should
also read-up on the use of "RES" instead of "CBLOCK", but I
don't think that's the problem...)

Jan-Erik.



2005\02\09@164701 by Bob J

picon face
The CBLOCK 0x0000 statement is not correct.  Try CBLOCK 0x20 if you
want to go that route, or better yet use the linker and an
uninitialized data section (udata) and res, let the linker figure out
the starting address:

      udata
example       res 1

Regards,
Bob


On Wed, 9 Feb 2005 22:02:19 +0100 (MET), Jan-Erik Soderholm
<spam_OUTjan-erik.soderholmTakeThisOuTspamtelia.com> wrote:
{Quote hidden}

> -

2005\02\09@171948 by John J. McDonough

flavicon
face
I am by no means an 18F expert, but the 452 linker script has a program
memory segment that is 29 locations long, followed by another segment
starting at 2a.  The code is 46 long so it won't fit.

Since you are using the linker, you don't want to be using org.  Use code
instead.

So, to break your goto Main apart from the rest of your code, the following
should work:

Start code 0x0000    ; Any old name will apparently work here
    goto Main

    code
Main:
      etc.

The goto will still be loaded into 0x0000, but Main will end up after 0x2a,
and in fact, after .cinit (assuming you are using the default linker
script), so when I ran a quick test, Main ended up at 002c.

The CBLOCK code is fine if your point is to specifcally access location
0x0000.  Normally, you would allocate space for a variable with

       udata
EXAMPLE    res 1

but this would cause the variable to be located in the gpr0 bank instead of
the accessram.

--McD


{Original Message removed}

2005\02\09@191303 by Ale[x] Garbino

picon face
I tried switching to code, but it gave the same error with '.code' instead.
It seems it's some memory issue, since when I specified a second code (this
is from a sample program:)

Reset_Vector  code 0x000
       goto Start

       ; Start application beyond vector area
       code        0x002A
Start
       clrf        PORTB                ;Clear PORTB
       ....

It works.
Could you point me to where this 'code' and 'org' business is explained in
the MPLAB manual?

Thanks for the help,
Alex


From: &quot;John J. McDonough&quot; &lt;.....mcdKILLspamspam@spam@is-sixsigma.com&gt;
Reply-To: &quot;Microcontroller discussion list - Public.&quot;
&lt;piclistspamKILLspammit.edu&gt;
To: &quot;Microcontroller discussion list - Public.&quot;
&lt;.....piclistKILLspamspam.....mit.edu&gt;
Subject: Re: [PIC] A/D Issues
Date: Wed, 9 Feb 2005 17:19:40 -0500

I am by no means an 18F expert, but the 452 linker script has a program
memory segment that is 29 locations long, followed by another segment
starting at 2a.  The code is 46 long so it won't fit.

Since you are using the linker, you don't want to be using org.  Use code
instead.

So, to break your goto Main apart from the rest of your code, the following
should work:

Start code 0x0000    ; Any old name will apparently work here
     goto Main

     code
Main:
       etc.

The goto will still be loaded into 0x0000, but Main will end up after 0x2a,
and in fact, after .cinit (assuming you are using the default linker
script), so when I ran a quick test, Main ended up at 002c.

The CBLOCK code is fine if your point is to specifcally access location
0x0000.  Normally, you would allocate space for a variable with

        udata
EXAMPLE    res 1

but this would cause the variable to be located in the gpr0 bank instead of
the accessram.

--McD


{Original Message removed}

2005\02\09@195439 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Ale[x] Garbino" <EraseMEagarbinospam_OUTspamTakeThisOuThotmail.com>
Subject: Re: [PIC] A/D Issues


> I tried switching to code, but it gave the same error with '.code'
instead.
> It seems it's some memory issue, since when I specified a second code
(this
> is from a sample program:)
>
> Reset_Vector  code 0x000
> goto Start
>
> ; Start application beyond vector area
> code 0x002A
> Start
> clrf PORTB ;Clear PORTB

This should work even if you leave the 0x2a off the second code directive.
The first code directive places the goto start at location zero.  The second
places the rest of the code wherever it will fit.  You forced it to 2a which
means the linker will put the .cinit code up areound 6something, but who
cares!  The thing is, the 2a really isn't needed.  With two code directives,
one of them needs to have a name.  You need two, because the segment at
0x0000 isn't large enough for your code.  Typically, you put your goto main,
start or whatever at 0x0000, then let the linker figure out where to put the
rest of your code.

> It works.
> Could you point me to where this 'code' and 'org' business is explained in
> the MPLAB manual?

This is explained, but not very well, in the MPASM manual, in "Chapter 1"
about the linker, which happens to be in the middle of my MPASM manual!
(There seem to be three Chapter 1's).  There is quite a lot of stuff there,
and unfortunately, it is a little hard to piece it together.  The example
code in MCHIP_TOOLS/TEMPLATE/Object isn't that bad *IF* you already
understand linking.

I have a document on the 14 bit processors that might help at
http://www.is-sixsigma.com/Elmer/E160L16.pdf
This is still a work in progress. Some members of this list have made
excellent comments which I have not yet incorporated.  Also, the linker
script files for the 18F processors rely more on the linker defaults than
the 16F scripts do, so it isn't all quite as applicable as you would like.
Nonetheless, it might help you put together some of the concepts.

--McD


2005\02\10@034157 by Jan-Erik Soderholm

face picon face
John J. McDonough wrote :

> With two code directives, one of them needs to have a name...

Hm, I thought that MPASM/MPLINK would supply some
made-up names for any un-named CODE segment, not ?

Now, I think you should *always* put your own name
on all CODE directives anyway, since that make the MAP files
much easier to read...

And personaly, I prefer to put a CODE directive for all/most
subroutines in the code. That makes it easy to read the
individual sizes for each segment from the MAP file. And
if you find out that you have to pin someting (like a table)
at a fixed address, the rest of the code will neatly spread
around it without any other changes.

Best Regards,
Jan-Erik.




2005\02\10@075219 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Jan-Erik Soderholm" <jan-erik.soderholmspamspam_OUTtelia.com>
Subject: RE: [PIC] A/D Issues


> Hm, I thought that MPASM/MPLINK would supply some
> made-up names for any un-named CODE segment, not ?

Yes, a default name will be provided.  However, OP needed two code segments
... one at location zero, and the other too big to fit in the segment at
location zero.  Every code segment in a single .asm file must have a
different name, so you  need to provide a name for at least one of them.  No
sin in providing two, tho.

> Now, I think you should *always* put your own name
> on all CODE directives anyway, since that make the MAP files
> much easier to read...

There is something to be said for that, and the price is pretty small.
Still, I always feel uneasy about adding any unnecessary constraints.  Can't
think of a reason not to do that one tho.

One thing that is interesting about the 18F parts is that the linker script
file doesn't provide all the nice section names that the 16F linker scripts
do.  For example, in most of the 16F parts I can supply the name STARTUP to
a section and it will be placed at 0x0000.  On the 18F parts it appears as
if you have to specify the 0x0000 or edit the linker script.  I'm not sure I
know which is preferable.

> And personaly, I prefer to put a CODE directive for all/most
> subroutines in the code. That makes it easy to read the
> individual sizes for each segment from the MAP file. And
> if you find out that you have to pin someting (like a table)
> at a fixed address, the rest of the code will neatly spread
> around it without any other changes.

Well, not only that, but if you do the one subroutine per file thing, when
you stuff it all in a library the linker will merrily pull out only the
stuff you need.  The downside (well, maybe not really down) is that makes
you start thinking about whether the routine is appropriately decoupled.  I
find I end up with much better thought out code, but it takes more time.

--McD


2005\02\10@081329 by olin_piclist

face picon face
Jan-Erik Soderholm wrote:
> And personaly, I prefer to put a CODE directive for all/most
> subroutines in the code.

You need to be very careful then as code within a module can end up on
different pages.  I normally put all the code in a module into the same
segment to guarantee it will all end up on the same page.  With the
convention that PCLATH is always loaded for the page of the currently
executing code, it allows simple GOTOs and CALLs within modules.  Special
PCLATH handling is only required when going between modules.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\10@082717 by Jan-Erik Soderholm

face picon face
John J. McDonough wrote :

> Well, not only that, but if you do the one subroutine per
> file thing, when you stuff it all in a library the linker will
> merrily pull out only the stuff you need.

Right, but the major problem with *object* code libraries is
that you lose all assembly-time calculations and conditionals
and so on. Olin's environment, as an example, would be quite
hard to move to a object LIB based build environment.

What I'd realy liked to see, is *source* code libraries where
the assembler would search, extract and include source code
"snippets" out of plain text libraries on-the-fly. Not having
to have everything in one large INC file.

B.t.w, how many are realy using object LIB's a lot in their
PIC projects ?

Jan-Erik.



2005\02\10@084738 by olin_piclist

face picon face
Jan-Erik Soderholm wrote:
> B.t.w, how many are realy using object LIB's a lot in their
> PIC projects ?

My build process creates a private library for each project.  This isn't
really used like a traditional library, but includes all modules of a
project except the STRT module that contains the reset vector code.  The
STRT module is explicitly linked in, and the linker pulls all the remaining
code out of the private library for that project.

Most of the time, everything in the library gets linked.  The purpose of the
library scheme is to allow easier handling of temporary debug code, or
perhaps various configuration options.  A temporary debugging module is
still part of the project source code for that project and can be easily
activated if needed later for maintenance, but doesn't get built into the
final production release.  This code selection can then be done solely by
changing the source code, and not by editing any build files.  The orphan
modules still get assembled and added to the project library, but are then
ignored by the linker.

Otherwise I don't use object code libraries as true libraries because there
is too much customization required for each project.  This customization
would be impossible or very burdensome to perform at run time, so each
"library" routine must be built with project-specific configuration.
Example of such project-specific state is the oscillator frequency, the size
and location of the data stack, which banks to use for local state per
module, etc.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\10@093810 by Jan-Erik Soderholm

face picon face
Olin Lathrop wrote :

> Jan-Erik Soderholm wrote:
> > And personaly, I prefer to put a CODE directive for all/most
> > subroutines in the code.
>
> You need to be very careful then as code within a module can
> end up on different pages.

You're right, of course.

I've mainly used either 18F parts (where this isn't that
much of an issue) or 12F's (with a single page), so... :-)

But on > 2Kwords 16F's, yes, this is an issue.

Jan-Erik.



2005\02\10@094430 by Jan-Erik Soderholm

face picon face
olin_piclist@embedinc.com wrote :

> Jan-Erik Soderholm wrote:
> > B.t.w, how many are realy using object LIB's a lot in their
> > PIC projects ?
>
> My build process creates a private library for each project.

Yes, that was one of the things I changed in my copy of
your envir. I probably just didn't understand why you
used a LIB, since it wasn't realy used for incremental (time
saving) builds anyway.

What I ment with my question was if anyone uses LIB's
for *cross-project* builds. That's is project-independant
LIBs, to put it another way.

Jan-Erik.



2005\02\10@095212 by Wouter van Ooijen

face picon face
> What I'd realy liked to see, is *source* code libraries where
> the assembler would search, extract and include source code
> "snippets" out of plain text libraries on-the-fly. Not having
> to have everything in one large INC file.

You need a tool for that. It is commonly called a compiler. If you treat
it kindly it will even allow you to use assembly language :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\10@100652 by Jan-Erik Soderholm

face picon face
Wouter van Ooijen wrote :

> > What I'd realy liked to see, is *source* code libraries where
> > the assembler would search, extract and include source code
> > "snippets" out of plain text libraries on-the-fly. Not having
> > to have everything in one large INC file.
>
> You need a tool for that. It is commonly called a compiler.

In what way would this be different in a compiler ?
I agree that you need a "tool", but that could either be
included in the compiler/assembler, beeing a preprocessor
(run before he compiler/assembler) or builtin in some kind
of "make" tool, not ?

Or did I miss something... ?

Jan-Erik.



2005\02\10@103520 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Jan-Erik Soderholm" <@spam@jan-erik.soderholmKILLspamspamtelia.com>
Subject: RE: [PIC] A/D Issues


> Wouter van Ooijen wrote :
>
> > > What I'd realy liked to see, is *source* code libraries where
> > > the assembler would search, extract and include source code

I'm not so sure I get the advantage here over an object library.  What is
the benefit?  Once I have a routine thoroughly tested and debugged, why
would I want to reassemble it?

--McD


2005\02\10@105248 by olin_piclist

face picon face
Jan-Erik Soderholm wrote:
> What I ment with my question was if anyone uses LIB's
> for *cross-project* builds. That's is project-independant
> LIBs, to put it another way.

Which I answered a little later in the same post you responded to.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\10@105504 by Jan-Erik Soderholm

face picon face
John J. McDonough wrote :

> > > > What I'd realy liked to see, is *source* code libraries where
> > > > the assembler would search, extract and include source code
>
> I'm not so sure I get the advantage here over an object
> library.  What is the benefit?  Once I have a routine thoroughly
> tested and debugged, why would I want to reassemble it?

Becuse there are so much "things" you can do with MPASM.

Just one simple example. Take a USART subroutine. You might like to
setup a symbol in the main code containing the wanted baud rate.
Then in the sub, let MPASM calculate the proper baud rate
register settings. This *can* be done at assembly time. This
can *not* be done using object code in LIB's.

Or, to have cross-plattform libraries with conditionaly assembly
of the rellevant code depending on what processor you are
currently building for.

All in all, this isn't much different from using separate source code
files, of course. It's more a question about administrating your
(common) source code.

Jan-Erik.



2005\02\10@110508 by olin_piclist

face picon face
John J. McDonough wrote:
> I'm not so sure I get the advantage here over an object library.  What
> is the benefit?  Once I have a routine thoroughly tested and debugged,
> why would I want to reassemble it?

Because there are many configuration choices that don't effect the source
code, but do effect the resulting binary.  For example, choice of processor,
number of pages, number of banks, size and location of the software stack,
and oscillator frequency are a few that I can think of off the top of my
head.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\10@114438 by Jan-Erik Soderholm

face picon face
Olin Lathrop wrote :

> Jan-Erik Soderholm wrote:
> > What I ment with my question was if anyone uses LIB's
> > for *cross-project* builds. That's is project-independant
> > LIBs, to put it another way.
>
> Which I answered a little later in the same post you responded to.

Hm, well... :-)

You know, if I was only concerned about your point
on this issue, Olin, I hadn't asked at all, since I already (think I)
know your point (which happens to match mine more or less...).

Again, does *anyone* successfully use LIB's together with
pre-assemebled object code in multiple projects ? (And no
answers is also a clear message on this issue, right ? :-) )
Maybe with "canned" A/D routines (to get this back on track :-) ).


Best Regards,
Jan-Erik.



2005\02\10@114910 by Wouter van Ooijen

face picon face
>> You need a tool for that. It is commonly called a compiler.
>
> In what way would this be different in a compiler ?
> I agree that you need a "tool", but that could either be
> included in the compiler/assembler, beeing a preprocessor
> (run before he compiler/assembler) or builtin in some kind
> of "make" tool, not ?

What I meant to say was that when you customize a bunch of code you
probably want to eliminate routines that are never called. I have yet to
see an assembler that can do this. Idem for variables that are never
used. And there are some things beyond that (static stack variable
allocation, constant expression propagation, dead branch removal, call
stack depth warning or even alternate (non-stack) calling) that a
compiler can do for you (at least some can). These things have little to
do with HLL-to-assembler translation, but everything with efficient
resource (code size, data size) use.

> Or did I miss something... ?

Obviously not yet :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\10@132636 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Jan-Erik Soderholm" <KILLspamjan-erik.soderholmKILLspamspamtelia.com>
Subject: RE: [PIC] A/D Issues


> Again, does *anyone* successfully use LIB's together with
> pre-assemebled object code in multiple projects ? (And no
> answers is also a clear message on this issue, right ? :-) )
> Maybe with "canned" A/D routines (to get this back on track :-) ).

Yes.  Admittedly, you need to reassemble the library for different
processors, but by conditionalizing based on MPLAB's processor symbol that
can be done without touching the source.

The inability to expose any old symbol is, in my view, a serious limitation
of MPLINK though.  It does make some sorts of conditionalization a bit
tricky.

I can't say I'm 100% convinced that overall it is a win.  I suspect it takes
a lot of projects to get the payback.  You really need to put a lot more
effort into the library routines to be sure they don't impose surprising
restrictions.

--McD


2005\02\10@171956 by James Newtons Massmind
face picon face
For the SX chip (a 16C5x clone) and its SASM compiler, I have a macro that
only compiles code for a function if that function is used. And the first
time, it compiles the code, the next time that code is used, it just
compiles the call to it. Huge include file, only the required code is
included. I would guess something like that could be written for MPASM.

---
James.



> {Original Message removed}

2005\02\10@175120 by Bob Axtell

face picon face
Using the standard compiler?

I'm interested in that, James.


James Newtons Massmind wrote:

{Quote hidden}

>>{Original Message removed}

2005\02\11@033141 by Wouter van Ooijen

face picon face
> For the SX chip (a 16C5x clone) and its SASM compiler, I have
> a macro that
> only compiles code for a function if that function is used.
> And the first
> time, it compiles the code, the next time that code is used, it just
> compiles the call to it. Huge include file, only the required code is
> included. I would guess something like that could be written
> for MPASM.

Once upon a time I was working on something like that for MPASM, but it
got terribly slow, and then I read that the MPASM macro space was
limited to something like a few kilobytes, so I abandoned the idea.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\11@035328 by William Chops Westfield

face picon face

On Feb 11, 2005, at 12:33 AM, Wouter van Ooijen wrote:

>> For the SX chip (a 16C5x clone) and its SASM compiler, I have
>> a macro that
>> only compiles code for a function if that function is used.

> Once upon a time I was working on something like that for MPASM, but it
> got terribly slow, and then I read that the MPASM macro space was
> limited to something like a few kilobytes, so I abandoned the idea.
>
There are other macro processors.  Who says (for instance) that
you can't use cpp to preprocess assembler?  (although this
particular example doesn't seem like something that cpp would
be very good at...)

BillW

2005\02\11@043234 by Wouter van Ooijen

face picon face
> > Once upon a time I was working on something like that for
> MPASM, but it
> > got terribly slow, and then I read that the MPASM macro space was
> > limited to something like a few kilobytes, so I abandoned the idea.
> >
> There are other macro processors.  Who says (for instance) that
> you can't use cpp to preprocess assembler?

Dunno why you ask, I certainly did not say so.

>  (although this
> particular example doesn't seem like something that cpp would
> be very good at...)

Right, and neither would M4 or one of the other common preprocessors,
for instance because they are not two-pass (some of the tricks I tried
to use require different processing in the two passes!) but mianly
because they are not aware of the assembly language. CPP might be
considered a 'general' preprocessor, but it contains a lot of
C-knowledge. Preprocessing a language with a preprocessor that was not
designed for that language is certainly possible, but I choose a
different route (Jal).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...