C Programming Language :: Show all memory occupied by the program


	Show all memory occupied by the program Can you all please suggest a program which tell us the range of memry addresses occupied by the given c program? Ravi <ra.ravi.@gmail.com> writes: > 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) k@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" In article <1180855032.631821.327@j4g2000prf.googlegroups.com>, Ravi <ra.ravi.@gmail.com> wrote: >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/cgi-bin/getdoc.cgi?coll=0650&db=m... 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 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 In article <1180855032.631821.327@j4g2000prf.googlegroups.com>, Ravi <ra.ravi.@gmail.com> writes >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 /\/\/\/\/ /\/\/ c@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ In article <lnhcppxydd.@nuthaus.mib.org>, Keith Thompson <k@mib.org> writes >Ravi <ra.ravi.@gmail.com> writes: >> 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 /\/\/\/\/ /\/\/ c@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ In article <qsnQXYBls7YGF@phaedsys.demon.co.uk>, Chris Hills <c@phaedsys.demon.co.uk> wrote: >In article <1180855032.631821.327@j4g2000prf.googlegroups.com>, Ravi ><ra.ravi.@gmail.com> writes >>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 Chris Hills wrote: > In article <lnhcppxydd.@nuthaus.mib.org>, Keith Thompson > <k@mib.org> writes >> Ravi <ra.ravi.@gmail.com> writes: >>> 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. Chris Hills wrote: > In article <1180855032.631821.327@j4g2000prf.googlegroups.com>, Ravi > <ra.ravi.@gmail.com> writes >> 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. In article <jswSn5B5t7YGF@phaedsys.demon.co.uk>, Chris Hills <c@phaedsys.demon.co.uk> wrote: >In article <lnhcppxydd.@nuthaus.mib.org>, Keith Thompson ><k@mib.org> writes >>Ravi <ra.ravi.@gmail.com> writes: >>> 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 Chris Hills <c@phaedsys.org> writes: > In article <1180855032.631821.327@j4g2000prf.googlegroups.com>, > Ravi <ra.ravi.@gmail.com> writes >>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) k@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" In article <f40gtd$9h@canopus.cc.umanitoba.ca>, Walter Roberson <rober@ibd.nrc-cnrc.gc.ca> writes >In article <qsnQXYBls7YGF@phaedsys.demon.co.uk>, >Chris Hills <c@phaedsys.demon.co.uk> wrote: >>In article <1180855032.631821.327@j4g2000prf.googlegroups.com>, Ravi >><ra.ravi.@gmail.com> writes >>>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 /\/\/\/\/ /\/\/ c@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ In article <f40i4t$bc@canopus.cc.umanitoba.ca>, Walter Roberson <rober@ibd.nrc-cnrc.gc.ca> writes - Hide quoted text - >In article <jswSn5B5t7YGF@phaedsys.demon.co.uk>, >Chris Hills <c@phaedsys.demon.co.uk> wrote: >>In article <lnhcppxydd.@nuthaus.mib.org>, Keith Thompson >><k@mib.org> writes >>>Ravi <ra.ravi.@gmail.com> writes: >>>> 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 /\/\/\/\/ /\/\/ c@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ In article <5chv8nF317d8@mid.individual.net>, Martin Ambuhl <mamb@earthlink.net> writes >Chris Hills wrote: >> In article <lnhcppxydd.@nuthaus.mib.org>, Keith Thompson <kst- >>u@mib.org> writes >>> Ravi <ra.ravi.@gmail.com> writes: >>>> 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 ... read more » In article <5chv9tF317d8@mid.individual.net>, Martin Ambuhl <mamb@earthlink.net> writes >Chris Hills wrote: >> In article <1180855032.631821.327@j4g2000prf.googlegroups.com>, >>Ravi <ra.ravi.@gmail.com> writes >>> 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 /\/\/\/\/ /\/\/ c@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ In article <5chv9tF317d8@mid.individual.net>, Martin Ambuhl <mamb@earthlink.net> writes >Chris Hills wrote: >> In article <1180855032.631821.327@j4g2000prf.googlegroups.com >>>, Ravi <ra.ravi.@gmail.com> writes >>> 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 ... read more » On Mon, 4 Jun 2007 11:47:50 +0100, in comp.lang.c , Chris Hills - Hide quoted text - <c@phaedsys.org> wrote: >In article <f40gtd$9h@canopus.cc.umanitoba.ca>, Walter Roberson ><rober@ibd.nrc-cnrc.gc.ca> writes >>In article <qsnQXYBls7YGF@phaedsys.demon.co.uk>, >>Chris Hills <c@phaedsys.demon.co.uk> wrote: >>>In article <1180855032.631821.327@j4g2000prf.googlegroups.com>, Ravi >>><ra.ravi.@gmail.com> writes >>>>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 On Mon, 4 Jun 2007 11:53:06 +0100, in comp.lang.c , Chris Hills <c@phaedsys.org> wrote: >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 In article <in28639gddeaovkrhqh1oqr2155cb2n@4ax.com>, Mark McIntyre <markmcint@spamcop.net> writes >On Mon, 4 Jun 2007 11:53:06 +0100, in comp.lang.c , Chris Hills ><c@phaedsys.org> wrote: >>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 /\/\/\/\/ /\/\/ c@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Chris Hills wrote: > [...] unless you are going to split hares Do you have a score to settle with rabbits in general? :-) In article <46642e0c$0$29101$426a7@news.free.fr>, Spoon <devn@localhost.com> writes >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 /\/\/\/\/ /\/\/ c@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ 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 On Mon, 4 Jun 2007 14:38:30 +0100, in comp.lang.c , Chris Hills <c@phaedsys.org> wrote: >In article <in28639gddeaovkrhqh1oqr2155cb2n@4ax.com>, Mark McIntyre ><markmcint@spamcop.net> writes >>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 - Hide quoted text - Chris Hills wrote: > In article <5chv8nF317d8@mid.individual.net>, Martin Ambuhl > <mamb@earthlink.net> writes >> Chris Hills wrote: >>> In article <lnhcppxydd.@nuthaus.mib.org>, Keith Thompson <kst- >>> u@mib.org> writes >>>> Ravi <ra.ravi.@gmail.com> writes: >>>>> 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. In article <ueq8635oomui6uqov0mhc5nt2228msg@4ax.com>, Mark McIntyre <markmcint@spamcop.net> writes - Hide quoted text - >On Mon, 4 Jun 2007 14:38:30 +0100, in comp.lang.c , Chris Hills ><c@phaedsys.org> wrote: >>In article <in28639gddeaovkrhqh1oqr2155cb2n@4ax.com>, Mark McIntyre >><markmcint@spamcop.net> writes >>>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 /\/\/\/\/ /\/\/ c@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/