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: Sandeep D. <sa...@dd...> - 2000-02-22 19:15:03
|
Hi Michael , This maynot be very easy to do..SDCCast.c would be the place to start... it just creates a tree as if there are several assignments to array elements in your case it creates six assignments. tile[0] = 1; tile[1] = 2; ... tile[5] = 6; we might me able to change this ..if this is a constant array however the compiler will generate the code differently it will generate _tile: .db 1,2,3,4,5,6 Sandeep > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all. I've added a 'c1' mode to sdcc so that it can be used inside a C > front end like gcc or lcc. See --c1mode. Basically its a mode where it > compiles pre-processed code into assembler. I'm using it with a hacked > version of lcc to give cmd lines like 'lcc -mgbz80 -o big.gb b1.c b2.c > lib.o' > > My question for the day is: > For static data like: > > char tile[] = { > 1, 2, 3, 4, 5, 6 > }; > > sdcc generates: > ld bc,#tile > ld a,1 > ld (bc),a > ld bc,#tile+1 > ld a,2 > ld (bc),a ... > > which is incredibly inefficent (6 bytes per static byte). What I'd like > it to do is: > > ld de,#tile > ld hl,#1_start$ > ld bc,#1_end$ > ldir (basically a memcpy) > jp 1_end$ > 1_start$: > .db 1,2,3,4,5,6 > 1_end$: > ... next gs init. > > Any clues as to where to start? I believe the relevent code is in > SDCCast.c, but I've yet to find where it actually emits the > genPointerSet. It seems that theres some interesting tree unfolding going > on. > > - -- Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.0 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE4shC3UejL3SuzxEgRAsvkAKCdo8LdZ5OMKVHSPvcg4nbCP/tPcQCfZlYB > 5SakardoxNcLMYWAH5c/UTE= > =WbZu > -----END PGP SIGNATURE----- > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sandeep Dutta Phone: 650-356-5417 Diab-SDS Fax: 650-356-5490 323 Vintage Park Drive Email: sa...@dd... Foster City, CA 94404 URL: www.ddi.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: Michael H. <mic...@ea...> - 2000-02-22 04:32:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. I've added a 'c1' mode to sdcc so that it can be used inside a C front end like gcc or lcc. See --c1mode. Basically its a mode where it compiles pre-processed code into assembler. I'm using it with a hacked version of lcc to give cmd lines like 'lcc -mgbz80 -o big.gb b1.c b2.c lib.o' My question for the day is: For static data like: char tile[] = { 1, 2, 3, 4, 5, 6 }; sdcc generates: ld bc,#tile ld a,1 ld (bc),a ld bc,#tile+1 ld a,2 ld (bc),a ... which is incredibly inefficent (6 bytes per static byte). What I'd like it to do is: ld de,#tile ld hl,#1_start$ ld bc,#1_end$ ldir (basically a memcpy) jp 1_end$ 1_start$: .db 1,2,3,4,5,6 1_end$: ... next gs init. Any clues as to where to start? I believe the relevent code is in SDCCast.c, but I've yet to find where it actually emits the genPointerSet. It seems that theres some interesting tree unfolding going on. - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4shC3UejL3SuzxEgRAsvkAKCdo8LdZ5OMKVHSPvcg4nbCP/tPcQCfZlYB 5SakardoxNcLMYWAH5c/UTE= =WbZu -----END PGP SIGNATURE----- |
From: Michael H. <mic...@ea...> - 2000-02-20 05:37:59
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nice. sdcc is now definatly better than gbdk when targeting the GB. The code generated is now as nice in most cases and the register packing is better/more directed. Dhrystone results: * C based strcpy, memcpy and strcmp 85.55 d/s * ASM based 157.52 d/s Other figures: * Z80/C 98 d/s * Z80/ASM 166 d/s * First gbz80 version 66 d/s Yeah. gbdk 3.0 here we come... - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4r30LUejL3SuzxEgRAj7WAJ0YFyfhAZKkGsFesoR6Xu3+qgggfQCffj8A abJfpBF3ALFOeR5xWtTHEmU= =ncrw -----END PGP SIGNATURE----- |
From: <da...@kd...> - 2000-02-20 00:08:38
|
Katix software for micro-ethernet as requested. http://sdcc.sourceforge.net/files/katix11.tar.gz -- Dave ----------------------------------------------------------------------- Dave Helton, KD0YU - da...@kd... - http://www.kd0yu.com Real World Computing - 319-386-4041 - 8am-5pm CST Linux/Novell/NT | Servers/Workstations | Consulting | Internet Technologies ----------------------------------------------------------------------- _ / / (_)__ __ ____ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a /____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . ----------------------------------------------------------------------- |
From: Michael H. <mic...@ea...> - 2000-02-19 19:49:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. Well, it now passes the dhrystone test. And the result is: sdcc/gbz80 v0.01: 68.12d/s lcc/gbz80 (gbdk) 2.1.5: 68.83d/s Funny, eh? Its not a fair test as the lcc version was using sdcc generated string functions. The code from sdcc/gbz80 is _so_ crusty, but can only get better :) lcc/gbz80 didnt actually pass the dhrystone test - some of the results were wrong. - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4rvMtUejL3SuzxEgRAhQoAJ9Kfe5IDx7jLx02ccCIFDU++o85dwCfROl5 WUjOBntXnjKbj6VwAnUdOvY= =WFky -----END PGP SIGNATURE----- |
From: Sandeep D. <sa...@dd...> - 2000-02-18 22:46:12
|
Hi Kevin , That sounds good for the time being will take a look this weekend..have beena little busy @ work so did have time to investigate it... The SE parms should always be executed .. that sounds right.. Sandeep > > I've tried to understand what geniCodeSEParms does, and utterly > failed (Sandeep?). > > But if it's description can be believed, it should be useless in > the --stack-auto case, since it is concerned with overlaying > parameters to function calls, which obviously doesn't apply when the > parameters are all on the stack. > > So I propose the following fix: only call geniCodeSEParms from > geniCodeCall if we're not in --stack-auto mode, like so: > > /* take care of parameters with side-effecting > function calls in them, this is required to take care > of overlaying function parameters */ > if (!options.stackAuto) > { > geniCodeSEParms ( parms ); > } > > This works for me. > > Peace, > Kevin > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sandeep Dutta Phone: 650-356-5417 Diab-SDS Fax: 650-356-5490 323 Vintage Park Drive Email: sa...@dd... Foster City, CA 94404 URL: www.ddi.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: Kevin V. <ke...@vi...> - 2000-02-18 22:36:26
|
I've tried to understand what geniCodeSEParms does, and utterly failed (Sandeep?). But if it's description can be believed, it should be useless in the --stack-auto case, since it is concerned with overlaying parameters to function calls, which obviously doesn't apply when the parameters are all on the stack. So I propose the following fix: only call geniCodeSEParms from geniCodeCall if we're not in --stack-auto mode, like so: /* take care of parameters with side-effecting function calls in them, this is required to take care of overlaying function parameters */ if (!options.stackAuto) { geniCodeSEParms ( parms ); } This works for me. Peace, Kevin |
From: Kevin V. <kv...@en...> - 2000-02-18 18:57:47
|
Michael, I've got it a little further, though I still don't fully understand it: the bad guy is geniCodeSEParms(). If you comment out the call to geniCodeSEParms() in geniCodeCall(), it works properly. According to the comments, geniCodeSEParms should only make a difference on parameters with side-effects (like parameters generated by function calls). This obviously isn't true at the moment. Still looking, but this is the first real clue I've found... Peace, Kevin |
From: <da...@kd...> - 2000-02-18 17:29:46
|
hi, I think someone had already sent this to the list. http://www.embeddedethernet.com/ Worth repeating. -- Dave ----------------------------------------------------------------------- Dave Helton, KD0YU - da...@kd... - http://www.kd0yu.com Real World Computing - 319-386-4041 - 8am-5pm CST Linux/Novell/NT | Servers/Workstations | Consulting | Internet Technologies ----------------------------------------------------------------------- _ / / (_)__ __ ____ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a /____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . ----------------------------------------------------------------------- |
From: Michael H. <mic...@ea...> - 2000-02-17 05:26:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, I've traced it down but I dont understand it. The flow is: * geniCodeCall (actually sets parmBytes) from the result of: * geniCodeParms which generates a 'stack' size from summing the size of all stack pushed parms. This is from the result of: * ...many calls to getSize() getSize is where things break. getSize is basically: if IS_SPEC(p) (is a char, short, int, long...) return sizeof(p); else is a pointer to something. return sizeof(POINTER in appropriate space) The problem is that its dereferencing the paramater down to a char, so IS_SPEC is true, and sizeof(char) is returned instead of sizeof(char *) Thats where I get lost. I cant find where the 'class' is actually set, and the diffs against two weeks ago look fine to my untrained eye. Yeah. I'll keep hunting. My notes are in doc/random-notes.txt. - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4q4XmUejL3SuzxEgRAnlRAKCXtkvFvo/4Stv/qb+rpYKmA5xCKgCfSP2D 5HIiLVzSd39sgWHVpUOzTqo= =DZcH -----END PGP SIGNATURE----- |
From: Michael H. <mic...@ea...> - 2000-02-17 04:36:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm going to try and track this down, but I though people might be interested in the problem. This code: unsigned a; void puts(char *s) { a = sizeof(s); printf(s); } Generates a = 2 hl = s push hl call printf pop l (ie parmBytes = 1 instead of 2) But changing the printf line to include a redundent cast: printf((char *)s) generates ... push hl call printf pop hl (parmBytes = 2, which is correct) - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4q3ojUejL3SuzxEgRAjTcAJ9iZR5ZpMgusw0zDJz5QmA8rSDrswCdHmZ/ EPRqxmvTS2F5nhArvVxTIhk= =cgft -----END PGP SIGNATURE----- |
From: Sandeep D. <sa...@dd...> - 2000-02-16 23:07:26
|
Hi Michael , Maybe you have not updated SDCCicode.c .... for parmbytes seems to get updated okay.. however there is a bug that the compiler does not complain about wrong number of parameters when the function is reentrant.. Sandeep > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all. Looks like we can Nintendo Gameboy to the list of ports. It's > processor is z80 like (no ix or iy but) and was reasonably easy to > port. Just try '-mgbz80' > > One problem thats come up: 'parambytes' for a function call seems to be > broken at the moment, and I'm not sure why. This code: > > unsigned a; > void puts(char *s) > { > a = sizeof(s); > printf(s); > } > > (Yes, it's ugly :) > > roughly generates: > > a = 2 > ld hl,s > push hl (2 bytes) > call printf > pop l (ie pop one byte, not two) > ret > > The sizeof is ok, and parambytes is definatly 1. It occurs in more than > one place. This: > > _printf(void *, void *, void *, void *); > > when called only pops 6 bytes. > > Any bets? > > - -- Michael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.0 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE4qjkIUejL3SuzxEgRAm1DAKCGx1w6GAQ+ZUpLDcPZ1rpF3uTrUgCcDB1L > POK/vyCCvFjyPoiUV74YkVg= > =x/EY > -----END PGP SIGNATURE----- > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sandeep Dutta Phone: 650-356-5417 Diab-SDS Fax: 650-356-5490 323 Vintage Park Drive Email: sa...@dd... Foster City, CA 94404 URL: www.ddi.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: Kevin V. <ke...@vi...> - 2000-02-16 21:19:27
|
On 16-Feb-2000 Michael Schmitt wrote: > In november last year i was in contact > with "bill" after some investigations about the > DS80C400 thas was never official released, but > replaced by the DS80C390. He sent me a version of > the asxxxx to compile for the Dallas DS80C390 > > I am not shure if this is of interest for you, > but maybe it can help "not to" develop > the "whell" twice. > > If somebody is interested, i can sent the zip > file. Michael, Well, I've already re-invented this wheel: I have modified the assembler/linker in the SDCC projest to support the '390 (the code is checked into the sdcc project at www.sourceforge.net if you want to see it; it's not yet in any released version of sdcc). I also have the compiler working (*); it generates valid though definitely non-optimal '390 24-bit code (if I can figure out how to get the compiler to use dual DPTRs, it'll be a whole lot better). I'd like to see the .zip, though, to compare the implementation. I had to do some interesting hacking, including mods to the .rel file format, to get this working. Maybe "bill" came up with a better solution... Peace, Kevin (*) this is all untested on real hardware; if Dallas doesn't get my TINI to me soon, my head will explode... |
From: Michael H. <mic...@ea...> - 2000-02-16 05:46:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. Looks like we can Nintendo Gameboy to the list of ports. It's processor is z80 like (no ix or iy but) and was reasonably easy to port. Just try '-mgbz80' One problem thats come up: 'parambytes' for a function call seems to be broken at the moment, and I'm not sure why. This code: unsigned a; void puts(char *s) { a = sizeof(s); printf(s); } (Yes, it's ugly :) roughly generates: a = 2 ld hl,s push hl (2 bytes) call printf pop l (ie pop one byte, not two) ret The sizeof is ok, and parambytes is definatly 1. It occurs in more than one place. This: _printf(void *, void *, void *, void *); when called only pops 6 bytes. Any bets? - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4qjkIUejL3SuzxEgRAm1DAKCGx1w6GAQ+ZUpLDcPZ1rpF3uTrUgCcDB1L POK/vyCCvFjyPoiUV74YkVg= =x/EY -----END PGP SIGNATURE----- |
From: Michael S. <arc...@db...> - 2000-02-16 03:11:59
|
This message was sent from Geocrawler.com by "Michael Schmitt" <mic...@t-...> Be sure to reply to that address. In november last year i was in contact with "bill" after some investigations about the DS80C400 thas was never official released, but replaced by the DS80C390. He sent me a version of the asxxxx to compile for the Dallas DS80C390 I am not shure if this is of interest for you, but maybe it can help "not to" develop the "whell" twice. If somebody is interested, i can sent the zip file. Michael ---- Copy of E-Mail ------ Michael, Attached is a zip of the assembler and linker. It does support the extended addressing mode. There are no new instructions but the jumps and calls use an extra byte of address if in address mode 2. Bill -----Original Message----- From: Michael Schmitt <msc...@ma...> To: w_m...@co... <w_m...@co...> Date: Tuesday, November 16, 1999 1:37 PM Subject: DS80C390 and ASxxxx ---- End of E-Mail ----- Geocrawler.com - The Knowledge Archive |
From: <da...@kd...> - 2000-02-15 16:56:31
|
On 15 Feb, Sandeep Dutta wrote: > Hi dave, > > Great picture..could make the LCD with the display our official LOGO.. I REALLY liked it! Jumped up and down and lit 2 cigs. > > PS I checkout the website pre-release looks good.. don't forget the > links I had sent this URL to Sandeep only. http://sdcc.sourceforge.net/sdcc-index.html Everyone please have a look. Feedback or corrections are invited. Any links I've missed or ones that should be added, please email them to me. Sandeep... not sure of all the links you would like added. Again, the page is a prelim and definitely not finished. Will add the two below right away. > eg GOOFEE etc etc.. also gota new one SENSORELLA..this one looks really > interesting..dual CPU 8051 board... > <http://www.sensorella.da.ru> Very cool. Cheap too. (Funny, my name is David and I call my dual 400 linux box Goliath. The guy at sensorella must be snooping around ;-) -- Dave ----------------------------------------------------------------------- Dave Helton, KD0YU - da...@kd... - http://www.kd0yu.com Real World Computing - 319-386-4041 - 8am-5pm CST Linux/Novell/NT | Servers/Workstations | Consulting | Internet Technologies ----------------------------------------------------------------------- _ / / (_)__ __ ____ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a /____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . ----------------------------------------------------------------------- |
From: Sandeep D. <sa...@dd...> - 2000-02-15 16:30:05
|
Hi dave, Great picture..could make the LCD with the display our official LOGO.. PS I checkout the website pre-release looks good.. don't forget the links eg GOOFEE etc etc.. also gota new one SENSORELLA..this one looks really interesting..dual CPU 8051 board... <http://www.sensorella.da.ru> Sandeep > > Sorta.... > I just had a major breakthru. Have been working with a graphic lcd > and a custom interface to it. Found a program on the net that can > disassemble bitmaps. I re-wrote the output of it to create a .asm file > based on black and white, ones and zeros. Bitbanged it out to the lcd > and... > > Enough... have a look. > http://sdcc.sourceforge.net/sdcc.gif > > Thought I'd share this. Next is an LCARS display made with the Gimp. > > -- Dave > > ----------------------------------------------------------------------- > Dave Helton, KD0YU - da...@kd... - http://www.kd0yu.com > Real World Computing - 319-386-4041 - 8am-5pm CST > Linux/Novell/NT | Servers/Workstations | Consulting | Internet Technologies > ----------------------------------------------------------------------- > _ > / / (_)__ __ ____ __ > / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a > /____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . > ----------------------------------------------------------------------- > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sandeep Dutta Phone: 650-356-5417 Diab-SDS Fax: 650-356-5490 323 Vintage Park Drive Email: sa...@dd... Foster City, CA 94404 URL: www.ddi.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: <da...@kd...> - 2000-02-15 05:34:47
|
Sorta.... I just had a major breakthru. Have been working with a graphic lcd and a custom interface to it. Found a program on the net that can disassemble bitmaps. I re-wrote the output of it to create a .asm file based on black and white, ones and zeros. Bitbanged it out to the lcd and... Enough... have a look. http://sdcc.sourceforge.net/sdcc.gif Thought I'd share this. Next is an LCARS display made with the Gimp. -- Dave ----------------------------------------------------------------------- Dave Helton, KD0YU - da...@kd... - http://www.kd0yu.com Real World Computing - 319-386-4041 - 8am-5pm CST Linux/Novell/NT | Servers/Workstations | Consulting | Internet Technologies ----------------------------------------------------------------------- _ / / (_)__ __ ____ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a /____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . ----------------------------------------------------------------------- |
From: Shawn M. <sc...@tc...> - 2000-02-13 20:59:37
|
That one is a typo on my part, it was 200 d/s. That is still fast though as I think the nearest competitor was 160 d/s. These were from adds in the early 90's, probably in Circuit Cellar. For reference the 68000/68010 (performance shouldn't be very different between these) was 2100 @ 8MHz and 4376 @ 16MHz according to the M68K FAQ. Even these numbers are a little dubious as there is no reason a 68000/68010 should not increase in performance past 1:1 with the clock frequency. This is probably due to a different stepping or something. There are also different dhrystone benchmarks, but I never thought they varied by much. Another thing to compare out is the way clocks are actually measured. The 68HC11 uses an 8MHz clock, but is said to be running at 2MHz (four phase cycle). Almost all other chips would say they were running at 8MHz then. I think Motorola was driven by marketing on this nomenclature:-). Using 8MHz gives a 10.5 performance difference between the 68000 and 68HC11 per MHz. That's not out of line given the complex commands and register structure of the 68000. I don't know where the Z80 should sit in all of this. It has a decent register structure for an 8bit micro, but it has a limited instruction set. It would be nice to start collecting a set of samples though to know how things are going with development. 73, Shawn > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On Behalf Of Michael Hope > Sent: Sunday, February 13, 2000 3:07 PM > To: sdc...@li... > Subject: RE: [sdcc-devel] More dhrystones... > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Introl's compilers on the 68HC11 often quote 2000 d/s, > which is considered > > fast for that chip running at 2MHz. I would like to see a run > down of the > > different compilers and chips though. > > Hmm. That corresponds to a 68010 at about 15MHz - can you give me a ref > to the original? > > - From the quality of the code I think I can get another 50% at > most out of > the system. Perhaps :) > > - -- Michael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.0 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE4pw7hUejL3SuzxEgRAncYAJ41Ri/M5M7KLbIVNZsmWPVAPkHkRgCfS8BB > 0vzKogxDhBJNxw4doqweulA= > =d7dT > -----END PGP SIGNATURE----- > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel > |
From: Michael H. <mic...@ea...> - 2000-02-13 20:09:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Introl's compilers on the 68HC11 often quote 2000 d/s, which is considered > fast for that chip running at 2MHz. I would like to see a run down of the > different compilers and chips though. Hmm. That corresponds to a 68010 at about 15MHz - can you give me a ref to the original? - From the quality of the code I think I can get another 50% at most out of the system. Perhaps :) - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4pw7hUejL3SuzxEgRAncYAJ41Ri/M5M7KLbIVNZsmWPVAPkHkRgCfS8BB 0vzKogxDhBJNxw4doqweulA= =d7dT -----END PGP SIGNATURE----- |
From: Shawn M. <sc...@tc...> - 2000-02-13 16:08:47
|
Introl's compilers on the 68HC11 often quote 2000 d/s, which is considered fast for that chip running at 2MHz. I would like to see a run down of the different compilers and chips though. 73, Shawn > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On Behalf Of Sandeep > Dutta > Sent: Saturday, February 12, 2000 11:40 PM > To: sdc...@li... > Subject: Re: [sdcc-devel] More dhrystones... > > > Hi Michael, > > Sounds like you are making real good progress early release > sounds good ... PS curious about the d/s performance with > other compilers.... (like lcc) > > Sandeep > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Well, I'm up to 98 d/s with C strings, and 166 d/s with ASM based > > strings. Thanks for your help Sandeep - I enabled that assign > > optimisation and put in some regarding short liveds and the > acc., and now > > the code is begining to look almost decent. > > > > I'm thinking of doing an early release of the Z80 compiler and > some hacked > > up libs, so that other people can test it. Any comments? > > > > A 4MHz Z80 using sdcc now clocks in at 0.094 MIPS, or 0.055 MIPS with C > > strings. Thats faster than a Cromeco Z2! (whoa!) > > > > Yeah, > > > > - -- Michael > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.0.0 (GNU/Linux) > > Comment: For info see http://www.gnupg.org > > > > iD8DBQE4pgebUejL3SuzxEgRAkK0AKCM+P2Sq35Gim02UtcNxE6NjiiO8gCfTPId > > nUaXJ/08rzsBoBueiECgHVA= > > =Gjpa > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > sdcc-devel mailing list > > sdc...@li... > > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel > |
From: Sandeep D. <sa...@dd...> - 2000-02-13 04:48:57
|
Hi Michael, Sounds like you are making real good progress early release sounds good ... PS curious about the d/s performance with other compilers.... (like lcc) Sandeep > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Well, I'm up to 98 d/s with C strings, and 166 d/s with ASM based > strings. Thanks for your help Sandeep - I enabled that assign > optimisation and put in some regarding short liveds and the acc., and now > the code is begining to look almost decent. > > I'm thinking of doing an early release of the Z80 compiler and some hacked > up libs, so that other people can test it. Any comments? > > A 4MHz Z80 using sdcc now clocks in at 0.094 MIPS, or 0.055 MIPS with C > strings. Thats faster than a Cromeco Z2! (whoa!) > > Yeah, > > - -- Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.0 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE4pgebUejL3SuzxEgRAkK0AKCM+P2Sq35Gim02UtcNxE6NjiiO8gCfTPId > nUaXJ/08rzsBoBueiECgHVA= > =Gjpa > -----END PGP SIGNATURE----- > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel |
From: Michael H. <mic...@ea...> - 2000-02-13 01:25:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, I'm up to 98 d/s with C strings, and 166 d/s with ASM based strings. Thanks for your help Sandeep - I enabled that assign optimisation and put in some regarding short liveds and the acc., and now the code is begining to look almost decent. I'm thinking of doing an early release of the Z80 compiler and some hacked up libs, so that other people can test it. Any comments? A 4MHz Z80 using sdcc now clocks in at 0.094 MIPS, or 0.055 MIPS with C strings. Thats faster than a Cromeco Z2! (whoa!) Yeah, - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4pgebUejL3SuzxEgRAkK0AKCM+P2Sq35Gim02UtcNxE6NjiiO8gCfTPId nUaXJ/08rzsBoBueiECgHVA= =Gjpa -----END PGP SIGNATURE----- |
From: Sandeep D. <sa...@dd...> - 2000-02-11 19:50:35
|
Michael, Welcome to the wonderful world of register packing.. this is a term I use to describe the phase for reducing temporaries (in a processor specific manner)..think of them as peephole optimizations on the intermediate code..in your case for example the iCode sequence would probably look something like itempX[b c] := iTempY[d e]; iTempX[b c] = iTempX[b c] + 1; iTempY[d e] := iTempX[b c]; Here register packing would reduce the code to iTempY := iTempY + 1; if there is no other usage of iTempX.. take a look @ packRegistersForAssign in mcs51/gen.c.. in a tree walking code generator (like burg - as in lcc) this phase would have been much simpler ... Couple of important things here to determie usage & definitions the MACRO ..OP_DEFS & OP_USES yeild the definition & usage bitvectors respectively.. bitVectnBitsOn(OP_DEFS(operand type*)) will yield number of definitions for this iTemp..similarly bitVectnBitsOn(OP_USES(operand type*)) will give you the number of uses.. to check if an operand is used in an iCode or not if (bitVectBitValue(OP_USES(operand type*),iCode type*->key)) then there are several other useful things you could do with these bit vectors... to see if two operands are used in the same icode if (bitVectBitsInCommon(OP_USES(op1),OP_USES(op2)); Hope this information helps.. Sandeep > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It's messier than I thought :) The first optimisation seems to be pointer > fetch/inc dependent. This code: > > Is: Should be: > - ---------------------------------------- -------------------- > ; genAssign > ld -4(ix),e ; tmp = d -4(ix) = de > ld -3(ix),d > ; genPlus > ; genPlusIncr > ld c,e inc de > ld b,d (ie really bad !) > inc bc > ; genAssign > ld e,c > ld d,b > ; genAssign > ld l,-2(ix) ; 0 hl = -2(ix) > ld h,-1(ix) ; 1 > ; genPlus > ; genPlusIncr > ld c,-2(ix) ; 0 inc -2(ix) > ld b,-1(ix) ; 1 jr > inc bc inc -1(ix) > ; genAssign > ld -2(ix),c > ld -1(ix),b > ; genPointerGet > ld a,(hl) a = (hl) > ld c,a > ; genAssign (pointer) > ld l,-4(ix) ; 0 hl = -4(ix) > ld h,-3(ix) ; 1 > ld (hl),c ld (hl),a > ; genGoto > jp 00101$ jp > > is generated from part of a standard memcpy: > *d++ = *s++ > > - -- Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.0 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE4o5qLUejL3SuzxEgRAkYnAJwJT9BQU4nj1QbS/BGzqJPPHbxieACeKUrm > CBfr/S6MAFK+fDBkDUzFAlA= > =ER8C > -----END PGP SIGNATURE----- > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sandeep Dutta Phone: 650-356-5417 Diab-SDS Fax: 650-356-5490 323 Vintage Park Drive Email: sa...@dd... Foster City, CA 94404 URL: www.ddi.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: Michael H. <mic...@ea...> - 2000-02-11 05:15:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's messier than I thought :) The first optimisation seems to be pointer fetch/inc dependent. This code: Is: Should be: - ---------------------------------------- -------------------- ; genAssign ld -4(ix),e ; tmp = d -4(ix) = de ld -3(ix),d ; genPlus ; genPlusIncr ld c,e inc de ld b,d (ie really bad !) inc bc ; genAssign ld e,c ld d,b ; genAssign ld l,-2(ix) ; 0 hl = -2(ix) ld h,-1(ix) ; 1 ; genPlus ; genPlusIncr ld c,-2(ix) ; 0 inc -2(ix) ld b,-1(ix) ; 1 jr inc bc inc -1(ix) ; genAssign ld -2(ix),c ld -1(ix),b ; genPointerGet ld a,(hl) a = (hl) ld c,a ; genAssign (pointer) ld l,-4(ix) ; 0 hl = -4(ix) ld h,-3(ix) ; 1 ld (hl),c ld (hl),a ; genGoto jp 00101$ jp is generated from part of a standard memcpy: *d++ = *s++ - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4o5qLUejL3SuzxEgRAkYnAJwJT9BQU4nj1QbS/BGzqJPPHbxieACeKUrm CBfr/S6MAFK+fDBkDUzFAlA= =ER8C -----END PGP SIGNATURE----- |