In article <slrngbe57c.ka4.aznomad.3@ip70-176-155-130.ph.ph.cox.net>, 
aznomad.3@PremoveOBthisOX.COM says...
> On Thu, 28 Aug 2008 22:54:17 +0200, David Brown <david.brown@hesbynett.removethisbit.no> wrote:
> >As I said, I'd expect toolkits for larger processors to be larger - 
> >libraries, examples, help files are all significantly larger.  As for 
> >what could be eliminated on Code Worrier for the 6805 - practically all 
> >the "beans" could be dropped.  I can see the point of trying to have a 
> >set of ready-to-use components with a fairly consistent interface for 
> >different targets, but they are wildly unsuitable for small 8-bit 
> >devices (the ADC "bean" took about 1.5k out of the 4k flash on the 
> >device - a single line of C code did pretty much the same job).
> 
> It's more a function of the quality of the libraries.  It goes back to the
> old "hello world" test, looking at the generated code to see how much
> irrelevent bullshit gets included. 
> 

One programmer's irrelevant bullshit is another's initialization code.

I expect that most embedded programmers will know that

printf("hello world");

will produce a different result from

puts("hello world");

Of course the result will also depend on whether the
program has to run on bare silicon or can take advantage
of a bios or more complet OS.   I generally start with
bare silicon, so I'm not surprised when the program has
to link in serial port drivers, initialization code,
etc. etc.

For a system like the 6805,  I would  probably consider the
'beans' to be example code and extract only the essence.
Codewarrior was probably a better system back when it
was only generating code for the M68K systems or systems
of equivalent register complexity.

I've never been a big fan of 'one size fits all' tool
vendors.  That's why I use tool sets from IAR for the 
Atmel ARM chips,  Codewarrior for the M68K, Imagecraft for the
MSP430 and GCC for an ARM-Linux system.  (The latter
was not my choice, though).  I've also used Keil for the
8051 series---but I'm not sure I'd pick them for an
ARM compiler vendor.

Mark Borgerson

On Thu, 28 Aug 2008 22:54:17 +0200, David Brown <david.brown@hesbynett.removethisbit.no> wrote:
>As I said, I'd expect toolkits for larger processors to be larger - 
>libraries, examples, help files are all significantly larger.  As for 
>what could be eliminated on Code Worrier for the 6805 - practically all 
>the "beans" could be dropped.  I can see the point of trying to have a 
>set of ready-to-use components with a fairly consistent interface for 
>different targets, but they are wildly unsuitable for small 8-bit 
>devices (the ADC "bean" took about 1.5k out of the 4k flash on the 
>device - a single line of C code did pretty much the same job).

It's more a function of the quality of the libraries.  It goes back to the
old "hello world" test, looking at the generated code to see how much
irrelevent bullshit gets included.

Mark Borgerson wrote:
> In article <48b6474f$0$25381$8404b019@news.wineasy.se>, 
> david@westcontrol.removethisbit.com says...
>> Mark Borgerson wrote:
>>> In article <Es-dneuLX7SdAyjVnZ2dnUVZ8hidnZ2d@lyse.net>, 
>>> david.brown@hesbynett.removethisbit.no says...
>>>> Dombo wrote:
>>>>> AZ Nomad wrote:
>>>>>> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <dombo@disposable.invalid> 
>>>>>> wrote:
>>>> <snip>
>>>>>> Maybe with 10ghz of cpu and 20GB of ram vista might run OK, but otherwise
>>>>>> it's a steaming mountain of pig shit.
>>>>>>
>>>>>> And adobe's latest reader runs just fine under linux on my 1.4 ghz laptop
>>>>>> with a typical 5200rpm laptop drive.  If MS wrote it, you could count 
>>>>>> on it
>>>>>> being unable to run on such hardware.
>>>>> Consider that Adobe needs 100MB hard disk space for just a reader, where 
>>>>> others can produce a PDF reader that takes less than 1 MB and starts at 
>>>>> least 10x faster, and you still believe Adobe is producing efficient 
>>>>> software?
>>>>>
>>>>> Ever tried Lotus Notes, or CM Synergy (nowadays both IBM), or Borland 
>>>>> C++ Builder and still believe Microsoft is the only company that 
>>>>> produces crap software.
>>>>>
>>>> For an example a little closer to the group's topic - Code Worrier for 
>>>> the Freescale 6805 devices was something like a 600 MB download, and 1 
>>>> GB install, for a compiler for a device with a couple of KB code space.
>>>>
>>> The sise of the IDE has little to do with the size of the code space
>>> on the target.  The size of the compiler also has little to do with
>>> the processor code space.
>>>
>> That's not entirely true - for a bigger and more powerful target, you 
>> could expect larger libraries (with corresponding files such as 
>> documentation), more IDE features (such as a more powerful debugger 
>> taking advantage of the target's features), etc.  Green Hills for the 
>> ColdFire, for example, weighs in at about 400 MB - a lot of that is from 
>> dozens of copies of very large static libraries for each target 
>> variation.  The actual useful bit of Code Worrier, the compiler, is 
>> pretty good, but the rest is an impressive quantity of bloat.
>>
> 
> 
> I just took a look at the CodeWarrior demo CD for the ColdFire 
> architecture.  The total data on the CD was  303MB.   That seems
> comparable to the Green Hills package---although the 270MB .cab
> file could expand quite a bit on installation.
> 
> I still use Codewarrior  8.0 for the PalmOS to compile M68K code
> for Persistor data loggers.  The Codewarrior folder with the
> IDE, help files, compiler and libraries is just 88MB.  The HTML
> help and manuals are about 45MB of the 88MB.  Perhaps this was
> one of the last pre-bloat versions of Codewarrior.
> 
> By comparison, the IAR Embedded Workbench for the Arm processor
> occupies about  435MB of disk space.  Of that, the bin folder
> is about 35MB, while the doc and examples folders add up
> to more than 200MB.  The rest goes to libraries, include files,
> drivers and  about 62MB for a sample version of their PowerPac
> RTOS.
> 
> 
> What elements of Codewarrior could be eliminated?   After all one
> programmer's help files are another's bloat.
> 

As I said, I'd expect toolkits for larger processors to be larger - 
libraries, examples, help files are all significantly larger.  As for 
what could be eliminated on Code Worrier for the 6805 - practically all 
the "beans" could be dropped.  I can see the point of trying to have a 
set of ready-to-use components with a fairly consistent interface for 
different targets, but they are wildly unsuitable for small 8-bit 
devices (the ADC "bean" took about 1.5k out of the 4k flash on the 
device - a single line of C code did pretty much the same job).

In article <slrngbdl0v.2p9.aznomad.3@ip70-176-155-130.ph.ph.cox.net>, 
aznomad.3@PremoveOBthisOX.COM says...
> On Thu, 28 Aug 2008 09:25:23 -0700, Mark Borgerson <mborgerson@comcast.net> wrote:
> >In article <48b6474f$0$25381$8404b019@news.wineasy.se>, 
> >david@westcontrol.removethisbit.com says...
> >> Mark Borgerson wrote:
> >> > In article <Es-dneuLX7SdAyjVnZ2dnUVZ8hidnZ2d@lyse.net>, 
> >> > david.brown@hesbynett.removethisbit.no says...
> >> >> Dombo wrote:
> >> >>> AZ Nomad wrote:
> >> >>>> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <dombo@disposable.invalid> 
> >> >>>> wrote:
> >> >> <snip>
> >> >>>> Maybe with 10ghz of cpu and 20GB of ram vista might run OK, but otherwise
> >> >>>> it's a steaming mountain of pig shit.
> >> >>>>
> >> >>>> And adobe's latest reader runs just fine under linux on my 1.4 ghz laptop
> >> >>>> with a typical 5200rpm laptop drive.  If MS wrote it, you could count 
> >> >>>> on it
> >> >>>> being unable to run on such hardware.
> >> >>> Consider that Adobe needs 100MB hard disk space for just a reader, where 
> >> >>> others can produce a PDF reader that takes less than 1 MB and starts at 
> >> >>> least 10x faster, and you still believe Adobe is producing efficient 
> >> >>> software?
> >> >>>
> >> >>> Ever tried Lotus Notes, or CM Synergy (nowadays both IBM), or Borland 
> >> >>> C++ Builder and still believe Microsoft is the only company that 
> >> >>> produces crap software.
> >> >>>
> >> >> For an example a little closer to the group's topic - Code Worrier for 
> >> >> the Freescale 6805 devices was something like a 600 MB download, and 1 
> >> >> GB install, for a compiler for a device with a couple of KB code space.
> >> >>
> >> > The sise of the IDE has little to do with the size of the code space
> >> > on the target.  The size of the compiler also has little to do with
> >> > the processor code space.
> >> > 
> >> 
> >> That's not entirely true - for a bigger and more powerful target, you 
> >> could expect larger libraries (with corresponding files such as 
> >> documentation), more IDE features (such as a more powerful debugger 
> >> taking advantage of the target's features), etc.  Green Hills for the 
> >> ColdFire, for example, weighs in at about 400 MB - a lot of that is from 
> >> dozens of copies of very large static libraries for each target 
> >> variation.  The actual useful bit of Code Worrier, the compiler, is 
> >> pretty good, but the rest is an impressive quantity of bloat.
> >> 
> 
> 
> >I just took a look at the CodeWarrior demo CD for the ColdFire 
> >architecture.  The total data on the CD was  303MB.   That seems
> >comparable to the Green Hills package---although the 270MB .cab
> >file could expand quite a bit on installation.
> 
> >I still use Codewarrior  8.0 for the PalmOS to compile M68K code
> >for Persistor data loggers.  The Codewarrior folder with the
> >IDE, help files, compiler and libraries is just 88MB.  The HTML
> >help and manuals are about 45MB of the 88MB.  Perhaps this was
> >one of the last pre-bloat versions of Codewarrior.
> 
> >By comparison, the IAR Embedded Workbench for the Arm processor
> >occupies about  435MB of disk space.  Of that, the bin folder
> >is about 35MB, while the doc and examples folders add up
> >to more than 200MB.  The rest goes to libraries, include files,
> >drivers and  about 62MB for a sample version of their PowerPac
> >RTOS.
> 
> 
> >What elements of Codewarrior could be eliminated?   After all one
> >programmer's help files are another's bloat.
> 
> Disk space is irrelevent unless you are running on a 10GB drive which is
> rather silly in this age where 500GB drives sell for $80. Other resources
> are far more important including the memory footprint, number and frequency
> of drive accesses such as to load ten thousand data files needed for
> operation, and lastly cpu usage.  450GB of application just sit on the hard
> drive and really don't matter one bit.
> 
The point about disk spacebeing irrelevant is true---especially if half 
the disk footprint is help files and example code, as is the case with
the IAR system.  I don't see memory footprint as much of an issue
either--when a recent PC ought to be able to malloc()  a
few hundred megabytes  for symbol tables,   etc.

The comment about requiring many files is valid---especially as
a complex C program may require  LOTS of header files.  There's
no reason any particular file should have to be read more than
once, though.  Read it once and cache it in RAM.

My largest embedded programs may get to a few hundred KBytes of
object code.  Compiling them generally takes only a few seconds--
even for a full rebuild, so I don't see CPU usage as a major issue.
This is especially true as my development PC has dual cores---
one of which is sitting idle most of the time anyway.


Mark Borgerson

On Thu, 28 Aug 2008 09:25:23 -0700, Mark Borgerson <mborgerson@comcast.net> wrote:
>In article <48b6474f$0$25381$8404b019@news.wineasy.se>, 
>david@westcontrol.removethisbit.com says...
>> Mark Borgerson wrote:
>> > In article <Es-dneuLX7SdAyjVnZ2dnUVZ8hidnZ2d@lyse.net>, 
>> > david.brown@hesbynett.removethisbit.no says...
>> >> Dombo wrote:
>> >>> AZ Nomad wrote:
>> >>>> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <dombo@disposable.invalid> 
>> >>>> wrote:
>> >> <snip>
>> >>>> Maybe with 10ghz of cpu and 20GB of ram vista might run OK, but otherwise
>> >>>> it's a steaming mountain of pig shit.
>> >>>>
>> >>>> And adobe's latest reader runs just fine under linux on my 1.4 ghz laptop
>> >>>> with a typical 5200rpm laptop drive.  If MS wrote it, you could count 
>> >>>> on it
>> >>>> being unable to run on such hardware.
>> >>> Consider that Adobe needs 100MB hard disk space for just a reader, where 
>> >>> others can produce a PDF reader that takes less than 1 MB and starts at 
>> >>> least 10x faster, and you still believe Adobe is producing efficient 
>> >>> software?
>> >>>
>> >>> Ever tried Lotus Notes, or CM Synergy (nowadays both IBM), or Borland 
>> >>> C++ Builder and still believe Microsoft is the only company that 
>> >>> produces crap software.
>> >>>
>> >> For an example a little closer to the group's topic - Code Worrier for 
>> >> the Freescale 6805 devices was something like a 600 MB download, and 1 
>> >> GB install, for a compiler for a device with a couple of KB code space.
>> >>
>> > The sise of the IDE has little to do with the size of the code space
>> > on the target.  The size of the compiler also has little to do with
>> > the processor code space.
>> > 
>> 
>> That's not entirely true - for a bigger and more powerful target, you 
>> could expect larger libraries (with corresponding files such as 
>> documentation), more IDE features (such as a more powerful debugger 
>> taking advantage of the target's features), etc.  Green Hills for the 
>> ColdFire, for example, weighs in at about 400 MB - a lot of that is from 
>> dozens of copies of very large static libraries for each target 
>> variation.  The actual useful bit of Code Worrier, the compiler, is 
>> pretty good, but the rest is an impressive quantity of bloat.
>> 


>I just took a look at the CodeWarrior demo CD for the ColdFire 
>architecture.  The total data on the CD was  303MB.   That seems
>comparable to the Green Hills package---although the 270MB .cab
>file could expand quite a bit on installation.

>I still use Codewarrior  8.0 for the PalmOS to compile M68K code
>for Persistor data loggers.  The Codewarrior folder with the
>IDE, help files, compiler and libraries is just 88MB.  The HTML
>help and manuals are about 45MB of the 88MB.  Perhaps this was
>one of the last pre-bloat versions of Codewarrior.

>By comparison, the IAR Embedded Workbench for the Arm processor
>occupies about  435MB of disk space.  Of that, the bin folder
>is about 35MB, while the doc and examples folders add up
>to more than 200MB.  The rest goes to libraries, include files,
>drivers and  about 62MB for a sample version of their PowerPac
>RTOS.


>What elements of Codewarrior could be eliminated?   After all one
>programmer's help files are another's bloat.

Disk space is irrelevent unless you are running on a 10GB drive which is
rather silly in this age where 500GB drives sell for $80. Other resources
are far more important including the memory footprint, number and frequency
of drive accesses such as to load ten thousand data files needed for
operation, and lastly cpu usage.  450GB of application just sit on the hard
drive and really don't matter one bit.

In article <48b6474f$0$25381$8404b019@news.wineasy.se>, 
david@westcontrol.removethisbit.com says...
> Mark Borgerson wrote:
> > In article <Es-dneuLX7SdAyjVnZ2dnUVZ8hidnZ2d@lyse.net>, 
> > david.brown@hesbynett.removethisbit.no says...
> >> Dombo wrote:
> >>> AZ Nomad wrote:
> >>>> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <dombo@disposable.invalid> 
> >>>> wrote:
> >> <snip>
> >>>> Maybe with 10ghz of cpu and 20GB of ram vista might run OK, but otherwise
> >>>> it's a steaming mountain of pig shit.
> >>>>
> >>>> And adobe's latest reader runs just fine under linux on my 1.4 ghz laptop
> >>>> with a typical 5200rpm laptop drive.  If MS wrote it, you could count 
> >>>> on it
> >>>> being unable to run on such hardware.
> >>> Consider that Adobe needs 100MB hard disk space for just a reader, where 
> >>> others can produce a PDF reader that takes less than 1 MB and starts at 
> >>> least 10x faster, and you still believe Adobe is producing efficient 
> >>> software?
> >>>
> >>> Ever tried Lotus Notes, or CM Synergy (nowadays both IBM), or Borland 
> >>> C++ Builder and still believe Microsoft is the only company that 
> >>> produces crap software.
> >>>
> >> For an example a little closer to the group's topic - Code Worrier for 
> >> the Freescale 6805 devices was something like a 600 MB download, and 1 
> >> GB install, for a compiler for a device with a couple of KB code space.
> >>
> > The sise of the IDE has little to do with the size of the code space
> > on the target.  The size of the compiler also has little to do with
> > the processor code space.
> > 
> 
> That's not entirely true - for a bigger and more powerful target, you 
> could expect larger libraries (with corresponding files such as 
> documentation), more IDE features (such as a more powerful debugger 
> taking advantage of the target's features), etc.  Green Hills for the 
> ColdFire, for example, weighs in at about 400 MB - a lot of that is from 
> dozens of copies of very large static libraries for each target 
> variation.  The actual useful bit of Code Worrier, the compiler, is 
> pretty good, but the rest is an impressive quantity of bloat.
> 

I just took a look at the CodeWarrior demo CD for the ColdFire 
architecture.  The total data on the CD was  303MB.   That seems
comparable to the Green Hills package---although the 270MB .cab
file could expand quite a bit on installation.

I still use Codewarrior  8.0 for the PalmOS to compile M68K code
for Persistor data loggers.  The Codewarrior folder with the
IDE, help files, compiler and libraries is just 88MB.  The HTML
help and manuals are about 45MB of the 88MB.  Perhaps this was
one of the last pre-bloat versions of Codewarrior.

By comparison, the IAR Embedded Workbench for the Arm processor
occupies about  435MB of disk space.  Of that, the bin folder
is about 35MB, while the doc and examples folders add up
to more than 200MB.  The rest goes to libraries, include files,
drivers and  about 62MB for a sample version of their PowerPac
RTOS.

What elements of Codewarrior could be eliminated?   After all one
programmer's help files are another's bloat.

Mark Borgerson

Michael A. Terrell wrote:
> Dombo wrote:
> 
>>Michael A. Terrell schreef:
>>
>>>Dombo wrote:
>>>
>>>>Michael A. Terrell wrote:
>>>>
>>>>>AZ Nomad wrote:
>>>>>
>>>>>
>>>>>>On Wed, 27 Aug 2008 08:56:39 -0400, Michael A. Terrell <mike.terrell@earthlink.net> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>AZ Nomad wrote:
>>>>>>>
>>>>>>>
>>>>>>>>On Wed, 27 Aug 2008 06:05:09 GMT, przemek klosowski <przemek.klosowski@gmail.nospam> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>On Tue, 26 Aug 2008 06:51:37 +0000, Guy Macon wrote:
>>>>>>>>>
>>>>>>>>>>Perhaps it's just me, but i expect a quad-core 3GHz machine to be able
>>>>>>>>>>to keep up with my typing as well as my Commodore 128 does.
>>>>>>>>>
>>>>>>>>>Software gets slower faster than hardware gets faster.
>>>>>>>>
>>>>>>>>And microsoft does it faster than the chip makers can.
>>>>>>>
>>>>>>>  The ironic thing is Microsoft wrote part of the firmware for the
>>>>>>>Commodore 128.
>>>>>>
>>>>>>no wonder it was a failure.
>>>>>>The probably had something to do with that commadore 64 floating around that
>>>>>>couldn't run any commadore 64 software.
>>>>>
>>>>>
>>>>>   The only case I know of like that was software that used undocumented
>>>>>op codes in the early 6510 CPU.  That isn't Mos Technology, Commodore or
>>>>>Microsoft's fault.  It was the programmer who used codes the 6510 manual
>>>>>told you not to use.
>>>>
>>>>The 6510 (and the 8502 used in the C128) supported the same undocumented
>>>>opcodes during its lifetime. The only real compatibility issue I'm aware
>>>>of involved an undocumented way to play samples on the sound chip, which
>>>>no longer worked with newer revisions of that chip.
>>>
>>>   Sorry, but some production runs of the 6510 didn't support all the
>>>undocumented op codes.  i had a friend who was into graphics, and his
>>>6510 died.  I had to try over a dozen chips to find one that worked with
>>>that program.  Everything else we tried ran on all the other 6510
>>>chips.  I repaired hundreds of c-64 & C128/128D computers at the
>>>component level.
>>
>>Hmmm...this the first time I heard of this (used to be in the c64
>>scene). Especially demo's relied heavily on undocumented features, but
>>nevertheless there were few compatibility issues.
> 
> 
> 
>    I only found two out of over 100 6510 that would run his program.  he
> contacted the software company abut it, and they admitted that it was
> written on a developer's pre production computer, but that they would
> not give him the current version, or even a discount, so RObert
> disassembled the software and re wrote the bad parts to work on any
> 6510.
> 
>  
> 
>>>>>   The Commode 128 was successful enough to spawned the 128D, and the
>>>>>never marketed 256 version that was being manufactured when they were
>>>>>shut down and liquidated.
>>
>>That would be the C65, the few hundred remaining units are nowadays a
>>collectors item which sell for over $1000 on eBay.
>>
>>
>>>>>   BTW, Microsoft wrote the BASIC versions used in most Commodore
>>>>>computers.
>>>>
>>>>With the exception of the Amiga line, all Commodore computers used the
>>>>Microsoft BASIC interpreter, just like many other home computers.
>>>
>>>
>>>   They had different levels though.  When they went from the PET seers,
>>>to the Vic-20, they scaled it way down.  The c-64 was a little better,
>>>but the C128/D was a lot better.
>>
>>The latest PET had BASIC 4.0. The VIC-20 and the C64 used BASIC 2.0,
>>can't think of anything in the C64 BASIC that the VIC-20 didn't have.
> 
>    Try running Basic programs written for the PET on either. They were
> stripped down so their business software won't run on the cheaper 'home'
> models.

Like I said; the PET had BASIC 4.0 where the VIC-20 and C64 had BASIC 
2.0. The most important difference between the two is that BASIC 4.0 
(PET) had disk commands. The advantage of BASIC 2.0 was that it could 
fit with the kernal in just 16 KByte. The VIC-20 and C64 were designed 
(in very short time) to be as cheap as possible, cutting corners where 
possible.

>>Interesting background information about why which basic was chosen for
>>a certain computer and why the C128, unlike earlier models, displayed
>>the Microsoft copyright message can be found in the book "On the Edge -
>>the spectacular rise and fall of Commodore".
>>
>>(comp.sys.cbm would be a better place to discuss this)
> 
> 
> 
>   I used to visit there, but there was very little traffic that wasn't
> cross posted from British Sinclair users.  It had more trolls than
> regulars, so I gave up.
> 
>

Mark Borgerson wrote:
> In article <Es-dneuLX7SdAyjVnZ2dnUVZ8hidnZ2d@lyse.net>, 
> david.brown@hesbynett.removethisbit.no says...
>> Dombo wrote:
>>> AZ Nomad wrote:
>>>> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <dombo@disposable.invalid> 
>>>> wrote:
>> <snip>
>>>> Maybe with 10ghz of cpu and 20GB of ram vista might run OK, but otherwise
>>>> it's a steaming mountain of pig shit.
>>>>
>>>> And adobe's latest reader runs just fine under linux on my 1.4 ghz laptop
>>>> with a typical 5200rpm laptop drive.  If MS wrote it, you could count 
>>>> on it
>>>> being unable to run on such hardware.
>>> Consider that Adobe needs 100MB hard disk space for just a reader, where 
>>> others can produce a PDF reader that takes less than 1 MB and starts at 
>>> least 10x faster, and you still believe Adobe is producing efficient 
>>> software?
>>>
>>> Ever tried Lotus Notes, or CM Synergy (nowadays both IBM), or Borland 
>>> C++ Builder and still believe Microsoft is the only company that 
>>> produces crap software.
>>>
>> For an example a little closer to the group's topic - Code Worrier for 
>> the Freescale 6805 devices was something like a 600 MB download, and 1 
>> GB install, for a compiler for a device with a couple of KB code space.
>>
> The sise of the IDE has little to do with the size of the code space
> on the target.  The size of the compiler also has little to do with
> the processor code space.
> 

That's not entirely true - for a bigger and more powerful target, you 
could expect larger libraries (with corresponding files such as 
documentation), more IDE features (such as a more powerful debugger 
taking advantage of the target's features), etc.  Green Hills for the 
ColdFire, for example, weighs in at about 400 MB - a lot of that is from 
dozens of copies of very large static libraries for each target 
variation.  The actual useful bit of Code Worrier, the compiler, is 
pretty good, but the rest is an impressive quantity of bloat.

In article <Es-dneuLX7SdAyjVnZ2dnUVZ8hidnZ2d@lyse.net>, 
david.brown@hesbynett.removethisbit.no says...
> Dombo wrote:
> > AZ Nomad wrote:
> >> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <dombo@disposable.invalid> 
> >> wrote:
> <snip>
> >> Maybe with 10ghz of cpu and 20GB of ram vista might run OK, but otherwise
> >> it's a steaming mountain of pig shit.
> >>
> >> And adobe's latest reader runs just fine under linux on my 1.4 ghz laptop
> >> with a typical 5200rpm laptop drive.  If MS wrote it, you could count 
> >> on it
> >> being unable to run on such hardware.
> > 
> > Consider that Adobe needs 100MB hard disk space for just a reader, where 
> > others can produce a PDF reader that takes less than 1 MB and starts at 
> > least 10x faster, and you still believe Adobe is producing efficient 
> > software?
> > 
> > Ever tried Lotus Notes, or CM Synergy (nowadays both IBM), or Borland 
> > C++ Builder and still believe Microsoft is the only company that 
> > produces crap software.
> > 
> 
> For an example a little closer to the group's topic - Code Worrier for 
> the Freescale 6805 devices was something like a 600 MB download, and 1 
> GB install, for a compiler for a device with a couple of KB code space.
> 
The sise of the IDE has little to do with the size of the code space
on the target.  The size of the compiler also has little to do with
the processor code space.


Mark Borgerson