谈谈个人对SKYEYE的看法及目前在做的一些事情

zyjjingle

首先谈谈个人的看法，SKYEYE目前对CPU核的仿真部分做的比较完善，但对体系架构及外设的虚拟部分的支持还比较弱，这使得它在实际的产品开发过程很难有多大的利用价值。因为我们代码在它上面基本运行不下去，经常会卡在与外设的交互上。所以为了让SKYEYE能真正为芯片开发及嵌入式产品开发提供使用价值的话，SKYEYE必须要做到产品级的虚拟。这就是说SKYEYE要虚拟实际产品中使用到的所有设备，而且要尽可能保持各个设备操作的时序。下载到实际产品的代码同样可以下载到虚拟机中运行，无需任何特殊的配置，而且运行的效果要一样（这里只能说效果，虚拟机时序和实际设备的时序肯定无法做到一样）。
我觉得SKYEYE要做到类似于WINCE虚拟机的那样的一种效果，它要有个设备界面
（可以是实际产品的正面图片）在它上面有屏幕、按键、开关等等，反正就是说它看起来和实际的产品是一样的，用户可在上面进行操作。如果在PC上有相应设备，尽量将虚拟机的外设映射到PC机的外设上，比较键盘，鼠标，串口，网络，USB，声音，并口等等，存储设备映射到文件系统。对于有些特殊的设备可以考虑开发一些虚拟设备，比如说虚拟打印机，虚拟读卡器等等。
为了能达到这些目标，我觉的SKYEYE在程序架构上要进行部分调整，应采用插件的技术来实现，将程序分成窗口界面部分，SDK部分和插件部分，这样可以保证SDK部分的相对稳定，同时便于ARCH和MACH部分开发维护。
窗口界面：1。虚拟机的管理（停止，重启，保存等等）
          2。虚拟机的配置（图形界面的配置）
        3。虚拟机界面维护及PC机操作系统事件的响应
SDK部分：1。插件管理
        2。设备管理
        3。GDBSERVER接口
插件部分：1。ARCH部分的arm,mips,ppc,bfin,cold-fire都以插件形式存在，SDK根据设备的配置情况动态加载
          2.。所有MACH部分都以插件形式存在，比如EP9312，AT91，CLPS7500等等，SDK根据设备的配
              置情况动态加载
          3。 虚拟设备
我目前在做的一些事情：
1．由于我对WINDOWS下编程比较熟悉，对VC6.0也比较偏好，所以就将SKYEYE移植到VC6。0下，在代码移植的过程中我选择了和WINDOWS系统绑定，没有考虑跨平台特性了。为了便于事件的响应的处理，将SKYEYE作为一个线程来运行，在双核CPU的PC机运行性能还可以，在单核的PC机可能较慢（还没测试）
2．用C＋＋类的方式重新整理的部分代码
3．按上面的思路对程序结构进行了调整
4．按插件形式编写我公司一颗SOC的参考实现，及AT91的参考实现
5．对SKYEYE进行部分优化，在我的笔记本（T61，T7250 2G）下能达到大概25MIPS的速度（外设包括10个GPIO口，5个UART，1个NET，640*480的16色屏，1个AT键盘，2片NORFLASH）

目前代码正在整理中，希望2－3个星期后能上传给大家参考。
有用AT91开发的朋友能否贴一张你们产品的正面照，及产品的配置情况给我（特别是PIO和外设的连接情况），看看我能否为它开发一个虚拟机（目前正在为AT91开发一个参考实现）

mach_at91.rar是我目前按此架构开发的一个插件参考（尚未测试中，可能有问题），希望有兴趣的朋友看看，
提些意见，先谢啦！

待续。。。

[ 本帖最后由 zyjjingle 于 2008-10-27 23:35 编辑 ]

ksh

1. 你提出的第一个问题也是我们一直考虑的问题。因为我们的资源有限（有限的开发人员，时间和精力），如何能够把这些资源分配到最利于SkyEye发展的方向? 我们目前还在关注于架构和API层面。实际上对于mach模拟的进一步晚上，和产品级别的模拟，更多的是希望交给产品的厂商，或者其他一些嵌入式爱好者去做。SkyEye的核心开发人员目前关注于架构模拟的稳定性和提供更加合理高效的框架上，我们的目标是让一些系统软件开发人员很容易基于SkyEye做扩展。我们当前有限的资源不会投入到某一个特定的产品上，当然如果这个产品的厂商资助SkyEye项目，可以考虑。

2. 关于插件和GUI，我想这也是我们的下一步计划。我们最重要的两个发展方向就是可扩展性和易用性。因为当前核心的架构还不完善，有些架构的模拟还没有完全稳定下来，我们暂时没有太多时间精力去关注插件和GUI

3. 你在windows上的工作非常好。但是从维护和升级的角度讲，最好还是能够和SkyEye当前的源码进行兼容。这样可以随着SkyEye版本的不断发布，可以对你的这个分支版本进行方便的维护和升级。如果有机会，能否介绍一下你的插件的一些思想和架构，多谢。

ihw

我就很想用skyeye搭建一个产品开发的虚拟环境
要知道整硬件是很麻烦的，
最好是类似的虚拟手段，启动快，性能好
能够把需要的东西都模拟了
其实开发就是音频，视频和网络
输入就是用IR或者gpio/adc的按键或者touch screen

最近这段时间来看
确实skyeye离实际应用的距离还是比较远

没有楼主这么牛了，我就是一个使用者。

ihw

另外楼主是什么公司的，你们公司有什么好的SoC？

ihw

找一个公司把skyeye商业化了有前途么？

ksh

SkyEye目前的定位：高效易用的，具有高度可扩性的调试开发环境及测试环境。

我们有可能会在年底着手SkyEye的GUI的开发，并且希望能够在这样的一个GUI工具里面集成一些SkyEye现有的调试手段和SkyEye团队的在系统软件上的一些调试经验和策略，提供一个方便易用的界面。

也希望大家能够对未来的发展给出更多的建议。。。。

ksh

目前的问题是如果我们的整体架构还没有完全做好，就去花很多资源做某一款产品的非常细节的模拟。当以后发现整体架构需要改变，很可能前面做的某一产品级的模拟需要做很多改动。

为了尽可能容纳不同的外设，不同的架构和处理器，以及考虑到今后的多核模拟，丰富调试手段等等问题，我们需要提供尽可能大的可扩展性，这是我们当前关注的一个方向。

当前的SkyEye开发的进度比较缓慢一些，可能没有达到大家的预期。主要由于：
1. SkyEye的可利用的开发资源有限，有限的时间和人力
2. 目前SkyEye的代码已经超过10万行，测试和维护的成本越来越高。

希望继续得到大家的支持和关注。。。

ihw

我觉得像MiniGUI这种模式是可以的
比如QT这样的公司

要赢利，才能壮大

skyeye本身是有价值的

zyjjingle

我前段时间在CODEBLOCK基础之上开发一个了嵌入式的集成开发环境（NEBDEV），我的目标就是希望为嵌入式开发提供一个类似VC6。0的集成开发环境，目前这个开发环境的初始版本已经开发差不多了，编译及调试都可实现，目前支持的编译器包括（MINGW－GCC，MINGW-ARM-GCC,及ARM ADT的工具链），调试器基于GDB，目前调试的功能基本上已经将GDB所支持的功能图形化了（断点设置，变量查看，内存信息，调用堆栈，汇编代码）。但在测试当中发现，如果没有虚拟机的支持，实际应用程序的调试仿真无法进行下去。所以最近就在SKYEYE之上进行了部分平台的虚拟机开发，我目前的思路就是按产品的概念了来完善SKYEYE已有部分，同时加强了SKYEYE的调试接口部分（主要考虑和我的IDE的交互），SKYEYE原有部分遇到异常会退出程序，为了和IDE配合，我基本上将这些异常回馈到GDB让GDB产生异常，最终让IDE下的程序在异常点BREAK。
目前我正在做SKYEYE插件化的改造(WINDOWS下），目前MACH部分和ARCH部分已经改造的差不多了，我最近几天正在整理代码，同时在建立一些MARCH和ARCH的插件模版。
另：我是福建新大陆公司，主要在做芯片配套工作

[ 本帖最后由 zyjjingle 于 2008-10-29 16:17 编辑 ]

zyjjingle

说说我对SKYEYE速度优化的基本思路：
1。SKYEY原有的部分对CACHE已经进行处理，但CACHE性能并没有正真体现出来，考虑到ARM的最小的页面切换是4K大小，所以可以利用这4K的原子单位来做进一步的CACHE,所有操作过的BYTE，HALFWORD,WORD的读写建立一个地址对（访问地址和虚拟机里的内存地址），每次在访问之前先判断是否在4K空间内，如果是就直接利用已经缓存的内存地址，不再进行一系列复杂的地址索引了（IO操作除外），这样可以大大提高虚拟机的性能，我测试的结果发现可以达到97％以上的命中率。（在TLB和CACHE的有些操作下，要相应清除这些地址对）
2。SKYEYE的原有部分，存在大量的ARMul_State* state的参数传递，也是会影响效率的，将ARMul_State作为全局变量，去掉这个参数
3。对ARMemu下的循环进行优化，假设虚拟机能达到20MIPS的速度，那就是说那个循环每秒就要跑2千万次，因此要尽量优化，调用函数的地方尽量将他inline进来，在函数内的判断移到函数外判断，能优化就优化

[ 本帖最后由 zyjjingle 于 2008-10-29 16:47 编辑 ]