2005编译法

Ⅰ 微指令的编译方法有哪些

直接编码（直接控制）方式、字段直接编码方式、字段间接编码方式、混合编码、其他（常数字段）。特点：直接编码速度快，但控存容量极大；字段直接编码缩短了微指令的长度，但是增加了译码电路。

微指令是指在机器的一个CPU周期中，一组实现一定操作功能的微命令的组合，描述微操作的语句。微命令是指控制部件通过控制线向执行部件发出各种控制命令。操作微指令是描述受控电路的操作语句 , 分支微指令是描述控制电路的分支语句。

一条机器指令的功能是若干条微指令组成的序列来实现的，即一条机器指令所完成的操作分成若干条微指令来完成，由微指令进行解释和执行，这个微指令序列通常叫做微程序。

微指令的编译方法是决定微指令格式的主要因素。考虑到速度，成本等原因，在设计计算机时采用不同的编译法 。因此微指令的格式大体分成两类：水平型微指令和垂直型微指令。

Ⅱ 怎样把.cs文件编译成DLL文件

开始--程序--Microsoft Visual Studio.NET 2005--Visual Studio.NET工具，点击其中的“Visual Studio.NET2005命令提示”，就会进入Microsoft Visual Studio.NET 2005命令提示窗口，然后我们用dos命令（cd）进入要编译成dll的cs文件所在的目录，然后输入命令：

csc /out: bin\index.dll /t:library index.cs

回车，就会在bin目录下生成与cs文件同名的dll文件

但是如果这个cs文件引用了bin目录下的另外一个dll文件如comman.dll，则应该这样输入命令：

csc /out: bin\index.dll /r: bin\comman.dll /t:library index.cs

Ⅲ 关于Visual C++2005编译过程中出现的问题知道的高手告诉我下。

此问题的原因是由于VS 2005在生成可执行文件时使用了一种新的技术，该技术生成的可执行文件会伴随生成一个清单文件（manifest file）（.manifest后缀文件）（其本质上是XML文档，你可以用文本编辑器打开看看），并在链接完成后将该清单文件嵌入到exe文件中（默认情况下）。而在FAT32文件系统中，在处理清单文件阶段，当增量链接时不能完成清单文件的更新（默认情况下），于是造成清单文件嵌入失败，从而使该 exe文件运行时没有相应的清单文件而运行失败并提示如上错误。而在NTFS文件系统中则不会出现上面的问题。

比较好的解决方案有两个：

1.在项目的“属性｜配置属性｜清单工具｜常规”中的“使用FAT32解决办法”选择“是”（默认为“否”），重新生成项目即可解决问题。如下图所示： （图略）

2.不启用增量链接。在项目的“属性｜配置属性｜链接器｜常规”中的“启用增量链接”选择“否”。此方法阻断了问题产生的源头，其每次生成exe文件时都直接嵌入清单文件，而不是默认的根据时戳而决定是否更新清单文件。（http://hi..com/sunglows/blog/item/7f90ef08c9539785d0581b3a.html）

英文版的也是一样的。。。。

Ⅳ 计算机编译就是指编码和译码两个过程吗

在微指令的控制字段中,每一位代表一个微命令,在设计微指令时,是否发出某个微命令,只要将控制字段中相应位置成"1"或"0",这样就可打开或关闭某个控制门,这就是直接控制法.
在6.3节中所讲的就是这种方法.但在某些复杂的计算机中,微命令甚至可多达三四百个,这使微指令字长达到难以接受的地步,并要求机器有大容量控制存储器,为了改进设计出现了以下各种编译法.
6.4.1 微指令的编译法(编码译码方法)(2)
2.字段直接编译法
在计算机中的各个控制门,在任一微周期内,不可能同时被打开,而且大部分是关闭的(相应的控制位为"0").所谓微周期,指的是一条微指令所需的执行时间.如果有若干个(一组)微命令,在每次选择使用它们的微周期内,只有一个微命令起作用,那么这若干个微命令是互斥的.
例如,向主存储器发出的读命令和写命令是互斥的;又如在ALU部件中,送往ALU两个输入端的数据来源往往不是唯一的,而每个输入端在任一微周期中只能输入一个数据,因此控制该输人门的微命令是互斥的.
选出互斥的微命令,并将这些微命令编成一组,成为微指令字的一个字段,用二进制编码来表示, 就是字段直接编译法.
6.4.1 微指令的编译法(编码译码方法)(3)
例如,将7个互斥的微命令编成一组,用三位二进制码分别表示每个微命令,那么在微指令中,该字段就从7位减成3位,缩短了微指令长度.而在微指令寄存器的输出端,为该字段增加一个译码器,该译码器的输出即为原来的微命令.
6.4.1 微指令的编译法(编码译码方法)(4)
字段长度与所能表示的微命令数的关系如下:
字段长度 微命令数
2位 2～3
3位 4～7
4位 8～15
一般每个字段要留出一个代码,表示本段不发出任何微命令,因此当字段长度为3位时,最多只能表示7个互斥的微命令,通常代码000表示不发微命令.
6.4.1 微指令的编译法(编码译码方法)(5)
3.字段间接编译法
字段间接编译法是在字段直接编译法的基础上,进一步缩短微指令字长的一种编译法.
如果在字段直接编译法中,还规定一个字段的某些微命令,要兼由另一字段中的某些微命令来解释,称为字段间接编译法.
本方法进一步减少了指令长度,但很可能会削弱微指令的并行控制能力,因此通常只作为直接编译法的一种辅助手段.
6.4.1 微指令的编译法(编码译码方法)(6)
字段A(3位)的微命令还受字段B控制,当字段B发出b1微命令时,字段A发出a1,1,a1,2,…,a1,7中的一个微命令;而当字段B发出b2微命令时,字段A发出a2,1,a2,2,…,a2,7中的一个微命令,仅当A为000时例外,此时什么控制命令都不产生.
6.4.1 微指令的编译法(编码译码方法)(7)
4.常数源字段E
在微指令中,一般设有一个常数源字段E就如指令中的直接操作数一样.E字段一般仅有几位,用来给某些部件发送常数,故有时称为发射字段.
该常数有时作为操作数送入ALU运算;有时作为计算器初值,用来控制微程序的循环次数等.
6.4.2 微程序流的控制 (1)
当前正在执行的微指令,称为现行微指令,现行微指令所在的控制存储器单元的地址称现行微地址,现行微指令执行完毕后,下一条要执行的微指令称为后继微指令,后继微指令所在的控存单元地址称为后继微地址.
所谓微程序流的控制是指当前微指令执行完毕后,怎样控制产生后继微指令的微地址.
与程序设计相似,在微程序设计中除了顺序执行微程序外还存在转移功能和微循环程和微子程序等,这将影响下址的形成.
下面介绍几种常见的产生后继微指令地址的方法.
6.4.2 微程序流的控制 (2)
(1)以增量方式产生后继微地址.
在顺序执行微指令时,后继微地址由现行微地址加上一个增量(通常为1)形成的;而在非顺序执行时则要产生一个转移微地址.
机器加电后执行的第一条微指令地址(微程序入口)来自专门的硬件电路,控制实现取令操作,然后由指令操作码产生后继微地址.接下去,若顺序执行微指令,则将现行微地址主微程序计数器( PC中)+1产生后继微地址;若遇到转移类微指令,则由 PC与形成转移微地址的逻辑电路组合成后继微地址.
6.4.2 微程序流的控制 (3)
6.4.2 微程序流的控制 (4)
(2)增量与下址字段结合产生后继微地址
将微指令的下址字段分成两部分:转移控制字段BCF和转移地址字段BAF,当微程序实现转移时,将BAF送 PC,否则顺序执行下一条微指令( PC+1).
执行微程序条件转移时,决定转移与否的硬件条件有好几种.例如,"运算结果为零","溢出","已完成指定的循环次数"等.
我们假设有八种转移情况,定义了八个微命令(BCF取3位),在图中设置计数器CT用来控制循环次数.如在执行乘(或除)法指令时,经常采用循环执行"加,移位"(或减,移位)的方法,指令开始执行时,在CT中置循环次数)每执行一次循环,计数器减1,当计数器为零时结束循环.又考虑到执行微子程序时,要保留返回微地址,因此图中设置了一个返回寄存器RR.

Ⅳ 如何编译chrome中的depot

1） 了解代码组织结构。
Chrome source非常庞大，并且在其主目录下还包含有工具和组件，任何一个工具和组件也附带有其源代码。首先得熟悉这些源代码的组织结构，在http://src.chromium.org/svn/中包含如下子目录：releases,曾经发布过的chrome源代码的正式版本；trunk，当前最新的源代码。由于releases中的代码比较旧，这里就不做说明了，只说明trunk的结构。在trunk下面有3个重要的目录，deps包含了chrome编译和运行所需要的全部组件的代码。src里面包含的则是chrome的主程序的代码，tools包含的是下载和配置编译所需要的第三方工具的压缩包和源代码，其中就有svn和python这2个比较重要的工具，后面再详细介绍。暂时做这样一个简单的介绍，因为其组织结构比较负责，以后再作补充斧正。

2）如何下载和同步源代码。
首先谈谈下载：
1，最简单的方法是从chrome官网上直接下载源代码压缩包，地址是http://build.chromium.org/buildbot/archives/chromium_tarball.html。

2，或者采用svn从http://src.chromium.org/svn/trunk/src这个地方heckout,这要求你先在本地建一个源代码的主目录。

3，另外一个办法则是采用google提供的一个部署工具depot_tools。虽然这几种办法都可下载完整的源代码，但目前的情况是：chrome基于Visual Stdio 2005 进行编译，如果顺利完成编译工作，自然少不了sln文件，较早的源代码中包含有现成的sln和vcproject文件，但后来做了修改，这些文件被抛弃掉，Google自己开发了一种脚本工具叫做GYP,这个工具采用python编写，GYP采用了自定义的一套规则，用于生成各种工程文件。而关键的python则包含于depot_tools中，因此不论采用什么方法下载的代码，都得下载depot_tools这个工具，以获得必须的工程文件。
depot_tools位于 http://src.chromium.org/svn/trunk/tools 下面，包括一个目录和一个zip格式的压缩包。

3）关于编译器
前面提到Chrome采用Visual Stdio 2005进行编译，根据http://dev.chromium.org的说明，需进行如下操作正常编译
a, 安装Visual Studio 2005.
b, 安装Visual Studio 2005 Service Packe 1.
c, 安装Visual Studio Hotfix 947315.
d, 如果是vista系统，还需安装Visual Studio 2005 Service Packe 1 Update for Windows Vista.
e, 安装Windows 2008 SDK，如果是Visual Studio 2008则不需要这一步。
f, 配置Windows 2008 SDK，使2008 SDK成为首选开发库，以获得一些新功能和特性。办法是在开始->程序->Microsoft Windows SDK v6.1 > Visual Studio Registration > Windows SDK Configuration Tool，选择make current按钮。也可以在VS里面手动配置include和libary路径，效果是一样的。

二，如何配置工程文件
1，如果是采用depot_tools，那么从代码下载到生成sln文件会自动完成。其步骤是
（1）下载depot_tools到本地存储，假设位于d:/depot_tools.
（2）将d:/depot_tools添加到系统环境变量中。
（3）创建一个源代码根目录，假设为 d:/chrome,目录不得包含空格。
（4）在命令行下切换当前目录到d:/chrome。
（5）执行命令 gclient config http://src.chromium.org/svn/trunk/src ,该命令会首先下载svn和python分别到d:/depot_tools/svn_bin和d:/depot_tools/python_bin。
（6）执行命令 gclient sync 这个命令会调用svn同步源代码。这个过程会比较漫长。全部完成之后全部源代码就保存在d:/chrome里面。未编译的代码大约有4个G左右，过程将十分漫长。这样获得的源代码已经包含所有的工程文件，可直接打开。

重点说明一下gclient，它实际上是一个批处理文件，它主要做了如下一些事情，首先设置环境变量，如代码根目录，工具根目录等。其次调用win_tools.bat从服务器下载svn和python。最后调用python.exe对Chrome.gyp进行解析生成所有工程文件。
另外需要说明的是，gclient sync的过程非常漫长，根据命令行的提示来看总共需要同步67个项目（不是工程），期间可能会因为一些原因导致错误而退出这个过程，需要继续调用sync。比如网络出现故障svn会多次进入sleep状态然后重试，如果多次失败就会报错退出，还有的情况是某些子目录的属性问题无法同步，可根据提示进行操作。还有个目前新出现的问题，下面2个目录“src/webkit/data/layout_tests/LayoutTests”和“src/third_party/WebKit/LayoutTests”的源代码是从src.webkit.org签出来的，但是这个网站目前存在问题无法签出代码， 需要屏蔽掉这2个目录，由于里面是测试代码，即使丢弃也不会影响整个工程的编译，方法是打开trunk下面的.gclient文件，向里面添加如下内容
"custom_deps" : {
"src/webkit/data/layout_tests/LayoutTests":None,
"src/third_party/WebKit/LayoutTests":None,
},

这样svn就能完成代码的同步了。最后gclient会调用depot_tools/python_bin/python.exe 对 src/build/gyp_
chromium进行处理，这样就得到了所有的sln和vcproject文件。

2，如果是下载的代码压缩包或者checkout的代码，代码目录里面没有sln文件，这个时候需要调用命令行进入源代码根目录，然后执行命令 gclient runhooks --force，命令执行后会直接对Chrome.gyp进行解析,生成sln文件。

在实际下载过程中，最开始的时候我用TortoiseSVN从http://src.chromium.org/svn/trunk/src checkout源代码，但是得到的代码只有几百兆，执行gclient runhooks --force命令后也没有找到sln文件，具体原因未知，不建议使用此方式。而直接下载代码压缩包的方式没有尝试过，不知道是否可行。因此最稳妥的方法还是使用depot_tools来部署和处理源代码。

三 编译工程
启动Visual Studio 2005打开 src/chrome/browser/chrome.sln,或者打开src/build/all.sln,如果打开的是chrome.sln里面包含480个工程，而all.sln则包含507个工程，一些09年的编译说明提到有300左右的工程，可见chrome的代码变动比较大。对整个解决方案进行编译，打开需要2个小时才能完成编译，视硬件环境而定，内存越大越快，推荐4G以上内存，酷睿2核或者4核。编译完成以后据说会占用30G的空间。编译后的文件位于 d:/chorme/chrome/debug 目录或者 d:/chorme/chrome/release目录下。

Ⅵ visual c++ 2005 里怎么没有编译和运行按钮

6.0 可以直接打开.cpp的文件来编译并生成.exe 但是2005就必须执行项目才可以，直接打开.cpp的文件，编译，执行按钮是灰的，不能用，只能新建一个空项目，再将代码拷进去，这样就可以编译了

Ⅶ debug和release两种编译方法的区别与联系

Debug 为调试版本，Release 为发布版本，从开发者和用户视角看，他们的区别如下：

一、从开发者视角，Debug和Release的区别，主要是编译器的选项不同，Debug 包含调试信息，并且不作任何优化，便于程序员调试程序。Release 往往是进行了各种优化，使得程序在代码大小和运行速度上都是最优的，以便用户很好地使用。

Debug 版本 相关参数解释：
参数 含义
/MDd /MLd 或 /MTd 使用 Debug runtime library(调试版本的运行时刻函数库)
/Od 关闭优化开关
/D "_DEBUG" 相当于 #define _DEBUG,打开编译调试代码开关(主要针对assert函数)
/ZI
创建 Edit and continue(编辑继续)数据库，这样在调试过程中如果修改了源代码不需重新编译
GZ 可以帮助捕获内存错误

Release 版本 参数含义
/MD /ML 或 /MT 使用发布版本的运行时刻函数库
/O1 或 /O2 优化开关，使程序最小或最快
/D "NDEBUG" 关闭条件编译调试代码开关(即不编译assert函数)
/GF 合并重复的字符串，并将字符串常量放到只读内存，防止被修改

二、使用者视角，我们下载软件的时候，一般应该选择Release版。Debug一般比测试版更粗，主要提供给高级测试者反馈修改意见。

Ⅷ 关于Visual C++2005怎么编译啊

首先，抛开编译器不说。一个C++程序必须要这样做：
1. 按照C++语法编写程序。（即：源代码）
2. 将源代码通过编译器的编译。生成Exe（即：可执行文件）Visual C++ 2005就是一个编译器。
其次，对于Visual C++ 2005 这个工具而言，它可以创建Win32控制台程序。也可以创建MFC程序，还可以创建其它程序。通过你的描述，需要创建Win32控制台程序。
关于Visual C++2005的使用，由于需要截图所以不方便贴。你可以到QQ群：140038975找我。

Ⅸ VS2005 debug编译和msbuild编译 有什么区别

用aspnet_compiler发布网站在asp.net 2.0模型中，vs2005已经完全脱离了编译而成为了一个彻底的ide.算是一个不小的改动。其中更是取消了有关Web Application的概念，使得习惯了vs2003的人刚开始的时候会有一些摸不着头脑。下面简单说一下我在使用过程中自己总结的，算是一点经验。

新建web工程并且位置是文件系统的时候，vs2005只是帮你建好了一个sln文件，这个东西只是指引msbuild 如何进行编译的，过程是：ide 调用 msbuild ,msbuild解析sln文件,msbuild调用aspnet_compiler.exe进行网站的编译。所以aspnet_compiler.exe只是负责进行网站的编译的。

预编译的概念在 .netframework 1.1 里面就存在了，vs2003中的预编译指的是将页面对应的cs/vb文件与resx文件编译后统一集成到一个dll中放到bin目录下，将aspx文件直接拷贝过去。这样做会留下隐患，因为aspx文件就直接暴露在最后的发行包中，如果完全是codeb-behind模型还好，只能改改界面，如果采用了页面上的来生成页面，源代码就暴露了。针对这些问题，vs2005采用了一种新的模式。
请参看ASP.NET 编译工具 (Aspnet_compiler.exe) 这篇文章了解对各种文件的处理方式。

IDE发布：
vs2005中选择 生成-〉发布网站，在对话框中的操作将映射到aspnet_compiler.exe的参数中，可更新的发布对应 -u，其他选项类似，请参考上面的文章了解。
注意：发布时将忽略web.config中的debug参数，统一生成无调试信息的文件。

手工编译：
简单说来，如果是无更新发布模式编译，appcode下面的class编译成dll放在bin下,页面内容清空位置不变作占位用，同时页面被编译成一个随机名称的dll,增加一个同名.compiled文件到bin目录下，内容大概如下：

<?xml version="1.0" encoding="utf-8"?>
<preserve resultType="3" virtualPath="/Forum/AdminList.aspx" hash="6772609c3" filehash="49154463f1d6738c" flags="110000" assembly="App_Web_hmrycg3w" type="ASP.forum_adminlist_aspx">
<filedeps>
<filedep name="/Controls/footer.ascx" />
<filedep name="/Controls/header.ascx" />
<filedep name="/Forum/AdminList.aspx" />
<filedep name="/Forum/AdminList.aspx.cs" />
<filedep name="/Forum/menu.ascx" />
<filedep name="/Forum/menu.ascx.cs" />
</filedeps>
</preserve>
里面只是列出了页面上的customcontrol,这里已经完成了和masterfile的映射。这样最大限度的保护了页面的敏感信息，发布过的网站中只能看见一堆文件名了。可更新的发布模式与vs2003类似，页面就直接拷贝过来不予编译了。

讲了一堆原理，下面说一下aspnet_compiler.exe的调用方法,这是我使用的例子

我的开发目录是这样的

Project/
library/
devroot/
pubroot/
proj.sln
使用的命令如下：

aspnet_compiler -v / -p .\devroot -f .\pubroot
分析：

-v / 指明了iis的虚拟目录
-p .\devroot 表示代码实际位置
.\pubroot 指明了要发布的位置
-f 表示强制改写目标位置
你还可以用-u来进行传统意义上的预编译，-d来插入编译符号。

总的来说，aspnet_compile结合msbuild,提供了一个很好的自动化编译环境，值得研究研究：）