Re: [ECOS] Port to c166 / c165 utah cpu

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Roland" == Roland =?iso-8859-1?q?Ca=DFebohm?= <Roland> writes:

    Roland> On Montag, 25. November 2002 10:24, Peter Vandenabeele wrote:
    >> On Mon, Nov 25, 2002 at 05:02:50PM +1300, Geoffrey Cant wrote:
    >> > Hi there, I'm looking for any information regarding a port of eCos to the
    >> > Infineon/siemens c166 or c165 utah processors. In the archives there
    >> > seems to be one email from 1999 about a c166 port and I'm wondering if
    >> > anything came of it.
    >> >
    >> > If anyone has any information about eCos and c165 chips they could send
    >> > me, that would be great.
    >> 
    >> Dear Geoff,
    >> 
    >> The c165 Utah chip is a 16 bit microcontroller
    >> (e.g.
    >> http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/prod_ov.jsp?oid=13746)
    >> 
    >> To my best knowledge, eCos is only available for 32 bit processors.
    >> 
    >> Sincerely,
    >> 
    >> Peter Vandenabeele

    Roland> Is it possible to port eCos to a 16 bit processor?

This rather depends on how you define "16 bit processor". does the
16bit refer to sizeof(int) ? sizeof(void*) ? The width of the external
data bus?

The first requirement is a gcc port, with ELF as the object format.
There are many gcc dependencies in the eCos source code, and some of
the tricks done at link-time depend on functionality that is currently
only really available if you use ELF. Some parts of eCos also depend
on 32-bit arithmetic, and in places 64-bit arithmetic (e.g. kernel
counters).

If sizeof(int) == 16bits, but sizeof(long) == 32 bits and sizeof(long
long) == 64 bits then much of the eCos code should be ok. For example
the kernel makes extensive use of types like cyg_int32 and the
processor-specific HAL package can define that as a long. However
there may well be places where a plain int is used rather than a
cyg_int32, and tracking down all those places could take a while. Of
particular concern would be imported code like the TCP/IP stacks.

There may be efficiency issues. Some code may use cyg_int32 where a
plain int or a cyg_count16 would suffice. Tracking down all such
places would be more difficult than incorrect uses of int, because the
existing code would still work.

If sizeof(void*) == 16bits then things get more interesting. Is the
address space really limited to 64K? Does the processor have some sort
of memory bank support, or 8086-style segment registers? Are there
separate address spaces for code and data? eCos code generally assumes
a simple linear address space, any divergence from that is likely to
cause problems.

So it depends very much on the specific processor. It should be
possible to port eCos to some 16-bit processors, but not all.

Bart

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss