Closed Lumin-exdo closed 1 month ago
我认为tokens结构体内应该把char [32]改成word_t num,这样寄存器的值在输入环节就直接在make_token这一步被isa_reg_str2val函数识别处理成对应的值存到num里,不保留到后面eval环节处理,因为eval里面扎堆处理时,由于那个整体p<q,需要逐项判断主运算符op是哪个字符,发现都不是,再逐次判断到底是0x十六进制还是指针还是取寄存器值,浪费了大量判断次数,而如果在make_token识别出是\$[\$0-9a-z]{2,3}属于寄存器的值这个类型时就当即判断,不留到后面重复判断一遍,就简明很多;但我不确定这样做是否符合开发规范,是否混淆了识别原始表达式与加工过程,只是提一点建议。这样改,就提前处理了十进制数、十六进制数和取寄存器值。
其实把加工叫成“预处理”,听起来就合理多了,make_token里如果预处理,后面的函数体内再正式处理起来就容易多了
token本身和token代表的值是两回事,框架代码中的char [32]是存放token本身。如果你想在这里解析出token的值,你可以自己添加一个num成员。
char [32]
num
由于暂无后续回复,本PR先关闭。
我认为tokens结构体内应该把char [32]改成word_t num,这样寄存器的值在输入环节就直接在make_token这一步被isa_reg_str2val函数识别处理成对应的值存到num里,不保留到后面eval环节处理,因为eval里面扎堆处理时,由于那个整体p<q,需要逐项判断主运算符op是哪个字符,发现都不是,再逐次判断到底是0x十六进制还是指针还是取寄存器值,浪费了大量判断次数,而如果在make_token识别出是\$[\$0-9a-z]{2,3}属于寄存器的值这个类型时就当即判断,不留到后面重复判断一遍,就简明很多;但我不确定这样做是否符合开发规范,是否混淆了识别原始表达式与加工过程,只是提一点建议。这样改,就提前处理了十进制数、十六进制数和取寄存器值。