Op 14-Oct-11 15:13, ian.okey@gmail.com schreef:
> "I do not see the need for a business case or return on investment."
> Most compiler vendors like to eat and do not want to live in cardboard boxes by the side of the road!

I doubt that there are many projects on sourceforge.net that have a 
solid business case.

"I do not see the need for a business case or return on investment."
Most compiler vendors like to eat and do not want to live in cardboard boxes by the side of the road!

Am 12.10.2011 10:34, schrieb ian.okey@gmail.com:
> Why would someone put the effort into creating a new standards
> compliant C compiler now?  What is the business case?  There are many
> more lucrative processor architectures around now that will give the
> compiler makers a good return on their investment.  Rabbit are
> unlikely to fund its development as they have their own, non
> compliant tools that lock developers into using their devices.

I do not see the need for a business case or return on investment.
They might make it slightly more likely that some software gets written,
but that's it.

> The number of times that I have had to move up through processor
> families to support more functionality on later generation products
> makes me very wary about locking in to some proprietary
> processor/language combination that limits my porting options.

Well, there already is the SoftTools compiler claiming standard
conformance. And while the sdcc Rabbit backend is still lacking support
for an address space larger than 64K, it otherwise does quite well.

Philipp

Why would someone put the effort into creating a new standards compliant C =
compiler now?  What is the business case?  There are many more lucrative pr=
ocessor architectures around now that will give the compiler makers a good =
return on their investment.  Rabbit are unlikely to fund its development as=
 they have their own, non compliant tools that lock developers into using t=
heir devices.

The number of times that I have had to move up through processor families t=
o support more functionality on later generation products makes me very war=
y about locking in to some proprietary processor/language combination that =
limits my porting options.

On 10/8/2011 5:09 PM, hamilton wrote:
> On 10/8/2011 8:38 AM, Philipp Klaus Krause wrote:
>> Am 07.10.2011 22:28, schrieb Jim Granville:
>>
>>>
>>> What peripheral features are there that have you looking at Rabbit ?
>>
>> I'm not looking at the Rabbit for a concrete project. I'm a sdcc
>> developer
>
> How about concentrating on newer and more classy processors.
>
> Z80 is dead, dead, dead.
>
> Yes, and I am sure you can create a compiler for the 8051 family as well.
>
> Dead, dead, dead

I wouldn't write-off either of those families prematurely.
They are reasonably small cores so easy to place in an FPGA.
Certainly more appealing than designing you own core and then
having to write a set of tools to develop for it!

E.g., the military still uses 6502 based designs (or, at least,
they seem to express an unusual interest in that skillset!).
I'm pretty sure there was a rad-hardened 8080 (or 85?) many
years *after* the 808x had retired.

Some of these older designs scaled to today's technology would
be really speedy little devices!

Am 09.10.2011 02:09, schrieb hamilton:
> On 10/8/2011 8:38 AM, Philipp Klaus Krause wrote:
>> Am 07.10.2011 22:28, schrieb Jim Granville:
>>
>>>
>>> What peripheral features are there that have you looking at Rabbit ?
>>
>> I'm not looking at the Rabbit for a concrete project. I'm a sdcc
>> developer
> 
> How about concentrating on newer and more classy processors.
> 
> Z80 is dead, dead, dead.

Our Z80 backen has quite some users, I think it's the second most
popular. Z80 softcores are alive.

> 
> Yes, and I am sure you can create a compiler for the 8051 family as well.
> 
> Dead, dead, dead
>

Our 8051 backend is probably the one with the most users.

Philipp

On 10/8/2011 8:38 AM, Philipp Klaus Krause wrote:
> Am 07.10.2011 22:28, schrieb Jim Granville:
>
>>
>> What peripheral features are there that have you looking at Rabbit ?
>
> I'm not looking at the Rabbit for a concrete project. I'm a sdcc
> developer

How about concentrating on newer and more classy processors.

Z80 is dead, dead, dead.

Yes, and I am sure you can create a compiler for the 8051 family as well.

Dead, dead, dead



  wondering how many users (and what type and which features
> they most care about) there would be for our Rabbit 2000/3000 backend,
> that will probably be ready for the 3.1.0 release.
>
> Philipp

Am 07.10.2011 22:28, schrieb Jim Granville:

> 
> What peripheral features are there that have you looking at Rabbit ?

I'm not looking at the Rabbit for a concrete project. I'm a sdcc
developer wondering how many users (and what type and which features
they most care about) there would be for our Rabbit 2000/3000 backend,
that will probably be ready for the 3.1.0 release.

Philipp

On Oct 7, 9:49=A0am, Philipp Klaus Krause <p...@spth.de> wrote:
> Are the Rabbits (Rabbit 2000 / 3000 / 3000A / 4000 / 5000 / 6000) still
> common in embedded systems? Do you happen to know if they tend to be
> chosen for new projects? If yes, which of the Rabbits are the most popula=
r?

A quick web scan finds they have a lot of modules, but Distributor
stocking of the chips thins out.
The R4000 shows just 40 in stock, and no sign of the R5000 or R6000.
The R2/3000 look popular (1000+ in stock at Mouser)

Usually devices like this self-selects, mainly on peripherals not
core.
At one time, if you needed a LOT of serial ports, Rabbit made sense.
Or, if you wanted modules, ready to go, and were not price-
sensitive...

What peripheral features are there that have you looking at Rabbit ?

Hi Philipp,

On 10/7/2011 11:48 AM, Philipp Klaus Krause wrote:
> Am 07.10.2011 20:18, schrieb Don Y:
>> On 10/7/2011 7:00 AM, ian.okey@gmail.com wrote:
>>> With all of the other processor architectures out there now,
>>> IMHO there are many better than the Rabbit.
>>
>> +42
>>
>> Unless, of course, you're developing a dead-end product that
>> you'll never need to port to a new platform, etc. (i.e.,
>> where *this* choice has no long term consequences).
>>
>> Ask yourself why you *aren't* looking at, e.g., an ARM-based
>> solution.  At least the code you write will be portable at the
>> *source* level (even if the hardware complement differs)
>
> But isn't source code portability just a tools issue that will go away
> when a standard-compliant C compiler for the Rabbit becomes available?

(some of) Dynamic C's features aren't compliant.  So, if you *use*
those features, your code won't be portable.  IME, the effort required
to remove non-portable features from an implementation is often
considerable and error-prone.  The more "involved" the features
become with the operation of the code itself, the greater the
cost/risk.

That's not to say it isn't "do-able"... just another cost
that you have to consider.  But, keep in mind, when it comes to
the reuse issues that are implicit in the thinking behind
"Model 2" of a product, a big issue is the assumption/belief
that there will be extra development economies realized because
"We can *just* reuse most of the code from Model 1".

I try to religiously avoid compiler-specific "extensions" in
my sources.  Any "special tweeks" are moved into header files
or "accessory functions" that provide interfaces, e.g., between
assembly language portions of the system and HLL portions
(i.e., *knowing* that these will have to be rewritten for a
new compiler... but *only* these!)