Semantics and pragmatics of programming language ASAMPL
This paper presents semantics and practical implementation of the domain-specific programming language ASAMPL. This programming language has been developed to support the efficient processing of multimodal data processing, in particular, the processing of multimedia content which components are evid...
Gespeichert in:
| Datum: | 2020 |
|---|---|
| Hauptverfasser: | , |
| Format: | Artikel |
| Sprache: | English |
| Veröffentlicht: |
PROBLEMS IN PROGRAMMING
2020
|
| Schlagworte: | |
| Online Zugang: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/392 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-392 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/64/fcd8b16901597abad929221f8a526f64.pdf |
| spelling |
pp_isofts_kiev_ua-article-3922020-12-02T14:52:38Z Semantics and pragmatics of programming language ASAMPL Семантика и прагматика языка программирования ASAMPL Семантика та прагматика мови програмування ASAMPL Sulema, Y.S. Glinskii, V.V. multimedia; multimodal data; programming language; compilation UDC 004.432 мультимедиа; мультимодальные данные; язык программирования; компиляция УДК 004.432 мультимедіа; мультимодальні дані; мова програмування; компіляція УДК 004.432 This paper presents semantics and practical implementation of the domain-specific programming language ASAMPL. This programming language has been developed to support the efficient processing of multimodal data processing, in particular, the processing of multimedia content which components are evidently defined in terms of time. The data processing concept employed in ASAMPL is based on the data structures, operations, and relations defined in the algebraic system of aggregates. The paper explains the compilation approach used for this programming language as well as it presents the test results and their discussion.Problems in programming 2020; 1: 74-83 В данной статье представлены семантика проблемно-ориентированного языка программирования ASAMPL и практическая реализация его компилятора. Этот язык программирования был разработан для обеспечения эффективной обработки мультимодальных данных, в частности, обработки мультимедийного контента, компоненты которого явно определены на временной шкале. Концепция обработки данных, используемая в ASAMPL, основана на структурах данных, операциях и отношениях, определенных в алгебраической системе агрегатов. В статье представлены основные семантические конструкции языка, которые используются для обработки данных. Кроме того, в статье объясняется подход к компиляции программ на языке программирования ASAMPL, а также представлены результаты тестов. Для сравнения результатов, полученных для языка программирования ASAMPL, тестирование проводилось также для аналогичных программ, написанных на языке программирования С, компиляция которых производилась с помощью компилятора GCC. Важным результатом тестирования является подтверждение гипотезы, что язык программирования ASAMPL позволяет разрабатывать более компактный и понятный программный код, исполнение которого требует меньше памяти.Problems in programming 2020; 1: 74-83 У цій статті представлено семантику проблемно-орієнтованої мови програмування ASAMPL та практичну реалізацію компілятора для неї. Ця мова програмування була розроблена для забезпечення ефективного оброблення мультимодальних даних, зокрема, оброблення мультимедійного контенту, компоненти якого явно визначені на часовій шкалі. Концепція оброблення даних, яка використовується в ASAMPL, заснована на структурах даних, операціях та відношеннях, визначених у алгебраїчній системі агрегатів. У статті представлено основні семантичні конструкції мови, які використовуються для оброблення даних. Крім того, в статті пояснюється підхід до компіляції програм на мові програмування ASAMPL, а також представлено результати тестів. Для порівняння результатів, отриманих для мови програмування ASAMPL, тестування проводилося також для аналогічних програм, написаних на мові програмування С, компіляція яких виконувалась за допомогою компілятора GCC. Важливим результатом тестування є підтвердження гіпотези про те, що мова програмування ASAMPL дозволяє розробляти більш компактний та зрозумілий програмний код, виконання якого вимагає менше пам'яті.Problems in programming 2020; 1: 74-83 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2020-02-28 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/392 10.15407/pp2020.01.074 PROBLEMS IN PROGRAMMING; No 1 (2020); 74-83 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2020); 74-83 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2020); 74-83 1727-4907 10.15407/pp2020.01 en https://pp.isofts.kiev.ua/index.php/ojs1/article/view/392/391 Copyright (c) 2020 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2020-12-02T14:52:38Z |
| collection |
OJS |
| language |
English |
| topic |
multimedia multimodal data programming language compilation UDC 004.432 |
| spellingShingle |
multimedia multimodal data programming language compilation UDC 004.432 Sulema, Y.S. Glinskii, V.V. Semantics and pragmatics of programming language ASAMPL |
| topic_facet |
multimedia multimodal data programming language compilation UDC 004.432 мультимедиа мультимодальные данные язык программирования компиляция УДК 004.432 мультимедіа мультимодальні дані мова програмування компіляція УДК 004.432 |
| format |
Article |
| author |
Sulema, Y.S. Glinskii, V.V. |
| author_facet |
Sulema, Y.S. Glinskii, V.V. |
| author_sort |
Sulema, Y.S. |
| title |
Semantics and pragmatics of programming language ASAMPL |
| title_short |
Semantics and pragmatics of programming language ASAMPL |
| title_full |
Semantics and pragmatics of programming language ASAMPL |
| title_fullStr |
Semantics and pragmatics of programming language ASAMPL |
| title_full_unstemmed |
Semantics and pragmatics of programming language ASAMPL |
| title_sort |
semantics and pragmatics of programming language asampl |
| title_alt |
Семантика и прагматика языка программирования ASAMPL Семантика та прагматика мови програмування ASAMPL |
| description |
This paper presents semantics and practical implementation of the domain-specific programming language ASAMPL. This programming language has been developed to support the efficient processing of multimodal data processing, in particular, the processing of multimedia content which components are evidently defined in terms of time. The data processing concept employed in ASAMPL is based on the data structures, operations, and relations defined in the algebraic system of aggregates. The paper explains the compilation approach used for this programming language as well as it presents the test results and their discussion.Problems in programming 2020; 1: 74-83 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2020 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/392 |
| work_keys_str_mv |
AT sulemays semanticsandpragmaticsofprogramminglanguageasampl AT glinskiivv semanticsandpragmaticsofprogramminglanguageasampl AT sulemays semantikaipragmatikaâzykaprogrammirovaniâasampl AT glinskiivv semantikaipragmatikaâzykaprogrammirovaniâasampl AT sulemays semantikatapragmatikamoviprogramuvannâasampl AT glinskiivv semantikatapragmatikamoviprogramuvannâasampl |
| first_indexed |
2025-07-17T09:34:51Z |
| last_indexed |
2025-07-17T09:34:51Z |
| _version_ |
1850412791505092608 |
| fulltext |
Мови програмування
© Y. Sulema, V. Glinskii, 2020
74 ISSN 1727-4907. Проблеми програмування. 2020. № 1
UDC 004.432 https://doi.org/10.15407/pp2020.01.074
Yevgeniya Sulema, Vladyslav Glinskii
SEMANTICS AND PRAGMATICS OF PROGRAMMING
LANGUAGE ASAMPL
This paper presents semantics and practical implementation of the domain-specific programming language
ASAMPL. This programming language has been developed to support the efficient processing of multimodal
data processing, in particular, the processing of multimedia content which components are evidently defined in
terms of time. The data processing concept employed in ASAMPL is based on the data structures, operations,
and relations defined in the algebraic system of aggregates. The paper explains the compilation approach used
for this programming language as well as it presents the test results and their discussion.
Key words: multimedia, multimodal data, programming language, compilation.
Introduction
Nowadays, such technologies as IoT,
machine learning, big data, augmented and
virtual reality are developing very fast and
they are more and more in use for solving
everyday tasks. For example, virtual assistants
like Amazon Alexa or Apple Siri help users
by employing natural language processing,
voice recognition and computer vision along
with other artificial intelligence techniques.
Multimedia technologies along with
AR and VR allow us to make education more
efficient [1–3]. Some examples are interactive
classes and training programs for medical
students, technicians, drivers, etc. These tech-
nologies enable modelling processes and vis-
ualize them, recreating required environment,
improve skills while minimizing loss due to
learner’s mistake. They can be used to make
monitoring and operating machines or even
industrial complexes much simpler. As an ex-
ample, it can greatly improve operation of the
drone used in emergency situation by giving
to operator visualization of the environment,
identified objects or threats.
IoT solutions are used not only in in-
dustrial and agricultural complexes but also to
create “smart homes” and “smart cities”. Data
gathered from different sensors can be used to
make immediate decisions to control opera-
tion of connected equipment. At the same
time this data is stored for analysis and pre-
diction of the future trends in self-learning
systems, visualization to human operators.
Rising amounts of diverse data push
requirements to its storage, transmission and
processing technologies further. So, nowa-
days we have real need to work with so-called
multimodal data, i.e. data which has different
origin, such as images, audio, environmental
characteristics (humidity, temperature), etc.
Usually such data is constantly changing in
time. In some cases, the use of general-
purpose programming languages for multi-
modal data processing tasks is not efficient
enough when timewise processing is required.
The understanding of this fact has leaded to
the creation of a domain-specific program-
ming language ASAMPL [4]. The purpose of
the research presented in this paper is to make
the semantics of ASAMPL more mature as
well as to carry out the reference implementa-
tion of this language by developing a compil-
er and a standard library.
1. Concept and features of ASAMPL
The ASAMPL programming language
derives its name from the "Algebraic System
of Aggregates" and the "Mulsemedia data
Processing Language" [4]. ASAMPL has
been designed for simple and efficient multi-
modal data processing which is based on the
following facts: (1) every element of such da-
ta is related to a certain point in time when it
has been obtained (recorded, generated,
measured, etc.); (2) multimodal data pro-
cessing needs to take into account the modali-
ty of the data, its compatibility and the possi-
ble interrelation between data of different
modalities. Therefore, the basic principle of
organizing a program in this language is that
the program code execution is governed by
two entities: time and data modality.
Мови програмування
75
A key concept in ASAMPL is the
concept of multi-image which is based on the
mathematical apparatus of the Algebraic Sys-
tem of Aggregates (ASA) [5-7]. To represent
the multi-image of a real-world object, two
basic data structures defined in ASA, namely,
tuples and aggregates, are employed in this
programming language. The processing of tu-
ples and aggregates is performed in accord-
ance with the rules prescribed in ACA.
The main features of the ASAMPL
language which specify the principles of the
programming paradigm for multimodal data
structures processing as the following:
1. Linking the data processing pro-
cess to a timeline.
2. Synchronizing the data of differ-
ent modalities.
3. Complex representation of multi-
modal data using tuples and aggregates.
4. Focusing on the simultaneous use
of various multimodal data sources (data
streams from remote sensors, media files from
cloud storages, etc.).
5. Dynamic linking external librar-
ies, renders (a renderer is a software tool for
reproducing the data of a certain modality),
handlers for encoding / decoding, data pro-
cessing and reproduction for each modality,
use of specific file formats and predefined de-
vices.
6. Mathematical processing of data
aggregates based on ACA.
A program code is ASAMPL consists
of blocks starting with the following key-
words:
ACTIONS, it defines data pro-
cessing logic;
AGGREGATES, it defines aggre-
gates composed from defined tuples;
ELEMENTS, it defines variables
and their belonging to defined sets;
HANDLERS, it defines built-in
and external modules for data converting;
LIBRARIES, it defines built-in
and external libraries;
PROGRAM, it starts a program
code;
RENDERERS, it defines built-in
and external modules for data rendering;
SETS, it defines sets which con-
tain data elements;
SOURCES, it defines data
sources where multimodal data is stored, rec-
orded, generated, etc.
TUPLES, it defines tuples and
their belonging to defined sets.
The program structure is as follows:
Program <name> {
Libraries {
<library1> is <path-
ToLibray1>;
<library2> is <pathToLi-
brary2>;
…………………………………… }
Handlers {
<handler1> is
<pathToHandler1>;
<handler2> is
<pathToHandler2>;
…………………………………… }
Renderers {
<renderer1> is <pathToRender-
er1>;
<renderer2> is <pathToRender-
er2>;
…………………………………… }
Sources {
<source1> is <pathToSource1>;
<source2> is <pathToSource2>;
…………………………………… }
Sets {
<set1> is <type1>;
<set2> is <type2>;
…………………………………… }
Elements {
<element1> is <set>;
<element2> = <value>;
…………………………………… }
Tuples {
<tuple1> = <set1>;
<tuple2> = <set2>;
…………………………………… }
Aggregates {
<aggregate1> = [<tuple1>, …,
<tupleM>];
<aggregate2> = [<tupleK>, …,
<tupleN>];
…………………………………… }
Actions {
<list of statements> } }
The logic of multimodal data struc-
tures timewise processing is set by the opera-
tors which are based on the mathematical
concept defined in ASA, in particular, logical
Мови програмування
76
and ordering operations on aggregates and
frequency and interval relations of discrete in-
tervals as well as the concept of a multi-image
[3–5].
To implement the multimodal data
timewise processing logic, the ASAMPL
specification includes the following operators:
TIMELINE; SEQUENCE; SUBSTITUTE
FOR WHEN; DOWNLOAD FROM WITH;
UPLOAD TO WITH; RENDER WITH.
To define the semantics of the
ASAMPL operators, the axiomatic approach
is used in this research [8, 9]. An axiomatic
specification is defined as the following deri-
vation rule:
1 2, , , nH H H
H
,
where H is true if ∀ Hi is true, i = [1..n].
TIMELINE operator enables timewise
data processing by allowing a programmer to
apply a certain action during a defined period
of time. All actions included into the operator
body are to be executed simultaneously. This
operator has three options for the timeline de-
fining.
The first option requires an evident in-
dication of both the beginning and the end
time moments of the timeline:
TIMELINE time1 : step : time2
{ list of actions to be carried
out simultaneously }
The semantics rule for the first option
of TIMELINE operator is:
{ &( ( ))} { }
{ }TIMELINE : : ( ) { }
P a x a a n C Q
P a a a a n C Q
.
The second option allows a program-
mer to specify an arbitrary tuple of time val-
ues which correspond to specific time mo-
ments when the actions from the given list
need to be carried out:
TIMELINE AS time_tuple { list of
actions to be carried out simul-
taneously }
The semantics rule for the second op-
tion of TIMELINE operator is:
1
1
{ &( [ .. ])} { }
{ }TIMELINE AS[ .. ] { }
n
n
P x a a C Q
P a a C Q
.
The third option of the TIMELINE
operator enables using a condition which trig-
gers the completion of the given actions ful-
filment:
TIMELINE UNTIL condition
{ list of actions to be carried
out simultaneously }
The semantics rule for the third option
of TIMELINE operator is:
{ & } { }
{ }TIMELINE UNTIL { }
P B C Q
P B C Q
.
SEQUENCE operator enables sequen-
tial processing of actions as one compound
action:
SEQUENCE { list of actions to be
carried out sequentially }
The semantics rule for this operator is
as follows:
1 2
1 2
{ } { }, { } { }
{ }SEQUENCE ; { }
P C Q Q C R
P C C R
.
SUBSTITUTE FOR WHEN operator
enables replacement of one data set by anoth-
er one if a certain condition becomes true:
SUBSTITUTE name1 FOR name2
WHEN logical_expression.
This operator can be useful in the case
when, for example, high-resolution data can-
not be downloaded, uploaded, or processed
because of insufficient data rates and, thus,
they can be replaced with low-resolution data
to allow an application to be executed even in
such inappropriate conditions.
The semantics rule for this operator is
as the following:
1 2
2 1
{ & } { }, { & } { }, ( : )
{ } SUBSTITUTE FOR WHEN { }
i iP B C Q P B C Q C d d
P d d d B Q
where i = [1, 2].
Мови програмування
77
DOWNLOAD FROM WITH operator
enables downloading data from a specified
data source by using either a predefined han-
dler, or a given one. In the first case, the oper-
ator has the following format:
DOWNLOAD data_name FROM source
Its semantic rule is as follows:
1
{ } { }
{ } DOWNLOAD { }
P C Q
P d FROM d Q
.
In the second case, the handler identi-
fier needs to be indicated directly:
DOWNLOAD data_name FROM source
WITH handler
Its semantic rule for this case is:
1
{ } { }
{ } DOWNLOAD WITH { }
P C Q
P d FROM d z Q
.
UPLOAD TO WITH operator allows
to upload any data (an element, a tuple, an
aggregate) to a defined resource by using ei-
ther a predefined handler, or a given one. In
the first option, there is no need to indicate
the handler because it is predefined:
UPLOAD data_name TO destination
The semantic rule for the first option
is the following:
1
{ } { }
{ } UPLOAD { }
P C Q
P d TO d Q
.
In the second option, the handler
needs to be indicated evidently:
UPLOAD data_name TO destination
WITH handler
The semantic rule for the second op-
tion is the following:
1
{ } { }
{ } UPLOAD WITH { }
P C Q
P d TO d z Q
.
RENDER WITH operator enables data
reproduction. Each data modality is pre-
processed and rendered by its specific render.
The form of this operator is as follows:
RENDER data_name WITH render_name
The semantic rule for this operator is
the following:
{ } { }
{ } RENDER WITH { }
P C Q
P d z Q
.
Besides, ASAMPL employs a branch
statement IF THEN; a selection statement
CASE OF; an assignment statement IS.
Thus, the logic of the data processing
is based on these basic actions. The method of
ASAMPL code translation is presented in the
next section.
2. Compilation approach
The compiler implementation lan-
guage needs to be strongly typed high-level
general-purpose programming language with
simple and expressive syntax. Automatic
memory management is desired but not man-
datory. Besides, this language should be pop-
ular and mature enough because popular lan-
guages tend to have bigger community, com-
prehensive documentation, many ready-to-use
program components, frameworks and librar-
ies. The analysis of top programming lan-
guages [10, 11] has been resulted in selecting
Python.
The parser and lexer compiler compo-
nents can be generated from the formal lan-
guage specification, thus, a generator with Py-
thon target language support was needed to be
selected. Another important criteria included
versatility, separation of output code from
grammar and comprehensive documentation.
For this research, ANTLR [12] has been se-
lected. A viable alternative to it is PLY [13].
Multimedia is the third base com-
ponent of the implementation, cross-platform
and open-source projects with Python bin-
dings were preferred. We have selected
GStreamer [14] because its core does not de-
pend on the type of processed data and it can
be extended by plugins, which enable adding
new formats, protocols or hardware support.
Мови програмування
78
The architecture of the implemented
two-pass compiler includes frontend and
backend (Fig. 1).
Fig. 1. Compiler architecture
2.1. Frontend. The frontend performs
syntax and semantics verification (e.g., identi-
fier availability, type checking). The lexer and
parser are generated by ANTLR from the lan-
guage context-free grammar description,
it also generates the helper base classes
for parse tree traversal: a listener and/or a vis-
itor. Our semantic analyser implements the
visitor design pattern to control the order
of traversal.
All declarations for declarative sec-
tions are checked if a name they define has
not been declared yet, and additional checks
need to be performed for every section.
The parse tree traversal starts at the
LIBRARIES section and the library importer
component tries to import declared libraries
as a regular Python package. The libraries
which define custom types need to have ex-
port_types dict in their packages which maps
type names to corresponding classes. If a li-
brary name has not been declared yet and its
package was successfully imported, the li-
brary is registered in a corresponding lookup
table and becomes available in anther pro-
gram parts.
For declarations in the HANDLERS
and RENDERERS sections, the visitor checks
if the specified name has not declared yet, the
library is imported, and it tries to import a
specified element as a class in that library. If
the class was imported successfully and inher-
its a required base class, it will be registered
in the lookup table.
In SETS section, type import declara-
tions are checked if a name has not been de-
clared yet, the specified library was imported
and has specified type, in that case the im-
ported type is registered in the lookup table.
Type alias are registered only for already pre-
sent types if the name defined by an alias has
not been used before.
The declarations in the ELEMENTS,
TUPLES and AGGREGATES sections assign
names to certain values in the lookup table
when a specified type name or a referenced
value name is defined.
The ACTIONS section declarations
define program logic and data flows, they are
converted to a hierarchy of action objects
which represent specific discrete tasks.
The interface defined by the base ac-
tion class includes methods Start, Stop and
Stop_Prepare, Finished signal and Depth
property (a depth within the hierarchy tree).
The Start method returns False when the ac-
tion finished immediately, otherwise it returns
True. The Stop_Prepare method is used to
notify an action before it is actually stopped
with the Stop method call. The Finished sig-
nal is emitted only when the action finished
neither during Start nor during Stop method
calls.
Another important abstract base class
is CompositeAction: a group of actions which
can be treated as a single action and may de-
fine custom execution order. There are two
concrete implementations: ChinedAction
which executes child actions sequentially and
ParallelAction, which executes child actions
concurrently. When they are stopped, they
stop child actions. The ChainedAction finish-
es execution only when all children have fin-
ished. The ParallelAction behaves in the same
way when execution duration is not specified
or when early finish is allowed, otherwise it
continues execution even when all children
have finished already and stops unfinished
when the data processing time elapses.
To create a delay in the beginning of
actions (e.g., in TIMELINE statements with
non-zero start time), the DelayAction is used.
Мови програмування
79
The behaviour which defines an up-
date frequency and an elapsed time tracking is
extracted into ActionUpdateStrategy sub-
classes and can be used in certain classes with
help of the Dependency Injection design pat-
tern. The base interface provides update
method which receives a time difference for a
current update step (for base class it updates
an object age) and properties to get a current
update interval duration, a next update delay,
an overall duration, an age and an update loop
finish status. All time values are stored with
microsecond precision. There are two con-
crete implementations: FixedStepUpdate
which has equal update intervals and
FramesTupleUpdate which accepts a list of
update intervals. The DelayAction objects in-
stantiate and encapsulate FixedStepUpdate
objects with an overall duration and an update
interval duration equal to the specified delay.
The ParallelAction can be initialized with any
concrete implementation of ActionUpdateS-
trategy to define the action duration and the
update frequency.
The DownloadAction, UploadAction,
and RenderAction implement corresponding
program statements DOWNLOAD FROM
WITH, UPLOAD TO WITH, and RENDER
WITH. They check compatibility of handlers
and renderers with user-specified data stream
objects, establish connections at the action
start and disconnect them when stopped of
finished execution. Additionally, Down-
loadAction and UploadAction create
GStreamer pipeline element that handles input
(or output) to a supplied source (or target)
URL.
The action hierarchy is built by Time-
lineBuilder object and helper classes. Every
TIMELINE statement block and root code
block are treated as a separate time interval
and are represented by separate _Timeline ob-
ject within TimelineBuilder. These objects
encapsulate checks for detecting duplicated
data streams in lists, cases when the same data
stream has different target or source declared
for the same execution time, ensure compati-
bility between specified data streams, handler
(or renderer) and action.
TimelineBuilder holds at least one
_Timeline instance: for the root code block.
Entering to a new TIMELINE statement
block will create a new _Timeline instance
with a parent object which becomes current
while the previous one becomes its parent.
Each _Timeline object has an initial mode set
to “in parallel”, but when the code block
marked with SEQUENCE keyword is en-
tered, it is switched to “in sequence”. On exit
from the top-level SEQUENCE block, all cre-
ated actions within that block are put into
wrapper ChainedAction (this step is skipped
for single action) and are added to the actions
list of this _Timeline. When TIMELINE
statement block is exited, the current
_Timeline instance is set to its parent. Empty
TIMELINE blocks are ignored, but when time
range is set and parent _Timeline has mode
“in sequence”, DelayAction is added instead
to the parent. When time range is not speci-
fied for the current TIMELINE statement
block and the parent has “in parallel” mode,
all actions of the current _Timeline are pushed
to the parent as they are. In all other cases
they are put to ParallelAction which has an
appropriate ActionUpdateStrategy set if need-
ed. When non-zero start time is specified, De-
layAction is created with the corresponding
delay set. If parent has “in sequence” mode or
start time is zero ParallelAction with De-
layAction are pushed as is to the parent. Oth-
erwise, they are wrapped with ChainedAction
before they are added to the parent.
2.2. Backend. The backend provides
runtime environment and runtime error han-
dling, schedules execution of the action hier-
archy received from the frontend stage. The
action hierarchy is represented here by a sin-
gle root ParallelAction object. The core com-
ponent of the backend is the scheduler object
UpdateSource which attach itself to GLib
main context as an event source to receive
updates.
Actions which need updates (e.g.,
ParallelAction and DelayAction) hold refer-
ence to the scheduler object and subscribe for
updates when needed. The scheduler holds the
priority queue of subscribed actions where
priority determined by both the next update
time in microseconds and the action depth
within the hierarchy tree. This ensures that the
parent action receives update before its chil-
dren when they have the same update time.
But for sibling actions update order (and, as a
Мови програмування
80
result, the start order) is not guaranteed.
The scheduler update loop has three
distinct stages (Fig. 2): prepare, wait, and
dispatch.
The prepare stage determines the
closest update time for subscribed actions and
calculates a delay for the wait stage. On the
first run, this stage starts a root action and the
scheduler subscribes to the root action fin-
ished signal if it did not finish immediately,
otherwise the wait stage is skipped.
Fig. 2. Scheduler update loop
The dispatch stage pulls actions which
reached their update time from a priority
queue. The actions update method receives a
defference between planned and actual update
time and returns a Boolean value. An action
which still needs updates is added back to the
scheduler priority queue. At the end of this
stage, on_update_unsubscribed handler is
called for all unsubscribed actions in the order
they received updates. If the root action is fin-
ished during or before the dispatch stage, the
scheduler removes itself from GLib main con-
text and the program finishes its execution.
2.3. Standard library. The standard
library provides base classes and reference
implementations of handlers, renderers and
data streams. Handlers and renderers imple-
ment BaseHandler class, its interface define
methods for attaching and detaching to data
streams, compatibility checking, starting and
stopping operation, signal done to notify sub-
scribed objects. Renderers are always used as
destination for data streams, while handlers
can implement either source or destination.
Depending on the implementation, they can
be attached to single or multiple data streams
at the same time (e.g., handlers for multi-
plexed data formats). The reference handler
implementations are classes OGGIn and
OGGOut which work with files in OGG con-
tainer format and support the following data
stream types: audio, video, and subtitles. Both
handlers try to automatically find the required
coder or decoder among GStreamer plugins
when attached to uncompressed data streams.
Standard renderers are represented by
AudioOutput and VideoOutput classes which
implement playback of uncompressed audio
and video. Data streams can have at most one
source and multiple receivers (handlers and
renderers). The base data stream class Base-
Stream provides an interface with the meth-
ods for attaching and detaching source and re-
ceiver objects, retrieving information about
supported data types for its inputs and out-
puts, signals to notify when no outputs are
present anymore or first output attached. The
standard library provides implementation of
uncompressed audio and video streams:
RawAudio and RawVideo.
All these components have own
GStreamer elements connected into pipelines.
During runtime actions they are connected to-
gether to ensure data flow described by the
program.
3. Results and discussion
In order to evaluate the efficiency of
the implemented solution we compared it
with traditional development tools, namely, C
compiler from GNU Compiler Collection
suite [15] and GStreamer framework. For this
purpose, we created two sets of equivalent
small- and medium-sized programs written in
both C and ASAMPL. To evaluate perfor-
mance of the implemented compiler, we
Мови програмування
81
measured overall running time and peak
memory consumption during program code
parsing, analysis, and preparation program
code to execution.
Table 1
Average program code size
Program
code
Small size
(lines of code)
Medium size
(lines of code)
C 193 318
ASAMPL 43 95
For running time measurement, we
used Perf tool [16], running each compiler for
every program 1000 times. Averaged results
for both program sets (see Table 2 and
Fig. 3b) show that execution time of GCC C
compiler is around 30 % lower.
Table 2
Average execution time
Program
code
Small size
(secs and
stddev)
Medium size
(secs and
stddev)
GCC
0.220516528
(0.34%)
0.23745095
(0.34 %)
ASAMPL
compiler
0.315360984
(0.53 %)
0.330313517
(0.29 %)
Difference 30 % 28 %
The results of peak memory consump-
tion measurement with Valdgrind tool [17]
(see Table 3 and Fig. 3c) show that on aver-
age it is 33% lower for ASAMPL compiler.
ASAMPL programs are visually sim-
pler, concise, and expressive since they omit
resource management, pipeline manipulation,
synchronization and other tasks required to
set up an environment, but not related to actu-
al data processing task. As a result, the pro-
gram size in lines-of-code (excluding com-
ments and whitespace) for ASAMPL is at
least 3 times smaller (see Table 1 and
Fig. 3a).
Table 3
Peak memory consumption
Program
code
Small size
(Mbytes)
Medium size
(Mbytes)
GCC 14.7 14.7
ASAMPL
compiler
9.62 9.8
Difference 35 % 33 %
.
Fig. 3. Benchmarking results comparison charts
Мови програмування
82
Conclusion
The programming language ASAMPL
is a domain-specific language driven by data
modality and time. It is developed for easy
and effective processing of multimodal data
defined with respect to time. To present such
data, the programming language specification
includes data structures called tuples and ag-
gregates. ASAMPL offers a set of special-
purpose operators, semantics of which is pre-
sented in the paper. To execute program code
in ASAMPL, a complier has been developed.
The paper presents both the architecture of
this compiler and the compilation approach.
The testing results show that ASAMPL code
is simpler, concise, and expressive as well as
memory consumption is lower for the devel-
oped ASAMPL compiler. Thus, ASAMPL
can be considered as an appropriate option
when the memory usage and the code simplic-
ity are important issues.
References
1. Virtual Reality for Education. Available from:
http://virtualrealityforeducation.com/ [Ac-
cessed 05/02/2020].
2. Antonov S., Antonova R., Spassov K. Multi-
media Applications in Education. Smart
Technologies and Innovation for a Sustaina-
ble Future. Springer. 2019. P. 263–271.
3. Weng C., Rathinasabapathi A., Weng A.,
Zagita C. Mixed Reality in Science Education
as a Learning Support: A Revitalized Science
Book. Journal of Educational Computing Re-
search. 2018. 57(3). P. 777–807.
4. Sulema Y. ASAMPL: Programming Lan-
guage for Mulsemedia Data Processing Based
on Algebraic System of Aggregates. Interac-
tive Mobile Communication Technologies and
Learning. Springer. 2018. P. 431–442.
5. Dychka I., Sulema Ye. Logical Operations in
Algebraic System of Aggregates for Multi-
modal Data Representation and Processing.
KPI Science News. 2018. Vol. 6. P. 44–52.
6. Dychka I., Sulema Ye. Ordering Operations in
Algebraic System of Aggregates for Multi-
Image Data Processing. KPI Science News.
2019. Vol. 1. P. 15–23.
7. Sulema Ye., Kerre E. Multimodal Data Rep-
resentation and Processing Based on Algebra-
ic System of Aggregates, preprint. 2020. 37 p.
8. Milner R. Operational and Algebraic Seman-
tics of Concurrent Processes. Formal Models
and Semantics. 1990. P. 1203–1242.
9. Roşu G., Ştefănescu A. Towards a Unified
Theory of Operational and Axiomatic Seman-
tics. Automata, Languages, and Program-
ming. Springer. 2012. P. 351–363.
10. TIOBE The Software Quality Company.
Available from: https://www.tiobe.com/tiobe-
index/ [Accessed 05/02/2020].
11. The Top Programming Languages 2019.
IEEE Spectrum. Available from:
https://spectrum.ieee.org/computing/software/
the-top-programming-languages-2019 [Ac-
cessed 05/02/2020].
12. ANTLR. Available from:
https://www.antlr.org/ [Accessed 05/02/2020].
13. PLY (Python Lex-Yacc). Available from:
https://www.dabeaz.com/ply/[Accessed
05/02/2020].
14. GStreamer. Available from:
https://gstreamer.freedesktop.org/ [Accessed
05/02/2020].
15. GCC, the GNU Compiler Collection. Availa-
ble from: https://gcc.gnu.org/ [Accessed
05/02/2020].
16. Perf Wiki. Available from:
https://perf.wiki.kernel.org/index.php/Tutorial
[Accessed 05/02/2020].
17. Valgrind's Tool Suite. Available from:
https://valgrind.org/info/tools.html [Accessed
05/02/2020].
Література
1. Virtual Reality for Education. Available from:
http://virtualrealityforeducation.com/ [Ac-
cessed 05/02/2020].
2. Antonov S., Antonova R., Spassov K. Multi-
media Applications in Education. Smart
Technologies and Innovation for a Sustainable
Future. Springer. 2019. P. 263–271.
3. Weng C., Rathinasabapathi A., Weng A.,
Zagita C. Mixed Reality in Science Education
as a Learning Support: A Revitalized Science
Book. Journal of Educational Computing Re-
search. 2018. 57(3). P. 777–807.
4. Sulema Y. ASAMPL: Programming Lan-
guage for Mulsemedia Data Processing Based
on Algebraic System of Aggregates. Interac-
tive Mobile Communication Technologies
and Learning. Springer. 2018. P. 431–442.
5. Dychka I., Sulema Ye. Logical Operations in
Algebraic System of Aggregates for Multi-
Мови програмування
83
modal Data Representation and Processing.
KPI Science News. 2018. Vol. 6. P. 44–52.
6. Dychka I., Sulema Ye. Ordering Operations in
Algebraic System of Aggregates for Multi-
Image Data Processing. KPI Science News.
2019. Vol. 1. P. 15–23.
7. Sulema Ye., Kerre E. Multimodal Data Rep-
resentation and Processing Based on Algebra-
ic System of Aggregates, preprint. 2020. 37 p.
8. Milner R. Operational and Algebraic Seman-
tics of Concurrent Processes. Formal Models
and Semantics. 1990. P. 1203–1242.
9. Roşu G., Ştefănescu A. Towards a Unified
Theory of Operational and Axiomatic Seman-
tics. Automata, Languages, and Programming.
Springer. 2012. P. 351–363.
10. TIOBE The Software Quality Company.
Available from: https://www.tiobe.com/tiobe-
index/ [Accessed 05/02/2020].
11. The Top Programming Languages 2019.
IEEE Spectrum. Available from:
https://spectrum.ieee.org/computing/software/
the-top-programming-languages-2019 [Ac-
cessed 05/02/2020].
12. ANTLR. Available from:
https://www.antlr.org/ [Accessed 05/02/2020].
13. PLY (Python Lex-Yacc). Available from:
https://www.dabeaz.com/ply/[Accessed
05/02/2020].
14. GStreamer. Available from:
https://gstreamer.freedesktop.org/ [Accessed
05/02/2020].
15. GCC, the GNU Compiler Collection. Availa-
ble from: https://gcc.gnu.org/ [Accessed
05/02/2020].
16. Perf Wiki. Available from:
https://perf.wiki.kernel.org/index.php/Tutorial
[Accessed 05/02/2020].
17. Valgrind's Tool Suite. Available from:
https://valgrind.org/info/tools.html [Accessed
05/02/2020].
Received 06.02.2020
About the authors:
Yevgeniya Sulema,
candidate of tech. sciences (PhD),
associate professor at Computer Systems
Software Department.
The number of publications in Ukrainian
and foreign journals is over 130.
Hirsh index is 4.
https://orcid.org/0000-0001-7871-9806,
Vladyslav Glinskii,
Master student at Computer Systems Soft-
ware Department.
https://orcid.org/0000-0003-1360-7218.
Affiliation:
Igor Sikorsky Kyiv Polytechnic Institute,
03056, Kyiv,
pr. Peremogy, 37, build. 15.
Tel.: +38 044 204 99 44.
Email: sulema@pzks.fpm.kpi.ua
|