Re: [Sdcc-user] Old style C declaration error
On Mon, 3 Aug 2009, roelof 't Hooft wrote:
> Hi guys,
>
> This is driving me nuts, I have been searching in all the
> obvious places for information on this but still can not
> find what is wrong :
>
> utilities.h:15: error 7: Old style C declaration. IGNORED 'Delay'
> utilities.h:15: error 141: two or more data types in declaration for
> 'Delay'
>
> In the header file I have this :
>
> void Delay(uint16_t);
>
>
> And this is in the source file :
>
> /*
> * Delay the program for a certain amount of time.
> * The delay time is (6 + 10 * time) * 543nS
> *
> * time mSec
> * 10 0,057
> * 50 0,274
> * 100 0,546
> * 200 1,089
> * 400 2,175
> */
> void Delay(uint16_t time)
> {
> uint16_t i;
>
> for(i = 0; i < time; i++)
> {
> }
> }
I think the declaration for uint16_t is missing. You should have
#include
somewhere before using uint16_t. Otherwise, the compiler thinks you are
trying to use the old K&R rule that an identifier that hasn't been given a
type defaults to int. So in
void Delay(uint16_t);
the compiler thinks you are trying to declare a function prototype that
takes a parameter named "uint16_t" (since it doesn't know this was
supposed to be a type rather than a parameter name) that has an implicit
type of "int".
Erik
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Why SVN repository can not be accessed ?
On Sun, 30 Jan 2011, Bin Shi wrote: http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/ seems a bad link. There has been an attack on several of SourceForge's servers and so they have taken some services temporarily offline (including ViewVC noted in the link above). Another side effect of this is that the nightly SDCC snapshot builds continue to be built, but SourceForge is currently rejecting uploads to the project web site and so they are missing from the snapshot page. For details from SourceForge, see: http://sourceforge.net/apps/wordpress/sourceforge/2011/01/27/sourceforge-net-attack-update/ Erik -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] overflow in supposed to be unsigned long
On Wed, 4 May 2011, stof...@skulp.net wrote:
> Hi, I have to transmit an unsigned long as four bytes, so I split them up
> and join them again, but with the folowing example code, I get overflow at
> long_counter>32767 - can any of you give me a clue how to do it right?
> // split long_counter to four unsigned char's
> for (i = 0; i < 4; i++) {
> char_counter[i] = (long_counter & (0xff << (i * 8))) >> (i * 8);
> }
>
> // convert them to unsigned int again
> long_counter = char_counter[0] | (char_counter[1] << 8) |
> (char_counter[2] << 16) | (char_counter[3] << 24);
>
Your code for splitting the long into chars should work, but SDCC can
optimize this much better:
char_counter[0] = long_counter;
char_counter[1] = long_counter >> 8;
char_counter[2] = long_counter >> 16;
char_counter[3] = long_counter >> 24;
The problem you are having putting them back together is due to the C
integer promotion rules. Although you store the final result into a
variable of type long, all of the math leading up to that result will be
calculated with an int sized intermediary. Typecasting is needed to
explicitly promote the values to a larger type so that the intermediary
compuation does not overflow:
long_counter = (char_counter[0] | (char_counter[1] << 8)) |
((unsigned long)(char_counter[2] | (char_counter[3] << 8)) << 16);
This combines pairs of bytes into two int sized values, then promotes one
of them to a long sized value (the other will then also be promoted to the
same size automatically) before combining them into a single long.
Erik
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] overflow in supposed to be unsigned long
On Thu, 5 May 2011, Kristoffer Ek wrote: > > On 4.5.2011, at 6:20, Erik Petrich wrote: > >> long_counter = (char_counter[0] | (char_counter[1] << 8)) | >> ((unsigned long)(char_counter[2] | (char_counter[3] << 8)) << 16); > > > This overflows at 32767 :-/ > > -- stoffer Sorry, I didn't take into account there would be a sign extension in the first half. Try this instead: long_counter = (unsigned int)(char_counter[0] | (char_counter[1] << 8)) | ((unsigned long)(char_counter[2] | (char_counter[3] << 8)) << 16); Erik -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] overflow in supposed to be unsigned long
On Wed, 4 May 2011, Kevin Bailey wrote: On Wed, May 4, 2011 at 7:31 PM, Erik Petrich wrote: long_counter = (unsigned int)(char_counter[0] | (char_counter[1] << 8)) | ((unsigned long)(char_counter[2] | (char_counter[3] << 8)) << 16); I hope the first (unsigned int) cast isn't necessary, because the char_counter[1] << 8 would overflow if it wasn't implicitly an int. Yes, char_counter[1] << 8 is implicitly an int. The cast is needed to force it to be unsigned. Otherwise during conversion from (signed) int to unsigned long the most significant bit of the int result will be copied to all of the bits in the upper half of the long, which could then interfere with the bytes from char_counter[2] and char_counter[3]. Converting from unsigned int to unsigned long will force all the bits in the upper half of the long to 0, so no interference. My original suggestion omitted this cast and failed because I forgot to take this signed int to unsigned long behaviour into account. Erik -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] sdcc 3.1.0 release
On Fri, 4 Nov 2011, Borut Razem wrote: > Dear sdcc developers, > > are we ready for the sdcc 3.1.0 RC1 planned for tomorrow? > > Borut I'm done with my pre-release bug stomping (unless, of course, something turns up in the release candidates that I've broken). Erik -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] SDCC bug: Optimizer breaks the code
On Thu, 19 Jan 2012, Butuza Tamas wrote:
> Dear SDCC developers,
>
> I found a bug when I tried to compile a code for pic16F1938. (14 bit
> enhanced core)
>
> The problem is: The optimizer breaks the code. Makes part of the code
> unreachable.
> Error message is:
> test.c:51: warning 110: conditional flow changed by optimizer: so said EVELYN
> the modified DOG
> test.c:52: warning 126: unreachable code
>
> The compiler has problem with this line in the interrupt routine: "if
> ((irx1tmp & 0x01) != 0) {"
> Compiler thinks, the condition is always false, but it is not true.
> irx1tmp contains the received byte from serial port.
Actually, I think it's this condition that the compiler is issuing the
warning about:
if (doLedChange) {
The variable doLedChange is assigned an initial value of 0 in main() and
never assigned a non-zero value in the while loop so the compiler
concludes that this condition is always false. The compiler normally does
not expect variables to spontaneously change their values. If you are
doing something unusual such as an interrupt handler that changes the
value of a variable that a non-interrupt hander is polling, you should use
the "volatile" specifier to tell the compiler that the variable should not
be optimized in any way:
static volatile unsigned char irx1tmp, doLedChange, ledState;
(depending on what else you intend to do, irx1tmp and ledState may not
need to be volatile and so might be better as a seperate declaration)
This is a much better approach than completely disabling all optimization
and is compatible with the ANSI/ISO C standards.
Erik
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Code generated for small loop
On Fri, 18 Jan 2013, Vincent Pelletier wrote:
> Hi.
>
> I'm looking at asm generated for the following loop (8051, a CYCFX2LP
> actually) with sdcc 3.1.0#7066:
>
> __sbit __at 0x98+1 TI;
> void main() {
> while (!TI);
> TI = 0;
> }
>
> I get this:
>
> 00101$:
> jbc _TI,00115$
> sjmp00101$
> 00115$:
>
> Wouldn't it be more efficient, for such bit polling loop, to use instead:
>
> 00101$:
> jnb _TI,00101$
> clr _TI
>
> The first version polls _TI every 7 cycles.
> The second version polls _TI every 4 cycles.
> If _TI is set on loop entry, the first version exits after 4 cycles while the
> second exits after 6 cycles. I believe it's sane to assume this is an unlikely
> event, so it shouldn't matter too much.
>
> Regards,
> --
> Vincent Pelletier
The compiler is thinking you are trying to use TI as a binary semaphore
and so implements the sequence with an atomic test and clear to eliminate
the possibility that an interrupt might occur between the while loop and
the assignment. It does not realize that you are simply polling a hardware
status bit followed by a write to a control bit (that happens to be at the
same location as the status bit). From a C perspective, both of these
operations look like the same C code.
With TI=0 not present, sdcc would not treat this as a special case and
instead would use the jnb instruction that you expected. If you were
simply curious about sdcc's odd instruction selection, I hope this is a
sufficient explanation of what's going on here. Otherwise, if this cycle
timing issue is critical in your application and you need to change this
behavior, there several methods you could use:
1) If there is any operation that is performed after TI=0, that could be
moved to preceed TI=0, then doing so would keep the compiler from seeing
this as a semaphore style operation.
2) You could split TI into two bits (that happen to be at the same
address) and use one for read and one for writes:
__sbit __at 0x98+1 TI;
__sbit __at 0x98+1 TIclear;
void main() {
while (!TI);
TIclear = 0;
}
3) You could use a custom peephole rule:
replace {
%3:
jbc %1,%2
sjmp%3
%2:
} by {
%3:
jnb %1,%3
clr %1
} if labelRefCount %2 1
(Just put this in a file "peep.def" (or whatever) and then add the option
"--peep-file peep.def" to the parameters passed to sdcc when compiling)
Erik
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] using a #define to set a register
On Fri, 8 Feb 2013, roelof 't Hooft wrote: > Hi guys, > > I am using a #define to do a calculation during compile > time and load the result in an (8 bit) uart register so > that I can set the baudrate. > > I am using the following in a header file : > > #define crystal 11059200 > #define bd4800 (256 - crystal / 192 * 4800) > > Here the result is 0xef854100 > > #define crystal 11059200 > #define bd4800 (256 - (crystal / 921600)) > > And here the (correct) result is 0xf4 > > Why is it that the multiplication in the first #define fails ? > I have used brackets "()" in numerous places, did typecasts, > split up the #define in multiple parts but all failed on the > multiplication. Multiplication and division have equal precedence and are evaluated left-to-right, so #define bd4800 (256 - crystal / 192 * 4800) is evaluated as #define bd4800 (256 - ((crystal / 192) * 4800)) which gives you the result you see. However, adding parenthesis like this #define bd4800 (256 - crystal / (192 * 4800)) will also give an unexpected result since the integer promotion rules require that 192 * 4800 be computed with an int result, but the arithmetic result is too large to fit in SDCC's 16-bit int. I'd suggest using: #define bd4800 (256 - crystal / (192L * 4800)) > It seems that when I use a multiplication the result stored in > the #define is limited to a signed 16 bit number. > Is this assumption correct ? The #define performs no math; it just defines text for substitution. When the substituted text is evaluated by the next stage of the compiler you need to be aware of the scale of the intermediate results and make sure they will fit within the C specified promoted type (which may not be sufficiently promoted automatically). Erik -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] float <-> int cast
On Mon, 18 Feb 2013, Daniel Michalik wrote:
> When comparing the asm outputs I see that the first example does not call
> ___fs2uint, why does it not need to do this to cast the value of x?
> void main(void) {
> float x = 6116.0;
> debug = x;
> //debug is 6116.
> }
> unsigned int debug = 1234;
> float julianday = 6116.0;
>
> void main(void) {
> float x = 6116.0;
>
> debug = julianday;
> // expect 6116, obtain a vastly different (arbitrary?) number
> }
I can't answer most of your questions because I do use pic and so I am not
very familiar with that part of SDCC. However, I can answer why SDCC does
not need to call __fs2uint in the first example. SDCC's optimizations are
all at the function level. It can see that x is assigned the float value
6116.0 and then debug is assigned a value from x. It sees that there are
no intervening instructions that could modify x's value, therefor debug is
assigned the value 6116.0 cast to unsigned int. This cast is being applied
to a known constant, so the compiler performs this cast during compilation
to avoid the overhead of calling __fs2uint during run-time.
This does not happen in the second example because julianday is assigned
the value 6116.0 outside of the function. When optimizing the function,
the compiler only considers the code within the function and so does not
assume any variable still has its globally initialized value. Since the
compiler is not certain of the value of julianday, it cannot compute the
cast at compile-time and so inserts a call to __fs2uint to perform the
cast at run-time.
Give this version a try:
void main(void) {
volatile float x = 6116.0;
debug = x;
//debug is 6116.
}
The "volatile" keyword should disable most optimizion related to the
variable x and force the cast to be performed at run-time. If this leaves
the correct value in debug, the problem is with initialization of global
variables. However, if this also fails, then there is likely a problem
with the function implementing the run-time cast.
Erik
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Debugging under Eclipse
On Tue, 6 Aug 2013, Stefan Falk wrote: Hey guys, it's me again! Trying to get rid of the need of Keil I am trying to be able to debug a program that was compiled under the SDCC. The program runs on a eval-board which communicates with a server. I can communicate with this server by bridgeing some .dll files which then allows me to do stuff like this: // a java plugin server.getDevice.getPc(); server.getDevice().getAllRegisters(); and so on.. But all this would only make sense if I was able to "highlight" that line on wich the PC at the moment is. Keil generates a table like: C:C006H LINE# 60 C:C009H LINE# 62 C:C00FH LINE# 63 C:C014H LINE# 64 so if the PC == 0xC006 line 60 in the corresponding .c file would be highlichted. Can anyone provide me some guideline how I could manage this under Eclipse? - I got a plugin - I can receive all ?C information - I (technically) can debug in Eclipse already (but without useful visualisation) but - I can not associate the PCs address with a specific line of a .c or .asm file to highlight it in Eclipse Is there already an easy way how one could do this? If not, where can I get a description about how I can filter these information from the files that will be generated using the "--debug" option? Okay, I know this is not a small request from me but I'd be glad about anything that could help me since getting so far really took me a lot. Thank you very much and best regards, Stefan There used to be a link on the SDCC web page that described the .cdb file format that has debugging information, including the line/address relationships. I'm not sure what happened to i, but I'll tell you the part you need to know. The .cdb file is a plain text file with one debugging record per line. The lines that begin "L:C" are the records with the address of a particular "L"ine of "C" source. This is followed by the source filename and line number, both separated by the "$" symbol. Then there are two other fields that aren't particularly important, also separated by a "$" symbol. At the very end is a ":" symbol and the hexadecimal address associated with that line (although there is no prefix explicitly denoting the use of hexadecimal). So for example, the line: L:C$sample.c$32$1$16:51 indicates that the code associated with line 32 of sample.c begins at address 0x51 in memory. Although I have no idea how to integrate this with Eclipse, it should be fairly simple to translate the line/address information in the .cdb file to the format that Keil generated using a convenient scripting language of your choice. Erik -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Debugging under Eclipse
On Tue, 6 Aug 2013, Erik Petrich wrote: > There used to be a link on the SDCC web page that described the .cdb file > format that has debugging information, including the line/address > relationships. I'm not sure what happened to it, but I'll tell you the > part you need to know. Found it; it was moved to the wiki: http://sdcc.sourceforge.net/mediawiki/index.php/CDB_File_Format Erik -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] An Error While Trying Latest SDCC
On Fri, 20 Dec 2013, Ben Shi wrote: > And the for.c is in the standard regression test of SDCC > > http://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/src/regression/for. > c > > sdcc for.c -mmcs51 > for.asm:175: Error: missing or improper operators, terminators, or > delimiters > for.asm:179: Error: missing or improper operators, terminators, or > delimiters > removing for.rel These are regression tests for the pic14 target and insert inline assembly specific to the assembler for this particular processor family. It is not expected or intended to work with other targets. I suspect that only the developers who work with the pic14 target pay it any attention. The regression test suite for all other targets, including mcs51, is under: .../trunk/sdcc/support/regression/ After SDCC is built (it doesn't matter if it is installed or not), you can go to that directory and use the command (assuming you want to test mcs51): make test-mcs51 There are nearly 1000 test source files, so it will take awhile unless you have a really fast computer. Erik -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] About the PIC14 port
On Tue, 21 Jan 2014, Ben Shi wrote: > Hello, > > According to Microchip's website, > http://www.microchip.com/pagehandler/en-us/products/picmicrocontrollers, > 8-bit PIC has 4 serials, pic-10, pic12, pic16, pic18. > > So what is the pic14 port in SDCC ? > > Quite strange about that. > > Ben The 14 in "pic14" does not refer to anything in the part number or series name, but instead to the size of the instruction word. These microcontrollers use completely separate instruction and data busses. The data bus is 8 bits wide, like most small microcontrollers, but the instruction bus is 14 bits wide. This is indeed quite strange. Likewise, the 16 in "pic16" also refers to the size of the instruction word and nothing in the part number or series name. Erik -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Use of SDCC assembler's macros
On Thu, 13 Feb 2014, Jacques Pelletier wrote: > Hi, > > I'm trying to use the macros (.macro/.endm) in the SDCC assembler for > the Z80. However, it doesn't seem to work, and neither the latest > version of ASZ80 (5.06). > > For both, the macro is not expanded and give the same main.lst > > Here is the command I use: > asz80 -glos main.asm (or) > sdasz80 -glos main.asm > > My main.asm file: > .area main (ABS) > > .macro mytest value > ld a,#value > .endm > > .org 0 > > start: > calldummyfunc > > mytest 0x30 > > dummyfunc: > ret > > test1: > nop > test2: > nop > > > The resulting main.lst file: > AS Assembler V02.00 + NoICE + SDCC mods (Zilog Z80 / Hitachi > HD64180), page 1. > > > > 1 .area main (ABS) > 2 > 3 .macro mytest value > 4 ld a,#value > 5 .endm > 6 > 7 .org 0 > 8 > 9 start: > CD 03 00 [17] 10 calldummyfunc > 11 >0003 12 mytest 0x30 > 1 > 2 > 13 >0003 14 dummyfunc: >0003 C9[10] 15 ret > 16 >0004 17 test1: >0004 00[ 4] 18 nop >0005 19 test2: >0005 00[ 4] 20 nop > 21 > 22 > 23 > > > Any ideas? > > Jacques Pelletier This sounds exactly like bug 2166 "Macro expansion in sdas not working" http://sourceforge.net/p/sdcc/bugs/2166/ Go to the SDCC snapshot page http://sdcc.sourceforge.net/snap.php and update to any snapshot that has a date after Jan 4 of this year and that will probably take care of it, at least for sdasz80. Erik -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] r/w order for STM8 16b registers (Maarten Brock)
On Fri, 18 Apr 2014, Georg Icking-Konert wrote: > Hello Maarten, > > so far I observed it only for the ADC result register (ADC_DR) for read, > and timer 3 compare register (TIM3_CCR) for write. The way I realized > was simple: the ADC the result was skewed, and the TIM3 period was > wrong. However, I didn=92t dig deeper after I found out that changing > the sequence helps. > > At least for ADC_DR there is a hint in the STM8 reference manual > (http://www.st.com/web/en/resource/technical/document/reference_manual/CD0= > 0190271.pdf, page 425): "The conversion results from ADC_DRH and ADC_DRL > data registers must be read in a specific order to guarantee data > coherency. This order depends on the data alignment". For TIM3_CCR I > couldn't find any such hint :-( The introductory section for TIM3 states: Only the main features of the general purpose timers are given in this chapter. Refer to the corresponding paragraphs of Section 17: 16-bit advanced control timer (TIM1) on page 136 for more details on each feature. Looking back through that section I see that sections 17.5-17.5.1 (page 164) describes reading and writing the TIM1_CCRi registers. It states 16-bit values are loaded in the TIM1_CCRi registers through preload registers. This must be performed by two write instructions, one for each byte. The MS byte must be written first. The sequence for reading the TIM1_CCRi register is also shown as MS byte then LS byte. So the byte ordering is not an issue of read versus write, but simply an idiosyncrasy of the particular peripheral subsystem. Erik -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] stm8 sdas : variable problem
On Fri, 5 Sep 2014, r...@remi.lu wrote: > Hello > > SDCC : stm8 3.4.1 #9068 (Sep 5 2014) (Linux) > > I dont see the difference between this ( A and B ) : > > I have _lcdchar declared by : > > .area OSEG > _varOne: > .ds 1 > _lcdchar: > .db 1 > > .area CSEG > > . > .which seems not working, at least the way variables > are to mee in assembly ... > . Assuming you aren't using a custom linker script, I think you should use areas DATA and CODE instead of OSEG and CSEG. In particular, OSEG is usually used to hold temporary values in functions that do not call other functions because all of the OSEG areas overlay (the O in OSEG) each other. So if your delay_m function also uses a variable in OSEG (or calls some other function that does), this other variable is likely to be at the same memory location as lcdchar, and so lcdchar is overwritten. Erik -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] SDCC port of STM8 Standard Peripheral Library
On Thu, 22 Jan 2015, Philipp Klaus Krause wrote: > On 21.01.2015 19:36, Georg Icking-Konert wrote: >> >> 1) how do I declare and implement the trap handler? According >> to http://sourceforge.net/p/sdcc/patches/224/ the keyword "__trap? is >> available via patch (2014-02-22). Is this already part of 3.4.0 (#8981; >> 2014-04-5) and, if yes, how do I use it? If not, is it planned for the >> next release which is due when? >> > > The patch has not been applied yet. It adds a new keyword, and I don't > feel familiar enough with all the backends at the moment do decide on > this. Maybe when looking at all the backends, there is a better way to > do it instead. If this is an important feature to stm8 users, I can > apply the patch (so it would be in the next release; if we come up with > a better way later, we can still change the syntax then). > > Philipp The patch seems reasonably safe to me. The __trap keyword would only be active for the stm8 backend. However, it would be similar to the __interrupt keyword in that it is expected to follow the function name rather than precede it; I don't know if that would be a problem or not. Erik -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] SDCC port of STM8 Standard Peripheral Library
On Mon, 26 Jan 2015, Georg Icking-Konert wrote: On Thu, 22 Jan 2015, Philipp Klaus Krause wrote: On 21.01.2015 19:36, Georg Icking-Konert wrote: 1) how do I declare and implement the trap handler? According to http://sourceforge.net/p/sdcc/patches/224/ the keyword "__trap? is available via patch (2014-02-22). Is this already part of 3.4.0 (#8981; 2014-04-5) and, if yes, how do I use it? If not, is it planned for the next release which is due when? The patch has not been applied yet. It adds a new keyword, and I don't feel familiar enough with all the backends at the moment do decide on this. Maybe when looking at all the backends, there is a better way to do it instead. If this is an important feature to stm8 users, I can apply the patch (so it would be in the next release; if we come up with a better way later, we can still change the syntax then). Philipp The patch seems reasonably safe to me. The __trap keyword would only be active for the stm8 backend. However, it would be similar to the __interrupt keyword in that it is expected to follow the function name rather than precede it; I don't know if that would be a problem or not. Erik Hi Eric, thanks for your assessment of the patch for __trap on STM8. However, if I understand correctly, you mean that it’s safe for me to apply the path…!? The target of my porting is to make the STM8-SPL available for the SDCC community. So, unless this becomes a standard feature in an official release, I probably won’t use it. Anyway, thanks for the reply! As for the "indicator before vs. after“ function name, this is indeed an annoying issue. Please see my other post on this… Georg Georg, I apologize for the ambiguity in my previous message; I was mainly trying to reassure Philipp about the patch with respect to the non-stm8 backends. I realize that what you are trying to accomplish probably will require some modification to SDCC mainline to conform to the expected syntax. Erik -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] SDCC preprocessor issue
On Mon, 26 Jan 2015, Georg Icking-Konert wrote: hello all, as mentioned elsewhere I am trying to port the STM8-SPL library by STM to SDCC. Currently I got stuck at a seemingly simple problem. Here’s the technical background: 1) my target is to modify only the common headers, not the project specific header 2) all other supported compilers (Cosmic, IAR, Resonance) declare interrupt routines with the keyword BEFORE the function, e.g. “__interrupt void ISR(void);" Are you sure? The Raisonance C compiler for ST7/STM8 appears to expect the interrupt or trap keywords to follow the function parameters, like SDCC. See pages 43-44 here: ftp://raisonance.com/pub/Support/RKit-STM8/RCSTM8.pdf You might also want to double check that you have the current version of the STM8-SPL. From the link you provided, I downloaded STSW-STM8069 version 2.2.0. It appears to provide compiler specific implementations of a macro named INTERRUPT_HANDLER that takes two parameters: a function name and a vector number. The macro forms a function declaration with interrupt keyword either at the beginning or end of the declartion, as appropriate for the detected compiler. Erik -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] SDCC preprocessor issue
On Fri, 30 Jan 2015, Georg Icking-Konert wrote: hello all, thanks a lot for your feedback! As for your mails see my comments below You forgot the option to modify SDCC so it accepts the __interrupt keyword either before or after the function :) w I figured that is not really an option - is it??? I did try this earlier in the week, but it leads to a number of ambiguities in the grammar. The main problem seems to be that a function can return a function pointer, so if the interrupt keyword can be either before or after the function name/parameters it's unclear whether the interrupt should be applied to the returned function pointer or the function itself. Of course semantically it makes no sense for an interrupt function to have any return type but void, but it is not easy to resolve this as the parsing stage. sorry I probably haven’t made myself clear. The macro INTERRUPT_HANDLER you mention is used for the implementation and works just fine with SDCC. I was referring to the macro INTERRUPT (a few lines below) which is only used for declaration in the ISR header file (see stm8s_it.h). Maybe in the end I have to do the same as for Raisonance, which simply skips the declaration: not nice but works Okay, I see what you are talking about now. I don't think the declaration of the functions as interrupt handlers without specifying a vector number in the ISR header file would do anything useful for SDCC. Following the same path as for Raisonance seems the most compatible with SDCC's existing grammar and interrupt function expectations. Erik -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] SDCC preprocessor issue
On Sat, 7 Feb 2015, Georg Icking-Konert wrote: > hi Maarten, hi Erik, > > thanks a lot by your feedback! Below I got 2 contradicting opinions: if I > understand Erik right, there is no easy fix to this problem and I should > just skip the declaration in the interrupt header file (like for > Raisonance). That will do of course, but it would prohibit 100% > compatibility with the examples and libs provided by STM on their homepage. > So, before I go for this option: Maarten, can you confirm or reject Eriks > statement (in contrast to first gut feeling), i.e. this won?t be supported by > SDCC anytime soon? For your feedback thanks a lot in advance! > > Georg The problems with the ambiguity are not insurmountable. There are other places in the C language with ambiguity in the parsing. The most obvious is how "else" gets associated with "if": if (condition1) if (condition2) statement1; else statement2; >From a grammar standpoint, the else could be associated with either "if (condition1)" or "if (condition2)". The C language specifies that it should be associated with "if (condition2)" and (hopefully) everyone who programs in C knows and expects this. Changing the grammar to support the function attributes either before or after the function name and parameters, is fairly simple, but caused bison (the parsar generator) to see roughly 30 new shift/reduce conflicts (grammar ambiguities). I also tried just the interrupt attribute rather than all of the function attributes; this still added 2 new shift/reduce conflicts. In the past SDCC has had a number of bugs related to properly handling function pointer types. So I am hesitant to commit a change to the grammar that increases the ambiguities in this area without having a really clear understanding of the result. This proposed change has, at least for me, moved beyond a quick and simple change to something that would require more study before I would feel comfortable. I can't speak for the other developer's priorities, but this would be low priority for me; I have only spent the time that I have on it because it initially seemed a simple and straightforward change. Erik -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] z80 binary sizes increasing by 25%
On Sat, 30 Jul 2016, alvin albrecht wrote: Sometime after #9676 and up to and including #9682, I am seeing an increase in z80 binary sizes of 25% in some compiles. It seems to be connected to increase spill to the stack and higher use of index registers in accessing stack variables. I will try to look closer to nail down what it is but I am wondering if anyone else is seeing this. I can give a link to before and after list files showing asm generated by #9676 vs #9692 for a particular case of a binary increasing from 39k to 51k. https://drive.google.com/file/d/0B6XhJJ33xpOWLTJRTkgxRzNXQ2s/view?usp=shari ng Yes, I can reproduce this. It appears to be revision #9682 (the patch associated with bug #2467) where the spill location use increases. Erik -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] z80 binary sizes increasing by 25%
On Sat, 30 Jul 2016, Philipp Klaus Krause wrote:
> On 30.07.2016 10:02, Erik Petrich wrote:
>>
>>
>> On Sat, 30 Jul 2016, alvin albrecht wrote:
>>
>>>
>>>
>>> Sometime after #9676 and up to and including #9682, I am seeing an
>>> increase
>>> in z80 binary sizes of 25% in some compiles. It seems to be connected to
>>> increase spill to the stack and higher use of index registers in
>>> accessing
>>> stack variables. I will try to look closer to nail down what it is
>>> but I am
>>> wondering if anyone else is seeing this.
>>>
>>>
>>> I can give a link to before and after list files showing asm generated by
>>> #9676 vs #9692 for a particular case of a binary increasing from 39k
>>> to 51k.
>>>
>>> https://drive.google.com/file/d/0B6XhJJ33xpOWLTJRTkgxRzNXQ2s/view?usp=shari
>>>
>>> ng
>>
>> Yes, I can reproduce this. It appears to be revision #9682 (the patch
>> associated with bug #2467) where the spill location use increases.
>>
>> Erik
>
> Do we have a resonably small, self-contained C code example to reproduce
> this?
>
> Philipp
This is what I was looking at (adapted from near the beginning of Alvin's
example):
float RND0(void)
{
return 0;
}
float RND(float n)
{
return (n == 0.0) ? RND0() : RND0()*n+1.0;
}
The code for RND0() is just trivial filler and nothing unexpected happens
there, but RND() suddenly uses a sloc instead of registers in revision
#9682.
Erik
--
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Can't link a simple example using PIC16 with SDCC : ASlink no definition of area errors
On Fri, 16 Dec 2016, Délisson Gonçalves wrote:
I'm currently trying to use SDCC to generate an Intel Hex file for a PIC16
device (pic18f452). I'm using a Makefile and multiple source files, to be
compiled separately and linked at the end. This is my Makefile setup:
CFLAGS=--std-c99 --use-non-free -mpic16
LDFLAGS=--out-fmt-ihx
build/image.hex: build/main.rel build/lcd.rel
sdcc -o build/image.hex $^
build/main.rel: main.c lcd.h
sdcc $(CFLAGS) -c $< -o $@
build/lcd.rel: lcd.c lcd.h
sdcc $(CFLAGS) -c $< -o $@
The source files are as simple as it gets:
lcd.h:
#ifndef _LCD_H_
#define _LCD_H_
void lcd_init(void);
#endif
lcd.c:
#include
#include "lcd.h"
void lcd_init(void) {
PORTEbits.RE1 = 0;
PORTEbits.RE2 = 0;
}
main.c:
#include
#include "lcd.h"
void main() {
lcd_init();
while (1);
}
Running make gives me the following (warnings?) errors, from the linking
stage:
ASlink-Warning-No definition of area HOME
ASlink-Warning-No definition of area XSEG
ASlink-Warning-No definition of area PSEG
And I don't get my output. If I concatenate all my code into one file
and run sdcc on it, however, it works:
$ cat lcd.h lcd.c main.c > monster.c
$ sdcc --use-non-free -mpic16 monster.c
message: Using default linker script "/usr/share/gputils/lkr/18f452_g.lkr".
$ ls
lcd.c lcd.h main.c Makefile monster.asm monster.c monster.cod
monster.hex monster.lst monster.o
Is there some other setup I should be doing, or flag I should be passing?
I'm not really using any ASM code or defining my own areas, and expected it
to work out-of-the-box with C. Are my assumptions wrong?
Sorry for the long message, hope to hear soon
Thanks in advance,
Délisson J. G. Silva
The compiler uses different assembler/linkers depending on the target
microcontroller. You need to also include -mpic16 when linking so that
sdcc knows to invoke gplink instead of aslink. This is why it was
successful for monster.c but not when linking separately from compiling.
Erik--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] OS X change preprocessor
On Fri, 30 Jun 2017, Maxwell Leiter via Sdcc-user wrote: Hi,On OS X, Apple has decided to symlink `gcc` to `clang` (and all related tools to their clang equivalents). So, I need to use `gcc-7` specifically to use `gcc`. Is there a way to pass options to sdcc to use `gcc-7` instead of `gcc`? Specifically, it uses `cpp` in SDCCmain.c If you are just using SDCC, rather than trying to build it, you probably don't need to do anything at all. The references in SDCCmain.c to cpp will ultimately call an executable named "sdcpp" which is SDCC's customized version of gcc's preprocessor rather than use the system's generic C preprocessor. Erik -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] How to deal bytewise with 24-bit symbols in asxxxx?
On Thu, 29 Mar 2018, Philipp Klaus Krause wrote: Full support for function pointers would need: 1) A way to get individual bytes of 24-bit symbols 2) A way to get the upper 16 bits of 24-bit symbols Philipp If that is true, then the ds390 target is totally broken and the huge model for mcs51 is broken as well. I'm sure this used to work. ISTR that the assembler has support for every odd kind of number of bits per address word, including 24 bit. Is the address size maybe set up incorrectly? Maarten I had also tested with ds390, and it seemed to work there. Maybe there is some functionality in the ds390 assembler that would have to be ported to the stm8 one. Philipp I have enabled the assembler to emit 24-bit addresses in the relocation records for stm8 like it does for ds390 and mcs51 (even though mcs51 is only using 16-bit addresses). So this should allow you to reference the individual bytes of the 24-bit address. However, I think additional work will still be needed to reference the upper 16 bits of a 24-bit address. Erik -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Anyone using --oldralloc when compiling for z80, z180, r2k, r3ka or ez80_z80?
On Sat, 15 Jun 2019, Philipp Klaus Krause wrote: Is anyone still using the old register allocator for a z80-related backend? If not, we could just remove it. Philipp I believe the 8bitworkshop IDE, which integrates an editor, several toolchains (including SDCC), and several emulators into a platform independent environment inside a web browser uses the old register allocator for performance reasons. What is the cost of keeping --oldralloc around? Erik ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
[Sdcc-user] SDCC 4.1.0 release candidate 1
The first release candidate (RC1) for SDCC 4.1.0 is available in our SourceForge File release system: https://sourceforge.net/projects/sdcc/files/ In addition to the source package, binaries are available for 32- and 64-bit Windows, 64-bit macOS, and x86_64 GNU/Linux. If you have time, please verify it and report your positive or neative results. In addition to various bug fixes, notable features added since the 4.0.0 release are: * New z80n port for the Spectrum Next CPU (a Z80 variant). * Much better register allocation in the gbz80 backend. * Workarounds for Rabbit wait state bugs in the r2k backend * New r2ka port to better support Rabbit 2000A, 2000B, 2000C, 3000. * Default crt0 and --data-loc for Rabbits suitable for typical Rabbit hardware configurations, such as the RCMs. * Many improvements in code generation for z80 and related ports. * Rabbit register definition headers for Rabbit 2000, 2000A, 2000B, 2000C, 3000, 3000A. * C23 digit separators. A full list of changes can be found in the ChangeLog: https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-4.1.0-rc1/sdcc/ChangeLog ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
[Sdcc-user] SDCC 4.1.0 release
The official release for SDCC 4.1.0 is available in our SourceForge File release system: https://sourceforge.net/projects/sdcc/files/ In addition to the source package, binaries are available for 32- and 64-bit Windows, 64-bit macOS, and x86_64 GNU/Linux. In addition to various bug fixes, notable features added since the 4.0.0 release are: * New z80n port for the Spectrum Next CPU (a Z80 variant). * Much better register allocation in the gbz80 backend. * Workarounds for Rabbit wait state bugs in the r2k backend * New r2ka port to better support Rabbit 2000A, 2000B, 2000C, 3000. * Default crt0 and --data-loc for Rabbits suitable for typical Rabbit hardware configurations, such as the RCMs. * Many improvements in code generation for z80 and related ports. * Rabbit register definition headers for Rabbit 2000, 2000A, 2000B, 2000C, 3000, 3000A. * C23 digit separators. A full list of changes can be found in the ChangeLog: https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-4.1.0/sdcc/ChangeLog ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] bug
On Mon, 11 Dec 2006, Greg Mann wrote: > I am beyond myself tring to find the problem with the attached code. > It is giving me a error on a ";". I have been able to get this code > to run on other demo compiler. If anyone could find the problem it > would make me very happy. > > Greg Mann SDCC wants an explicit return type. Use int reflect(unsigned int ch); instead of just reflect(unsigned int ch); Erik - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Pointer Increment - Is it a bug?
On Thu, 4 Jan 2007, Mr.Cashe wrote: > But I have found this draft: > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf > > Page 59, $6.3.2.3.1 says: "A pointer to void may be converted to or from a > pointer to any incomplete or object type. A pointer to any incomplete or > object type may be converted to a pointer to void and back again; the result > shall compare equal to the original pointer" This just means that after this code: void * p1; char * p2; void * p3; p2 = p1; p3 = p2; that p3 == p1 is always true. > Page 48, $6.2.5.26 says: "A pointer to void shall have the same > representation > and alignment requirements as a pointer to a character type (*The same > representation and alignment requirements are meant to imply > interchangebility as arguments to functions, return values from functions, > and members of unions)" This means that in the above code p1, p2, and p3 would also have an identical pattern of bits. It does not imply that any arithmetic applied to them would give identical results. > Is it still meant the increment code in my first post may not work? What are > you think about? Take a look at question 11.24 "Why can't I perform arithmetic on a void * pointer" in the C FAQ (available at http://c-faq.com among other places). There you can find further citations to specific subclauses of the C standard that define this behaviour. It worked as you expected with GCC because GCC treats this case as a special extension. From the current (4.1.1) GCC manual: 5.17 Arithmetic on void- and Function-Pointers In GNU C, addition and subtraction operations are supported on pointers to void and on pointers to functions. This is done by treating the size of a void or of a function as 1. A consequence of this is that sizeof is also allowed on void and on function types, and returns 1. The option `-Wpointer-arith' requests a warning if these extensions are used. Of course, the drawback to using an extension is that your code becomes less portable. Erik - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] passing pointer of struct to function
On Sat, 14 Apr 2007, Dheya Ghazi Mustafa wrote: > Hi, > I am trying to pass a pointer of struct to function. > I received the following error. > > C:/plansw_006_doc/CoordinateMapper.c:59: > error 52: Actual Argument type different from declaration 1 from type 'struct > piccolodatastruct generic* ' to type 'struct piccolodatastruct generic* ' You may need to add the statement: struct piccolodatastruct; before your function definition or prototype. See the comp.lang.c FAQ Question 11.5 for details: http://c-faq.com/ansi/structinproto.html Erik - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Sdcc-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sdcc-user
