AZ Nomad wrote:
> On Wed, 27 Aug 2008 16:09:37 +0200, Dombo <i...@invalid.invalid> wrote:
> 
>>AZ Nomad wrote:
>>
>>>On Wed, 27 Aug 2008 14:55:27 +0200, Dombo <i...@invalid.invalid> wrote:
>>>
>>>
>>>
>>>>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?
>>>
>>>
>>>Go downtown with a guitar and a bucket.
>>>Maybe somebody will toss you the penny that 100MB costs.  Actually,
>>>you'll have 2/3rds of the penny left to buy another 200MB.
>>>
>>>Newsflash:  files on a hard drive do not every one of them get loaded for
>>>an application to function.  Stuff like help files, drm-shit, infrequently
>>>used functions just sit on the hard drive until the user needs them.
>>>
>>>Adobe reader runs fine and fast on a 1.4mhz laptop.  
>>>
>>>Are you still using a 200mhz P1 as your main desktop?  
> 
> 
>>You missed the point entirely, but I guess that should have been 
>>expected. Maybe you understand when you grow up.
> 
> 
> Actually, it was you who missed the point.  I was pointing that vista is
> dog slow on the fastest hardware and you pointed out that linux is
> bloated as well.  I mentioned that linux works just fine on hardware
> 1/4th as fast as current machines, and you pulled out bullshit story
> about adobe being bloated.  
> 
> Maybe on a 200mhz P1, it is too bloated to run.  Compare that to vista
> that is too bloated to run worth a shit on a 6ghz 2gb machine.

You claimed that only Microsoft produces inefficient software, and that 
all other companies use OO programming (why should I care as a user?) 
and produce more efficient software. If that were true that would be 
nice, I would only have to avoid Microsoft and I get good quality and 
efficient software. Unfortunately the reality isn't that simple, and 
Microsoft far from the only sinner.

When confronted with counter examples, your argument is that bloat isn't 
a problem (except apparently when it is from Microsoft). Funny comming 
from someone posting in in an embedded newsgroup, where in a typcial 
embedded project every penny counts and throwing more powerful hardware 
isn't often an option.

Anyway when I replace my desktop machine (which is already much more 
powerful than your '1.4mhz laptop') with a machine that has at least 
twice the processing power, I expect it to be at least as responsive as 
the machine it replaces, not slower. I guess I'm funny that way.

> You're just argueing for the sake of argueing.
> Kplonk>

The equivalent of putting your fingers in your ears and shouting 'nah, 
nah, I can't hear you'. Very mature.

Dombo wrote:
> AZ Nomad wrote:
>> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <d...@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.

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 <m...@earthlink.net> wrote:
>>>>
>>>>
>>>>> AZ Nomad wrote:
>>>>>
>>>>>> On Wed, 27 Aug 2008 06:05:09 GMT, przemek klosowski <p...@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.

>>>    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. 
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)

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 <m...@earthlink.net> wrote:
> >>>>
> >>>>
> >>>>> AZ Nomad wrote:
> >>>>>
> >>>>>> On Wed, 27 Aug 2008 06:05:09 GMT, przemek klosowski <p...@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.


> 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.


-- 
http://improve-usenet.org/index.html

aioe.org, Goggle Groups, and Web TV users must request to be white
listed, or I will not see your messages.

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm


There are two kinds of people on this earth:
The crazy, and the insane.
The first sign of insanity is denying that you're crazy.

In article <E...@lyse.net>, 
d...@hesbynett.removethisbit.no says...
> Dombo wrote:
> > AZ Nomad wrote:
> >> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <d...@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

Mark Borgerson wrote:
> In article <E...@lyse.net>, 
> d...@hesbynett.removethisbit.no says...
>> Dombo wrote:
>>> AZ Nomad wrote:
>>>> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <d...@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.

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 <m...@earthlink.net>
wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>AZ Nomad wrote:
>>>>>>>
>>>>>>>
>>>>>>>>On Wed, 27 Aug 2008 06:05:09 GMT, przemek klosowski
<p...@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.
> 
> 

In article <48b6474f$0$25381$8...@news.wineasy.se>, 
d...@westcontrol.removethisbit.com says...
> Mark Borgerson wrote:
> > In article <E...@lyse.net>, 
> > d...@hesbynett.removethisbit.no says...
> >> Dombo wrote:
> >>> AZ Nomad wrote:
> >>>> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <d...@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

On Thu, 28 Aug 2008 09:25:23 -0700, Mark Borgerson <m...@comcast.net> wrote:
>In article <48b6474f$0$25381$8...@news.wineasy.se>, 
>d...@westcontrol.removethisbit.com says...
>> Mark Borgerson wrote:
>> > In article <E...@lyse.net>, 
>> > d...@hesbynett.removethisbit.no says...
>> >> Dombo wrote:
>> >>> AZ Nomad wrote:
>> >>>> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <d...@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 <s...@ip70-176-155-130.ph.ph.cox.net>, 
a...@PremoveOBthisOX.COM says...
> On Thu, 28 Aug 2008 09:25:23 -0700, Mark Borgerson <m...@comcast.net> wrote:
> >In article <48b6474f$0$25381$8...@news.wineasy.se>, 
> >d...@westcontrol.removethisbit.com says...
> >> Mark Borgerson wrote:
> >> > In article <E...@lyse.net>, 
> >> > d...@hesbynett.removethisbit.no says...
> >> >> Dombo wrote:
> >> >>> AZ Nomad wrote:
> >> >>>> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <d...@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