分享一个ST语言的bison文件
接上一份的 flex文件，下面是realw写的st语言的bison文件。
%code top{
#include <stdio.h>
#include <stdlib.h>
}
%code requires{
#define YYLTYPE YYLTYPE
typedef struct PlcSrcLocation YYLTYPE;
typedef void* yyscan_t;
#define YYLTYPE_IS_TRIVIAL 1
}
%code provides{
#define YY_DECL int yylex \
(YYSTYPE *yylval_param,YYLTYPE *yylloc_param,struct PlcCContext *context,yyscan_t yyscanner)
YY_DECL;
}
%code {
void yyerror(YYLTYPE *loc,yyscan_t yyscanner,const char *msg);
}
/* Page 97,4.1,there is an example. */
%param { yyscan_t yyscanner }
/* Page 84 for yylex(YYSTYPE*,YYLTYPE*) */
%locations
%define api.pure full
/* enable run-time debug */
%define parse.trace
/* generate the parse description file. */
%verbose
/* verbose error reporting, 4.7 The Error Reporting Function*/
%define parse.error verbose
/* LAC enable, 5.8.3 LAC*/
%define parse.lac full
%start pou
%%
pou:
%empty
{
}
| stmt_list
{
}
;
stmt_list:
statement
{
}
| stmt_list statement
{
}
;
statement:
';'
{
}
| assignment_statement
{
}
| selection_statement
{
}
| function_call_statement
{
}
| jump_statement
{
}
| goto_label_statement
{
}
|error_statement
{
}
;
function_call_statement:
function_call ';'
{
};
error_statement:
error ';'
{
}
| error ':'
{
}
;
jump_statement:
return_statement
{
}
| goto_statement
{
}
;
return_statement:
RETURN ';'
{
}
| RETURN expression ';'
{
}
;
goto_statement:
GOTO IDENTIFIER ';'
{
}
;
goto_label_statement:
IDENTIFIER ':' statement
{
}
;
assignment_statement:
sym_variable ASSIGN expression ';'
{
}
;
selection_statement:
if_statement
{
}
;
if_statement:
IF expression THEN stmt_list END_IF
{
}
| IF expression THEN stmt_list elseif_stmt_list END_IF
{
}
| IF expression THEN stmt_list ELSE stmt_list END_IF
{
}
| IF error END_IF
{
}
| IF expression THEN error END_IF
{
}
;
elseif_stmt_list:
elseif_statement
{
}
| elseif_stmt_list elseif_statement
{
}
;
elseif_statement:
ELSIF expression THEN stmt_list
{
}
;
expression:
bitwise_or_expression
{
}
;
bitwise_or_expression:
bitwise_xor_expression
{
}
| bitwise_or_expression OR bitwise_xor_expression
{
}
;
bitwise_xor_expression:
bitwise_and_expression
{
}
| bitwise_xor_expression XOR bitwise_and_expression
{
}
;
bitwise_and_expression:
equality_expression
{
}
| bitwise_and_expression '&' equality_expression
{
}
| bitwise_and_expression AND equality_expression
{
}
;
equality_expression:
relation_expression
{
}
| equality_expression '=' relation_expression
{
}
| equality_expression NE_OP relation_expression
{
}
;
relation_expression:
additive_expression
{
}
| relation_expression '<' additive_expression
{
}
| relation_expression '>' additive_expression
{
}
| relation_expression LE_OP additive_expression
{
}
| relation_expression GE_OP additive_expression
{
}
;
additive_expression:
multiplication_expression
{
}
| additive_expression '+' multiplication_expression
{
}
| additive_expression '-' multiplication_expression
{
}
;
multiplication_expression:
exp_expression
{
}
| multiplication_expression '*' exp_expression
{
}
| multiplication_expression '/' exp_expression
{
}
| multiplication_expression MOD exp_expression
{
}
;
exp_expression:
unary_expression
{
}
| exp_expression EXP_OP unary_expression
{
}
;
unary_expression:
primary_expression
{
}
| unary_operator primary_expression
{
}
;
unary_operator:
'-'
{
}
| NOT
{
}
| '+'
{
}
;
primary_expression:
literal
{
}
| paren_expr
{
}
| sym_variable
{
}
| function_call
{
}
;
paren_expr:
'(' expression ')'
{
};
literal:
TYPE_PREFIX LITERAL_VALUE
{
}
| LITERAL_VALUE
{
};
sym_variable:
IDENTIFIER
{
}
| sym_variable '.' IDENTIFIER
{
}
| sym_variable '[' expression']'
{
}
| sym_variable '[' error ']'
{
}
| sym_variable '.' error
{
}
;
function_call:
IDENTIFIER '(' parameter_list ')'
{
}
;
parameter_list:
%empty
{}
| parameter_init
{
}
| parameter_list ',' parameter_init
{
}
;
parameter_init:
IDENTIFIER ASSIGN expression
{
}
| error
{
}
;
%%
void yyerror(YYLTYPE *loc,yyscan_t yyscanner,const char *msg){
}
已经经过了基本测试。
以上。 realw
我敢打赌95%以上的电工不懂 lex 和 yacc。 mangocity 发表于 2016-3-23 17:13
我敢打赌95%以上的电工不懂 lex 和 yacc。
。 。 。 。 。 。 。 。 。 mangocity 发表于 2016-3-23 17:13
我敢打赌95%以上的电工不懂 lex 和 yacc。
不懂就一起学习被。 正是我需要的。我参考beremiz也在搞！ mangocity 发表于 2016-3-23 17:13
我敢打赌95%以上的电工不懂 lex 和 yacc。
做编译器的工作很少，一般只有做IC的公司才有吧？ gpfrank 发表于 2016-3-29 12:01
正是我需要的。我参考beremiz也在搞！
直到 这种转成C，然后再调用GCC的做法有没有成熟的案例？
直接来说，这种方案系统复杂度太高了。 realw 发表于 2016-3-29 21:11
直到 这种转成C，然后再调用GCC的做法有没有成熟的案例？
直接来说，这种方案系统复杂度太高了。 ...
beremiz不就是这个架构吗？ realw 发表于 2016-3-29 21:11
直到 这种转成C，然后再调用GCC的做法有没有成熟的案例？
直接来说，这种方案系统复杂度太高了。 ...
CoDeSys就是如此啊 本帖最后由 realw 于 2016-3-30 14:02 编辑
zzsczz 发表于 2016-3-30 09:14
CoDeSys就是如此啊
我不是说这种方案行不通，而是认为这种方案的系统复杂度有点高。
因为随着开发的进行，设计可能会过于依赖第三方编译器的内部机制，而第三方通用编译器的复杂度
通常都会比较高，这会令整个系统的复杂度上升的比较快。而复杂度是软件最大的敌人。 realw 发表于 2016-3-30 11:55
我不是说这种方案不好，而是认为这种方案的系统复杂度有点高。
因为随着开发的进行，设计可能会过于依赖 ...
把规范、ABI、API和虚拟机做好 。（一千个读者眼中有一千个哈姆雷特，一千个电工解读 iec标准，结果没一千个，百八十个是有的）
系统级的软件 摆脱不了编译器的，甚至是编译器 将就软件。
本帖最后由 realw 于 2016-3-30 13:44 编辑
zzsczz 发表于 2016-3-30 13:14
把规范、ABI、API和虚拟机做好 。（一千个读者眼中有一千个哈姆雷特，一千个电工解读 iec标准，结果没一 ...
把规范、ABI、API和虚拟机做好 ，和选择设计方案没有关系。这些是问题，无论何种方案都要解决。
他们两家编译C语言一定是调用第三方的编译器，自己再做一个C编译器这种方案就没有意义了。
我认为调用第三方的C编译器就是风险最高的部分，可能会比较快的出产品，但是第三方的C编译器
的复杂度会大大增加整个系统的复杂度。而方案的选择是整个设计中最重要的部分，因为它的影响会
从产品第一版发布到产品重写为止。某种意义上说，架构就是程序的文化。 gpfrank 发表于 2016-3-29 22:37
beremiz不就是这个架构吗？
我还没看过beremiz，我想问一下beremiz的C编译器用的是什么呢？ realw 发表于 2016-3-30 13:36
我还没看过beremiz，我想问一下beremiz的C编译器用的是什么呢？
这个要看你平台了。
如果你用WINDOWS，那就用MINGWIN，
如果你用LINUX，就用GCC.
我是用的YAGATO realw 发表于 2016-3-30 13:34
把规范、ABI、API和虚拟机做好 ，和选择设计方案没有关系。这些是问题，无论何种方案都要解决。
他们两 ...
跟人觉得，重复造轮子，你能造得过GCC或者C LANG吗?
可能BUG比他们还多。
再说都是开源的 当然这东西个人玩玩可以，
真的做产品，算了！大公司做做还可以，投入量，不是个人或者小公司玩得起锝。呵呵！ gpfrank 发表于 2016-3-31 12:13
当然这东西个人玩玩可以，
真的做产品，算了！大公司做做还可以，投入量，不是个人或者小公司玩得起锝。呵 ...
自己不玩，不要妨碍别人玩。
玩也是一种学习啊。
看别人玩也是学习。 本帖最后由 realw 于 2016-3-31 19:07 编辑
gpfrank 发表于 2016-3-31 12:11
跟人觉得，重复造轮子，你能造得过GCC或者C LANG吗?
可能BUG比他们还多。
再说都是开源的 ...
我觉得，如果方案选择使用GCC或者LLVM作为编译器后端，你就不仅仅是使用这个工具了[当然，仅仅是使用也有很多坑]，很多时候需要理解工具。
我认为学习GCC或者LLVM的难度高于自己做解释器，而且把一个庞然大物整合进自己的系统，想想脑袋就很大。最终没采用codesys的方案。 附件是我的ST语言的规格说明，也是我对于IEC61131-3ST语言的理解。
继续前行。
有一张图片转成PDF时丢失了. zzsczz 发表于 2016-3-31 15:18
自己不玩，不要妨碍别人玩。
玩也是一种学习啊。
不知道哪里妨碍别人玩了？ realw 发表于 2016-3-31 19:06
我觉得，如果方案选择使用GCC或者LLVM作为编译器后端，你就不仅仅是使用这个工具了[当然，仅仅是使用也有 ...
如果转换成的目标不是c，而是虚拟机，再用解释器，个人觉得肯定比用gcc好控制！
用gcc我也只是玩玩而已！毕竟beremiz也还只是个框架！让人学习用的！ 本帖最后由 realw 于 2016-4-1 09:54 编辑
gpfrank 发表于 2016-3-31 21:03
如果转换成的目标不是c，而是虚拟机，再用解释器，个人觉得肯定比用gcc好控制！
用gcc我也只是玩玩而已！ ...
是的，这就是我选择不编译成C的原因。
毕竟主要精力需要放在IEC61131-3上，这个是做出来给自动化应用工程师用的。
我看过KW的方案，他们的方案是
KW --> CIL --> machine code
后端使用的是 MONO的AOT。
本帖最后由 gpfrank 于 2016-4-1 08:29 编辑
realw 发表于 2016-3-31 21:46
是的，这就是我选择不编译成C的原因。
毕竟主要精力需要放在IEC61131-3上，这个是自动化应用工程师最常用 ...
参加过KW的研讨会，也了解他们的运行模式。
只知道他们用的是AOT技术，至于是不是MONO就不清楚了。而且似乎他还关闭了GC的功能。
通过AOT加无GC来克服CLR的实时性问题。
除BISON和FLEX。 我很想试试ANTLR。
不过我编译原理学的不是很好，所以还在学习中。
.NETMF现在也有一个分支，也再考虑提高速度。
gpfrank 发表于 2016-4-1 08:23
参加过KW的研讨会，也了解他们的运行模式。
只知道他们用的是AOT技术，至于是不是MONO就不清楚了。而且似 ...
如果打算学习编译原理，可以考虑coursera上的斯坦福大学的Compilers课程，以及Automata课程。其中自动机课程我已经拿到证书了。
不过我觉得这是一个交叉领域，61131-3也十分重要。 本帖最后由 zzsczz 于 2016-4-1 19:39 编辑
realw 发表于 2016-3-31 19:06
我觉得，如果方案选择使用GCC或者LLVM作为编译器后端，你就不仅仅是使用这个工具了[当然，仅仅是使用也有 ...
同意。
ST 规范 要比C“呆板” ，用错的机率小 ；不过 规范 是一码事 ，实现 就是另外一回事了。
BTW 编译原理学习笔记能否共享？ zzsczz 发表于 2016-4-1 19:31
同意。
ST 规范 要比C“呆板” ，用错的机率小 ；不过 规范 是一码事 ，实现 就是另外一回事了。
我没做笔记，只是做完了 compiler && automata 的课后习题，参加了最终考试。 realw 发表于 2016-3-31 21:46
是的，这就是我选择不编译成C的原因。
毕竟主要精力需要放在IEC61131-3上，这个是做出来给自动化应用工程 ...
设计一个比较好的虚拟机你有什么方案呢？ gpfrank 发表于 2016-4-3 19:07
设计一个比较好的虚拟机你有什么方案呢？
两种类型的虚拟机：
1. 堆栈型虚拟机;
2. 寄存器型虚拟机;
堆栈型虚拟机优点是代码密度大，实现起来容易，但是性能比较差，典型的Java，C#虚拟机就是这个样子，只是后面加上了JIT。
寄存器型虚拟机，实现复杂度高，目前大规模应用的只有LUA虚拟机，性能相对较高。
虚拟机最复杂的是内存回收部分，但是在我们的系统中动态分配的需求很少，可以使用一些简单的机制解决内存动态分配的问题，
没有了动态分配，也就不存在内存回收了。 realw 发表于 2016-4-3 21:11
两种类型的虚拟机：
1. 堆栈型虚拟机;
2. 寄存器型虚拟机;
看来还是要参考LUA了。LUA的语法有点不习惯。
GC肯定是不能使用的，不然会破坏实时性。
虚拟机还有个好处，就是加载器不用担心没有MMU的问题。
可能唯一就是效率比C转换成目标代码的稍微慢点。 gpfrank 发表于 2016-4-4 14:51
看来还是要参考LUA了。LUA的语法有点不习惯。
GC肯定是不能使用的，不然会破坏实时性。
61131-3 同等重要， 如果你打算做出来给人用的话。 realw 发表于 2016-4-5 08:36
61131-3 同等重要， 如果你打算做出来给人用的话。
61131-3 中 对 虚拟机 没有 强制性要求，具体实现交给供应商解决；相比之下 JVM CLR之类的很完备了 。（若不对请指出）
西门子 STEP7中梯形图 每个元素都能翻译成对应的 指令表 （STL 对应于61131-3 的IL ）,西门子的 SCL(结构化文本)也可编译成STL; 西门子 STEP7的 虚拟机可执行代码规范是 MC7 ，对应汇编语言是 STL，STL的子集可用梯形图展现。
61131-3 的 IL 能否作为虚拟机的汇编语言？(可能性不大，找过几个开源方案，有采用自定义中间代码的 ，也有转C的 ，直接执行 IL 的还没有 )
61131-3 规范有很多部分（软件模型，类型系统）很抽象，有好多工作要做。
本帖最后由 realw 于 2016-4-6 06:53 编辑
zzsczz 发表于 2016-4-5 14:46
61131-3 中 对 虚拟机 没有 强制性要求，具体实现交给供应商解决；相比之下 JVM CLR之类的很完备了 。（ ...
61131-3代表的是自动化应用工程师如何使用以下几种语言：
1. SFC
2. 功能块
3. 梯形图
4. ST
5. IL
以及编程模型中各种概念：
1. 任务
2. 程序
3. 功能块
4. 功能
5. 变量
6. 配置等等
还有一些基本数据数据类型：
1. 范型，各种ANY
2. 基础数据类型，INT等等
3. 自定义数据类型，结构体，数组等等
这个与虚拟机确实没啥关系，这个是产品定义。
使用JVM或者CLR的指令当然很好，因为没有必要再定义出来一套图灵完备的指令。
IL直接执行应该是可以的，但是执行性能可能会比较差，因为很多编译期的工作都推到了执行期。IL作为[缓冲]中间语言的一个大好处是编译性能可能会比较好，
很少有直接把5种语言都翻译成bytecode的，大部分是先翻译成一门缓冲型中间语言。然后统一翻译成为bytecode。我的方案是统一翻译成为ST，因为不打算
支持IL。
realw 发表于 2016-4-6 06:51
61131-3代表的是自动化应用工程师如何使用以下几种语言：
1. SFC
2. 功能块
IL是没必要支持了。
连61131-3的第三版讨论中，都有取消IL的想法的。
本帖最后由 realw 于 2016-4-6 23:00 编辑
gpfrank 发表于 2016-4-6 08:34
IL是没必要支持了。
连61131-3的第三版讨论中，都有取消IL的想法的。
是的，IL好像没有什么支持的必要。 zzsczz 发表于 2016-4-5 14:46
61131-3 中 对 虚拟机 没有 强制性要求，具体实现交给供应商解决；相比之下 JVM CLR之类的很完备了 。（ ...
整体工作量确实很大，
不算用例文件，我的单元测试代码量都快上万了。 realw 发表于 2016-4-6 23:00
整体工作量确实很大，
不算用例文件，我的单元测试代码量都快上万了。
单元测试那么多 ， 那你还不是信心满满 zzsczz 发表于 2016-4-7 09:09
单元测试那么多 ， 那你还不是信心满满
另外，十分想探讨一下写AOT编译器的可行性。
各位有什么想法么？ gpfrank 发表于 2016-4-6 08:34
IL是没必要支持了。
连61131-3的第三版讨论中，都有取消IL的想法的。
另外，十分想探讨一下写AOT编译器的可行性。
各位有什么想法么？ realw 发表于 2016-4-14 14:44
另外，十分想探讨一下写AOT编译器的可行性。
各位有什么想法么？
你讨论的问题已经超越电工的范围了。
上llvm
realw 发表于 2016-4-14 14:44
另外，十分想探讨一下写AOT编译器的可行性。
各位有什么想法么？
看应用场合，运动控制 对 循环时间有要求，效率优先。
至于 PLC 开关量控制么，IO速度跟不上，稳定性优先，AOT需不需要掂量一下。
至于 参考设计么 西家 step7 5.x版本 是 st 编译成 MC7, 控制器 解释执行； 目前 博途 是 ST 编译成机器码 执行；
step5 -> step7 有 15年积累，step7 ->博途 有10多年积累。
建议C后端 ，可用资源多。 realw 发表于 2016-4-14 14:44
另外，十分想探讨一下写AOT编译器的可行性。
各位有什么想法么？
比较赞同ZZSCZZ关于AOT的看法。
用来做逻辑，解释执行已经足够了。
用来做运动控制等，还是追求速度的。
不过话说回来。如果以61131-3的ST为核心，那么就是以运算，复杂逻辑为主的。所以速度还是很重要的。
如果只是逻辑控制的话，可能61131-3的思想还复杂化了，传统的PLC就够用了。
可能国内仿PLC很厉害，很火，和大部分是逻辑控制有关吧！
我看很少人自己研究MC的，很多都是购买了3S等MC的库。我们也没什么大学做这些基础研究感觉！ gpfrank 发表于 2016-4-19 08:24
比较赞同ZZSCZZ关于AOT的看法。
用来做逻辑，解释执行已经足够了。
很少人研究是因为很难么？
还是没法赚到快钱？ zzsczz 发表于 2016-4-14 19:13
看应用场合，运动控制 对 循环时间有要求，效率优先。
至于 PLC 开关量控制么，IO速度跟不上，稳定性优 ...
运动控制的精确程度是1毫秒级别还是1微秒级别的控制？
realw 发表于 2016-4-19 11:43
运动控制的精确程度是1毫秒级别还是1微秒级别的控制？
http://pan.baidu.com/s/1o7UesP0
电流环8位微秒级别
速度环 16位100微秒
位置环32位4毫秒
控制指标 依 需求而定 gpfrank 发表于 2016-4-19 08:24
比较赞同ZZSCZZ关于AOT的看法。
用来做逻辑，解释执行已经足够了。
我没有回复短消息的权限。
我倒是有一些KW的开发包PDF可以发给你。 realw 发表于 2016-5-3 09:11
我没有回复短消息的权限。
我倒是有一些KW的开发包PDF可以发给你。
如果可以的话，可以发送到我的信箱
xtrend_frank ＠126．com
谢谢！ 本帖最后由 gpfrank 于 2016-5-6 08:37 编辑
是KW的一些宣传资料吗？宣传资料我也有。
页:
[1]