讨论稿，向【64位超算中心】前进 ! DSP/DPU351 + TFPU, DPU32@全新32位8051

LA***

如难度高, 来个简配版的也不错, 规格化定点小数 2进制 <--> 10进制 之间转换.

不过这些都是辅助功能, 主要用于数据输入/输出.

LA***

Register Usage
In an assembler subroutine, the following registers may be used without prior saving of their contents: R0 to R11, WR16 to WR30, PSW, PSW1, and DPTR. DR60 is the STACK POINTER; at the end of the assembler subroutine the value of DR60 must be the same as at the entry of the routine. If the subroutine uses the registers R12 to R15, the contents of the registers must be saved and restored at return to the calling C function.

When calling a C function from assembler, it must be assumed that the register contents of R0 to R11, WR16 to WR30, PSW, PSW1, and DPTR are destroyed during the processing of the C function. The PSW flag UD is not used in C251 code and may be freely used.

Copyright © Keil, An ARM Company. All rights reserved.

杨***

LAOXU 发表于 2024-4-3 16:44
Register Usage
In an assembler subroutine, the following registers may be used without prior saving  ...

感谢LAOXU特地找出权威说明，下面是百度翻译结果：


Keil C251编译器的寄存器使用说明
在汇编子程序中，可以使用以下寄存器，而无需事先保存其内容：R0到R11、WR16到WR30、PSW、PSW1和DPTR。DR60是STACK POINTER；
在汇编子程序结束时，DR60的值必须与子程序入口处的值相同。
如果子程序使用寄存器R12至R15，则必须保存寄存器的内容，并在返回到调用C函数时将其恢复。
当从汇编程序调用C函数时，必须假设R0到R11、WR16到WR30、PSW、PSW1和DPTR的寄存器内容在C函数的处理过程中被破坏。
PSW标志UD不用于C251代码中，并且可以自由使用。
版权所有©Keil，ARM公司。保留所有权利。

神***

后续相关寄存器名称，按杨老师指出的
STC351体系结构方向的 寄存器命名风格靠拢，
为向64位前进做准备

杨***

LAOXU 发表于 2024-4-3 16:44
Register Usage
In an assembler subroutine, the following registers may be used without prior saving  ...

3天了，比起草案1征求意见的帖子，这个帖子罕见的冷清，为什么呢？



（1）LAOXU，我等了你一天，我义务地把你的重要的英文论据翻译为中文，你怎么连谢谢的反馈都没有？
莫非是你学聪明了，预感到后面有个巨大的瓜要砸下来？


（2）我是赞同草案1的，LAOXU草案1征求意见的帖子不停地叨叨叨，担心这，担心那，被我形容为“产前焦虑症”和“与风车打架”。
（3）草案2明显地是采纳了LAOXU叨叨叨的意见，比如将草案1中的“EAX/EBX”的名称互相对换成了你老的“EBX/EAX”，倚天剑和屠龙刀变成了“倚天刀”和“屠龙剑”了，把我都看糊涂了。
（4）LAOXU明显是赞同草案2的，所以不再“假如若是、假如若是”地提出一百 个聪明人都难以回答的问题了。
（5）此贴是征求意见的帖子，既然我不赞同草案2，我也得说说我的理由，该轮到我叨叨叨了，轮到我担心这，担心那了。
LAOXU，风水轮流转，你的机会来了，轮到你来评价我了，看我是不是与你一样的得“产前焦虑症”和“与风车打架”了。

杨***

梁工 发表于 2024-4-1 21:43
研究了一晚上，指令都比较齐全。
有点疑问：
加法运算没有说明是否有符号，没看到“32位有符号加法”这样的 ...

“这是STC32F12K54的程序，不知道C251编译后，是怎么调用上述的DPU指令的？”
下面以MAC乘加指令为例来说明：


（1）由于C251编译器是依据80251指令集来设计的，在80251指令集里没有“STC 80351”指令集中的乘加“MA64_EDX”指令，
（相当于M3/M4中的“SMLAL”指令--有符号的MAC，(32b×32b)+64b=64b）
所以C251编译器不会自动调用80251这些没有的指令的。
（据我经验 ARM MDK的C语言编译器同样也不会自动调用“SMLAL”指令，这种指令只能在汇编语言中使用）


（2）因此这种DSP指令无论在C251中还是在ARM MKD中，都是第三方用汇编语言写成“DSP库函数”的方式提供用户使用。

以你的例子为例，未来会以“8阶巴特沃斯”库函数“filters_8”这种形式提供用户使用，就像高斯法解线性代数方程组那样写成通用的函数库。


（3）等到搭载“DPU351-L1”数字处理单元的STC32G单片机出来后，我就用你的这个例子写一个标准函数，供你测试和提出改进意见，为建立STC32/64位单片机的“DSP”函数库做探索。

LA***

这段时间太忙, 我已不想跟你争论了, 你老永远是 伟大光荣正确.

草案1，征求意见的帖子不停地叨叨叨, 核心的技术内容有 2点,
至于 EAX/EBX 对换, 根本排不上号(只不过和现有51/251风格完全不同, 不便记忆, 反感).
1. DPU32寄存器不能放在 RAM中, 一定要放在 受 C51/C251保护的 SFR中 ...... 草案2 已改
2. MDU16 执行时 不停止 CPU工作, 为什么 MDU32不这样做呢? .......
   老姚解释, 指令就是指令(纯粹当 51/251指令执行).

以上两点都是为了 让 DPU32 指令, 执行的更快更有效.

依现有工艺, DPU32 指令的执行时钟周期是一定的, 但在整个系统运行中, 指令执行的总的时间是不确定可变的,
由以下几点花费时间累加确定.
1. 参数传递.
2. 子程序调用,
3. 保护受影响的SFR/RAM
4. 参数送DPU32寄存器.
5. 执行DPU32命令
6. 计算结果回送.
7. 恢复受影响的SFR/RAM
8. 子程序返回,

DPU32寄存器的设计与布局, 影响以上这些内容, 从而改变整个执行时间.

当然简单指令不会用到上述全部步序, 只有复杂指令才会用全,
1. 草案2 已改DPU32寄存器不放在 RAM中, 改为放在 受 C51/C251保护的 SFR中,

   那么 上述 3,7 可取消(缩短指令总执行时间). 51会略为受点影响.

2. 草案2  DPU32 指令执行期间, CPU停止. 影响指令执行速度是一定的,
   在上述中, 子程序返回需 3个时钟周期, 假如 DPU32 指令执行时间(绝大多数) 大于等于3个时钟周期
   假如 DPU32 指令执行期间, CPU不停止工作. 那么, 经适当的延时(-3) , 提前 RET 返回, 总的
   执行时间可缩短 3个时钟周期(变相提升DPU32 指令执行周期).
   在复杂函数多次调用DPU32 指令的应用中, 优势明显, 因为 DPU32 指令执行期间, CPU不停止工作.  
   那么, CPU好做好多准备(辅助)工作, 相当于 双核同时运行(真正做到老姚所设想的 TFPU为主, CPU为辅 两核同时工作)
   以梁工 所例举的 8阶滤波函数为例, 让我来编这个程序, 经初步评估, 快 10% 没问题, 经优化程序, 可望提升速度 约 20%,
   这是针对单独 使用 DPU32 指令执行 8阶滤波函数 相 PK, 你单独用 DPU32 指令想提升速度20%,

   DPU32  IP内核 起码要提速 > 20%-50%. 这个工艺不是那么容易解决的.
   个人认为, DPU32 指令执行CPU停止工作(只是好看不实用), 并且影响中断的实时响应.

   至于你老编个“8阶巴特沃斯”库函数, 我没兴趣, 这是我几十年前玩剩的, 你老如有兴趣, 不如咱们各自编个“8阶巴特沃斯”库函数,
   PK 一下,
1.  谁的程序更短更精练.
2.  谁的程序执行速度更快更高效.
   假如你老同意我以上观点, 我倒有兴趣玩一把.
   为建立STC32/64位单片机的“DSP”函数库做贡献.

杨***

LAOXU 发表于 2024-4-5 06:08
这段时间太忙, 我已不想跟你争论了, 你老永远是 伟大光荣正确.

草案1，征求意见的帖子不停地叨叨叨, 核心 ...

终于把你请出来了。



（1）STC要想在继续使用C251作为主流C语言编译器的情况下，实现STC 32位/64位内核的单片机的推广应用，有许多技术上的难题要去克服。
芯片造出来不算成功，还要广大用户应用到实际中才算成功。因此不但STC本身要克服这些难题，还要让用户也知道是如何克服的，将来在使用C251编程时要注意什么。
（2）就像“西藏扎什伦布寺 响彻近六百年的辩经声”，本论坛也是这样，我相信在你我互相质疑的过程中，广大的网友一定会收获到很多知识。
（3）你这次提出的问题很多，容我以后逐一解释，反正草案2就是不行。
（4）以后我俩别比老，别比计算机经历。一是我年龄比你大10岁，二是我非计算机科班出身，作为学生我仅上过两门计算机相关课程：本科上过数学系的“ALGOL60 计算机语言”（1980年），硕士研究生上过数学系的“数值计算方法”（1983年）。

LA***

以梁工的 "8阶滤波函数". 其中的核心计算----乘加(减)运算 为例

out = (Coef[p*5+0] * Xin[p][0] + Coef[p*5+1] * Xin[p][1] + Coef[p*5+2] * Xin[p][2] - Coef[p*5+3] * Yout[p][0] - Coef[p*5+4] * Yout[p][1])/32768

1. 前提: 常规, DPU32 指令执行期间, CPU停止工作.
你用 MA64 , 执行一次 12 个时钟周期, 碰到 "-" 还要进行极性转换再用 MA64, 执行时间更长.
我用 无符号32位乘法指令(MULU_EABX), 执行一次 8 个时钟周期, 再执行一次 251 32位寄存器加/减指令(不管 "+" 还是 "-" , 都耗时 1个时钟周期), 总共执行 9个时钟周期.
你用 MA64 , 执行一次起码 12 个时钟周期, 哪个运算速度快效率高, 傻子都看得懂.
老姚: ===老农田间插秧，插话：高端 STC351, 是 DPU351 + TFPU, 无 MDU32了
===老农田间插秧，插话：CPU 跑 100MHz, DPU351 跑250MHz, 你咋看
===============================================
回老姚: 依我看, DPU351 跑2500000MHz,  都没关系, 只要在 数据交换(读写专用寄存器),  暂停 CPU 一个时钟周期 即可.  

2. 前提: DPU32 指令执行期间, CPU不停止工作.
我的 程序会执行的更快, 在 执行 DPU32 无符号32位乘法指令(8个时钟周期) 期间, 可执行很多辅助指令, 进一步缩短此功能函数 整体运行时间, 提升速度.
要想达到 我的运行速度, 只有提升 DPU32 工作频率, 从而提升速度.
但是, 随着 DPU32 工作频率提高, DPU32  MA64速度提升的同时, 其他 DPU32指令的速度也同步提升(包括 无符号32位乘法指令), 我的程序总体速度, 永远快于使用 MA64 的速度.

结论: 以梁工的 "8阶滤波函数". 为例, 使用 MA64 指令, 在速度上完败.
补上神门一脚, 本例中  MA64 指令 毫无用处.

梁***

杨为民 发表于 2024-4-4 23:42
“这是STC32F12K54的程序，不知道C251编译后，是怎么调用上述的DPU指令的？”
下面以MAC乘加指令为例来说 ...

好的，非常感谢！
在我的实际项产品目中，对算力有要求的一般是乘加运算的速度，
比如PID、DFT、FFT、各种数字滤波器算法、多通道语音处理（
比如多键电子琴、多通道和弦），都是使用乘加运算，其速度严重
制约能处理的最高采样，所以急需要能快速处理乘加运算的MCU。

如果能做成DMA则更加好。