The Realtime-Programming Language PEARL
The name PEARL stands for Process and Experiment Automation Realtime Language and must not be mistaken for Perl, the Practical Extraction and Report Language.
PEARL is a higher programming language, which allows a comfortable, secure and almost processor independent programming of multitasking- and realtime problems and has been standardized since 1977 at various stages of its development, the last time 1998 as PEARL-90 (DIN 66253-2 1998, Berlin, Beuth-Verlag, 1998).
Besides the simple possibility to map process technical problems, an important principle at the development of PEARL was the easy learning by the programmer. Everyone who already knows a procedural programming language will get acquainted with PEARL in a very short time.
All basic data types and language structures of other procedural programming languages exist in PEARL (<). In addition PEARL offers comfortable language elements for the handling of multitasking- and realtime tasks (<).
- Basic data types
- fixed point, floating point
- characters, character strings
- bit variables, bit strings
- Assembled data types
- arrays of various dimensions with user defined lower- and upper limits for the individual dimensions.
- Functions, procedures (parameter transfer via value, via IDENT and as pointer)
- Type pointers to all objects, also to functions and procedures
- Type-free pointers and type-casting
Block structure, validity of objects:
- Object declarations within a
- Procedure- and function-wide objects
- Module-wide objects
- Access to objects of other modules via global specification of variables
- Announcement of objects for other modules via global declaration
- Conditional commands
Detailed information about the construction of PEARL is contained in
- DIN 66253-2 1998, Berlin, Beuth-Verlag, 1998
- PEARL 90 - Language Report, Version 2.2., GI-Fachgruppe 4.4.2, Bonn, GI Gesellschaft für Informatik e.V., 1998
To reach a separation from hardware dependent components, like for example in- and output interfaces, to the hardware independent program, a PEARL-module is subdivided into two parts:
- In the so called system part, beginning after the keyword SYSTEM, the names for the hardware dependent I/O-interfaces are declared and their features defined. Here also interrupt sources can be defined.
- The so called problem part, beginning with
PROBLEM, contains for example variables, constants, tasks and procedures. Tasks and procedures have access to the interfaces defined in the SYSTEM-part.
The state of tasks known to the operating system can be modified in a PEARL-program.
immediately makes runable the task with the name Taskname.
the task with the name Taskname is terminated.
the task with the name Taskname is suspended.
the suspended task with the name Taskname will be continued.
the task with the name Taskname, of which the activation was coupled with an event, will be prevented. It will not be activated or continued anymore by this event.
The activation and continuation of tasks can be executed to external events or time instants under certain conditions. Schedules to an exact clock-time, also schedules in case of external events (interrupts), are possible.
ALL 0.00005 SEC ACTIVATE Highspeedcontroller;
cyclical activation of a controller with a frequency of 20 kHz
AT 12:00 ALL 4 SEC UNTIL 12:30 ACTIVATE lunchhour PRIO 1;
cyclical scheduling, every 4 seconds between 12:00 and 12:30 hrs with high priority
WHEN fire ACTIVATE extinguish;
activation of the task extinguish, when interrupt fire occurs.
A synchronisation of tasks always becomes necessary when they jointly use data. The following three examples show how tasks can be synchronized with
the use of semaphore-' and boltvariables. If a task A intends the access to a data record, which is just being handled by a TASK B, the
operating system blocks task A until B releases the data. In connection with semaphores PEARL allows instead of a blockade also the
"testing with entry when free" (keyword
TRY in the example).
PROBLEM; DCL A CHAR(255); ! character string: 255 Bytes DCL SEMVAR SEMA PRESET(1); ! reservation: access allowed DCL FAILED FIXED INIT(0); T1: TASK; DCL B1 CHAR(255); REQUEST SEMVAR; A=B1; RELEASE SEMVAR; END; T2: TASK; DCL B2 CHAR(255); REQUEST SEMVAR; A=B2; RELEASE SEMVAR; END; TEST: TASK; IF TRY SEMVAR THEN RELEASE SEMVAR; !release semaphore again ELSE FAILED=FAILED+1; FIN; ! self activation after 10 seconds AFTER 10 SEC ACTIVATE TEST; END;
If a task A produces data, which are provided for subsequent treatment by one or several other tasks, one talks about a producer-consumer-scheme. Following is the example of a ring storage with 1024 characters, of which the reading task always needs 2 at the same time.
PROBLEM; DCL IS_PLACE SEMA PRESET(1024); ! Init: 1024 free DCL IS_CHARACTER SEMA PRESET(0); ! Init: empty DATAFETCH: TASK; REQUEST FETCH_TWO_CHARACTERS_FROM_THE_RINGBUFFER;; REQUEST IS_PLACE; FETCH_TWO_CHARACTERS_FROM_THE_RINGBUFFER; RELEASE IS_PLACE; RELEASE IS_PLACE; END; DATAPUT: TASK; REQUEST IS_PLACE; PUT_ONE_CHARACTER_INTO_RINGBUFFER; RELEASE IS_PLACE; END;
Producer-consumer-schemes also occur at the digital measuring and the automation of production processes.
When the programmer wants to allow the reading of a data record by several tasks simultaneously (in the example the tasks
READER2), but only one task can write without another task reading at the same time, BOLT-variables are the choice.
PROBLEM; DCL A CHAR(255); ! String: 255 Bytes DCL BOLTVAR BOLT; ! Default: free READER1: TASK; DCL L1 CHAR(255); ! ENTER allows, that all other tasks with ENTER ! can continue to run ENTER BOLTVAR; L1=A; LEAVE BOLTVAR; END; READER2: TASK; DCL L2 CHAR(255); ENTER BOLTVAR; L2=A; LEAVE BOLTVAR; END; WRITER1: TASK; DCL S1 CHAR(255); ! After a RESERVE a task only continues to run if ! no other reader or writer has executed an ! ENTER/RESERVE. RESERVE BOLTVAR; A=S1; FREE BOLTVAR; END; WRITER2: TASK; DCL S2 CHAR(255); RESERVE BOLTVAR; A=S2; FREE BOLTVAR; END;
PEARL offers an own keyword for each of the different in- and output forms. In the following examples
alphic_dation stands for a
harddisk, terminal, LCD-display and serial or parallel interface e.g., a
basic_dation stands for an analog or digital process I/O e.g.
- formatted output
PUT objekt1, ... TO alphic_dation BY formatliste;
- binary output
WRITE objekt1, ... TO alphic_dation;
- output to process periphery
SEND objekt1, ... TO basic_dation;
- formatted output
- formatted read-in
GET objekt1, ... FROM alphic_dation BY formatliste;
- binary read in
READ objekt1, ... FROM alphic_dation;
- read from process periphery
TAKE objekt1, ... FROM basic_dation;
- formatted read-in
The sizes in the individual format lists can be fixed by constants and also by variables and function calls. They don't need to be known already at time of compilation..
Both these data types describe dates and periodics. With the time schedules these data types also appear. In the mentioned examples
12:00is a constant of the type
0.00005 SECa constant of the type
DURATION. Arithmetic operations between these data types are also possible, as the following two examples show.
durationvar = clockvar - clockvar
clockvar = clockvar + durationvar
These data types must be connected in the system part of a module with a hardware interrupt entry. In the problem part they can be used with the above described means (
WHEN ..) for changing a task state.
Semaphore-variables are used for the synchronisation between different tasks, mainly for the protection of compound data objects, which are used by several tasks at the same time. Used with critical paths or producer consumer-schemes. A semaphore emulation is not possible without support of the operating system, as the usual high language operations 'allocate, resp. block' resp. 'release or continue blocked tasks' must not be divisible in a multitasking system.
Contrary to semaphores, boltvariables allow a reading access to data of several tasks and at the same time block writing tasks, when another task has started a reading- or writing access. Regarding the emulation of these variables without support of the operating system, the explanations to semaphores apply analogously.