[PATCH] score: Remove support for RTEMS_USE_16_BIT_OBJECT

[Sebastian Huber]

----- Am 17. Nov 2018 um 2:02 schrieb Chris Johns chrisj at rtems.org:

> On 16/11/18 5:08 pm, Sebastian Huber wrote:
>> The RTEMS_USE_16_BIT_OBJECT define is not set by an RTEMS port.  Remove
>> support for 16-bit object identifiers.  If someone really wants to use
>> RTEMS on a 16-bit target, then it is better to use self-contained
>> objects instead of playing around with object identifier optimizations.
> 
> Are self-contained threads supported?

Self-contained threads are not yet supported. There are some steps left to realize them.

One issue is that the existing APIs using a thread ID should also work with threads without a normal object ID. We could remove one bit from the object class field and use it to indicate if the ID is a normal object ID or a pointer (the pointer address must be at least 2-byte aligned). In case the normal lookup fails, then we check the bit and if it set, then we assume it is a pointer to a TCB.

Another problem is that the TCB has a configuration defined size. We could layout self-contained threads like this:

TCP
space for configuration defined TCB content
space for thread-local storage (size defined at link-time)
space for POSIX key value pairs
space for stack

#define RTEMS_THREAD_DEFINE(name, size)
struct {
  Thread_Control TCB;
  char space[size];
} _Thread_Object_##name;
static const Thread_Configuration _Thread_Config_##name = {
  .name = #name,
  .object = &_Thread_Object_##name.TCB,
  .size = size
};
RTEMS_ROSET_ITEM(_Threads, &_Thread_Config_##name)

The threads need a static constructor, if the allocated size is too small, then we issue a fatal error.

I think we should move the POSIX key value pairs to thread-specific storage (for example at the end of the stack area, a stack overflow would then first hit the POSIX key values of the same thread) for SMP performance reasons and memory management issues with the free list which is currently used.