You can subscribe to this list here.
2000 |
Jan
(1) |
Feb
(56) |
Mar
(65) |
Apr
(18) |
May
(40) |
Jun
(12) |
Jul
(18) |
Aug
(19) |
Sep
(164) |
Oct
(86) |
Nov
(67) |
Dec
(29) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(96) |
Feb
(176) |
Mar
(119) |
Apr
(59) |
May
(181) |
Jun
(193) |
Jul
(140) |
Aug
(180) |
Sep
(182) |
Oct
(322) |
Nov
(263) |
Dec
(187) |
2002 |
Jan
(130) |
Feb
(83) |
Mar
(106) |
Apr
(28) |
May
(39) |
Jun
(46) |
Jul
(78) |
Aug
(107) |
Sep
(66) |
Oct
(33) |
Nov
(58) |
Dec
(53) |
2003 |
Jan
(197) |
Feb
(261) |
Mar
(282) |
Apr
(242) |
May
(218) |
Jun
(107) |
Jul
(108) |
Aug
(78) |
Sep
(129) |
Oct
(181) |
Nov
(139) |
Dec
(108) |
2004 |
Jan
(224) |
Feb
(185) |
Mar
(115) |
Apr
(102) |
May
(98) |
Jun
(103) |
Jul
(124) |
Aug
(88) |
Sep
(124) |
Oct
(100) |
Nov
(74) |
Dec
(79) |
2005 |
Jan
(66) |
Feb
(83) |
Mar
(123) |
Apr
(53) |
May
(109) |
Jun
(46) |
Jul
(126) |
Aug
(78) |
Sep
(61) |
Oct
(43) |
Nov
(213) |
Dec
(93) |
2006 |
Jan
(63) |
Feb
(109) |
Mar
(79) |
Apr
(185) |
May
(283) |
Jun
(179) |
Jul
(147) |
Aug
(156) |
Sep
(114) |
Oct
(173) |
Nov
(137) |
Dec
(148) |
2007 |
Jan
(154) |
Feb
(108) |
Mar
(132) |
Apr
(151) |
May
(241) |
Jun
(94) |
Jul
(109) |
Aug
(50) |
Sep
(62) |
Oct
(128) |
Nov
(90) |
Dec
(74) |
2008 |
Jan
(53) |
Feb
(161) |
Mar
(261) |
Apr
(53) |
May
(87) |
Jun
(44) |
Jul
(73) |
Aug
(67) |
Sep
(54) |
Oct
(37) |
Nov
(72) |
Dec
(53) |
2009 |
Jan
(51) |
Feb
(73) |
Mar
(84) |
Apr
(67) |
May
(59) |
Jun
(31) |
Jul
(78) |
Aug
(45) |
Sep
(90) |
Oct
(56) |
Nov
(69) |
Dec
(51) |
2010 |
Jan
(188) |
Feb
(73) |
Mar
(20) |
Apr
(46) |
May
(91) |
Jun
(24) |
Jul
(115) |
Aug
(135) |
Sep
(132) |
Oct
(90) |
Nov
(92) |
Dec
(58) |
2011 |
Jan
(121) |
Feb
(90) |
Mar
(56) |
Apr
(79) |
May
(98) |
Jun
(109) |
Jul
(104) |
Aug
(113) |
Sep
(234) |
Oct
(143) |
Nov
(160) |
Dec
(93) |
2012 |
Jan
(162) |
Feb
(160) |
Mar
(219) |
Apr
(186) |
May
(135) |
Jun
(360) |
Jul
(138) |
Aug
(72) |
Sep
(130) |
Oct
(146) |
Nov
(64) |
Dec
(137) |
2013 |
Jan
(65) |
Feb
(18) |
Mar
(35) |
Apr
(26) |
May
(108) |
Jun
(34) |
Jul
(16) |
Aug
(11) |
Sep
(61) |
Oct
(4) |
Nov
(23) |
Dec
(24) |
2014 |
Jan
(56) |
Feb
(58) |
Mar
(54) |
Apr
(26) |
May
(3) |
Jun
(31) |
Jul
(13) |
Aug
(13) |
Sep
(7) |
Oct
(26) |
Nov
(65) |
Dec
(54) |
2015 |
Jan
(64) |
Feb
(15) |
Mar
(25) |
Apr
(41) |
May
(22) |
Jun
(62) |
Jul
(26) |
Aug
(17) |
Sep
(35) |
Oct
(33) |
Nov
(37) |
Dec
(17) |
2016 |
Jan
(39) |
Feb
(12) |
Mar
(15) |
Apr
(13) |
May
(41) |
Jun
(76) |
Jul
(53) |
Aug
(38) |
Sep
(31) |
Oct
(11) |
Nov
(9) |
Dec
(19) |
2017 |
Jan
(11) |
Feb
(19) |
Mar
|
Apr
(28) |
May
(61) |
Jun
(9) |
Jul
(9) |
Aug
(14) |
Sep
|
Oct
(63) |
Nov
(43) |
Dec
(21) |
2018 |
Jan
(24) |
Feb
(46) |
Mar
(38) |
Apr
(6) |
May
(14) |
Jun
(10) |
Jul
(12) |
Aug
(12) |
Sep
(29) |
Oct
(9) |
Nov
(17) |
Dec
(22) |
2019 |
Jan
(20) |
Feb
(22) |
Mar
(22) |
Apr
(10) |
May
(2) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
(5) |
Oct
(13) |
Nov
(8) |
Dec
(11) |
2020 |
Jan
(23) |
Feb
(14) |
Mar
(2) |
Apr
(11) |
May
(14) |
Jun
(48) |
Jul
(111) |
Aug
(26) |
Sep
(6) |
Oct
(22) |
Nov
(7) |
Dec
(26) |
2021 |
Jan
(4) |
Feb
(40) |
Mar
(64) |
Apr
(46) |
May
(18) |
Jun
(20) |
Jul
(11) |
Aug
(40) |
Sep
(16) |
Oct
(15) |
Nov
(46) |
Dec
(10) |
2022 |
Jan
(60) |
Feb
(163) |
Mar
(117) |
Apr
(8) |
May
(22) |
Jun
(13) |
Jul
(5) |
Aug
(1) |
Sep
(20) |
Oct
(4) |
Nov
(13) |
Dec
(16) |
2023 |
Jan
(45) |
Feb
(5) |
Mar
(1) |
Apr
(7) |
May
(128) |
Jun
(41) |
Jul
(40) |
Aug
(52) |
Sep
(20) |
Oct
(18) |
Nov
(40) |
Dec
(52) |
2024 |
Jan
(19) |
Feb
(5) |
Mar
(6) |
Apr
(18) |
May
(5) |
Jun
(20) |
Jul
(58) |
Aug
(16) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
From: <no...@so...> - 2001-11-04 03:16:19
|
Bugs item #477927, was opened at 2001-11-03 19:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100599&aid=477927&group_id=599 Category: C-Front End Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hope (michaelh) Assigned to: Nobody/Anonymous (nobody) Summary: Un-inited variables in while loops Initial Comment: See the regression tests under this bug number. Basically in: int a; do { b = fun(); if (something on b) { a = ++array[b]; } } while (a != 123) a is not initalised in all paths to the while conditional, but sdcc doesn't throw a warning. What's really funky is that as 'a' is not inited before entering the while, 'a' only lives while in the do loop, and it can take on a random value depending on what other iTemps it shares registers with, causing the while condition to fail unpredictibly. I don't know what the fix should be or if it should be fixed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100599&aid=477927&group_id=599 |
From: Sandeep D. <sa...@wi...> - 2001-11-04 01:27:17
|
Folks I'm now the proud owner of a TINI board. My first contribution to the ds390 port. The compiler will now generate code for the Arithmetic Accelerator unit.. i.e. 16 bit by 16 bit multiplication , division & remainder operations will now generate inline code.... This can be disabled by setting the port->muldiv = 1 (currently set to 2 ). Now for the other thoughts .. while implementing the accelerator code I desperately wanted a debugger.. I have some ideas want to pass it by you folks... a simple debugger can be made by enhancing the boot loader.. (Dallas has been kind enough the provide the source code)..... e.g. add a command like "br <hex-address>"... the loader will then read the contents of the location into a "loader internal" location and patch the location with a branch to a "debug" entry point in the loader... when the code reaches the point .. it will branch back to the loader.. the loader then patches back the old values (it saved).. displays register contents etc etc .. and waits for more commands ..... I have to work up some more courage before I try to ZAP BANK 0 ...:) Having FUN!!! Sandeep |
From: Johan K. <joh...@id...> - 2001-11-03 18:52:16
|
There is still something wrong with this funptrs.c, I am working on it. So don't spend to much time on this yet, although this info seems usefull. Johan > I notice that we now seem to automatically pull function parameters into > local registers if they are used. For example, in tests/funptr.c: > > void > callViaPtr(NOARGFUNPTR fptr) > { > (*fptr)(); > } > > turns into: > ld hl,sp+2 > ld bc,(hl) > > ld hl,bc > call (hl) > > Is this intended? It seems a bit inefficient to me, especially if it is > only used once. On the z80/gbz80 the cost of bringing something into > registers is the same as the cost of using it directly, making the above > code slower than the alternative: > > ld hl,sp+2 > ld hl,(hl) > call (hl) > > It's worse in dumb code like this: > > void > testAdd(int a) > { > a++; > spoil(a); > } > > This turns into: > ld hl,sp+2 > ld bc,(hl) > inc bc > ld (hl),bc > push bc > call _spoil > > Instead of: > ld hl,sp+2 > inc (hl) > push (hl) > call _spoil > > It also exposed a bug in the z80 port - it seems that the registers used > for the function pointer aren't actually marked as used, causing the > caller not to save them, causing them to be corrupted. > > - -- Michael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (OpenBSD) > Comment: For info see http://www.gnupg.org > > iEYEARECAAYFAjvkKrgACgkQ3L3H1ImjCiQqgACeIVbrhdWEp1kcRirWOC6cscvC > c+EAn0it/lbOkEC/o85xLKdL9FF/nJyU > =gfIz > -----END PGP SIGNATURE----- > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: <no...@so...> - 2001-11-03 18:15:06
|
Bugs item #477835, was opened at 2001-11-03 10:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100599&aid=477835&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hope (michaelh) Assigned to: Nobody/Anonymous (nobody) Summary: Regs used in a pcall are not saved Initial Comment: This code: void fptr(void (*fp)(void)) { int i; for (i = 0; i < 50; i++) (*fp)(); } fails as the registers assigned to the local copy of fp are not saved across the call. Visible on the z80 and mcs51 stack based ports. I'm looking into the z80 port. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100599&aid=477835&group_id=599 |
From: Michael H. <mic...@ju...> - 2001-11-03 17:34:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I notice that we now seem to automatically pull function parameters into local registers if they are used. For example, in tests/funptr.c: void callViaPtr(NOARGFUNPTR fptr) { (*fptr)(); } turns into: ld hl,sp+2 ld bc,(hl) ld hl,bc call (hl) Is this intended? It seems a bit inefficient to me, especially if it is only used once. On the z80/gbz80 the cost of bringing something into registers is the same as the cost of using it directly, making the above code slower than the alternative: ld hl,sp+2 ld hl,(hl) call (hl) It's worse in dumb code like this: void testAdd(int a) { a++; spoil(a); } This turns into: ld hl,sp+2 ld bc,(hl) inc bc ld (hl),bc push bc call _spoil Instead of: ld hl,sp+2 inc (hl) push (hl) call _spoil It also exposed a bug in the z80 port - it seems that the registers used for the function pointer aren't actually marked as used, causing the caller not to save them, causing them to be corrupted. - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (OpenBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjvkKrgACgkQ3L3H1ImjCiQqgACeIVbrhdWEp1kcRirWOC6cscvC c+EAn0it/lbOkEC/o85xLKdL9FF/nJyU =gfIz -----END PGP SIGNATURE----- |
From: Johan K. <joh...@id...> - 2001-11-03 10:31:27
|
fixed in mcs51/gen.c Where for the mult expression "iTemp38(int) = iTem32(char) * iTemp37(char)" both right and result shared the same sloc. Now because result made the aop size 2, genMult() didn't call genMultOneByte() but did an assert(1) which went unnoticed. Now the symbol size is used to make the decision. This makes sense for other ports as well. Johan ----- Original Message ----- From: <no...@so...> To: <no...@so...> Sent: Sunday, October 14, 2001 6:58 PM Subject: [sdcc-devel] [ sdcc-Bugs-471059 ] mul ab missing > Bugs item #471059, was opened at 2001-10-14 10:58 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=100599&aid=471059&group_id= 599 > > Category: msc51(8051) target > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Bernhard Held (bernhardheld) > Assigned to: Nobody/Anonymous (nobody) > Summary: mul ab missing > > Initial Comment: > This is a quite old bug, which was well hidden in the > library. Once I've promised to write a consistent bug > report, so here it is: > > union bil { > struct {unsigned char b0,b1,b2 ;} b; > } ; > > #define bcast(x) ((union bil near *)&(x)) > > unsigned char > _mullong (unsigned long a, unsigned long b) reentrant > { > union bil t; > > t.b.b1 += bcast(a)->b.b1 * bcast(b)->b.b0; > // next line: mul ab missing (optimized away?) > t.b.b1 += bcast(a)->b.b2 * bcast(b)->b.b1; > t.b.b1 += bcast(a)->b.b2 * bcast(b)->b.b0; > t.b.b1 += bcast(a)->b.b1 * bcast(b)->b.b1; > return t.b.b0; > } > > This is a stripped down version of the original > library file _mullong.c. Here the bug can be > reproduced with: > > sdcc -S _mullong.c --stack-auto -D_SDCC_NO_ASM_LIB_FUNCS > > In the assembler file are only 9 "mul ab" instead of > 10. > > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=100599&aid=471059&group_id= 599 > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Michael H. <mic...@us...> - 2001-11-03 09:24:26
|
Summary for 'host': 0 failures, 2257 tests, 453 test cases Summary for 'z80': 0 failures, 2257 tests, 454 test cases Summary for 'gbz80': 0 failures, 2257 tests, 454 test cases gen/mcs51/funptrs/funptrs.out:3:--- FAIL: "Assertion failed" on count == 8 at gen/mcs51/funptrs/funptrs.c:50 Summary for 'mcs51': 1 failures, 2257 tests, 450 test cases |
From: Michael H. <mic...@us...> - 2001-11-03 08:12:38
|
Summary for 'host': 0 failures, 2257 tests, 453 test cases Summary for 'z80': 0 failures, 2257 tests, 454 test cases Summary for 'gbz80': 0 failures, 2257 tests, 454 test cases gen/mcs51/funptrs/funptrs.out:3:--- FAIL: "Assertion failed" on count == 8 at gen/mcs51/funptrs/funptrs.c:50 Summary for 'mcs51': 1 failures, 2257 tests, 450 test cases |
From: Johan K. <joh...@id...> - 2001-11-02 15:35:25
|
but is probably never intended to be just that, so I boldly replaced all occurrences to assert(0). If it breaks something, you know who to blame. CVS: Modified Files: CVS: SDCCicode.c avr/gen.c ds390/gen.c mcs51/gen.c pic/gen.c (this came up out of bug #471059) Johan |
From: Johan K. <joh...@id...> - 2001-11-02 14:54:09
|
Ok. ----- Original Message ----- From: Sandeep Dutta <sa...@wi...> To: 'Johan Knol' <joh...@id...>; <sdc...@li...> Sent: Friday, November 02, 2001 3:48 PM Subject: RE: [sdcc-devel] --xstack obsolete > No Absolutely not .. for ds390 yes, for > mcs51 I still plan to fix it up. > Sandeep > > > -----Original Message----- > > From: sdc...@li... > > [mailto:sdc...@li...]On Behalf Of Johan Knol > > Sent: Friday, November 02, 2001 5:56 AM > > To: sdc...@li... > > Subject: [sdcc-devel] --xstack obsolete > > > > > > Are we all agreed on that? > > > > Johan > > > > > > _______________________________________________ > > sdcc-devel mailing list > > sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > > > > |
From: Sandeep D. <sa...@wi...> - 2001-11-02 14:49:23
|
No Absolutely not .. for ds390 yes, for mcs51 I still plan to fix it up. Sandeep > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On Behalf Of Johan Knol > Sent: Friday, November 02, 2001 5:56 AM > To: sdc...@li... > Subject: [sdcc-devel] --xstack obsolete > > > Are we all agreed on that? > > Johan > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > |
From: Johan K. <joh...@id...> - 2001-11-02 13:56:30
|
Are we all agreed on that? Johan |
From: Johan K. <joh...@id...> - 2001-11-02 12:02:55
|
fixed in SDCCast.c:1.104 ----- Original Message ----- From: <no...@so...> To: <no...@so...> Sent: Friday, November 02, 2001 8:08 AM Subject: [sdcc-devel] [ sdcc-Bugs-477397 ] Bad code generated for struct offsets > Bugs item #477397, was opened at 2001-11-01 23:08 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=100599&aid=477397&group_id= 599 > > Category: msc51(8051) target > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Alex Karahalios (karahalios) > Assigned to: Nobody/Anonymous (nobody) > Summary: Bad code generated for struct offsets > > Initial Comment: > For SDCC : mcs51/gbz80/z80/avr/ds390/pic14/i186/tlcs900h 2.3.1 (10/17/01) (UNIX) > > The following program generates bad code: > > typedef struct _STRUCT_ { > unsigned char SRC[100]; > int FRAMETYPE; > } STRUCT; > xdata at 0x4000 unsigned char someData[]; > extern void func(unsigned char *p); > #define offsetof(type, member) ((unsigned int)(&((type *)0)->member)) > > void main(void) { > func(&someData[offsetof(STRUCT,SRC)]); > func(&someData[offsetof(STRUCT,FRAMETYPE)]); > } > > Notice that the first address calculation for the "func" call is correct, while the second one generates bad code: > ; bug.c 10 > mov r2,#_someData > mov r3,#(_someData >> 8) > mov r4,#0x01 > mov dpl,r2 > mov dph,r3 > mov b,r4 > lcall _func > ; bug.c 11 > ; Peephole 181 used 16 bit load of dptr > mov dptr,#0x0000 > mov b,#0x64 > lcall __gptrget > mov r2,a > mov r3,#0x00 > mov a,r2 > add a,#_someData > mov r2,a > mov a,r3 > addc a,#(_someData >> 8) > mov r3,a > mov r4,#0x01 > mov dpl,r2 > mov dph,r3 > mov b,r4 > lcall _func > > The first function call correctly loads r2,r3 & r4. The second function call should also just load r2, r3 & r4. It, however, decides to call __gptrget with an invalid argument for b (#0x64). This is the offset into the structure. Register b needs to be a 1. On return a is 0xFF which is then used as an offset into the structure. > > I've extracted this piece of code from some software I'm writing. Ideally the compiler should just load the constant offset of the structure into r2, r3 & r4. > > This problem manifests itself when the structure element is a char or int. With that knowledge the current workaround is to create a union of the int with an array: > > typedef union _INT_ { > int Int; > unsigned char x[2]; > } INT; > typedef struct _STRUCT_ { > unsigned char SRC[100]; > INT FRAMETYPE; > } STRUCT; > > This generates the correct code: > > ; bug.c 14 > mov r2,#_someData > mov r3,#(_someData >> 8) > mov r4,#0x01 > mov dpl,r2 > mov dph,r3 > mov b,r4 > lcall _func > ; bug.c 15 > mov r2,#(_someData + 0x0064) > mov r3,#((_someData + 0x0064) >> 8) > mov r4,#0x01 > mov dpl,r2 > mov dph,r3 > mov b,r4 > lcall _func > > Thanks, > > Alex Karahalios > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=100599&aid=477397&group_id= 599 > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Michael H. <mic...@us...> - 2001-11-02 09:24:16
|
cannot change permissions on temporary directory Operation not permitted make[2]: *** [stamps/gbdk-support.fetched] Error 1 Summary for 'host': 0 failures, 2257 tests, 453 test cases Summary for 'z80': 0 failures, 2257 tests, 454 test cases Summary for 'gbz80': 0 failures, 2257 tests, 454 test cases Summary for 'mcs51': 0 failures, 2257 tests, 450 test cases make[2]: Target `build' not remade because of errors. |
From: <no...@so...> - 2001-11-02 07:08:25
|
Bugs item #477397, was opened at 2001-11-01 23:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100599&aid=477397&group_id=599 Category: msc51(8051) target Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Karahalios (karahalios) Assigned to: Nobody/Anonymous (nobody) Summary: Bad code generated for struct offsets Initial Comment: For SDCC : mcs51/gbz80/z80/avr/ds390/pic14/i186/tlcs900h 2.3.1 (10/17/01) (UNIX) The following program generates bad code: typedef struct _STRUCT_ { unsigned char SRC[100]; int FRAMETYPE; } STRUCT; xdata at 0x4000 unsigned char someData[]; extern void func(unsigned char *p); #define offsetof(type, member) ((unsigned int)(&((type *)0)->member)) void main(void) { func(&someData[offsetof(STRUCT,SRC)]); func(&someData[offsetof(STRUCT,FRAMETYPE)]); } Notice that the first address calculation for the "func" call is correct, while the second one generates bad code: ; bug.c 10 mov r2,#_someData mov r3,#(_someData >> 8) mov r4,#0x01 mov dpl,r2 mov dph,r3 mov b,r4 lcall _func ; bug.c 11 ; Peephole 181 used 16 bit load of dptr mov dptr,#0x0000 mov b,#0x64 lcall __gptrget mov r2,a mov r3,#0x00 mov a,r2 add a,#_someData mov r2,a mov a,r3 addc a,#(_someData >> 8) mov r3,a mov r4,#0x01 mov dpl,r2 mov dph,r3 mov b,r4 lcall _func The first function call correctly loads r2,r3 & r4. The second function call should also just load r2, r3 & r4. It, however, decides to call __gptrget with an invalid argument for b (#0x64). This is the offset into the structure. Register b needs to be a 1. On return a is 0xFF which is then used as an offset into the structure. I've extracted this piece of code from some software I'm writing. Ideally the compiler should just load the constant offset of the structure into r2, r3 & r4. This problem manifests itself when the structure element is a char or int. With that knowledge the current workaround is to create a union of the int with an array: typedef union _INT_ { int Int; unsigned char x[2]; } INT; typedef struct _STRUCT_ { unsigned char SRC[100]; INT FRAMETYPE; } STRUCT; This generates the correct code: ; bug.c 14 mov r2,#_someData mov r3,#(_someData >> 8) mov r4,#0x01 mov dpl,r2 mov dph,r3 mov b,r4 lcall _func ; bug.c 15 mov r2,#(_someData + 0x0064) mov r3,#((_someData + 0x0064) >> 8) mov r4,#0x01 mov dpl,r2 mov dph,r3 mov b,r4 lcall _func Thanks, Alex Karahalios ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100599&aid=477397&group_id=599 |
From: Michael H. <mic...@ju...> - 2001-11-02 04:58:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've added runtime link path discovery to the mcs51 port, and have added the mcs51 port to the nightly regression tests. Here's hoping it works. - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (OpenBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjviJ/AACgkQ3L3H1ImjCiQmEgCgu78Eqb6i76Yy+D6fHnhbRshv sXMAn3Hb9KVUaoUaOw3bWxbUyTiWlnI3 =39uk -----END PGP SIGNATURE----- |
From: Johan K. <joh...@id...> - 2001-11-01 10:56:26
|
> gen/z80/funptrs/funptrs.c(28):error *** too few parameters > gen/z80/funptrs/funptrs.c(28):error *** code not generated for 'callViaPtr' due to previous errors This obviously wasn't fixed for the z80 port. I made a temporary fix in SDCCsymt.c:1.110 but I don't like this at all. The dumptree clearly shows that the symbol declaration of fptr is missing for the z80 port. Has something to do with regparms. So I reopened bug #476632 to have a closer look later. Johan |
From: Michael H. <mic...@us...> - 2001-11-01 09:18:55
|
gen.c: In function `gencjne': gen.c:3764: warning: unused variable `tlbl' Summary for 'host': 0 failures, 2257 tests, 453 test cases gen/z80/funptrs/funptrs.c(28):error *** too few parameters gen/z80/funptrs/funptrs.c(28):error *** code not generated for 'callViaPtr' due to previous errors gen/z80/funptrs/funptrs.c(34):error *** code not generated for 'callViaPtr2' due to previous errors gen/z80/funptrs/funptrs.c(40):error *** too few parameters gen/z80/funptrs/funptrs.c(40):error *** code not generated for 'callViaPtr3' due to previous errors gen/z80/funptrs/funptrs.c(50):error *** code not generated for 'testFunPtr' due to previous errors error *** code not generated for 'suite' due to previous errors error *** code not generated for 'getSuiteName' due to previous errors make[5]: *** [gen/z80/funptrs/funptrs.ihx] Error 1 make[5]: Target `iterations' not remade because of errors. make[4]: *** [results/z80/funptrs.out] Error 2 make[4]: Target `test-port' not remade because of errors. make[3]: *** [test-z80] Error 2 gen/gbz80/funptrs/funptrs.c(28):error *** too few parameters gen/gbz80/funptrs/funptrs.c(28):error *** code not generated for 'callViaPtr' due to previous errors gen/gbz80/funptrs/funptrs.c(34):error *** code not generated for 'callViaPtr2' due to previous errors gen/gbz80/funptrs/funptrs.c(40):error *** too few parameters gen/gbz80/funptrs/funptrs.c(40):error *** code not generated for 'callViaPtr3' due to previous errors gen/gbz80/funptrs/funptrs.c(50):error *** code not generated for 'testFunPtr' due to previous errors error *** code not generated for 'suite' due to previous errors error *** code not generated for 'getSuiteName' due to previous errors make[5]: *** [gen/gbz80/funptrs/funptrs.gb] Error 1 make[5]: Target `iterations' not remade because of errors. make[4]: *** [results/gbz80/funptrs.out] Error 2 make[4]: Target `test-port' not remade because of errors. make[3]: *** [test-gbz80] Error 2 make[2]: *** [sdcc-regression] Error 2 make[2]: Target `build' not remade because of errors. |
From: Michael H. <mic...@us...> - 2001-11-01 08:12:30
|
gen.c: In function `gencjne': gen.c:3764: warning: unused variable `tlbl' |
From: Michael H. <mic...@us...> - 2001-11-01 08:09:22
|
gen.c: In function `gencjne': gen.c:3764: warning: unused variable `tlbl' Summary for 'host': 0 failures, 2257 tests, 453 test cases gen/z80/funptrs/funptrs.c(28):error *** too few parameters gen/z80/funptrs/funptrs.c(28):error *** code not generated for 'callViaPtr' due to previous errors gen/z80/funptrs/funptrs.c(34):error *** code not generated for 'callViaPtr2' due to previous errors gen/z80/funptrs/funptrs.c(40):error *** too few parameters gen/z80/funptrs/funptrs.c(40):error *** code not generated for 'callViaPtr3' due to previous errors gen/z80/funptrs/funptrs.c(50):error *** code not generated for 'testFunPtr' due to previous errors error *** code not generated for 'suite' due to previous errors error *** code not generated for 'getSuiteName' due to previous errors make[5]: *** [gen/z80/funptrs/funptrs.ihx] Error 1 make[5]: Target `iterations' not remade because of errors. make[4]: *** [results/z80/funptrs.out] Error 2 make[4]: Target `test-port' not remade because of errors. make[3]: *** [test-z80] Error 2 gen/gbz80/funptrs/funptrs.c(28):error *** too few parameters gen/gbz80/funptrs/funptrs.c(28):error *** code not generated for 'callViaPtr' due to previous errors gen/gbz80/funptrs/funptrs.c(34):error *** code not generated for 'callViaPtr2' due to previous errors gen/gbz80/funptrs/funptrs.c(40):error *** too few parameters gen/gbz80/funptrs/funptrs.c(40):error *** code not generated for 'callViaPtr3' due to previous errors gen/gbz80/funptrs/funptrs.c(50):error *** code not generated for 'testFunPtr' due to previous errors error *** code not generated for 'suite' due to previous errors error *** code not generated for 'getSuiteName' due to previous errors make[5]: *** [gen/gbz80/funptrs/funptrs.gb] Error 1 make[5]: Target `iterations' not remade because of errors. make[4]: *** [results/gbz80/funptrs.out] Error 2 make[4]: Target `test-port' not remade because of errors. make[3]: *** [test-gbz80] Error 2 make[2]: *** [sdcc-regression] Error 2 make[2]: Target `build' not remade because of errors. |
From: Scott D. <sc...@da...> - 2001-10-31 22:11:13
|
On Wed, 31 Oct 2001, Sandeep Dutta wrote: > AHA!! that make sense .. in the example seemed like char2 is > defined in c2. In case it isn't obvious already, I strive to write obfuscating code. That's why I like PIC's so much :). Scott |
From: Sandeep D. <sa...@wi...> - 2001-10-31 21:38:01
|
AHA!! that make sense .. in the example seemed like char2 is defined in c2. Sandeep > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On Behalf Of Scott > Dattalo > Sent: Wednesday, October 31, 2001 1:27 PM > Cc: sdc...@li... > Subject: RE: [sdcc-devel] [ sdcc-Bugs-476678 ] Global scoping > is getting > lost > > > On Wed, 31 Oct 2001, Sandeep Dutta wrote: > > > Johan, > > > > I'm still confused .. why does char2 inside the loop have a > > global scope it has been declared in function ... > > void c1(void) > > > > { > > > > char2 = 9; > > Sandeep, > > "char2" is not declared in the scope of c1. It was declared > globally and > only assigned within c1. > > > > > > > > > > for(i=0;i<4;i++) { > > > > c2(); > > > > char1=char2; <<== should be 9 > > > > char0+=char1; > > > > > > > > } > > > > } > > > The problem here is that the function c2() changes the > contents of char2. > However, the function c1 is using its locale copy of char2 to add to > char1. > > Scott > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > |
From: Scott D. <sc...@da...> - 2001-10-31 21:26:56
|
On Wed, 31 Oct 2001, Sandeep Dutta wrote: > Johan, > > I'm still confused .. why does char2 inside the loop have a > global scope it has been declared in function ... > void c1(void) > > > { > > > char2 = 9; Sandeep, "char2" is not declared in the scope of c1. It was declared globally and only assigned within c1. > > > > > > for(i=0;i<4;i++) { > > > c2(); > > > char1=char2; <<== should be 9 > > > char0+=char1; > > > > > > } > > > } The problem here is that the function c2() changes the contents of char2. However, the function c1 is using its locale copy of char2 to add to char1. Scott |
From: Michael H. <mic...@ju...> - 2001-10-31 20:04:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Normally I reply to this list if I (think I) fixed something, to avoid > waisting other people's time hunting the same bug. This time I forgot. It > would be easier if not only the initial bug report would be forwarded to the > list, but also subsequent comments. Micheal? As far as I know, only creation can be sent to the list - everything else is between the assigned developer and the reporter. Sorry. - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (OpenBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjvgWV8ACgkQ3L3H1ImjCiQUGQCfVG1IzKBWPDcCxdhS98KZRINs vCwAn0LKh/kC0HzVWxZbn53p4oZi68wj =mp5Y -----END PGP SIGNATURE----- |
From: Johan K. <joh...@id...> - 2001-10-31 19:20:42
|
> In this case the scope isn't local but global. Please look at my fix in > SDCCloop.c:1.19 > > Normally I reply to this list if I (think I) fixed something, to avoid > waisting other people's time hunting the same bug. This time I forgot. It > would be easier if not only the initial bug report would be forwarded to the > list, but also subsequent comments. Micheal? Or changing assignments, meaning: Ok, I'll get it. |