[En-Nut-Discussion] NutEnterCriticalLevel

[Dušan]

Uwe,

I feel we've got on a wrong path :-).

Why you concentrate on the NutEnterCriticalLevel ? Let's forget about it 
for a while.
I suggest to start with NutEnterCritical for m68k platform. This is the 
initially issue, we started to talk about.
I attached 2 emails below.

Let's look at the include\arch\arm\ atom.h.
Here ccodes are also stored into a temp variable.

That's exactly what we are doing on the m68k platform.

----------
But with m68k gcc, we have a problem, when there is a nested 
NutEnterCritical.
The temp variable is compiled as 2 different registers, 1st level goes 
e.g. into d1, 2nd level into d2. Then leaving the 2nd level restores 
status word from d1, which is a problem
This is why we started to use NutUseCritical macro.

In my previous email, dated 9.1.2018, I was wrong with the example.
I should explained the NutThreadAddPriQueue critical section handling.


On 9.1.2018 12:54, Dušan wrote:

> We also added a NutUseCritical  macro,
> which was finally the only way, how to deal with our GCC compiler for 
> m68k.
> Without this, there was a really hard issue at NutThreadAddPriQueue 
> (NutThreadResume), which sometimes resulted in probably lost condition 
> flags due to interrupts.
> Construction
>
>         NutEnterCritical();
>         ...
>         if (...) {
>         ...
>         } else if (cnt) {
>             NutExitCritical();
>
>             NutEnterCritical();
>         }
>         ...
>         NutExitCritical();
>
> was compiled for some code optimizations as below.
> The problem is, if status word (condition flags) changes between point 
> B and C.
> These changes are lost, because they are overwritten at point D.
> This was really very hard to find and after this was fixed, several 
> "problems" were fixed.
>
> I tried many ways, how to stay without NutUseCritical, but I was 
> unable to find any.
>
> >NutEnterCritical, point A
>
> move.w    %sr, %d0
> move.w    %d0, %*d1*
> ori.l    #0x700, %d0
> move.w    %d0, %sr
>
> >NutExitCritical, point B
> move.w    %*d1*, %sr
>
> >NutEnterCritical, point C
> move.w    %sr, %d0
> move.w    %d0, %*d2 ;Here d1 should be used*
> ori.l    #0x700, %d0
> move.w    %d0, %sr
>
> >NutExitCritical, point D
> move.w    %*d1*, %sr
>

On 11.1.2018 17:19, Dušan wrote:

> Yes, I checked other platforms to get an inspiration.
> 1) We tried to place status register directly on stack, but this 
> brings following 2 issues
>     - due to optimization, compiler is not always at a same position 
> in stack after various function calls, i.e. stack pointer is 
> "polished" only before a return from a function is made.
>     - if stack is in external memory (see handle addresses below, 
> those beginning with 8 are in external memory, those starting with 2 
> are in internal SRAM),
>       entering / leaving critical section, thus context switching, is 
> slowed down
>
> 2) We tried to use a local variable on stack
>     - this solves the optimization issue, but still context switching 
> is slowed down
>
> 3) We tried to use a certain register for holding the status word,
> but as you can imagine, this makes things more complex and is not a 
> good solution, almost there appear a case when it is unreliable and 
> brings conflicts.
>
> ------------------
> Maybe the most recent gcc compiler is a solution.
> Do you know someone, who can provide a gcc toolchain for Windows for m68k?
>
> If you have a code up to 128 kB (e.g. Nut / OS + a sample app), you 
> can try NXP's Codewarrior 
> <https://www.nxp.com/products/processors-and-microcontrollers/additional-processors-and-mcus/coldfire-plus-coldfire/coldfire-processors/coldfire-v4-mpus/codewarrior-development-studio-for-coldfire-architectures-linux-editions-classic-ide-v2.5:CW-COLDFIRE-LINUX?fsrch=1&sr=10&pageNum=1> 
> (Eclipse based).
>
> We rely on Codesourcery port, which we bought in 2012.
> There was also a Lite (free) version, which did not plug into Eclipse, 
> i.e. it did not have direct firmware burn from Eclipse over BDM (JTAG 
> variant on Freescale, now NXP) and did not offer debugging.
> Then Codesourcery was acquired by Mentor, which also made the free 
> version no longer available.
>
> At the "Codesourcery" time, we found a bug in the compiler (function 
> returning a result of another function, which was of a pointer type).
> So maybe there are other bugs like this optimization.
>
> Any idea?
>
> -------------------
> I tried to google some info:
> https://community.nxp.com/thread/101270
> The Mentor web page 
> <https://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/> 
> no more lists the Coldfire version, neither as a payed version.
> Shareware 
> <https://en.freedownloadmanager.org/Windows-PC/Sourcery-G-Lite-for-ColdFire-uClinux.html> 
> for $99.
>
> Instructions
> http://usbdm.sourceforge.net/USBDM_V4.9/USBDM_JMxx/html/code_sourcery_page.html
>
> Building a CodeSourcery GCC Coldfire tool chain in windows 
> <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/2007-December/000416.html>
>


*Dušan*

On 15.1.2018 16:32, Uwe Bonnes wrote:
>>>>>> "Dušan" == Dušan  <dferbas at etech.cz> writes:
>      Dušan> Hi Uwe, sounds like some smileys appear :-).
>
>      Dušan> After reading your arguments I started to think - wow, why not to
>      Dušan> have our life easier?
>
>      Dušan> But the priority level is one thing, if we forget about it, then
>      Dušan> we have the condition codes inside the status word.  And this
>      Dušan> must be preserved during interrupt processing.  So the goal is
>      Dušan> not to preserve priority level only, but to preserve condition
>      Dušan> codes.  And if ccodes, then why not to preserve also priority
>      Dušan> level :-).
>
> What changes the condition code?
> Your code implementing NutEnter/Exit Critical? Then change that code to not
> touch the condition code.
>
> Or the interrupt routine that may happen with your NutEnterCriticalLevel?
> Then keep NutEnterCriticalLevel what it is: an arch-specific extension. Keep
> it apart from the generic NutEnter|ExitCritical implementation. Then no
> change in the generic nut/dev/ directory is needed.
>
> Bye
>