语言格式

语言格式（精选5篇）

语言格式 篇1

1. 引言

VHDL语言是一种集设计、模拟、综合于一体的标准硬件描述语言, 它经过VHDL编译器的分析进行相应的语法及语义检查后, 转换为一种中间数据格式。中间数据格式是VHDL源描述的一种内部表示形式, 它能够保存完整的语义信息。每个设计单元以中间数据格式的形式独立存入设计库中, 作为后端的应用。对于不同的应用, 其相应的中间数据格式各有不同的, 但从目前的所使用的各种中间数据格式, 大部分都是基于属性表示的。所谓的属性表示就是VHDL语言中的所有结构都采用结构名和其属性来表示, 结构名指的是VHDL语言中的各种基本结构名, 如entity, architecture等;属性分为值属性和关联属性, 值属性表示的是一些结构的基本信息, 关联属性表示指向别的结点名或类名的指针, 表示该结点与其它结点的关联关系。属性表示的不是一种特定的数据结构, 而是一种抽象的数据类型, 这种抽象的数据类型是独立于各“后端”工具数据格式的特定要求。

2. 中间数据格式设计准则

对中间数据格式的设计, 本文考虑了以下几个准则:

(1) 基本的要求是能够充分反映VHDL作为硬件描述语言的特点, 完整地保存源程序的各种信息;其所具有的数据类型能反映VHDL源程序中所有词法、语法和静态语义的信息。

(2) 必须独立于各“后端”工具, 即尽可能地避免使用对于某一特定工具的中间数据格式的实现方法。

(3) 结构清晰, 层次分明, 逻辑关系和物理连接关系都要表示清楚。

(4) 有效性, 其本身必须能被有效的生成。

根据这几个准则, 本文中采用了有向无环图 (DAG) 作为其中间表示, 它是一种推广的树结构, 和语法树相比, 它以更紧凑的方式给出了同样的信息, 其中的结点可以有多个父结点, 从而允许表达式能够使用多次。

3. 中间数据格式的基本构成

一个完整的VHDL语言程序通常由设计库、设计单元和基本单元组成。设计库主要有IEEE、STD及用户库, 它们作为VHDL设计的最高层。设计单元能够独立的被分析, 并生成独立的中间数据单元保存在设计库中。而还有一些信号定义、过程语句及选择语句之类的单元则称为基本单元, 所有的设计单元都是由这些基本单元所构成。基于VHDL源程序这样的层次结构, 将VHDL元素划分为三种对象类型:库对象、设计对象及基本对象。库对象表示设计库, 设计对象表示设计单元, 而基本对象则表示了VHDL的其它所有的基本元素。在本文中, 一个完整的、被存储的中间数据格式单元是由一个设计对象和多个基本对象组成。在其有向无环图表示结构中, 顶点代表各种基本对象, 边表示各个对象之间的关联关系。

3.1 设计对象

设计单元是由库单元及上下文语句 (context clause) 所构成, VHDL语言包括五种库单元:实体定义 (entity declaration) 、包定义 (package declaration) 、配置定义 (configuration declaration) 、结构体 (architecture body) 和包实体 (package body) , 前三种称为主单元, 后两种称为次单元。因此也相应出现五种设计单元, 这些设计单元可独立的被分析, 所得到的中间数据格式文件存放在设计库中。设计对象类的定义如下:

其中, Type表示设计单元的类型, 如entity或architecture类型;pname表示主单元的名字;sname表示与之相关的次单元的名字, 在次单元生成中间数据格式时, 其中间数据文件名是由主单元名+次单元名组成。如主单元entity名为A1, 次单元architecture名为B1, 则次单元最终生成的中间数据文件名为A1_B1;path表示这个设计单元经分析后所存放的位置;spath表示这个设计单元属于哪个VHDL源文件;count表示这个设计单元共包含多少个基本对象;top是一个基本对象指针类型, 它指向这个设计单元中的唯一一个库单元, 是这个有向图的顶点, 也是这个设计单元的入口点;_extTable是一个线性表类型, 存储了这个设计单元的外部关联对象, 如次单元architecture可能关联到主单元entity中的端口声明对象;_mapTable存放这个设计单元的内部基本对象, 也是一个单向的线性链表, 每一个设计单元都有各自独立的maptable表。

3.2 基本对象[14]

在VHDL语言中间数据格式中, 除了设计单元和设计库外, 所有的VHDL结构都是由基本对象来表示的[7]。一个基本对象是由值属性和关联属性来描述。值属性表示了对象本身的一些基本信息, 其内容在对象产生时就已经确定, 不能被修改, 如名字、类型和所在行数等[8];关联属性所存储的是与这个对象相联系的对象指针, 把各个对象互相联系起来。在对象与对象之间存在两种关联, 一种是一对一的关联, 也就是一个对象只指向一个对象;另一种是一对多的关联, 一个对象指向多个对象, 这种情况下, 对应的多个对象用单链表存储[9]。利用这种关联属性, 可清晰的表示VHDL源程序中各种结构间的逻辑关系。

根据VHDL的语法, 共设计了27种基本对象, 每一种基本对象对应到VHDL中的一种基本结构, 它们分别作为有向图中的一个结点, 每一个结点又是一个记录, 它们的域表示由词法分析、语法分析和语义分析程序收集的信息[10]。其27种基本对象类型如图1所示, 标识符前面带有O的是基本对象类型, 其他的是基本类型下的子类型。如字面量又分为整型字面量 (L_integer) 、浮点型字面量 (L_float) 、字符串型字面量 (L_string) 、位字符串型字面量 (L_bit_string) 及空型 (L_null) 。在用C++开发时, 每一种基本对象都由一个类来实现, 其值属性和关联属性作为类的私有成员, 对这些域的处理函数作为类的成员函数。

4. 实例及其结果

下面是一个两输入与门实体部分的VHDL描述。

由前面可知, 名为“and_gate”的实体 (entity) 可以作为一个单独的设计单元被分析, 经VHDL词法、语法及语义分析完成后, 可得到该设计单元对应的中间数据格式。采用本文所提出的VHDL语言的中间数据格式结构, “and_gate”设计单元可被表示为图2所示的结构形式, 图的顶部表格中所描述的是该设计单元的基本信息, 它表明了这个设计单元的类型、名字、所处的位置, 还有就是通过分析后, 这个设计单元所包含的基本对象数目及设计单元的入口对象。这与前面所定义的设计对象类中的值属性和关联属性一一对应, 前面六个都是

值属性, 记录的都是整型或字符型值。“count”值为10, 表明此设计单元共包含有10个基本对象;“top”的内容为6, 表明该设计单元的库单元, 也就是其顶层结点是编号为6的对象, 在maptable表中可得出, 编号为6的对象是O_entity对象, 因此该指针指向基本对象O_entity。maptable域指向图中左边部分的maptable表, 它按顺序存储了该设计单元的所有基本对象。该设计单元涉及到一个外部连接, 也就是所有端口信号关联到STD库中的某一个类型对象, 因此extable表中存有一外部基本对象O_type。

图2的中间部分表示的是各基本对象之间的关联关系。粗线条粗箭头表示的是各基本对象之间的关联, 细线条细箭头表示该设计单元中所有的基本对象在maptable表中所存储位置, 各对象是以对象类型为关键字进行存储, 按VHDL源码分析的先后顺序将各种基本对象依次存储。

5. 结束语

本文介绍了一种基于属性表示方法的VHDL中间数据格式, 这种格式已经使用在VHDL分析器中, 并且这种中间数据格式已经作为某一项工程开发的基础, 经多种实例的验证, 有其自身的可用性和可行性。在分析过程中, 对VHDL中的某些结构还需进一步的优化, 以便其得到的结果更适用。

摘要：VHDL语言中间数据格式是VHDL设计环境的要求, 用来作为VHDL开发环境中各设计工具的一个公共数据界面。本文给出的是一种基于属性表示的中间数据格式, 是一种通用的VHDL中间数据表示方法, 采用有向无环图 (DAG) 作为其抽象结构, 它是一种推广的树结构。这种中间数据格式已经作为某一项工程开发的基础, 经多种实例的验证, 有其自身的可用性和可行性。

关键词：VHDL,中间数据格式,属性,有向无环图

参考文献

[1]李广军.VHDL实用教程.电子科技大学出版社.2000

[2]牛振东, 徐嵩杰, 刘明业.VHDL语言分析器的设计与实现.计算机学报, 1994, Vol.17, No.10:777-785

[3]王兼明.V H D L中间数据格式及其设计库.计算机学报.1992, No.523:522-528

[4]Wilsey, P.A.Martin, D.E.Subramani, K.SAVANT/TyVIS/WARPED:components for the analysis and simulation of VHDL.Verilog HDL Conference and VHDL International Users Forum, 1998.IVC/VIUF, 195-201

[5]J.Willis, G.Peterson, A.Zamfirescu.Advanced Intermediate Representation with Extensibility (AIRE) .Proceedings of the Fall1996VHDL International User’s Forum1996

[6]Brown.M.“vhdl intermediate form standardization;process, issues and status”.publied by Design Automation Conference, 1992.EURO-VHDL'92, EURO-DAC'92.European7-10Sept.1992Page (s) :758–762.

[7]IEEE Standard VHDL Language Reference Manual.IEEE Std.1076-1999, IEEE1999.

[8]Charles N.Fischer, Richard J.LeBlanc, Jr.编译器构造-C语言描述.机械工业出版社.2005

[9]Doboli, A.;Vemuri, A.;A VHDL-AMS compiler and architecture generator for behavioral synthesis of analog systems Design.Automation and Test in Europe Conference and Exhibition1999.Proceedings9-12March1999Page (s) :338-345

[10]陈火旺刘春林.程序设计语言编译原理.国防工业出版社.1990

语言格式 篇2

一、教学目标（活动目标）

（一般从发音、字词、朗诵、常识或知识、德育、拓展活动等方面确定）

二、教学重点：以幼儿语言发展为主

三、教学难点：（难点不一定是重点，指教学中难度比较大的环节）

四、教学方法：（比如讲授法、练习法、提问法、演示法等）

五、教学准备

（一般包括与教材内容配套的课件、实物、图片、音乐、视频材料、奖品及各种活动用的材料）

六、教学过程

一般包括：

1、导入部分（一般通过提问、谈话、出示课件或实物图片、场景等方式，要灵活运用，出奇制胜。）

2、完整朗诵或讲述部分（教师要声情并茂、速度缓慢地朗诵，如果教师自身水平有限，也可以采用录音）

3、讲解诗歌（采用各种有效方法，引导幼儿分析理解诗歌内容。此部分要注意教学重点和教学难点。）

4、教幼儿朗诵或讲述，注意完成教学重点。

5、采用各种练习方式让幼儿朗诵（或讲述）并记熟儿歌（故事）。

6、（建议：带领幼儿根据教材内容进行游戏、表演、手工制作或其他拓展活动。）

七、结束部分

1、教师小结教学效果，给予表扬和鼓励。

2、根据教材内容，适当进行德育教育。

3、结束活动，请幼儿休息或自由活动。

语言格式 篇3

DWARF是一种常用的调试信息格式,它包括DWARF1、DWARF2、DWARF3三个版本。其中DWARF2格式是使用最广泛,定义最标准的DWARF格式。BWDSP芯片调试系统支持对DWARF2版本调试信息的分析。

DWARF格式中,行号调试信息在.debug_line节区存储,而高级语言的源文件、函数、变量、类型等调试信息在.debug_info节区中存储。该文主要介绍对高级语言调试信息的分析,提出的算法主要针对C语言调试信息。

.debug_info节区中,调试信息以节点的形式存在。节点可以存储一个源文件的调试信息、一个变量的调试信息、一个函数的调试信息等等。节点之间存在兄弟或父子的关系,一个源文件的调试信息节点形成一个调试信息树。若被调试文件由多个源文件联合编译生成,则.debug_info节区会包含多个源文件的调试信息,这些源文件的调试信息树构成一个调试信息森林数据结构。

.debug_info节区中的节点有不同的类型和格式,但大多数节点的类型和格式是相同的,为了节省存储空间,DWARF在.debug_abbrev节区中定义了所有节点的类型和格式。.debug_info节区中存储节点调试信息时,只需要引用.debug_abbrev节区中存储的节点类型格式等信息即可,然后只存储节点的取值即可。所以,分析.debug_abbrev节区是分析.debug_info节区的先决条件。

本文将详细介绍DWARF格式C语言调试信息的格式以及在BWDSP系列芯片中应用的一种自主可控的解析方法和存储数据结构。

1 DWARF格式C语言调试信息简介

DWARF格式高级语言调试信息以树的形式存在,所有调试信息都可以用树中的节点表示。一个节点用一个整数来表示其类型。DDWWAARRFF22中预定义的节点类型有如表11所示。

每个节点表示一种调试信息。例如,DW_TAG_compile_unit表示源文件调试信息,DW_TAG_variable表示变量,DW_TAG_subprogram表示函数,DW_TAG_typedef表示自定义类型等等。每个节点有若干组属性,这些属性描述该节点的特点。例如,常见的DW_TAG_compile_unit节点的属性及属性的格式如图1所示。该节点描述源文件的调试信息,每个源文件都有一个该类型的节点描述。

每个预定义的TAG具有的属性并不是固定的。例如,常见的节点DW_TAG_compile_unit具有上述几种属性,但对不同的源文件DW_TAG_compile_unit节点也可以具有其他属性。所以,在表示一个节点的调试信息时,必须把它具有什么属性也表示出来。DWARF2中预定义的属性值如表2所示。

节点的每种属性都要有一个确定的取值,该属性的取值可以有多种格式,有4字节整数、2字节整数、字符串、LEB128数、节区内的偏移值等等。LEB128数是DWARF定义的一种压缩存储数据方式,它可以描述任意范围的数据,但又可以占用较少的空间。DWARF2中属性的常见格式如表3所示。

除属性外,节点还有一个默认的属性:是否有子节点。一般,调试信息按其从属关系确定子节点。例如源文件调试信息DW_TAG_compile_unit节点的子节点是该源文件中的函数调试信息DW_TAG_subprogram节点。DW_TAG_subprogram节点的子节点包括函数参数、在该函数中定义的局部变量等等。DW_TAG_compile_unit节点的子节点还包括在该源文件中定义的全局变量节点、类型节点等等。不同类型节点之间的从属关系见表4。

一般,一个被调试文件的调试信息中有很多节点,这些节点的类型大多数是相同的。例如,若一个可执行文件由若干个源文件编译而成,其调试信息中必然有若干个DW_TAG_compile_unit节点,这些节点的属性类型、属性的格式一般是相同的。又比如,一般一个源文件中会有若干个函数,则该源文件调试信息的DW_TAG_compile_unit节点必然有很多子节点是DW_TAG_subpro-gram节点,这些子节点的属性类型、属性格式也相同。如果把这些相同类型节点的属性类型及其格式都显式地表示出来,会造成很多存储空间的浪费。因此,DWARF2规定,所有节点的类型、属性类型、属性格式、是否有子节点等信息都定义在.debug_abbrev节区内。而.debug_info节区内只记录各节点的属性的具体取值。.debug_abbrev节区中定义的节点类型、属性类型等信息称为节点的缩略信息。例如,对上述DW_TAG_compile_unit节点,该节点的类型、属性的类型、属性的格式等信息存储在.debug_abbrev节区内。属于该类型的节点可以有若干个,它们各属性的具体取值存储在.debug_info节区中。图1是一个DW_TAG_compile_unit类型节点及其属性类型、属性格式在.debug_abbrev节区中的定义,而图2则是该类型节点在.debug_info节区中的具体取值。

2 DWARF格式调试信息分析方法

2.1 .debug_abbrev节区分析方法

根据DWARF格式调试信息的特点,读取DWARF调试信息的第一步是读取.debug_abbrev节区内各节点的缩略信息。首先定义读取.debug_abbrev节区需要的数据结构。下面是存储属性类型及属性格式的数据结构。

图中实线矩形内为.debug_abbrev节区的内容示意,虚线圆角矩形内为注释。

在.debug_abbrev节区中,节点类型、属性类型、属性格式类型都以无符号LEB128数的格式存储。它们存储顺序依次为:节点的缩略信息编号、节点的类型、若干组属性类型和属性格式类型定义。若一组属性类型和属性格式类型都为0,标志着一个节点的属性信息结束。每个源文件的节点缩略信息连续存储,节点缩略信息编号从1开始,连续递增。不同的源文件也可以共享节点缩略信息。若一个节点的缩略信息编号为0,标志着一个源文件的节点缩略信息的结束。.debug_abbrev节区中的信息结构如图3示意。

分析.debug_abbrev节区的算法流程图如图4所示。

2.2 .debug_info节区分析方法

一个节点的属性及其值用如下数据结构表示。

其中shared_ptr<char>为boost库智能指针类型,它可以存储一块动态分配的内存块,并且不需要用户主动释放该内存块。

Entry Att数据结构可以存储一个属性的类型、格式及取值。由于该结构体需要存储各种格式的属性值,所以它必须支持存储所有DWARF2可能属性格式。各种属性格式的存储数据结构见表3。但由于一个属性的格式只有一种,所以该结构体中存储属性值的元素只能使用一个。

存储一个节点的调试信息的数据结构如下:

Entry数据结构中,除DWARF格式中定义的一些节点调试信息外,还有一些帮助分析调试信息的元素,如u Cp Idx、u Et Idx、depth、done等等。其中u Cp Idx记录该节点所属源文件调试信息的索引号,u Et Idx是该节点在其所在源文件中的索引号,depth表示该节点在DWARF调试信息树中的深度,done标记该节点是否已经被分析完成,offset标志该节点在.debug_info节区中的偏移。

一个源文件的所有节点调试信息记录在一个数据结构中:

同样,源文件的调试信息数据结构Comp Unit中,除DWARF格式规定的信息外,还有一些为方便解析调试信息而加入的额外信息,如offset、endoffset。Offset表示一个源文件的节点调试信息在.debug_info节区中的开始位置,endoffset表示一个源文件的节点调试信息在.debug_info节区中的结束位置。

.debug_info节区中,源文件的节点调试信息是连续存放的。例如,若一个可执行文件由a.c和b.c编译而成,则a.c的调试信息在.debug_info中存放为连续的二进制块,b.c的调试信息也存储为连续的二进制块,两者不会交叉。

每个源文件的调试信息以一个源文件头开始。该源文件头不是节点,其格式与节点的格式不同。源文件头按顺序包含如下信息:

1) 一个4字节的长度信息len,该长度表示.debug_info节区中为该源文件产生的调试信息的长度,这里的长度不包含存放该长度信息的4字节;

2) 一个2字节的版本信息,该版本信息该源文件调试信息的DWARF格式版本号;

一个字节的偏移,该偏移指该源文件调试信息的节点缩略信息在节区中的位置;

4) 一个1字节的地址大小。例如,对于32位计算机,该值为4,对于64位计算机,该值为8。

源文件调试信息头仅仅给出与该源文件与DWARF存储格式有关的一些信息。对每一个源文件,都会有一个DW_TAG_com-pile_unit类型节点,该节点会给出关于该节点更详细的调试信息。一般,DW_TAG_compile_unit节点是该源文件调试信息的第一个节点,并且是该源文件DWARF调试信息节点树的根节点。

源文件调试信息头之后就是一系列的DWARF调试信息节点值。每个节点以一个LEB128数开始,这个数记录该节点的缩略信息编号。调试信息分析程序可以从.debug_abbrev节区中根据该缩略信息编号找到该节点类型、属性类型、属性格式等信息。该LEB128缩略信息编号之后就是该节点各属性的取值。若该节点缩略信息中记录该节点有子节点,则.debug_info节区中此后的节点为该节点的子节点,这些节点在调试信息树中的深度比本节点深一层。若遇到一个节点的缩略信息编号为0,表示子节点结束,此后的节点在调试信息树的上一层。.debug_info节区的内容格式如图5示意。

图中实线矩形内为.debug_info节区的内容示例,虚线圆角矩形内为注释。

.debug_info节区分析算法流程如图6所示。

3 实验结果

DWDSP系列芯片调试系统的DWARF调试信息分析算法在分析调试信息的过程中,不断通过向日志文件中写入调试信息来记录每一步的数据。通过这种方法可以验证解析过程中每一步的正确性,方便追踪错误调试信息的来源。当所有调试信息都得到解析并处理完成后,输出获得的最终调试信息,与源代码进行验证,可以验证调试信息分析算法的正确性。如下为一个示例性的源文件。

经过调试信息解析算法分析处理后,得到的最终调试信息如图5所示。可见,解析得到的最终调试信息与源代码一致,算法处理过程正确。该文提出的解析算法经过大量源代码测试,已经证实该算法是正确有效的算法。

4 结束语

本文介绍了高级语言的DWARF2格式调试信息。该文还着重介绍了BWDSP系列芯片调试系统使用的DWARF格式调试信息分析算法。该算法首先分析.debug_abbrev节区,读取调试信息节点的缩略信息。然后该算法分析.debug_info节区,读取各节点的值。该文还介绍了该算法使用的主要数据结构。该算法在BWDSP芯片的调试系统中已经得到应用,经过实际使用,该算法的正确性已经得到确保。该算法还通过输出日志的方式验证分析过程每一步的正确性。通过日志文件最后一步输出的调试信息,可以验证该算法的正确性。

摘要：DWARF格式是一种常见的调试信息格式,它以节点作为存储调试信息的基本单元。BWDSP系列芯片的调试系统使用一种自主可控的算法分析C语言的DWARF调试信息。该方法首先读取.debugabbrev节区,获得节点的缩略信息。然后读取.debuginfo节区,获取调试信息节点属性的取值,并把这些调试信息存储为内部数据结构。该算法已经在BWDSP系列芯片的调试系统中得到成功的使用,实践验证了其可行性与正确性。

C语言上机实验报告_书写格式 篇4

课程名称 _____C语言程序设计____ 实验项目 _实验一 顺序结构程序设计___ 实验仪器 ______ ___________

系别_____光电学院_______ 专业______电信__________ 班级/学号 学生姓名 ______***_________实验日期 ____2011年10月17日___ 成绩 _______________________指导教师

一、实验目的1、掌握C语言中，基本的输入输出函数的使用方法。

2、掌握printf中转义字符’t’，’n’的用法。

3、掌握赋值语句的用法。

4、掌握算术表达式、赋值表达式的计算。

5、掌握数学函数的使用。

二、实验内容

1、输入圆的半径 r，计算圆的周长和面积。其中 π =3.1416程序代码：

……

执行结果：

[输入] ……

[输出] ……

2、3、……

三、实验体会

语言格式 篇5

测井资料解释软件 (WATCH生产测井解释平台) 无法直接识别原始测井数据[1], 需人工对测井数据进行格式转换、图头处理等, 特别是同位素测井, 这道工序一般要重复操作8次 (伽马基线1次、静温曲线1次、流温曲线1次、同位素曲线最少4次) 才能完成, 此流程机械、重复、耗时。具体操作流程细述如下:

1.1在EXCEL办公软件中把所有的数据精度更改为4位, 并删除图头后保存为txt文档;图1为原始测井数据样, 经EX⁃CEL办公软件将此文件打开后, 需将所有的数据精度改为4位, 然后删除图头 (数据块上面的英文字母块) , 测几条曲线就要重复、逐个地处理几次。

1.2对处理过的TXT数据, 再进行加图头, 并将图头内的起始深度、结束深度、步长、曲线名进行更改。图2为WATCH生产测井解释平台可识别的数据截图图样, 加的图头样式为固定的, 但是STDEP (起始深度) 为数据块第一行、第一列对应数据;ENDEP (结束深度) 为数据块最后一行、第一列对应数据;RLEV (步长) 为第N行、第一列与第N~1行、第一列的差值, CURVE⁃NAME (曲线名) “=”后的内容为数据块每列所对应的曲线名称, 上述4项要根据实际都需要修改, 且测几条曲线就要重复、逐个地处理几次。

可见, 该软件在解释时繁冗、机械、重复、耗时, 为更加高效完成测井解释工作, 提高办公效率[2], 本论文将计算机编程应用于生产测井解释原始数据格式化处理进行资料解释, 既高效、又准确, 具有广阔的推广前景。

2计算机编程在生产测井原始数据格式处理中应用的优势

2.1操作简便快捷、省时高效

相比人工原始测井数据格式转换操作方式, 利用此“数据格式转换”可执行程序进行数据格式化处理消除了机械、繁琐、耗时的不足, 操作简便快捷。实践发现, 由“数据格式转换”可执行程序来完成原始测井数据格式转换, 最多需要0.2min。如图3所示, 只需将已经编辑好的曲线名 (已有固定模板) 复制后粘贴输入, 点击回车, 瞬间完成数据格式转换。

2.2具有重要推广价值

按2015年工作量来核算, 饱和度测井、多臂测井、校深、井温等714井次, 一井次至少节省3分钟, 共计2142分钟;产液测井、氧活化测井703井次, 一井次至少节省5分钟, 共计时间3515分钟;同位素测井550井次, 一井次至少节省15分钟时间, 共计8250分钟, 所有测井项目合计节省时间13907分钟, 故该方法年节省大约232小时。因此, 将“数据格式转换”可执行程序应用在生产测井原始数据格式处理中可以明显提高处理效率, 具有重要的推广价值。

3结语

针对目前生产测井解释常用的WATCH生产测井解释软件存在效率不高、操作繁琐的缺点, 本文提出利用计算机语言编写“数据格式转换”可执行程序, 由计算机来完成原始测井数据格式转换工作[3]。实践表明, 该方法能够节约大量时间, 为繁重的测井解释工作提供了有力技术支撑, 具有重要推广价值。

摘要：在生产测井解释中, 主要应用WATCH生产测井解释软件, 由于软件设计存在一定的局限性, 如无法直接识别原始测井数据, 需人工对测井数据进行格式转换后, 再利用平台的数据加载功能读入数据, 而人工对测井数据的格式转换工作非常机械、繁琐、耗时。因此, 针对WATCH生产测井解释平台在这方面存在的局限性, 提出利用计算机语言编写“数据格式转换”可执行程序, 由计算机来完成原始测井数据格式转换工作, 该方法节省了解释时间, 大大提高了资料解释工作效率。

关键词：生产测井,WATCH生产测井解释软件,程序

参考文献

[1]于浩洋, 谢传礼, 张航, 等.基于VBA的测井原始数据处理方法[J].断块油气田, 2014, 6 (7) :11~13.

[2]张军, 李洪奇, 谭伏霖, 等.常规测井原始资料质量检查软件系统研制[J].测井技术, 2013, 10 (12) :44~46.