Hello Karel,
with 32KiB RTEMS will only run with a careful chosen configuration. The POSIX
threads use 8KiB stack by default on ARM, so you run quickly out of memory if
you use this.
Please have a look at the Configuration global variable with the debugger. It
tells you the size estimates
Hello,
there was some lobbying against the deprecation of the i386 support of GCC:
http://gcc.gnu.org/ml/gcc/2012-12/msg00132.html
Is this really justified? Why does the RTEMS project need the i386? We should
not make the life of GCC developers harder than necessary.
--
Sebastian Huber, em
I don't care about the i386 in particular but no on addressed my concern about
setting a precedent for other architectures such as m68k which may not have
desirable instructions in low models. Even SPARC V7 is questionable if you must
have atomic instructions to stay in GCC.
Sebastian Huber wr
The i386 is a bit special since x86 is the GCC main stream architecture. I
asked this out of curiosity. Is there really some working i386 hardware around
with RTEMS on it?
On 2013-08-12 13:52, Joel Sherrill wrote:
I don't care about the i386 in particular but no on addressed my concern about
I couldn't find any pure i386 applications when I asked last time. That was for
dropping soft float support. My concern was use of space hardened i386 and
non-Intel cpus like the Geode which might effectively be i386.
I understand on x86 but don't want this to turn into a general minimum
requir
Hello Sebastian,
thanks for your note, I've already disabled POSIX and changed ticker
Init.c configuration with information taken from minimal sample to:
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_MAXIMUM_TASKS
On 2013-08-12 14:44, Karel Gardas wrote:
Hello Sebastian,
thanks for your note, I've already disabled POSIX and changed ticker Init.c
configuration with information taken from minimal sample to:
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVE
the organization and naming of the sptests is a mess to figure out
what tests are testing. i think there was some effort by the testing
framework student last year to work on this spaghetti of test cases..
I much prefer at the very least to give the test a meaningful name as
Sebastian suggested wit
Good work Zhongwei! This was a good effort and will be useful for many
in the future. I hope you can find other little RTEMS projects to work
on as your time and interest permits.
-Gedare
On Sun, Aug 4, 2013 at 8:23 PM, Ashi wrote:
> Here is the patch created by git format-patch.
>
> Cheers,
> Z
Is anything lost by going to POSIX threads in GCC?
On Fri, Aug 9, 2013 at 3:06 AM, Chris Johns wrote:
> Hi,
>
> The patch attached changes the RTEMS thread model in GCC from 'rtems' to
> 'posix'. The patch also fixes the include paths for newlib so the correct
> 'machine/_types.h' is picked up.
>
On Fri, Aug 9, 2013 at 2:35 AM, Sebastian Huber
wrote:
> @@ -59,10 +60,12 @@ void _Scheduler_Handler_initialization( void );
> *
> * This kernel routine implements the scheduling decision logic for
> * the scheduler. It does NOT dispatch.
> + *
> + * @param[in] thread The thread which state
On 2013-08-12 16:11, Gedare Bloom wrote:
On Fri, Aug 9, 2013 at 2:35 AM, Sebastian Huber
wrote:
@@ -59,10 +60,12 @@ void _Scheduler_Handler_initialization( void );
*
* This kernel routine implements the scheduling decision logic for
* the scheduler. It does NOT dispatch.
+ *
+ * @para
On Mon, Aug 12, 2013 at 9:12 AM, Sebastian Huber
wrote:
> On 2013-08-12 16:11, Gedare Bloom wrote:
>>
>> On Fri, Aug 9, 2013 at 2:35 AM, Sebastian Huber
>> wrote:
>>
>>>
>>> @@ -59,10 +60,12 @@ void _Scheduler_Handler_initialization( void );
>>>*
>>>* This kernel routine implements the s
What about the cost of stacking an argument which is not used often?
Just wondering...
--Wendell
2013/8/12 Sebastian Huber
> On 2013-08-12 16:11, Gedare Bloom wrote:
>
>> On Fri, Aug 9, 2013 at 2:35 AM, Sebastian Huber
>> >
>> wrote:
>>
>>
>>> @@ -59,10 +60,12 @@ void _Scheduler_Handler_**ini
On 08/12/2013 03:41 PM, Gedare Bloom wrote:
Is anything lost by going to POSIX threads in GCC?
RTEMS has been using native RTEMS threads in GCC.
The purpose of this had been:
- Avoiding to have POSIX support hard-wired into RTEMS.
- Code Size (RTEMS POSIX threads are wrappers around RTEMS thre
On 08/12/2013 09:57 AM, Sebastian Huber wrote:
Hello,
there was some lobbying against the deprecation of the i386 support of GCC:
http://gcc.gnu.org/ml/gcc/2012-12/msg00132.html
Is this really justified? Why does the RTEMS project need the i386? We
should not make the life of GCC developers
On 8/12/2013 8:41 AM, Gedare Bloom wrote:
Is anything lost by going to POSIX threads in GCC?
Maintaining our own specific glue? :)
Seriously, this will just mean you have to have POSIX enabled
to have C++ run-time supported. This is the same as Ada now
and some TCP/IP servers.
Can this pthread
Hello,
I've tried to fix what I could, but I'm not sure about it.
There is definitely much improvement left, but I hope it's some progress, as
compared to earlier patch.
Hoping to receive your views soon.
Regards
Vipul NayyarÂ
patch
Description: Binary data
__
Joel Sherrill wrote:
On 8/12/2013 8:41 AM, Gedare Bloom wrote:
Is anything lost by going to POSIX threads in GCC?
Maintaining our own specific glue? :)
Yes. The threading support in gcc is designed around POSIX and when
enabled gcc directly accesses the calls. No extra overhead calling an
R
On 8/12/2013 12:13 PM, Ralf Corsepius wrote:
On 08/12/2013 03:41 PM, Gedare Bloom wrote:
Is anything lost by going to POSIX threads in GCC?
RTEMS has been using native RTEMS threads in GCC.
The purpose of this had been:
- Avoiding to have POSIX support hard-wired into RTEMS.
That was true but
On 08/12/2013 11:41 PM, Chris Johns wrote:
Joel Sherrill wrote:
On 8/12/2013 8:41 AM, Gedare Bloom wrote:
Is anything lost by going to POSIX threads in GCC?
Maintaining our own specific glue? :)
Yes. The threading support in gcc is designed around POSIX and when
enabled gcc directly accesses
On Mon, Aug 12, 2013 at 12:15 PM, Ralf Corsepius
wrote:
> On 08/12/2013 09:57 AM, Sebastian Huber wrote:
>>
>> Hello,
>>
>> there was some lobbying against the deprecation of the i386 support of
>> GCC:
>>
>> http://gcc.gnu.org/ml/gcc/2012-12/msg00132.html
>>
>> Is this really justified? Why does
On 08/13/2013 05:22 AM, Gedare Bloom wrote:
On Mon, Aug 12, 2013 at 12:15 PM, Ralf Corsepius
wrote:
On 08/12/2013 09:57 AM, Sebastian Huber wrote:
Hello,
there was some lobbying against the deprecation of the i386 support of
GCC:
http://gcc.gnu.org/ml/gcc/2012-12/msg00132.html
Is this reall
23 matches
Mail list logo
