From: SourceForge.net <no...@so...> - 2003-08-09 18:27:38
|
Bugs item #785979, was opened at 2003-08-09 11:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2003-08-09 21:39:12
|
Bugs item #785979, was opened at 2003-08-09 18:27 Message generated for change (Comment added) made by frief You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- >Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 21:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2003-08-14 18:15:57
|
Bugs item #785979, was opened at 2003-08-09 11:27 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 11:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 14:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2003-08-14 19:28:03
|
Bugs item #785979, was opened at 2003-08-09 11:27 Message generated for change (Comment added) made by jesusc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- >Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 11:36 Message: Logged In: YES user_id=603650 Check the sdcc manual, section 2.4.7: Building SDCC Using Microsoft Visual C++ 6.0/NET (MSVC) at http://sdcc.sourceforge.net/doc/sdccman.html/node14.html#S ECTION00034700000000000000 Jesus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 11:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 14:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2003-08-14 22:58:50
|
Bugs item #785979, was opened at 2003-08-09 11:27 Message generated for change (Comment added) made by jesusc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- >Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 14:35 Message: Logged In: YES user_id=603650 There is a simpler solution to this problem than using an external initialization file crt0.s: If option --no-xinit-opt is used, the initialiazion of external RAM can be placed directly in _sdcc_external_startup(). A bonus to this would be the use of dual dptr registers when available. Jesus ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-14 13:27 Message: Logged In: YES user_id=589052 Hi, with the cygnal deviating from the standard 8051 core patching the compiler currently seems the only way to properly initialize it. This is not nice. Maybe the 8051 port should switch to an initialization via an external file crt0.s as the z80 port does? Frieder ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 11:36 Message: Logged In: YES user_id=603650 Check the sdcc manual, section 2.4.7: Building SDCC Using Microsoft Visual C++ 6.0/NET (MSVC) at http://sdcc.sourceforge.net/doc/sdccman.html/node14.html#S ECTION00034700000000000000 Jesus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 11:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 14:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2003-08-15 04:23:00
|
Bugs item #785979, was opened at 2003-08-09 18:27 Message generated for change (Comment added) made by frief You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- >Comment By: Frieder Ferlemann (frief) Date: 2003-08-14 20:27 Message: Logged In: YES user_id=589052 Hi, with the cygnal deviating from the standard 8051 core patching the compiler currently seems the only way to properly initialize it. This is not nice. Maybe the 8051 port should switch to an initialization via an external file crt0.s as the z80 port does? Frieder ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 18:36 Message: Logged In: YES user_id=603650 Check the sdcc manual, section 2.4.7: Building SDCC Using Microsoft Visual C++ 6.0/NET (MSVC) at http://sdcc.sourceforge.net/doc/sdccman.html/node14.html#S ECTION00034700000000000000 Jesus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 18:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 21:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2003-08-18 01:41:26
|
Bugs item #785979, was opened at 2003-08-09 11:27 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-17 18:41 Message: Logged In: NO I did as advised; used the --no-xinit-opt and source code something to this effect (actual tested source code not available at time of posting) main() { ... Variable declarations _asm mov r0, #l_XINIT mov r1, #(l_XINIT >> 8) mov r2, #s_XINIT mov r3, #(s_XINIT >> 8) mov r4, #s_XISEG mov r5, #(s_XISEG >> 8) 00001$: mov a, #255 add a, r0 mov r0, a mov a, #255 addc r1, a mov r1, a jnc 00002$ mov dpl, r2 mov dph, r3 clr a movc a, @a+dptr inc dptr mov r2, dpl mov r3, dph mov dpl, r4 mov dph, r5 movx @dptr, a inc dptr mov r4, dpl mov r5, dph sjmp 00001$ 00002$: _endasm; I am wondering why not use something like what is shown above so 8051 variants that don't accept P2 paging for xdata will still work? This code is only executed once on startup, so efficiency and code size are not a primary concern; I would tend to side with greater reliability than code size or efficiency in this case. I am posting this mostly as a solution around this problem, since I consider the problem essentially solved, now. ro...@hi... ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 14:35 Message: Logged In: YES user_id=603650 There is a simpler solution to this problem than using an external initialization file crt0.s: If option --no-xinit-opt is used, the initialiazion of external RAM can be placed directly in _sdcc_external_startup(). A bonus to this would be the use of dual dptr registers when available. Jesus ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-14 13:27 Message: Logged In: YES user_id=589052 Hi, with the cygnal deviating from the standard 8051 core patching the compiler currently seems the only way to properly initialize it. This is not nice. Maybe the 8051 port should switch to an initialization via an external file crt0.s as the z80 port does? Frieder ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 11:36 Message: Logged In: YES user_id=603650 Check the sdcc manual, section 2.4.7: Building SDCC Using Microsoft Visual C++ 6.0/NET (MSVC) at http://sdcc.sourceforge.net/doc/sdccman.html/node14.html#S ECTION00034700000000000000 Jesus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 11:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 14:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2003-08-30 17:00:24
|
Bugs item #785979, was opened at 2003-08-09 11:27 Message generated for change (Comment added) made by pjs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- >Comment By: Paul Stoffregen (pjs) Date: 2003-08-30 10:00 Message: Logged In: YES user_id=104682 Perhaps the "hard coded" initialization should be a simple LCALL instruction, and move this code into the library. This same approach is used for _sdcc_external_startup() today, and it allows a "default" version to be in the library, and users can easily code their own and the linker will use their code rather than the default copy in the standard library. -Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-17 18:41 Message: Logged In: NO I did as advised; used the --no-xinit-opt and source code something to this effect (actual tested source code not available at time of posting) main() { ... Variable declarations _asm mov r0, #l_XINIT mov r1, #(l_XINIT >> 8) mov r2, #s_XINIT mov r3, #(s_XINIT >> 8) mov r4, #s_XISEG mov r5, #(s_XISEG >> 8) 00001$: mov a, #255 add a, r0 mov r0, a mov a, #255 addc r1, a mov r1, a jnc 00002$ mov dpl, r2 mov dph, r3 clr a movc a, @a+dptr inc dptr mov r2, dpl mov r3, dph mov dpl, r4 mov dph, r5 movx @dptr, a inc dptr mov r4, dpl mov r5, dph sjmp 00001$ 00002$: _endasm; I am wondering why not use something like what is shown above so 8051 variants that don't accept P2 paging for xdata will still work? This code is only executed once on startup, so efficiency and code size are not a primary concern; I would tend to side with greater reliability than code size or efficiency in this case. I am posting this mostly as a solution around this problem, since I consider the problem essentially solved, now. ro...@hi... ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 14:35 Message: Logged In: YES user_id=603650 There is a simpler solution to this problem than using an external initialization file crt0.s: If option --no-xinit-opt is used, the initialiazion of external RAM can be placed directly in _sdcc_external_startup(). A bonus to this would be the use of dual dptr registers when available. Jesus ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-14 13:27 Message: Logged In: YES user_id=589052 Hi, with the cygnal deviating from the standard 8051 core patching the compiler currently seems the only way to properly initialize it. This is not nice. Maybe the 8051 port should switch to an initialization via an external file crt0.s as the z80 port does? Frieder ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 11:36 Message: Logged In: YES user_id=603650 Check the sdcc manual, section 2.4.7: Building SDCC Using Microsoft Visual C++ 6.0/NET (MSVC) at http://sdcc.sourceforge.net/doc/sdccman.html/node14.html#S ECTION00034700000000000000 Jesus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 11:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 14:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2003-10-31 13:00:31
|
Bugs item #785979, was opened at 2003-08-09 20:27 Message generated for change (Comment added) made by vanmierlo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- Comment By: Van Mierlo Ingenieursbureau (vanmierlo) Date: 2003-10-31 14:00 Message: Logged In: YES user_id=591031 Hello Frieder, Since nobody answers your question, I'll give you the answer. The cygnal devices come in four different flavours with regard to internal xram: 1) no xram, nor external memory interface: nothing to be done with internal xram/external memory interface: 2) 'just' another paging register EMI0CN at 0xAF 3) 'just' another paging register EMI0CN at 0xAA 4) not 'just' another paging register, but a paging register EMI0CN at 0xA2 in an sfr-page (0). Especially the last one will give most problems I guess. The best approach I see is either use the generic solution or use the move-it-to-library option. The last one would be my preferred option. greetings, Maarten Brock ---------------------------------------------------------------------- Comment By: Paul Stoffregen (pjs) Date: 2003-08-30 19:00 Message: Logged In: YES user_id=104682 Perhaps the "hard coded" initialization should be a simple LCALL instruction, and move this code into the library. This same approach is used for _sdcc_external_startup() today, and it allows a "default" version to be in the library, and users can easily code their own and the linker will use their code rather than the default copy in the standard library. -Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-18 03:41 Message: Logged In: NO I did as advised; used the --no-xinit-opt and source code something to this effect (actual tested source code not available at time of posting) main() { ... Variable declarations _asm mov r0, #l_XINIT mov r1, #(l_XINIT >> 8) mov r2, #s_XINIT mov r3, #(s_XINIT >> 8) mov r4, #s_XISEG mov r5, #(s_XISEG >> 8) 00001$: mov a, #255 add a, r0 mov r0, a mov a, #255 addc r1, a mov r1, a jnc 00002$ mov dpl, r2 mov dph, r3 clr a movc a, @a+dptr inc dptr mov r2, dpl mov r3, dph mov dpl, r4 mov dph, r5 movx @dptr, a inc dptr mov r4, dpl mov r5, dph sjmp 00001$ 00002$: _endasm; I am wondering why not use something like what is shown above so 8051 variants that don't accept P2 paging for xdata will still work? This code is only executed once on startup, so efficiency and code size are not a primary concern; I would tend to side with greater reliability than code size or efficiency in this case. I am posting this mostly as a solution around this problem, since I consider the problem essentially solved, now. ro...@hi... ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 23:35 Message: Logged In: YES user_id=603650 There is a simpler solution to this problem than using an external initialization file crt0.s: If option --no-xinit-opt is used, the initialiazion of external RAM can be placed directly in _sdcc_external_startup(). A bonus to this would be the use of dual dptr registers when available. Jesus ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-14 22:27 Message: Logged In: YES user_id=589052 Hi, with the cygnal deviating from the standard 8051 core patching the compiler currently seems the only way to properly initialize it. This is not nice. Maybe the 8051 port should switch to an initialization via an external file crt0.s as the z80 port does? Frieder ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 20:36 Message: Logged In: YES user_id=603650 Check the sdcc manual, section 2.4.7: Building SDCC Using Microsoft Visual C++ 6.0/NET (MSVC) at http://sdcc.sourceforge.net/doc/sdccman.html/node14.html#S ECTION00034700000000000000 Jesus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 20:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 23:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2003-11-01 13:20:47
|
Bugs item #785979, was opened at 2003-08-09 18:27 Message generated for change (Comment added) made by frief You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- >Comment By: Frieder Ferlemann (frief) Date: 2003-11-01 13:20 Message: Logged In: YES user_id=589052 Hi, > The cygnal devices come in four different > flavours with regard to internal xram: > 1) no xram, nor external memory interface: nothing to be done > 2) 'just' another paging register EMI0CN at 0xAF > 3) 'just' another paging register EMI0CN at 0xAA These could maybe be resolved with the help of the linker. If SDCC would output "P2_ALIKE_PDATA_PAGING_SFR" instead of "P2", then the linker could first try to link to location "P2_ALIKE_PDATA_PAGING_SFR" (which would be EMI0CN on a cygnal and something else for f.e. a Triscend) and if this fails fall back to "P2". The long name is chosen here for clarity and not as a real proposal - Comments? > 4) not 'just' another paging register, but a paging register > EMI0CN at 0xA2 in an sfr-page (0). Funny that the paging register itself is a paged register =:O Probably it will stay the responsibility of the programmer to asure that EMI0CN is paged in when it is needed - if that is true then the above proposal should be OK. Please note: If you want to use generic pointers (on a cygnal) pointing to addresses in pdata then you won't like the use of "p2" in: sdcc/device/lib/_gptrget.c (f.e. memcpy and friends are calling gptrget) You probably have three options there: a) cast your pointer to (xdata char*), b) provide your own gptrget function c) persuade users/developers to have a slightly slower but cygnal compatible function;) Greetings, Frieder ---------------------------------------------------------------------- Comment By: Van Mierlo Ingenieursbureau (vanmierlo) Date: 2003-10-31 13:00 Message: Logged In: YES user_id=591031 Hello Frieder, Since nobody answers your question, I'll give you the answer. The cygnal devices come in four different flavours with regard to internal xram: 1) no xram, nor external memory interface: nothing to be done with internal xram/external memory interface: 2) 'just' another paging register EMI0CN at 0xAF 3) 'just' another paging register EMI0CN at 0xAA 4) not 'just' another paging register, but a paging register EMI0CN at 0xA2 in an sfr-page (0). Especially the last one will give most problems I guess. The best approach I see is either use the generic solution or use the move-it-to-library option. The last one would be my preferred option. greetings, Maarten Brock ---------------------------------------------------------------------- Comment By: Paul Stoffregen (pjs) Date: 2003-08-30 17:00 Message: Logged In: YES user_id=104682 Perhaps the "hard coded" initialization should be a simple LCALL instruction, and move this code into the library. This same approach is used for _sdcc_external_startup() today, and it allows a "default" version to be in the library, and users can easily code their own and the linker will use their code rather than the default copy in the standard library. -Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-18 01:41 Message: Logged In: NO I did as advised; used the --no-xinit-opt and source code something to this effect (actual tested source code not available at time of posting) main() { ... Variable declarations _asm mov r0, #l_XINIT mov r1, #(l_XINIT >> 8) mov r2, #s_XINIT mov r3, #(s_XINIT >> 8) mov r4, #s_XISEG mov r5, #(s_XISEG >> 8) 00001$: mov a, #255 add a, r0 mov r0, a mov a, #255 addc r1, a mov r1, a jnc 00002$ mov dpl, r2 mov dph, r3 clr a movc a, @a+dptr inc dptr mov r2, dpl mov r3, dph mov dpl, r4 mov dph, r5 movx @dptr, a inc dptr mov r4, dpl mov r5, dph sjmp 00001$ 00002$: _endasm; I am wondering why not use something like what is shown above so 8051 variants that don't accept P2 paging for xdata will still work? This code is only executed once on startup, so efficiency and code size are not a primary concern; I would tend to side with greater reliability than code size or efficiency in this case. I am posting this mostly as a solution around this problem, since I consider the problem essentially solved, now. ro...@hi... ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 21:35 Message: Logged In: YES user_id=603650 There is a simpler solution to this problem than using an external initialization file crt0.s: If option --no-xinit-opt is used, the initialiazion of external RAM can be placed directly in _sdcc_external_startup(). A bonus to this would be the use of dual dptr registers when available. Jesus ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-14 20:27 Message: Logged In: YES user_id=589052 Hi, with the cygnal deviating from the standard 8051 core patching the compiler currently seems the only way to properly initialize it. This is not nice. Maybe the 8051 port should switch to an initialization via an external file crt0.s as the z80 port does? Frieder ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 18:36 Message: Logged In: YES user_id=603650 Check the sdcc manual, section 2.4.7: Building SDCC Using Microsoft Visual C++ 6.0/NET (MSVC) at http://sdcc.sourceforge.net/doc/sdccman.html/node14.html#S ECTION00034700000000000000 Jesus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 18:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 21:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2003-12-05 15:53:12
|
Bugs item #785979, was opened at 2003-08-09 20:27 Message generated for change (Comment added) made by vanmierlo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- Comment By: Van Mierlo Ingenieursbureau (vanmierlo) Date: 2003-12-05 16:53 Message: Logged In: YES user_id=591031 Hello, I've seen in the logs that the use of P2 in _gptrget.c is already disabled. Now I've looked in the source tree and found only two other places where it is used: in mcs51/main.c in the initialisation as already observed and I think this really should be moved to a library function. And the other place is in SDCCglue.c (line 1801) for setting up the xstack. I think this should be moved into _sdcc_external_startup() where it can be changed/overridden by the user. Btw, two questions: Is it ensured that the xstack area starts on a 256 byte aligned page? (And how?) And what happens if one compiles _sdcc_external_startup() with --xstack? I think this will go wrong and there should be a warning about it in _startup.c and the documentation. Greetings, Maarten ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-11-01 14:20 Message: Logged In: YES user_id=589052 Hi, > The cygnal devices come in four different > flavours with regard to internal xram: > 1) no xram, nor external memory interface: nothing to be done > 2) 'just' another paging register EMI0CN at 0xAF > 3) 'just' another paging register EMI0CN at 0xAA These could maybe be resolved with the help of the linker. If SDCC would output "P2_ALIKE_PDATA_PAGING_SFR" instead of "P2", then the linker could first try to link to location "P2_ALIKE_PDATA_PAGING_SFR" (which would be EMI0CN on a cygnal and something else for f.e. a Triscend) and if this fails fall back to "P2". The long name is chosen here for clarity and not as a real proposal - Comments? > 4) not 'just' another paging register, but a paging register > EMI0CN at 0xA2 in an sfr-page (0). Funny that the paging register itself is a paged register =:O Probably it will stay the responsibility of the programmer to asure that EMI0CN is paged in when it is needed - if that is true then the above proposal should be OK. Please note: If you want to use generic pointers (on a cygnal) pointing to addresses in pdata then you won't like the use of "p2" in: sdcc/device/lib/_gptrget.c (f.e. memcpy and friends are calling gptrget) You probably have three options there: a) cast your pointer to (xdata char*), b) provide your own gptrget function c) persuade users/developers to have a slightly slower but cygnal compatible function;) Greetings, Frieder ---------------------------------------------------------------------- Comment By: Van Mierlo Ingenieursbureau (vanmierlo) Date: 2003-10-31 14:00 Message: Logged In: YES user_id=591031 Hello Frieder, Since nobody answers your question, I'll give you the answer. The cygnal devices come in four different flavours with regard to internal xram: 1) no xram, nor external memory interface: nothing to be done with internal xram/external memory interface: 2) 'just' another paging register EMI0CN at 0xAF 3) 'just' another paging register EMI0CN at 0xAA 4) not 'just' another paging register, but a paging register EMI0CN at 0xA2 in an sfr-page (0). Especially the last one will give most problems I guess. The best approach I see is either use the generic solution or use the move-it-to-library option. The last one would be my preferred option. greetings, Maarten Brock ---------------------------------------------------------------------- Comment By: Paul Stoffregen (pjs) Date: 2003-08-30 19:00 Message: Logged In: YES user_id=104682 Perhaps the "hard coded" initialization should be a simple LCALL instruction, and move this code into the library. This same approach is used for _sdcc_external_startup() today, and it allows a "default" version to be in the library, and users can easily code their own and the linker will use their code rather than the default copy in the standard library. -Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-18 03:41 Message: Logged In: NO I did as advised; used the --no-xinit-opt and source code something to this effect (actual tested source code not available at time of posting) main() { ... Variable declarations _asm mov r0, #l_XINIT mov r1, #(l_XINIT >> 8) mov r2, #s_XINIT mov r3, #(s_XINIT >> 8) mov r4, #s_XISEG mov r5, #(s_XISEG >> 8) 00001$: mov a, #255 add a, r0 mov r0, a mov a, #255 addc r1, a mov r1, a jnc 00002$ mov dpl, r2 mov dph, r3 clr a movc a, @a+dptr inc dptr mov r2, dpl mov r3, dph mov dpl, r4 mov dph, r5 movx @dptr, a inc dptr mov r4, dpl mov r5, dph sjmp 00001$ 00002$: _endasm; I am wondering why not use something like what is shown above so 8051 variants that don't accept P2 paging for xdata will still work? This code is only executed once on startup, so efficiency and code size are not a primary concern; I would tend to side with greater reliability than code size or efficiency in this case. I am posting this mostly as a solution around this problem, since I consider the problem essentially solved, now. ro...@hi... ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 23:35 Message: Logged In: YES user_id=603650 There is a simpler solution to this problem than using an external initialization file crt0.s: If option --no-xinit-opt is used, the initialiazion of external RAM can be placed directly in _sdcc_external_startup(). A bonus to this would be the use of dual dptr registers when available. Jesus ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-14 22:27 Message: Logged In: YES user_id=589052 Hi, with the cygnal deviating from the standard 8051 core patching the compiler currently seems the only way to properly initialize it. This is not nice. Maybe the 8051 port should switch to an initialization via an external file crt0.s as the z80 port does? Frieder ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 20:36 Message: Logged In: YES user_id=603650 Check the sdcc manual, section 2.4.7: Building SDCC Using Microsoft Visual C++ 6.0/NET (MSVC) at http://sdcc.sourceforge.net/doc/sdccman.html/node14.html#S ECTION00034700000000000000 Jesus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 20:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 23:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2004-03-18 04:45:55
|
Bugs item #785979, was opened at 2003-08-09 13:27 Message generated for change (Comment added) made by epetrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 >Category: msc51(8051) target >Group: fixed >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Erik Petrich (epetrich) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- >Comment By: Erik Petrich (epetrich) Date: 2004-03-17 22:45 Message: Logged In: YES user_id=635249 With the changes noted in ChangeLog 1.683, initialization can now be easily compatible with Cygnal (Silicon Labs) parts. For most cases, just define the sfr _PAGESFR at the location of the EMI0CN register. For example, include the declaration: sfr at 0xaf _PAGESFR; /* EMI0CN at 0xAF */ in any C file linked in a project. Most of the run-time startup/initialization is in a library now and thus can be overridden at the local level if more complex customizations are needed. ---------------------------------------------------------------------- Comment By: Van Mierlo Ingenieursbureau (vanmierlo) Date: 2003-12-05 09:53 Message: Logged In: YES user_id=591031 Hello, I've seen in the logs that the use of P2 in _gptrget.c is already disabled. Now I've looked in the source tree and found only two other places where it is used: in mcs51/main.c in the initialisation as already observed and I think this really should be moved to a library function. And the other place is in SDCCglue.c (line 1801) for setting up the xstack. I think this should be moved into _sdcc_external_startup() where it can be changed/overridden by the user. Btw, two questions: Is it ensured that the xstack area starts on a 256 byte aligned page? (And how?) And what happens if one compiles _sdcc_external_startup() with --xstack? I think this will go wrong and there should be a warning about it in _startup.c and the documentation. Greetings, Maarten ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-11-01 07:20 Message: Logged In: YES user_id=589052 Hi, > The cygnal devices come in four different > flavours with regard to internal xram: > 1) no xram, nor external memory interface: nothing to be done > 2) 'just' another paging register EMI0CN at 0xAF > 3) 'just' another paging register EMI0CN at 0xAA These could maybe be resolved with the help of the linker. If SDCC would output "P2_ALIKE_PDATA_PAGING_SFR" instead of "P2", then the linker could first try to link to location "P2_ALIKE_PDATA_PAGING_SFR" (which would be EMI0CN on a cygnal and something else for f.e. a Triscend) and if this fails fall back to "P2". The long name is chosen here for clarity and not as a real proposal - Comments? > 4) not 'just' another paging register, but a paging register > EMI0CN at 0xA2 in an sfr-page (0). Funny that the paging register itself is a paged register =:O Probably it will stay the responsibility of the programmer to asure that EMI0CN is paged in when it is needed - if that is true then the above proposal should be OK. Please note: If you want to use generic pointers (on a cygnal) pointing to addresses in pdata then you won't like the use of "p2" in: sdcc/device/lib/_gptrget.c (f.e. memcpy and friends are calling gptrget) You probably have three options there: a) cast your pointer to (xdata char*), b) provide your own gptrget function c) persuade users/developers to have a slightly slower but cygnal compatible function;) Greetings, Frieder ---------------------------------------------------------------------- Comment By: Van Mierlo Ingenieursbureau (vanmierlo) Date: 2003-10-31 07:00 Message: Logged In: YES user_id=591031 Hello Frieder, Since nobody answers your question, I'll give you the answer. The cygnal devices come in four different flavours with regard to internal xram: 1) no xram, nor external memory interface: nothing to be done with internal xram/external memory interface: 2) 'just' another paging register EMI0CN at 0xAF 3) 'just' another paging register EMI0CN at 0xAA 4) not 'just' another paging register, but a paging register EMI0CN at 0xA2 in an sfr-page (0). Especially the last one will give most problems I guess. The best approach I see is either use the generic solution or use the move-it-to-library option. The last one would be my preferred option. greetings, Maarten Brock ---------------------------------------------------------------------- Comment By: Paul Stoffregen (pjs) Date: 2003-08-30 12:00 Message: Logged In: YES user_id=104682 Perhaps the "hard coded" initialization should be a simple LCALL instruction, and move this code into the library. This same approach is used for _sdcc_external_startup() today, and it allows a "default" version to be in the library, and users can easily code their own and the linker will use their code rather than the default copy in the standard library. -Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-17 20:41 Message: Logged In: NO I did as advised; used the --no-xinit-opt and source code something to this effect (actual tested source code not available at time of posting) main() { ... Variable declarations _asm mov r0, #l_XINIT mov r1, #(l_XINIT >> 8) mov r2, #s_XINIT mov r3, #(s_XINIT >> 8) mov r4, #s_XISEG mov r5, #(s_XISEG >> 8) 00001$: mov a, #255 add a, r0 mov r0, a mov a, #255 addc r1, a mov r1, a jnc 00002$ mov dpl, r2 mov dph, r3 clr a movc a, @a+dptr inc dptr mov r2, dpl mov r3, dph mov dpl, r4 mov dph, r5 movx @dptr, a inc dptr mov r4, dpl mov r5, dph sjmp 00001$ 00002$: _endasm; I am wondering why not use something like what is shown above so 8051 variants that don't accept P2 paging for xdata will still work? This code is only executed once on startup, so efficiency and code size are not a primary concern; I would tend to side with greater reliability than code size or efficiency in this case. I am posting this mostly as a solution around this problem, since I consider the problem essentially solved, now. ro...@hi... ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 16:35 Message: Logged In: YES user_id=603650 There is a simpler solution to this problem than using an external initialization file crt0.s: If option --no-xinit-opt is used, the initialiazion of external RAM can be placed directly in _sdcc_external_startup(). A bonus to this would be the use of dual dptr registers when available. Jesus ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-14 15:27 Message: Logged In: YES user_id=589052 Hi, with the cygnal deviating from the standard 8051 core patching the compiler currently seems the only way to properly initialize it. This is not nice. Maybe the 8051 port should switch to an initialization via an external file crt0.s as the z80 port does? Frieder ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 13:36 Message: Logged In: YES user_id=603650 Check the sdcc manual, section 2.4.7: Building SDCC Using Microsoft Visual C++ 6.0/NET (MSVC) at http://sdcc.sourceforge.net/doc/sdccman.html/node14.html#S ECTION00034700000000000000 Jesus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 13:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 16:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2004-03-18 14:10:17
|
Bugs item #785979, was opened at 2003-08-09 20:27 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: msc51(8051) target Group: fixed Status: Closed Resolution: Fixed Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Erik Petrich (epetrich) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2004-03-18 15:10 Message: Logged In: YES user_id=888171 Thanks Erik, I was recently looking into this issue as well, but wasn't sure how to implement the asm code into the libraries. Thanks for this fix. However, the sfr name you chose is not ideal for silabs processors. Some of them have so many sfr's that they don't fit in 128 positions. So they implemented sfr-paging with some common sfr's in all pages and others at overlapping addresses in different pages (EMI0CN is one of them). Now guess what, the name they use to select the sfr-page is SFRPAGE. May I suggest another name for _PAGESFR: _XPAGE. Furthermore, if I were to create an example crtxinit.asm and crtxstack.asm for one of those sfr-paging mcu's (F12x), could it be added to the examples? After I hear from you, I will also update the silabs header files. Greets, Maarten ---------------------------------------------------------------------- Comment By: Erik Petrich (epetrich) Date: 2004-03-18 05:45 Message: Logged In: YES user_id=635249 With the changes noted in ChangeLog 1.683, initialization can now be easily compatible with Cygnal (Silicon Labs) parts. For most cases, just define the sfr _PAGESFR at the location of the EMI0CN register. For example, include the declaration: sfr at 0xaf _PAGESFR; /* EMI0CN at 0xAF */ in any C file linked in a project. Most of the run-time startup/initialization is in a library now and thus can be overridden at the local level if more complex customizations are needed. ---------------------------------------------------------------------- Comment By: Van Mierlo Ingenieursbureau (vanmierlo) Date: 2003-12-05 16:53 Message: Logged In: YES user_id=591031 Hello, I've seen in the logs that the use of P2 in _gptrget.c is already disabled. Now I've looked in the source tree and found only two other places where it is used: in mcs51/main.c in the initialisation as already observed and I think this really should be moved to a library function. And the other place is in SDCCglue.c (line 1801) for setting up the xstack. I think this should be moved into _sdcc_external_startup() where it can be changed/overridden by the user. Btw, two questions: Is it ensured that the xstack area starts on a 256 byte aligned page? (And how?) And what happens if one compiles _sdcc_external_startup() with --xstack? I think this will go wrong and there should be a warning about it in _startup.c and the documentation. Greetings, Maarten ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-11-01 14:20 Message: Logged In: YES user_id=589052 Hi, > The cygnal devices come in four different > flavours with regard to internal xram: > 1) no xram, nor external memory interface: nothing to be done > 2) 'just' another paging register EMI0CN at 0xAF > 3) 'just' another paging register EMI0CN at 0xAA These could maybe be resolved with the help of the linker. If SDCC would output "P2_ALIKE_PDATA_PAGING_SFR" instead of "P2", then the linker could first try to link to location "P2_ALIKE_PDATA_PAGING_SFR" (which would be EMI0CN on a cygnal and something else for f.e. a Triscend) and if this fails fall back to "P2". The long name is chosen here for clarity and not as a real proposal - Comments? > 4) not 'just' another paging register, but a paging register > EMI0CN at 0xA2 in an sfr-page (0). Funny that the paging register itself is a paged register =:O Probably it will stay the responsibility of the programmer to asure that EMI0CN is paged in when it is needed - if that is true then the above proposal should be OK. Please note: If you want to use generic pointers (on a cygnal) pointing to addresses in pdata then you won't like the use of "p2" in: sdcc/device/lib/_gptrget.c (f.e. memcpy and friends are calling gptrget) You probably have three options there: a) cast your pointer to (xdata char*), b) provide your own gptrget function c) persuade users/developers to have a slightly slower but cygnal compatible function;) Greetings, Frieder ---------------------------------------------------------------------- Comment By: Van Mierlo Ingenieursbureau (vanmierlo) Date: 2003-10-31 14:00 Message: Logged In: YES user_id=591031 Hello Frieder, Since nobody answers your question, I'll give you the answer. The cygnal devices come in four different flavours with regard to internal xram: 1) no xram, nor external memory interface: nothing to be done with internal xram/external memory interface: 2) 'just' another paging register EMI0CN at 0xAF 3) 'just' another paging register EMI0CN at 0xAA 4) not 'just' another paging register, but a paging register EMI0CN at 0xA2 in an sfr-page (0). Especially the last one will give most problems I guess. The best approach I see is either use the generic solution or use the move-it-to-library option. The last one would be my preferred option. greetings, Maarten Brock ---------------------------------------------------------------------- Comment By: Paul Stoffregen (pjs) Date: 2003-08-30 19:00 Message: Logged In: YES user_id=104682 Perhaps the "hard coded" initialization should be a simple LCALL instruction, and move this code into the library. This same approach is used for _sdcc_external_startup() today, and it allows a "default" version to be in the library, and users can easily code their own and the linker will use their code rather than the default copy in the standard library. -Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-18 03:41 Message: Logged In: NO I did as advised; used the --no-xinit-opt and source code something to this effect (actual tested source code not available at time of posting) main() { ... Variable declarations _asm mov r0, #l_XINIT mov r1, #(l_XINIT >> 8) mov r2, #s_XINIT mov r3, #(s_XINIT >> 8) mov r4, #s_XISEG mov r5, #(s_XISEG >> 8) 00001$: mov a, #255 add a, r0 mov r0, a mov a, #255 addc r1, a mov r1, a jnc 00002$ mov dpl, r2 mov dph, r3 clr a movc a, @a+dptr inc dptr mov r2, dpl mov r3, dph mov dpl, r4 mov dph, r5 movx @dptr, a inc dptr mov r4, dpl mov r5, dph sjmp 00001$ 00002$: _endasm; I am wondering why not use something like what is shown above so 8051 variants that don't accept P2 paging for xdata will still work? This code is only executed once on startup, so efficiency and code size are not a primary concern; I would tend to side with greater reliability than code size or efficiency in this case. I am posting this mostly as a solution around this problem, since I consider the problem essentially solved, now. ro...@hi... ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 23:35 Message: Logged In: YES user_id=603650 There is a simpler solution to this problem than using an external initialization file crt0.s: If option --no-xinit-opt is used, the initialiazion of external RAM can be placed directly in _sdcc_external_startup(). A bonus to this would be the use of dual dptr registers when available. Jesus ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-14 22:27 Message: Logged In: YES user_id=589052 Hi, with the cygnal deviating from the standard 8051 core patching the compiler currently seems the only way to properly initialize it. This is not nice. Maybe the 8051 port should switch to an initialization via an external file crt0.s as the z80 port does? Frieder ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 20:36 Message: Logged In: YES user_id=603650 Check the sdcc manual, section 2.4.7: Building SDCC Using Microsoft Visual C++ 6.0/NET (MSVC) at http://sdcc.sourceforge.net/doc/sdccman.html/node14.html#S ECTION00034700000000000000 Jesus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 20:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 23:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2004-03-18 15:41:54
|
Bugs item #785979, was opened at 2003-08-09 13:27 Message generated for change (Comment added) made by epetrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: msc51(8051) target Group: fixed Status: Closed Resolution: Fixed Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Erik Petrich (epetrich) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- >Comment By: Erik Petrich (epetrich) Date: 2004-03-18 09:41 Message: Logged In: YES user_id=635249 Ok, _PAGESFR is now _XPAGE. I had browsed a number of Silicon Lab's databooks looking for one that described the case in which EMI0CN itself was paged, but couldn't find it (they have so many databooks to cover their myriad of implementations!) An example of customizing crt*.asm would be great. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2004-03-18 08:10 Message: Logged In: YES user_id=888171 Thanks Erik, I was recently looking into this issue as well, but wasn't sure how to implement the asm code into the libraries. Thanks for this fix. However, the sfr name you chose is not ideal for silabs processors. Some of them have so many sfr's that they don't fit in 128 positions. So they implemented sfr-paging with some common sfr's in all pages and others at overlapping addresses in different pages (EMI0CN is one of them). Now guess what, the name they use to select the sfr-page is SFRPAGE. May I suggest another name for _PAGESFR: _XPAGE. Furthermore, if I were to create an example crtxinit.asm and crtxstack.asm for one of those sfr-paging mcu's (F12x), could it be added to the examples? After I hear from you, I will also update the silabs header files. Greets, Maarten ---------------------------------------------------------------------- Comment By: Erik Petrich (epetrich) Date: 2004-03-17 22:45 Message: Logged In: YES user_id=635249 With the changes noted in ChangeLog 1.683, initialization can now be easily compatible with Cygnal (Silicon Labs) parts. For most cases, just define the sfr _PAGESFR at the location of the EMI0CN register. For example, include the declaration: sfr at 0xaf _PAGESFR; /* EMI0CN at 0xAF */ in any C file linked in a project. Most of the run-time startup/initialization is in a library now and thus can be overridden at the local level if more complex customizations are needed. ---------------------------------------------------------------------- Comment By: Van Mierlo Ingenieursbureau (vanmierlo) Date: 2003-12-05 09:53 Message: Logged In: YES user_id=591031 Hello, I've seen in the logs that the use of P2 in _gptrget.c is already disabled. Now I've looked in the source tree and found only two other places where it is used: in mcs51/main.c in the initialisation as already observed and I think this really should be moved to a library function. And the other place is in SDCCglue.c (line 1801) for setting up the xstack. I think this should be moved into _sdcc_external_startup() where it can be changed/overridden by the user. Btw, two questions: Is it ensured that the xstack area starts on a 256 byte aligned page? (And how?) And what happens if one compiles _sdcc_external_startup() with --xstack? I think this will go wrong and there should be a warning about it in _startup.c and the documentation. Greetings, Maarten ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-11-01 07:20 Message: Logged In: YES user_id=589052 Hi, > The cygnal devices come in four different > flavours with regard to internal xram: > 1) no xram, nor external memory interface: nothing to be done > 2) 'just' another paging register EMI0CN at 0xAF > 3) 'just' another paging register EMI0CN at 0xAA These could maybe be resolved with the help of the linker. If SDCC would output "P2_ALIKE_PDATA_PAGING_SFR" instead of "P2", then the linker could first try to link to location "P2_ALIKE_PDATA_PAGING_SFR" (which would be EMI0CN on a cygnal and something else for f.e. a Triscend) and if this fails fall back to "P2". The long name is chosen here for clarity and not as a real proposal - Comments? > 4) not 'just' another paging register, but a paging register > EMI0CN at 0xA2 in an sfr-page (0). Funny that the paging register itself is a paged register =:O Probably it will stay the responsibility of the programmer to asure that EMI0CN is paged in when it is needed - if that is true then the above proposal should be OK. Please note: If you want to use generic pointers (on a cygnal) pointing to addresses in pdata then you won't like the use of "p2" in: sdcc/device/lib/_gptrget.c (f.e. memcpy and friends are calling gptrget) You probably have three options there: a) cast your pointer to (xdata char*), b) provide your own gptrget function c) persuade users/developers to have a slightly slower but cygnal compatible function;) Greetings, Frieder ---------------------------------------------------------------------- Comment By: Van Mierlo Ingenieursbureau (vanmierlo) Date: 2003-10-31 07:00 Message: Logged In: YES user_id=591031 Hello Frieder, Since nobody answers your question, I'll give you the answer. The cygnal devices come in four different flavours with regard to internal xram: 1) no xram, nor external memory interface: nothing to be done with internal xram/external memory interface: 2) 'just' another paging register EMI0CN at 0xAF 3) 'just' another paging register EMI0CN at 0xAA 4) not 'just' another paging register, but a paging register EMI0CN at 0xA2 in an sfr-page (0). Especially the last one will give most problems I guess. The best approach I see is either use the generic solution or use the move-it-to-library option. The last one would be my preferred option. greetings, Maarten Brock ---------------------------------------------------------------------- Comment By: Paul Stoffregen (pjs) Date: 2003-08-30 12:00 Message: Logged In: YES user_id=104682 Perhaps the "hard coded" initialization should be a simple LCALL instruction, and move this code into the library. This same approach is used for _sdcc_external_startup() today, and it allows a "default" version to be in the library, and users can easily code their own and the linker will use their code rather than the default copy in the standard library. -Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-17 20:41 Message: Logged In: NO I did as advised; used the --no-xinit-opt and source code something to this effect (actual tested source code not available at time of posting) main() { ... Variable declarations _asm mov r0, #l_XINIT mov r1, #(l_XINIT >> 8) mov r2, #s_XINIT mov r3, #(s_XINIT >> 8) mov r4, #s_XISEG mov r5, #(s_XISEG >> 8) 00001$: mov a, #255 add a, r0 mov r0, a mov a, #255 addc r1, a mov r1, a jnc 00002$ mov dpl, r2 mov dph, r3 clr a movc a, @a+dptr inc dptr mov r2, dpl mov r3, dph mov dpl, r4 mov dph, r5 movx @dptr, a inc dptr mov r4, dpl mov r5, dph sjmp 00001$ 00002$: _endasm; I am wondering why not use something like what is shown above so 8051 variants that don't accept P2 paging for xdata will still work? This code is only executed once on startup, so efficiency and code size are not a primary concern; I would tend to side with greater reliability than code size or efficiency in this case. I am posting this mostly as a solution around this problem, since I consider the problem essentially solved, now. ro...@hi... ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 16:35 Message: Logged In: YES user_id=603650 There is a simpler solution to this problem than using an external initialization file crt0.s: If option --no-xinit-opt is used, the initialiazion of external RAM can be placed directly in _sdcc_external_startup(). A bonus to this would be the use of dual dptr registers when available. Jesus ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-14 15:27 Message: Logged In: YES user_id=589052 Hi, with the cygnal deviating from the standard 8051 core patching the compiler currently seems the only way to properly initialize it. This is not nice. Maybe the 8051 port should switch to an initialization via an external file crt0.s as the z80 port does? Frieder ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 13:36 Message: Logged In: YES user_id=603650 Check the sdcc manual, section 2.4.7: Building SDCC Using Microsoft Visual C++ 6.0/NET (MSVC) at http://sdcc.sourceforge.net/doc/sdccman.html/node14.html#S ECTION00034700000000000000 Jesus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 13:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 16:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |
From: SourceForge.net <no...@so...> - 2004-03-18 19:31:17
|
Bugs item #785979, was opened at 2003-08-09 20:27 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 Category: msc51(8051) target Group: fixed Status: Closed Resolution: Fixed Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Erik Petrich (epetrich) Summary: xdata initialization fails on Cygnal parts Initial Comment: SDCC puts in code for initializing xdata that directly writes to port 2. The xdata command in Cygnal's 8051's accesses interal "extern data"--it is not external. As a result, the direct control of P2 to set the proper page before doing the movx @r0, a command fails on these products. ro...@hi... ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2004-03-18 20:28 Message: Logged In: YES user_id=888171 Hi Erik, Looking into your code some more, I see you initialize __start__xstack in src/mcs51/main.c (181) to the start of xram. If however this is not on a page boundary, the allocation for it overflows the page. See src/SDCCglue.c (1760). Maybe it's wise to change this allocation to use only the rest of this page (256 - (options.xdata_loc % 256)). And why doesn't crtxinit.asm have some .globl entries? And while you're at it, untabify the file please. SDCC is getting better every day. Thanks. Maarten ---------------------------------------------------------------------- Comment By: Erik Petrich (epetrich) Date: 2004-03-18 16:41 Message: Logged In: YES user_id=635249 Ok, _PAGESFR is now _XPAGE. I had browsed a number of Silicon Lab's databooks looking for one that described the case in which EMI0CN itself was paged, but couldn't find it (they have so many databooks to cover their myriad of implementations!) An example of customizing crt*.asm would be great. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2004-03-18 15:10 Message: Logged In: YES user_id=888171 Thanks Erik, I was recently looking into this issue as well, but wasn't sure how to implement the asm code into the libraries. Thanks for this fix. However, the sfr name you chose is not ideal for silabs processors. Some of them have so many sfr's that they don't fit in 128 positions. So they implemented sfr-paging with some common sfr's in all pages and others at overlapping addresses in different pages (EMI0CN is one of them). Now guess what, the name they use to select the sfr-page is SFRPAGE. May I suggest another name for _PAGESFR: _XPAGE. Furthermore, if I were to create an example crtxinit.asm and crtxstack.asm for one of those sfr-paging mcu's (F12x), could it be added to the examples? After I hear from you, I will also update the silabs header files. Greets, Maarten ---------------------------------------------------------------------- Comment By: Erik Petrich (epetrich) Date: 2004-03-18 05:45 Message: Logged In: YES user_id=635249 With the changes noted in ChangeLog 1.683, initialization can now be easily compatible with Cygnal (Silicon Labs) parts. For most cases, just define the sfr _PAGESFR at the location of the EMI0CN register. For example, include the declaration: sfr at 0xaf _PAGESFR; /* EMI0CN at 0xAF */ in any C file linked in a project. Most of the run-time startup/initialization is in a library now and thus can be overridden at the local level if more complex customizations are needed. ---------------------------------------------------------------------- Comment By: Van Mierlo Ingenieursbureau (vanmierlo) Date: 2003-12-05 16:53 Message: Logged In: YES user_id=591031 Hello, I've seen in the logs that the use of P2 in _gptrget.c is already disabled. Now I've looked in the source tree and found only two other places where it is used: in mcs51/main.c in the initialisation as already observed and I think this really should be moved to a library function. And the other place is in SDCCglue.c (line 1801) for setting up the xstack. I think this should be moved into _sdcc_external_startup() where it can be changed/overridden by the user. Btw, two questions: Is it ensured that the xstack area starts on a 256 byte aligned page? (And how?) And what happens if one compiles _sdcc_external_startup() with --xstack? I think this will go wrong and there should be a warning about it in _startup.c and the documentation. Greetings, Maarten ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-11-01 14:20 Message: Logged In: YES user_id=589052 Hi, > The cygnal devices come in four different > flavours with regard to internal xram: > 1) no xram, nor external memory interface: nothing to be done > 2) 'just' another paging register EMI0CN at 0xAF > 3) 'just' another paging register EMI0CN at 0xAA These could maybe be resolved with the help of the linker. If SDCC would output "P2_ALIKE_PDATA_PAGING_SFR" instead of "P2", then the linker could first try to link to location "P2_ALIKE_PDATA_PAGING_SFR" (which would be EMI0CN on a cygnal and something else for f.e. a Triscend) and if this fails fall back to "P2". The long name is chosen here for clarity and not as a real proposal - Comments? > 4) not 'just' another paging register, but a paging register > EMI0CN at 0xA2 in an sfr-page (0). Funny that the paging register itself is a paged register =:O Probably it will stay the responsibility of the programmer to asure that EMI0CN is paged in when it is needed - if that is true then the above proposal should be OK. Please note: If you want to use generic pointers (on a cygnal) pointing to addresses in pdata then you won't like the use of "p2" in: sdcc/device/lib/_gptrget.c (f.e. memcpy and friends are calling gptrget) You probably have three options there: a) cast your pointer to (xdata char*), b) provide your own gptrget function c) persuade users/developers to have a slightly slower but cygnal compatible function;) Greetings, Frieder ---------------------------------------------------------------------- Comment By: Van Mierlo Ingenieursbureau (vanmierlo) Date: 2003-10-31 14:00 Message: Logged In: YES user_id=591031 Hello Frieder, Since nobody answers your question, I'll give you the answer. The cygnal devices come in four different flavours with regard to internal xram: 1) no xram, nor external memory interface: nothing to be done with internal xram/external memory interface: 2) 'just' another paging register EMI0CN at 0xAF 3) 'just' another paging register EMI0CN at 0xAA 4) not 'just' another paging register, but a paging register EMI0CN at 0xA2 in an sfr-page (0). Especially the last one will give most problems I guess. The best approach I see is either use the generic solution or use the move-it-to-library option. The last one would be my preferred option. greetings, Maarten Brock ---------------------------------------------------------------------- Comment By: Paul Stoffregen (pjs) Date: 2003-08-30 19:00 Message: Logged In: YES user_id=104682 Perhaps the "hard coded" initialization should be a simple LCALL instruction, and move this code into the library. This same approach is used for _sdcc_external_startup() today, and it allows a "default" version to be in the library, and users can easily code their own and the linker will use their code rather than the default copy in the standard library. -Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-18 03:41 Message: Logged In: NO I did as advised; used the --no-xinit-opt and source code something to this effect (actual tested source code not available at time of posting) main() { ... Variable declarations _asm mov r0, #l_XINIT mov r1, #(l_XINIT >> 8) mov r2, #s_XINIT mov r3, #(s_XINIT >> 8) mov r4, #s_XISEG mov r5, #(s_XISEG >> 8) 00001$: mov a, #255 add a, r0 mov r0, a mov a, #255 addc r1, a mov r1, a jnc 00002$ mov dpl, r2 mov dph, r3 clr a movc a, @a+dptr inc dptr mov r2, dpl mov r3, dph mov dpl, r4 mov dph, r5 movx @dptr, a inc dptr mov r4, dpl mov r5, dph sjmp 00001$ 00002$: _endasm; I am wondering why not use something like what is shown above so 8051 variants that don't accept P2 paging for xdata will still work? This code is only executed once on startup, so efficiency and code size are not a primary concern; I would tend to side with greater reliability than code size or efficiency in this case. I am posting this mostly as a solution around this problem, since I consider the problem essentially solved, now. ro...@hi... ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 23:35 Message: Logged In: YES user_id=603650 There is a simpler solution to this problem than using an external initialization file crt0.s: If option --no-xinit-opt is used, the initialiazion of external RAM can be placed directly in _sdcc_external_startup(). A bonus to this would be the use of dual dptr registers when available. Jesus ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-14 22:27 Message: Logged In: YES user_id=589052 Hi, with the cygnal deviating from the standard 8051 core patching the compiler currently seems the only way to properly initialize it. This is not nice. Maybe the 8051 port should switch to an initialization via an external file crt0.s as the z80 port does? Frieder ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2003-08-14 20:36 Message: Logged In: YES user_id=603650 Check the sdcc manual, section 2.4.7: Building SDCC Using Microsoft Visual C++ 6.0/NET (MSVC) at http://sdcc.sourceforge.net/doc/sdccman.html/node14.html#S ECTION00034700000000000000 Jesus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-14 20:08 Message: Logged In: NO I am using W95 (not linux) but have MSVC 6 for programming C++. I bought it but never got good at it; is SDCC adaptable to MSVC 6 for a WIN32 console application? The place you mentioned is the perfect place to put in my own initialization code that doesn't use P2. Maybe you can give a pointer or two on recompiling the source with MSVC Visual Studio. While we are recompiling the source, there is a pointer to function error that ought to be found where calling a function from an array of function pointers generates bad code because someone used the wrong addressing mode; this should be a very simple fix of the proper fprintf statement. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-08-09 23:39 Message: Logged In: YES user_id=589052 Hi, you're probably talking about code that is generated by _mcs51_genXINIT in sdcc/src/mcs51/main.c near line 172 you can adapt the code there (hopefully 'just' use another paging register?), then recompile sdcc and have a go at your code again. Could you give a pointer as to which/how the cygnal devices differ? Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=785979&group_id=599 |