CC BY
19
References
1. Hydroelectric stations / F. F. Gubin. M.: Energy, 1980. P. 368.
2. Krivchenko G. I. Hydraulic machines: Turbines and pumps. The textbook for universities. M.: energy, 1978. P. 320.
3. Operation of hydroelectric power stations / V. S. Serkova. M.: Energy, 1977. P. 302.
4. Мuhammadiyev M. M., Urishev B. and etc. Designing of hydraulic engineering constructions. The textbook for universities. T., TSTU, 1994. P. 105.
Linking as a part of the application building process Klimiankou Y. (Republic of Belarus) Компоновка как часть процесса сборки приложения Клименков Е. И. (Республика Беларусь)
Клименков Евгений Иванович /Klimiankou Yauhen — магистр технических наук, аспирант, кафедра программного обеспечения информационных технологий, факультет компьютерных систем и сетей, Белорусский государственный университет информатики и радиоэлектроники, г. Минск, Республика Беларусь
Abstract: this paper provides a brief introduction into the linking (linkage editor processing) of programs, which is one of the core steps of the transformation process of the program source code into the executable module.
Аннотация: данная статья дает краткое введение в процесс компоновки программ, который является одним из основных этапов процесса трансформации исходного кода программы в исполнимый модуль.
Keywords: linking, building of software. Ключевые слова: компоновка, сборка приложения.
Most of programs are complex solutions containing a huge amount of logic. To facilitate the understanding of the programs to developers, the process of software design and development, as well as its compilation and assembling, the programs are divided into parts called modules. Division into modules also serves for a more utilitarian purposes such as reduction of code duplication and encourage of code reuse, which in their turn lead to such benefits as the cutting of the program's development cost and of the amount of memory and storage space required for them [1].
Fig. 1. Program transformation flow. CMP - compiler, LNK - linker, LDR - loader
1. Role of the linker in the program transformation
Ordinarily, a program comprises of multiple modules, which are coupled together to solve some particular task. Each module implements a part of the required functionality and solves its own subtask. The modules can be designed, programmed and compiled independently. Each module can be implemented using tool that best suits the functions to be performed. Consider the flow of transformation of the source code into an executable program image (Fig. 1).
Initially we have a program source code consisting of multiple source modules. Each of them is usually implemented as a separate file and is written in one programming language. The first transformation step is compilation. During this step, each source module is passed through suitable compiler which translates it into
an object module. The object module contains a logic and a data described in the source module. But in contrast to the source module, object module contains them the form of machine code.
On the second step of the transformation flow, a set of object modules is linked by a linker into a single load module. From the set of source object files the linker selects those modules which are actually in use in the final program. Then it serializes the selected object modules into a single image. Finally the linker performs linking of the modules between each other and generates a metadata. It connects the import points of each module with appropriate export points of the modules from the same set.
Fig. 2. Structure of the object and load modules
Last step is loading. At this step, the loader, which is usually a part of the operating system, parses the load module to collect all the necessary information about the environment required by the application [3]. Using this information and knowing the state of the OS, the loader adjusts an application and an execution environment to each other, including the module relocation and preparation of the memory layout [2]. Finally, the loader copies the code and data of application into the memory and passes control to the application's entry point.
2. Object and load modules
The object and load modules are composed from one or more sections. Section is a non-empty continuous sequence of code or data of a variable size which acts as an atomic entity of the application logic. All elements of the section are strictly ordered and tightly coupled between each other. Example of the section is a function consisting from ordered set of instructions with explicit branch points for each of which control transition offset the specified. Another example is the global instance of the structure, which layout is explicitly defined and assumed in the rest of the program. Summarizing, the section contains indivisible set of data, which for linker and for the loader plays a role of the atomic building block of the application.
Each section of the object module has a symbolic name and may contain external references to other sections, possibly located in other modules. Every time when the compiler needs to put the address of an object located in one section into another section it in fact inserts a placeholder and creates an external reference. The reference contains the offset to the placeholder in the section, the offset in the target object and the symbolic name of the target section. Such target names are called external names.
Each section also has yet another attribute specifying its type. Types give a hint about the purpose of the section for the linker and for the loader. These hints are used by the loader to determine the most suitable access rights to a region of memory in which the section will be placed during load into the process.
After the linker has identified the sections of the object modules which are used by the application, it merges the sections of the same type into a single section of the load module. Knowing the actual order of the object modules sections in the load module section linker resolves references. During this process it replaces all the placeholders by the offset to the corresponding object sections in the load module section. The structure of the object and load modules is depicted on the Figure 2.
A number of optimizations not available at the time of the compilation can be applied during the linking. First of all, the unused sections of the object modules can be omitted in the produced load module, and thus reduce its size. Secondly, a linker is able to combine and colocate the tightly coupled objects to improve the
efficiency of cache utilization and swapping. Finally, it can try to merge semantically different but binarily equivalent constant objects together to gain an additional compaction of the final load module.
References
1. Levine J. R. Linkers and Loaders. San Francisco. CA. USA: Morgan Kaufmann Publishers Inc. 1st ed., 1999.
2. Ramsey N. Relocating machine instructions by currying. SIGPLAN Not. Vol. 31. P. 226-236. May, 1996.
3. Salomon D. Assemblers and Loaders. Upper Saddle River. NJ. USA: Ellis Horwood, 1992.
Problems of adaptation of the international standard "Good Laboratory Practice (GLP)" in Kazakstan Musabaeva B. (Republic of Kazakhstan) Проблемы адаптации международного стандарта «Надлежащая лабораторная
практика (GLP)» в Казахстане Мусабаева Б. Б. (Республика Казахстан)
Мусабаева Багила Бердалиевна / Musabaeva Bagila — магистрант, специальность: стандартизация и сертификация, Университет «Нархоз», г. Алматы, Республика Казахстан
Аннотация: в статье рассматриваются основные принципы и некоторые проблемы адаптации международного стандарта «Надлежащая лабораторная практика (GLP)» в Казахстане. Делается вывод о целесообразности адаптации стандарта GLP к казахстанской практике. Abstract: the article discusses the basic principles and some problems of adaptation of the international standard "good laboratory practice (GLP)" in Kazakhstan. The conclusion about expediency of adaptation of Kazakhstan to GLP standard practice.
Ключевые слова: техническое регулирование, надлежащая лабораторная практика, стандарт GLP, менеджмент качества.
Keywords: technical regulation, Good Laboratory Practice, GLP standard, quality management.
В Послании Президента Республики Казахстан народу Казахстана от 17 января 2014 года «Казахстанский путь - 2050: Единая цель, единые интересы, единое будущее» поставлена задача внедрения в Казахстане ряда принципов и стандартов Организации экономического сотрудничества и развития (далее - ОЭСР), в которую входят 30 самых развитых стран мира, что позволит стандарты качества жизни, действующие на территории стран-участниц ОЭСР, сделать нормой казахстанской жизни [1]. Одним из таких стандартов является стандарт «Надлежащая лабораторная практика (GLP)» (далее - GLP).
Стандарт GLP (согласно руководству ОЭСР) - система норм, правил и указаний, направленных на обеспечение согласованности и достоверности результатов доклинических исследований безопасности испытуемых веществ фармацевтической продукции, пестицидов, косметики, ветеринарных препаратов, а также пищевых и кормовых добавок, промышленных химикатов на стадиях их планирования, выполнения, контроля, оценки и документирования. Соблюдение стандарта GLP обеспечивает:
- научную значимость исследований;
- приемлемость исследований;
- полную документированность, достоверность и признание полученных результатов во всем мире [2]. Правила GLP включают в себя требования к организации испытаний; личному составу
исследователей; помещениям, в которых проводятся испытания; лабораторному оборудованию и его калибровке; испытуемому и контрольному веществу; составлению и проведению подробной стандартной методикам экспериментальных работ.
Для дальнейшего развития GLP системы в Казахстане потребуется преодоление следующих преград: • 1) Создание в стране испытательной GLP-базы.
Во всех странах ОЭСР, внедривших систему GLP, функционируют органы контроля над лабораториями (организациями), выполняющими GLP исследования [3]. Такая же система
