Chris, Chris, Chris...> Irrelevant. (besides most serious engineers can't afford free tools.)ROFL. A little disingenuous, no? So, what exactly is Keil supplying in their GNU package? I would say, they are bowing to the inevitable. There are more reference materials and real products out there using free compilers and assemblers than buyware. Open-source operating systems (which, I remind you, are designed to be compiled with open-source compilers - and are exceedingly difficult to build with alien proprietary toolchains) are increasing in market share at the expense of closed-source products. I agree in advance with the criticism that these comments are much more applicable to the 32-bit market than the 8-bit market, but I point out that 8-bit cores seem to be bottoming out on price while 32-bit parts are still dropping. For practical purposes, gcc is the "natural" choice for a 32-bit application, and anything else is a maverick choice made because some customer requirement mandates use of a particular operating system that won't build with gcc. A vendor of 32-bit parts who doesn't explicitly support gcc is not going to enjoy significant sales. Buyware tools are exceedingly low-volume products with long product lifecycles (i.e. slow bug support) and dauntingly high pricetags. It has been my consistent experience that the "support" and "guarantees" bought with the money are utterly worthless. Buyware tools have just as many warts and quirks as free tools. But buyware is maintained at by-the-hour engineering rates, and nobody can or will lift a finger to fix the closed-source problems unless they are paid to do so. Open-source tools are fixed as and when they break, comparatively speaking.> >ANSI - C compiler. > > And you can justify that statement? Remind me, which test suites has itI didn't make the statement, so I don't really need to. It's copied from the first paragraph of the SDCC homepage on sourceforge. I'm offering you a can of Coke and you're challenging me to provide a certified assay proving that it isn't Pepsi, and furthermore launching into a diatribe as to why Coke is inferior to Pepsi. Free is the future, which in all things encroaches continuously upon the present.
8051 development board in India
Started by ●January 19, 2004
Reply by ●January 25, 20042004-01-25
Reply by ●January 26, 20042004-01-26
On Fri, 23 Jan 2004 23:32:56 +0000, Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> wrote: [...]> >Are you telling me gcc can compile for the AVR?You didn't know? http://www.avrfreaks.net/Tools/showtools.php?ToolID=145 It does a very nice job, actually... Regards, -=Dave -- Change is inevitable, progress is not.
Reply by ●January 26, 20042004-01-26
Dave Hansen wrote:> On Fri, 23 Jan 2004 23:32:56 +0000, Ian Bell > <ian@ruffrecordsDOTworldonline.co.uk> wrote: > > [...] >> >>Are you telling me gcc can compile for the AVR? > > You didn't know? > > http://www.avrfreaks.net/Tools/showtools.php?ToolID=145 > > It does a very nice job, actually... > > Regards, > > -=DaveNo I didn't know. I thought gcc was limited to 16 bit and over processors. That is compiles with the AVR is cool. Ian
Reply by ●January 26, 20042004-01-26
On 2004-01-26, Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> wrote:> Dave Hansen wrote: > >> On Fri, 23 Jan 2004 23:32:56 +0000, Ian Bell >> <ian@ruffrecordsDOTworldonline.co.uk> wrote: >> >> [...] >>> >>>Are you telling me gcc can compile for the AVR? >> >> You didn't know? >> >> http://www.avrfreaks.net/Tools/showtools.php?ToolID=145 >> >> It does a very nice job, actually... > > No I didn't know. I thought gcc was limited to 16 bit and > over processors.If you want an "int" to be 16 bits, it does help if there are a few 16-bit instructions and/or registers available. [There's also a pretty decent GCC port for the 68HC11 (which, in my book is an 8-bit processor.] One thing gcc can't handle is when pointers to different types of objects need to be different lengths.> That is compiles with the AVR is cool.Definitely. -- Grant Edwards grante Yow! .. over in west at Philadelphia a puppy is visi.com vomiting...
Reply by ●January 26, 20042004-01-26
Grant Edwards wrote:> On 2004-01-26, Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> wrote: >> Dave Hansen wrote: >> >>> On Fri, 23 Jan 2004 23:32:56 +0000, Ian Bell >>> <ian@ruffrecordsDOTworldonline.co.uk> wrote: >>> >>> [...] >>>> >>>>Are you telling me gcc can compile for the AVR? >>> >>> You didn't know? >>> >>> http://www.avrfreaks.net/Tools/showtools.php?ToolID=145 >>> >>> It does a very nice job, actually... >> >> No I didn't know. I thought gcc was limited to 16 bit and >> over processors. > > If you want an "int" to be 16 bits, it does help if there are a > few 16-bit instructions and/or registers available. [There's > also a pretty decent GCC port for the 68HC11 (which, in my book > is an 8-bit processor.]Mine too. Used it not long after it came out.> > One thing gcc can't handle is when pointers to different types > of objects need to be different lengths.I assume the paramter passing on the stack model still holds irrespective of processor type? I thought this was one (of many) reasons why 8 bitters were not even considered let alone supported by gcc. Ian> >> That is compiles with the AVR is cool. > > Definitely. >
Reply by ●January 26, 20042004-01-26
On 2004-01-26, Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> wrote:> Grant Edwards wrote:>> If you want an "int" to be 16 bits, it does help if there are >> a few 16-bit instructions and/or registers available. [There's >> also a pretty decent GCC port for the 68HC11 (which, in my >> book is an 8-bit processor.)] > > Mine too. Used it not long after it came out. > >> One thing gcc can't handle is when pointers to different types >> of objects need to be different lengths. > > I assume the paramter passing on the stack model still holds > irrespective of processor type?Sure. For architectures with a decent number of registers, the first one or two parameters are often passed in registers. But, in general gcc expects to be able to use a stack for parameters and local "auto" storage.> I thought this was one (of many) reasons why 8 bitters were > not even considered let alone supported by gcc.Plenty of 8-bit processors (starting at least as early as the mid-70s with the 8080 and 6800 families) had fully functional stacks that could be used for parameter passing. Judging by what I've seen with the 6811 port, just about any of the 8 bit CPUs that have a 16-bit address space with a 16-bit SP and 16-bit PC, could be supported. Processors with variable sized pointers and without a user-accessible, full-sized stack pointer (e.g. 8051) are a problem. -- Grant Edwards grante Yow! I've got a COUSIN at who works in the GARMENT visi.com DISTRICT...
Reply by ●January 27, 20042004-01-27
csshieh@cc.kuas.edu.tw (Chin-Shiuh Shieh) wrote in message news:<400bf97c.713786@news.hinet.net>...> Dear Seemanta Dutta, > > You may consider to do it by yourself. > Please refer to http://bit.kuas.edu.tw/~8051 > >Thanks a lot for the info. I have added that link to my ever increasing 8051 links collection. really cool link I must say!! regards, Seemanta
Reply by ●January 27, 20042004-01-27
Grant Edwards wrote:> On 2004-01-26, Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> wrote: >> Grant Edwards wrote: > >>> If you want an "int" to be 16 bits, it does help if there are >>> a few 16-bit instructions and/or registers available. [There's >>> also a pretty decent GCC port for the 68HC11 (which, in my >>> book is an 8-bit processor.)] >> >> Mine too. Used it not long after it came out. >> >>> One thing gcc can't handle is when pointers to different types >>> of objects need to be different lengths. >> >> I assume the paramter passing on the stack model still holds >> irrespective of processor type? > > Sure. For architectures with a decent number of registers, the > first one or two parameters are often passed in registers. But, > in general gcc expects to be able to use a stack for parameters > and local "auto" storage. > >> I thought this was one (of many) reasons why 8 bitters were >> not even considered let alone supported by gcc. > > Plenty of 8-bit processors (starting at least as early as the > mid-70s with the 8080 and 6800 families) had fully functional > stacks that could be used for parameter passing. Judging by > what I've seen with the 6811 port, just about any of the 8 bit > CPUs that have a 16-bit address space with a 16-bit SP and > 16-bit PC, could be supported.This is fine for microprocessors but potentialy problematic for microcontrollers which have very limited resources e.g. RAM such as the 8051 and the PIC. Ian
Reply by ●January 27, 20042004-01-27
On 2004-01-27, Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> wrote:>>> I thought this was one (of many) reasons why 8 bitters were >>> not even considered let alone supported by gcc. >> >> Plenty of 8-bit processors (starting at least as early as the >> mid-70s with the 8080 and 6800 families) had fully functional >> stacks that could be used for parameter passing. Judging by >> what I've seen with the 6811 port, just about any of the 8 bit >> CPUs that have a 16-bit address space with a 16-bit SP and >> 16-bit PC, could be supported. > > This is fine for microprocessors but potentialy problematic for > microcontrollers which have very limited resources e.g. RAM such as the > 8051 and the PIC.Sure. If you don't have a stack, porting GCC is going to be a problem. But -- there's nothing inherently unsupportable about 8-bit processors. -- Grant Edwards grante Yow! Sometime in 1993 at NANCY SINATRA will lead a visi.com BLOODLESS COUP on GUAM!!
Reply by ●January 27, 20042004-01-27
On Tue, 27 Jan 2004 13:18:49 +0000, Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> wrote:>Grant Edwards wrote: > >> On 2004-01-26, Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> wrote: >>> Grant Edwards wrote: >> >>>> If you want an "int" to be 16 bits, it does help if there are >>>> a few 16-bit instructions and/or registers available. [There's >>>> also a pretty decent GCC port for the 68HC11 (which, in my >>>> book is an 8-bit processor.)] >>> >>> Mine too. Used it not long after it came out. >>> >>>> One thing gcc can't handle is when pointers to different types >>>> of objects need to be different lengths. >>> >>> I assume the paramter passing on the stack model still holds >>> irrespective of processor type? >> >> Sure. For architectures with a decent number of registers, the >> first one or two parameters are often passed in registers. But, >> in general gcc expects to be able to use a stack for parameters >> and local "auto" storage. >> >>> I thought this was one (of many) reasons why 8 bitters were >>> not even considered let alone supported by gcc. >> >> Plenty of 8-bit processors (starting at least as early as the >> mid-70s with the 8080 and 6800 families) had fully functional >> stacks that could be used for parameter passing. Judging by >> what I've seen with the 6811 port, just about any of the 8 bit >> CPUs that have a 16-bit address space with a 16-bit SP and >> 16-bit PC, could be supported. > >This is fine for microprocessors but potentialy problematic for >microcontrollers which have very limited resources e.g. RAM such as the >8051 and the PIC.I have written programs in C compiled with gcc for AVR with 2K code space and 128bytes of ram. I had less ram space problems with this setup than with IAR 8051 compiler and a 8051 clone with the same amount of ram. Regards Anton Erasmus
