huge memory model, get_lib_suffix missing HUGE

I downloaded the latest version and noticed a small issue with the huge 
memory model.  the get_lib_suffix routine is missing the HUGE option...

         case MODEL_MEDIUM:
           if (options.stackAuto)
             c = "medium-stack-auto";
           else
             c = "medium";
           break;

         case MODEL_LARGE:
           if (options.stackAuto)
             c = "large-stack-auto";
           else
             c = "large";
           break;

         case MODEL_FLAT24:
           /* c = "flat24"; */
           if (TARGET_IS_DS390)
             {
               c = "ds390";
             }
           else if (TARGET_IS_DS400)
             {
               c = "ds400";
             }

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval

Someone using sdcc with Maxim MAXQ622?

Hello,

does someone use sdcc together wirh Maxim MAXQ Microcontrollers?

In one of my applications I  use  currently  a  SiLabs  C8051F320  which
consumes to much power and I like to switch to  the  new  Maxim  MAXQ622
because I need only one I²C and USB-HID-PD device (APP is like an UPS).

As an Add-On only, I need SPI to control an EPSON S1D13781.

My OS is Debian GNU/Linx 5.0 and if someone can helpme with resource...

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant

--

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
<http://www.tamay-dogan.net/>                 Michelle Konzack
<http://www.can4linux.org/>                   Apt. 917
<http://www.flexray4linux.org/>               50, rue de Soultz
Jabber linux4michelle@...           67100 Strabourg/France
IRC    #Debian (irc.icq.com)                  Tel. DE: +49 177 9351947
ICQ    #328449886                             Tel. FR: +33  6  61925193

------------------------------------------------------------------------------

Re: huge memory model, get_lib_suffix missing HUGE

Thanks Anthony, it's in revision 5722 now.

> I downloaded the latest version and noticed a small issue with the huge 
> memory model.  the get_lib_suffix routine is missing the HUGE option...
> 
>          case MODEL_MEDIUM:
>            if (options.stackAuto)
>              c = "medium-stack-auto";
>            else
>              c = "medium";
>            break;
> 
>          case MODEL_LARGE:
>            if (options.stackAuto)
>              c = "large-stack-auto";
>            else
>              c = "large";
>            break;
> 
>          case MODEL_FLAT24:
>            /* c = "flat24"; */
>            if (TARGET_IS_DS390)
>              {
>                c = "ds390";
>              }
>            else if (TARGET_IS_DS400)
>              {
>                c = "ds400";
>              }

PIC18F4550 code generation error?

Hi,

sorry I can't post a complete compilable example but here is snippet of my problematic code:

static volatile u8 linelen = 0;

void getMessage() {
	u8 len, chr, sum,cnt;
	do {
		linelen = 0;
		chr = 0x55;
		sum = 0;
		len = 0;
		cnt = 0 ;
		LED_PIN = 0;
		while (len == 0) {
			len = usbcdc_getchar();
			if (len > 0x80)
				len &= 0x7F;
			else
				len = 0;
		}
		LED_PIN = 1;
		rx_timeout = 255;
		while ((linelen < len) && (rx_timeout > 0)) {
			if (usbcdc_rd_ready()) {
			        cnt++;
				sum += chr;
				chr = usbcdc_getchar();
				linebuffer[linelen++] = chr; // <<<<<< PROBLEM HERE

SDCC for Z80 target. About the SDCC ".cdb" to ".noi" converter.

Hello all,

- I use SDCC and NoICE to develop on Z80 target, and I just discovered that
   SDCC linker seems to create a ".noi" file.
   This indicate that SDCC convert its ".cdc" file to a ".noi" file at
   link time.

- Since, the ".noi" file created by SDCC do not work correctly with NoICE, and
   that John Hartman has recently released new version of its ".cdc" to ".noi"
   file converter ("cdb2noi") that support the Z80 (and work just fine);
   I think that the integrated ".cdc" to ".noi" file converter in SDCC is
   no more necessary for the Z80 target.

 From a SDCC user,

Claude Sylvain
Electro-Technica inc.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

building under Solaris: a little closer

   I've been working on building sdcc under Solaris with the Sun  
Studio 12 compiler.  I've not gotten all the way there, but I've made  
substantial progress.  I've detailed a few simple things that need  
fixing for this to work.  Most of them seem to come from the autoconf  
scripts' assumption that GCC will be used to compile sdcc.  I'm NOT  
asking that sdcc be modified to specifically support Sun's compilers,  
but if autoconf is going to check to see if GCC is in use, and finds  
that it isn't but still allows the user to continue, it shouldn't put  
GCC-specific options into CFLAGS. :)

   I'm working with 2.9.7, one of the source snapshots from a few  
days ago, 20100313-5734.

   The first thing that breaks is the automatic inclusion of -Wall  
(which is GCC-specific) in CFLAGS.

   Next comes this line in src/pic/ralloc.c:

#define FENTRY2                 1 ? (void)0 : printf

   I removed the void cast; that allowed it to compile.

   The last one is a weird problem that I've not really dug into yet;  
I think it probably has to do with -E handling.  The Makefile.dep  
files end up being huge (several megabytes) and contain lots of C  
source code fragments.  I ended up just turning that into "touch  
Makefile.dep" in the Makefiles and being careful about doing a "make  
clean" between builds, which is obviously not the correct solution.

Re: building under Solaris: a little closer

Dave McGuire wrote:
>    I've been working on building sdcc under Solaris with the Sun  
> Studio 12 compiler.  I've not gotten all the way there, but I've made  
> substantial progress.  I've detailed a few simple things that need  
> fixing for this to work.  Most of them seem to come from the autoconf  
> scripts' assumption that GCC will be used to compile sdcc.  I'm NOT  
> asking that sdcc be modified to specifically support Sun's compilers,  
> but if autoconf is going to check to see if GCC is in use, and finds  
> that it isn't but still allows the user to continue, it shouldn't put  
> GCC-specific options into CFLAGS. :)
> 
>    I'm working with 2.9.7, one of the source snapshots from a few  
> days ago, 20100313-5734.
> 
>    The first thing that breaks is the automatic inclusion of -Wall  
> (which is GCC-specific) in CFLAGS.
> 
>    Next comes this line in src/pic/ralloc.c:
> 
> #define FENTRY2                 1 ? (void)0 : printf
> 
>    I removed the void cast; that allowed it to compile.
> 
>    The last one is a weird problem that I've not really dug into yet;  
> I think it probably has to do with -E handling.  The Makefile.dep  
> files end up being huge (several megabytes) and contain lots of C  
> source code fragments.  I ended up just turning that into "touch  
> Makefile.dep" in the Makefiles and being careful about doing a "make  
> clean" between builds, which is obviously not the correct solution.
> 

Re: building under Solaris: a little closer

On Mar 15, 2010, at 12:40 PM, Marc Lobelle wrote:
> I'm using sdcc on Solaris (for pic processors) since a few years now,
> but I compiled it with gcc. i did not have compilation problems.

   Yes, I'm trying with gcc right now on a test machine.  The code  
generation of Sun's compiler for UltraSPARC architecture is far  
better than GCC's, so I've standardized on that for all of my  
builds.  I don't want to have just one package built with GCC.   
(requiring the libgcc_s.so hanging around, etc)

> If you plan to use sdcc on pics, be careful to access the registers  
> one byte at a time: for memory,
> the compiler handles larger data types, but do not try to write 16  
> bits in a pair of registers, as
> some microchip compiler allows.

   Ahh ok, thanks for the tip.  My current applications are all  
mcs51, but I've been looking at doing something with a PIC18 chip  
very soon.

              -Dave

--

-- 
Dave McGuire
Port Charlotte, FL

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.

Re: building under Solaris: a little closer

Hi Dave,

Dave McGuire wrote:
>    I've been working on building sdcc under Solaris with the Sun  
> Studio 12 compiler.  I've not gotten all the way there, but I've made  
> substantial progress.  I've detailed a few simple things that need  
> fixing for this to work.  Most of them seem to come from the autoconf  
> scripts' assumption that GCC will be used to compile sdcc.  I'm NOT  
> asking that sdcc be modified to specifically support Sun's compilers,  
> but if autoconf is going to check to see if GCC is in use, and finds  
> that it isn't but still allows the user to continue, it shouldn't put  
> GCC-specific options into CFLAGS. :)
>
>   

Quite some time ago, before the SourceForge Compile Farm died, the sdcc 
nightly builds were done also on Solaris, but, if I remember well, they 
were compiled with gcc.

>    I'm working with 2.9.7, one of the source snapshots from a few  
> days ago, 20100313-5734.
>
>    The first thing that breaks is the automatic inclusion of -Wall  
> (which is GCC-specific) in CFLAGS.
>
>    Next comes this line in src/pic/ralloc.c:
>
> #define FENTRY2                 1 ? (void)0 : printf
>
>    I removed the void cast; that allowed it to compile.

Re: building under Solaris: a little closer

Borut Razem wrote:
>>    The last one is a weird problem that I've not really dug into yet;  
>> I think it probably has to do with -E handling.  The Makefile.dep  
>> files end up being huge (several megabytes) and contain lots of C  
>> source code fragments.  I ended up just turning that into "touch  
>> Makefile.dep" in the Makefiles and being careful about doing a "make  
>> clean" between builds, which is obviously not the correct solution.
>>
>>   
>>     
>
> Tis is the hardest one: the gcc preprocessor understands -M command line 
> option, which generates the makefile dependencies. I don't know if 
> Solaris cc can do this. If not, an external toll should be found and used.
>
>   

I found this: http://sourceforge.net/projects/makedep/, but I haven't 
tried it yet.

Borut

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev