On 03/26/2015 04:12 PM, Peter Dufault wrote:
On Mar 23, 2015, at 16:23 , Sebastian Huber<sebastian.hu...@embedded-brains.de>
wrote:
----- Am 23. Mrz 2015 um 16:51 schrieb Gedare Bloom ged...@gwu.edu:
I guess this is a problem for 16-bit targets? changing the constants
to 16UL and 8UL also should work. A comment should be made that this
is only for 16-bit targets. If we rid RTEMS of those, we can get rid
of some of these shenanigans...
It would be interesting to know if we have at least one real application
running RTEMS on a 16-bit target. Apart from warning fixes I don't see any
activity in this area.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Late answer, I'm catching up on old e-mails.
I think if 16 bit Harvard architecture (64K instruction / 64K data) targets are
no longer supportable then 16 bit should be deprecated and then abandoned. If
you can still do a lot with RTEMS in 128K then that useful subset of the code
should be identified and kept 16 bit clean, that would be a good requirement on
developers and that part of the code base.
That is, if anyone wants to do that, I currently use 4MB instruction / 4MB data
as my minimal targets that can be comfortably extended during the support life
time (I want TCP/IP and NFS as part of my minimum, your mileage will definitely
vary).
The original target platform for RTEMS was 1MB RAM that was used for
everything.
I still think this is a very reasonable memory profile for most
applications.
I am not sure if the 64K instruction/data is that useful but 16-bit
architectures are
not necessarily limited to 64K address spaces. We all remember the 8086 and
variants. The m32c has 24 bit address space.
I don't know the requirements for what I used to frequently call
Tiny/RTEMS.
If you have a 20+ bit address space, then there isn't much of a code
size issue.
There will be combinations of code that just won't fit. I expect the new
TCP/IP
stack to be a casualty there. But the old TCP/IP stack worked quite well in
a 1MB environment and I would expect LWIP to do even better.
So my focus is just on being 16-bit integer clean. I don't think we will
shrink
into the smallest AVR CPU models but something like an 8086 in large memory
model or an m32c shouldn't be an issue for most of RTEMS.
But yes.. we should have some insight into which features are hopeless in
a 16-bit integer environment and maybe some idea of what is really too
small.
Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
-- Joel Sherrill
Ask me about RTEMS: a free RTOS
Support and Training Available
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
