<tusunov@my-deja.com> wrote in message 
news:1150734201.723432.142010@h76g2000cwa.googlegroups.com...

>> Eh, where do you get the 8x codesize expansion from? The average
>> instruction size of Thumb is around 20 bits. For 6502 it is slightly
>> under 16 bits. Considering you need many 6502 instructions to do the
>> same work, ARM wins big time on codesize. The same is true for
>> other 8-bit CPUs.
>
> if the difference is so small does this means that you can fit the
> Applesoft interpterer in 10K code for ARM? I doubt

I don't see why not, you can do a lot in 10KB of code, and AppleSoft
wasn't that large compared to BBC BASIC. It would need to be done
in assembler as the code was likely highly compressed. Performance
was a dirty word at the time, anything was done to save a few bytes.

A perfect illustration of this is Steve Wozniac's floating point code
http://www.6502.org/source/floats/wozfp3.txt (part of the Apple II ROM).
At 114 instructions and 212 bytes for 32-bit float add/sub/mul/div it is
amazingly small. However don't ask how many thousand cycles each
operation could take, why it doesn't round at all, etc.

My point is that you can trade performance and functionality for codesize.
On 32-bit CPUs people choose for more functionality (eg. IEEE 754) and
much higher performance and only pay a modest cost in terms of codesize.
The tradeoffs are simply different.

Wilco

On 19 Jun 2006 09:23:21 -0700, tusunov@my-deja.com wrote:

>> You clearly haven't ever used ARM or 6502. A typical ARM instruction
>> does the work of many 6502 instructions. Eg ADDEQ r0,r1,r2,LSL #2
>> does a branch, a shift, an add and a move.
>
>sure, I admit that I never wrote anything in ARM assembler, and I'm not
>familiar with ARM instructions, but I wrote a lot of assembly code for
>6502 on the old Apple ][
>
>> Eh, where do you get the 8x codesize expansion from? The average
>> instruction size of Thumb is around 20 bits. For 6502 it is slightly
>> under 16 bits. Considering you need many 6502 instructions to do the
>> same work, ARM wins big time on codesize. The same is true for
>> other 8-bit CPUs.
>
>if the difference is so small does this means that you can fit the
>Applesoft interpterer in 10K code for ARM? I doubt
>

It would be better to comapre sizes of BBC basic. Versions coded in
both 6502 and ARM exists. The ARM versions have quite a few extentions
compared to the 6502 versions.  AFAICR the actual interpreter fit
inside the 16K cache of the ARM on the various Acorn machines. This
allowed for quite fast execution of Basic programs.

Regards
  Anton Erasmus

> You clearly haven't ever used ARM or 6502. A typical ARM instruction
> does the work of many 6502 instructions. Eg ADDEQ r0,r1,r2,LSL #2
> does a branch, a shift, an add and a move.

sure, I admit that I never wrote anything in ARM assembler, and I'm not
familiar with ARM instructions, but I wrote a lot of assembly code for
6502 on the old Apple ][

> Eh, where do you get the 8x codesize expansion from? The average
> instruction size of Thumb is around 20 bits. For 6502 it is slightly
> under 16 bits. Considering you need many 6502 instructions to do the
> same work, ARM wins big time on codesize. The same is true for
> other 8-bit CPUs.

if the difference is so small does this means that you can fit the
Applesoft interpterer in 10K code for ARM? I doubt

Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb (http://www.olimex.com/pcb)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430
(http://www.olimex.com/dev)

>
> this is why ARMs are much memory hungry and with the $2 worth  32K
> Flash memory ARM part you can't do what you can do on old 6502 with 4K
> ROM :)

I think you can probably write a 6502 emulator in much less than 32 kB...

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB 

<tusunov@my-deja.com> wrote in message 
news:1150627866.719795.231980@y41g2000cwy.googlegroups.com...

> David M. Palmer ??????:
>
>> I may be an old fogey, but I remember when computers came with a 4k ROM
>> for integer BASIC or 8k for floating-point BASIC (and we LIKED it!).
>> An adequate, if stripped down, floating point library shouldn't require
>> 50k.

Indeed. It depends all on your performance requirements and what
exactly you include. With all math.h functions in both single and double
precision 50KB is about right. If you exclude the maths functions then
you end up with about 10KB. A fast float-only lib containing add, mul,
div, compare takes less than 4KB, a slow one can be done in 1KB.

> haha yeah the old times, 1Mhz 8-bit 6502 with 8K for Applisoft basic,
> but ARM is 32 bit architecture and 16/32 bit instructions on top of
> this is RISC i.e. what you do on 6502 with one assembly instruction
> will take few ARM RISC instruction to do

You clearly haven't ever used ARM or 6502. A typical ARM instruction
does the work of many 6502 instructions. Eg ADDEQ r0,r1,r2,LSL #2
does a branch, a shift, an add and a move.

> this is why ARMs are much memory hungry and with the $2 worth  32K
> Flash memory ARM part you can't do what you can do on old 6502 with 4K
> ROM :)

Eh, where do you get the 8x codesize expansion from? The average
instruction size of Thumb is around 20 bits. For 6502 it is slightly
under 16 bits. Considering you need many 6502 instructions to do the
same work, ARM wins big time on codesize. The same is true for
other 8-bit CPUs.

Wilco 

linnix wrote:
> 
... snip ...
> 
> Yes, ARM7 or 9 would be a better choice.  30MHz would be tight and
> fitting a floating point C library in 50 K is impossible.  Don't know
> about asm, and never want to try anyway.  I would settle with 50MHz
> 128K flash.

Back in 8080 days I could fit a complete FP library, with i/o and
transcendentals etc, into 2k of object code.  You can find an early
version of the source in the DDJ archives, March and April, 1979.

Apart from the actual i/o routines, the code was fully re-entrant.

-- 
 "A man who is right every time is not likely to do very much."
                           -- Francis Crick, co-discover of DNA
 "There is nothing more amazing than stupidity in action."
                                             -- Thomas Matthews

David M. Palmer =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:

> I may be an old fogey, but I remember when computers came with a 4k ROM
> for integer BASIC or 8k for floating-point BASIC (and we LIKED it!).
> An adequate, if stripped down, floating point library shouldn't require
> 50k.

haha yeah the old times, 1Mhz 8-bit 6502 with 8K for Applisoft basic,
but ARM is 32 bit architecture and 16/32 bit instructions on top of
this is RISC i.e. what you do on 6502 with one assembly instruction
will take few ARM RISC instruction to do
this is why ARMs are much memory hungry and with the $2 worth  32K
Flash memory ARM part you can't do what you can do on old 6502 with 4K
ROM :)

Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb (http://www.olimex.com/pcb)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430
(http://www.olimex.com/dev)

linnix schrieb:
> Andreas Schwarz wrote:
>> linnix schrieb:
>>> bmearns wrote:
>>>> I'm looking for code for any of Microchip's dsPICs that will decode an
>>>> MP3 file stream into PCM data. C is preferable, but asm will work fine,
>>>> as well.
>>>>
>>>> Does anyone have any leads on this?
>>>> Thanks.
>>> Sure, just need a PIC with 500K program space, 50MHz for mono and 80MHz
>>> for stereo.  Of course, float point multiplers are needed as well.
>> No, even an ARM7TDMI with ~30 MHz and 50 kB ROM can decode MP3.
> 
> Yes, ARM7 or 9 would be a better choice.  30MHz would be tight and
> fitting a floating point C library in 50 K is impossible.  Don't know
> about asm, and never want to try anyway.  I would settle with 50MHz
> 128K flash.

Decoding MP3 with software floating point is impossible, you need an
optimized fixed point decoder like Helix
(https://datatype.helixcommunity.org/mp3dec). 30 MHz and 50 kB is enough
 for the decoder itself, to do something useful with it you need a bit
more of course.

On Sat, 17 Jun 2006 19:25:04 -0600, "David M. Palmer"
<dmpalmer@email.com> wrote:

>In article <1150583554.893825.313680@c74g2000cwc.googlegroups.com>,
>linnix <me@linnix.info-for.us> wrote:
>
>> Andreas Schwarz wrote:
>> > linnix schrieb:
>> > > bmearns wrote:
>> > >> I'm looking for code for any of Microchip's dsPICs that will decode an
>> > >> MP3 file stream into PCM data. C is preferable, but asm will work fine,
>> > >> as well.
>> > >>
>> > >> Does anyone have any leads on this?
>> > >> Thanks.
>> > >
>> > > Sure, just need a PIC with 500K program space, 50MHz for mono and 80MHz
>> > > for stereo.  Of course, float point multiplers are needed as well.
>> >
>> > No, even an ARM7TDMI with ~30 MHz and 50 kB ROM can decode MP3.
>> 
>> Yes, ARM7 or 9 would be a better choice.  30MHz would be tight and
>> fitting a floating point C library in 50 K is impossible.  Don't know
>> about asm, and never want to try anyway.  I would settle with 50MHz
>> 128K flash.
>
>I may be an old fogey, but I remember when computers came with a 4k ROM
>for integer BASIC or 8k for floating-point BASIC (and we LIKED it!). 
>An adequate, if stripped down, floating point library shouldn't require
>50k.
>

You could always have a look at http://yampp.com/

Alan

>On the other hand, I believe I've seen a design article for a PIC (or
>similar class) MP3 player.  Decoding was done by a dedicated commercial
>MP3 ASIC.

--
Sell your surplus electronic components at 
http://ozcomponents.com
Search or browse for that IC, capacitor,
crystal or other component you need.

In article <1150583554.893825.313680@c74g2000cwc.googlegroups.com>,
linnix <me@linnix.info-for.us> wrote:

> Andreas Schwarz wrote:
> > linnix schrieb:
> > > bmearns wrote:
> > >> I'm looking for code for any of Microchip's dsPICs that will decode an
> > >> MP3 file stream into PCM data. C is preferable, but asm will work fine,
> > >> as well.
> > >>
> > >> Does anyone have any leads on this?
> > >> Thanks.
> > >
> > > Sure, just need a PIC with 500K program space, 50MHz for mono and 80MHz
> > > for stereo.  Of course, float point multiplers are needed as well.
> >
> > No, even an ARM7TDMI with ~30 MHz and 50 kB ROM can decode MP3.
> 
> Yes, ARM7 or 9 would be a better choice.  30MHz would be tight and
> fitting a floating point C library in 50 K is impossible.  Don't know
> about asm, and never want to try anyway.  I would settle with 50MHz
> 128K flash.

I may be an old fogey, but I remember when computers came with a 4k ROM
for integer BASIC or 8k for floating-point BASIC (and we LIKED it!). 
An adequate, if stripped down, floating point library shouldn't require
50k.

On the other hand, I believe I've seen a design article for a PIC (or
similar class) MP3 player.  Decoding was done by a dedicated commercial
MP3 ASIC.

-- 
David M. Palmer  dmpalmer@email.com (formerly @clark.net, @ematic.com)