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

tzz***

原来你们都躲在这"干活"呢

本以为论坛这东西大部分是小年轻在逛，看来又看走眼了

LAOXU, 在另一贴上我还称你为小年轻....  

等你不忙的时候, 来杭州, 我请你吃饭哈

神***

如果
70多高龄的 杨教授 是     达摩院 院长的话/计算机系系主任
60多高龄的 老许    就是  嵩山少年 的藏经阁 图书管理员
===最近修仙，发现掌握这绝对权力中心的，是超级高手啊

我们知天命，正是代表华夏拒敌国门之外的 青春少年

杨***

LAOXU 发表于 2024-4-6 01:58
这里, 我纠正一下说法, 我上面指的挑刺, 是指 欢迎大家找出 我程序中可能 存在的缺点和错误.
找到了肯定要 ...

本来“这些汇编程序, 如老姚没合适人员, 我来帮你写,
挺简单的, 不要一毛钱, 你只需要找人挑刺即可.”

看来我们没有机会欣赏到LAOXU为草案2编写的挺简单的汇编语言程序，
也没有机会挑他的刺了。LAOXU，风水轮流转，今天到你家，下面是我为
草案1--未来的DPU351-L1编写的32位乘法的标准库函数，
欢迎你挑刺、找BUG和质疑。


（1）C251用户使用“DPU351-L1”的方式：
在自己的Keil项目文件中添加“STC_DPU351_L1_STC32G.LIB”的官方库文件，或者自己编写的库文件。
（正如LAOXU所言，用汇编语言编写这个标准函数库是挺简单的，见下面所给的例子）


（2）C251用户在C语言程序中的使用方式： 就像没有DPU一样，直接在表达式中使用C语言的“*”符号，
无需做出任何改变。比如
long   X1,Y1,Z1;
        Z1=X1*Y1;

（3）草案1的32位乘法的标准库函数：
void STC_MDU32_LMUL(void){      
        __asm   {
?C?LMUL:               
                PUBLIC        ?C?LMUL
               
                        MOV                                DMAIR, # 02;               
                        RET;
        }                                
}

第1行“void STC_MDU32_LMUL(void){ ”  是库函数的内部定义。

第2行“__asm   {”              是内嵌汇编语言块的开始行。

第3行“?C?LMUL:”              是C251编译器的32位乘法库函数名（标号名）。

第4行“PUBLIC        ?C?LMUL”      是将自编的函数名声明为公共过程名称，
C251编译器最后连接时就会将这个自编的函数取代C251自己原有的库函数。

第5行“MOV  DMAIR, # 02;”  是向DPU发出的32位乘法指令。
DPU接收到这条指令就开始运算，此时CPU进入“空闲 IDEL”状态，
除CPU暂时不继续执行下一条指令外，其他设备比如定时器、串口等都继续正常运行。
等DPU运算完成后，CPU结束“空闲 IDEL”状态，继续执行下一条指令。

第6行“RET;”程序从库函数中返回，完成32位的乘法操作。

第7行“} ”是内嵌汇编语言块的结束行。

（4）从上面可以看出，通过用自编运算的库函数来替代C251原来的库函数，
就可以实现DPU351与C251在所有32位运算操作上的“无缝连接”，
同时又大大提升32位运算的速度，
使得C251可以继续作为STC32位单片机的主流编译器。

tzz***

执行 DSP/DPU351 + TFPU, DPU32  指令时, 为什么要停CPU时钟?   
我想很多人还是不能理解.  可以继续讨论一下这个话题.

我是这样理解的, 有几种方法可以实现 DSP/DPU351 + TFPU, DPU32 的功能:
1.  外设寄存器模式,  把数据传给外设寄存器, 启动运算, 查询结果.
2.  协处理器.
3.  真正的 DSP/DPU351 + TFPU, DPU32 指令, 即真正意义上的扩充CPU指令.
4.  模仿  DSP/DPU351 + TFPU, DPU32 指令.

对于方法 2,3  因为出现了新的指令, 需要编译器支持 , 短时间内很难改变现状, 暂不考虑

现在只剩下方法1 和 4 ,  各位认为应该怎么选呢.  显然 STC 选择了方法 4

继续分析方法 1 和 4 各自的优缺点.  

方法1的优点很明显, 外设和CPU没有直接关系, 各行其事. 逻辑比较简单. 执行期间CPU不需要断时钟.
缺点也明显,  作为外设来运作, 必然是要互斥访问的, 这对于中断来说很不友好.  
中断可不能等. 如果选用此方式, 就相当于把问题抛给了程序员.  (欢迎补充, 让大家对硬件更加认识)

在说方法4前先说一下真的正CPU指令, 比如DIV AB 指令, 执行时间是6个时钟.
执行指令是一个元子过程, 即在此期间CPU不可能做其它的事情, 也不可以响应中断!  
CPU专心致致的做这一件事情. 运算结束后自动把结果存放在指定的位置, 并做好标志.

方法4,  即在执行  DSP/DPU351 + TFPU, DPU32 指令时, 停掉CPU的时钟.
就好像是CPU真的在运行一样的效果. 运算结束后通过DMA把结果放在指定的位置, 并设置好标志.
此方法的优点很明显, 和真正的指令一样, 效率高, 随时可用, 没有互斥问题.
缺点, 如果执行时间过长是会影响中断响应的,
===但是通过努力提高新增指令速度, 可以把这个缺点降低到很低的程度!  (欢迎补充)
===还有通过努力提高 【DSP/DPU351 + TFPU】 的主频，远远高于CPU的主频

如果让我选, 我也会选方法4, 不知道大家怎么选呢?  

神***

儿童节出来的，STC8051H :
TFPU + STC32位8051
===通过努力提高 TFPU 的主频，高于CPU的主频

TFPU@108MHz
CPU32@43MHz

管脚兼容 STC89C52RC / STC12C5A60S2

tzz***

神农鼎 发表于 2024-4-6 12:56
儿童节出来的，STC8051H :
TFPU + STC32位8051
===通过努力提高 TFPU 的主频，高于CPU的主频

STC8051H  到底是251内核, 还是51内核呢?
说来也奇怪, 刚才在STC8H的手册上看到STC8051H的介绍,
说有 2K  edata,  这使我有点迷糊啊,  51内核还有2K  edata 吗

神***

tzz1983 发表于 2024-4-6 15:37
STC8051H  到底是251内核, 还是51内核呢?
说来也奇怪, 刚才在STC8H的手册上看到STC8051H的介绍,
说有 2K ...

你烧录时选择型号来区分跑8位还是跑32位
【STC8051H - 32Bit】，2K edata, 32K xdata
【STC8051H - 8Bit】，256 idata,  32K xdata

杨***

神农鼎 发表于 2024-4-6 16:23
你烧录时选择型号来区分跑8位还是跑32位
【STC8051H - 32Bit】，2K edata, 32K xdata
【STC8051H - 8Bi ...

【STC8051H - 32Bit】，2K edata, 32K xdata
【STC8051H - 8Bit】，256 idata,  32K xdata



为这个模式点赞，量体裁衣的理论架构、RTOS和编译器正在构建中...


由于有MDU32/TFPU的存在，建议烧录名称改为Keil的输出选项
【STC8051H - HEX386】，2K edata, 32K xdata
【STC8051H - HEX80】，256 idata,  32K xdata

神***

杨为民 发表于 2024-4-6 21:05
【STC8051H - 32Bit】，2K edata, 32K xdata
【STC8051H - 8Bit】，256 idata,  32K xdata

收到

liju***

中断，本质上也是查询方式，只不过是提高了查询的频率而已。