diameter 发表于 2011-11-30 18:07:59

正式宣布ADCS退化为AtomProject

ADCS的原帖
http://www.cncalc.org/thread-6376-1-1.html
因为种种原因.....这个计划放弃掉了，目前我手头正在开发的叫AtomCompiler....
使用了ADCS的lexer....
采用虚拟机执行，可以模拟SH中断，到时候完整的9860端SDK还可以有一个虚拟的AtomDesktop
问题是不支持浮点数....语言难度可能比较大（最初版本接近纯汇编）
大家先yy一下吧

chsi 发表于 2011-11-30 19:26:35

支持一下。

imath 发表于 2011-11-30 20:57:36

我觉得还是先发布再介绍吧。正如以前人造人所说的。
比如你说的Mathpad g1a版本，到现在影子都没一个。

hcz 发表于 2011-11-30 21:31:29

挺巧的，最近正好也在折腾解释语言（给GLPoint项目）

一起加油吧

ps.真心的建议，初期花费计划之外的时间来改进设计，在后面大大节省时间。

Wudy 发表于 2011-12-2 18:13:27

不用弄这个了，我觉得malical如果做下去可以做的很好

diameter 发表于 2011-12-2 21:21:42

5# Wudy

不搞这个恐怕不能获得最佳的速度啊....Malical的复杂度已经到达极限了，如果再弄出OOP的特性来，9860根本就带不动....parser和eval会随着支持的函数的增多越来越慢（O(N^2)的线性查找匹配）

Wudy 发表于 2011-12-2 21:24:03

6# diameter
原来这样 0.0
本来还指望把malical的函数库扩充到跟SDK差不多，现在只能等你这个了- -

wtof1996 发表于 2011-12-3 15:12:41

恩，打算寒假研究下sdk，写个g1a版的黑客游戏。
目前已有原型，不过要备战期末。不然cx就泡汤了。。。。

Wudy 发表于 2011-12-9 19:47:36

本帖最后由 Wudy 于 2011-12-9 19:58 编辑

5# Wudy
不搞这个恐怕不能获得最佳的速度啊....Malical的复杂度已经到达极限了，如果再弄出OOP的特性来，9860根本就带不动....parser和eval会随着支持的函数的增多越来越慢（O(N^2)的线性查找匹配）
diameter 发表于 2011-12-2 21:21 http://www.cncalc.org/images/common/back.gif
函数查找的复杂度不是O(n)吗？
函数多了用二分查找会不会更好

Wudy 发表于 2011-12-9 19:48:24

本帖最后由 Wudy 于 2011-12-9 19:59 编辑

5# Wudy
不搞这个恐怕不能获得最佳的速度啊....Malical的复杂度已经到达极限了，如果再弄出OOP的特性来，9860根本就带不动....parser和eval会随着支持的函数的增多越来越慢（O(N^2)的线性查找匹配）
diameter 发表于 2011-12-2 21:21 http://www.cncalc.org/images/common/back.gif
函数查找的复杂度不是O(n)吗？
函数多了用二分查找会不会更好
——————————————————————————————————————————————————————
手机连发了……

diameter 发表于 2011-12-9 23:12:58

10# Wudy

比较加上比较字符串函数的调用就成O(N^2)了.....就这点来看解释器是跑不过字节码的。二分法查找的话还要对全局的已知标识符进行排序....划得来么？不只是函数，每一个输入的标识符都要逐一与已知的标识符进行比较才能确定用途。考虑到Malical蛋疼的二义性处理......

Malical其实现有的bug大大的，比如可以使用关键字当标识符（只要不出现在行首就认不出来，这是Parser设计时失误）还有就是eval分不清负号与减号...

Wudy 发表于 2011-12-10 00:56:08

标题

本帖最后由 Wudy 于 2011-12-10 01:04 编辑

11# diameter
变量就不用二分查找了。
函数可以在预扫描后加到库函数里一起排序，虽然运行前会卡一下，但运行时速度应该会有提高。而且这样可以支持数量很大的函数库

NAT 发表于 2012-1-20 17:31:36

编的咋样啦？
页: [1]
查看完整版本: 正式宣布ADCS退化为AtomProject