By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,395 Members | 2,513 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,395 IT Pros & Developers. It's quick & easy.

Show all memory occupied by the program

P: n/a
Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?

Jun 3 '07 #1
Share this Question
Share on Google+
39 Replies


P: n/a
Ravi <ra*********@gmail.comwrites:
Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
It can't be done in portable standard C. Try asking in a newsgroup
that deals with your operating system.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 3 '07 #2

P: n/a
In article <11**********************@j4g2000prf.googlegroups. com>,
Ravi <ra*********@gmail.comwrote:
>Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
gmemusage

http://techpubs.sgi.com/library/tpl/...t1/gmemusage.z

It is SGI IRIX specific, but you just asked for *a* program, without
indicating anything about the operating systems that are useful
for your purposes.

There is absolutely no way to get information about memory address
ranges through pure C, and it seems highly unlikely that such
a facility would ever be added to C; for one thing, it's kinda
difficult to define what the address ranges should mean for embedded
systems. Information about memory address ranges is inherently system
specific, so you will need to continue your investigations in a
newsgroup that deals with your operating system.

--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers
Jun 3 '07 #3

P: n/a
Ravi wrote:
>
Can you all please suggest a program which tell us the range of
memry addresses occupied by the given c program?
No. Off-topic.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 4 '07 #4

P: n/a
In article <11**********************@j4g2000prf.googlegroups. com>, Ravi
<ra*********@gmail.comwrites
>Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
Try looking at the map file that is output by the compiler.

Ignore the netpolice.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 4 '07 #5

P: n/a
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>Ravi <ra*********@gmail.comwrites:
>Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?

It can't be done in portable standard C. Try asking in a newsgroup
that deals with your operating system.
It has nothing to do with the OS it sounds like he is looking for the
map file that the compiler will output.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 4 '07 #6

P: n/a
In article <qs**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.ukwrote:
>In article <11**********************@j4g2000prf.googlegroups. com>, Ravi
<ra*********@gmail.comwrites
>>Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
>Try looking at the map file that is output by the compiler.
*What* map file output by the compiler? The compilers I use
(brand name compilers) don't output a map file; the toolsets
include tools to -generate- various forms of memory summaries,
but the compilers don't output memory maps.

Even the advice to look at map files is system specific.
--
All is vanity. -- Ecclesiastes
Jun 4 '07 #7

P: n/a
Chris Hills wrote:
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>Ravi <ra*********@gmail.comwrites:
>>Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?

It can't be done in portable standard C. Try asking in a newsgroup
that deals with your operating system.

It has nothing to do with the OS it sounds like he is looking for the
map file that the compiler will output.
That is, of course, absurd. The output of the compiler tells you
*nothing* about the memory addresses used by the program.
Jun 4 '07 #8

P: n/a
Chris Hills wrote:
In article <11**********************@j4g2000prf.googlegroups. com>, Ravi
<ra*********@gmail.comwrites
>Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
Try looking at the map file that is output by the compiler.
That is, of course, absurd. The output of the compiler tells you
*nothing* about the memory addresses used by the program.
>
Ignore the netpolice.
More important is to ignore Chris Hills, who obviously knows nothing.
Jun 4 '07 #9

P: n/a
In article <js**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.ukwrote:
>In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>>Ravi <ra*********@gmail.comwrites:
>>Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
>>It can't be done in portable standard C. Try asking in a newsgroup
that deals with your operating system.
>It has nothing to do with the OS it sounds like he is looking for the
map file that the compiler will output.
Chris, I was really convinced that you knew better than that.

The OP's question is completely meaningless on some operating systems,
and on some other operating systems none of the major compilers generate
memory maps (though other tools might be able to generate them.)

The question is also not specific enough to be answerable by the
"memory map" pancea. If for a particular program, some of the
variables are tossed into a section marked as Demand Zero Paging,
an other variables are tossed into a section for Block Initialize Data,
and some of the code is put down below the 64K boundary so short addresses
can be used, and if there are unusued gaps between each of these, then
does the OP need to know the start and end of each and every used segment?
If there happen to be 5 unused bytes between the code for one function
and the code for another, is that detail required to be revealed, since
those 5 bytes are -not- part of the range of memory addresses
occupied by that program? Does the OP need to know where each DLL
or DSO will get mapped into in virtual address space? If the OP is
using a malloc that uses mmap() to bring pages into the virtual address
range then the mmap() could "fill in" any space not nailed down, in
which case the "range of memory addressed occupied by the given c program"
could only be determined by -running- the program.
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers
Jun 4 '07 #10

P: n/a
Chris Hills <ch***@phaedsys.orgwrites:
In article <11**********************@j4g2000prf.googlegroups. com>,
Ravi <ra*********@gmail.comwrites
>>Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
Try looking at the map file that is output by the compiler.

Ignore the netpolice.
On the contrary, the so-called "netpolice" are trying to direct you to
a forum where you can actually get answers to your question.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 4 '07 #11

P: n/a
In article <f4**********@canopus.cc.umanitoba.ca>, Walter Roberson
<ro******@ibd.nrc-cnrc.gc.cawrites
>In article <qs**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.ukwrote:
>>In article <11**********************@j4g2000prf.googlegroups. com>, Ravi
<ra*********@gmail.comwrites
>>>Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
>>Try looking at the map file that is output by the compiler.

*What* map file output by the compiler? The compilers I use
(brand name compilers) don't output a map file; the toolsets
include tools to -generate- various forms of memory summaries,
but the compilers don't output memory maps.
All of the 30 odd I have do generate memory maps.
>Even the advice to look at map files is system specific.
Not at all. Memory maps are generated on a very wide range of compilers
for many targets. Each memory map will be specific to the program in
question.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 4 '07 #12

P: n/a
In article <f4**********@canopus.cc.umanitoba.ca>, Walter Roberson
<ro******@ibd.nrc-cnrc.gc.cawrites
>In article <js**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.ukwrote:
>>In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>>>Ravi <ra*********@gmail.comwrites:
Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
>>>It can't be done in portable standard C. Try asking in a newsgroup
that deals with your operating system.
>>It has nothing to do with the OS it sounds like he is looking for the
map file that the compiler will output.

Chris, I was really convinced that you knew better than that.
The OP's question is completely meaningless on some operating systems,
and on some other operating systems none of the major compilers generate
memory maps (though other tools might be able to generate them.)
As you say the OP's question is wide open. I think that all bar one of
my 30 odd compilers generate memory maps.
>The question is also not specific enough to be answerable by the
"memory map" pancea.
True. It should prompt him to look at the memory map if he has one and
learn a bit. Otherwise he will have to be a lot more specific
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 4 '07 #13

P: n/a
In article <5c*************@mid.individual.net>, Martin Ambuhl
<ma*****@earthlink.netwrites
>Chris Hills wrote:
>In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.orgwrites
>>Ravi <ra*********@gmail.comwrites:
Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?

It can't be done in portable standard C. Try asking in a newsgroup
that deals with your operating system.
It has nothing to do with the OS it sounds like he is looking for the
map file that the compiler will output.

That is, of course, absurd. The output of the compiler tells you *nothing*
about the memory addresses used by the program.

So would you care to explain the mythical output below?
It seems to have memory addresses for the program and the data. All the
compilers I use will do this.
(Compilers to mean compiler-linker combination of course unless you are
going to split hares)
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 1

LX51 LINKER/LOCATER V4.09, INVOKED BY:
C:\KEIL\C51\BIN\LX51.EXE MAIN.obj, XBANKING.obj TO LARGE_RAM IXREF
CLASSES (HDATA (X:0X020000-X:0X02FFFF))

CPU MODE: 8051 MODE
MEMORY MODEL: SMALL

INPUT MODULES INCLUDED:
MAIN.obj (MAIN)
COMMENT TYPE 0: C51 V8.05a
XBANKING.obj (?C?XBANKING)
COMMENT TYPE 0: AX51 V3.01a
C:\KEIL\C51\LIB\C51BS.LIB (?C_STARTUP)
COMMENT TYPE 1: A51 / ASM51 Assembler
C:\KEIL\C51\LIB\C51BS.LIB (?C?CLDPTR)
COMMENT TYPE 1: A51 / ASM51 Assembler
C:\KEIL\C51\LIB\C51BS.LIB (?C?CSTPTR)
COMMENT TYPE 1: A51 / ASM51 Assembler
C:\KEIL\C51\LIB\C51BS.LIB (PRINTF)
COMMENT TYPE 1: A51 / ASM51 Assembler
C:\KEIL\C51\LIB\C51BS.LIB (?C?PLDIIDATA)
COMMENT TYPE 1: A51 / ASM51 Assembler
C:\KEIL\C51\LIB\C51BS.LIB (?C?CCASE)
COMMENT TYPE 1: A51 / ASM51 Assembler
C:\KEIL\C51\LIB\C51BS.LIB (PUTCHAR)
COMMENT TYPE 1: A51 / ASM51 Assembler
ACTIVE MEMORY CLASSES OF MODULE: LARGE_RAM (MAIN)

BASE START END USED MEMORY CLASS
================================================== ========
X:000000H X:020000H X:02FFFFH 00C000H HDATA
C:000000H C:000000H C:00FFFFH 000600H CODE
I:000000H I:000000H I:00007FH 00001EH DATA
X:000000H X:000000H X:00FFFFH 000001H XDATA
I:000000H I:000000H I:0000FFH 000001H IDATA
I:000020H.0 I:000020H.0 I:00002FH.7 000001H.1 BIT
MEMORY MAP OF MODULE: LARGE_RAM (MAIN)
START STOP LENGTH ALIGN RELOC MEMORY CLASS SEGMENT NAME
================================================== =======================

* * * * * * * * * * * D A T A M E M O R Y * * * * * * * * * * * *
*
000000H 000007H 000008H --- AT.. DATA "REG BANK
0"
000008H 00001DH 000016H BYTE UNIT DATA _DATA_GROUP_
00001EH.0 00001FH.7 000002H.0 --- --- **GAP**
000020H.0 000021H.0 000001H.1 BIT UNIT BIT _BIT_GROUP_
000021H.1 000021H 000000H.7 --- --- **GAP**
000022H 000022H 000001H BYTE UNIT IDATA ?STACK

* * * * * * * * * * * C O D E M E M O R Y * * * * * * * * * * * *
*
000000H 000002H 000003H --- OFFS.. CODE ?CO??C_STARTUP?0
000003H 00000AH 000008H --- --- **GAP**
00000BH 00000DH 000003H BYTE OFFS.. CODE ?MAIN?0000B
00000EH 00038EH 000381H BYTE UNIT CODE ?PR?PRINTF?PRINTF
00038FH 000500H 000172H BYTE UNIT CODE ?C?LIB_CODE
000501H 00059EH 00009EH BYTE UNIT CODE ?PR?MAIN?MAIN
00059FH 0005C5H 000027H BYTE UNIT CODE ?PR?PUTCHAR?PUTCHAR
0005C6H 0005E1H 00001CH BYTE UNIT CODE ?CO?MAIN
0005E2H 0005FBH 00001AH BYTE UNIT CODE ?PR?TIMER0?MAIN
0005FCH 000607H 00000CH BYTE UNIT CODE ?C_C51STARTUP
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 2

* * * * * * * * * * * X D A T A M E M O R Y * * * * * * * * * * * *
*
000000H 000000H 000001H BYTE UNIT XDATA ?XD?MAIN
000001H 01FFFFH 01FFFFH --- --- **GAP**
020000H 02BFFFH 00C000H BYTE INSEG HDATA ?FD?MAIN

OVERLAY MAP OF MODULE: LARGE_RAM (MAIN)
FUNCTION/MODULE BIT_GROUP DATA_GROUP
--CALLED FUNCTION/MODULE START STOP START STOP
================================================== ==
TIMER0/MAIN ----- ----- ----- -----

*** NEW ROOT **************

?C_C51STARTUP ----- ----- ----- -----
+--?PR?MAIN?MAIN

MAIN/MAIN ----- ----- 0008H 0009H
+--?CO?MAIN
+--?PR?PRINTF?PRINTF

?CO?MAIN ----- ----- ----- -----

PRINTF/PRINTF 20H.0 21H.0 000AH 001DH
+--?PR?PUTCHAR?PUTCHAR

PUTCHAR/PUTCHAR ----- ----- ----- -----

PUBLIC SYMBOLS OF MODULE: LARGE_RAM (MAIN)
VALUE CLASS TYPE PUBLIC SYMBOL NAME
=================================================
0000000AH DATA --- ?_PRINTF517?BYTE
0000000AH DATA --- ?_PRINTF?BYTE
0000000AH DATA --- ?_SPRINTF517?BYTE
0000000AH DATA --- ?_SPRINTF?BYTE
010004DBH CODE --- ?C?CCASE
01000496H CODE --- ?C?CLDPTR
0100038FH CODE NEAR LAB ?C?CLDXPTR
00000000H NUMBER --- ?C?CODESEG
010004B4H CODE --- ?C?CSTPTR
010003AAH CODE NEAR LAB ?C?CSTXPTR
010003BFH CODE NEAR LAB ?C?ILDXPTR
010003E3H CODE NEAR LAB ?C?ISTXPTR
01000445H CODE NEAR LAB ?C?LLDXPTR
01000477H CODE NEAR LAB ?C?LSTXPTR
010004CBH CODE --- ?C?PLDIIDATA
010003FCH CODE NEAR LAB ?C?PLDXPTR
01000427H CODE NEAR LAB ?C?PSTXPTR
00000000H NUMBER --- ?C?XDATASEG
00000000H NUMBER --- ?C?XPAGE1RST
00000084H DATA BYTE ?C?XPAGE1SFR
01000501H CODE --- ?C_START
01000000H CODE --- ?C_STARTUP
01000070H CODE --- _PRINTF
01000070H CODE --- _PRINTF517
0100059FH CODE --- _PUTCHAR
0100006AH CODE --- _SPRINTF
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 3
0100006AH CODE --- _SPRINTF517
*SFR* 000000D0H.6 DATA BIT AC
*SFR* 000000E0H DATA BYTE ACC
*SFR* 000000EFH DATA BYTE ADCCON1
*SFR* 000000D8H DATA BYTE ADCCON2
*SFR* 000000F5H DATA BYTE ADCCON3
*SFR* 000000DAH DATA BYTE ADCDATAH
*SFR* 000000D9H DATA BYTE ADCDATAL
*SFR* 000000F4H DATA BYTE ADCGAINH
*SFR* 000000F3H DATA BYTE ADCGAINL
*SFR* 000000D8H.7 DATA BIT ADCI
*SFR* 000000F2H DATA BYTE ADCOFSH
*SFR* 000000F1H DATA BYTE ADCOFSL
*SFR* 000000F0H DATA BYTE B
*SFR* 000000C8H DATA BIT CAP2
*SFR* 000000D8H.5 DATA BIT CCONV
*SFR* 000000C8H.1 DATA BIT CNT2
*SFR* 000000F8H.2 DATA BIT CPHA
*SFR* 000000F8H.3 DATA BIT CPOL
*SFR* 000000D8H DATA BIT CS0
*SFR* 000000D8H.1 DATA BIT CS1
*SFR* 000000D8H.2 DATA BIT CS2
*SFR* 000000D8H.3 DATA BIT CS3
*SFR* 000000D0H.7 DATA BIT CY
*SFR* 000000E8H.5 DATA BIT D0
*SFR* 000000E8H.3 DATA BIT D0EN
*SFR* 000000E8H.7 DATA BIT D1
*SFR* 000000E8H.6 DATA BIT D1EN
*SFR* 000000FAH DATA BYTE DAC0H
*SFR* 000000F9H DATA BYTE DAC0L
*SFR* 000000FCH DATA BYTE DAC1H
*SFR* 000000FBH DATA BYTE DAC1L
*SFR* 000000FDH DATA BYTE DACCON
*SFR* 000000E8H DATA BYTE DCON
*SFR* 000000D8H.6 DATA BIT DMA
*SFR* 000000D3H DATA BYTE DMAH
*SFR* 000000D2H DATA BYTE DMAL
*SFR* 000000D4H DATA BYTE DMAP
*SFR* 00000083H DATA BYTE DPH
*SFR* 00000082H DATA BYTE DPL
*SFR* 00000084H DATA BYTE DPP
*SFR* 000000A8H.7 DATA BIT EA
*SFR* 000000A8H.6 DATA BIT EADC
*SFR* 000000C6H DATA BYTE EADRL
*SFR* 000000B9H DATA BYTE ECON
*SFR* 000000BCH DATA BYTE EDATA1
*SFR* 000000BDH DATA BYTE EDATA2
*SFR* 000000BEH DATA BYTE EDATA3
*SFR* 000000BFH DATA BYTE EDATA4
*SFR* 000000A8H.4 DATA BIT ES
*SFR* 000000A8H.1 DATA BIT ET0
*SFR* 000000A8H.3 DATA BIT ET1
*SFR* 000000A8H.5 DATA BIT ET2
*SFR* 000000BAH DATA BYTE ETIM1
*SFR* 000000BBH DATA BYTE ETIM2
*SFR* 000000C4H DATA BYTE ETIM3
*SFR* 000000A8H DATA BIT EX0
*SFR* 000000A8H.2 DATA BIT EX1
*SFR* 000000C8H.3 DATA BIT EXEN2
*SFR* 000000C8H.6 DATA BIT EXF2
*SFR* 000000D0H.5 DATA BIT F0
*SFR* 000000D0H.1 DATA BIT F1
*SFR* 0000009BH DATA BYTE I2CADD
*SFR* 000000E8H DATA BYTE I2CCON
*SFR* 0000009AH DATA BYTE I2CDAT
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 4
*SFR* 000000E8H DATA BIT I2CI
*SFR* 000000E8H.3 DATA BIT I2CM
*SFR* 000000E8H.2 DATA BIT I2CRS
*SFR* 000000E8H.1 DATA BIT I2CTX
*SFR* 000000A8H DATA BYTE IE
*SFR* 00000088H.1 DATA BIT IE0
*SFR* 00000088H.3 DATA BIT IE1
*SFR* 000000A9H DATA BYTE IE2
*SFR* 000000B0H.2 DATA BIT INT0
*SFR* 000000B0H.3 DATA BIT INT1
*SFR* 000000B8H DATA BYTE IP
*SFR* 000000F8H.7 DATA BIT ISPI
*SFR* 00000088H DATA BIT IT0
*SFR* 00000088H.2 DATA BIT IT1
02020000H HDATA --- large_array
01000501H CODE --- main
*SFR* 000000E8H.5 DATA BIT MCO
*SFR* 000000E8H.6 DATA BIT MDE
*SFR* 000000E8H.4 DATA BIT MDI
*SFR* 000000E8H.7 DATA BIT MDO
*SFR* 000000D0H.2 DATA BIT OV
*SFR* 000000D0H DATA BIT P
*SFR* 00000080H DATA BYTE P0
*SFR* 00000090H DATA BYTE P1
*SFR* 000000A0H DATA BYTE P2
*SFR* 000000B0H DATA BYTE P3
*SFR* 000000B8H.6 DATA BIT PADC
*SFR* 00000087H DATA BYTE PCON
*SFR* 000000C0H.5 DATA BIT PRE0
*SFR* 000000C0H.6 DATA BIT PRE1
*SFR* 000000C0H.7 DATA BIT PRE2
*SFR* 000000B8H.4 DATA BIT PS
*SFR* 000000B8H.7 DATA BIT PSI
*SFR* 000000DFH DATA BYTE PSMCON
*SFR* 000000D0H DATA BYTE PSW
*SFR* 000000B8H.1 DATA BIT PT0
*SFR* 000000B8H.3 DATA BIT PT1
*SFR* 000000B8H.5 DATA BIT PT2
*SFR* 000000B8H DATA BIT PX0
*SFR* 000000B8H.2 DATA BIT PX1
*SFR* 00000098H.2 DATA BIT RB8
*SFR* 000000CBH DATA BYTE RCAP2H
*SFR* 000000CAH DATA BYTE RCAP2L
*SFR* 000000C8H.5 DATA BIT RCLK
*SFR* 000000B0H.7 DATA BIT RD
*SFR* 00000098H.4 DATA BIT REN
*SFR* 00000098H DATA BIT RI
*SFR* 000000D0H.3 DATA BIT RS0
*SFR* 000000D0H.4 DATA BIT RS1
*SFR* 000000B0H DATA BIT RXD
*SFR* 00000099H DATA BYTE SBUF
*SFR* 00000098H DATA BYTE SCON
*SFR* 000000D8H.4 DATA BIT SCONV
*SFR* 00000098H.7 DATA BIT SM0
*SFR* 00000098H.6 DATA BIT SM1
*SFR* 00000098H.5 DATA BIT SM2
*SFR* 00000081H DATA BYTE SP
*SFR* 000000F8H.5 DATA BIT SPE
*SFR* 000000F8H DATA BYTE SPICON
*SFR* 000000F7H DATA BYTE SPIDAT
*SFR* 000000F8H.4 DATA BIT SPIM
*SFR* 000000F8H DATA BIT SPR0
*SFR* 000000F8H.1 DATA BIT SPR1
*SFR* 000000B0H.4 DATA BIT T0
*SFR* 000000B0H.5 DATA BIT T1
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 5
*SFR* 00000090H DATA BIT T2
*SFR* 000000C8H DATA BYTE T2CON
*SFR* 00000090H.1 DATA BIT T2EX
*SFR* 00000098H.3 DATA BIT TB8
*SFR* 000000C8H.4 DATA BIT TCLK
*SFR* 00000088H DATA BYTE TCON
*SFR* 00000088H.5 DATA BIT TF0
*SFR* 00000088H.7 DATA BIT TF1
*SFR* 000000C8H.7 DATA BIT TF2
*SFR* 0000008CH DATA BYTE TH0
*SFR* 0000008DH DATA BYTE TH1
*SFR* 000000CDH DATA BYTE TH2
*SFR* 00000098H.1 DATA BIT TI
010005E2H CODE --- timer0
02000000H XDATA BYTE timer_tick
*SFR* 0000008AH DATA BYTE TL0
*SFR* 0000008BH DATA BYTE TL1
*SFR* 000000CCH DATA BYTE TL2
*SFR* 00000089H DATA BYTE TMOD
*SFR* 00000088H.4 DATA BIT TR0
*SFR* 00000088H.6 DATA BIT TR1
*SFR* 000000C8H.2 DATA BIT TR2
*SFR* 000000B0H.1 DATA BIT TXD
*SFR* 000000F8H.6 DATA BIT WCOL
*SFR* 000000C0H DATA BYTE WDCON
*SFR* 000000C0H DATA BIT WDE
*SFR* 000000C0H.3 DATA BIT WDR1
*SFR* 000000C0H.2 DATA BIT WDR2
*SFR* 000000C0H.1 DATA BIT WDS
*SFR* 000000B0H.6 DATA BIT WR

SYMBOL TABLE OF MODULE: LARGE_RAM (MAIN)

VALUE REP CLASS TYPE SYMBOL NAME
================================================== ==
--- MODULE --- --- MAIN
02000000H PUBLIC XDATA BYTE timer_tick
02020000H PUBLIC HDATA --- large_array
01000501H PUBLIC CODE --- main
010005E2H PUBLIC CODE --- timer0
000000F1H SFRSYM DATA BYTE ADCOFSL
00000080H SFRSYM DATA BYTE P0
00000090H SFRSYM DATA BYTE P1
000000A0H SFRSYM DATA BYTE P2
000000B0H SFRSYM DATA BYTE P3
000000D0H.6 SFRSYM DATA BIT AC
000000B0H.4 SFRSYM DATA BIT T0
000000B0H.5 SFRSYM DATA BIT T1
000000A8H.7 SFRSYM DATA BIT EA
00000090H SFRSYM DATA BIT T2
000000C8H SFRSYM DATA BIT CAP2
000000E8H.3 SFRSYM DATA BIT D0EN
000000E8H SFRSYM DATA BIT I2CI
000000E8H.6 SFRSYM DATA BIT D1EN
0000009BH SFRSYM DATA BYTE I2CADD
000000D8H.4 SFRSYM DATA BIT SCONV
000000E8H.3 SFRSYM DATA BIT I2CM
000000A8H.6 SFRSYM DATA BIT EADC
000000A8H SFRSYM DATA BYTE IE
000000D8H.7 SFRSYM DATA BIT ADCI
000000BCH SFRSYM DATA BYTE EDATA1
000000BDH SFRSYM DATA BYTE EDATA2
000000BEH SFRSYM DATA BYTE EDATA3
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 6
000000BFH SFRSYM DATA BYTE EDATA4
000000C8H.6 SFRSYM DATA BIT EXF2
000000B0H.7 SFRSYM DATA BIT RD
000000C8H.1 SFRSYM DATA BIT CNT2
000000C0H.5 SFRSYM DATA BIT PRE0
000000A8H.4 SFRSYM DATA BIT ES
000000C0H.6 SFRSYM DATA BIT PRE1
000000B8H.6 SFRSYM DATA BIT PADC
000000B8H SFRSYM DATA BYTE IP
0000009AH SFRSYM DATA BYTE I2CDAT
000000C0H.7 SFRSYM DATA BIT PRE2
00000098H SFRSYM DATA BIT RI
000000D3H SFRSYM DATA BYTE DMAH
000000D0H.7 SFRSYM DATA BIT CY
000000B0H.2 SFRSYM DATA BIT INT0
000000F8H.2 SFRSYM DATA BIT CPHA
000000B0H.3 SFRSYM DATA BIT INT1
00000098H.1 SFRSYM DATA BIT TI
000000C0H.3 SFRSYM DATA BIT WDR1
000000D2H SFRSYM DATA BYTE DMAL
000000C0H.2 SFRSYM DATA BIT WDR2
000000E8H SFRSYM DATA BYTE I2CCON
000000CBH SFRSYM DATA BYTE RCAP2H
000000B8H.4 SFRSYM DATA BIT PS
000000D4H SFRSYM DATA BYTE DMAP
00000081H SFRSYM DATA BYTE SP
00000090H.1 SFRSYM DATA BIT T2EX
000000D0H.2 SFRSYM DATA BIT OV
000000E8H SFRSYM DATA BYTE DCON
000000F8H SFRSYM DATA BIT SPR0
000000CAH SFRSYM DATA BYTE RCAP2L
000000B9H SFRSYM DATA BYTE ECON
000000F8H.1 SFRSYM DATA BIT SPR1
000000B0H.6 SFRSYM DATA BIT WR
000000FDH SFRSYM DATA BYTE DACCON
000000C8H.5 SFRSYM DATA BIT RCLK
000000DAH SFRSYM DATA BYTE ADCDATAH
000000F8H.3 SFRSYM DATA BIT CPOL
000000C8H.4 SFRSYM DATA BIT TCLK
000000D9H SFRSYM DATA BYTE ADCDATAL
00000099H SFRSYM DATA BYTE SBUF
00000087H SFRSYM DATA BYTE PCON
000000F4H SFRSYM DATA BYTE ADCGAINH
00000098H SFRSYM DATA BYTE SCON
00000089H SFRSYM DATA BYTE TMOD
00000088H SFRSYM DATA BYTE TCON
000000F8H.6 SFRSYM DATA BIT WCOL
000000F8H.7 SFRSYM DATA BIT ISPI
000000F3H SFRSYM DATA BYTE ADCGAINL
000000F8H.4 SFRSYM DATA BIT SPIM
00000088H.1 SFRSYM DATA BIT IE0
00000088H.3 SFRSYM DATA BIT IE1
000000A9H SFRSYM DATA BYTE IE2
000000FAH SFRSYM DATA BYTE DAC0H
000000F0H SFRSYM DATA BYTE B
000000FCH SFRSYM DATA BYTE DAC1H
000000F9H SFRSYM DATA BYTE DAC0L
000000D8H SFRSYM DATA BIT CS0
000000FBH SFRSYM DATA BYTE DAC1L
000000D8H.1 SFRSYM DATA BIT CS1
000000F7H SFRSYM DATA BYTE SPIDAT
000000E0H SFRSYM DATA BYTE ACC
000000D8H.2 SFRSYM DATA BIT CS2
000000D8H.3 SFRSYM DATA BIT CS3
000000A8H.1 SFRSYM DATA BIT ET0
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 7
000000A8H.3 SFRSYM DATA BIT ET1
00000088H.5 SFRSYM DATA BIT TF0
000000A8H.5 SFRSYM DATA BIT ET2
00000088H.7 SFRSYM DATA BIT TF1
000000C8H.7 SFRSYM DATA BIT TF2
00000098H.2 SFRSYM DATA BIT RB8
0000008CH SFRSYM DATA BYTE TH0
000000A8H SFRSYM DATA BIT EX0
00000088H SFRSYM DATA BIT IT0
0000008DH SFRSYM DATA BYTE TH1
000000A8H.2 SFRSYM DATA BIT EX1
00000098H.3 SFRSYM DATA BIT TB8
00000088H.2 SFRSYM DATA BIT IT1
000000F8H SFRSYM DATA BYTE SPICON
000000CDH SFRSYM DATA BYTE TH2
000000D0H SFRSYM DATA BIT P
00000098H.7 SFRSYM DATA BIT SM0
0000008AH SFRSYM DATA BYTE TL0
00000098H.6 SFRSYM DATA BIT SM1
0000008BH SFRSYM DATA BYTE TL1
000000D8H.6 SFRSYM DATA BIT DMA
00000098H.5 SFRSYM DATA BIT SM2
000000DFH SFRSYM DATA BYTE PSMCON
000000CCH SFRSYM DATA BYTE TL2
000000B8H.1 SFRSYM DATA BIT PT0
000000D0H.3 SFRSYM DATA BIT RS0
000000B8H.3 SFRSYM DATA BIT PT1
000000E8H.6 SFRSYM DATA BIT MDE
000000D0H.4 SFRSYM DATA BIT RS1
000000B8H.5 SFRSYM DATA BIT PT2
00000088H.4 SFRSYM DATA BIT TR0
00000088H.6 SFRSYM DATA BIT TR1
000000C8H.2 SFRSYM DATA BIT TR2
000000B8H SFRSYM DATA BIT PX0
000000B8H.2 SFRSYM DATA BIT PX1
000000E8H.4 SFRSYM DATA BIT MDI
000000EFH SFRSYM DATA BYTE ADCCON1
000000D8H SFRSYM DATA BYTE ADCCON2
00000083H SFRSYM DATA BYTE DPH
000000F5H SFRSYM DATA BYTE ADCCON3
000000E8H.5 SFRSYM DATA BIT MCO
000000E8H.7 SFRSYM DATA BIT MDO
000000C0H SFRSYM DATA BIT WDE
00000082H SFRSYM DATA BYTE DPL
000000BAH SFRSYM DATA BYTE ETIM1
000000BBH SFRSYM DATA BYTE ETIM2
000000C8H.3 SFRSYM DATA BIT EXEN2
000000C4H SFRSYM DATA BYTE ETIM3
000000E8H.2 SFRSYM DATA BIT I2CRS
00000084H SFRSYM DATA BYTE DPP
00000098H.4 SFRSYM DATA BIT REN
000000C8H SFRSYM DATA BYTE T2CON
000000F8H.5 SFRSYM DATA BIT SPE
000000C6H SFRSYM DATA BYTE EADRL
000000E8H.1 SFRSYM DATA BIT I2CTX
000000B8H.7 SFRSYM DATA BIT PSI
000000C0H.1 SFRSYM DATA BIT WDS
000000B0H SFRSYM DATA BIT RXD
000000B0H.1 SFRSYM DATA BIT TXD
000000E8H.5 SFRSYM DATA BIT D0
000000E8H.7 SFRSYM DATA BIT D1
000000D0H.5 SFRSYM DATA BIT F0
000000D0H.1 SFRSYM DATA BIT F1
000000D8H.5 SFRSYM DATA BIT CCONV
000000F2H SFRSYM DATA BYTE ADCOFSH
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 8
000000D0H SFRSYM DATA BYTE PSW
000000C0H SFRSYM DATA BYTE WDCON

010005E2H BLOCK CODE --- LVL=0
010005E2H LINE CODE --- #23
010005EDH LINE CODE --- #24
010005F3H LINE CODE --- #25
--- BLOCKEND --- --- LVL=0

01000501H BLOCK CODE --- LVL=0
01000501H BLOCK CODE NEAR LAB LVL=1
00000008H SYMBOL DATA WORD i
--- BLOCKEND --- --- LVL=1
01000501H LINE CODE --- #32
01000501H LINE CODE --- #38
01000504H LINE CODE --- #39
01000507H LINE CODE --- #40
0100050AH LINE CODE --- #41
0100050CH LINE CODE --- #42
0100050EH LINE CODE --- #46
01000511H LINE CODE --- #47
01000514H LINE CODE --- #48
01000517H LINE CODE --- #49
01000519H LINE CODE --- #50
0100051BH LINE CODE --- #51
0100051DH LINE CODE --- #53
01000528H LINE CODE --- #54
01000533H LINE CODE --- #56
0100053FH LINE CODE --- #57
01000550H LINE CODE --- #58
0100055AH LINE CODE --- #59
01000566H LINE CODE --- #60
01000592H LINE CODE --- #61
0100059CH LINE CODE --- #62
--- BLOCKEND --- --- LVL=0

--- MODULE --- --- ?C?XBANKING
0100038FH PUBLIC CODE NEAR LAB ?C?CLDXPTR
010003AAH PUBLIC CODE NEAR LAB ?C?CSTXPTR
010003BFH PUBLIC CODE NEAR LAB ?C?ILDXPTR
010003E3H PUBLIC CODE NEAR LAB ?C?ISTXPTR
01000445H PUBLIC CODE NEAR LAB ?C?LLDXPTR
01000477H PUBLIC CODE NEAR LAB ?C?LSTXPTR
010003FCH PUBLIC CODE NEAR LAB ?C?PLDXPTR
01000427H PUBLIC CODE NEAR LAB ?C?PSTXPTR
00000000H PUBLIC NUMBER --- ?C?XPAGE1RST
00000084H PUBLIC DATA BYTE ?C?XPAGE1SFR
000000E0H SFRSYM DATA BYTE ACC
000000F0H SFRSYM DATA BYTE B
00000083H SFRSYM DATA BYTE DPH
00000082H SFRSYM DATA BYTE DPL
0100039DH SYMBOL CODE NEAR LAB ??0000
010003B8H SYMBOL CODE NEAR LAB ??0001
010003CDH SYMBOL CODE NEAR LAB ??0002
010003F1H SYMBOL CODE NEAR LAB ??0003
0100040AH SYMBOL CODE NEAR LAB ??0004
01000435H SYMBOL CODE NEAR LAB ??0005
01000453H SYMBOL CODE NEAR LAB ??0006
01000485H SYMBOL CODE NEAR LAB ??0007
010003A4H SYMBOL CODE NEAR LAB CLDCODE
010003BBH SYMBOL CODE NEAR LAB CSTCODE
010003D8H SYMBOL CODE NEAR LAB ILDCODE
010003F8H SYMBOL CODE NEAR LAB ISTCODE
01000464H SYMBOL CODE NEAR LAB LLDCODE
01000492H SYMBOL CODE NEAR LAB LSTCODE
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 9
01000418H SYMBOL CODE NEAR LAB PLDCODE
01000441H SYMBOL CODE NEAR LAB PSTCODE

0100038FH BLOCK CODE NEAR LAB LVL=0
--- BLOCKEND --- --- LVL=0

--- MODULE --- --- ?C_STARTUP
01000000H PUBLIC CODE --- ?C_STARTUP

--- MODULE --- --- ?C?CLDPTR
01000496H PUBLIC CODE --- ?C?CLDPTR

--- MODULE --- --- ?C?CSTPTR
010004B4H PUBLIC CODE --- ?C?CSTPTR

--- MODULE --- --- PRINTF
0000000AH PUBLIC DATA --- ?_PRINTF517?BYTE
0000000AH PUBLIC DATA --- ?_PRINTF?BYTE
0000000AH PUBLIC DATA --- ?_SPRINTF517?BYTE
0000000AH PUBLIC DATA --- ?_SPRINTF?BYTE
01000070H PUBLIC CODE --- _PRINTF
01000070H PUBLIC CODE --- _PRINTF517
0100006AH PUBLIC CODE --- _SPRINTF
0100006AH PUBLIC CODE --- _SPRINTF517

--- MODULE --- --- ?C?PLDIIDATA
010004CBH PUBLIC CODE --- ?C?PLDIIDATA

--- MODULE --- --- ?C?CCASE
010004DBH PUBLIC CODE --- ?C?CCASE

--- MODULE --- --- PUTCHAR
0100059FH PUBLIC CODE --- _PUTCHAR

INTER-MODULE CROSS-REFERENCE LISTING
NAME . . . . . . . CLASS MODULE NAMES
========================================

?_PRINTF517?BYTE . DATA PRINTF
?_PRINTF?BYTE. . . DATA PRINTF MAIN
?_SPRINTF517?BYTE. DATA PRINTF
?_SPRINTF?BYTE . . DATA PRINTF
?C?CCASE . . . . . CODE ?C?CCASE PRINTF
?C?CLDPTR. . . . . CODE ?C?CLDPTR MAIN PRINTF
?C?CLDXPTR . . . . CODE ?C?XBANKING ?C?CLDPTR
?C?CODESEG . . . . NUMBER ** LX51 GENERATED **
?C?CSTPTR. . . . . CODE ?C?CSTPTR MAIN PRINTF
?C?CSTXPTR . . . . CODE ?C?XBANKING ?C?CSTPTR
?C?ILDXPTR . . . . CODE ?C?XBANKING
?C?ISTXPTR . . . . CODE ?C?XBANKING
?C?LLDXPTR . . . . CODE ?C?XBANKING
?C?LSTXPTR . . . . CODE ?C?XBANKING
?C?PLDIIDATA . . . CODE ?C?PLDIIDATA PRINTF
?C?PLDXPTR . . . . CODE ?C?XBANKING
?C?PSTXPTR . . . . CODE ?C?XBANKING
?C?XDATASEG. . . . NUMBER ** LX51 GENERATED **
?C?XPAGE1RST . . . NUMBER ?C?XBANKING MAIN
?C?XPAGE1SFR . . . DATA ?C?XBANKING MAIN
?C_START . . . . . CODE ** LX51 GENERATED ** ?C_STARTUP
?C_STARTUP . . . . CODE ?C_STARTUP MAIN
_PRINTF. . . . . . CODE PRINTF MAIN
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 10
_PRINTF517 . . . . CODE PRINTF
_PUTCHAR . . . . . CODE PUTCHAR PRINTF
_SPRINTF . . . . . CODE PRINTF
_SPRINTF517. . . . CODE PRINTF
AC . . . . . . . . DATA MAIN
ACC. . . . . . . . DATA MAIN
ADCCON1. . . . . . DATA MAIN
ADCCON2. . . . . . DATA MAIN
ADCCON3. . . . . . DATA MAIN
ADCDATAH . . . . . DATA MAIN
ADCDATAL . . . . . DATA MAIN
ADCGAINH . . . . . DATA MAIN
ADCGAINL . . . . . DATA MAIN
ADCI . . . . . . . DATA MAIN
ADCOFSH. . . . . . DATA MAIN
ADCOFSL. . . . . . DATA MAIN
B. . . . . . . . . DATA MAIN
CAP2 . . . . . . . DATA MAIN
CCONV. . . . . . . DATA MAIN
CNT2 . . . . . . . DATA MAIN
CPHA . . . . . . . DATA MAIN
CPOL . . . . . . . DATA MAIN
CS0. . . . . . . . DATA MAIN
CS1. . . . . . . . DATA MAIN
CS2. . . . . . . . DATA MAIN
CS3. . . . . . . . DATA MAIN
CY . . . . . . . . DATA MAIN
D0 . . . . . . . . DATA MAIN
D0EN . . . . . . . DATA MAIN
D1 . . . . . . . . DATA MAIN
D1EN . . . . . . . DATA MAIN
DAC0H. . . . . . . DATA MAIN
DAC0L. . . . . . . DATA MAIN
DAC1H. . . . . . . DATA MAIN
DAC1L. . . . . . . DATA MAIN
DACCON . . . . . . DATA MAIN
DCON . . . . . . . DATA MAIN
DMA. . . . . . . . DATA MAIN
DMAH . . . . . . . DATA MAIN
DMAL . . . . . . . DATA MAIN
DMAP . . . . . . . DATA MAIN
DPH. . . . . . . . DATA MAIN
DPL. . . . . . . . DATA MAIN
DPP. . . . . . . . DATA MAIN
EA . . . . . . . . DATA MAIN
EADC . . . . . . . DATA MAIN
EADRL. . . . . . . DATA MAIN
ECON . . . . . . . DATA MAIN
EDATA1 . . . . . . DATA MAIN
EDATA2 . . . . . . DATA MAIN
EDATA3 . . . . . . DATA MAIN
EDATA4 . . . . . . DATA MAIN
ES . . . . . . . . DATA MAIN
ET0. . . . . . . . DATA MAIN
ET1. . . . . . . . DATA MAIN
ET2. . . . . . . . DATA MAIN
ETIM1. . . . . . . DATA MAIN
ETIM2. . . . . . . DATA MAIN
ETIM3. . . . . . . DATA MAIN
EX0. . . . . . . . DATA MAIN
EX1. . . . . . . . DATA MAIN
EXEN2. . . . . . . DATA MAIN
EXF2 . . . . . . . DATA MAIN
F0 . . . . . . . . DATA MAIN
F1 . . . . . . . . DATA MAIN
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 11
I2CADD . . . . . . DATA MAIN
I2CCON . . . . . . DATA MAIN
I2CDAT . . . . . . DATA MAIN
I2CI . . . . . . . DATA MAIN
I2CM . . . . . . . DATA MAIN
I2CRS. . . . . . . DATA MAIN
I2CTX. . . . . . . DATA MAIN
IE . . . . . . . . DATA MAIN
IE0. . . . . . . . DATA MAIN
IE1. . . . . . . . DATA MAIN
IE2. . . . . . . . DATA MAIN
INT0 . . . . . . . DATA MAIN
INT1 . . . . . . . DATA MAIN
IP . . . . . . . . DATA MAIN
ISPI . . . . . . . DATA MAIN
IT0. . . . . . . . DATA MAIN
IT1. . . . . . . . DATA MAIN
large_array. . . . HDATA MAIN
main . . . . . . . CODE MAIN
MCO. . . . . . . . DATA MAIN
MDE. . . . . . . . DATA MAIN
MDI. . . . . . . . DATA MAIN
MDO. . . . . . . . DATA MAIN
OV . . . . . . . . DATA MAIN
P. . . . . . . . . DATA MAIN
P0 . . . . . . . . DATA MAIN
P1 . . . . . . . . DATA MAIN
P2 . . . . . . . . DATA MAIN
P3 . . . . . . . . DATA MAIN
PADC . . . . . . . DATA MAIN
PCON . . . . . . . DATA MAIN
PRE0 . . . . . . . DATA MAIN
PRE1 . . . . . . . DATA MAIN
PRE2 . . . . . . . DATA MAIN
PS . . . . . . . . DATA MAIN
PSI. . . . . . . . DATA MAIN
PSMCON . . . . . . DATA MAIN
PSW. . . . . . . . DATA MAIN
PT0. . . . . . . . DATA MAIN
PT1. . . . . . . . DATA MAIN
PT2. . . . . . . . DATA MAIN
PX0. . . . . . . . DATA MAIN
PX1. . . . . . . . DATA MAIN
RB8. . . . . . . . DATA MAIN
RCAP2H . . . . . . DATA MAIN
RCAP2L . . . . . . DATA MAIN
RCLK . . . . . . . DATA MAIN
RD . . . . . . . . DATA MAIN
REN. . . . . . . . DATA MAIN
RI . . . . . . . . DATA MAIN
RS0. . . . . . . . DATA MAIN
RS1. . . . . . . . DATA MAIN
RXD. . . . . . . . DATA MAIN
SBUF . . . . . . . DATA MAIN
SCON . . . . . . . DATA MAIN
SCONV. . . . . . . DATA MAIN
SM0. . . . . . . . DATA MAIN
SM1. . . . . . . . DATA MAIN
SM2. . . . . . . . DATA MAIN
SP . . . . . . . . DATA MAIN
SPE. . . . . . . . DATA MAIN
SPICON . . . . . . DATA MAIN
SPIDAT . . . . . . DATA MAIN
SPIM . . . . . . . DATA MAIN
SPR0 . . . . . . . DATA MAIN
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 12
SPR1 . . . . . . . DATA MAIN
T0 . . . . . . . . DATA MAIN
T1 . . . . . . . . DATA MAIN
T2 . . . . . . . . DATA MAIN
T2CON. . . . . . . DATA MAIN
T2EX . . . . . . . DATA MAIN
TB8. . . . . . . . DATA MAIN
TCLK . . . . . . . DATA MAIN
TCON . . . . . . . DATA MAIN
TF0. . . . . . . . DATA MAIN
TF1. . . . . . . . DATA MAIN
TF2. . . . . . . . DATA MAIN
TH0. . . . . . . . DATA MAIN
TH1. . . . . . . . DATA MAIN
TH2. . . . . . . . DATA MAIN
TI . . . . . . . . DATA MAIN
timer0 . . . . . . CODE MAIN
timer_tick . . . . XDATA MAIN
TL0. . . . . . . . DATA MAIN
TL1. . . . . . . . DATA MAIN
TL2. . . . . . . . DATA MAIN
TMOD . . . . . . . DATA MAIN
TR0. . . . . . . . DATA MAIN
TR1. . . . . . . . DATA MAIN
TR2. . . . . . . . DATA MAIN
TXD. . . . . . . . DATA MAIN
WCOL . . . . . . . DATA MAIN
WDCON. . . . . . . DATA MAIN
WDE. . . . . . . . DATA MAIN
WDR1 . . . . . . . DATA MAIN
WDR2 . . . . . . . DATA MAIN
WDS. . . . . . . . DATA MAIN
WR . . . . . . . . DATA MAIN

Program Size: data=32.1 xdata=49153 const=0 code=1536
LX51 RUN COMPLETE. 0 WARNING(S), 0 ERROR(S)
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 4 '07 #14

P: n/a
In article <5c*************@mid.individual.net>, Martin Ambuhl
<ma*****@earthlink.netwrites
>Chris Hills wrote:
>In article <11**********************@j4g2000prf.googlegroups. com>,
Ravi <ra*********@gmail.comwrites
>>Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
Try looking at the map file that is output by the compiler.

That is, of course, absurd. The output of the compiler tells you
*nothing* about the memory addresses used by the program.
> Ignore the netpolice.

More important is to ignore Chris Hills, who obviously knows nothing.
:-)

Clearly one of use knows less than he thinks.

Before you ask.... this compiler aggressively overlays data so several
variables can have the same address.....

ACTIVE MEMORY CLASSES OF MODULE: LARGE_RAM (MAIN)

BASE START END USED MEMORY CLASS
================================================== ====
X:000000H X:020000H X:02FFFFH 00C000H HDATA
C:000000H C:000000H C:00FFFFH 000600H CODE
I:000000H I:000000H I:00007FH 00001EH DATA
X:000000H X:000000H X:00FFFFH 000001H XDATA
I:000000H I:000000H I:0000FFH 000001H IDATA
I:000020H.0 I:000020H.0 I:00002FH.7 000001H.1 BIT
MEMORY MAP OF MODULE: LARGE_RAM (MAIN)

START STOP LENGTH ALIGN RELOC MEMORY CLASS SEGMENT NAME
================================================== ====
* * * * * * * * * * * D A T A M E M O R Y * * * * * * * * * * * *
*
000000H 000007H 000008H --- AT.. DATA "REG BANK
0"
000008H 00001DH 000016H BYTE UNIT DATA _DATA_GROUP_
00001EH.0 00001FH.7 000002H.0 --- --- **GAP**
000020H.0 000021H.0 000001H.1 BIT UNIT BIT _BIT_GROUP_
000021H.1 000021H 000000H.7 --- --- **GAP**
000022H 000022H 000001H BYTE UNIT IDATA ?STACK

* * * * * * * * * * * C O D E M E M O R Y * * * * * * * * * * * *
*
000000H 000002H 000003H --- OFFS.. CODE ?CO??C_STARTUP?0
000003H 00000AH 000008H --- --- **GAP**
00000BH 00000DH 000003H BYTE OFFS.. CODE ?MAIN?0000B
00000EH 00038EH 000381H BYTE UNIT CODE ?PR?PRINTF?PRINTF
00038FH 000500H 000172H BYTE UNIT CODE ?C?LIB_CODE
000501H 00059EH 00009EH BYTE UNIT CODE ?PR?MAIN?MAIN
00059FH 0005C5H 000027H BYTE UNIT CODE ?PR?PUTCHAR?PUTCHAR
0005C6H 0005E1H 00001CH BYTE UNIT CODE ?CO?MAIN
0005E2H 0005FBH 00001AH BYTE UNIT CODE ?PR?TIMER0?MAIN
0005FCH 000607H 00000CH BYTE UNIT CODE ?C_C51STARTUP
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 2

* * * * * * * * * * * X D A T A M E M O R Y * * * * * * * * * * * *
*
000000H 000000H 000001H BYTE UNIT XDATA ?XD?MAIN
000001H 01FFFFH 01FFFFH --- --- **GAP**
020000H 02BFFFH 00C000H BYTE INSEG HDATA ?FD?MAIN

OVERLAY MAP OF MODULE: LARGE_RAM (MAIN)
FUNCTION/MODULE BIT_GROUP DATA_GROUP
--CALLED FUNCTION/MODULE START STOP START STOP
================================================== ==
TIMER0/MAIN ----- ----- ----- -----

*** NEW ROOT **************

?C_C51STARTUP ----- ----- ----- -----
+--?PR?MAIN?MAIN

MAIN/MAIN ----- ----- 0008H 0009H
+--?CO?MAIN
+--?PR?PRINTF?PRINTF

?CO?MAIN ----- ----- ----- -----

PRINTF/PRINTF 20H.0 21H.0 000AH 001DH
+--?PR?PUTCHAR?PUTCHAR

PUTCHAR/PUTCHAR ----- ----- ----- -----

PUBLIC SYMBOLS OF MODULE: LARGE_RAM (MAIN)
VALUE CLASS TYPE PUBLIC SYMBOL NAME
=================================================
0000000AH DATA --- ?_PRINTF517?BYTE
0000000AH DATA --- ?_PRINTF?BYTE
0000000AH DATA --- ?_SPRINTF517?BYTE
0000000AH DATA --- ?_SPRINTF?BYTE
010004DBH CODE --- ?C?CCASE
01000496H CODE --- ?C?CLDPTR
0100038FH CODE NEAR LAB ?C?CLDXPTR
00000000H NUMBER --- ?C?CODESEG
010004B4H CODE --- ?C?CSTPTR
010003AAH CODE NEAR LAB ?C?CSTXPTR
010003BFH CODE NEAR LAB ?C?ILDXPTR
010003E3H CODE NEAR LAB ?C?ISTXPTR
01000445H CODE NEAR LAB ?C?LLDXPTR
01000477H CODE NEAR LAB ?C?LSTXPTR
010004CBH CODE --- ?C?PLDIIDATA
010003FCH CODE NEAR LAB ?C?PLDXPTR
01000427H CODE NEAR LAB ?C?PSTXPTR
00000000H NUMBER --- ?C?XDATASEG
00000000H NUMBER --- ?C?XPAGE1RST
00000084H DATA BYTE ?C?XPAGE1SFR
01000501H CODE --- ?C_START
01000000H CODE --- ?C_STARTUP
01000070H CODE --- _PRINTF
01000070H CODE --- _PRINTF517
0100059FH CODE --- _PUTCHAR
0100006AH CODE --- _SPRINTF

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 4 '07 #15

P: n/a
In article <5c*************@mid.individual.net>, Martin Ambuhl
<ma*****@earthlink.netwrites
>Chris Hills wrote:
>In article <11**********************@j4g2000prf.googlegroups. com
>>>, Ravi <ra*********@gmail.comwrites
Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
Try looking at the map file that is output by the compiler.

That is, of course, absurd. The output of the compiler tells you *nothing*
about the memory addresses used by the program.
> Ignore the netpolice.

More important is to ignore Chris Hills, who obviously knows nothing.
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 1
LX51 LINKER/LOCATER V4.09, INVOKED BY:
C:\KEIL\C51\BIN\LX51.EXE MAIN.obj, XBANKING.obj TO LARGE_RAM IXREF
CLASSES (HDATA (X:0X020000-X:0X02FFFF))
CPU MODE: 8051 MODE
MEMORY MODEL: SMALL
INPUT MODULES INCLUDED:
MAIN.obj (MAIN)
COMMENT TYPE 0: C51 V8.05a
XBANKING.obj (?C?XBANKING)
COMMENT TYPE 0: AX51 V3.01a
C:\KEIL\C51\LIB\C51BS.LIB (?C_STARTUP)
COMMENT TYPE 1: A51 / ASM51 Assembler
C:\KEIL\C51\LIB\C51BS.LIB (?C?CLDPTR)
COMMENT TYPE 1: A51 / ASM51 Assembler
C:\KEIL\C51\LIB\C51BS.LIB (?C?CSTPTR)
COMMENT TYPE 1: A51 / ASM51 Assembler
C:\KEIL\C51\LIB\C51BS.LIB (PRINTF)
COMMENT TYPE 1: A51 / ASM51 Assembler
C:\KEIL\C51\LIB\C51BS.LIB (?C?PLDIIDATA)
COMMENT TYPE 1: A51 / ASM51 Assembler
C:\KEIL\C51\LIB\C51BS.LIB (?C?CCASE)
COMMENT TYPE 1: A51 / ASM51 Assembler
C:\KEIL\C51\LIB\C51BS.LIB (PUTCHAR)
COMMENT TYPE 1: A51 / ASM51 Assembler
ACTIVE MEMORY CLASSES OF MODULE: LARGE_RAM (MAIN)

BASE START END USED MEMORY CLASS
================================================== ========
X:000000H X:020000H X:02FFFFH 00C000H HDATA
C:000000H C:000000H C:00FFFFH 000600H CODE
I:000000H I:000000H I:00007FH 00001EH DATA
X:000000H X:000000H X:00FFFFH 000001H XDATA
I:000000H I:000000H I:0000FFH 000001H IDATA
I:000020H.0 I:000020H.0 I:00002FH.7 000001H.1 BIT
MEMORY MAP OF MODULE: LARGE_RAM (MAIN)
START STOP LENGTH ALIGN RELOC MEMORY CLASS SEGMENT NAME
================================================== =======================

* * * * * * * * * * * D A T A M E M O R Y * * * * * * * * * * * *
*
000000H 000007H 000008H --- AT.. DATA "REG BANK
0"
000008H 00001DH 000016H BYTE UNIT DATA _DATA_GROUP_
00001EH.0 00001FH.7 000002H.0 --- --- **GAP**
000020H.0 000021H.0 000001H.1 BIT UNIT BIT _BIT_GROUP_
000021H.1 000021H 000000H.7 --- --- **GAP**
000022H 000022H 000001H BYTE UNIT IDATA ?STACK

* * * * * * * * * * * C O D E M E M O R Y * * * * * * * * * * * *
*
000000H 000002H 000003H --- OFFS.. CODE ?CO??C_STARTUP?0
000003H 00000AH 000008H --- --- **GAP**
00000BH 00000DH 000003H BYTE OFFS.. CODE ?MAIN?0000B
00000EH 00038EH 000381H BYTE UNIT CODE ?PR?PRINTF?PRINTF
00038FH 000500H 000172H BYTE UNIT CODE ?C?LIB_CODE
000501H 00059EH 00009EH BYTE UNIT CODE ?PR?MAIN?MAIN
00059FH 0005C5H 000027H BYTE UNIT CODE ?PR?PUTCHAR?PUTCHAR
0005C6H 0005E1H 00001CH BYTE UNIT CODE ?CO?MAIN
0005E2H 0005FBH 00001AH BYTE UNIT CODE ?PR?TIMER0?MAIN
0005FCH 000607H 00000CH BYTE UNIT CODE ?C_C51STARTUP
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 2

* * * * * * * * * * * X D A T A M E M O R Y * * * * * * * * * * * *
*
000000H 000000H 000001H BYTE UNIT XDATA ?XD?MAIN
000001H 01FFFFH 01FFFFH --- --- **GAP**
020000H 02BFFFH 00C000H BYTE INSEG HDATA ?FD?MAIN

OVERLAY MAP OF MODULE: LARGE_RAM (MAIN)
FUNCTION/MODULE BIT_GROUP DATA_GROUP
--CALLED FUNCTION/MODULE START STOP START STOP
================================================== ==
TIMER0/MAIN ----- ----- ----- -----

*** NEW ROOT **************

?C_C51STARTUP ----- ----- ----- -----
+--?PR?MAIN?MAIN

MAIN/MAIN ----- ----- 0008H 0009H
+--?CO?MAIN
+--?PR?PRINTF?PRINTF

?CO?MAIN ----- ----- ----- -----

PRINTF/PRINTF 20H.0 21H.0 000AH 001DH
+--?PR?PUTCHAR?PUTCHAR

PUTCHAR/PUTCHAR ----- ----- ----- -----

PUBLIC SYMBOLS OF MODULE: LARGE_RAM (MAIN)
VALUE CLASS TYPE PUBLIC SYMBOL NAME
=================================================
0000000AH DATA --- ?_PRINTF517?BYTE
0000000AH DATA --- ?_PRINTF?BYTE
0000000AH DATA --- ?_SPRINTF517?BYTE
0000000AH DATA --- ?_SPRINTF?BYTE
010004DBH CODE --- ?C?CCASE
01000496H CODE --- ?C?CLDPTR
0100038FH CODE NEAR LAB ?C?CLDXPTR
00000000H NUMBER --- ?C?CODESEG
010004B4H CODE --- ?C?CSTPTR
010003AAH CODE NEAR LAB ?C?CSTXPTR
010003BFH CODE NEAR LAB ?C?ILDXPTR
010003E3H CODE NEAR LAB ?C?ISTXPTR
01000445H CODE NEAR LAB ?C?LLDXPTR
01000477H CODE NEAR LAB ?C?LSTXPTR
010004CBH CODE --- ?C?PLDIIDATA
010003FCH CODE NEAR LAB ?C?PLDXPTR
01000427H CODE NEAR LAB ?C?PSTXPTR
00000000H NUMBER --- ?C?XDATASEG
00000000H NUMBER --- ?C?XPAGE1RST
00000084H DATA BYTE ?C?XPAGE1SFR
01000501H CODE --- ?C_START
01000000H CODE --- ?C_STARTUP
01000070H CODE --- _PRINTF
01000070H CODE --- _PRINTF517
0100059FH CODE --- _PUTCHAR
0100006AH CODE --- _SPRINTF
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 3
0100006AH CODE --- _SPRINTF517
*SFR* 000000D0H.6 DATA BIT AC
*SFR* 000000E0H DATA BYTE ACC
*SFR* 000000EFH DATA BYTE ADCCON1
*SFR* 000000D8H DATA BYTE ADCCON2
*SFR* 000000F5H DATA BYTE ADCCON3
*SFR* 000000DAH DATA BYTE ADCDATAH
*SFR* 000000D9H DATA BYTE ADCDATAL
*SFR* 000000F4H DATA BYTE ADCGAINH
*SFR* 000000F3H DATA BYTE ADCGAINL
*SFR* 000000D8H.7 DATA BIT ADCI
*SFR* 000000F2H DATA BYTE ADCOFSH
*SFR* 000000F1H DATA BYTE ADCOFSL
*SFR* 000000F0H DATA BYTE B
*SFR* 000000C8H DATA BIT CAP2
*SFR* 000000D8H.5 DATA BIT CCONV
*SFR* 000000C8H.1 DATA BIT CNT2
*SFR* 000000F8H.2 DATA BIT CPHA
*SFR* 000000F8H.3 DATA BIT CPOL
*SFR* 000000D8H DATA BIT CS0
*SFR* 000000D8H.1 DATA BIT CS1
*SFR* 000000D8H.2 DATA BIT CS2
*SFR* 000000D8H.3 DATA BIT CS3
*SFR* 000000D0H.7 DATA BIT CY
*SFR* 000000E8H.5 DATA BIT D0
*SFR* 000000E8H.3 DATA BIT D0EN
*SFR* 000000E8H.7 DATA BIT D1
*SFR* 000000E8H.6 DATA BIT D1EN
*SFR* 000000FAH DATA BYTE DAC0H
*SFR* 000000F9H DATA BYTE DAC0L
*SFR* 000000FCH DATA BYTE DAC1H
*SFR* 000000FBH DATA BYTE DAC1L
*SFR* 000000FDH DATA BYTE DACCON
*SFR* 000000E8H DATA BYTE DCON
*SFR* 000000D8H.6 DATA BIT DMA
*SFR* 000000D3H DATA BYTE DMAH
*SFR* 000000D2H DATA BYTE DMAL
*SFR* 000000D4H DATA BYTE DMAP
*SFR* 00000083H DATA BYTE DPH
*SFR* 00000082H DATA BYTE DPL
*SFR* 00000084H DATA BYTE DPP
*SFR* 000000A8H.7 DATA BIT EA
*SFR* 000000A8H.6 DATA BIT EADC
*SFR* 000000C6H DATA BYTE EADRL
*SFR* 000000B9H DATA BYTE ECON
*SFR* 000000BCH DATA BYTE EDATA1
*SFR* 000000BDH DATA BYTE EDATA2
*SFR* 000000BEH DATA BYTE EDATA3
*SFR* 000000BFH DATA BYTE EDATA4
*SFR* 000000A8H.4 DATA BIT ES
*SFR* 000000A8H.1 DATA BIT ET0
*SFR* 000000A8H.3 DATA BIT ET1
*SFR* 000000A8H.5 DATA BIT ET2
*SFR* 000000BAH DATA BYTE ETIM1
*SFR* 000000BBH DATA BYTE ETIM2
*SFR* 000000C4H DATA BYTE ETIM3
*SFR* 000000A8H DATA BIT EX0
*SFR* 000000A8H.2 DATA BIT EX1
*SFR* 000000C8H.3 DATA BIT EXEN2
*SFR* 000000C8H.6 DATA BIT EXF2
*SFR* 000000D0H.5 DATA BIT F0
*SFR* 000000D0H.1 DATA BIT F1
*SFR* 0000009BH DATA BYTE I2CADD
*SFR* 000000E8H DATA BYTE I2CCON
*SFR* 0000009AH DATA BYTE I2CDAT
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 4
*SFR* 000000E8H DATA BIT I2CI
*SFR* 000000E8H.3 DATA BIT I2CM
*SFR* 000000E8H.2 DATA BIT I2CRS
*SFR* 000000E8H.1 DATA BIT I2CTX
*SFR* 000000A8H DATA BYTE IE
*SFR* 00000088H.1 DATA BIT IE0
*SFR* 00000088H.3 DATA BIT IE1
*SFR* 000000A9H DATA BYTE IE2
*SFR* 000000B0H.2 DATA BIT INT0
*SFR* 000000B0H.3 DATA BIT INT1
*SFR* 000000B8H DATA BYTE IP
*SFR* 000000F8H.7 DATA BIT ISPI
*SFR* 00000088H DATA BIT IT0
*SFR* 00000088H.2 DATA BIT IT1
02020000H HDATA --- large_array
01000501H CODE --- main
*SFR* 000000E8H.5 DATA BIT MCO
*SFR* 000000E8H.6 DATA BIT MDE
*SFR* 000000E8H.4 DATA BIT MDI
*SFR* 000000E8H.7 DATA BIT MDO
*SFR* 000000D0H.2 DATA BIT OV
*SFR* 000000D0H DATA BIT P
*SFR* 00000080H DATA BYTE P0
*SFR* 00000090H DATA BYTE P1
*SFR* 000000A0H DATA BYTE P2
*SFR* 000000B0H DATA BYTE P3
*SFR* 000000B8H.6 DATA BIT PADC
*SFR* 00000087H DATA BYTE PCON
*SFR* 000000C0H.5 DATA BIT PRE0
*SFR* 000000C0H.6 DATA BIT PRE1
*SFR* 000000C0H.7 DATA BIT PRE2
*SFR* 000000B8H.4 DATA BIT PS
*SFR* 000000B8H.7 DATA BIT PSI
*SFR* 000000DFH DATA BYTE PSMCON
*SFR* 000000D0H DATA BYTE PSW
*SFR* 000000B8H.1 DATA BIT PT0
*SFR* 000000B8H.3 DATA BIT PT1
*SFR* 000000B8H.5 DATA BIT PT2
*SFR* 000000B8H DATA BIT PX0
*SFR* 000000B8H.2 DATA BIT PX1
*SFR* 00000098H.2 DATA BIT RB8
*SFR* 000000CBH DATA BYTE RCAP2H
*SFR* 000000CAH DATA BYTE RCAP2L
*SFR* 000000C8H.5 DATA BIT RCLK
*SFR* 000000B0H.7 DATA BIT RD
*SFR* 00000098H.4 DATA BIT REN
*SFR* 00000098H DATA BIT RI
*SFR* 000000D0H.3 DATA BIT RS0
*SFR* 000000D0H.4 DATA BIT RS1
*SFR* 000000B0H DATA BIT RXD
*SFR* 00000099H DATA BYTE SBUF
*SFR* 00000098H DATA BYTE SCON
*SFR* 000000D8H.4 DATA BIT SCONV
*SFR* 00000098H.7 DATA BIT SM0
*SFR* 00000098H.6 DATA BIT SM1
*SFR* 00000098H.5 DATA BIT SM2
*SFR* 00000081H DATA BYTE SP
*SFR* 000000F8H.5 DATA BIT SPE
*SFR* 000000F8H DATA BYTE SPICON
*SFR* 000000F7H DATA BYTE SPIDAT
*SFR* 000000F8H.4 DATA BIT SPIM
*SFR* 000000F8H DATA BIT SPR0
*SFR* 000000F8H.1 DATA BIT SPR1
*SFR* 000000B0H.4 DATA BIT T0
*SFR* 000000B0H.5 DATA BIT T1
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 5
*SFR* 00000090H DATA BIT T2
*SFR* 000000C8H DATA BYTE T2CON
*SFR* 00000090H.1 DATA BIT T2EX
*SFR* 00000098H.3 DATA BIT TB8
*SFR* 000000C8H.4 DATA BIT TCLK
*SFR* 00000088H DATA BYTE TCON
*SFR* 00000088H.5 DATA BIT TF0
*SFR* 00000088H.7 DATA BIT TF1
*SFR* 000000C8H.7 DATA BIT TF2
*SFR* 0000008CH DATA BYTE TH0
*SFR* 0000008DH DATA BYTE TH1
*SFR* 000000CDH DATA BYTE TH2
*SFR* 00000098H.1 DATA BIT TI
010005E2H CODE --- timer0
02000000H XDATA BYTE timer_tick
*SFR* 0000008AH DATA BYTE TL0
*SFR* 0000008BH DATA BYTE TL1
*SFR* 000000CCH DATA BYTE TL2
*SFR* 00000089H DATA BYTE TMOD
*SFR* 00000088H.4 DATA BIT TR0
*SFR* 00000088H.6 DATA BIT TR1
*SFR* 000000C8H.2 DATA BIT TR2
*SFR* 000000B0H.1 DATA BIT TXD
*SFR* 000000F8H.6 DATA BIT WCOL
*SFR* 000000C0H DATA BYTE WDCON
*SFR* 000000C0H DATA BIT WDE
*SFR* 000000C0H.3 DATA BIT WDR1
*SFR* 000000C0H.2 DATA BIT WDR2
*SFR* 000000C0H.1 DATA BIT WDS
*SFR* 000000B0H.6 DATA BIT WR

SYMBOL TABLE OF MODULE: LARGE_RAM (MAIN)

VALUE REP CLASS TYPE SYMBOL NAME
================================================== ==
--- MODULE --- --- MAIN
02000000H PUBLIC XDATA BYTE timer_tick
02020000H PUBLIC HDATA --- large_array
01000501H PUBLIC CODE --- main
010005E2H PUBLIC CODE --- timer0
000000F1H SFRSYM DATA BYTE ADCOFSL
00000080H SFRSYM DATA BYTE P0
00000090H SFRSYM DATA BYTE P1
000000A0H SFRSYM DATA BYTE P2
000000B0H SFRSYM DATA BYTE P3
000000D0H.6 SFRSYM DATA BIT AC
000000B0H.4 SFRSYM DATA BIT T0
000000B0H.5 SFRSYM DATA BIT T1
000000A8H.7 SFRSYM DATA BIT EA
00000090H SFRSYM DATA BIT T2
000000C8H SFRSYM DATA BIT CAP2
000000E8H.3 SFRSYM DATA BIT D0EN
000000E8H SFRSYM DATA BIT I2CI
000000E8H.6 SFRSYM DATA BIT D1EN
0000009BH SFRSYM DATA BYTE I2CADD
000000D8H.4 SFRSYM DATA BIT SCONV
000000E8H.3 SFRSYM DATA BIT I2CM
000000A8H.6 SFRSYM DATA BIT EADC
000000A8H SFRSYM DATA BYTE IE
000000D8H.7 SFRSYM DATA BIT ADCI
000000BCH SFRSYM DATA BYTE EDATA1
000000BDH SFRSYM DATA BYTE EDATA2
000000BEH SFRSYM DATA BYTE EDATA3
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 6
000000BFH SFRSYM DATA BYTE EDATA4
000000C8H.6 SFRSYM DATA BIT EXF2
000000B0H.7 SFRSYM DATA BIT RD
000000C8H.1 SFRSYM DATA BIT CNT2
000000C0H.5 SFRSYM DATA BIT PRE0
000000A8H.4 SFRSYM DATA BIT ES
000000C0H.6 SFRSYM DATA BIT PRE1
000000B8H.6 SFRSYM DATA BIT PADC
000000B8H SFRSYM DATA BYTE IP
0000009AH SFRSYM DATA BYTE I2CDAT
000000C0H.7 SFRSYM DATA BIT PRE2
00000098H SFRSYM DATA BIT RI
000000D3H SFRSYM DATA BYTE DMAH
000000D0H.7 SFRSYM DATA BIT CY
000000B0H.2 SFRSYM DATA BIT INT0
000000F8H.2 SFRSYM DATA BIT CPHA
000000B0H.3 SFRSYM DATA BIT INT1
00000098H.1 SFRSYM DATA BIT TI
000000C0H.3 SFRSYM DATA BIT WDR1
000000D2H SFRSYM DATA BYTE DMAL
000000C0H.2 SFRSYM DATA BIT WDR2
000000E8H SFRSYM DATA BYTE I2CCON
000000CBH SFRSYM DATA BYTE RCAP2H
000000B8H.4 SFRSYM DATA BIT PS
000000D4H SFRSYM DATA BYTE DMAP
00000081H SFRSYM DATA BYTE SP
00000090H.1 SFRSYM DATA BIT T2EX
000000D0H.2 SFRSYM DATA BIT OV
000000E8H SFRSYM DATA BYTE DCON
000000F8H SFRSYM DATA BIT SPR0
000000CAH SFRSYM DATA BYTE RCAP2L
000000B9H SFRSYM DATA BYTE ECON
000000F8H.1 SFRSYM DATA BIT SPR1
000000B0H.6 SFRSYM DATA BIT WR
000000FDH SFRSYM DATA BYTE DACCON
000000C8H.5 SFRSYM DATA BIT RCLK
000000DAH SFRSYM DATA BYTE ADCDATAH
000000F8H.3 SFRSYM DATA BIT CPOL
000000C8H.4 SFRSYM DATA BIT TCLK
000000D9H SFRSYM DATA BYTE ADCDATAL
00000099H SFRSYM DATA BYTE SBUF
00000087H SFRSYM DATA BYTE PCON
000000F4H SFRSYM DATA BYTE ADCGAINH
00000098H SFRSYM DATA BYTE SCON
00000089H SFRSYM DATA BYTE TMOD
00000088H SFRSYM DATA BYTE TCON
000000F8H.6 SFRSYM DATA BIT WCOL
000000F8H.7 SFRSYM DATA BIT ISPI
000000F3H SFRSYM DATA BYTE ADCGAINL
000000F8H.4 SFRSYM DATA BIT SPIM
00000088H.1 SFRSYM DATA BIT IE0
00000088H.3 SFRSYM DATA BIT IE1
000000A9H SFRSYM DATA BYTE IE2
000000FAH SFRSYM DATA BYTE DAC0H
000000F0H SFRSYM DATA BYTE B
000000FCH SFRSYM DATA BYTE DAC1H
000000F9H SFRSYM DATA BYTE DAC0L
000000D8H SFRSYM DATA BIT CS0
000000FBH SFRSYM DATA BYTE DAC1L
000000D8H.1 SFRSYM DATA BIT CS1
000000F7H SFRSYM DATA BYTE SPIDAT
000000E0H SFRSYM DATA BYTE ACC
000000D8H.2 SFRSYM DATA BIT CS2
000000D8H.3 SFRSYM DATA BIT CS3
000000A8H.1 SFRSYM DATA BIT ET0
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 7
000000A8H.3 SFRSYM DATA BIT ET1
00000088H.5 SFRSYM DATA BIT TF0
000000A8H.5 SFRSYM DATA BIT ET2
00000088H.7 SFRSYM DATA BIT TF1
000000C8H.7 SFRSYM DATA BIT TF2
00000098H.2 SFRSYM DATA BIT RB8
0000008CH SFRSYM DATA BYTE TH0
000000A8H SFRSYM DATA BIT EX0
00000088H SFRSYM DATA BIT IT0
0000008DH SFRSYM DATA BYTE TH1
000000A8H.2 SFRSYM DATA BIT EX1
00000098H.3 SFRSYM DATA BIT TB8
00000088H.2 SFRSYM DATA BIT IT1
000000F8H SFRSYM DATA BYTE SPICON
000000CDH SFRSYM DATA BYTE TH2
000000D0H SFRSYM DATA BIT P
00000098H.7 SFRSYM DATA BIT SM0
0000008AH SFRSYM DATA BYTE TL0
00000098H.6 SFRSYM DATA BIT SM1
0000008BH SFRSYM DATA BYTE TL1
000000D8H.6 SFRSYM DATA BIT DMA
00000098H.5 SFRSYM DATA BIT SM2
000000DFH SFRSYM DATA BYTE PSMCON
000000CCH SFRSYM DATA BYTE TL2
000000B8H.1 SFRSYM DATA BIT PT0
000000D0H.3 SFRSYM DATA BIT RS0
000000B8H.3 SFRSYM DATA BIT PT1
000000E8H.6 SFRSYM DATA BIT MDE
000000D0H.4 SFRSYM DATA BIT RS1
000000B8H.5 SFRSYM DATA BIT PT2
00000088H.4 SFRSYM DATA BIT TR0
00000088H.6 SFRSYM DATA BIT TR1
000000C8H.2 SFRSYM DATA BIT TR2
000000B8H SFRSYM DATA BIT PX0
000000B8H.2 SFRSYM DATA BIT PX1
000000E8H.4 SFRSYM DATA BIT MDI
000000EFH SFRSYM DATA BYTE ADCCON1
000000D8H SFRSYM DATA BYTE ADCCON2
00000083H SFRSYM DATA BYTE DPH
000000F5H SFRSYM DATA BYTE ADCCON3
000000E8H.5 SFRSYM DATA BIT MCO
000000E8H.7 SFRSYM DATA BIT MDO
000000C0H SFRSYM DATA BIT WDE
00000082H SFRSYM DATA BYTE DPL
000000BAH SFRSYM DATA BYTE ETIM1
000000BBH SFRSYM DATA BYTE ETIM2
000000C8H.3 SFRSYM DATA BIT EXEN2
000000C4H SFRSYM DATA BYTE ETIM3
000000E8H.2 SFRSYM DATA BIT I2CRS
00000084H SFRSYM DATA BYTE DPP
00000098H.4 SFRSYM DATA BIT REN
000000C8H SFRSYM DATA BYTE T2CON
000000F8H.5 SFRSYM DATA BIT SPE
000000C6H SFRSYM DATA BYTE EADRL
000000E8H.1 SFRSYM DATA BIT I2CTX
000000B8H.7 SFRSYM DATA BIT PSI
000000C0H.1 SFRSYM DATA BIT WDS
000000B0H SFRSYM DATA BIT RXD
000000B0H.1 SFRSYM DATA BIT TXD
000000E8H.5 SFRSYM DATA BIT D0
000000E8H.7 SFRSYM DATA BIT D1
000000D0H.5 SFRSYM DATA BIT F0
000000D0H.1 SFRSYM DATA BIT F1
000000D8H.5 SFRSYM DATA BIT CCONV
000000F2H SFRSYM DATA BYTE ADCOFSH
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 8
000000D0H SFRSYM DATA BYTE PSW
000000C0H SFRSYM DATA BYTE WDCON

010005E2H BLOCK CODE --- LVL=0
010005E2H LINE CODE --- #23
010005EDH LINE CODE --- #24
010005F3H LINE CODE --- #25
--- BLOCKEND --- --- LVL=0

01000501H BLOCK CODE --- LVL=0
01000501H BLOCK CODE NEAR LAB LVL=1
00000008H SYMBOL DATA WORD i
--- BLOCKEND --- --- LVL=1
01000501H LINE CODE --- #32
01000501H LINE CODE --- #38
01000504H LINE CODE --- #39
01000507H LINE CODE --- #40
0100050AH LINE CODE --- #41
0100050CH LINE CODE --- #42
0100050EH LINE CODE --- #46
01000511H LINE CODE --- #47
01000514H LINE CODE --- #48
01000517H LINE CODE --- #49
01000519H LINE CODE --- #50
0100051BH LINE CODE --- #51
0100051DH LINE CODE --- #53
01000528H LINE CODE --- #54
01000533H LINE CODE --- #56
0100053FH LINE CODE --- #57
01000550H LINE CODE --- #58
0100055AH LINE CODE --- #59
01000566H LINE CODE --- #60
01000592H LINE CODE --- #61
0100059CH LINE CODE --- #62
--- BLOCKEND --- --- LVL=0

--- MODULE --- --- ?C?XBANKING
0100038FH PUBLIC CODE NEAR LAB ?C?CLDXPTR
010003AAH PUBLIC CODE NEAR LAB ?C?CSTXPTR
010003BFH PUBLIC CODE NEAR LAB ?C?ILDXPTR
010003E3H PUBLIC CODE NEAR LAB ?C?ISTXPTR
01000445H PUBLIC CODE NEAR LAB ?C?LLDXPTR
01000477H PUBLIC CODE NEAR LAB ?C?LSTXPTR
010003FCH PUBLIC CODE NEAR LAB ?C?PLDXPTR
01000427H PUBLIC CODE NEAR LAB ?C?PSTXPTR
00000000H PUBLIC NUMBER --- ?C?XPAGE1RST
00000084H PUBLIC DATA BYTE ?C?XPAGE1SFR
000000E0H SFRSYM DATA BYTE ACC
000000F0H SFRSYM DATA BYTE B
00000083H SFRSYM DATA BYTE DPH
00000082H SFRSYM DATA BYTE DPL
0100039DH SYMBOL CODE NEAR LAB ??0000
010003B8H SYMBOL CODE NEAR LAB ??0001
010003CDH SYMBOL CODE NEAR LAB ??0002
010003F1H SYMBOL CODE NEAR LAB ??0003
0100040AH SYMBOL CODE NEAR LAB ??0004
01000435H SYMBOL CODE NEAR LAB ??0005
01000453H SYMBOL CODE NEAR LAB ??0006
01000485H SYMBOL CODE NEAR LAB ??0007
010003A4H SYMBOL CODE NEAR LAB CLDCODE
010003BBH SYMBOL CODE NEAR LAB CSTCODE
010003D8H SYMBOL CODE NEAR LAB ILDCODE
010003F8H SYMBOL CODE NEAR LAB ISTCODE
01000464H SYMBOL CODE NEAR LAB LLDCODE
01000492H SYMBOL CODE NEAR LAB LSTCODE
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 9
01000418H SYMBOL CODE NEAR LAB PLDCODE
01000441H SYMBOL CODE NEAR LAB PSTCODE

0100038FH BLOCK CODE NEAR LAB LVL=0
--- BLOCKEND --- --- LVL=0

--- MODULE --- --- ?C_STARTUP
01000000H PUBLIC CODE --- ?C_STARTUP

--- MODULE --- --- ?C?CLDPTR
01000496H PUBLIC CODE --- ?C?CLDPTR

--- MODULE --- --- ?C?CSTPTR
010004B4H PUBLIC CODE --- ?C?CSTPTR

--- MODULE --- --- PRINTF
0000000AH PUBLIC DATA --- ?_PRINTF517?BYTE
0000000AH PUBLIC DATA --- ?_PRINTF?BYTE
0000000AH PUBLIC DATA --- ?_SPRINTF517?BYTE
0000000AH PUBLIC DATA --- ?_SPRINTF?BYTE
01000070H PUBLIC CODE --- _PRINTF
01000070H PUBLIC CODE --- _PRINTF517
0100006AH PUBLIC CODE --- _SPRINTF
0100006AH PUBLIC CODE --- _SPRINTF517

--- MODULE --- --- ?C?PLDIIDATA
010004CBH PUBLIC CODE --- ?C?PLDIIDATA

--- MODULE --- --- ?C?CCASE
010004DBH PUBLIC CODE --- ?C?CCASE

--- MODULE --- --- PUTCHAR
0100059FH PUBLIC CODE --- _PUTCHAR

INTER-MODULE CROSS-REFERENCE LISTING
NAME . . . . . . . CLASS MODULE NAMES
========================================

?_PRINTF517?BYTE . DATA PRINTF
?_PRINTF?BYTE. . . DATA PRINTF MAIN
?_SPRINTF517?BYTE. DATA PRINTF
?_SPRINTF?BYTE . . DATA PRINTF
?C?CCASE . . . . . CODE ?C?CCASE PRINTF
?C?CLDPTR. . . . . CODE ?C?CLDPTR MAIN PRINTF
?C?CLDXPTR . . . . CODE ?C?XBANKING ?C?CLDPTR
?C?CODESEG . . . . NUMBER ** LX51 GENERATED **
?C?CSTPTR. . . . . CODE ?C?CSTPTR MAIN PRINTF
?C?CSTXPTR . . . . CODE ?C?XBANKING ?C?CSTPTR
?C?ILDXPTR . . . . CODE ?C?XBANKING
?C?ISTXPTR . . . . CODE ?C?XBANKING
?C?LLDXPTR . . . . CODE ?C?XBANKING
?C?LSTXPTR . . . . CODE ?C?XBANKING
?C?PLDIIDATA . . . CODE ?C?PLDIIDATA PRINTF
?C?PLDXPTR . . . . CODE ?C?XBANKING
?C?PSTXPTR . . . . CODE ?C?XBANKING
?C?XDATASEG. . . . NUMBER ** LX51 GENERATED **
?C?XPAGE1RST . . . NUMBER ?C?XBANKING MAIN
?C?XPAGE1SFR . . . DATA ?C?XBANKING MAIN
?C_START . . . . . CODE ** LX51 GENERATED ** ?C_STARTUP
?C_STARTUP . . . . CODE ?C_STARTUP MAIN
_PRINTF. . . . . . CODE PRINTF MAIN
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 10
_PRINTF517 . . . . CODE PRINTF
_PUTCHAR . . . . . CODE PUTCHAR PRINTF
_SPRINTF . . . . . CODE PRINTF
_SPRINTF517. . . . CODE PRINTF
AC . . . . . . . . DATA MAIN
ACC. . . . . . . . DATA MAIN
ADCCON1. . . . . . DATA MAIN
ADCCON2. . . . . . DATA MAIN
ADCCON3. . . . . . DATA MAIN
ADCDATAH . . . . . DATA MAIN
ADCDATAL . . . . . DATA MAIN
ADCGAINH . . . . . DATA MAIN
ADCGAINL . . . . . DATA MAIN
ADCI . . . . . . . DATA MAIN
ADCOFSH. . . . . . DATA MAIN
ADCOFSL. . . . . . DATA MAIN
B. . . . . . . . . DATA MAIN
CAP2 . . . . . . . DATA MAIN
CCONV. . . . . . . DATA MAIN
CNT2 . . . . . . . DATA MAIN
CPHA . . . . . . . DATA MAIN
CPOL . . . . . . . DATA MAIN
CS0. . . . . . . . DATA MAIN
CS1. . . . . . . . DATA MAIN
CS2. . . . . . . . DATA MAIN
CS3. . . . . . . . DATA MAIN
CY . . . . . . . . DATA MAIN
D0 . . . . . . . . DATA MAIN
D0EN . . . . . . . DATA MAIN
D1 . . . . . . . . DATA MAIN
D1EN . . . . . . . DATA MAIN
DAC0H. . . . . . . DATA MAIN
DAC0L. . . . . . . DATA MAIN
DAC1H. . . . . . . DATA MAIN
DAC1L. . . . . . . DATA MAIN
DACCON . . . . . . DATA MAIN
DCON . . . . . . . DATA MAIN
DMA. . . . . . . . DATA MAIN
DMAH . . . . . . . DATA MAIN
DMAL . . . . . . . DATA MAIN
DMAP . . . . . . . DATA MAIN
DPH. . . . . . . . DATA MAIN
DPL. . . . . . . . DATA MAIN
DPP. . . . . . . . DATA MAIN
EA . . . . . . . . DATA MAIN
EADC . . . . . . . DATA MAIN
EADRL. . . . . . . DATA MAIN
ECON . . . . . . . DATA MAIN
EDATA1 . . . . . . DATA MAIN
EDATA2 . . . . . . DATA MAIN
EDATA3 . . . . . . DATA MAIN
EDATA4 . . . . . . DATA MAIN
ES . . . . . . . . DATA MAIN
ET0. . . . . . . . DATA MAIN
ET1. . . . . . . . DATA MAIN
ET2. . . . . . . . DATA MAIN
ETIM1. . . . . . . DATA MAIN
ETIM2. . . . . . . DATA MAIN
ETIM3. . . . . . . DATA MAIN
EX0. . . . . . . . DATA MAIN
EX1. . . . . . . . DATA MAIN
EXEN2. . . . . . . DATA MAIN
EXF2 . . . . . . . DATA MAIN
F0 . . . . . . . . DATA MAIN
F1 . . . . . . . . DATA MAIN
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 11
I2CADD . . . . . . DATA MAIN
I2CCON . . . . . . DATA MAIN
I2CDAT . . . . . . DATA MAIN
I2CI . . . . . . . DATA MAIN
I2CM . . . . . . . DATA MAIN
I2CRS. . . . . . . DATA MAIN
I2CTX. . . . . . . DATA MAIN
IE . . . . . . . . DATA MAIN
IE0. . . . . . . . DATA MAIN
IE1. . . . . . . . DATA MAIN
IE2. . . . . . . . DATA MAIN
INT0 . . . . . . . DATA MAIN
INT1 . . . . . . . DATA MAIN
IP . . . . . . . . DATA MAIN
ISPI . . . . . . . DATA MAIN
IT0. . . . . . . . DATA MAIN
IT1. . . . . . . . DATA MAIN
large_array. . . . HDATA MAIN
main . . . . . . . CODE MAIN
MCO. . . . . . . . DATA MAIN
MDE. . . . . . . . DATA MAIN
MDI. . . . . . . . DATA MAIN
MDO. . . . . . . . DATA MAIN
OV . . . . . . . . DATA MAIN
P. . . . . . . . . DATA MAIN
P0 . . . . . . . . DATA MAIN
P1 . . . . . . . . DATA MAIN
P2 . . . . . . . . DATA MAIN
P3 . . . . . . . . DATA MAIN
PADC . . . . . . . DATA MAIN
PCON . . . . . . . DATA MAIN
PRE0 . . . . . . . DATA MAIN
PRE1 . . . . . . . DATA MAIN
PRE2 . . . . . . . DATA MAIN
PS . . . . . . . . DATA MAIN
PSI. . . . . . . . DATA MAIN
PSMCON . . . . . . DATA MAIN
PSW. . . . . . . . DATA MAIN
PT0. . . . . . . . DATA MAIN
PT1. . . . . . . . DATA MAIN
PT2. . . . . . . . DATA MAIN
PX0. . . . . . . . DATA MAIN
PX1. . . . . . . . DATA MAIN
RB8. . . . . . . . DATA MAIN
RCAP2H . . . . . . DATA MAIN
RCAP2L . . . . . . DATA MAIN
RCLK . . . . . . . DATA MAIN
RD . . . . . . . . DATA MAIN
REN. . . . . . . . DATA MAIN
RI . . . . . . . . DATA MAIN
RS0. . . . . . . . DATA MAIN
RS1. . . . . . . . DATA MAIN
RXD. . . . . . . . DATA MAIN
SBUF . . . . . . . DATA MAIN
SCON . . . . . . . DATA MAIN
SCONV. . . . . . . DATA MAIN
SM0. . . . . . . . DATA MAIN
SM1. . . . . . . . DATA MAIN
SM2. . . . . . . . DATA MAIN
SP . . . . . . . . DATA MAIN
SPE. . . . . . . . DATA MAIN
SPICON . . . . . . DATA MAIN
SPIDAT . . . . . . DATA MAIN
SPIM . . . . . . . DATA MAIN
SPR0 . . . . . . . DATA MAIN
LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 12
SPR1 . . . . . . . DATA MAIN
T0 . . . . . . . . DATA MAIN
T1 . . . . . . . . DATA MAIN
T2 . . . . . . . . DATA MAIN
T2CON. . . . . . . DATA MAIN
T2EX . . . . . . . DATA MAIN
TB8. . . . . . . . DATA MAIN
TCLK . . . . . . . DATA MAIN
TCON . . . . . . . DATA MAIN
TF0. . . . . . . . DATA MAIN
TF1. . . . . . . . DATA MAIN
TF2. . . . . . . . DATA MAIN
TH0. . . . . . . . DATA MAIN
TH1. . . . . . . . DATA MAIN
TH2. . . . . . . . DATA MAIN
TI . . . . . . . . DATA MAIN
timer0 . . . . . . CODE MAIN
timer_tick . . . . XDATA MAIN
TL0. . . . . . . . DATA MAIN
TL1. . . . . . . . DATA MAIN
TL2. . . . . . . . DATA MAIN
TMOD . . . . . . . DATA MAIN
TR0. . . . . . . . DATA MAIN
TR1. . . . . . . . DATA MAIN
TR2. . . . . . . . DATA MAIN
TXD. . . . . . . . DATA MAIN
WCOL . . . . . . . DATA MAIN
WDCON. . . . . . . DATA MAIN
WDE. . . . . . . . DATA MAIN
WDR1 . . . . . . . DATA MAIN
WDR2 . . . . . . . DATA MAIN
WDS. . . . . . . . DATA MAIN
WR . . . . . . . . DATA MAIN

Program Size: data=32.1 xdata=49153 const=0 code=1536
LX51 RUN COMPLETE. 0 WARNING(S), 0 ERROR(S)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 4 '07 #16

P: n/a
On Mon, 4 Jun 2007 11:47:50 +0100, in comp.lang.c , Chris Hills
<ch***@phaedsys.orgwrote:
>In article <f4**********@canopus.cc.umanitoba.ca>, Walter Roberson
<ro******@ibd.nrc-cnrc.gc.cawrites
>>In article <qs**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.ukwrote:
>>>In article <11**********************@j4g2000prf.googlegroups. com>, Ravi
<ra*********@gmail.comwrites
Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
>>>Try looking at the map file that is output by the compiler.

*What* map file output by the compiler? The compilers I use
(brand name compilers) don't output a map file; the toolsets
include tools to -generate- various forms of memory summaries,
but the compilers don't output memory maps.

All of the 30 odd I have do generate memory maps.
Still not certain to tell you where in memory different objects are.
The map will be a static picture of how stuff gets laid out, not a
dynamic picture of where it actuall is.
>>Even the advice to look at map files is system specific.

Not at all.
Of course it is - by definition it has to be system specific...
>Memory maps are generated on a very wide range of compilers
for many targets. Each memory map will be specific to the program in
question.
As you acknowledge here.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jun 4 '07 #17

P: n/a
On Mon, 4 Jun 2007 11:53:06 +0100, in comp.lang.c , Chris Hills
<ch***@phaedsys.orgwrote:
>
BASE START END USED MEMORY CLASS
================================================= =========
X:000000H X:020000H X:02FFFFH 00C000H HDATA
fascinating, but wildly offtopic, and highly specific to the
freestanding impementation you have to hand.

I also strongly suspect that this merely tells you where, relative to
some base, stuff might get laid out in a virtual map. Maps do not
generally tell you where it actually _is_ when you run the programme.

But you know that, this looks like hole-digging to me...

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jun 4 '07 #18

P: n/a
In article <in********************************@4ax.com>, Mark McIntyre
<ma**********@spamcop.netwrites
>On Mon, 4 Jun 2007 11:53:06 +0100, in comp.lang.c , Chris Hills
<ch***@phaedsys.orgwrote:
>>
BASE START END USED MEMORY CLASS
================================================ ==========
X:000000H X:020000H X:02FFFFH 00C000H HDATA

fascinating, but wildly offtopic, and highly specific to the
freestanding impementation you have to hand.
Yes This one is specific to the target in question However I could
have generated a similar file from any of the 30 compilers I have.

However as the majority of compilers are for free-standing targets it is
not off topic. BTW this compiler, as will most of the others I have
still generate an EXACT map file even when using an OS or RTOS or
scheduler.... So your premise is wrong anyway.

(Just see how many non x86 targets GCC has and therer are at least 5
other compiler vendors for any target compared to the number of current
PC compiler you can get..... You are making an assumption as to the
target of the OP. Most PC/Linux programmers do this.
>I also strongly suspect that this merely tells you where, relative to
some base, stuff might get laid out in a virtual map. Maps do not
generally tell you where it actually _is_ when you run the programme.
You are COMPLETELY WRONG the map above give EXACT memory locations that
is the point of a Map file. This is why I made the comment about the
data overlaying as some variables had the same address.
>But you know that, this looks like hole-digging to me...
You have dug your own hole The memory map given above give EXACT memory
locations. This is how you debug programs that are not dynamically
mapped which is, if not the majority a very sizeable minority.

You need to remember that for every x86 desktop system there are
probably 1000 embedded systems on something like 60 different MCU types
from 8-128 bit systems.

Map files are used with Ice and Logic analysers to debug.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 4 '07 #19

P: n/a
Chris Hills wrote:
[...] unless you are going to split hares
Do you have a score to settle with rabbits in general?

:-)
Jun 4 '07 #20

P: n/a
In article <46***********************@news.free.fr>, Spoon
<de*****@localhost.comwrites
>Chris Hills wrote:
>[...] unless you are going to split hares

Do you have a score to settle with rabbits in general?

:-)
Only if hungry.....
I used to have some ground with rabbits (also pheasant and partridge )
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 4 '07 #21

P: n/a
Chris Hills wrote:

Ignore the netpolice.

Don't listen to this idiot. If you ignore the group consensus on
topicality, you'll quickly be marginalized. That means even when you
have a topical question, you'll not get answers because the majority
will be ignoring you.

You will get the best answers in the correct newsgroup.

Brian
Jun 4 '07 #22

P: n/a
On Mon, 4 Jun 2007 14:38:30 +0100, in comp.lang.c , Chris Hills
<ch***@phaedsys.orgwrote:
>In article <in********************************@4ax.com>, Mark McIntyre
<ma**********@spamcop.netwrites
>>fascinating, but wildly offtopic, and highly specific to the
freestanding impementation you have to hand.

Yes This one is specific to the target in question However I could
have generated a similar file from any of the 30 compilers I have.

However as the majority of compilers are for free-standing targets it is
not off topic.
The majority of compilers emit textual error messages too. That
doesn't make specific text messages, or even the existence of text
mesages, topical. The standard is silent on how or indeed whether an
implementation must provide a textual error. It must merely emit one
diagnostic, which could equally be a beep, inverting video briefly, or
emitting a TCP packet.
>>I also strongly suspect that this merely tells you where, relative to
some base, stuff might get laid out in a virtual map. Maps do not
generally tell you where it actually _is_ when you run the programme.

You are COMPLETELY WRONG the map above give EXACT memory locations
Why is precisely why wittering on about offtopic stuff here is
irresponsible. I can't call you on that, whether its true or not,
because I'm no expert in your platform.

>>But you know that, this looks like hole-digging to me...

You have dug your own hole
Amusing.
>The memory map given above give EXACT memory
locations.
On one very specific platform, using one very specific memory layout,
and with one very specific addressing strategy. It is completely
nonportable, probably totally unlike any other memory map and quite
off topic.

But as I said, you knew all this already...
>Map files are used with Ice and Logic analysers to debug.
No sh.. sherlock?

I disagree by the way, map files are used to provide my GPS with
cutesy pictures to show me where the nearest kebab shop is.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jun 4 '07 #23

P: n/a
Chris Hills wrote:
In article <5c*************@mid.individual.net>, Martin Ambuhl
<ma*****@earthlink.netwrites
>Chris Hills wrote:
>>In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.orgwrites
Ravi <ra*********@gmail.comwrites:
Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?
It can't be done in portable standard C. Try asking in a newsgroup
that deals with your operating system.

It has nothing to do with the OS it sounds like he is looking for the
map file that the compiler will output.
That is, of course, absurd. The output of the compiler tells you *nothing*
about the memory addresses used by the program.


So would you care to explain the mythical output below?
He won't. He gets his kicks form being rude, not admitting he is wrong.

--
Ian Collins.
Jun 4 '07 #24

P: n/a
In article <ue********************************@4ax.com>, Mark McIntyre
<ma**********@spamcop.netwrites
>On Mon, 4 Jun 2007 14:38:30 +0100, in comp.lang.c , Chris Hills
<ch***@phaedsys.orgwrote:
>>In article <in********************************@4ax.com>, Mark McIntyre
<ma**********@spamcop.netwrites
>>>fascinating, but wildly offtopic, and highly specific to the
freestanding impementation you have to hand.

Yes This one is specific to the target in question However I could
have generated a similar file from any of the 30 compilers I have.

However as the majority of compilers are for free-standing targets it is
not off topic.
>>>I also strongly suspect that this merely tells you where, relative to
some base, stuff might get laid out in a virtual map. Maps do not
generally tell you where it actually _is_ when you run the programme.

You are COMPLETELY WRONG the map above give EXACT memory locations

Why is precisely why wittering on about offtopic stuff here is
irresponsible. I can't call you on that, whether its true or not,
because I'm no expert in your platform.
I was talking about the majority of platforms. It's not my problem that
you only have experience of a very few platforms or targets.
>>The memory map given above give EXACT memory
locations.

On one very specific platform, using one very specific memory layout,
and with one very specific addressing strategy. It is completely
nonportable, probably totally unlike any other memory map and quite
off topic.
As I said the file I showed was specific but is an example of the map
file the majority of compilers will do. The majority of compilers will
give exect memory locations.

Wintel is one of the few exceptions. where it doesn't work.

I could give examples for another 30+ compilers including x86
targets.... all of which will give a similar file all with exact memory
locations that is the whole point of a map file.
>But as I said, you knew all this already...
I know your experience is so limited as to be pointless in this
discussion

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 4 '07 #25

P: n/a
In article <5c*************@mid.individual.net>, Default User
<de***********@yahoo.comwrites
>Chris Hills wrote:

>Ignore the netpolice.


Don't listen to this idiot. If you ignore the group consensus on
topicality, you'll quickly be marginalized.
Which is why you see so many posts shouting OT.

Last time this discussion came up there were as many on one side as the
other and that has the case for the decade or so I have been no here.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 4 '07 #26

P: n/a
In article <t0**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.ukwrote:
>I was talking about the majority of platforms. It's not my problem that
you only have experience of a very few platforms or targets.
No, you said "It has nothing to do with the OS." If you had said, "It
has little to do with the OS" you might have been right (perhaps,
allowed for the sake of argument), but you made an absolute statement
implying that *every* OS and compiler produces a memory map suitable
for the OP's muddy purposes. As your "nothing to do with the OS"
statement was in reply to a statement that the matter is OS specific,
your reply was an incorrect attempted refutation of the redirection.

If your reply had been to -add- the information that "On many
systems, the compiler produces a memory map file that may be
sufficient for the OP's needs", then there wouldn't be an issue.
--
Programming is what happens while you're busy making other plans.
Jun 4 '07 #27

P: n/a
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article <t0**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.ukwrote:
>>I was talking about the majority of platforms. It's not my problem that
you only have experience of a very few platforms or targets.

No, you said "It has nothing to do with the OS." If you had said, "It
has little to do with the OS" you might have been right (perhaps,
allowed for the sake of argument), but you made an absolute statement
implying that *every* OS and compiler produces a memory map suitable
for the OP's muddy purposes. As your "nothing to do with the OS"
statement was in reply to a statement that the matter is OS specific,
your reply was an incorrect attempted refutation of the redirection.
[...]

And regardless of how much it has to do with the OS, it has very
little to do with the C programming language. On the one system I've
bothered to check, a memory map file is generated by the linker, not
by the compiler. My guess is that that's true in general. A linker
deals with object files, not with source files; it may not even be
aware of what language the original sources were written it.

So neither the question nor Chris Hills's answer to it had anything to
do with the C programming language. Perhaps comp.compilers or
comp.programming would have been a better place to redirect the
original query, rather than an OS-specific newsgroup, but it seems
clear that comp.lang.c isn't the right place for it, even if somebody
here happens to know the answer.

<OT>
The particular OS-specific solution I was thinking of was the
/proc/<PID>/maps pseudo-file available under Linux.
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 4 '07 #28

P: n/a
Chris Hills wrote:
In article <5c*************@mid.individual.net>, Default User
<de***********@yahoo.comwrites
Chris Hills wrote:

Ignore the netpolice.

Don't listen to this idiot. If you ignore the group consensus on
topicality, you'll quickly be marginalized.

Which is why you see so many posts shouting OT.

Last time this discussion came up there were as many on one side as
the other and that has the case for the decade or so I have been no
here.

I don't believe you. Every time this discussion comes up, there a few
people on the side of expansion, but very few. The overwhelming
majority, especially when weighted by typical contribution rate, favors
keeping the basic topicality that the group has employed for many years
now.


Brian
Jun 4 '07 #29

P: n/a
"Default User" <de***********@yahoo.comwrites:
Chris Hills wrote:
>In article <5c*************@mid.individual.net>, Default User
<de***********@yahoo.comwrites
Chris Hills wrote:
Ignore the netpolice.
Don't listen to this idiot. If you ignore the group consensus on
topicality, you'll quickly be marginalized.

Which is why you see so many posts shouting OT.

Last time this discussion came up there were as many on one side as
the other and that has the case for the decade or so I have been no
here.

I don't believe you. Every time this discussion comes up, there a few
people on the side of expansion, but very few. The overwhelming
majority, especially when weighted by typical contribution rate, favors
keeping the basic topicality that the group has employed for many years
now.
And, to the best of my recollection, nobody has ever come up with a
coherent proposal for a new and more expansive set of topicality
guidelines, though I've asked for such proposals several times.

The set of guidelines encouraged by the so-called "netpolice" are the
*only* set of guidelines on which there's any kind of consensus
(unless you count the consensus of the trolls and spammers that
absolutely anything goes). If you don't like that situation, Chris,
then do something to change it. Tell us what guidelines you'd like to
see. It's not inconceivable that we might agree with you.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 4 '07 #30

P: n/a
On Mon, 4 Jun 2007 21:08:55 +0100, in comp.lang.c , Chris Hills
<ch***@phaedsys.orgwrote:
>In article <ue********************************@4ax.com>, Mark McIntyre
<ma**********@spamcop.netwrites
>>Why is precisely why wittering on about offtopic stuff here is
irresponsible. I can't call you on that, whether its true or not,
because I'm no expert in your platform.

I was talking about the majority of platforms. It's not my problem that
you only have experience of a very few platforms or targets.
Ah, I see - insults. Very good.
>As I said the file I showed was specific
Good that we agree about something.
>but is an example of the map
file the majority of compilers will do. The majority of compilers will
give exect memory locations.
Well, now, I don't claim to be the complete expert of this offtopic
field that you claim to be but putting it shortly: utter bollocks. You
can run the same app twice and it'll get loaded at a different address
each time, depending on other stuff in memory.....
Wintel is one of the few exceptions. where it doesn't work.
..... even on non-wintel platforms.
>I could give examples for another 30+ compilers including x86
targets.... all of which will give a similar file all with exact memory
locations that is the whole point of a map file.
So what? Its still offtopic.
>>But as I said, you knew all this already...

I know your experience is so limited as to be pointless in this
discussion
Ah, more insults, argument over then.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jun 4 '07 #31

P: n/a
On Mon, 4 Jun 2007 21:11:02 +0100, in comp.lang.c , Chris Hills
<ch***@phaedsys.orgwrote:
>Last time this discussion came up there were as many on one side as the
other and that has the case for the decade or so I have been no here.
Not only does that last sentence not parse, but it also makes no sense
even if you fill in the gaps. However its not a problem, because
you're in the bitbucket.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jun 4 '07 #32

P: n/a
Keith Thompson wrote:
>
.... snip ...
>
And regardless of how much it has to do with the OS, it has very
little to do with the C programming language. On the one system I've
bothered to check, a memory map file is generated by the linker, not
by the compiler. My guess is that that's true in general. A linker
deals with object files, not with source files; it may not even be
aware of what language the original sources were written it.
Linkage is part of the C std. From N869, 5.1.1.2:

8. All external object and function references are
resolved. Library components are linked to satisfy
external references to functions and objects not
defined in the current translation. All such
translator output is collected into a program image
which contains information needed for execution in its

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 6 '07 #33

P: n/a
Chris Hills wrote:
>
.... snip ...
>
So would you care to explain the mythical output below? It seems
to have memory addresses for the program and the data. All the
compilers I use will do this. (Compilers to mean compiler-linker
combination of course unless you are going to split hares)

LX51 LINKER/LOCATER V4.09 06/04/2007 11:36:05 PAGE 1
It won't run on my system and thus is OT. Incidentally, split
hares are probably dead hares. You may have been thinking of
hairs. :-)

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 6 '07 #34

P: n/a
Chris Hills wrote:
Keith Thompson <ks***@mib.orgwrites
>Ravi <ra*********@gmail.comwrites:
>>Can you all please suggest a program which tell us the range of
memry addresses occupied by the given c program?

It can't be done in portable standard C. Try asking in a
newsgroup that deals with your operating system.

It has nothing to do with the OS it sounds like he is looking for
the map file that the compiler will output.
And the actual compiler is system specific and OT here. Ravi
should go to a group that deals with his system, and describe that
system sufficiently.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 6 '07 #35

P: n/a
Chris Hills wrote:
>
.... snip ...
>
However as the majority of compilers are for free-standing targets
it is not off topic. BTW this compiler, as will most of the
others I have still generate an EXACT map file even when using an
OS or RTOS or scheduler.... So your premise is wrong anyway.
To the contrary, it means that ALL those specifics are off-topic.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 6 '07 #36

P: n/a
Chris Hills wrote:
Martin Ambuhl <ma*****@earthlink.netwrites
.... snip ...
>
>More important is to ignore Chris Hills, who obviously knows nothing.

Clearly one of use knows less than he thinks.
Not necessarily. But one of you has decided to annoy everybody by
including a ridiculous off-topic file (for the newsgroup theme) in
each message. Very childish.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 6 '07 #37

P: n/a
Keith Thompson wrote:
"Default User" <de***********@yahoo.comwrites:
>Chris Hills wrote:
.... snip ...
>>
>>Last time this discussion came up there were as many on one side
as the other and that has the case for the decade or so I have
been no here.

I don't believe you. Every time this discussion comes up, there
a few people on the side of expansion, but very few. The
overwhelming majority, especially when weighted by typical
contribution rate, favors keeping the basic topicality that the
group has employed for many years now.

And, to the best of my recollection, nobody has ever come up with
a coherent proposal for a new and more expansive set of topicality
guidelines, though I've asked for such proposals several times.

The set of guidelines encouraged by the so-called "netpolice" are
the *only* set of guidelines on which there's any kind of consensus
(unless you count the consensus of the trolls and spammers that
absolutely anything goes). If you don't like that situation, Chris,
then do something to change it. Tell us what guidelines you'd like
to see. It's not inconceivable that we might agree with you.
Hills also spouts this nonsense (about c.l.c) on other groups.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com

Jun 6 '07 #38

P: n/a
Chris Hills wrote:
Ravi <ra*********@gmail.comwrites
>Can you all please suggest a program which tell us the range of
memry addresses occupied by the given c program?

Try looking at the map file that is output by the compiler.

Ignore the netpolice.
Bad advice. Go to a newsgroup that handles your system.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 6 '07 #39

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>>
... snip ...
>>
And regardless of how much it has to do with the OS, it has very
little to do with the C programming language. On the one system I've
bothered to check, a memory map file is generated by the linker, not
by the compiler. My guess is that that's true in general. A linker
deals with object files, not with source files; it may not even be
aware of what language the original sources were written it.

Linkage is part of the C std. From N869, 5.1.1.2:

8. All external object and function references are
resolved. Library components are linked to satisfy
external references to functions and objects not
defined in the current translation. All such
translator output is collected into a program image
which contains information needed for execution in its
Yes, but memory map files, and the operation of any particular linker,
are not.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 6 '07 #40

This discussion thread is closed

Replies have been disabled for this discussion.