From: <pa...@pj...> - 2001-12-14 12:45:44
|
Before I throw in my 2-cents, I think it'd be good to mention an excellent little blurb at Abiword that was mentioned on slashdot recently, regarding support expectations for free software. http://www.abisource.com/support/expectations.phtml With that out of the way, you should also know that I'm mostly a circuits and assembly guy who dreams of someday making a grand contribution to SDCC's code, but for the forseeable future my involvement is pretty much bug reporting and peephole rules. So my opinions don't count much compared to Sandeep, Johan, and others... but I do have many years of mcs51 experience and I think I can comment a bit about what you're trying to do and how I feel it "should" be handled. >.... SDCC assumes that any >data values that are not constant and therefore held in CODE have to be >copied from CODE to XDATA at startup time in some way; .... From your other earlier posts, it looks like your project has some large data structures stored in an EPROM or some other non-volatile memory, and you've connected the NV chip that has this data to RD instead of PSEN so that it doesn't burn up the 64k of code space, which you presumably want to fill with code that won't need much (or any) external RAM. The first fundamental problem is that standard intel-hex format provides a single 64k memory space. There are a couple record types (02, 04) which allow 20 or 32 bit address spaces. To the best of my knowledge, there is no commonly accepted extension to intel-hex to define multiple memory spaces. In the world of Microchip PIC, I've seen extensions where a certain memory region was intended to represent data to be loaded into the chips EEPROM. For mcs51, you'd probably want to produce two hex files, one for code memory initialization and the other for xdata memory. Now the current mcs51 xdata initialization, using hardcoded MOVX instructions (aka genAssign) is highly inefficient for initialization of anything more than about a dozen bytes. The approach taken by Hi-Tech C (which I think is the "right way") involves defining special code memory segments to the linker for initialized data and adding runtime startup code in the library which copies these segments from code memory to data, xdata, idata. The library code uses special symbols available from the linker to directly embed the source (in code) and distination addresses and the length, which makes this code very fast and compact when written in assembly. Even for fairly small numbers of initialized variables, the code size added by these startup routines is less than the space taken by using MOV/MOVX (genAssign). So, if anyone has actually read this far, please at least comment yeah or nay as to wether you think this approach is the right thing to do. There is of course the separate issue of someone actually doing it.... but first, does this approach sound like the right thing to do?? I recall Johan did something a while back, but isn't it only in the ds390 port?? Now, back to Russel's application. If SDCC were to take this approach, then at least the compiler portion of SDCC would be able to emit .rel files that meet your needs (or at least what I understand as I described above). You would still need to have support in the linker, where you could direct the linker to emit those special segments as a separate file, or at some special offset that matches how your toolset will program the chips or otherwise load the data. I seriously doubt that anyone will write special code into the linker for this particular application, partly because it's special, partly because nobody seems to work on the linker much, and partly because the code in the linker is not much fun to work on. >1. Does anyone have any experience of using SDCC with ROM/OTP/EEPROM in >XDATA? I do, but I believe it's quite different from your application. In my case, I connected the RAM to the PSEN pin instead of RD, so that code could be downloaded and exectuted. I've recently redesigned the board to use an AND gate to use either PSEN or RD (which appears to be the most common approach). I originally hacked up gen.c, with a lot of conditional if/else's around every place that emitted a MOVX. This worked, but it was a mess and I'm glad it didn't find its way into CVS. I later changed the approach to use two peephole rules and a substitute version of _gptrget in the library, but there is still some patching to add a command line option and make the peepholes conditional depending on this option being set. It's still something of a hack, so I've been maintaining a little fork of the code with this extra command line option. Someday I'd like to put it into the official SDCC, but it's been a low priority so I haven't brought it up again (until now, hint hint :) >2. Are people actually interested in these issues at all? I am. Anyone who's read this entire message probably is also. Paul |
From: <pa...@pj...> - 2001-12-14 23:01:50
|
>I think this is the right approach, and yes, it's there. Only for the mcs51 >port when you set envvar $TRY_THE_NEW_INITIALIZER. But since no one >commented when I implemented this, I didn't really finish it. Now that we >also have a _builtin memcpy() this could be made the default. I'm sorry, I should have tried it immediately when you announced it. I tried it now, and I have some a few comments. First, here is the test code I tried: xdata long long_in_xdata=0x1234567; xdata char string_in_xdata[20]="This is a test\r\n"; void test(void) { long_in_xdata++; string_in_xdata[2]++; } In my dream world, this would consume 24 bytes (assuming that the string is padded with zeros), plus the code for the "test" function. Without TRY_THE_NEW_INITIALIZER, here is SDCC's default: ;-------------------------------------------------------- ; external ram data ;-------------------------------------------------------- .area XSEG (XDATA) _long_in_xdata:: .ds 4 _string_in_xdata:: .ds 20 ;-------------------------------------------------------- ; global & static initialisations ;-------------------------------------------------------- .area GSINIT (CODE) .area GSFINAL (CODE) .area GSINIT (CODE) ; test.c 2 ; genAssign mov dptr,#_long_in_xdata mov a,#0x67 movx @dptr,a inc dptr mov a,#0x45 movx @dptr,a inc dptr mov a,#0x23 movx @dptr,a inc dptr mov a,#0x01 movx @dptr,a ; test.c 10 ; genPointerSet ; genFarPointerSet mov dptr,#_string_in_xdata mov a,#0x54 movx @dptr,a ; genPointerSet ; genFarPointerSet mov dptr,#(_string_in_xdata + 0x0001) mov a,#0x68 movx @dptr,a ; genPointerSet ; genFarPointerSet mov dptr,#(_string_in_xdata + 0x0002) mov a,#0x69 movx @dptr,a [snip: 71 more lines of the same] The default initialization uses 119 bytes of code to initialize these two xdata variables with only 24 bytes of data. Ouch. Here's what I got with TRY_THE_NEW_INITIALIZER: ;-------------------------------------------------------- ; external ram data ;-------------------------------------------------------- .area XSEG (XDATA) _long_in_xdata:: .ds 4 _string_in_xdata:: .ds 20 ;-------------------------------------------------------- ; global & static initialisations ;-------------------------------------------------------- .area GSINIT (CODE) .area GSFINAL (CODE) .area GSINIT (CODE) ; test.c 2 ; genAssign mov dptr,#_long_in_xdata mov a,#0x67 movx @dptr,a inc dptr mov a,#0x45 movx @dptr,a inc dptr mov a,#0x23 movx @dptr,a inc dptr mov a,#0x01 movx @dptr,a ; test.c 10 ; gen51AggregateAssign ; initialize string_in_xdata mov dptr,#_memcpy_PARM_2 mov a,#_string_in_xdata_init__ movx @dptr,a inc dptr mov a,#(_string_in_xdata_init__>>8) movx @dptr,a inc dptr mov a,#02; only from cseg for now movx @dptr,a mov dptr,#_memcpy_PARM_3 mov a,#(20>>0); number of bytes movx @dptr,a inc dptr mov a,#(20>>8) movx @dptr,a mov dptr,#_string_in_xdata mov b,#01; only to xseg for now lcall _memcpy [snip, application code] .area CSEG (CODE) _string_in_xdata_init__: .ascii "This is a test" .db 0x0D .db 0x0A .db 0x00 .db 0x00 .db 0x00 .db 0x00 I added this up to a total of 75 bytes consumed in code space, which is a big improvement over the default of 119, but I think there's a great opportunity to do much better. The builtin memcpy would help, but I'm envisioning a different approach (well, in truth I didn't think this up at all, it's what Hi-Tech C does and I used the XA version of their compiler a couple years ago). Here's roughly what I had in mind: ;-------------------------------------------------------- ; external ram data ;-------------------------------------------------------- .area XSEG (XDATA) _long_in_xdata:: .ds 4 _string_in_xdata:: .ds 20 ;-------------------------------------------------------- ; global & static initialisations ;-------------------------------------------------------- .area XINIT_SEG (CODE) .byte #0x67,#0x45,#0x23,#0x01 ;_long_in_xdata .ascii "This is a test" ;_string_in_xdata .db 0x0D .db 0x0A .db 0x00 .db 0x00 .db 0x00 .db 0x00 This isn't the whole story, but within the .rel file, the number of bytes it consumes exactly 24 bytes to initialize the 24 bytes of xdata variables. Of course, I just made up "XINIT_SEG". The idea is that the linker would locate this segment somewhere in code space, and it would define the usual special symbols that it creates for every segment. The C library startup code would include one highly optimized memcpy which transfers all of XINIT_SEG (composed of possibly many .rel files' initialization data). Here's roughly what it'd look like: mov dptr, #s_XINIT_SEG mov r0, #s_XSEG mov p2, #(s_XSEG >> 8) 00001$: clr a movc @a+dptr movx @r0, a inc dptr inc r0 cjne r0, #0, 00002$ inc p2 00002$: mov a, dpl cjne a, #(s_XINIT_SEG + l_XINIT_SEG), 00001$ mov a, dph cjne a, #((s_XINIT_SEG + l_XINIT_SEG) >> 8), 00001$ mov p2, #0xFF ret The key point about this startup code is that it copies all of the xdata initialized bytes from all the .rel files, so the overhead of code to do a memcpy is spent only once. The other important point is that it does not require any input parameters. All the info it needs is hard coded, and the linker's special symbols provide the code source, xdata destination and length at link time. I quickly added up the bytes, and I believe this little routine is 31 bytes of mcs51 opcodes, so it's a net win over the current TRY_THE_NEW_INITIALIZER, even for the simple case of a single .rel file that initializes only those two variables. As you add more variables and .rel files, the savings only get better and rapidly approach 1 byte in code for each byte in initialized xdata. No matter how many xdata variables you have, the overhead to init them is always only 31 bytes! There are numerous advantages to using this approach for folks who want to do something special, like Russel (and me). Because the compiler would just emit the initialization into special code segments, a modified linker could put them somewhere special in Russel's memory map, and presumably the Russel would replace the runtime startup code with something that integrates with his special memory manager. There's also the very interesting opportunity to try some sort of compression scheme on that data (a heavily modified linker) and include runtime startup routines with the decompression code. Well, that's enough wishful thinking for one day. I would really like to see this sort of xdata initialization, so if you want to do it, let me know how I could help out. I get the impression that nobody really does much with the linker, so maybe I could help there if needed?? Thanks, Paul |
From: Johan K. <joh...@id...> - 2001-12-16 12:56:27
|
Basically what I did: - Removed the "TRY_THE_NEW_INITIALIZER" approach. - Added a new area "XISEG (REL,CON,XDATA)" where initialized data will be allocated - Added a new area "XINIT (REL,CON,CODE)" where a copy of the initialized data will be stored Ofcourse these areas are added to the port structure together with a "void (*genXINIT) (FILE *)". If that one is !NULL the above segments will be used and once at startup genXINIT() will copy XINIT to XISEG for all initialized data. I added this for the mcs51 port (others are set to NULL) and used Paul's optimized memcpy (with a small modification because the assembler can't do " cjne a,#(s_XINIT+l_XINIT),00001$"). I can think of some command line switches to either prevent all that or emit XINIT in a seperate file instead of in the code segment. The framework is there. All that is needed for other ports: - Write a smallest most efficient genXINIT() in e.g. port/main.c (look at mcs51/main.c for an example) - Think of a reasonable name for XISEG and XINIT - Insert these three in the port structure and you should be all set Please note that the static segment should be CSEG now, not GSINIT (which was always ignored) or probably nothing will work anymore. Please comment. Johan |
From: Johan K. <joh...@id...> - 2001-12-16 16:17:17
|
> Please note that the static segment should be CSEG now, not GSINIT (which > was always ignored) or probably nothing will work anymore. Forget about that. There is still something weird with CSEG GSINIT and GSFINAL. I am working on it. Now it seems at least stable. Johan |
From: Bernhard H. <ber...@be...> - 2001-12-17 16:14:10
|
My first test failed: xdata char str[257] = "You and me"; ;-------------------------------------------------------- ; external ram data ;-------------------------------------------------------- .area XSEG (XDATA) G$str$0$0;-------------------------------------------------------- ; external initialized ram data ;-------------------------------------------------------- .area XISEG (XDATA) G$str$0$0==. _str:: .ds 257 ?ASxxxx-Error-<o> in line 40 of test.asm <o> .org in REL area or directive / mnemonic error Bernhard |
From: Johan K. <joh...@id...> - 2001-12-17 16:22:01
|
It's ok without the --debug. Haven't though about that. Someone with debug experience? Johan ----- Original Message ----- From: Bernhard Held <ber...@be...> To: Johan Knol <joh...@id...>; <sdc...@li...> Sent: Monday, December 17, 2001 5:08 PM Subject: Re: [sdcc-devel] comitted: extra segments for initialized data > My first test failed: > > > xdata char str[257] = "You and me"; > > > ;-------------------------------------------------------- > ; external ram data > ;-------------------------------------------------------- > .area XSEG (XDATA) > G$str$0$0;-------------------------------------------------------- > ; external initialized ram data > ;-------------------------------------------------------- > .area XISEG (XDATA) > G$str$0$0==. > _str:: > .ds 257 > > > ?ASxxxx-Error-<o> in line 40 of test.asm > <o> .org in REL area or directive / mnemonic error > > Bernhard > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Johan K. <joh...@id...> - 2001-12-17 17:43:50
|
Fixed, still puzled with the duplicate ".global _str". Johan ----- Original Message ----- From: Johan Knol <joh...@id...> To: Bernhard Held <ber...@be...>; <sdc...@li...> Sent: Monday, December 17, 2001 5:21 PM Subject: Re: [sdcc-devel] comitted: extra segments for initialized data > It's ok without the --debug. Haven't though about that. Someone with debug > experience? > > Johan > > ----- Original Message ----- > From: Bernhard Held <ber...@be...> > To: Johan Knol <joh...@id...>; <sdc...@li...> > Sent: Monday, December 17, 2001 5:08 PM > Subject: Re: [sdcc-devel] comitted: extra segments for initialized data > > > > My first test failed: > > > > > > xdata char str[257] = "You and me"; > > > > > > ;-------------------------------------------------------- > > ; external ram data > > ;-------------------------------------------------------- > > .area XSEG (XDATA) > > G$str$0$0;-------------------------------------------------------- > > ; external initialized ram data > > ;-------------------------------------------------------- > > .area XISEG (XDATA) > > G$str$0$0==. > > _str:: > > .ds 257 > > > > > > ?ASxxxx-Error-<o> in line 40 of test.asm > > <o> .org in REL area or directive / mnemonic error > > > > Bernhard > > > > > > _______________________________________________ > > sdcc-devel mailing list > > sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Bernhard H. <ber...@be...> - 2001-12-16 18:50:53
|
The code failed, when l_XINIT is 0. I committed a small fix. Bernhard |
From: Johan K. <joh...@id...> - 2001-12-16 19:03:53
|
Thanks, can you do that for the ds390 port too? I noticed that the mcs51 regression tests took more that 35min now. Any idea? Hey, that could be it! Johan ----- Original Message ----- From: Bernhard Held <ber...@be...> To: Johan Knol <joh...@id...>; <sdc...@li...> Sent: Sunday, December 16, 2001 7:52 PM Subject: Re: [sdcc-devel] comitted: extra segments for initialized data > The code failed, when l_XINIT is 0. I committed a small fix. > > Bernhard > > > |
From: Bernhard H. <ber...@be...> - 2001-12-16 19:21:10
|
> Thanks, can you do that for the ds390 port too? Done. > I noticed that the mcs51 regression tests took more that 35min now. Any > idea? Hey, that could be it! The mcs51 regression tests are up and running again. But I still don't know what's the problem with the ds390. Bernhard |
From: Johan K. <joh...@id...> - 2001-12-16 19:29:57
|
I know, and Sandeep knows. He knows how to fix it, I dont. Right now I think the mcs51 regression tests are only done smal-model. There is at least one ( ;-) problem I know of that only shows in large-model. Could we do that too? Johan ----- Original Message ----- From: Bernhard Held <ber...@be...> To: Johan Knol <joh...@id...>; <sdc...@li...> Sent: Sunday, December 16, 2001 8:11 PM Subject: Re: [sdcc-devel] comitted: extra segments for initialized data > > Thanks, can you do that for the ds390 port too? > Done. > > > I noticed that the mcs51 regression tests took more that 35min now. Any > > idea? Hey, that could be it! > The mcs51 regression tests are up and running again. But I still don't know > what's the problem with the ds390. > > Bernhard > > > |
From: Sandeep D. <sa...@wi...> - 2001-12-16 19:39:43
|
Yes I do know the fix.. just haven't had time to sit at the machine today.. should get some time 2nite.. Sandeep > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On Behalf Of Johan Knol > Sent: Sunday, December 16, 2001 11:30 AM > To: Bernhard Held; sdc...@li... > Subject: Re: [sdcc-devel] comitted: extra segments for > initialized data > > > I know, and Sandeep knows. He knows how to fix it, I dont. > > Right now I think the mcs51 regression tests are only done > smal-model. There > is at least one ( ;-) problem I know of that only shows in > large-model. > Could we do that too? > > Johan > > ----- Original Message ----- > From: Bernhard Held <ber...@be...> > To: Johan Knol <joh...@id...>; > <sdc...@li...> > Sent: Sunday, December 16, 2001 8:11 PM > Subject: Re: [sdcc-devel] comitted: extra segments for > initialized data > > > > > Thanks, can you do that for the ds390 port too? > > Done. > > > > > I noticed that the mcs51 regression tests took more that > 35min now. Any > > > idea? Hey, that could be it! > > The mcs51 regression tests are up and running again. But I > still don't > know > > what's the problem with the ds390. > > > > Bernhard > > > > > > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > |
From: Bernhard H. <ber...@be...> - 2001-12-17 07:29:27
|
> Right now I think the mcs51 regression tests are only done smal-model. There > is at least one ( ;-) problem I know of that only shows in large-model. > Could we do that too? Yes, it's already on my disk. I hesitated to commit it, because I have to break with one of Michael's rules: # Each directory under ports/ is used as a port name. Each port is tested. # The port name must be the same as the one used in the SDCC '-mxxx' argument. The necessary changes are small. If Michael agrees, I will commit them. Bernhard |
From: Michael H. <mic...@ju...> - 2001-12-17 17:35:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Feel free. Just update the rules so the documentation is consistent. - -- Michael On Mon, 17 Dec 2001, Bernhard Held wrote: > > Right now I think the mcs51 regression tests are only done smal-model. > There > > is at least one ( ;-) problem I know of that only shows in large-model. > > Could we do that too? > > Yes, it's already on my disk. I hesitated to commit it, because I have to > break with one of Michael's rules: > > # Each directory under ports/ is used as a port name. Each port is tested. > # The port name must be the same as the one used in the SDCC '-mxxx' > argument. > > > The necessary changes are small. If Michael agrees, I will commit them. > > Bernhard > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (OpenBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjweLMQACgkQ3L3H1ImjCiSo1ACffq5LGPeMDvyLbCnRJq/nWtbK +E8AmwewSxP1tTSImCsIWwCiMKX/2Qi+ =JqeU -----END PGP SIGNATURE----- |
From: Bernhard H. <ber...@be...> - 2001-12-17 20:49:42
|
> Feel free. Just update the rules so the documentation is consistent. Thanks. Everything's ready to commit, but cvs (resp. ssh) tells me: >Secure connection to cvs.sdcc.sourceforge.net refused. Even an "cvs update" is refused. Don't know what's going on :-( I'll try again tomorrow. Bernhard |
From: Sandeep D. <sa...@wi...> - 2001-12-17 21:38:29
|
Yes I'm having the same problem. I made the fix to the ds390 port .. now cannot commit because of this sourceforge problem. Sandeep > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On Behalf Of Bernhard > Held > Sent: Monday, December 17, 2001 12:51 PM > To: sdc...@li... > Subject: Re: [sdcc-devel] comitted: extra segments for > initialized data > > > > Feel free. Just update the rules so the documentation is > consistent. > Thanks. > > Everything's ready to commit, but cvs (resp. ssh) tells me: > >Secure connection to cvs.sdcc.sourceforge.net refused. > > Even an "cvs update" is refused. Don't know what's going on :-( > I'll try again tomorrow. > > Bernhard > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > |
From: Johan K. <joh...@id...> - 2001-12-14 13:10:20
|
> So, if anyone has actually read this far, please at least > comment yeah or nay as to wether you think this approach is > the right thing to do. There is of course the separate > issue of someone actually doing it.... but first, does this > approach sound like the right thing to do?? I recall Johan > did something a while back, but isn't it only in the ds390 > port?? I think this is the right approach, and yes, it's there. Only for the mcs51 port when you set envvar $TRY_THE_NEW_INITIALIZER. But since no one commented when I implemented this, I didn't really finish it. Now that we also have a _builtin memcpy() this could be made the default. > >2. Are people actually interested in these issues at all? > > I am. Anyone who's read this entire message probably is also. :) me too Johan |
From: Russel W. <r.w...@18...> - 2001-12-14 13:59:11
|
Paul, > http://www.abisource.com/support/expectations.phtml Very apposite and well worth a read. > circuits and assembly guy who dreams of someday making a grand I am in need of someone who can work in Java, C, assembler (8051, z80, 68hc12, h8) and Verilog and wants to work in East Croydon, UK. > >From your other earlier posts, it looks like your project has > some large data structures stored in an EPROM or some other > non-volatile memory, and you've connected the NV chip that has > this data to RD instead of PSEN so that it doesn't burn up the > 64k of code space, which you presumably want to fill with code > that won't need much (or any) external RAM. The systems we are working with are single package systems, there are no separate chips. The silicon arrives with a collaborator who breaks it into units and tapes it up and then after programming bonds it into the carrier (smartcards, SIMs, etc.) The exact internal connectivity of these things is being debated between the silicon manufacturer and the rest of us -- i.e. I currently don't have a clue but assume the manufacturer does! Our data structure is part OTP, part EEPROM. > The first fundamental problem is that standard intel-hex format > provides a single 64k memory space. There are a couple record > types (02, 04) which allow 20 or 32 bit address spaces. To > the best of my knowledge, there is no commonly accepted extension > to intel-hex to define multiple memory spaces. In the world of > Microchip PIC, I've seen extensions where a certain memory > region was intended to represent data to be loaded into the > chips EEPROM. For mcs51, you'd probably want to produce two > hex files, one for code memory initialization and the other for > xdata memory. The same is also true of S-Records (with different constraints). I had assumed that there would have to be two download files as communication from the compiler to the downloader to cover this and the downloader would then do the merge as needed. > Now the current mcs51 xdata initialization, using hardcoded > MOVX instructions (aka genAssign) is highly inefficient for > initialization of anything more than about a dozen bytes. Agreed. Some weeks ago there was a debate amongst the development activists as to how this might be changed to use a memcpy equivalent but I don't think this got developed further. Also this is an alteration of the status quo to deal with large structures in the current ROM/RAM partitioning model. > The approach taken by Hi-Tech C (which I think is the "right > way") involves defining special code memory segments to the > linker for initialized data and adding runtime startup code > in the library which copies these segments from code memory > to data, xdata, idata. The library code uses special symbols > available from the linker to directly embed the source (in code) > and distination addresses and the length, which makes this > code very fast and compact when written in assembly. Even > for fairly small numbers of initialized variables, the > code size added by these startup routines is less than the > space taken by using MOV/MOVX (genAssign). This could then be extended to have an XDATA pre-initialized segment which gets treated differently, i.e. the values are specified in the C code but are not initialized in either of the MOVX or memcpy routes but via a separate download file. This allows the code itself to link properly. <snip> > Now, back to Russel's application. If SDCC were to take > this approach, then at least the compiler portion of SDCC > would be able to emit .rel files that meet your needs (or > at least what I understand as I described above). You > would still need to have support in the linker, where > you could direct the linker to emit those special segments > as a separate file, or at some special offset that matches > how your toolset will program the chips or otherwise > load the data. You are, I believe, describing a minor variation on what I was thinking and what we have mocked up in a hacky way that works with IAR EW. Fortunately, their linker and simulator already had the necessary hooks (even though IAR had not put them there explicitly!) to allow part of what we need and you describe to happen. Their compiler/linker/simulator needs work but they have agreed that "something needs doing". > I seriously doubt that anyone will write special code into > the linker for this particular application, partly because > it's special, partly because nobody seems to work on the > linker much, and partly because the code in the linker is > not much fun to work on. Not entirely true. SDCC took a fork of aslink sometime back and so the linker code is open to amendment. It might even be worth re-integrating asXXXX since it has developed since Sandeep took a fork of it. <snip> > >2. Are people actually interested in these issues at all? > > I am. Anyone who's read this entire message probably is also. Certainly includes me, but if it didn't I would be a total hypocrite. -- Russel. ==================================================================== Dr Russel Winder Chief Technology Officer OneEighty Software Ltd Tel: +44 20 8680 8712 Cygnet House Fax: +44 20 8680 8453 12-14 Sydenham Road R.W...@18... Croydon, Surrey CR9 2ET, UK http://www.180sw.com ==================================================================== Under the Regulation of Investigatory Powers (RIP) Act 2000 together with any and all Regulations in force pursuant to the Act One Eighty Software Ltd reserves the right to monitor any or all incoming or outgoing communications as provided for under the Act |