fanxsp
发表于 2024-5-8 08:23:16
V1.21
发现并修复一个bug, 请在顶楼下载。
杨为民
发表于 2024-5-8 09:36:28
CosyOS 发表于 2024-5-7 13:07
很多现有的 RTOS，都是墨守陈规，一致采取了 古老的 临界区保护技术（关闭总中断），
并未吸取 Arm 为 OS...
很多现有的 RTOS，都是墨守陈规，一致采取了 古老的 临界区保护技术（关闭总中断），
并未吸取 Arm 为 OS 设计的、现代的、OS思想。
你这一杆子打死的人太多了：这个论坛里除了你其他人都是“墨守成规”吗？
论坛外的RT-Thread和其他国内大厂推出的基于ARM和RISC-V的RTOS也都是“墨守成规”吗？
tzz1983
发表于 2024-5-8 09:50:48
fanxsp 发表于 2024-5-8 08:23
V1.21
发现并修复一个bug, 请在顶楼下载。
我发现你的进出临界区的代码很高效。所以我新做的移植参照你的临界区的做法。
现在发现一个有意思的小细节，临界区改成如下这样更快！
#defineOS_ENTER_CRITICAL() do{EA=0;uxCriticalNesting++;}while(0)
#defineOS_EXIT_CRITICAL() do{if(!--uxCriticalNesting)EA=1;}while(0)
分析一下： 编译后，进临界区是固定的两条汇编指条，没什么好说的
出临界出，按照我发出这样的出写格式，会被编译为 DJNZ指令，
也就是把 “减1 ，判断，跳转“ 合成为一条汇编指令，这个编译器有时候比我们聪明哈{:lol:}
这样一来， 出临界区也是两条汇编指令。
这将是51核，最快的可嵌套进出临界区办法！
fanxsp
发表于 2024-5-8 10:02:43
本帖最后由 fanxsp 于 2024-5-8 10:05 编辑
tzz1983 发表于 2024-5-8 09:50
我发现你的进出临界区的代码很高效。所以我新做的移植参照你的临界区的做法。
现在发现一个有意思的小细 ...
编译器确实是比我们想象的要聪明。
do{if(!--uxCriticalNesting)EA=1;}while(0) 和do{if(--uxCriticalNesting==0)EA=1;}while(0) 编译结果是一样的
tzz1983
发表于 2024-5-8 10:13:36
fanxsp 发表于 2024-5-8 10:02
编译器确实是比我们想象的要聪明。
do{if(!--uxCriticalNesting)EA=1;}while(0) 和do{if(--uxCritical ...
不一样的，==0 因为是整形变量， 会用JZJNZCJNE ADD,0XFF 等手段
你看一下编译结果：
用！是逻辑量，再看一下：
当然了，这种细节只是无意中发现的，哪种做法都是对的，并不用太在意
fanxsp
发表于 2024-5-8 10:20:26
tzz1983 发表于 2024-5-8 10:13
不一样的，==0 因为是整形变量， 会用JZJNZCJNE ADD,0XFF 等手段
你看一下编译结果：
我的编译结果是一样的啊，我有看过，你的怎么不一样？ 奇怪了。
; OSExitCritical() ;
; SOURCE LINE # 168
DJNZ OSEnterSum,?C0021
SETB EA
; }
; SOURCE LINE # 169
?C0021:
杨为民
发表于 2024-5-8 10:20:39
本帖最后由 杨为民 于 2024-5-8 10:25 编辑
CosyOS 发表于 2024-5-7 12:49
是这样一个原则，外部中断（IRQHandler）的优先等级 应 高于 内核服务 和 任务。
而 内核服务 的优先等级...
你在168楼说：“Keil 在此基础上进一步发展出了新一代的 OS模型，可实现“零中断延迟”。”
你在169楼说：很多现有的 RTOS，都是墨守陈规，一致采取了 古老的 临界区保护技术（关闭总中断），并未吸取 Arm 为 OS 设计的、现代的、OS思想。
（1）我不确定Keil是哪一年发明“不关闭总中断”的“零中断延迟”。
（2）但我确定我1980年代使用的PDP-11计算机上的RT-11实时多任务操作系统的临界区保护方法就没有关闭总中断了。
（3）但我确定我1989年参与指导的研究生在PC/AT计算机开发的RTOS-X86的临界区保护方法也没有关闭总中断，他现在已博导退休了。
（4）关于临界区保护是计算机操作系统的基本理论问题，关不关闭总中断的影响早就研究的很透彻了。因此FreeRTOS和uC/OS等RTOS早就留下了接口，让移植者选择临界区保护方法是不是需要“关闭总中断”了。
（5）ARM的Cortex-A/M指令集是一款专门考虑了OS/RTOS用途的指令集，因此这之后的FreeRTOS和uC/OS-III的设计已经充分考虑Cortex-M架构的特点了，它们主流的移植者都选择“关闭总中断”是另有原因的，绝不是“墨守陈规”。
（6）考虑到STC33单片机已经进入测试阶段了，我已经在M3上移植了“关闭总中断”的uC/OS-II，并且测试中断响应的源程序和测试结果已经放在排行榜帖子里了。要不你也把你的“零中断延迟”的M3/M4上的CosyOS-II的测试程序也放上来，和我移植的uC/OS-II比较一下。这样RTX4/5的理念和方法是不是创新，我移植的RTOS是不是“墨守成规”？
比一比不就知道了？用事实说话，行吗？
fanxsp
发表于 2024-5-8 10:21:49
本帖最后由 fanxsp 于 2024-5-8 10:24 编辑
fanxsp 发表于 2024-5-8 10:20
我的编译结果是一样的啊，我有看过，你的怎么不一样？ 奇怪了。
; OSExitCritical() ;
; SOURCE LIN ...
这个我是有专门看过汇编代码，我自已感觉用 ==0会直观一点，你的变量类型是不是 unsigned char?
tzz1983
发表于 2024-5-8 10:22:59
fanxsp 发表于 2024-5-8 10:20
我的编译结果是一样的啊，我有看过，你的怎么不一样？ 奇怪了。
; OSExitCritical() ;
; SOURCE LIN ...
那我就不知道了，
发个版本出来，我们对比一下：
fanxsp
发表于 2024-5-8 10:24:48
tzz1983 发表于 2024-5-8 10:22
那我就不知道了，
发个版本出来，我们对比一下：
版本一样的，你的变量类型是不是 unsigned char?