杨为民 发表于 2024-9-29 19:06
老子写了《道德经》，你知道老子为什么不写《西游记》吗？
所以说啊，，专业的就让专业的来啊{:4_187:}
本帖最后由 咫尺天涯 于 2024-9-30 09:55 编辑
有几个问题：
1、编译器是否带由标准库，比如stido
2、代码自动补全功能关键词提示等效果如何
3、代码编译效率怎么样，是否可以优化处理
_奶咖君_ 发表于 2024-9-30 08:46
所以说啊，，专业的就让专业的来啊
我问：老子写了《道德经》，你知道老子为什么不写《西游记》吗？
你答：所以说啊，，专业的就让专业的来啊
我评：回答错误，0分。
网络标准答案：因为老子他不愿意！
------------------
对于30楼主的说法“要不 让STCIDE也支持插件也不是不行”
我看法是：行是行呀，可是老子不愿意呀
咫尺天涯 发表于 2024-9-30 09:53
有几个问题：
1、编译器是否带由标准库，比如stido
2、代码自动补全功能关键词提示等效果如何
谢谢你的关心，下面逐条回答：1、编译器是否带由标准库，比如stido
金水151编译器带了C51/C251的全套标准库，由于增加了笔者认为对于单片机更有用的库函数，因此库的分类的方法与C51/C25有所不同。
金水151编译器的库函数用A351汇编语言和C351语言编写，所有的库函数除了“printf”和“scanf”外都是可重入函数。
“LIBC351_JSx51_8051_FMTIO.LIB”是格式化输出函数库，除了“ltos”等外，新增了“ptos”对于指针变量内容的字符串转换函数。
“LIBC351_JSx51_8051_MATH.LIB”是标准函数库，新增加了“extern float exp10 (float v1);// Only C351”和“extern float fint(float v1); // Only C351”函数。
“LIBC351_JSx51_8051_STDIO.LIB”是标准输入输出函数库，原来其中的“printf”和“scanf”类函数被单独放到了“LIBC351_JSx51_8051_PRTSCN.LIB”库中。
“LIBC351_JSx51_8051_STDLIBI.LIB”和“LIBC351_JSx51_8051_STDLIBF.LIB”是将原来的“STDLIB”的整数部分和浮点数部分分开来写，并且还增加了“extern voidltoh8s(char *Outs, binary long x32l);”这种对新数据类型的十六进制转换。
“LIBC351_JSx51_8051_STRING.LIB”是字符串处理函数库。考虑到当前STC单片机的主流型号都是控制类和数字型号处理类型而非数据库类型的单片机，因此本函数库只包括4个基本函数“strlen”、“strcpy”、“strcat”和“strcmp”。
2、代码自动补全功能关键词提示等效果如何
（1）STCIDE是与Keil的C51/C251同类的集成开发环境，计划支持STC/AI类、ARM类和RISC-V类的单片机编译器，目前版本没有你说的功能和仿真的功能，只是用于单片机程序项目管理、源程序编辑和调用编译器进行编译三大功能。
（2）笔者的第一代STC单片机C语言编译器“小鹰”系列开始设计时是为了与大学本科的理科C语言课程和C语言等级考试接轨，采用的是VC2010集成开发环境，你提到的这些功能自然是有的。
但是由于STC单片机的中断函数和数据存储类型的定义实在难以嵌入VC计算机语言的框架，就放弃了。
（3）笔者的第二代STC单片机C语言编译器“长缨”系列开始设计时决定使用Keil的集成开发环境，所以使用“MakeFile”的方法来调用长缨系列编译器。
（4）笔者的第三代STC单片机C语言编译器“金水”系列设计为主要使用STCIDE集成开发环境，同时也可以继续使用Keil集成开发环境的“MakeFile”方法。
（5）笔者的第四代STC单片机C语言编译器计划继续使用STCIDE集成开发环境，然后计划支持其他第三方IDE。
3、代码编译效率怎么样，是否可以优化处理
由于“金水”系列编译器除了支持C语言和汇编语言外，还支持使用FORTH-351高级计算机语言（目前金水151没有开放该语言接口）对STC单片机编程，所以对于C语言没有进行任何优化处理。
因此金水151与C51/C251比，C351编译器的代码编译效率比C51/C251低15%左右。但是F351编译器对FORTH-351高级计算机语言的代码编译效率远比C51/C251高，接近专业程序员直接用汇编语言编写程序的水平。
高！{:4_250:}很期待杨老师及STC的强力发展和贡献！！
能在stm32,gd32等其他单片机中使用吗
杨老师威武，未来国产化值得推荐。
只有这样才能冲破壁垒，避免被卡脖子。
网友提到的插件也是值得杨老师考虑的。
微信小程序就像微信的插件。借助微信的海量基础用户和其自身的便捷性、跨平台等有点迅速获得海量用户。
获得了海量用户也就拥有了海量的使用反馈，经过不断的迭代微信小程序目前已经被广泛应用于各个领域。
如果国产自研编译器能够以插件的形式出现在vscode。 肯定能够迅速得到很多宝贵的测试case和建设性建议；
杨为民 发表于 2024-9-30 17:51
谢谢你的关心，下面逐条回答：1、编译器是否带由标准库，比如stido
金水151编译器带了C51/C251的全套标准 ...
只是15%，那就是比 SDCC-51要高了
大锤子 发表于 2024-11-9 22:44
杨老师威武，未来国产化值得推荐。
只有这样才能冲破壁垒，避免被卡脖子。
（1）谢谢你的支持。我个人认为目前8051指令集的单片机的编译器和集成开发环境的国产化进程不是技术问题，也不是推广问题，是市场选择的结果。目前已经有几个大厂有自己的国产8051编译器了，但是以8位单片机承担的市场角色而言，Keil的C51已经是一个堪称完美的IDE了（包括实现RTOS），而SDCC也早就集成进好几种Arduion开发环境了，因此除非出现类似华为这种情况，中国人付钱也不让用的情况，8051指令集的单片机的国产化的必要性和紧迫性不大。
（2）我是做理论研究的，寄生于8051指令集的金水明151编译器是为基于80251指令集的金水明351编译器探路的。Keil的C251编译器对于STC32G/F和AI8051U单片机尚称得上是优秀的编译器，但对于STC即将推出AI8052U单片机资源肯定是支持不足的，其将函数重入堆栈与系统SP堆栈混用在EDATA空间的方式会成为应用（尤其是RTOS应用）的天花板。因此基于80251指令集的编译器的国产化进程是应该提上日程了。
（3）对于金水明351编译器，已经验证过使用MakeFile等的方式，以其他IDE对接了
{:4_174:}